Ceremonia de claves fallida de eMudhra dejó ocho claves de CA al alcance de cualquiera

Ocho autoridades de certificación intermedias operadas por eMudhra, de la India, se emitieron con claves privadas que cualquiera podía recuperar a partir de los certificados públicos en bastante menos de un segundo. Lo comunicó el 17 de octubre de 2026 un investigador conocido como «Wayne». Mozilla recibió el informe a las 20:06 UTC, reenviado por el Chrome Root Program. En unas dos horas, Mozilla recuperó las claves por su cuenta y sin conocer el método del investigador. Eso confirmó que el problema estaba en la generación de claves y que era trivial de explotar.

La causa no fue una intrusión. Según el relato de eMudhra, se trató de un script defectuoso ejecutado durante una ceremonia de claves, y los controles humanos no lo detectaron.

01Qué tan débiles eran las claves

Eran claves de curva elíptica P-384. Una clave privada bien generada es un número extraído de un espacio de aproximadamente 2^384 valores. Según el informe de incidente de Mozilla, las ocho claves tenían valores inferiores a 256, de modo que a un atacante le bastaba probar 256 candidatos. Las claves eran 4, 56, 66, 115, 155, 156, 230 y 237. La clave privada de «EM OV TLS CA - G3C» era simplemente 4.

Como la clave pública de curva elíptica es el escalar privado multiplicado por el punto base de la curva, un escalar menor que 256 se puede encontrar calculando unos cientos de múltiplos de ese punto. Después basta una comparación con la clave pública del certificado. Esa es la inferencia detrás de los tiempos de recuperación inferiores a un segundo que se han comunicado. Ars Technica sitúa el tamaño efectivo de las claves entre 3 y 8 bits. Un análisis de un proveedor habla de «bytes», lo cual no concuerda con los valores de las propias claves.

La clave de una CA intermedia puede firmar cualquier certificado de entidad final que encadene con la raíz superior. Un atacante con una de estas claves podría falsificar un certificado para cualquier dominio y suplantar servidores para interceptar o modificar el tráfico. Aun así, la explotación requiere una posición activa de adversario en el medio, como señala Ars. Es una barrera alta para algunos atacantes, pero fácil de superar para quien controle una red local.

El alcance importa. Las ocho claves provenían de un lote de 24 intermedias generadas el 30 de abril de 2025. Seis emiten certificados TLS y dos son de firma de código, y Sectigo firmó de forma cruzada las ocho en mayo de 2025. Contando las firmas cruzadas, resultaron afectados 16 certificados.

02Qué falló en la ceremonia

Una ceremonia de claves es el procedimiento guionizado y presenciado en el que una CA genera sus claves más sensibles dentro de módulos de seguridad de hardware (HSM). eMudhra afirma que en la ceremonia se usaron HSM FIPS 140-2 Nivel 3. Su declaración actualizada subraya que el fallo estuvo en un paso del procedimiento, no en la ausencia de HSM.

El relato en Bugzilla da la secuencia:

• La ceremonia creó, en el interior del HSM, los pares de claves ECC robustos previstos.
• Una desviación aprobada añadió una prueba de wrap/unwrap (envolver/desenvolver), porque en este caso las claves estaban pensadas para exportarse. El wrapping cifra una clave bajo otra para poder trasladarla entre HSM.
• Un fallo de código creó además, en el interior, un segundo par de claves débil.
• Las etiquetas del par débil se parecían a las de los originales, por lo que se usó por error para construir las solicitudes de firma de certificado (CSR), que la raíz firmó.
• Las mismas CSR se enviaron a Sectigo para su firma cruzada.

Nada en esta cadena exigió que fallara el hardware criptográfico. El HSM generó una clave defectuosa cuando se le pidió, y una persona o un proceso eligió la equivocada. La propia empresa admite que un error de script dio lugar a CA emisoras con claves débiles. También reconoció errores humanos en varios pasos y prometió volver a verificar todas las ceremonias de claves que ha realizado. Eso apunta a la falta de controles de doble verificación (maker/checker). Nadie comparó las claves públicas que se certificaban con las que la ceremonia debía producir, y nadie comprobó el tamaño ni la aleatoriedad de la clave antes de que la raíz firmara.

03La advertencia que se pasó por alto

El detalle más incómodo es un precedente de 2025. Las preguntas de Mozilla a eMudhra se refieren al Bug 1970728, de junio de 2025. En él, la clave usada para firmar ciertas CRL no coincidía con la clave pública del certificado de CA correspondiente. eMudhra localizó el segundo par de claves, que sí coincidía, y volvió a firmar las CRL con él. No detuvo las operaciones para preguntarse por qué existían dos pares. Una CRL es la lista firmada de certificados revocados que publica una CA. Una CA cuya CRL no supera la verificación tiene, por definición, un problema de integridad de claves.

Según la explicación posterior de eMudhra, las CRL se firmaron primero con las claves robustas originales. Esas firmas fallaron porque los certificados se habían emitido sobre las claves débiles, así que las CRL se volvieron a firmar con las defectuosas. Un proveedor de avisos de amenazas afirma que el fallo sobrevivió unos 17 meses y dos ciclos de auditoría. Es una afirmación secundaria y no he verificado los detalles de las auditorías. Sea cual sea el registro de auditoría, el incidente de 2025 ofrecía una vía de diagnóstico que habría dejado al descubierto el problema, y se cerró como un error de configuración.

Descubrirlo salió barato. Los informes describen al investigador analizando el corpus de la CCADB de intermedias de confianza pública, y un relato dice que se usaron las comprobaciones de código abierto paranoid_crypto de Google. Analizar certificados públicos en busca de claves débiles es una técnica antigua. Nada indica públicamente que hiciera falta algo exótico.

04La revocación, y por qué no fue el final

La contención en el parque de navegadores fue rápida. Chrome distribuyó una actualización de CRLSet y Mozilla publicó entradas en OneCRL el 17 de octubre, sin necesidad de reiniciar el navegador. eMudhra revocó las ocho intermedias el 18 de octubre (motivo: caCompromise). Sectigo revocó los certificados de firma cruzada el 19 de octubre. Apple y Microsoft siguieron en los días posteriores, con algunos informes que difieren en uno o dos días en las fechas exactas. La primera información de Ars Technica, que hablaba de uno o dos días para los bloqueos en navegadores, es más lenta que la cronología primaria. Ars también señaló que Edge en Windows 10 seguía conectándose a hosts vulnerables en el momento de la publicación. Microsoft no dio más detalles.

El problema más difícil son los clientes que no consumen datos de revocación. Mozilla decidió retirar de forma urgente la confianza en la raíz madre, emSign ECC Root CA - G3, para proteger a los clientes que ignoran la información de revocación o no pueden retirar la confianza en intermedias concretas. Chrome dijo que haría lo mismo. Según los informes, la retirada en Chrome llegará a todos los dispositivos el 27 de octubre, que es hoy. Las correcciones de Mozilla para Go y NSS se publicaron el 20 de octubre.

Filippo Valsorda, mantenedor de criptografía de Go, dijo a Ars que la limpieza tendría una cola muy larga. Mencionó dispositivos IoT, contenedores, máquinas Linux olvidadas y herramientas que incluyen sus propios almacenes de raíces, y la comparó con Heartbleed por su magnitud. Esa comparación es una valoración suya y sigue sin demostrarse. Cloudflare, por su parte, informó de que las claves eran de confianza dentro de su propia infraestructura y publicó actualizaciones de cliente.

La retirada de confianza tiene un coste colateral. Los datos de Certificate Transparency a 21 de octubre mostraban unos 30 800 precertificados sin caducar encadenados a la raíz sin confianza. eMudhra estimó que cerca del 97 % se emitió mediante ACME. La empresa está migrando a sus suscriptores a su jerarquía RSA G1. Algunos de esos certificados son legítimos y ahora deben sustituirse por un fallo ajeno a ellos, ocurrido más arriba en la cadena.

05Detección y lo que revela sobre la supervisión

Si alguien abusó de las claves no está del todo aclarado, pero las pruebas hasta ahora son tranquilizadoras. Ars informó de que no hay indicios en los registros de transparencia de un uso malicioso. Un relato secundario dice que Google no halló certificados TLS encadenados a las seis intermedias registrados antes de bloquearlas. Red Sift encontró un puñado registrados tras la divulgación, procedentes de investigadores que probaban las claves recuperadas. eMudhra afirma que solo una intermedia se puso en producción y que ninguna emitió certificados de clientes. Los registros de transparencia solo detectan los certificados que se registran, y los clientes que no exigen CT podrían haber recibido falsificaciones sin registrar. Ese riesgo residual no puede descartarse, y varios analistas lo señalan.

Destacan tres lecciones:

1. Las auditorías muestrean procesos, no resultados. Una ceremonia que supera una lista de verificación presenciada puede igualmente certificar la clave equivocada. Una comprobación mecánica de que la clave pública certificada coincide con la prevista del HSM, junto con una comprobación de entropía mínima, lo habría detectado.
2. Las anomalías exigen un análisis de causa raíz. La discrepancia de la CRL en 2025 fue una señal gratuita. Las preguntas publicadas por Mozilla apuntan directamente a por qué se tapó.
3. La revocación vale lo que valga su distribución. Los navegadores pueden bloquear en horas. Todo lo demás exige actualizaciones de software, y retirar la confianza en una raíz entera es el instrumento contundente que alcanza la cola larga.

El consejo de administración de eMudhra anunció el jueves que abandonará el negocio global de TLS. El presidente citó los costes de cumplimiento y una línea de negocio que genera alrededor del 1 % de los ingresos. La empresa sigue revisando sus ceremonias de claves y el análisis de causa raíz está incompleto. Las decisiones de Chrome y Mozilla sobre su raíz RSA restante también están pendientes. Faltan los registros completos de la ceremonia, la diferencia de código (diff) y una explicación de por qué no se dio seguimiento a la anomalía de 2025. Eso mostraría si se trató de un script defectuoso o de un entorno de control incapaz de detectar una clave privada de un solo byte.