Chiffrement basé sur les fichiers

Android 7.0 et versions ultérieures sont compatibles avec le chiffrement basé sur les fichiers (FBE, File-Based Encryption). 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 explique comment activer le chiffrement basé sur des fichiers sur de nouveaux appareils et comment les applications système peuvent utiliser les API Direct Boot 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 utilisant le chiffrement complet du disque (FDE), les utilisateurs devaient fournir des identifiants avant de pouvoir accéder à des données, ce qui empêchait le téléphone d'effectuer toutes les opérations, à l'exception des plus élémentaires. 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 d'être informées 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 de l'appareil dispose de deux emplacements de stockage accessibles aux applications :

• Le stockage chiffré par identifiants (CE), qui est l'emplacement de stockage par défaut et n'est disponible qu'une fois l'appareil déverrouillé par l'utilisateur.
• Stockage chiffré de l'appareil (DE, Device Encrypted), 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 au 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 permettre d'informer les applications lorsque le 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, lorsqu'un défi professionnel est fourni. 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. Toutefois, sans FBE, le stockage DE et CE est toujours déverrouillé.

Une implémentation complète du chiffrement basé sur des fichiers sur les systèmes de fichiers Ext4 et F2FS est fournie dans le projet Android Open Source (AOSP). Il suffit de l'activer sur les appareils qui répondent aux exigences. Les fabricants qui choisissent d'utiliser FBE peuvent explorer des 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 ê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 fournissant 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 les fichiers, dans laquelle vold (system/vold) fournit la fonctionnalité de gestion des périphériques et des 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 pour utiliser les fonctionnalités de chiffrement basées sur les fichiers dans le noyau, de nombreux packages système, y compris l'écran de verrouillage et SystemUI, ont été modifiés pour prendre en charge les fonctionnalités FBE et Direct Boot. En voici quelques exemples :

• Application de téléphone 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 trouver 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 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 :

• Prise en charge du noyau pour le chiffrement Ext4 ou F2FS.
• KeyMint (ou Keymaster 1.0 ou version ultérieure) Support. Keymaster 0.3 n'est pas compatible, car il ne fournit pas les fonctionnalités nécessaires ni une protection suffisante pour les 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 afin qu'un OS non autorisé (OS personnalisé installé sur l'appareil) ne puisse pas simplement demander les clés DE.
• Une racine de confiance matérielle et un démarrage validé liés à l'initialisation de KeyMint sont nécessaires 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 Direct Boot.

Assistance pour le noyau

La prise en charge du noyau pour le chiffrement Ext4 et F2FS est disponible dans les noyaux communs Android, version 3.18 et ultérieure. 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 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 davantage les performances et réduire la consommation d'énergie, les fabricants d'appareils peuvent également envisager d'implémenter un matériel de chiffrement en ligne, 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 le matériel et le pilote du fournisseur sont compatibles. 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 :

CONFIG_SCSI_UFS_CRYPTO=y

Si votre appareil utilise un stockage basé sur eMMC, activez également les éléments suivants :

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 automatiquement 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 des deux-points :

• Le paramètre contents_encryption_mode définit l'algorithme cryptographique utilisé pour chiffrer le contenu des fichiers. 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'indicateurs séparés 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é sur Android 11 ou version ultérieure (comme déterminé par ro.product.first_api_level), ou "v1" si l'appareil a été lancé sur Android 10 ou version antérieure.
  • L'indicateur 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 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 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. Cet indicateur ne doit être utilisé que sur le matériel de chiffrement intégré conforme à la spécification JEDEC eMMC v5.2 et qui ne prend donc en charge que 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 le stockage basé sur UFS, car la spécification UFS autorise l'utilisation d'IV de 64 bits.
  • Sur les appareils compatibles avec les clés protégées par matériel, l'indicateur wrappedkey_v0 permet d'utiliser des clés protégées par matériel pour le chiffrement basé sur un fichier. Cette option ne peut être utilisée qu'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 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 des fichiers. 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 un 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 kernels Android 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 une version antérieure, fileencryption=ice est également accepté pour spécifier l'utilisation du mode de chiffrement du contenu du fichier FSCRYPT_MODE_PRIVATE. Ce mode n'est pas implémenté par les noyaux communs Android, mais il pourrait l'être 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 chiffrement standard doit être utilisé à la place.

Par défaut, le contenu des fichiers est chiffré à 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 de montage 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, FBE et l'espace de stockage adoptable peuvent être utilisés ensemble.

Si vous spécifiez l'option fstab fileencryption pour userdata, le chiffrement basé sur un fichier et le chiffrement des métadonnées sont automatiquement activés sur le stockage pouvant être adopté. Toutefois, vous pouvez remplacer les formats de chiffrement FBE ou des 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 a la même syntaxe que l'argument de l'option fileencryption fstab 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 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 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électionnez le format de chiffrement des métadonnées sur la mémoire de 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 à traiter 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 doivent être non chiffrés, tels que le répertoire qui contient la clé DE du système lui-même et les répertoires qui contiennent 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.

Dans Android 11 et versions ultérieures, la clé à laquelle init s'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

Sous 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 des modifications de ce type sont apportées, le fabricant de l'appareil doit inclure des stratégies SELinux qui n'accordent l'accès qu'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 pour cela est la prise en charge 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 est une abréviation pour marquer tous les composants de l'application comme étant compatibles avec le chiffrement.

L'attribut defaultToDeviceProtectedStorage redirige l'emplacement de stockage par défaut de l'application 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.

Lorsqu'il s'exécute dans ce mode, les API système suivantes sont disponibles pour gérer explicitement un contexte soutenu par le stockage CE si nécessaire, qui sont équivalentes à leurs homologues 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 les cryptomonnaies interagissent avec les utilisateurs de la manière suivante : INTERACT_ACROSS_USERS et INTERACT_ACROSS_USERS_FULL permettent à une application d'agir pour tous les utilisateurs de l'appareil. Toutefois, ces applications ne peuvent accéder qu'aux répertoires chiffrés avec CE pour les utilisateurs déjà déverrouillés.

Une application peut interagir librement dans 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. Une fois le défi professionnel relevé, l'utilisateur du profil est déverrouillé et KeyMint (dans TEE) peut fournir la clé TEE du profil.

Gérer les mises à jour

La partition de récupération ne peut pas accéder au stockage protégé par le chiffrement des données sur la partition userdata. Il est fortement recommandé aux appareils implémentant le FBE de prendre en charge les mises à jour OTA à l'aide des mises à jour 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 lecteur 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 de premier niveau 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

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.
  • Vérifier que ro.crypto.state est chiffré
• Vérifiez que ro.crypto.type existe.
  • Assurez-vous que ro.crypto.type est défini sur file.

Les testeurs peuvent également vérifier que le stockage CE est verrouillé avant que l'appareil n'ait été déverrouillé pour la première fois depuis le démarrage. Pour ce faire, utilisez une version 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 du système sans affichage (la plupart des appareils automobiles), l'utilisateur principal est l'utilisateur 10. Exécutez donc la commande suivante :

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

Sur d'autres appareils (la plupart des appareils non automobiles), 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 à tester l'upstream Linux 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 AOSP

Cette section fournit des informations sur l'implémentation AOSP et décrit le fonctionnement du chiffrement basé sur des fichiers. Les fabricants d'appareils ne devraient pas avoir à 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 :

• Chiffrer le 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. Les exigences du CDD pour les appareils lancés avec Android 11 et versions ultérieures ne sont compatibles qu'avec la version 2. Les règles de chiffrement de la version 2 utilisent HKDF-SHA512 pour obtenir les clés de chiffrement réelles à partir 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 de manière chiffrée 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 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 chiffrement à toutes les clés FBE. Toutes les clés, à l'exception des clés CE pour le stockage interne, sont chiffrées avec AES-256-GCM à l'aide de leur propre clé Keystore, qui n'est pas exposée en dehors de l'environnement d'exécution sécurisé (TEE). Cela garantit que les clés FBE ne peuvent être déverrouillées que si un système d'exploitation de confiance a démarré, comme l'impose la validation de l'intégrité du système au démarrage. La résistance au rollback est également requise pour la clé Keystore, ce qui permet de supprimer les clés FBE de manière sécurisée sur les appareils où KeyMint est compatible avec la résistance au rollback. En cas d'indisponibilité de la résistance au rollback, 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 de code secret sécurisé ou les clés côté client et côté serveur pour une opération Reprise au redémarrage. Les jetons de réinitialisation du 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 à haute 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 la façon dont il est protégé.

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

Si l'appareil dispose d'un élément sécurisé (SE), LockSettingsService mappe le LSKF étiré à un secret aléatoire à entropie élevée stocké dans le SE à l'aide de Weaver HAL. 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 d'appliquer une limitation du débit aux tentatives de devinettes LSKF.

Si l'appareil ne dispose pas d'un SE, LockSettingsService utilise à la place le LSKF étendu 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'enregistrement Gatekeeper. Cela permet de limiter le débit des suppositions de LSKF appliquées par l'environnement d'exécution sécurisé.

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