In che modo Android L raggiunge una crittografia strong con una frase d'accesso a bassa entropia?

Le carte bancarie basate su chip utilizzano in genere un PIN a 4 cifre. Ci vorrebbero al massimo alcune ore per provarli tutti se la carta non proteggesse da tentativi di forza bruta. La carta protegge dai tentativi di forza bruta murando se stessa dopo 3 fallimenti consecutivi. L'avversario non ha accesso a un hash del PIN (ci sono protezioni fisiche nella scheda che rendono estremamente difficile leggere la sua memoria), ma solo a una scatola nera che prende 4 cifre come input e risponde "sì" o " no". La chiave per la sicurezza qui è che l'avversario può effettuare solo tentativi online, non tentativi offline . Ogni tentativo richiede il calcolo sul dispositivo di difesa, non si tratta solo di fare i conti.

Un telefono Android o qualsiasi altro computer può fare la stessa cosa con la sua chiave di crittografia di archiviazione. La chiave non deriva dalla passphrase (o pattern), ma è memorizzata da qualche parte e crittografata con la passphrase. La maggior parte dei sistemi di crittografia di archiviazione ha questo indiretto in modo che la modifica della passphrase non richieda la crittografia dell'intero spazio di archiviazione e che la memoria possa essere cancellata efficacemente cancellando i pochi byte che compongono la chiave crittografata (la chiave di crittografia è uniformemente casuale quindi, a differenza di una chiave derivata da una passphrase, non è soggetta a forza bruta: l'avversario deve ottenere almeno la chiave di archiviazione crittografata per ottenere un punto d'appoggio).

Se l'avversario può leggere la chiave di archiviazione crittografata, può eseguire rapidi tentativi di forza bruta sulla chiave su un cluster di PC. Ma se la chiave di archiviazione è archiviata in una memoria resistente alle manomissioni, l'avversario non è in grado di leggerla e può solo inviare tentativi di passphrase al dispositivo, quindi il dispositivo può applicare criteri come "limitare la velocità di tentativi di 3 al minuto "o" richiedono una seconda passphrase più lunga dopo 10 tentativi falliti ".

La nuova funzionalità di Android L è il supporto upstream per una chiave di archiviazione crittografata che non è archiviata nella memoria flash (dalla quale può essere scaricata con un po 'di saldatura o con accesso root), ma in alcune memorie protette (che può essere accessibile solo in modalità sicura TrustZone ). Tuttavia, non tutti i telefoni che eseguono Android L dispongono di tale memoria protetta e, anche se è presente, non è garantito che sia utilizzato per la crittografia. Tutte le modifiche di Android L stanno fornendo il codice richiesto come parte dell'immagine di base di Android, rendendo più facile l'integrazione dei fornitori di telefoni.

Android fornisce un'API per controllare se la memoria del portachiavi dell'applicazione è nella memoria protetta ). Non so se esiste un'API corrispondente per verificare la protezione della chiave di crittografia di archiviazione.

Non so se questo è il modo in cui lo fa Android, ma un dispositivo di archiviazione sicuro supportato da hardware può bloccare tentativi ripetuti troppo rapidamente, rendendo invalida la supposizione di 0.1 tentativi al secondo. Supponiamo che inizialmente consenta un tentativo ogni 0,01 di secondo, ma raddoppia il tempo tra i tentativi con ciascun errore dopo i primi cinque. Dopo soli 50 tentativi, dovrai aspettare 250 mila anni prima di poter riprovare (e ci vorranno 250 mila anni per arrivare così lontano). Tuttavia, se riesci a inserire correttamente il tuo passcode in 10 tentativi o meno, non noterai alcun ritardo.

La generazione di una chiave e l'uso di una pass-frase sono due cose diverse. Le chiavi, ad esempio nella crittografia asimmetrica, sono generate utilizzando l'entropia proveniente dall'ambiente del computer (come /dev/urandom , che potrebbe o meno essere una buona fonte di entropia, ma questo è un altro dibattito). Quindi la chiave in sé non ha nulla a che fare con la frase d'accesso. La passphrase verrà semplicemente utilizzata per crittografare la chiave stessa in un contenitore progettato per memorizzare la chiave.

Se qualcuno vuole decrittografare i dati del disco, ha bisogno della chiave. Trovare la chiave dovrebbe essere quasi impossibile nelle giuste condizioni. Se fatto correttamente, interrompere la crittografia del contenitore delle chiavi dovrebbe essere impossibile anche senza la chiave.

Per quanto riguarda la forzatura brute della chiave, potrebbe essere di fatto un'operazione banale se l'utente malintenzionato ha accesso al file chiave crittografato, considerando lo spazio-chiave basso. È il dispositivo responsabile di rendere tale file chiave crittografato non disponibile per l'autore dell'attacco.

Dal tuo articolo collegato ho letto:

Obtaining a raw copy of a disk partition is usually not possible on most commercial devices, but can be achieved by booting a specialized data acquisition boot image signed by the device manufacturer, exploiting a flaw in the bootloader that allows unsigned images to be booted (such as this one), or simply by booting a custom recovery image on devices with an unlocked bootloader (a typical first step to 'rooting').

Questi attacchi, se non impossibile, richiedono qualche investimento (in termini di tempo o denaro). Tutta la sicurezza è un compromesso.

Ho anche letto:

Assuming that the implementation is similar to that of the hardware-backed credential store, disk encryption keys should be encrypted by an unextractable key encryption key stored in the SoC, so obtaining a copy of the crypto footer and the encrypted userdata partition, and bruteforcing the lockscreen passphrase should no longer be sufficient to decrypt disk contents.

Quale dovrebbe risolvere il secondo problema.

Penso che i seguenti quattro approcci coprano più o meno tutte le possibilità per ciò che potrebbe essere fatto:

• Utilizzare una funzione di derivazione dei tasti costosa (in termini di tempo CPU). Tuttavia, rallentando l'attaccante di qualsiasi fattore in questo modo si rallentano gli attacchi legittimi con lo stesso fattore. E realisticamente, l'aggressore sarà in grado di utilizzare più potenza della CPU rispetto a quella presente su un singolo dispositivo mobile e l'autore dell'attacco può probabilmente aspettare più a lungo di una risposta rispetto a ciò che un utente è disposto ad attendere per sbloccare il dispositivo. Come hai giustamente capito, questo approccio richiede più entropia di un milione di possibili passphrase possibili.
• Utilizza hardware antimanomissione. Metti la chiave in un hardware specializzato che limiterà il numero di tentativi di estrazione della chiave a una frequenza specificata e diminuirà quella percentuale in caso di tentativi falliti. Probabilmente anche distruggendo la chiave dopo un gran numero di tentativi falliti. Funziona solo contro un avversario che non può rimuovere questo hardware ed estrarre la chiave dall'interno.
• Utilizza un servizio online. Se si ha accesso a un servizio online, tale servizio potrebbe fornire parte del calcolo necessario e applicare un limite tariffario. Un'operazione RSA in cieco potrebbe raggiungere questo obiettivo senza perdite di informazioni sulla chiave o sui dati crittografati per il servizio online. Ma non molto pratico, dal momento che il dispositivo potrebbe non avere accesso a una connessione di rete ogni volta che si desidera sbloccarlo.
• Usa la memoria quantistica. Questa è fondamentalmente una variazione dell'hardware resistente alla manomissione, ma impone la distruzione della chiave dopo un numero massimo di tentativi facendo affidamento sulla fisica quantistica. Anche poco pratico, perché non penso che nessuno abbia progettato con successo la memoria quantistica in grado di contenere dati abbastanza a lungo da poterlo utilizzare per dati persistenti.

Di quanto sopra l'hardware antimanomissione sembra l'approccio più pratico.