eMudhra, otto chiavi CA prevedibili mettono a rischio la fiducia HTTPS

🛡️ Executive Summary

• Otto chiavi private associate a certificati intermedi eMudhra risultano recuperabili quasi istantaneamente perché generate con valori inferiori a 256.
• Sei certificati riguardano TLS e due il code signing; Mozilla, Google e Apple hanno avviato interventi di revoca e rimozione della fiducia.
• L’incidente coinvolge anche librerie, runtime e sistemi operativi: Firefox, Go e diversi trust store hanno distribuito correzioni urgenti.

Otto chiavi private appartenenti a certificati intermedi dell’autorità di certificazione eMudhra sono risultate crittograficamente prevedibili, permettendo di ricostruirle quasi istantaneamente attraverso un numero irrisorio di tentativi. La scoperta, segnalata il 17 ottobre 2026, ha provocato una risposta coordinata dei programmi di certificazione di Mozilla, Google, Apple e Microsoft, perché sei delle chiavi potevano essere utilizzate per firmare certificati TLS potenzialmente accettati dai client che ancora le consideravano attendibili. Il problema non riguarda una debolezza dell’algoritmo crittografico P-384, ma un errore nel processo di generazione e selezione delle chiavi che ha compromesso la fiducia in una parte dell’infrastruttura WebPKI. La revoca ha prodotto aggiornamenti urgenti anche per runtime, librerie e strumenti di sviluppo.

Otto chiavi P-384 generate con meno di 256 valori possibili

Il rapporto pubblico Mozilla sull’incidente eMudhra ricostruisce una sequenza iniziata il 17 ottobre, quando un ricercatore identificato come Wayne ha comunicato ai programmi di certificazione la possibilità di recuperare le chiavi private di otto certificati intermedi. La segnalazione includeva prove crittografiche del controllo delle chiavi, successivamente verificate da Google e Mozilla. Quest’ultima ha riprodotto autonomamente il risultato senza conoscere il metodo utilizzato dal ricercatore, accertando che tutte le chiavi interessate, generate il 30 aprile 2025, utilizzavano la curva ellittica P-384 ma contenevano valori interi inferiori a 256. Una chiave privata correttamente generata su questa curva dovrebbe essere scelta casualmente da uno spazio di dimensioni estremamente elevate; in questo caso, invece, bastava verificare poche centinaia di possibilità per ricostruire il segreto. Una delle chiavi individuate aveva addirittura valore numerico pari a 4, dimostrando quanto il problema fosse distante dalla complessità matematica normalmente associata alla crittografia a curve ellittiche. I certificati compromessi appartengono alle serie G3B e G3C e comprendono sei autorità intermedie TLS, distribuite tra Domain Validation, Organization Validation ed Extended Validation, oltre a due autorità destinate alla firma del codice. Il caso è radicalmente diverso dai precedenti incidenti nei quali gli attaccanti avevano ottenuto certificati HTTPS validi compromettendo registri di domini: qui era possibile ricostruire direttamente la chiave capace di firmare nuovi certificati.

Leggi anche: CylindricalCanine colpisce DigiCert e firma Golden Gh0st RAT con certificati rubati

Un errore nella cerimonia crittografica compromette la catena di fiducia

L’aspetto più delicato emerge dalla spiegazione preliminare fornita da eMudhra. La società ha confermato che le chiavi problematiche provenivano da una Key Generation Ceremony effettuata nell’aprile 2025 attraverso dispositivi HSM Ultimaco, precisando che l’indagine aveva individuato un’anomalia nello script utilizzato durante la procedura. Una modifica autorizzata rispetto al processo ordinario prevedeva verifiche sulle operazioni di wrapping e unwrapping delle chiavi; secondo la ricostruzione aziendale, un errore nello script avrebbe provocato la generazione di una seconda serie di chiavi deboli, successivamente utilizzate per produrre le richieste di certificazione perché contraddistinte da etichette simili a quelle delle chiavi corrette. Questi certificati furono poi firmati dalla root di eMudhra e, in alcuni casi, sottoposti anche a cross-signing da parte di Sectigo, estendendo le catene di fiducia potenzialmente interessate. La società afferma che il problema non coinvolge le chiavi private delle proprie root CA né gli altri certificati intermedi, ma l’accertamento delle cause rimane oggetto dell’indagine e della verifica dei programmi di certificazione. Nella dichiarazione ufficiale sull’incidente eMudhra sostiene inoltre che soltanto uno degli intermedi interessati fosse stato effettivamente impiegato in produzione e che nessuno degli otto avesse emesso certificati finali destinati agli utenti. Queste dichiarazioni ridimensionano l’impatto operativo documentato, ma non cancellano il problema: una chiave privata prevedibile resta compromessa indipendentemente dall’eventuale assenza di certificati legittimi emessi. La vicenda pone una questione di affidabilità dei controlli sulla generazione delle chiavi, distinta dal problema della protezione dei certificati e della catena di fiducia nei browser.

Mozilla, Google e Apple bloccano i certificati: Firefox e Android aggiornati

La comunicazione del Mozilla Security Team conferma che Firefox ha distribuito attraverso OneCRL il blocco dei certificati intermedi compromessi entro le 22:59 UTC del 17 ottobre, meno di tre ore dopo aver ricevuto la segnalazione. L’intervento è stato applicato senza richiedere il riavvio del browser o l’installazione di una nuova versione nelle configurazioni standard. Mozilla ha comunque pubblicato il 20 ottobre Firefox 158.0.1 per desktop e Android, insieme a Firefox ESR 115.43.1 ed ESR 153.5.1, per proteggere anche gli utenti le cui impostazioni personalizzate potevano impedire la ricezione automatica delle revoche. Parallelamente, l’aggiornamento NSS 3.131.1 rimuove la root collegata agli intermedi compromessi, ampliando la protezione alle applicazioni che utilizzano il trust store Mozilla senza ricevere direttamente OneCRL. Google ha invece confermato di aver verificato la segnalazione il 17 ottobre e distribuito il blocco attraverso i CRLSet di Chrome, intervenendo sugli hash SPKI delle chiavi pubbliche per impedire l’accettazione anche di certificati alternativi che utilizzassero le medesime chiavi. Il rapporto ufficiale dei team Chrome e Android indica inoltre l’arrivo della protezione su Android attraverso Google Play Services il 19 ottobre. Apple ha introdotto protezioni il 19 ottobre, mentre Google prevede la rimozione della root emSign ECC Root CA – G3 dal Chrome Root Store, con distribuzione generale programmata dal 27 ottobre 2026. L’operazione potrebbe rendere non attendibili anche certificati legittimi collegati alla stessa gerarchia, imponendo ai gestori dei siti interessati la migrazione verso un’altra autorità. Il precedente delle modifiche alla Mozilla Root Store Policy dimostra quanto il controllo delle autorità certificate sia parte integrante della sicurezza dei browser, non una semplice procedura amministrativa.

Certificate Transparency limita il rischio ma non protegge tutti i software

Il rischio teorico dell’incidente è elevato: chiunque fosse stato in grado di ricostruire una delle sei chiavi TLS avrebbe potuto firmare certificati apparentemente validi per domini non controllati, utilizzandoli in un attacco di intercettazione o impersonificazione contro client che continuavano a riconoscere quella catena di certificazione. Google introduce però una distinzione determinante, precisando che nessun certificato TLS collegato ai sei intermedi risultava registrato nei log di Certificate Transparency prima dell’intervento di blocco. Poiché Chrome richiede normalmente questa registrazione per considerare attendibile un certificato pubblico, non emergono evidenze che certificati fraudolenti emessi da quelle autorità potessero essere accettati dal browser nelle configurazioni standard. La protezione non è universale: applicazioni che non applicano Certificate Transparency, client con archivi di certificati autonomi o sistemi incapaci di aggiornare le informazioni di revoca possono continuare ad accettare catene non più sicure. Il rischio si estende quindi oltre il traffico HTTPS visualizzato nei browser, coinvolgendo software enterprise, strumenti da riga di comando, runtime applicativi, container e sistemi embedded. Non esistono prove pubbliche di campagne di intercettazione realmente condotte sfruttando queste chiavi, ma la loro recuperabilità dalla data di generazione crea una finestra temporale teorica che non può essere esclusa soltanto sulla base della rapidità degli aggiornamenti. L’incidente conferma inoltre che un certificato formalmente valido non equivale necessariamente a un’identità affidabile, un problema già emerso nella revisione dei sistemi di autenticazione e verifica dei certificati digitali in Chrome.

Continua con:

Chrome 155 corregge 247 falle, Firefox rilancia la sicurezza gratis

OpenSSL 4.0.3 chiude una falla High in DTLS e nuovi DoS su QUIC

Go, Linux e librerie applicative devono aggiornare i propri trust store

L’incidente ha provocato interventi urgenti nell’ecosistema software che utilizza archivi di certificazione indipendenti dai principali browser. Il team Go ha pubblicato Go 1.27.3 e 1.26.10, introducendo una modifica al verificatore crypto/x509 che esclude le catene contenenti gli intermedi interessati; il problema è identificato come CVE-2026-111943, relativo alla mitigazione introdotta nel runtime e non a una nuova vulnerabilità crittografica della curva P-384. Aggiornamenti o interventi correttivi sono stati segnalati anche per NSS, Python certifi, curl, diverse distribuzioni Linux, componenti Rust ed Electron, mentre alcuni ecosistemi continuano a richiedere modifiche specifiche. Per le organizzazioni italiane il controllo non dovrebbe quindi limitarsi all’aggiornamento di Firefox o Chrome, ma comprendere i sistemi che stabiliscono connessioni TLS attraverso librerie autonome, applicazioni JavaScript o Go, infrastrutture containerizzate e software che distribuiscono un proprio archivio di root certificate. Gli amministratori dovrebbero verificare le versioni dei trust store utilizzati, identificare eventuali certificati ancora collegati alle autorità eMudhra interessate e pianificare la sostituzione di quelli che perderanno attendibilità dopo la rimozione della root. Un particolare controllo riguarda i software che non verificano la revoca o che utilizzano archivi statici aggiornati raramente, perché possono continuare ad accettare certificati rifiutati dai browser moderni. La compromissione eMudhra non dimostra la debolezza della crittografia moderna, ma la vulnerabilità dei processi operativi che dovrebbero garantirne l’impiego corretto. Un algoritmo robusto non può compensare chiavi generate senza entropia sufficiente, controlli di qualità incapaci di individuare valori prevedibili e procedure di certificazione che trasformano un errore interno in un problema per l’intero ecosistema della fiducia digitale.