À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

Cette page a été traduite par l'API Cloud Translation.

Chiffrement des métadonnées

Android 7.0 ou version ultérieure est compatible chiffrement basé sur les fichiers (FBE). FBE permet de chiffrer différents fichiers avec différentes clés qui peuvent être déverrouillées indépendamment. Ces clés permettent de chiffrer à la fois le contenu et les noms des fichiers. Lorsque le chiffrement de bout en bout est utilisé, d'autres informations, telles que les mises en page de répertoires, les tailles de fichiers, les autorisations et les heures de création/modification, ne sont pas chiffrées. Ensemble, ces autres informations sont connues sous le nom de métadonnées du système de fichiers.

Android 9 est compatible avec le chiffrement des métadonnées. Avec le chiffrement des métadonnées, une seule clé présente au démarrage chiffre tout le contenu n'est pas chiffré par FBE. Cette clé est protégée par Keymaster, qui dans est protégé par le démarrage validé.

Le chiffrement des métadonnées est toujours activé sur le stockage adoptable lorsque le FBE est activé. Le chiffrement des métadonnées peut également être activé sur la mémoire de stockage interne. Appareils lancés avec Android 11 ou version ultérieure, les métadonnées doivent être chiffrées sur la mémoire de stockage interne.

Implémentation sur la mémoire de stockage interne

Vous pouvez configurer le chiffrement des métadonnées dans la mémoire de stockage interne des nouveaux appareils en procédant comme suit : configurer le système de fichiers metadata, modifier la séquence d'initialisation, et activer 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 lorsque la partition de données est la première formatées. Par conséquent, cette fonctionnalité n'est destinée qu'aux nouveaux appareils. Ce n'est pas quelque chose qu'une mise à jour OTA devrait modifier.

Le chiffrement des métadonnées nécessite que le module dm-default-key soit activé dans votre noyau. Sur Android 11 et versions ultérieures, dm-default-key est compatible avec les noyaux courants Android, 4.14 et versions ultérieures. Cette version de dm-default-key utilise un framework de chiffrement indépendant du matériel et des fournisseurs 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 du matériel de chiffrement intégré (matériel chiffre/déchiffre les données en transit vers/depuis l'appareil de stockage) lorsque disponibles. Si vous n'utilisez pas de matériel de chiffrement intégré, également nécessaire pour activer un remplacement de l'API de cryptographie du noyau:

CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y

Lorsque vous n'utilisez pas de matériel de chiffrement intégré, vous devez également activer L'accélération basée sur le processeur, comme recommandé dans la documentation FBE.

Sous Android 10 ou version antérieure, dm-default-key n'était pas pris en charge par le noyau courant 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 de la partition userdata ne peut être lu tant que la clé de chiffrement des métadonnées n'est pas présente, la table de partitionnement doit réserver 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 se trouve sur cette partition et l'installe sur /metadata, y compris l'option formattable pour vous assurer qu'elle est formatée au démarrage. La Le système de fichiers f2fs ne fonctionne pas sur des partitions plus petites ; nous vous recommandons d'utiliser ext4 à la place. Exemple :

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

Pour vous assurer que le point d'installation /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 exécuté avant /data est installé. Pour vous assurer qu'il est démarré 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 l'initialisation ne tente de monter /data.

init.hardware.rc doit déjà contenir un mount_all qui installe /data lui-même dans la stanza 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 au Colonne fs_mgr_flags de l'entrée fstab pour userdata Par exemple, une ligne fstab complète peut se présenter comme suit :

/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 la mémoire de stockage interne AES-256-XTS Vous pouvez ignorer ce paramètre en définissant l'option metadata_encryption, également dans Colonne fs_mgr_flags:

Sur les appareils qui ne disposent pas d'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 metadata_encryption=aes-256-xts:wrappedkey_v0 (ou équivaut à metadata_encryption=:wrappedkey_v0, comme aes-256-xts est l'algorithme par défaut).

Comme l'interface du noyau vers dm-default-key a changé dans Android 11, assurez-vous également d'avoir défini 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 contiennent:

PRODUCT_SHIPPING_API_LEVEL := 30

Vous pouvez également définir la propriété système suivante pour forcer l'utilisation du nouveau dm-default-key quel que soit le niveau d'API de livraison:

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 de dépannage 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 root
adb 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 ignoré les paramètres de chiffrement par défaut en paramétrant le l'option metadata_encryption dans le fstab de l'appareil, puis le résultat diffère légèrement de ce qui précède. Par exemple, si vous avez activé le chiffrement Adiantum, le troisième champ est xchacha12,aes-adiantum-plain64 au lieu de aes-xts-plain64.

Exécutez ensuite vts_kernel_encryption_test pour vérifier l'exactitude du chiffrement des métadonnées et du FBE :

atest vts_kernel_encryption_test

ou :

vts-tradefed run vts -m vts_kernel_encryption_test

Problèmes courants

Lors de l'appel de mount_all, qui monte la partition /data chiffrée par métadonnées, init exécute l'outil vdc. L'outil vdc se connecte à vold via binder pour configurer l'appareil chiffré par métadonnées et installer la partition. Pendant toute la durée init est bloqué, et tente de lire ou de définir Les propriétés de init seront bloquées jusqu'à la fin de mount_all. Si, à ce stade, une partie du travail de vold est bloquée directement ou indirectement lors de la lecture ou de la définition d'une propriété, un interblocage se produit. Il est important de s'assurer que vold peut effectuer la lecture des clés, interagir avec Keymaster et monter le 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é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'appel mount_all approprié, comme indiqué, garantit que Keymaster s'exécute entièrement à l'avance et évite ainsi ce blocage.

Configuration sur un stockage adoptable

Depuis Android 9, une forme de chiffrement des métadonnées Toujours activée sur l'espace de stockage adoptable chaque fois que FBE est activé, même si le chiffrement des métadonnées n'est pas activé mémoire de stockage interne.

Dans AOSP, il existe deux implémentations du chiffrement des métadonnées sur le stockage adoptable : une version obsolète basée sur dm-crypt et une version plus récente basée sur dm-default-key. Pour vous assurer que la bonne implémentation est sélectionnée pour votre appareil, assurez-vous 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:

PRODUCT_SHIPPING_API_LEVEL := 30

Vous pouvez également définir les propriétés système suivantes pour forcer l'utilisation du nouveau Méthode de chiffrement des métadonnées de volume (et nouvelle version de la stratégie FBE par défaut) quel que soit le niveau d'API de livraison:

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 kernel dm-default-key, comme sur le stockage interne. Consultez les conditions préalables ci-dessus pour savoir quelle configuration de noyau à activer. Notez que le matériel de chiffrement intégré qui fonctionne sur la mémoire de stockage interne de l'appareil peut ne pas être disponible sur le stockage adoptable. CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y peut donc être nécessaire.

Par défaut, la méthode de chiffrement des métadonnées du 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 fstab metadata_encryption décrite ci-dessus. Par exemple, sur les appareils qui ne disposent pas d'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 équipés d'Android 10 ou version antérieure, les métadonnées le chiffrement sur un espace de stockage adoptable utilise le module de noyau dm-crypt au lieu de dm-default-key:

CONFIG_DM_CRYPT=y

Contrairement à la méthode dm-default-key, la méthode dm-crypt entraîne le chiffrement deux fois du contenu du fichier: 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 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 les métadonnées clé de chiffrement. Les fournisseurs peuvent personnaliser le noyau pour éviter le double chiffrement, en particulier en implémentant l'option allow_encrypt_override que 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. Ce peut être remplacée en définissant les propriétés système suivantes (qui sont également utilisé pour FDE):

ro.crypto.fde_algorithm sélectionne l'algorithme de chiffrement des métadonnées. Vous avez le choix entre aes-128-cbc et adiantum Adiantum ne peut être utilisé que si l'appareil ne dispose pas d'accélération AES.
ro.crypto.fde_sector_size sélectionne la taille du secteur des cryptomonnaies. Vous avez le choix entre 512, 1 024, 2 048 et 4 096. Pour le chiffrement Adiantum, utilisez 4096.