C'è qualche spazio di archiviazione sicuro in Android tramite Monodroid fuori dalla scatola?

Question

Come molte persone - Sto sviluppando un'applicazione con base di codice condivisa (Windows Store + Android + MonoTouch + [successivo] WP8).

Inoltre, come con molte app, ho lo stato locale di cui ho bisogno per mantenere questa app.

Una parte di informazioni che memorizzo è un token di autenticazione per l'utente che ha eseguito l'accesso. Sulla piattaforma di Windows Store ho implementato l'archiviazione di questo con una combinazione di impostazioni di roaming (ApplicationData.Current.RoamingSettings) per i dati ausiliari del token (nome utente e data di emissione) e lo PasswordVault per il valore di token effettivo. Pertanto il token è protetto dall'introspezione a livello di sistema operativo, poiché è crittografato dal sistema operativo.

Ora sto implementando la stessa interfaccia per il mio build MonoDroid, e non vedo in alcun modo, fornito dalla piattaforma, di memorizzare dati che possono essere decifrati dalla mia applicazione - allo stesso modo della password vault può essere utilizzato per le app Store.

Come risultato, al momento sto semplicemente utilizzando l'interfaccia Android.Content.ISharedPreferences tramite il metodo Application.Context.GetSharedPreferences per leggere e scrivere questi valori.

Quindi ho ragione nel ritenere che la piattaforma (MonoDroid o Android) non offra spazio di archiviazione sicuro OOB? È l'unica alternativa per implementare la crittografia all'interno dell'app, che ovviamente richiederà la cottura della chiave di crittografia nel codice? Oppure posso prendere il certificato utilizzato per firmare l'app e usarlo come chiave?

In ultima analisi, non è la fine del mondo se non riesco crittografare questi dati, dal momento che il token è tempo limitato in ogni caso - ma sarebbe bello se potessi farlo davvero correttamente!

Answer 1

Forse questo citando here può aiutare:

Sul lato OOB Android non è supportato nella API pubblica e quindi le cose si fanno difficili . Credo che questo sia dovuto al fatto che Honeycomb 3.2 non ha uno stack bluez che supporta ufficialmente l'OOB bonding, ma Google ha un codice di implementazione codificato. Credo che questo sia dovuto al codice sorgente per l'adattatore Bluetooth e il dispositivo Bluetooth Nelle classi è possibile visualizzare i metodi OOB disponibili ma non esposti tramite l'API documentata .

Questi metodi sono ancora pubblici, quindi è possibile chiamarli tramite la riflessione . Usando la reflection puoi anche ottenere tutte le firme del metodo in una classe. Questo è il modo in cui ho capito quali metodi avevo a disposizione .

Attenzione però che molti non sono documentati e non è chiaro cosa fanno alcuni . I più importanti da prendere in considerazione sono readOutOfBandData() nella classe adapter e setDeviceOutOfandData() nella classe del dispositivo.

Answer 2

Si potrebbe usare con una combinazione di Keychain API (disponibile in API di livello 14 in poi) e la crittografia dei dati con Cipher API utilizzando il certificato dal api portachiavi.

Prendete nota: secondo sicurezza Android Panoramica documento, non v'è alcuna garanzia se il dispositivo è radicata: http://source.android.com/tech/security/index.html#rooting-of-devices