Mea culpa :

C’est « amusant » de voir la confiance accordée à la cryptographie. Je me souviens encore d’une époque proche de la préhistoire en temps informatique (comprendre l’an 2000) où des responsables de banque criaient sur tous les toits et autres revues spécialisées combien leur site en ligne était sécurisé, puisqu’il utilisait de la cryptographie. Bien sûr, toute personne qui a réalisé ne serait-ce qu’un ersatz de pentest se rend bien compte de l’absurdité, pour ne pas dire de la bêtise, d’une telle assertion : une faille PHP include() ou une injection SQL, ça reste toujours des failles, que le canal soit chiffré et authentifié ou non. Bref, ça n’empêche pas de se faire rooter. À la décharge de ces hauts responsables et autres directeurs, ils ne sont pas les seuls à commettre des erreurs. La faille à la mode est due à la spirale infernale, à savoir Debian. Un article du présent numéro détaille les raisons de ce qui m’apparaît comme une des plus grosses failles jamais publiées. Pourquoi une des plus grosses ? Les conséquences sont simplement énormes. En gros, tout ce qui emploie de la cryptographie construite sur la version Debian d’OpenSSL depuis mi-2006 est à mettre à la poubelle. De manière évidente, ça signifie les clés SSH, les certificats SSL (pour se connecter à sa banque) ou encore certains VPN. S’il n’est pas toujours simple de mettre à jour tout ça, ça reste faisable. Non, le plus gros problème est ailleurs (comme la vérité).

Imaginons, vous comprenez que tout ceci est totalement fictif bien sûr, un endroit regroupant environ 400 personnes, plutôt sensibilisées à la sécurité. Au hasard, ça correspond à un amphi pour une conférence de sécurité (qui a dit SSTIC ? Imaginons toujours que des personnes aient voulu superviser le trafic, et qu’elles l’aient donc enregistré avec leur sniffer préféré. Eh bien, la bonne nouvelle, c’est qu’aujourd’hui elles pourraient déchiffrer tout ce trafic ! Sessions SSH, IMAPS ou POPS, connexions SSL vers des sites web : tout cela est déchiffrable a posteriori, sans demander une puissance de calcul incroyable (n’importe qui peut le faire chez lui). J’ai bien dit que c’était fictif, hein ? Enfin, j’espère… Plus drôle (ou pas), on peut se demander qui s’est rendu compte de cette faiblesse pendant ces deux ans, et qui en a donc profité. Au-delà de ça, il n’est pas rare de trouver des affaiblissements dans les fonctions cryptographiques, que ce soit volontaire ou non. En effet, il est techniquement simple d’introduire des limitations (invisibles) dans toutes les protections cryptographiques, et ce, que ce soit au niveau des algorithmes mathématiques (les fameuses trappes) ou au niveau de leur implémentation. Des exemples ? Hans Bühler, employé de la société suisse Crypto-AG, fut retenu en otage en Iran en 1995. Certains hommes politiques avaient parlé dans les médias, révélant des informations qui permirent au gouvernement iranien de comprendre que les matériels de communication (servant pour les militaires, la diplomatie, etc.) achetés à Crytpo-AG étaient piégés. Ou encore Lotus qui affaiblit volontairement – et le reconnaît ensuite publiquement – un générateur aléatoire dans la version de Notes livrée au gouvernement suédois en 1997. Et il en existe de nombreux autres, voire on déterre des vestiges du passé 1, résultats d’une époque où la cryptographie était considérée comme une arme chez nous… De ces quelques exemples, faut-il conclure que cette pratique est systématique ? Et si d’autres le font, qu’en est-il des entreprises françaises ?

J’en profite au passage pour corriger une erreur que j’ai commise dans un article paru par ailleurs sur ce thème. En parlant de Vista, j’attribue à tort une déclaration à B. Ourghanlian (Chief Security Officer de Microsoft France depuis 2001) stipulant que Microsoft aurait installé, à la demande du gouvernement, une clé de recouvrement. Erreur et imprécision de ma part, toutes mes excuses ! Une telle clé générique n’existe a priori pas, mais cette fonctionnalité est présente pour un annuaire Active Directory configuré pour cela : le séquestre des clés utilisateurs permet alors d’accéder à leurs données chiffrées. Plus généralement, comment prouver qu’un algorithme ne possède pas de trappe. C’est hélas impossible. On se retrouve confronté au paradoxe classique de la sécurité. D’un côté, on aimerait prouver tout un tas de choses pour se rassurer. De l’autre, on en est incapable et on en revient toujours à une question de confiance, et à qui/quoi on l’accorde.

Qu’il s’agisse d’erreurs volontaires ou non, de fonctionnalités, on sent bien que les conséquences sont énormes, et pas uniquement sur le plan technique. Les États sont, quant à eux, confrontés à un choix politique complexe entre protection des citoyens et autorisation d’outils susceptibles de nuire à l’intégrité de nos démocraties. Et si ces trappes étaient leur (bonne) réponse ? Du moins tant qu’elles ne sont pas découvertes par ailleurs : et là, c’est le drame… Bonnes vacances, on se retrouve à la rentrée, avec une surprise. Fred Raynal

1 http://expertmiami.blogspot.com/2008/06/francaises-francais-time-to-bend-over.html