NIST SP 800-90A: Padrões de DRBG

As operações criptográficas precisam de números aleatórios de alta qualidade: geração de chaves, valores de uso único, IVs, salts e tokens de sessão. Os geradores de números aleatórios verdadeiros (TRNGs) coletam entropia de fontes físicas (ruído de hardware, interrupções e ruído térmico), mas são lentos e nem sempre estão disponíveis — especialmente em máquinas virtuais ou durante a inicialização inicial. Os Geradores Determinísticos de Bits Aleatórios (DRBGs) resolvem esse problema: um DRBG é inicializado com uma pequena quantidade de entropia verdadeira e usa um algoritmo criptográfico para expandi-la em um grande fluxo de bits pseudoaleatórios que são computacionalmente indistinguíveis de bits verdadeiramente aleatórios. O NIST SP 800-90A define três mecanismos aprovados de DRBG usados em praticamente todas as implementações criptográficas modernas.

Um DRBG opera por meio de três operações fundamentais. Instanciar: inicializar o estado interno do DRBG usando entropy_input (de uma fonte de entropia), um valor de uso único (um valor usado uma única vez para garantir a exclusividade) e, opcionalmente, personalization_string (um contexto específico da aplicação). Gerar: produzir o número solicitado de bits pseudoaleatórios e atualizar o estado interno para impedir a recuperação do estado anterior. Fazer nova semeadura: injetar entropia nova no estado do DRBG para fornecer resistência à predição — após uma nova semeadura, mesmo um adversário que conhecesse o estado anterior não poderia prever as saídas futuras. O NIST especifica intervalos máximos de geração (reseed_interval): 2^48 solicitações antes da nova semeadura obrigatória para os três tipos de DRBG.

O NIST SP 800-90A define quatro níveis de força de segurança: 112, 128, 192 e 256 bits. A força de segurança determina a entropia mínima necessária na instanciação e a qualidade da saída gerada. Para uma segurança de 128 bits, a entrada de entropia deve fornecer pelo menos 128 bits de entropia. A relação é: security_strength bits de entropia produzem uma saída do DRBG computacionalmente indistinguível de uma saída aleatória para um adversário que execute 2^security_strength operações. As escolhas do tamanho da chave (AES-128 ou AES-256) e da função de hash (SHA-256 ou SHA-512) devem corresponder ou exceder a força de segurança desejada. Parametrizar excessivamente (SHA-512 para uma segurança de 128 bits) é seguro, mas desperdiça recursos; parametrizar de forma insuficiente compromete a segurança.

O Hash_DRBG mantém dois valores de estado: V (um valor que gera a saída) e C (uma constante adicionada durante a geração). A geração: hash_gen produz bits iterando H(0x01 || V), H(0x01 || V+1), ... até que haja saída suficiente; depois, V é atualizado com V = V + H(0x03 || V) + C + reseed_counter. A nova semeadura usa Hash_df (função de derivação baseada em hash), combinando o V atual com entropia nova para produzir novos valores de V e C. O Hash_DRBG é simples de implementar e tem uma análise de segurança simples, o que o torna adequado para ambientes com recursos limitados. O NIST recomenda a instanciação com SHA-256 ou SHA-512. O Hash_DRBG é usado no SHA1PRNG (mais antigo) do Java e no DRBG legado do OpenSSL.

O HMAC_DRBG mantém um estado (chave K, valor V). A geração itera V = HMAC(K, V) até produzir saída suficiente; depois, K = HMAC(K, V || 0x00) e V = HMAC(K, V). A atualização recebe additional_input e faz uma nova semeadura de K e V usando operações HMAC. O HMAC_DRBG tem uma prova de segurança clara baseada na segurança do HMAC (hipótese de PRF sobre HMAC). É o DRBG mais amplamente recomendado: OpenSSL (desde a versão 1.1.1), mbedTLS, wolfSSL e a maioria das pilhas TLS usam HMAC_DRBG. A construção HMAC fornece uma mistura interna entre chamadas sucessivas, dificultando ataques de recuperação do estado anterior mesmo quando parte do estado é exposta.

O CTR_DRBG usa uma cifra de bloco (AES) no modo contador. Estado: chave K e contador V. A geração criptografa valores sucessivos do contador E(K, V), E(K, V+1), ... e incrementa V. A atualização usa Block_Cipher_df para derivar novos valores de K e V a partir de additional_input. O CTR_DRBG é o DRBG mais rápido — a aceleração de hardware AES-NI o torna várias ordens de grandeza mais rápido que os DRBGs baseados em hash nos processadores modernos. Ele é o DRBG padrão no Windows CNG (CryptGenRandom usa CTR_DRBG com AES-256), no OpenSSL 3.0 (padrão) e no RNG do kernel do Linux (chamada de sistema getrandom). A segurança do CTR_DRBG depende de o AES ser uma permutação pseudoaleatória, propriedade sustentada por décadas de análise.

Resistência à predição é a propriedade segundo a qual a saída do DRBG permanece imprevisível até para um adversário que tenha comprometido anteriormente o estado do DRBG, desde que entropia nova seja misturada por meio de uma nova semeadura. Um DRBG com prediction_resistance_flag=true consulta a fonte de entropia antes de cada chamada de geração para injetar entropia nova. Sem resistência à predição, o comprometimento do estado no instante T permite calcular todas as saídas futuras (a segurança para frente é perdida). A segurança para trás (também chamada resistência a retrocesso) significa que as saídas passadas permanecem imprevisíveis mesmo quando o estado atual é conhecido — HMAC_DRBG e CTR_DRBG alcançam isso por meio de suas etapas de atualização, que derivam uma nova chave do estado atual após cada geração.

O SP 800-90A especifica os algoritmos de DRBG, mas não a fonte de entropia. O SP 800-90B define requisitos para fontes de entropia: as fontes de ruído de hardware devem ser caracterizadas e validadas, as estimativas de entropia devem ser conservadoras e os testes de integridade devem detectar falhas nas fontes de entropia. O SP 800-90C especifica como combinar fontes de entropia com DRBGs para formar geradores completos de bits aleatórios. Fontes de entropia típicas: CPU RDRAND/RDSEED (RNG de hardware, disponível em CPUs Intel/AMD desde 2012), entropia do OS (/dev/urandom no Linux, BCryptGenRandom no Windows), módulos de segurança de hardware, RNG do TPM 2.0 e ruído ambiental (temporização de disco e variação da rede). Condições de baixa entropia (máquinas virtuais e inicialização inicial) exigem tratamento especial para evitar sementes fracas.

O FIPS 140-3 (o padrão atual para validação de módulos criptográficos) exige DRBGs do NIST SP 800-90A para toda geração de números aleatórios dentro de módulos certificados. O módulo deve: usar um DRBG aprovado (baseado em hash, HMAC ou CTR); obter a semente de uma fonte de entropia aprovada que atenda aos requisitos do SP 800-90B; executar testes automáticos na inicialização (POST) que verifiquem a operação do DRBG; implementar testes contínuos de RNG (CRNGT) que detectem falhas de entropia presa em zero ou em um; e permitir uma nova semeadura quando a fonte de entropia indicar que há entropia disponível. HSMs (Thales Luna, AWS CloudHSM e Utimaco), placas aceleradoras de TLS e dispositivos de criptografia de rede normalmente exigem módulos validados pelo FIPS 140-3, impulsionando a adoção do SP 800-90A.

Os sistemas operacionais modernos mantêm um DRBG no nível do núcleo, inicializado com entropia proveniente de fontes de hardware. O Linux usa um DRBG baseado em ChaCha20 (desde o núcleo 5.17, substituindo o design mais antigo semelhante ao Fortuna), inicializado a partir de RDRAND, interrupções e eventos de disco/rede. /dev/urandom retorna a saída do DRBG e não bloqueia depois da semeadura inicial. /dev/random bloqueia até que haja entropia suficiente disponível (comportamento legado, em grande parte removido nos núcleos recentes). A chamada de sistema getrandom(2) é a interface moderna e bloqueia apenas no início da inicialização, antes de o DRBG ser semeado. O Windows usa CTR_DRBG (AES-256) no RNG do núcleo, inicializado a partir do TPM e de eventos de hardware. Os aplicativos devem usar o DRBG do OS por meio de interfaces de alto nível, em vez de semear seus próprios mecanismos DRBG usando carimbos de data/hora ou PID.

As vulnerabilidades de DRBG no mundo real resultam de erros de implementação, e não de falhas nos algoritmos. (1) Semeadura insuficiente: semear apenas com o carimbo de data/hora atual ou com o PID fornece aos invasores uma semente previsível. (2) Cegueira diante de bifurcações: quando um processo cria uma bifurcação, o processo pai e o filho compartilham o mesmo estado do DRBG — eles geram números aleatórios idênticos. Solução: faça uma nova semeadura após a bifurcação (pthread_atfork ou uma chamada explícita a getrandom). (3) Reutilização de instantâneos de VM: se um instantâneo de VM for restaurado, o estado do DRBG volta ao estado do instantâneo, gerando uma saída vista anteriormente. Solução: injete entropia exclusiva na inicialização da VM (VIRTIO RNG). (4) Falha silenciosa nos testes de integridade: um DRBG que continua gerando depois de detectar uma falha de entropia fornece uma saída previsível para o invasor. (5) Reutilização de números únicos entre instâncias de DRBG.

Que propriedade a resemeadura de um DRBG com entropia nova oferece?

A NIST SP 800-90A define três mecanismos DRBG aprovados: Hash_DRBG (hash iterativo, simples), HMAC_DRBG (baseado em HMAC, com uma prova de segurança clara e amplamente implantado) e CTR_DRBG (modo contador do AES, mais rápido por meio de AES-NI, padrão no Windows/OpenSSL). Todos compartilham o ciclo de vida Instantiate/Generate/Reseed, com um limite reseed_interval de 2^48. A força de segurança (112–256 bits) determina os requisitos de entropia. A resistência à predição exige uma resemeadura antes de cada chamada a Generate. A FIPS 140-3 exige mecanismos DRBG da SP 800-90A com fontes de entropia da SP 800-90B. A cegueira diante de bifurcações, a reutilização de instantâneos de VM e a semeadura insuficiente são as principais armadilhas de implementação no mundo real.