Entresijos de Hash-DRBG, HMAC-DRBG y CTR-DRBG

Cada uno de los tres mecanismos DRBG de NIST mantiene distintos componentes de estado interno, de acuerdo con su enfoque algorítmico subyacente. Hash_DRBG almacena V (una semilla del tamaño del hash) y C (una constante derivada de V que se utiliza durante la generación de la salida). HMAC_DRBG almacena la clave secreta K (del tamaño del hash) y el valor V (un valor de encadenamiento del tamaño del hash). CTR_DRBG almacena la clave K (una clave AES) y V (un contador del tamaño del bloque). Los tres mantienen un reseed_counter que registra las llamadas a Generate desde la última inicialización. El tamaño del estado determina la memoria ocupada: Hash_DRBG y HMAC_DRBG con SHA-256 utilizan 64 bytes de estado; CTR_DRBG con AES-256 utiliza 48 bytes (una clave de 32 bytes + un contador de 16 bytes).

Hash_DRBG utiliza Hash_df (función de derivación basada en hash) para derivar el estado a partir del material de entropía. Hash_df(input_string, no_of_bits_to_return) itera de la siguiente manera: para counter = 1, 2, ..., calcula H(counter || no_of_bits || input_string) y concatena las salidas hasta producir suficientes bits. Esto amplía entradas de entropía cortas para convertirlas en semillas del tamaño del estado. Durante Generate, la función de salida calcula W = H(0x03 || V), donde el prefijo 0x03 distingue este uso de otros usos del hash. El bucle de salida es: data = H(0x01 || V); V = V + 1; se repite para generar más salida. Después de generar la salida, V se actualiza: V = V + H(0x03 || V) + C + reseed_counter. La separación de dominios mediante bytes de prefijo (0x01, 0x03) evita que la salida de la fase de generación se confunda con la salida de la fase de actualización del estado.

La función Update de HMAC_DRBG es el núcleo de todas las transiciones de estado. Update(provided_data, K, V): K = HMAC(K, V || 0x00 || provided_data); V = HMAC(K, V). Si provided_data no está vacío: K = HMAC(K, V || 0x01 || provided_data); V = HMAC(K, V). Esta actualización en dos pasos garantiza que tanto la nueva clave como el nuevo valor dependan del estado anterior y de cualquier entropía nueva. Generate: se repite V = HMAC(K, V) y se añade el resultado a la salida hasta producir suficientes bits; después se llama a Update con additional_input para avanzar el estado. La seguridad de HMAC_DRBG se reduce a la suposición de que HMAC es una PRF segura: un adversario que no pueda distinguir la salida de HMAC de una salida aleatoria tampoco podrá distinguir la salida del DRBG de una salida aleatoria.

CTR_DRBG utiliza Block_Cipher_df (función de derivación) para transformar el material de la semilla al formato de clave y contador. Block_Cipher_df(input_string, no_of_bits) utiliza una construcción BCC (Block Cipher Chaining): itera AES-CBC sobre fragmentos de entrada para producir una salida de la longitud requerida. La función de derivación es necesaria para gestionar entradas de entropía de longitud variable y proporcionar separación de dominios. CTR_DRBG sin función de derivación (permitido para tests de FIPS con entradas formateadas con precisión) es más rápido, pero más sensible a los requisitos de formato de entrada. El bucle de Generate es: temp = E(K, V); V = V + 1; se añade temp a la salida. Update: K || V = Block_Cipher_df(V || additional_input, seedlen); se aplica XOR con la clave actual.

El rendimiento varía considerablemente entre los distintos tipos de DRBG. En una CPU x86_64 moderna con AES-NI, CTR_DRBG (AES-256) alcanza aproximadamente entre 5 y 10 GB/s de salida seudoaleatoria; la instrucción AES-NI hace que el cálculo de AES tenga un coste prácticamente insignificante. HMAC_DRBG (SHA-256) alcanza aproximadamente entre 200 y 400 MB/s; SHA-256 es rápido, pero no está acelerado por hardware en el mismo grado. Hash_DRBG (SHA-256) alcanza aproximadamente entre 100 y 300 MB/s. Para la generación masiva de claves o como sustituto de un cifrador de flujo, CTR_DRBG es mucho más rápido. Para usos de bajo rendimiento (generación de claves de sesión o derivación de nonces), la diferencia de rendimiento es insignificante. Por este motivo, OpenSSL 3.0 utiliza CTR_DRBG (AES-256) de forma predeterminada.

Durante la instanciación, los tres DRBG aceptan una personalization_string opcional, que se mezcla con la entrada de entropía para hacer única la instancia del DRBG. Esto evita que dos DRBG instanciados simultáneamente con la misma entropía produzcan la misma salida: divergen en función de la personalization_string. Cadenas de personalización recomendadas: identificador de la aplicación + ID del proceso + ID del subproceso + marca de tiempo + identificador de hardware. Aunque dos máquinas virtuales reciban la misma entropía (un problema relacionado con las instantáneas de máquinas virtuales en la nube), distintas cadenas de personalización garantizan distintos flujos de salida del DRBG. NIST SP 800-90C recomienda utilizar siempre una cadena de personalización. El parámetro nonce cumple una función similar: es un valor corto y único que garantiza que ninguna instanciación comience en el mismo estado.

Los tres DRBG admiten un parámetro additional_input en las llamadas a Generate. Esto permite que quien realiza la llamada inyecte contexto o entropía adicionales en una sola llamada a Generate sin hacer una resiembra completa. Usos: (1) inyectar entropía por solicitud procedente de una fuente de entropía secundaria; (2) proporcionar contexto a nivel de aplicación (ID de solicitud, marca de tiempo) para vincular los valores generados con su uso; (3) proporcionar resistencia a la predicción opcional mediante la inyección de entropía nueva procedente del sistema operativo. additional_input se mezcla con el estado del DRBG antes de generar la salida. Si additional_input proporciona entropía real, mejora la seguridad sin requerir una resiembra formal (que implica la interfaz de la fuente de entropía y la sobrecarga asociada).

Después de desinstanciar un DRBG (o al cambiar a una instancia nueva), el estado interno debe ponerse a cero de forma segura. El estado V, C (Hash_DRBG), K, V (HMAC_DRBG y CTR_DRBG) y todas las variables de trabajo intermedias deben sobrescribirse con ceros. Esto se denomina puesta a cero explícita y es obligatorio en los módulos FIPS 140-3. En código C, utilice explicit_bzero() o SecureZeroMemory(); un memset optimizado por el compilador podría eliminarse como optimización de almacenamiento inerte y dejar material de clave en la memoria. La crate zeroize de Rust y soluciones similares específicas de cada lenguaje gestionan esto de forma portable. La destrucción segura de claves es importante en contextos en los que los volcados de memoria, los ataques de arranque en frío o las herramientas de inspección de procesos podrían exponer el estado residual.

NIST proporciona vectores de prueba del Cryptographic Algorithm Validation Program (CAVP) para todos los DRBG de SP 800-90A. Tipos de prueba: (1) Known Answer Tests (KAT): dada una entrada de entropía, un nonce y una cadena de personalización fijos, se verifica que la salida generada coincida con valores precalculados. (2) Pruebas de resiembra: se verifica el estado del DRBG después de una operación de resiembra. (3) Pruebas de PR (Prediction Resistance): se verifica que solicitar prediction_resistance=true produzca la salida correcta después de inyectar entropía nueva. La validación CAVP es obligatoria para presentar una solicitud de validación FIPS 140-3. Las bibliotecas de código abierto (OpenSSL, mbedTLS) incluyen vectores de prueba CAVP en sus conjuntos de pruebas de regresión para detectar regresiones en las implementaciones de DRBG.

Las implementaciones de DRBG afrontan riesgos sutiles de canal lateral que van más allá del modelo de seguridad algorítmico. Los ataques de temporización de caché contra AES (en CTR_DRBG sin AES-NI) pueden filtrar material de la clave de ronda; AES-NI elimina este riesgo al realizar los cálculos en registros sin búsquedas en tablas. HMAC_DRBG utiliza HMAC internamente, que funciona en tiempo constante si el SHA-256 subyacente también funciona en tiempo constante; SHA-256 se considera generalmente de tiempo constante porque no tiene bifurcaciones que dependan de los datos. Los canales laterales físicos (análisis del consumo eléctrico y radiación electromagnética) contra hardware que produce DRBG son una preocupación en tarjetas inteligentes y dispositivos IoT, y se abordan mediante implementaciones con enmascaramiento. El ataque mediante copia de seguridad del estado: si un adversario puede leer el estado del DRBG a través de una vulnerabilidad de divulgación de memoria (al estilo de Heartbleed), toda la salida futura queda comprometida hasta la siguiente resiembra con entropía nueva.

Si el estado de un DRBG queda comprometido (por ejemplo, debido a una vulnerabilidad de divulgación de memoria), la recuperación requiere: (1) Detectar la intrusión: las filtraciones del estado del DRBG no son evidentes por sí mismas; se necesitan supervisión externa o comprobaciones de integridad. (2) Resembrar con entropía nueva procedente de una fuente de confianza que no esté implicada en la intrusión. (3) Volver a generar todo el material criptográfico derivado del DRBG comprometido (claves de sesión y claves de firma generadas desde la última resiembra en estado saludable). (4) En implementaciones de software, reiniciar el proceso proporciona una instanciación limpia del DRBG. SP 800-90C recomienda encadenar fuentes de entropía: si una fuente queda comprometida, la combinación sigue proporcionando seguridad siempre que la otra fuente proporcione entropía real.

¿Qué mecanismo DRBG es el más rápido para generar grandes volúmenes de salida seudoaleatoria en CPU modernas?

Hash_DRBG utiliza hashing iterativo con Hash_df para la derivación y produce la salida mediante bucles H(0x01 || V). HMAC_DRBG utiliza HMAC como PRF, con una función Update en dos pasos (primero la clave y después el valor) que proporciona una reducción de seguridad clara. CTR_DRBG utiliza AES en modo contador con Block_Cipher_df y alcanza entre 5 y 10 GB/s en hardware con AES-NI. Todos aceptan personalization_string durante la instanciación para garantizar la unicidad de la instancia y additional_input en cada Generate para vincular el contexto. Los vectores de prueba CAVP validan las implementaciones. El estado debe ponerse a cero de forma segura después de su uso. El compromiso del estado requiere una resiembra con entropía nueva y volver a generar el material derivado.