Le chiffrement de disques durs, appelé aussi le chiffrement de surface, est une mesure intéressante pour éviter la fuite d'information en cas de perte ou vol de matériels.
J'ai à ce sujet écrit un article dans linux Magazine il y a un an et demi, présentant diverses méthodes pour mettre en oeuvre le chiffrement de partitions sous linux en janvier 2008.
L'article devrait être disponible un jour ou l'autre sur http://www.unixgarden.com . L'article fournissait une méthode offrant de la plausible deniability et une méthode graphique permettant de visualiser le chiffrement (ces deux points ne sont pas considérés dans l'article du blog présent).
Les conclusions de l'article sont les suivantes:
-le chiffrement ne protège les données que lorsque la machine est éteinte
-il reste toujours un angle d'attaque sur la machine chiffrée, correspondant à la partition en clair supportant le noyau et son initrd.
Appliquons ces deux points à l'actualité récente, MISC 45 et la blackhat 2009.
1/ MISC 45
Tout d'abord, j'ai lu dans MISC 45 l'article sur dokuwiki. L'article est intéressant, agréable à lire et j'aime bien cette idée de donner des détails pratiques sur la mise en oeuvre d'un outil.
Ceci dit l'auteur conclut en indiquant (entre autre bons conseils) qu'il est conseillé de chiffrer le disque dur du serveur et du client pour des raisons de confidentialité.
Cette raison me paraît totalement inutile. Pour le serveur tout d'abord. Un serveur, ça sert des pages, donc c'est allumé. Tant que la machine est allumée, le disque est ouvert, la clé de chiffrement présente, l'accès aux fichiers possibles. Donc pour limiter la fuite d'informations de ce serveur, le chiffrement est tout simplement superfétatoire.
Pour la même raison (la confidentialité), l'auteur conseille de chiffrer le disque de la machine cliente qui va éditer un fichier wiki afin de l'uploader sur le serveur dokuwiki; la raison en est simple, en cours d'édition, le contenu du fichier est contenu dans un javascript enregistré localement. Et pour la même raison j'indique que cela est tout autant inutile. Un attaquant sur la machine -allumée bien sûr- aura accès à ce fichier, chiffrement de disque ou pas.
Le chiffrement de disque est utile, mais attention aux raisons qui vous poussent à le mettre en oeuvre...
2/ Fuite de la clé de chiffrement
Une conférence à la blackhat 2009 fournit une méthode pour lire la clé TrueCrypt. Le principe en est simple. Il suffit de s'intercaler entre le disque et le système pour lire la clé alors qu'elle lui est transmise. Je salue l'exploit (l'auteur a ajouté pas mal de petites options intéressantes, citée dans l'article). Ceci dit, je note que l'attaque reste locale puisque elle repose sur l'infection du MBR.
Et cette attaque peut être exactement portée sous linux (l'essence de cette attaque, pas le code du bootkit). Le déchiffrement du disque sous linux est réalisé dans l'initrd (ou initramfs) lors du boot. Et cet initrd/ramfs est situé sur une partition non chiffrée.
Ainsi, un attaquant qui aurait en sa possession un portable chiffré pourrait sans aucun problème modifier cet initrd afin qu'il lise la clé fournie par l'utilisateur, et la dupliquer quelque part sur le disque ou l'envoyer sur le réseau une fois la machine bootée. Cette attaque est tellement simple à mettre en oeuvre que son évocation est un PoC à lui seul.
Pour éviter ceci, dans mon article linux magazine, je préconisais deux méthodes:
-Camoufler le noyau et l'initrd dans les premiers Mo de la partition swap. Après le boot, le swap n'utilise pas ces quelques Mo. Le tout début de la partition swap est à son tour chiffré, empêchant ainsi un attaquant d'analyser les partitions en clair. Méthode relativement lourde à mettre en oeuvre, et qui ne résiste pas à une analyse poussée.
-Mettre le noyau et l'initrd sur une clé USB, qui peut également contenir des clés de chiffrements des disques [2]. Sans cette clé, la machine est inerte. Un attaquant pourra infecter le MBR sans risques pour la confidentialité, puisque ce sera la clé USB qui sera démarrée au boot. Il ne reste qu'a sensibiliser l'utilisateur à cette clé USB pour qu'il ne la laisse pas trainer avec le portable.
La perte de la clé USB en elle même n'est pas forcément grave, il suffit de supprimer la clé de chiffrement du disque contenue dans cette clé USB, puis d'en fournir une nouvelle à l'utilisateur.
Bien entendu, cette attaque peut être portée sous n'importe quel type de chiffrement logiciel. Au boot, windows aura forcément besoin d'un bout de code en clair quelquepart. Et ce code pourra donc être modifié par autre chose. La signature de ce bout de code pourrait être une solution, mais la complexité de mise en oeuvre augmente d'autant.
CONCLUSION/
Le chiffrement de surface doit rester confiné à son utilisation première: protéger les disques éteints (donc plutôt dédiée aux périphériques mobiles ayant des phases d'extinction. Un ordinateur portable semble une bonne idée, un téléphone portable moins, étant la majeure partie du temps allumé). Si elle est étendue à d'autres services (ex chiffrement de disque d'un serveur) la raison doit en être clairement identifiée sous raison de perdre du temps, de la puissance CPU et une augmentation de la complexité lors de la résolution de problèmes (ex: clusters défectueux). Pour finir sur une note humoristique, je conseille la lecture de ce post d'XKCD concernant le chiffrement de disques :)
[1]Pour préciser, j'indiquerai que la phrase "le chiffrement de surface ne protège que les machines éteintes" doit être légerement modifiée. En effet des chercheurs ont mis en oeuvre une attaque appelée cold-boot attack. La RAM conservant un certain temps des informations (dont la clé de chiffrement du disque) après extinction de la machine, il faut modifier la règle en: "Le chiffrement de surface ne protège que les machines éteintes depuis quelques minutes". Ceci dit, tout les limitations concernant le chiffrement de surface restent identiques.
[2]Ce qui a le double avantage de faciliter la vie de l'utilisateur: il veut allumer sa machine, il met sa clé USB, elle démarre. Il n'a qu'a ranger la clé USB de manière sécurisée par la suite. Pas de mot de passe compliqué qui finira écrit sur un post-it, pas de complications et c'est simple à comprendre pour n'importe quel utilisateur. Cerise sur le gâteau la clé peut être perdue sans aucun risque de fuite d'information...
Aucun commentaire:
Enregistrer un commentaire