Crittografia basata su file

Android 7.0 e versioni successive supportano la crittografia basata su file (FBE). La crittografia basata su file consente di criptare file diversi con chiavi diverse sbloccabili in modo indipendente.

Questo articolo descrive come attivare la crittografia basata su file sui nuovi dispositivi e come le app di sistema possono utilizzare le API Direct Boot per offrire agli utenti la migliore esperienza possibile e la massima sicurezza.

Tutti i dispositivi lanciati con Android 10 e versioni successive devono obbligatoriamente 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. Avvio diretto consente ai dispositivi criptati di avviarsi direttamente nella schermata di blocco. In precedenza, sui dispositivi criptati che utilizzano la crittografia del disco completo (FDE), gli utenti dovevano fornire le credenziali prima che fosse possibile accedere ai dati, impedendo allo smartphone di eseguire tutte le operazioni tranne le più di base. Ad esempio, non era possibile attivare gli allarmi, i servizi di accessibilità non erano disponibili e i telefoni non potevano ricevere chiamate, ma erano limitati alle operazioni di base della tastiera di emergenza.

Con l'introduzione della crittografia basata su file (FBE) e di nuove API per informare le app della crittografia, è possibile che queste app funzionino in un contesto limitato. Ciò può accadere prima che gli utenti abbiano fornito le loro credenziali, proteggendo comunque le informazioni private degli utenti.

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

  • Archiviazione con credenziali con crittografia CE, che è la posizione di archiviazione predefinita e disponibile solo dopo che l'utente ha sbloccato il dispositivo.
  • Spazio di archiviazione criptato del dispositivo (DE), ovvero un percorso 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ù utenti alla volta, in quanto la crittografia non si basa più solo su una password al momento dell'avvio.

L'API Direct Boot consente alle app sensibili alla crittografia di accedere a ciascuna di queste aree. Il ciclo di vita delle app viene modificato per soddisfare la necessità di inviare una notifica alle app quando lo spazio di archiviazione di 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 verifica di lavoro. I dispositivi con Android 7.0 devono supportare queste nuove API e questi nuovi cicli di vita, indipendentemente dal fatto che implementino o meno FBE. Tuttavia, senza FBE, gli archivi DE e CE sono sempre in stato sbloccato.

L'implementazione completa della crittografia basata su file nei file system Ext4 ed F2FS viene 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 possono esplorare i modi per ottimizzare la funzionalità in base al system on chip (SoC) utilizzato.

Tutti i pacchetti necessari in AOSP sono stati aggiornati per essere compatibili con il boot diretto. Tuttavia, se i produttori di dispositivi utilizzano versioni personalizzate di queste app, devono assicurarsi che esistano almeno pacchetti compatibili con il boot diretto che forniscono i seguenti servizi:

  • Servizi di telefonia e tastiera
  • Metodo di immissione delle password nella schermata di blocco

Esempi e origine

Android fornisce un'implementazione di riferimento della crittografia basata su file, in cui vold (system/vold) fornisce la funzionalità per la gestione dei dispositivi di archiviazione e dei volumi su Android. L'aggiunta di FBE fornisce a vold diversi nuovi comandi per supportare la gestione delle chiavi per le chiavi CE e DE di più utenti. Oltre alle modifiche principali per l'utilizzo delle funzionalità di crittografia basata su file nel kernel, molti pacchetti di sistema, tra cui la schermata di blocco e SystemUI, sono stati modificati per supportare le funzionalità FBE e Direct Boot. come le seguenti.

  • AOSP Dialer (packages/apps/Dialer)
  • Orologio da scrivania (packages/apps/DeskClock)
  • LatinIME (packages/inputmethods/LatinIME)*
  • App Impostazioni (packages/apps/Settings)*
  • SystemUI (frameworks/base/packages/SystemUI)*

* App di sistema che utilizzano l'attributo manifest defaultToDeviceProtectedStorage

Altri esempi di app e servizi che supportano la crittografia possono essere trovati eseguendo il comando mangrep directBootAware nella directory dei framework o dei pacchetti della struttura di origine 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 F2FS.
  • Keymaster Support con HAL 1.0 o versioni successive. Non è supportato Keymaster 0.3 perché non fornisce le funzionalità necessarie o garantisce protezione sufficiente per le chiavi di crittografia.
  • Keymaster/Keystore e Gatekeeper devono essere implementati in un Trusted Execution Environment (TEE) per garantire la protezione delle chiavi DE in modo che un sistema operativo non autorizzato (il sistema operativo personalizzato installato sul dispositivo) non possa semplicemente richiedere le chiavi DE.
  • Hardware Root of Trust e Avvio verificato vincolati all'inizializzazione di Keymaster sono obbligatori per garantire che le chiavi DE non siano accessibili da un sistema operativo non autorizzato.

Implementazione

Innanzitutto, le app come sveglie, telefono e funzionalità di accessibilità devono essere impostate su android:directBootAware in base alla documentazione per gli sviluppatori di Direct Boot.

Supporto del kernel

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

CONFIG_FS_ENCRYPTION=y

Per i kernel meno recenti, usa CONFIG_EXT4_ENCRYPTION=y se il file system userdata del tuo dispositivo è Ext4 oppure usa CONFIG_F2FS_FS_ENCRYPTION=y se il file system userdata del tuo dispositivo è F2FS.

Se il tuo dispositivo supporta lo spazio di archiviazione adottabile o utilizza la crittografia dei metadati sullo spazio di archiviazione interno, attiva 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 devono anche attivare l'accelerazione della crittografia per velocizzare la crittografia basata su file e migliorare l'esperienza 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 di energia, i produttori di dispositivi potrebbero anche valutare l'implementazione di hardware di crittografia in linea, che cripta/decripta i dati mentre sono in viaggio verso/dal dispositivo di archiviazione. I kernel comuni di Android (versione 4.14 e successive) contengono un framework che consente di utilizzare la crittografia in linea quando è disponibile il supporto dei driver hardware e del fornitore. Il framework di crittografia in linea può essere attivato 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 lo spazio di archiviazione basato su UFS, attiva anche: 

CONFIG_SCSI_UFS_CRYPTO=y

Se il dispositivo utilizza lo spazio di archiviazione eMMC, attiva anche: 

CONFIG_MMC_CRYPTO=y

Abilita la crittografia basata su file

L'attivazione della crittografia lato client su un dispositivo richiede l'attivazione nello spazio di archiviazione interno (userdata). Viene attivata automaticamente anche nello spazio di archiviazione adottabile. Tuttavia, se necessario, il formato di crittografia nello spazio di archiviazione adottabile può essere ignorato.

Memoria interna

Il servizio 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 per l'archiviazione interna. Contiene fino a tre parametri separati da due punti:

  • Il parametro contents_encryption_mode definisce quale algoritmo crittografico viene utilizzato per criptare i contenuti dei 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 l'algoritmo crittografico utilizzato per criptare 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 i criteri di crittografia della versione 1; il flag v2 seleziona i criteri di crittografia della versione 2. I criteri di crittografia della versione 2 utilizzano una funzione di derivazione delle chiavi più sicura e flessibile. Il valore predefinito è v2 se il dispositivo è stato lanciato su Android 11 o versioni successive (come stabilito da ro.product.first_api_level) o v1 se il dispositivo è stato lanciato su Android 10 o versioni precedenti.
    • Il flag inlinecrypt_optimized seleziona un formato di crittografia ottimizzato per l'hardware di crittografia in linea che non gestisce in modo efficiente un numero elevato di chiavi. Per farlo, ricava una sola chiave di crittografia dei contenuti del file per chiave CE o DE, anziché una per file. La generazione degli IV (vettori di inizializzazione) viene adeguatamente modificata.
    • Il flag emmc_optimized è simile a inlinecrypt_optimized, ma seleziona anche un metodo di generazione degli IV che li limita a 32 bit. Questo flag deve essere utilizzato solo su hardware di crittografia in linea conforme alla specifica JEDEC eMMC v5.2 e che pertanto supporta solo IV a 32 bit. Sull'altro hardware di crittografia in linea, utilizza inlinecrypt_optimized. Questo flag non deve mai essere utilizzato nello spazio di archiviazione basato su UFS; la specifica UFS consente l'utilizzo di IV a 64 bit.
    • Sui dispositivi che supportano chiavi con wrapping hardware, il flag wrappedkey_v0 consente l'utilizzo di chiavi con wrapping hardware per FBE. Può essere utilizzato solo in combinazione con l'opzione di montaggio inlinecrypt e con il flag inlinecrypt_optimized o emmc_optimized.
    • Il flag dusize_4k forza la dimensione dell'unità dati di crittografia a 4096 byte, anche quando la dimensione del blocco del file system non è di 4096 byte. Le dimensioni dell'unità di dati di crittografia corrispondono alla granularità della crittografia dei contenuti dei file. Questo flag è disponibile da Android 15. Questo flag deve essere usato solo per abilitare l'uso di hardware di crittografia in linea che non supporta unità di dati superiori a 4096 byte su un dispositivo che utilizza una dimensione di pagina superiore a 4096 byte e che utilizza il file system f2fs.

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 fileencryption=::inlinecrypt_optimized). Sui dispositivi senza alcuna forma di accelerazione AES, è possibile utilizzare Adiantum anziché AES impostando fileencryption=adiantum.

A partire da Android 14, AES-HCTR2 è la modalità preferita per la crittografia dei nomi file per i dispositivi con istruzioni di crittografia accelerata. Tuttavia, solo i kernel Android più recenti supportano AES-HCTR2. In una futura release di Android, è previsto che diventi la modalità predefinita per la crittografia dei nomi file. Se il kernel supporta AES-HCTR2, può essere attivato per la crittografia dei nomi file impostando filenames_encryption_mode su aes-256-hctr2. Nel caso più semplice, questo viene eseguito con fileencryption=aes-256-xts:aes-256-hctr2.

Sui dispositivi con Android 10 o versioni precedenti, fileencryption=ice è accettata anche per specificare l'utilizzo della modalità di crittografia dei contenuti dei file di 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 con Android 11 o versioni successive, questa modalità non è più consentita ed è necessario utilizzare un formato di crittografia standard.

Per impostazione predefinita, la crittografia dei contenuti dei file viene eseguita utilizzando l'API di crittografia del kernel di Linux. Se invece vuoi utilizzare hardware di crittografia in linea, aggiungi anche l'opzione di montaggio inlinecrypt. Ad esempio, una riga completafstab potrebbe avere il seguente aspetto: 

/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 utilizzabile

Da Android 9, FBE e lo spazio di archiviazione adottabile possono essere utilizzati insieme.

Se specifichi l'opzione fstab fileencryption per userdata, attivi automaticamente anche FBE e la crittografia dei metadati nello spazio di archiviazione adottabile. Tuttavia, puoi eseguire l'override dei formati di crittografia dei metadati o FBE sullo spazio di archiviazione utilizzabile impostando le proprietà in PRODUCT_PROPERTY_OVERRIDES.

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

  • ro.crypto.volume.options (novità di Android 11) seleziona il formato di crittografia FBE per lo spazio di archiviazione adottabile. Ha la stessa sintassi dell'argomento dell'opzione fstab fileencryption e utilizza gli stessi valori predefiniti. Consulta i consigli per fileencryption sopra per sapere cosa utilizzare qui.
  • ro.crypto.volume.metadata.encryption seleziona il formato di crittografia dei metadati nella memoria utilizzabile. Consulta la documentazione sulla crittografia dei metadati.

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

  • ro.crypto.volume.contents_mode seleziona la modalità di crittografia dei contenuti. 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. È equivalente al secondo campo separato da due punti di ro.crypto.volume.options, tranne per il fatto che il valore predefinito sui dispositivi lanciati con Android 10 o versioni precedenti è aes-256-heh. Sulla maggior parte dei dispositivi, questo valore deve essere override esplicitamente su aes-256-cts.
  • ro.crypto.fde_algorithm e ro.crypto.fde_sector_size selezionano il formato di crittografia dei metadati sullo spazio di archiviazione adottabile. Consulta la documentazione sulla crittografia dei metadati.

Integrazione con Keymaster

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

Escludi directory

init applica la chiave DE di sistema a tutte le directory di primo livello di /data, ad eccezione di quelle che devono essere non criptate, come la directory contenente la chiave DE di sistema stessa e le directory contenenti le directory CE o DE dell'utente. Le chiavi di crittografia si applicano in modo ricorsivo e non possono essere sostituite dalle sottodirectory.

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

In Android 10, le azioni di crittografia init erano hardcoded nella seguente posizione: 

/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 la crittografia di determinate directory. Se vengono apportate modifiche di questo tipo, il produttore del dispositivo deve includere i criteri SELinux che concedono l'accesso solo alle app che devono utilizzare la directory non criptata. In questo modo dovrebbero essere escluse tutte le app non attendibili.

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

Supporta l'avvio diretto nelle app di sistema

Rendere le app compatibili con il riavvio diretto

Per facilitare la migrazione rapida delle app di sistema, è possibile impostare due nuovi attributi a livello di app. 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 app è un'abbreviazione per contrassegnare tutti i componenti dell'app come sensibili alla crittografia.

L'attributo defaultToDeviceProtectedStorage reindirizza la posizione di archiviazione delle app predefinita in modo che punti allo spazio di archiviazione DE anziché allo spazio di 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 lo spazio di archiviazione CE. I produttori di dispositivi che utilizzano questa opzione devono ispezionare attentamente i dati che archiviano per assicurarsi che non contengano informazioni personali.

Quando viene eseguita in questa modalità, le seguenti API di sistema sono disponibili per gestire esplicitamente un contesto basato sullo spazio di archiviazione CE, se necessario, e sono equivalenti alle loro controparti protette dal dispositivo.

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

Supporta più utenti

Ogni utente in un ambiente multiutente riceve una chiave di crittografia separata. Ogni utente riceve due chiavi: una DE e una CE. L'utente 0 deve accedere prima al dispositivo in quanto è un utente speciale. È pertinente per gli utilizzi dell'amministrazione del dispositivo.

Le app che supportano la crittografia interagiscono tra gli utenti nel seguente modo: INTERACT_ACROSS_USERS e INTERACT_ACROSS_USERS_FULL consentono a un'app di agire su tutti gli utenti del dispositivo. Tuttavia, queste app possono accedere solo alle directory con crittografia CE per gli utenti già sbloccati.

Un'app potrebbe essere in grado di interagire liberamente nelle aree DE, ma lo sblocco di un utente non significa che tutti gli utenti sul dispositivo siano sbloccati. L'app dovrebbe controllare questo stato prima di tentare di accedere a queste aree.

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

Gestire gli aggiornamenti

La partizione di ripristino non è in grado di accedere allo spazio di archiviazione con protezione DE sulla partizione dei dati utente. Per i dispositivi che implementano FBE è vivamente consigliato supportare gli aggiornamenti OTA utilizzando gli aggiornamenti di sistema A/B. Poiché l'OTA può essere applicata durante il normale funzionamento, non è necessario il ripristino per accedere ai dati sull'unità criptata.

Quando utilizzi una soluzione OTA precedente, che richiede il ripristino per accedere al file OTA sulla partizione userdata:

  1. Crea una directory di primo livello (ad esempio misc_ne) nella partizione userdata.
  2. Configura questa directory di primo livello in modo che non sia criptata (vedi Esclusione delle directory).
  3. Crea una directory all'interno della directory di primo livello per contenere i pacchetti OTA.
  4. Aggiungi una regola SELinux e contesti dei file per controllare l'accesso a questa directory e ai suoi contenuti. Solo il processo o le app che ricevono aggiornamenti OTA dovrebbero essere in grado di leggere e scrivere in questa directory. Nessun'altra app o nessun altro processo dovrebbe avere accesso a questa directory.

Convalida

Per assicurarti che la versione implementata della funzionalità funzioni come previsto, esegui innanzitutto i numerosi test di crittografia CTS, ad esempio DirectBootHostTest e EncryptionTest.

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

atest vts_kernel_encryption_test

oppure:

vts-tradefed run vts -m vts_kernel_encryption_test

Inoltre, i produttori di 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 criptato
  • Verifica che ro.crypto.type esista
    • Assicurati che ro.crypto.type sia impostato su file.

Inoltre, i tester possono verificare che lo spazio di archiviazione CE sia bloccato prima che il dispositivo sia stato sbloccato per la prima volta dopo l'avvio. Per farlo, utilizza una build userdebug o eng, imposta un PIN, una sequenza o una password per l'utente principale e riavvia il dispositivo. Prima di sbloccare il dispositivo, esegui il seguente comando per controllare lo spazio di archiviazione CE dell'utente principale. Se il dispositivo utilizza la modalità utente del sistema headless (la maggior parte dei dispositivi automotive), l'utente principale è l'utente 10, quindi esegui: 

adb root; adb shell ls /data/user/10

Su altri dispositivi (la maggior parte dei dispositivi non Automotive), l'utente principale è l'utente 0, quindi esegui:

adb root; adb shell ls /data/user/0

Verifica che i nomi file elencati siano codificati in Base64, a indicare che i nomi file sono criptati e che la chiave per decriptarli non è ancora disponibile. Se i nomi file sono elencati in testo normale, c'è un problema.

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

Dettagli implementazione AOSP

Questa sezione fornisce dettagli sull'implementazione di AOSP e descrive come funziona la crittografia basata su file. I produttori di dispositivi non dovrebbero dover apportare modifiche per utilizzare FBE e Direct Boot sui loro dispositivi.

crittografia fscrypt

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

  • Crittografa i contenuti dei file con AES-256 in modalità XTS
  • Cripta i nomi dei file con AES-256 in modalità CBC-CTS

È supportata anche la crittografia Adiantum. Quando la crittografia di Adiantum è abilitata, sia i contenuti che i nomi dei file vengono criptati con Adiantum.

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

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

Classi di archiviazione

La tabella seguente elenca le chiavi FBE e le directory che proteggono in modo più dettagliato:

Classe di archiviazione Descrizione Elenchi
Non criptato Directory in /data che non possono o non devono essere protette da FBE. Sui dispositivi che utilizzano la crittografia dei metadati, queste directory non sono realmente non criptate, ma sono protette dalla chiave di crittografia dei metadati, che equivale al sistema DE.
  • /data/apex, esclusi /data/apex/decompressed e /data/apex/ota_reserved, che sono il sistema DE
  • /data/lost+found
  • /data/preloads
  • /data/unencrypted
  • Tutte le directory le cui sottodirectory utilizzano chiavi FBE diverse. Ad esempio, poiché ogni directory /data/user/${user_id} utilizza una chiave per utente, /data/user non utilizza alcuna chiave.
Sistema DE Dati criptati sul dispositivo non associati a un utente specifico
  • /data/apex/decompressed
  • /data/apex/ota_reserved
  • /data/app
  • /data/misc
  • /data/system
  • /data/vendor
  • Tutte le altre sottodirectory di /data che questa tabella non menziona come appartenenti a una classe diversa
Per ogni avvio File di sistema effimeri che non devono sopravvivere a un riavvio /data/per_boot
CE utente (interno) Dati criptati con credenziali per utente nello spazio di archiviazione interno
  • /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 criptati sul 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}
CE dell'utente (adottabile) Dati criptati con credenziali per utente nello spazio di archiviazione 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 (adottato) Dati criptati per utente sul dispositivo nello spazio di archiviazione 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 sono archiviate su disco criptate, ad eccezione della chiave per avvio che non viene memorizzata. Nella tabella seguente sono elencate le posizioni in cui sono memorizzate le varie chiavi FBE:

Tipo di chiave Posizione della chiave Classe di archiviazione della località della chiave
Chiave DE di sistema /data/unencrypted Non criptato
Chiavi CE (interne) utente /data/misc/vold/user_keys/ce/${user_id} Sistema DE
Chiavi DE (interne) utente /data/misc/vold/user_keys/de/${user_id} Sistema DE
Chiavi CE (adottabili) utente /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} CE utente (interno)
Chiavi DE (adottabili) dell'utente /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} Utente DE (interno)

Come mostrato nella tabella precedente, la maggior parte delle chiavi FBE viene archiviata in directory che sono criptate 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, ad eccezione delle chiavi CE per l'archiviazione interna, viene criptata con AES-256-GCM utilizzando la propria chiave Keystore che non è esposta al di fuori del TEE. In questo modo, le chiavi FBE non possono essere sbloccate a meno che non sia stato avviato un sistema operativo attendibile, come imposto dall'Avvio verificato. La resistenza al rollback è richiesta anche per la chiave del Keystore, che consente di eliminare in modo sicuro le chiavi FBE sui dispositivi in cui Keymaster supporta la resistenza al rollback. Come best effort per i casi in cui la resistenza al rollback non è disponibile, l'hash SHA-512 di 16.384 byte casuali archiviati nel file secdiscardable archiviato accanto alla chiave viene utilizzato come tag ID app della chiave dell'archivio chiavi. Tutti questi byte devono essere recuperati per recuperare una chiave FBE.

Le chiavi CE per lo spazio di archiviazione interno ricevono un livello di protezione più elevato che garantisce che non possano essere sbloccate senza conoscere il Fattore di conoscenza (LSKF) della schermata di blocco dell'utente (PIN, sequenza o password), un token di reimpostazione del passcode sicuro o entrambe le chiavi lato client e lato server per un'operazione di Ripristino all'avvio. È consentito creare token di reimpostazione del passcode solo per i profili di lavoro e per i dispositivi completamente gestiti.

A questo scopo, vold cripta ogni 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 in modo casuale per ogni utente. LockSettingsService in system_server gestisce la password sintetica e i modi in cui viene protetta.

Per proteggere la password sintetica con l'LSKF, LockSettingsService prima estende la LSKF passando attraverso scrypt, scegliendo come target un tempo di circa 25 ms e un utilizzo della memoria di circa 2 MiB. Poiché le LSKF di solito sono brevi, questo passaggio di solito non offre molta sicurezza. Il livello di sicurezza principale è l'elemento di sicurezza (SE) o il limite di velocità imposto dal TEE descritto di seguito.

Se il dispositivo è dotato di Secure Element (SE), LockSettingsService mappa l'LSKF ampliato a un secret casuale ad alta entropia archiviato nella SE utilizzando l'HAL Weaver. LockSettingsService cripta la password sintetica due volte: la prima con una chiave software derivata dalla LSKF ampliata e dal secret di Weaver, la seconda con una chiave dell'archivio chiavi non associata all'autenticazione. Ciò fornisce un limite di frequenza imposto da SE per le supposizioni LSKF.

Se il dispositivo non ha un SE, LockSettingsService utilizza invece la LSKF estesa come password del Gatekeeper. LockSettingsService cripta quindi la password sintetica due volte: prima con una chiave software derivata dall'LSKF allungato e dall'hash di un file secdiscardable e poi con una chiave dell'archivio chiavi associata all'autenticazione della registrazione di Gatekeeper. Ciò fornisce una limitazione di frequenza applicata dal TEE delle ipotesi LSKF.

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