Logo du CNRS Le Journal Logo de CSA Research

Grande enquête « CNRS Le Journal »

Votre avis nous intéresse.

Le CNRS a mandaté l’institut CSA pour réaliser une enquête de satisfaction auprès de ses lecteurs.

Répondre à cette enquête ne vous prendra que quelques minutes.

Un grand merci pour votre participation !

Grande enquête « CNRS Le Journal »
Donner du sens à la science

Logjam : la faille qui met Internet à nu

Logjam : la faille qui met Internet à nu

Des chercheurs mettent en garde contre une faille majeure dans le protocole qui sécurise les connexions Internet et expliquent pourquoi et comment il faut se prémunir contre cette faille.

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.

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é.

En informatique,
l’existence d’un
compromis entre
coût et sécurité
est fréquente,
et les dérives
qui s’ensuivent
bien connues.

Nous connaissons très bien les algorithmes en jeu et sommes détenteurs du record actuel du plus grand nombre premier pour lequel le problème du logarithme discret a été résolu1. Pour fixer les idées, ce record concerne un nombre premier de 180 chiffres, alors que la taille minimale recommandée actuellement est de l’ordre de 600 chiffres. Il y a donc de la marge ! Malheureusement, sur Internet, on trouve encore trop de systèmes protégés par des nombres premiers de seulement 300 chiffres, voire moins. En informatique comme dans d’autres domaines, l’existence d’un compromis entre coût et sécurité est fréquente, et les dérives qui s’ensuivent bien connues…

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.

Faille Logjam
Faille Logjam

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.

Il est grand temps
de suivre les
recommandations
et de passer à des
nombres premiers
d’au moins
600 chiffres.

Au-delà de l’attaque liée au mode Export, le second intérêt de notre travail a été de donner pour la première fois un ordre de grandeur du temps de cassage du logarithme discret, lorsque les précalculs étaient réalisés. Comme ce temps est finalement très faible, même pour d’assez grands nombres premiers, les questions de la faisabilité et du coût du précalcul deviennent critiques. Surtout quand on sait que ce coût sera amorti par le fait que le même précalcul peut être utilisé pour casser des millions de connexions.
 

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.

Commentaires

0 commentaire
Pour laisser votre avis sur cet article
Connectez-vous, rejoignez la communauté
du journal CNRS