Cerimonia delle chiavi errata: otto CA di eMudhra con chiavi banali da violare

Otto autorità di certificazione intermedie gestite dalla società indiana eMudhra sono state emesse con chiavi private che chiunque poteva ricavare dai certificati pubblici in ben meno di un secondo. Lo ha segnalato il 17 ottobre 2026 un ricercatore noto come «Wayne». Mozilla ha ricevuto la segnalazione alle 20:06 UTC, inoltrata dal Chrome Root Program. In circa due ore Mozilla ha recuperato le chiavi in modo indipendente, senza conoscere il metodo del segnalatore. Questo ha confermato che il problema stava nella generazione delle chiavi ed era banale da sfruttare.

La causa non è stata un'intrusione. Secondo la ricostruzione di eMudhra, si è trattato di uno script difettoso eseguito durante una key ceremony, e i controlli umani non sono riusciti a individuarlo.

01Quanto erano deboli le chiavi

Erano chiavi a curva ellittica P-384. Una chiave privata generata correttamente è un numero estratto da uno spazio di circa 2^384 valori. Secondo il rapporto sull'incidente di Mozilla, tutte e otto le chiavi avevano valori inferiori a 256, quindi a un attaccante bastava provare 256 candidati. Le chiavi erano 4, 56, 66, 115, 155, 156, 230 e 237. La chiave privata di «EM OV TLS CA - G3C» era semplicemente 4.

Poiché la chiave pubblica a curva ellittica è lo scalare privato moltiplicato per il punto base della curva, uno scalare inferiore a 256 si trova calcolando qualche centinaio di multipli di quel punto. Poi basta un confronto con la chiave pubblica presente nel certificato. È questa l'inferenza alla base dei tempi di recupero inferiori al secondo riportati. Ars Technica indica dimensioni effettive della chiave da 3 a 8 bit. Un resoconto di un fornitore parla di «byte», il che è incoerente con i valori stessi delle chiavi.

La chiave di una CA intermedia può firmare qualsiasi certificato end-entity che risalga alla radice sovrastante. Un attaccante in possesso di una di queste chiavi poteva falsificare un certificato per qualsiasi dominio e impersonare server per intercettare o modificare il traffico. Lo sfruttamento richiede comunque una posizione attiva di adversary-in-the-middle, come osserva Ars. È una soglia alta per alcuni attaccanti, ma facile per chi controlla una rete locale.

La portata conta. Le otto chiavi provenivano da un lotto di 24 intermedie generate il 30 aprile 2025. Sei emettono certificati TLS e due sono per il code signing; Sectigo le ha sottoposte tutte e otto a cross-signing nel maggio 2025. Contando i cross-sign, i certificati coinvolti sono 16.

02Che cosa è andato storto nella cerimonia

Una key ceremony è la procedura scritta e controllata da testimoni con cui una CA genera le proprie chiavi più sensibili all'interno di hardware security module (HSM). eMudhra afferma che la cerimonia ha usato HSM FIPS 140-2 Level 3. La dichiarazione aggiornata sottolinea che il difetto stava in un singolo passaggio della procedura, non nell'assenza di HSM.

La ricostruzione su Bugzilla segue questa sequenza:

• La cerimonia ha creato a bordo dell'HSM le coppie di chiavi ECC robuste previste.
• Una deviazione approvata ha aggiunto un test di wrap/unwrap, perché in questo caso le chiavi erano destinate all'esportazione. Il wrapping cifra una chiave con un'altra chiave, in modo che possa spostarsi tra HSM.
• Un difetto nel codice ha creato a bordo anche una seconda coppia di chiavi, debole.
• Le etichette della coppia debole somigliavano a quelle delle originali, perciò è stata usata per errore per costruire le richieste di firma del certificato (CSR), che la radice ha poi firmato.
• Le stesse CSR sono state inviate a Sectigo per il cross-signing.

Nulla in questa catena ha richiesto il guasto dell'hardware crittografico. L'HSM ha generato una chiave debole su richiesta, e una persona o un processo ha scelto quella sbagliata. La stessa società ammette che un errore di script ha portato a emettere CA con chiavi deboli. Riconosce inoltre errori umani in più passaggi e ha promesso di riverificare tutte le key ceremony svolte. Il quadro indica l'assenza di controlli maker/checker. Nessuno ha confrontato le chiavi pubbliche da certificare con quelle che la cerimonia avrebbe dovuto produrre, e nessuno ha verificato la lunghezza o la casualità delle chiavi prima che la radice firmasse.

03L'avvertimento ignorato

Il dettaglio più scomodo è un precedente del 2025. Le domande di Mozilla a eMudhra fanno riferimento al Bug 1970728, del giugno 2025. In quel caso la chiave usata per firmare alcune CRL non corrispondeva alla chiave pubblica nel certificato della CA corrispondente. eMudhra individuò la seconda coppia di chiavi, quella che corrispondeva, e ri-firmò con essa le CRL. Non sospese le operazioni per chiedersi perché esistessero due coppie. Una CRL è l'elenco firmato dei certificati revocati che una CA pubblica. Una CA la cui CRL non supera la verifica ha, per definizione, un problema di integrità delle chiavi.

Secondo la spiegazione successiva di eMudhra, le CRL erano state firmate in origine con le chiavi robuste originali. Quelle firme non risultavano valide perché i certificati erano stati emessi sulle chiavi deboli, e così le CRL furono ri-firmate con queste ultime. Un fornitore di threat advisory sostiene che il difetto sia sopravvissuto circa 17 mesi e due cicli di audit. È un'affermazione di seconda mano e non ho verificato i dettagli degli audit. Quali che siano le risultanze degli audit, l'incidente del 2025 offriva un percorso diagnostico che avrebbe portato alla luce il problema, ed è stato invece chiuso come errore di configurazione.

La scoperta è stata economica. I resoconti descrivono il ricercatore mentre esamina il corpus CCADB delle intermedie pubblicamente fidate, e uno di essi afferma che siano stati usati i controlli open source paranoid_crypto di Google. La scansione dei certificati pubblici alla ricerca di chiavi deboli è una tecnica collaudata. Nessuna prova pubblica suggerisce che servisse qualcosa di esotico.

04La revoca, e perché non è bastata

Il contenimento nella popolazione dei browser è stato rapido. Chrome ha distribuito un aggiornamento CRLSet e Mozilla ha pubblicato le voci OneCRL il 17 ottobre, senza bisogno di riavviare il browser. eMudhra ha revocato tutte e otto le intermedie il 18 ottobre (motivo: caCompromise). Sectigo ha revocato i certificati cross-signed il 19 ottobre. Apple e Microsoft sono seguite nei giorni successivi, con alcuni resoconti che differiscono di uno o due giorni sulle date esatte. Il primo articolo di Ars Technica, che parlava di uno o due giorni per i blocchi nei browser, è più lento della cronologia primaria. Segnalava inoltre che Edge su Windows 10 si collegava ancora a host vulnerabili al momento della pubblicazione. Microsoft non ha fornito dettagli.

Il problema più difficile sono i client che non consultano i dati di revoca. Mozilla ha deciso la rimozione d'emergenza della fiducia nella radice madre, emSign ECC Root CA - G3, per proteggere i client che ignorano le informazioni di revoca o non possono ritirare la fiducia in specifiche intermedie. Chrome ha dichiarato che si sarebbe allineata. Secondo i resoconti, la rimozione in Chrome raggiunge tutti i dispositivi il 27 ottobre, cioè oggi. Le correzioni di Mozilla per Go e NSS sono state rilasciate il 20 ottobre.

Filippo Valsorda, manutentore della crittografia di Go, ha detto ad Ars che la bonifica avrà una coda molto lunga. Ha citato dispositivi IoT, container, macchine Linux dimenticate e strumenti che includono i propri root store, e ha paragonato la portata del caso a quella di Heartbleed. Il paragone è un suo giudizio e resta non dimostrato. Cloudflare, da parte sua, ha riferito che le chiavi erano considerate fidate all'interno del proprio stack e ha rilasciato aggiornamenti per i client.

La revoca della fiducia ha un costo collaterale. I dati di Certificate Transparency al 21 ottobre mostravano circa 30.800 precertificati non scaduti riconducibili alla radice revocata. eMudhra stima che circa il 97% sia stato emesso tramite ACME. La società sta migrando gli abbonati alla propria gerarchia RSA G1. Alcuni di quei certificati sono legittimi e ora vanno sostituiti per un guasto non correlato a monte.

05Rilevamento e che cosa mostra sulla supervisione

Se qualcuno abbia abusato delle chiavi non è del tutto chiarito, ma le evidenze finora sono rassicuranti. Ars non ha riscontrato prove di uso malevolo nei log di trasparenza. Un resoconto secondario afferma che Google non abbia trovato certificati TLS riconducibili alle sei intermedie registrati nei log prima del blocco. Red Sift ne ha trovati alcuni registrati dopo la divulgazione, opera di ricercatori che provavano le chiavi recuperate. eMudhra afferma che solo un'intermedia è stata messa in produzione e che nessuna ha emesso certificati per i clienti. I log di trasparenza rilevano soltanto i certificati che vengono registrati, e i client che non applicano la CT potrebbero aver ricevuto falsificazioni non registrate. Questo rischio residuo non si può escludere, e diversi analisti lo dicono.

Emergono tre lezioni:

1. Gli audit campionano il processo, non i risultati. Una cerimonia che supera una checklist con testimoni può comunque certificare la chiave sbagliata. Un controllo meccanico che verifichi la corrispondenza tra la chiave pubblica certificata e quella prevista dell'HSM, insieme a un controllo di entropia minima, avrebbe intercettato l'errore.
2. Le anomalie richiedono un'analisi delle cause profonde. Il disallineamento delle CRL del 2025 era un segnale gratuito. Le domande pubblicate da Mozilla vanno dritte al perché sia stato insabbiato.
3. La revoca vale quanto la sua distribuzione. I browser possono bloccare in poche ore. Tutto il resto richiede aggiornamenti software, e revocare la fiducia in un'intera radice è lo strumento brutale che raggiunge la lunga coda.

Giovedì il consiglio di amministrazione di eMudhra ha annunciato l'uscita dal mercato TLS globale. Il presidente ha citato i costi di conformità e una linea di business che genera circa l'1 percento dei ricavi. La società sta ancora rivedendo le proprie key ceremony e l'analisi delle cause profonde è incompleta. Restano in sospeso anche le decisioni di Chrome e Mozilla sulla radice RSA rimanente. Mancano i log completi della cerimonia, il diff del codice e una spiegazione del perché l'anomalia del 2025 non sia stata approfondita. Questi elementi mostrerebbero se si è trattato di un solo script difettoso o di un ambiente di controllo incapace di rilevare una chiave privata di un solo byte.