Google s'est engagé à promouvoir l'équité raciale pour les communautés noires. Regarde comment.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Chiffrement des métadonnées

Android 7.0 et supérieur prend en charge le cryptage 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 sont utilisées pour crypter à la fois le contenu des fichiers et les noms de fichiers. Lorsque FBE est utilisé, les 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 cryptage des métadonnées. Avec le cryptage des métadonnées, une seule clé présente au démarrage crypte tout contenu non crypté 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 cryptage des métadonnées peut également être activé sur le stockage interne.

Implémentation sur 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 de 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 cryptage des métadonnées ne peut être configuré que lors du premier formatage de la partition de données. En conséquence, cette fonctionnalité est uniquement pour les nouveaux appareils; ce n'est pas quelque chose qu'une OTA devrait changer.

Le chiffrement des métadonnées nécessite que le module dm-default-key soit activé dans votre noyau. Dans Android R et supérieur, dm-default-key est pris en charge par les noyaux communs Android, version 4.14 et supérieure. Cette version de dm-default-key utilise un framework de chiffrement matériel et 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 en ligne (matériel qui crypte / 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 cryptage en ligne, il est également nécessaire d'activer un retour à l'API de cryptographie 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 basée sur le processeur disponible, comme recommandé dans la documentation FBE .

Dans Android 10 et dm-default-key , 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 userdata 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 objets blob 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 à monter les /metadata , y compris le formattable drapeau pour assurer qu'il est formaté au moment du 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 /data montage de /data . 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 init 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 wait_for_keymaster 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 cryptage 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 à 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. 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 qui prennent en charge les clés à enveloppe matérielle qui sont directement provisionnées sur le matériel de chiffrement en ligne, la clé de chiffrement des métadonnées peut être enveloppée de manière matérielle en définissant metadata_encryption=aes-256-xts:wrappedkey_v0 . Consultez la documentation FBE pour plus d'informations sur les clés encapsulées de matériel et leurs prérequis.

Étant donné que l'interface du noyau à dm-default-key changé dans Android R, 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 est lancé avec Android R (niveau d'API 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 de l'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. Soyez également conscient des problèmes courants décrits ci-dessous.

Des 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

La sortie doit être similaire à:

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 remplacez les paramètres de chiffrement par défaut en définissant l'option metadata_encryption dans le fstab l'appareil, la sortie sera légèrement différente de ce qui précède. Par exemple, si vous avez activé le cryptage Adiantum , le troisième champ sera xchacha12,aes-adiantum-plain64 au lieu de aes-xts-plain64 .

Ensuite, exécutez VtsKernelEncryptionTest pour vérifier l'exactitude du chiffrement des métadonnées et FBE:

atest vts_kernel_encryption_test

ou:

vts-tradefed run vts -m VtsKernelEncryptionTest

Problèmes courants

Lors de l'appel à mount_all , qui monte la partition chiffrée /data métadonnées /data , 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 se bloquent jusqu'à mount_all que mount_all termine. Si, à ce stade, une partie quelconque du vold de vold est directement ou indirectement bloquée lors de la lecture ou de la définition d'une propriété, il en résultera un blocage. 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 depuis 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 cryptage des métadonnées est toujours activée sur le stockage adoptable chaque fois que FBE est activé, même lorsque le cryptage 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 l'implémentation 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 est lancé avec Android R (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 de la nouvelle méthode de chiffrement des métadonnées de volume (et de la nouvelle version de stratégie 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 R ou version ultérieure, 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 conditions préalables ci-dessus pour connaître les options de configuration du noyau à activer. Notez que le matériel de cryptage 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 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 provoque 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 cryptage réduit les performances et n'est pas nécessaire pour atteindre les objectifs de sécurité du cryptage des métadonnées, car Android garantit que les clés FBE sont au moins aussi difficiles à compromettre que la clé de cryptage des métadonnées. Les fournisseurs peuvent effectuer des personnalisations du noyau pour éviter le double cryptage, notamment en implémentant l'option allow_encrypt_override qu'Android transmettra à 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 cryptage des métadonnées de volume dm-crypt utilise l'algorithme de cryptage AES-128-CBC avec ESSIV et des secteurs cryptographiques 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 sont 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 de cryptage. Les choix sont 512, 1024, 2048 et 4096. Pour le chiffrement Adiantum, utilisez 4096.