viernes, 30 de octubre de 202623°General Pico · 10° / 25°Dólar Oficial $1.560Dólar Blue $1.565Dólar MEP $1.568Dólar Tarjeta $2.028
Las claves de la certificadora eMudhra eran tan débiles que se quebraron en milisegundos
Un investigador detectó que ocho certificados intermedios de eMudhra tenían claves privadas casi triviales, lo que permitió recuperarlas en fracciones de segundo. Los navegadores principales ya los bloquearon, pero muchos programas que no revisan esos bloqueos siguen expuestos.
Redacción Pico Tecno
· Actualizada 22 de octubre de 2026 a las 18:04
3 min de lectura
(Nikhil Agrawal / Wikimedia Commons · CC BY-SA 4.0)
Según informó scotthelme.co.uk, un investigador de seguridad reportó el sábado 17 de octubre a Apple, Google, Microsoft, Mozilla y eMudhra que las claves privadas de ocho certificados intermedios de esa empresa estaban comprometidas. Los certificados intermedios forman parte de la cadena que permite validar la identidad de un sitio web o de un software firmado, por lo que su clave privada es un secreto crítico.
Chrome bloqueó los certificados esa misma noche mediante una actualización de su lista CRLSet, y Firefox lo hizo horas después a través de OneCRL. El martes 20, Mozilla hizo el anuncio público, publicó una actualización de NSS que elimina el certificado raíz de eMudhra y Google confirmó que ese certificado raíz también saldrá del almacén de Chrome en la versión 43.
De los ocho certificados, seis son de emisión TLS, en sus variantes DV, OV y EV, con dos generaciones cada una, y dos son de firma de código. Todos fueron creados en abril de 2025 y, en mayo del mismo año, Sectigo los firmó de forma cruzada con su certificado raíz AAA Certificate Services.
El punto más llamativo es cómo se pudieron recuperar las claves. Las claves usan la curva elíptica P-384, en la que la clave privada es un número y la clave pública se obtiene a partir de él mediante una operación matemática que es fácil de hacer en un sentido, pero impracticable de revertir. Esa seguridad depende de que el número sea enorme y aleatorio. En este caso, las claves eran números muy pequeños: el autor encontró valores como 4, 56 y 115. Con números así, basta probar unas pocas opciones para dar con la clave, y el autor recuperó las ocho en menos de un segundo desde su notebook, usando los certificados públicos.
Quiénes quedan expuestos
Como las claves se podían calcular a partir de datos públicos, cualquier persona que hubiera visto esos certificados desde abril de 2025 podría haberlas obtenido. Según el autor, eso representa una ventana de unos 17 meses, y no hay forma de saber si alguien lo hizo. A diferencia de otros incidentes, aquí no hubo un robo con un momento preciso ni un responsable identificable.
Chrome señaló que, como exige Certificate Transparency (un registro público de certificados emitidos), no aparecieron certificados TLS de esas cadenas, por lo que no habría certificados falsos aceptados por defecto en ese navegador. Sin embargo, Certificate Transparency detecta emisiones indebidas pero no las impide, y muchos programas no la verifican. En los navegadores actualizados, el riesgo parece bajo.
La preocupación mayor está en el software que no es navegador. Herramientas como curl, Python, Node, Go, Java o git suelen confiar en un conjunto de certificados raíz guardado en el equipo, no verifican la revocación por defecto y tampoco revisan Certificate Transparency. Por eso, la revocación de esos certificados no les sirve de nada. El autor probó con un certificado falso para api.stripe.com en equipos Linux y macOS, y curl, Python y Node aceptaron la conexión con la configuración predeterminada. En Windows, el sistema solo rechazó la cadena cuando se activó la verificación de revocación, y aun así en una de las dos rutas.
Según el autor, quien tiene una conexión en la red podría interceptar el tráfico de un dispositivo con ese certificado falso para cualquier nombre de dominio. Los equipos que se pueden actualizar tienen una solución sencilla, pero el problema está en los dispositivos que no se pueden actualizar o que son difíciles de actualizar.
Por último, el autor actualizó su nota al informar que eMudhra explicó en el ticket público de Mozilla que un error en el script usado durante la generación de claves creó un segundo par de claves débil en el HSM (módulo de seguridad de hardware), y que, por nombres similares, se usaron las claves equivocadas para la solicitud de firma. El autor aclaró que esa información no modificó lo escrito en su artículo.
