Les clés de l'AC eMudhra compromises en raison d'une génération de clés privées extrêmement faible

Le 17 octobre 2026, un chercheur en sécurité a signalé aux grandes entreprises technologiques que les clés privées de huit certificats intermédiaires d'eMudhra avaient été compromises. La vulnérabilité provenait d'une faiblesse extrême dans la génération des clés, où les clés privées étaient essentiellement des entiers sur un seul octet. Le 20 octobre, Mozilla et Google avaient publiquement annoncé la révocation de ces certificats et supprimé la confiance accordée aux autorités racines associées.

Ce qui s'est passé

L'incident concerne huit certificats intermédiaires émis par eMudhra, créés en avril 2025. Ceux-ci comprenaient six certificats d'émission TLS pour la validation de domaine (Domain Validation), la validation d'organisation (Organization Validation) et la validation étendue (Extended Validation), ainsi que deux certificats de signature de code. Les huit certificats intermédiaires ont également été contresignés par la racine AAA Certificate Services de Sectigo en mai 2025. À la réception du rapport, Chrome a déployé une mise à jour CRLSet pour bloquer les certificats intermédiaires le même jour, tandis que Mozilla les a bloqués dans Firefox via OneCRL peu après.

Mardi 20 octobre, Mozilla a publié une annonce publique et a expédié une mise à jour NSS qui a entièrement supprimé la racine d'eMudhra. Google a confirmé que la racine d'eMudhra serait retirée du Chrome Root Store dans la version 43. Le problème central n'était pas un vol de clés au sens traditionnel, mais une défaillance dans le processus de génération qui rendait les clés privées triviales à dériver à partir des certificats publics.

Il a été constaté que les clés privées de ces certificats étaient des nombres incroyablement petits, tels que 4, 56 et 115. En cryptographie à courbe elliptique, spécifiquement sur la courbe P-384 utilisée ici, la clé privée est un grand nombre aléatoire. La sécurité du système repose sur le fait que ce nombre soit suffisamment grand pour rendre le brute-force impossible. Cependant, les clés d'eMudhra consistaient principalement en zéros suivis d'un seul octet non nul. Cela réduisait l'espace de recherche à seulement 256 possibilités, permettant à quiconque ayant accès au certificat public de récupérer la clé privée en quelques millisecondes sur du matériel standard.

Détails clés

• Huit certificats intermédiaires ont été compromis, dont six pour TLS et deux pour la signature de code.
• Les clés privées étaient des valeurs sur un seul octet, telles que 4, 56 et 115, au lieu des nombres aléatoires de 384 bits requis.
• La récupération des clés privées à partir des certificats publics a pris moins d'une seconde sur du matériel courant.
• Les certificats affectés ont été créés en avril 2025 et contresignés par Sectigo en mai 2025.
• Les principaux navigateurs comme Chrome et Firefox ont révoqué leur confiance, mais de nombreux clients non-navigateurs restent vulnérables.
• La fenêtre d'exposition s'étend d'avril 2025 jusqu'à la révocation en octobre 2026, sans moyen de déterminer si les clés ont été exploitées.

Contexte

Pour comprendre la gravité de la situation, il est utile de savoir comment fonctionne la cryptographie à courbe elliptique. Une clé privée est un nombre secret, souvent noté d. La clé publique, qui est partagée ouvertement dans les certificats, est dérivée en multipliant ce nombre secret par un point fixe sur la courbe. Bien que calculer la clé publique à partir de la clé privée soit facile, inverser le processus pour trouver la clé privée à partir de la clé publique est computationnellement infaisable si la clé privée est grande et aléatoire.

Pour les courbes P-384, la clé privée doit être un nombre de 384 bits, offrant environ 10¹¹⁵ combinaisons possibles. Cet vaste espace de recherche assure la sécurité. Cependant, si la clé privée est petite, comme un seul octet, il n'y a que 256 valeurs possibles. Un attaquant peut simplement essayer chaque valeur jusqu'à trouver celle qui correspond à la clé publique. C'est ce qui s'est produit avec les clés d'eMudhra, rendant la protection cryptographique inutile.

Pourquoi c'est important

Bien que les navigateurs modernes comme Chrome, Firefox et Safari soient protégés car ils appliquent la transparence des certificats (Certificate Transparency) et mettent rapidement à jour leurs listes de blocage, l'écosystème plus large est en risque. De nombreuses applications non-navigateurs, y compris les outils en ligne de commande comme curl, les environnements d'exécution de langages de programmation comme Python et Node.js, et les gestionnaires de paquets, ne vérifient pas par défaut les journaux de transparence des certificats ou les listes de révocation. Ils comptent sur des magasins de confiance locaux qui peuvent ne pas être mis à jour immédiatement.

Cela crée un risque significatif pour les communications serveur à serveur, les pipelines CI/CD et les appareils IoT. Par exemple, un script téléchargeant des mises à jour via HTTPS en utilisant un bundle de certificats obsolète pourrait accepter un certificat falsifié signé par les clés compromises d'eMudhra. Cela permettrait à un attaquant d'intercepter le trafic, d'injecter du code malveillant ou de voler des données sensibles. Les appareils avec firmware figé, tels que les routeurs et les électroménagers connectés, pourraient continuer à faire confiance à ces certificats invalides jusqu'à ce que leur matériel soit remplacé ou mis à jour manuellement, potentiellement dans plusieurs années.

Que pouvez-vous faire

• Mettez à jour les bundles de certificats AC sur tous les serveurs, postes de travail et images de conteneurs immédiatement.
• Vérifiez les mises à jour des environnements d'exécution de langages comme Python, Node.js et Go, qui incluent souvent leurs propres magasins de certificats.
• Examinez les pipelines CI/CD pour vous assurer qu'ils utilisent des images de base à jour et vérifient strictement la validité des certificats.
• Identifiez les appareils IoT et embarqués qui ne peuvent pas être facilement mis à jour et évaluez le risque qu'ils fassent confiance à des AC compromises.
• Activez la vérification stricte de la révocation des certificats lorsque cela est possible, bien que beaucoup de clients ne le prennent pas en charge par défaut.
• Surveillez toute activité inhabituelle dans les systèmes qui dépendent des connexions TLS vers des services externes.