Claves débiles de eMudhra: 5 mitos de PKI, desmentidos

La clave privada de una de las autoridades de certificación de eMudhra es el número 4. No un número de 384 bits que empieza por 4, sino simplemente 4, con 47 bytes a cero rellenando el resto para que parezca respetable. Es un fallo en la generación de claves de una CA de un tipo que yo habría dicho que era imposible, y sobrevivió a auditorías, a la certificación cruzada de Sectigo y a diecisiete meses en infraestructura casi en producción, hasta que alguien probó lo obvio: un ataque de fuerza bruta a un solo byte. Estos son cinco mitos sobre PKI que este incidente destruye por completo.

Mito 1: «Un certificado estructuralmente válido es un certificado seguro»

Cada comprobación automatizada del pipeline decía que estos certificados estaban bien. Y tenían razón, en un sentido estrecho e inútil. La clave pública correspondiente a d = 4 es un punto perfectamente válido en la curva P-384. La codificación ASN.1 se parsea. La firma se verifica. La cadena se construye. Todas las herramientas de linting, todos los validadores estructurales y todas las listas de cumplimiento que revisan un certificado y confirman que está bien formado lo aprobarán, porque lo está.

Ahí está la trampa. La validación estructural responde a la pregunta «¿es este un certificado correctamente formateado?». No responde a «¿se generó bien la clave que contiene?». En las claves de curva elíptica, son propiedades casi totalmente independientes. La clave privada es solo un escalar d; la clave pública es d × G, donde G es el punto generador de la curva. Todo el argumento de seguridad es que recuperar d a partir del punto público exige resolver el problema del logaritmo discreto, pero solo si d se eligió del espacio completo de 384 bits. Si eliges d de 8 bits, el problema «imposible» se convierte en un bucle de como mucho 255 iteraciones.

Nada del certificado resultante insinúa esto. El punto público derivado de d = 4 parece tan aleatorio como uno derivado de una clave generada correctamente. No puedes detectarlo a simple vista ni encontrarlo con un linter. La única forma de saberlo es probar valores pequeños y patrones débiles conocidos, que es exactamente lo que ocurrió: el reportero ejecutó la suite de pruebas paranoid_crypto de Google contra el corpus de la Common CA Database, tal cual, y obtuvo un resultado. Una comprobación que tarda milisegundos en un portátil, contra claves que anclan la confianza de navegadores reales.

Así que la primera lección: la validez es necesaria, pero ni de lejos suficiente. Si tus pruebas de PKI se detienen en «el certificado se parsea y encadena», estás probando el sobre e ignorando la carta.

Mito 2: «Los requisitos base y las auditorías detectan errores en la generación de claves»

Las CA operan bajo los Baseline Requirements del CA/Browser Forum y se auditan según los criterios WebTrust o ETSI. Hay documentación de ceremonias, requisitos de HSM y requisitos de longitud de clave. Las claves de eMudhra tenían la longitud correcta: 384 bits sobre el papel. La brecha de la auditoría está en que el cumplimiento verifica la representación de la clave, no la entropía del proceso que la produjo. Una clave rellenada con 47 bytes a cero sigue ocupando 48 bytes en disco.

Según la propia explicación de eMudhra, publicada en el ticket de incidencia de Mozilla, la causa raíz parece una comedia negra: un error en el script de la ceremonia generó un segundo par de claves débil en el HSM; los dos pares tenían nombres parecidos; una persona eligió el incorrecto para la CSR. Tres fallos separados (un error de script, una colisión de nombres y un error de selección), y en ningún momento ningún control preguntó «¿esta clave realmente tiene la entropía por la que pagamos al HSM?».

Esta es la parte que debería preocupar a cualquier ingeniero que gestione su propia PKI interna. Si una CA con confianza pública, con los programas raíz respirándole en la nuca y auditorías en el calendario, puede distribuir una clave privada igual a 4, ¿qué hay dentro de tu backend PKI de Vault o de tus plantillas de Active Directory Certificate Services? La solución es barata y no hay excusa para no aplicarla. Después de generar cualquier clave, y antes de firmar nada con ella, pásala por paranoid_crypto o, como mínimo, por una comprobación de cordura trivial:

from cryptography.hazmat.primitives.asymmetric import ec
CURVE_ORDER_BITS = 384
def sanity_check_private_key(key: ec.EllipticCurvePrivateKey) -> None:
d = key.private_numbers().private_value
# Reject keys whose effective entropy is far below the curve size.
# A healthy P-384 key should have a bit length close to 384.
if d.bit_length() < CURVE_ORDER_BITS - 32:
raise ValueError(
f"Suspiciously small private scalar: {d.bit_length()} bits"
)
# Also reject known bad values outright.
if d < 2**16:
raise ValueError("Private scalar is trivially brute-forceable")

Treinta segundos de trabajo. Habría detectado cada una de las ocho claves de eMudhra. Las auditorías verifican que los procesos existen; no verifican que los procesos funcionaron un martes cualquiera de abril. Solo las pruebas sobre la salida hacen eso.

Mito 3: «Una clave de CA comprometida puede contenerse»

Cuando una clave de CA está «comprometida» en el sentido habitual, hay un ladrón. Alguien extrajo la clave en un momento concreto, y puedes razonar sobre el radio de impacto: certificados emitidos después del robo, por partes que tienen la clave robada. Feo, pero acotado. Ya escribimos sobre lo que pasa cuando el compromiso de una CA intermedia rompe una cadena de confianza, y el manual estándar (revocar, retirar la confianza, reemitir) asume un antes y un después.

Este incidente no tiene antes ni después. La clave era efectivamente pública desde el momento en que se creó el certificado, porque cualquiera que lo mirara podía recuperarla en milisegundos. No hay un evento de robo que acotar. La ventana es toda la vida útil de los certificados, desde abril de 2025 en adelante, y no hay forma de saber quién, si alguien, cruzó la puerta abierta. La afirmación de eMudhra de que las intermedias no emitieron certificados de entidad final, corroborada por los registros de Certificate Transparency, es genuinamente tranquilizadora en cuanto a lo que esas CA hicieron. No dice nada sobre lo que alguien con d=4 podría haber hecho de forma oportunista en una ruta de red.

Peor aún, la respuesta no puede llegar del todo. Chrome y Firefox bloquearon las intermedias en cuestión de horas mediante CRLSet y OneCRL, y ambos exigen registro en CT, así que los certificados TLS falsificados nunca habrían sido válidos en esos navegadores de todos modos. Muy bien. Pero esa protección termina en la frontera del navegador, lo que nos lleva al siguiente mito.

Mito 4: «Si los navegadores están seguros, el ecosistema está seguro»

Los navegadores son el mejor escenario en el ecosistema TLS, y son una minoría de los clientes TLS que te importan operativamente. Piensa en lo que realmente hace conexiones HTTPS en tu infraestructura: curl, requests de Python, Node, binarios de Go, servicios Java, git, gestores de paquetes y SDK de la nube. Estos clientes comparten tres rasgos que se combinan mal aquí: confían en un paquete de CA en disco, no comprueban la revocación por defecto y no comprueban Certificate Transparency. Las tres protecciones que salvaron a los usuarios de Chrome están ausentes.

Scott Helme lo demostró de forma concreta: con un certificado falsificado para api.stripe.com encadenado a una de las intermedias débiles de eMudhra, el curl por defecto mostró SSL certificate verify ok, Python completó el handshake, Node informó de que la conexión estaba autorizada y Windows CryptoAPI aceptó la cadena. En todas las máquinas Linux y macOS probadas. Un certificado falso para cualquier nombre de host, aceptado por las herramientas por defecto en las que se basan tus scripts de despliegue y tus runners de CI. Eso no es un problema del navegador; es un problema de tu infraestructura.

El mapa de exposición es peor de lo que imaginan la mayoría de personas:

• Instaladores curl | sh y autoactualizadores. rustup, nvm, el instalador de Homebrew e incontables páginas de «install.sh». Un certificado falso aquí significa ejecutar código del atacante, frecuentemente como root.
• Pipelines de CI/CD. Los runners descargan dependencias y suben artefactos mientras tienen credenciales de la nube y claves de firma, a menudo en imágenes base desactualizadas.
• Tráfico servidor a servidor. Webhooks de pagos, intercambios de tokens OAuth y llamadas de SDK de la nube que llevan secretos en las cabeceras.
• Dispositivos IoT y embebidos. Firmware congelado con paquetes de CA que no cambiarán hasta que los certificados caduquen, en julio de 2039.
• Firma de código en Windows. Dos de las ocho claves débiles pertenecían a CA de firma de código; el malware firmado con ellas parece software de un editor legítimo.

El consejo práctico es aburrido y correcto: actualiza todo lo que incluya un paquete de CA. El paquete ca-certificates de tu sistema operativo, certifi, Node y Homebrew, y reconstruye tus imágenes de contenedor una vez que las imágenes base incorporen la desconfianza, porque las capas tienen memoria. La parte que no puedes accionar es el dispositivo que no puedes actualizar. Ese smart TV confiará en una clave igual a 4 durante otra década y media. Si necesitabas un argumento más para segmentar en red tus dispositivos IoT, este es el definitivo.

Mito 5: «Alguien ya debe estar revisando esto»

La frase más discretamente condenatoria del incidente vino del reportero: el descubrimiento llegó al ejecutar paranoid_crypto contra el corpus de CCADB como una prueba rápida del corpus antes de pasar a los certificados de suscriptores. La fruta al alcance de la mano. Las propias palabras del reportero: «La mayor parte de mi tiempo se fue en repasar lo básico que todos asumían que alguien más ya había hecho, un error grave que nunca se debe cometer cerca de la seguridad».

Léelo otra vez. Ocho claves privadas de CA (las joyas de la corona de una autoridad de confianza pública, certificada cruzadamente con la raíz AAA Certificate Services de Sectigo) estuvieron expuestas a fuerza bruta durante diecisiete meses, y no las encontró un auditor, ni un programa raíz, ni la propia CA, sino una persona ejecutando una herramienta de código abierto tal cual. El ecosistema asumió colectivamente que lo básico estaba cubierto. Nadie cubrió lo básico.

Este es un patrón más amplio en la infraestructura de seguridad, y por eso sigo insistiendo en la ingeniería defensiva: sistemas que resisten la catástrofe en lugar de sistemas que asumen un funcionamiento correcto. Las comprobaciones que habrían detectado esto son casi vergonzosamente baratas:

1. Ejecuta paranoid_crypto o comprobaciones equivalentes de claves débiles en cada clave en el momento de generarla y en cada CSR antes de firmarla.
2. Verifica la entropía empíricamente: comprueba la longitud en bits del escalar privado y rechaza cualquiera con una entropía efectiva implausiblemente baja, como en el código de ejemplo de arriba.
3. Prueba la ceremonia, no solo la configuración. Haz ensayos de tus ceremonias de claves e inspecciona los artefactos reales producidos, incluido qué objeto del HSM con nombre acaba en la CSR.
4. Escanea continuamente los certificados emitidos, no solo tus plantillas. El certificado es la verdad fundamental; todo lo anterior es intención.

El certificado es la verdad fundamental. Todo lo anterior (scripts, ceremonias, auditorías) es solo intención.

Ocho bits es todo lo que hace falta

Hay algo casi reconfortante en una catástrofe con una causa absurda. Un error de script, dos claves con nombres parecidos en un HSM, una persona que elige la equivocada: nada de estados-nación ni criptoanálisis novedoso, solo un episodio de los Three Stooges con una mecha de diecisiete meses. Pero lo absurdo es la advertencia. Si el eslabón más débil de una CA de confianza pública puede ser un solo byte, entonces la fortaleza de tu PKI no la fija tu elección de curva ni tu presupuesto para HSM. La fija si alguien, en algún punto del pipeline, probó de verdad la salida.

Los fabricantes de navegadores hicieron su parte en cuestión de horas. El resto nos toca a nosotros: audita tu propia generación de claves, ejecuta las comprobaciones baratas, actualiza cada paquete de CA al que llegues y segmenta los dispositivos que no puedas actualizar. Y deja de asumir que alguien más ya revisó lo básico. En seguridad, esa es la suposición más cara que existe.