Une autorité de certification a mis en œuvre la chute d'une blague XKCD
Une révélation frappante du chercheur en sécurité "Wayne" le 17 octobre a mis en lumière une défaillance profonde dans l'infrastructure à clé publique : huit certificats intermédiaires eMudhra, y compris des autorités de TLS et de signature de code, ont été compromis. Les clés privées sous-jacentes de ces certificats, auxquelles les principaux navigateurs et systèmes d'exploitation ont fait confiance pendant 17 mois, étaient des entiers trivialement petits—l'un étant littéralement le chiffre 4.
Ces clés reposaient sur la courbe elliptique P-384, qui nécessite normalement qu'un private scalar (d) soit un grand nombre imprévisible de 384 bits, offrant environ $10^{115}$ possibilités. Au lieu de cela, les clés compromises d'eMudhra présentaient 47 octets nuls en tête, le dernier octet contenant une valeur suffisamment petite pour être bruteforcée sur au plus 255 candidats.
Cette faiblesse catastrophique a permis une récupération immédiate des clés privées. Les valeurs identifiées étaient :
- 4
- 56
- 66
- 115
- 155
- 156
- 230
- 237
Malgré leur taille minuscule, ces entiers produisent toujours des points de clé publique mathématiquement valides sur la courbe. Cela signifie que les certificats ont passé les contrôles structurels standard, masquant la fragilité cryptographique sous-jacente. Google Chrome et Firefox ont rapidement bloqué ces certificats, suivis par Apple et Microsoft.
L'erreur avait une trace écrite—et une alarme manquée
La cause signalée remonte à une April 2025 key ceremony où eMudhra a modifié un script pour tester les exportations de clés. Ce script a généré par inadvertance des paires de clés supplémentaires faibles sur le Hardware Security Module (HSM). Les opérateurs, induits en erreur par des étiquettes similaires, ont ensuite utilisé ces clés compromises pour les demandes de certificat, plutôt que celles prévues, cryptographiquement robustes.
Crucialement, un avertissement est apparu en juin 2025. Sectigo, le signataire croisé, a signalé des signatures invalides sur les listes de révocation de certificats (CRL) d'eMudhra. Ce décalage s'est produit parce qu'eMudhra a tenté de signer les CRL avec ses clés originales et fortes, qui ne correspondaient pas aux clés faibles intégrées dans les certificats émis.
Au lieu d'enquêter sur la divergence sous-jacente, eMudhra a re-signé les listes de révocation en utilisant les clés faibles. Cette solution de contournement a effectivement masqué le symptôme, permettant à la faille de sécurité fondamentale de persister pendant 16 mois supplémentaires.
Sur le plan opérationnel, cet incident souligne deux leçons critiques. Les cérémonies de clés exigent des independent identity and strength checks sur tout matériel cryptographique généré. De plus, toute discordance de signature, en particulier dans le contexte d'une infrastructure à clé publique, doit déclencher une réponse immédiate à l'incident plutôt qu'une solution de contournement superficielle.
Les navigateurs avaient des garde-fous. Les systèmes de build n'en ont souvent pas
Sectigo a signé de manière croisée les intermédiaires d'eMudhra, leur donnant une large portée dans les magasins de confiance des plateformes. Le chercheur Wayne a démontré son contrôle en signant un message de preuve, "We have a problem here," avec chacune des huit clés compromises. Cela a confirmé la compromission des clés et mis en évidence le potentiel généralisé d'utilisation abusive.
Les navigateurs comme Google Chrome et Mozilla Firefox ont rapidement révoqué les certificats, souvent en quelques heures. Ils appliquent des journaux de Certificate Transparency (CT), enregistrant publiquement tous les certificats TLS de confiance. Les navigateurs rejettent généralement les certificats absents de ces journaux, une protection critique qui a empêché l'exploitation directe par les navigateurs.
Cependant, les clients non-navigateurs manquent souvent de ces défenses robustes. Des outils tels que curl, Python, Node, Go et Git s'appuient fréquemment sur des bundles CA locaux, ignorant totalement les vérifications CT ou de révocation. Cela les laisse vulnérables aux attaques de type machine-in-the-middle (MITM).
Les enjeux pratiques sont considérables. Un attaquant utilisant l'une de ces clés falsifiées pourrait cibler :
- Les appels API
- Les scripts d'installation
- Les runners CI
- Les identifiants cloud
Les deux clés de signature de code compromises ont également soulevé des inquiétudes concernant des logiciels falsifiés, pouvant potentiellement distribuer des mises à jour ou des applications malveillantes. Pour plus de détails techniques, consultez le Mozilla Bugzilla: eMudhra Private Key Compromise of Intermediate Certificates.
Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.
un e-mail par jour · désinscription en deux clics · aucun traqueur tiers
Corrigez le trust store, puis testez l'ensemble du pipeline
Les éditeurs de navigateurs et les opérateurs de plateformes ont rapidement pris des mesures pour révoquer la confiance accordée aux certificats affectés. Apple, Google Chrome, Microsoft et Mozilla ont bloqué les intermédiaires compromis en quelques jours, tandis que Sectigo a mis fin à son accord de signature croisée avec eMudhra. Go a publié une version d'urgence ciblée, la 1.27.3, bloquant directement ces huit intermédiaires au sein de sa bibliothèque standard.
La couverture des mises à jour des appareils et des logiciels peut encore varier, en particulier pour les systèmes embarqués. Pour atténuer les risques, mettez à jour immédiatement votre système d'exploitation et vos packages CA. Mettez à niveau les environnements d'exécution de langage comme Go vers la version 1.27.3 et le package certifi de Python vers la version 2026.10.19. Reconstruisez les images de conteneurs et les runners CI/CD pour vous assurer que toutes les dépendances sont à jour.
Testez vos clients par rapport au point de terminaison de test d'incident publié, DV G3B eMudhra.we-have-a-problem.com. Si votre client rejette la chaîne de certificats avec une erreur, il est sécurisé. Cette étape de validation est cruciale pour tous les systèmes qui reposent sur la confiance des certificats.
L'incident souligne une leçon critique en matière de PKI : les vérifications de format ne peuvent pas prouver le caractère aléatoire ou l'intention. Automatisez les vérifications de robustesse des clés dans le cadre des cérémonies de clés. Validez que les clés publiques des certificats correspondent précisément aux clés HSM prévues, et pas seulement à celles qui sont structurellement valides. Surveillez les journaux de Certificate Transparency (CT) et traitez les signatures de révocation invalides — comme l'avertissement de Sectigo de juin 2025 — comme des urgences de sécurité graves.
Foire aux questions
Quel était le problème avec les clés privées d'eMudhra ?
Huit certificats CA intermédiaires utilisaient des valeurs de clé privée minuscules, dont 4, au lieu de valeurs imprévisibles de 384 bits. Les clés correspondantes pouvaient être récupérées en testant seulement quelques possibilités.
Les utilisateurs ordinaires de navigateurs étaient-ils en danger ?
Les exigences de Certificate Transparency des navigateurs modernes ont aidé à bloquer les certificats falsifiés non enregistrés, bien que les protections et les mises à jour aient varié. Les logiciels non-navigateurs manquent souvent de vérifications équivalentes.
Pourquoi les pipelines CI étaient-ils une préoccupation ?
Les outils et services dans les pipelines de build peuvent faire confiance aux bundles CA locaux sans vérifier la Certificate Transparency ou la révocation des certificats, acceptant potentiellement un certificat de serveur falsifié.
Que doivent faire les développeurs ?
Mettez à jour les trust stores du système d'exploitation et des environnements d'exécution de langage, reconstruisez les conteneurs affectés et testez le comportement de validation des certificats des clients non-navigateurs et des runners CI.