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 à l'aide de différentes clés pouvant être déverrouillées indépendamment les unes des autres. Ces clés permettent de chiffrer à la fois le contenu et les noms des fichiers. Lorsque FBE est utilisé, d’autres informations, telles que les mises en page de répertoire, la taille des fichiers, les autorisations et les délais de création/modification, n'est pas chiffré. Collectivement, 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 pouvant être adopté chaque fois que 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 disponible que pour les nouveaux appareils. ce n'est pas quelque chose qu’une agence de voyages en ligne doit changer.

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 matériel un framework de chiffrement indépendant 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 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. C'était donc aux fournisseurs pour implémenter dm-default-key.

Configurer le système de fichiers de métadonnées

Parce que rien dans la partition userdata ne peut être lu tant que les métadonnées de chiffrement est présente, la table de partitionnement doit réserver appelée "partition des métadonnées" permettant de stocker les blobs keymaster protéger 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 : vers 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'elle est lancée suffisamment tôt, ajoutez le stanza suivant vers 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 toute tentative d'installation par init /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 la 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 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 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 dépourvus 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 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 la 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 activé sur la mémoire de 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 sera légèrement différent de ce qui précède. Par exemple, si vous avez activé le chiffrement Adiantum, le troisième affichera 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 du 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 installe les métadonnées chiffrées /data, init exécute l'outil vdc. VDC se connecte à vold via binder pour configurer chiffré par métadonnées et d'installer la partition. Pendant toute la durée init est bloqué, et tente de lire ou de définir init propriétés seront bloquées jusqu'à la fin de mount_all. Si, à ce stade, une partie du travail de vold est directement ou bloquée 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 terminer la lecture de la des clés, interagir avec Keymaster et installer le répertoire de données sans interagir davantage avec init.

Si Keymaster n'est pas complètement démarré lors de l'exécution de mount_all, il ne répondre à vold tant qu'il n'a pas lu certaines propriétés depuis init, ce qui entraîne exactement l'interblocage décrit. Positionnement exec_start wait_for_keymaster au-dessus des valeurs mount_all comme défini permet de s'assurer que Keymaster est complètement en cours d'exécution à l'avance, ce qui permet d'éviter cet interblocage.

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 les clés stockage: un ancien basé sur dm-crypt et un nouveau basé sur le 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 équipés d'Android 11 ou version ultérieure, Le chiffrement des métadonnées sur un espace de stockage adoptable utilise le dm-default-key du noyau, comme pour la mémoire de 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 la mémoire de stockage interne de l'appareil peut être indisponible sur la mémoire de stockage adoptable. CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y peut être requis.

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. La peut être ignoré en définissant Propriété système ro.crypto.volume.metadata.encryption. Ce La valeur de la propriété a la même syntaxe que metadata_encryption fstab décrite ci-dessus. Par exemple, sur les appareils qui n'utilisent pas accélération, chiffrement Adiantum peuvent être activées en paramétrant 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 du 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 effectuer des personnalisations du noyau pour éviter le double et le chiffrement, notamment en implémentant Option allow_encrypt_override à laquelle Android sera transmise dm-crypt lorsque la propriété système ro.crypto.allow_encrypt_override est défini sur true. Ces personnalisations ne sont pas prises en charge par le noyau courant Android.

Par défaut, la méthode de chiffrement des métadonnées du volume dm-crypt utilise le Algorithme de chiffrement AES-128-CBC avec ESSIV et les secteurs de 512 octets de cryptographie. Ce en définissant les propriétés système suivantes (qui sont également utilisé pour FDE):

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