Cryptage basé sur les fichiers

Android 7.0 et versions ultérieures prennent en charge le cryptage basé sur les fichiers (FBE). Le chiffrement basé sur les fichiers permet de chiffrer différents fichiers avec différentes clés pouvant être déverrouillées indépendamment.

Cet article décrit comment activer le chiffrement basé sur les fichiers sur les nouveaux appareils et comment les applications système peuvent utiliser les API Direct Boot pour offrir aux utilisateurs l'expérience la meilleure et la plus sécurisée possible.

Tous les appareils lancés avec Android 10 et versions ultérieures doivent utiliser le cryptage basé sur les fichiers.

Démarrage direct

Le chiffrement basé sur les fichiers active une nouvelle fonctionnalité introduite dans Android 7.0 appelée Direct Boot . Direct Boot permet aux appareils cryptés de démarrer directement sur l'écran de verrouillage. Auparavant, sur les appareils chiffrés utilisant le chiffrement complet du disque (FDE), les utilisateurs devaient fournir des informations d'identification avant de pouvoir accéder aux données, empêchant ainsi le téléphone d'effectuer toutes les opérations, sauf les plus élémentaires. Par exemple, les alarmes ne pouvaient pas fonctionner, les services d’accessibilité n’étaient pas disponibles et les téléphones ne pouvaient pas recevoir d’appels mais étaient limités aux seules opérations de base de numérotation d’urgence.

Avec l'introduction du chiffrement basé sur les fichiers (FBE) et de nouvelles API pour sensibiliser les applications au chiffrement, il est possible que ces applications fonctionnent dans un contexte limité. Cela peut se produire avant que les utilisateurs n’aient fourni leurs informations d’identification, tout en protégeant les informations privées des utilisateurs.

Sur un appareil compatible FBE, chaque utilisateur de l'appareil dispose de deux emplacements de stockage disponibles pour les applications :

  • Stockage Credential Encrypted (CE), qui est l'emplacement de stockage par défaut et disponible uniquement une fois que l'utilisateur a déverrouillé l'appareil.
  • Stockage Device Encrypted (DE), qui est un emplacement de stockage disponible à la fois pendant le mode Direct Boot et après que l'utilisateur a déverrouillé l'appareil.

Cette séparation rend les profils de travail plus sécurisés car elle permet de protéger plusieurs utilisateurs à la fois puisque le cryptage n'est plus basé uniquement sur un mot de passe au démarrage.

L'API Direct Boot permet aux applications compatibles avec le chiffrement d'accéder à chacune de ces zones. Des modifications ont été apportées au cycle de vie des applications pour répondre à la nécessité d'avertir les applications lorsque le stockage CE d'un utilisateur est déverrouillé en réponse à la première saisie des informations d'identification sur l'écran de verrouillage, ou dans le cas d'un profil professionnel offrant un défi professionnel . Les appareils exécutant Android 7.0 doivent prendre en charge ces nouvelles API et cycles de vie, qu'ils implémentent ou non FBE. Cependant, sans FBE, le stockage DE et CE sera toujours dans un état déverrouillé.

Une implémentation complète du chiffrement basé sur les fichiers sur les systèmes de fichiers Ext4 et F2FS est fournie dans le projet Android Open Source (AOSP) et ne doit être activée que sur les appareils qui répondent aux exigences. Les fabricants choisissant d'utiliser FBE souhaiteront peut-être explorer les moyens d'optimiser la fonctionnalité en fonction du système sur puce (SoC) utilisé.

Tous les packages nécessaires dans AOSP ont été mis à jour pour prendre en charge le démarrage direct. Cependant, lorsque les fabricants d'appareils utilisent des versions personnalisées de ces applications, ils voudront s'assurer au minimum qu'il existe des packages compatibles avec le démarrage direct fournissant les services suivants :

  • Services de téléphonie et numéroteur
  • Méthode de saisie pour saisir les mots de passe dans l'écran de verrouillage

Exemples et source

Android fournit une implémentation de référence du chiffrement basé sur les fichiers, dans laquelle vold ( system/vold ) fournit la fonctionnalité de gestion des périphériques de stockage et des volumes sur Android. L'ajout de FBE fournit à vold plusieurs nouvelles commandes pour prendre en charge la gestion des clés CE et DE de plusieurs utilisateurs. En plus des modifications fondamentales visant à utiliser les capacités de chiffrement basées sur les fichiers dans le noyau , de nombreux packages système, notamment le lockscreen et SystemUI, ont été modifiés pour prendre en charge les fonctionnalités FBE et Direct Boot. Ceux-ci inclus:

  • AOSP Dialer (paquets/applications/Dialer)
  • Horloge de bureau (packages/applications/DeskClock)
  • LatinIME (paquets/méthodes de saisie/LatinIME)*
  • Application Paramètres (packages/applications/Paramètres)*
  • SystemUI (frameworks/base/packages/SystemUI)*

* Applications système qui utilisent l'attribut manifeste defaultToDeviceProtectedStorage

D'autres exemples d'applications et de services prenant en charge le chiffrement peuvent être trouvés en exécutant la commande mangrep directBootAware dans le répertoire frameworks ou packages de l'arborescence source AOSP.

Dépendances

Pour utiliser l’implémentation AOSP de FBE en toute sécurité, un appareil doit répondre aux dépendances suivantes :

  • Prise en charge du noyau pour le cryptage Ext4 ou F2FS.
  • Prise en charge de Keymaster avec HAL version 1.0 ou supérieure. Il n'y a pas de support pour Keymaster 0.3 car il ne fournit pas les fonctionnalités nécessaires ni n'assure une protection suffisante pour les clés de chiffrement.
  • Keymaster/ Keystore et Gatekeeper doivent être implémentés dans un environnement d'exécution de confiance (TEE) pour assurer la protection des clés DE afin qu'un système d'exploitation non autorisé (système d'exploitation personnalisé flashé sur l'appareil) ne puisse pas simplement demander les clés DE.
  • La racine matérielle de confiance et le démarrage vérifié liés à l'initialisation du Keymaster sont requis pour garantir que les clés DE ne sont pas accessibles par un système d'exploitation non autorisé.

Mise en œuvre

Avant tout, les applications telles que les réveils, le téléphone et les fonctionnalités d'accessibilité doivent être créées sous Android : directBootAware conformément à la documentation du développeur Direct Boot .

Prise en charge du noyau

La prise en charge du noyau pour le chiffrement Ext4 et F2FS est disponible dans les noyaux communs Android, versions 3.18 et supérieures. Pour l'activer dans un noyau version 5.1 ou supérieure, utilisez :

CONFIG_FS_ENCRYPTION=y

Pour les noyaux plus anciens, utilisez CONFIG_EXT4_ENCRYPTION=y si le système de fichiers userdata de votre appareil est Ext4, ou utilisez CONFIG_F2FS_FS_ENCRYPTION=y si le système de fichiers userdata de votre appareil est F2FS.

Si votre appareil prend en charge le stockage adoptable ou utilise le chiffrement des métadonnées sur le stockage interne, activez également les options de configuration du noyau nécessaires au chiffrement des métadonnées, comme décrit dans la documentation sur le chiffrement des métadonnées .

En plus de la prise en charge fonctionnelle du chiffrement Ext4 ou F2FS, les fabricants d'appareils doivent également activer l'accélération cryptographique pour accélérer le chiffrement basé sur les fichiers et améliorer l'expérience utilisateur. Par exemple, sur les appareils basés sur ARM64, l'accélération ARMv8 CE (Cryptography Extensions) peut être activée en définissant les options de configuration du noyau suivantes :

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Pour améliorer encore les performances et réduire la consommation d'énergie, les fabricants d'appareils peuvent également envisager de mettre en œuvre un matériel de chiffrement en ligne , qui chiffre/déchiffre les données pendant leur transfert vers/depuis le périphérique de stockage. Les noyaux communs Android (versions 4.14 et supérieures) contiennent un cadre qui permet d'utiliser le chiffrement en ligne lorsque la prise en charge du matériel et des pilotes du fournisseur est disponible. Le cadre de chiffrement en ligne peut être activé en définissant les options de configuration du noyau suivantes :

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Si votre appareil utilise un stockage basé sur UFS, activez également :

CONFIG_SCSI_UFS_CRYPTO=y

Si votre appareil utilise un stockage basé sur eMMC, activez également :

CONFIG_MMC_CRYPTO=y

Activation du chiffrement basé sur les fichiers

L'activation de FBE sur un appareil nécessite son activation sur le stockage interne ( userdata ). Cela active également automatiquement FBE sur le stockage adoptable ; cependant, le format de cryptage sur le stockage adoptable peut être remplacé si nécessaire.

Stockage interne

FBE est activé en ajoutant l'option fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] à la colonne fs_mgr_flags de la ligne fstab pour userdata . Cette option définit le format de cryptage sur le stockage interne. Il contient jusqu'à trois paramètres séparés par deux points :

  • Le paramètre contents_encryption_mode définit quel algorithme cryptographique est utilisé pour chiffrer le contenu du fichier. Il peut s'agir de aes-256-xts ou adiantum . Depuis Android 11, il peut également être laissé vide pour spécifier l'algorithme par défaut, qui est aes-256-xts .
  • Le paramètre filenames_encryption_mode définit quel algorithme cryptographique est utilisé pour chiffrer les noms de fichiers. Il peut s'agir de aes-256-cts , aes-256-heh , adiantum ou aes-256-hctr2 . S'il n'est pas spécifié, la valeur par défaut est aes-256-cts si contents_encryption_mode est aes-256-xts , ou adiantum si contents_encryption_mode est adiantum .
  • Le paramètre flags , nouveau dans Android 11, est une liste de drapeaux séparés par le caractère + . Les indicateurs suivants sont pris en charge :
    • L'indicateur v1 sélectionne les politiques de chiffrement de la version 1 ; l'indicateur v2 sélectionne les politiques de chiffrement de la version 2. Les politiques de chiffrement de la version 2 utilisent une fonction de dérivation de clé plus sécurisée et plus flexible. La valeur par défaut est v2 si l'appareil est lancé sur Android 11 ou version ultérieure (comme déterminé par ro.product.first_api_level ), ou v1 si l'appareil est lancé sur Android 10 ou version ultérieure.
    • L'indicateur inlinecrypt_optimized sélectionne un format de chiffrement optimisé pour le matériel de chiffrement en ligne qui ne gère pas efficacement un grand nombre de clés. Pour ce faire, il dérive une seule clé de chiffrement du contenu du fichier par clé CE ou DE, plutôt qu'une par fichier. La génération des IV (vecteurs d'initialisation) est ajustée en conséquence.
    • L'indicateur emmc_optimized est similaire à inlinecrypt_optimized , mais il sélectionne également une méthode de génération IV qui limite les IV à 32 bits. Cet indicateur ne doit être utilisé que sur du matériel de chiffrement en ligne conforme à la spécification JEDEC eMMC v5.2 et ne prend donc en charge que les IV 32 bits. Sur un autre matériel de chiffrement en ligne, utilisez plutôt inlinecrypt_optimized . Cet indicateur ne doit jamais être utilisé sur le stockage basé sur UFS ; la spécification UFS permet l'utilisation de IV 64 bits.
    • Sur les appareils prenant en charge les clés encapsulées matériellement , l'indicateur wrappedkey_v0 permet l'utilisation de clés encapsulées matériellement pour FBE. Cela ne peut être utilisé qu'en combinaison avec l'option de montage inlinecrypt et l'indicateur inlinecrypt_optimized ou emmc_optimized .
    • L'indicateur dusize_4k force la taille de l'unité de données de chiffrement à 4 096 octets même lorsque la taille du bloc du système de fichiers n'est pas de 4 096 octets. La taille de l'unité de données de chiffrement correspond à la granularité du chiffrement du contenu du fichier. Ce flag est disponible depuis Android 15 (AOSP expérimental). Cet indicateur ne doit être utilisé que pour permettre l'utilisation d'un matériel de chiffrement en ligne qui ne prend pas en charge les unités de données supérieures à 4 096 octets, sur un périphérique qui utilise une taille de page supérieure à 4 096 octets et qui utilise le système de fichiers f2fs.

Si vous n'utilisez pas de matériel de chiffrement en ligne, le paramètre recommandé pour la plupart des appareils est fileencryption=aes-256-xts . Si vous utilisez du matériel de chiffrement en ligne, le paramètre recommandé pour la plupart des appareils est fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (ou de manière équivalente fileencryption=::inlinecrypt_optimized ). Sur les appareils sans aucune forme d'accélération AES, Adiantum peut être utilisé à la place d'AES en définissant fileencryption=adiantum .

Depuis Android 14, AES-HCTR2 est le mode préféré de cryptage des noms de fichiers pour les appareils dotés d’instructions de cryptographie accélérée. Cependant, seuls les noyaux Android les plus récents prennent en charge AES-HCTR2. Dans une future version d'Android, il est prévu de devenir le mode par défaut pour le cryptage des noms de fichiers. Si votre noyau prend en charge AES-HCTR2, il peut être activé pour le cryptage des noms de fichiers en définissant filenames_encryption_mode sur aes-256-hctr2 . Dans le cas le plus simple, cela se ferait avec fileencryption=aes-256-xts:aes-256-hctr2 .

Sur les appareils lancés avec Android 10 ou une version antérieure, fileencryption=ice est également accepté pour spécifier l'utilisation du mode de cryptage du contenu du fichier FSCRYPT_MODE_PRIVATE . Ce mode n'est pas implémenté par les noyaux communs d'Android, mais il pourrait être implémenté par les fournisseurs utilisant des correctifs de noyau personnalisés. Le format sur disque produit par ce mode était spécifique au fournisseur. Sur les appareils lancés avec Android 11 ou version ultérieure, ce mode n'est plus autorisé et un format de cryptage standard doit être utilisé à la place.

Par défaut, le chiffrement du contenu des fichiers est effectué à l'aide de l'API de cryptographie du noyau Linux. Si vous souhaitez plutôt utiliser du matériel de chiffrement en ligne, ajoutez également l'option de montage inlinecrypt . Par exemple, une ligne fstab complète pourrait ressembler à :

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

Stockage adoptable

Depuis Android 9, FBE et le stockage adoptable peuvent être utilisés ensemble.

La spécification de l'option fstab fileencryption pour userdata active également automatiquement le chiffrement FBE et les métadonnées sur le stockage adoptable. Cependant, vous pouvez remplacer les formats de chiffrement FBE et/ou des métadonnées sur le stockage adoptable en définissant les propriétés dans PRODUCT_PROPERTY_OVERRIDES .

Sur les appareils lancés avec Android 11 ou version ultérieure, utilisez les propriétés suivantes :

  • ro.crypto.volume.options (nouveau dans Android 11) sélectionne le format de cryptage FBE sur le stockage adoptable. Il a la même syntaxe que l'argument de l'option fstab fileencryption et utilise les mêmes valeurs par défaut. Consultez les recommandations pour fileencryption ci-dessus pour savoir quoi utiliser ici.
  • ro.crypto.volume.metadata.encryption sélectionne le format de cryptage des métadonnées sur le stockage adoptable. Consultez la documentation sur le chiffrement des métadonnées .

Sur les appareils lancés avec Android 10 ou une version antérieure, utilisez les propriétés suivantes :

  • ro.crypto.volume.contents_mode sélectionne le mode de cryptage du contenu. Ceci équivaut au premier champ séparé par deux-points de ro.crypto.volume.options .
  • ro.crypto.volume.filenames_mode sélectionne le mode de cryptage des noms de fichiers. Cela équivaut au deuxième champ séparé par deux points de ro.crypto.volume.options , sauf que la valeur par défaut sur les appareils lancés avec Android 10 ou une version antérieure est aes-256-heh . Sur la plupart des appareils, cela doit être explicitement remplacé par aes-256-cts .
  • ro.crypto.fde_algorithm et ro.crypto.fde_sector_size sélectionnent le format de cryptage des métadonnées sur le stockage adoptable. Consultez la documentation sur le chiffrement des métadonnées .

Intégration avec Keymaster

Le Keymaster HAL doit être démarré dans le cadre de la classe early_hal . En effet, FBE exige que Keymaster soit prêt à gérer les demandes lors de la phase de démarrage post-fs-data , c'est-à-dire lorsque vold configure les clés initiales.

Hors répertoires

init applique la clé DE du système à tous les répertoires de niveau supérieur de /data , à l'exception des répertoires qui doivent être non chiffrés, tels que le répertoire qui contient la clé DE du système elle-même et les répertoires qui contiennent les répertoires utilisateur CE ou DE. Les clés de chiffrement s'appliquent de manière récursive et ne peuvent pas être remplacées par des sous-répertoires.

Sous Android 11 et versions ultérieures, la clé init applique aux répertoires peut être contrôlée par l'argument encryption=<action> de la commande mkdir dans les scripts d'initialisation. Les valeurs possibles de <action> sont documentées dans le README pour le langage d'initialisation Android .

Dans Android 10, les actions de chiffrement init étaient codées en dur à l'emplacement suivant :

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Sous Android 9 et versions antérieures, l'emplacement était :

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Il est possible d'ajouter des exceptions pour empêcher que certains répertoires soient chiffrés. Si des modifications de ce type sont apportées, le fabricant du périphérique doit inclure des politiques SELinux qui accordent uniquement l'accès aux applications qui doivent utiliser le répertoire non chiffré. Cela devrait exclure toutes les applications non fiables.

Le seul cas d’utilisation acceptable connu concerne la prise en charge des fonctionnalités OTA héritées.

Prise en charge du démarrage direct dans les applications système

Rendre les applications conscientes du démarrage direct

Pour faciliter la migration rapide des applications système, deux nouveaux attributs peuvent être définis au niveau de l'application. L'attribut defaultToDeviceProtectedStorage est disponible uniquement pour les applications système. L'attribut directBootAware est accessible à tous.

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

L'attribut directBootAware au niveau de l'application est un raccourci permettant de marquer tous les composants de l'application comme étant compatibles avec le chiffrement.

L'attribut defaultToDeviceProtectedStorage redirige l'emplacement de stockage de l'application par défaut pour pointer vers le stockage DE au lieu de pointer vers le stockage CE. Les applications système utilisant cet indicateur doivent auditer soigneusement toutes les données stockées dans l'emplacement par défaut et modifier les chemins des données sensibles pour utiliser le stockage CE. Les fabricants d'appareils utilisant cette option doivent inspecter soigneusement les données qu'ils stockent pour s'assurer qu'elles ne contiennent aucune information personnelle.

Lors de l'exécution dans ce mode, les API système suivantes sont disponibles pour gérer explicitement un contexte soutenu par le stockage CE en cas de besoin, qui sont équivalentes à leurs homologues Device Protected.

  • Context.createCredentialProtectedStorageContext()
  • Context.isCredentialProtectedStorage()

Prise en charge de plusieurs utilisateurs

Chaque utilisateur dans un environnement multi-utilisateur reçoit une clé de chiffrement distincte. Chaque utilisateur reçoit deux clés : une clé DE et une clé CE. L'utilisateur 0 doit d'abord se connecter à l'appareil car il s'agit d'un utilisateur spécial. Ceci est pertinent pour les utilisations d’administration de périphériques .

Les applications compatibles avec la cryptographie interagissent de cette manière entre les utilisateurs : INTERACT_ACROSS_USERS et INTERACT_ACROSS_USERS_FULL permettent à une application d'agir sur tous les utilisateurs de l'appareil. Cependant, ces applications ne pourront accéder qu'aux répertoires cryptés CE pour les utilisateurs déjà déverrouillés.

Une application peut interagir librement dans les zones DE, mais un utilisateur déverrouillé ne signifie pas que tous les utilisateurs de l'appareil sont déverrouillés. L'application doit vérifier cet état avant d'essayer d'accéder à ces zones.

Chaque ID utilisateur de profil professionnel reçoit également deux clés : DE et CE. Lorsque le défi de travail est relevé, l'utilisateur du profil est déverrouillé et le Keymaster (dans TEE) peut fournir la clé TEE du profil.

Gestion des mises à jour

La partition de récupération ne peut pas accéder au stockage protégé par DE sur la partition de données utilisateur. Il est fortement recommandé aux appareils implémentant FBE de prendre en charge l'OTA à l'aide des mises à jour du système A/B . Comme l'OTA peut être appliqué pendant le fonctionnement normal, aucune récupération n'est nécessaire pour accéder aux données sur le lecteur crypté.

Lors de l'utilisation d'une solution OTA existante, qui nécessite une récupération pour accéder au fichier OTA sur la partition userdata :

  1. Créez un répertoire de niveau supérieur (par exemple misc_ne ) dans la partition userdata .
  2. Configurez ce répertoire de niveau supérieur pour qu'il soit non chiffré (voir Exclusion de répertoires ).
  3. Créez un répertoire dans le répertoire de niveau supérieur pour contenir les packages OTA.
  4. Ajoutez une règle SELinux et des contextes de fichiers pour contrôler l'accès à ce répertoire et à son contenu. Seuls les processus ou les applications recevant les mises à jour OTA doivent pouvoir lire et écrire dans ce répertoire. Aucune autre application ou processus ne doit avoir accès à ce répertoire.

Validation

Pour vous assurer que la version implémentée de la fonctionnalité fonctionne comme prévu, exécutez d'abord les nombreux tests de chiffrement CTS, tels que DirectBootHostTest et EncryptionTest .

Si l'appareil exécute Android 11 ou une version ultérieure, exécutez également vts_kernel_encryption_test :

atest vts_kernel_encryption_test

ou:

vts-tradefed run vts -m vts_kernel_encryption_test

De plus, les fabricants d'appareils peuvent effectuer les tests manuels suivants. Sur un appareil avec FBE activé :

  • Vérifiez que ro.crypto.state existe
    • Assurez-vous que ro.crypto.state est crypté
  • Vérifiez que ro.crypto.type existe
    • Assurez-vous que ro.crypto.type est défini sur file

De plus, les testeurs peuvent vérifier que le stockage CE est verrouillé avant que l'appareil ne soit déverrouillé pour la première fois depuis le démarrage. Pour ce faire, utilisez une version userdebug ou eng , définissez un code PIN, un modèle ou un mot de passe sur l'utilisateur principal et redémarrez l'appareil. Avant de déverrouiller l'appareil, exécutez la commande suivante pour vérifier le stockage CE de l'utilisateur principal. Si l'appareil utilise le mode utilisateur du système sans tête (la plupart des appareils automobiles), l'utilisateur principal est l'utilisateur 10, alors exécutez :

adb root; adb shell ls /data/user/10

Sur les autres appareils (la plupart des appareils non automobiles), l'utilisateur principal est l'utilisateur 0, alors exécutez :

adb root; adb shell ls /data/user/0

Vérifiez que les noms de fichiers répertoriés sont codés en Base64, ce qui indique que les noms de fichiers sont cryptés et que la clé pour les déchiffrer n'est pas encore disponible. Si les noms de fichiers sont répertoriés en texte brut, quelque chose ne va pas.

Les fabricants d'appareils sont également encouragés à envisager d'exécuter les tests Linux en amont pour fscrypt sur leurs appareils ou noyaux. Ces tests font partie de la suite de tests du système de fichiers xfstests. Cependant, ces tests en amont ne sont pas officiellement pris en charge par Android.

Détails de mise en œuvre de l'AOSP

Cette section fournit des détails sur la mise en œuvre de l'AOSP et décrit le fonctionnement du chiffrement basé sur les fichiers. Il ne devrait pas être nécessaire pour les fabricants d'appareils d'apporter des modifications ici pour utiliser FBE et Direct Boot sur leurs appareils.

cryptage fscrypt

L'implémentation AOSP utilise le cryptage « fscrypt » (pris en charge par ext4 et f2fs) dans le noyau et est normalement configurée pour :

  • Crypter le contenu du fichier avec AES-256 en mode XTS
  • Crypter les noms de fichiers avec AES-256 en mode CBC-CTS

Le cryptage Adiantum est également pris en charge. Lorsque le cryptage Adiantum est activé, le contenu et les noms de fichiers sont cryptés avec Adiantum.

fscrypt prend en charge deux versions de politiques de chiffrement : la version 1 et la version 2. La version 1 est obsolète et les exigences CDD pour les appareils lancés avec Android 11 et versions ultérieures ne sont compatibles qu'avec la version 2. Les politiques de chiffrement de la version 2 utilisent HKDF-SHA512 pour dériver le chiffrement réel. clés de chiffrement à partir des clés fournies par l'espace utilisateur.

Pour plus d'informations sur fscrypt, consultez la documentation du noyau en amont .

Cours de stockage

Le tableau suivant répertorie plus en détail les clés FBE et les répertoires qu'elles protègent :

Classe de stockage Description Annuaires
Non crypté Répertoires dans /data qui ne peuvent pas ou n'ont pas besoin d'être protégés par FBE. Sur les appareils qui utilisent le chiffrement des métadonnées , ces répertoires ne sont pas véritablement non chiffrés mais sont plutôt protégés par la clé de chiffrement des métadonnées qui est équivalente au Système DE.
  • /data/apex , à l'exclusion /data/apex/decompressed et /data/apex/ota_reserved qui sont du système DE
  • /data/lost+found
  • /data/preloads
  • /data/unencrypted
  • Tous les répertoires dont les sous-répertoires utilisent des clés FBE différentes. Par exemple, puisque chaque répertoire /data/user/${user_id} utilise une clé par utilisateur, /data/user n'utilise aucune clé lui-même.
Système DE Données cryptées sur l'appareil non liées à un utilisateur particulier
  • /data/apex/decompressed
  • /data/apex/ota_reserved
  • /data/app
  • /data/misc
  • /data/system
  • /data/vendor
  • Tous les autres sous-répertoires de /data que ce tableau ne mentionne pas comme ayant une classe différente
Par démarrage Fichiers système éphémères qui n'ont pas besoin de survivre à un redémarrage /data/per_boot
Utilisateur CE (interne) Données cryptées par identifiant par utilisateur sur le stockage interne
  • /data/data (alias de /data/user/0 )
  • /data/media/${user_id}
  • /data/misc_ce/${user_id}
  • /data/system_ce/${user_id}
  • /data/user/${user_id}
  • /data/vendor_ce/${user_id}
Utilisateur DE (interne) Données cryptées par appareil par utilisateur sur le stockage interne
  • /data/misc_de/${user_id}
  • /data/system_de/${user_id}
  • /data/user_de/${user_id}
  • /data/vendor_de/${user_id}
Utilisateur CE (adoptable) Données cryptées par identifiant par utilisateur sur un stockage adoptable
  • /mnt/expand/${volume_uuid}/media/${user_id}
  • /mnt/expand/${volume_uuid}/misc_ce/${user_id}
  • /mnt/expand/${volume_uuid}/user/${user_id}
Utilisateur DE (adoptable) Données cryptées par appareil par utilisateur sur un stockage adoptable
  • /mnt/expand/${volume_uuid}/misc_de/${user_id}
  • /mnt/expand/${volume_uuid}/user_de/${user_id}

Rangement et protection des clés

Toutes les clés FBE sont gérées par vold et sont stockées cryptées sur le disque, à l'exception de la clé par démarrage qui n'est pas du tout stockée. Le tableau suivant répertorie les emplacements dans lesquels les différentes clés FBE sont stockées :

Type de clé Emplacement clé Classe de stockage de l'emplacement clé
Clé système DE /data/unencrypted Non crypté
Clés utilisateur CE (internes) /data/misc/vold/user_keys/ce/${user_id} Système DE
Clés utilisateur DE (internes) /data/misc/vold/user_keys/de/${user_id} Système DE
Clés CE utilisateur (adoptables) /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} Utilisateur CE (interne)
Clés utilisateur DE (adoptables) /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} Utilisateur DE (interne)

Comme le montre le tableau précédent, la plupart des clés FBE sont stockées dans des répertoires chiffrés par une autre clé FBE. Les clés ne peuvent pas être déverrouillées tant que la classe de stockage qui les contient n'a pas été déverrouillée.

vold applique également une couche de cryptage à toutes les clés FBE. Chaque clé, à l'exception des clés CE pour le stockage interne, est chiffrée avec AES-256-GCM à l'aide de sa propre clé Keystore qui n'est pas exposée en dehors du TEE. Cela garantit que les clés FBE ne peuvent pas être déverrouillées à moins qu'un système d'exploitation de confiance n'ait démarré, comme l'exige Verified Boot . La résistance au rollback est également demandée sur la clé Keystore, ce qui permet de supprimer en toute sécurité les clés FBE sur les appareils sur lesquels Keymaster prend en charge la résistance au rollback. En guise de solution de secours lorsque la résistance à l'annulation n'est pas disponible, le hachage SHA-512 de 16 384 octets aléatoires stocké dans le fichier secdiscardable stocké à côté de la clé est utilisé comme balise d'identification d'application de la clé Keystore. Tous ces octets doivent être récupérés pour récupérer une clé FBE.

Les clés CE pour le stockage interne bénéficient d'un niveau de protection plus élevé qui garantit qu'elles ne peuvent pas être déverrouillées sans connaître le facteur de connaissance de l'écran de verrouillage (LSKF) de l'utilisateur (PIN, modèle ou mot de passe), un jeton de réinitialisation de code sécurisé ou les deux côté client. et des clés côté serveur pour une opération de reprise au redémarrage . Les jetons de réinitialisation du code d'accès ne peuvent être créés que pour les profils professionnels et les appareils entièrement gérés .

Pour y parvenir, vold crypte chaque clé CE pour le stockage interne à l'aide d'une clé AES-256-GCM dérivée du mot de passe synthétique de l'utilisateur. Le mot de passe synthétique est un secret cryptographique immuable à haute entropie généré aléatoirement pour chaque utilisateur. LockSettingsService dans system_server gère le mot de passe synthétique et la manière dont il est protégé.

Pour protéger le mot de passe synthétique avec le LSKF, LockSettingsService étend d'abord le LSKF en le passant via scrypt , en ciblant un temps d'environ 25 ms et une utilisation de la mémoire d'environ 2 Mo. Étant donné que les LSKF sont généralement courts, cette étape n'offre généralement pas beaucoup de sécurité. La principale couche de sécurité est la limitation de débit appliquée par Secure Element (SE) ou TEE décrite ci-dessous.

Si l'appareil dispose d'un élément sécurisé (SE), LockSettingsService mappe le LSKF étendu à un secret aléatoire à haute entropie stocké dans le SE à l'aide du Weaver HAL . LockSettingsService crypte ensuite le mot de passe synthétique deux fois : d'abord avec une clé logicielle dérivée du LSKF étendu et du secret Weaver, et ensuite avec une clé Keystore non liée à l'authentification. Cela fournit une limitation de débit appliquée par SE pour les suppositions LSKF.

Si l'appareil ne dispose pas de SE, LockSettingsService utilise à la place le LSKF étendu comme mot de passe Gatekeeper . LockSettingsService crypte ensuite le mot de passe synthétique deux fois : d'abord avec une clé logicielle dérivée du LSKF étendu et du hachage d'un fichier secondaire, et ensuite avec une clé Keystore qui est authentifiée par l'inscription du Gatekeeper. Cela fournit une limitation de débit appliquée par TEE pour les suppositions LSKF.

Lorsque le LSKF est modifié, LockSettingsService supprime toutes les informations associées à la liaison du mot de passe synthétique à l'ancien LSKF. Sur les appareils prenant en charge les clés Keystore Weaver ou résistantes à la restauration, cela garantit la suppression sécurisée de l’ancienne liaison. Pour cette raison, les protections décrites ici sont appliquées même lorsque l'utilisateur ne dispose pas de LSKF.