Une courbe sur 384 bits dont le secret réel n’était que 4
Le samedi 17 octobre 2026, des chercheurs en sécurité ont alerté Apple, Google, Microsoft, Mozilla et l’autorité de certification indienne eMudhra d’une découverte invraisemblable : les clés privées de huit certificats d’autorités intermédiaires (CA) pouvaient être cassées sur un simple ordinateur portable en moins d’une seconde.
Ces certificats s’appuyaient sur la courbe elliptique standard NIST P-384. Selon les spécifications cryptographiques, une clé privée doit être un nombre aléatoire de 384 bits choisi parmi environ 10^115 valeurs possibles. Qu’étaient ces clés en réalité ? Quarante-sept octets consécutifs de zéros, suivis d’un seul octet utile. Les huit clés secrètes valaient respectivement 4, 56, 115, 155, 156, 230, 66 et 237. L’une d’entre elles valait tout simplement 4.
Briser une telle clé n’exige au maximum que 255 opérations d’addition de points sur la courbe elliptique, ce qu’un ordinateur personnel réalise en quelques millisecondes. En analysant les 16 certificats joints à la notification de Mozilla, les chercheurs ont pu reconstituer l’intégralité des huit clés privées. En pratique, ces clés étaient de fait publiques depuis l’émission même des certificats en avril 2025.
Illustration : Un cadenas forcé. Source : Ars Technica
Des contrôles de conformité tous validés : où se situait la faille ?
Dans l’écosystème HTTPS, la chaîne de confiance se déploie en cascade depuis les certificats racines jusqu’aux certificats feuilles, chaque échelon étant soumis à des contrôles de format rigoureux : validation de la courbe, encodage ASN.1 conforme et structures de signature irréprochables. Les huit certificats d’eMudhra — six autorités émettrices TLS (deux générations pour les validations DV, OV et EV) et deux autorités de signature de code — avaient été générés en avril 2025 avant de recevoir en mai la contre-signature de la racine AAA Certificate Services de Sectigo. Chaque vérification formelle avait été couronnée de succès.
Pourtant, aucun test automatisé n’impose de vérifier si la clé privée est véritablement aléatoire. L’étape de génération de clé relève de la seule responsabilité interne de l’autorité émettrice ; les intervenants externes n’ont accès qu’à la clé publique correspondante. La puissance mathématique de P-384 et ses 10^115 états possibles ne protègent les échanges que si la clé est tirée de façon rigoureusement équiprobable. La défaillance critique d’eMudhra s’est nichée dans le seul interstice où aucun mécanisme automatisé externe ne pouvait intervenir.
Dans les échanges communautaires, plusieurs hypothèses techniques ont circulé : un script d’automatisation dont les paramètres positionnels auraient été inversés, ou une ligne de code extrayant par erreur key[0] d’une clé chiffrée. D’autres spécialistes ont rappelé une exigence fondamentale : les clés de signature doivent être générées directement à l’intérieur d’un module de sécurité matériel (HSM). Le simple fait d’avoir pu générer des clés hors HSM et de produire des valeurs aussi aberrantes démontre que les procédures opérationnelles étaient défaillantes dès l’origine.
Réaction éclair des navigateurs : quatre jours de crise
Dès la soirée du 17 octobre, Google a poussé en urgence une mise à jour CRLSet pour révoquer ces huit certificats ; Mozilla lui a emboîté le pas quelques heures plus tard via OneCRL. Le 20 octobre, Mozilla a rendu l’incident public et a purement et simplement purgé le certificat racine d’eMudhra de la bibliothèque NSS ; Google a confirmé à son tour son éviction dans le magasin Chrome Root Store v43.
Pourquoi une telle célérité ? Le chercheur Ian Carroll l’a résumé sans détour : « Il s’agit fondamentalement de clés sur 1 octet que n’importe qui peut factoriser ; l’incident était tout simplement incontrôlable. » En l’absence d’une date d’intrusion identifiable, n’importe quel acteur malveillant aurait pu forger des certificats frauduleux à n’importe quel moment au cours des 17 mois écoulés.
L’équipe d’ingénierie de Google Chrome a précisé un point technique notable : ces autorités intermédiaires n’avaient jamais inscrit de certificat TLS dans les journaux de Transparence des Certificats (CT, Certificate Transparency). Par conséquent, les certificats contrefaits n’auraient pas été reconnus par défaut par Chrome. Cependant, si le mécanisme CT permet de repérer les émissions non conformes, il n’empêche pas l’acte de signature lui-même — et d’innombrables outils logiciels en dehors des navigateurs ne vérifient jamais les journaux CT.
Schéma : Chaque échelon repose sur le contrôle du niveau supérieur, mais l’entropie de la clé de base n’est jamais auditée de l’extérieur. Source : Keytos
Pourquoi les scripts curl | sh arrivent en tête des vecteurs d’attaque
Les utilisateurs ordinaires de navigateurs web sont demeurés largement protégés grâce à l’association des listes de révocation d’urgence et de l’obligation CT. En réalité, la zone de vulnérabilité maximale se situe entièrement hors de l’univers des navigateurs.
Des clients TLS comme curl, Python, Node.js, Go, Java, git et de multiples gestionnaires de paquets système s’appuient par défaut sur les magasins statiques de certificats CA présents sur le disque. Par conception, la plupart ne vérifient ni les listes de révocation (OCSP/CRL), ni les journaux CT. Pour ces outils headless, les avis de révocation restent lettre morte : en consultant le magasin du système hôte, ces clients continuaient d’accorder leur confiance aux autorités intermédiaires d’eMudhra malgré leurs clés de 8 bits.
Le risque devient particulièrement critique dans deux contextes : premièrement, les scripts d’installation directe via curl | sh et les mécanismes d’auto-mise à jour logicielle, où un certificat falsifié permet l’exécution immédiate de code hostile avec les privilèges utilisateur ou root ; deuxièmement, les chaînes d’intégration et déploiement continus (CI/CD), dont les conteneurs de compilation manipulent couramment des identifiants cloud, des jetons de registres de paquets et des secrets de signature. Pour perpétrer une attaque de l’homme du milieu (MitM), un assaillant n’avait besoin que d’un ordinateur portable ordinaire et d’une fraction de seconde de calcul.
Les justifications d’eMudhra et la cessation d’activité
Le 22 octobre, eMudhra a officialisé son retrait définitif du marché mondial des certificats SSL/TLS. L’entreprise a avancé trois arguments : l’activité SSL/TLS internationale ne pesait qu’environ 1 % de son chiffre d’affaires global ; les coûts associés à la souveraineté des données et à la conformité réglementaire ne cessaient de grimper face à l’offre gratuite des géants du web ; et « l’amplification sur les réseaux sociaux et la sévérité du contrôle public se sont avérées disproportionnées par rapport à la place réelle de cette division au sein de notre groupe ». eMudhra a par ailleurs affirmé avoir révoqué les CA concernées en l’espace de 14 heures, n’avoir délivré aucun certificat d’entité finale et n’avoir constaté aucune intrusion au sein de son infrastructure.
La communauté technique n’a pas été convaincue par l’argument de la disproportion. Les interrogations se sont concentrées sur un point névralgique : comment aucun processus interne de contrôle n’a-t-il pu déceler pendant 17 mois l’absence totale d’entropie dans ces clés ? Le fait que des clés cryptographiques aient pu être générées en dehors d’un HSM matériel scellé prouve que l’ensemble de la chaîne de confiance organisationnelle était compromise dès le premier jour.
Le facteur humain sans filet de sécurité automatisé
Dans cette affaire, aucun algorithme cryptographique n’a failli. Les courbes étaient conformes, les encodages impeccables, les formats respectés et les contre-signatures délivrées par des sommités du secteur telles que Sectigo. Huit certificats ont passé avec succès 17 mois de vérifications automatisées, pour la simple raison qu’aucun outil logiciel ni aucun audit de conformité standard ne réalise ce contrôle élémentaire : vérifier si une clé censée offrir 384 bits d’aléa n’est pas, dans les faits, un entier codé sur 8 bits.
La chaîne de confiance HTTPS aboutit au navigateur de l’utilisateur, mais la robustesse intrinsèque des clés privées des autorités intermédiaires ne peut être déduite qu’en analysant les clés publiques a posteriori. Pour eMudhra, il aura fallu 17 mois et l’initiative individuelle de chercheurs extérieurs pour révéler la faille. En matière d’infrastructure à clé publique (PKI), la frontière de sécurité repose avant tout sur la discipline humaine, une rigueur qu’aucune simple commande curl ne pourra jamais certifier d’un simple clic. En fermant sa division SSL/TLS, eMudhra a clos le dossier, mais la prochaine fois que se posera la question « qui garde les gardiens », l’acteur mis en cause ne disposera pas nécessairement d’une branche accessoire représentant 1 % de ses revenus à sacrifier pour s’en sortir.
Références :
- Déclaration Mozilla Bugzilla et notes de publication NSS
- Annonce officielle Chrome Root Store v43
- Communiqué d’eMudhra sur l’abandon du marché SSL/TLS mondial
- Analyse et commentaires d’Ian Carroll
- Discussion sur Hacker News (item?id=50177916)
