4 !
eMudhra, une entreprise indienne qui se targue d’avoir délivré plus de 60 millions de certificats numériques, utilisait des clés privées très mal générées. Résultat : n’importe qui pouvait les utiliser pour certifier un site. Le travail pour faire le ménage est important et ne se limite pas aux navigateurs qui ont rapidement bloqué les certificats concernés.
Des ingénieurs en cryptographie se sont aperçus que huit clés privées de l’entreprise eMudhra, autorité de certification basée en Inde, étaient extrêmement mal générées. Elles mettent la sécurité des communications sur Internet en grande difficulté. L’entreprise indienne assure cependant qu’une seule d’entre elles était en production et qu’elle n’avait délivré aucun certificat.
Les certificats TLS permettent aux internautes d’authentifier un tiers et d’initier une communication sécurisée. Ils sont notamment utilisés pour sécuriser le protocole HTTPS. Mais ils reposent sur la certification émise par des autorités via une signature construite à partir d’une clé privée. Si un tiers obtient celle-ci, il peut créer des certificats et se faire passer pour quelqu’un d’autre, par exemple votre banque ou une entreprise de vente en ligne en laquelle vous avez assez confiance.
Des clés privées associées à huit certificats intermédiaires compromises
« Le samedi 17 octobre, à 20 h 06 UTC, Mozilla a reçu un signalement d’un membre de la communauté indiquant que les clés privées associées à huit certificats intermédiaires eMudhra avaient été compromises. Ces clés pourraient permettre à des pirates d’émettre des certificats HTTPS frauduleux pour des sites web qu’ils ne contrôlent pas », a expliqué Dennis Jackson, ingénieur en cryptographie chez Mozilla ce mardi 20 octobre dans un message envoyé à la communauté.
« Un pirate peut créer un faux certificat pour n’importe quel domaine et s’en servir pour usurper l’identité de serveurs afin d’intercepter ou de modifier le trafic. Il s’agit d’un incident de sécurité grave dont les répercussions s’étendent à l’ensemble d’Internet », ajoute Cloudflare dans un billet consacré au sujet.
Des clés « intrinsèquement faibles »
Le problème, découvert par un certain Wayne, est décrit sur un site nommé « eMudhra, nous avons un problème » créé par Dennis Jackson, un ingénieur de Mozilla. Il y partage la preuve de la compromission des certificats. Le chercheur en cryptographie, Scott Helme a analysé le problème dans un billet de blog.
« Ces huit certificats intermédiaires comprennent six autorités de certification (CA) délivrant des certificats TLS (DV, OV et EV, deux générations pour chaque type) et deux autorités de certification pour la signature de code, toutes créées en avril 2025. Chacune d’entre elles a également été signée de manière croisée par la racine « AAA Certificate Services » de Sectigo en mai 2025 », explique-t-il.
« Il s’agit de clés à un octet intrinsèquement faibles que n’importe qui peut factoriser, et ce problème ne peut pas être maîtrisé », ajoute le chercheur. « Intrinsèquement faibles » est presque une litote puisque, comme le souligne Scott Helme : « L’une des clés privées de l’autorité de certification eMudhra est le chiffre 4 ». « Il ne s’agit pas d’un nombre commençant par 4, ni du chiffre 4 suivi de quelques centaines de chiffres aléatoires, mais simplement du chiffre 4… », insiste-t-il. « Une autre est 56, et une autre encore 115 ». Elles étaient donc extrêmement faciles à trouver.
Normalement, avec des clés de ce type (courbe elliptique P-384), il faudrait un nombre aléatoire de 384 bits (48 octets), alors que dans le cas présent seul le dernier octet est utile ; les 47 autres ne contiennent que des 0. Retrouver la clé privée ne demande donc que 255 essais au maximum, autant dire en un claquement de doigts.
Les certificats rapidement bloqués pour la navigation web
Concernant la navigation sur le web, Mozilla, Chrome, Apple et Microsoft ont rapidement réagi. Ainsi Mozilla affirme que, moins de trois heures après avoir été prévenu, elle a bloqué les certificats dans Firefox via OneCRL. Les équipes de Chrome expliquent avoir fait de même via CRLSet. Les deux éditeurs ont aussi signalé qu’ils supprimaient le certificat racine eMudhra de leurs listes de certificats de confiance. L’entreprise indienne et Sectigo ont elles-mêmes révoqué les huit certificats en question.
L’équipe de Chrome explique aussi que, « par défaut, Chrome applique la transparence des certificats (Certificate Transparency, CT) à toutes les connexions s’appuyant sur des certificats racine figurant dans le magasin de certificats racine de Chrome, et rejette tout certificat TLS n’ayant pas été enregistré conformément à notre politique ». C’est le cas aussi de Firefox depuis la version 135. « Étant donné qu’aucun certificat TLS lié à ces six autorités de certification intermédiaires n’avait été enregistré dans CT avant notre blocage du CRLSet le 17 octobre, aucun certificat frauduleux émis par ces autorités de certification n’aurait pu être considéré comme fiable par défaut dans Chrome ou dans d’autres navigateurs appliquant la transparence des certificats ».
Sur son site, Dennis Jackson explique que les certificats sont aussi bloqués sur les appareils Apple depuis le 19 octobre et sur les plateformes Microsoft depuis le 20. Ainsi, les logiciels pour Windows et les systèmes d’exploitation d’Apple ne peuvent plus non plus être authentifiés par ces certificats.
Des services à mettre à jour, une résolution plus compliquée pour le matériel
Mais le problème reste pour nombre de services Internet. « La plupart des clients TLS autres que les navigateurs (c’est-à-dire pratiquement tout le reste, avec les paramètres par défaut), tels que curl, Python, Node, Go, Java, git, les gestionnaires de paquets ainsi que tous les scripts et démons dont vous disposez, effectuent trois actions importantes dans ce contexte : ils font confiance à un ensemble d’autorités de certification [CA bundle, en anglais] stocké sur le disque, ils ne vérifient pas la révocation par défaut et ils ne vérifient pas la CT », explique Scott Helme.
Certaines équipes de ces outils ont déjà réagi. Comme le liste The Hacker News, un correctif a par exemple été mis en place pour Go, pour Network Security Services, pour Python certifi, pour Homebrew-core ou encore pour Rust webpki-roots.
Le conseil est donc de mettre à jour tout ce qui peut l’être et qui intègre un ensemble d’autorités de certification [CA bundle]. Comme le souligne Scott Helme, reste le matériel ne pouvant pas être mis à jour et qui va donc faire confiance à ces certificats jusqu’à juillet 2039, date de leur expiration.
eMudhra assure qu’aucun certificat ne s’appuyait sur ces clés et qu’une seule était en production
De son côté, eMudhra explique depuis le 20 octobre enquêter sur l’incident. Ce mercredi 21 octobre, elle assure que « sept des huit [clés] intermédiaires n’ont jamais été utilisées en production. La seule qui ait été utilisée en production n’avait délivré aucun certificat ». Elle affirme les avoir révoquées mais insiste : « elles n’ont jamais émis de certificat ; par conséquent, aucun certificat utilisé où que ce soit ne s’appuyait sur elles ».
Mais comme l’explique Scott Helme, pendant 17 mois, tout le monde pouvait pourtant émettre ses propres certificats en utilisant ces clés et ainsi certifier un site ou un service. Le chercheur l’a testé sur un serveur local et un certificat pour l’API de paiement par Internet de Stripe api.stripe.com. « Avec les paramètres par défaut, curl a indiqué que la vérification du certificat SSL s’était bien déroulée, Python a mené à bien la négociation de connexion et Node a renvoyé la valeur authorized: true. Cela s’est vérifié sur toutes les machines Linux et macOS que j’ai testées », explique-t-il.
« Par mesure de précaution, la clé racine a été considérée comme non fiable par les programmes de gestion des clés racines. À notre connaissance, aucune autre clé racine ni aucune clé intermédiaire n’ont été générées à l’aide de ce processus défaillant », ajoute dans sa note eMudhra.
L’entreprise n’a pas encore fini son enquête. Mais elle assure qu’elle a bien généré des clés « sur des modules de sécurité matériels [Hardware Security Modules, HSM] certifiés FIPS 140 - 2 niveau 3. Les allégations selon lesquelles les HSM n’auraient pas été utilisés sont erronées ». Elle ajoute cependant que « le problème provenait d’une faille dans l’une des étapes de la procédure de génération, et non de l’absence d’HSM ». Ainsi, pendant cette procédure, une étape clé de « wrap/unwrap » » aurait, selon l’entreprise indienne, « généré un deuxième ensemble de clés, plus faibles, en plus des clés originales, plus fortes. Ce sont ces clés plus faibles qui ont été publiées dans les magasins de clés racines des navigateurs ».
Connexion
