Petit préalable. On utilise maintenant quotidiennement la cryptographie pour sécuriser le fonctionnement des systèmes informatiques aussi bien que les transactions sur Internet. Quand on se connecte à un commerçant pour passer commande et qu'on lui fournir son numéro de carte bancaire, la communication est chiffrée et authentifiée, c'est-à-dire que l'on est assuré de bien parler au commerçant et non à un imposteur, et que lui seul peut lire les messages envoyés. (En réalité c'est un peu plus compliqué mais ce n'est pas l'objet de ce message.)

Considérons les cartes bancaires. On attribue à chaque usager un code à quatre chiffres. L'idée est qu'un voleur aurait une chance sur 10000 (codes de 0000 à 9999) de trouver par hasard le code. Même s'il a réussi à espionner le client et à voir 2 chiffres sur les 4, il n'a qu'une chance sur 100 de retrouver les deux autres. Cela fonctionne parce que le code à quatre chiffres est aléatoire et uniformément distribué : il y a autant de chances que le code soit 0000 que 5123. Si par contre on n'attribuait de codes que parmi une liste restreinte de 110 codes, le voleur aurait bien plus de chances de devenir le bon.



La cryptographie fait un fréquent usage de nombres aléatoires. Elle fait notamment usage de clefs, qui jouent un rôle semblable au code secret de la carte : c'est une information tenue secrète qui permet de déchiffrer les messages, ou de s'authentifier comme étant une certaine personne. L'idée est que les clefs sont tirées dans des ensembles de milliards de milliards de clefs toutes aussi probables les unes que les autres, de sorte que même avec un ordinateur très puissant on ne puisse pas toutes les essayer une par une (ce qu'on appelle une attaque par la force brute).

Ce n'est pas facile de générer des nombres aléatoires à l'aide d'un ordinateur. En effet, un ordinateur est (grosso modo) une machine déterministe : si on lui donne un calcul à faire (et un ordinateur ne sait faire que cela) et des données, il donnera toujours le même résultat sur les mêmes données. Lui faire fournir un nombre aléatoire relève donc de la gageure. Sur certains systèmes informatiques, on trouve des dispositifs matériels tirant partie de la physique quantique pour produire du hasard, mais cela est rare. En pratique, on utilise plutôt le caractère imprévisible de certaines actions... par exemple l'instant exact où un utilisateur appuie sur les touches du clavier ou bouge la souris.

Toutes ces données imprévisibles (actions de l'utilisateur sur le clavier et la souris, instant précis où des données arrivent du réseau, etc.) sont stockées dans une zone appelée pool d'entropie. Combinées avec d'autres données, elles servent à produire des nombres aléatoires.

Figurez-vous que depuis deux ans, un générateur aléatoire utilisé à des fins cryptographiques livré dans une des principales distributions Linux (Debian) n'utilisait pas de pool d'entropie. Au lieu de choisir des clefs parmi des milliards de milliards, il les choisissait parmi quelques dizaines de milliers éléments... nombre modeste qui laisse la possibilité d'une attaque par la force brute.

Je reviendrai plus tard sur les conséquences, mais en résumé : il semble qu'actuellement, il y a tout un tas de systèmes informatiques où l'on peut pénétrer simplement en essayant les quelques dizaines de milliers de clefs à l'aide d'un programme automatisé. Et il n;y a pas que Debian Linux de touché : diverses autres distributions sont concernées, ainsi qu'apparemment aussi des dispositifs matériels pour réseau utilisant Debian en interne... De plus, sont touchés tous les systèmes, y compris Windows, où l'on utilise des clefs générées sur Debian et variantes.

Comment a-t-on pu en arriver là ? L'histoire est tout bonnement incroyable, et rien ne serait arrivé si on avait tenu compte de ces deux maximes simples et que je crois ma maman m'a enseignées quand j'étais petit :

  1. La route de l'enfer est pavée de bonnes intentions.
  2. On ne touche pas à ce qu'on ne comprend pas.

Ajoutons une maxime de l'informatique : if it ain't broken, don't fix it (on ne répare pas ce qui n'est pas cassé).

Le responsable du paquet OpenSSL dans Debian a voulu bien faire. (Le rôle de cette personne est de prendre les logiciels provenant de chez OpenSSL/OpenSSL et de les préparer spécifiquement pour l'usage sur Debian.) Debian avait décidé de chasser les bugs et pour cela passait sur les programmes qu'ils livraient un outil remarquable appelé Valgrind. Cet outil détecte des comportements suspects, qui dénotent probablement des bugs.

Ici, l'outil avait indiqué comme suspectes deux lignes d'OpenSSL, dont l'une concernait le générateur d'aléa. Le responsable du paquet Debian a donc pris sur lui... de supprimer la ligne litigieuse, dont il ne comprenait pas très bien à quoi elle servait. Si j'ai bien compris, il en a aussi discuté sur des listes de diffusion et personne n'a bronché. Or, cette ligne servait à copier le pool d'entropie.

Le principal danger en matière de cryptographie est qu'on a des gens qui ne comprennent pas ce qu'ils font qui s'en mêlent. Ainsi, une collègue m'expliquait encore hier que divers produits industriels avaient des faiblesses assez bêtes en matière de cryptographie parce qu'ils sont conçus par des non-cryptographes. Je ne pensais pas cependant qu'on irait au point d'avoir des gens qui suppriment des lignes de code au milieu d'un élément central de la sécurité cryptographique au motif qu'elles génèrent des avertissements, qu'ils ne comprennent pas ce qu'elles font, mais que ça semble toujours fonctionner même si on les supprime.

Deuxième problème : alors qu'il n'y avait aucune urgence à apporter un correctif, le responsable de paquet a pris sur lui d'apporter une modification au logiciel, alors qu'il aurait simplement dû signaler ces deux lignes aux concepteurs du logiciel et attendre leur réponse.

Troisième problème : personne ne s'en est aperçu. L'argument souvent ressorti pour justifier de la qualité des logiciels Open Source est que http://en.wikipedia.org/wiki/Linus's_Law, autrement dit, s'il y a de nombreux relecteurs, les bugs finissent par être mis en évidence. On s'est aperçu en cette occasion comme dans d'autres que même si le source est disponible, très peu de monde le relit. C'est un avatar d'un phénomène maintes fois constaté : quand il y a trop de monde, on finit par croire que quelqu'un d'autre s'est forcément chargé des corvées. (Richard Feynman a ainsi mentionné dans Surely you're joking Mr Feynman le cas de personnes qui avaient mis une note à un ouvrage qu'elles n'avaient en fait jamais reçu, probablement en se disant que ça passerait inaperçu parce que d'autres certainement auraient fait le travail consciencieusement.)

Les conséquences ? Je n'ai pas encore les idées très claires, mais, pour parler familièrement, c'est du lourd.

Je ne sais pas s'il y a un impact sur la sécurité des connexions https (notamment, commerce électronique).

Un correctif d'urgence a été rajouté à OpenSSH : des « listes noires » de clefs devinables sont interdites. Les systèmes mis a jour refuseront donc les utilisateurs utilisant ces clefs, ces utilisateurs devront donc en faire de nouvelles et les faire enregistrer sur ces systèmes. Sur les systèmes non mis à jour, les comptes appartenant à des utilisateurs utilisant des clefs devinables pourront être utilisés par des pirates, sauf si des précautions sont par ailleurs prises contre les attaques en force brute (par exemple, interdiction d'échecs de connexion répétés depuis la même adresse).

Le problème est donc plus large que Debian : tous les systèmes SSH de quelque provenance que ce soit doivent utiliser une telle liste noire, car le problème est au niveau des clefs utilisées.

Il semble également que toute clef DSA qui ait été utilisée pour faire de la signature sur un système Debian est compromise, vu que le générateur aléatoire ne fonctionnait pas.

PS: Alors que les agences de presse et le journal Le Monde avaient parlé en décembre 2006 d'une attaque assez peu pratique sur RSA via les caches de processeur, la « grande presse » ignore totalement ce trou énorme...