Why plausible deniability sucks, at last

La cryptographie est le meilleur moyen de garantir la confidentialité des données. Depuis Kerckhoffs, nous savons que les algorithmes doivent être publics et que la sécurité du chiffre ne doit reposer que sur sa clé. Si cette clé est divulguée, alors les données sont révélées. Pour parer à la demande de divulgation de la clé, il est tentant de cacher le chiffré. Deux méthodes existent, la stéganographie, ou la plausible deniability. Le concept de plausible deniability a été popularisé par truecrypt bien qu'il soit généralisable à tout autre système de chiffrement moyennant conditions. Ce principe repose sur l'existence de deux clés permettant d'ouvrir le même fichier chiffré, chaque clé donnant accès à des documents différents. La force de la méthode, dont le nom dérive, s'appuye sur le fait qu'il est impossible à un attaquant de prouver qu'une seconde clé existe.

Cet article de blog va s'intéresser au fonctionnement de la plausible deniability et montrer qu'in fine, l'implémentation impose un usage très désagréable de la méthode. Tout d'abord sera expliqué comment la plausible deniability fonctionne, et comment deux clés peuvent ouvrir différemment le même fichier chiffré. Ensuite seront vus les détails d'implémentation afin d'éviter de dévoiler l'usage de la seconde clé. Enfin sera montré la faille de la méthode, et la manière inélégante de la contourner.

En préambule, quelques mots de vocabulaire (je reprends la terminologie de Truecrypt). Le container, ou container principal, est le fichier contenant les données. Ce fichier n'a pas d'en-tête spécifique, il est chiffré intégralement. Le premier container est généralement confondu avec le container principal. Les données du container principal ne sont accessibles que si l'on fournit la première clé. Tous les containers truecrypt contiennent un container principal. Container caché: ce terme définit le second container, caché dans le container principal. Un second mot de passe permet d'accéder à ses données.

1/Comment fonctionne la plausible deniability?/
Démarrons par quelques définitions avant de montrer comment la plausible deniability est mise en oeuvre: Un procédé de chiffrement moderne doit produire un résultat indiscernable d'un flux d'octet aléatoire. Un container doit être préalablement rempli de données aléatoires.
Et l'idée vient d'elle même: il est donc possible de faire cohabiter un second container s'il est suffisement loin du premier. Si on prend un livre blanc en exemple, il est possible d'écrire deux histoires, l'une démarrant page 0, et l'autre démarrant page 80. La connaissance de la page de démarrage permet d'accéder à l'une ou l'autre histoire. La plausible deniability fonctionne de la même manière, cf http://www.truecrypt.org/images/docs/hidden-volume.gif :

Cela fonctionne bien. Un attaquant ne pourra pas différencier les octets aléatoires de la fin du disque des octets chiffrés par le container caché. Quelques précautions d'usages sont nécessaires et découlent de la lecture de l'image ci-dessus. Le container caché sera toujours plus petit que le container principal. Le premier container ne devra pas contenir trop de données, en effet elles pourraient écraser les données du container caché. (Pour cette raison, truecrypt propose une protection du container caché lorsque l'on écrit dans le premier container; bien entendu, les deux mots de passes sont nécessaires :) ).

2/Quelles précautions d'usage?/
Quelques précautions s'imposent pour celui qui souhaiterait implémenter son système de plausible deniability. Nous allons en voir quatre.

2.1-Le procédé crypto
A partir du moment ou un attaquant est capable de différencier du chiffré de l'aléatoire, il sera capable de détecter l'existence du second container rendant la plausible deniability inefficace puisqu'il prouvera par la même l'existence de données non révélée par la fourniture du mot de passe du premier container.
Truecrypt utilise AES comme méthode de chiffrement qui est encore solide à l'heure actuelle. Et le jour ou quelqu'un sera capable de différencier un flux aléatoire d'un flux chiffré par AES, il suffira de changer de procédé de chiffrement.

2.2-Le filesystem
Dans le container, les données sont rangées à l'aide d'un filesystem. Certains filesystems ont des caractéritiques impropres à l'utilisation de la plausible deniability. Le filesystem par défaut de linux, extX, duplique de manière régulière des informations sur son emploi (superblock, tables d'inodes, etc..). Le container caché démarre à partir d'un certain seuil. Les données du container caché vont donc écraser les métadonnées du premier filesystem. Un attaquant peut donc vérifier l'état sain des métadonnées sur l'intégralité du container pour s'assurer qu'aucun container caché ne soit présent.

Truecrypt fait le choix d'imposer FAT comme filesystem du premier container lors de l'emploi de la plausible deniability. FAT est un filesystem très basique qui n'écrit des données qu'au début de son disque. Il n'y a donc pas de risques d'écrasement des métadonnées du premier filesystem par le container caché puisqu'il n'y en a pas.

2.3-Les sauvegardes
Un cas particulier se pose pour les sauvegardes. En effet, un attaquant peut alors étudier deux versions du container et regarder les blocs de données qui sont modifiés. La détection de changement de blocs permet de prouver facilement l'existence d'un container caché. En effet, les blocs chiffrés ne sont modifiés que si le clair change. Le container caché démarre à partir d'un certain seuil, ou offset. Les blocs modifiés par le container caché sont donc au delà de ce seuil, et bien au delà des données du premier container. Un attaquant peut dès lors prouver l'existence du container caché par différenciation. Pour reprendre l'exemple du livre, cela signifie qu'un attaquant sait qu'entre deux versions les pages 1 à 10 ont été modifiées, et les pages 80 à 85. Le mot de passe du premier container lui indique que les fichiers font bien la taille des 10 premières pages. D'où la question: d'où viennent les modifs des pages 80 à 85? Et de là, découle la révélation du container caché.

J'ai écrit un petit programme permettant de donner un aspect visuel à ces changements. Le principe en est le suivant: je XOR les octets de deux versions du container. Et je me sers du résultat pour en faire une image. Si les octets sont identiques, alors le résultat vaut 0 (et donc un pixel de couleur 000000: noir). Si les octets sont modifiés, alors un pixel est coloré. Ci-joint une image.

 Le premier bandeau chiffré du haut correspond à la modification des données du premier container. Le second bandeau prouve l'existence du container chiffré: ces octets n'ont aucune autre raison d'être modifiés que par l'existence d'ajout de données dans le container caché. Cela correspond de plus à mon container. J'avais réservé les 2/3 de l'espace pour mon container caché. Il démarre donc comme attendu au premier tiers du container principale.

Truecrypt propose une solution pour éviter cela: il suffit de créer un nouveau container à chaque sauvegarde et dupliquer les données qu'il contient (cf: http://www.truecrypt.org/docs/how-to-back-up-securely).
Une autre solution serait de ne jamais faire de sauvegardes. Mais je ne pense pas que cela soit acceptable en raison du risque de pertes de données (on peut en effet penser que ces données sont importantes puisqu'elles nécessitent une protection accrue).

2.4-Les autres précautions
Il faut bien entendu lire également http://www.truecrypt.org/docs/?s=security-requirements-and-precautions qui évoque deux points principaux selon moi: la sécurité physique pour éviter la modification du logiciel Truecrypt (n'oubliez pas que 6 lignes de codes sont suffisantes pour trojaniser Truecrypt..) et la manière d'éviter la duplication des blocs chiffrés pour que la détection du volume caché soit réalisable comme indiqué au chapitre au dessus. Ces précautions sont relativement contraignantes, mais sont nécessaires même pour l'emploi "classique" de truecrypt (c'est à dire sans plausible deniability).

3/Mais alors tout va bien?/
Et bien non, tout ne va pas bien :-)
Le ver est dans le fruit et dans les méthodes citées au dessus. Il est à peu près possible d'employer la plausible deniability de manière fiable, en faisant particulièrement attention aux sauvegardes. Et c'est précisément là ou le bât blesse.
Prenons comme hypothèse une personne qui "backup securely" ses containers truecrypt pour éviter que l'on détecte ses containers cachés. Plaçons nous désormais comme attaquant face à cette personne et posons lui la question suivante:
"pourquoi avez vous choisi de générer un nouveau container de zéro pour chaque sauvegarde?".
Et comme la seule et unique raison de générer un nouveau container pour chaque sauvegarde est de pouvoir camoufler l'usage d'un container caché, la méthode se retourne contre son utilisateur: en voulant cacher l'usage de ses containers cachés, il en démontre précisément l'existence!

Aux échecs, cela s'appelle un zugzwang: c'est à vous de jouer et tous les coups sont mauvais. Si vous utilisez la plausible deniability; vous vous mettez dans une situation désagréable ou soit vous êtes
détectable, soit vous ne faites aucune sauvegarde...

Moralité de l'histoire: il n'y en a pas.