Compromiso de EMudhra Intermediate CA

Artículo original ↗ Discusión en Hacker News ↗

Una autoridad certificadora india, eMudhra, emitió múltiples certificados intermedios TLS y de firma de código cuyas claves privadas de curva elíptica eran trivialmente adivinables (valores de un solo byte como “4”), lo que en la práctica permitía a cualquiera falsificar certificados para dominios arbitrarios hasta que navegadores y proveedores de sistemas operativos los revocaran. Los comentaristas señalan que los mecanismos de revocación y Certificate Transparency de los principales navegadores limitaron el riesgo para los usuarios web, pero que enormes cantidades de clientes no navegador y dispositivos IoT que incrustan sus propios almacenes de CA pueden seguir siendo vulnerables durante años. El incidente reaviva las críticas al modelo de Web PKI —donde cualquier CA de confianza puede avalar cualquier dominio— y alimenta el debate sobre alternativas como DNSSEC/DANE, restricciones de nombre más estrictas y una infraestructura de revocación más centralizada o auditada.

Descripción del incidente

  • Se descubrió que las claves privadas de ocho CA intermedias de eMudhra/emSign eran trivialmente recuperables.
  • Eran claves ECC P-384 cuyos escalares privados eran enteros diminutos (<256); una clave era literalmente “4”.
  • Las intermedias estaban firmadas cruzadamente por otra CA importante, por lo que encadenaban hasta raíces ampliamente confiables.
  • Las intermedias afectadas cubrían TLS (incluido DV) y al menos dos CA de firma de código confiadas por Microsoft.

Causa raíz técnica (según se discute)

  • El informe de incidente de eMudhra culpa a un fallo en un script de ceremonia de generación de claves usado con HSMs de Ultimaco.
  • Supuestamente las claves normales se generaban dentro del HSM, pero una ruta de prueba de “wrap/unwrap” produjo claves secundarias débiles.
  • Debido a etiquetas similares, el personal usó por error las claves débiles para crear CSRs que luego fueron firmadas tanto por la raíz de eMudhra como por la CA de firma cruzada.
  • Los CRLs se firmaron inicialmente con las claves “correctas”, fallaron la validación y luego se volvieron a firmar con las claves débiles, lo que muchos ven como un fallo importante del proceso.

Impacto en seguridad

  • Cualquiera que tenga los certificados públicos de las intermedias puede derivar las claves privadas y emitir certificados leaf que parecen válidos.
  • Permite MITM indetectable para clientes que:
    • confían en las cadenas afectadas, y
    • no aplican Certificate Transparency (CT).
  • Los navegadores que exigen CT rechazarían el uso indebido no registrado, y no se observaron en los registros de CT certificados leaf previos al incidente de estas intermedias.
  • El TLS fuera del navegador (curl, IoT, VPNs, sistemas embebidos/industriales) está fuertemente expuesto porque muchos no hacen CT y rara vez actualizan los almacenes de confianza.

Revocación y respuesta del ecosistema

  • Los principales navegadores usaron mecanismos centralizados (CRLSet/OneCRL/estilo CRLite) para bloquear rápidamente las intermedias; a menudo los usuarios no necesitaron actualizaciones de software.
  • Los sistemas operativos y las bibliotecas varían: Windows puede bloquear de forma centralizada; Linux/Unix normalmente solo distribuyen paquetes PEM, así que Go, rustls, Homebrew, certifi de Python, Electron, etc. están publicando actualizaciones de emergencia que bloquean por completo las intermedias.
  • Muchos proyectos incrustan sus propios paquetes de CA, lo que hace lenta y desigual la remediación en todo el ecosistema.
  • Algunos usuarios informan de bloqueos inconsistentes en Firefox móvil hasta que se propagan las actualizaciones de CRL.

Debate sobre Web PKI frente a alternativas

  • Crítica fuerte de que cualquier CA de confianza puede emitir para cualquier dominio, haciendo que la seguridad dependa de la CA más débil.
  • Propuestas y contraargumentos:
    • DNSSEC/DANE: los partidarios valoran alinear la autenticación con la jerarquía DNS; los críticos señalan fragilidad operativa, incapacidad de “eliminar” TLDs que se comporten mal y mecanismos de monitorización/expulsión más débiles que Web PKI.
    • Name constraints y CAA: se consideran poco usados o difíciles de desplegar (NCs), y CAA solo limita la emisión, no la aceptación por parte del cliente.
    • Web of trust: algunos argumentan que es más natural para humanos; otros señalan los fracasos históricos de PGP y la aparición de autoridades centrales de facto.
  • Varios comentaristas defienden el modelo de “pena de muerte” de Web PKI: los navegadores pueden expulsar CA, y de hecho lo hacen; no se puede expulsar un TLD de forma práctica.

Consecuencias para eMudhra y las CA

  • Muchos esperan que las raíces de eMudhra sean eliminadas de los principales programas de raíces; se hacen comparaciones con casos pasados de “pena de muerte” para CA.
  • Algunos señalan el papel de eMudhra en ecosistemas de certificados de universidades de EE. UU. a través de una marca relacionada, lo que plantea preocupaciones de cadena de suministro.
  • El incidente destaca debilidades percibidas en la auditoría de CA y en permitir intermedias destinadas a exportación de claves y uso amplio.

Lecciones más amplias (IoT, tooling, trust stores)

  • Los dispositivos IoT y otros que no pueden actualizarse o se actualizan raramente podrían confiar en estas intermedias hasta que expiren (~2039), lo que los convierte en objetivos MITM a largo plazo.
  • Algunos ven un “lado positivo” en un MITM benigno más fácil para la ingeniería inversa de dispositivos endurecidos.
  • El incidente expone el coste de tener muchos trust stores fragmentados y stacks TLS a medida en lugar de un mecanismo de plataforma consistentemente actualizable.
  • Se discuten varias herramientas y proyectos (por ejemplo, upki, overlays de Nix) como formas de mejorar la revocación centralizada y automatizada para software que no es navegador.