eMudhra lascia il business globale dei certificati SSL/TLS dopo la scoperta di otto certificati intermedi con chiavi private tanto deboli da poter essere individuate in millisecondi. Chi le avesse ricavate avrebbe potuto generare certificati per qualsiasi sito o server di posta, riconosciuti come attendibili dai principali browser. L’azienda indiana ha annunciato il ritiro due giorni dopo la divulgazione dei ricercatori, spiegando che questa attività rappresentava appena l’1% dei ricavi e comportava costi e complessità crescenti sul fronte della conformità.
Il presidente V. Srinivasan ha indicato anche la concorrenza delle organizzazioni che offrono certificati TLS gratuiti, che aveva ulteriormente ridotto il ritorno sull’investimento rispetto agli altri prodotti e servizi dell’azienda. Nella comunicazione, eMudhra ha giudicato l’attenzione generata sui social dall’incidente sproporzionata rispetto al peso di SSL/TLS nel proprio business. Dopo le deliberazioni, il consiglio di amministrazione ha quindi considerato l’uscita la scelta più adatta per la società e i suoi azionisti.
La debolezza delle chiavi private emerge dal confronto con i valori previsti. La crittografia a curve ellittiche NIST P-384, utilizzata per quei certificati, dovrebbe offrire circa 384 bit di entropia, cioè un insieme di possibili chiavi pari a 2 elevato alla 384. Le otto chiavi difettose avevano invece un’entropia compresa tra 3 e 8 bit: persino la più robusta lasciava al massimo 256 possibilità. Una delle chiavi aveva semplicemente valore numerico 4, rendendo impraticabile qualsiasi aspettativa di segretezza.
Nella spiegazione tecnica, l’azienda ha ricondotto l’incidente alla cerimonia di generazione delle chiavi del 30 aprile 2025, svolta sotto la propria radice ECC con moduli HSM conformi a FIPS 140-2 Level 3. Questi dispositivi custodiscono chiavi crittografiche e dati sensibili, generalmente separati dal resto della rete. Secondo la verifica descritta da eMudhra, le chiavi originali erano state generate correttamente; un difetto nel codice aveva però prodotto anche un secondo insieme di chiavi deboli, poi utilizzato per i certificati distribuiti.
Il passaggio coinvolto era una prova di wrap/unwrap, introdotta come variazione approvata della procedura perché le chiavi erano destinate all’esportazione. Il meccanismo protegge una chiave con un’altra chiave durante il trasferimento tra HSM, per poi recuperarla nel dispositivo di destinazione. La somiglianza delle etichette avrebbe portato a selezionare per errore le chiavi deboli nella richiesta di firma del certificato, successivamente firmata dalla radice di eMudhra. Le richieste basate sulle stesse chiavi erano state inviate anche a Sectigo per la firma incrociata.
Un ulteriore segnale era emerso nelle liste di revoca, o CRL: elenchi firmati digitalmente con cui un’autorità di certificazione identifica i certificati revocati prima della scadenza. Le liste erano state inizialmente firmate con le chiavi private originali, considerate corrette, ma le firme risultavano errate. Erano state quindi firmate nuovamente con le chiavi difettose. La sequenza solleva un interrogativo sui controlli: il fallimento della prima firma avrebbe potuto offrire l’occasione per indagare sulla discrepanza tra le chiavi utilizzate.
eMudhra ha riconosciuto errori umani in più passaggi e gravi carenze nell’integrità del ciclo di vita delle chiavi durante quella specifica cerimonia. Ha annunciato verifiche più approfondite sui difetti del codice, sulle lacune procedurali e sui controlli incrociati tra chi esegue le operazioni e chi le verifica. L’impegno dichiarato comprendeva inoltre il riesame di tutte le cerimonie di generazione delle chiavi svolte dall’azienda nell’arco della settimana successiva.
I produttori di browser hanno bloccato i certificati emessi attraverso gli intermedi compromessi entro uno o due giorni dalla scoperta, eliminando gran parte della minaccia. Per gli ambienti aziendali, il problema si estende però a server di posta, dispositivi IoT, container Docker, macchine Linux dimenticate e strumenti da riga di comando non mantenuti che includono una propria copia delle radici fidate. Questi sistemi possono richiedere tempi molto più lunghi per recepire il blocco; alcuni dispositivi embedded potrebbero non essere mai in grado di applicarlo.