La gestion d'un périphérique de stockage entièrement chiffré n'est pas nécessairement simple… ni efficace. Et l'exemple d'un problème découvert récemment avec le chiffrement sous GNU/Linux est éclairant : le fait de presser très rapidement la touche Enter (avec l'aide d'un petit périphérique USB) permet d'accéder à un périphérique chiffré.

Commençons par un point : il s'agit d'un cas un peu particulier. Dans un environnement classique, l'utilisateur doit en effet entrer deux mots de passe au démarrage : le premier permet d'accéder au périphérique et sert à déchiffrer le « disque », le second sert à accéder à la session de l'utilisateur. C'est un choix peu pratique dans certains cas, spécialement pour les appareils qui ne sont pas accessibles facilement : il n'est pas possible de se connecter à distance sans d'abord physiquement taper le premier mot de passe.

La solution la plus courante est celle choisie par Microsoft avec BitLocker : stocker la clé de déchiffrement dans un composant spécifique¹, la puce TPM. De cette manière, le déchiffrement est automatique au démarrage, et l'utilisateur doit uniquement taper son mot de passe. Apple travaille un peu différemment avec FileVault, mais l'idée est la même : taper un seul mot de passe. Dans les cas de macOS, le système demande un mot de passe qui va être le même pour le déchiffrement et l'accès à la session.

L'idée derrière la faille présentée par Michael Fincham est liée à ce choix : pour permettre de régler un éventuel problème au démarrage, comme un système corrompu, il est possible de passer outre le démarrage automatique pour accéder à une console de récupération. En pressant une touche au bon moment, il est possible d'arriver sur un écran qui demande le mot de passe de déchiffrement, même si la clé est stockée dans la puce TPM.

En utilisant une clé USB programmée pour émuler un clavier, il est possible d'envoyer le signal de la touche Enter environ dix fois plus vite qu'un être humain (une pression toutes les 10 millisecondes dans l'exemple) et après quelques minutes, de façon presque magique, l'utilisateur dispose d'un accès root, c'est-à-dire avec le plus haut niveau de privilège. L'auteur explique par ailleurs qu'il est possible de le faire manuellement, mais le résultat dépend en partie du clavier et de la vitesse de frappe.

Mais pourquoi ?

Les raisons exactes sont liées à des dépendances entre les différents programmes qui servent à déchiffrer le périphérique de stockage, mais l'idée reste basique : envoyer la touche Enter en rafale au bon moment va permettre de bloquer le processus qui gère le déchiffrement, avec des erreurs de mot de passe en série. Et les dépendances entre les logiciels font que le démarrage classique est bloqué et que systemd (le programme d'initialisations sous GNU/Linux) décide de lancer la console de récupération avec un accès root. Dans ce mode, l'utilisateur dispose donc de privilèges très élevés pour — en théorie — tenter de régler un problème de démarrage. Une fois à cet endroit, il est visiblement trivial de déchiffrer le périphérique de stockage, pour une bonne raison : les clés de chiffrement sont dans la puce TPM et il est donc possible de demander à cette dernière de déchiffrer le disque.

Maintenant, est-il possible de régler cette faille ? Nous pourrions évidemment simplement recommander de ne pas laisser un accès physique à un attaquant, mais ça reste un vœu pieux. La solution de Michael passe par deux lignes à ajouter dans un fichier de configuration, qui permettent de forcer le redémarrage automatiquement en cas de problème. Ce choix amène une contrainte : l'accès à la console de récupération est impossible. L'autre solution, basique, consiste à ne pas passer par la puce TPM, mais nous revenons au point de départ : elle amène un côté pratique évident. La solution de Microsoft se trouve entre les deux : en cas d'accès à la console de récupération de Windows, le chiffrement nécessite une clé de sécurité secondaire (la clé de récupération), ce qui permet le dépannage tout en fournissant une solution sûre pour l'accès aux données… en supposant que l'utilisateur dispose bien des clés en question.

Dans tous les cas, cette faille qui peut sembler un peu risible montre que la sécurité des données ne doit jamais être considérée comme parfaite, spécialement quand on prend en compte le fait qu'un attaquant puisse disposer d'un accès physique.