Dernière version du 26 novembre 2019 à 22:07

Travail réalisé dans le cadre de l'info 910 | WIP

Nous allons vous présenter Logjam, une attaque révélée en 2015 par une équipe multinational de chercheurs du domaine privé et public. Cette attaque permet à un attaquant de se faire passer pour un serveur légitime lorsqu’une transaction TLS a lieu avec un client.Cette attaque exploite les faiblesses des configurations des serveurs, notamment le support de Diffie-Hellman avec des clés de 512 bits ou encore la réutilisation de nombre premiers.Cette faille touche environs 8% des sites webs du top 1 millions d’Alexa. Ainsi, après une semaine de pré-calcul, les chercheurs ont pu mené des attaques contre des sites sensibles comme: tips.fbi.gov. Nous allons donc commencer par voir le protocole TLS avant de nous intéresser à l’attaque en elle-même. Enfin nous verrons quels sont les moyens de s’en prévenir.

Protocole TLS

TLS (Transport Layer Security ) est un protocole de sécurisation pour les échanges sur Internet. Il utilise un mode de communication client-serveur, où il y a d’un côté le client qui envoie des requêtes, et de l’autre le serveur qui attend les requêtes du client et y répond.L’avantage de celui-ci, est que le serveur est authentifié, et que les données échangées sont confidentielles et intègres.Au sujet de son fonctionnement, il utilise la cryptologie, donc il transforme les données grâce à un algorithme et une clé de chiffrement afin de les rendre illisibles.Pour commencer, le protocole utilise la cryptographie asymétrique avec un certificat pourauthentifier le serveur, puis il utilise l’algorithme Diffie-Hellman pour que le client et le serveur se mettent d’accord sur une clé de chiffrement, pour finir il utilise la cryptographie symétrique pour la communication des messages.

Cryptographie asymétrique avec certificat

Dans la cryptographie asymétrique, on utilise deux clés, une clé publique et une clé privée. L’une des clés sert à chiffrer le message, et l’autre à déchiffrer.

Fonctionnement :

Alice et Bob ont chacun une clé publique et une clé privée
Alice transmet sa clé publique à Bob, et Bob transmet sa clé publique à Alice, mais ils gardent tous les deux leur clé privée
Bob veut envoyer un message à Alice, alors il chiffre son message avec la clé publique d’Alice
Alice déchiffre le message en utilisant sa clé privée, comme elle est la seule à posséder cette clé, personne d’autres peut déchiffrer le message
De la même façon, si Alice veut répondre à Bob, elle chiffrera son message en utilisant la clé publique de Bob
Puis Bob utilisera sa clé privée pour déchiffrer le message

Les points positifs de cette méthode est qu’elle assure la confidentialité des messages, car seule le détenteur de la clé privée peut déchiffrer les messages chiffrés avec la clé publique. Puis, elle authentifie l’expéditeur, car si le message ne peut pas être déchiffré avec la clé privée, alors ce n’est pas le bon expéditeur, car il n’a pas chiffré le message avec la bonne clé publique.

Le problème est la transmission de la clé publique, d’où l’attaque du MITM ( Man In The Middle ). Une personne malveillante peut se positionner entre Alice et Bob, donner sa clé publique à la place et récupérer celles d’Alice et Bob.

Afin de résoudre ce problème, le protocole TLS utilise un certificat pour identifier le porteur de la clé. Ce certificat contient la clé publique de la personne, ses informations personnelles comme son nom et son email, des informations sur le certificat comme sa date de validité, ainsi qu’une signature électronique de l’AC ( autorité de certification ). La signature électronique est la combinaison de toutes les informations du certificat et de la clé publique, tout ceci chiffré avec la clé privée de l’AC, qui est l’institution créant les certificats et garantissant que les informations contenus dans ceux-ci sont corrects.

Donc, afin d’authentifier le porteur de la clé : Alice créer un certificat en fournissant ses informations et sa clé publique à l’AC L’AC vérifie et crée le certificat avec la signature électronique Alice envoie son certificat à Bob Bob déchiffre la signature électronique avec la clé publique de l’AC et vérifie si les informations sont corrects, si c’est le cas, alors le porteur de la clé est authentifié

Algorithme Diffie-Hellman

Maintenant que le serveur est authentifié, il doit se mettre d’accord sur une clé de chiffrement avec le client. Pour ceci, le protocole utilise l’algorithme de Diffie-Hellman.

Fonctionnement :

Alice et Bob se mettent d’accord sur deux très grands nombres, p et g, en communiquant en clair sur le réseau
Alice et Bob choisissent chacun de leur côté un très grand nombre aléatoire, qu’ils gardent pour eux. Soit a pour Alice et b pour Bob
Alice calcule A = g^a mod p, et le transmet à Bob
De même pour Bob, il calcule B = g^b mod p, et le transmet à Alice
Puis, Alice et Bob calculent K = B^a mod p = A^b mod p

Ainsi, Alice et Bob se sont mis d’accord sur une clé de chiffrement secrète.

Grâce à cet algorithme, la confidentialité est garantie car si l‘attaquant intercepte les communications, il ne pourrait pas retrouver la clé privée à partir des informations transmises en clair Sachant que a et b sont de très grands nombres, il est presque impossible de retrouver leur valeur.

Cryptographie symétrique

Après que le client et le serveur se sont mis d’accord sur une clé de chiffrement, ils vont pouvoir communiquer en utilisant la cryptographie symétrique.

Dans la cryptographie symétrique, on utilise qu’une seule clé pour chiffrer et déchiffrer un message.

Fonctionnement :

Alice et Bob ont une même clé secrète
Alice veut envoyer un message à Bob, alors elle chiffre son message avec la clé secrète, et l’envoie à Bob
Bob déchiffre le message avec la même clé secrète
De la même façon, si Bob veut répondre, il chiffrera son message avec la clé secrète en l’enverra à Alice

L’avantage de cette méthode, est que personne ne peut lire les messages envoyés car ils sont chiffrés avec la clé secrète.

Le problème qui peut se poser est l’échange de la clé secrète, mais comme on utilise l’algorithme de Diffie-Hellman, alors l’échange de la clé est sécurisée.

Attaque “Logjam”

Principe

L’attaque Logjam, rendu public en 2015, se base sur l’échange des paramètres qui est effectué au tout début d’un handshake via TLS. En effet pour des soucis de compatibilité historiques, le client envoie une liste d'algorithmes cryptographiques supportés qui est ensuite choisi par le serveur. Par exemple, l’algorithme Diffie-Hellman est supporté par environ deux tiers des sites utilisant HTTPS. Pour cracker Diffie-Hellman, il faut donc trouver la valeur a à partir de A, g et p qui vaut: A = g^a mod p, ce qui est le problème du logarithme discret et impossible en temps raisonnable lorsque p est bien choisi (notamment s’il est de longueur supérieur à 1024 bits et s’il est “sûr”, c’est à dire qu’il peut s’écrire de la forme 2p + 1, avec p un autre nombre premier). Cependant, une partie des serveurs mondiaux, 8% en général et jusqu'à 29% pour les serveurs mails, supportent encore “export-DHE”, une version historique de Diffie-Hellman utilisant 512 bits.

Ainsi, pour exploiter cette faille, un attaquant en position de Man-In-The-Middle, peut récupérer la liste des algorithmes cryptographiques envoyé par le client et la remplacer par l’unique option “export-DHE” ce qui va forcer le serveur à baisser le niveau de sécurité pour la suite de la transaction. Cette méthode marche également si le client ne supporte pas l’option “export-DHE” car il verra par la suite la réponse du serveur comme une demande d’utiliser Diffie-Hellman de manière classique où seulement les paramètres sont étonnamment peu sécurisés.

L’attaque en pratique

TLS possède néanmoins des éléments de protections contre les attaques type Man-In-The-Middle, en utilisant une authentification à la fin de l’échange via un MAC de l’ensemble des messages échangés depuis le début. Ainsi pour que l’attaque fonctionne en pratique, l’attaquant doit pouvoir découvrir le secret avant la fin du handshake TLS.

Plusieurs éléments permettent à un attaquant de retrouver ce secret, le premier est l’algorithme “number field sieve”, (NFS) qui est, à ce jour, l’algorithme le plus rapide pour factoriser des entiers relativement grand (supérieur à 10^100). Néanmoins en utilisant l’algorithme tel quel, le secret ne serait découvert qu’au bout d’une semaine sur un ordinateurs à plusieurs milliers de coeurs. Les chercheurs ont néanmoins tiré parti du fait que les 3 premières étapes de l’algorithme nécessite uniquement p, hors ce nombre premier est régulièrement utilisé, pour éviter de devoir recalculer un nombre premier avec les bonnes propriétés à chaque nouvelle connection. Or 2 nombre premier sont utilisé par 92% des sites https. NFS peut ainsi être pré-calculé pour ces 2 nombres ce qui permet d’obtenir une table de logarithmes pour un nombre premier donné.

À partir de cette table, de A et de g, les chercheurs ont pu trouver le secret a dans un temps de l’ordre de la minute sur un serveur puissant (2 CPU à 18 coeurs d’Intel, Xeon E5-2699 avec 128 GB de RAM). Ce temps est donc acceptable pour des processus qui n’ont pas de timeout sur les handshake TLS, comme git ou curl. Pour les autres processus, comme l’affichage de page web, l’attaquant doit utiliser des éléments comme les messages d’alertes TLS qui sont ignorés par les navigateurs mais permettent de remettre à zéro le timeout. Un autre élément est la réutilisation par le serveur de B pour de multiple transactions. Microsoft Schannel, par exemple, utilise la même valeur pendant 2 heures. Un attaquant peut donc observer un B d’une transaction, calculer le logarithme et l’utiliser pour de futur handshake. Enfin un dernier élément à la disposition des attaquant est le faux départ TLS qui permet de reporter l’envoie de la signature final (en permettant au client de commencer à envoyer les données nécessaire à l’affichage d’une page web par exemple). Ce qui laisse donc d’avantage de temps à l’attaquant pour cracker le secret.

Résolution

Afin d’éviter cette attaque, il faut mettre à niveau les principaux navigateurs Web en appliquant une taille minimale plus grande pour les clés DHE reçues. Le problème est que ça va casser quelques serveurs qui négocient le DHE avec des clés de 512 bits. Heureusement, les principaux navigateurs ont accepté d’appliquer une taille minimale de 768 bits ou de 1024 bits. Donc, actuellement la grande majorité des serveurs utilisent des modules Diffie-Hellman avec une longueur minimale de 1024 bits.

Comme décrit précédemment, l’attaque NFS nécessite d’effectuer de nombreux calculs préalables pour trouver le nombre premier p de Diffie-Hellman, suivi d’un calcul court pour rompre toute connexion grâce à p. Pour les modules de 512 bits, le pré-calcul nécessite qu’une semaine environ, alors que pour 1024 bits, c’est de l’ordre de 35 millions d’années. Il faudrait un équipement informatique de plusieurs milliards de dollars afin de pouvoir effectuer le pré-calcul dans un délai raisonnable.

Cependant, selon une série de documents publiés par Snowden, des preuves montrent que la NSA dispose de moyens pour décrypter des connexions IPSec et SSH. En effet, le pré-calcul NFS peut être réalisable lorsque les nombres premiers à 1024 bits sont réutilisés. Les attaques peuvent être basés sur un chiffrement symétrique faible ou sur un générateur de nombre aléatoire incorrect. Toutefois, il existe quelques preuves qui montrent qu’une rupture de Diffie-Hellman est possible. Tour d’abord, l’échange de la clé de chiffrement est vulnérable au calcul préalable car celle-ci utilise un petit nombre de nombre premiers normalisés appelés groupes d’Oakley. De plus, les logiciels malveillants permettent à la NSA de contourner complètement la négociation de la clé de chiffrement.