Crittografia basata su file

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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 usare le API di avvio diretto per offrire agli utenti l'esperienza migliore e più sicura possibile.

Avvio diretto

La crittografia basata su file abilita una nuova funzionalità introdotta in Android 7.0 chiamata Direct Boot . Direct Boot consente ai dispositivi crittografati di avviarsi direttamente dalla 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ù elementari. Ad esempio, gli allarmi non potevano funzionare, i servizi di accessibilità non erano disponibili ei telefoni non potevano ricevere chiamate ma erano limitati alle sole operazioni di base del combinatore di emergenza.

Con l'introduzione della crittografia basata su file (FBE) e le nuove API per rendere le applicazioni 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 abilitato per FBE, ogni utente del dispositivo ha due posizioni di archiviazione disponibili per le applicazioni:

  • Archiviazione Credential Encrypted (CE), che è la posizione di archiviazione predefinita e disponibile solo dopo che l'utente ha sbloccato il dispositivo.
  • Archiviazione Device Encrypted (DE), che è una posizione di archiviazione disponibile sia durante la modalità di avvio diretto che 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 poiché la crittografia non è più basata esclusivamente su una password all'avvio.

L'API di avvio diretto consente alle applicazioni in grado di riconoscere 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 l'archiviazione CE di un utente viene sbloccata in risposta alla prima immissione delle credenziali nella schermata di blocco o nel caso di un profilo di lavoro che fornisce una sfida di lavoro . I dispositivi che eseguono Android 7.0 devono supportare queste nuove API e cicli di vita indipendentemente dal fatto che implementino o meno FBE. Sebbene, senza FBE, l'archiviazione DE e CE sarà sempre nello stato 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 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 a conoscenza dell'avvio diretto. Tuttavia, laddove i produttori di dispositivi utilizzino versioni personalizzate di queste app, vorranno assicurarsi almeno che ci siano pacchetti che supportano l'avvio diretto che forniscono i seguenti servizi:

  • Servizi di telefonia e dialer
  • 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 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 l'interfaccia utente di sistema, sono stati modificati per supportare le funzionalità FBE e Direct Boot. Questi includono:

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

* Applicazioni di sistema che utilizzano l'attributo manifest defaultToDeviceProtectedStorage

È possibile trovare altri esempi di applicazioni e servizi che supportano la crittografia 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 una versione HAL 1.0 o 2.0. Non esiste supporto per Keymaster 0.3 in quanto non fornisce le capacità 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.
  • Hardware Root of Trust e Verified Boot associati all'inizializzazione del keymaster sono necessari per garantire che le credenziali di Device Encryption non siano accessibili da un sistema operativo non autorizzato.

Nota : i criteri di archiviazione vengono applicati a una cartella ea tutte le sue sottocartelle. I produttori dovrebbero limitare i contenuti non crittografati alla cartella OTA e alla cartella che contiene la chiave che decrittografa il sistema. La maggior parte dei contenuti dovrebbe risiedere in un archivio crittografato con credenziali anziché in un dispositivo di archiviazione crittografato.

Implementazione

Innanzitutto, app come sveglie, telefono, funzionalità di accessibilità dovrebbero essere rese Android:directBootAware secondo la documentazione per sviluppatori 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 con versione 5.1 o successiva, utilizzare:

CONFIG_FS_ENCRYPTION=y

Per i kernel meno recenti, usa CONFIG_EXT4_ENCRYPTION=y se il filesystem userdata del tuo dispositivo è Ext4, oppure 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 nella memoria 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 possono anche prendere in considerazione l'implementazione di hardware di crittografia in linea , che crittografa/decodifica 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 inline quando è disponibile il supporto per hardware e driver 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 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 sulla memoria interna ( userdata ). Ciò abilita automaticamente anche FBE sullo storage adottabile; tuttavia, il formato di crittografia sulla memoria adottabile può essere sovrascritto, se necessario.

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 sulla memoria interna. Contiene fino a tre parametri separati da due punti:

  • Il parametro content_encryption_mode definisce quale algoritmo crittografico viene utilizzato per crittografare il contents_encryption_mode dei file. Può essere aes-256-xts o adiantum . Da Android 11 può anche essere lasciato vuoto per specificare l'algoritmo predefinito, che è aes-256-xts .
  • Il parametro filenames_encryption_mode definisce quale algoritmo di crittografia 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 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. L'impostazione predefinita è 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 in modo efficiente un numero elevato di chiavi. Lo fa derivando solo una chiave di crittografia del contenuto del file per chiave CE o DE, anziché una per file. La generazione di 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 quindi supporta solo IV a 32 bit. Su altro hardware di crittografia in linea, usa 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 chiavi con wrapping hardware , il flag wrappedkey_v0 consente l'uso di chiavi con wrapping hardware per FBE. Questo può essere utilizzato solo in combinazione con l'opzione di montaggio inlinecrypt e il flag inlinecrypt_optimized o emmc_optimized .

Se non utilizzi l'hardware di crittografia in linea, l'impostazione consigliata per la maggior parte dei dispositivi è fileencryption=aes-256-xts . Se si utilizza l'hardware di crittografia inline, 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 .

Da Android 14 (AOSP sperimentale), 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 di file. Se il tuo kernel ha il supporto AES-HCTR2, può essere abilitato per la crittografia dei nomi di 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 dei contenuti 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 che si avviano con Android 11 o versioni successive, questa modalità non è più consentita ed è necessario utilizzare 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 inline, aggiungi anche l'opzione di montaggio inlinecrypt . Ad esempio, una riga fstab completa potrebbe essere simile a:

/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

Da Android 9, FBE e lo storage adottabile possono essere utilizzati insieme.

Specificando l' fileencryption userdata di crittografia file per i dati utente, vengono abilitati automaticamente sia la crittografia FBE che quella dei metadati sullo spazio di archiviazione adottabile. Tuttavia, puoi ignorare 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, utilizzare 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 fileencryption fstab di crittografia file e utilizza le stesse impostazioni predefinite. Vedi i consigli per la fileencryption dei file sopra per cosa usare qui.
  • ro.crypto.volume.metadata.encryption seleziona il formato di crittografia dei metadati sulla memoria adottabile. Vedere la documentazione sulla crittografia dei metadati .

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

  • ro.crypto.volume.contents_mode seleziona la modalità di crittografia dei contenuti. Questo è equivalente 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 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, questo deve essere sovrascritto in modo esplicito in 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. Vedere la documentazione sulla crittografia dei metadati .

Integrazione con Keymaster

La generazione delle chiavi e la gestione del keyring del kernel è gestita da vold . L'implementazione AOSP di FBE richiede che il dispositivo supporti Keymaster HAL versione 1.0 o successiva. Non è disponibile il supporto per le versioni precedenti di Keymaster HAL.

Al primo avvio, le chiavi dell'utente 0 vengono generate e installate all'inizio del processo di avvio. Al termine della fase di init on-post-fs , il Keymaster deve essere pronto a gestire le richieste. Sui dispositivi Pixel, questo viene gestito con un blocco di script che assicura che Keymaster sia avviato prima /data venga montato.

Politica di crittografia

La crittografia basata su file applica la politica di crittografia a livello di directory. Quando la partizione userdata di un dispositivo viene creata per la prima volta, le strutture e le politiche di base vengono applicate dagli script init . Questi script attiveranno la creazione delle chiavi CE e DE del primo utente (user 0) e definiranno quali directory devono essere crittografate con queste chiavi. Quando vengono creati utenti e profili aggiuntivi, le chiavi aggiuntive necessarie vengono generate e archiviate nel keystore; le loro credenziali e le posizioni di archiviazione dei dispositivi vengono create e la politica di crittografia collega queste chiavi a tali directory.

In Android 11 e versioni successive, il criterio di crittografia non è più codificato in una posizione centralizzata, ma piuttosto è definito dagli argomenti dei comandi mkdir negli script init. Le directory crittografate con la chiave DE di sistema utilizzano encryption=Require , mentre le directory non crittografate (o le directory le cui sottodirectory sono crittografate con chiavi per utente) utilizzano encryption=None .

In Android 10, il criterio di crittografia era codificato in questa 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 dovrebbe includere le politiche SELinux che concedono l'accesso solo alle applicazioni che devono utilizzare la directory non crittografata. Questo 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 consapevoli le applicazioni di Direct Boot

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 è un'abbreviazione per contrassegnare tutti i componenti dell'app come a conoscenza della crittografia.

L'attributo defaultToDeviceProtectedStorage reindirizza il percorso di archiviazione dell'app predefinito in modo che punti all'archiviazione DE invece di puntare 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.

Durante l'esecuzione in questa modalità, le seguenti API di sistema sono disponibili per gestire in modo esplicito un contesto supportato da archiviazione CE quando necessario, che sono equivalenti alle loro controparti con dispositivo protetto.

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

Supportare più utenti

Ogni utente in un ambiente multiutente ottiene 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 in quanto è un utente speciale. Questo è pertinente per gli usi dell'amministrazione del dispositivo .

Le applicazioni compatibili con le criptovalute 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 sul dispositivo. Tuttavia, tali app potranno accedere solo alle directory crittografate con CE per gli utenti che sono già sbloccati.

Un'applicazione può essere in grado di interagire liberamente nelle 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 ottiene anche due chiavi: DE e CE. Quando la sfida di lavoro 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 alla memoria protetta da DE sulla partizione userdata. 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 primo livello (ad esempio misc_ne ) nella partizione userdata .
  2. Aggiungi questa directory di primo livello all'eccezione della politica di crittografia (consulta la politica di crittografia sopra).
  3. Creare 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 cartella 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 cartella. Nessun'altra applicazione o processo dovrebbe avere accesso a questa cartella.

Convalida

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

Se il dispositivo esegue 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 di dispositivi possono eseguire i seguenti test manuali. Su un dispositivo con FBE abilitato:

  • Verifica che ro.crypto.state esista
    • Assicurati ro.crypto.state sia crittografato
  • Verifica che ro.crypto.type esista
    • Assicurati 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; se non lo fa, c'è qualcosa che non va.

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

Dettagli di implementazione dell'AOSP

Questa sezione fornisce dettagli sull'implementazione AOSP e descrive come funziona la crittografia basata su file. Non dovrebbe essere necessario che i produttori di dispositivi apportino 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 i contenuti dei 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.

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

Derivazione chiave

Le chiavi di crittografia basate su file, che sono chiavi a 512 bit, vengono archiviate crittografate da un'altra chiave (una chiave AES-GCM a 256 bit) contenuta nel TEE. Per utilizzare questa chiave TEE, devono essere soddisfatti tre requisiti:

  • Il token di autenticazione
  • La credenziale allungata
  • L'"hash secscartabile"

Il token di autenticazione è un token autenticato crittograficamente generato da Gatekeeper quando un utente accede correttamente. Il TEE rifiuterà di utilizzare la chiave a meno che non venga fornito il token di autenticazione corretto. Se l'utente non dispone di credenziali, non viene utilizzato né necessario alcun token di autenticazione.

La credenziale estesa è la credenziale dell'utente dopo il salting e lo stretching con l'algoritmo scrypt . La credenziale viene effettivamente sottoposta a hash una volta nel servizio delle impostazioni di blocco prima di essere passata a vold per essere passata a scrypt . Questo è crittograficamente vincolato alla chiave nel TEE con tutte le garanzie che si applicano a KM_TAG_APPLICATION_ID . Se l'utente non dispone di credenziali, non viene utilizzata né necessaria alcuna credenziale estesa.

L' secdiscardable hash è un hash a 512 bit di un file casuale di 16 KB archiviato insieme ad altre informazioni utilizzate per ricostruire la chiave, come il seme. Questo file viene eliminato in modo sicuro quando la chiave viene eliminata o viene crittografata in un nuovo modo; questa protezione aggiuntiva assicura che un utente malintenzionato debba recuperare ogni bit di questo file eliminato in modo sicuro per recuperare la chiave. Questo è crittograficamente vincolato alla chiave nel TEE con tutte le garanzie che si applicano a KM_TAG_APPLICATION_ID .

Nella maggior parte dei casi, le chiavi FBE subiscono anche un ulteriore passaggio di derivazione della chiave nel kernel per generare le sottochiavi effettivamente utilizzate per eseguire la crittografia, ad esempio chiavi per file o per modalità. Per i criteri di crittografia della versione 2, viene utilizzato HKDF-SHA512.