Android implementa la crittografia del dispositivo in un modulo di Vold (Volume Daemon) chiamato cryptfs che effettua le chiamate al kernel che effettivamente crittografano il dispositivo. Quando un utente crittografa il dispositivo, Vold riavvia il dispositivo e inizia a crittografare la partizione dati. Durante il processo di crittografia Vold disabilita tutto ciò che non è un servizio di base sul dispositivo. Android richiede che l'utente crei un passcode se non ne ha già impostato uno all'inizio del processo di crittografia, che è una delle critiche dell'implementazione in quanto il processo di decrittazione è legato al codice di accesso dello screen per gli utenti che non è super complesso . Una volta crittografato il dispositivo, in base alla documentazione nella pagina AOSP, la chiave master crittografata viene archiviata nel piè di pagina della partizione dati. Per quanto ne so, l'implementazione di Android crittografa solo la partizione dati, che sarebbe dati utente e app. Una volta che il dispositivo è stato crittografato, l'utente dovrà inserire il proprio codice di accesso ogni volta che il telefono è bloccato. Prima che possano accedere ai loro dati, il kernel monta un tmpfs / dati che legge dai dispositivi a blocchi effettivamente cifrati. Lo schermo sblocca il passcode con codice hash e viene utilizzato per decrittografare la chiave master. Questa è la descrizione delle Note sull'implementazione della crittografia.
The crypto footer contains details on the type of encryption, and an encrypted copy of the master key to decrypt the filesystem. The master key is a 128 bit number created by reading from /dev/urandom. It is encrypted with a hash of the user password created with the PBKDF2 function from the SSL library. The footer also contains a random salt (also read from /dev/urandom) used to add entropy to the hash from PBKDF2, and prevent rainbow table attacks on the password. Also, the flag CRYPT_ENCRYPTION_IN_PROGRESS is set in the crypto footer to detect failure to complete the encryption process. See the file cryptfs.h for details on the crypto footer layout. The crypto footer is kept in the last 16 Kbytes of the partition, and the /data filesystem cannot extend into that part of the partition.
Una volta che il dispositivo è stato crittografato, l'unico modo per annullarlo è cancellare i dati. Non penso che l'implementazione di default che si ottiene nella sorgente AOSP codifichi la scheda SD poiché non tutti i dispositivi Android hanno una scheda rimovibile, come il Galaxy Nexus, ma suppongo che i produttori di dispositivi possano aggiungere supporto per questo. La documentazione AOSP sull'implementazione FDE è disponibile qui, Implementazione di Notes Android per la crittografia . È piuttosto approfondito rispetto ad altri documenti AOSP. Potresti essere interessato a controllare questo post del blog, Ripristino della chiave di crittografia con avvio a freddo su un telefono Android che contiene alcune informazioni sul tentativo di ripristino delle chiavi con CyanogenMod7.
Le sue conclusioni erano:
The key is fully recoverable if the phone reboots itself. It may be recoverable if the soft reset keychord is used. It may be partially recoverable if rebooted by power-pull (there may be an error in the experiments here.) It appears to not be recoverable if the phone powers itself off. Variables such as rebooting directly to fastboot or doing a normal reboot while holding the fastboot key, or leaving it connected to USB or not, appear to be irrelevant.
Ma stava eseguendo CyanogenMod7 quindi non so se questo è generalmente applicabile alle ROM di riserva su dispositivi o ROM costruiti direttamente da AOSP, ma forse ci sono altre informazioni e ricerche sul potenziale di recupero delle chiavi.
Spero che questo aiuti alcuni.