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 su come le applicazioni di sistema possono utilizzare le API di avvio diretto per offrire la migliore e più sicura possibile.

Tutti i dispositivi che verranno lanciati con Android 10 o versioni successive sono la crittografia basata su file.

Avvio diretto

La crittografia basata su file attiva una nuova funzionalità introdotta in Android 7.0 chiamata Direct Avvio. Avvio diretto consente ai dispositivi criptati di avviarsi direttamente nella serratura schermo. In precedenza, sui dispositivi criptati utilizzando full-disk la crittografia (FDE), gli utenti dovevano fornire le credenziali prima che i dati potessero al fine di impedire allo smartphone di eseguire tutte le operazioni di base, tranne quelle più basilari. operazioni aziendali. Ad esempio, impossibile attivare le sveglie, i servizi di accessibilità erano non disponibile e i telefoni non potevano ricevere chiamate, ma erano limitati alla versione di base la gestione delle chiamate di emergenza.

Con l'introduzione della crittografia basata su file (FBE) e di nuove API per le applicazioni sono consapevoli della crittografia, queste possono in un contesto limitato. Ciò può accadere prima che gli utenti abbiano fornito il proprio e credenziali e allo stesso tempo protegge le informazioni private degli utenti.

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

  • Archivio con credenziali con crittografia CE, che è la posizione di archiviazione predefinita ed è disponibile solo dopo che l'utente ha sbloccato il dispositivo.
  • Dispositivo di archiviazione con crittografia DE, che è una posizione di archiviazione disponibile durante la modalità Avvio diretto e dopo che l'utente ha sbloccato il dispositivo.
di Gemini Advanced.

Questa separazione rende i profili di lavoro più sicuri perché consente da proteggere in un determinato momento, in quanto la crittografia non è più basata unicamente su un password di avvio.

L'API Direct Boot consente alle applicazioni sensibili alla crittografia di accedere a ciascuno di questi in queste aree. Il ciclo di vita dell'applicazione è stato modificato per soddisfare la necessità invia una notifica alle applicazioni quando lo spazio di archiviazione CE di un utente viene sbloccato in risposta a prima di inserire le credenziali nella schermata di blocco o, nel caso del profilo di lavoro, offrendo un lavoro una sfida. I dispositivi con Android 7.0 devono supportare queste nuove API e o meno, indipendentemente dal fatto che implementino o meno FBE. Tuttavia, senza Lo spazio di archiviazione FBE, DE e CE sarà sempre in stato sbloccato.

Un’implementazione completa della crittografia basata su file sui file Ext4 e F2FS vengono forniti nell'Android Open Source Project (AOSP) e devono essere su dispositivi che soddisfano i requisiti. Produttori che scelgono di utilizzare FBE potrebbe volere esplorare modi per ottimizzare la funzionalità in base al system on chip (SoC).

Tutti i pacchetti necessari in AOSP sono stati aggiornati affinché siano sensibili all'avvio diretto. Tuttavia, quando i produttori di dispositivi usano versioni personalizzate di queste app, assicurarti che ci siano almeno pacchetti sensibili all'avvio diretto che i seguenti servizi:

  • Servizi di telefonia e tastiera
  • Metodo di immissione 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) offre la funzionalità per gestire i dispositivi di archiviazione volumi su Android. L'aggiunta di FBE fornisce ai vold diversi nuovi comandi per supportare la gestione delle chiavi CE e DE di più utenti. Inoltre, alle modifiche principali per utilizzare il modello basato le funzionalità di crittografia del kernel, molti pacchetti di sistema, schermata di blocco e SystemUI sono state modificate per supportare FBE e Direct Funzionalità di avvio. tra cui:

  • AOSP Dialer (pacchetti/app/Dialer)
  • Orologio da scrivania (pacchetti/app/DeskClock)
  • LatinIME (packages/inputmethods/LatinIME)*
  • App Impostazioni (pacchetti/app/impostazioni)*
  • SystemUI (framework/base/packages/SystemUI)*

* Applicazioni di sistema che utilizzano defaultToDeviceProtectedStorage attributo del file manifest

Altri esempi di applicazioni e servizi che sono consapevoli della crittografia possono essere trovato eseguendo il comando mangrep directBootAware nel di framework o pacchetti dell'AOSP nell'albero di origine.

Dipendenze

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

  • Supporto del kernel per la crittografia Ext4 o F2FS.
  • Keymaster Supporto con HAL 1.0 o versioni successive. Non è disponibile assistenza per Keymaster 0.3 in quanto non fornisce le funzionalità necessarie o non assicura una protezione sufficiente per le chiavi di crittografia.
  • Keymaster/Keystore e Il gatekeeper deve essere implementato in un'esecuzione attendibile Ambiente (TEE) per garantire la protezione delle chiavi DE in modo che il sistema operativo non autorizzato (il sistema operativo personalizzato installato sul dispositivo) non può semplicemente richiedere DE.
  • Root di affidabilità hardware e Avvio verificato associate all'inizializzazione Keymaster è necessaria per garantire che le chiavi DE non siano accessibili da un sistema operativo non autorizzato.

Implementazione

Innanzitutto, app come sveglie, smartphone e funzioni di accessibilità deve essere impostato come android:directBootAware in base al ruolo Direct Avvio della documentazione per gli sviluppatori.

Supporto kernel

Il supporto del kernel per la crittografia Ext4 e F2FS è disponibile nella community Android versione 3.18 e successive. Per abilitarlo in un kernel versione 5.1: o superiore, utilizza: 

CONFIG_FS_ENCRYPTION=y

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

Se il tuo dispositivo supporterà l'adozione spazio di archiviazione o utilizzeranno i metadati crittografia sulla 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, sul dispositivo i produttori dovrebbero anche abilitare l'accelerazione crittografica per velocizzare la crittografia basata su file e migliorare l'esperienza utente. Ad esempio, su Sui dispositivi basati su ARM64, l'accelerazione ARMv8 CE (Cryptography Extensions) può essere abilitato 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 Inoltre, valuta la possibilità di implementare hardware di crittografia in linea, 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 consente di utilizzare la crittografia in linea quando il supporto di driver hardware e del fornitore è disponibili. Il framework di crittografia in linea può essere abilitato impostando il metodo seguenti opzioni di configurazione del kernel: 

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Se il dispositivo utilizza uno spazio di archiviazione basato su UFS, abilita anche: 

CONFIG_SCSI_UFS_CRYPTO=y

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

CONFIG_MMC_CRYPTO=y

Attivazione della crittografia basata su file

Per abilitare FBE su un dispositivo, è necessario abilitarlo nella memoria interna (userdata) Inoltre, abilita automaticamente FBE sulle piattaforme archiviazione; Tuttavia, il formato della crittografia sullo spazio di archiviazione adottabile potrebbe essere sostituito se necessario.

Memoria 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 archiviazione. Contiene fino a tre parametri separati da due punti:

  • Il parametro contents_encryption_mode definisce l'algoritmo crittografico viene utilizzato per crittografare i contenuti 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 l'algoritmo crittografico viene utilizzato per crittografare i nomi dei file. Può essere aes-256-cts, aes-256-heh, adiantum o aes-256-hctr2. Se non specificato, il valore predefinito è aes-256-cts se contents_encryption_mode è aes-256-xts o a 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 Il flag v2 seleziona i criteri di crittografia della versione 2. Versione Due criteri di crittografia utilizzano una funzione di derivazione della chiave più sicura e flessibile. L'impostazione predefinita è v2 se Sul dispositivo con Android 11 o versioni successive. (come determinato da ro.product.first_api_level) o v1 se il dispositivo è stato avviato con Android 10 in basso.
    • Il flag inlinecrypt_optimized seleziona una crittografia ottimizzato per l'hardware di crittografia in linea che non gestire in modo efficiente grandi quantità di chiavi. A questo scopo, ricava una sola chiave di crittografia dei contenuti di file per chiave CE o DE, anziché uno per file. La generazione di IV (vettori di inizializzazione) è modificati di conseguenza.
    • Il flag emmc_optimized è simile a inlinecrypt_optimized, ma seleziona anche un IV che limita gli IV a 32 bit. Questo flag deve includere da utilizzare su hardware di crittografia in linea conforme alle specifica JEDEC eMMC v5.2 e pertanto supporta solo IV Su altro hardware di crittografia in linea, usa inlinecrypt_optimized in alternativa. Questo flag non deve mai essere usata su unità di archiviazione basate su UFS; la specifica UFS consente l'utilizzo di IV a 64 bit.
    • Sui dispositivi che supportano il wrapping hardware , il flag wrappedkey_v0 consente l'uso di chiavi con wrapping hardware per FBE. Può essere usato solo in combinazione con l'opzione di montaggio inlinecrypt e il inlinecrypt_optimized o emmc_optimized flag.
    • Il flag dusize_4k forza la dimensione dell'unità di dati di crittografia a 4096 byte anche se la dimensione del blocco del file system è diversa da 4096 byte. La dimensione dell'unità di dati di crittografia è la granularità la crittografia dei contenuti. Questo flag è disponibile da Android 15. Questo flag deve essere usato solo per abilitare l'utilizzo di hardware di crittografia in linea che non supporta i dati unità più grandi di 4096 byte, su un dispositivo che usa una dimensione pagina più grande di 4096 byte e che utilizza il file system f2fs.

Se non utilizzi hardware di crittografia in linea, l'impostazione consigliata per la maggior parte dispositivi sono fileencryption=aes-256-xts. Se utilizzi la modalità in linea l'impostazione consigliata per la maggior parte dei dispositivi è fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (o fileencryption=::inlinecrypt_optimized). Attivato dispositivi senza alcuna forma di accelerazione AES, è possibile usare Adiantum al posto dell'algoritmo AES impostazione fileencryption=adiantum.

Da Android 14, AES-HCTR2 è la modalità preferita per la crittografia dei nomi file. per i dispositivi con istruzioni per la crittografia accelerata. Tuttavia, solo i kernel Android più recenti supportano AES-HCTR2. In una futura versione di Android, è prevista la modalità predefinita per i nomi file. la crittografia. Se il kernel supporta AES-HCTR2, può essere abilitato per la crittografia dei nomi file Impostazione di 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 o versioni precedenti, fileencryption=ice consente inoltre di specificare l'utilizzo dei FSCRYPT_MODE_PRIVATE modalità di crittografia dei contenuti dei file. Questa modalità è non implementato dai kernel comuni di Android, ma potrebbe essere implementato che usano patch del kernel personalizzate. Il formato su disco prodotto da questa modalità era specifico del fornitore. Sui dispositivi che vengono lanciati con Android 11 o successive, questa modalità non è più consentita e è necessario utilizzare il formato standard della crittografia.

Per impostazione predefinita, la crittografia dei contenuti dei file viene eseguita utilizzando l'API crittografica. Se invece vuoi utilizzare hardware di crittografia in linea, aggiungi l'opzione di montaggio inlinecrypt. Ad esempio, La riga fstab 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 può essere usato insieme.

Specificare l'opzione fstab fileencryption per Inoltre, userdata attiva automaticamente sia FBE sia la crittografia dei metadati sui modelli archiviazione. Tuttavia, puoi eseguire l'override dei formati di crittografia dei metadati e/o FBE su e adottare lo spazio di archiviazione da adottare impostando le proprietà PRODUCT_PROPERTY_OVERRIDES.

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

  • ro.crypto.volume.options (novità di Android 11) seleziona il formato di crittografia FBE su di archiviazione utilizzabili. Ha la stessa sintassi dell'argomento fileencryption, che utilizza le stesse impostazioni predefinite. Leggi i consigli per fileencryption qui sopra su cosa fare usare qui.
  • ro.crypto.volume.metadata.encryption seleziona i metadati per la crittografia lato client sullo spazio di archiviazione adottabile. Consulta i metadati documentazione sulla crittografia.

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

  • ro.crypto.volume.contents_mode seleziona i contenuti modalità di crittografia. Equivale al primo campo separato da due punti di ro.crypto.volume.options.
  • ro.crypto.volume.filenames_mode seleziona i nomi file modalità di crittografia. Equivale al secondo campo separato da due punti di ro.crypto.volume.options, ad eccezione dell'impostazione predefinita sui dispositivi lanciato con Android 10 o versioni precedenti è aes-256-heh. Sulla maggior parte dei dispositivi, questo deve essere sostituito in aes-256-cts.
  • ro.crypto.fde_algorithm e ro.crypto.fde_sector_size seleziona la crittografia dei metadati disponibile sullo spazio di archiviazione adottabile. Consulta i metadati documentazione sulla crittografia.

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 Fase di avvio di post-fs-data, ovvero quando vold è configurato le chiavi iniziali.

Esclusione di directory

init applica la chiave DE del sistema a tutte le directory di primo livello di /data, tranne le directory che non devono essere criptati, ad esempio la directory che contiene la chiave DE del sistema e quelle che contengono le directory CE o DE dell'utente. Chiavi di crittografia e non possono essere sostituite dalle sottodirectory.

In Android 11 e versioni successive, la chiave init si applica alle directory può essere controllato Argomento encryption=<action> a mkdir negli script di inizializzazione. I valori possibili di <action> sono documentato README per la lingua init di Android.

In Android 10, le azioni di crittografia di init sono stati impostati 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 che determinate directory criptati. Se vengono apportate modifiche di questo tipo, il dispositivo il produttore deve includere Criteri SELinux che concedono l'accesso solo ai delle applicazioni che devono utilizzare la directory non criptata. Dovrebbero essere escluse tutte per le applicazioni non attendibili.

L'unico caso d'uso accettabile noto in merito è il supporto di OTA precedenti le funzionalità di machine learning.

Supporto dell'avvio diretto nelle applicazioni di sistema

Informare le applicazioni con Avvio diretto

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

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

L'attributo directBootAware a livello di applicazione è un modo breve per contrassegnare tutti i componenti dell'app tenendo in considerazione la crittografia.

L'attributo defaultToDeviceProtectedStorage reindirizza il valore predefinito posizione di archiviazione dell'app 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 nel posizione e modificare i percorsi dei dati sensibili per utilizzare l'archiviazione CE. Dispositivo che utilizzano questa opzione devono esaminare attentamente i dati che per assicurarti che non contenga informazioni personali.

Quando l'esecuzione è in questa modalità, le seguenti API di sistema vengono disponibile per gestire in modo esplicito un contesto supportato da archiviazione CE quando necessario, sono equivalenti alle controparti protette dal dispositivo.

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

Supportare più utenti

Ogni utente in un ambiente multiutente riceve una chiave di crittografia separata. Ogni utente ottiene due chiavi: una DE e una CE. L'utente 0 deve prima accedere al dispositivo così com'è per un utente speciale. È pertinente per il dispositivo Utilizzi per gli amministratori.

Le applicazioni Crypto-aware 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, potranno accedere solo alle directory con crittografia CE per gli utenti che è già sbloccato.

Un'applicazione potrebbe essere in grado di interagire liberamente tra le aree geografiche della Germania, ma un solo utente sbloccato non significa che tutti gli utenti sul dispositivo sono sbloccati. La applicazione deve verificare questo stato prima di tentare di accedere a tali aree.

Ogni ID utente del profilo di lavoro riceve anche due chiavi: DE e CE. La sfida "Quando il lavoro" viene soddisfatto, l'utente del profilo è sbloccato e il Keymaster (in TEE) può fornire chiave TEE del profilo.

Gestione degli aggiornamenti

La partizione di ripristino non è in grado di accedere allo spazio di archiviazione con protezione DE sul la partizione dei dati utente. I dispositivi che implementano FBE sono vivamente consigliati per il supporto OTA tramite aggiornamenti di sistema A/B. Come l'OTA può essere applicata durante il normale funzionamento, non c'è bisogno di ripristino accedere ai dati sull'unità criptata.

Quando si utilizza 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 userdata partizione.
  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 in cui inserire i pacchetti OTA.
  4. Aggiungi una regola SELinux e contesti dei file per controllare l'accesso a questa directory e contenuti. Deve essere eseguito solo il processo o le applicazioni che ricevono aggiornamenti OTA possono leggere e scrivere in questa directory. Nessun'altra domanda o nessun altro processo dovrebbe avere accesso a questa directory.

Convalida

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

Se il dispositivo utilizza 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 venga è stato sbloccato per la prima volta dall'avvio. A questo scopo, utilizza un userdebug o eng build, imposta un PIN, una sequenza oppure password sull'utente principale e riavvia il dispositivo. Prima di sbloccare il dispositivo, esegui questo comando per verificare lo spazio di archiviazione CE dell'utente principale. Se il dispositivo utilizza Headless System Modalità utente (la maggior parte dei dispositivi automobilistici), 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 automobilistici), 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, indicando che sono crittografati e la chiave per decriptarli non è ancora disponibile. Se i nomi file sono elencati in testo non crittografato, significa che si è verificato un problema.

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

Dettagli implementazione AOSP

Questa sezione fornisce dettagli sull'implementazione di AOSP e descrive come la crittografia basata su file. Non dovrebbe essere necessario per i produttori di dispositivi di apportare modifiche qui per utilizzare FBE e Avvio diretto sui loro dispositivi.

crittografia fscrypt

L'implementazione di AOSP utilizza "fscrypt" crittografia (supportata da ext4 e f2fs) nel kernel e di solito è configurato per:

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

Anche la crittografia Adiantum supportati. Quando la crittografia di Adiantum è abilitata, sia i contenuti che i nomi dei file sono criptati con Adiantum.

fscrypt supporta due versioni dei criteri di crittografia: versione 1 e 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 relativa ai kernel upstream.

Classi di archiviazione

Nella tabella seguente sono elencate le chiavi FBE e le directory in cui proteggono maggiormente dettaglio:

Classe di archiviazione Descrizione Elenchi
Non criptato Directory in /data che non possono essere o non devono essere protetta da FBE. Sui dispositivi che utilizzano metadati crittografia, queste directory non sono realmente decriptate, ma piuttosto sono protetti dalla chiave di crittografia dei metadati, che equivale Sistema DE.
  • /data/apex, esclusi /data/apex/decompressed e /data/apex/ota_reserved che corrispondono al sistema DE
  • /data/lost+found
  • /data/preloads
  • /data/unencrypted
  • Tutte le directory le cui sottodirectory utilizzano chiavi FBE diverse. Per Ad esempio, poiché ogni directory /data/user/${user_id} usa una chiave per utente, /data/user non usa alcuna chiave per trovare le regole.
Sistema DE Dati criptati sul dispositivo non associati a un determinato utente
  • /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 che hai un corso diverso
Per avvio File di sistema temporanei che non devono permanere dopo un riavvio /data/per_boot
Utente CE (interno) Dati crittografati con credenziali per utente nella memoria interna
  • /data/data (alias di /data/user/0)
  • /data/media/${user_id}
  • /data/misc_ce/${user_id}
  • /data/system_ce/${user_id}
  • /data/user/${user_id}
  • /data/vendor_ce/${user_id}
Utente DE (interno) Dati 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 (adottabile) Dati criptati sul dispositivo per utente 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 archiviate sul disco con crittografia, tranne la chiave per avvio, che non è archiviata. La tabella seguente elenca 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 del sistema /data/unencrypted Non criptato
Chiavi CE (interne) utente /data/misc/vold/user_keys/ce/${user_id} Sistema DE
Chiavi DE (interne) dell'utente /data/misc/vold/user_keys/de/${user_id} Sistema DE
Chiavi CE (adottabili) dell'utente /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} Utente CE (interno)
Chiavi DE (adottabili) dell'utente /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} Utente DE (interno)

Come illustrato nella tabella precedente, la maggior parte delle chiavi FBE è archiviata in directory sono criptati da un'altra chiave FBE. Le chiavi non possono essere sbloccate fino a quando lo spazio di archiviazione che li contiene è stato sbloccato.

vold applica inoltre un livello di crittografia a tutte le chiavi FBE. Ogni chiave oltre alle chiavi CE per l'archiviazione interna, è crittografata con AES-256-GCM usando La chiave archivio chiavi non sia esposto all'esterno del TEE. Ciò garantisce che le chiavi FBE non possano essere sbloccate a meno che non venga affidabile, come previsto dall'Avvio verificato. Rollback resistenza è richiesta anche sulla chiave dell'archivio chiavi, che consente alle chiavi FBE di i dispositivi in cui Keymaster supporta la resistenza al rollback. Come un fallback best effort per quando non è disponibile la resistenza al rollback, hash di 16384 byte casuali archiviato nel file secdiscardable archiviato e la chiave sono usati come ID applicazione del token della chiave dell'archivio chiavi. Tutti questi byte devono essere recuperati per recuperare un Tasto FBE.

Le chiavi CE per l'archiviazione interna ricevono un livello di protezione più elevato che garantisce non possono essere sbloccati senza conoscere la schermata di blocco dell'utente Knowledge Factor (LSKF) (PIN, sequenza o password), una di reimpostazione del passcode oppure sia la chiave lato client sia quella lato server per un Operazione Riprendi al riavvio. È possibile creare token di reimpostazione del passcode solo per profili di lavoro e pienamente dispositivi 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 generati in modo casuale per ciascun utente. LockSettingsService pollici system_server gestisce la password sintetica e i modi in cui è protetto.

Per proteggere la password sintetica con l'LSKF: LockSettingsService prima estende la LSKF facendola passare attraverso scrypt, con targeting per un tempo di circa 25 ms e una memoria utilizzata di circa 2 MiB. Poiché le LSKF di solito sono brevi, questo passaggio non offre molta sicurezza. Il livello principale di sicurezza è l' Element (SE) o limitazione di frequenza applicata da TEE descritta di seguito.

Se il dispositivo dispone di Secure Element (SE), LockSettingsService mappa l'LSKF allungata a un segreto casuale ad alta entropia memorizzata nella SE utilizzando Weaver HAL. LockSettingsService quindi cripta la password sintetica due volte: la prima con una chiave software derivata LSKF ampliato e il segreto di Weaver, e il secondo con un archivio chiavi non associato all'autorizzazione chiave. Ciò fornisce la limitazione di frequenza applicata dalla SE delle ipotesi LSKF.

Se il dispositivo non dispone di un SE, allora LockSettingsService utilizza l'LSKF allungato come Gatekeeper password. LockSettingsService cripta la password sintetica due volte: la prima con una chiave software derivata dall'LSKF ampliato e l'hash di il secondo con una chiave dell'archivio chiavi associata all'autenticazione Registrazione del gatekeeper. Ciò fornisce una limitazione di frequenza applicata dal TEE delle ipotesi LSKF.

Quando l'LSKF viene modificato, LockSettingsService elimina tutti informazioni associate all'associazione della password sintetica alla vecchia LSKF Sui dispositivi che supportano chiavi di archivi chiavi Weaver o resistenti al rollback, garantisce l'eliminazione sicura dell'associazione precedente. Per questo motivo, le protezioni descritti qui vengono applicati anche quando l'utente non dispone di una LSKF.