Testando e Validando Implementações de RNG

O teste de geradores de números aleatórios enfrenta um desafio fundamental: sequências verdadeiramente aleatórias e sequências pseudoaleatórias de um bom PRNG parecem idênticas para testes estatísticos. Nenhum teste de comprimento finito pode provar que uma sequência é aleatória — as estatísticas só conseguem detectar a não aleatoriedade com certo grau de confiança. Os testes verificam que um RNG não apresenta vieses ou padrões óbvios, mas não podem provar sua segurança criptográfica. Os testes de RNGs criptográficos têm dois objetivos distintos: (1) qualidade estatística — verificar se a distribuição da saída parece uniforme e independente; (2) força criptográfica — verificar se o algoritmo DRBG foi implementado corretamente e se as alegações de segurança são válidas. Esses objetivos exigem abordagens de teste diferentes.

O NIST SP 800-22 fornece 15 testes estatísticos para avaliar sequências de bits. Os testes incluem: teste de frequência (um único bit) — a proporção de 1s deve estar próxima de 0,5. Teste de frequência por blocos — frequência de 1s em cada bloco de m bits. Teste de sequências — número de sequências ininterruptas de bits idênticos. Teste da maior sequência — comprimento da maior sequência de 1s. Teste do posto de matriz binária — posto de matrizes binárias formadas pela sequência. Teste espectral (DFT) — detectar padrões periódicos. Correspondência de padrões sobrepostos — contar ocorrências de padrões específicos. Teste estatístico universal de Maurer — comprimir a sequência e medir quanto menor ela fica. Cada teste produz um valor-p; p < 0,01 sugere não aleatoriedade. Os testes são executados em sequências de 1 milhão a 1 bilhão de bits.

TestU01 (L'Ecuyer e Simard, 2007) é um conjunto abrangente de testes estatísticos amplamente usado pela comunidade de RNGs. SmallCrush: 10 testes, aproximadamente 35 segundos, apropriado para verificações rápidas. Crush: 144 testes, aproximadamente 2 horas. BigCrush: 160 testes, aproximadamente 24 horas. Os testes do BigCrush detectam correlações sutis que o NIST SP 800-22 não detecta. DRBGs criptográficos bem projetados (HMAC_DRBG, CTR_DRBG) passam pelo BigCrush sem dificuldade — sua saída é computacionalmente indistinguível de aleatória para algoritmos de tempo polinomial. PRNGs não criptográficos (Mersenne Twister, geradores congruenciais lineares) falham em alguns testes do BigCrush. Uma falha no BigCrush é um forte indicador de que o RNG não deve ser usado para fins criptográficos.

O SP 800-90B e o 90A especificam testes de integridade que os DRBGs devem executar continuamente durante a operação. Teste contínuo de RNG (CRNGT): cada bloco gerado é comparado ao bloco anterior — se forem iguais (RNG travado), o DRBG deve entrar em um estado de erro e parar de gerar. Teste de contagem de repetições: se amostras consecutivas apresentarem o mesmo valor repetido mais vezes do que seria esperado estatisticamente, considerando a estimativa de entropia, o teste deve falhar. Teste de proporção adaptativa: se o valor mais frequente ocorrer mais vezes que o limite definido em uma janela, o teste deve falhar. Esses testes de integridade detectam falhas na fonte de entropia (sensor travado, falha de hardware do HWRNG) antes que comprometam silenciosamente a geração de chaves criptográficas.

PractRand é uma ferramenta moderna de teste de RNGs projetada para avaliação em fluxo, analisando a sequência à medida que ela é gerada, em vez de exigir um comprimento predeterminado. Ela aplica testes que incluem testes de intervalos, testes de distribuição de bits e testes espectrais com precisão adaptativa. O PractRand é especialmente eficaz para detectar RNGs que produzem sequências curtas de boa qualidade, mas revelam padrões ao longo de bilhões de bits. Os DRBGs criptográficos produzem uma saída que o PractRand não consegue distinguir de aleatória, independentemente do comprimento — essa é a definição operacional de indistinguibilidade computacional. O PractRand também é usado para avaliar fontes de entropia (testando a saída de /dev/urandom e a saída do RDRAND) e detectar falhas de hardware ou vieses sistemáticos.

O Programa de Validação de Algoritmos Criptográficos (CAVP) fornece vetores de teste oficiais para DRBGs do SP 800-90A. O teste do CAVP envolve enviar uma implementação ao sistema automatizado de testes da NIST com vetores de teste de resposta conhecida (KAT): dada uma entrada de entropia específica, um valor de uso único, uma cadeia de personalização e uma entrada adicional, a implementação deve produzir exatamente os bits de saída esperados. O CAVP não testa propriedades estatísticas — testa a correção algorítmica. A certificação FIPS 140-3 exige validação CAVP para todos os algoritmos criptográficos usados dentro do limite do módulo. Os vetores de teste do CAVP estão disponíveis publicamente no servidor ACVP da NIST (Protocolo Automatizado de Validação Criptográfica) e são integrados aos conjuntos de testes do OpenSSL, mbedTLS e BoringSSL.

Antes que um DRBG possa ser inicializado com segurança, sua fonte de entropia deve ser validada. O SP 800-90B define: (1) Estimativa de entropia — medir a entropia real por bit usando testes estatísticos (estimativa da entropia mínima). (2) Testes de inicialização — verificar se a fonte de entropia produz uma saída válida antes do primeiro uso. (3) Testes sob demanda — testes opcionais acionados pelo aplicativo. (4) Testes de integridade da fonte de ruído — detectar degradação do hardware. Fontes comuns de entropia e sua entropia estimada por bit: CPU RDRAND/RDSEED (aproximadamente 1 bit/bit, com certificação de hardware); /dev/urandom (mistura várias fontes, com estimativa de entropia conservadora); TRNG de oscilador em anel (0,5–0,9 bits/bit, dependendo do projeto); ruído do ADC (0,1–0,5 bits/bit). A validação do SP 800-90B exige testes laboratoriais com equipamentos especializados.

Ambientes virtuais introduzem desafios específicos para os testes de RNG. As máquinas virtuais podem apresentar condições de baixa entropia na inicialização (sem eventos de hardware) ou após a restauração de um instantâneo (estado redefinido). Os contêineres do Docker compartilham o RNG do núcleo do sistema — um contêiner não pode testar diretamente a qualidade da entropia subjacente. Testes para implantações em máquinas virtuais: (1) Meça o tempo até a conclusão da leitura de /dev/random — esperas longas indicam entropia insuficiente. (2) Teste a existência de UUIDs ou chaves duplicados gerados em instâncias de VM executadas em paralelo (um modo de falha real documentado em implantações na nuvem). (3) Verifique se VIRTIO-RNG (virtio_rng.ko) está carregado nas VM — isso fornece injeção de entropia do anfitrião para o convidado. (4) Audite a sequência de inicialização do aplicativo: a geração de chaves ocorre antes que haja entropia suficiente?

Testar a segurança contra bifurcação do RNG evita uma vulnerabilidade sutil: quando um processo se bifurca, o processo pai e o filho compartilham o mesmo estado do DRBG, fazendo com que gerem sequências idênticas. Detecção: inicie N processos filhos, gere um UUID em cada um e verifique se todos os UUIDs são exclusivos. Se dois coincidirem, o RNG não é seguro contra bifurcação. OpenSSL corrigiu um erro de segurança contra bifurcação em 2020 (CVE-2020-1971 não envolvia diretamente o DRBG, mas o padrão é semelhante). A versão atual do OpenSSL usa uma atualização da semente baseada no PID: se o PID mudou desde a última chamada (indicando uma bifurcação), o DRBG recebe automaticamente uma nova semente. Para testar isso: execute o teste antes e depois de uma bifurcação e confirme que a nova semeadura ocorreu verificando se as saídas são distintas.

Uma lista de verificação prática para auditorias de implementações de RNG: (1) O RNG é inicializado a partir do OS (getrandom, BCryptGenRandom), em vez de usar sementes baseadas no tempo? (2) O tipo de DRBG é um mecanismo aprovado pela NIST SP 800-90A (função de resumo, HMAC, CTR)? (3) O comprimento da semente é suficiente para o nível de segurança alegado? (4) A nova semeadura é acionada periodicamente ou após um número fixo de chamadas de geração? (5) A implementação trata da segurança contra bifurcação (nova semeadura após bifurcação)? (6) Os testes de integridade estão habilitados e interrompem o sistema em caso de falha? (7) O estado é zerado ao desligar? (8) Os vetores de teste da CAVP são executados na integração e entrega contínuas? (9) As estimativas de entropia estão documentadas e validadas? (10) Para requisitos da FIPS: o módulo é certificado pela FIPS 140-3?

Falhas históricas de RNG demonstram o que está em jogo. Debian OpenSSL (2006–2008): uma correção removeu acidentalmente duas linhas do código de coleta de entropia, reduzindo o conjunto de sementes a um espaço de PID de 15 bits — apenas 32.767 chaves SSH possíveis foram geradas para toda a base de usuários Debian. Todas as chaves de host SSH e as chaves de usuários geradas pelo Debian precisaram ser substituídas. Carteiras de Bitcoin no Android (2013): o SecureRandom do Android usava uma semeadura no nível de Java que falhava em alguns dispositivos, causando valores k duplicados nas assinaturas ECDSA — o que revelava diretamente as chaves privadas. Sony PS3 (2010): usava um nonce constante na assinatura de firmware ECDSA, permitindo a extração da chave privada a partir de duas assinaturas (o mesmo k em mensagens diferentes revela a chave por meio de álgebra simples).

Qual dos testes a seguir detecta que um DRBG pode estar gerando uma saída constante (o mesmo valor repetidamente)?

Testes estatísticos (NIST SP 800-22, TestU01 BigCrush, PractRand) verificam a qualidade da saída, mas não podem provar a segurança criptográfica. Testes de resposta conhecida da CAVP verificam a correção algorítmica das implementações do SP 800-90A. Os testes de fontes de entropia do SP 800-90B (estimativa de min-entropia, testes de integridade) validam a entrada da semente. O Teste Contínuo de RNG (CRNGT) detecta saídas constantes em tempo real. As implantações em máquinas virtuais e contêineres exigem injeção de entropia (VIRTIO-RNG) e verificações da entropia na inicialização. Os testes de segurança contra bifurcação verificam se os processos filhos não herdam o estado do DRBG pai. Falhas do mundo real (Debian, Android) demonstram que erros em RNG levam diretamente ao comprometimento de chaves criptográficas. As listas de verificação para auditoria formalizam essas verificações para implantações em produção.