El incidente de eMudhra revela una falla de seguridad fundamental en la generación de claves criptográficas para certificados de autoridad. En lugar de generar claves privadas P-384 aleatorias de 384 bits, eMudhra generó claves de un solo byte (valores como 4, 56, 115). Esto redujo el espacio de búsqueda de 2^384 a 256 posibles valores, haciendo que las claves fueran trivialmente recuperables mediante fuerza bruta en milisegundos. La debilidad no era aparente en la estructura del certificado, ya que las claves públicas derivadas eran matemáticamente válidas en la curva elíptica, pasando todas las comprobaciones estructurales.
La causa raíz se atribuye a un error humano y un bug en el script de generación de claves durante la ceremonia de creación de certificados. Se generaron pares de claves débiles en el HSM, y debido a nombres similares, se seleccionaron las claves incorrectas para las solicitudes de firma de certificados (CSR). Esto subraya la importancia crítica de la validación exhaustiva de la entropía y la aleatoriedad en la generación de claves, especialmente para componentes tan sensibles como las CA.
Las salvaguardas existentes fallaron porque la debilidad no era un compromiso tradicional (robo de clave), sino una debilidad inherente desde el momento de la creación. Los mecanismos de revocación (CRL, OCSP) y Certificate Transparency (CT) son útiles para detectar y mitigar el uso de certificados mal emitidos o comprometidos, pero no previenen la emisión inicial de certificados con claves intrínsecamente débiles. Además, muchos clientes TLS no-navegador (curl, Python, Node, Go, Java, git, etc.) no verifican la revocación por defecto ni utilizan CT, dejando un vasto ecosistema vulnerable a ataques Man-in-the-Middle con certificados forjados.