A entropia de drenagem tornaria mais fácil comprometer um sistema? [duplicado]

Question

A entropia é importante para muitos recursos de segurança, como números de sequência TCP e geração de chave / parâmetro criptográfico. Meu entendimento é que o pool de entropia é drenado por uma operação tão simples quanto cat /dev/random , que pode estar oculta em um script mal-intencionado ou mal escrito. Isso também pode ser feito por um invasor que assumiu uma conta local sem privilégios e está tentando se aprofundar no sistema.

Como a maioria dos sistemas usa um gerador de pseudo-números criptograficamente seguro ( /dev/urandom ) em vez de /dev/random , estou imaginando se um pool de entropia drenado tem alguma conseqüência de segurança. Para dar um exemplo: seria mais fácil adivinhar a chave privada de um certificado SSL recém-gerado se o pool de entropia estivesse baixo durante a geração? Eu li man 4 random , mas ainda não tenho certeza de como a entropia é tratada pelo sistema.

    

Answer 1

A falácia desta questão é que não existe tal coisa como “entropia drenante”. (Não em qualquer sentido em que você fica sem entropia antes que o universo fique sem uma entropia para que você viva nele.)

Qualquer gerador aleatório projetado para criptografia precisa de dois elementos: uma fonte de entropia e uma maneira de “suavizar” a fonte de entropia. Fontes de entropia são não fontes de bits aleatórios, elas têm vieses que precisam ser distorcidos. Uma fonte de entropia incondicionada não é boa para criptografia. O condicionamento, isto é, transformar uma fonte de entropia em uma fonte de bits uniformemente aleatórios, é feito por um gerador de números pseudo-aleatórios criptograficamente seguro (CSPRNG abreviado). Uma vez que um CSPRNG tenha sido semeado com entropia suficiente, é bom passar pelo menos algumas vidas do universo¹.

O /dev/urandom do Linux usa um CSPRNG que é periodicamente propagado novamente com entropia extra. A nova propagação periódica ajuda no caso de um comprometimento parcial da máquina que, de alguma forma, vaza o estado interno do gerador aleatório.

O /dev/random do Linux usa um CSPRNG que é periodicamente propagado novamente com entropia extra. (Parece familiar?) O Linux mantém um cálculo interno que pressupõe que o algoritmo CSPRNG está mal quebrado e vaza entropia a uma taxa rápida e bloqueia /dev/random . Mas se você não confia na criptografia por trás do CSPRNG, você não pode confiar nem mesmo no que /dev/random deu a você, ou em praticamente qualquer outra criptografia que você usaria.

Então, não, drenar a entropia não torna seu sistema mais vulnerável de alguma forma.

O único risco com o /dev/urandom do Linux é que ele fornece um resultado previsível antes de ser propagado corretamente . Isso não é uma preocupação para o uso diário em um desktop ou computador “normal”, porque eles salvam o pool de entropia no disco. É uma preocupação se você tiver um sistema instalado recentemente ou um sistema ativo que inicializa a partir de mídia somente leitura. (Um sistema ativo é um lugar ruim para gerar chaves de longo prazo!) Uma vez que o sistema tenha entropia suficiente, isso é para sempre.

Se você quiser uma análise profissional do criptógrafo sobre esse problema, leia Thomas Pornin's ou Thomas Hühn's .

¹ _{N bits de entropia tomam 2 ^N para descobrir. Se você gerar um bilhão de bits por segundo, e começar com um nível de segurança decente de 128 bits, 1 vida-universo lhe dará tempo para gerar cerca de um sextilhão de bits, que é 2 ⁹⁶ , confortavelmente abaixo do limite.}

    

Answer 2

Não , a leitura constante de bits aleatórios de /dev/{u,}random} não tornaria mais fácil atacar outras partes do sistema. (Isto é, a menos que o invasor possa prever o estado interno do gerador de sua saída. Mas é considerado improvável que qualquer um possa.)

Haverá sempre "aleatoriedade" suficiente, uma vez que o gerador de números aleatórios atrás de /dev/{,u}random (eles são basicamente a mesma coisa) foi semeado. A leitura de lotes de bits aleatórios dos dispositivos não altera o estado interno do gerador de pseudo-números do sistema de forma a diminuir a qualidade do número gerado.

Citando o link que foi mencionado por @roaima nos comentários:

What about entropy running low?

It doesn't matter.

The underlying cryptographic building blocks are designed such that an attacker cannot predict the outcome, as long as there was enough randomness (a.k.a. entropy) in the beginning. A usual lower limit for “enough” may be 256 bits. No more.