¿La NSA puso una puerta trasera en el Nuevo Estandar de Encriptación?

¿Quién no escuchó alguna vez la teoría de que los organismos de seguridad observan todo? Quienes sostienen y defienden esa postura no han podido demostrarla nunca. Sin embargo, desde hace años que quienes trabajan en seguridad intentan demostrar su transparencia explicando todo lo que hacen y sus porqués. Casos clásicos son quienes se encargan de hacer algoritmos de encriptación – la base de la seguridad digital -, que utilizan constantes permanentemente y explican cómo llegaron a ellos o simplemente utilizan fuentes conocidas (como el número PI, o secuencias obvias como 123456).

Sin embargo, dados recientes estudios, el NIST (Instituto Nacional de Estándares y Tecnología – USA) publicó 4 algoritmos para generar números pseudo-aleatorios. Uno de ellos utiliza una gran cantidad de constantes cuya explicación brilla por su ausencia. Como si eso fuese poco, hace unos meses descubrieron que esas constantes tienen relación con otros números que formarían el esqueleto de una llave maestra que permitiría predecir la generación de números. Esto, evidentemente, es un problema de seguridad grande como una casa.

Aquí traduzco el artículo completo escrito por Bruce Schneier (una persona dedicada a la seguridad y la criptografía desde hace décadas) y publicado en Wired el día de hoy.

Notas de Traducción

  • Esto es una traducción, el original debe de ser atribuído a Bruce Schneier
  • Los links se mantuvieron como en el original, por lo que seguramente conducen a información en inglés
  • Los acrónimos utilizados tendrán su correspondiente traducción aunque ésta no se encuentre en el original
  • Artículo Original: Did NSA Put a Secret Backdoor in New Encryption Standard?

La Traducción

Los números aleatorios son críticos para la criptografía: claves de encriptación, desafíos aleatorios de autenticación, vectores de inicialización, esquemas de intercambios de clave, generación de números primos y mucho más. Rompamos el generador de números aleatorios y generalmente romperemos también el sistema de seguridad completo. Razón por la que debemos preocuparnos por un nuevo estándar de generadores de números aleatorios que incluye un algoritmo que es lento, mal diseñado y que podría llegar a incluir una puerta trasera para la NSA (Agencia Nacional de Seguridad de USA)

Generar números aleatorios no es sencillo y los investigadores descubrieron muchos problemas y ataques con el pasar de los años. Un paper reciente encontró una falla en el generador de números aleatorios de Windows 2000. Otro encontró fallas en el generador de números aleatorios de Linux. Allá en 1996, una temprana versión de SSL fue quebrada debido a las fallas en su generador de números aleatorios. Con John Kelsey y Niels Ferguson en 1999 diseñamos Yarrow, un generador de números aleatorios basado en nuestro propio trabajo de criptoanálisis. Yo mejoré el diseño cuatro años más tarde – y lo renombré Fortuna – en el libro “Criptografía Práctica” que escribimos con Ferguson.

El gobierno de los Estados Unidos publicó un nuevo estándar oficial para generadores de números aleatorios este año, seguramente a seguir por desarrolladores de software y de hardware en todo el mundo. Llamado NIST Special Publication 800-90 (PDF), el documento de 130 páginas contiene cuatro técnicas aprobadas llamadas DRBGs (Generadores Determinísticos de Bits Aleatorios). Los cuatro basados en primitivas criptográficas pre-existentes. Uno está basado en funciones de hash, otro en HMAC, uno en cipher de bloque y el último en curvas elípticas. Es un diseño criptográfico inteligente el utilizar sólo unas pocas primitivas criptográficas confiables, por lo que construir un generador de números aleatorios de partes existentes es algo bueno.

Pero uno de esos generadores – el basado en curbas elípticas (N. de T.: curvas elípticas es un concepto matemático muy avanzado y muy utilizado en la actualidad en criptografía) – no es como los demás. Llamado Dual_EC_DRBG, no sólo es complicado de pronunciar sino que es tres órdenes de magnitud más lento que sus pares. Es parte del estándar sólo por haber sido premiado por la NSA, quien lo propuso originalmente hace años en un proyecto de estandarización relacionado en el ANSI (Instituto Nacional Americano de Estándares).

La NSA siempre estuvo íntimamente involucrada en los estándares criptográficos de Estados Unidos – son, después de todo, expertos en hacer y romper códigos secretos. Por lo que la participación de la agencia en el estándar publicaod por el NIST no es siniestro en sí mismo. Sólo cuando se revisa en detalle la contribución de la NSA surgen las dudas.

Los problemas con Dual_EC_DRBG fueron descriptos por primera vez a principios de 2006. La matemática es complicada pero la idea general es que los números aleatorios producidos por el generador tiene un pequeño sesgo. El problema no es suficiente como para hacer inusable al algoritmo – pero es causa de preocupación. Los criptógrafos somos gente conservadora: no nos gusta utilizar algoritmos que tengan el más mínimo esbozo de problema.

Pero hoy hay un hedor aún más grande alrededor de Dual_EC_DRBG. En una presentación informal (PDF) en la conferencia CRYPTO 2007 en Agosto, Dan Shumow y Niels Ferguson mostraron que el algoritmo contiene una debilidad que sólo puede ser descripta como una puerta trasera.

Así funciona: hay un conjunto de constantes – números fijos – en el estándar que se usan para definir la curva elíptica del algoritmo. Éstas constantes están listadas en el Apéndice A de la publicación del NIST, pero en ningún lado se explica de dónde salieron.

Lo que mostraron Shumow y Ferguson es que éstos números tienen una relación con un segundo conjunto de números secretos que pueden hacer las veces de un tipo de esqueleto de clave. Si se conoce los números secretos, se puede predecir la salida del generador de números aleatorios recolectando sólo 32 bytes de su salida. Para ponerlo en términos concretos, sólo necesitamos monitorear una conexión de internet encryptada con TLS para poder romper la seguridad de ese protocolo. Si se conoce los números secretos se puede romper completamente cualquier instancia de Dual_EC_DRBG.

Los investigadores no saben cuáles son dichos números secretos. Pero por la forma en la que funciona el algoritmo, la persona que generó las constantes podría saber; tuvo la oportunidad matemática de generar las constantes y los números secretos en paralelo.

Por supuesto, no tenemos forma de saber si la NSA conoce los números secretos que rompen Dual_EC_DRBG. No tenemos forma de saber si un empleado de la NSA trabajando por su cuenta encontró las constantes – y tiene los números secretos. No sabemos si alguien del NIST o alguien del grupo de trabajo de ANSI las tiene. A lo mejor nadie las posee.

No sabemos de dónde vinieron las constantes para empezar. Sólo sabemos que quien sea que las generó podría tener la clave para esta puerta trasera. Y sabemos que no existe forma que el NIST – o nadie más – demuestre lo contrario.

Esto es algo preocupante.

Aún si nadie conoce los números secretos, el hecho que haya una puerta trasera presente hace a Dual_EC_DRBG muy fráfil. Si alguien resuelve sólo una instancia del problema de curva elíptica del algoritmo, efectivamente tendría las llaves del reino. Podría utilizarlas entonces para cualquier propósito infame que desee. O podría publicar su resultado y dejar toda implementación del generador de números aleatorio completamente insegura.

Es posible implementar Dual_EC_DRBG de forma tal que esté protegido contra esta puerta trasera generando nuevas constantes con algún otro generador de números aleatorios seguro y luego publicando su semilla. Este método inclusive está en el documento del NIST en el apéndice A. Pero el procedimiento es opcional, y adivino que la mayoría de las implementaciones de Dual_EC_DRBG no se molestarán en utilizarlo.

Si esta historia los deja confundidos, bienvenidos al club. No comprendo por qué la NSA fue tan insistente en incluir Dual_EC_DRBG en el estándar. No tiene sentido como puerta trasera: es pública y bastante obvia. No tiene sentido desde una perspectiva ingenieril: es muy lento para que alguien realmente quiera utilizarlo. Y no tiene sentido mirándolo desde el punto de la compatibilidad: cambiar un generador de números aleatorios por otro es sencillo.

Mi recomendación es, si necesitan un generador de números aleatorios, no utilizar Dual_EC_DRBG bajo ninguna circumstancia. Si tienen que utilizar algo del SP 800-90 utilicen CTR_DRBG ó Hash_DRBG.

Mientras tanto, tanto el NIST como la NSA tiene explicaciones que dar.