Una de las claves privadas de una autoridad de certificación de confianza pública era, literalmente, el número 4. Otra era el 56. Las ocho claves de las CA intermedias que la india eMudhra generó en abril de 2025 eran números enteros menores que 256, cuando deberían haber sido números aleatorios de 384 bits. Cualquiera podía calcularlas en menos de un segundo a partir de los certificados públicos.
Las claves usaban ECDSA sobre la curva NIST P-384, uno de los algoritmos más robustos que hoy se usan en la PKI. Y no sirvió de nada. El caso recuerda algo que en el debate sobre criptografía postcuántica y criptoagilidad a veces se olvida: el algoritmo no lo es todo. Tan importante como elegir bien la curva o el tamaño de clave es generar la clave correctamente, comprobar que se ha generado bien y poder sustituirla con rapidez cuando algo falla, incluso cuando el fallo está en el propio hardware.
Qué ha pasado
Los certificados afectados son seis CA intermedias de TLS (EM DV, EM OV y EM EV TLS CA – G3B y G3C) y dos de firma de código (EM OV CS CA – G3B y G3C), que dependían de la raíz emSign ECC Root CA – G3 y tenían además una certificación cruzada de Sectigo.
| Fecha | Hecho |
|---|---|
| 30 de abril de 2025 | Ceremonia de generación de claves en la que se crean las intermedias |
| 2025 | Las listas de revocación (CRL) de esas intermedias aparecen con firmas no válidas (bug 1970728 de Mozilla). eMudhra las vuelve a firmar y el síntoma desaparece |
| 17 de octubre de 2026 | Un investigador firma un mensaje con las ocho claves privadas y lo comunica a los programas de raíces. Chrome (CRLSet) y Firefox (OneCRL) bloquean las intermedias en pocas horas |
| 18 de octubre | eMudhra revoca las ocho intermedias por compromiso de la CA; Sectigo revoca las certificaciones cruzadas |
| 19 y 20 de octubre | Bloqueo en Android, Apple y Microsoft. Mozilla retira la raíz de su almacén. Go publica CVE-2026-111943 |
| 22 de octubre | eMudhra anuncia que abandona el negocio global de certificados SSL/TLS |
| 27 de octubre (previsto) | Chrome retira la raíz emSign ECC Root CA – G3 de su almacén |
Según Google, no llegó a registrarse en Certificate Transparency ningún certificado fraudulento emitido con esas claves, por lo que los navegadores que exigen CT no pudieron ser atacados. Pero durante año y medio, cualquiera que hubiera mirado los certificados con atención habría podido emitir certificados de cualquier dominio aceptados por clientes que no exigen CT, como muchas aplicaciones y servicios que usan bibliotecas de Go, Python, Java o Node. eMudhra estima en unos 30.000 los certificados de clientes que deben migrar.
La causa: una curva excelente con una clave ridícula
En ECDSA, la clave privada d es un número entero elegido al azar entre 1 y el orden de la curva, y la clave pública es el punto Q = d · G, que resulta de sumar el punto generador G consigo mismo d veces. La seguridad descansa en que, con un d de 384 bits aleatorios, recuperarlo a partir de Q (el problema del logaritmo discreto en curva elíptica) es inviable. Pero si d es menor que 256, basta con calcular 4·G, 56·G… hasta encontrar el punto que coincide con la clave pública del certificado: como mucho, 255 multiplicaciones.
| Certificado intermedio | Clave privada (d) |
|---|---|
| EM OV TLS CA – G3C | 4 |
| EM EV TLS CA – G3C | 56 |
| EM OV CS CA – G3B | 66 |
| EM EV TLS CA – G3B | 115 |
| EM OV TLS CA – G3B | 155 |
| EM DV TLS CA – G3B | 156 |
| EM DV TLS CA – G3C | 230 |
| EM OV CS CA – G3C | 237 |
Según la explicación preliminar de eMudhra en el hilo del incidente en Mozilla, el HSM funcionó correctamente. El fallo estuvo en el procedimiento:
- Durante la ceremonia se generaron primero pares de claves correctos.
- Una prueba de envoltura y desenvoltura (wrap/unwrap) aprobada como desviación del guión, combinada con un error en el código de automatización, creó en el HSM un segundo juego de claves con entropía truncada.
- Por la coincidencia de etiquetas entre ambos juegos, el script usó las claves débiles para generar las solicitudes de certificado.
- La raíz firmó esas solicitudes, y las listas de revocación, firmadas con las claves buenas, empezaron a fallar. En vez de investigar por qué, se volvieron a firmar con las claves débiles.
Hay un detalle técnico que merece atención: las comprobaciones habituales de validez de la clave pública no detectan este fallo. Un punto 4·G es un punto perfectamente válido de la curva P-384: cumple la ecuación, está en el subgrupo correcto y supera la validación completa de clave pública de NIST. Solo lo delata una prueba específica, comparar la clave pública con los múltiplos pequeños del generador, o una revisión de la clave privada antes de usarla.
No es la primera vez
La historia de la criptografía aplicada está llena de algoritmos impecables arruinados por una mala generación de claves o de números aleatorios. Y varios de los casos más graves ocurrieron en dispositivos certificados.
| Año | Caso | Qué falló | Lección |
|---|---|---|---|
| 2008 | OpenSSL de Debian (CVE-2008-0166) | Un cambio en el código dejó como única fuente de entropía el identificador de proceso: solo unas 32.000 claves posibles por tipo y tamaño, durante casi dos años | Un fallo de software en la generación anula cualquier algoritmo |
| 2010 | Consola PlayStation 3 | Sony firmaba con ECDSA reutilizando siempre el mismo número aleatorio por firma, y su clave privada pudo despejarse | En ECDSA no basta con una buena clave: cada firma necesita aleatoriedad nueva |
| 2012 | Estudio «Mining your Ps and Qs» (Heninger y otros) | Miles de dispositivos de red generaban claves RSA al arrancar, sin entropía suficiente, y compartían factores primos | Los dispositivos embebidos son especialmente vulnerables |
| 2013 | Tarjetas del certificado digital ciudadano de Taiwán (Bernstein y otros) | Un generador de números aleatorios defectuoso en tarjetas certificadas permitió factorizar 184 claves RSA | La certificación del hardware no garantiza la calidad de cada clave |
| 2017 | ROCA (CVE-2017-15361) | La biblioteca RSALib de Infineon generaba primos con una estructura que permitía factorizar claves de 1024 y 2048 bits. Afectó a TPM, a YubiKey 4 y a documentos de identidad electrónicos de Estonia (unos 760.000), Eslovaquia y España, cuyos certificados se suspendieron | El fallo puede estar en el chip, y afectar a millones de claves a la vez |
| 2024 | EUCLEAK (CVE-2024-45678) | La implementación de ECDSA de la biblioteca de Infineon filtraba la clave por canal lateral; estuvo sin detectar unos 14 años y unas 80 evaluaciones Common Criteria | Tampoco la curva elíptica en un chip certificado es garantía absoluta |
| 2025-2026 | eMudhra | Un error en el guión de la ceremonia dejó en producción claves P-384 menores que 256 | El procedimiento importa tanto como el HSM |
El caso ROCA tiene especial interés en España. A principios de noviembre de 2017, la Policía anunció que suspendía los certificados de los DNI electrónicos afectados y que los sustituiría, aunque los documentos siguieron siendo válidos para identificarse y viajar. Estonia tuvo que suspender los certificados de unas 760.000 tarjetas y abrir centros temporales para renovarlos. Fue una demostración a escala nacional de lo que significa no tener criptoagilidad.
Generar en el HSM, sí; pero poder importar claves también
La buena práctica, y lo que exigen las normas para las claves de las autoridades de certificación, es generar las claves dentro de un módulo criptográfico seguro (HSM): así la clave privada nunca existe en claro fuera de un entorno protegido. Es lo correcto, pero no basta, por dos motivos.
El hardware también falla. ROCA, las tarjetas de Taiwán o EUCLEAK demuestran que el generador de claves o la biblioteca criptográfica de un chip certificado pueden tener defectos que afectan a todas las claves que produce. Cuando eso ocurre, el fabricante necesita meses para corregir el firmware y volver a certificarlo, y mientras tanto el prestador no puede generar claves fiables con ese equipo.
La diversidad es una defensa. Si un prestador puede instalar en su HSM claves generadas externamente, en otro dispositivo certificado de un fabricante distinto o en un entorno de generación aislado y auditado, no depende de un único generador de números aleatorios ni de una única biblioteca. Si se descubre un fallo en uno, puede seguir operando con el otro sin esperar a que el fabricante lo corrija. Es criptoagilidad aplicada no al algoritmo, sino al origen de las claves.
Ahora bien, el caso eMudhra tiene una ironía: las claves débiles nacieron precisamente en una prueba de envoltura y desenvoltura, que es el mecanismo con el que se exportan e importan claves entre HSM. Importar claves no es más seguro por sí mismo; exige el mismo rigor que generarlas:
- La clave viaja siempre cifrada con otra clave (wrapping) y nunca en claro.
- El proceso se divide entre varias personas, con conocimiento compartido y control dual (esquemas M de N).
- La importación se hace en una ceremonia con guion, testigos y acta, igual que la generación.
- Las pruebas se hacen en un entorno distinto del de producción, y nunca dejan material criptográfico en el HSM productivo.
- Cada clave lleva una etiqueta única y se verifica, antes de firmar la solicitud de certificado, que la clave pública de la solicitud es la que se acaba de generar o importar.
Y, sobre todo, venga de donde venga la clave, hay que comprobarla antes de certificarla.
Qué revisar en una ceremonia de claves
Las normas ya obligan a documentar y supervisar la generación de claves de las autoridades de certificación. Los Requisitos Básicos del CA/Browser Forum exigen un guión de generación de claves, que la ceremonia la presencie o la grabe un auditor cualificado y que este emita un informe. En Europa, la norma ETSI EN 319 411-1, que aplican los prestadores de servicios de confianza bajo eIDAS, pide que las claves de CA se generen en dispositivos criptográficos seguros y bajo control múltiple. Los Requisitos Básicos obligan además a rechazar claves con debilidades conocidas, como las del OpenSSL de Debian o las afectadas por ROCA.
La ceremonia de eMudhra se hizo con un HSM certificado FIPS 140-2 de nivel 3 y bajo un guión aprobado, y aun así falló. Por experiencia en auditoría, añadiría a la lista de comprobaciones algunas que no siempre se hacen:
- Comprobar la calidad de cada clave generada, no solo que el HSM esté certificado. Para curvas elípticas, descartar que la clave pública coincida con múltiplos pequeños del generador. Para RSA, aplicar los detectores de ROCA, las listas de claves débiles conocidas y las pruebas de primos demasiado cercanos.
- Probar la clave con el certificado ya emitido: firmar un mensaje de prueba y verificarlo con la clave pública del certificado, no con la que el sistema «cree» que tiene.
- Separar de verdad las pruebas de la producción. Cualquier desviación del guión, como la prueba de envoltura de eMudhra, debe repetirse después en un entorno limpio o justificar por qué no deja rastro.
- Exigir etiquetas únicas e inventario de objetos del HSM al final de la ceremonia: cuántas claves hay, cuáles y para qué.
- Tratar cualquier anomalía criptográfica como un posible incidente de claves. La firma no válida de las listas de revocación en 2025 era la pista que lo explicaba todo. Volver a firmarlas para que el error desapareciera fue tapar el síntoma.
- Prever la sustitución. Tener ensayado cómo revocar una intermedia, generar o importar otra y migrar a los clientes en horas, no en meses.
Conclusión
En plena transición postcuántica, buena parte del debate se centra en qué algoritmos elegir: ML-DSA, SLH-DSA, curvas elípticas o RSA de más bits. El caso eMudhra recuerda que una clave de P-384 que vale 4 es más débil que una clave RSA de 512 bits bien generada. La seguridad de una PKI depende de una cadena con muchos eslabones: el algoritmo, el generador de números aleatorios, el hardware, el guión de la ceremonia, las personas que lo ejecutan, las comprobaciones posteriores y la capacidad de reaccionar. Y la criptoagilidad no consiste solo en poder cambiar de algoritmo, sino también en poder cambiar de clave, de fabricante y de origen de las claves cuando uno de esos eslabones falla.
Fuentes
- Bug 2083449: eMudhra, compromiso de claves privadas de certificados intermedios, Mozilla.
- Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates, Google.
- eMudhra to exit global SSL/TLS certificate business, eMudhra, 22 de octubre de 2026.
- Indian certification authority eMudhra’s private keys compromised, The Register.
- Eight eMudhra CA keys compromised, The Hacker News.
- The eMudhra CA compromise and exit from public SSL/TLS, análisis técnico con la tabla de claves.
- Factoring RSA keys from certified smart cards: Coppersmith in the wild, Bernstein y otros, 2013.
- ROCA vulnerability y noticia sobre su impacto en los eID europeos, Interoperable Europe.
- EUCLEAK, NinjaLab, 2024.
