Ho appena installato Marshmallow su un Nexus 5 tramite un aggiornamento push. Sono confuso sul modo in cui funziona la crittografia. Ho una buona conoscenza tecnica della crittografia sui computer. Vorrei acquisire conoscenze simili su Android 6.

Quello che segue è quello che ho fatto e come mi sono confuso. Dopo un ripristino delle impostazioni predefinite, ho impostato un PIN, quindi ho crittografato il dispositivo. All'avvio mi ha chiesto il mio PIN, che era previsto. Ho quindi rimosso il PIN e riavviato il dispositivo. Non ha richiesto alcun PIN all'avvio, ma il dispositivo si è comunque segnalato come crittografato nel menu di configurazione. Quest'ultimo è ciò che mi confonde poiché mi aspettavo che il PIN sbloccasse la chiave di decrittazione.

Domande:

• Nel caso della crittografia senza PIN, da dove proviene la chiave di decrittazione? Presumo che sia memorizzato su un chip simile a un TPM, è corretto? In tal caso, cosa impedisce a un hacker di richiedere questa chiave dal chip? Controlla l'hash del firmware? Qualunque altra cosa? I dettagli tecnici sarebbero molto apprezzati.
• Nel caso della crittografia con un PIN, il PIN viene utilizzato come token aggiuntivo per accedere alla chiave di decrittografia? Oppure il processo di decodifica funziona esattamente come se non ci fosse il PIN.

TL; DL risposta:

La chiave di decrittazione è sbloccata con tutto quanto segue:

• Il PIN (o password, ecc.) O una password predefinita se non ce n'è
• Un TEE (un generatore di firma con supporto hardware che utilizza chiavi che non possono essere estratte)
• Un sale (prontamente disponibile ma prevenendo gli attacchi delle tabelle arcobaleno)

Sto citando dal manuale di Android qui , ma:

NOTA:

La fonte che ho usato non è direttamente pertinente a Marshmallow ma è rilevante per Lollipop e superiori.

TL: DR

Ora affronterò solo le domande del PO. Seguiranno i dettagli tecnici.

1. La chiave di crittografia predefinita proviene da un'origine hardware (un chip simile a un TPM) e la password predefinita di AOSP definita come default_passwordnel cryptfs.cfile di origine, vedere di seguito.

2. Sì, non solo il valore predefinito, ma qualsiasi password viene trasformata in una chiave e memorizzata su un chip simile a TPM, chiamato TEE (abbreviazione di "Trusted Execution Environment", vedi sotto per ulteriori dettagli).

3. Un hacker con accesso UART / JTAG ai chip sul SoC del dispositivo potrebbe tecnicamente ottenere l'accesso alla chiave TEE o un kernel personalizzato può trasferire queste informazioni a un hacker. Alcune agenzie di 3 lettere nelle teorie della cospirazione possono eventualmente collaborare con l'OEM per ottenere questi kernel insicuri utilizzati nei dispositivi di produzione, ma non dispongo molti negozi. Ancora una volta, vedere l'ultima sezione di questa risposta per ulteriori dettagli.

L'unica cosa che impedisce a un hacker di accedere alla chiave è la grande quantità di sforzi necessari per farlo.

4. Il controllo dell'hash di (checksum) del firmware (chiamato "Avvio verificato" di Google) viene infatti eseguito su Lollipop e sopra di default (ed è disponibile da JellyBean 4.3 in poi), da un modulo del kernel chiamato dm-verity. Tuttavia, questo è indipendente dallo stato della crittografia.

Fonte: guida alla sicurezza AOSP qui .

5. Informazioni sul processo coinvolto nella decodifica del sistema con una password personalizzata, vedere di seguito. Ti dirò solo qui che la password dell'utente è coinvolta sia nella creazione che nell'uso della chiave di crittografia.

Panoramica

Al primo avvio, il dispositivo crea una chiave master a 128 bit generata casualmente e quindi l'hash con una password predefinita e salt memorizzato. La password predefinita è: "default_password" Tuttavia, l'hash risultante viene anche firmato tramite un TEE (come TrustZone), che utilizza un hash della firma per crittografare la chiave master.

Puoi trovare la password predefinita definita nel file cryptfs.c del Progetto Open Source Android .

Quando l'utente imposta il PIN / pass o la password sul dispositivo, solo la chiave a 128 bit viene nuovamente crittografata e memorizzata. (ad es. le modifiche al PIN / pass / pattern dell'utente NON causano la crittografia della partizione userdata.)

Avvio di un dispositivo crittografato con crittografia predefinita

Questo è ciò che accade quando si avvia un dispositivo crittografato senza password. Poiché i dispositivi Android 5.0 sono crittografati al primo avvio, non dovrebbe esserci una password impostata e quindi questo è lo stato di crittografia predefinito.

1. Rileva dati / crittografati senza password

Rileva che il dispositivo Android è crittografato perché / data non può essere montato e uno dei flag encryptableo forceencryptè impostato.

voldimposta vold.decryptsu trigger_default_encryption, che avvia il defaultcryptoservizio. trigger_default_encryptioncontrolla il tipo di crittografia per vedere se / data è crittografato con o senza password.

2. Decifrare / dati

Crea il dm-cryptdispositivo sul dispositivo a blocchi in modo che il dispositivo sia pronto per l'uso.

3. Montare / dati

voldquindi monta la partizione reale / dati decodificata e quindi prepara la nuova partizione. Imposta la proprietà vold.post_fs_data_donesu 0e quindi imposta vold.decryptsu trigger_post_fs_data. Questo provoca init.rcl'esecuzione dei suoi post-fs-datacomandi. Creano tutte le directory o i collegamenti necessari e quindi impostano vold.post_fs_data_donesu 1.

Una volta che voldvede la 1 in quella proprietà, imposta la proprietà vold.decrypta: trigger_restart_framework. Ciò provoca il riavvio dei init.rcservizi in classe maine l'avvio dei servizi in classe late_start per la prima volta dall'avvio.

4. Avvia framework

Ora il framework avvia tutti i suoi servizi utilizzando i dati / decrittografati e il sistema è pronto per l'uso.

Avvio di un dispositivo crittografato senza crittografia predefinita

Questo è ciò che accade quando si avvia un dispositivo crittografato con una password impostata. La password del dispositivo può essere un pin, una sequenza o una password.

1. Rileva dispositivo crittografato con una password

Rileva che il dispositivo Android è crittografato a causa della bandiera ro.crypto.state = "encrypted"

voldimpostato vold.decryptsu trigger_restart_min_frameworkperché / data è crittografato con una password.

2. Mount tmpfs

initimposta cinque proprietà per salvare le opzioni di montaggio iniziali fornite per / data con i parametri passati da init.rc. voldutilizza queste proprietà per impostare il mapping crittografico:

ro.crypto.fs_type

ro.crypto.fs_real_blkdev

ro.crypto.fs_mnt_point

ro.crypto.fs_options

ro.crypto.fs_flags (Numero esadecimale a 8 cifre ASCII preceduto da 0x)

3. Avviare framework per richiedere la password

Il framework si avvia e vede che vold.decryptè impostato su trigger_restart_min_framework. Questo dice al framework che si sta avviando su un tmpfs /datadisco e deve ottenere la password dell'utente.

Innanzitutto, tuttavia, è necessario assicurarsi che il disco sia stato crittografato correttamente. Invia il comando cryptfs cryptocompletea vold. voldrestituisce 0 se la crittografia è stata completata correttamente, -1 in caso di errore interno o -2 se la crittografia non è stata completata correttamente. volddetermina questo cercando nei metadati crittografici la CRYPTO_ENCRYPTION_IN_PROGRESSbandiera. Se impostato, il processo di crittografia è stato interrotto e non ci sono dati utilizzabili sul dispositivo.

Se voldrestituisce un errore, l'interfaccia utente dovrebbe visualizzare un messaggio all'utente per riavviare e ripristinare in fabbrica il dispositivo e dare all'utente un pulsante da premere per farlo.

4. Decifrare i dati con password

Una volta cryptfs cryptocompleteeseguito correttamente, il framework visualizza un'interfaccia utente che richiede la password del disco. L'interfaccia utente controlla la password inviando il comando cryptfs checkpwa vold. Se la password è corretta (che viene determinata montando correttamente la decrittografia /datain una posizione temporanea, quindi smontandola), vold salva il nome del dispositivo a blocchi decrittografato nella proprietà ro.crypto.fs_crypto_blkdeve restituisce lo stato 0 all'interfaccia utente. Se la password non è corretta, restituisce -1 all'interfaccia utente.

5. Stop quadro

L'interfaccia utente crea un grafico di avvio crittografico e quindi chiama vold con il comando cryptfs restart. voldimposta la proprietà vold.decryptsu trigger_reset_main, che causa init.rcfare class_reset main. Ciò interrompe tutti i servizi della mainclasse, che consente tmpfs /datadi smontare.

6. Montare / dati

voldquindi monta la /datapartizione reale decodificata e prepara la nuova partizione (che potrebbe non essere mai stata preparata se fosse stata crittografata con l'opzione di cancellazione, che non è supportata nella prima versione). Imposta la proprietà vold.post_fs_data_donesu 0e quindi imposta vold.decryptsu trigger_post_fs_data. Questo provoca init.rcl'esecuzione post-fs-data commands. Creano tutte le directory o i collegamenti necessari e quindi impostano vold.post_fs_data_donesu 1. Una volta che voldvede 1in quella proprietà, imposta la proprietà vold.decryptsu trigger_restart_framework. Ciò provoca il riavvio dei init.rcservizi in classe maine l'avvio dei servizi in classe late_startper la prima volta dall'avvio.

7. Avvia il framework completo

Ora il framework avvia tutti i suoi servizi utilizzando il file system decrittografato / dati e il sistema è pronto per l'uso.

Memorizzazione della chiave crittografata

La chiave crittografata viene archiviata nei metadati crittografici. Il supporto hardware viene implementato utilizzando la funzionalità di firma TEE (Trusted Execution Environment). In precedenza, abbiamo crittografato la chiave master con una chiave generata applicando scryptla password dell'utente e il salt memorizzato.

Al fine di rendere la chiave resistente agli attacchi off-box, estendiamo questo algoritmo firmando la chiave risultante con una chiave TEE memorizzata. La firma risultante viene quindi trasformata in una chiave di lunghezza appropriata da un'altra applicazione di scrypt. Questa chiave viene quindi utilizzata per crittografare e decrittografare la chiave principale. Per memorizzare questa chiave:

1. Genera chiave di crittografia del disco a 16 byte (DEK) e salt 16 byte casuali.
2. Applicare scryptalla password dell'utente e al salt per produrre la chiave intermedia 1 (IK1) a 32 byte.
3. Pad IK1 con zero byte per la dimensione della chiave privata associata all'hardware (HBK). In particolare, il pad è: 00 || IK1 || 00..00; un byte zero, 32 byte IK1, 223 byte zero.
4. Iscriviti imbottito IK1 con HBK per produrre IK2 a 256 byte.
5. Applicare scryptsu IK2 e sale (stesso sale del passaggio 2) per produrre IK3 a 32 byte.
6. Usa i primi 16 byte di IK3 come KEK e gli ultimi 16 byte come IV.
7. Crittografa DEK con AES_CBC, con chiave KEK e vettore di inizializzazione IV.