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 utilizzata la crittografia lato client, 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 dall'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 attivata anche sullo spazio di archiviazione interno. 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 al primo formattazione della partizione di dati. 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 attivato 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, 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 attivare un fallback all'API di crittografia del kernel:
CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y
Se 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 denominata "partizione dei metadati" per l'archiviazione dei blob keymaster che proteggono questa chiave. La partizione dei metadati deve avere una dimensione 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 inizializzazione
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 init provi a montare
/data.
init.hardware.rc dovrebbe già contenere un'istruzione 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 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 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 che non dispongono 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 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 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 presente anche i problemi comuni descritti di seguito.
Test
Per prima cosa, esegui il seguente comando per verificare che la crittografia dei metadati sia attivata sullo spazio di archiviazione interno:
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 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 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 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 con crittografia dei metadati 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 sono presenti due implementazioni della crittografia dei metadati nello spazio di archiviazione adottabile: una deprecata basata su dm-crypt e una più recente basata su dm-default-key. Per assicurarti che sia selezionata l'implementazione corretta per il tuo dispositivo, assicurati 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 le seguenti proprietà di sistema per forzare l'utilizzo del nuovo metodo di crittografia dei metadati dei volumi (e della nuova versione predefinita del criterio FBE) indipendentemente dal livello dell'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 corrente
Sui dispositivi lanciati con Android 11 o versioni successive, la crittografia dei metadati sullo spazio di archiviazione adottabile utilizza il modulo del kernel dm-default-key, come nello spazio di archiviazione interno. Consulta i prerequisiti sopra per sapere quali opzioni di configurazione del kernel attivare. Tieni presente che l'hardware di crittografia in linea che funziona sullo spazio di archiviazione interno 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. L'algoritmo può essere ignorato impostando la proprietà di sistema ro.crypto.volume.metadata.encryption. Il valore di questa proprietà ha la stessa sintassi dell'opzione metadata_encryption fstab descritta sopra. Ad esempio, sui dispositivi che non dispongono dell'accelerazione AES, la crittografia Adiantum può essere attivata impostandoro.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 crittografici di 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 cripto. Le opzioni sono 512, 1024, 2048 e 4096. Per la crittografia Adiantum, utilizza 4096.