El 17 de octubre de 2026, un investigador de seguridad independiente encontró algo que no debería ser posible: una clave privada de una autoridad certificadora —una de las entidades en las que tu navegador confía ciegamente para validar que un sitio web es quien dice ser— cuyo valor secreto era, literalmente, el número 4.
No era la única. En total eran ocho claves, generadas por la autoridad certificadora india eMudhra en abril de 2025, todas con el mismo defecto estructural. Chrome y Firefox las bloquearon el mismo día en que se reportó el hallazgo.
Por qué una clave como «4» es catastrófica
Las claves afectadas eran de curva elíptica (ECDSA, curva P-384) —no RSA—, un detalle que importa porque cambia por completo la forma en que la clave privada queda expuesta. En ECDSA, la clave privada es un número d, y la clave pública se calcula multiplicando ese número por un punto fijo de la curva: d × G. Calcular la clave pública a partir de d es trivial; el problema inverso —recuperar d a partir de la clave pública— es, en teoría, computacionalmente imposible, siempre que d sea un número aleatorio grande, del orden de 2³⁸⁴.
El defecto en las ocho claves de eMudhra es que d no era un número de 384 bits: era un número de apenas un par de bytes —4, 56, 66, 115, 155, 156, 230 y 237, según los reportes técnicos—. Con un valor así de pequeño, un atacante no necesita romper ninguna matemática: simplemente prueba 1 × G, 2 × G, 3 × G… hasta que el resultado coincide con la clave pública del certificado, que es información completamente visible para cualquiera. El investigador que encontró el fallo recuperó las ocho claves en menos de un segundo, en una laptop corriente.
Lo más inquietante no es la facilidad del cálculo, sino que una clave con
d=4es, en todos los sentidos formales, un punto válido de la curva. No hay ninguna comprobación estándar que la distinga de una clave generada correctamente. La única forma de saberlo es intentar romperla.
Qué estaba realmente en riesgo (y qué no)
Aquí vale la pena ser preciso, porque la forma más común de resumir este incidente —»una clave se podía descifrar en menos de un segundo»— da una idea equivocada de lo que estaba en juego. Estas no eran claves usadas para cifrar datos de nadie. Eran claves de CA intermedias: el mecanismo que una autoridad certificadora usa para firmar certificados de sitios web.
Quien tuviera esa clave privada no podía «descifrar» tráfico ya existente. Podía, en cambio, forjar certificados válidos para cualquier dominio —incluyendo bancos, correo, lo que fuera— que cualquier navegador aceptaría como legítimos sin ninguna advertencia. Combinado con una posición de intermediario en la red (una red Wi-Fi comprometida, un proveedor malicioso, un Estado con capacidad de intercepción), esa capacidad sí permite interceptar y descifrar tráfico que de otro modo estaría protegido — pero el paso crítico es la falsificación del certificado, no un ataque directo contra el cifrado de los datos.
Cómo ocurrió, según eMudhra
Según el relato de la propia empresa, un error en el script usado durante la ceremonia de generación de claves en abril de 2025 produjo, sin que nadie lo notara, un segundo conjunto de claves defectuosas dentro del HSM (el módulo de hardware donde se generan y custodian este tipo de claves). Por una coincidencia en los nombres asignados, ese segundo conjunto —el débil— fue el que terminó usándose para firmar los certificados, en lugar del conjunto generado correctamente. Algunas de esas claves fueron además enviadas a Sectigo para obtener una firma cruzada, duplicando la exposición.
Cronología de la respuesta
- Abril de 2025: se generan las ocho CA intermedias defectuosas. Quedan públicamente expuestas desde este momento — cualquiera que examinara esos certificados pudo, en teoría, recuperar la clave desde entonces.
- 17 de octubre de 2026: un investigador independiente detecta el problema escaneando certificados públicos y lo reporta a Apple, Google, Microsoft, Mozilla y eMudhra el mismo día. Chrome bloquea los certificados esa misma noche; Mozilla hace lo mismo pocas horas después.
- 19-20 de octubre de 2026: Apple añade sus propias protecciones. Mozilla retira la raíz de eMudhra de Firefox mediante una actualización de NSS; Chrome confirma que hará lo mismo en su Chrome Root Store. eMudhra revoca las ocho CA y detiene la emisión bajo esa raíz.
eMudhra afirma que la mayoría de las CA intermedias afectadas nunca se usaron en producción y que no hay evidencia de que se hayan emitido certificados fraudulentos a partir de ellas. Es una buena noticia, pero con un matiz importante: como la clave era recuperable desde el momento mismo en que el certificado se publicó, no hay forma de confirmar con certeza que nadie la encontró antes que el investigador que finalmente dio la alarma.
La lección de fondo
Ninguna cantidad de infraestructura de confianza —HSM, ceremonias auditadas, cumplimiento de estándares de la industria— sustituye la verificación del resultado final. El sistema diseñado para evitar justamente este tipo de fallo (generación de claves en hardware especializado, bajo procedimientos formales) funcionó como debía en todos los pasos salvo uno: nadie comprobó que la clave que terminó firmando los certificados fuera, de hecho, la clave fuerte. Y el mecanismo que finalmente detectó el problema no fue un control interno de eMudhra, sino la naturaleza pública de los certificados TLS: cualquiera puede examinarlos, y eso es, paradójicamente, lo que hizo posible encontrar el fallo antes de que causara un daño confirmado.