Android 7.0 et supérieur prend en charge le chiffrement basé sur les fichiers (FBE). FBE permet de crypter différents fichiers avec différentes clés qui peuvent être déverrouillées indépendamment. Ces clés sont utilisées pour chiffrer à la fois le contenu des fichiers et les noms de fichiers. Lorsque FBE est utilisé, d'autres informations, telles que la disposition des répertoires, la taille des fichiers, les autorisations et les heures de création/modification, ne sont pas chiffrées. Collectivement, ces autres informations sont appelées métadonnées du système de fichiers.
Android 9 a introduit la prise en charge du chiffrement des métadonnées. Avec le chiffrement des métadonnées, une seule clé présente au démarrage chiffre tout contenu non chiffré par FBE. Cette clé est protégée par Keymaster, qui à son tour est protégé par un démarrage vérifié.
Le chiffrement des métadonnées est toujours activé sur le stockage adoptable chaque fois que FBE est activé. Le chiffrement des métadonnées peut également être activé sur le stockage interne. Les appareils lancés avec Android 11 ou version ultérieure doivent avoir activé le chiffrement des métadonnées sur le stockage interne.
Implémentation sur le stockage interne
Vous pouvez configurer le chiffrement des métadonnées sur le stockage interne des nouveaux appareils en configurant le système de fichiers metadata
, en modifiant la séquence d'initialisation et en activant le chiffrement des métadonnées dans le fichier fstab de l'appareil.
Conditions préalables
Le chiffrement des métadonnées ne peut être configuré que lorsque la partition de données est formatée pour la première fois. Par conséquent, cette fonctionnalité est uniquement destinée aux nouveaux appareils ; ce n'est pas quelque chose qu'un OTA devrait changer.
Le chiffrement des métadonnées nécessite que le module dm-default-key
soit activé dans votre noyau. Dans Android 11 et versions ultérieures, dm-default-key
est pris en charge par les noyaux communs Android, version 4.14 et versions ultérieures. Cette version de dm-default-key
utilise une infrastructure de chiffrement indépendante du matériel et du fournisseur appelée blk-crypto .
Pour activer dm-default-key
, utilisez :
CONFIG_BLK_INLINE_ENCRYPTION=y CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y CONFIG_DM_DEFAULT_KEY=y
dm-default-key
utilise le matériel de chiffrement en ligne (matériel qui chiffre/déchiffre les données lorsqu'elles sont en route vers/depuis le périphérique de stockage) lorsqu'il est disponible. Si vous n'utilisez pas de matériel de chiffrement en ligne, il est également nécessaire d'activer un retour à l'API de chiffrement du noyau :
CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y
Lorsque vous n'utilisez pas de matériel de chiffrement en ligne, vous devez également activer toute accélération disponible basée sur le processeur, comme recommandé dans la documentation FBE .
Dans Android 10 et versions antérieures, dm-default-key
n'était pas pris en charge par le noyau commun Android. Il appartenait donc aux éditeurs d'implémenter dm-default-key
.
Configurer le système de fichiers de métadonnées
Étant donné que rien dans la partition de données utilisateur ne peut être lu tant que la clé de chiffrement des métadonnées n'est pas présente, la table de partition doit mettre de côté une partition distincte appelée "partition de métadonnées" pour stocker les blobs keymaster qui protègent cette clé. La partition de métadonnées doit être de 16 Mo.
fstab.hardware
doit inclure une entrée pour le système de fichiers de métadonnées qui vit sur cette partition en le montant sur /metadata
, y compris l'indicateur formattable
pour s'assurer qu'il est formaté au démarrage. Le système de fichiers f2fs ne fonctionne pas sur des partitions plus petites ; nous vous recommandons d'utiliser ext4 à la place. Par exemple:
/dev/block/bootdevice/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard wait,check,formattable
Pour vous assurer que le point de montage /metadata
existe, ajoutez la ligne suivante à BoardConfig-common.mk
:
BOARD_USES_METADATA_PARTITION := true
Modifications de la séquence d'initialisation
Lorsque le chiffrement des métadonnées est utilisé, vold
doit être en cours d'exécution avant que /data
ne soit monté. Pour vous assurer qu'il démarre suffisamment tôt, ajoutez la strophe suivante à init.hardware.rc
:
# We need vold early for metadata encryption on early-fs start vold
Keymaster doit être en cours d'exécution et prêt avant que init ne tente de monter /data
.
init.hardware.rc
devrait déjà contenir une instruction mount_all
qui monte /data
elle-même dans la strophe on late-fs
. Avant cette ligne, ajoutez la directive pour exécuter le service 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
Activer le chiffrement des métadonnées
Enfin, ajoutez keydirectory=/metadata/vold/metadata_encryption
à la colonne fs_mgr_flags de l'entrée fstab
pour userdata
. Par exemple, une ligne fstab complète pourrait ressembler à :
/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
Par défaut, l'algorithme de chiffrement des métadonnées sur le stockage interne est AES-256-XTS. Cela peut être remplacé en définissant l'option metadata_encryption
, également dans la colonne fs_mgr_flags :
- Sur les appareils dépourvus d'accélération AES, le chiffrement Adiantum peut être activé en définissant
metadata_encryption=adiantum
. - Sur les appareils prenant en charge les clés encapsulées dans le matériel , la clé de chiffrement des métadonnées peut être encapsulée dans le matériel en définissant
metadata_encryption=aes-256-xts:wrappedkey_v0
(ou de manière équivalentemetadata_encryption=:wrappedkey_v0
, caraes-256-xts
est l'algorithme par défaut).
Étant donné que l'interface du noyau vers dm-default-key
a changé dans Android 11, vous devez également vous assurer que vous avez défini la valeur correcte pour PRODUCT_SHIPPING_API_LEVEL
dans device.mk
. Par exemple, si votre appareil démarre avec Android 11 (API niveau 30), device.mk
doit contenir :
PRODUCT_SHIPPING_API_LEVEL := 30
Vous pouvez également définir la propriété système suivante pour forcer l'utilisation de la nouvelle API dm-default-key
quel que soit le niveau d'API d'expédition :
PRODUCT_PROPERTY_OVERRIDES += \ ro.crypto.dm_default_key.options_format.version=2
Validation
Pour vérifier que le chiffrement des métadonnées est activé et fonctionne correctement, exécutez les tests décrits ci-dessous. Tenez également compte des problèmes courants décrits ci-dessous.
Essais
Commencez par exécuter la commande suivante pour vérifier que le chiffrement des métadonnées est activé sur le stockage interne :
adb root
adb shell dmctl table userdata
La sortie devrait ressembler à :
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
Si vous avez remplacé les paramètres de chiffrement par défaut en définissant l'option metadata_encryption
dans le fstab
de l'appareil, le résultat sera légèrement différent de ce qui précède. Par exemple, si vous avez activé le chiffrement Adiantum , le troisième champ sera xchacha12,aes-adiantum-plain64
au lieu de aes-xts-plain64
.
Ensuite, exécutez vts_kernel_encryption_test pour vérifier l'exactitude du chiffrement des métadonnées et de FBE :
atest vts_kernel_encryption_test
ou:
vts-tradefed run vts -m vts_kernel_encryption_test
Problèmes courants
Lors de l'appel à mount_all
, qui monte la partition /data
chiffrée par les métadonnées, init
exécute l'outil vdc. L'outil vdc se connecte à vold
over binder
pour configurer le périphérique chiffré par métadonnées et monter la partition. Pendant la durée de cet appel, init
est bloqué et les tentatives de lecture ou de définition des propriétés init
seront bloquées jusqu'à ce que mount_all
se termine. Si, à ce stade, une partie du travail de vold
est directement ou indirectement bloquée lors de la lecture ou de la définition d'une propriété, une impasse en résultera. Il est important de s'assurer que vold
peut terminer le travail de lecture des clés, d'interaction avec Keymaster et de montage du répertoire de données sans interagir davantage avec init
.
Si Keymaster n'est pas complètement démarré lorsque mount_all
s'exécute, il ne répondra pas à vold
tant qu'il n'aura pas lu certaines propriétés de init
, ce qui entraînera exactement le blocage décrit. Placer exec_start wait_for_keymaster
au-dessus de l'invocation mount_all
appropriée, comme indiqué, garantit que Keymaster est entièrement exécuté à l'avance et évite ainsi ce blocage.
Configuration sur stockage adoptable
Depuis Android 9, une forme de chiffrement des métadonnées est toujours activée sur le stockage adoptable chaque fois que FBE est activé, même lorsque le chiffrement des métadonnées n'est pas activé sur le stockage interne.
Dans AOSP, il existe deux implémentations du chiffrement des métadonnées sur le stockage adoptable : une obsolète basée sur dm-crypt
et une plus récente basée sur dm-default-key
. Pour vous assurer que la mise en œuvre correcte est sélectionnée pour votre appareil, assurez-vous que vous avez défini la valeur correcte pour PRODUCT_SHIPPING_API_LEVEL
dans device.mk
. Par exemple, si votre appareil démarre avec Android 11 (API niveau 30), device.mk
doit contenir :
PRODUCT_SHIPPING_API_LEVEL := 30
Vous pouvez également définir les propriétés système suivantes pour forcer l'utilisation de la nouvelle méthode de chiffrement des métadonnées de volume (et la nouvelle version de politique FBE par défaut) quel que soit le niveau d'API d'expédition :
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
Méthode actuelle
Sur les appareils lancés avec Android 11 ou supérieur, le chiffrement des métadonnées sur le stockage adoptable utilise le module de noyau dm-default-key
, tout comme sur le stockage interne. Consultez les prérequis ci-dessus pour savoir quelles options de configuration du noyau activer. Notez que le matériel de chiffrement en ligne qui fonctionne sur le stockage interne de l'appareil peut ne pas être disponible sur le stockage adoptable, et donc CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y
peut être requis.
Par défaut, la méthode de chiffrement des métadonnées de volume dm-default-key
utilise l'algorithme de chiffrement AES-256-XTS avec des secteurs de chiffrement de 4096 octets. L'algorithme peut être remplacé en définissant la propriété système ro.crypto.volume.metadata.encryption
. La valeur de cette propriété a la même syntaxe que l'option fstab metadata_encryption
décrite ci-dessus. Par exemple, sur les appareils dépourvus d'accélération AES, le chiffrement Adiantum peut être activé en définissant ro.crypto.volume.metadata.encryption=adiantum
.
Méthode héritée
Sur les appareils lancés avec Android 10 ou une version antérieure, le chiffrement des métadonnées sur le stockage adoptable utilise le module de noyau dm-crypt
plutôt que dm-default-key
:
CONFIG_DM_CRYPT=y
Contrairement à la méthode dm-default-key
, la méthode dm-crypt
entraîne le chiffrement du contenu du fichier deux fois : une fois avec une clé FBE et une fois avec la clé de chiffrement des métadonnées. Ce double chiffrement réduit les performances et n'est pas nécessaire pour atteindre les objectifs de sécurité du chiffrement des métadonnées, car Android garantit que les clés FBE sont au moins aussi difficiles à compromettre que la clé de chiffrement des métadonnées. Les éditeurs peuvent effectuer des personnalisations du noyau pour éviter le double chiffrement, notamment en implémentant l'option allow_encrypt_override
qu'Android passera à dm-crypt
lorsque la propriété système ro.crypto.allow_encrypt_override
est définie sur true
. Ces personnalisations ne sont pas prises en charge par le noyau commun Android.
Par défaut, la méthode de chiffrement des métadonnées de volume dm-crypt
utilise l'algorithme de chiffrement AES-128-CBC avec ESSIV et des secteurs de chiffrement de 512 octets. Cela peut être remplacé en définissant les propriétés système suivantes (qui sont également utilisées pour FDE) :
-
ro.crypto.fde_algorithm
sélectionne l'algorithme de chiffrement des métadonnées. Les choix sontaes-128-cbc
etadiantum
. Adiantum ne peut être utilisé que si l'appareil manque d'accélération AES. -
ro.crypto.fde_sector_size
sélectionne la taille du secteur crypto. Les choix sont 512, 1024, 2048 et 4096. Pour le chiffrement Adiantum, utilisez 4096.