È ragionevolmente sicuro usare il codice PIN per la crittografia?

19

Su Android 4.0 (Samsung Galaxy Nexus) esiste la possibilità di crittografare il telefono. Ho trovato questo sulla crittografia su Android 3.0, sono gli stessi algoritmi utilizzati in Android 4? http://source.android.com/tech/encryption/android_crypto_implementation.html

La mia domanda principale riguarda l'uso di un codice PIN per decrittografare il telefono. Perché sono costretto a utilizzare la stessa password per sbloccare lo schermo e decrittografare il telefono? Questa limitazione mi consentirà di utilizzare solo una password di bassa complessità (come un numero PIN) poiché sarebbe difficile scrivere in 17 caratteri per sbloccare il mio telefono per una semplice telefonata.

Tentativi di forza bruta contro lo sblocco dello schermo potrebbero essere impediti, ad esempio con un riavvio forzato ogni 5 tentativi. Quindi non c'è bisogno di una password molto forte lì, un PIN potrebbe essere abbastanza buono.
Questo tipo di protezione non può essere utilizzato sul disco, pertanto qui è necessario disporre di password più complesse. (Non è molto utile che le entropi delle password siano aumentate poiché ci saranno pochissimi utenti con una password complessa, quindi un utente malintenzionato potrebbe semplicemente provare la maggior parte delle password con bassa complessità). Qual è il ragionamento alla base dell'obbligo di utilizzare la stessa password per entrambe le funzionalità?

security  encryption 
— Christopher Käck
fonte
3
Sì, ma se uso la password avrei bisogno di usarla per sbloccare semplicemente il mio schermo. Non molto utile digitare 17 caratteri per effettuare una chiamata veloce. Pertanto, la maggior parte degli utenti dovrà fare i conti con i numeri PIN e questa sarebbe la prima cosa che un utente malintenzionato dovrebbe provare. Un approccio migliore potrebbe forse essere quello di consentire passphrase per la crittografia del disco e consentire semplici numeri PIN nella schermata di blocco. Per evitare tentativi di bruteforce sulla schermata di blocco, è possibile che si verifichi un riavvio forzato dopo 3 tentativi non riusciti che comportano la richiesta della password.
— Christopher Käck il
1
Non so che chiunque non sia Google potrebbe purtroppo dirti il ​​ragionamento. Probabilmente potresti provare il tracker di bug Android per presentare una richiesta di funzionalità. Sembra una cosa ragionevole archiviare lì.
— eldarerathis,
2
Sì, contro il tentativo di accesso nella schermata di sblocco, ma non contro la decrittografia del disco rigido. Questo è quello che sto cercando di dire, lo sblocco dello schermo non deve essere lungo quanto la crittografia del disco rigido (che deve essere molto più lungo di 4 numeri) e quindi non si dovrebbe essere costretti a usare lo stesso per entrambi.
— Christopher Käck,
1
+1, sono totalmente con te @ ChristopherKäck Quella decisione non ha senso, gli ingegneri di Google avrebbero dovuto conoscerlo meglio, spero che lo risolvano presto.
— João Portela,
1
@Christopher: ma stai basando la tua decisione su una premessa errata, la crittografia su disco era AES a 128 bit, non il PIN a 4 cifre. Determinare se questo schema è sicuro o intrinsecamente difettoso, non è l'esperienza di Android.SE.
— Lie Ryan,

Risposte:

4

Penso di aver trovato la soluzione. Controllare questo link . È un hack e richiede il root di un telefono, ma ti consente di usare password alfanumerica per crittografia e PIN per sbloccare lo schermo.

— Oscar_6
fonte
1

Utilizzando una password / frase rispetto a un pin a quattro cifre, aumenta la sicurezza del dispositivo. Il trucco è che, anche se hai una password di quattro caratteri, hai appena aumentato la tua sicurezza per due motivi:

  • Hai aumentato i personaggi disponibili.
  • Hai portato via la conoscenza degli attaccanti della tua lunghezza pw.

Se un utente malintenzionato sa che la tua password è di 14 caratteri, è più sicura di una password di quattro o otto caratteri, ma le statistiche tipiche utilizzano intervalli (1-4, 1-8, 1-14) e non la realtà (che sarebbe semplicemente un calcolo combinazioni disponibili di una lunghezza).

Attualmente, è semplicemente MODO FACILE accedere ai dati del tuo telefono. Tua nonna ha la capacità di farlo (senza offesa per te o la tua famiglia: P). Quindi, mentre hai ragione sul fatto che ci sono limiti di questa crittografia, la versione "rotta" funziona MOLTO meglio dei dati non crittografati attualmente praticati.

Spetta a voi giudicare quanto siano sensibili e privati ​​i vostri dati, nonché la vostra destinazione per il furto di tali dati. La scelta di una password appropriata è una tua responsabilità dopo aver valutato questi rischi.

— earthmeLon
fonte
2
Sì, ma penso che sarebbe una semplice soluzione al problema avere password diverse per sbloccare lo schermo e per decrittografare il dispositivo (come ho già detto qui android.stackexchange.com/questions/17086/… ) poiché sono usati in diversi senarios e devono avere attributi diversi.
— Christopher Käck,
1

Se stai cercando di decifrare la crittografia del disco, indipendentemente dal resto del dispositivo in uno scenario in cui hai un dispositivo spento, o solo i chip di memoria, allora questo è un vettore di attacco diverso da quello utilizzato su un acceso dispositivo protetto da password in cui la chiave di decrittazione può essere conservata in memoria (portando a vulnerabilità utilizzate da cose come i ladri di chiavi di crittografia Firewire prevalenti sui PC che utilizzano software di crittografia FDE precedente e non un modulo di tipo TPM), oppure la schermata di sblocco potrebbe essere bruta- forzato (o ha le proprie vulnerabilità).

Se stai attaccando direttamente il disco, in questo caso non stai attaccando il PIN di 4 cifre o la password dell'utente che sta crittografando il dispositivo, quello che stai attaccando è la chiave AES a 128 bit:

La chiave principale è un numero a 128 bit creato leggendo da / dev / urandom. È crittografato con un hash della password utente creata con la funzione PBKDF2 dalla libreria SSL. Il piè di pagina contiene anche un salt casuale (anche letto da / dev / urandom) usato per aggiungere entropia all'hash da PBKDF2 e prevenire attacchi da tavolo arcobaleno alla password.

Dal punto 4 in " Abilitazione della crittografia sul dispositivo " delle Note sull'implementazione della crittografia in Android 3.0 a cui si è collegati.

(sarebbe stato un commento ma è finito troppo a lungo)

— GAThrawn
fonte
1
Grazie per questo bel commento! Una cosa però; non sto cercando la password dell'utente (che molto probabilmente sarà un pin a 4 cifre, perché sei costretto a condividere la chiave con lo sblocco dello schermo e qualsiasi altra cosa sarà una seccatura da digitare per effettuare una chiamata) per decrittografare i 128 bit Chiave AES? (invece di cercare direttamente la chiave). Se eseguo il hash di tutti i 10000 pin con la funzione PBKDF2 + salt, non ci sono solo 10000 tentativi di decrittazione per me da provare allora?
— Christopher Käck,
@Melpomene L '" attacco della tabella arcobaleno " di cui parlano è il punto in cui pre-crittografate tutte le 10.000 combinazioni per vedere come sembrano crittografate e quindi confrontare ciò che è sul disco con ciò che è nella tabella arcobaleno. Il " sale casuale " è ciò che viene utilizzato per aiutare a prevenire ciò creando molto più di 10.000 combinazioni che dovrete indovinare (a meno che non riusciate a elaborare prima il "sale").
— GAThrawn
1
Un arcobaleno è un modo intelligente per archiviare le password crittografate sì. E se viene usato un sale, probabilmente dovrebbe essere appositamente costruito solo per decifrare le password con quel sale. Questa non è un'operazione molto difficile quando ci sono solo 10.000 password tra cui scegliere. Si noti che Salt è sempre considerato noto all'attaccante (poiché sembra essere letto da / dev / urandom nei documenti, è molto probabilmente memorizzato in chiaro o crittografato con la password dell'utente). In entrambi i casi la password dell'utente è l'anello debole.
— Christopher Käck,
Ma non avrei nemmeno bisogno di costruire un arcobaleno poiché la memorizzazione (o il calcolo) di 10.000 hash non è così difficile per la mia memoria (processore).
— Christopher Käck,
L'uso di una funzione di derivazione dei tasti come PBKDF2 sembra una buona notizia, ma un tipico pin a 4 cifre è ancora solo 10000 combinazioni possibili.
— João Portela,
0

Se hai abilitato la cancellazione remota (supponendo che funzioni ancora con un dispositivo crittografato), il PIN potrebbe non proteggere il tuo dispositivo per sempre, ma potrebbe impiegare così tanto tempo per darti il ​​tempo di cancellare il tuo dispositivo.

— Opportunità
fonte
2
Il problema è che un breve PIN può proteggere il dispositivo solo quando è acceso. Pertanto, la disattivazione di un dispositivo rubato impedisce che il dispositivo venga cancellato e inoltre il PIN può essere rotto in un attacco di forza bruta offline. Quindi un breve PIN non ti aiuta in questa situazione.
— Robert,
@Robert, non ho familiarità con il funzionamento della cancellazione remota. Se viene eseguito tramite Exchange, il telefono deve trovarsi nello stesso momento in cui viene emesso il comando di cancellazione remota? Il mio pensiero è che se posso emettere una cancellazione remota entro circa 30 minuti dalla perdita del telefono, ciò è abbastanza buono per me, ma non ho dati finanziari, la mia preoccupazione principale è la mia e-mail di lavoro GMail.
— Probabilità del
2
Il telefono deve essere acceso e in linea un po 'di tempo dopo aver emesso il comando di cancellazione remota. Se il telefono è stato spento (e rimane spento) il comando di cancellazione è inutile.
— Robert,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.