E. Thomé, Inria : « Les clefs de chiffrement de 768 bits ne suffisent plus »

Sécurité
6 15 Donnez votre avis

Un des chercheurs à l’origine de la découverte de la faille LogJam, logée dans les systèmes de chiffrement, détaille les implications de ses travaux. Où il apparaît clairement que les clefs de moins de 768 bits sont aisément à portée de calculs d’un Etat. Et que même le 1024 bits ne semble plus inaccessible à la NSA.

Suite à la découverte de la faille LogJam affectant la plupart des protocoles de chiffrement (SSL, TLS, SMTPS…), nous avons interrogé Emmanuel Thomé, chargé de recherche à l’Inria Nancy. Ce spécialiste des calculs permettant d’attaquer les primitifs cryptographiques (autrement dit les algorithmes de bas niveau sur lesquels reposent, en pratique, les systèmes de sécurité) fait partie de l’équipe de chercheurs qui a mis au jour la faille LogJam, exploitant des caractéristiques héritées d’une vieille réglementation pour dégrader les longueur des clefs utilisée dans les échanges chiffrés.

Mais l’étude publiée par les chercheurs montre aussi que l’algorithme Diffie-Hellman, une de ces briques de base des systèmes mis entre les mains des utilisateurs, n’est, dans certains cas, plus hors de portée des capacités de calcul des services de renseignement comme la NSA. Même en dehors de toute exploitation d’une faille.

Emmanuel ThoméSilicon.fr : A quoi sert l’algorithme Diffie-Hellman dans lequel réside la faille LogJam mise au jour dans des travaux de recherche auxquels vous avez participés ?

Emmanuel Thomé : C’est une méthode d’échanges de clefs qui fait partie des briques élémentaires de la cryptographie. Elle permet à deux personnes ne se connaissant pas de s’entendre sur un secret commun, et de communiquer dans des échanges à priori impossibles à déchiffrer par un tiers n’ayant pas ce secret en main. Cet algorithme sert dans l’initialisation de nombreux protocoles de sécurisation des communications : VPN, HTTPS, SMTPS… Il s’appuie sur la difficulté à calculer les logarithmes discrets (objet mathématique utilisé en cryptologie, dans lequel des nombres sont élevés à une certaine puissance, NDLR). C’est d’ailleurs sur cet aspect que nous avons travaillé.

Est-ce que l’attaque LogJam est similaire à Freak, autre faille se logeant dans les systèmes de cryptographie ?

E.T. : La similarité réside dans le fait que ces deux vulnérabilités s’appuient sur un héritage des années 90, les restrictions à l’export des outils de chiffrement mises en place par les Etats-Unis. Dans les deux cas, cette réglementation aboutit à employer des clefs qui sont accessibles à un assaillant via les moyens de calcul actuels. Même si l’algorithme RSA, impliqué dans Freak, s’appuie sur un objet mathématique différent, la factorisation de nombres premiers.

Dans quelles conditions, un assaillant peut-il exploiter cette vulnérabilité de Diffie-Hellman ?

E.T. : Les échanges de clefs Diffie-Hellman s’établissent en utilisant des objets mathématiques répandus. Avant de déchiffrer une communication à proprement parler, un assaillant doit effectuer un précalcul. Cette opération est effectuée une fois pour toutes et sert ensuite lors de chaque communications VPN utilisant le même objet mathématique. Or, si Diffie-Hellman ne repose pas forcément sur le même objet mathématique, en pratique, dans les systèmes de chiffrement déployés, ces objets sont peu nombreux.

Via l’attaque LogJam, on force l’échange de clefs d’une longueur de 512 bits. Dans ce cas, le précalcul via la méthode que nous proposons ne demande que quelques dizaines de milliers d’heures de calcul sur un cœur processeur. Ensuite, le déchiffrement à proprement parler d’une communication requiert 90 secondes sur un processeur à 4 cœurs. On a donc là tout à fait la capacité à siphonner le contenu, d’autant que les calculs sont parallélisables (autrement dit peuvent être réparties sur de multiples unités de calcul, NDLR).

Quelles sont les implications sur les longueurs de clefs supérieures ?

E.T. : Nous montrons que le déchiffrement de communications établies avec des clefs de 768 bits est tout à fait à la portée d’un organisme académique, sans même parler d’un Etat. Le précalcul demande alors quelques dizaines de milliers d’années de calcul sur un cœur processeur. Et chaque déchiffrement mobilise 1 journée sur un cœur unique. Là encore, en tenant compte de la capacité à paralléliser ces calculs, ce sont des chiffres tout à fait raisonnables aujourd’hui. Et ce niveau ne nécessite même pas la mise en œuvre de l’attaque LogJam, visant à dégrader la longueur des clefs. Il faut savoir qu’environ 10 % des communications VPN ou HTTPS emploie des longueurs de clefs inférieures à 768 bits.

Avec une longueur de clef de 1 024 bits, les choses se compliquent. On parle alors de précalculs nécessitant des investissements se chiffrant en milliards de dollars. C’est évidemment énorme, mais pas totalement fantaisiste, le budget cryptographie de la NSA est de cet ordre.

LogJam impots
Le site des impôts utilise des clefs de 1024 bits. Les chercheurs recommandent de passer à 2048 bits.

Dans votre étude, pourquoi, précisément, établissez-vous un lien avec les documents Snowden ?

E.T. : Un des documents dévoilés par Edward Snowden décrivait une infrastructure de déchiffrement de communications VPN, mise en place par la NSA. Dès lors se pose la question du comment ; des calculs qu’effectuent les services américains et surtout des calculs en temps réels qu’ils mettent en œuvre pour parvenir à ce résultat. En développant l’attaque que nous détaillons dans notre article, nous montrons une voie possible pour mettre en place de telles infrastructures de déchiffrement.

Comment les entreprises peuvent-elles se protéger ?

E.T. : Les administrateurs doivent reconfigurer les serveurs VPN pour bannir les dimensionnements insuffisants de clefs. Et modifier les paramètres des serveurs Apache ou autres. Nous avons publié une liste de recommandations sur le site dédié à LogJam.

A lire aussi :

LogJam : nouvelle faille dans le chiffrement des sites Web
Une application Android sur 10 victime de Freak
5 questions pour comprendre le déchiffrement SSL

Crédits photo : Inria

Lire la biographie de l´auteur  Masquer la biographie de l´auteur