C’est l’étape obligée d’une vérification des pratiques de sécurité informatique de base, le chiffrement de disque, au sens de toutes les données et souvent de la majorité du système d’exploitation (en anglais full disk encryption). Mais tous les chiffrements ne se valent pas, une petite vue d’ensemble.

Note: Il ne faut pas ici imaginer un avis sur les systèmes d’exploitation ou les éventuelles marques associées.

Le principe de base: Linux

Le chiffrement de disque y est souvent réalisée par l’association du module de noyau dm-crypt et du format de partition LUKS avec cryptsetup.

Le principe est simple: à l’allumage du système, l’utilisateur rentre un long mot de passe, qui une fois passé par un fonction de dérivation de clef (KDF en anglais), donne la clef de chiffrement utilisée pour le disque. Comble du raffinement, en utilisant un format de partition dédié, on peut avoir plusieurs mots de passe ! Il suffit de chiffrer la clef de chiffrement du disque avec la clef obtenue par la fonction de dérivation, et de faire de même autant de fois qu’on le souhaite (ou plutôt que le permet le format).

On chiffre le disque un peu comme si c’était un gros fichier. Le noyau Linux se chargeant de ces opérations de chiffrement, la clef réside dans sa mémoire une fois le démarrage réalisé.

On pourra d’ailleurs trouver une citation éminemment politique dans la foire aux questions à propos des clefs de chiffrement:

In most civilized countries you can just refuse to hand over the keys, no harm done.

Un premier problème: lancer le système d’exploitation

Pour arriver à saisir le mot de passe, il faut un clavier et un écran initialisés. Et pour permettre cela on va donc laisser toute une partition du disque en clair, /boot. Celle-ci va contenir notamment le gestionnaire de démarrage (usuellement Grub), ainsi que le noyau linux.

Laisser une partie ou même la totalité du système en clair ne représente pas un grand risque de confidentialité, ce sont des fichiers librement disponibles sur internet où ils sont distribués en clair. Le risque est pour l’intégrité de celui-ci: sans chiffrement (qui dans le cas qui nous occupe est toujours intègre), un attaquant pourrait le modifier, le compromettre dans l’objectif par exemple d’obtenir le mot de passe que vous allez entrer au démarrage. Se prémunir contre ce genre d’attaque nécessite une vérification d’intégrité du démarrage extérieure au chiffrement du disque lui-même, c’est les Secure/Trusted/Verified Boot.

L’arrivée d’une puce: Windows

La solution linuxienne repose sur la capacité de l’utilisateur à choisir un mot de passe fort, tâche pour laquelle les utilisateurs sont notoirement mauvais. De plus, celui-ci est la seule protection de la clef de chiffrement du disque, et ainsi seule la complexité de la fonction de dérivation de clef protège le chiffrement d’une attaque par force brute.

Vient alors l’idée de stocker la clef de chiffrement, ailleurs que sur le disque, dans ce que l’on va nommer un élément sécurisé, dans le cas de Windows un TPM (Trusted Platform Module).

C’est devenu un classique en sécurité informatique: Face aux faiblesses du logiciel, la réponse est bien souvent d’intégrer la fonctionnalité à un circuit intégré. (jeu de mot!)

Le principe: au démarrage, le TPM stocke la clef de chiffrement du disque et le processus de démarrage interroge ce module TPM pour l’obtenir. Le disque est effectivement chiffré, le disque peut-être retiré de la machine et revendu tel quel sur le marché de seconde main, la confidentialité des données n’en sera pas affectée. Mais il suffit à un attaquant d’écouter (en se branchant physiquement sur l’interface du TPM) le processus de démarrage, sniffer le trafic pour obtenir la clef de chiffrement. On pourrait penser que démarrer l’ordinateur avec un autre système d’exploitation et interroger le TPM suffirait à obtenir la clef. Ce n’est pas le cas, car le TPM “enregistre” le démarrage grâce au micrologiciel UEFI et ne révélera la clef que dans les bonnes conditions.

Le retour de la première solution, en mieux

La solution est relativement simple: un secret de l’utilisateur est nécessaire au démarrage pour obtenir la clef, usuellement un PIN (mais une clef USB peut aussi faire l’affaire). Celui-ci est différent des identifiants utilisateur Windows (même si ceux-ci peuvent aussi être protégés par le TPM). Grâce à l’élément sécurisé à disposition on peut mieux protéger ce secret des attaques par force brute, en effet le TPM va limiter le nombre d’essai.

La clef finit de toutes façons en mémoire dans le noyau.

Les évolutions d’implémentations: Android

Android étant basé sur Linux, il a d’abord adopté une solution très similaire à celle de Linux décrite ci-dessus. À noter qu’un secret utilisateur est requis et combiné à un secret fort au sein de l’élément sécurisé du système sur (une) puce (System on (a) Chip, SoC) pour obtenir la clef de chiffrement.

Cependant ce n’est pas très satisfaisant car on souhaite qu’un certain nombre de fonctionnalités soient disponibles uniquement en démarrant le téléphone, sans le secret utilisateur. Pour se faire le chiffrement se fait désormais au niveau de chaque fichier, permettant de séparer les fichiers en deux catégories: ceux chiffrés par une clef en clair dans l’élément sécurisé et ceux chiffrés par une clef protégé par le mot de passe (ou PIN) de l’utilisateur similaire à la solution initiale.

À noter que l’élément sécurisé n’existe pas vraiment ! Ou plutôt il est majoritairement virtuel: c’est un environnent d’exécution particulier du System on Chip (en pratique le Trusted Execution Environment, TEE). Il n’y a donc pas de liaison physique exposée et quasiment pas de risque de sniffing de clefs.

La, ou les clefs, une fois obtenues de l’élément sécurisé finissent en mémoire dans le noyau, qui se charge des opérations de chiffrement.

L’état de l’art: Apple et les derniers Android

L’idée est similaire à la section précédente, sauf que l’élément sécurisé (puce “T2”, puis intégré aux Sytem on Chip) va se charger du opérations de chiffrement directement plutôt que de fournir la clef au noyau.

La clef ne finit pas en mémoire dans le noyau, elle ne quitte jamais l’élément sécurisé qui la dérive à chaque mise en route.

Cette solution pose des contraintes de performance: le cryptoprocesseur de l’élément sécurisé devant pouvoir chiffrer et déchiffrer sans que les performances du stockage ne soit affecté. Ce qui explique peut-être pourquoi Android ne l’a pas directement adoptée même si une solution similaire est maintenant disponible.