eMudhra, el CA indio cuyas 8 llaves caben en un byte

Ocho llaves de eMudhra que cabían en un solo byte

La clave privada de una de las autoridades de certificación (CA) intermedias de eMudhra es el número 4. No un número que empieza por 4: el 4. Otra es el 56 y otra el 115. El investigador de seguridad Scott Helme recuperó las ocho desde los certificados públicos, en su portátil, en menos de un segundo.

Una CA intermedia es la pieza que firma los certificados que presentan los sitios web. Quien tiene su clave privada puede emitir un certificado válido para cualquier dominio y que el sistema de la víctima acepte como legítimo. Si tu producto cobra, autentica usuarios o mueve datos por HTTPS, esto toca la capa sobre la que está construida toda tu seguridad.

Qué pasó, con fechas

El sábado 17 de octubre un investigador reportó a Apple, Google, Microsoft, Mozilla y a eMudhra que las claves privadas de ocho certificados intermedios estaban comprometidas. Esa misma tarde Chrome publicó una actualización de CRLSet que bloqueaba los certificados y Mozilla hizo lo propio en Firefox a través de OneCRL unas horas después. El martes 20, Mozilla lo anunció públicamente y publicó una actualización de NSS que eliminaba la raíz de eMudhra de su lista de confianza; Chrome confirmó que esa raíz sale en la versión 43 de su Chrome Root Store.

Según The Hacker News, Chrome recibió el reporte a las 18:05 UTC del 17 de octubre y tenía el bloqueo activo a las 19:45 UTC; Mozilla lo recibió a las 20:06 y completó la distribución a las 22:59. Apple bloqueó los certificados el 19 de octubre, Microsoft el 20 y los dispositivos Android recibieron un bloqueo equivalente vía Google Play Services alrededor de las 22:00 UTC del 19.

Los ocho intermedios son seis CA emisoras de TLS (validación de dominio, de organización y extendida, dos generaciones de cada una) y dos CA de firma de código, todas creadas en abril de 2025. Cada una existía además como un segundo certificado con la misma clave pública, cross-signed por Sectigo en mayo de 2025.

Para dimensionar al actor: eMudhra es una CA india que vende certificados bajo la marca emSign a través de compañías en India, Estados Unidos y Países Bajos, y tenía raíces en las tiendas de confianza de Mozilla, Chrome y Apple, según The Hacker News.

Por qué bastó un byte: la matemática del fallo

Estas son claves de curva elíptica sobre P-384. La clave privada es simplemente un número, d, y la pública es d × G, donde G es un punto fijo de la curva. Ir hacia adelante es fácil; volver desde la pública a d debería ser impracticable. Ese es todo el modelo de seguridad, y solo se sostiene si d es gigantesco: una clave P-384 sana es un número aleatorio de 384 bits, con unas 10^115 posibilidades.

Las claves de eMudhra eran 47 bytes de ceros y un único byte al final. Eso deja 256 valores posibles: se calcula 1 × G, 2 × G, 3 × G y se para cuando coincide con el certificado. Como máximo, 255 pasos.

Intermedio	Tipo	Clave privada (d)
EM DV TLS CA - G3B	TLS	156
EM DV TLS CA - G3C	TLS	230
EM EV TLS CA - G3B	TLS	115
EM EV TLS CA - G3C	TLS	56
EM OV TLS CA - G3B	TLS	155
EM OV TLS CA - G3C	TLS	4
EM OV CS CA - G3B	Firma de código	66
EM OV CS CA - G3C	Firma de código	237

Lo incómodo es que nada en esos certificados parece estar mal. Una clave pública derivada de d = 4 es un punto perfectamente válido de la curva, la codificación es correcta y todas las validaciones estructurales pasan. La única forma de descubrirlo es intentarlo.

Por qué el problema no se puede contener

Cuando se compromete la clave de una CA, normalmente alguien la robó: hay un ladrón, hay un momento concreto y se puede razonar sobre quién tiene acceso a esa clave. Aquí nadie tuvo que robar nada. La clave era efectivamente pública desde el día en que el certificado existió. Cualquiera que haya mirado uno de esos certificados en cualquier momento desde abril de 2025 pudo recuperar la clave en milisegundos con hardware de consumo. Lo resume el investigador Ian Carroll:

"They are inherently weak single-byte keys that anyone can factor, and the issue cannot be contained."

Es una ventana de 17 meses y no hay manera de saber si alguien la aprovechó. Chrome sostiene que, como aplica Certificate Transparency y ningún certificado TLS que encadenara a esas CA apareció en los registros, ningún certificado falsificado podría haber sido aceptado por defecto en Chrome. Es cierto, pero CT detecta la emisión fraudulenta, no la impide, y muchísimo software no consulta CT.

Quién está protegido y quién no

Los navegadores actualizados están bien: Chrome y Firefox bloquean los intermedios directamente y exigen CT; Safari también requiere CT. El resto del ecosistema es otra historia.

La mayoría de los clientes TLS que no son navegadores (curl, Python, Node, Go, Java, git, gestores de paquetes y cada script o demonio de tu infraestructura) hacen tres cosas que aquí importan: confían en un bundle de CA en disco, no comprueban revocación por defecto y no comprueban CT. Que eMudhra y Sectigo hayan revocado los intermedios no les sirve de nada.

Helme lo probó con un certificado propio para api.stripe.com. Con la configuración por defecto, curl respondió "SSL certificate verify ok", Python completó el handshake y Node dijo "authorized: true", en todas las máquinas Linux y macOS que probó. En Windows, CryptoAPI aceptó la cadena salvo que se activara la comprobación de revocación, y aun así solo una de las dos rutas apareció como revocada.

Los escenarios donde esto pega más fuerte, según el propio análisis del incidente:

• Instaladores tipo curl | sh y auto-actualizadores que descargan binarios por HTTPS sin verificar firma (rustup, nvm, el instalador de Homebrew, firmwares de IoT). Un certificado falsificado aquí significa ejecutar el código del atacante, a menudo como root.
• Pipelines de CI/CD. Runners de GitHub y GitLab, Jenkins y contenedores de build que descargan dependencias y publican artefactos mientras sostienen claves de cloud, tokens de registro y claves de firma.
• Llamadas API servidor a servidor. Pasarelas de pago, webhooks, intercambios de tokens OAuth y SDKs de cloud, que llevan secretos y datos de clientes en las cabeceras.
• IoT, embebidos y OT. Cámaras, routers, coches, dispositivos médicos y controladores industriales. Sus bundles quedan congelados hasta julio de 2039, que es la parte literalmente no contenible.
• Firma de código en Windows. Windows confía directamente en la raíz CS de eMudhra, así que el malware firmado con esas CA parece software firmado por un editor real ante cualquier sistema que no revise revocación.

La explicación de eMudhra y el golpe en bolsa

En un comunicado presentado ante la bolsa de Bombay el 21 de octubre, eMudhra atribuyó el fallo a su ceremonia de generación de claves del 30 de abril de 2025: un error en el script de la ceremonia produjo un segundo juego de claves débiles junto a las correctas y, por tener etiquetas parecidas, las débiles fueron las que acabaron seleccionándose para firmar el CSR. La compañía sostiene que su infraestructura no fue comprometida, que no hubo fuga de datos y que el incidente no afecta a sus raíces ni a sus otras CA intermedias. También afirmó que solo uno de los ocho intermedios llegó a producción, que ninguno emitió certificados finales y que el negocio global de TLS representa alrededor del 1% de sus ingresos.

El mercado no lo leyó como un problema menor: las acciones de eMudhra cayeron un 20% en Mumbai el 21 de octubre, según The Hacker News, que cita a Business Standard.

Hay un detalle que debería interesar a cualquier equipo que esté adoptando agentes de IA: Helme confirmó en la actualización de su análisis que le bastó un solo prompt en un agente de IA para recuperar las claves privadas. Lo que antes requería un criptógrafo con tiempo y herramientas ahora es una línea de texto. La barrera de entrada para explotar un fallo de PKI acaba de caer un piso más.

Qué significa esto para tu startup

La lección de negocio no es criptográfica, es operativa. Tu empresa ya no depende solo de que los navegadores de tus clientes estén parchados: depende de que tu stack lo esté. Y hay una asimetría peligrosa: los navegadores reciben las revocaciones empujadas desde el fabricante, sin que nadie haga nada. Tu código no. Tus contenedores, tus runners de CI, tus scripts de despliegue y tus dispositivos de campo siguen confiando en un bundle de certificados que hay que actualizar a mano.

Eso explica por qué un incidente que Google ya contenía el 17 de octubre sigue siendo un riesgo abierto semanas después: el bloqueo llegó a los navegadores en horas, pero a Debian, FreeBSD, Node.js y Bun todavía no había llegado, según el seguimiento del ingeniero de Mozilla Dennis Jackson recogido por BleepingComputer.

Qué hacer ahora, en orden de urgencia

1. Actualiza todos los bundles de CA de tu stack y reconstruye las imágenes. Toca el paquete ca-certificates del sistema operativo, el bundle de curl (2026-10-20), Python certifi (2026.10.19 o superior), Homebrew ca-certificates (2026-09-25_1), pip (26.2.2), uv (0.13.4), Electron (44.9.1, 43.8.1 o 42.11.16) y Elixir castore (1.0.22). En distros, Ubuntu, Alpine, Arch, Gentoo y Chainguard ya tienen versión publicada; Debian y FreeBSD seguían pendientes. Si no reconstruyes la imagen base, el parche no llega a producción.

2. Si tienes servicios en Go, recompílalos. La corrección del equipo de Go (versiones 1.27.3 y 1.26.10, CVE-2026-111943) vive en la librería estándar y rechaza cualquier cadena que contenga una de las ocho claves, incluso en las rutas de verificación del sistema en macOS y Windows. No hay setting para desactivarla, pero solo se aplica cuando el binario se recompila: actualizar sin recompilar no sirve. Y Go 1.25 y anteriores quedan sin corrección.

3. Revisa si algún certificado tuyo encadena a emSign ECC Root CA - G3. Chrome elimina esa raíz en la versión 43 de su root store, y según The Hacker News el cambio llegará a los dispositivos la mañana del martes 27 de octubre (hora del Pacífico). Si tu sitio depende de esa cadena, migra a otra jerarquía antes de esa fecha o tus usuarios verán errores de certificado. eMudhra se comprometió a mover a esos clientes fuera de la raíz.

4. No cuentes con la revocación para los clientes que no son navegadores. El propio mantenedor de criptografía de Go, Filippo Valsorda, señaló en el issue oficial que los almacenes de raíces de Linux están tan mal mantenidos que la revocación no llega a las aplicaciones: por eso la única opción práctica fue meter las claves comprometidas en el código.

5. Trata los dispositivos que no puedes actualizar como red insegura. Routers, impresoras, cámaras y electrodomésticos con firmware congelado seguirán confiando en esos certificados hasta julio de 2039. Si tienes hardware en campo, aíslalo en una VLAN segmentada y asume que el canal TLS de esos equipos ya no es confiable.

6. Añade una prueba de humo a tu CI. Levanta un servidor local con un certificado emitido por una de las ocho claves y comprueba que tus clientes rechazan la conexión. Si alguno la acepta, sabes exactamente qué componente te falta parchear. Helme publicó los endpoints de prueba y las instrucciones de mitigación junto a su análisis.

Conclusión

Ocho bits. Durante 17 meses, eso fue todo lo que separó a una enorme cantidad de software no-navegador de un certificado falsificado para cualquier sitio. La parte incómoda no es el error humano en una ceremonia con HSM: es que el modo de fallo era invisible para todas las validaciones estructurales y que la mayoría de la infraestructura de una startup no tiene forma de enterarse de una revocación. Si tu equipo tiene un inventario de dependencias y un proceso de reconstrucción de imágenes, este episodio es solo una tarea más del sprint. Si no lo tiene, acabas de encontrar el motivo para construirlo.

Fuentes

• Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds
• Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software
• Mozilla, Google, Apple block compromised eMudhra CA certificates