PBKDF2 à l'épreuve du FBI

V

ous n'êtes probablement pas passé à côté de cette news retentissante : le FBI aurait échoué à décrypter des disques protégés par TrueCrypt. C'est évidemment une mauvaise nouvelle pour la justice brésilienne à qui ces données auraient été bien utiles pour étayer ses poursuites contre Daniel Dantas, mais d'un autre côté, c'est un énorme coup de pub pour ce logiciel libre de chiffrement de volumes.

Si j'en parle dans la catégorie Wi-Fi, c'est que cet échec des autorités brésiliennes et américaines nous ramène à la solidité pratique de la fonction de dérivation de clés utilisée par TrueCrypt, laquelle se trouve être la même que celle proposée par WPA et WPA2 en authentification PSK.

Cette fonction standard, qui porte de le nom barbare de PBKDF2, sert à dériver une clé de longueur arbitraire à partir d'un mot de passe. On comprend bien que dans des contextes comme celui d'un disque chiffré ou d'une connexion Wi-Fi authentifiée par passphrase, la qualité d'une telle fonction est primordiale. D'une part pour ne pas introduire de vulnérabilité qui permettrait de contourner la solidité du mot de passe, et d'autre part pour fournir un fonctionnement qui rendra plus difficile les attaques de mots de passe telles que nous les connaissons. Et sans entrer dans les détails, on peut dire que PBKDF2 s'en sort plutôt bien ;)

D'abord en utilisant une graine d'aléa, ou salt anglais, pour bloquer les attaques par dictionnaires précalculés, couramment appelés "Rainbow Tables". Dans le cas du Wi-Fi, le salt est le SSID du réseau, ce qui implique qu'un éventuel dictionnaire précalculé pour cet accès ne pourra pas être utilisé sur un autre. Plus généralement, une telle table pour WPA/WPA2-PSK ne sera utilisable que pour les SSID qui auront été utilisés pour sa création. D'où la nécessité d'opter pour un SSID personnalisé, éventuellement unique, quand on configure son accès. Certains FAIs vous en fournissent un par défaut, d'autres non, et ce n'est jamais le cas sur les routeurs ou points d'accès qu'on trouve dans le commerce.

Ensuite en mettant en œuvre un nombre conséquent d'itérations d'une fonction de hash pour atteindre un temps de calcul conséquent, sans être prohibitif. En effet, lors d'un accès légitime, la dérivation est faite une fois à l'initialisation ; on peut se permettre un mécanisme un peu gourmand dans la mesure où il ne sera pas répété par la suite. Alors que lors d'une attaque, il faut exécuter la fonction pour chaque nouveau mot de passe à tester. L'impact est alors nettement plus conséquent. Pour le Wi-Fi, on va itérer un peu plus de 8000 fois un SHA-1. Ceci a pour effet de faire exploser la complexité du calcul. Là où tester un mot de passe en MD5 requiert environ 300 opérations, tester une PSK en demande presque 16 millions.

Bref, c'est pas simple à attaquer quand c'est bien fait. Le FBI vient de nous le confirmer en se cassant les dents sur TrueCrypt.

Note aux curieux d'entre vous qui se poseraient des question sur PBKDF2 : il pourront en trouver une excellente analyse, en français qui plus est, sur le blog d'Artiflo^[1].

Pour en revenir à TrueCrypt et au FBI, on notera deux articles traitant de l'affaire. Le premier est celui de Globo. Dans ce dernier, un passage m'a fait sourire :

The government has no legal instrument to compel the 
manufacturer of the American encryption system or Dantas 
to give the access codes.

Décidemment, cette croyance comme quoi les éditeurs de systèmes cryptographiques sont forcément capables de fournir la clé de toute donnée chiffrée avec leur système à la vie dure. Pas que ce soit forcément faux, mais c'est quand même rarement vrai, en particulier dans le monde du logiciel libre.

Le second article est publié par Computer World UK. Il remarque qu'en 2008, quand Dantas a été arrêté et ses disques saisis, un papier décrivant sur des failles dans TrueCrypt 5.1 avait été publié. Mais comme indiqué, il est clair que les techniques décrites ne permettent pas d'attaquer un volume chiffré tel qu'on le récupère lors d'une saisie. Au mieux trouvera-t-on quelques fuites... Et encore...

Par contre, ce que cet article démontre, c'est l'existence de techniques qui permettent d'identifier l'existence d'un volume chiffré caché en étudiant le système qui l'utilise. Encore un argument pour le chiffrement complet de disque, OS compris...

Notes

[1] Blog dont je vous recommande la lecture.