eMudhra révoque huit autres autorités de certification après qu'une erreur de script a exposé des clés RSA

L'autorité de certification eMudhra a révoqué huit autorités de certification (AC) intermédiaires supplémentaires après avoir déterminé qu'un script Python personnalisé utilisé lors d'une cérémonie de génération de clés avait exposé leurs clés privées RSA. La société avait initialement déclaré que ces AC n'étaient pas affectées par la compromission d'octobre, mais elle est revenue sur sa position début novembre à la suite d'une enquête approfondie et de discussions avec les programmes racine des navigateurs.

Ce qui s'est passé

L'incident remonte à une cérémonie de génération de clés le 30 avril 2025, où eMudhra a généré 16 clés d'AC sur des modules de sécurité matériels (HSM) Utimaco. Ces clés étaient destinées à être transférées vers des HSM Crypto4A sur les sites américains et européens de l'entreprise. Comme le transfert de clés entre HSM de fournisseurs différents est restreint, l'équipe des opérations PKI a écrit un script Python pour envelopper et déballer les clés afin de les transporter. Lors d'une simulation de ce transfert, le script a lu les clés privées hors du HSM dans la mémoire de l'ordinateur de la cérémonie pour les reconstruire.

Pour huit clés ECDSA, une ligne unique du script a tronqué la valeur privée à son octet de tête, créant des clés gravement faibles qui ont ensuite été certifiées. Alors que ces huit-là ont été révoquées en octobre, l'entreprise croyait initialement que huit clés RSA traitées par le même script étaient sûres car le script ne les tronquait pas. Cependant, l'enquête a révélé que les composants privés de ces clés RSA, tels que l'exposant privé et les nombres premiers, restaient dans la mémoire du processus Python sur l'ordinateur de la cérémonie.

Cette exposition signifiait qu'eMudhra ne pouvait pas prouver la conformité avec sa propre Déclaration de pratiques de certification (CPS) concernant la gestion des clés. L'entreprise a déclaré qu'elle "ne peut pas démontrer positivement que ce matériel de clé était conforme" aux règles régissant les mouvements des clés entrant et sortant des HSM. Par conséquent, les huit AC RSA ont été révoquées à la fin de la semaine dernière. Six concernaient des certificats de sites web TLS et deux la signature de code, couvrant 195 certificats émis, dont 29 pour les domaines propres d'eMudhra.

Détails clés

• Huit AC intermédiaires ont été révoquées en raison de l'exposition de clés RSA en mémoire, et non de la troncature des clés.
• Le défaut provenait d'un script Python utilisé lors d'une cérémonie de génération de clés le 30 avril 2025.
• 195 certificats ont été affectés, y compris ceux pour des universités, un comté et eMudhra elle-même.
• L'entreprise a initialement affirmé que ces AC n'étaient pas affectées dans une mise à jour du 19 octobre adressée à Mozilla.
• La raison de la révocation était indiquée comme cessationOfOperation plutôt que keyCompromise.
• Microsoft supprimera les racines restantes d'eMudhra de Windows et Edge à partir du 16 novembre.

Contexte

Les modules de sécurité matériels (HSM) sont des dispositifs physiques conçus pour générer et stocker des clés cryptographiques de manière sécurisée. Un principe fondamental de l'utilisation des HSM est que les clés privées ne doivent jamais quitter le dispositif en clair. Lorsque les organisations doivent migrer des clés entre différents fournisseurs de HSM, elles utilisent souvent des processus d'enveloppement qui chiffrent la clé pour le transport. Dans ce cas, le script personnalisé d'eMudhra a contourné les protections standard en lisant la clé dans la mémoire système pour reconstruction, créant une fenêtre où le matériel secret était vulnérable à l'extraction ou à la journalisation.

Les autorités de certification opèrent sous des audits stricts comme WebTrust et doivent suivre une Déclaration de pratiques de certification (CPS). Si une AC ne peut pas prouver qu'une clé privée a été gérée selon ces règles, les navigateurs et les systèmes d'exploitation peuvent révoquer la confiance envers cette AC. Cela garantit que si une clé est potentiellement compromise, même sans preuve d'utilisation malveillante, le risque est atténué en invalidant la chaîne de confiance.

Pourquoi c'est important

Pour les équipes exécutant des logiciels auto-hébergés, cet incident met en lumière la fragilité de la confiance dans l'écosystème public des certificats. Si vous comptez sur des certificats de la marque emSign d'eMudhra, vos services pourraient bientôt rencontrer des erreurs de confiance dans les navigateurs et les systèmes d'exploitation. Microsoft supprime les racines restantes d'eMudhra le 16 novembre, et Apple mettra fin à la confiance dans tous les certificats G1 d'ici le 30 novembre. Cela signifie que les outils internes, les API ou les applications orientées client utilisant ces certificats cesseront de fonctionner sauf s'ils sont migrés.

Au-delà des pannes immédiates, cette histoire sert de récit édifiant sur la création de scripts personnalisés dans des infrastructures de sécurité critiques. Même de grandes organisations auditées peuvent introduire de graves vulnérabilités via de simples erreurs de codage. Pour les responsables DevOps et IT, cela souligne l'importance de vérifier la provenance et la manipulation des matériaux cryptographiques, surtout lors de l'utilisation d'AC tierces qui pourraient quitter le marché ou faire face à des problèmes de stabilité.

Ce que vous pouvez faire

• Vérifiez si vos services utilisent des certificats émis par les hiérarchies G1 ou G2C d'eMudhra via les journaux de transparence des certificats.
• Remplacez immédiatement tout certificat affecté par ceux provenant d'un fournisseur stable et fiable.
• Mettez à jour les systèmes macOS vers les versions 27.2.1, 26.7.3 ou 15.8.3 pour garantir que les outils intégrés comme curl rejettent les racines compromises.
• Surveillez les journaux de votre application pour détecter les échecs de poignée de main TLS pouvant indiquer des problèmes de confiance avec des certificats plus anciens.
• Passez en revue vos propres procédures de gestion des clés pour vous assurer qu'aucun script personnalisé n'expose les clés privées en mémoire.
• Vérifiez que votre pile de surveillance vous alerte en cas d'expiration des certificats ou de changement de statut de révocation.