Android 7.0 e versioni successive supportano la 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, come i layout delle directory, le dimensioni dei file, le autorizzazioni e i tempi di creazione/modifica, non vengono criptate. 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 a sua volta è protetta da Avvio verificato.
La crittografia dei metadati è sempre attivata sullo spazio di archiviazione adottabile ogni volta che è attiva la crittografia lato client. 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 nella memoria interna dei nuovi dispositivi configurando il file system metadata, modificando la sequenza di avvio e attivando la crittografia dei metadati nel file fstab del dispositivo.
Prerequisiti
La crittografia dei metadati può essere configurata solo dopo la prima formattazione della partizione dati. Di conseguenza, questa funzionalità è disponibile solo per i nuovi dispositivi e non è una funzionalità che dovrebbe essere modificata.
La crittografia dei metadati richiede l'abilitazione del modulo dm-default-key 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 dall'hardware e dal fornitore denominato blk-crypto.
Per attivare dm-default-key, utilizza:
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 abilitare un'API di riserva di riserva 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 dati utente finché non è presente la chiave di crittografia dei metadati, la tabella di partizione 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 del montaggio di /data. Per assicurarti che venga avviato in tempo, aggiungi
la seguente stanza a 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'istruzione mount_all
che monta /data stesso nella stanza on
late-fs. Prima di questa riga, aggiungi l'istruzione per eseguire il servizio wait_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 alla colonna fs_mgr_flags della voce fstab per userdata. Ad esempio, una riga 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 nella memoria interna è AES-256-XTS. È possibile eseguire l'override di questa opzione impostando l'opzione metadata_encryption, anche nella colonna fs_mgr_flags:
- Sui dispositivi privi dell'accelerazione AES, la crittografia Adiantum può essere
attivata 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 su 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 della nuova APIdm-default-key indipendentemente dal livello dell'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 nella memoria interna:
adb rootadb shell dmctl table userdata
L'output dovrebbe essere simile a questo:
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 ignorato le impostazioni di crittografia predefinite impostando l'opzione metadata_encryption in fstab del dispositivo, l'output è leggermente diverso da quello riportato sopra. Ad esempio, se hai abilitato la crittografia Adiantum, il terzo campo è xchacha12,aes-adiantum-plain64 anziché aes-xts-plain64.
Quindi, esegui vts_kernel_encryption_test per verificare la correttezza della crittografia dei metadati e di FBE:
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 la partizione /data con crittografia dei metadati, init esegue lo strumento vdc. Lo strumento Vdc si connette a vold tramite binder per configurare il dispositivo criptato con metadati e montare la partizione. Per la durata di questa
chiamata, init sarà bloccato e tenterà di leggere o impostare
il blocco delle proprietà init fino al termine mount_all.
Se, in questa fase, qualsiasi parte del lavoro di vold viene bloccata direttamente o
indirettamente nella lettura o nell'impostazione di una proprietà, vengono rilevati risultati di 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. Posizionando exec_start wait_for_keymaster sopra la chiamata di mount_all pertinente come indicato, Keymaster verrà eseguito completamente in anticipo ed evita questo deadlock.
Configurazione sullo spazio di archiviazione adottabile
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, esistono due implementazioni della crittografia dei metadati per l'archiviazione adottabile: una deprecata in base a dm-crypt e una più recente basata su dm-default-key. Per assicurarti di aver selezionato la corretta implementazione per il tuo dispositivo, verifica di aver impostato il valore corretto per PRODUCT_SHIPPING_API_LEVEL in device.mk. Ad esempio,
se il tuo dispositivo viene avviato con Android 11 (livello API 30),
device.mk dovrebbe 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 del volume (e della nuova versione predefinita del criterio FBE) indipendentemente dal livello dell'API di importazione:
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 corrente
Sui dispositivi con Android 11 o versioni successive, la crittografia dei metadati sullo spazio di archiviazione adottabile utilizza il modulo del kernel dm-default-key, proprio come per la memoria interna. Vedi i prerequisiti qui sopra per quali opzioni di configurazione del kernel abilitare. Tieni presente che l'hardware di crittografia in linea che funziona sulla memoria interna del dispositivo potrebbe non essere disponibile sullo spazio di archiviazione adottabile e, di conseguenza, potrebbe essere richiesto 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. È possibile eseguire l'override dell'algoritmo impostando la proprietà di sistema ro.crypto.volume.metadata.encryption. Il valore di questa proprietà ha la stessa sintassi dell'opzione fstab metadata_encryption descritta in precedenza. Ad esempio, sui dispositivi che non dispongono dell'accelerazione AES, la crittografia Adiantum può essere attivata impostando ro.crypto.volume.metadata.encryption=adiantum.
Metodo precedente
Sui dispositivi lanciati con Android 10 o versioni precedenti, la crittografia dei metadati sullo spazio di archiviazione adottabile utilizza il modulo del 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 e non è obbligatoria per raggiungere gli obiettivi di sicurezza della crittografia dei metadati, poiché Android garantisce che le chiavi FBE siano almeno altrettanto difficili da compromettere quanto la chiave di crittografia dei metadati. I fornitori possono apportare personalizzazioni al kernel per evitare la doppia crittografia, in particolare implementando l'opzione allow_encrypt_override che Android passa a dm-crypt quando la proprietà di sistema ro.crypto.allow_encrypt_override è impostata 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 l'algoritmo di crittografia AES-128-CBC con ESSIV e settori di crittografia a 512 byte. Questo valore può essere ignorato impostando le seguenti proprietà di sistema (utilizzate anche per la crittografia lato client):
ro.crypto.fde_algorithmseleziona l'algoritmo di crittografia dei metadati. Le opzioni sonoaes-128-cbceadiantum. Adiantum può essere utilizzato solo se il dispositivo non dispone dell'accelerazione AES.ro.crypto.fde_sector_sizeseleziona la dimensione del settore crypto. Le opzioni sono 512, 1024, 2048 e 4096. Per la crittografia Adiantum, utilizza 4096.