Cryptage basé sur les fichiers

Android 7.0 et supérieur prend en charge le chiffrement basé sur les fichiers (FBE). Le chiffrement basé sur les fichiers permet de chiffrer différents fichiers avec différentes clés qui peuvent être déverrouillées indépendamment.

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

Démarrage direct

Le chiffrement basé sur les fichiers active une nouvelle fonctionnalité introduite dans Android 7.0 appelée Direct Boot . 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 intégral du disque (FDE), les utilisateurs devaient fournir des informations d'identification avant d'accéder aux données, ce qui empêchait 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 opérations de numérotation d'urgence de base.

Avec l'introduction du chiffrement basé sur les fichiers (FBE) et de nouvelles API pour rendre les applications conscientes du 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 après que l'utilisateur a déverrouillé l'appareil.
  • Stockage Device Encrypted (DE), qui est un emplacement de stockage disponible à la fois pendant le mode de démarrage direct et après que l'utilisateur a déverrouillé l'appareil.

Cette séparation rend les profils professionnels plus sûrs car elle permet de protéger plus d'un utilisateur à la fois car le cryptage n'est plus basé uniquement sur un mot de passe au démarrage.

L'API Direct Boot permet aux applications prenant en charge le chiffrement d'accéder à chacune de ces zones. Des modifications ont été apportées au cycle de vie de l'application pour répondre à la nécessité de notifier les applications lorsque le stockage CE d'un utilisateur est déverrouillé en réponse à la première saisie d'informations d'identification sur l'écran de verrouillage, ou dans le cas d'un profil professionnel fournissant 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. Bien que, sans FBE, le stockage DE et CE sera toujours à l'é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 qui choisissent d'utiliser FBE peuvent souhaiter 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. 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 composeur
  • 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 pour les clés CE et DE de plusieurs utilisateurs. En plus des changements de base pour utiliser les capacités de chiffrement basées sur les fichiers dans le noyau, de nombreux packages système, y compris l'écran de verrouillage et l'interface utilisateur système, ont été modifiés pour prendre en charge les fonctionnalités FBE et Direct Boot. Ceux-ci inclus:

  • AOSP Dialer (forfaits/applications/Dialer)
  • Horloge de bureau (forfaits/applications/DeskClock)
  • LatinIME (paquets/méthodes d'entrée/LatinIME)*
  • Application Paramètres (forfaits/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 le cryptage F2FS.
  • Prise en charge de Keymaster avec une version HAL 1.0 ou 2.0. Il n'y a pas de support pour Keymaster 0.3 car cela ne fournit pas les capacités nécessaires ou n'assure pas une protection suffisante pour les clés de chiffrement.
  • Keymaster/ Keystore et Gatekeeper doivent être implémentés dans un environnement d'exécution sécurisé (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 maître de clé sont nécessaires pour garantir que les informations d'identification de chiffrement de périphérique ne sont pas accessibles par un système d'exploitation non autorisé.

Remarque : les politiques de stockage sont appliquées à un dossier et à tous ses sous-dossiers. Les fabricants doivent limiter le contenu non chiffré au dossier OTA et au dossier contenant la clé qui déchiffre le système. La plupart des contenus doivent résider dans un stockage chiffré par identifiants plutôt que dans un stockage chiffré par appareil.

Mise en œuvre

Tout d'abord, les applications telles que les réveils, le téléphone, les fonctionnalités d'accessibilité doivent être rendues 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, version 3.18 et supérieure. Pour l'activer dans un noyau de 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 de données utilisateur de votre appareil est userdata , ou utilisez CONFIG_F2FS_FS_ENCRYPTION=y si le système de fichiers de données utilisateur de votre appareil est userdata .

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 .

Outre 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 de mettre en œuvre un matériel de chiffrement en ligne , qui chiffre/déchiffre les données lorsqu'elles sont en route vers/depuis le périphérique de stockage. Les noyaux communs Android (version 4.14 et ultérieure) 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. L'infrastructure de chiffrement en ligne peut être activée 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 d' 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 ou adiantum . 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 stratégies de chiffrement de la version 2 utilisent une fonction de dérivation de clé plus sécurisée et plus souple. La valeur par défaut est v2 si l'appareil a été lancé sur Android 11 ou supérieur (tel que déterminé par ro.product.first_api_level ), ou v1 si l'appareil a été lancé sur Android 10 ou inférieur.
    • 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 d'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 d'autres matériels de chiffrement en ligne, utilisez plutôt inlinecrypt_optimized . Cet indicateur ne doit jamais être utilisé sur un stockage basé sur UFS ; la spécification UFS permet l'utilisation d'IV 64 bits.
    • Sur les appareils qui prennent en charge les clés encapsulées dans le matériel, l'indicateur wrappedkey_v0 permet l'utilisation de clés encapsulées dans le matériel pour FBE. Cela ne peut être utilisé qu'en combinaison avec l'option de montage inlinecrypt et l' inlinecrypt_optimized ou emmc_optimized .

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 .

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 ê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 supérieur, 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 chiffrement du noyau Linux. Si vous souhaitez utiliser du matériel de chiffrement en ligne à la place, 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 fileencryption fstab pour les données userdata active également automatiquement le chiffrement FBE et des métadonnées sur le stockage adoptable. Cependant, vous pouvez remplacer les formats de chiffrement FBE et/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 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. Voir les recommandations pour le fileencryption de fichiers 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. 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 inférieur 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 chiffrement des métadonnées sur le stockage adoptable. Consultez la documentation sur le chiffrement des métadonnées .

Intégration avec Keymaster

La génération de clés et la gestion du trousseau de clés du noyau sont gérées par vold . L'implémentation AOSP de FBE nécessite que l'appareil prenne en charge Keymaster HAL version 1.0 ou ultérieure. Il n'y a pas de support pour les versions antérieures de Keymaster HAL.

Au premier démarrage, les clés de l'utilisateur 0 sont générées et installées au début du processus de démarrage. Au moment où la phase on-post-fs de init se termine, le Keymaster doit être prêt à traiter les requêtes. Sur les appareils Pixel, cela est géré en ayant un bloc de script garantissant que Keymaster est démarré avant que /data soit monté.

Politique de chiffrement

Le chiffrement basé sur fichier applique la stratégie de chiffrement au niveau du répertoire. Lorsque la partition de userdata d'un périphérique est créée pour la première fois, les structures et politiques de base sont appliquées par les scripts d' init . Ces scripts déclencheront la création des clés CE et DE du premier utilisateur (utilisateur 0) et définiront les répertoires à chiffrer avec ces clés. Lorsque des utilisateurs et des profils supplémentaires sont créés, les clés supplémentaires nécessaires sont générées et stockées dans le magasin de clés ; leurs emplacements de stockage d'informations d'identification et de périphériques sont créés et la stratégie de chiffrement lie ces clés à ces répertoires.

Dans Android 11 et versions ultérieures, la politique de chiffrement n'est plus codée en dur dans un emplacement centralisé, mais est plutôt définie par des arguments aux commandes mkdir dans les scripts init. Les répertoires chiffrés avec la clé système DE utilisent encryption=Require , tandis que les répertoires non chiffrés (ou les répertoires dont les sous-répertoires sont chiffrés avec des clés par utilisateur) utilisent encryption=None .

Dans Android 10, la stratégie de chiffrement était codée en dur à cet emplacement :

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Dans 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 certains répertoires d'être chiffrés. Si des modifications de ce type sont apportées, le fabricant de l'appareil doit inclure des politiques 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 approuvées.

Le seul cas d'utilisation acceptable connu pour cela est la prise en charge des capacités OTA héritées.

Prise en charge du 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 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 pour marquer tous les composants de l'application comme prenant en charge le chiffrement.

L'attribut defaultToDeviceProtectedStorage redirige l'emplacement de stockage de l'application par défaut pour qu'il pointe vers le stockage DE au lieu de pointer vers le stockage CE. Les applications système utilisant cet indicateur doivent soigneusement auditer 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 de l'administration des appareils .

Les applications sensibles au chiffrement interagissent entre les utilisateurs de cette manière : 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 être en mesure d'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 obtient é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 (en 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 mettant en œuvre FBE de prendre en charge OTA à l'aide des mises à jour 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 héritée, qui nécessite une récupération pour accéder au fichier userdata sur la partition de données utilisateur :

  1. Créez un répertoire de niveau supérieur (par exemple misc_ne ) dans la partition userdata .
  2. Ajoutez ce répertoire de niveau supérieur à l'exception de stratégie de chiffrement (voir Stratégie de chiffrement ci-dessus).
  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 dossier et à son contenu. Seuls le processus ou les applications recevant les mises à jour OTA doivent pouvoir lire et écrire dans ce dossier. Aucune autre application ou processus ne doit avoir accès à ce dossier.

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

De plus, les testeurs peuvent démarrer une instance userdebug avec un écran de verrouillage défini sur l'utilisateur principal. Ensuite, adb shell dans l'appareil et utilisez su pour devenir root. Assurez-vous que /data/data contient des noms de fichiers chiffrés ; si ce n'est pas le cas, quelque chose ne va pas.

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 de système de fichiers xfstests. Cependant, ces tests en amont ne sont pas officiellement pris en charge par Android.

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

Cette section fournit des détails sur la mise en œuvre d'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 chiffrement "fscrypt" (pris en charge par ext4 et f2fs) dans le noyau et est normalement configuré 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 chiffrement Adiantum est également pris en charge. Lorsque le chiffrement Adiantum est activé, le contenu des fichiers et les noms de fichiers sont chiffrés avec Adiantum.

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

Dérivation de clé

Les clés de chiffrement basées sur des fichiers, qui sont des clés de 512 bits, sont stockées chiffrées par une autre clé (une clé AES-GCM de 256 bits) détenue dans le TEE. Pour utiliser cette clé TEE, trois conditions doivent être remplies :

  • Le jeton d'authentification
  • Le titre étiré
  • Le "secdiscardable hash"

Le jeton d'authentification est un jeton authentifié par chiffrement généré par Gatekeeper lorsqu'un utilisateur se connecte avec succès. Le TEE refusera d'utiliser la clé à moins que le jeton d'authentification correct ne soit fourni. Si l'utilisateur n'a pas d'informations d'identification, aucun jeton d'authentification n'est utilisé ni nécessaire.

Les informations d' identification étirées sont les informations d'identification de l'utilisateur après le salage et l'étirement avec l'algorithme scrypt . Les informations d'identification sont en fait hachées une fois dans le service des paramètres de verrouillage avant d'être transmises à vold pour être transmises à scrypt . Celle-ci est cryptographiquement liée à la clé dans le TEE avec toutes les garanties qui s'appliquent à KM_TAG_APPLICATION_ID . Si l'utilisateur n'a pas d'informations d'identification, aucune information d'identification étendue n'est utilisée ni nécessaire.

Le secdiscardable hash est un hachage de 512 bits d'un fichier aléatoire de 16 Ko stocké avec d'autres informations utilisées pour reconstruire la clé, comme la graine. Ce fichier est supprimé en toute sécurité lorsque la clé est supprimée, ou il est chiffré d'une nouvelle manière ; cette protection supplémentaire garantit qu'un attaquant doit récupérer chaque bit de ce fichier supprimé en toute sécurité pour récupérer la clé. Celle-ci est cryptographiquement liée à la clé dans le TEE avec toutes les garanties qui s'appliquent à KM_TAG_APPLICATION_ID .

Dans la plupart des cas, les clés FBE subissent également une étape supplémentaire de dérivation de clé dans le noyau afin de générer les sous-clés réellement utilisées pour effectuer le chiffrement, par exemple des clés par fichier ou par mode. Pour les politiques de chiffrement version 2, HKDF-SHA512 est utilisé pour cela.