Chiffrement basé sur les fichiers

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Android 7.0 et versions ultérieures sont compatibles avec le chiffrement basé sur les fichiers (FBE). Le chiffrement par fichier 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 possible.

Tous les appareils lancés avec 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é n'étaient pas disponibles et les téléphones ne pouvaient pas recevoir d'appels, mais étaient limités aux opérations de base du numéroteur d'urgence.

Avec l'introduction du chiffrement basé sur les fichiers (FBE) et de nouvelles API pour 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 personnelles.

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 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 rend les profils professionnels plus sécurisés, 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 de l'application a été modifié pour répondre à la nécessité de notifier 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 choisissent d'utiliser FBE peuvent 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. Toutefois, lorsque les fabricants d'appareils utilisent des versions personnalisées de ces applications, ils veulent s'assurer qu'il existe au moins des paquets compatibles avec le démarrage direct fournissant les services suivants:

• Services de téléphonie et clavier téléphonique
• Méthode de 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 lequel vold (system/vold) fournit la fonctionnalité de gestion des appareils 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 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 remplir les dépendances suivantes:

• Compatibilité du noyau avec le chiffrement Ext4 ou F2FS.
• Compatibilité avec Keymaster avec la version 1.0 ou ultérieure de HAL. Keymaster 0.3 n'est pas pris en charge, car il ne fournit pas les fonctionnalités nécessaires ni ne garantit 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 protéger les clés de déverrouillage d'appareil afin qu'un OS non autorisé (OS personnalisé flashé sur l'appareil) ne puisse pas simplement demander les clés de déverrouillage d'appareil.
• La racine de confiance matérielle et le démarrage validé associés à l'initialisation de Keymaster sont nécessaires pour s'assurer que les clés de chiffrement côté client 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 noyau

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 de 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 nécessaires au 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 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 ARM64, l'accélération ARMv8 CE (Cryptography Extensions) peut être activée en définissant les options de configuration du kernel 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 d'implémenter un matériel de chiffrement en ligne, qui chiffre/déchiffre les données pendant leur transfert vers/depuis l'appareil de stockage. Les noyaux communs 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 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 basé sur eMMC, activez également les éléments suivants:

CONFIG_MMC_CRYPTO=y

Activer le chiffrement basé sur les fichiers

Pour activer le FBE sur un appareil, vous devez l'activer sur le stockage interne (userdata). Le FBE est également automatiquement activé sur le stockage adoptable. Toutefois, le format de chiffrement sur le stockage adoptable peut être ignoré si nécessaire.

Mémoire de stockage interne

La FBE est activée 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 chiffrement sur le 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 règles de chiffrement de la version 1. L'indicateur v2 sélectionne les règles 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 flexible. La valeur par défaut est v2 si l'appareil a été lancé sur Android 11 ou version ultérieure (comme déterminé par ro.product.first_api_level), ou v1 si l'appareil a été lancé sur Android 10 ou version antérieure.
  • 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 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 des IV (vectors 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 en ligne conforme à la spécification JEDEC eMMC v5.2 et ne prend donc en charge que les IV de 32 bits. Sur d'autres appareils 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 autorise l'utilisation d'IV 64 bits.
  • Sur les appareils compatibles avec les clés encapsulées matériellement, l'indicateur 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'indicateur dusize_4k force la taille de l'unité de données de chiffrement à 4 096 octets, même lorsque la taille de 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 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 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 noyau personnalisés. Le format sur disque généré 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 en ligne, ajoutez également l'option de montage inlinecrypt. Par exemple, une ligne fstab complète 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 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 (nouveau dans 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 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 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 séparé par deux-points de ro.crypto.volume.options.
• ro.crypto.volume.filenames_mode sélectionne le mode de chiffrement 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 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

Le HAL Keymaster doit être démarré dans la classe early_hal. En effet, FBE exige que Keymaster soit prêt à gérer les requêtes lors de la phase de démarrage post-fs-data, c'est-à-dire lorsque 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.

Sous 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 README pour le langage d'initialisation 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 apportées, le fabricant de l'appareil doit inclure des règles SELinux qui n'autorisent 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 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 de l'application par défaut vers le stockage DE au lieu du stockage CE. Les applications système qui utilisent cet indicateur doivent auditer attentivement toutes les données stockées à 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.

Lorsque vous exécutez ce mode, les API système suivantes sont disponibles pour gérer explicitement un contexte basé sur le stockage CE si nécessaire, ce qui équivaut à leurs homologues protégés par l'appareil.

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

Prendre en charge plusieurs utilisateurs

Chaque utilisateur d'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. 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 de profil professionnel reçoit également 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 racine pour y placer les packages OTA.
4. Ajoutez une règle SELinux et des contextes de fichier pour contrôler l'accès à ce répertoire et à son contenu. Seul 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 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

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.
  • Vérifier 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 l'espace de stockage CE de l'utilisateur principal. Si l'appareil utilise le mode utilisateur du système headless (la plupart des appareils automobiles), l'utilisateur principal est l'utilisateur 10. Exécutez donc:

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, un problème est survenu.

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. Toutefois, 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 besoin d'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 pris en charge. Lorsque le chiffrement Adiantum est activé, le contenu et le nom 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 du 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 présente 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 stockée du tout. Le tableau suivant indique les emplacements où 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 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é. La résistance au rollback est également demandée pour la clé Keystore, ce qui permet de supprimer de manière sécurisée les clés FBE sur les appareils où Keymaster est compatible avec 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 Tag::APPLICATION_ID 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 bénéficient d'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 (code, schéma ou mot de passe), un jeton de réinitialisation du mot de passe sécurisé, ou les clés côté client et côté serveur pour une opération de reprise au redémarrage. Les jetons de réinitialisation du code secret ne sont autorisé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 haute entropie immuable 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 la clé LSKF, LockSettingsService étire d'abord la clé LSKF en la transmettant via scrypt, en ciblant un temps d'environ 25 ms et une utilisation de la mémoire d'environ 2 Mo. Étant donné que les clés LSKF sont généralement courtes, cette étape ne fournit généralement pas beaucoup de sécurité. La couche de sécurité principale est l'élément sécurisé (SE) ou la limitation de débit appliquée par le TEE décrite ci-dessous.

Si l'appareil dispose d'un élément sécurisé (SE), LockSettingsService mappe la clé LSKF étirée sur 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 de 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 en TEE.

Lorsque le LSKF est modifié, LockSettingsService supprime toutes les informations associées à l'association 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. C'est pourquoi les protections décrites ici sont appliquées même si l'utilisateur ne dispose pas d'un LSKF.