Google is committed to advancing racial equity for Black communities. See how.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

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 diversi file con chiavi diverse che possono essere sbloccate in modo indipendente.

In questo articolo viene descritto come abilitare la crittografia basata su file su 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.

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 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ù 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 telefonico di emergenza.

Con l'introduzione della crittografia basata su file (FBE) e 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 degli utenti privati.

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

  • Archiviazione con credenziali crittografate (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ù di un utente alla volta poiché la crittografia non è più basata esclusivamente su una password all'avvio.

L'API di avvio diretto 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 l'archiviazione CE di un utente viene sbloccata in risposta alla prima immissione delle credenziali nella schermata di blocco o nel caso in cui il profilo di lavoro fornisca 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 consapevoli dell'avvio diretto. Tuttavia, laddove i produttori di dispositivi utilizzano versioni personalizzate di queste app, vorranno assicurarsi che ci siano almeno pacchetti che supportano l'avvio diretto che forniscono i seguenti servizi:

  • Servizi di telefonia e dialer
  • Metodo di input 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 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 la SystemUI 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 (packages / inputmethods / LatinIME) *
  • App Impostazioni (pacchetti / app / Impostazioni) *
  • SystemUI (framework / base / packages / SystemUI) *

* Applicazioni di sistema che utilizzano l'attributo manifest defaultToDeviceProtectedStorage

Ulteriori esempi di applicazioni e servizi che mangrep directBootAware la crittografia possono essere trovati eseguendo il comando mangrep directBootAware nella mangrep directBootAware 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 kernel per crittografia Ext4 o crittografia F2FS.
  • Keymaster Support con una versione HAL 1.0 o 2.0. Non è disponibile alcun supporto per Keymaster 0.3 in quanto non fornisce le funzionalità necessarie né 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 (OS personalizzato installato sul dispositivo) non possa semplicemente richiedere le chiavi DE.
  • La radice di attendibilità hardware e l' avvio verificato 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 e a tutte le relative 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 archivio crittografato con il dispositivo.

Implementazione

Prima di tutto, app come sveglie, telefono e funzioni di accessibilità dovrebbero essere rese android: directBootAware secondo la documentazione per 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 abilitarlo in un kernel che è la versione 5.1 o successiva, usa:

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 dispositivo supporterà l' archiviazione adottabile o utilizzerà la crittografia dei metadati sull'archiviazione interna, abilitare 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 abilitare anche 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 di energia, i produttori di dispositivi possono anche prendere in considerazione l'implementazione di hardware di crittografia in linea , che crittografa / decrittografa i dati mentre è in viaggio da / per il 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 nella 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 è 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:

  • I contents_encryption_mode definisce dei parametri che l'algoritmo di crittografia viene utilizzata per crittografare il contenuto dei file. Può essere aes-256-xts o adiantum .
  • 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 o adiantum . Se non specificato, il valore predefinito è aes-256-cts se contents_encryption_mode è aes-256-xts , o per 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 della chiave 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 ro.product.first_api_level .
    • Il flag inlinecrypt_optimized seleziona un formato di crittografia ottimizzato per l'hardware di crittografia inline che non gestisce un gran numero di chiavi in ​​modo efficiente. 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 regolata 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 un 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.
    • Il flag wrappedkey_v0 abilita l'uso di chiavi avvolte in hardware. Quando abilitate, le chiavi FBE non vengono generate dal software, ma piuttosto vengono generate da Keymaster utilizzando il tag STORAGE_KEY . Quindi, ogni chiave FBE effettivamente fornita al kernel è la chiave STORAGE_KEY esportata da Keymaster, il che fa sì che venga racchiusa con una chiave STORAGE_KEY per avvio. Il kernel fornisce quindi le chiavi incapsulate direttamente all'hardware di crittografia in linea. Se implementate correttamente, le chiavi non imballate non sono mai presenti nella memoria di sistema e una chiave compromessa non può essere utilizzata dopo un riavvio. Questo flag richiede il supporto hardware, supporto per Keymaster STORAGE_KEY , il supporto driver del kernel, inlinecrypt opzione di montaggio, e sia le inlinecrypt_optimized o emmc_optimized bandiere.

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

Sui dispositivi che sono stati avviati con Android 10 o fileencryption=ice , fileencryption=ice è accettato anche per specificare l'uso 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 che utilizzano 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 e al suo posto deve essere utilizzato 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

Archiviazione adattabile

A partire da Android 9, FBE e l' archiviazione adottabile possono essere utilizzati insieme.

La specifica fileencryption fstab di fileencryption per userdata abilita automaticamente sia la crittografia FBE che quella dei metadati sulla memoria adottabile. Tuttavia, puoi sovrascrivere i formati di crittografia FBE e / o metadati sulla memoria adottabile impostando le proprietà in PRODUCT_PROPERTY_OVERRIDES .

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

  • ro.crypto.volume.options (nuovo in Android 11) seleziona il formato di crittografia FBE sulla memoria adottabile. Ha la stessa sintassi dell'argomento fileencryption fstab fileencryption e utilizza gli stessi valori predefiniti. Vedi i consigli per la fileencryption dei fileencryption sopra per cosa usare qui.
  • ro.crypto.volume.metadata.encryption seleziona il formato di crittografia dei metadati sulla memoria 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. 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 di file. Questo è equivalente 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 inferiore è aes-256-heh . Sulla maggior parte dei dispositivi, questo deve essere esplicitamente sovrascritto in aes-256-cts .
  • ro.crypto.fde_algorithm e ro.crypto.fde_sector_size selezionano il formato di crittografia dei metadati sulla memoria adottabile. Consulta la documentazione sulla crittografia dei metadati .

Integrazione con Keymaster

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

Al primo avvio, le chiavi dell'utente 0 vengono generate e installate all'inizio del processo di avvio. Quando la fase on-post-fs di init completata, il Keymaster deve essere pronto a gestire le richieste. Sui dispositivi Pixel, questo viene gestito facendo in modo che un blocco di script assicuri che Keymaster venga avviato prima del montaggio di /data .

Criterio di crittografia

La crittografia basata su file applica il criterio di crittografia a livello di directory. Quando la partizione userdata un dispositivo viene creata per la prima volta, le strutture e le politiche di base vengono applicate dagli script di init . Questi script attiveranno la creazione delle chiavi CE e DE del primo utente (utente 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 memorizzate nel keystore; vengono create le credenziali e le posizioni di archiviazione dei dispositivi e il criterio di crittografia collega queste chiavi a tali directory.

In Android 11 e versioni successive, la politica di crittografia non è più codificata in una posizione centralizzata, ma piuttosto è definita dagli argomenti ai comandi mkdir negli script di inizializzazione. Le directory crittografate con la chiave DE di sistema utilizzano la encryption=Require , mentre le directory non crittografate (o le directory le cui sottodirectory sono crittografate con chiavi per utente) utilizzano la 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 del tutto la crittografia di determinate directory. Se vengono apportate modifiche di questo tipo, il produttore del dispositivo dovrebbe includere le politiche SELinux che concedono solo l'accesso alle applicazioni che devono utilizzare la directory non crittografata. Ciò dovrebbe escludere tutte le applicazioni non attendibili.

L'unico caso d'uso accettabile noto per questo è a 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 è un'abbreviazione per contrassegnare tutti i componenti nell'app come consapevoli della crittografia.

L'attributo defaultToDeviceProtectedStorage reindirizza la posizione di archiviazione dell'app predefinita 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 devono ispezionare attentamente i dati che stanno archiviando per assicurarsi che non contengano informazioni personali.

Quando si esegue in questa modalità, le seguenti API di sistema sono disponibili per gestire in modo esplicito un contesto supportato dall'archiviazione CE quando necessario, che sono equivalenti alle loro controparti protette da 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 DE e una chiave CE. L'utente 0 deve prima accedere al dispositivo poiché è un utente speciale. Ciò è pertinente per gli usi di amministrazione del dispositivo .

Le applicazioni che supportano 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, queste app potranno accedere solo alle directory crittografate 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 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. 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 all'archivio protetto da DE sulla partizione userdata. I dispositivi che implementano FBE sono vivamente consigliati per 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 di OTA legacy, che impone il recupero di accedere al file OTA sul userdata partizione:

  1. Crea una directory di primo livello (ad esempio misc_ne ) nella partizione userdata .
  2. Aggiungere questa directory di primo livello all'eccezione del criterio di crittografia (vedere Criterio di crittografia sopra).
  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 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.

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 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 esista ro.crypto.state
    • Assicurati che ro.crypto.state sia crittografato
  • Verifica che esista ro.crypto.type
    • Assicurati che ro.crypto.type sia impostato su file

Inoltre, i tester possono avviare un'istanza di userdebug con una userdebug 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 esplorare l'esecuzione dei test Linux upstream 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 supportati ufficialmente da Android.

Dettagli di implementazione AOSP

Questa sezione fornisce dettagli sull'implementazione di 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 l'avvio diretto sui loro 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
  • Il "secdiscardable hash"

Il token di autenticazione è un token autenticato crittograficamente generato da Gatekeeper quando un utente accede con successo. 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 di scrypt . La credenziale viene effettivamente sottoposta ad hashing una volta nel servizio delle impostazioni di blocco prima di essere passata a vold per essere passata a scrypt . Questo è associato crittograficamente alla chiave nel TEE con tutte le garanzie che si applicano a KM_TAG_APPLICATION_ID . Se l'utente non dispone di credenziali, non vengono utilizzate né necessarie credenziali estese.

L' secdiscardable hash è un secdiscardable hash a 512 bit di un file casuale di 16 KB memorizzato 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 crittografato in un nuovo modo; questa protezione aggiuntiva garantisce che un utente malintenzionato debba recuperare ogni bit di questo file eliminato in modo sicuro per recuperare la chiave. Questo è associato crittograficamente alla chiave nel TEE con tutte le garanzie che si applicano a KM_TAG_APPLICATION_ID .

Nella maggior parte dei casi, le chiavi FBE vengono anche sottoposte a un passaggio aggiuntivo 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.