L'autorité de certification indienne eMudhra Limited annonce qu'elle quitte le marché mondial des certificats SSL/TLS. Cette décision fait suite à la découverte de huit certificats TLS intermédiaires dont les clés privées étaient si faibles qu'elles pouvaient être récupérées presque instantanément. Quiconque récupérait l'une de ces clés pouvait émettre des certificats TLS pour n'importe quel site web ou serveur de messagerie. L'une d'elles ne valait que 4.
La société a annoncé sa décision dans un message publié jeudi, deux jours après la divulgation du problème par les chercheurs, selon le compte rendu d'Ars Technica. Le président V. Srinivasan a invoqué la hausse des coûts et l'accroissement des exigences de conformité. Il a aussi indiqué que le SSL/TLS ne représente qu'environ 1 % du chiffre d'affaires de l'entreprise, et que les fournisseurs de certificats TLS gratuits avaient réduit la rentabilité de cette activité par rapport aux autres produits et services d'eMudhra. Dans ce message, eMudhra affirme que l'attention des réseaux sociaux a placé l'incident sous un examen disproportionné par rapport au rôle que le TLS joue dans ses activités, et que son conseil d'administration a conclu que le retrait était le bon choix pour l'entreprise et ses actionnaires.
Des tailles de clés bien inférieures à la robustesse attendue
Les chercheurs ont constaté que les huit certificats avaient été émis avec des clés privées de 3 à 8 bits. Ces clés étaient censées être des clés elliptiques NIST P-384, qui devraient offrir environ 384 bits d'entropie. Les valeurs des clés défectueuses étaient 4, 56, 66, 115, 155, 156, 230 et 237. La plus robuste d'entre elles n'offrait au plus que 256 possibilités, alors qu'une clé correcte devrait en offrir environ 2^384, un nombre de 116 chiffres.
Selon le récit des chercheurs, la faille était facile à exploiter. La récupération d'une clé ne prenait que des millisecondes. Une fois une clé récupérée, un attaquant pouvait s'en servir pour créer des certificats que les principaux navigateurs accepteraient, et ces certificats pouvaient à leur tour être acceptés par un nombre important et inconnu de serveurs de messagerie, d'appareils IoT, de conteneurs Docker, de vieilles machines Linux et d'outils en ligne de commande non maintenus, qui embarquent leurs propres copies des certificats racines.
Les éditeurs de navigateurs ont bloqué les certificats émis sous les intermédiaires concernés dans un délai d'un ou deux jours après la découverte. Ars Technica a noté que d'autres appareils qui dépendent des mêmes certificats pourraient avoir besoin de beaucoup plus de temps pour faire de même, et que certains appareils embarqués ne pourront peut-être jamais les bloquer. Ars estimait également qu'eMudhra était probablement confrontée à la possibilité que le CA/Browser Forum, le groupe professionnel qui fixe les règles du programme de certificats TLS, lui retire son autorité. Il s'agit là de l'appréciation d'Ars, et non d'une décision annoncée.
L'explication d'eMudhra
Mercredi, eMudhra a publié une brève explication. Elle indique que les certificats ont été créés sous sa racine ECC lors d'une cérémonie de génération de clés (KGC) tenue le 30 avril 2025, à l'aide de modules de sécurité matériels (HSM) certifiés FIPS 140-2 niveau 3. Selon la société, une faille de la KGC a amené une étape wrap/unwrap à produire un second jeu de clés faibles à côté des clés initiales solides, et ce sont ces clés faibles qui ont été publiées dans les magasins de certificats racines des navigateurs. eMudhra affirme qu'elle travaille toujours à établir la cause première.
Les HSM sont des appareils dédiés au stockage des clés de chiffrement et d'autres données sensibles, et ils sont normalement isolés du reste du réseau. Le wrapping et l'unwrapping sont le procédé qui permet de déplacer une clé d'un HSM à un autre : l'appareil émetteur chiffre la clé avec une clé d'enveloppe distincte, et l'appareil récepteur la déchiffre à son arrivée.
Dans un fil de discussion Mozilla Bugzilla, eMudhra a donné davantage de détails. Elle indique que le script de KGC utilisé ce jour-là contenait une faille. Les clés ECC d'origine ont été générées sur l'appareil comme prévu. Une modification approuvée de la procédure habituelle, destinée à tester un wrap/unwrap pour des clés destinées à l'export, a ensuite été introduite. Un défaut dans le code a alors conduit à la génération, sur l'appareil, d'une seconde paire de clés, plus faible. Les étiquettes des clés étant similaires, c'est par erreur que la paire la plus faible a été utilisée pour créer la demande de signature de certificat, que la racine a ensuite signée. eMudhra affirme que la demande créée à partir des clés faibles a également été envoyée à Sectigo pour une certification croisée, et que la société avait vérifié les fichiers transmis.
eMudhra indique également que ses listes de révocation de certificats (CRL) ont d'abord été signées avec les clés privées d'origine, générées correctement. Ces signatures se sont révélées incorrectes, si bien que les CRL ont été re-signées avec les clés défectueuses. Ars Technica a demandé pourquoi l'entreprise n'avait pas plus tôt cherché à comprendre la cause de cet échec de signature. La société répond que des erreurs humaines commises à plusieurs étapes ont entraîné de graves faiblesses dans le processus d'intégrité du cycle de vie des clés pour cette cérémonie. Elle indique qu'elle examine les failles de code, les lacunes de processus et les contrôles maker/checker, et qu'elle revérifiera, au cours de la semaine suivante, toutes les cérémonies de génération de clés qu'elle avait effectuées.
