El 17 de octubre de 2026, un grupo de investigadores reportó de forma simultánea a Apple, Google, Microsoft, Mozilla y a la Autoridad de Certificación (CA) eMudhra una vulnerabilidad crítica: ocho certificados CA intermedios emitidos por eMudhra utilizaban claves privadas que eran simples números enteros de un solo byte: 4, 56, 66, 115, 155, 156, 230 y 237.
Dichos certificados utilizan la curva elíptica P-384. De acuerdo con los estándares criptográficos, una clave privada debe ser un número aleatorio de 384 bits con un espacio de búsqueda aproximado de 3,9 × 10¹¹⁵ posibilidades, donde un ataque por fuerza bruta resulta inviable. Sin embargo, cuando la clave privada toma valores ínfimos como 4 o 56, al atacante le basta con calcular múltiplos sucesivos del punto base (1×G, 2×G… hasta un máximo de 255×G) para reconstruir la clave secreta por completo. El investigador de seguridad Scott Helme tardó menos de un segundo en recuperar las ocho claves privadas correspondientes a 16 certificados usando un portátil corriente.
Impecables en apariencia
La brecha se produjo en el punto ciego de las auditorías automatizadas: aunque estas ocho claves carecían por completo de entropía, su estructura formal era intachable. Al multiplicar el punto generador de la curva P-384 por 4, la clave pública resultante constituye un punto matemáticamente válido sobre la curva, con codificación perfecta, parámetros de curva estándar y verificación positiva de algoritmos de firma. La cadena de certificación, los periodos de validez y las extensiones X.509 eran perfectamente conformes.
Para advertir la anomalía era indispensable probar números enteros pequeños de forma intencionada, una comprobación que no figuraba en las auditorías estándar de las CA. Esa ausencia explica por qué estos certificados comprometidos permanecieron activos en Internet durante 17 meses sin que nadie los detectara.
Los ocho certificados intermedios se emitieron en abril de 2025: seis de ellos destinados a la emisión TLS (dos generaciones para DV, OV y EV respectivamente) y dos para firma de código. En mayo de 2025 recibieron firmas cruzadas de la raíz AAA Certificate Services de Sectigo, elevando a 16 el número de certificados afectados. Su fecha de caducidad fijada era julio de 2039.
Otro detalle revelador provino de las explicaciones oficiales de eMudhra: la entidad aseguró que las claves privadas siempre estuvieron custodiadas dentro de módulos de seguridad de hardware (HSM). De ser cierto, el HSM se limitó a custodiar con total celo una clave cuyo valor era 4: el cumplimiento de normativas de hardware y la calidad de las claves criptográficas son conceptos completamente independientes. La comunidad técnica lo resumió con rapidez: dado que la clave permanecía sellada en el HSM, nadie comprobó jamás su contenido real, pasando por alto que el generador de números aleatorios nunca estuvo funcionando.
Figura: Logotipo de la Autoridad de Certificación eMudhra. Sus ocho certificados intermedios permanecieron expuestos silenciosamente en la red durante 17 meses. Fuente: blog de Scott Helme y web de eMudhra
Certificado para Stripe firmado con clave 4: curl lo dio por bueno
Con las claves privadas al alcance de cualquiera, suplantar identidades se convirtió en una tarea trivial.
Scott Helme utilizó la clave privada 4 para firmar un certificado para el dominio api.stripe.com, levantó una instancia local con openssl s_server e intentó conectar con clientes habituales bajo su configuración predeterminada. Los resultados fueron contundentes: curl en Linux y macOS devolvió SSL certificate verify ok; el handshake TLS de Python culminó sin reparos; Node.js respondió con authorized: true; y la CryptoAPI de Windows aceptó la conexión sin advertencias mientras no tuviera activada una comprobación estricta de revocación.
La diferencia crucial radica en la arquitectura de los almacenes de confianza. Los navegadores web operan bajo un modelo centralizado y con capacidad de actualización remota: Chrome introdujo los certificados afectados en su lista CRLSet la misma noche del 17 de octubre, y Mozilla hizo lo propio horas después mediante OneCRL. El 20 de octubre Mozilla publicó un boletín oficial y eliminó las raíces de eMudhra de NSS, medida que Chrome secundó al retirarlas de su Root Store v43. Además, el mecanismo obligatorio de Certificate Transparency (CT) permitió confirmar que no se habían registrado certificados fraudulentos en los registros públicos, protegiendo la navegación web cotidiana de ataques directos.
Las herramientas de línea de comandos, los SDK de servidores y los dispositivos IoT dependen, en cambio, de una lógica muy distinta: sus almacenes de confianza son paquetes estáticos distribuidos con el software. Rara vez consultan listas de revocación (CRL u OCSP) por defecto y omiten por completo los registros CT. En tales entornos, certificados que ya están revocados en los navegadores continúan considerándose credenciales legítimas.
Figura: El colapso de la cadena de confianza digital no residió en las matemáticas de la curva, sino en el proceso de generación de la clave. Fuente: Ars Technica
La revocación solo protegió a los navegadores
Analizar el radio de impacto permite dimensionar la magnitud y duración del riesgo.
Los scripts de instalación mediante curl | sh (como rustup, nvm o Homebrew), al depender de la verificación HTTPS, permitirían que un atacante en posición privilegiada suplantara el origen e introdujera binarios maliciosos con permisos de administrador en terminales de desarrollo. Los entornos de CI/CD presentan un peligro aún más delicado: los contenedores de GitHub Actions, GitLab Runner o Jenkins concentran credenciales de plataformas en la nube y secretos de despliegue, en máquinas donde nadie suele actualizar los almacenes de certificados a mano. La comunicación entre microservicios (pasarelas de pago, webhooks, flujos OAuth) que utiliza las imágenes base de los contenedores queda igualmente expuesta. A ello se suma la firma de código en Windows: cualquier binario firmado fraudulentamente con los certificados comprometidos de eMudhra será tratado como software fiable en sistemas que no comprueben activamente el estado de revocación.
El criptógrafo Filippo Valsorda advirtió que el volumen de saneamiento posterior podría superar al de Heartbleed: servidores Linux desatendidos, imágenes de contenedores sin mantenimiento y utilidades CLI con copias locales obsoletas de certificados raíz formarán una larga estela de vulnerabilidad. Ben Cartwright-Cox sugirió que fragmentos de código de ejemplo pudieron colarse inadvertidamente en producción, remarcando la gravedad de que ninguna auditoría lo detectara a lo largo de un año y medio. Ian Carroll sintetizó la situación: estas claves de un solo byte están al alcance de cualquiera y, una vez filtradas, resulta imposible retirarlas de circulación por completo.
Una sombra de 13 años
El margen de maniobra de los equipos de operaciones es limitado. En infraestructuras bajo control directo, eliminar los certificados raíz de eMudhra o añadir los intermedios a listas de bloqueo constituye la pauta estándar; los sistemas que usan OpenSSL deben verificar que el paquete de certificados del sistema operativo esté actualizado. La verdadera complicación surge en los sistemas fuera de control: routers domésticos, cámaras de videovigilancia, autómatas industriales, sistemas de infoentretenimiento de vehículos y datáfonos integran almacenes de confianza grabados de fábrica. Si el fabricante ha discontinuado el soporte, la única alternativa es sustituir el dispositivo, mientras que los certificados comprometidos no expirarán de forma natural hasta julio de 2039.
Para quienes diseñan sistemas y productos, el incidente deja una lección concluyente: empotrar una copia estática de certificados raíz ahorra consultas de red durante la validación, pero a costa de cercenar cualquier vía de revocación durante la siguiente década. Confiar la seguridad del sistema a la premisa de que «nadie examinará la clave privada» se desmorona en el instante en que un generador de números aleatorios deja de inicializarse.
Enlaces de referencia:
- Blog técnico de Scott Helme
- Informe del incidente en We Have A Problem
- Reportaje en profundidad de Ars Technica
- Blog oficial de seguridad de Mozilla
- Debate técnico en la comunidad Hacker News
