Em um projeto em que estou trabalhando, o aplicativo é iniciado usando um comando semelhante a este:
java -Djava.security.egd=file:/dev/urandom -jar app.jarEu nunca vi a java.security.egdopção antes. Pesquisando um pouco, parece usado para configurar a geração aleatória de números em um aplicativo Java.
Está certo? Quando deve ser aplicado?
Respostas:
Os aplicativos Java podem e devem usar a classe java.security.SecureRandom para produzir valores aleatórios criptograficamente fortes usando um gerador de números pseudo-aleatórios criptograficamente fortes ( CSPRNG ). As implementações JDK padrão da classe java.util.Random não são consideradas criptograficamente fortes.
Os sistemas operacionais do tipo Unix possuem /dev/randomum arquivo especial que serve para números pseudo-aleatórios acessando ruído ambiental coletado de drivers de dispositivo e outras fontes. No entanto, ele bloqueia se houver menos entropia disponível do que o solicitado ; /dev/urandomnormalmente nunca bloqueia, mesmo que a semente do gerador de números aleatórios pseudoaleatórios não tenha sido totalmente inicializada com entropia desde a inicialização. Ainda existe um terceiro arquivo especial, /dev/arandomque bloqueia após a inicialização até que a semente tenha sido inicializada com segurança com entropia suficiente e nunca mais bloqueia novamente.
Por padrão, a JVM semeia a classe SecureRandom usando /dev/random, portanto, seu código Java pode bloquear inesperadamente . A opção -Djava.security.egd=file:/dev/./urandomna chamada da linha de comandos usada para iniciar o processo Java informa à JVM para usar /dev/urandom.
O extra /./parece fazer com que a JVM use o algoritmo SHA1PRNG, que usa o SHA-1 como base do PRNG (Pseudo Random Number Generator). É mais forte que o algoritmo NativePRNG usado quando /dev/urandomé especificado.
Finalmente, existe um mito que /dev/urandomé um gerador de números pseudo-aleatórios, um PRNG, enquanto /dev/randomé um gerador de números aleatórios “verdadeiro” . Isso simplesmente não é verdade, ambos /dev/randome /dev/urandomsão alimentados pelo mesmo CSPRNG (gerador de números pseudoaleatórios criptograficamente seguros). Somente o comportamento quando o respectivo pool fica sem entropia, de acordo com alguma estimativa, difere: /dev/randombloqueia, enquanto /dev/urandomnão.
E a entropia ficando baixa? Não importa.
Acontece que “parecer aleatório” é o requisito básico para muitos dos nossos blocos de construção criptográficos. E se você pegar a saída de um hash criptográfico, ele deve ser indistinguível de uma sequência aleatória para que as cifras o aceitem. Essa é a razão de usar o algoritmo SHA1PRNG, pois ele usa uma função hash e um contador, junto com uma semente.
Quando deve ser aplicado?
Sempre, eu diria.
Fontes:
https://gist.github.com/svrc/5a8accc57219b9548fe1
https://www.2uo.de/myths-about-urandom
EDIT 04/2020:
Um comentário menciona uma alteração no comportamento da classe SecureRandom no Java 8.
SHA1PRNG e NativePRNG foram corrigidos para respeitar adequadamente as propriedades de origem de semente SecureRandom no arquivo java.security. (A solução alternativa obscura usando file: /// dev / urandom e file: / dev /./ urandom não é mais necessária.)
Isso já havia sido apontado pelos testes mencionados na seção Fontes acima. O extra /./é necessário para alterar o algoritmo usado pelo SecureRanom no Java 8 de NativePRNG para SHA1PRNG.
No entanto, tenho algumas notícias que gostaria de compartilhar. De acordo com o JEP-273 , desde o Java 9, a classe SecureRandom implementa os três mecanismos do Gerador de bits aleatórios determinísticos (DRBG) descritos no NIST 800-90Ar1 . Esses mecanismos implementam algoritmos modernos tão fortes quanto o SHA-512 e o AES-256.
O JDK tinha dois tipos de implementações do SecureRandom :
/dev/{u}randomno Unix ou o uso do CryptoAPI no Windows. As versões mais recentes do Linux e Windows já suportam DRBG, mas versões mais antigas e sistemas incorporados podem não .Enquanto isso, o Java 13 Security Developer's Guide ainda lê
No Linux e macOS, se o dispositivo de coleta de entropia em java.security estiver definido como
file:/dev/urandomoufile:/dev/random, NativePRNG será preferido como SHA1PRNG. Caso contrário, é preferido o SHA1PRNG.
Para esclarecer como os novos mecanismos DRBG são executados em conjunto com os PRNGs anteriores, executei alguns testes no macOS (Darwin) com o AdoptOpenJDK (build 13.0.2 + 8). Aqui estão os resultados:
file: / dev / random
Ordem de preferência dos provedores:
SecureRandom.NativePRNG
SecureRandom.DRBG
SecureRandom.SHA1PRNG
file: / dev / urandom
Ordem de preferência dos provedores:
SecureRandom.NativePRNG
SecureRandom.DRBG
SecureRandom.SHA1PRNG
file: / dev /./ urandom
Ordem de preferência dos provedores:
SecureRandom.DRBG
SecureRandom.SHA1PRNG
SecureRandom.NativePRNG
Conclusão:
Eu recomendo o uso -Djava.security.egd=file:/dev/./urandompara garantir o aproveitamento da implementação SecureRandom mais forte disponível, independentemente da plataforma usada, evitando o bloqueio inesperado do código.
/dev/urandomseletores NativePRNG alimentados por /dev/urandomenquanto /dev/./urandomseleciona SHA1PRNG (também alimentado por /dev/urandom) ao usar o Java 8. A partir do Java 9 em diante, o DRBG prevalece quando a /dev/./urandomorigem é especificada.
Isso não é mais necessário se você estiver usando o JDK 8 ou superior
O problema foi corrigido pelo Java e aqui estão alguns links
Esboço
SHA1PRNG e NativePRNG foram corrigidos para respeitar adequadamente as propriedades de origem de semente SecureRandom no arquivo java.security. (A solução alternativa obscura usando file: /// dev / urandom e file: / dev /./ urandom não é mais necessária.)
Para mais informações (pesquise aleatoriamente na página):
https://docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html
https://www.oracle.com/technetwork/java/javase/8-whats-new-2157071.html
Isso está relacionado à diferença entre o linux /dev/randome o /dev/urandomgerador de números aleatórios.
Retirado deste link
O bug Java 6202721 afirma que o java.security.SecureRandom usa / dev / random em vez de / dev / urandom, mesmo que / dev / urandom seja especificado porque, na época (por volta de 2004) / dev / urandom não estava funcionando corretamente. O bug nunca foi revertido agora que / dev / urandom funciona muito bem. Portanto, você precisa fingir obscurecendo a configuração usando /dev/./urandom para forçar o uso de SHA1PRNG em vez de / dev / random.
Para responder sua pergunta
Quando deve ser aplicado?
Com base no link acima, isso é algo exclusivo das versões 5 e seguintes do Java que resultou de problemas com o / dev / urandom nos sistemas Linux em 2004.