Contexte de la compromission
Le mardi 15 octobre 2026, huit certificats intermédiaires émis par l’autorité de certification indienne eMudhra Limited ont été identifiés comme contenant des clés privées dont la force cryptographique était insuffisante pour résister à une attaque de factorisation. Les clés compromises permettent de signer de nouveaux certificats qui seraient acceptés par les navigateurs et les applications comme légitimes, ouvrant la possibilité de créer des identités numériques pour n’importe quel domaine Internet.
Mécanismes de la faiblesse des clés
Les certificats concernés utilisent des paramètres RSA dont la taille ou l’entropie des nombres premiers était nettement inférieure aux exigences habituelles (exemple typique : 1024 bits ou génération avec un générateur de nombres aléatoires défectueux). Une telle faiblesse rend la clé vulnérable à une factorisation en temps raisonnable, ce qui autorise un attaquant à reconstituer la clé privée à partir de la clé publique disponible dans le certificat. Une fois la clé privée récupérée, l’attaquant peut signer des certificats intermédiaires ou finaux, insérant ainsi des identités falsifiées dans la chaîne de confiance.
Réaction des navigateurs et des écosystèmes
En moins de deux heures après la divulgation, les principaux fournisseurs de navigateurs (Chrome, Firefox, Safari, Edge) ont retiré les huit certificats intermédiaires de leurs magasins de confiance. De même, plusieurs environnements d’exécution – notamment les runtimes Go, Python, Java, ainsi que les images Docker contenant leurs propres copies de certificats racines – ont été mis à jour pour bloquer ces intermédiaires. Aucun journal de transparence (Certificate Transparency) n’a encore enregistré d’utilisation malveillante des clés compromises, ce qui indique que l’exploitation n’est pas encore active ou que les acteurs malveillants attendent un moment opportun.
Implications pour l’infrastructure Internet
La mise à jour des systèmes dépendants de ces certificats pose un problème d’échelle. Les distributions Linux, qui intègrent souvent des copies locales de certificats racines, doivent publier des correctifs et les administrateurs doivent les appliquer sur des milliers de serveurs, y compris des machines embarquées et des dispositifs IoT qui reçoivent rarement des mises à jour. De plus, certains outils en ligne de commande et bibliothèques (par exemple, les clients CLI qui embarquent leurs propres certificats) restent vulnérables tant qu’ils ne sont pas recompilés ou reconfigurés. Le nettoyage requis dépasse celui de la faille Heartbleed, car il implique non seulement le retrait de certificats, mais aussi la rotation de toutes les clés dérivées et la revalidation des chaînes de confiance dans des environnements hétérogènes.
