Claves de CA de eMudhra comprometidas por una generación de claves privadas críticamente débil

El 17 de octubre de 2026, un investigador de seguridad informó a las principales empresas tecnológicas que las claves privadas de ocho certificados intermedios de eMudhra habían sido comprometidas. La vulnerabilidad se originó en una extrema debilidad en la generación de claves, donde las claves privadas eran efectivamente enteros de un solo byte. Para el 20 de octubre, Mozilla y Google anunciaron públicamente la revocación de estos certificados y eliminaron la confianza en las autoridades raíz asociadas.

Qué ocurrió

El incidente involucra ocho certificados intermedios emitidos por eMudhra, creados en abril de 2025. Estos incluían seis certificados emisores TLS para Validación de Dominio (Domain Validation), Validación de Organización (Organization Validation) y Validación Extendida (Extended Validation), así como dos certificados de firma de código. Los ocho intermediarios también fueron firmados cruzadamente por la raíz AAA Certificate Services de Sectigo en mayo de 2025. Al recibir el informe, Chrome desplegó una actualización de CRLSet para bloquear los intermediarios ese mismo día, mientras que Mozilla los bloqueó en Firefox mediante OneCRL poco después.

Para el martes 20 de octubre, Mozilla publicó un anuncio público y envió una actualización de NSS que eliminaba por completo la raíz de eMudhra. Google confirmó que la raíz de eMudhra sería eliminada del Chrome Root Store en la versión 43. El problema central no fue un robo de claves en el sentido tradicional, sino un fallo en el proceso de generación que hacía que las claves privadas fueran trivialmente fáciles de derivar a partir de los certificados públicos.

Se encontró que las claves privadas de estos certificados eran números increíblemente pequeños, como 4, 56 y 115. En la criptografía de curva elíptica, específicamente en la curva P-384 utilizada aquí, la clave privada es un número aleatorio grande. La seguridad del sistema depende de que este número sea suficientemente grande para hacer imposible la fuerza bruta. Sin embargo, las claves de eMudhra consistían principalmente en ceros seguidos de un único byte no nulo. Esto reducía el espacio de búsqueda a solo 256 posibilidades, permitiendo a cualquiera con acceso al certificado público recuperar la clave privada en milisegundos en hardware estándar.

Detalles clave

• Ocho certificados intermedios fueron comprometidos, incluidos seis para TLS y dos para firma de código.
• Las claves privadas eran valores de un solo byte, como 4, 56 y 115, en lugar de los números aleatorios de 384 bits requeridos.
• La recuperación de las claves privadas desde los certificados públicos tomó menos de un segundo en hardware comercial.
• Los certificados afectados fueron creados en abril de 2025 y firmados cruzadamente por Sectigo en mayo de 2025.
• Navegadores principales como Chrome y Firefox han revocado la confianza, pero muchos clientes que no son navegadores siguen siendo vulnerables.
• La ventana de exposición abarca desde abril de 2025 hasta la revocación en octubre de 2026, sin forma de determinar si las claves fueron explotadas.

Contexto

Para entender la gravedad, ayuda saber cómo funciona la criptografía de curva elíptica. Una clave privada es un número secreto, a menudo denotado como d. La clave pública, que se comparte abiertamente en los certificados, se deriva multiplicando este número secreto por un punto fijo en la curva. Mientras que calcular la clave pública a partir de la privada es fácil, invertir el proceso para encontrar la clave privada a partir de la pública es computacionalmente inviable si la clave privada es grande y aleatoria.

Para las curvas P-384, la clave privada debería ser un número de 384 bits, ofreciendo aproximadamente 10¹¹⁵ combinaciones posibles. Este vasto espacio de búsqueda garantiza la seguridad. Sin embargo, si la clave privada es pequeña, como un solo byte, solo hay 256 valores posibles. Un atacante simplemente puede probar cada valor hasta encontrar el que coincide con la clave pública. Esto es lo que ocurrió con las claves de eMudhra, haciendo inútil la protección criptográfica.

Por qué importa

Aunque los navegadores modernos como Chrome, Firefox y Safari están protegidos porque aplican la Transparencia de Certificados (Certificate Transparency) y actualizan rápidamente sus listas de bloqueo, el ecosistema más amplio está en riesgo. Muchas aplicaciones que no son navegadores, incluidas herramientas de línea de comandos como curl, entornos de ejecución de lenguajes de programación como Python y Node.js, y gestores de paquetes, no verifican los registros de Transparencia de Certificados ni las listas de revocación por defecto. Dependen de almacenes de confianza locales que pueden no actualizarse inmediatamente.

Esto crea un riesgo significativo para las comunicaciones servidor a servidor, los pipelines de CI/CD y los dispositivos IoT. Por ejemplo, un script que descargue actualizaciones sobre HTTPS utilizando un paquete de certificados obsoleto podría aceptar un certificado falsificado firmado con las claves comprometidas de eMudhra. Esto permitiría a un atacante interceptar tráfico, inyectar código malicioso o robar datos sensibles. Dispositivos con firmware congelado, como routers y electrodomésticos inteligentes, podrían seguir confiando en estos certificados inválidos hasta que su hardware sea reemplazado o actualizado manualmente, posiblemente dentro de años.

Qué puedes hacer

• Actualiza los paquetes de certificados de CA en todos los servidores, estaciones de trabajo e imágenes de contenedor inmediatamente.
• Busca actualizaciones para entornos de ejecución de lenguajes como Python, Node.js y Go, que a menudo incluyen sus propios almacenes de certificados.
• Revisa los pipelines de CI/CD para asegurar que usen imágenes base actualizadas y verifiquen estrictamente la validez de los certificados.
• Identifica dispositivos IoT y embebidos que no puedan actualizarse fácilmente y evalúa el riesgo de que confíen en CAs comprometidas.
• Habilita la comprobación estricta de revocación de certificados donde sea posible, aunque ten en cuenta que muchos clientes no la soportan por defecto.
• Monitoriza cualquier actividad inusual en sistemas que dependan de conexiones TLS a servicios externos.