Le 17 octobre 2026, des chercheurs en sécurité ont alerté simultanément Apple, Google, Microsoft, Mozilla et l’autorité de certification (CA) eMudhra d’une faille critique : huit certificats CA intermédiaires émis par eMudhra utilisaient des clés privées correspondant à de minuscules entiers sur un seul octet, à savoir les valeurs 4, 56, 66, 115, 155, 156, 230 et 237.
Ces certificats s’appuient sur la courbe elliptique P-384. Selon les standards cryptographiques, une clé privée doit être un nombre aléatoire de 384 bits tiré au sort dans un espace d’environ 3,9 × 10¹¹⁵ possibilités, rendant toute recherche par force brute irréalisable. Mais lorsque la clé privée n’est qu’un scalaire valant 4 ou 56, il suffit à un attaquant de calculer les multiples successifs du point générateur (1×G, 2×G… jusqu’à 255×G) pour reconstituer la clé intégrale. L’expert en sécurité Scott Helme est ainsi parvenu à retrouver les huit clés privées couvrant 16 certificats en moins d’une seconde sur un simple ordinateur portable.
Une régularité formelle absolue
L’anomalie s’est logée dans l’angle mort des outils de contrôle automatisés : bien que l’entropie de ces huit clés fût virtuellement nulle, leur structure ne présentait aucun défaut apparent. Multiplier le point de base de la courbe P-384 par 4 engendre un point mathématiquement irréprochable sur la courbe, doté d’un encodage conforme, de paramètres valides et validant sans encombre les algorithmes de signature numérique. Chaîne de certification, dates de validité et extensions X.509 répondaient toutes rigoureusement aux normes.
Pour détecter la faille, il aurait fallu tester délibérément de petits entiers, un test absent des processus d’audit conventionnels des CA. C’est ce qui explique pourquoi ces certificats vulnérables ont pu subsister sur le réseau public durant dix-sept mois sans éveiller le moindre soupçon.
Émis en avril 2025, les huit certificats intermédiaires comprenaient six CA d’émission TLS (deux générations pour DV, OV et EV) et deux CA dédiées à la signature de code. En mai 2025, ils ont en outre fait l’objet d’une signature croisée par la racine AAA Certificate Services de Sectigo, étendant le périmètre à seize certificats au total, avec une échéance fixée à juillet 2039.
Un détail embarrassant découle des déclarations officielles d’eMudhra : l’organisme a affirmé que les clés privées étaient stockées en permanence au sein de modules de sécurité matériels (HSM). Si cette allégation est exacte, le HSM n’a fait que garder fidèlement une clé d’une valeur égale à 4. La conformité matérielle et la robustesse cryptographique sont deux notions sans rapport. Les discussions communautaires n’ont pas tardé à souligner l’ironie de la situation : les clés étant enfermées dans un HSM, personne n’a sans doute pris la peine d’en inspecter le contenu réel, laissant ainsi inaperçu le fait que le générateur de nombres aléatoires n’avait jamais fonctionné.
Figure : L’identité visuelle de l’autorité de certification eMudhra. Huit de ses certificats intermédiaires sont restés exposés en silence sur Internet pendant 17 mois. Source : blog de Scott Helme d’après le site officiel d’eMudhra
Un certificat Stripe signé avec la clé 4 : curl valide sans broncher
Dès lors que les clés privées étaient de facto publiques, usurper des identités numériques devenait un jeu d’enfant.
Scott Helme a utilisé la clé privée 4 pour signer un certificat à destination du domaine api.stripe.com, a lancé openssl s_server en local, puis s’y est connecté avec les clients usuels dans leur configuration par défaut. Le verdict s’est avéré sans équivoque : sous Linux et macOS, la commande curl a retourné SSL certificate verify ok ; la négociation TLS en Python s’est achevée avec succès ; Node.js a répondu authorized: true ; et la CryptoAPI de Windows a avalé le certificat sans broncher dès lors que la vérification dynamique des révocations n’était pas expressément requise.
La ligne de démarcation tient à l’architecture des magasins de confiance. Les navigateurs web reposent sur une gouvernance centralisée dotée d’une capacité de mise à jour à distance : Chrome a intégré les certificats concernés à sa liste CRLSet dès la soirée du 17 octobre, et Mozilla a réagi quelques heures plus tard via OneCRL. Le 20 octobre, Mozilla a publié un bulletin d’alerte et supprimé la racine eMudhra de NSS, tandis que Chrome a purgé la confiance associée dans la version 43 de son magasin racine. Par ailleurs, la journalisation obligatoire Certificate Transparency (CT) s’est avérée salutaire : les vérifications ont confirmé qu’aucun certificat frauduleux n’avait été enregistré dans les registres CT, préservant la navigation quotidienne du grand public de préjudices directs.
Les utilitaires en ligne de commande, les SDK applicatifs et les terminaux IoT obéissent en revanche à un principe différent : leurs magasins de confiance sont des collections statiques figées lors du déploiement. Ils ne consultent quasiment jamais de listes de révocation (CRL ou OCSP) par défaut et ne vérifient pas les registres CT. Des certificats déjà révoqués depuis longtemps au sein des navigateurs continuent donc d’y faire autorité en toute légitimité.
Figure : La rupture de la chaîne de confiance numérique ne provenait pas des fondements mathématiques, mais du processus de génération de la clé. Source : Ars Technica
Une révocation cantonnée aux seuls navigateurs
Faire l’inventaire de la surface exposée met en lumière l’étendue des risques résiduels.
Les scripts d’installation du type curl | sh (tels que rustup, nvm ou Homebrew) reposent sur la vérification HTTPS. Un attaquant en position d’interception pourrait falsifier la source et faire exécuter des binaires malveillants avec des privilèges administrateur sur des postes de développement. Les environnements d’intégration continue (CI/CD) s’avèrent plus délicats encore : les conteneurs GitHub Actions, GitLab Runner ou Jenkins abritent des clés d’accès aux infrastructures cloud et des secrets de déploiement, sans que personne ne mette à jour manuellement leurs magasins de certificats. Les flux inter-services (passerelles de paiement, webhooks, jetons OAuth) tributaires des images de base de conteneurs se retrouvent eux aussi directement dans la ligne de mire. S’y ajoute la signature de code sous Windows : des exécutables signés au moyen des certificats eMudhra compromis seront exécutés en toute confiance sur les postes ne vérifiant pas l’état de révocation.
L’expert en cryptographie Filippo Valsorda a souligné que l’effort d’assainissement pourrait dépasser l’ampleur de celui requis lors de Heartbleed : les serveurs Linux laissés à l’abandon, les images conteneurisées non maintenues et les outils CLI pourvus de leurs propres magasins racine figés laisseront subsister une longue traîne de vulnérabilités. Ben Cartwright-Cox a émis l’hypothèse qu’un extrait de code d’exemple avait pu se retrouver par mégarde en production, tout en s’étonnant qu’aucun audit ne l’ait identifié pendant dix-huit mois. Ian Carroll a résumé l’impasse avec gravité : ces clés sur un seul octet sont à la portée de tous, et une fois propagées dans la nature, aucun mécanisme ne permet de les rappeler intégralement.
Une dette de sécurité sur 13 ans
Pour les équipes d’exploitation, les leviers d’action immédiats sont restreints. Sur les machines sous contrôle, supprimer les racines eMudhra ou inscrire les certificats intermédiaires sur liste noire représente la mesure standard ; les systèmes s’appuyant sur OpenSSL doivent quant à eux s’assurer du rafraîchissement des paquets de certificats de l’OS. Le danger le plus tenace réside dans le parc d’équipements non administrés : routeurs grand public, caméras de surveillance, automates industriels, systèmes embarqués automobiles et terminaux de paiement intègrent des magasins de certificats gravés dans leur micrologiciel d’origine. Dès lors qu’un constructeur abandonne le support logiciel, il n’existe d’autre remède que le remplacement physique du matériel, sachant que les certificats ne parviendront à expiration naturelle qu’en juillet 2039.
Pour les concepteurs de systèmes et d’applications, l’incident sonne comme un avertissement architectural majeur. Figer une copie statique de magasin racine permet d’économiser une requête réseau lors de la négociation, mais se paie par la perte de toute faculté de révocation pendant plus de dix ans. Faire reposer un modèle de sécurité sur la simple conviction que « personne n’ira regarder à l’intérieur d’une clé privée » vole en éclats dès lors qu’un générateur de nombres aléatoires omet de s’initialiser.
Références :
- Blog technique de Scott Helme
- Rapport d’incident sur We Have A Problem
- Analyse approfondie d’Ars Technica
- Blog officiel de sécurité de Mozilla
- Discussion technique sur la communauté Hacker News
