Resolving an Apparent Key-Dependent Timing Side-Channel in Bouncy Castle ML-DSA-65 Signing: A Pre-Registered Discrimination

En el mundo de la seguridad digital, las cerraduras más poderosas suelen ser aquellas que tardan más en abrirse. Durante décadas, los matemáticos han diseñado sistemas de cifrado que se basan en problemas complejos para mantener la seguridad de los datos. A medida que las computadoras se vuelven más potentes, y ante la promesa de las computadoras cuánticas, los científicos compiten por construir nuevas cerraduras que incluso esas máquinas futuras no puedan romper. Uno de los diseños nuevos más prometedores se llama ML-DSA. Es un método para crear firmas digitales, el equivalente electrónico a una firma manuscrita en un contrato o un certificado. Estas firmas demuestran que un mensaje proviene de una persona específica y que no ha sido manipulado.

Sin embargo, un nuevo tipo de peligro ha surgido junto con estas cerraduras matemáticas. No es un fallo en la matemática en sí, sino un fallo en cómo la matemática se ejecuta en una computadora. Esto se conoce como un ataque de canal lateral de tiempo (timing side-channel attack). Imagine una caja fuerte que hace un clic ligeramente más fuerte cuando se introduce la combinación correcta, o una puerta que tarda una fracción de segundo más en abrirse cuando se usa la llave adecuada. Si un atacante puede medir estas diminutas diferencias de tiempo con extrema precisión, podría ser capaz de deducir la clave secreta. Para el nuevo sistema ML-DSA, los diseñadores incorporaron una función de seguridad: el proceso implica mucho ensayo y error. La computadora intenta generar una firma, comprueba si es válida y, si no lo es, la desecha e intenta de nuevo. Debido a que el número de intentos varía aleatoriamente, el tiempo total que toma firmar un mensaje también varía. Se supone que esta aleatoriedad oculta la clave secreta, haciendo imposible determinar si un retraso específico fue causado por la clave o simplemente por mala suerte.

Un investigador llamado Arpan Sharma investigó recientemente si esta función de seguridad estaba funcionando según lo previsto en una popular biblioteca de software llamada Bouncy Castle. Esta biblioteca es ampliamente utilizada para asegurar desde actualizaciones de software hasta conexiones web seguras. Cuando Sharma observó los datos por primera vez, vio algo que parecía una filtración. Al comparar el tiempo que tomó firmar mensajes con veinte claves secretas diferentes, encontró que algunas claves tardaban consistentemente más que otras. La diferencia era pequeña —aproximadamente un 1.35 por ciento— pero en el mundo de la seguridad, incluso una diferencia diminuta y constante puede ser una señal de que un secreto está siendo revelado. La pregunta era si esta diferencia era una vulnerabilidad real, un fallo en el código que permitía que la clave secreta influyera en el tiempo, o simplemente una ilusión estadística causada por la naturaleza aleatoria del sistema.

Para responder a esto, Sharma no confió en una simple suposición o en una prueba rápida. Diseñó un experimento riguroso y preplanificado para separar la señal del ruido. El núcleo de su método consistió en observar el trabajo que la computadora realizaba realmente para cada firma, en lugar de solo mirar el tiempo final. Construyó una herramienta que registraba exactamente cuántas veces la computadora tenía que intentar y fallar antes de encontrar una firma válida. Esto es crucial porque el tiempo que toma firmar un mensaje está directamente ligado a cuántas veces tiene que reintentarlo la computadora. Si una clave resultaba tener un conjunto de mensajes "afortunados" que requerían menos reintentos, terminaría más rápido, no porque la clave fuera diferente, sino porque la matemática fue más fácil ese día.

Sharma ejecutó una campaña masiva, generando más de 1.2 millones de firmas para cada una de las veinte claves. Luego agrupó las firmas basándose en la cantidad exacta de trabajo que requerían. Se hizo una pregunta simple: si dos firmas requerían exactamente el mismo número de reintentos y pasaban por exactamente los mismos pasos, ¿seguían tomando tiempos diferentes dependiendo de qué clave se usaba? La respuesta fue un no definitivo. Una vez que contabilizó el número de reintentos, la diferencia de tiempo entre las claves desapareció. Las variaciones diminutas que permanecieron eran tan pequeñas que podían explicarse por las fluctuaciones naturales y aleatorias del procesador y la memoria de la computadora, en lugar de por las claves secretas mismas.

El estudio fue más allá para asegurar que los resultados no fueran un golpe de suerte de la computadora específica o de la forma en que el software se cargaba en la memoria. Sharma repitió el experimento con un nuevo conjunto de claves y un nuevo conjunto de mensajes. También realizó una prueba de control donde desordenó el orden en que la computadora manejaba los datos. Si las diferencias de tiempo fueran causadas por las claves secretas, el orden de las claves no importaría. Si las diferencias fueran causadas por dónde aterrizaban los datos en la memoria de la computadora, el orden cambiaría los resultados. El experimento mostró que las diferencias de tiempo no seguían a las claves; seguían al diseño de la memoria. Esto confirmó que la aparente filtración era un artefacto del entorno de la computadora, no un fallo en la seguridad del código.

La investigación también analizó la parte del código que se sabía que era ligeramente distinta dependiendo de los datos. El software comprueba el tamaño de los números durante el proceso y, si un número es demasiado grande, detiene la comprobación del resto de la lista inmediatamente. Esta es una optimización estándar para ahorrar tiempo, pero significa que la computadora podría detenerse antes para algunas entradas que para otras. Sharma midió el impacto de este atajo y encontró que contribuía con un retraso de solo un nanosegundo. Esto es un nanosegundo, un milmillonésima de segundo, una escala de tiempo tan pequeña que está muy por debajo del umbral que un atacante podría medir o utilizar de manera realista para robar una clave.

Los hallazgos se aplicaron a toda la familia de estos nuevos estándares de firma digital, incluyendo las versiones más pequeñas y más grandes utilizadas para diferentes niveles de seguridad. En cada caso, el resultado fue el mismo. La implementación del software era limpia. Las aparentes diferencias en el tiempo no eran una señal de que las claves secretas se estuvieran filtrando. En cambio, eran el resultado natural de un sistema que está diseñado para variar su trabajo para proteger esas mismas claves. El estudio concluyó que la biblioteca Bouncy Castle es segura contra este tipo específico de ataque. La dispersión del 1.35 por ciento en el tiempo que inicialmente levantó alarmas fue simplemente el sonido de veinte claves diferentes tomando veinte muestras distintas de una distribución aleatoria, un eco estadístico en lugar de una brecha de seguridad.

Esta investigación sirve como un recordatorio de lo difícil que es probar que un sistema es seguro. En el pasado, los investigadores podrían haberse detenido ante la primera señal de una diferencia de tiempo y haber declarado una vulnerabilidad. Este estudio muestra que en sistemas complejos y aleatorios, la primera señal es a menudo el sistema haciendo su trabajo. Al medir cuidadosamente el trabajo realizado y controlar el entorno, el investigador pudo distinguir entre una filtración real y una ilusión estadística. El resultado es una confirmación de que las nuevas firmas digitales son robustas, y que las variaciones aleatorias en su velocidad son una característica, no un error. Para los millones de dispositivos que dependen de estas firmas para mantenerse seguros, el mensaje es claro: la cerradura resiste, y el tiempo que toma girar la llave no te dice nada sobre el secreto que hay dentro.