Au printemps dernier, en collaboration avec des chercheurs de l’Inria Paris-Rocquencourt, de Microsoft Research, et des universités américaines Johns Hopkins, du Michigan et de Pennsylvanie, nous avons mis en évidence une faille importante dans le protocole TLS qui permet de sécuriser les connexions Internet. Cette faille affectait un grand nombre de services Internet (Web, mail, vpn, etc), avec des conséquences allant de l’absence de confidentialité à l’usurpation d’identité de serveurs. Dans cet article, nous souhaitons revenir sur cette attaque et ses implications pratiques.

TLS, un protocole omniprésent sur Internet

Le protocole TLS (pour Transport Layer Security) est le mécanisme qui est mis en œuvre de manière automatique, et souvent transparente pour l’utilisateur, dès que l’on souhaite sécuriser une connexion Internet entre deux machines. Par exemple, la différence entre deux adresses Web de la forme http://fr.wikipedia.org et https://fr.wikipedia.org est que, dans le second cas, les échanges de données entre ma machine et le serveur de Wikipédia seront chiffrés par TLS. Plus précisément, le rôle de TLS dans ce type de connexion est d’abord de garantir la confidentialité : ni mon fournisseur d’accès, ni personne qui écoute sur la ligne ne doit pouvoir connaître le contenu de la communication. Tout au plus, on pourra savoir que je me suis connecté à Wikipédia et connaître la quantité de données qui aura transité sur le réseau.

adrian_ilie825/FOTOLIA.COM

adrian_ilie825/FOTOLIA.COM

Partager

Partager

Une autre fonction de TLS, tout aussi critique, est l’authenticité. Grâce à un système de certificats, véritables cartes d’identité numériques des serveurs Web, je suis certain que les pages que je vois sont bien fournies par Wikipédia, et non par un serveur pirate usurpant son identité.

TLS est un protocole très complexe où de nombreux algorithmes cryptographiques sont combinés, avec pour objectifs la sécurité et la rapidité d’exécution. Au tout début de la connexion, dans une première phase appelée handshake, les deux machines (le serveur Web et mon ordinateur personnel, dans l’exemple ci-dessus) s’entendent sur les algorithmes à utiliser. En effet, pour des raisons d’interopérabilité, un serveur se doit de parler de très nombreuses langues cryptographiques, sachant que de nombreux ordinateurs ne sont pas très à jour et ne connaissent que des algorithmes datant d’il y a une dizaine d’années. Ensuite, les deux machines fabriquent et s’échangent ce qu’on appelle une clé de session. Cette clé temporaire va servir à chiffrer les communications durant la connexion.

Assez de chiffres pour chiffrer ?

Au sein de TLS, les calculs permettant aux deux machines de s’entendre sur une clé se font souvent à l’aide de l’algorithme de Diffie-Hellman, dont la sécurité repose sur un problème mathématique complexe : le problème du logarithme discret.

Sans entrer dans les détails, on peut dire que le problème du logarithme discret repose sur l’utilisation de grands nombres premiers, et que plus ces nombres sont grands, plus le système sera sûr, mais plus les calculs seront lourds. Quantifier précisément ce compromis est notre spécialité.

L’attaque Logjam : un problème de taille

Pour comprendre l’attaque Logjam, il faut se souvenir de la législation américaine à la fin des années 1990. L’export de produits cryptographiques était alors très réglementé. En conséquence, les protocoles de chiffrement prévoyaient explicitement un mode « Export » lors des connexions, limitant la taille des nombres premiers utilisés à 155 chiffres.

Cette « tare génétique » de TLS est encore présente dans les spécifications, et dans bien des logiciels, aussi bien du côté des serveurs que dans les ordinateurs personnels. Ce mode n’est certes pas activé par défaut, mais toujours considéré acceptable si l’une des machines le demande lors du handshake. Une petite subtilité dans le protocole (qu’on peut tout à fait qualifier de bug de conception) fait qu’un attaquant malintentionné peut se glisser au milieu de la connexion et faire croire aux deux protagonistes que l’autre désire passer en mode Export. Cela requiert toutefois de résoudre le problème du logarithme discret pour un nombre de 155 chiffres.

GUIDO ROSA/IKON IMAGES/CORBIS

GUIDO ROSA/IKON IMAGES/CORBIS

Partager

Partager

Un calcul qui, nous l’avons vu, est désormais faisable si l’on dispose de quelques semaines et de moyens de calculs modérés, mais pas durant les quelques secondes que dure le handshake… Le souci vient d’une seconde subtilité, bien connue des spécialistes du logarithme discret : quand le nombre premier ne change pas, des précalculs permettent de résoudre chaque instance bien plus rapidement. Ainsi, pour un nombre de 155 chiffres, quelques jours sur un cluster d’un millier de cœurs de processeurs modernes sont nécessaires pour faire ce précalcul, mais ensuite, le cassage du logarithme discret peut être effectué en quelques secondes. En pratique, seule une poignée de nombres premiers différents sont effectivement utilisés. La raison n’est pas théorique (il y a énormément de nombres premiers de la taille voulue), mais uniquement pour faciliter la mise en pratique ; et de fait, si la taille du nombre premier était suffisante, cela ne poserait pas de problème. Mais avec un nombre limité de nombres de 155 chiffres, au final, l’attaque s’avère très réaliste.

L’importance des preuves de concept

Convaincre qu’une faille de sécurité est réellement exploitable est un art difficile. Dans le cas de l’attaque Logjam, il ne suffit pas de démontrer mathématiquement que le calcul peut s’effectuer pendant le handshake. Dans ce contexte, présenter un logiciel qui y parvient avec des moyens modérés est un argument crucial. Or c’est ce que permet notre logiciel CADO-NFS de factorisation d’entiers et de calcul de logarithme discret. Développé depuis huit ans, principalement par les membres de notre équipe nancéienne et diffusé librement, il permet de forcer les vendeurs de solutions de sécurité à se plier aux nouvelles recommandations quant aux tailles des nombres premiers à utiliser.

Ainsi, lors de la publication de la vulnérabilité, celle-ci a été prise particulièrement au sérieux : des milliers de serveurs ont été reconfigurés pour ne plus accepter de passer en mode Export, et les navigateurs des ordinateurs personnels ont également été mis à jour.

Les regards se tournent alors évidemment vers les agences de renseignement. La paranoïa ambiante vis-à-vis de la NSA à la suite des révélations d’Edward Snowden incite d’autant plus à ne pas jouer avec le feu : augmentons les tailles des nombres premiers ! Il est grand temps de suivre les recommandations et de passer à des premiers d’au moins 600 chiffres ! Mieux encore, la cryptographie moderne se doit de continuer la transition vers des algorithmes de chiffrement plus sûrs qui reposent sur des fonctions plus complexes comme les courbes elliptiques.

Les points de vue, les opinions et les analyses publiés dans cette rubrique n’engagent que leur auteur. Ils ne sauraient constituer une quelconque position du CNRS.