Chiffrement basé sur les fichiers

Android 7.0 et versions ultérieures sont compatibles 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 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 Direct Boot pour offrir aux utilisateurs la meilleure expérience et la plus sécurisée possible.

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

Démarrage direct

Le chiffrement basé sur les fichiers permet d'utiliser une nouvelle fonctionnalité introduite dans Android 7.0 appelée démarrage direct. Le démarrage direct permet aux appareils chiffrés de démarrer directement sur l'écran de verrouillage. Auparavant, sur les appareils chiffrés utilisant le chiffrement de disque complet (FDE), les utilisateurs devaient fournir des identifiants avant de pouvoir accéder à des données, ce qui empêchait le téléphone d'effectuer toutes les opérations, sauf les plus basiques. Par exemple, les alarmes ne pouvaient pas fonctionner, les services d'accessibilité étaient indisponibles et les téléphones ne pouvaient pas recevoir d'appels, mais se limitaient aux opérations de base du clavier d'urgence.

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

Sur un appareil compatible avec FBE, deux emplacements de stockage sont disponibles pour les applications :

  • Stockage chiffré par identifiants (CE), qui est l'emplacement de stockage par défaut et qui n'est disponible qu'une fois l'appareil déverrouillé par l'utilisateur.
  • Stockage chiffré de l'appareil (DE), un emplacement de stockage disponible en mode Démarrage direct et après le déverrouillage de l'appareil par l'utilisateur

Cette séparation renforce la sécurité des profils professionnels, car elle permet de protéger plusieurs utilisateurs à la fois, car le chiffrement n'est plus basé uniquement sur un mot de passe au démarrage.

L'API Démarrage direct permet aux applications compatibles avec le chiffrement d'accéder à chacune de ces zones. Le cycle de vie des applications a été modifié pour tenir compte de la nécessité d'informer les applications lorsque l'espace de stockage CE d'un utilisateur est déverrouillé en réponse à la première saisie d'identifiants sur l'écran de verrouillage, ou dans le cas d'un profil professionnel fournissant un défi professionnel. Les appareils équipés d'Android 7.0 doivent prendre en charge ces nouvelles API et ces nouveaux cycles de vie, qu'ils implémentent FBE ou non. Toutefois, sans FBE, le stockage DE et CE est toujours dans 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 décident d'utiliser FBE peuvent explorer les moyens d'optimiser la fonctionnalité en fonction du SoC (système sur puce) utilisé.

Tous les packages nécessaires dans AOSP ont été mis à jour pour être compatibles avec le démarrage direct. Toutefois, lorsque les fabricants d'appareils utilisent des versions personnalisées de ces applications, ils souhaitent s'assurer au minimum que des packages compatibles avec le démarrage direct fournissent 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) fournit la fonctionnalité permettant de gérer les périphériques de stockage et les volumes sur Android. L'ajout de FBE fournit à Vold plusieurs nouvelles commandes permettant de gérer les clés CE et DE de plusieurs utilisateurs. En plus des modifications de base pour utiliser les fonctionnalités de chiffrement basées sur les fichiers dans le noyau, de nombreux packages système, y compris l'écran de verrouillage et SystemUI, ont été modifiés pour prendre en charge les fonctionnalités FBE et Direct Boot. En voici quelques exemples :

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

* Applications système qui utilisent l'attribut de fichier manifeste defaultToDeviceProtectedStorage

Pour obtenir d'autres exemples d'applications et de services compatibles avec le chiffrement, exécutez la commande mangrep directBootAware dans le répertoire des frameworks ou des packages de l'arborescence source AOSP.

Dépendances

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

  • Prise en charge du noyau pour le chiffrement Ext4 ou F2FS.
  • Compatibilité avec Keymaster avec la version 1.0 ou une version ultérieure de HAL. Keymaster 0.3 n'est pas compatible, car il ne fournit pas les fonctionnalités nécessaires ni n'assure une protection suffisante des clés de chiffrement.
  • Keymaster/Keystore et Gatekeeper doivent être implémentés dans un environnement d'exécution sécurisé (TEE) pour protéger les clés de déverrouillage des appareils afin qu'un OS non autorisé (OS personnalisé flashé sur l'appareil) ne puisse pas simplement demander les clés de déverrouillage des appareils.
  • La racine matérielle de confiance et le démarrage validé liés à l'initialisation du Keymaster sont nécessaires pour garantir que les clés DE ne sont pas accessibles par un système d'exploitation non autorisé.

Implémentation

Tout d'abord, les applications telles que les réveils, le téléphone et les fonctionnalités d'accessibilité doivent être définies comme android:directBootAware, conformément à la documentation destinée aux développeurs sur le démarrage direct.

Prise en charge du kernel

La prise en charge du noyau pour le chiffrement Ext4 et F2FS est disponible dans les noyaux communs Android, version 3.18 et ultérieure. Pour l'activer dans un noyau version 5.1 ou ulté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 CONFIG_F2FS_FS_ENCRYPTION=y si le système de fichiers userdata de votre appareil est F2FS.

Si votre appareil est compatible avec le stockage adoptable ou utilise le chiffrement des métadonnées sur le stockage interne, activez également les options de configuration du noyau requises pour le chiffrement des métadonnées, comme décrit dans la documentation sur le chiffrement des métadonnées.

En plus de la compatibilité fonctionnelle avec le 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, vous pouvez activer l'accélération d'ARMv8 CE (Cryptography Extensions) 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 également envisager de mettre en œuvre du matériel de chiffrement intégré, qui chiffre/déchiffre les données en transit depuis ou vers l'appareil de stockage. Les noyaux courants d'Android (version 4.14 ou ultérieure) contiennent un framework qui permet d'utiliser le chiffrement intégré lorsque la compatibilité du matériel et des pilotes de fournisseurs est disponible. Vous pouvez activer le framework de chiffrement intégré 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 les éléments suivants : 

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

L'activation du FBE sur un appareil nécessite de l'activer dans la mémoire de stockage interne (userdata). Cela active également automatiquement le FBE sur le stockage adoptable. Toutefois, le format de chiffrement sur le stockage adoptable peut être ignoré si nécessaire.

Mémoire de stockage interne

Pour activer FBE, ajoutez l'option fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] à la colonne fs_mgr_flags de la ligne fstab pour userdata. Cette option définit le format de chiffrement dans la mémoire de stockage interne. Elle contient jusqu'à trois paramètres séparés par deux-points :

  • Le paramètre contents_encryption_mode définit l'algorithme cryptographique utilisé pour chiffrer le contenu des fichiers. Il peut s'agir de aes-256-xts ou de adiantum. Depuis Android 11, vous pouvez également le laisser vide pour spécifier l'algorithme par défaut, qui est aes-256-xts.
  • Le paramètre filenames_encryption_mode définit l'algorithme cryptographique utilisé pour chiffrer les noms de fichiers. Il peut s'agir de aes-256-cts, aes-256-heh, adiantum ou aes-256-hctr2. Si aucune valeur n'est spécifiée, la valeur par défaut est aes-256-cts si contents_encryption_mode est aes-256-xts ou adiantum si contents_encryption_mode est adiantum.
  • Le paramètre flags, nouveau dans Android 11, est une liste d'indicateurs séparés par le caractère +. Les options suivantes sont acceptées :
    • L'indicateur v1 sélectionne les stratégies de chiffrement de la version 1. L'indicateur v2 sélectionne les stratégies de chiffrement de la version 2. Les règles de chiffrement de la version 2 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 a été lancé sous Android 11 ou version ultérieure (comme déterminé par ro.product.first_api_level), ou v1 si l'appareil a été lancé sous Android 10 ou version antérieure.
    • L'option inlinecrypt_optimized sélectionne un format de chiffrement optimisé pour le matériel de chiffrement intégré qui ne gère pas efficacement un grand nombre de clés. Pour ce faire, il ne dérive qu'une seule clé de chiffrement du contenu de fichier par clé CE ou DE, plutôt qu'une par fichier. La génération de vecteurs d'initialisation (vecteurs d'initialisation) est ajustée en conséquence.
    • L'indicateur emmc_optimized est semblable à inlinecrypt_optimized, mais il sélectionne également une méthode de génération d'IV qui limite les IV à 32 bits. Cet indicateur ne doit être utilisé que sur le matériel de chiffrement intégré conforme à la spécification JEDEC eMMC v5.2 et n'est donc compatible qu'avec les vecteurs d'initialisation 32 bits. Sur un autre matériel de chiffrement intégré, utilisez plutôt inlinecrypt_optimized. Cette option ne doit jamais être utilisée sur le stockage UFS ; la spécification UFS autorise l'utilisation de vecteurs d'initialisation 64 bits.
    • Sur les appareils compatibles avec les clés encapsulées dans le matériel, l'option wrappedkey_v0 permet d'utiliser des clés encapsulées matériellement pour le FBE. Cette option ne peut être utilisée qu'avec l'option de montage inlinecrypt et l'indicateur inlinecrypt_optimized ou emmc_optimized.
    • L'option dusize_4k force la taille de l'unité de données de chiffrement à 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 du chiffrement du contenu des fichiers. Cet indicateur est disponible depuis Android 15. Cet indicateur ne doit être utilisé que pour activer l'utilisation d'un matériel de chiffrement en ligne qui n'est pas compatible avec les unités de données supérieures à 4 096 octets, sur un appareil qui utilise une taille de page supérieure à 4 096 octets et qui utilise le système de fichiers f2fs.

Si vous n'utilisez pas de matériel de chiffrement intégré, le paramètre recommandé pour la plupart des appareils est fileencryption=aes-256-xts. Si vous utilisez 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 fileencryption=::inlinecrypt_optimized). Sur les appareils sans aucune forme d'accélération AES, Adiantum peut être utilisé à la place d'AES en définissant fileencryption=adiantum.

Depuis Android 14, AES-HCTR2 est le mode de chiffrement des noms de fichiers privilégié pour les appareils dotés d'instructions de cryptographie accélérées. Toutefois, seuls les noyaux Android plus récents sont compatibles avec AES-HCTR2. Dans une prochaine version d'Android, il devrait devenir le mode par défaut pour le chiffrement des noms de fichiers. Si votre kernel est compatible avec AES-HCTR2, vous pouvez l'activer pour le chiffrement des noms de fichiers en définissant filenames_encryption_mode sur aes-256-hctr2. Dans le cas le plus simple, cela se fait avec fileencryption=aes-256-xts:aes-256-hctr2.

Sur les appareils lancés avec Android 10 ou version antérieure, fileencryption=ice est également accepté pour spécifier l'utilisation du mode de chiffrement du contenu des fichiers FSCRYPT_MODE_PRIVATE. Ce mode n'est pas implémenté par les noyaux communs Android, mais il peut être implémenté par les fournisseurs à l'aide de correctifs de kernel personnalisés. Le format sur disque produit par ce mode était spécifique au fournisseur. Sur les appareils lancés avec Android 11 ou version ultérieure, ce mode n'est plus autorisé et un format de chiffrement standard doit être utilisé à la place.

Par défaut, le chiffrement du contenu des fichiers est effectué à l'aide de l'API de cryptographie du noyau Linux. Si vous préférez utiliser du matériel de chiffrement intégré, ajoutez également l'option d'installation inlinecrypt. Par exemple, une ligne fstab complète peut ressembler à ceci: 

/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.

Spécifier l'option fstab fileencryption pour userdata active également automatiquement à la fois le FBE et le chiffrement des métadonnées sur le stockage adoptable. Toutefois, vous pouvez remplacer les formats de chiffrement FBE 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 (nouveauté sous Android 11) sélectionne le format de chiffrement FBE sur le stockage adoptable. Il a la même syntaxe que l'argument de l'option fstab fileencryption et 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 le format de chiffrement des métadonnées sur le stockage adoptable. Consultez la documentation sur le chiffrement des métadonnées.

Sur les appareils lancés avec Android 10 ou version antérieure, utilisez les propriétés suivantes:

  • ro.crypto.volume.contents_mode sélectionne le mode de chiffrement des contenus. Cela équivaut au premier champ de ro.crypto.volume.options, séparés par des deux-points.
  • ro.crypto.volume.filenames_mode sélectionne le mode de chiffrement des noms de fichiers. Cela équivaut au deuxième champ de ro.crypto.volume.options séparés par un signe deux-points, sauf que la valeur par défaut sur les appareils lancés avec Android 10 ou version antérieure est aes-256-heh. Sur la plupart des appareils, ce paramètre doit être remplacé explicitement 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é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 lors de la phase de démarrage post-fs-data, qui correspond au moment où vold configure les clés initiales.

Exclure des répertoires

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

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

Dans Android 10, les actions de chiffrement init étaient codées en dur à l'emplacement suivant : 

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Sous Android 9 et versions antérieures, l'emplacement était le suivant : 

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Vous pouvez ajouter des exceptions pour empêcher le chiffrement de certains répertoires. Si des modifications de ce type sont effectuées, le fabricant de l'appareil doit inclure des règles SELinux qui n'accordent l'accès qu'aux applications devant utiliser le répertoire non chiffré. Cela devrait exclure toutes les applications non approuvées.

Le seul cas d'utilisation acceptable connu à cet égard concerne les anciennes fonctionnalités OTA.

Prendre en charge le démarrage direct dans les applications système

Rendre les applications compatibles avec le Démarrage direct

Pour faciliter la migration rapide des applications système, deux nouveaux attributs peuvent être définis au niveau de l'application. L'attribut defaultToDeviceProtectedStorage n'est disponible que pour les applications système. L'attribut directBootAware est disponible pour tous. 

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

L'attribut directBootAware au niveau de l'application permet de marquer tous les composants de l'application comme compatibles avec le chiffrement.

L'attribut defaultToDeviceProtectedStorage redirige l'emplacement de stockage par défaut 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 l'emplacement par défaut et modifier les chemins d'accès des données sensibles pour utiliser le stockage CE. Les fabricants d'appareils qui utilisent cette option doivent inspecter attentivement 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 sauvegardé par le stockage CE si nécessaire, ce qui équivaut à leurs homologues de protection de l'appareil.

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

Compatibilité multi-utilisateur

Dans un environnement multi-utilisateur, chaque utilisateur reçoit une clé de chiffrement distincte. Chaque utilisateur reçoit deux clés : une clé DE et une clé CE. L'utilisateur 0 doit d'abord se connecter à l'appareil, car il s'agit d'un utilisateur spécial. Cela est pertinent pour les utilisations de la gestion des appareils.

Les applications compatibles avec la cryptographie 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. Toutefois, ces applications ne peuvent accéder qu'aux répertoires chiffrés par CE pour les utilisateurs déjà déverrouillés.

Une application peut être en mesure d'interagir librement dans les zones de déverrouillage, mais le déverrouillage d'un utilisateur 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 du profil professionnel est également associé à deux clés: DE et CE. Lorsque le défi professionnel est relevé, l'utilisateur du profil est déverrouillé et Keymaster (dans le TEE) peut fournir la clé TEE du profil.

Gérer les mises à jour

La partition de récupération ne peut pas accéder au stockage protégé par DE sur la partition userdata. Nous vous recommandons vivement d'utiliser les mises à jour du système A/B pour les appareils implémentant FBE. Étant donné que la mise à jour OTA peut être appliquée en fonctionnement normal, aucune récupération n'est nécessaire pour 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 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 fichiers pour contrôler l'accès à ce répertoire et à son contenu. Seuls le processus ou les applications recevant des mises à jour OTA doivent pouvoir lire et écrire dans ce répertoire. Aucune autre application ni aucun autre processus ne doit avoir accès à ce répertoire.

Validation

Pour vous assurer que la version mise en œuvre 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érifiez que ro.crypto.state existe.
    • Assurez-vous que ro.crypto.state est chiffré
  • Vérifiez 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 ne soit déverrouillé pour la première fois depuis le démarrage. Pour ce faire, utilisez une version userdebug ou eng, définissez un code, un schéma ou un mot de passe pour l'utilisateur principal, puis redémarrez l'appareil. Avant de déverrouiller l'appareil, exécutez la commande suivante pour vérifier le stockage CE de l'utilisateur principal. Si l'appareil utilise le mode utilisateur système headless (la plupart des appareils automobiles), l'utilisateur principal est l'utilisateur 10. Exécutez la commande suivante: 

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

Sur d'autres appareils (la plupart des appareils autres que ceux du secteur automobile), l'utilisateur principal est l'utilisateur 0. Exécutez donc :

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

Vérifiez que les noms de fichiers listés sont encodés en base64, ce qui indique qu'ils sont chiffrés et que la clé de déchiffrement 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 invités à exécuter les tests Linux en amont pour fscrypt sur leurs appareils ou leurs 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 compatibles avec Android.

Détails de l'implémentation AOSP

Cette section fournit des informations sur l'implémentation d'AOSP et décrit le fonctionnement du chiffrement basé sur les fichiers. Les fabricants d'appareils ne devraient pas avoir à apporter de modifications ici pour utiliser FBE et le démarrage direct sur leurs appareils.

Chiffrement fscrypt

L'implémentation AOSP utilise le chiffrement "fscrypt" (compatible avec ext4 et f2fs) dans le noyau et est normalement configurée comme suit :

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

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

fscrypt accepte deux versions de stratégies de chiffrement : la version 1 et la version 2. La version 1 est obsolète, et les exigences concernant le CDD pour les appareils lancés avec Android 11 ou version ultérieure ne sont compatibles qu'avec la version 2. Les règles de chiffrement de la version 2 utilisent HKDF-SHA512 pour dériver 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 kernel en amont.

Classes de stockage

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

Classe de stockage Description Répertoires
Pas de chiffrement Répertoires de /data qui ne peuvent pas ou n'ont pas besoin d'être protégés par FBE. Sur les appareils qui utilisent le chiffrement des métadonnées, ces répertoires ne sont pas véritablement non chiffrés, mais sont protégés par la clé de chiffrement des métadonnées, qui équivaut à la clé DE du système.
  • /data/apex, à l'exception de /data/apex/decompressed et /data/apex/ota_reserved, qui sont des valeurs système DE
  • /data/lost+found
  • /data/preloads
  • /data/unencrypted
  • Tous les répertoires dont les sous-répertoires utilisent des clés FBE différentes. Par exemple, comme chaque répertoire /data/user/${user_id} utilise une clé par utilisateur, /data/user n'utilise aucune clé.
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 ne mentionne pas comme ayant une classe différente
Par démarrage Fichiers système éphémères qui ne doivent pas survivre à un redémarrage /data/per_boot
Ingénieur client utilisateur (interne) Données chiffrées par identifiant utilisateur sur l'espace 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 et par utilisateur sur le stockage interne
  • /data/misc_de/${user_id}
  • /data/system_de/${user_id}
  • /data/user_de/${user_id}
  • /data/vendor_de/${user_id}
CE utilisateur (adaptable) 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}
DE utilisateur (adaptable) 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 disque, à l'exception de la clé par démarrage, qui n'est pas stockée du tout. Le tableau suivant indique les emplacements où les différentes clés FBE sont stockées :

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 utilisateur DE (internes) /data/misc/vold/user_keys/de/${user_id} Système Allemagne
Clés CE (adoptables) utilisateur /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} CE utilisateur (interne)
Clés DE (adoptables) 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 de FBE sont stockées dans des répertoires chiffrés par une autre clé FBE. Les clés ne peuvent pas être déverrouillées tant que la classe de stockage qui les contient n'a pas été déverrouillée.

vold applique également une couche de chiffrement à toutes les clés FBE. Toutes les clés, à l'exception des clés CE pour le stockage interne, sont chiffrées avec AES-256-GCM à l'aide de leur propre clé Keystore qui n'est pas exposée en dehors du TEE. Cela garantit que les clés FBE ne peuvent pas être déverrouillées tant qu'un système d'exploitation approuvé n'a pas démarré, comme l'exige le démarrage validé. Une résistance au rollback est également demandée sur la clé Keystore, ce qui permet de supprimer de manière sécurisée les clés FBE sur les appareils où Keymaster permet la résistance au rollback. En cas de non-disponibilité de la résistance au rollback, le hachage SHA-512 de 16 384 octets aléatoires stockés dans le fichier secdiscardable stocké à côté de la clé est utilisé comme balise d'ID 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 la mémoire de stockage interne bénéficient d'un niveau de protection renforcé qui garantit qu'elles ne peuvent pas être déverrouillées sans connaître le facteur de connaissance de l'écran de verrouillage (LSKF) (code, schéma ou mot de passe), un jeton de réinitialisation de code secret sécurisé, ou les deux clés côté client et côté serveur pour une opération Resume-on-Restart (Reprendre au redémarrage). Les jetons de réinitialisation de code secret ne peuvent être créés que pour les profils professionnels et les appareils entièrement gérés.

Pour ce faire, vold chiffre chaque clé CE pour le stockage interne à l'aide d'une clé AES-256-GCM dérivée du mot de passe synthétique de l'utilisateur. Le mot de passe synthétique est un secret cryptographique immuable à entropie élevée, généré de manière aléatoire pour chaque utilisateur. LockSettingsService dans system_server gère le mot de passe synthétique et les méthodes de protection.

Pour protéger le mot de passe synthétique avec le LSKF, LockSettingsService étire d'abord le LSKF en le transmettant via scrypt, en ciblant un temps d'environ 25 ms et une utilisation de la mémoire d'environ 2 Mo. Les fichiers LSKF étant généralement courts, cette étape n'offre généralement pas un niveau de sécurité élevé. La principale couche de sécurité est l'élément sécurisé (SE) ou la limitation du débit imposée par le TEE décrite ci-dessous.

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

Si l'appareil ne dispose pas d'un SE, LockSettingsService utilise à la place le LSKF étiré comme mot de passe Gatekeeper. LockSettingsService chiffre ensuite le mot de passe synthétique deux fois : d'abord avec une clé logicielle dérivée de la clé LSKF étirée et du hachage d'un fichier secdiscardable, puis avec une clé Keystore liée à l'enregistrement Gatekeeper. Cela permet de limiter le débit des suppositions LSKF via le TEE.

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 compatibles avec Weaver ou les clés Keystore résistantes au rollback, cela garantit la suppression sécurisée de l'ancienne liaison. Pour cette raison, les protections décrites ici s'appliquent même lorsque l'utilisateur ne dispose pas d'une valeur LSKF.