Chiffrement complet de disque

Le chiffrement complet du disque consiste à encoder toutes les données utilisateur sur un appareil Android à l'aide d'une clé chiffrée. Une fois un appareil chiffré, toutes les données créées par l'utilisateur sont automatiquement chiffrées avant d'être écrites sur le disque, et toutes les lectures déchiffrent automatiquement les données avant de les renvoyer au processus appelant.

Le chiffrement de disque complet a été introduit dans Android 4.4, mais Android 5.0 a ajouté les nouvelles fonctionnalités suivantes :

• Création d'un chiffrement rapide, qui ne chiffre que les blocs utilisés sur la partition de données pour éviter que le premier démarrage ne prenne trop de temps. Seuls les systèmes de fichiers ext4 et f2fs sont actuellement compatibles avec le chiffrement rapide.
• Ajout de l'indicateur fstab forceencrypt pour chiffrer au premier démarrage.
• Ajout de la compatibilité avec les schémas et le chiffrement sans mot de passe.
• Ajout du stockage de la clé de chiffrement reposant sur le matériel à l'aide de la fonctionnalité de signature de l'environnement d'exécution sécurisé (TEE), comme dans une TrustZone. Pour en savoir plus, consultez Stocker la clé chiffrée.

Attention : Les appareils mis à niveau vers Android 5.0, puis chiffrés, peuvent être ramenés à un état non chiffré en rétablissant la configuration d'usine. Les nouveaux appareils Android 5.0 chiffrés au premier démarrage ne peuvent pas être ramenés à un état non chiffré.

Fonctionnement du chiffrement complet du disque Android

Le chiffrement complet du disque Android est basé sur dm-crypt, qui est une fonctionnalité du noyau fonctionnant au niveau de la couche du périphérique de bloc. C'est pourquoi le chiffrement fonctionne avec les cartes multimédias intégrées (eMMC) et les périphériques flash similaires qui se présentent au noyau en tant que périphériques de bloc. Le chiffrement n'est pas possible avec YAFFS, qui communique directement avec une puce NAND brute.

L'algorithme de chiffrement est AES (Advanced Encryption Standard) 128 bits avec CBC (Cipher-Block Chaining) et ESSIV:SHA256. La clé principale est chiffrée avec AES 128 bits via des appels à la bibliothèque OpenSSL. Vous devez utiliser une clé de 128 bits ou plus (256 bits étant facultatif).

Remarque : Les OEM peuvent utiliser un chiffrement de 128 bits ou plus pour la clé principale.

Dans la version 5.0 d'Android, il existe quatre types d'états de chiffrement :

• par défaut
• Code
• mot de passe
• schéma

Au premier démarrage, l'appareil crée une clé principale de 128 bits générée de manière aléatoire, puis la hache avec un mot de passe par défaut et un sel stocké. Le mot de passe par défaut est "default_password". Toutefois, le hachage résultant est également signé via un TEE (tel que TrustZone), qui utilise un hachage de la signature pour chiffrer la clé principale.

Vous trouverez le mot de passe par défaut défini dans le fichier cryptfs.cpp du projet Android Open Source.

Lorsque l'utilisateur définit le code ou le mot de passe sur l'appareil, seule la clé de 128 bits est à nouveau chiffrée et stockée. (Par exemple, les modifications du code, du mot de passe ou du schéma de l'utilisateur n'entraînent PAS le rechiffrement des données utilisateur.) Notez qu'un appareil géré peut être soumis à des restrictions concernant le code, le schéma ou le mot de passe.

Le chiffrement est géré par init et vold. init appelle vold, et vold définit les propriétés pour déclencher des événements dans init. D'autres parties du système examinent également les propriétés pour effectuer des tâches telles que l'état du rapport, la demande de mot de passe ou l'invite à réinitialiser les paramètres d'usine en cas d'erreur fatale. Pour appeler les fonctionnalités de chiffrement dans vold, le système utilise les commandes cryptfs de l'outil de ligne de commande vdc : checkpw, restart, enablecrypto, changepw, cryptocomplete, verifypw, setfield, getfield, mountdefaultencrypted, getpwtype, getpw et clearpw.

Pour chiffrer, déchiffrer ou effacer /data, /data ne doit pas être monté. Toutefois, pour afficher une interface utilisateur, le framework doit démarrer et nécessite /data pour s'exécuter. Pour résoudre ce problème, un système de fichiers temporaire est installé sur /data. Cela permet à Android d'inviter l'utilisateur à saisir des mots de passe, d'afficher la progression ou de suggérer un effacement des données si nécessaire. Il impose toutefois une limite : pour passer du système de fichiers temporaire au véritable système de fichiers /data, le système doit arrêter tous les processus avec des fichiers ouverts sur le système de fichiers temporaire et redémarrer ces processus sur le véritable système de fichiers /data. Pour ce faire, tous les services doivent appartenir à l'un des trois groupes suivants : core, main et late_start.

• core : ne jamais arrêter après le démarrage.
• main : Arrêtez, puis redémarrez l'ordinateur après avoir saisi le mot de passe du disque.
• late_start : ne démarre qu'après le déchiffrement et le montage de /data.

Pour déclencher ces actions, la propriété vold.decrypt est définie sur différentes chaînes. Pour arrêter et redémarrer des services, les commandes init sont les suivantes :

• class_reset : arrête un service, mais permet de le redémarrer avec class_start.
• class_start : redémarre un service.
• class_stop : arrête un service et ajoute un indicateur SVC_DISABLED. Les services arrêtés ne répondent pas à class_start.

Flows

Il existe quatre flux pour un appareil chiffré. Un appareil n'est chiffré qu'une seule fois, puis suit une procédure de démarrage normale.

• Chiffrer un appareil qui ne l'était pas :
  • Chiffrez un nouvel appareil avec forceencrypt : chiffrement obligatoire au premier démarrage (à partir d'Android L).
  • Chiffrer un appareil existant : chiffrement initié par l'utilisateur (Android K et versions antérieures).
• Démarrer un appareil chiffré :
  • Démarrer un appareil chiffré sans mot de passe : démarrer un appareil chiffré sans mot de passe défini (pertinent pour les appareils équipés d'Android 5.0 et versions ultérieures).
  • Démarrage d'un appareil chiffré avec un mot de passe : démarrage d'un appareil chiffré pour lequel un mot de passe a été défini.

En plus de ces flux, l'appareil peut également ne pas réussir à chiffrer /data. Chacun de ces flux est expliqué en détail ci-dessous.

Chiffrer un nouvel appareil avec forceencrypt

Il s'agit du premier démarrage normal pour un appareil Android 5.0.

1. Détecter un système de fichiers non chiffré avec l'indicateur forceencrypt

   /data n'est pas chiffré, mais il doit l'être, car forceencrypt l'exige. Démontez /data.

2. Commencer le chiffrement /data

   vold.decrypt = "trigger_encryption" déclenche init.rc, ce qui entraîne le chiffrement de /data par vold sans mot de passe. (Aucun n'est défini, car il s'agit d'un nouvel appareil.)

3. Monter tmpfs

   vold monte un /data tmpfs (en utilisant les options tmpfs de ro.crypto.tmpfs_options) et définit la propriété vold.encrypt_progress sur 0. vold prépare le tmpfs /data pour le démarrage d'un système chiffré et définit la propriété vold.decrypt sur : trigger_restart_min_framework

4. Afficher le framework pour montrer la progression

   Comme l'appareil n'a pratiquement aucune donnée à chiffrer, la barre de progression n'apparaît pas souvent, car le chiffrement est très rapide. Pour en savoir plus sur l'UI de progression, consultez Chiffrer un appareil existant.

5. Lorsque /data est chiffré, supprimez le framework.

   vold définit vold.decrypt sur trigger_default_encryption, ce qui démarre le service defaultcrypto. (Cela lance le flux ci-dessous pour monter des données utilisateur chiffrées par défaut.) trigger_default_encryption vérifie le type de chiffrement pour déterminer si /data est chiffré avec ou sans mot de passe. Étant donné que les appareils Android 5.0 sont chiffrés au premier démarrage, aucun mot de passe ne devrait être défini. Par conséquent, nous déchiffrons et montons /data.

6. Monter /data

   init monte ensuite /data sur un RAMDisk tmpfs à l'aide des paramètres qu'il récupère à partir de ro.crypto.tmpfs_options, qui est défini dans init.rc.

7. Framework de démarrage

   vold définit vold.decrypt sur trigger_restart_framework, ce qui poursuit le processus de démarrage habituel.

Chiffrer un appareil existant

Voici ce qui se passe lorsque vous chiffrez un appareil Android K ou version antérieure non chiffré qui a été migré vers L.

Ce processus est initié par l'utilisateur et est appelé "chiffrement sur place" dans le code. Lorsqu'un utilisateur choisit de chiffrer un appareil, l'UI s'assure que la batterie est complètement chargée et que l'adaptateur secteur est branché afin qu'il y ait suffisamment d'énergie pour terminer le processus de chiffrement.

Avertissement : Si l'appareil n'a plus de batterie et s'éteint avant la fin du chiffrement, les données des fichiers sont partiellement chiffrées. La configuration d'usine de l'appareil doit être rétablie, ce qui entraîne la perte de toutes les données.

Pour activer le chiffrement sur place, vold lance une boucle pour lire chaque secteur du véritable périphérique de bloc, puis l'écrit sur le périphérique de bloc de chiffrement. vold vérifie si un secteur est utilisé avant de le lire et de l'écrire, ce qui rend le chiffrement beaucoup plus rapide sur un nouvel appareil qui contient peu ou pas de données.

État de l'appareil : définissez ro.crypto.state = "unencrypted" et exécutez le déclencheur on nonencrypted init pour poursuivre le démarrage.

1. Vérifier le mot de passe

   L'UI appelle vold avec la commande cryptfs enablecrypto inplace, où passwd correspond au mot de passe de l'écran de verrouillage de l'utilisateur.

2. Supprimer le framework

   vold recherche les erreurs, renvoie -1 s'il ne peut pas chiffrer et affiche une raison dans le journal. S'il peut chiffrer, il définit la propriété vold.decrypt sur trigger_shutdown_framework. Cela entraîne l'arrêt des services init.rc dans les classes late_start et main.

3. Créer un pied de page de crypto-monnaie
4. Créer un fichier de fil d'Ariane
5. Redémarrer
6. Détecter le fichier de fil d'Ariane
7. Commencer le chiffrement /data

   vold configure ensuite le mappage cryptographique, ce qui crée un périphérique de bloc cryptographique virtuel qui mappe sur le périphérique de bloc réel, mais chiffre chaque secteur lors de l'écriture et déchiffre chaque secteur lors de la lecture. vold crée et écrit ensuite les métadonnées de chiffrement.

8. Pendant le chiffrement, montez tmpfs.

   vold monte un /data tmpfs (à l'aide des options tmpfs de ro.crypto.tmpfs_options) et définit la propriété vold.encrypt_progress sur 0. vold prépare le tmpfs /data au démarrage d'un système chiffré et définit la propriété vold.decrypt sur trigger_restart_min_framework.

9. Afficher le framework pour montrer la progression

   trigger_restart_min_framework entraîne le démarrage de la classe de services main par init.rc. Lorsque le framework constate que vold.encrypt_progress est défini sur 0, il affiche l'UI de la barre de progression, qui interroge cette propriété toutes les cinq secondes et met à jour une barre de progression. La boucle de chiffrement met à jour vold.encrypt_progress chaque fois qu'elle chiffre un autre pourcentage de la partition.

10. Mettre à jour le pied de page de chiffrement lorsque /data est chiffré

    Lorsque /data est chiffré, vold efface l'indicateur ENCRYPTION_IN_PROGRESS dans les métadonnées.

    Une fois l'appareil déverrouillé, le mot de passe est utilisé pour chiffrer la clé principale et le pied de page de chiffrement est mis à jour.

    Si le redémarrage échoue pour une raison quelconque, vold définit la propriété vold.encrypt_progress sur error_reboot_failed et l'UI doit afficher un message demandant à l'utilisateur d'appuyer sur un bouton pour redémarrer. Cette situation ne devrait jamais se produire.

Démarrer un appareil chiffré avec le chiffrement par défaut

Voici ce qui se passe lorsque vous démarrez un appareil chiffré sans mot de passe. Étant donné que les appareils Android 5.0 sont chiffrés au premier démarrage, aucun mot de passe ne devrait être défini. Il s'agit donc de l'état de chiffrement par défaut.

1. Détecter les /data chiffrés sans mot de passe

   Détecter que l'appareil Android est chiffré, car /data ne peut pas être installé et l'un des indicateurs encryptable ou forceencrypt est défini.

   vold définit vold.decrypt sur trigger_default_encryption, ce qui démarre le service defaultcrypto. trigger_default_encryption vérifie le type de chiffrement pour déterminer si /data est chiffré avec ou sans mot de passe.

2. Déchiffrer /data

   Crée l'appareil dm-crypt sur le périphérique de bloc afin que l'appareil soit prêt à l'emploi.

3. Monter /data

   vold monte ensuite la partition /data réelle déchiffrée, puis prépare la nouvelle partition. Il définit la propriété vold.post_fs_data_done sur 0, puis définit vold.decrypt sur trigger_post_fs_data. Cela entraîne l'exécution des commandes post-fs-data par init.rc. Ils créent les répertoires ou les liens nécessaires, puis définissent vold.post_fs_data_done sur 1.

   Une fois que vold voit le 1 dans cette propriété, il définit la propriété vold.decrypt sur trigger_restart_framework.. Cela entraîne le redémarrage des services dans la classe main par init.rc et le démarrage des services dans la classe late_start pour la première fois depuis le démarrage.

4. Framework de démarrage

   Le framework démarre maintenant tous ses services à l'aide du fichier /data déchiffré, et le système est prêt à être utilisé.

Démarrer un appareil chiffré sans chiffrement par défaut

Voici ce qui se passe lorsque vous démarrez un appareil chiffré avec un mot de passe défini. Le mot de passe de l'appareil peut être un code, un schéma ou un mot de passe.

1. Détecter un appareil chiffré avec un mot de passe

   Détecter que l'appareil Android est chiffré, car l'indicateur ro.crypto.state = "encrypted"

   vold définit vold.decrypt sur trigger_restart_min_framework, car /data est chiffré avec un mot de passe.

2. Monter tmpfs

   init définit cinq propriétés pour enregistrer les options de montage initiales fournies pour /data avec les paramètres transmis depuis init.rc. vold utilise les propriétés suivantes pour configurer le mappage cryptographique :

   1. ro.crypto.fs_type
   2. ro.crypto.fs_real_blkdev
   3. ro.crypto.fs_mnt_point
   4. ro.crypto.fs_options
   5. ro.crypto.fs_flags (nombre hexadécimal ASCII à huit chiffres précédé de 0x)
3. Démarrer le framework pour demander le mot de passe

   Le framework démarre et constate que vold.decrypt est défini sur trigger_restart_min_framework. Cela indique au framework qu'il démarre sur un disque tmpfs /data et qu'il doit obtenir le mot de passe de l'utilisateur.

   Toutefois, il doit d'abord s'assurer que le disque a été correctement chiffré. Il envoie la commande cryptfs cryptocomplete à vold. vold renvoie 0 si le chiffrement a réussi, -1 en cas d'erreur interne ou -2 si le chiffrement a échoué. vold le détermine en recherchant l'indicateur CRYPTO_ENCRYPTION_IN_PROGRESS dans les métadonnées de chiffrement. Si elle est définie, cela signifie que le processus de chiffrement a été interrompu et qu'il n'y a aucune donnée utilisable sur l'appareil. Si vold renvoie une erreur, l'UI doit afficher un message invitant l'utilisateur à redémarrer l'appareil et à rétablir sa configuration d'usine, et lui fournir un bouton à appuyer pour ce faire.

4. Déchiffrer des données avec un mot de passe

   Une fois cryptfs cryptocomplete exécuté, le framework affiche une UI demandant le mot de passe du disque. L'interface utilisateur vérifie le mot de passe en envoyant la commande cryptfs checkpw à vold. Si le mot de passe est correct (ce qui est déterminé par le montage réussi du /data déchiffré à un emplacement temporaire, puis par son démontage), vold enregistre le nom du périphérique de bloc déchiffré dans la propriété ro.crypto.fs_crypto_blkdev et renvoie l'état 0 à l'UI. Si le mot de passe est incorrect, la valeur -1 est renvoyée à l'UI.

5. Framework Stop

   L'UI affiche un graphique de démarrage crypto, puis appelle vold avec la commande cryptfs restart. vold définit la propriété vold.decrypt sur trigger_reset_main, ce qui entraîne init.rc à effectuer class_reset main. Cela arrête tous les services de la classe principale, ce qui permet de démonter le tmpfs /data.

6. Monter /data

   vold monte ensuite la véritable partition /data déchiffrée et prépare la nouvelle partition (qui n'a peut-être jamais été préparée si elle a été chiffrée avec l'option d'effacement, qui n'est pas prise en charge dans la première version). Il définit la propriété vold.post_fs_data_done sur 0, puis définit vold.decrypt sur trigger_post_fs_data. Cela entraîne l'exécution des commandes post-fs-data de init.rc. Ils créent les répertoires ou les liens nécessaires, puis définissent vold.post_fs_data_done sur 1. Lorsque vold détecte la valeur 1 dans cette propriété, il définit la propriété vold.decrypt sur trigger_restart_framework. Cela entraîne le redémarrage des services dans la classe main par init.rc et le démarrage des services dans la classe late_start pour la première fois depuis le démarrage.

7. Démarrer le framework complet

   Le framework démarre maintenant tous ses services à l'aide du système de fichiers /data déchiffré, et le système est prêt à être utilisé.

Échec

Un appareil qui ne parvient pas à déchiffrer les données peut présenter un problème pour plusieurs raisons. L'appareil commence par la séquence de démarrage normale :

1. Détecter un appareil chiffré avec un mot de passe
2. Monter tmpfs
3. Framework de démarrage pour demander le mot de passe

Toutefois, une fois le framework ouvert, l'appareil peut rencontrer des erreurs :

• Le mot de passe correspond, mais les données ne peuvent pas être déchiffrées
• L'utilisateur saisit un mot de passe incorrect 30 fois

Si ces erreurs ne sont pas résolues, invitez l'utilisateur à rétablir la configuration d'usine :

Si vold détecte une erreur lors du processus de chiffrement, et si aucune donnée n'a encore été détruite et que le framework est opérationnel, vold définit la propriété vold.encrypt_progress sur error_not_encrypted. L'interface utilisateur invite l'utilisateur à redémarrer l'appareil et l'informe que le processus de chiffrement n'a jamais démarré. Si l'erreur se produit après la fermeture du framework, mais avant l'affichage de l'UI de la barre de progression, vold redémarre le système. Si le redémarrage échoue, vold.encrypt_progress est défini sur error_shutting_down et -1 est renvoyé, mais il n'y aura rien pour détecter l'erreur. Cette situation ne devrait pas se produire.

Si vold détecte une erreur lors du processus de chiffrement, il définit vold.encrypt_progress sur error_partially_encrypted et renvoie -1. L'UI doit ensuite afficher un message indiquant que le chiffrement a échoué et fournir un bouton permettant à l'utilisateur de rétablir la configuration d'usine de l'appareil.

Stocker la clé chiffrée

La clé chiffrée est stockée dans les métadonnées de chiffrement. La sauvegarde matérielle est implémentée à l'aide de la fonctionnalité de signature de l'environnement d'exécution sécurisé (TEE). Auparavant, nous chiffrions la clé principale avec une clé générée en appliquant scrypt au mot de passe de l'utilisateur et au sel stocké. Afin de rendre la clé résistante aux attaques hors du boîtier, nous étendons cet algorithme en signant la clé résultante avec une clé TEE stockée. La signature résultante est ensuite transformée en clé de longueur appropriée par une autre application de scrypt. Cette clé est ensuite utilisée pour chiffrer et déchiffrer la clé principale. Pour stocker cette clé :

1. Générez une clé de chiffrement de disque (DEK) et un salt de 16 octets chacun.
2. Appliquez scrypt au mot de passe de l'utilisateur et au sel pour générer la clé intermédiaire 1 (KI1) de 32 octets.
3. Ajoutez des octets nuls à IK1 pour atteindre la taille de la clé privée liée au matériel (HBK). Plus précisément, nous ajoutons des octets comme suit : 00 || IK1 || 00..00 ; un octet zéro, 32 octets IK1, 223 octets zéro.
4. Signez IK1 avec HBK en ajoutant des octets de remplissage pour produire IK2 de 256 octets.
5. Appliquez scrypt à IK2 et au sel (le même sel qu'à l'étape 2) pour produire IK3 de 32 octets.
6. Utilisez les 16 premiers octets d'IK3 comme KEK et les 16 derniers octets comme IV.
7. Chiffrez la DEK avec AES_CBC, avec la clé KEK et le vecteur d'initialisation IV.

Modifier le mot de passe

Lorsqu'un utilisateur choisit de modifier ou de supprimer son mot de passe dans les paramètres, l'UI envoie la commande cryptfs changepw à vold, et vold rechiffre la clé principale du disque avec le nouveau mot de passe.

Propriétés de chiffrement

vold et init communiquent entre eux en définissant des propriétés. Voici la liste des propriétés disponibles pour le chiffrement.

Propriétés Vold

Propriétés init

Actions d'initialisation

on post-fs-data
on nonencrypted
on property:vold.decrypt=trigger_reset_main
on property:vold.decrypt=trigger_post_fs_data
on property:vold.decrypt=trigger_restart_min_framework
on property:vold.decrypt=trigger_restart_framework
on property:vold.decrypt=trigger_shutdown_framework
on property:vold.decrypt=trigger_encryption
on property:vold.decrypt=trigger_default_encryption