Crittografia dei metadati

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 gli orari 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 all'avvio cripta tutti i contenuti non criptati da FBE. Questa chiave è protetta da KeyMint (in precedenza Keymaster), che a sua volta è protetta dall'Avvio verificato.

La crittografia dei metadati è sempre attiva sulla memoria adattabile ogni volta che FBE è abilitato. La crittografia dei metadati può essere attivata anche sulla memoria interna. I dispositivi lanciati con Android 11 o versioni successive devono avere la crittografia dei metadati sulla memoria interna attivata.

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 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 viene formattata per la prima volta. 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 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 dall'hardware e dal 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 mentre sono in transito verso/da un dispositivo di archiviazione) quando disponibile. Se non utilizzi hardware di crittografia inline, è necessario anche 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 l'accelerazione basata sulla CPU disponibile, come consigliato nella documentazione FBE.

In Android 10 e versioni precedenti, dm-default-key non era supportato dal kernel comune di Android. Pertanto, spettava 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 archiviare i blob KeyMint 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 su quella partizione, montandola in /metadata, inclusa l'opzione formattable per assicurarsi che venga formattata all'avvio. Il file system f2fs non funziona su partizioni più piccole; ti consigliamo di utilizzare ext4 in alternativa. Ad esempio: 

/dev/block/bootdevice/by-name/metadata              /metadata          ext4        noatime,nosuid,nodev,discard                          wait,check,formattable

Per assicurarti che esista il punto di montaggio /metadata, 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 che venga montato /data. Per assicurarti che venga avviato in tempo, aggiungi la seguente sezione a init.hardware.rc: 

# We need vold early for metadata encryption
on early-fs
    start vold

KeyMint deve essere in esecuzione e pronto prima che init tenti di montare /data.

init.hardware.rc dovrebbe già contenere un'istruzione mount_all che monta /data nella sezione on late-fs. Prima di questa riga, aggiungi la direttiva 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

Attiva 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 sulla memoria interna è AES-256-XTS. Questo valore può essere sostituito impostando l'opzione metadata_encryption, anch'essa nella colonna fs_mgr_flags:

  • Sui dispositivi che non dispongono dell'accelerazione AES, la crittografia Adiantum può essere abilitata impostando metadata_encryption=adiantum.
  • Sui dispositivi che supportano le chiavi protette dall'hardware, la chiave di crittografia dei metadati può essere protetta dall'hardware impostando metadata_encryption=aes-256-xts:wrappedkey_v0 (o metadata_encryption=:wrappedkey_v0 in modo equivalente, 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 API dm-default-key indipendentemente dal livello dell'API Shipping: 

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

Inizia eseguendo questo comando per verificare che la crittografia dei metadati sia attivata sullo spazio di archiviazione interno: 

adb root
adb 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 nelle fstab del dispositivo, l'output è leggermente diverso da quello sopra indicato. 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 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 criptata con i metadati, init esegue lo strumento vdc. Lo strumento vdc si connette a vold tramite binder per configurare il dispositivo con metadati criptati e montare la partizione. Per la durata di questa chiamata, init è bloccato e i tentativi di leggere o impostare le proprietà di init vengono bloccati fino al termine di mount_all. Se, in questa fase, una parte del lavoro di vold viene bloccata direttamente o indirettamente nella lettura o nell'impostazione di una proprietà, si verifica un deadlock. È importante assicurarsi che vold possa completare il lavoro di lettura delle chiavi, interagire con KeyMint e montare la directory dei dati senza interagire ulteriormente con init.

Se KeyMint non è completamente avviato quando viene eseguito mount_all, non risponde a vold finché non ha letto determinate proprietà da init, il che comporta esattamente il deadlock descritto. Il posizionamento di exec_start wait_for_keymaster sopra l'invocazione mount_all pertinente, come indicato, garantisce che KeyMint sia in esecuzione in anticipo ed evita quindi questo stallo.

Configurazione dello spazio di archiviazione utilizzabile

A partire da Android 9, una forma di crittografia dei metadati è sempre abilitata sull'archiviazione adottabile ogni volta che FBE è abilitata, anche quando la crittografia dei metadati non è abilitata sull'archiviazione interna.

In AOSP esistono due implementazioni della crittografia dei metadati sullo spazio di archiviazione adottabile: una obsoleta basata su dm-crypt e una più recente basata su dm-default-key. Per assicurarti che l'implementazione corretta sia selezionata 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 del volume (e della nuova versione predefinita dei criteri FBE) indipendentemente 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 lanciati con Android 11 o versioni successive, la crittografia dei metadati sullo spazio di archiviazione adattabile utilizza il modulo del kernel dm-default-key, proprio come sullo spazio di archiviazione interno. Consulta i prerequisiti sopra per scoprire 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 sulla memoria adattabile e pertanto potrebbe essere necessario 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 di crittografia di 4096 byte. L'algoritmo può essere sostituito 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 impostando ro.crypto.volume.metadata.encryption=adiantum.

Metodo legacy

Sui dispositivi lanciati con Android 10 e versioni precedenti, la crittografia dei metadati sullo spazio di archiviazione adattabile 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 dei 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 è necessaria 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 personalizzare il 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 può essere sostituito impostando le seguenti proprietà di sistema (che vengono utilizzate anche per FDE):

  • ro.crypto.fde_algorithm seleziona l'algoritmo di crittografia dei metadati. Le opzioni sono aes-128-cbc e adiantum. Adiantum può essere utilizzato solo se il dispositivo non dispone dell'accelerazione AES.
  • ro.crypto.fde_sector_size seleziona le dimensioni del settore delle criptovalute. Le opzioni sono 512, 1024, 2048 e 4096. Per la crittografia Adiantum, utilizza 4096.