Crittografia dei metadati

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 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. Collettivamente, quest'altra informazione è nota come metadati di 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 qualsiasi cosa i contenuti non sono criptati da FBE. 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. Dispositivi lanciati con Android 11 o versioni successive, è necessario disporre della crittografia dei metadati sulla memoria interna.

Implementazione nella memoria interna

Puoi configurare la crittografia dei metadati nella memoria interna dei nuovi dispositivi configurare il file system metadata, modificare la sequenza di inizializzazione e Attivare 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à è disponibile solo per i nuovi dispositivi. questo non è e qualcosa che un'agenzia di viaggi online dovrebbe cambiare.

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 Android, versione 4.14 e successive. Questa versione di dm-default-key utilizza un hardware e framework di crittografia indipendente dal 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 mentre sono in viaggio verso/dal dispositivo di archiviazione) quando disponibili. Se non utilizzerai hardware di crittografia in linea, è necessario anche per abilitare un fallback all'API di crittografia del kernel: 

CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y

Se non utilizzi hardware di crittografia in linea, devi abilitare anche qualsiasi Accelerazione basata sulla CPU come consigliato nella documentazione FBE.

In Android 10 e versioni precedenti, dm-default-key non era supportato dal kernel comune di Android. Di conseguenza, spettava ai fornitori per implementare dm-default-key.

Configura il file system dei metadati

Perché nulla nella partizione dati utente può essere letto fino a quando i metadati chiave di crittografia, la tabella di partizione deve riservare una chiave denominata "metadata partition" per l'archiviazione dei BLOB keymaster che proteggere la chiave. La partizione dei metadati deve essere di 16 MB.

fstab.hardware deve includere una voce per il file system di metadati che risiede su quella partizione montandola su /metadata, includendo il flag formattable per garantire che sia formattato al momento dell'avvio. La Il file system f2fs non funziona su partizioni più piccole; consigliamo di usare 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 l'istruzione per exec 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

Attivazione della 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 nella memoria interna AES-256-XTS. Questa opzione può essere ignorata impostando il valore metadata_encryption, anche nel Colonna fs_mgr_flags:

  • Sui dispositivi privi di accelerazione AES, la crittografia Adiantum potrebbe abilitato impostando metadata_encryption=adiantum.
  • Sui dispositivi che supportano 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 equivalente a metadata_encryption=:wrappedkey_v0, come aes-256-xts è l'algoritmo predefinito).

Perché l'interfaccia del kernel in dm-default-key è cambiata in Android 11, devi inoltre assicurarti di aver impostato valore corretto di PRODUCT_SHIPPING_API_LEVEL in device.mk. Ad esempio, se il dispositivo viene avviato con Android 11 (livello API 30), device.mk deve contiene: 

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. Inoltre, tieni presente le di sicurezza descritti di seguito.

Test

Inizia eseguendo questo comando per verificare che la crittografia dei metadati sia abilitata nella memoria interna: 

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 sovrascritto le impostazioni di crittografia predefinite impostando il parametro Opzione metadata_encryption nell'app fstab del dispositivo, poi l'output sarà leggermente diverso da quanto riportato sopra. Ad esempio, se hai abilitato la crittografia Adiantum, il terzo sarà xchacha12,aes-adiantum-plain64 invece di 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 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 la durata di questo periodo chiamata, init è bloccato e tenta di leggere o impostare init proprietà verrà bloccata fino al termine del periodo mount_all. Se, in questa fase, qualsiasi parte del lavoro di vold è direttamente o indirettamente bloccato durante la lettura o l'impostazione di una proprietà, ne risulta un deadlock. È è importante assicurarsi che vold possa completare la lettura chiave, interagendo con Keymaster e montando la directory dei dati senza interagendo ulteriormente con init.

Se Keymaster non viene avviato completamente quando mount_all è in esecuzione, non rispondi a vold finché non avrà letto determinate proprietà da init, generando esattamente il deadlock descritto. In fase di posizionamento exec_start wait_for_keymaster sopra il valore pertinente La chiamata di mount_all come indicato garantisce che Keymaster sia completamente in anticipo, evitando così questa situazione di stallo.

Configurazione sullo spazio di archiviazione adottabile

Da Android 9, viene usata una forma di crittografia dei metadati Sempre abilitato per lo spazio di archiviazione utilizzabile ogni volta che FBE è abilitato, anche quando la crittografia dei metadati non è abilitata su memoria interna.

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, pertanto 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 di crittografia a 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 causa la doppia crittografia dei contenuti dei file: una con una chiave FBE e l'altra 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 allow_encrypt_override opzione a cui Android passerà 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_algorithm seleziona la crittografia dei metadati dell'algoritmo. Le opzioni disponibili 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.