Android 7.0 e versioni successive supporta crittografia basata su file (FBE). FBE consente di criptare file diversi con chiavi diverse che possono essere sbloccate in modo indipendente. Queste chiavi vengono utilizzate per criptare sia i contenuti dei file sia i nomi dei file. Quando viene utilizzato FBE, altre informazioni, ad esempio i layout delle directory, le dimensioni autorizzazioni e tempi di creazione/modifica non sono criptati. Nel complesso, queste altre informazioni sono note come metadati del file system.
Android 9 ha introdotto il supporto per la crittografia dei metadati. Con la crittografia dei metadati, una singola chiave presente al momento dell'avvio cripta i contenuti non criptati dalla crittografia lato client. Questa chiave è protetta da Keymaster, che in è protetta da Avvio verificato.
La crittografia dei metadati è sempre abilitata nello spazio di archiviazione adottabile ogni volta che FBE è abilitato. La crittografia dei metadati può essere abilitata anche nella memoria interna. Sui dispositivi lanciati con Android 11 o versioni successive deve essere attivata la crittografia dei metadati sullo spazio di archiviazione interno.
Implementazione nella memoria interna
Puoi configurare la crittografia dei metadati sullo spazio di archiviazione interno dei nuovi dispositivi impostando il file system metadata, modificando la sequenza di inizializzazione e attivando la crittografia dei metadati nel file fstab del dispositivo.
Prerequisiti
La crittografia dei metadati può essere configurata solo quando la partizione dei dati è la prima formattato. Di conseguenza, questa funzionalità è solo per i nuovi dispositivi; non è qualcosa che un aggiornamento OTA dovrebbe modificare.
La crittografia dei metadati richiede che il modulo dm-default-key sia
sia abilitato nel kernel. In Android 11 e versioni successive,dm-default-key è supportato dai kernel comuni di Android, versione
4.14 e successive. Questa versione di dm-default-key utilizza un framework di crittografia indipendente da hardware e fornitore chiamato blk-crypto.
Per attivare dm-default-key, usa:
CONFIG_BLK_INLINE_ENCRYPTION=y CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y CONFIG_DM_DEFAULT_KEY=y
dm-default-key utilizza hardware di crittografia in linea (hardware che cripta/decripta i dati durante il trasferimento verso/dall'unità di archiviazione) se disponibile. Se non utilizzi hardware di crittografia in linea,
necessario anche per abilitare un fallback all'API di crittografia del kernel:
CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y
Quando non utilizzi l'hardware di crittografia in linea, devi anche attivare qualsiasi accelerazione basata su CPU disponibile, come consigliato nella documentazione FBE.
In Android 10 e versioni precedenti, dm-default-key
non era supportato dal kernel comune di Android. Spettava quindi ai fornitori implementare dm-default-key.
Configura il file system dei metadati
Poiché non è possibile leggere nulla nella partizione userdata finché non è presente la chiave di crittografia dei metadati, la tabella delle partizioni deve riservare una partizione separata chiamata "partizione dei metadati" per l'archiviazione dei blob keymaster che proteggono questa chiave. La partizione dei metadati deve essere di 16 MB.
fstab.hardware deve includere una voce per il file system dei metadati
che si trova nella partizione montata su /metadata, incluso
il flag formattable per assicurarsi che venga formattato al momento dell'avvio. Il filesystem f2fs non funziona su partizioni più piccole. Ti consigliamo di utilizzare ext4. Ad esempio:
/dev/block/bootdevice/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard wait,check,formattable
Per assicurarti che il punto di montaggio /metadata esista, aggiungi la seguente riga
a BoardConfig-common.mk:
BOARD_USES_METADATA_PARTITION := true
Modifiche alla sequenza di avvio
Quando viene utilizzata la crittografia dei metadati, vold deve essere in esecuzione prima
/data montato. Per assicurarti che venga avviata abbastanza presto, aggiungi
la seguente stanza per init.hardware.rc:
# We need vold early for metadata encryption
on early-fs
start vold
Keymaster deve essere in esecuzione e pronto prima che l'inizializzazione tenti di montare
/data.
init.hardware.rc deve già contenere un mount_all
che monta /data nella stanza on
late-fs. Prima di questa riga, aggiungi la direttiva per eseguire il serviziowait_for_keymaster:
on late-fs … # Wait for keymaster exec_start wait_for_keymaster # Mount RW partitions which need run fsck mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
Attivare la crittografia dei metadati
Infine, aggiungi keydirectory=/metadata/vold/metadata_encryption al
colonna fs_mgr_flags della voce fstab per
userdata. Ad esempio, una linea fstab completa potrebbe avere il seguente aspetto:
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,inlinecrypt latemount,wait,check,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized,keydirectory=/metadata/vold/metadata_encryption,quota,formattable
Per impostazione predefinita, l'algoritmo di crittografia dei metadati sullo spazio di archiviazione interno è AES-256-XTS. Questo valore può essere ignorato impostando l'opzione metadata_encryption anche nella colonna fs_mgr_flags:
- Sui dispositivi privi di accelerazione AES, la crittografia Adiantum può essere
abilitato impostando
metadata_encryption=adiantum. - Sui dispositivi che supportano le chiavi con wrapping hardware,
la chiave di crittografia dei metadati può essere sottoposta a wrapping hardware impostando
metadata_encryption=aes-256-xts:wrappedkey_v0(o equivalentementemetadata_encryption=:wrappedkey_v0, poichéaes-256-xtsè l'algoritmo predefinito).
Poiché l'interfaccia del kernel per dm-default-key è cambiata in Android 11, devi anche assicurarti di aver impostato il valore corretto per PRODUCT_SHIPPING_API_LEVEL in device.mk. Ad esempio, se il tuo dispositivo viene lanciato con Android 11 (livello API 30), device.mk deve contenere:
PRODUCT_SHIPPING_API_LEVEL := 30
Puoi anche impostare la seguente proprietà di sistema per forzare l'utilizzo del nuovo
API dm-default-key indipendentemente dal livello API di spedizione:
PRODUCT_PROPERTY_OVERRIDES += \
ro.crypto.dm_default_key.options_format.version=2
Convalida
Per verificare che la crittografia dei metadati sia abilitata e funzioni correttamente, esegui i test descritti di seguito. Tieni inoltre presente i problemi comuni descritti di seguito.
Test
Inizia eseguendo questo comando per verificare che la crittografia dei metadati sia abilitata sulla memoria interna:
adb rootadb shell dmctl table userdata
L'output dovrebbe essere simile al seguente:
Targets in the device-mapper table for userdata: 0-4194304: default-key, aes-xts-plain64 - 0 252:2 0 3 allow_discards sector_size:4096 iv_large_sectors
Se hai sovrascritto le impostazioni di crittografia predefinite impostando il parametro
Opzione metadata_encryption nell'app fstab del dispositivo, poi
l'output differisce leggermente da quanto riportato sopra. Ad esempio, se hai attivato la crittografia Adiantum, il terzo campo è xchacha12,aes-adiantum-plain64 anziché aes-xts-plain64.
Successivamente, esegui vts_kernel_encryption_test per verificare la correttezza della crittografia dei metadati e della crittografia lato client:
atest vts_kernel_encryption_test
oppure:
vts-tradefed run vts -m vts_kernel_encryption_test
Problemi comuni
Durante la chiamata a mount_all, che monta il file criptato
/data, init esegue lo strumento Vdc. VDC
lo strumento si collega a vold tramite binder per configurare
con i metadati del dispositivo e montare la partizione. Per tutta la durata di questa chiamata, init è bloccato e i tentativi di leggere o impostare le proprietà init vengono bloccati fino al termine di mount_all.
Se, in questa fase, qualsiasi parte del lavoro di vold è bloccata direttamente o indirettamente durante la lettura o l'impostazione di una proprietà, si verifica un deadlock. È importante assicurarsi che vold possa completare il lavoro di lettura delle chiavi, interagire con Keymaster e montare la directory dei dati senza interagire ulteriormente con init.
Se Keymaster non è completamente avviato quando viene eseguito mount_all, non risponde a vold finché non ha letto determinate proprietà da init, con il risultato esatto della situazione di stallo descritta. Posizionareexec_start wait_for_keymaster sopra l'invocazionemount_all pertinente come indicato garantisce che Keymaster sia completamente in esecuzione in anticipo e quindi evita questo blocco.
Configurazione sullo spazio di archiviazione utilizzabile
Da Android 9, una forma di crittografia dei metadati è sempre attivata sullo spazio di archiviazione adottabile ogni volta che è attivata la crittografia lato client, anche se la crittografia dei metadati non è attivata sullo spazio di archiviazione interno.
In AOSP, ci sono due implementazioni della crittografia dei metadati su
storage: uno deprecato in base a dm-crypt e uno più recente
il giorno dm-default-key. Per garantire che la corretta implementazione sia
per il dispositivo, accertati di aver impostato il valore corretto per
PRODUCT_SHIPPING_API_LEVEL a device.mk. Ad esempio:
se il tuo dispositivo viene avviato con Android 11 (livello API 30),
device.mk deve contenere:
PRODUCT_SHIPPING_API_LEVEL := 30
Puoi anche impostare le seguenti proprietà di sistema per forzare l'utilizzo del nuovo metodo di crittografia dei metadati di volume (e nuova versione predefinita del criterio FBE) a prescindere dal livello API di spedizione:
PRODUCT_PROPERTY_OVERRIDES += \
ro.crypto.volume.metadata.method=dm-default-key \
ro.crypto.dm_default_key.options_format.version=2 \
ro.crypto.volume.options=::v2
Metodo attuale
Sui dispositivi che verranno lanciati con Android 11 o versioni successive:
la crittografia dei metadati sullo spazio di archiviazione adottabile utilizza dm-default-key
come nell'archiviazione interna. Vedi i prerequisiti qui sopra per quale configurazione del kernel
le opzioni da attivare. Tieni presente che l'hardware di crittografia in linea che funziona
potrebbe non essere disponibile nello spazio di archiviazione adottabile, perciò la memoria interna del dispositivo
Potrebbe essere necessario specificare CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y.
Per impostazione predefinita, il metodo di crittografia dei metadati del volume dm-default-key utilizza l'algoritmo di crittografia AES-256-XTS con settori crittografici di 4096 byte. La
l'algoritmo può essere sostituito impostando
proprietà di sistema ro.crypto.volume.metadata.encryption. Questo
ha la stessa sintassi della proprietà metadata_encryption
fstab descritta sopra. Ad esempio, sui dispositivi privi di AES
accelerazione, crittografia Adiantum
possono essere attivate impostando
ro.crypto.volume.metadata.encryption=adiantum.
Metodo precedente
Sui dispositivi che vengono lanciati con Android 10 o versioni precedenti, i metadati
la crittografia sullo spazio di archiviazione adottabile usa il modulo kernel dm-crypt
anziché dm-default-key:
CONFIG_DM_CRYPT=y
A differenza del metodo dm-default-key, il metodo dm-crypt
fa sì che i contenuti del file vengano criptati due volte: una volta con una chiave FBE e una volta con
la chiave di crittografia dei metadati. Questa doppia crittografia riduce le prestazioni
non sono necessari per raggiungere gli obiettivi
di sicurezza della crittografia dei metadati, dato che
Garantisce che le chiavi FBE siano difficili da compromettere quanto i metadati
chiave di crittografia. I fornitori possono effettuare personalizzazioni del kernel per evitare
la crittografia, in particolare implementando
L'opzione allow_encrypt_override a cui Android trasmette
dm-crypt quando la proprietà di sistema
ro.crypto.allow_encrypt_override impostato su true.
Queste personalizzazioni non sono supportate dal kernel comune di Android.
Per impostazione predefinita, il metodo di crittografia dei metadati del volume dm-crypt utilizza la classe
Algoritmo di crittografia AES-128-CBC con settori crittografici ESSIV e 512-byte. Questo
può essere sostituito impostando le seguenti proprietà di sistema (che sono
utilizzata per FDE):
ro.crypto.fde_algorithmseleziona la crittografia dei metadati dell'algoritmo. Le opzioni disponibili sonoaes-128-cbceadiantum. Adiantum può essere utilizzato solo se il dispositivo non dispone dell'accelerazione AES.ro.crypto.fde_sector_sizeseleziona le dimensioni del settore delle criptovalute. Le opzioni sono 512, 1024, 2048 e 4096. Per la crittografia Adiantum, utilizza 4096.