mardi 11 septembre 2012

Le chiffrement de disque sous linux: Second strike

1/ Introduction: la théorie
Toutes les distributions linux permettent depuis longtemps de chiffrer la racine du système afin d'améliorer la sécurité du système. Ce chiffrement se fait à l'aide de cryptsetup et dm-crypt, la documentation est abondante sur le sujet.

Cet article propose une étude des limites du chiffrement:
-L'humain: l'implémentation et l'utilisation
-Ecrasement de données
-Evil Maid
-Cold boot attack

2/ L'humain
Le plus gros problème de la crypto c'est qu'il est possible de se tromper mais que cela fonctionne tout de même: c'est juste non sécurisé.
2/A/ L'implémentation
le meilleur chiffrement du monde peut être anéanti si le programmeur l'a mal codé. Si le programmeur a bien travaillé, alors l'intégrateur peut se tromper également (n'est ce pas debian?).
Les algos par défaut peuvent également être mal choisis (ce n'est pas le cas avec cryptsetup).
Comme je l'ai montré dans un précédent article, un simple cat peut aussi réduire toute la sécurité à zéro. Une lecture des init de debian et slackware montrent que des choix efficaces ont été fait.
2/B/ L'utilisateur
Toute solution de chiffrement est vulnérable à au mauvais mot de passe. Il faut donc forcer l'utilisation de bon mots de passe. On peut imaginer des solutions hardwares ou des politiques strictes.
Il faut aussi se méfier de l'utilisateur malveillant qui peut dumper la clé maître de chiffrement du disque (dmsetup --showkeys), rendant caduque le remplacement des clés de slots par l'administrateur qui veut lui couper l'accès.
Heureusement, cryptsetup propose depuis la version 1.5.0 en expérimental un système de changement de clé maitre: http://code.google.com/p/cryptsetup/wiki/Cryptsetup150 (chercher cryptsetup-reencrypt dans la page)

3/ Protection anti-écrasement
Un autre de mes articles expliquait comment écraser des données choisies afin d'éviter le lancement au démarrage de contre mesures de protection. Il n'existe pas encore au niveau de dm-crypt un mécanisme de vérification d'intégrité. Toutefois, deux solutions sont envisageables:
3/A/ Le filesystem
Ext4 depuis la version 3.5 permet de calculer un CRC32 des données.
Si un écrasement à eu lieu, alors le fs est remonté en ro. Il devient donc possible de détecter si un écrasement (volontaire ou non) a eu lieu en testant en fin de boot si / est en rw.
3/B/ dm-verity
Une nouvelle couche device mapper a fait son apparition avec le noyau 3.4. Elle maintient un hash de tous les blocs et permet de les vérifier de manière fiable à l'aide d'un TPM.

4/ Protection anti Evil Maid
On le sait, même si l'intégralité du disque est chiffré, il reste toujours une petite partie en clair, servant à gérer le démarrage et demander la clé de déchiffrement. Un pirate pourrait modifier ce code en clair afin de logger le mot de passe quelque part.
4/A/ TPM
le noyau peut utiliser un TPM. Ce TPM permet de vérifier que le code en clair (MBR + noyau + initramfs) est bien celui d'origine et n'a pas été modifié.
La conférence que j'ai donné aux RMLL 2010 explique comment utiliser le TPM sous linux.
4/B/ If it walk like a duck, is it a duck?
Ma conférence était un poil incomplète. En effet, le setup laisse un léger trou qui peut se combler facilement. Lors du démarrage, les métriques du boot (MBR, noyau, initramfs) sont chargées dans le TPM. Ensuite, la racine est déchiffrée
via la clé scellée dans la partition /boot. Mais si je suis un pirate, je peux déplacer cette clé, changer l'intégralité du système linux et rebooter. Ainsi, je deviens root sur mon système et les métriques TPM sont correctement positionnées!! Je peux donc désceller aisément la clé scellée et lire/modifier les données du système initial.
Cela se corrige simplement en "brûlant" les métriques TPM en fin de boot en ajoutant de l'alea afin de les dévalider.

5/ Protection cold boot
Une autre attaque consiste à aller chercher les clés directement dans la mémoire vive. Ciblant plus linux, un travail d'étude intéressant peut se lire ici: http://events.ccc.de/camp/2007/Fahrplan/attachments/1300-Cryptokey_forensics_A.pdf
Je cite une partie: "The obvious conclusion that can be drawn is that key recovery is surprisingly easy. Once an attacker, in our case a forensic investigator, has gained access to an image of the memory the keys can be easily found, extracted and reused to gain access to the encrypted material."
La solution consiste donc à éviter que les clés soient présentes en mémoire vive. Deux projets me semblent intéressant.
5/1/ Frozencache
Le projet semble relativement mort. L'idée de base est de placer les clés dans le cache CPU. Lorsque la clé est dans le cache, les performances sont calamiteuses, mais comme le dit l'auteur, la clé n'a besoin d'y être que lors de la phase d'hibernation ou lorsque la machine a son screensaver de lancé.

5/2/ Tresor
 Ce projet n'est pas inclus
dans les sources officielles du kernel mais semble plus intéressant.
"Our solution takes advantage of Intel’s new AES-NI instruction set and exploits the x86 debug registers in a non-standard way, namely as cryptographic key storage. TRESOR is compatible with all modern Linux distributions, and its performance is on a par with that of standard AES implementations."

5/3/ Les clés OK, mais quid des données?
Il reste encore un léger problème avec ces implémentations. Les clés sont sauves d'une attaque coldboot, mais les données, elles, ne le sont pas. C'et mineur, mais il faudrait prévoir un mécanisme permettant de dropper tous les caches afin d'éviter qu'un attaquant lise le contenu de la RAM (le proc vm_drop_cache). On sait plutôt bien reconstruire le contenu d'une RAM linux, ainsi que les fichiers présents (volatilitux).

6/ Conclusion
Il s'agit actuellement d'un WIP (Work In Progress). Il me reste plusieurs setups à tester et des attaques à vérifier. J'espère avoir fait le tour des risques liés au chiffrement de disque et des moyens pour les limiter.