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 entidad de certificación 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.
Para entender por qué esto es tan grave (y por qué un algoritmo criptográfico basado en una curva «excelente» no salvó la situación), conviene recordar brevemente cómo funciona un certificado digital y qué es realmente una clave privada. Si ya conoces estos conceptos, puedes saltarte el siguiente apartado.
Qué es una clave privada y una clave pública
Imagina una caja de mago con dos tapas, dos cerraduras y un mecanismo que gira al cerrarla. Lo que se introduce en la caja con una llave solo se puede sacar por la otra tapa, con la otra llave. Una de las llaves se define para que pueda conocerla cualquiera (la llave pública) y la otra se protege celosamente (la llave privada).
En criptografía de curva elíptica (ECDSA), la clave privada es un número secreto muy grande, y la clave pública se calcula a partir de ese número. Si el número secreto es fácil de adivinar, cualquiera puede fabricar la «llave» privada y hacerse pasar por la autoridad de certificación.
Qué es una autoridad de certificación raíz y una intermedia
Una autoridad de certificación (CA, Certification Authority) es una entidad de confianza que emite certificados digitales, los «DNI» de los sitios web. Hay una CA raíz, la de más confianza, y CA subordinadas a ella (CA intermedias), que son las que firman los certificados de los sitios web que se usan en el protocolo TLS. Si la clave privada de una CA intermedia queda comprometida, un atacante puede emitir certificados válidos para cualquier dominio (google.com, tu banco, etc.) que los navegadores aceptarían, siempre que esa CA haya superado los requisitos de aceptación del CA/Browser Forum.
Entropía y generación de claves
La seguridad de la clave privada depende de que ese número sea impredecible. Si en lugar de un número aleatorio de unos 384 bits se usa un número pequeño (como 4 o 56), cualquiera puede probar todos los valores posibles en segundos. Es como poner «0004» como combinación de la caja fuerte.
HSM y ceremonia de claves
Un HSM (Hardware Security Module) es un dispositivo físico diseñado para generar y proteger claves de forma segura. Una ceremonia de claves es el procedimiento formal (con testigos, auditores, guiones, controles duales…) que se sigue para generar las claves de una CA. El fallo del prestador de servicios de certificación eMudhra no fue del algoritmo ni, aparentemente, del HSM en sí, sino de un error en el procedimiento y en el código de automatización durante esa ceremonia.
Las claves usaban el algoritmo ECDSA sobre la curva NIST P-384, uno de los algoritmos más robustos que hoy se usan en una 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 (el registro histórico público de certificados emitidos) 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.
Actualización (26 de octubre). El hilo de Mozilla sigue abierto y aporta matices:
- eMudhra insiste en que ella no emitió certificados finales con esas intermedias. Pero un participante ha contado 107.107 certificados registrados en Certificate Transparency entre el 20 y el 21 de octubre bajo seis de las ocho claves, emitidos por terceros una vez que las claves eran públicas. Es la demostración práctica de que cualquiera podía firmar con ellas.
- Mozilla envió el 20 de octubre una lista de preguntas con 24 horas de plazo que, a 23 de octubre, seguían sin respuesta. El programa de raíces de Chrome ha rechazado que la presión mediática justifique el retraso.
- eMudhra ha anunciado que presentará su informe completo dentro del plazo de 14 días que fija la CCADB. Varias respuestas vencen el 28 de octubre.
- Se ha abierto otro incidente (bug 2085612) porque los servidores de CRL y OCSP de eMudhra bloqueaban peticiones según el agente de usuario, lo que podría incumplir los Requisitos Básicos sobre disponibilidad del estado de revocación.
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 |
Para hacerse una idea del tamaño: una clave privada correcta de P-384 tiene del orden de 2³⁸⁴ posibilidades, un número de 116 cifras. Estas claves tenían menos de 256.
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, que exigen la presencia de al menos M custodios de entre N posibles).
- La importación se hace en una ceremonia con guion, auditores, 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. Existen herramientas abiertas que agrupan estas pruebas, como paranoid_crypto, de Google, aunque su repositorio se archivó en agosto de 2026; en el hilo de eMudhra ya se ha preguntado si los programas de raíces aplican este tipo de comprobaciones a todas las intermedias.
- 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.
