Contexte et découverte

Le 17 octobre, un chercheur a signalé à Apple, Google, Microsoft, Mozilla et à eMudhra la compromission de huit certificats intermédiaires de l’autorité de certification eMudhra. Les navigateurs ont réagi rapidement : Chrome a diffusé une mise à jour CRLSet le soir même, Mozilla a ajouté les certificats à OneCRL puis a retiré la racine eMudhra de son magasin NSS le 20 octobre, et Chrome a prévu la suppression de la racine dans le Chrome Root Store v43. Les huit intermédiaires, créés en avril 2025, comprennent six CAs TLS (DV, OV, EV, deux générations) et deux CAs de signature de code, tous cross‑signés par le root Sectigo AAA en mai 2025.

Mécanisme de faiblesse des clés

Les certificats utilisent la courbe elliptique P‑384. Un privé valide doit être un nombre aléatoire de 384 bits, offrant 2⁴⁸⁴ ≈ 10¹¹⁵ combinaisons. Les clés compromises sont cependant de la forme :

d = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004

et les sept autres sont similaires, ne contenant qu’un seul octet non nul (valeur entre 1 et 255). La recherche consiste donc à calculer 1 × G, 2 × G, … jusqu’à 255 × G et à comparer le point résultant au point public présent dans le certificat. Cette opération se réalise en moins d’une seconde sur du matériel grand public, car le nombre d’essais est limité à 255, contre 10¹¹⁵ pour une clé correctement générée.

Conséquences pour l’écosystème TLS

Le problème ne se limite pas à la perte d’une clé ; la clé était effectivement publique depuis la création du certificat. Sur une période de 17 mois, tout acteur disposant du certificat pouvait reconstruire la clé privée et émettre des certificats frauduleux. Les navigateurs modernes ne sont pas affectés, car ils bloquent les intermédiaires et exigent la transparence des certificats (CT). En revanche, la majorité des clients TLS hors navigateur (curl, Python, Node.js, Go, Java, gestionnaires de paquets, CI/CD, appareils IoT) utilisent des bundles de confiance locaux, ne vérifient pas la révocation et ignorent CT. Ainsi, un attaquant peut, en quelques millisecondes, faire accepter un certificat falsifié à un script d’installation, à un pipeline de déploiement ou à un dispositif embarqué, compromettant potentiellement des systèmes critiques.

Limitations et mesures d’atténuation

Le rapport ne fournit aucun indicateur quant à une exploitation réelle pendant la fenêtre de 17 mois ; l’absence de traces dans les logs CT rend la détection difficile. La mitigation immédiate consiste à retirer les intermédiaires du magasin de confiance et à mettre à jour les bundles CA sur tous les systèmes non‑navigateurs. Les solutions de révocation en temps réel (CRLite, OCSP stapling) restent limitées aux navigateurs de bureau. À plus long terme, les autorités de certification doivent renforcer les contrôles de génération de clés, notamment en imposant des tests de distribution d’entropie et en refusant les clés contenant plus de 80 % de zéros.