it-swarm-eu.dev

Come è possibile modificare la password dell'utente dopo la crittografia dell'archiviazione? (su OS X, Android)

Esistono funzionalità integrate per crittografare un archivio su OS X ( FileVault ) e Android.

Su OS X: per abilitare la crittografia, l'utente corrente deve disporre di un account protetto da password. Dopo aver abilitato la crittografia, viene generata la chiave di ripristino (qualcosa come HHWj-Y8DK-ODO4-BQEN-FQ4V-M4O8). Al termine della crittografia (e con ogni probabilità anche prima) l'utente è in grado di modificare la propria password, senza la necessità di crittografare nuovamente la memoria.

Su Android: l'utente deve impostare la protezione della schermata di blocco su pin o password. Dopo aver eseguito la crittografia dell'archiviazione (di nuovo, probabilmente anche prima), l'utente è in grado di modificare la password e persino passare da password a pin e viceversa.

Ora ecco cosa mi confonde: la mia comprensione è che quando l'archiviazione è crittografata, viene eseguita con la password dell'utente corrente (una specie di crittografia di un archivio) e se la password viene modificata, l'intero archivio deve essere crittografato nuovamente. Questa comprensione (apparentemente errata) mi porta alle seguenti domande:

  1. In base a quale "chiave" (poiché non è la password stessa) viene eseguita la crittografia?
    • Per OS X, immagino, è la chiave di ripristino, ma come si collega alla password dell'utente?
  2. Se la password non è la base per la crittografia, perché è necessario impostarne una prima di crittografare la memoria?
  3. Come viene mantenuta la capacità di decrittografare l'archiviazione (senza ricodifica) dopo la modifica della password?
28
Filippo Walker

Ad un livello elevato, la crittografia del disco viene implementata utilizzando una chiave di crittografia dei dati (DEK) e una chiave di crittografia della chiave (KEK). Il DEK viene generato in modo casuale e utilizzato per crittografare l'unità, il KEK viene derivato dalla password dell'utente utilizzando un KDF come PBKDF2 o Argon2 e quindi utilizzato per crittografare il DEK.

Quando si modifica la password, DEK viene semplicemente crittografato con un nuovo KEK derivato dalla nuova password.

La crittografia senza password è probabilmente vietata per evitare un falso senso di sicurezza. Sarebbe un po 'come chiudere la porta ma lasciare la chiave nella serratura.

Ovviamente, se stai cambiando la tua password perché ritieni che qualcuno l'abbia capito, e quella persona abbia anche accesso al dispositivo crittografato, è possibile che abbia archiviato una copia del DEK. In questo caso potrebbe essere necessario ricodificare l'intero disco, anche se probabilmente ciò richiederà del tempo.

48
AndrolGenhald

Sono completamente d'accordo con la risposta di alto livello di AndrolGenhald. Nel caso in cui sia interessato a una procedura dettagliata di basso livello dell'implementazione della crittografia di archiviazione di Android:

Android può eseguire Crittografia basata su file (FBE) e Crittografia full-disc (FDE), con "disco" che fa riferimento alla partizione/data. Mi concentrerò su FDE per illustrare il principio. L'installazione viene eseguita da Volume Daemon (Vold), in particolare in system/vold/cryptfs.cpp .

  • cryptfs_enable_internal(int crypt_type, const char* passwd, ...) avvia la crittografia dell'archiviazione, con crypt_type che specifica se viene utilizzato un pin o una password (per determinare quale tastiera visualizzare sulla schermata di sblocco) e passwd fornendo il pin/password dell'utente reale. Imposta un piè di pagina crypt_ftr Da archiviare lungo la partizione crittografata, quindi chiama create_encrypted_random_key Per popolare crypt_ftr.

    • create_encrypted_random_key genera una chiave master casuale e un salt casuale e li passa a encrypt_master_key.
    • encrypt_master_key usa una funzione di derivazione della chiave (ad es. Scrypt), che prende il sale e il pin/password dell'utente come input e deriva in modo deterministico una chiave intermedia. La chiave master viene quindi crittografata con la chiave intermedia utilizzando AES-128-CBC. La chiave master crittografata e il salt sono memorizzati in crypt_ftr, Ma non il pin/la password dell'utente.
    • Di nuovo in cryptfs_enable_internal, crypt_ftr Viene scritto sul disco. Quindi la crittografia effettiva dell'archiviazione tramite Linux dm-crypt Viene attivata utilizzando la chiave master decrittografata.
  • cryptfs_check_passwd(const char* passwd) avvia la decodifica della memoria eseguendo il backtracking dei passaggi precedenti per ottenere la chiave master decrittografata. Il crypt_ftr Deve essere letto dal disco, contenente la chiave master crittografata e il salt. Il pin/password forniti dall'utente più salt vengono inseriti nella funzione di derivazione dei tasti. Ciò si traduce in una chiave intermedia che può decrittografare la chiave principale (la maggior parte di ciò accade in decrypt_master_key_aux ).

  • cryptfs_changepw(int crypt_type, const char* newpw) gestisce la modifica del pin/password dell'utente. Non genererà una nuova chiave master, ma crittograferà la chiave master esistente tramite encrypt_master_key Utilizzando il nuovo pin/password utente.

Sulla base di queste informazioni, le risposte alle tue domande sarebbero:

  1. La chiave master generata casualmente viene utilizzata per la crittografia di archiviazione effettiva.

  2. Abbiamo bisogno di un pin utente/password per crittografare la chiave principale. Pertanto, il pin/password dell'utente è necessario per recuperare in seguito la chiave master per decrittografare la memoria.

  3. La modifica del pin/password dell'utente non modificherà la chiave principale, ma solo la crittografia della chiave principale.