Chiffrement basé sur les fichiers

Android 7.0 et versions ultérieures sont compatibles avec le chiffrement basé sur les fichiers (FBE). Le chiffrement basé sur les fichiers permet de chiffrer différents fichiers avec des clés différentes qui peuvent être déverrouillées indépendamment.

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

Tous les appareils lancés avec Android 10 ou version ultérieure doivent utiliser le chiffrement basé sur les fichiers.

Démarrage direct

Le chiffrement basé sur les fichiers permet d'utiliser une nouvelle fonctionnalité introduite dans Android 7.0, appelée Démarrage direct. Le démarrage direct permet aux appareils chiffrés de démarrer directement sur l'écran de verrouillage. Auparavant, sur les appareils chiffrés à l'aide du chiffrement de disque (FDE), les utilisateurs devaient fournir des identifiants avant de pouvoir accéder aux données, ce qui empêchait le téléphone d'effectuer toutes les opérations, à l'exception des plus basiques. Par exemple, les alarmes ne fonctionnaient pas, les services d'accessibilité n'étaient pas disponibles et les téléphones ne pouvaient pas recevoir d'appels, mais étaient limités aux opérations de base du clavier d'urgence.

Avec l'introduction du chiffrement basé sur les fichiers (FBE) et de nouvelles API permettant aux applications de prendre conscience du chiffrement, il est possible pour ces applications de fonctionner dans un contexte limité. Cela peut se produire avant que les utilisateurs n'aient fourni leurs identifiants, tout en protégeant les informations utilisateur privées.

Sur un appareil compatible avec le chiffrement basé sur les fichiers, chaque utilisateur dispose de deux emplacements de stockage pour les applications :

• Stockage chiffré par identifiants (CE), l'emplacement de stockage par défaut qui n'est disponible qu'une fois l'appareil déverrouillé par l'utilisateur.
• Le stockage chiffré de l'appareil (DE), un emplacement de stockage disponible en mode Démarrage direct et après le déverrouillage de l'appareil par l'utilisateur

Cette séparation renforce la sécurité des profils professionnels, car elle permet de protéger plusieurs utilisateurs à la fois, le chiffrement n'étant plus basé uniquement sur un mot de passe de démarrage.

L'API Direct Boot permet aux applications compatibles avec le chiffrement d'accéder à chacune de ces zones. Le cycle de vie de l'application a été modifié pour répondre à la nécessité d'informer les applications lorsque l'espace de stockage CE d'un utilisateur est déverrouillé en réponse à la première saisie d'identifiants sur l'écran de verrouillage, ou dans le cas d'un profil professionnel fournissant un défi professionnel. Les appareils équipés d'Android 7.0 doivent être compatibles avec ces nouvelles API et ces nouveaux cycles de vie, qu'ils implémentent ou non FBE. Cependant, sans FBE, les espaces de stockage DE et CE sont toujours déverrouillés.

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). Elle ne doit être activée que sur les appareils qui répondent aux exigences. Les fabricants qui choisissent d'utiliser le chiffrement basé sur les fichiers peuvent explorer des moyens d'optimiser la fonctionnalité en fonction du système sur une puce (SoC) utilisé.

Tous les packages nécessaires de l'AOSP ont été mis à jour pour être compatibles avec le démarrage direct. Toutefois, lorsque les fabricants d'appareils utilisent des versions personnalisées de ces applications, ils souhaitent s'assurer qu'il existe au minimum des packages compatibles avec le démarrage direct qui fournissent les services suivants :

• Services de téléphonie et clavier téléphonique
• Méthode de saisie des mots de passe sur l'écran de verrouillage

Exemples et source

Android fournit une implémentation de référence du chiffrement basé sur des fichiers, dans laquelle vold (system/vold) fournit la fonctionnalité de gestion des périphériques et volumes de stockage sur Android. L'ajout du 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 principales apportées pour utiliser les fonctionnalités de chiffrement basé sur les fichiers dans le noyau, de nombreux packages système, y compris l'écran de verrouillage et l'UI du système, ont été modifiés pour prendre en charge les fonctionnalités de chiffrement basé sur les fichiers et de démarrage direct. Exemples :

• Composeur AOSP (packages/apps/Dialer)
• Horloge de bureau (packages/apps/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• Application Paramètres (packages/apps/Settings)*
• SystemUI (frameworks/base/packages/SystemUI)*

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

Pour obtenir d'autres exemples d'applications et de services compatibles avec le chiffrement, exécutez la commande mangrep directBootAware dans le répertoire des frameworks ou des packages de l'arborescence source d'AOSP.

Dépendances

Pour utiliser l'implémentation AOSP de FBE de manière sécurisée, un appareil doit répondre aux dépendances suivantes :

• Compatibilité du noyau avec le chiffrement Ext4 ou F2FS.
• Compatibilité avec KeyMint (ou Keymaster 1.0 ou version ultérieure). Keymaster 0.3 n'est pas compatible, car il ne fournit pas les fonctionnalités nécessaires ni n'assure une protection suffisante des clés de chiffrement.
• KeyMint/Keymaster et Gatekeeper doivent être implémentés dans un environnement d'exécution sécurisé (TEE) pour protéger les clés DE, de sorte qu'un OS non autorisé (OS personnalisé installé sur l'appareil) ne puisse pas simplement demander les clés DE.
• La racine de confiance matérielle et le démarrage validé liés à l'initialisation de KeyMint sont requis pour s'assurer que les clés DE ne sont pas accessibles par un système d'exploitation non autorisé.

Implémentation

Tout d'abord, les applications telles que les réveils, le téléphone et les fonctionnalités d'accessibilité doivent être définies sur android:directBootAware conformément à la documentation pour les développeurs sur le démarrage direct.

Compatibilité du kernel

La compatibilité du noyau avec le chiffrement Ext4 et F2FS est disponible dans les noyaux Android courants, version 3.18 et ultérieures. Pour l'activer dans un noyau de version 5.1 ou ultérieure, utilisez :

CONFIG_FS_ENCRYPTION=y

Pour les anciens noyaux, 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 est compatible avec le stockage adoptable ou utilise le chiffrement des métadonnées sur la mémoire de 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 compatibilité fonctionnelle avec le 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 d'implémenter un matériel de chiffrement intégré, qui chiffre/déchiffre les données lorsqu'elles sont en transit vers/depuis le périphérique de stockage. Les noyaux communs Android (version 4.14 et ultérieures) contiennent un framework qui permet d'utiliser le chiffrement en ligne lorsque la prise en charge du matériel et du pilote du fournisseur est disponible. Le framework de chiffrement intégré 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 les éléments suivants :

CONFIG_SCSI_UFS_CRYPTO=y

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

CONFIG_MMC_CRYPTO=y

Activer le chiffrement basé sur les fichiers

Pour activer FBE sur un appareil, vous devez l'activer sur le stockage interne (userdata). Cela active également FBE sur le stockage adoptable. Toutefois, le format de chiffrement sur le stockage adoptable peut être remplacé si nécessaire.

Mémoire de stockage interne

Pour activer FBE, ajoutez 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 chiffrement sur le stockage interne. Il contient jusqu'à trois paramètres séparés par un deux-points :

• Le paramètre contents_encryption_mode définit l'algorithme cryptographique utilisé pour chiffrer le contenu du fichier. Il peut s'agir de aes-256-xts ou de 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 l'algorithme cryptographique utilisé pour chiffrer les noms de fichiers. Il peut s'agir de aes-256-cts, aes-256-heh, adiantum ou aes-256-hctr2. Si aucune valeur n'est spécifiée, 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 d'options séparées par le caractère +. Les options suivantes sont acceptées :
  • L'indicateur v1 sélectionne les règles de chiffrement de version 1, tandis que l'indicateur v2 sélectionne les règles de chiffrement de version 2. Les règles de chiffrement de la version 2 utilisent une fonction de dérivation de clé plus sécurisée et flexible. La valeur par défaut est v2 si l'appareil a été lancé sous Android 11 ou version ultérieure (comme déterminé par ro.product.first_api_level), ou v1 si l'appareil a été lancé sous Android 10 ou version antérieure.
  • L'option inlinecrypt_optimized sélectionne un format de chiffrement optimisé pour le matériel de chiffrement intégré qui ne gère pas efficacement un grand nombre de clés. Pour ce faire, il ne dérive qu'une seule clé de chiffrement du contenu des fichiers par clé CE ou DE, au lieu d'une par fichier. La génération des IV (vecteurs d'initialisation) est ajustée en conséquence.
  • Le flag emmc_optimized est semblable à inlinecrypt_optimized, mais il sélectionne également une méthode de génération d'IV qui limite les IV à 32 bits. Cette option ne doit être utilisée que sur le matériel de chiffrement intégré conforme à la spécification JEDEC eMMC v5.2 et qui n'est donc compatible qu'avec les IV 32 bits. Sur d'autres matériels de chiffrement intégré, utilisez plutôt inlinecrypt_optimized. Cette option ne doit jamais être utilisée sur un stockage UFS. La spécification UFS permet d'utiliser des IV de 64 bits.
  • Sur les appareils compatibles avec les clés de chiffrement en ligne encapsulées dans le matériel, les clés FBE peuvent être encapsulées dans le matériel en ajoutant l'indicateur wrappedkey ou wrappedkey_v0. wrappedkey est la version moderne. wrappedkey_v0 ne doit être utilisé que sur les appareils qui ne sont pas compatibles avec wrappedkey ou qui ont déjà été lancés avec wrappedkey_v0. Pour en savoir plus, consultez Activer les clés encapsulées.
  • L'indicateur dusize_4k force la taille de l'unité de données de chiffrement à 4 096 octets, même lorsque la taille de 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 précision du chiffrement du contenu du fichier. Cet indicateur est disponible depuis Android 15. Ce flag ne doit être utilisé que pour activer l'utilisation du matériel de chiffrement intégré qui ne prend pas en charge les unités de données de plus de 4 096 octets, sur un appareil 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 intégré, le paramètre recommandé pour la plupart des appareils est fileencryption=aes-256-xts. Si vous utilisez du matériel de chiffrement intégré, le paramètre recommandé pour la plupart des appareils est fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (ou 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 de chiffrement des noms de fichiers privilégié pour les appareils dotés d'instructions de chiffrement accéléré. Toutefois, seuls les noyaux Android plus récents sont compatibles avec AES-HCTR2. Dans une prochaine version d'Android, il est prévu qu'il devienne le mode par défaut pour le chiffrement des noms de fichiers. Si votre noyau est compatible avec AES-HCTR2, vous pouvez l'activer pour le chiffrement 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 version antérieure, fileencryption=ice est également accepté pour spécifier l'utilisation du mode de chiffrement du contenu des fichiers FSCRYPT_MODE_PRIVATE. Ce mode n'est pas implémenté par les noyaux communs Android, mais il pourrait l'être par les fournisseurs à l'aide de 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 chiffrement standard doit être utilisé à la place.

Par défaut, le chiffrement du contenu des fichiers est effectué à l'aide de l'API de chiffrement du noyau Linux. Si vous souhaitez utiliser du matériel de chiffrement intégré, ajoutez également l'option d'installation inlinecrypt. Par exemple, une ligne fstab complète peut se présenter comme suit :

/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, le FBE et le stockage adaptable peuvent être utilisés ensemble.

La spécification de l'option fstab fileencryption pour userdata active également automatiquement le chiffrement FBE et le chiffrement des métadonnées sur le stockage adoptable. Toutefois, vous pouvez remplacer les formats de chiffrement FBE ou de métadonnées sur le stockage adoptable en définissant des 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 chiffrement FBE sur le stockage adoptable. Il utilise la même syntaxe que l'argument de l'option fstab fileencryption et 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 chiffrement 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 chiffrement du contenu. Cela équivaut au premier champ séparé par un deux-points de ro.crypto.volume.options.
• ro.crypto.volume.filenames_mode sélectionne le mode de chiffrement des noms de fichiers. Cela équivaut au deuxième champ séparé par un deux-points de ro.crypto.volume.options, sauf que la valeur par défaut sur les appareils lancés avec Android 10 ou version antérieure est aes-256-heh. Sur la plupart des appareils, cette valeur doit être explicitement remplacée par aes-256-cts.
• ro.crypto.fde_algorithm et ro.crypto.fde_sector_size sélectionnent le format de chiffrement des métadonnées sur le stockage adoptable. Consultez la documentation sur le chiffrement des métadonnées.

Intégrer à KeyMint

Le HAL KeyMint doit être démarré dans le cadre de la classe early_hal. En effet, FBE exige que KeyMint soit prêt à gérer les requêtes lors de la phase de démarrage post-fs-data, qui est le moment où vold configure les clés initiales.

Exclure des répertoires

init applique la clé DE du système à tous les répertoires de premier niveau de /data, à l'exception des répertoires qui ne doivent pas être chiffrés, tels que le répertoire contenant la clé DE du système elle-même et les répertoires contenant les répertoires CE ou DE de l'utilisateur. 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é que 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 fichier 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

Dans Android 9 et versions antérieures, l'emplacement était le suivant :

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Il est possible d'ajouter des exceptions pour empêcher le chiffrement de certains répertoires. Si de telles modifications sont apportées, le fabricant de l'appareil doit inclure des règles SELinux qui n'accordent l'accès qu'aux applications devant utiliser le répertoire non chiffré. Cela devrait exclure toutes les applications non fiables.

Le seul cas d'utilisation acceptable connu pour cela est en faveur des anciennes fonctionnalités OTA.

Prendre en charge le démarrage direct dans les applications système

Rendre les applications compatibles avec le 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 n'est disponible que pour les applications système. L'attribut directBootAware est disponible pour tous.

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

L'attribut directBootAware au niveau de l'application permet 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 vers le stockage DE au lieu du stockage CE. Les applications système utilisant cet indicateur doivent examiner attentivement toutes les données stockées à l'emplacement par défaut et modifier les chemins d'accès aux données sensibles pour utiliser le stockage CE. Les fabricants d'appareils qui utilisent cette option doivent examiner attentivement 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 si nécessaire. Elles sont équivalentes à leurs équivalents protégés par l'appareil.

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

Prendre en charge plusieurs utilisateurs

Chaque utilisateur d'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. Cela concerne les utilisations de l'administration des appareils.

Les applications compatibles avec le chiffrement interagissent entre les utilisateurs de la manière suivante : INTERACT_ACROSS_USERS et INTERACT_ACROSS_USERS_FULL permettent à une application d'agir sur tous les utilisateurs de l'appareil. Toutefois, ces applications ne peuvent accéder qu'aux répertoires chiffrés par identifiants (CE) des utilisateurs qui sont déjà déverrouillés.

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

Chaque ID utilisateur du profil professionnel reçoit également deux clés : DE et CE. Lorsque le test d'authentification professionnel est réussi, l'utilisateur du profil est déverrouillé et KeyMint (dans l'environnement d'exécution sécurisé) peut fournir la clé de l'environnement d'exécution sécurisé du profil.

Gérer les mises à jour

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

Lorsque vous utilisez une ancienne solution OTA, qui nécessite une récupération pour accéder au fichier OTA sur la partition userdata :

1. Créez un répertoire de premier niveau (par exemple, misc_ne) dans la partition userdata.
2. Configurez ce répertoire de premier niveau pour qu'il ne soit pas chiffré (voir Exclure des répertoires).
3. Créez un répertoire dans le répertoire racine pour stocker les packages OTA.
4. Ajoutez une règle SELinux et des contextes de fichier pour contrôler l'accès à ce répertoire et à son contenu. Seuls le processus ou les applications recevant des mises à jour OTA doivent pouvoir lire et écrire dans ce répertoire. Aucune autre application ni aucun autre 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 est équipé d'Android 11 ou 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

En outre, les fabricants d'appareils peuvent effectuer les tests manuels suivants. Sur un appareil sur lequel le chiffrement basé sur les fichiers est activé :

• Vérifiez que ro.crypto.state existe.
  • S'assurer que ro.crypto.state est chiffré
• 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 un build userdebug ou eng, définissez un code, un schéma ou un mot de passe pour l'utilisateur principal, puis 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 système sans interface graphique (la plupart des appareils Automotive), l'utilisateur principal est l'utilisateur 10. Exécutez donc la commande suivante :

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

Sur les autres appareils (la plupart des appareils non Automotive), l'utilisateur principal est l'utilisateur 0. Exécutez donc la commande suivante :

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

Vérifiez que les noms de fichiers listés sont encodés en Base64, ce qui indique qu'ils sont chiffrés et que la clé permettant de les déchiffrer n'est pas encore disponible. Si les noms de fichiers sont listés en texte brut, cela signifie qu'il y a un problème.

Les fabricants d'appareils sont également encouragés à explorer l'exécution des tests Linux en amont pour fscrypt sur leurs appareils ou leurs noyaux. Ces tests font partie de la suite de tests du système de fichiers xfstests. Toutefois, ces tests en amont ne sont pas officiellement compatibles avec Android.

Détails de l'implémentation d'AOSP

Cette section fournit des détails sur l'implémentation d'AOSP et décrit le fonctionnement du chiffrement basé sur les fichiers. Les fabricants d'appareils ne devraient pas avoir besoin d'apporter de modifications ici pour utiliser FBE et Direct Boot sur leurs appareils.

Chiffrement fscrypt

L'implémentation AOSP utilise le chiffrement "fscrypt" (compatible avec ext4 et f2fs) dans le noyau et est normalement configurée pour :

• Chiffrement du contenu des fichiers avec AES-256 en mode XTS
• Chiffrer les noms de fichiers avec AES-256 en mode CBC-CTS

Le chiffrement Adiantum est également pris en charge. Lorsque le chiffrement Adiantum est activé, le contenu et les noms des fichiers sont chiffrés avec Adiantum.

fscrypt est compatible avec deux versions de règles de chiffrement : la version 1 et la version 2. La version 1 est obsolète, et les exigences du CDD pour les appareils lancés avec Android 11 ou version ultérieure ne sont compatibles qu'avec la version 2. Les règles de chiffrement de la version 2 utilisent HKDF-SHA512 pour dériver les clés de chiffrement réelles des clés fournies par l'espace utilisateur.

Pour en savoir plus sur fscrypt, consultez la documentation du noyau en amont.

Classes de stockage

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

Stockage et protection des clés

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

Comme indiqué dans 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 chiffrement à toutes les clés FBE. Chaque clé, à l'exception des clés CE pour la mémoire de 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, sauf si un système d'exploitation de confiance a démarré, comme l'impose le démarrage validé. La résistance au rollback est également demandée sur la clé Keystore, ce qui permet de supprimer de manière sécurisée les clés FBE sur les appareils où KeyMint est compatible avec la résistance au rollback. En cas d'indisponibilité de la protection contre le rétablissement, le hachage SHA-512 de 16 384 octets aléatoires stockés dans le fichier secdiscardable stocké à côté de la clé est utilisé comme Tag::APPLICATION_ID 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 (code, schéma ou mot de passe), un jeton de réinitialisation sécurisée du code secret, ou les clés côté client et côté serveur pour une opération de reprise au redémarrage. Les jetons de réinitialisation de code secret ne peuvent être créés que pour les profils professionnels et les appareils entièrement gérés.

Pour ce faire, vold chiffre 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 à forte entropie généré de manière aléatoire pour chaque utilisateur. LockSettingsService dans system_server gère le mot de passe synthétique et les moyens de le protéger.

Pour protéger le mot de passe synthétique avec le LSKF, LockSettingsService étire d'abord le LSKF en le transmettant via scrypt, en ciblant une durée d'environ 25 ms et une utilisation de mémoire d'environ 2 Mio. Comme 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 Secure Element (SE) ou la limitation du débit appliquée par TEE décrite ci-dessous.

Si l'appareil implémente la HAL Weaver, LockSettingsService mappe le LSKF étiré à un secret aléatoire à entropie élevée stocké dans l'élément sécurisé ou le TEE à l'aide de Weaver. LockSettingsService chiffre ensuite le mot de passe synthétique deux fois : d'abord avec une clé logicielle dérivée du LSKF étiré et du secret Weaver, puis avec une clé Keystore non liée à l'authentification. Cela permet de limiter le débit des suppositions LSKF appliquées par SE ou TEE.

Si l'appareil n'implémente pas Weaver, LockSettingsService utilise plutôt le LSKF étiré comme mot de passe Gatekeeper. LockSettingsService chiffre ensuite le mot de passe synthétique deux fois : d'abord avec une clé logicielle dérivée du LSKF étiré et du hachage d'un fichier secdiscardable, puis avec une clé Keystore liée à l'authentification de l'enregistrement Gatekeeper. Cela permet de limiter le débit des tentatives de deviner la LSKF, en appliquant cette limite au niveau de l'environnement d'exécution de confiance.

Lorsque la LSKF est modifiée, LockSettingsService supprime toutes les informations associées à l'association du mot de passe synthétique à l'ancienne LSKF. Sur les appareils compatibles avec Weaver ou les clés Keystore résistantes au rollback, cela garantit la suppression sécurisée de l'ancienne liaison. C'est pourquoi les protections décrites ici sont appliquées même si l'utilisateur n'a pas de LSKF.