Android 7.0 et les versions ultérieures sont compatibles avec le chiffrement basé sur les fichiers (FBE). FBE permet de chiffrer différents fichiers avec différentes clés pouvant être déverrouillées indépendamment. Ces clés permettent de chiffrer à la fois le contenu et les noms des fichiers. Lorsque le FBE est utilisé, d'autres informations, telles que les mises en page 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 moment du démarrage chiffre tout le contenu qui n'est pas chiffré par FBE. Cette clé est protégée par KeyMint (anciennement Keymaster), qui est elle-même protégée par le démarrage validé.
Le chiffrement des métadonnées est toujours activé sur le stockage adoptable lorsque 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 le chiffrement des métadonnées activé sur le stockage interne.
Implémentation sur la mémoire de 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.
Prérequis
Le chiffrement des métadonnées ne peut être configuré que lors du premier formatage de la partition de données. Par conséquent, cette fonctionnalité n'est disponible que pour les nouveaux appareils. Elle ne doit pas être modifiée par une mise à jour OTA.
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 ultérieure. Cette version de dm-default-key utilise un framework de chiffrement indépendant du matériel et du fournisseur appelé 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 un matériel de chiffrement intégré (matériel qui chiffre/déchiffre les données lorsqu'elles sont en cours de transfert vers/depuis le périphérique de stockage) lorsqu'il est disponible. Si vous n'utilisez pas de matériel de chiffrement intégré, 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 intégré, vous devez également activer toute accélération basée sur le processeur disponible, 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 fournisseurs d'implémenter dm-default-key.
Configurer le système de fichiers de métadonnées
Étant donné que rien ne peut être lu dans la partition de données utilisateur 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 KeyMint 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 se trouve sur cette partition, en le montant à /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 les partitions plus petites. Nous vous recommandons d'utiliser plutôt ext4. 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 apportées à la séquence d'initialisation
Lorsque le chiffrement des métadonnées est utilisé, vold doit être en cours d'exécution avant le montage de /data. 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
KeyMint doit être en cours d'exécution et prêt avant que init tente de monter /data.
init.hardware.rc doit déjà contenir une instruction mount_all qui monte /data lui-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 peut ressembler à ceci :
/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. Vous pouvez remplacer cette valeur par défaut en définissant l'option metadata_encryption dans la colonne fs_mgr_flags :
- Sur les appareils qui ne disposent pas de l'accélération AES, le chiffrement Adiantum peut être activé en définissant
metadata_encryption=adiantum. - Sur les appareils compatibles avec 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(oumetadata_encryption=:wrappedkey_v0, caraes-256-xtsest 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 d'avoir défini la valeur correcte pour PRODUCT_SHIPPING_API_LEVEL dans device.mk. Par exemple, si votre appareil est lancé avec Android 11 (niveau d'API 30), device.mk doit contenir les éléments suivants :
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 de l'API Shipping :
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.
Tests
Commencez par exécuter la commande suivante pour vérifier que le chiffrement des métadonnées est activé sur le stockage interne :
adb rootadb shell dmctl table userdata
Le résultat doit être semblable à ceci :
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, la sortie sera légèrement différente de celle ci-dessus. Par exemple, si vous avez activé le chiffrement Adiantum, le troisième champ est 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 avec des métadonnées, init exécute l'outil vdc. L'outil vdc se connecte à vold via binder pour configurer l'appareil chiffré avec des métadonnées et installer la partition. Pendant toute la durée de cet appel, init est bloqué, et les tentatives de lecture ou de définition des propriétés init sont 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é, il en résulte un blocage. Il est important de s'assurer que vold peut lire les clés, interagir avec KeyMint et monter le répertoire de données sans interagir davantage avec init.
Si KeyMint n'est pas complètement démarré lorsque mount_all s'exécute, il ne répond pas à vold tant qu'il n'a pas lu certaines propriétés de init, ce qui entraîne exactement le blocage décrit. Placer exec_start wait_for_keymaster au-dessus de l'invocation mount_all concernée, comme indiqué, permet de s'assurer que KeyMint est entièrement exécuté à l'avance et d'éviter ainsi ce blocage.
Configuration sur le stockage adoptable
Depuis Android 9, une forme de chiffrement des métadonnées est toujours activée sur le stockage adoptable lorsque FBE est activé, même si 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 implémentation obsolète basée sur dm-crypt et une implémentation plus récente basée sur dm-default-key. Pour vous assurer que la bonne implémentation est sélectionnée pour votre appareil, vérifiez que vous avez défini la bonne valeur pour PRODUCT_SHIPPING_API_LEVEL dans device.mk. Par exemple, si votre appareil est lancé avec Android 11 (niveau d'API 30), device.mk doit contenir les éléments suivants :
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 de la nouvelle version par défaut de la stratégie FBE), 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 version ultérieure, le chiffrement des métadonnées sur le stockage adoptable utilise le module de noyau dm-default-key, comme sur le stockage interne. Consultez les prerequisites ci-dessus pour savoir quelles options de configuration du noyau activer. Notez que le matériel de chiffrement intégré qui fonctionne sur la mémoire interne de l'appareil peut ne pas être disponible sur la mémoire adoptable. Par conséquent, CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y peut être nécessaire.
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 4 096 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 metadata_encryption fstab décrite ci-dessus. Par exemple, sur les appareils qui ne disposent pas de l'accélération AES, le chiffrement Adiantum peut être activé en définissant ro.crypto.volume.metadata.encryption=adiantum.
Ancienne méthode
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 des fichiers à deux reprises : 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 fournisseurs peuvent personnaliser le noyau pour éviter le double chiffrement, en particulier en implémentant l'option allow_encrypt_override qu'Android transmet à dm-crypt lorsque la propriété système ro.crypto.allow_encrypt_override est définie sur true.
Ces personnalisations ne sont pas compatibles avec 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. Vous pouvez remplacer cette valeur en définissant les propriétés système suivantes (qui sont également utilisées pour le FDE) :
ro.crypto.fde_algorithmsélectionne l'algorithme de chiffrement des métadonnées. Les options sontaes-128-cbcetadiantum. Adiantum ne peut être utilisé que si l'appareil ne dispose pas d'accélération AES.ro.crypto.fde_sector_sizesélectionne la taille du secteur des crypto-monnaies. Vous avez le choix entre 512, 1 024, 2 048 et 4 096. Pour le chiffrement Adiantum, utilisez 4096.