NIST SP 800-90A - ("SP" es la abreviatura de S pecial P ublication " , "publicación especial") es una publicación del Instituto Nacional de Estándares y Tecnología ( NIST ) con el título "Recomendación para generar números aleatorios utilizando generadores deterministas". bits aleatorios "( ing. "Recomendación para la generación de números aleatorios utilizando generadores de bits aleatorios deterministas" ). La publicación contiene descripciones de tres generadores de números pseudoaleatorios supuestamente fuertes criptográficamente para su uso en criptografía : Hash_DRBG (basado en funciones hash ), HMAC_DRBG (basado en el hash de autenticación de mensajes ) y CTR_DRBG (basado en cifrados de bloque en modo contador ).
A partir del 24 de junio de 2015, la versión actual de la publicación es la Revisión 1 ( " Revisión 1" ). Las versiones anteriores incluían un cuarto generador, Dual_EC_DRBG (basado en criptografía elíptica ). Más tarde se informó que Dual_EC_DRBG probablemente contiene una puerta trasera cleptográfica , implementada por la Agencia de Seguridad Nacional , mientras que los otros tres generadores de números aleatorios son aceptados como consistentes y seguros por varios criptógrafos [1] [2] .
NIST SP 800-90A es de dominio público y es de dominio público, ya que es un estudio del gobierno federal de EE . UU .
HASH-DRBG se basa en la función hash SH : {0, 1} ∗ → {0, 1} l de la familia SHA de funciones hash criptográficas [3] . El estado tiene la forma S = (V, C, cnt) , donde V ∈ {0, 1} len es un contador que se procesa para crear bloques hoja, cuyo valor se actualiza durante cada llamada del generador; С es una constante que depende del elemento principal ( eng. seed ), y cnt es el contador de recarga. cnt indica el número de solicitudes de bits pseudoaleatorios desde que se recibió el nuevo valor del generador aleatorio verdadero durante la creación de instancias o la repoblación.
Algoritmo de generación para HASH-DRBG. Si se usa una entrada adicional en la llamada para generar, se codifica y se agrega al contador V módulo 2 len durante el proceso de inicialización. Los bloques de salida r j se forman luego mediante el hash del contador V . Al final de la llamada, el contador se codifica con un prefijo separado y la cadena resultante, junto con la constante C y cnt , se agrega a V , el resultado de tal operación se da como el contador actualizado.
La constante C se actualiza solo durante la repoblación (cuando nuevamente es un derivado de la nueva variable V ) y se agrega a la variable de estado V durante cada actualización de estado. La constante C asegura que incluso si el contador anterior V se duplica en algún momento en diferentes períodos de recarga (casi con certeza diferentes), el contador evitará que la secuencia anterior de estados se repita la próxima vez que se actualice el valor. La norma define V y C como variables críticas de estado de seguridad [3] .
Datos de entrada: S = (V, C, cnt), β, suma Salida: S' = (V', C, cnt'), R si 0 ← comprobar (S, β, suma) entonces Devolver (error, ⊥) si sumando ≠ ε entonces w ← SH(0x02||V||complemento) V0 = (V + w) mod 2^len más V(0) ← V temperatura ← e metro ← [β/l] para j = 1, . . . , lo hago r(j) ← SH(V(j−1)) V(j) ← (V(j−1) + 1) mod 2^len temperatura ← temperatura||r(j) R ← izquierda (temperatura, β) H ← SH(0x03||V(0)) V' ← (V(0) + H + C + cnt) mod 2^len cnt' ← cnt + 1 retorno (V', C, cnt')HMAC es un código de autenticación de mensajes basado en hash que fue introducido por Mihir Bellare y colegas [ 4] y posteriormente estandarizado [5] . HMAC-DRBG utiliza HMAC: {0, 1} l × {0, 1} * → {0, 1} l para generar bloques de salida pseudoaleatorios. El estado tiene la forma S = (K, V, cnt) , donde el estándar define K y V como variables de estado secretas críticas para la seguridad. Se supone que después de la inicialización, el estado inicial es S 0 = (K 0 , V 0 , cnt 0 ) , donde cnt 0 = 1 y K 0 , V 0 ← {0, 1} len . Aquí K ∈ {0, 1} l se usa como clave HMAC, V ∈ {0, 1} l es el contador y cnt denota el contador de recarga [3] .
El algoritmo de generación usa la función de actualización, que se usa para agregar cualquier entrada adicional a las variables de estado K y V , y actualiza ambas en un solo sentido. Si se incluye una entrada adicional en la llamada, se realizan un par adicional de actualizaciones. El algoritmo de generación en sí para HMAC-DRBG funciona de la siguiente manera: el proceso de inicialización agrega cualquier entrada adicional a las variables de estado a través de la función de actualización; si no se incluyen entradas adicionales en la llamada, el estado permanece sin cambios. Para K 0 , V 0 denotamos las variables de estado correspondientes a este proceso, después de lo cual los bloques resultantes se generan automáticamente aplicando iterativamente el algoritmo HMAC(K 0 ,·) para el contador de corriente V j-1 , el bloque de salida r j y el siguiente valor del contador V j es igual a la cadena resultante. La clave K 0 permanece sin cambios a lo largo de cada iteración. Cuando se completa la llamada, el proceso final actualiza K y V con la función de actualización [3] . función de actualización
Datos de entrada: complemento, K, V Datos de salida: K, V K ← HMAC(K, V||0x00||complemento) V ← HMAC(K, V) si sumando ≠ ε entonces K ← HMAC(K, V||0x01||complemento) V ← HMAC(K, V) volver (K, V)generar función
Datos de entrada: S = (K, V, cnt), β, suma Salida: S' = (K', V', cnt'), R si 0 ← comprobar (S, β, suma) entonces devolver (error, ⊥) si sumando ≠ ε entonces (K0, V0) ← actualizar (complemento, K, V) más (K0, V(0)) ← (K, V) temperatura ← e ; metro ← [β/l] para j = 1, . . . , lo hago V(j) ← HMAC(K0, V(j−1)) r(j) ← V(j) temperatura ← temperatura||r(j) R ← izquierda (temperatura, β) (K', V') ← actualizar(complemento, K0, V(m)) cnt' ← cnt + 1 retorno (R, (K', V', cnt'))CTR_DRBG se basa en un algoritmo de cifrado de bloques cuya función de cifrado E : {0, 1} k × {0, 1} l → {0, 1} l se utiliza en el modo CTR (modo contador). El estado tiene la forma S = (K, V, cnt) , donde K ∈ {0, 1} k se usa como clave para el cifrado de bloque, V ∈ {0, 1} l es el contador y cnt denota el contador de recargas. La norma establece que K y V son variables críticas de estado de seguridad. La inicialización devuelve el estado inicial S 0 = (К 0 , V 0 , cnt 0 ) , donde cnt 0 = 1 y K 0 ← {0, 1} k , V 0 ← {0, 1} l [3] .
Al igual que en HMAC_DRBG, el algoritmo usa la función de actualización para actualizar las variables de estado K y V unidireccionales , así como para incluir entradas de datos adicionales (que se pasan a la función de actualización a través del parámetro proporcionado_datos). La función ejecuta el cifrado de bloque en modo CTR utilizando la clave y el contador actuales, concatenando los bloques de salida resultantes r j . Luego, los bits κ+l más a la izquierda se truncan y los valores de datos proporcionados se alinean mediante la operación XOR. La función de actualización es llamada por cada uno de los otros procesos de tal manera que garantiza que los datos proporcionados tengan exactamente κ+1 bits de longitud [3] .
Hay dos opciones para CTR_DRBG dependiendo de si se está utilizando la función de generación. La función generadora CTR_DRBG df combina una función basada en CBC-MAC con la capacidad de extraer una salida casi uniforme de entradas de entropía suficientemente altas. Si no se utiliza la función generadora df , las cadenas de entrada adicionales se limitan a no más de (κ + l) — bits de longitud. El proceso de inicialización conecta cada entrada adicional a la función de actualización: si se usa una función de generación, entonces la cadena de entrada adicional es una cadena de (κ + l) -bits con CTR_DRBG df antes de iniciar este proceso. Si no se usa ninguna entrada adicional, el estado permanece sin cambios y addin tiene el valor 0 (κ+l) (para formar la entrada a la función de actualización durante el procedimiento final cuando se completa la llamada). Los bloques de salida r j luego se crean iterativamente con el cifrado de bloque en modo CTR. La clave K sigue siendo la misma a lo largo de todas estas iteraciones. Cuando se completa la llamada, el proceso final actualiza tanto K como V a través de una llamada para actualizar [3] . función de actualización
Datos de entrada: datos proporcionados, K, V Datos de salida: K, V temperatura ← e metro ← [(κ + l)/l] para j = 1, . . . , lo hago V ← (V + 1) módulo 2^l C(i) ← E(K, V) temperatura ← temperatura||Ci temperatura ← izquierda (temperatura, (κ + l)) K||V ← temp ⊕ datos proporcionados volver (K, V)generar función
Datos de entrada: S = (K, V, cnt), β, suma Salida: S' = (K', V', cnt'), R si 0 ← comprobar (S, β, suma) entonces devolver (error, ⊥) si sumando ≠ ε entonces si se usa la función de derivación entonces suma ← df(complemento, (κ + l)) de lo contrario, si len (complemento) < (κ + l) entonces suma ← suma||0^(κ+l−len(complemento)) (K0, V0) ← actualizar (complemento, K, V) más sumando ← 0^κ+l; (K0, V(0)) ← (K, V) temperatura ← e ; metro ← [β/l] para j = 1, . . . , lo hago V(j) ← (V(j−1) + 1) módulo 2^l r(j) ← E(K0, V(j)) temperatura ← temperatura||r(j) R ← izquierda (temperatura, β) (K', V') ← actualizar(complemento, K0, V(m)) cnt' ← cnt + 1 retorno (R, (K', V', cnt'))Dual_EC_DRBG se retiró de la publicación con el lanzamiento de la primera revisión del documento. La razón de esto fue la posible existencia de una puerta trasera . Una puerta trasera es un defecto incorporado deliberadamente en un algoritmo que permite el acceso no autorizado a los datos o el control remoto de una computadora [6] .
Como parte del programa Bullrun , la NSA inserta puertas traseras en los sistemas criptográficos. Dual_EC_DRBG supuestamente fue uno de los objetivos en 2013 [7] . En el proceso de trabajo de estandarización, la NSA logró lo que finalmente se convirtió en el único editor de la norma [8] . Al acceder a Dual_EC_DRBG adoptado en NIST SP 800-90A, la NSA citó el uso de Dual_EC_DRBG por parte de la renombrada firma de seguridad RSA Security en sus productos. Sin embargo, la NSA pagó $ 10 millones a RSA Security para usar Dual_EC_DRBG de forma predeterminada en sus productos. Reuters describe el acuerdo como "elaborado por líderes empresariales, no por tecnólogos puros". Debido a que Reuters describió como secreto el contrato de $10 millones para obligar a RSA Security a usar Dual_EC_DRBG, las personas involucradas en el proceso de adopción de NIST SP 800-90A para Dual_EC_DRBG supuestamente desconocían este aparente conflicto de intereses [9] . Esto puede ayudar a explicar cómo se adoptó como estándar en NIST SP 800-90A un generador de números aleatorios, que luego se demostró que era inferior a las alternativas (además de una posible puerta trasera).
Aunque el potencial de una puerta trasera en Dual_EC_DRBG ya fue documentado por Dan Shumov y Nils Ferguson en 2007, [10] se siguió utilizando en productos de empresas como RSA Security hasta 2013 [1] . Dadas las deficiencias conocidas en Dual_EC_DRBG, posteriormente surgieron acusaciones de que RSA Security insertó deliberadamente la puerta trasera de la NSA en sus productos. RSA niega haber insertado a sabiendas una puerta trasera en sus productos [11] .
Después de que se descubrió la puerta trasera, el NIST reanudó el proceso de revisión del gobierno NIST SP 800-90A [7] [12] . En junio de 2015 [13] se publicó una versión revisada de NIST SP 800-90A, en la que se eliminó Dual_EC_DRBG .
Hash_DRBG y HMAC_DRBG tienen pruebas de seguridad para generar secuencias pseudoaleatorias [14] . El documento de prueba de seguridad para Hash_DRBG y HMAC_DRBG cita intentos de prueba de seguridad para Dual_EC_DRBG que indican que CTR_DRBG no debe usarse porque es el único generador en NIST SP 800-90A para el que no hay prueba de seguridad [14] .
HMAC_DRBG también tiene una prueba de seguridad verificada por máquina [15] . La tesis, que contiene una prueba de seguridad verificada computacionalmente, también demuestra que descifrar una instancia de HMAC_DRBG correctamente implementada no compromete la seguridad de los números creados antes del descifrado [15] .
Se ha demostrado que CTR_DRBG tiene problemas de seguridad cuando se usa con ciertos parámetros, ya que los criptógrafos no consideraron el tamaño del bloque de cifrado al diseñar este generador de números pseudoaleatorios [16] . CTR_DRBG parece ser seguro e indistinguible de una verdadera fuente aleatoria cuando se usa AES como cifrado de bloque subyacente y se toman 112 bits de este generador de números pseudoaleatorios [16] . Cuando se utiliza AES como cifrado de bloque subyacente y se toman 128 bits de cada instancia, el nivel de seguridad necesario se establece con la condición de que la salida de un cifrado de 128 bits en modo contador se pueda distinguir de un verdadero generador de números aleatorios [16]. ] . Cuando se utiliza AES como cifrado de bloque subyacente y se toman más de 128 bits de este generador de números pseudoaleatorios, el nivel de seguridad resultante está limitado por el tamaño del bloque, no por el tamaño de la clave, por lo que el nivel de seguridad real es mucho menor. que el nivel de seguridad implícito en el tamaño de la clave [16] . También se ha demostrado que CTR_DRBG no puede proporcionar el nivel de seguridad esperado cuando se utiliza Triple DES porque su tamaño de bloque de 64 bits es mucho más pequeño que el tamaño de clave de 112 bits utilizado para Triple DES [16] .
El intento de prueba de seguridad para Dual_EC_DRBG argumenta que Dual_EC_DRBG requiere tres problemas para ser NP para ser seguro : el problema de Diffie-Hellman , el problema del logaritmo discreto y el problema del punto truncado [17] . El problema de decisión de Diffie-Hellman es ampliamente reconocido como matemáticamente difícil [17] . El problema del logaritmo discreto no es ampliamente aceptado para la clase NP, algunas demostraciones muestran que este problema es difícil, pero no lo prueban [17] . Por lo tanto, la prueba de seguridad está abierta a cuestionamiento y puede invalidarse si se demuestra que el problema del logaritmo discreto es solucionable en lugar de matemáticamente difícil. El problema del punto truncado requiere que se trunquen suficientes bits del punto elegido por Dual_EC_DRBG para que no se pueda distinguir de un número verdaderamente aleatorio [17] . sin embargo, se ha demostrado que el truncamiento de 16 bits predeterminado por el estándar Dual_EC_DRBG es insuficiente para hacer que la salida sea indistinguible de un verdadero generador de números aleatorios [18] y, por lo tanto, invalida la prueba de seguridad Dual_EC_DRBG cuando se usa el valor de truncamiento predeterminado.
Los algoritmos anteriores son estándares y son utilizados por grandes empresas para crear sus propios productos basados en ellos. Entonces , Microsoft , en el proceso de crear una actualización para su CryptoApi llamada “Cryptography API: Next Generation (CNG)”, configuró el generador de números pseudoaleatorios predeterminado en CTR_DRBG [19] .
Intel también usa CTR_DRBG [20] para generar un número aleatorio usando el generador de números aleatorios incorporado en la instrucción RdRand .