Cérémonie de clés ratée chez eMudhra : huit clés d'AC de confiance faciles à casser

Huit autorités de certification intermédiaires exploitées par l'indien eMudhra ont été émises avec des clés privées que n'importe qui pouvait retrouver à partir des certificats publics en bien moins d'une seconde. Un chercheur connu sous le nom de « Wayne » l'a signalé le 17 octobre 2026. Mozilla a reçu le signalement à 20 h 06 UTC, transmis par le Chrome Root Program. Mozilla a retrouvé les clés de façon indépendante en deux heures environ, sans connaître la méthode du chercheur. Cela a confirmé que le problème se situait dans la génération des clés et qu'il était trivial à exploiter.

La cause n'est pas une intrusion. Selon eMudhra, il s'agit d'un script défectueux exécuté pendant une cérémonie de clés, et les contrôles humains ne l'ont pas détecté.

01Une faiblesse extrême des clés

Il s'agissait de clés à courbe elliptique P-384. Une clé privée correctement générée est un nombre tiré dans un espace d'environ 2^384 valeurs. D'après le rapport d'incident de Mozilla, les huit clés avaient toutes des valeurs inférieures à 256 : un attaquant n'avait donc que 256 candidats à tester. Les clés valaient 4, 56, 66, 115, 155, 156, 230 et 237. La clé privée de « EM OV TLS CA - G3C » était simplement 4.

Une clé publique à courbe elliptique étant le scalaire privé multiplié par le point de base de la courbe, un scalaire inférieur à 256 se retrouve en calculant quelques centaines de multiples de ce point. Il suffit ensuite d'une comparaison avec la clé publique du certificat. C'est ce qui explique les temps de récupération inférieurs à la seconde qui ont été rapportés. Ars Technica évalue la taille effective des clés entre 3 et 8 bits. Une analyse d'un éditeur parle d'« octets », ce qui est incohérent avec les valeurs mêmes des clés.

La clé d'une AC intermédiaire peut signer n'importe quel certificat d'entité finale rattaché à la racine située au-dessus. Un attaquant en possession de l'une de ces clés pouvait forger un certificat pour n'importe quel domaine et usurper l'identité de serveurs afin d'intercepter ou de modifier le trafic. L'exploitation exige toutefois une position active d'attaquant en intermédiaire (adversary-in-the-middle), comme le souligne Ars. C'est un obstacle élevé pour certains attaquants, mais facile à franchir pour quiconque contrôle un réseau local.

La portée compte. Les huit clés provenaient d'un lot de 24 intermédiaires générées le 30 avril 2025. Six émettent des certificats TLS et deux servent à la signature de code ; Sectigo les a toutes les huit signées en certification croisée en mai 2025. En comptant ces certifications croisées, 16 certificats étaient concernés.

02Ce qui a dérapé pendant la cérémonie

Une cérémonie de clés est la procédure scénarisée et supervisée par des témoins au cours de laquelle une AC génère ses clés les plus sensibles dans des modules de sécurité matériels (HSM). eMudhra affirme que la cérémonie a utilisé des HSM FIPS 140-2 de niveau 3. Sa déclaration mise à jour insiste sur le fait que la faille se situait dans une étape de la procédure, et non dans une absence de HSM.

Le récit publié sur Bugzilla donne la séquence suivante :

• La cérémonie a créé, à bord du HSM, les paires de clés ECC robustes attendues.
• Une dérogation approuvée a ajouté un test de wrap/unwrap, car ces clés devaient être exportables dans ce cas précis. Le wrapping consiste à chiffrer une clé sous une autre clé afin de pouvoir la transférer d'un HSM à un autre.
• Un défaut du code a aussi créé, à bord, une seconde paire de clés, faible.
• Les étiquettes de cette paire faible ressemblaient à celles des originales ; elle a donc été utilisée par erreur pour construire les demandes de signature de certificat (CSR), que la racine a ensuite signées.
• Les mêmes CSR ont été envoyées à Sectigo pour la certification croisée.

Rien dans cette chaîne n'exigeait une défaillance du matériel cryptographique. Le HSM a généré une mauvaise clé à la demande, et une personne ou un processus a choisi la mauvaise. L'entreprise reconnaît elle-même qu'une erreur de script a conduit à émettre des AC avec des clés faibles. Elle admet aussi des erreurs humaines à plusieurs étapes et promet de revérifier toutes les cérémonies de clés qu'elle a menées. Cela évoque l'absence de contrôles maker/checker (principe des quatre yeux). Personne n'a comparé les clés publiques certifiées à celles que la cérémonie devait produire, et personne n'a vérifié la taille ou le caractère aléatoire des clés avant que la racine ne signe.

03L'avertissement ignoré

Le détail le plus dérangeant est un précédent de 2025. Les questions de Mozilla à eMudhra renvoient au bug 1970728, de juin 2025. La clé servant à signer certaines CRL ne correspondait pas à la clé publique du certificat d'AC correspondant. eMudhra a retrouvé la seconde paire de clés, qui, elle, correspondait, et a re-signé les CRL avec celle-ci. L'entreprise n'a pas interrompu ses opérations pour se demander pourquoi deux paires existaient. Une CRL est la liste signée des certificats révoqués qu'une AC publie. Une AC dont la CRL échoue à la vérification a, par définition, un problème d'intégrité de clé.

Selon l'explication ultérieure d'eMudhra, les CRL avaient d'abord été signées avec les clés robustes d'origine. Ces signatures échouaient parce que les certificats avaient été émis sur les clés faibles ; les CRL ont donc été re-signées avec les clés défectueuses. Un éditeur d'avis de menace affirme que la faille a survécu environ 17 mois et deux cycles d'audit. Il s'agit d'une affirmation de seconde main, et je n'ai pas vérifié les détails des audits. Quoi que montre le dossier d'audit, l'incident de 2025 offrait une piste de diagnostic qui aurait révélé le problème, et il a été clos comme une erreur de configuration.

La découverte a été peu coûteuse. Selon les comptes rendus, le chercheur a testé le corpus CCADB des intermédiaires de confiance publique, et un récit indique que les vérifications open source paranoid_crypto de Google ont été utilisées. L'analyse de certificats publics à la recherche de clés faibles est une technique ancienne. Aucun élément public n'indique qu'il ait fallu quoi que ce soit d'exotique.

04La révocation, et pourquoi elle n'a pas mis fin à l'affaire

L'endiguement a été rapide pour le parc de navigateurs. Chrome a publié une mise à jour de CRLSet et Mozilla a poussé des entrées OneCRL le 17 octobre, sans redémarrage de navigateur nécessaire. eMudhra a révoqué les huit intermédiaires le 18 octobre (motif : caCompromise). Sectigo a révoqué les certificats de certification croisée le 19 octobre. Apple et Microsoft ont suivi dans les jours suivants, certains comptes rendus divergeant d'un jour ou deux sur les dates exactes. Le premier article d'Ars Technica, qui évoquait un ou deux jours pour les blocages dans les navigateurs, est plus lent que la chronologie primaire. Il notait aussi qu'Edge sous Windows 10 se connectait encore à des hôtes vulnérables au moment de la publication. Microsoft n'a pas donné de précisions.

Le problème le plus difficile concerne les clients qui n'exploitent pas les données de révocation. Mozilla a décidé de retirer en urgence la confiance accordée à la racine parente, emSign ECC Root CA - G3, afin de protéger les clients qui ignorent les informations de révocation ou ne peuvent pas retirer la confiance à des intermédiaires précis. Chrome a indiqué qu'il suivrait. Selon les comptes rendus, le retrait côté Chrome atteint tous les appareils le 27 octobre, soit aujourd'hui. Les correctifs de Mozilla pour Go et NSS ont été publiés le 20 octobre.

Filippo Valsorda, mainteneur de la cryptographie de Go, a déclaré à Ars que le nettoyage aurait une très longue traîne. Il a cité les objets connectés, les conteneurs, les machines Linux oubliées et les outils qui embarquent leur propre magasin de racines, et a comparé l'ampleur de l'affaire à celle de Heartbleed. Cette comparaison relève de son appréciation et reste non démontrée. Cloudflare, de son côté, a indiqué que les clés étaient approuvées dans sa propre pile et a publié des mises à jour clientes.

La révocation de confiance a un coût collatéral. Les données de Certificate Transparency au 21 octobre montraient environ 30 800 précertificats non expirés rattachés à la racine révoquée. eMudhra estimait qu'environ 97 % d'entre eux avaient été émis via ACME. L'entreprise migre ses abonnés vers sa hiérarchie RSA G1. Certains de ces certificats sont légitimes et doivent maintenant être remplacés à cause d'une défaillance sans rapport survenue en amont.

05Détection, et ce que cela révèle de la supervision

La question de savoir si quelqu'un a abusé des clés n'est pas totalement tranchée, mais les éléments disponibles sont rassurants. Ars n'a relevé aucune trace d'usage malveillant dans les journaux de transparence. Un compte rendu de seconde main indique que Google n'a trouvé aucun certificat TLS rattaché aux six intermédiaires enregistré avant leur blocage. Red Sift en a trouvé une poignée enregistrés après la divulgation, émanant de chercheurs testant les clés récupérées. eMudhra affirme qu'une seule intermédiaire a été mise en production et qu'aucune n'a émis de certificats clients. Les journaux de transparence ne détectent que les certificats qui y sont enregistrés, et des clients n'appliquant pas la CT auraient pu recevoir des faux non journalisés. Ce risque résiduel ne peut être exclu, et plusieurs analystes le disent.

Trois enseignements se dégagent :

1. Les audits échantillonnent les processus, pas les résultats. Une cérémonie qui passe une liste de contrôle supervisée peut tout de même certifier la mauvaise clé. Une vérification mécanique que la clé publique certifiée correspond à la clé voulue du HSM, ainsi qu'un contrôle d'entropie minimale, aurait détecté le problème.
2. Les anomalies exigent une analyse des causes profondes. L'écart de CRL de 2025 était un signal gratuit. Les questions publiées par Mozilla portent directement sur la raison pour laquelle il a été étouffé.
3. La révocation vaut ce que vaut sa distribution. Les navigateurs peuvent bloquer en quelques heures. Tout le reste passe par des mises à jour logicielles, et révoquer la confiance d'une racine entière est l'instrument brutal qui atteint la longue traîne.

Le conseil d'administration d'eMudhra a annoncé jeudi qu'il sortirait du marché mondial du TLS. Son président a invoqué les coûts de conformité et une activité qui représente environ 1 % du chiffre d'affaires. L'entreprise poursuit l'examen de ses cérémonies de clés, et l'analyse des causes profondes est incomplète. Les décisions de Chrome et de Mozilla sur sa racine RSA restante sont elles aussi en suspens. Il manque encore les journaux complets de la cérémonie, le diff du code et une explication des raisons pour lesquelles l'anomalie de 2025 n'a pas été suivie d'effet. Ces éléments permettraient de savoir s'il s'agissait d'un simple mauvais script ou d'un environnement de contrôle incapable de détecter une clé privée d'un octet.