Una curva de 384 bits donde el secreto real era simplemente 4
El sábado 17 de octubre de 2026, un grupo de investigadores de seguridad alertó a Apple, Google, Microsoft, Mozilla y a la autoridad de certificación india eMudhra sobre un hallazgo alarmante: las claves privadas de ocho certificados intermedios podían vulnerarse en un ordenador portátil en menos de un segundo.
Dichos certificados empleaban la curva elíptica NIST P-384. Según las especificaciones criptográficas, la clave privada debe ser un número aleatorio de 384 bits escogido entre aproximadamente 10^115 valores posibles. ¿Cuál era la clave en realidad? Cuarenta y siete bytes consecutivos con ceros seguidos de un único byte. Los valores de las ocho claves eran 4, 56, 115, 155, 156, 230, 66 y 237. Una de ellas era, literalmente, el número 4.
Romper una clave de estas características requiere como máximo 255 operaciones de suma de puntos sobre la curva elíptica, un cálculo que cualquier procesador común resuelve en milisegundos. A partir de los 16 certificados adjuntos al aviso de Mozilla, los investigadores recuperaron las ocho claves privadas de manera íntegra. En la práctica, esas claves secretas estuvieron expuestas como si fueran de dominio público desde el mismo momento de su emisión en abril de 2025.
Foto: Un candado comprometido. Fuente: Ars Technica
Todos los controles formales fueron superados: ¿dónde estuvo el fallo?
Una cadena de confianza en HTTPS se estructura de forma jerárquica desde las entidades raíz, superando en cada nivel estrictas validaciones de conformidad: curvas admitidas, codificación ASN.1 legal y estructuras de firma sintácticamente perfectas. Los ocho certificados de eMudhra —seis CA emisoras de TLS (dos generaciones que cubrían DV, OV y EV) y dos CA para firma de código— se generaron en abril de 2025 y en mayo recibieron la firma cruzada de la raíz AAA Certificate Services de Sectigo. Cada una de las comprobaciones de formato fue aprobada sin tacha.
Sin embargo, ningún control automatizado exige validar si una clave privada es verdaderamente aleatoria. El proceso de generación de claves se ejecuta bajo el control exclusivo de la entidad de certificación; los auditores externos solo tienen acceso a la clave pública. La robustez matemática prometida por los 10^115 estados de P-384 solo protege si el secreto se elige con entropía genuina. El colapso de eMudhra tuvo lugar en el único punto ciego que ninguna herramienta externa puede auditar.
En los foros técnicos se plantearon varias hipótesis sobre el origen del fallo: un script de aprovisionamiento con parámetros desordenados por posición, o un fragmento de código que tomó indebidamente key[0] de una clave envuelta. Otros especialistas fueron más tajantes: las claves criptográficas deben generarse exclusivamente en el interior de un Módulo de Seguridad de Hardware (HSM). El simple hecho de haber generado las claves fuera y cometer un error tan elemental evidenciaba que los procedimientos operativos estaban rotos desde el primer día.
Respuesta fulminante de los navegadores: cuatro días de desconexión
La misma noche del 17 de octubre, Google desplegó una actualización urgente de CRLSet para bloquear los ocho certificados intermedios; Mozilla reaccionó pocas horas después con OneCRL. El 20 de octubre, Mozilla publicó el incidente y revocó de raíz la entidad eMudhra del paquete NSS; poco después, Google confirmó la expulsión de la autoridad en Chrome Root Store v43.
¿Por qué actuaron con tanta contundencia? El investigador Ian Carroll lo explicó con claridad: «Básicamente son claves de 1 byte que cualquiera puede factorizar; el problema resulta imposible de contener». Al no existir una fecha concreta de brecha o intrusión, cualquier atacante pudo haber generado certificados fraudulentos de forma inadvertida durante los 17 meses transcurridos.
Los ingenieros de Chrome añadieron un matiz técnico crucial: dado que estas autoridades intermedias jamás registraron certificados TLS emitidos en los registros de Transparencia de Certificados (CT, Certificate Transparency), Chrome no habría confiado por defecto en los certificados espurios. No obstante, aunque CT detecta emisiones indebidas, no impide técnicamente la firma de certificados falsos, y la inmensa mayoría del software ajeno a los navegadores web ni siquiera comprueba los registros CT.
Esquema: Cada eslabón de la cadena confía en la validación del anterior, pero la entropía de las claves base no se audita externamente. Fuente: Keytos
Los scripts curl | sh encabezan la lista de amenazas críticas
Los usuarios de navegadores modernos estuvieron mayormente a salvo gracias a las listas de revocación inmediata y al requisito estricto de CT. El riesgo real y desprotegido se concentra en el ecosistema exterior.
Clientes TLS sin interfaz gráfica como curl, Python, Node.js, Go, Java, git y diversos gestores de paquetes dependen habitualmente de almacenes estáticos de certificados CA alojados en disco. Por diseño, la mayoría no consulta listas de revocación (OCSP/CRL) ni comprueba registros de Transparencia de Certificados. Frente a estos clientes, los avisos de revocación quedan anulados: al consultar los paquetes de certificados del sistema, las entidades intermedias de eMudhra con claves de 8 bits seguían figurando como emisores válidos.
El vector de ataque resulta devastador en dos entornos concretos: en primer lugar, los scripts de instalación rápida canalizados mediante curl | sh y los sistemas de actualización automática, donde un certificado interceptado permite ejecutar código arbitrario con permisos de usuario o de administrador (root); en segundo lugar, los entornos de integración continua (CI/CD), cuyos contenedores de compilación custodian credenciales de infraestructura en la nube, tokens de registros de paquetes y claves de firmado. Para materializar un ataque de intermediario (Man-in-the-Middle), a un atacante le bastaba un simple portátil y menos de un segundo de potencia de cálculo.
La defensa de eMudhra y su retirada estratégica
El 22 de octubre, eMudhra hizo público su abandono absoluto del mercado global de certificados SSL/TLS. La compañía defendió su postura con tres argumentos: el negocio global de SSL/TLS representaba apenas el 1 % de sus ingresos totales; los costes derivados de la soberanía de datos y el cumplimiento normativo aumentaban al tiempo que grandes gigantes tecnológicos expedían certificados gratuitos de forma masiva; y, por último, que «la repercusión y el escrutinio desatados en redes sociales fueron desproporcionados respecto al peso real de esta división en nuestra actividad». Al mismo tiempo, recalcaron haber revocado las CA afectadas en un margen de 14 horas, no haber emitido certificados para dominios finales y no haber sufrido brechas en su infraestructura.
La comunidad técnica rechazó de pleno el argumento de la supuesta desproporción. La crítica generalizada apuntó al núcleo del problema: cómo fue posible que durante 17 meses ningún procedimiento interno detectase que las claves carecían por completo de entropía. La necesidad de que las claves se originen dentro de un entorno HSM inaccesible descartaba cualquier excusa organizativa.
El último eslabón es humano y carece de red de seguridad automatizada
En todo este episodio no falló ningún algoritmo criptográfico. Las curvas cumplían los estándares, los formatos eran válidos, las estructuras eran correctas y las firmas cruzadas procedían de gigantes consolidados como Sectigo. Ocho certificados superaron 17 meses de comprobaciones automatizadas simplemente porque ninguna herramienta estandarizada ni auditoría rutinaria se detuvo a comprobar lo más elemental: si una clave que debía contar con 384 bits de entropía era en realidad un número entero de 8 bits.
El extremo final de la cadena HTTPS desemboca en el navegador web, pero la verificación de la calidad de las claves privadas de las autoridades intermedias solo puede inferirse a posteriori mediante el análisis de las claves públicas. En el caso de eMudhra hicieron falta 17 meses y la curiosidad manual de un investigador externo. La auténtica frontera de la seguridad en PKI descansa sobre la disciplina operativa, un factor que no admite un comando simple como curl para autoinspeccionarse. eMudhra cerró su división SSL/TLS para dar por zanjada la crisis, pero ante el dilema de «quién vigila al vigilante», la próxima entidad negligente tal vez no cuente con una división secundaria prescindible que represente solo el 1 % de su facturación.
Enlaces de referencia:
- Divulgación en Mozilla Bugzilla y notas de versión de NSS
- Anuncio oficial de Chrome Root Store v43
- Comunicado de eMudhra sobre el abandono del negocio global SSL/TLS
- Análisis técnico de Ian Carroll
- Hilo de debate en Hacker News (item?id=50177916)
