Crittografia basata su file

Android 7.0 e versioni successive supportano la crittografia basata su file (FBE). La crittografia basata su file consente di crittografare file diversi con chiavi diverse che possono essere sbloccate in modo indipendente.

Questo articolo descrive come abilitare la crittografia basata su file sui nuovi dispositivi e come le applicazioni di sistema possono utilizzare le API di avvio diretto per offrire agli utenti l'esperienza migliore e più sicura possibile.

Tutti i dispositivi avviati con Android 10 e versioni successive devono utilizzare la crittografia basata su file.

Avvio diretto

La crittografia basata su file abilita una nuova funzionalità introdotta in Android 7.0 chiamata Direct Boot . L'avvio diretto consente ai dispositivi crittografati di avviarsi direttamente nella schermata di blocco. In precedenza, sui dispositivi crittografati che utilizzavano la crittografia dell'intero disco (FDE), gli utenti dovevano fornire le credenziali prima di poter accedere a qualsiasi dato, impedendo al telefono di eseguire tutte le operazioni tranne le più basilari. Ad esempio, gli allarmi non potevano funzionare, i servizi di accessibilità non erano disponibili e i telefoni non potevano ricevere chiamate ma erano limitati solo alle operazioni di base delle chiamate di emergenza.

Con l'introduzione della crittografia basata su file (FBE) e di nuove API per rendere le applicazioni consapevoli della crittografia, è possibile che queste app operino in un contesto limitato. Ciò può verificarsi prima che gli utenti abbiano fornito le proprie credenziali, proteggendo comunque le informazioni private dell'utente.

Su un dispositivo abilitato per FBE, ogni utente del dispositivo ha due posizioni di archiviazione disponibili per le applicazioni:

  • Archiviazione con crittografia delle credenziali (CE), che è la posizione di archiviazione predefinita e disponibile solo dopo che l'utente ha sbloccato il dispositivo.
  • Archiviazione Device Encrypted (DE), ovvero una posizione di archiviazione disponibile sia durante la modalità di avvio diretto sia dopo che l'utente ha sbloccato il dispositivo.

Questa separazione rende i profili di lavoro più sicuri perché consente di proteggere più di un utente alla volta poiché la crittografia non si basa più esclusivamente su una password all'avvio.

L'API Direct Boot consente alle applicazioni che supportano la crittografia di accedere a ciascuna di queste aree. Sono state apportate modifiche al ciclo di vita dell'applicazione per soddisfare la necessità di notificare alle applicazioni quando lo spazio di archiviazione CE di un utente viene sbloccato in risposta al primo inserimento delle credenziali nella schermata di blocco o nel caso in cui il profilo di lavoro fornisca una sfida lavorativa . I dispositivi che eseguono Android 7.0 devono supportare queste nuove API e cicli di vita indipendentemente dal fatto che implementino o meno FBE. Tuttavia, senza FBE, lo storage DE e CE sarà sempre nello stato sbloccato.

Un'implementazione completa della crittografia basata su file sui file system Ext4 e F2FS è fornita nell'Android Open Source Project (AOSP) e deve essere abilitata solo sui dispositivi che soddisfano i requisiti. I produttori che scelgono di utilizzare FBE potrebbero voler esplorare modi per ottimizzare la funzionalità in base al sistema su chip (SoC) utilizzato.

Tutti i pacchetti necessari in AOSP sono stati aggiornati per essere compatibili con l'avvio diretto. Tuttavia, laddove i produttori di dispositivi utilizzano versioni personalizzate di queste app, vorranno garantire come minimo la presenza di pacchetti compatibili con l'avvio diretto che forniscono i seguenti servizi:

  • Servizi di telefonia e combinatore
  • Metodo di immissione per inserire le password nella schermata di blocco

Esempi e fonte

Android fornisce un'implementazione di riferimento della crittografia basata su file, in cui vold ( system/vold ) fornisce la funzionalità per la gestione di dispositivi e volumi di archiviazione su Android. L'aggiunta di FBE fornisce a Vold diversi nuovi comandi per supportare la gestione delle chiavi CE e DE di più utenti. Oltre alle modifiche fondamentali per utilizzare le funzionalità di crittografia basata su file nel kernel , molti pacchetti di sistema tra cui la schermata di blocco e l'interfaccia utente del sistema sono stati modificati per supportare le funzionalità FBE e avvio diretto. Questi includono:

  • Dialer AOSP (pacchetti/app/Dialer)
  • Orologio da tavolo (pacchetti/app/DeskClock)
  • LatinIME (pacchetti/metodi di input/LatinIME)*
  • App Impostazioni (pacchetti/app/Impostazioni)*
  • SystemUI (framework/base/pacchetti/SystemUI)*

* Applicazioni di sistema che utilizzano l'attributo manifest defaultToDeviceProtectedStorage

Altri esempi di applicazioni e servizi che riconoscono la crittografia possono essere trovati eseguendo il comando mangrep directBootAware nella directory dei framework o dei pacchetti dell'albero dei sorgenti AOSP.

Dipendenze

Per utilizzare l'implementazione AOSP di FBE in modo sicuro, un dispositivo deve soddisfare le seguenti dipendenze:

  • Supporto del kernel per la crittografia Ext4 o la crittografia F2FS.
  • Supporto Keymaster con HAL versione 1.0 o successiva. Non esiste supporto per Keymaster 0.3 in quanto non fornisce le funzionalità necessarie o assicura una protezione sufficiente per le chiavi di crittografia.
  • Keymaster/ Keystore e Gatekeeper devono essere implementati in un Trusted Execution Environment (TEE) per fornire protezione per le chiavi DE in modo che un sistema operativo non autorizzato (sistema operativo personalizzato flashato sul dispositivo) non possa semplicemente richiedere le chiavi DE.
  • La radice hardware di attendibilità e l'avvio verificato associati all'inizializzazione del Keymaster sono necessari per garantire che le chiavi DE non siano accessibili da un sistema operativo non autorizzato.

Implementazione

Innanzitutto, app come sveglie, telefono e funzionalità di accessibilità dovrebbero essere rese Android:directBootAware secondo la documentazione per gli sviluppatori di Direct Boot .

Supporto del kernel

Il supporto del kernel per la crittografia Ext4 e F2FS è disponibile nei kernel comuni Android, versione 3.18 e successive. Per abilitarlo in un kernel versione 5.1 o successiva, utilizzare:

CONFIG_FS_ENCRYPTION=y

Per i kernel più vecchi, usa CONFIG_EXT4_ENCRYPTION=y se il filesystem userdata del tuo dispositivo è Ext4, o usa CONFIG_F2FS_FS_ENCRYPTION=y se il filesystem userdata del tuo dispositivo è F2FS.

Se il tuo dispositivo supporterà l'archiviazione adottabile o utilizzerà la crittografia dei metadati sull'archiviazione interna, abilita anche le opzioni di configurazione del kernel necessarie per la crittografia dei metadati come descritto nella documentazione sulla crittografia dei metadati .

Oltre al supporto funzionale per la crittografia Ext4 o F2FS, i produttori di dispositivi dovrebbero anche abilitare l’accelerazione crittografica per accelerare la crittografia basata su file e migliorare l’esperienza dell’utente. Ad esempio, sui dispositivi basati su ARM64, l'accelerazione ARMv8 CE (Cryptography Extensions) può essere abilitata impostando le seguenti opzioni di configurazione del kernel:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Per migliorare ulteriormente le prestazioni e ridurre il consumo energetico, i produttori di dispositivi potrebbero anche prendere in considerazione l'implementazione di hardware di crittografia in linea , che crittografa/decrittografa i dati mentre sono in viaggio da/verso il dispositivo di archiviazione. I kernel comuni di Android (versione 4.14 e successive) contengono un framework che consente l'utilizzo della crittografia in linea quando è disponibile il supporto dell'hardware e dei driver del fornitore. Il framework di crittografia in linea può essere abilitato impostando le seguenti opzioni di configurazione del kernel:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Se il tuo dispositivo utilizza l'archiviazione basata su UFS, abilita anche:

CONFIG_SCSI_UFS_CRYPTO=y

Se il tuo dispositivo utilizza l'archiviazione basata su eMMC, abilita anche:

CONFIG_MMC_CRYPTO=y

Abilitazione della crittografia basata su file

L'abilitazione di FBE su un dispositivo richiede l'abilitazione nella memoria interna ( userdata ). Ciò abilita automaticamente anche FBE sullo storage adottabile; tuttavia, se necessario, il formato di crittografia sullo spazio di archiviazione adottabile può essere sovrascritto.

Archiviazione interna

FBE viene abilitato aggiungendo l'opzione fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] alla colonna fs_mgr_flags della riga fstab per userdata . Questa opzione definisce il formato di crittografia nella memoria interna. Contiene fino a tre parametri separati da due punti:

  • Il parametro contents_encryption_mode definisce quale algoritmo crittografico viene utilizzato per crittografare il contenuto del file. Può essere aes-256-xts o adiantum . A partire da Android 11 può anche essere lasciato vuoto per specificare l'algoritmo predefinito, ovvero aes-256-xts .
  • Il parametro filenames_encryption_mode definisce quale algoritmo crittografico viene utilizzato per crittografare i nomi dei file. Può essere aes-256-cts , aes-256-heh , adiantum o aes-256-hctr2 . Se non specificato, il valore predefinito è aes-256-cts se contents_encryption_mode è aes-256-xts o adiantum se contents_encryption_mode è adiantum .
  • Il parametro flags , nuovo in Android 11, è un elenco di flag separati dal carattere + . Sono supportati i seguenti flag:
    • Il flag v1 seleziona le policy di crittografia della versione 1; il flag v2 seleziona i criteri di crittografia della versione 2. Le policy di crittografia della versione 2 utilizzano una funzione di derivazione della chiave più sicura e flessibile. Il valore predefinito è v2 se il dispositivo è stato avviato su Android 11 o versioni successive (come determinato da ro.product.first_api_level ) o v1 se il dispositivo è stato avviato su Android 10 o versioni precedenti.
    • Il flag inlinecrypt_optimized seleziona un formato di crittografia ottimizzato per l'hardware di crittografia inline che non gestisce un numero elevato di chiavi in ​​modo efficiente. A tale scopo, deriva solo una chiave di crittografia del contenuto del file per chiave CE o DE, anziché una per file. La generazione degli IV (vettori di inizializzazione) viene adeguata di conseguenza.
    • Il flag emmc_optimized è simile a inlinecrypt_optimized , ma seleziona anche un metodo di generazione IV che limita gli IV a 32 bit. Questo flag deve essere utilizzato solo su hardware di crittografia in linea conforme alla specifica JEDEC eMMC v5.2 e pertanto supporta solo IV a 32 bit. Su altri hardware di crittografia in linea, utilizzare invece inlinecrypt_optimized . Questo flag non dovrebbe mai essere utilizzato su storage basato su UFS; la specifica UFS consente l'uso di IV a 64 bit.
    • Sui dispositivi che supportano le chiavi con wrapper hardware , il flag wrappedkey_v0 abilita l'uso di chiavi con wrapper hardware per FBE. Può essere utilizzato solo in combinazione con l'opzione di montaggio inlinecrypt e con il flag inlinecrypt_optimized o emmc_optimized .

Se non utilizzi hardware di crittografia in linea, l'impostazione consigliata per la maggior parte dei dispositivi è fileencryption=aes-256-xts . Se utilizzi hardware di crittografia in linea, l'impostazione consigliata per la maggior parte dei dispositivi è fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (o equivalentemente fileencryption=::inlinecrypt_optimized ). Sui dispositivi senza alcuna forma di accelerazione AES, Adiantum può essere utilizzato al posto di AES impostando fileencryption=adiantum .

A partire da Android 14, AES-HCTR2 è la modalità preferita di crittografia dei nomi di file per i dispositivi con istruzioni di crittografia accelerata. Tuttavia, solo i kernel Android più recenti supportano AES-HCTR2. In una futura versione di Android, si prevede che diventi la modalità predefinita per la crittografia dei nomi dei file. Se il tuo kernel ha il supporto AES-HCTR2, può essere abilitato per la crittografia dei nomi dei file impostando filenames_encryption_mode su aes-256-hctr2 . Nel caso più semplice ciò verrebbe fatto con fileencryption=aes-256-xts:aes-256-hctr2 .

Sui dispositivi avviati con Android 10 o versioni precedenti, fileencryption=ice è accettato anche per specificare l'uso della modalità di crittografia del contenuto del file FSCRYPT_MODE_PRIVATE . Questa modalità non è implementata dai kernel comuni di Android, ma potrebbe essere implementata dai fornitori utilizzando patch del kernel personalizzate. Il formato su disco prodotto da questa modalità era specifico del fornitore. Sui dispositivi avviati con Android 11 o versioni successive, questa modalità non è più consentita ed è necessario utilizzare invece un formato di crittografia standard.

Per impostazione predefinita, la crittografia del contenuto dei file viene eseguita utilizzando l'API di crittografia del kernel Linux. Se invece desideri utilizzare l'hardware di crittografia in linea, aggiungi anche l'opzione di montaggio inlinecrypt . Ad esempio, una riga fstab completa potrebbe assomigliare a:

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

Spazio di archiviazione adottabile

A partire da Android 9, FBE e spazio di archiviazione adottabile possono essere utilizzati insieme.

Specificando l'opzione fstab fileencryption per userdata si abilita automaticamente anche la crittografia FBE e dei metadati sullo storage adottabile. Tuttavia, puoi sovrascrivere i formati di crittografia FBE e/o metadati sullo spazio di archiviazione adottabile impostando le proprietà in PRODUCT_PROPERTY_OVERRIDES .

Sui dispositivi avviati con Android 11 o versioni successive, utilizza le seguenti proprietà:

  • ro.crypto.volume.options (nuovo in Android 11) seleziona il formato di crittografia FBE sullo spazio di archiviazione adottabile. Ha la stessa sintassi dell'argomento dell'opzione fstab fileencryption e utilizza gli stessi valori predefiniti. Vedi i consigli per fileencryption sopra per cosa usare qui.
  • ro.crypto.volume.metadata.encryption seleziona il formato di crittografia dei metadati sullo spazio di archiviazione adottabile. Consulta la documentazione sulla crittografia dei metadati .

Sui dispositivi avviati con Android 10 o versioni precedenti, utilizza le seguenti proprietà:

  • ro.crypto.volume.contents_mode seleziona la modalità di crittografia dei contenuti. Ciò equivale al primo campo separato da due punti di ro.crypto.volume.options .
  • ro.crypto.volume.filenames_mode seleziona la modalità di crittografia dei nomi dei file. Ciò equivale al secondo campo separato da due punti di ro.crypto.volume.options , tranne per il fatto che l'impostazione predefinita sui dispositivi avviati con Android 10 o versioni precedenti è aes-256-heh . Sulla maggior parte dei dispositivi, è necessario sovrascriverlo esplicitamente su aes-256-cts .
  • ro.crypto.fde_algorithm e ro.crypto.fde_sector_size selezionano il formato di crittografia dei metadati sullo storage adottabile. Consulta la documentazione sulla crittografia dei metadati .

Integrazione con Keymaster

L'HAL Keymaster deve essere avviato come parte della classe early_hal . Questo perché FBE richiede che Keymaster sia pronto a gestire le richieste entro la fase di avvio post-fs-data , ovvero quando vold imposta le chiavi iniziali.

Directory escluse

init applica la chiave DE di sistema a tutte le directory di livello superiore di /data , ad eccezione delle directory che devono essere non crittografate: la directory che contiene la chiave DE di sistema stessa e le directory che contengono le directory CE o DE dell'utente. Le chiavi di crittografia si applicano in modo ricorsivo e non possono essere sovrascritte dalle sottodirectory.

In Android 11 e versioni successive, la chiave applicata da init alle directory può essere controllata dall'argomento encryption=<action> del comando mkdir negli script init. I possibili valori di <action> sono documentati nel README per il linguaggio init di Android .

In Android 10, le azioni di crittografia init erano codificate nel seguente percorso:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

In Android 9 e versioni precedenti, la posizione era:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

È possibile aggiungere eccezioni per impedire del tutto la crittografia di determinate directory. Se vengono apportate modifiche di questo tipo, il produttore del dispositivo dovrebbe includere politiche SELinux che garantiscano l'accesso solo alle applicazioni che necessitano di utilizzare la directory non crittografata. Ciò dovrebbe escludere tutte le applicazioni non attendibili.

L'unico caso d'uso accettabile noto per questo è il supporto delle funzionalità OTA legacy.

Supporto dell'avvio diretto nelle applicazioni di sistema

Rendere le applicazioni consapevoli dell'avvio diretto

Per facilitare la migrazione rapida delle app di sistema, sono disponibili due nuovi attributi che possono essere impostati a livello di applicazione. L'attributo defaultToDeviceProtectedStorage è disponibile solo per le app di sistema. L'attributo directBootAware è disponibile per tutti.

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

L'attributo directBootAware a livello di applicazione è una scorciatoia per contrassegnare tutti i componenti dell'app come compatibili con la crittografia.

L'attributo defaultToDeviceProtectedStorage reindirizza il percorso di archiviazione dell'app predefinito in modo che punti all'archiviazione DE anziché all'archiviazione CE. Le app di sistema che utilizzano questo flag devono controllare attentamente tutti i dati archiviati nella posizione predefinita e modificare i percorsi dei dati sensibili per utilizzare l'archiviazione CE. I produttori di dispositivi che utilizzano questa opzione dovrebbero ispezionare attentamente i dati che stanno archiviando per assicurarsi che non contengano informazioni personali.

Quando vengono eseguite in questa modalità, sono disponibili le seguenti API di sistema per gestire in modo esplicito un contesto supportato dallo storage CE quando necessario, che sono equivalenti alle loro controparti protette da dispositivo.

  • Context.createCredentialProtectedStorageContext()
  • Context.isCredentialProtectedStorage()

Supportare più utenti

Ogni utente in un ambiente multiutente riceve una chiave di crittografia separata. Ogni utente riceve due chiavi: una chiave DE e una chiave CE. L'utente 0 deve prima accedere al dispositivo poiché è un utente speciale. Ciò è pertinente per gli usi di Amministrazione dispositivo .

Le applicazioni in grado di riconoscere la crittografia interagiscono tra gli utenti in questo modo: INTERACT_ACROSS_USERS e INTERACT_ACROSS_USERS_FULL consentono a un'applicazione di agire su tutti gli utenti del dispositivo. Tuttavia, tali app potranno accedere solo alle directory crittografate CE per gli utenti già sbloccati.

Un'applicazione può essere in grado di interagire liberamente tra le aree DE, ma un utente sbloccato non significa che tutti gli utenti sul dispositivo siano sbloccati. L'applicazione dovrebbe verificare questo stato prima di tentare di accedere a queste aree.

Ogni ID utente del profilo di lavoro riceve inoltre due chiavi: DE e CE. Quando la sfida lavorativa viene soddisfatta, l'utente del profilo viene sbloccato e il Keymaster (in TEE) può fornire la chiave TEE del profilo.

Gestione degli aggiornamenti

La partizione di ripristino non è in grado di accedere allo spazio di archiviazione protetto da DE sulla partizione dei dati utente. Si consiglia vivamente ai dispositivi che implementano FBE di supportare OTA utilizzando gli aggiornamenti di sistema A/B . Poiché l'OTA può essere applicato durante il normale funzionamento, non è necessario il ripristino per accedere ai dati sull'unità crittografata.

Quando si utilizza una soluzione OTA legacy, che richiede il ripristino per accedere al file OTA sulla partizione userdata :

  1. Crea una directory di livello superiore (ad esempio misc_ne ) nella partizione userdata .
  2. Configura questa directory di primo livello in modo che non sia crittografata (vedi Esclusione di directory ).
  3. Crea una directory all'interno della directory di livello superiore per contenere i pacchetti OTA.
  4. Aggiungi una regola SELinux e contesti di file per controllare l'accesso a questa directory e al suo contenuto. Solo il processo o le applicazioni che ricevono gli aggiornamenti OTA dovrebbero essere in grado di leggere e scrivere in questa directory. Nessun'altra applicazione o processo dovrebbe avere accesso a questa directory.

Validazione

Per garantire che la versione implementata della funzionalità funzioni come previsto, eseguire prima i numerosi test di crittografia CTS, come DirectBootHostTest e EncryptionTest .

Se sul dispositivo è installato Android 11 o versioni successive, esegui anche vts_kernel_encryption_test :

atest vts_kernel_encryption_test

O:

vts-tradefed run vts -m vts_kernel_encryption_test

Inoltre, i produttori dei dispositivi possono eseguire i seguenti test manuali. Su un dispositivo con FBE abilitato:

  • Verifica che ro.crypto.state esista
    • Assicurati che ro.crypto.state sia crittografato
  • Verifica che ro.crypto.type esista
    • Assicurati che ro.crypto.type sia impostato su file

Inoltre, i tester possono avviare un'istanza userdebug con una schermata di blocco impostata sull'utente principale. Quindi adb shell nel dispositivo e usa su per diventare root. Assicurati che /data/data contenga nomi di file crittografati; in caso contrario, qualcosa non va.

I produttori di dispositivi sono inoltre incoraggiati a valutare l'esecuzione di test Linux upstream per fscrypt sui propri dispositivi o kernel. Questi test fanno parte della suite di test del filesystem xfstests. Tuttavia, questi test upstream non sono supportati ufficialmente da Android.

Dettagli di implementazione AOSP

Questa sezione fornisce dettagli sull'implementazione AOSP e descrive il funzionamento della crittografia basata su file. Non dovrebbe essere necessario per i produttori di dispositivi apportare modifiche qui per utilizzare FBE e Direct Boot sui propri dispositivi.

crittografia fscrypt

L'implementazione AOSP utilizza la crittografia "fscrypt" (supportata da ext4 e f2fs) nel kernel e normalmente è configurata per:

  • Crittografa il contenuto del file con AES-256 in modalità XTS
  • Crittografa i nomi dei file con AES-256 in modalità CBC-CTS

È supportata anche la crittografia Adiantum . Quando la crittografia Adiantum è abilitata, sia il contenuto dei file che i nomi dei file vengono crittografati con Adiantum.

fscrypt supporta due versioni di policy di crittografia: versione 1 e versione 2. La versione 1 è deprecata e i requisiti CDD per i dispositivi avviati con Android 11 e versioni successive sono compatibili solo con la versione 2. Le policy di crittografia della versione 2 utilizzano HKDF-SHA512 per ricavare le policy effettive chiavi di crittografia dalle chiavi fornite dallo spazio utente.

Per ulteriori informazioni su fscrypt, consultare la documentazione del kernel upstream .

Classi di archiviazione

La tabella seguente elenca le chiavi FBE e le directory da esse protette in modo più dettagliato:

Classe di archiviazione Descrizione Directory
Sistema DE Dati crittografati dal dispositivo non legati a un particolare utente /data/system , /data/app e varie altre sottodirectory di /data
Per avvio File di sistema temporanei che non devono sopravvivere al riavvio /data/per_boot
Utente CE (interno) Dati crittografati con credenziali per utente nella memoria interna
  • /data/data (alias di /data/user/0 )
  • /data/media/${user_id}
  • /data/misc_ce/${user_id}
  • /data/system_ce/${user_id}
  • /data/user/${user_id}
  • /data/vendor_ce/${user_id}
Utente DE (interno) Dati crittografati per dispositivo per utente nella memoria interna
  • /data/misc_de/${user_id}
  • /data/system_de/${user_id}
  • /data/user_de/${user_id}
  • /data/vendor_de/${user_id}
Utente CE (adottabile) Dati crittografati con credenziali per utente su storage adottabile
  • /mnt/expand/${volume_uuid}/media/${user_id}
  • /mnt/expand/${volume_uuid}/misc_ce/${user_id}
  • /mnt/expand/${volume_uuid}/user/${user_id}
Utente DE (adottabile) Dati crittografati per dispositivo per utente su storage adottabile
  • /mnt/expand/${volume_uuid}/misc_de/${user_id}
  • /mnt/expand/${volume_uuid}/user_de/${user_id}

Archiviazione e protezione delle chiavi

Tutte le chiavi FBE sono gestite da vold e vengono archiviate crittografate su disco, ad eccezione della chiave per avvio che non viene archiviata affatto. La tabella seguente elenca le posizioni in cui sono archiviate le varie chiavi FBE:

Tipo di chiave Posizione chiave Classe di archiviazione della posizione della chiave
Tasto DE del sistema /data/unencrypted Non crittografato
Chiavi CE utente (interne). /data/misc/vold/user_keys/ce/${user_id} Sistema DE
Chiavi utente DE (interne). /data/misc/vold/user_keys/de/${user_id} Sistema DE
Chiavi CE utente (adottabili). /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} Utente CE (interno)
Chiavi utente DE (adottabili). /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} Utente DE (interno)

Come mostrato nella tabella precedente, la maggior parte delle chiavi FBE vengono archiviate in directory crittografate da un'altra chiave FBE. Le chiavi non possono essere sbloccate finché la classe di archiviazione che le contiene non è stata sbloccata.

vold applica anche un livello di crittografia a tutte le chiavi FBE. Ogni chiave oltre alle chiavi CE per l'archiviazione interna viene crittografata con AES-256-GCM utilizzando la propria chiave Keystore che non è esposta all'esterno del TEE. Ciò garantisce che le chiavi FBE non possano essere sbloccate a meno che non venga avviato un sistema operativo attendibile, come imposto da Verified Boot . La resistenza al rollback è richiesta anche sulla chiave Keystore, che consente di eliminare in modo sicuro le chiavi FBE sui dispositivi in ​​cui Keymaster supporta la resistenza al rollback. Come migliore soluzione di riserva per quando la resistenza al rollback non è disponibile, l'hash SHA-512 di 16384 byte casuali archiviato nel file secdiscardable archiviato insieme alla chiave viene utilizzato come tag ID applicazione della chiave Keystore. Tutti questi byte devono essere recuperati per recuperare una chiave FBE.

Le chiavi CE per l'archiviazione interna ricevono un livello di protezione più elevato che garantisce che non possano essere sbloccate senza conoscere il fattore di conoscenza dello schermo di blocco (LSKF) dell'utente (PIN, sequenza o password), un token di reimpostazione del codice di accesso sicuro o entrambi i codici lato client e chiavi lato server per un'operazione di ripresa al riavvio . È consentito creare token di reimpostazione del passcode solo per profili di lavoro e dispositivi completamente gestiti .

Per raggiungere questo obiettivo, vold crittografa ciascuna chiave CE per l'archiviazione interna utilizzando una chiave AES-256-GCM derivata dalla password sintetica dell'utente. La password sintetica è un segreto crittografico immutabile ad alta entropia generato casualmente per ciascun utente. LockSettingsService in system_server gestisce la password sintetica e le modalità con cui è protetta.

Per proteggere la password sintetica con LSKF, LockSettingsService prima allunga l'LSKF facendolo passare attraverso scrypt , puntando a un tempo di circa 25 ms e un utilizzo della memoria di circa 2 MiB. Poiché gli LSKF sono generalmente brevi, questo passaggio di solito non fornisce molta sicurezza. Il livello principale di sicurezza è il Secure Element (SE) o la limitazione della velocità applicata dal TEE descritta di seguito.

Se il dispositivo ha un Secure Element (SE), LockSettingsService mappa l'LSKF allungato su un segreto casuale ad entropia elevata archiviato in SE utilizzando Weaver HAL . LockSettingsService crittografa quindi la password sintetica due volte: la prima con una chiave software derivata dall'LSKF allungato e dal segreto Weaver e la seconda con una chiave Keystore non associata all'autenticazione. Ciò fornisce la limitazione della velocità applicata da SE per le ipotesi LSKF.

Se il dispositivo non dispone di SE, LockSettingsService utilizza invece l'LSKF allungato come password Gatekeeper . LockSettingsService crittografa quindi la password sintetica due volte: la prima con una chiave software derivata dall'LSKF allungato e l'hash di un file secdiscardable e la seconda con una chiave Keystore associata all'autenticazione alla registrazione Gatekeeper. Ciò fornisce una limitazione della velocità applicata dal TEE per le ipotesi LSKF.

Quando l'LSKF viene modificato, LockSettingsService elimina tutte le informazioni associate all'associazione della password sintetica al vecchio LSKF. Sui dispositivi che supportano chiavi Keystore resistenti al sistema Weaver o al rollback, ciò garantisce l'eliminazione sicura della vecchia associazione. Per questo motivo le protezioni qui descritte vengono applicate anche quando l'utente non dispone di LSKF.