La certificate authority indiana eMudhra Limited afferma che lascerà il mercato globale dei certificati SSL/TLS. La decisione arriva dopo la scoperta di otto certificati TLS intermedi le cui chiavi private erano così deboli da poter essere recuperate quasi istantaneamente. Chiunque fosse riuscito a recuperare una di queste chiavi avrebbe potuto emettere certificati TLS per qualsiasi sito web o server di posta. In un caso la chiave aveva un valore di appena 4.
L'azienda ha annunciato la decisione giovedì, in un post, due giorni dopo che i ricercatori avevano divulgato il problema, secondo quanto riportato da Ars Technica. Il presidente V. Srinivasan ha citato l'aumento dei costi e i crescenti obblighi di conformità. Ha inoltre affermato che i certificati SSL/TLS rappresentano solo circa l'1 per cento dei ricavi dell'azienda e che i fornitori di certificati TLS gratuiti avevano ridotto il ritorno economico di questo business rispetto agli altri prodotti e servizi di eMudhra. Nel post, eMudhra ha sostenuto che l'attenzione dei social media aveva portato sull'incidente un'attenzione sproporzionata rispetto al ruolo che il TLS svolge nelle sue attività, e che il consiglio di amministrazione aveva concluso che il ritiro fosse la scelta giusta per l'azienda e per i suoi azionisti.
Dimensioni delle chiavi ben al di sotto della robustezza attesa
I ricercatori hanno scoperto che i certificati erano stati emessi con chiavi private di lunghezza compresa tra 3 e 8 bit. Le chiavi avrebbero dovuto essere chiavi ellittiche NIST P-384, che dovrebbero garantire circa 384 bit di entropia. I valori delle chiavi difettose erano 4, 56, 66, 115, 155, 156, 230 e 237. La più robusta di queste ammetteva al massimo 256 possibilità, a fronte delle circa 2^384 che una chiave corretta dovrebbe offrire, un numero di 116 cifre.
Secondo il resoconto dei ricercatori, la vulnerabilità era facile da sfruttare. Il recupero di una chiave richiedeva solo millisecondi. Una volta recuperata la chiave, un attaccante avrebbe potuto usarla per creare certificati che i principali browser avrebbero considerato attendibili. Questi certificati, a loro volta, avrebbero potuto essere accettati da un numero elevato e sconosciuto di server di posta, dispositivi IoT, container Docker, vecchi computer Linux e strumenti a riga di comando non più manutenuti, che conservano una propria copia dei certificati radice.
I produttori di browser hanno bloccato i certificati emessi dagli intermedi interessati entro uno o due giorni dalla scoperta. Ars Technica ha osservato che altri dispositivi che dipendono dagli stessi certificati potrebbero impiegare molto più tempo per fare lo stesso passo, e che alcuni dispositivi embedded potrebbero non riuscire mai a bloccarli. Ars riteneva inoltre che eMudhra rischiasse probabilmente che il CA/Browser Forum, il gruppo industriale che stabilisce le regole del programma di certificazione TLS, potesse revocarle l'autorizzazione. Si tratta di una valutazione di Ars, non di una decisione dichiarata.
La spiegazione di eMudhra
Mercoledì eMudhra ha pubblicato una breve spiegazione. Ha dichiarato che i certificati erano stati creati sotto la sua radice ECC durante una Key Generation Ceremony (KGC) tenutasi il 30 aprile 2025, usando moduli hardware di sicurezza (HSM) conformi al FIPS 140-2 Livello 3. Secondo l'azienda, un difetto nella KGC aveva fatto sì che un passaggio di wrap/unwrap producesse un secondo set di chiavi deboli accanto a quelle originali robuste, e che furono proprio le chiavi deboli a essere pubblicate nei root store dei browser. eMudhra ha affermato di essere ancora al lavoro per stabilire la causa principale.
Gli HSM sono dispositivi dedicati alla conservazione di chiavi di crittografia e di altri dati sensibili, e normalmente sono isolati dalla maggior parte della rete. Il wrapping e l'unwrapping è il processo usato per trasferire una chiave tra HSM: il dispositivo mittente cifra la chiave con una chiave di wrapping separata, e il dispositivo ricevente la decifra al momento dell'arrivo.
In un thread su Mozilla Bugzilla, eMudhra ha fornito più dettagli. Ha dichiarato che lo script KGC usato quel giorno conteneva un difetto. Le chiavi ECC originali erano state generate sul dispositivo come previsto. Era stata poi introdotta una modifica approvata alla procedura abituale, destinata a testare un wrap/unwrap per le chiavi destinate all'esportazione. Un errore nel codice ha quindi causato la generazione, sul dispositivo, di una seconda coppia di chiavi, più debole. Poiché le etichette delle chiavi erano simili, la coppia più debole è stata usata per errore per creare la richiesta di firma del certificato (CSR), che la radice ha poi firmato. eMudhra ha detto che anche la CSR generata con le chiavi deboli era stata inviata a Sectigo per la cross-firma, e che l'azienda aveva verificato i file inviati.
eMudhra ha inoltre affermato che le sue liste di revoca dei certificati (CRL) erano state inizialmente firmate con le chiavi private originali, generate correttamente. Quelle firme sono risultate errate, e le CRL sono state quindi firmate di nuovo con le chiavi difettose. Ars Technica ha chiesto perché l'azienda non avesse indagato prima sulla causa di quel fallimento della firma. L'azienda ha risposto che errori umani commessi in più fasi avevano causato gravi debolezze nel processo di integrità del ciclo di vita delle chiavi per quella cerimonia. Ha affermato di star esaminando difetti nel codice, lacune di processo e controlli maker/checker, e che nella settimana successiva avrebbe ricontrollato tutte le cerimonie di generazione delle chiavi che aveva eseguito.
