2010-07-27 11 views
21

Desidero memorizzare alcune informazioni piccole ma importanti come le chiavi AES nella mia applicazione Android. Quale sarebbe il modo consigliato per farlo? Non voglio le chiavi con hardcode come parte della mia applicazione.Android Secure Storage

Guardo KeyStore ma in realtà non risolve il mio problema. Può memorizzare le mie chiavi dato che posso fornire una password. Quindi ho bisogno di trovare un posto sicuro per memorizzare questa password, che è la stessa del mio problema originale.

Esiste una classe Android integrata per eseguire questa attività? O dovrei cercare librerie di terze parti? Anche l'uso di NDK è accettabile per me.

Aggiornamento:

Speravo di trovare un'API di Android per lo storage in modo che garantisce che solo l'applicazione che memorizzate alcune informazioni possono recuperare indietro. Il sistema operativo Android avrebbe potuto applicarlo in base alle firme di firma dell'applicazione. In questo modo la mia applicazione può generare una chiave casuale al primo avvio e memorizzarla in un archivio sicuro per un uso successivo. Ci sono API per questo?

+2

Beh, se si memorizzano i dati in '/ dati/dati dell'applicazione/ /' allora solo che l'applicazione possa accedervi. Questo non è vero se il telefono è radicato però. Ma a parte questo, dovresti essere ok a memorizzare i dati della password lì. – Falmarri

risposta

5

Esiste una classe Android integrata a eseguire questa attività?

diverso da java.io.File, n.

Oppure devo cercare librerie di terze parti ?

Puoi provare, ma sospetto che la maggior parte sembrerà la soluzione che hai già rifiutato. Gli archivi di dati più sicuri includono password e presuppongono che le password siano conservate altrove (ad esempio, nella testa di un utente). Ad esempio, OI Safe dispone di un sistema basato su Intenti che consente alle applicazioni di archiviare materiale nella cassaforte, ma l'utente è coinvolto nello sblocco della cassaforte IIRC.

+0

Grazie per la risposta. In realtà non risolve il mio problema, ma è bene conoscere i limiti. –

+0

@Szere Dyeri: "Speravo di trovare un'API Android per l'archiviazione in modo tale da garantire che solo l'applicazione che ha memorizzato alcune informazioni possa recuperarla". - non ci sono tali API in Android, mi dispiace. – CommonsWare

+2

Cosa intendi se non esiste una tale API? Questa garanzia è il comportamento predefinito per tutti i file che l'app memorizza nella memoria interna, poiché ad ogni applicazione viene assegnato un ID utente univoco e la modalità predefinita dei file che un'app crea deve essere leggibile/scrivibile solo dall'utilità del creatore. L'unica eccezione a questo è (a) i file posizionati su una memoria esterna e (b) i file creati con la bandiera per renderli leggibili/scrivibili. L'unico modo in cui un'altra applicazione può essere eseguita con il tuo uid è se entrambi (a) sono firmati con il tuo cert e (b) entrambi hai lo stesso androide: sharedUserId. – hackbod

4

Una soluzione, se si finisce con l'utilizzo dell'API KeyStore, è di generare la password in modo dinamico in fase di esecuzione ogni volta che l'app deve accedere al KeyStore. Se si basa l'algoritmo della password su una variabile semplice, ma variabile, legata all'installazione specifica come il MEID del dispositivo (o altro ID specifico del dispositivo fisico acquisito in fase di esecuzione), è possibile fornire una chiave per il blocco che diventa sempre più difficile prendere.

Esempio: utilizzare un ID dal dispositivo fisico, tagliare in tre posizioni e aggiungerle alla posizione finale nella stringa ID, quindi aggiungere le iniziali alla stringa in modo programmatico. Penserei che questo approccio darebbe un livello di sicurezza che non può essere facilmente rotto a meno che il cracker non sappia come hai fatto la chiave (cioè il tuo codice sorgente).

MEID = MEID + "fluffy" + "2008"; 

Dove MEID è una stringa con un po 'ID del dispositivo, "soffice" è il nome dei tuoi migliori amici gatto, e "2008" è l'anno di un evento importante nella vostra vita. Quindi inserisci questa nuova stringa in un array, analizza un numero adatto a te (il giorno del mese in cui hai ottenuto la patente di guida, ad esempio), prendi tre caratteri e rilascia questi caratteri alla fine della stringa. Aggancia dalla parte anteriore della corda al numero di posizioni necessarie per la tua chiave e via. Questo non dovrebbe essere un compito molto intensivo del processore quindi, con un codice di tolleranza agli errori per le variabili, dovresti essere in grado di eseguirlo nel tuo processo principale anche senza troppa preoccupazione di ottenere un ANR dal sistema. Se vuoi davvero diventare froggy, converti la stringa in bit ad un certo punto e 'bitwise op' le modifiche. Viola, una chiave dinamica in basso, che è unica per il dispositivo su cui viene eseguita!

EDIT:

Come @RedWarp sottolineato, decompilazione un .apk è sempre nel regno del possiblility per qualsiasi codice oggetto con gli strumenti adeguati e la motivazione. Se la generazione della "chiave" è un processo veramente importante, è necessario astrarre la chiave gen al di fuori dell'ambito dell'app.

Il vero punto che sto cercando di fare con questa risposta è che un po 'di prospettiva può andare in un modo per quanto riguarda la sicurezza minima. Una sicurezza più forte è più approfondita di una semplice risposta da parte mia.

+1

La sicurezza attraverso l'oscurità può ritardare solo un aggressore persistente. Di sicuro aggiunge spezie alla ricetta. Non dovrebbe essere usato come unica opzione valida. – Samuel

+0

@SamQuest Ovviamente questo non è presentato come un'opzione valida solo, ma è un inizio, per indurlo a pensare in altri e unici modi per quanto riguarda la sicurezza chiave. Ma a meno che l'app in questione non sia un'applicazione finanziaria o un'altra implementazione ad alta sicurezza, questo dovrebbe fornire un'adeguata oscurità. Un'altra opzione potrebbe essere quella di fornire in remoto la chiave oscurata attraverso uno script RPC o qualcosa del genere, ma questo approccio includerà probabilmente ulteriore complessità. – Kingsolmn

+2

È abbastanza facile invertire un .apk e quindi ottenere l'algoritmo – Redwarp

0

È necessario distinguere tra chiavi e dati dell'app.

"AndroidKeyStore" KeyPairGenerator e KeyGenerator memorizzano le chiavi generate dall'app sotto un alias nel KeyStore e associano le chiavi all'app. Se il dispositivo ha "hardware sicuro", è possibile specificare che verrà utilizzato e le chiavi verranno memorizzate lì.

Non esiste alcuna password per i tasti. Si utilizza l'alias per specificare quale chiave si desidera utilizzare. Solo la tua app può recuperare le chiavi che aveva generato.

vedere: https://developer.android.com/training/articles/keystore.html

Per i dati privati ​​della tua app, se ho capito ".. un'API di Android per lo storage in modo che garantisce che solo l'applicazione che memorizzate alcune informazioni possono recuperare indietro ...", Si potrebbe guardare a questi:

https://developer.android.com/guide/topics/data/data-storage.html#filesInternal https://developer.android.com/guide/topics/data/data-storage.html#db