Cryptage basé sur les fichiers

Android 7.0 et versions ultérieures prennent en charge le chiffrement basé sur les fichiers (FBE). Le cryptage basé sur les fichiers permet de crypter différents fichiers avec différentes clés 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 la meilleure et la plus sûre expérience possible.

Démarrage direct

Chiffrement à base de fichiers permet une nouvelle fonctionnalité introduite dans Android 7.0 appelé Boot direct . Le démarrage direct permet aux appareils cryptés de démarrer directement sur l'écran de verrouillage. Auparavant, sur les périphériques chiffrés à l' aide de chiffrement de disque complet (FDE), les utilisateurs devaient fournir des informations avant que les données pourraient être accessibles, ce qui empêche le téléphone d'effectuer tous , mais les plus élémentaires des opérations. 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 base du numéroteur 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 aient fourni leurs informations d'identification tout en protégeant les informations personnelles des utilisateurs.

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

  • Stockage crypté par les informations d'identification (CE), qui est l'emplacement de stockage par défaut et n'est disponible qu'une fois que l'utilisateur a déverrouillé l'appareil.
  • Le 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 de travail 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 de démarrage.

L'API Direct Boot permet aux applications prenant en charge le chiffrement d'accéder à chacune de ces zones. Il y a des changements au cycle de vie de l' application pour tenir compte de la nécessité de notifier les applications quand est déverrouillé le stockage CE d'un utilisateur en réponse aux premières informations d'identification entrant à l'écran de verrouillage, ou dans le cas du profil de travail offrant un défi de travail . 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 cryptage 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 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 de chiffrement basé sur fichier, dans lequel Vold ( système / 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 du noyau change d'utiliser le chiffrement à base de fichiers capacités dans le noyau, de nombreux paquets du système , y compris le lockscreen et SystemUI ont été modifiés pour soutenir la FBE et dispose d' amorçage direct. Ceux-ci inclus:

  • Numéroteur AOSP (paquets/applications/numéroteur)
  • Horloge de bureau (packages/applications/DeskClock)
  • LatinIME (packages/inputmethods/LatinIME)*
  • Application Paramètres (packages/applications/Paramètres)*
  • SystemUI (frameworks/base/packages/SystemUI)*

* Les applications système qui utilisent le defaultToDeviceProtectedStorage attribut manifeste

D' autres exemples d'applications et de services qui sont au courant de chiffrement peuvent être trouvés en exécutant la commande mangrep directBootAware dans les cadres ou les paquets de l'arborescence source PSBA.

Dépendances

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

  • Support du noyau pour le cryptage ou chiffrement Ext4 f2fs.
  • Keymaster support 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 mises en œuvre dans un environnement d' exécution de confiance (TEE) pour fournir une protection pour les touches DE de sorte qu'un système d' exploitation non autorisée (OS personnalisé flashé sur l'appareil) ne peut pas demander simplement les touches DE.
  • Matériel racine de confiance et Verified Boot lié à l'initialisation de Keymaster est nécessaire pour faire en sorte que les informations d' identification de chiffrement de périphériques ne sont pas accessibles par un système d'exploitation non autorisée.

Remarque: Les stratégies 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 crypté par les informations d'identification plutôt que dans un stockage crypté par l'appareil.

Mise en œuvre

Tout d'abord, des applications telles que réveils, téléphone, les fonctions d'accessibilité doivent être android: directBootAware selon Direct Boot documentation pour les développeurs.

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 votre appareil userdata est Ext4 système de fichiers, ou l' utilisation CONFIG_F2FS_FS_ENCRYPTION=y si de votre appareil userdata système de fichiers est f2fs.

Si votre appareil soutiendra le stockage adoptables ou utilisera le cryptage des métadonnées sur le stockage interne, activez également les options de configuration du noyau nécessaires pour le cryptage des métadonnées comme décrit dans la documentation de 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 la mise en œuvre du matériel de chiffrement en ligne, qui cryptent / déchiffre les données alors qu'il est sur le chemin vers / depuis le périphérique de stockage. Les noyaux communs Android (version 4.14 et supérieure) contiennent un cadre qui permet d'utiliser le chiffrement en ligne lorsque la prise en charge des pilotes matériels et fournisseurs 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 dispositif requiert l' activation sur la mémoire interne ( userdata ). Cela active également automatiquement FBE sur le stockage adoptable ; cependant, le format de chiffrement sur le stockage adoptable peut être outrepassé 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 fstab ligne userdata . Cette option définit le format de cryptage sur le stockage interne. Il contient jusqu'à trois paramètres séparés par des deux-points :

  • Les contents_encryption_mode paramètre définit l'algorithme cryptographique est utilisée pour crypter le contenu du fichier. Il peut être soit aes-256-xts ou adiantum . Depuis Android 11 , il peut également être laissé vide pour indiquer l'algorithme par défaut, qui est aes-256-xts .
  • Le filenames_encryption_mode paramètre définit l'algorithme cryptographique est utilisé pour les noms de fichiers Crypter. Il peut être soit aes-256-cts , aes-256-heh , ou adiantum . Si non spécifié, la valeur par défaut aes-256-cts si contents_encryption_mode est aes-256-xts , ou adiantum si contents_encryption_mode est adiantum .
  • Le flags paramètre, nouveau dans Android 11, une liste de drapeaux séparés par le + caractère. Les indicateurs suivants sont pris en charge :
    • Le v1 drapeau de la version 1 politiques de cryptage; la v2 version drapeau 2 politiques de cryptage. Version 2 politiques de chiffrement utilisent une plus sûre et flexible clé fonction de dérivation . La valeur par défaut est v2 si le dispositif lancé sur les applications 11 ou plus (tel que déterminé par ro.product.first_api_level ), ou si le dispositif v1 lancé sur les applications 10 ou moins.
    • Le inlinecrypt_optimized drapeau sélectionne un format de chiffrement qui est optimisé pour le matériel de chiffrement en ligne qui ne gère pas un grand nombre de touches plus efficacement. 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.
    • Le emmc_optimized drapeau est similaire à inlinecrypt_optimized , mais elle sélectionne également un procédé de génération de IV qui limite IVs à 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 inlinecrypt_optimized à la place. 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 supportent les clés enveloppées matériels , le wrappedkey_v0 drapeau permet l'utilisation de clés enveloppé le matériel pour FBE. Cela ne peut être utilisé en combinaison avec l' inlinecrypt option de montage, et soit le inlinecrypt_optimized ou emmc_optimized drapeau.

Si vous n'utilisez pas du 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 équivalente fileencryption=::inlinecrypt_optimized ). Sur les appareils sans aucune forme d'accélération AES, Adiantum peut être utilisé au lieu d'AES en définissant fileencryption=adiantum .

Sur les appareils avec Android qui a lancé 10 ou moins, fileencryption=ice est également accepté de préciser l'utilisation du FSCRYPT_MODE_PRIVATE contenu fichier mode de cryptage. Ce mode n'est pas implémenté par les noyaux communs Android, mais il pourrait être implémenté 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 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 à la place du matériel de chiffrement en ligne, ajoutez également la inlinecrypt option de montage. Par exemple, une pleine fstab ligne 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 stockage adoptables peuvent être utilisés ensemble.

Spécification de la fileencryption option fstab userdata permet également automatiquement les FBE et le cryptage des métadonnées sur le stockage adoptable. Cependant, vous pouvez remplacer la FBE et / ou les formats de chiffrement 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 (nouveaux dans Android 11) sélectionne le format de chiffrement FBE sur le stockage adoptable. Il a la même syntaxe que l'argument de la fileencryption option fstab et utilise les mêmes valeurs par défaut. Voir les recommandations pour fileencryption ci - dessus pour ce qu'il faut utiliser ici.
  • ro.crypto.volume.metadata.encryption sélectionne le format de chiffrement des métadonnées sur le stockage adoptable. Consultez la documentation de 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 de contenu. Ceci est équivalent à la première zone de séparation-virgule ro.crypto.volume.options .
  • ro.crypto.volume.filenames_mode sélectionne le mode de cryptage des noms de fichiers. Ceci est équivalent à la deuxième zone de séparation-virgule ro.crypto.volume.options , sauf que la valeur par défaut sur les appareils qui a lancé avec les applications 10 ou inférieur est aes-256-heh . Sur la plupart des appareils, cela doit être explicitement écarté pour aes-256-cts .
  • ro.crypto.fde_algorithm et ro.crypto.fde_sector_size sélectionner le format de chiffrement des métadonnées sur le stockage adoptable. Consultez la documentation de chiffrement des métadonnées .

Intégration avec Keymaster

La génération des clés et la gestion du trousseau de clés du noyau est géré 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 prise en charge des 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ù le on-post-fs phase d' init terminée, le Keymaster doit être prêt à traiter les demandes. Sur les appareils Pixel, cela est géré en ayant un bloc de script assurer Keymaster est démarré avant /data est monté.

Politique de chiffrement

Le chiffrement basé sur fichier applique la stratégie de chiffrement au niveau du répertoire. Lorsque d'un périphérique userdata partition est créée, les structures de base et les politiques sont appliquées par les init des scripts. Ces scripts déclencheront la création des clés CE et DE du premier utilisateur (utilisateur 0) ainsi que 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 informations d'identification et les emplacements de stockage des périphériques sont créés et la politique de chiffrement lie ces clés à ces répertoires.

Dans Android 11 et plus, la politique de chiffrement n'est plus dans un hardcoded emplacement centralisé, mais est définie par des arguments aux mkdir commandes dans les scripts d'initialisation. Répertoires chiffrés avec le système DE l' utilisation des clés de encryption=Require , alors que les répertoires non cryptés (ou répertoires dont les sous - répertoires sont chiffrés avec des clés par utilisateur) utiliser le 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 éviter que certains répertoires ne soient cryptés. Si des modifications de ce type sont faites, le fabricant de l' appareil devrait inclure des politiques SELinux qui accordent seulement l' accès aux applications qui ont besoin d'utiliser le répertoire non crypté. 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. Le defaultToDeviceProtectedStorage attribut est disponible uniquement pour les applications système. Le directBootAware attribut est accessible à tous.

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

Le directBootAware attribut au niveau de l' application est un raccourci pour marquer tous les composants de l'application comme étant au courant de cryptage.

Le defaultToDeviceProtectedStorage attribut redirige l'emplacement de stockage d'application par défaut à un point au stockage DE au lieu de pointer au 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-utilisateurs obtient 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 l' administration des périphériques utilisations.

Applications Crypto-aware interagir entre les utilisateurs de cette manière: INTERACT_ACROSS_USERS et INTERACT_ACROSS_USERS_FULL permettent une application d'agir dans 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 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 (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. Dispositifs de mise en œuvre FBE sont fortement recommandés pour soutenir l' OTA à l' aide des mises à jour du système A / B . Comme l'OTA peut être appliqué pendant le fonctionnement normal, il n'y a pas besoin de récupération pour accéder aux données sur le lecteur crypté.

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

  1. Créez un répertoire de niveau supérieur (par exemple misc_ne ) dans la userdata partition.
  2. Ajoutez ce répertoire de haut niveau à l'exception de la politique de chiffrement (voir la politique 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 fichier 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 assurer la version mise en œuvre des fonctionnalités fonctionne comme prévu, d' abord exécuter les nombreux tests de cryptage CTS, comme DirectBootHostTest et EncryptionTest .

Si l'appareil est en cours d' exécution Android 11 ou plus, 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é :

  • Assurez -vous que ro.crypto.state existe
    • Assurez -vous ro.crypto.state est crypté
  • Assurez -vous que ro.crypto.type existe
    • Assurez -vous ro.crypto.type est réglé sur file

De plus, les testeurs peuvent démarrer une userdebug instance avec un ensemble lockscreen sur l'utilisateur principal. Ensuite adb shell dans l'appareil et de l' utilisation su pour devenir root. Assurez - vous /data/data contient noms de fichiers crypté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 de 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 la 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.

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'autorisation
  • La référence étirée
  • Le « hash secdable »

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

Le titre est étiré les informations d' identification de l' utilisateur après le salage et d' étirement avec le scrypt algorithme. Le titre est en fait une fois dans le haché service du verrou avant d' être passé à vold pour passer à scrypt . Ceci est lié à la cryptographiquement clé dans la TEE avec toutes les garanties applicables à 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 une table de hachage de 512 bits d'un fichier de 16 KB aléatoire stocké aux côtés d' autres informations utilisées pour reconstruire la clé, telles que les semences. Ce fichier est supprimé de manière sécurisée lorsque la clé est supprimée, ou il est crypté 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é. Ceci est lié à la cryptographiquement clé dans la TEE avec toutes les garanties applicables à KM_TAG_APPLICATION_ID .

Dans la plupart des cas, les clés FBE subissent également une étape de dérivation de clé supplémentaire 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 de la version 2, HKDF-SHA512 est utilisé pour cela.