# La clé privée valait 4 : comment huit autorités eMudhra ont perdu leur secret

> Huit clés d’autorités intermédiaires eMudhra tenaient dans un octet. Nous expliquons la découverte, le risque de faux certificats et la réponse des navigateurs.

Publié le: 2026-11-04  
Canonical: https://rootzero.eu/research/emudhra-cle-privee-quatre/

**Événement : 17 octobre 2026. Analyse rédigée le 4 novembre 2026.** Une clé privée d’autorité de certification n’est pas censée pouvoir être retrouvée à partir de son certificat public. Pour huit intermédiaires eMudhra, les scalaires privés étaient `4`, `56`, `66`, `115`, `155`, `156`, `230` et `237`, selon l’[enquête publique de Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449). La valeur `4` est spectaculaire, mais le problème est commun aux huit : **moins de 256 candidats** là où une clé P-384 correcte doit être tirée dans un espace d’environ 2³⁸⁴ possibilités.

Les clés concernées étaient des *intermédiaires*, pas les clés des racines. Le [dossier Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449) distingue **six autorités TLS**, sous `emSign Root TLS CA - G3`, et **deux autorités de signature de code**, sous `emSign Root CS CA - G3`. La compromission des six premières permettait de fabriquer des certificats HTTPS apparemment valides, sous réserve que le client fasse encore confiance à leur chaîne et que l’attaquant se place sur le chemin de la victime. La compromission des deux autres concernait la confiance accordée aux signatures de code, selon les usages autorisés par leurs certificats. [Mozilla](https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/) a bloqué les certificats dans Firefox le 17 octobre et a ensuite retiré la racine TLS concernée de NSS. [eMudhra](https://emudhra.com/en/post/certificate-security-incident) les a révoqués le 18 octobre et a annoncé son retrait du marché mondial des certificats TLS publics.

## Pourquoi un certificat public suffisait à retrouver le secret

Sur une courbe elliptique, la clé privée est un entier `d`, la clé publique un point `Q = d × G`, où `G` est le point générateur. Avec un `d` choisi uniformément sur 384 bits, retrouver `d` à partir de `Q` est le problème du logarithme discret, impraticable avec les moyens connus. Si `d` appartient à l’ensemble `{1, …, 255}`, il suffit en revanche de calculer `G`, `2G`, `3G` et ainsi de suite, puis de comparer chaque point à `Q`. Ce test utilise exclusivement le certificat public. Il ne demande ni accès au HSM ni fuite de fichier secret.

La taille nominale « P-384 » ne protège donc rien si la génération du scalaire s’est effondrée. Une clé de 384 bits dont la valeur est `4` n’offre pas 384 bits de sécurité. C’est une distinction fondamentale entre **format de la clé** et **entropie effective du secret**. Mozilla indique avoir retrouvé indépendamment les clés, et le chercheur a fourni des attestations signées avec elles dans le [dossier d’incident](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449). Cela confirme la possession du secret correspondant, bien au-delà d’une simple anomalie statistique.

## Comment on pouvait découvrir l’anomalie

Une méthode défensive consiste à inventorier les certificats d’autorités publiques, extraire leurs clés EC et comparer `Q` aux multiples de `G` pour une plage de très petits scalaires. On peut aussi chercher des collisions, des signatures invalides, des certificats dont la clé ne correspond pas au signataire réel, puis remonter à la cérémonie de génération. Le chercheur décrit avoir lancé un contrôle sur un corpus issu de CCADB le 17 octobre ; il a repéré les clés faibles en moins d’une demi-heure et notifié les programmes de confiance le soir même. Cette chronologie provient de son [compte rendu dans Bugzilla](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449).

Une alerte existait dans le cycle d’exploitation : en 2025, des listes de révocation, ou CRL, de ces mêmes intermédiaires avaient été signées par des clés ne correspondant pas à leurs certificats. eMudhra explique désormais qu’une première série de clés fortes avait été créée, puis qu’une opération de *wrap/unwrap* avait généré une seconde série faible. Les certificats avaient été émis sur cette seconde série, tandis que certaines CRL utilisaient d’abord les premières clés. La correction des CRL avait traité le symptôme sans remonter à la coexistence des deux séries. C’est le point soulevé dans le [suivi Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449). Le rapport de cause racine complet restait attendu au 4 novembre ; eMudhra a annoncé une revue indépendante par KPMG.

## Ce qu’un attaquant aurait pu faire

Une autorité intermédiaire TLS valide peut signer un certificat pour un domaine. Avec l’un des six secrets TLS, un attaquant pouvait donc produire un faux certificat et le présenter à un client qui faisait encore confiance à la chaîne. Il lui fallait aussi diriger la connexion vers son serveur, par exemple en contrôlant un réseau ou une route. **La connaissance du secret ne redirige pas à elle seule le trafic et ne déchiffre pas rétroactivement une session TLS moderne enregistrée.** Le risque principal pour ces six autorités est l’usurpation future de serveurs et l’interception active des échanges. Les deux clés de signature de code exposent un autre usage de la confiance, distinct de TLS.

La révocation des huit intermédiaires limite ce chemin quand elle est effectivement reçue et appliquée. Or tous les clients TLS ne récupèrent pas les révocations avec la même fiabilité. C’est pourquoi Mozilla a utilisé OneCRL immédiatement, livré une mise à jour Firefox pour certaines configurations et retiré la racine de NSS. [eMudhra](https://emudhra.com/en/post/certificate-security-incident) affirme que les huit intermédiaires n’avaient émis aucun certificat client final avant la divulgation et qu’une seule était utilisée en production. Ces affirmations réduisent l’impact opérationnel connu ; elles ne rendaient pas les clés fortes et n’empêchaient pas un tiers de signer ses propres certificats avec elles.

La défiance de la racine a également touché des certificats légitimes émis par **d’autres** intermédiaires de la même hiérarchie. eMudhra chiffre à environ 30 800 les certificats à migrer pour un groupe de clients américain. Il faut donc distinguer deux ensembles : les huit clés cassées, puis les services légitimes affectés par le retrait plus large de la racine. ([État de la migration](https://emudhra.com/en/post/certificate-security-incident))

## La leçon technique

Un HSM peut exécuter correctement une opération avec un secret qui lui a été fourni ou sélectionné par erreur. L’étiquette « généré dans un HSM certifié » ne remplace pas une vérification indépendante du résultat public. Pour une autorité de certification, le contrôle doit relier chaque clé, chaque CSR, chaque certificat et chaque CRL au même identifiant de cérémonie, puis détecter automatiquement les scalaires triviaux et toute discordance de clé. La revue de code du processus d’export, les tests de *wrap/unwrap* et la capacité de révocation à grande échelle font partie de cette preuve.

À retenir : l’incident n’est pas une cassure de P-384. C’est une défaillance de génération et de suivi des clés, visible depuis des données publiques et restée présente malgré des contrôles de procédure.

Notre [lecteur de certificats X.509](/outils/certificate/) aide à examiner les champs d’un certificat public dans le navigateur ; il ne remplace ni la validation de la chaîne ni la recherche de clés faibles. Le cas [Binance et EIP-7702](/research/binance-signature-portefeuille-eip7702-2026/) illustre un autre échec de confiance : une signature peut être valide alors que l’opération métier n’est pas autorisée.

**Sources principales :** [Mozilla Security Blog](https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/), [dossier technique Mozilla](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449), [mises à jour eMudhra](https://emudhra.com/en/post/certificate-security-incident).