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.

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

Démarrage direct

Le chiffrement basé sur les fichiers active une nouvelle fonctionnalité introduite dans Android 7.0 appelée Direct Boot . 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 HAL version 1.0 ou supérieure. 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 Keymaster sont nécessaires pour garantir que les clés DE ne sont pas accessibles par un système d'exploitation non autorisé.

Mise en œuvre

Avant tout, les applications telles que les réveils, le téléphone et les fonctionnalités d'accessibilité doivent être 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 userdata de votre appareil est Ext4, ou utilisez CONFIG_F2FS_FS_ENCRYPTION=y si le système de fichiers userdata de votre appareil est F2FS.

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

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 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 . 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'indicateur 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 .

Depuis Android 14 (AOSP expérimental), AES-HCTR2 est le mode préféré de cryptage des noms de fichiers pour les appareils avec des instructions de cryptographie accélérées. Cependant, seuls les noyaux Android les plus récents prennent en charge AES-HCTR2. Dans une future version d'Android, il est prévu de devenir le mode par défaut pour le cryptage des noms de fichiers. Si votre noyau prend en charge AES-HCTR2, il peut être activé pour le 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 ê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 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 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. 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

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

Exclure les répertoires

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

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

/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 périphériques .

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 OTA sur la partition userdata :

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

Validation

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

Si l'appareil exécute Android 11 ou 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 que 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.

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

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

Classes de stockage

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

Stockage et protection des clés

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

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 cryptage à toutes les clés FBE. Chaque clé en plus des clés CE pour le stockage interne est cryptée avec AES-256-GCM en utilisant sa propre clé Keystore qui n'est pas exposée en dehors du TEE. Cela garantit que les clés FBE ne peuvent pas être déverrouillées à moins qu'un système d'exploitation approuvé n'ait démarré, comme appliqué par Verified Boot . La résistance à la restauration est également demandée sur la clé Keystore, ce qui permet de supprimer en toute sécurité les clés FBE sur les appareils où Keymaster prend en charge la résistance à la restauration. En tant que solution de repli au mieux lorsque la résistance à la restauration n'est pas disponible, le hachage SHA-512 de 16384 octets aléatoires stocké dans le fichier secdiscardable stocké à côté de la clé est utilisé comme balise d'identification d'application de la clé Keystore. Tous ces octets doivent être récupérés pour récupérer une clé FBE.

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

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

Pour protéger le mot de passe synthétique avec le LSKF, LockSettingsService étend d'abord le LSKF en le faisant passer par scrypt , 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 ne fournit généralement pas beaucoup de sécurité. La principale couche de sécurité est l' élément sécurisé (SE) ou la limitation de débit appliquée par TEE décrite ci-dessous.

Si l'appareil dispose d'un élément sécurisé (SE), LockSettingsService mappe le LSKF étiré sur un secret aléatoire à haute entropie stocké dans le SE à l'aide de Weaver HAL . LockSettingsService crypte 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 fournit une limitation de débit appliquée par SE des suppositions LSKF.

Si l'appareil n'a pas de SE, LockSettingsService utilise à la place le LSKF étendu comme mot de passe Gatekeeper . LockSettingsService crypte ensuite le mot de passe synthétique deux fois : d'abord avec une clé logicielle dérivée du LSKF étiré et du hachage d'un fichier secdiscardable, et ensuite avec une clé Keystore liée à l'authentification du Gatekeeper. Cela fournit une limitation de débit imposée par TEE des suppositions LSKF.

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