EC_DRBG dual

Polémico generador de números pseudoaleatorios

Dual_EC_DRBG ( Dual Elliptic Curve Deterministic Random Bit Generator ) ^[1] es un algoritmo que se presentó como un generador de números pseudoaleatorios criptográficamente seguro (CSPRNG) que utiliza métodos de criptografía de curva elíptica . A pesar de las amplias críticas públicas, incluida la identificación pública de la posibilidad de que la Agencia de Seguridad Nacional pusiera una puerta trasera en una implementación recomendada, fue, durante siete años, uno de los cuatro CSPRNG estandarizados en NIST SP 800-90A como se publicó originalmente alrededor de junio de 2006, hasta que fue retirado en 2014.

Debilidad: una puerta trasera potencial

Las debilidades en la seguridad criptográfica del algoritmo eran conocidas y criticadas públicamente mucho antes de que el algoritmo se convirtiera en parte de un estándar formal avalado por la ANSI , la ISO y anteriormente por el Instituto Nacional de Estándares y Tecnología (NIST). Una de las debilidades identificadas públicamente fue el potencial del algoritmo para albergar una puerta trasera criptográfica ventajosa para quienes lo conocen (la Agencia de Seguridad Nacional (NSA) del gobierno de los Estados Unidos) y para nadie más . En 2013, The New York Times informó que los documentos en su posesión pero nunca publicados al público "parecen confirmar" que la puerta trasera era real y que había sido insertada deliberadamente por la NSA como parte de su programa de descifrado Bullrun . En diciembre de 2013, un artículo de noticias de Reuters afirmó que en 2004, antes de que el NIST estandarizara Dual_EC_DRBG, la NSA pagó a RSA Security 10 millones de dólares en un acuerdo secreto para utilizar Dual_EC_DRBG como predeterminado en la biblioteca de criptografía RSA BSAFE , lo que dio lugar a que RSA Security se convirtiera en el distribuidor más importante del algoritmo inseguro. ^[2] RSA respondió que "niega categóricamente" que alguna vez haya coludido deliberadamente con la NSA para adoptar un algoritmo que se sabía que tenía fallas, pero también declaró que "nunca hemos mantenido [nuestra] relación [con la NSA] en secreto". ^[3]

Poco antes de su primera publicación conocida en 2004, se descubrió una posible puerta trasera cleptográfica con el diseño de Dual_EC_DRBG, que tenía la inusual propiedad de que era teóricamente imposible para cualquiera que no fuera los diseñadores de Dual_EC_DRBG (NSA) confirmar la existencia de la puerta trasera. Bruce Schneier concluyó poco después de la estandarización que la puerta trasera "bastante obvia" (junto con otras deficiencias) significaría que nadie usaría Dual_EC_DRBG. ^[4] La puerta trasera permitiría a la NSA descifrar, por ejemplo, el cifrado SSL/TLS que utilizaba Dual_EC_DRBG como CSPRNG. ^[5]

Los miembros del grupo de estándares ANSI al que se presentó por primera vez Dual_EC_DRBG conocían el mecanismo exacto de la puerta trasera potencial y cómo desactivarla, ^[6] pero no optaron por desactivarla ni hacerla pública. La comunidad criptográfica general inicialmente no estaba al tanto de la puerta trasera potencial, hasta la publicación de Dan Shumow y Niels Ferguson , o de la solicitud de patente de 2005 de Daniel RL Brown y Scott Vanstone de Certicom que describe el mecanismo de la puerta trasera.

En septiembre de 2013, The New York Times informó que los memorandos internos de la NSA filtrados por Edward Snowden indicaban que la NSA había trabajado durante el proceso de estandarización para eventualmente convertirse en el único editor del estándar Dual_EC_DRBG, ^[7] y concluyó que el estándar Dual_EC_DRBG efectivamente contenía una puerta trasera para la NSA. ^[8] En respuesta, el NIST declaró que "el NIST no debilitaría deliberadamente un estándar criptográfico", ^[9] pero según la historia del New York Times , la NSA había estado gastando $ 250 millones por año para insertar puertas traseras en software y hardware como parte del programa Bullrun . ^[10] Posteriormente, un comité asesor presidencial creado para examinar la conducta de la NSA recomendó, entre otras cosas, que el gobierno de los EE. UU. "apoye plenamente y no socave los esfuerzos para crear estándares de cifrado". ^[11]

El 21 de abril de 2014, el NIST retiró Dual_EC_DRBG de su borrador de guía sobre generadores de números aleatorios y recomendó que "los usuarios actuales de Dual_EC_DRBG realicen la transición a uno de los tres algoritmos aprobados restantes lo más rápidamente posible". ^[12]

Cronología de Dual_EC_DRBG

Descripción

Descripción general

El algoritmo utiliza un único entero s como estado. Siempre que se solicita un nuevo número aleatorio, este entero se actualiza. El estado k -ésimo se da por

${\displaystyle s_{k}=g_{P}(s_{k-1})}$

El entero aleatorio devuelto r es una función del estado. El k -ésimo número aleatorio es

${\displaystyle r_{k}=g_{Q}(s_{k})}$

La función depende del punto fijo de la curva elíptica P. Es similar excepto que utiliza el punto Q. Los puntos P y Q permanecen constantes para una implementación particular del algoritmo. ${\displaystyle g_{P}(x)}$ ${\displaystyle g_{Q}(x)}$

Detalles

El algoritmo permite diferentes constantes, longitud de salida variable y otras personalizaciones. Para simplificar, el algoritmo descrito aquí utilizará las constantes de la curva P-256 (uno de los 3 conjuntos de constantes disponibles) y tendrá una longitud de salida fija. El algoritmo opera exclusivamente sobre un campo finito primo ( ) donde p es primo. El estado, la semilla y los números aleatorios son todos elementos de este campo. El tamaño del campo es ${\displaystyle F_{p}}$ ${\displaystyle \mathbb {Z} /p\mathbb {Z} }$

${\displaystyle p={\mathtt {ffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551}}_{16}}$

Se da una curva elíptica sobre ${\displaystyle F_{p}}$

${\displaystyle y^{2}=x^{3}-3x+b}$

donde la constante b es

${\displaystyle b={\mathtt {5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b}}_{16}}$

Los puntos de la curva son . Dos de estos puntos se dan como puntos fijos P y Q ${\displaystyle E({\displaystyle F_{p}})}$

${\displaystyle P,Q\in E(F_{p})}$

Sus coordenadas son

${\displaystyle {\begin{aligned}P_{x}&={\mathtt {6b17d1f2\ e12c4247\ f8bce6e5\ 63a440f2\ 77037d81\ 2deb33a0\ f4a13945\ d898c296}}_{~16}\\P_{y}&={\mathtt {4fe342e2\ fe1a7f9b\ 8ee7eb4a\ 7c0f9e16\ 2bce3357\ 6b315ece\ cbb64068\ 37bf51f5}}_{~16}\\Q_{x}&={\mathtt {c97445f4\ 5cdef9f0\ d3e05e1e\ 585fc297\ 235b82b5\ be8ff3ef\ ca67c598\ 52018192}}_{~16}\\Q_{y}&={\mathtt {b28ef557\ ba31dfcb\ dd21ac46\ e2a91e3c\ 304f44cb\ 87058ada\ 2cb81515\ 1e610046}}_{~16}\end{aligned}}}$

Se utiliza una función para extraer la coordenada x. Esta "convierte" los puntos de la curva elíptica en elementos del campo.

${\displaystyle X(x,y)=x}$

Los números enteros de salida se truncan antes de ser emitidos.

${\displaystyle t(x)=x\ {\text{mod}}\ {\frac {p}{2^{16}}}}$

Las funciones y . Estas funciones elevan los puntos fijos a una potencia. "Elevar a una potencia" en este contexto significa utilizar la operación especial definida para los puntos de las curvas elípticas . ${\displaystyle g_{P}}$ ${\displaystyle g_{Q}}$

${\displaystyle g_{P}(x)=X(P^{x})}$

${\displaystyle g_{Q}(x)=t(X(Q^{x}))}$

El generador se siembra con un elemento de ${\displaystyle F_{p}}$

${\displaystyle s_{1}=g_{P}(seed)}$

El estado k -ésimo y el número aleatorio

${\displaystyle s_{k}=g_{P}(s_{k-1})}$

${\displaystyle r_{k}=g_{Q}(s_{k})}$

Los números aleatorios

${\displaystyle r_{1},r_{2},\ldots }$

Seguridad

El propósito declarado de incluir el Dual_EC_DRBG en NIST SP 800-90A es que su seguridad se basa en suposiciones de dureza computacional de la teoría de números. Una prueba matemática de reducción de seguridad puede entonces demostrar que mientras los problemas teóricos de números sean difíciles, el generador de números aleatorios en sí es seguro. Sin embargo, los creadores de Dual_EC_DRBG no publicaron una reducción de seguridad para Dual_EC_DRBG, y se demostró poco después de que se publicara el borrador de NIST que Dual_EC_DRBG de hecho no era seguro, porque generaba demasiados bits por ronda. ^{[22] [35] [36]} La salida de demasiados bits (junto con los puntos de curva elíptica cuidadosamente elegidos P y Q ) es lo que hace posible la puerta trasera de la NSA, porque permite al atacante revertir el truncamiento mediante una suposición de fuerza bruta. La salida de demasiados bits no se corrigió en el estándar publicado final, lo que dejó a Dual_EC_DRBG inseguro y con puerta trasera. ^[5]

En muchos otros estándares, las constantes que se supone que son arbitrarias se eligen mediante el principio numérico de "nada bajo la manga" , donde se derivan de pi o constantes matemáticas similares de una manera que deja poco espacio para el ajuste. Sin embargo, Dual_EC_DRBG no especificó cómo se eligieron las constantes P y Q predeterminadas , posiblemente porque fueron construidas por la NSA para que se pudieran crear puertas traseras. Debido a que el comité de estándares era consciente del potencial de una puerta trasera, se incluyó una forma para que un implementador eligiera sus propias P y Q seguras. ^{[6] [15]} Pero la formulación exacta en el estándar se escribió de tal manera que el uso de las supuestas puertas traseras P y Q era necesario para la validación FIPS 140-2 , por lo que el proyecto OpenSSL eligió implementar las puertas traseras P y Q , a pesar de que eran conscientes de la puerta trasera potencial y hubieran preferido generar sus propias P y Q seguras . ^[37] El New York Times escribiría más tarde que la NSA había trabajado durante el proceso de estandarización para eventualmente convertirse en el único editor del estándar. ^[7]

Posteriormente, Daniel RL Brown y Kristian Gjøsteen publicaron una prueba de seguridad para Dual_EC_DRBG, que mostraba que los puntos de curva elíptica generados serían indistinguibles de los puntos de curva elíptica aleatorios uniformes, y que si se generaban menos bits en el truncamiento de salida final, y si los dos puntos de curva elíptica P y Q eran independientes, entonces Dual_EC_DRBG era seguro. La prueba se basó en la suposición de que tres problemas eran difíciles: la suposición decisional de Diffie-Hellman (que generalmente se acepta como difícil) y dos problemas más nuevos menos conocidos que generalmente no se aceptan como difíciles: el problema del punto truncado y el problema del logaritmo x . ^{[35] [36]} Dual_EC_DRBG era bastante lento en comparación con muchos CSPRNG alternativos (que no tienen reducciones de seguridad ^[38] ), pero Daniel RL Brown argumenta que la reducción de seguridad hace que el lento Dual_EC_DRBG sea una alternativa válida (suponiendo que los implementadores desactiven la puerta trasera obvia). ^[38] Téngase en cuenta que Daniel RL Brown trabaja para Certicom, el principal propietario de patentes de criptografía de curva elíptica, por lo que puede haber un conflicto de intereses en la promoción de un CSPRNG de EC.

La supuesta puerta trasera de la NSA permitiría al atacante determinar el estado interno del generador de números aleatorios al observar la salida de una sola ronda (32 bytes); toda la salida futura del generador de números aleatorios se puede calcular fácilmente, hasta que el CSPRNG se vuelva a sembrar con una fuente externa de aleatoriedad. Esto hace que, por ejemplo, SSL/TLS sea vulnerable, ya que la configuración de una conexión TLS incluye el envío de un nonce criptográfico generado aleatoriamente en claro. ^[5] La supuesta puerta trasera de la NSA dependería de que conocieran el único e tal que . Este es un problema difícil si P y Q se establecen de antemano, pero es más fácil si se eligen P y Q. ^[24] e es una clave secreta que presumiblemente solo conoce la NSA, y la supuesta puerta trasera es una puerta trasera oculta asimétrica cleptográfica . ^[39] La publicación del blog de Matthew Green The Many Flaws of Dual_EC_DRBG ^[40] tiene una explicación simplificada de cómo funciona la supuesta puerta trasera de la NSA empleando el cleptograma de registro discreto introducido en Crypto 1997. ^[14] ${\displaystyle eQ=P}$

Estandarización e implementaciones

La NSA introdujo por primera vez Dual_EC_DRBG en el ANSI X9.82 DRBG a principios de la década de 2000, incluidos los mismos parámetros que crearon la supuesta puerta trasera, y Dual_EC_DRBG se publicó en un borrador de estándar ANSI. Dual_EC_DRBG también existe en el estándar ISO 18031. ^[6]

Según John Kelsey (quien junto con Elaine Barker fue catalogado como autor de NIST SP 800-90A), la posibilidad de la puerta trasera mediante P y Q cuidadosamente elegidos se planteó en una reunión del Grupo de Normas y Directrices de Herramientas ANSI X9F1. ^[6] Cuando Kelsey le preguntó a Don Johnson de Cygnacom sobre el origen de Q , Johnson respondió en un correo electrónico del 27 de octubre de 2004 a Kelsey que la NSA había prohibido la discusión pública de la generación de una Q alternativa a la proporcionada por la NSA. ^[41]

Al menos dos miembros del grupo de estándares y pautas de herramientas ANSI X9F1 que escribió ANSI X9.82, Daniel RL Brown y Scott Vanstone de Certicom , ^[6] conocían las circunstancias exactas y el mecanismo en el que podría ocurrir una puerta trasera, ya que presentaron una solicitud de patente ^[18] en enero de 2005 sobre exactamente cómo insertar o prevenir la puerta trasera en DUAL_EC_DRBG. El funcionamiento de la "trampilla" mencionada en la patente es idéntico al que se confirmó más tarde en Dual_EC_DRBG. Al escribir sobre la patente en 2014, el comentarista Matthew Green describe la patente como una forma " pasivo-agresiva " de burlarse de la NSA al hacer pública la puerta trasera, mientras sigue criticando a todos los miembros del comité por no desactivar realmente la puerta trasera de la que obviamente estaban al tanto. ^[41] La patente de Brown y Vanstone enumera dos condiciones necesarias para que exista la puerta trasera:

1) Elegido Q

Un generador de números aleatorios de curva elíptica evita las claves de depósito al elegir un punto Q en la curva elíptica como verificablemente aleatorio. El uso intencional de claves de depósito puede proporcionar una función de respaldo. La relación entre P y Q se utiliza como clave de depósito y se almacena para un dominio de seguridad. El administrador registra la salida del generador para reconstruir el número aleatorio con la clave de depósito.

2) Pequeño truncamiento de salida

[0041] Otro método alternativo para prevenir un ataque de custodia de claves en la salida de un ECRNG, mostrado en las Figuras 3 y 4, es añadir una función de truncamiento al ECRNG para truncar la salida del ECRNG a aproximadamente la mitad de la longitud de un punto de curva elíptica comprimido. Preferiblemente, esta operación se realiza además del método preferido de las Figuras 1 y 2, sin embargo, se apreciará que puede realizarse como una medida primaria para prevenir un ataque de custodia de claves. El beneficio del truncamiento es que la lista de valores R asociados con una única salida r del ECRNG es típicamente inviable de buscar. Por ejemplo, para un grupo de curva elíptica de 160 bits, el número de puntos potenciales R en la lista es aproximadamente 2 ⁸⁰ , y buscar en la lista sería casi tan difícil como resolver el problema del logaritmo discreto. El costo de este método es que el ECRNG se vuelve la mitad de eficiente, porque la longitud de salida se reduce efectivamente a la mitad.

Según John Kelsey, la opción en el estándar para elegir un Q aleatorio verificable se agregó como una opción en respuesta a la puerta trasera sospechada, ^[15] aunque de tal manera que la validación FIPS 140-2 solo se pudiera lograr utilizando el Q posiblemente con puerta trasera . ^[37] Steve Marquess (que ayudó a implementar NIST SP 800-90A para OpenSSL) especuló que este requisito de usar los puntos potencialmente con puerta trasera podría ser evidencia de la complicidad del NIST. ^[42] No está claro por qué el estándar no especificó el Q predeterminado en el estándar como un número generado verificablemente de nothing up my sleeve , o por qué el estándar no usó un truncamiento mayor, que la patente de Brown decía que podría usarse como la "medida principal para prevenir un ataque de depósito de claves". El pequeño truncamiento era inusual en comparación con los PRG de EC anteriores, que según Matthew Green solo habían emitido entre 1/2 y 2/3 de los bits en la función de salida. ^[5] En 2006, Gjøsteen demostró que el bajo truncamiento hace que el RNG sea predecible y, por lo tanto, inutilizable como CSPRNG, incluso si no se hubiera elegido Q para contener una puerta trasera. ^[20] El estándar dice que las implementaciones "deberían" utilizar el pequeño max_outlen proporcionado, pero da la opción de generar un múltiplo de 8 bits menos. El Apéndice C del estándar ofrece un argumento vago de que generar menos bits hará que la salida esté distribuida de manera menos uniforme. La prueba de seguridad de Brown de 2006 se basa en que outlen es mucho menor que el valor max_outlen predeterminado en el estándar.

El grupo de normas y directrices de la herramienta ANSI X9F1 que analizó la puerta trasera también incluyó a tres empleados de la destacada empresa de seguridad RSA Security. ^[6] En 2004, RSA Security implementó Dual_EC_DRBG que contenía la puerta trasera de la NSA (CSPRNG) predeterminada en su RSA BSAFE como resultado de un acuerdo secreto de 10 millones de dólares con la NSA. En 2013, después de que el New York Times informara que Dual_EC_DRBG contenía una puerta trasera de la NSA, RSA Security dijo que no sabían de ninguna puerta trasera cuando hicieron el acuerdo con la NSA y les dijeron a sus clientes que cambiaran a CSPRNG. En la conferencia principal de RSA de 2014, el presidente ejecutivo de RSA Security, Art Coviello, explicó que RSA había visto una disminución de los ingresos por cifrado y había decidido dejar de ser "impulsores" de la investigación independiente sobre cifrado, y en su lugar "poner su confianza en" los estándares y la orientación de organizaciones de estándares como NIST. ^[32]

En diciembre de 2005 se publicó un borrador de NIST SP 800-90A que incluía Dual_EC_DRBG. La versión final de NIST SP 800-90A que incluía Dual_EC_DRBG se publicó en junio de 2006. Los documentos filtrados por Snowden han sido interpretados como una sugerencia de que la NSA introdujo una puerta trasera en Dual_EC_DRBG, y quienes hacen la acusación citan el trabajo de la NSA durante el proceso de estandarización para finalmente convertirse en el único editor del estándar. ^[7] El uso temprano de Dual_EC_DRBG por parte de RSA Security (por el que luego se informó que la NSA había pagado en secreto 10 millones de dólares) fue citado por la NSA como un argumento para la aceptación de Dual_EC_DRBG en el estándar NIST SP 800-90A . ^[2] Posteriormente, RSA Security citó la aceptación de Dual_EC_DRBG en el estándar NIST como una razón para usar Dual_EC_DRBG. ^[43]

El artículo de marzo de 2006 de Daniel RL Brown sobre la reducción de seguridad de Dual_EC_DRBG menciona la necesidad de un mayor truncamiento de salida y una Q elegida aleatoriamente , pero principalmente de pasada, y no menciona sus conclusiones de su patente de que estos dos defectos en Dual_EC_DRBG juntos pueden usarse como una puerta trasera. Brown escribe en la conclusión: "Por lo tanto, el ECRNG debe ser una consideración seria, y su alta eficiencia lo hace adecuado incluso para entornos restringidos". Tenga en cuenta que otros han criticado Dual_EC_DRBG por ser extremadamente lento, con Bruce Schneier concluyendo "Es demasiado lento para que alguien lo use voluntariamente", ^[4] y Matthew Green diciendo que Dual_EC_DRBG es "Hasta mil veces más lento" que las alternativas. ^[5] El potencial de una puerta trasera en Dual_EC_DRBG no fue ampliamente publicitado fuera de las reuniones internas del grupo de estándares. Fue solo después de la presentación de Dan Shumow y Niels Ferguson en 2007 que el potencial de una puerta trasera se hizo ampliamente conocido. Shumow y Ferguson habían recibido el encargo de implementar Dual_EC_DRBG para Microsoft, y al menos Furguson había discutido la posible puerta trasera en una reunión de X9 en 2005. ^[15] Bruce Schneier escribió en un artículo de Wired de 2007 que las fallas de Dual_EC_DRBG eran tan obvias que nadie usaría Dual_EC_DRBG: "No tiene sentido como trampilla: es pública y bastante obvia. No tiene sentido desde una perspectiva de ingeniería: es demasiado lenta para que alguien la use voluntariamente". ^[4] Schneier aparentemente no sabía que RSA Security había usado Dual_EC_DRBG como predeterminado en BSAFE desde 2004.

OpenSSL implementó todo el NIST SP 800-90A, incluido Dual_EC_DRBG, a pedido de un cliente. Los desarrolladores de OpenSSL estaban al tanto de la posible puerta trasera debido a la presentación de Shumow y Ferguson, y querían usar el método incluido en el estándar para elegir un P y Q sin puerta trasera garantizada , pero se les dijo que para obtener la validación FIPS 140-2 tendrían que usar el P y Q predeterminados . OpenSSL eligió implementar Dual_EC_DRBG a pesar de su dudosa reputación de integridad, y señaló que OpenSSL intentó ser completo e implementa muchos otros algoritmos inseguros. OpenSSL no usó Dual_EC_DRBG como CSPRNG predeterminado, y se descubrió en 2013 que un error hizo que la implementación de OpenSSL de Dual_EC_DRBG no funcionara, lo que significa que nadie podría haberlo estado usando. ^[37]

Bruce Schneier informó en diciembre de 2007 que Microsoft agregó soporte Dual_EC_DRBG a Windows Vista, aunque no está habilitado de manera predeterminada, y Schneier advirtió sobre la conocida puerta trasera potencial. ^[44] Windows 10 y versiones posteriores reemplazarán silenciosamente las llamadas a Dual_EC_DRBG con llamadas a CTR_DRBG basadas en AES. ^[45]

El 9 de septiembre de 2013, tras la filtración de Snowden y el informe del New York Times sobre la puerta trasera en Dual_EC_DRBG, el Instituto Nacional de Estándares y Tecnología (NIST) ITL anunció que, en vista de las preocupaciones de seguridad de la comunidad, estaba reeditando SP 800-90A como borrador de estándar y reabriendo SP800-90B/C para comentarios públicos. NIST ahora "recomienda firmemente" no usar Dual_EC_DRBG, como se especifica en la versión de enero de 2012 de SP 800-90A. ^{[46] [47]} El descubrimiento de una puerta trasera en un estándar NIST ha sido una gran vergüenza para el NIST . ^[48]

RSA Security había mantenido Dual_EC_DRBG como el CSPRNG predeterminado en BSAFE incluso después de que la comunidad criptográfica más amplia se enterara de la posible puerta trasera en 2007, pero no parece haber habido una conciencia general del uso de Dual_EC_DRBG por parte de BSAFE como una opción de usuario en la comunidad. Solo después de la preocupación generalizada sobre la puerta trasera hubo un esfuerzo por encontrar software que usara Dual_EC_DRBG, de los cuales BSAFE fue, con mucho, el más destacado encontrado. Después de las revelaciones de 2013, el jefe de tecnología de seguridad de RSA, Sam Curry, proporcionó a Ars Technica una justificación para elegir originalmente el estándar defectuoso Dual EC DRBG como predeterminado sobre los generadores de números aleatorios alternativos. ^[49] La precisión técnica de la declaración fue ampliamente criticada por los criptógrafos, incluidos Matthew Green y Matt Blaze . ^[28] El 20 de diciembre de 2013, Reuters informó que RSA había aceptado un pago secreto de 10 millones de dólares de la NSA para configurar el generador de números aleatorios Dual_EC_DRBG como predeterminado en dos de sus productos de cifrado. ^{[2] [50]} El 22 de diciembre de 2013, RSA publicó una declaración en su blog corporativo negando "categóricamente" un acuerdo secreto con la NSA para insertar un "generador de números aleatorios con fallas conocidas" en su kit de herramientas BSAFE. ^[3]

Después de que el New York Times publicara un artículo que afirmaba que Dual_EC_DRBG contenía una puerta trasera, Brown (que había solicitado la patente de la puerta trasera y publicado la reducción de seguridad) escribió un correo electrónico a una lista de correo de la IETF defendiendo el proceso estándar Dual_EC_DRBG: ^[38]

1. Dual_EC_DRBG, tal como se especifica en NIST SP 800-90A y ANSI X9.82-3, permite una elección alternativa de las constantes P y Q. Hasta donde sé, las alternativas no admiten una puerta trasera factible conocida. En mi opinión, es incorrecto dar a entender que Dual_EC_DRBG siempre tiene una puerta trasera, aunque admito que una redacción para calificar los casos afectados puede ser incómoda.

2. Muchas cosas son obvias en retrospectiva. No estoy seguro de si esto era obvio. [...]

8. En definitiva, no veo cómo las normas ANSI y NIST para Dual_EC_DRBG pueden considerarse una norma subvertida, per se. Pero tal vez sea simplemente porque soy parcial o ingenuo.

—  Daniel Brown, ^[38]

Software y hardware que contenía la posible puerta trasera

Las implementaciones que utilizaban Dual_EC_DRBG normalmente lo habrían obtenido a través de una biblioteca. Al menos RSA Security (biblioteca BSAFE), OpenSSL , Microsoft y Cisco ^[51] tienen bibliotecas que incluían Dual_EC_DRBG, pero solo BSAFE lo utilizaba por defecto. Según el artículo de Reuters que reveló el acuerdo secreto de 10 millones de dólares entre RSA Security y la NSA, BSAFE de RSA Security era el distribuidor más importante del algoritmo. ^[2] Había una falla en la implementación de Dual_EC_DRBG de OpenSSL que lo hacía no funcionar fuera del modo de prueba, de lo cual Steve Marquess de OpenSSL concluye que nadie utilizó la implementación Dual_EC_DRBG de OpenSSL. ^[37]

En el NIST se encuentra disponible una lista de productos cuya implementación CSPRNG ha sido validada según la norma FIPS 140-2. ^[52] Los CSPRNG validados se enumeran en el campo Descripción/Notas. Tenga en cuenta que, incluso si Dual_EC_DRBG figura como validado, es posible que no se haya habilitado de forma predeterminada. Muchas implementaciones provienen de una copia renombrada de una implementación de biblioteca. ^[53]

El software de BlackBerry es un ejemplo de uso no predeterminado. Incluye soporte para Dual_EC_DRBG, pero no como predeterminado. Sin embargo, BlackBerry Ltd no ha emitido un aviso a ninguno de sus clientes que puedan haberlo utilizado, porque no consideran que la probable puerta trasera sea una vulnerabilidad. ^[54] Jeffrey Carr cita una carta de Blackberry: ^[54]

El algoritmo Dual EC DRBG solo está disponible para desarrolladores externos a través de las API criptográficas en la plataforma [Blackberry]. En el caso de la API criptográfica, está disponible si un desarrollador externo desea utilizar la funcionalidad y diseñó y desarrolló explícitamente un sistema que solicita el uso de la API.

Bruce Schneier ha señalado que incluso si no está habilitado de forma predeterminada, tener un CSPRNG con puerta trasera implementado como una opción puede facilitar que la NSA espíe a objetivos que tienen un interruptor de línea de comandos controlado por software para seleccionar el algoritmo de cifrado, o un sistema de " registro ", como la mayoría de los productos de Microsoft , como Windows Vista :

Un troyano es algo muy, muy grande. No se puede decir que haya sido un error. Es un fragmento enorme de código que recopila las pulsaciones de teclas. Pero cambiar un bit uno por un bit dos [en el registro para cambiar el generador de números aleatorios predeterminado en la máquina] probablemente no se detecte. Es una forma poco conspirativa y muy fácil de negar de conseguir una puerta trasera. Por lo tanto, hay un beneficio en introducirlo en la biblioteca y en el producto.

—Bruce  Schneier, ^[51]

En diciembre de 2013, se publicó una puerta trasera de prueba de concepto ^{[39] que utiliza el estado interno filtrado para predecir números aleatorios posteriores, un ataque viable hasta la próxima resiembra.}

En diciembre de 2015, Juniper Networks anunció ^[55] que algunas revisiones de su firmware ScreenOS usaban Dual_EC_DRBG con los puntos P y Q sospechosos , creando una puerta trasera en su firewall. Originalmente se suponía que usaría un punto Q elegido por Juniper que puede o no haber sido generado de manera demostrablemente segura. Luego, Dual_EC_DRBG se usó para generar ANSI X9.17 PRNG. Esto habría ofuscado la salida de Dual_EC_DRBG, matando así la puerta trasera. Sin embargo, un "error" en el código expuso la salida sin procesar de Dual_EC_DRBG, comprometiendo así la seguridad del sistema. Esta puerta trasera luego fue bloqueada por una parte desconocida que cambió el punto Q y algunos vectores de prueba. ^{[56] [57] [58]} Las acusaciones de que la NSA tenía acceso persistente por puerta trasera a través de los firewalls de Juniper ya habían sido publicadas en 2013 por Der Spiegel . ^[59] La puerta trasera cleptográfica es un ejemplo de la política NOBUS de la NSA , de tener agujeros de seguridad que sólo ellos pueden explotar.

Véase también

• Ataque con generador de números aleatorios
• Crypto AG , una empresa suiza especializada en seguridad de las comunicaciones y la información , que según se cree permitió a las agencias de seguridad occidentales (incluida la NSA) insertar puertas traseras en sus máquinas de criptografía ^[60]

Referencias

1. Barker, EB; Kelsey, JM (enero de 2012). "Recomendaciones para la generación de números aleatorios utilizando generadores de bits aleatorios deterministas (revisados)" (PDF) . Instituto Nacional de Estándares y Tecnología . doi : 10.6028/NIST.SP.800-90A . NIST SP 800-90. Archivado (PDF) desde el original el 2013-10-09 . Consultado el 2013-09-11 . {{cite journal}}: Requiere citar revista |journal=( ayuda )
2. Menn, Joseph (20 de diciembre de 2013). «Exclusiva: contrato secreto vinculó a la NSA y a un pionero de la industria de seguridad». Reuters . San Francisco. Archivado desde el original el 24 de septiembre de 2015. Consultado el 20 de diciembre de 2013 .
3. División de Seguridad de EMC, RSA. "Respuesta de RSA a las afirmaciones de los medios sobre la relación con la NSA". RSA. Archivado desde el original el 23 de diciembre de 2013. Consultado el 22 de diciembre de 2013 .
4. Bruce Schneier (15 de noviembre de 2007). "¿La NSA puso una puerta trasera secreta en el nuevo estándar de cifrado?". Wired News . Archivado desde el original el 21 de junio de 2014.
5. Green, Matthew (18 de septiembre de 2013). "Los numerosos defectos de Dual_EC_DRBG". Archivado desde el original el 20 de agosto de 2016. Consultado el 22 de septiembre de 2013 .
6. Green, Matthew (28 de diciembre de 2013). "Algunas reflexiones sobre ingeniería criptográfica: algunas notas más sobre los generadores de números aleatorios de la NSA". Blog.cryptographyengineering.com. Archivado desde el original el 26 de enero de 2016. Consultado el 23 de diciembre de 2015 .
7. Ball, James; Borger, Julian; Greenwald, Glenn (6 de septiembre de 2013). «Revelado: cómo las agencias de espionaje de Estados Unidos y el Reino Unido derrotan la privacidad y la seguridad en Internet». The Guardian . Archivado desde el original el 18 de septiembre de 2013. Consultado el 14 de diciembre de 2016 .
8. Perlroth, Nicole (10 de septiembre de 2013). «Gobierno anuncia medidas para restablecer la confianza en los estándares de cifrado». The New York Times . Archivado desde el original el 12 de julio de 2014. Consultado el 11 de septiembre de 2013 .
9. Swenson, Gayle (10 de septiembre de 2013). «Declaración de estándares criptográficos». NIST . Archivado desde el original el 25 de agosto de 2016. Consultado el 15 de febrero de 2018 .
10. "Documentos secretos revelan una campaña de la NSA contra el cifrado". The New York Times . 5 de septiembre de 2013. Archivado desde el original el 11 de febrero de 2018 . Consultado el 1 de marzo de 2017 .
11. "La NSA debería dejar de socavar los estándares de cifrado, dice el panel de Obama". Ars Technica . 2013-12-18. Archivado desde el original el 2018-03-04 . Consultado el 2017-06-14 .
12. "NIST elimina algoritmo de criptografía de recomendaciones de generadores de números aleatorios". Instituto Nacional de Estándares y Tecnología . 21 de abril de 2014. Archivado desde el original el 29 de agosto de 2016. Consultado el 13 de julio de 2017 .
13. Young, Adam; Yung, Moti (11 de mayo de 1997). "Kleptografía: uso de la criptografía contra la criptografía". Avances en criptología — EUROCRYPT '97. Apuntes de clase sobre informática. Vol. 1233. Springer, Berlín, Heidelberg. págs. 62–74. doi :10.1007/3-540-69053-0_6. ISBN 978-3-540-69053-5– vía ResearchGate .
14. Young, Adam; Yung, Moti (17 de agosto de 1997). "La prevalencia de ataques cleptográficos en criptosistemas basados ​​en registros discretos". Avances en criptología — CRYPTO '97. Apuntes de clase en informática. Vol. 1294. Springer, Berlín, Heidelberg. págs. 264–276. doi :10.1007/bfb0052241. ISBN 978-3-540-63384-6– vía ResearchGate .
15. http://csrc.nist.gov/groups/ST/crypto-review/documents/dualec_in_X982_and_sp800-90.pdf Archivado el 29 de noviembre de 2015 en Wayback Machine ^{[ URL básica PDF ]}
16. "'Error en el DRBG de EC dual (no, ese no)' – MARC". Marc.info. 2013-12-19. Archivado desde el original el 2014-10-16 . Consultado el 2015-12-23 .
17. Goh, EJ; Boneh, D.; Pinkas, B.; Golle, P. (2003). El diseño y la implementación de la recuperación de claves ocultas basada en protocolos . ISC.
18. US 2007189527, Brown, Daniel RL y Vanstone, Scott A., "Generación de números aleatorios de curva elíptica", asignado a Certicom Corp. 
19. "ISO/IEC 18031:2005 – Tecnología de la información – Técnicas de seguridad – Generación aleatoria de bits". Iso.org. Archivado desde el original el 2016-03-03 . Consultado el 2015-12-23 .
20. "Copia archivada" (PDF) . Archivado desde el original (PDF) el 25 de mayo de 2011 . Consultado el 16 de noviembre de 2007 .{{cite web}}: CS1 maint: copia archivada como título ( enlace )
21. Daniel RL Brown (2006). "Seguridad conjeturada del generador de números aleatorios de curva elíptica ANSI-NIST". Archivo de ePrints de criptología . Archivado desde el original el 21 de noviembre de 2007. Consultado el 16 de noviembre de 2007 .
22. Schoenmakers, Berry; Sidorenko, Andrey (29 de mayo de 2006). "Criptoanálisis del generador pseudoaleatorio de curva elíptica dual". Archivo de criptografía ePrint . Archivado desde el original el 18 de noviembre de 2007. Consultado el 15 de noviembre de 2007 .
23. Adam L. Young, Moti Yung (2007). Cleptografía con uso eficiente del espacio sin oráculos aleatorios . Ocultación de información.
24. Shumow, Dan; Ferguson, Niels. "Sobre la posibilidad de una puerta trasera en el NIST SP800-90 Dual Ec PRNG" (PDF) . Microsoft. Archivado (PDF) desde el original el 23 de octubre de 2007. Consultado el 15 de noviembre de 2007 .
25. Perlroth, Nicole (10 de septiembre de 2013). «Gobierno anuncia medidas para restablecer la confianza en los estándares de cifrado». The New York Times . Archivado desde el original el 12 de julio de 2014. Consultado el 11 de septiembre de 2013 .
26. "Declaración de estándares criptográficos". NIST . Nist.gov. 10 de septiembre de 2013. Archivado desde el original el 12 de septiembre de 2013. Consultado el 23 de diciembre de 2015 .
27. NIST, Instituto Nacional de Estándares y Tecnología. "BOLETÍN SUPLEMENTARIO DEL ITL PARA SEPTIEMBRE DE 2013" (PDF) . NIST.gov. Archivado (PDF) del original el 27 de septiembre de 2013. Consultado el 12 de septiembre de 2013 .
28. Matthew Green (20 de septiembre de 2013). "RSA advierte a los desarrolladores que no utilicen productos RSA". Algunas reflexiones sobre ingeniería criptográfica. Archivado desde el original el 29 de diciembre de 2013. Consultado el 28 de septiembre de 2013 .
29. "RSA niega vínculos con agencia de espionaje estadounidense". BBC News . 23 de diciembre de 2013. Archivado desde el original el 6 de noviembre de 2018 . Consultado el 20 de junio de 2018 .
30. "La 'negación' de RSA sobre los 10 millones de dólares de la NSA para promocionar criptomonedas defectuosas no es en realidad una negación en absoluto". Techdirt. 23 de diciembre de 2013. Archivado desde el original el 24 de diciembre de 2015. Consultado el 23 de diciembre de 2015 .
31. Goodin, Dan (23 de diciembre de 2013). "RSA emite una negación sin reservas del acuerdo con la NSA para favorecer un código criptográfico defectuoso". Ars Technica . Archivado desde el original el 24 de diciembre de 2015 . Consultado el 23 de diciembre de 2015 .
32. Jeffrey Carr (26 de febrero de 2014). "Seis criptógrafos cuyo trabajo en el DRBG de EC dual fue considerado sin mérito por el jefe de RSA, Art Coviello". Digital Dao. Archivado desde el original el 3 de marzo de 2014. Consultado el 27 de febrero de 2014 .
33. S. Checkoway; M. Fredrikson; R. Niederhagen; A. Everspaugh; M. Green; T. Lange ; T. Ristenpart; DJ Bernstein; J. Maskiewicz; H. Shacham (2014). Sobre la explotabilidad práctica de la EC dual en implementaciones de TLS . Simposio de seguridad de USENIX.
34. https://www.ams.org/journals/notices/201502/rnoti-p165.pdf Archivado el 9 de febrero de 2022 en Wayback Machine ^{[ URL básica PDF ]}
35. Kristian Gjøsteen. Comentarios sobre Dual-EC-DRBG/NIST SP 800-90 Archivado el 25 de mayo de 2011 en Wayback Machine.
36. Brown, Daniel RL; Gjøsteen, Kristian (19 de agosto de 2007). "Un análisis de seguridad del generador de números aleatorios de curva elíptica NIST SP 800-90". Avances en criptología - CRYPTO 2007. Apuntes de clase en informática. Vol. 4622. Springer, Berlín, Heidelberg. págs. 466–481. doi :10.1007/978-3-540-74143-5_26. ISBN 978-3-540-74142-8Archivado desde el original el 16 de febrero de 2018. Consultado el 15 de febrero de 2018 a través de Cryptology ePrint Archive .
37. Steve Marquess. "Error en el DRBG de EC dual (no, ese no)". Proyecto OpenSSL. Archivado desde el original el 2014-10-16 . Consultado el 2013-12-27 .
38. "[Cfrg] Dual_EC_DRBG ... [era RE: Solicitud de destitución del copresidente de CFRG]". Ietf.org. 2013-12-27. Archivado desde el original el 2016-08-18 . Consultado el 2015-12-23 .
39. "Aris ADAMANTIADIS: "Dual_Ec_Drbg backdoor: a proof of concept" 31 de diciembre de 2013". 31 de diciembre de 2013. Archivado desde el original el 17 de diciembre de 2014 . Consultado el 2 de enero de 2014 .
40. "Los numerosos defectos de Dual_EC_DRBG". 18 de septiembre de 2013. Archivado desde el original el 20 de agosto de 2016. Consultado el 20 de noviembre de 2016 .
41. Green, Matthew (14 de enero de 2015). "Algunas reflexiones sobre ingeniería criptográfica: espero que sea la última publicación que escriba sobre el DRBG de EC dual". Blog.cryptographyengineering.com. Archivado desde el original el 28 de diciembre de 2015. Consultado el 23 de diciembre de 2015 .
42. Steve Marquess. "Seguridad o cumplimiento, elija una opción". Archivado desde el original el 27 de diciembre de 2013.
43. "No habilitamos puertas traseras en nuestros productos criptográficos, informa RSA a sus clientes". Ars Technica . 20 de septiembre de 2013. Archivado desde el original el 12 de octubre de 2014. Consultado el 14 de junio de 2017 .
44. "Dual_EC_DRBG añadido a Windows Vista – Schneier on Security". Schneier.com. 17 de diciembre de 2007. Archivado desde el original el 10 de junio de 2018. Consultado el 23 de diciembre de 2015 .
45. "Identificadores de algoritmos CNG". Microsoft Developer Network . Archivado desde el original el 13 de febrero de 2017. Consultado el 19 de noviembre de 2016 .
46. http://csrc.nist.gov/publications/nistbul/itlbul2013_09_supplemental.pdf Archivado el 27 de septiembre de 2013 en Wayback Machine ^{[ URL básica PDF ]}
47. Perlroth, Nicole (10 de septiembre de 2013). «Gobierno anuncia medidas para restablecer la confianza en los estándares de cifrado». New York Times . Archivado desde el original el 12 de julio de 2014. Consultado el 11 de septiembre de 2013 .
48. Hay, Lily (9 de octubre de 2013). "¿Se puede confiar en el NIST? - IEEE Spectrum". IEEE . Archivado desde el original el 1 de febrero de 2016 . Consultado el 23 de diciembre de 2015 .
49. "RSA recomienda a sus clientes que dejen de utilizar códigos influenciados por la NSA en nuestros productos". Ars Technica . 19 de septiembre de 2013. Archivado desde el original el 7 de junio de 2017 . Consultado el 14 de junio de 2017 .
50. "Un contrato de 10 millones de dólares de la NSA con la empresa de seguridad RSA condujo a una 'puerta trasera' de cifrado". The Guardian . 20 de diciembre de 2013. Archivado desde el original el 25 de enero de 2014 . Consultado el 14 de diciembre de 2016 .
51. "wired.com: "Cómo una 'puerta trasera' criptográfica enfrentó al mundo tecnológico contra la NSA" (Zetter) 24 de septiembre de 2013". Archivado desde el original el 1 de febrero de 2014. Consultado el 6 de marzo de 2017 .
52. "NIST: "Lista de validación de DRBG"". Archivado desde el original el 29 de diciembre de 2013. Consultado el 30 de diciembre de 2013 .
53. "Velocidades y avances › Seguro o compatible, elija uno". Veridicalsystems.com. Archivado desde el original el 2013-12-27 . Consultado el 2015-12-23 .
54. "Digital Dao: "Evolving Hostilities in the Global Cyber ​​Commons" 24 Jan 2014". Archivado desde el original el 2 de febrero de 2014 . Consultado el 25 de enero de 2014 .
55. Derrick Scholl (17 de diciembre de 2015). «Anuncio importante sobre ScreenOS». Juniper Networks . Archivado desde el original el 21 de diciembre de 2015. Consultado el 22 de diciembre de 2015 .
56. Green, Matthew (22 de diciembre de 2015). "Sobre la puerta trasera de Juniper". Algunas reflexiones sobre ingeniería criptográfica . Archivado desde el original el 29 de agosto de 2016. Consultado el 23 de diciembre de 2015 .
57. Weinmann, Ralf-Philipp. "Algunos análisis de la puerta trasera con puerta trasera". RPW . Archivado desde el original el 2015-12-22 . Consultado el 2015-12-22 .
58. "Investigadores resuelven el misterio de la puerta trasera de Juniper; las señales apuntan a la NSA". Wired . 22 de diciembre de 2015. Archivado desde el original el 14 de noviembre de 2016 . Consultado el 22 de diciembre de 2015 .
59. Dan Goodin - (18 de diciembre de 2015). «"Código no autorizado" en los cortafuegos de Juniper descifra el tráfico VPN cifrado». Ars Technica . Archivado desde el original el 22 de diciembre de 2015 . Consultado el 22 de diciembre de 2015 .
60. "Operación encubierta de espionaje: pocos en la fábrica suiza sabían que los misteriosos visitantes estaban llevando a cabo un sorprendente golpe de inteligencia, tal vez el más audaz en la larga guerra de la Agencia de Seguridad Nacional contra los códigos extranjeros - tribunedigital-baltimoresun". Articles.baltimoresun.com. 1995-12-10. Archivado desde el original el 2011-08-27 . Consultado el 2015-12-23 .

Enlaces externos

• NIST SP 800-90A: recomendación para la generación de números aleatorios mediante generadores de bits aleatorios deterministas
• Dual EC DRBG: recopilación de información Dual_EC_DRBG, por Daniel J. Bernstein , Tanja Lange y Ruben Niederhagen.
• Sobre la explotabilidad práctica de EC dual en implementaciones de TLS: artículo de investigación clave de Stephen Checkoway et al.
• La prevalencia de ataques cleptográficos en criptosistemas basados ​​en registros discretos – Adam L. Young, Moti Yung (1997)
• Publicación de solicitud de patente de Estados Unidos US 2007189527, Brown, Daniel RL y Vanstone, Scott A., "Generación de números aleatorios de curva elíptica", asignada a Certicom Corp. sobre la puerta trasera Dual_EC_DRBG y formas de negar la puerta trasera. 
• Comentarios sobre Dual-EC-DRBG/NIST SP 800-90, borrador de diciembre de 2005 Artículo de Kristian Gjøsteen de marzo de 2006 que concluye que Dual_EC_DRBG es predecible y, por lo tanto, inseguro.
• Análisis de seguridad del generador de números aleatorios de curva elíptica NIST SP 800-90 Análisis de seguridad de 2007 de Dual_EC_DRBG realizado por Daniel RL Brown y Kristian Gjøsteen. Aunque al menos Brown conocía la puerta trasera (por su patente de 2005), no se la menciona explícitamente. Se asume el uso de constantes sin puerta trasera y un truncamiento de bits de salida mayor que el especificado por Dual_EC_DRBG.
• Sobre la posibilidad de una puerta trasera en el NIST SP800-90 Dual Ec Prng Presentación de Dan Shumow y Niels Ferguson, que dio a conocer ampliamente la posible puerta trasera.
• Los numerosos defectos de Dual_EC_DRBG: explicación simplificada de Matthew Green sobre cómo y por qué funciona la puerta trasera.
• Algunas notas más sobre los generadores de números aleatorios de la NSA – Matthew Green
• Lo siento, RSA, no lo compro: resumen y cronología de Dual_EC_DRBG y conocimiento público.
• [Cfrg] Dual_EC_DRBG ... [era RE: Solicitud de eliminación del copresidente de CFRG] Un correo electrónico de diciembre de 2013 de Daniel RL Brown defendiendo Dual_EC_DRBG y el proceso estándar.
• DUELO POR DUAL_EC_DRBG: LAS CONSECUENCIAS DE CORROMPER UN PROCESO DE ESTANDARIZACIÓN CRIPTOGRÁFICA Artículo de Kostsyuk y Landau sobre la confianza en gran medida continua de la comunidad criptográfica internacional en el NIST a pesar del Dual EC DRBG.