Cryptage des métadonnées

Android 7.0 et supporte plus le chiffrement basé sur des 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 crypter à la fois le contenu 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 cryptage des métadonnées. Avec le cryptage des métadonnées, une seule clé présente au démarrage crypte tout contenu qui n'est pas crypté par FBE. Cette clé est protégée par Keymaster, qui à son tour est protégé par un démarrage vérifié.

Le cryptage des métadonnées est toujours activé sur le stockage adoptables chaque fois 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 cryptage des métadonnées sur le stockage interne des nouveaux dispositifs en mettant en place les metadata système de fichiers, modifier la séquence d'initialisation, et permettant 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 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 cryptage des métadonnées exige que la dm-default-key le module est activé dans votre noyau. Dans Android 11 et plus, dm-default-key est pris en charge par les noyaux communs Android, version 4.14 et plus. Cette version de dm-default-key utilise un matériel et d'un cadre de cryptage fournisseur indépendant 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 utilisations inline matériel de chiffrement (matériel cryptant / déchiffre les données alors qu'il est sur le chemin vers / depuis le périphérique de stockage) lorsqu'ils sont disponibles. Si vous ne comptez pas utiliser le matériel de chiffrement en ligne, il est également nécessaire pour permettre une solution de repli à l'API de cryptographie du noyau:

CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y

Lorsqu'ils ne sont pas en utilisant du matériel de chiffrement en ligne , vous devez également activer une accélération à base de CPU disponible tel que recommandé dans la documentation de FBE .

Dans Android 10 et inférieure, dm-default-key n'a pas été pris en charge par le noyau commun Android. Il appartient donc aux fournisseurs de mettre en œuvre 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 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 à 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 assurer la /metadata point de montage 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 est monté. Pour veiller à ce qu'il commence assez tôt, ajoutez la section 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 les tentatives d'initialisation pour monter /data .

init.hardware.rc devrait déjà contenir une mount_all instruction qui monte /data lui - même dans la on late-fs strophe. Avant cette ligne, ajoutez la directive exec avec le wait_for_keymaster service:

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 la fstab entrée 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ée en définissant la metadata_encryption option également dans la colonne fs_mgr_flags:

  • Sur les appareils qui ne disposent pas d' accélération AES, le cryptage Adiantum peut être activé en réglant metadata_encryption=adiantum .
  • Sur les appareils qui supportent les clés enveloppées matériels , la clé de chiffrement des métadonnées peuvent être faites de réglage enveloppé du matériel par metadata_encryption=aes-256-xts:wrappedkey_v0 (ou équivalente metadata_encryption=:wrappedkey_v0 , comme aes-256-xts est l'algorithme par défaut).

Parce que l'interface noyau 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 lance avec Android 11 (niveau API 30), device.mk doivent contenir:

PRODUCT_SHIPPING_API_LEVEL := 30

Vous pouvez également définir la propriété système suivante pour forcer l'utilisation de la nouvelle dm-default-key API quel que soit le niveau de l' API 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 conscients des problèmes communs 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 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 les paramètres de redéfini chiffrement par défaut en définissant la metadata_encryption option du dispositif fstab , la sortie sera légèrement différent 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 vts_kernel_encryption_test pour vérifier l'exactitude du chiffrement des métadonnées et FBE:

atest vts_kernel_encryption_test

ou:

vts-tradefed run vts -m vts_kernel_encryption_test

Problèmes courants

Au cours de l'appel à mount_all , qui monte les métadonnées crypté /data partition, init exécute l'outil vdc. Les connecte à l' outil de vdc vold sur binder de mettre en place le dispositif crypté métadonnées et monter la partition. Pendant la durée de cet appel, init est bloqué, et les tentatives de lecture ou d' ensemble d' init propriétés bloquera jusqu'à ce que mount_all finitions. Si, à ce stade, une partie de vold travail » est directement ou indirectement bloqué à la lecture ou définition d' une propriété, blocage entraînera. Il est important de veiller à ce que vold peut compléter le travail de la lecture des clés, en interaction avec Keymaster et monter le répertoire de données sans interagir plus avec init .

Si Keymaster n'est pas complètement commencé quand mount_all court, il ne répondra pas à vold jusqu'à ce qu'il a lu certaines propriétés de init , ce qui entraîne exactement l'impasse décrit. Mise en place exec_start wait_for_keymaster au- dessus du correspondant mount_all invocation que définies garantit que Keymaster est entièrement opérationnel à l' avance et évite donc cette impasse.

Configuration sur stockage adoptable

Depuis Android 9, une forme de cryptage des métadonnées est toujours activé sur le stockage adoptables chaque fois FBE est activé, même lorsque le cryptage des métadonnées n'est pas activé sur le stockage interne.

En PSBA, il existe deux implémentations de chiffrement des métadonnées sur le stockage adoptable: un désapprouvée basé sur dm-crypt , et une plus récente basé sur dm-default-key . Pour veiller à ce que la mise en œuvre est sélectionné 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 lance avec Android 11 (niveau API 30), device.mk doivent 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 la politique FBE par défaut) quel que soit le niveau de l'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 de lancement avec Android 11 ou plus, le cryptage des métadonnées sur le stockage adoptable utilise la dm-default-key par dm-default-key module du noyau, tout comme sur le stockage interne. Voir les conditions ci - dessus pour lesquelles les options de configuration du noyau pour activer. Notez que le matériel de chiffrement en ligne qui fonctionne sur le stockage interne de l'appareil peuvent être indisponibles sur le stockage adoptables, et donc CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y peut être nécessaire.

Par défaut, la dm-default-key méthode de cryptage des métadonnées de volume utilise l'algorithme de chiffrement AES-256-XTS avec les secteurs de crypto 4096 octets. L'algorithme peut être remplacée en définissant la ro.crypto.volume.metadata.encryption propriété système. La valeur de cette propriété a la même syntaxe que l' metadata_encryption option fstab décrit ci - dessus. Par exemple, sur les appareils qui ne disposent pas d' accélération AES, le cryptage Adiantum peut être activé en réglant ro.crypto.volume.metadata.encryption=adiantum .

Méthode héritée

Sur les appareils de lancement avec Android 10 ou moins, le cryptage des métadonnées sur le stockage adoptable utilise le dm-crypt module noyau plutôt que de dm-default-key :

CONFIG_DM_CRYPT=y

Contrairement à la dm-default-key par dm-crypt dm-default-key méthode, la dm-crypt méthode provoque le contenu du fichier à chiffrer 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 vendeurs peuvent faire des personnalisations du noyau pour éviter la double cryptage, notamment en mettant en œuvre la allow_encrypt_override option que Android passera à dm-crypt lorsque la propriété du système ro.crypto.allow_encrypt_override est réglé sur true . Ces personnalisations ne sont pas prises en charge par le noyau commun Android.

Par défaut, le dm-crypt méthode de cryptage des métadonnées de volume utilise l'algorithme de chiffrement AES-128-CBC avec essiv et secteurs de crypto 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 cryptage des métadonnées. Les choix sont aes-128-cbc et adiantum . Adiantum peut être utilisée que si le dispositif ne dispose pas 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.