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 che possono essere sbloccate 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 in termini di sicurezza.

Tutti i dispositivi lanciati 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 Avvio diretto. L'avvio diretto consente ai dispositivi criptati di avviarsi direttamente nella schermata di blocco. In precedenza, sui dispositivi criptati che utilizzavano la crittografia dell'intero disco (FDE), gli utenti dovevano fornire le credenziali prima di poter accedere ai dati, impedendo allo smartphone di eseguire tutte le operazioni tranne quelle più basilari. Ad esempio, le sveglie non funzionavano, i servizi di accessibilità non erano disponibili e gli smartphone non potevano ricevere chiamate, ma erano limitati alle sole operazioni di base del tastierino di emergenza.

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

Su un dispositivo con crittografia basata su file (FBE) abilitata, ogni utente del dispositivo ha due posizioni di archiviazione disponibili per le app:

• Archiviazione delle credenziali criptate (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 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, in quanto la crittografia non si basa più solo su una password di avvio.

L'API Direct Boot consente alle app compatibili con la crittografia di accedere a ciascuna di queste aree. Sono state apportate modifiche al ciclo di vita delle app per soddisfare la necessità di notificare alle app 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 del profilo di lavoro, fornendo una verifica del profilo di lavoro. I dispositivi con Android 7.0 devono supportare queste nuove API e cicli di vita indipendentemente dall'implementazione o meno di FBE. Tuttavia, senza FBE, lo spazio di archiviazione DE e CE è sempre sbloccato.

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

Tutti i pacchetti necessari in AOSP sono stati aggiornati per supportare l'avvio diretto. Tuttavia, laddove i produttori di dispositivi utilizzano versioni personalizzate di queste app, vogliono assicurarsi che almeno i pacchetti compatibili con l'avvio diretto forniscano i seguenti servizi:

• Servizi di telefonia e tastierino
• Metodo di immissione per l'inserimento delle 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 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 utilizzare le 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 Avvio diretto. tra cui:

• Dialer AOSP (packages/apps/Dialer)
• Orologio (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

Puoi trovare altri esempi di app e servizi che supportano la crittografia eseguendo il comando mangrep directBootAware nella directory dei framework o dei pacchetti dell'albero 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.
• Supporto di KeyMint (o Keymaster 1.0 o versioni successive). Keymaster 0.3 non è supportato, in quanto non fornisce le funzionalità necessarie o non garantisce una protezione sufficiente per le chiavi di crittografia.
• KeyMint/Keymaster e Gatekeeper devono essere implementati in un Trusted Execution Environment (TEE) per fornire protezione alle chiavi DE, in modo che un sistema operativo non autorizzato (sistema operativo personalizzato installato sul dispositivo) non possa semplicemente richiedere le chiavi DE.
• La radice di attendibilità hardware e l'Avvio verificato associati all'inizializzazione di KeyMint sono necessari per garantire che le chiavi DE non siano accessibili da un sistema operativo non autorizzato.

Implementazione

Innanzitutto, le app come sveglie, telefono e funzioni di accessibilità devono essere impostate su android:directBootAware in base alla documentazione per lo sviluppo relativa all'avvio diretto.

Supporto del kernel

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

CONFIG_FS_ENCRYPTION=y

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

Se il tuo dispositivo supporta l'archiviazione adottabile o utilizza la crittografia dei metadati nella memoria interna, 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 crittografica 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 attivata 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 un hardware di crittografia in linea, che cripta/decripta i dati mentre sono in transito da/verso il 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 inline 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 lo spazio di archiviazione basato su UFS, attiva anche:

CONFIG_SCSI_UFS_CRYPTO=y

Se il tuo dispositivo utilizza uno spazio di archiviazione basato su eMMC, attiva anche:

CONFIG_MMC_CRYPTO=y

Abilita la crittografia basata su file

L'attivazione di FBE su un dispositivo richiede l'attivazione della funzionalità sulla memoria interna (userdata). In questo modo, FBE viene attivato automaticamente anche sulla memoria adattabile. Tuttavia, il formato di crittografia sulla memoria adattabile può essere sostituito, se necessario.

Memoria interna

La crittografia basata su file viene attivata 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 l'algoritmo crittografico 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 le policy di crittografia della versione 1; il flag v2 seleziona le policy di crittografia della versione 2. Le norme 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 determinato da ro.product.first_api_level) o v1 se il dispositivo è stato lanciato su Android 10 e versioni precedenti.
  • Il flag inlinecrypt_optimized seleziona un formato di crittografia ottimizzato per l'hardware di crittografia inline che non gestisce in modo efficiente un numero elevato di chiavi. A questo scopo, deriva una sola chiave di crittografia dei contenuti del file per ogni chiave CE o DE, anziché una per file. La generazione di IV (vettori di inizializzazione) viene modificata 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 inline conforme alla specifica JEDEC eMMC v5.2 e pertanto supporta solo IV a 32 bit. Su altro hardware di crittografia inline, utilizza inlinecrypt_optimized. Questo flag non deve mai essere utilizzato su uno spazio di archiviazione basato su UFS; la specifica UFS consente l'utilizzo di IV a 64 bit.
  • Sui dispositivi che supportano le chiavi di crittografia inline con wrapping hardware, le chiavi FBE possono essere sottoposte a wrapping hardware aggiungendo il flag wrappedkey o wrappedkey_v0. wrappedkey è la versione moderna; wrappedkey_v0 deve essere utilizzato solo su dispositivi che non supportano wrappedkey o che sono già stati lanciati con wrappedkey_v0. Per saperne di più, consulta Abilita le chiavi con wrapping.
  • Il flag dusize_4k forza la dimensione dell'unità di dati di crittografia a 4096 byte anche quando la dimensione del blocco del file system non è di 4096 byte. La dimensione dell'unità di dati di crittografia è la granularità della crittografia dei contenuti dei file. Questo flag è disponibile a partire da Android 15. Questo flag deve essere utilizzato solo per attivare l'utilizzo di hardware di crittografia inline che non supporta unità di dati più grandi di 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 inline, l'impostazione consigliata per la maggior parte dei dispositivi è fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (o, in modo equivalente, fileencryption=::inlinecrypt_optimized). Sui dispositivi senza alcuna forma di accelerazione AES, è possibile utilizzare Adiantum al posto di AES impostando fileencryption=adiantum.

A partire da Android 14, AES-HCTR2 è la modalità preferita di crittografia dei nomi file per i dispositivi con istruzioni di crittografia accelerate. 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 dei file. Se il tuo kernel supporta AES-HCTR2, puoi attivarlo per la crittografia dei nomi file impostando filenames_encryption_mode su aes-256-hctr2. Nel caso più semplice, questo viene fatto con fileencryption=aes-256-xts:aes-256-hctr2.

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

Per impostazione predefinita, la crittografia dei contenuti dei file viene eseguita utilizzando l'API di crittografia del kernel Linux. Se invece vuoi utilizzare l'hardware di crittografia inline, aggiungi anche l'opzione di montaggio inlinecrypt. Ad esempio, una riga fstab completa 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

Memoria adottabile

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

Se specifichi l'opzione fstab fileencryption per userdata, vengono attivate automaticamente anche la crittografia FBE e la crittografia dei metadati sulla memoria adottabile. Tuttavia, puoi eseguire l'override dei formati di crittografia FBE o dei metadati sulla memoria adottabile impostando le proprietà in PRODUCT_PROPERTY_OVERRIDES.

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

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

Sui dispositivi lanciati con Android 10 e 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 file. Questo campo è equivalente al secondo campo separato da due punti di ro.crypto.volume.options, tranne per il fatto che il valore predefinito sui dispositivi avviati con Android 10 e versioni precedenti è aes-256-heh. Sulla maggior parte dei dispositivi, questo valore deve essere esplicitamente sostituito con aes-256-cts.
• ro.crypto.fde_algorithm e ro.crypto.fde_sector_size selezionano il formato di crittografia dei metadati nella memoria adottabile. Consulta la documentazione sulla crittografia dei metadati.

Integrazione con KeyMint

L'HAL KeyMint deve essere avviato come parte della classe early_hal. Questo perché la crittografia basata su file (FBE) richiede che KeyMint sia pronto a gestire le richieste entro la fase di avvio 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 delle directory che devono essere decriptate, come la directory che contiene la chiave DE di sistema stessa e le directory che contengono directory CE o DE dell'utente. Le chiavi di crittografia vengono applicate in modo ricorsivo e non possono essere sostituite dalle sottodirectory.

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

In Android 10, le azioni di crittografia init erano impostate come 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 policy SELinux che concedono l'accesso solo alle app che devono utilizzare la directory non criptata. In questo modo verranno escluse tutte le app non attendibili.

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

Supporto dell'avvio diretto nelle app di sistema

Rendi le app compatibili con l'avvio diretto

Per facilitare la migrazione rapida delle app di sistema, sono disponibili due nuovi attributi che possono essere impostati 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 compatibili con la crittografia.

L'attributo defaultToDeviceProtectedStorage reindirizza la posizione di archiviazione predefinita dell'app in modo che punti allo spazio di archiviazione DE anziché a quello 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 in modo che utilizzino l'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 è in esecuzione in questa modalità, sono disponibili le seguenti API di sistema per gestire esplicitamente un contesto supportato dallo spazio di archiviazione CE, se necessario, che sono equivalenti alle loro controparti protette dal dispositivo.

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

Supporto di 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 accedere per primo al dispositivo, in quanto è un utente speciale. Questo è pertinente per gli utilizzi di Device Administration.

Le app che supportano la crittografia interagiscono tra gli utenti in questo 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 criptate con 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 del dispositivo siano sbloccati. L'app deve controllare questo stato prima di tentare di accedere a queste aree.

Anche ogni ID utente del profilo di lavoro riceve due chiavi: DE e CE. Quando la sfida di lavoro viene superata, l'utente del profilo viene sbloccato e KeyMint (in TEE) può fornire la chiave TEE del profilo.

Gestisci gli aggiornamenti

La partizione di recovery non è in grado di accedere allo spazio di archiviazione protetto da DE nella partizione userdata. I dispositivi che implementano FBE sono fortemente consigliati per 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 legacy, che richiede il ripristino per accedere al file OTA nella 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 di directory).
3. Crea una directory all'interno della directory di primo livello per contenere i pacchetti OTA.
4. Aggiungi una regola SELinux e contesti di file per controllare l'accesso a questa directory e ai suoi contenuti. Solo il processo o le app che ricevono aggiornamenti OTA devono essere in grado di leggere e scrivere in questa directory. Nessun'altra app o processo deve avere accesso a questa directory.

Convalida

Per assicurarti che la versione implementata della funzionalità funzioni come previsto, esegui prima i numerosi test di crittografia CTS, come DirectBootHostTest ed EncryptionTest.

Se il dispositivo esegue 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 abilitata:

• 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 l'archivio CE sia bloccato prima che il dispositivo venga 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 di 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, il che indica che i nomi file sono criptati e la chiave per decriptarli non è ancora disponibile. Se i nomi dei file sono elencati in testo normale, qualcosa non va.

I produttori di dispositivi sono inoltre invitati a valutare la possibilità di eseguire i test Linux upstream per fscrypt sui propri dispositivi o kernel. Questi test fanno parte della suite di test del file system xfstests. Tuttavia, questi test upstream non sono supportati ufficialmente da Android.

Dettagli di implementazione di AOSP

Questa sezione fornisce dettagli sull'implementazione di AOSP e descrive il funzionamento della crittografia basata su file. I produttori di dispositivi non dovrebbero apportare modifiche per utilizzare FBE e Avvio diretto sui propri dispositivi.

Crittografia fscrypt

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

• Cripta i contenuti del 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 Adiantum è abilitata, sia i contenuti sia i nomi dei file vengono criptati con Adiantum.

fscrypt supporta due versioni di policy di crittografia: versione 1 e versione 2. La versione 1 è ritirata 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 derivare 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:

Archiviazione e protezione delle chiavi

Tutte le chiavi FBE sono gestite da vold e vengono archiviate su disco in forma criptata, 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:

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

vold applica anche un livello di crittografia a tutte le chiavi FBE. Ogni chiave, ad eccezione delle chiavi CE per lo spazio di archiviazione interno, viene criptata con AES-256-GCM utilizzando la propria chiave Keystore, che non viene esposta al di fuori del TEE. Ciò garantisce che le chiavi FBE non possano 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 Keystore, il che consente di eliminare in modo sicuro le chiavi FBE sui dispositivi in cui KeyMint supporta la resistenza al rollback. Come fallback best-effort quando 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::APPLICATION_ID della chiave Keystore. Tutti questi byte devono essere recuperati per recuperare una chiave FBE.

Le chiavi CE per la memoria interna ricevono un livello di protezione più elevato che garantisce che non possano essere sbloccate senza conoscere il fattore di conoscenza della schermata di blocco (LSKF) (PIN, sequenza o password) dell'utente, un token di reimpostazione sicura del passcode o entrambe le chiavi lato client e lato server per un'operazione di Ripresa all'avvio. I token di reimpostazione del passcode possono essere creati solo per i profili di lavoro e i dispositivi completamente gestiti.

Per farlo, 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 che viene 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 la LSKF, LockSettingsService allunga innanzitutto la LSKF passandola attraverso scrypt, con un tempo di esecuzione di circa 25 ms e una memoria utilizzata di circa 2 MiB. Poiché le LSKF sono in genere brevi, questo passaggio di solito non offre molta sicurezza. Il livello principale di sicurezza è il Secure Element (SE) o la limitazione di frequenza applicata da TEE descritta di seguito.

Se il dispositivo implementa l'HAL Weaver, LockSettingsService mappa l'LSKF esteso a un secret casuale ad alta entropia archiviato nell'SE o nel TEE utilizzando Weaver. LockSettingsService cripta quindi la password sintetica due volte: prima con una chiave software derivata dalla LSKF estesa e dal secret Weaver, poi con una chiave Keystore non associata all'autenticazione. In questo modo, viene fornita una limitazione della frequenza delle ipotesi LSKF applicata da SE o TEE.

Se il dispositivo non implementa Weaver, LockSettingsService utilizza invece LSKF esteso come password Gatekeeper. LockSettingsService cripta quindi la password sintetica due volte: prima con una chiave software derivata dall'LSKF esteso e dall'hash di un file secdiscardable, poi con una chiave Keystore associata all'autenticazione della registrazione di Gatekeeper. In questo modo, viene applicata la limitazione di frequenza dei tentativi di indovinare la LSKF applicata dal TEE.

Quando la LSKF viene modificata, LockSettingsService elimina tutte le informazioni associate al binding della password sintetica alla vecchia LSKF. Sui dispositivi che supportano le chiavi Keystore resistenti a Weaver o al rollback, questo garantisce l'eliminazione sicura del vecchio binding. Per questo motivo, le protezioni descritte qui vengono applicate anche quando l'utente non ha un LSKF.