Chiffrement basé sur les fichiers

Android 7.0 ou version ultérieure est compatible avec le chiffrement basé sur les fichiers (FBE). 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 les fichiers sur les nouveaux appareils. et comment les applications système peuvent utiliser les API Direct Boot pour proposer aux utilisateurs l'expérience la plus efficace et la plus sécurisée possible.

Tous les appareils équipés d'Android 10 ou version ultérieure sont pour utiliser le chiffrement basé sur les fichiers.

Démarrage direct

Le chiffrement basé sur les fichiers permet une nouvelle fonctionnalité introduite dans Android 7.0 : Direct Démarrage. Le démarrage direct permet aux appareils chiffrés de démarrer directement sur la serrure l'écran. Auparavant, sur les appareils chiffrés avec full-disk de données (FDE), les utilisateurs devaient fournir des identifiants ce qui empêche le téléphone d'exécuter toutes les tâches, sauf les plus élémentaires opérations. Par exemple, les alarmes ne pouvaient pas se déclencher, les services d'accessibilité indisponibles, et les téléphones ne pouvaient pas recevoir d'appels, mais étaient limités au mode de base les services d'urgence.

Avec l'introduction du chiffrement basé sur les fichiers (FBE) et de nouvelles API pour applications compatibles avec le chiffrement, elles peuvent fonctionner dans un contexte limité. Cela peut se produire avant que les utilisateurs n'aient fourni leur tout en protégeant les informations privées des utilisateurs.

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

  • Stockage chiffré par identifiants (CE), 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), un emplacement de stockage disponible à la fois en mode Démarrage direct et après que l'utilisateur a déverrouillé l'appareil.

Cette séparation renforce la sécurité des profils professionnels, car elle autorise d'un utilisateur à protéger à la fois, car le chiffrement ne repose plus uniquement mot de passe de démarrage.

L'API Direct Boot permet aux applications compatibles avec le chiffrement d'accéder à chacun de ces dans différentes zones géographiques. Le cycle de vie de l'application a été modifié pour répondre à la nécessité notifier les applications lorsque l'espace de stockage CE d'un utilisateur est déverrouillé en réponse à saisir d'abord les identifiants sur l'écran de verrouillage ou, dans le cas d'un profil professionnel, en fournissant travail . Les appareils équipés d'Android 7.0 doivent être compatibles avec ces nouvelles API et cycles de vie, qu'ils implémentent ou non FBE. Bien que, sans Le stockage FBE, DE et CE sera toujours déverrouillé.

Implémentation complète du chiffrement basé sur les fichiers sur les fichiers Ext4 et F2FS sont fournis dans le projet Android Open Source (AOSP) et ne doivent être activée sur les appareils répondant aux exigences. Fabricants choisissant d'utiliser FBE vous souhaiterez peut-être explorer des moyens d'optimiser la fonctionnalité en fonction du système sur puce. (SoC) utilisés.

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

  • Services de téléphonie et numéroteur
  • Mode de saisie pour la 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) permet de gérer les périphériques de stockage 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 outre, aux principaux changements pour utiliser la fonctionnalité de chiffrement dans le noyau, de nombreux packages système, y compris l'écran de verrouillage et SystemUI ont été modifiés pour prendre en charge le FBE et Direct Fonctionnalités de démarrage En voici quelques exemples :

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

* Les applications système qui utilisent defaultToDeviceProtectedStorage attribut manifeste

D'autres exemples d'applications et de services compatibles avec le chiffrement peuvent être trouvé en exécutant la commande mangrep directBootAware dans Répertoire des frameworks ou packages de l'AOSP arborescence source.

Dépendances

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

  • Prise en charge du noyau pour le chiffrement Ext4 ou F2FS.
  • Keymaster Compatibilité avec HAL version 1.0 ou ultérieure Il n'est pas compatible avec Keymaster 0.3, car il n'offre pas les capacités nécessaires ni n'assure une protection suffisante pour les clés de chiffrement.
  • Keymaster/Keystore et l'agent de contrôle doit être implémenté dans une exécution sécurisée ; environnement (TEE) pour assurer la protection des clés DE afin qu'un un système d'exploitation non autorisé (OS personnalisé flashé sur l'appareil) ne peut pas simplement demander le clés DE.
  • Racine matérielle de confiance et démarrage validé liée à l'initialisation du Keymaster est nécessaire pour garantir que les clés DE ne sont pas accessibles par un système d'exploitation non autorisé.

Implémentation

Avant tout, les applications comme les réveils, les téléphones et les fonctionnalités d'accessibilité doit devenir android:directBootAware conformément à la Direct sur le démarrage.

Prise en charge du kernel

Le noyau est compatible avec le chiffrement Ext4 et F2FS noyaux, versions 3.18 et ultérieures. Pour l'activer dans un noyau équipé de la version 5.1 ou version ultérieure, utilisez: 

CONFIG_FS_ENCRYPTION=y

Pour les noyaux plus anciens, utilisez CONFIG_EXT4_ENCRYPTION=y si votre appareil Le système de fichiers userdata est Ext4, ou utilisez CONFIG_F2FS_FS_ENCRYPTION=y si userdata de votre appareil système de fichiers est F2FS.

Si votre appareil est compatible avec les stockage ou utiliseront des métadonnées le chiffrement sur la mémoire de stockage interne, d'activer les options de configuration du noyau nécessaires pour le 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 appareils les fabricants doivent également activer l'accélération cryptographique le chiffrement basé sur les fichiers et d’améliorer l'expérience utilisateur. Par exemple, sur Sur les appareils basés sur ARM64, l'accélération d'ARMv8 CE (Cryptography Extensions) peut être en définissant les options de configuration de 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 envisagez également d'implémenter du matériel de chiffrement intégré, qui chiffre/déchiffre les données lorsqu'elles sont en transit vers/depuis l'appareil de stockage. Les noyaux courants d'Android (version 4.14 et ultérieure) contiennent un framework qui permet d'utiliser le chiffrement intégré lorsque la prise en charge du matériel et des pilotes du fournisseur est disponibles. Vous pouvez activer le framework de chiffrement intégré en définissant les options de configuration de noyau suivantes: 

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Si votre appareil utilise un espace de stockage UFS, activez également: 

CONFIG_SCSI_UFS_CRYPTO=y

Si votre appareil utilise un stockage eMMC, activez également ce qui suit: 

CONFIG_MMC_CRYPTO=y

Activer le chiffrement basé sur les fichiers

Pour activer FBE sur un appareil, vous devez l'activer dans la mémoire de stockage interne (userdata). Cela permet également d'activer automatiquement FBE sur les stockage ; Toutefois, le format de chiffrement du stockage adoptable peut être ignoré si nécessaire.

Mémoire de stockage interne

FBE est activé en ajoutant l'option fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] dans la colonne fs_mgr_flags de la ligne fstab userdata Cette option définit le format de chiffrement des données stockage. Il contient jusqu'à trois paramètres séparés par le signe deux-points:

  • Le paramètre contents_encryption_mode définit un algorithme cryptographique est utilisé pour chiffrer le contenu des fichiers. Il peut s'agir de aes-256-xts ou adiantum. Depuis Android, 11, vous pouvez également le laisser vide pour indiquer algorithme par défaut, à savoir aes-256-xts.
  • Le paramètre filenames_encryption_mode définit un algorithme cryptographique est 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 prises en charge: <ph type="x-smartling-placeholder">
      </ph>
    • L'option v1 sélectionne les règles de chiffrement de la version 1. la L'option v2 sélectionne les règles de chiffrement de la version 2. Version Deux règles de chiffrement utilisent une fonction de dérivation de clé plus sécurisée et plus flexible. La valeur par défaut est v2 si L'appareil lancé sous Android 11 ou version ultérieure (tel que déterminé par ro.product.first_api_level) ou "v1" si l'appareil lancé sur Android 10 ou moins élevée.
    • L'option inlinecrypt_optimized sélectionne un chiffrement optimisé pour le matériel de chiffrement intégré pour gérer efficacement un grand nombre de clés. Pour ce faire, il génère une seule clé de chiffrement de contenu de fichier par clé CE ou DE, un par fichier. La génération de vecteurs d'initialisation ajustés en conséquence.
    • L'indicateur emmc_optimized est semblable à inlinecrypt_optimized, mais il sélectionne aussi un vecteur d'initialisation. de génération de texte qui limite les vecteurs d'initialisation à 32 bits. Cet indicateur ne doit être utilisée sur du matériel de chiffrement intégré conforme à la la spécification JEDEC eMMC v5.2 et n'est donc compatible qu'avec les charges de travail 32 bits Les vecteurs d'initialisation Sur un autre matériel de chiffrement intégré, utilisez inlinecrypt_optimized à la place. Cet indicateur ne doit jamais être utilisé sur un stockage UFS ; la spécification UFS permet d'utiliser des vecteurs d'initialisation 64 bits.
    • Sur les appareils compatibles avec les encapsulations matérielles clés, l'option wrappedkey_v0 permet d'utiliser clés encapsulées dans le matériel pour le FBE. Il ne peut être utilisé qu’en combinaison avec l'option d'installation inlinecrypt, et inlinecrypt_optimized ou emmc_optimized .
    • L'option dusize_4k force la taille de l'unité de données de chiffrement. soit de 4 096 octets, même si la taille du 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 le chiffrement du contenu. Cet indicateur est disponible depuis Android 15. Cet indicateur ne doit être utilisé que pour activer L'utilisation de matériel de chiffrement intégré qui n'est pas compatible avec blocs d'une taille supérieure à 4 096 octets, sur un appareil utilisant une taille de page de plus de 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 appareils est fileencryption=aes-256-xts. Si vous utilisez des fonctions matériel de chiffrement. Le paramètre recommandé pour la plupart des appareils est fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (ou fileencryption=::inlinecrypt_optimized équivalentes). Activé sans aucune forme d'accélération AES, vous pouvez utiliser Adiantum à la place de AES en configurant fileencryption=adiantum.

Depuis Android 14, AES-HCTR2 est le mode privilégié pour le chiffrement des noms de fichiers. pour les appareils avec des instructions de cryptographie accélérée. Toutefois, seuls les noyaux Android plus récents prennent en charge AES-HCTR2. Dans une prochaine version d'Android, il est prévu de devenir le mode par défaut pour les noms de fichiers le chiffrement. Si votre noyau prend en charge l'algorithme AES-HCTR2, vous pouvez l'activer pour le chiffrement des noms de fichiers en en définissant filenames_encryption_mode sur aes-256-hctr2. Dans le cas le plus simple cette opération est effectuée avec fileencryption=aes-256-xts:aes-256-hctr2.

Sur les appareils équipés d'Android 10 ou version antérieure, fileencryption=ice est également accepté pour spécifier l'utilisation de la classe Mode de chiffrement du contenu du fichier FSCRYPT_MODE_PRIVATE Ce mode est non implémentée par les noyaux Android courants, mais elle pourrait être implémentée en de fournisseurs tiers à l'aide de correctifs de noyau personnalisés. Format sur disque produit par ce mode était spécifique au fournisseur. Sur les appareils équipés d'Android 11 ou plus, ce mode n'est plus autorisé et le format de chiffrement standard doit être utilisé à la place.

Par défaut, le chiffrement du contenu d'un fichier est effectué à l'aide de la couche API Cryptography. Si vous préférez utiliser du matériel de chiffrement intégré à la place, Ajoutez l'option d'installation inlinecrypt. Par exemple, un La ligne fstab 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 stockage adoptable peuvent être utilisés conjointement.

Spécifier l'option fstab fileencryption pour De plus, userdata active automatiquement le FBE et le chiffrement des métadonnées sur les stockage. Toutefois, vous pouvez ignorer les formats de chiffrement de métadonnées et/ou de FBE stockage adoptable en définissant des propriétés dans PRODUCT_PROPERTY_OVERRIDES

Sur les appareils équipés d'Android 11 ou version ultérieure, utilisez les propriétés suivantes:

  • ro.crypto.volume.options (nouveau sur Android) 11) sélectionne le format de chiffrement FBE sur stockage adoptable. Elle a la même syntaxe que l'argument de la fonction fileencryption. Elle utilise les mêmes valeurs par défaut. Consultez les recommandations pour fileencryption ci-dessus afin de savoir quoi utiliser ici.
  • ro.crypto.volume.metadata.encryption sélectionne les métadonnées de chiffrement sur un espace de stockage adoptable. Consultez les métadonnées sur le chiffrement.

Sur les appareils équipés d'Android 10 ou version antérieure, utilisez les propriétés suivantes:

  • ro.crypto.volume.contents_mode sélectionne le contenu mode de chiffrement. Cela équivaut au premier champ de valeurs séparées par le signe deux-points de ro.crypto.volume.options
  • ro.crypto.volume.filenames_mode sélectionne les noms de fichiers mode de chiffrement. Cela équivaut au deuxième champ de valeurs séparées par le signe deux-points de ro.crypto.volume.options, sauf que le paramètre par défaut sur les appareils lancé avec Android 10 ou version antérieure est aes-256-heh Sur la plupart des appareils, il doit être explicitement remplacé par aes-256-cts.
  • ro.crypto.fde_algorithm et ro.crypto.fde_sector_size sélectionner le chiffrement des métadonnées sur un espace de stockage adoptable. Consultez les métadonnées sur le chiffrement.

Intégrer à Keymaster

L'HAL Keymaster doit être démarré dans la classe early_hal. En effet, FBE exige que Keymaster soit prêt à traiter les requêtes transmises par le La phase de démarrage de post-fs-data, qui correspond au moment où vold est configuré les clés initiales.

Exclusion de répertoires

init applique la clé DE système aux éléments suivants : tous les répertoires de premier niveau de /data, à l'exception de ceux qui ne doivent pas être chiffrés, par exemple le répertoire contenant la clé DE du système lui-même et les répertoires qui contiennent les répertoires CE ou DE de l’utilisateur. Clés de chiffrement s'appliquent de manière récursive et ne peuvent pas être remplacés par des sous-répertoires.

Dans Android 11 et versions ultérieures, init s'applique aux répertoires qui peuvent être contrôlés par l'argument encryption=<action> à mkdir dans les scripts d'initialisation. Les valeurs possibles de <action> sont les suivantes : documentées dans le Fichier README pour le langage init Android.

Sous Android 10, les actions de chiffrement init ont été 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 éviter que certains répertoires chiffrés. Si des modifications de ce type sont apportées, l'appareil le fabricant doit inclure Règles SELinux qui accordent uniquement l'accès les applications qui doivent utiliser le répertoire non chiffré. Cela devrait exclure tous des applications non approuvées.

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

Assurer la compatibilité avec 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 peut être défini au niveau de l'application. La L'attribut defaultToDeviceProtectedStorage n'est disponible que pour 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 étant compatibles avec le chiffrement.

L'attribut defaultToDeviceProtectedStorage redirige la valeur par défaut l'emplacement de stockage de l'application de sorte 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 et modifier les chemins d'accès des données sensibles pour utiliser le stockage CE. Appareil les fabricants qui utilisent cette option doivent inspecter soigneusement les données qu'ils stocker pour s'assurer qu'il ne contient aucune information personnelle.

Lors de l'exécution dans ce mode, les API système suivantes sont disponible pour gérer explicitement un contexte sauvegardé par le stockage CE si nécessaire, ce qui sont équivalentes à celles de l'API Device Protect.

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

Compatibilité avec plusieurs utilisateurs

Dans un environnement multi-utilisateur, chaque utilisateur reçoit une clé de chiffrement distincte. Tous les utilisateurs obtient deux clés: une clé DE et une clé CE. L'utilisateur 0 doit d'abord se connecter à l'appareil tel quel. un utilisateur spécial. Ceci est pertinent pour les appareils Administration.

Les applications utilisant le chiffrement interagissent entre les utilisateurs de la manière suivante: INTERACT_ACROSS_USERS et INTERACT_ACROSS_USERS_FULL permettent à une application d'agir sur tous les utilisateurs de l'appareil. Cependant, ces les applications n'ont accès qu'aux annuaires chiffrés par CE pour les utilisateurs déjà déverrouillée.

Même si une application peut interagir librement entre les différents pays d'Allemagne, ne signifie pas que tous les utilisateurs de l'appareil sont déverrouillés. La application doit vérifier cet état avant d'essayer d'accéder à ces zones.

Chaque ID utilisateur du profil professionnel est également associé à deux clés: DE et CE. Quand le défi du travail est satisfaite, l'utilisateur du profil est déverrouillé et le Keymaster (dans le TEE) peut fournir le 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 DE sur le "userdata". Il est vivement recommandé d'utiliser les appareils qui implémentent FBE OTA via des mises à jour du système A/B En tant que l'OTA peut être appliquée en fonctionnement normal. Aucune récupération n'est nécessaire accéder aux données sur le disque chiffré.

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

  1. Créez un répertoire de premier niveau (par exemple misc_ne) dans la section 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 qu'il contient. Seuls le processus ou les applications recevant des mises à jour OTA doivent capable de lire et écrire dans ce répertoire. Aucune autre demande ou processus devrait avoir accès à ce répertoire.

Validation

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

Si l'appareil est équipé d'Android 11 ou version ultérieure, exécutez également vts_kernel_encryption_test: 

atest vts_kernel_encryption_test

ou :

vts-tradefed run vts -m vts_kernel_encryption_test

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

  • Vérifier que ro.crypto.state existe
    • Assurez-vous que ro.crypto.state est chiffré
  • Vérifier que ro.crypto.type existe
    • Assurez-vous que ro.crypto.type est défini sur file

De plus, les testeurs peuvent vérifier que l'espace de stockage CE est verrouillé avant que l'appareil a été déverrouillé pour la première fois depuis le démarrage. Pour ce faire, utilisez un le build userdebug ou eng, de définir un code, un schéma ou mot de passe sur l’utilisateur principal et redémarrer l’appareil. Avant de déverrouiller l’appareil, exécutez la commande suivante pour vérifier le stockage CE de l'utilisateur principal. Si le l'appareil utilise un système headless Mode utilisateur (la plupart des appareils automobiles), l'utilisateur principal est l'utilisateur 10, alors exécutez: 

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

Sur les autres appareils (la plupart des autres appareils), l'utilisateur principal est l'utilisateur 0, donc exécuter:

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

Vérifiez que les noms de fichiers répertoriés sont encodés en base64, ce qui indique que le les noms de fichiers sont chiffrés et la clé permettant de les déchiffrer n’est pas encore disponible. Si les noms de fichiers sont listés en texte brut, il y a un problème.

Les fabricants d'appareils sont également encouragés à envisager d'exécuter les tests Linux en amont pour fscrypt sur leurs appareils. 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 pris en charge par Android.

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

Cette section fournit des détails sur l'implémentation d'AOSP et décrit comment le chiffrement basé sur les fichiers fonctionne. Les fabricants d'appareils ne devraient pas en avoir besoin de faire des modifications ici pour utiliser FBE et Démarrage direct sur leurs appareils.

chiffrement fscrypt

L’implémentation d’AOSP utilise « fscrypt » chiffrement (compatible avec ext4 et f2fs) dans le noyau et qui est normalement configuré pour:

  • Chiffrer le contenu des fichiers avec AES-256 en mode XTS
  • Chiffrer les noms de fichiers avec l'algorithme AES-256 en mode CBC-CTS

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

fscrypt prend en charge deux versions des règles de chiffrement: la version 1 et la version 2. La version 1 est obsolète, et les exigences du CDD pour les appareils lancés avec Android 11 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 répertorie les clés FBE et les répertoires qu’elles protègent dans d’autres détail:

Classe de stockage Description Répertoires
Pas de chiffrement Répertoires dans /data qui ne peuvent pas ou ne doivent pas l'être protégées par FBE. Sur les appareils qui utilisent des métadonnées chiffrement, ces répertoires ne sont pas vraiment non chiffrés, mais plutôt sont protégés par la clé de chiffrement des métadonnées, qui équivaut à Système DE.
  • /data/apex (non inclus) /data/apex/decompressed et /data/apex/ota_reserved, qui correspondent à
  • /data/lost+found
  • /data/preloads
  • /data/unencrypted
  • Tous les répertoires dont les sous-répertoires utilisent des clés FBE différentes. Pour exemple, étant donné que chaque répertoire /data/user/${user_id} utilise une clé par utilisateur, /data/user n'utilise aucune clé lui-même.
Système Allemagne Données chiffrées de l'appareil non associées à un utilisateur particulier
  • /data/apex/decompressed
  • /data/apex/ota_reserved
  • /data/app
  • /data/misc
  • /data/system
  • /data/vendor
  • Tous les autres sous-répertoires de /data que cette table n'est pas mentionnée comme ayant une classe différente
Par démarrage Fichiers système éphémères qui n'ont pas besoin de survivre à un redémarrage /data/per_boot
Certificat client de l'utilisateur (interne) Données chiffrées par identifiant de l'utilisateur dans la mémoire de stockage interne
  • /data/data (alias de /data/user/0)
  • /data/media/${user_id}
  • /data/misc_ce/${user_id}
  • /data/system_ce/${user_id}
  • /data/user/${user_id}
  • /data/vendor_ce/${user_id}
Utilisateur DE (interne) Données chiffrées par appareil par utilisateur dans la mémoire de stockage interne
  • /data/misc_de/${user_id}
  • /data/system_de/${user_id}
  • /data/user_de/${user_id}
  • /data/vendor_de/${user_id}
Ingénieur client utilisateur (adoption) Données chiffrées par identifiant par utilisateur sur le stockage adoptable
  • /mnt/expand/${volume_uuid}/media/${user_id}
  • /mnt/expand/${volume_uuid}/misc_ce/${user_id}
  • /mnt/expand/${volume_uuid}/user/${user_id}
Utilisateur DE (adoption) Données chiffrées par appareil par utilisateur sur un espace de stockage adoptable
  • /mnt/expand/${volume_uuid}/misc_de/${user_id}
  • /mnt/expand/${volume_uuid}/user_de/${user_id}

Stockage et protection des clés

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

Type de clé Emplacement de la clé Classe de stockage de l'emplacement de la clé
Clé DE du système /data/unencrypted Pas de chiffrement
Clés CE (internes) de l'utilisateur /data/misc/vold/user_keys/ce/${user_id} Système Allemagne
Clés DE utilisateur (internes) /data/misc/vold/user_keys/de/${user_id} Système Allemagne
Clés de chiffrement client (adoption) de l'utilisateur /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} Certificat client de l'utilisateur (interne)
Clés DE (adoption) de l'utilisateur /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} Utilisateur DE (interne)

Comme indiqué dans le tableau précédent, la plupart des clés FBE sont stockées dans des répertoires sont chiffrés par une autre clé FBE. Impossible de déverrouiller les clés tant que le stockage la classe qui les contient a été déverrouillée.

vold applique également une couche de chiffrement à toutes les clés FBE. Chaque clé outre les clés CE pour la mémoire de stockage interne, elle est chiffrée avec l'algorithme AES-256-GCM Keystore qui n'est pas à l'extérieur du TEE. Cela garantit que les clés FBE ne peuvent pas être déverrouillées à moins qu’un système d'exploitation approuvé a démarré, comme l'exige le Démarrage validé. Rollback la résistance est également demandée sur la clé du keystore, ce qui permet aux clés FBE être supprimés en toute sécurité sur les appareils sur lesquels Keymaster peut résister au rollback. En tant que une solution de secours si la résistance au rollback n'est pas disponible, hachage de 16 384 octets aléatoires stockés dans le fichier secdiscardable stocké en plus de la clé sert d'identifiant d'application tag de la clé Keystore. Tous ces octets doivent être récupérés Clé FBE.

Les clés CE destinées au stockage interne bénéficient d'un niveau de protection renforcé qui garantit il ne peut pas être déverrouillé sans connaître l'écran de verrouillage de l'utilisateur LSKF (code, schéma ou mot de passe), une méthode sécurisée jeton de réinitialisation du code secret, ou les deux clés côté client et côté serveur Opération Reprendre au redémarrage. Vous ne pouvez créer des jetons de réinitialisation de code secret que pour les profils professionnels. entièrement appareils 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 à entropie élevée qui est générées aléatoirement pour chaque utilisateur. LockSettingsService po system_server gère le mot de passe synthétique et la manière dont où elles sont protégées.

Pour protéger le mot de passe synthétique avec le LSKF, LockSettingsService étire d'abord la clé LSKF en la faisant passer par scrypt, en ciblant une durée d'environ 25 ms et d'environ 2 Mio. Étant donné que les valeurs LSKF sont généralement courtes, cette étape n'offre pas beaucoup de sécurité. La principale couche de sécurité est la sécurité par élément (SE) ou par TEE, comme décrit ci-dessous.

Si l'appareil est équipé d'un composant sécurisé (SE), LockSettingsService mappe la LSKF étirée à un secret aléatoire à haute entropie stocké dans le SE à l'aide de le HAL Weaver. LockSettingsService chiffre ensuite le mot de passe synthétique deux fois: d'abord avec une clé logicielle dérivée étendu LSKF et le secret Weaver, puis avec un keystore non lié à l'authentification . Cela permet de limiter le débit des suppositions LSKF à l'aide de l'SE.

Si l'appareil n'a pas de composant sécurisé, LockSettingsService à la place utilise le LSKF étiré comme Gatekeeper mot de passe. 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 de un fichier secdiscardable, puis avec une clé Keystore liée à l'authentification Inscription auprès de l'opérateur. Cela permet de limiter le débit des hypothèses LSKF à l'aide du TEE.

Lorsque le fichier LSKF est modifié, LockSettingsService supprime tout les informations associées à la liaison du mot de passe synthétique LSKF. Sur les appareils compatibles avec Weaver ou les clés Keystore résistantes aux rollbacks, garantit la suppression sécurisée de l'ancienne liaison. C'est pourquoi les protections décrites ici s'appliquent même si l'utilisateur ne dispose pas d'une clé LSKF.