Ataque al generador de números aleatorios

Al igual que otros componentes de un criptosistema, un generador de números aleatorios de software debe diseñarse para resistir ciertos ataques. Algunos ataques posibles a un generador de números aleatorios incluyen (de ^{[ 3 ]} ):

Ataque criptoanalítico directo

cuando un atacante obtiene parte del flujo de bits aleatorios y puede usar esto para distinguir la salida del generador de números aleatorios de un flujo verdaderamente aleatorio.

Ataques basados ​​en la entrada

modificar la entrada al generador de números aleatorios para atacarlo, por ejemplo, "eliminando" la entropía existente del sistema y colocándola en un estado conocido.

Ataques de extensión de compromiso estatal

Cuando se conoce el estado secreto interno del generador de números aleatorios, se puede utilizar para predecir resultados futuros o recuperar resultados anteriores. Esto puede ocurrir cuando un generador se inicia y tiene poca o ninguna entropía (especialmente si el ordenador acaba de arrancar y ha seguido una secuencia de operaciones muy estándar), por lo que un atacante podría obtener una estimación inicial de su estado.

Existen varios tipos de ataques posibles contra los generadores de números aleatorios de hardware , como intentar capturar las emisiones de radiofrecuencia del ordenador (obtener, por ejemplo, los tiempos de interrupción del disco duro a partir del ruido del motor) o intentar introducir señales controladas en una fuente supuestamente aleatoria (como apagar las luces de una lámpara de lava o introducir una señal fuerte y conocida en una tarjeta de sonido).

Se pueden crear números aleatorios manipulados utilizando un generador de números pseudoaleatorios criptográficamente seguro con un valor semilla conocido por el atacante, pero oculto en el software. Una porción relativamente corta de la semilla, de entre 24 y 40 bits, puede ser verdaderamente aleatoria para evitar repeticiones evidentes, pero no lo suficientemente larga como para impedir que el atacante recupere, por ejemplo, una clave generada "aleatoriamente".

Los números aleatorios suelen pasar por varias capas de hardware y software antes de ser utilizados. Los bits pueden generarse en un dispositivo periférico, enviarse a través de un cable serie, recopilarse en una utilidad del sistema operativo y recuperarse mediante una llamada al sistema . Los bits manipulados pueden sustituirse en cualquier punto de este proceso con escasa probabilidad de detección.

Se puede construir un circuito de hardware para producir bits manipulados en un circuito integrado de pocos milímetros cuadrados. Incluso el generador de números aleatorios de hardware más sofisticado puede manipularse colocando un chip de este tipo en cualquier punto anterior a la digitalización de la fuente de aleatoriedad, por ejemplo, en un chip controlador de salida o incluso en el cable que conecta el generador de números aleatorios al ordenador. El chip manipulado puede incluir un reloj para limitar el inicio de la operación a un tiempo después de que la unidad se encienda por primera vez y se hayan realizado las pruebas de aceptación, o puede contener un receptor de radio para el control de encendido/apagado. Podría ser instalado por el fabricante a petición de su servicio nacional de inteligencia de señales, o añadido posteriormente por cualquier persona con acceso físico. Los chips de CPU con generadores de números aleatorios de hardware integrados pueden sustituirse por chips compatibles con un generador de números aleatorios manipulado en su firmware.

Las primeras versiones del protocolo de cifrado Secure Sockets Layer (SSL) de Netscape utilizaban cantidades pseudoaleatorias derivadas de un generador de números pseudoaleatorios (PRNG) inicializado con tres valores variables: la hora del día, el ID del proceso y el ID del proceso padre. Estas cantidades suelen ser relativamente predecibles, por lo que tienen poca entropía y son menos que aleatorias, y como resultado, esa versión de SSL se consideró insegura. El problema fue reportado a Netscape en 1994 por Phillip Hallam-Baker , entonces investigador del equipo web del CERN , pero no se solucionó antes del lanzamiento. El problema en el código en ejecución fue descubierto en 1995 por Ian Goldberg y David Wagner , ^{[ 4 ]} quienes tuvieron que realizar ingeniería inversa del código objeto porque Netscape se negó a revelar los detalles de su generación de números aleatorios ( seguridad por ocultación ). Ese generador de números aleatorios se corrigió en versiones posteriores (versión 2 y superiores) mediante una inicialización más robusta (es decir, más aleatoria y, por lo tanto, con mayor entropía desde la perspectiva de un atacante).

Microsoft utilizó un algoritmo no publicado para generar valores aleatorios en versiones anteriores de su sistema operativo Windows . Estas cantidades aleatorias se ponen a disposición de los usuarios mediante la utilidad CryptGenRandom . En noviembre de 2007, Leo Dorrendorf y otros investigadores de la Universidad Hebrea de Jerusalén y la Universidad de Haifa publicaron un artículo titulado « Criptoanálisis del generador de números aleatorios del sistema operativo Windows» . ^{[ 5 ]} El artículo reveló graves deficiencias en el enfoque de Microsoft en aquel momento. Las conclusiones del artículo se basaron en el desensamblaje del código de Windows 2000 , pero, según Microsoft, también se aplicaban a Windows XP. ^{[ 6 ]} Microsoft ha declarado que los problemas descritos en el artículo se han solucionado en versiones posteriores de Windows, que utilizan una implementación diferente del generador de números aleatorios. ^{[ 6 ]}

El Instituto Nacional de Estándares y Tecnología de EE. UU. ha publicado una colección de "generadores de bits aleatorios deterministas" que recomienda como Publicación Especial NIST 800-90. ^{[ 7 ]} Uno de los generadores, Dual_EC_DRBG , fue el preferido por la Agencia de Seguridad Nacional . ^{[ 8 ]} Dual_EC_DRBG utiliza tecnología de curva elíptica e incluye un conjunto de constantes recomendadas. En agosto de 2007, Dan Shumow y Niels Ferguson de Microsoft demostraron que las constantes podían construirse de tal manera que crearan una puerta trasera cleptográfica en el algoritmo. ^{[ 9 ]} En septiembre de 2013, The New York Times escribió que "la NSA había insertado una puerta trasera en un estándar de 2006 adoptado por el NIST... llamado estándar Dual EC DRBG", ^{[ 10 ]} revelando así que la NSA llevó a cabo un ataque de malware contra el pueblo estadounidense. En diciembre de 2013, Reuters informó que documentos publicados por Edward Snowden indicaban que la NSA había pagado a RSA Security 10 millones de dólares para que Dual_EC_DRBG se convirtiera en el algoritmo predeterminado de su software de cifrado, y generó más preocupación de que el algoritmo pudiera contener una puerta trasera para la NSA. ^{[ 11 ]} Debido a estas preocupaciones, en 2014, el NIST retiró Dual EC DRBG de su borrador de guía sobre generadores de números aleatorios, recomendando que "los usuarios actuales de Dual_EC_DRBG migren a uno de los tres algoritmos aprobados restantes lo antes posible". ^{[ 12 ]}

Crypto-1 es un criptosistema desarrollado por NXP para su uso en chips MIFARE . El sistema es propietario y, originalmente, el algoritmo no se había publicado. Tras realizar ingeniería inversa del chip, investigadores de la Universidad de Virginia y del Chaos Computer Club descubrieron un ataque contra Crypto-1 que explotaba un generador de números aleatorios mal inicializado. ^{[ 13 ]}

En mayo de 2008, el investigador de seguridad Luciano Bello reveló su descubrimiento de que los cambios realizados en 2006 al generador de números aleatorios en la versión del paquete OpenSSL distribuida con Debian Linux y otras distribuciones basadas en Debian, como Ubuntu , redujeron la entropía total del ID del proceso y hicieron vulnerables a ataques a diversas claves de seguridad. ^{[ 14 ] [ 15 ]} La vulnerabilidad de seguridad fue causada por cambios realizados en el código openssl por un desarrollador de Debian en respuesta a advertencias del compilador sobre el acceso a memoria no inicializada . ^{[ 16 ]} Esto provocó una regeneración masiva de claves a nivel mundial y, a pesar de toda la atención que recibió el problema, se podría suponer que muchas de estas claves antiguas todavía están en uso. Los tipos de claves afectadas incluyen claves SSH , claves OpenVPN , claves DNSSEC , material de clave para usar en certificados X.509 y claves de sesión utilizadas en conexiones SSL/TLS . Las claves generadas con GnuPG o GNUTLS no se ven afectadas, ya que estos programas utilizan métodos diferentes para generar números aleatorios. Las claves generadas por distribuciones de Linux que no se basan en Debian tampoco se ven afectadas. La vulnerabilidad de generación de claves débiles se corrigió rápidamente tras su notificación, pero cualquier servicio que aún utilice claves generadas con el código antiguo sigue siendo vulnerable. Varios paquetes de software ahora incluyen comprobaciones contra una lista negra de claves débiles para intentar evitar el uso de cualquiera de estas claves débiles restantes, pero los investigadores siguen encontrando implementaciones de claves débiles. ^{[ 17 ]}

En diciembre de 2010, un grupo autodenominado fail0verflow anunció la recuperación de la clave privada del algoritmo de firma digital de curva elíptica (ECDSA) utilizado por Sony para firmar el software de la consola de videojuegos PlayStation 3. El ataque fue posible porque Sony no generó un nuevo nonce aleatorio para cada firma. ^{[ 18 ]}

Un análisis que compara millones de claves públicas RSA recopiladas de Internet fue anunciado en 2012 por Lenstra, Hughes, Augier, Bos, Kleinjung y Wachter. Lograron factorizar el 0,2% de las claves usando solo el algoritmo de Euclides . ^{[ 19 ] [ 20 ]} Explotaron una debilidad única de los criptosistemas basados ​​en la factorización de enteros . Si n = pq es una clave pública y n ′ = p ′ q ′ es otra, entonces si por casualidad p = p ′ , entonces un cálculo simple de mcd( n , n ′) = p factoriza tanto n como n ′, comprometiendo totalmente ambas claves. Nadia Heninger , parte de un grupo que realizó un experimento similar, dijo que las claves defectuosas ocurrieron casi exclusivamente en aplicaciones embebidas , y explica que el problema del primo compartido descubierto por los dos grupos resulta de situaciones en las que el generador de números pseudoaleatorios está mal inicializado y luego se vuelve a inicializar entre la generación del primer y segundo primo. ^{[ 21 ]}

En agosto de 2013, se reveló que errores en la clase Java SecureRandom podían generar colisiones en los valores k nonce utilizados para ECDSA en implementaciones de Bitcoin en Android . Cuando esto ocurría, se podía recuperar la clave privada, lo que a su vez permitía robar Bitcoins de la billetera que la contenía . ^{[ 22 ]}