Java.security.egd seçeneği nedir?

22

Üzerinde çalıştığım bir projede, uygulama buna benzer bir komut kullanılarak başlatılır:

java -Djava.security.egd=file:/dev/urandom -jar app.jar

Bu java.security.egdseçeneği daha önce hiç görmedim . Biraz arama yapıldığında, bir Java uygulamasında rastgele sayı oluşturmayı yapılandırmak için kullanılır.

Doğru mu? Ne zaman uygulanmalı?

java jvm

— davioooh
kaynak

29

Java uygulamaları, kriptografik olarak güçlü sahte rasgele sayı üreteci ( CSPRNG ) kullanarak kriptografik olarak güçlü rasgele değerler üretmek için java.security.SecureRandom sınıfını kullanabilir ve kullanmalıdır . Java.util.Random sınıfının standart JDK uygulamaları kriptografik olarak güçlü kabul edilmez.

Unix benzeri işletim sistemleri /dev/random, aygıt sürücülerinden ve diğer kaynaklardan toplanan çevresel gürültüye erişen sahte rasgele sayılar sunan özel bir dosyaya sahiptir. Ancak, istenenden daha az entropi olup olmadığını engeller ; /dev/urandomtipik olarak asla bloke edilmez, çünkü yalancı sayı üreteci tohumu önyüklemeden beri entropi ile tam olarak başlatılmamış olsa bile. Yine de, /dev/arandomtohum yeterli entropi ile güvenli bir şekilde başlatılana kadar önyüklemeden sonra bloke eden ve daha sonra tekrar bloke etmeyen 3. özel bir dosya var.

Varsayılan olarak, JVM SecureRandom sınıfını kullanarak tohumlar oluşturur /dev/random, bu nedenle Java kodunuz beklenmedik şekilde engellenebilir . -Djava.security.egd=file:/dev/./urandomJava işlemini başlatmak için kullanılan komut satırı çağırma seçeneğinde , /dev/urandombunun yerine JVM'ye kullanılması bildirilir .

Ekstra /./, JVM'yi PRNG'nin (Pseudo Random Number Generator) temeli olarak SHA-1 kullanan SHA1PRNG algoritmasını kullanacak gibi görünüyor . /dev/urandomBelirtildiğinde kullanılan NativePRNG algoritmasından daha güçlüdür .

Son olarak, /dev/urandomsözde rasgele sayı üreteci, PRNG,/dev/random efsane ise “gerçek” rasgele sayı üreteci . Bu her ikisi de doğru değildir /dev/randomve /dev/urandomaynı CSPRNG (kriptografik olarak güvenli sahte sayı üreteci) tarafından beslenir. Bazı tahminlere göre, sadece kendi havuzları entropi bittiğinde davranış farklıdır: /dev/randombloklar, /dev/urandomdeğil.

Entropinin azalmasına ne dersiniz? Önemli değil.

Kriptografik yapı taşlarımızın birçoğu için “rastgele görünmenin” temel gereksinim olduğu ortaya çıkıyor. Ve eğer bir kriptografik karma çıktı alırsanız, bu rastgele bir dize ayırt edilemez olması gerekir böylece şifreler kabul edecektir. SHA1PRNG algoritmasını kullanmanın nedeni, bir karma işlev ve bir sayaç kullanarak bir tohumla birlikte kullanılmasıdır.

Ne zaman uygulanmalı?

Her zaman söyleyebilirim.

Kaynaklar:
https://gist.github.com/svrc/5a8accc57219b9548fe1
https://www.2uo.de/myths-about-urandom

04/2020 DÜZENLE:

Bir yorum, SecureRandom sınıfının Java 8'deki davranışında bir değişiklikten bahsediyor .

SHA1PRNG ve NativePRNG, java.security dosyasındaki SecureRandom tohum kaynağı özelliklerine uygun şekilde uyması için düzeltildi. (File: /// dev / urandom ve file: / dev /./ urandom kullanarak belirsiz bir geçici çözüm artık gerekli değildir.)

Bu, yukarıda Kaynaklar bölümünde belirtilen testlerle zaten belirtilmişti. Ekstra /./, Java 8'de SecureRanom tarafından kullanılan algoritmayı NativePRNG'den SHA1PRNG'ye değiştirmek için gereklidir.

Ancak paylaşmak istediğim bazı haberlerim var. Gereğince JEP-273 Java 9 beri SecureRandom sınıfının uyguladığı üç Deterministik Rastgele Bit Jeneratör (DRBG) mekanizmalar tarif NIST 800-90Ar1 . Bu mekanizmalar SHA-512 ve AES-256 kadar güçlü modern algoritmalar uygular.

JDK'nın iki tür SecureRandom uygulaması vardı:

Bunlardan biri platforma bağlıdır ve yerel çağrılara veya /dev/{u}randomUnix'te okuma veya Windows'ta CryptoAPI kullanma gibi işletim sistemlerine dayanmaktadır . Linux ve Windows'un en son sürümleri zaten DRBG'yi destekliyor, ancak eski sürümler ve gömülü sistemler desteklemiyor olabilir .
Diğer tür, onaylanmış DRBG mekanizmaları tarafından kullanılan algoritmalar kadar güçlü olmayan eski bir SHA1 tabanlı RNG uygulaması kullanan saf bir Java uygulamasıdır.

Bu arada Java 13 Güvenlik Geliştirici Kılavuzu hala okunuyor

Linux ve macOS'ta java.security'deki entropi toplama cihazı file:/dev/urandomveya olarak ayarlanırsa file:/dev/random, SHA1PRNG yerine NativePRNG tercih edilir. Aksi takdirde, SHA1PRNG tercih edilir.

Yeni DRBG mekanizmalarının önceki PRNG'lerle birlikte nasıl oynadığını açıklığa kavuşturmak için, AdoptOpenJDK (build 13.0.2 + 8) ile macOS (Darwin) üzerinde bazı testler yapıyorum. Sonuçlar burada:

file: / dev / random
Sağlayıcılar için tercih sırası:

SecureRandom.NativePRNG
SecureRandom.DRBG
SecureRandom.SHA1PRNG

file: / dev / urandom
Sağlayıcılar için tercih sırası:

SecureRandom.NativePRNG
SecureRandom.DRBG
SecureRandom.SHA1PRNG

file: / dev /./ urandom
Sağlayıcılar için tercih sırası:

SecureRandom.DRBG
SecureRandom.SHA1PRNG
SecureRandom.NativePRNG

Sonuç:

Beklenmedik bir şekilde bloke kodu almaktan kaçınırken kullanılan platform ne olursa olsun kullanılabilir -Djava.security.egd=file:/dev/./urandomen güçlü SecureRandom uygulamasını kullanarak emin olmak için kullanmanızı tavsiye ederim .

— dbaltor
kaynak

1

Java 8'den itibaren, dosya adındaki fazladan ./ dosyasının "belirsiz çözümü" artık gerekli değildir, bu nedenle yalnızca "/ dev / urandom" kullanabilirsiniz, bkz: docs.oracle.com/javase/8/docs / technotes / guides / security /…

— Kamal

Cevabı güncellediğiniz için teşekkür ederiz (özellikle Java 9 ve 13'teki değişiklikler hakkında). Anladığım kadarıyla, Java 8'in "entropi toplama cihazı" nı / dev / urandom veya /dev/./urandom olarak ayarlaması tam olarak aynı sonuçları vermelidir, aksi takdirde düzeltme mantıklı olmaz. İşletim sistemi perspektifinden bakıldığında, aynı özdeş dosyaya işaret ediyorlar, bu yüzden Java'yı etkilememeli (düzeltmeden önce yapıldı, ancak amaçlanan bir özellik değil, bir hataydı). Bu nedenle "PRNG seçimini etkilemek için ekstra /./ gereklidir" ifadesi. Java 8'den itibaren artık doğru olmamalıdır.

— Kamal

Yorumlarınız için @Kamal'a teşekkürler. Benim önceki ifade "PRNG seçimi" yeterince açık değildi. Kullanılan algoritma hakkında konuştuğumu açıklığa kavuşturdum: NativePRNG veya SHA1PRNG. Kullanımı /dev/urandomseçer NativePRNG beslenen /dev/urandomiken /dev/./urandom(aynı zamanda beslenen kadar SHA1PRNG alır /dev/urandomitibaren Java 9 kaynaktan Java 8. kullanılırken zaman, DRBG öncelik taşır) /dev/./urandomkaynak belirtilir.

— dbaltor

1

JDK 8 veya üstünü kullanıyorsanız, bu artık gerekli değildir

Sorun Java tarafından düzeltildi ve işte bazı bağlantılar

taslak

SHA1PRNG ve NativePRNG, java.security dosyasındaki SecureRandom tohum kaynağı özelliklerine uygun şekilde uyması için düzeltildi. (File: /// dev / urandom ve file: / dev /./ urandom kullanarak belirsiz bir geçici çözüm artık gerekli değildir.)

Daha fazla bilgi için (sayfada rastgele arama yapın):

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

— Venu Madhav
kaynak

Bunun doğru olduğuna inanmıyorum. Arka plan için: tersesystems.com/blog/2015/12/17/… Java 8'deki düzeltmeler artık java.security dosyasındaki SecureRandom tohum kaynağı özelliklerine saygı duyduklarını söylüyor. Ancak varsayılan olarak yine de aşağıdakileri içerir: securerandom.source = file: / dev / random "Belirsiz geçici çözüm", dosya adındaki, burada kabul edilen (ve en çok oylanan) yanıta da değinilen ekstra ./ anlamına gelir.

— Kamal

"Belirsiz geçici çözüm" oldu : Sadece bkz Özel durumlarda gerekli bugs.java.com/bugdatabase/view_bug.do?bug_id=6202721

— Kamal

@Kamal Gönderdiğiniz bağlantılar Java 6 ve öncesi,

— Venu Madhav

Bu tam olarak nokta, Java 8'de düzeltildi. Hata raporuna göre, Java 1.4.2 ve 6'ya kadar sonra "belirsiz geçici çözüm" (dosya adına fazladan / ekleyerek) gerekliydi. Java 7'de de, aksi halde Java 8'de sabit olarak belirtilmez. Engelleme yapmayan bir cihaz kullanmak istiyorsanız, / dev / random yerine / dev / urandom ayarı hala gereklidir.

— Kamal

0

Bu linux /dev/randomve /dev/urandomrasgele sayı üretecinin farkı ile ilgilidir .

Bu bağlantıdan alındı

Java Bug 6202721 , java.security.SecureRandom öğesinin / dev / urandom belirtilse bile / dev / urandom yerine / dev / random kullandığını belirtir (çünkü o sırada (yaklaşık 2004) / dev / urandom düzgün çalışmıyor. / Dev / urandom oldukça iyi çalıştığı için bug hiç bir zaman tersine çevrilmedi. Bu nedenle, / dev / random yerine SHA1PRNG kullanımını zorlamak için /dev/./urandom komutunu kullanarak ayarı gizleyerek bunu yapmak zorundasınız.

Soruna cevap vermek için

Ne zaman uygulanmalı?

Yukarıdaki bağlantıya dayanarak, bu Java sürümleri 5 ve sonrasındaki benzersiz bir şeydir ve 2004'te / dev / urandom ile ilgili Linux sistemlerindeki sorunlardan kaynaklanmıştır.

— Ruelos Joel
kaynak

Java Bug 6202721 aslında "/ dev / urandom / / dev / random düzgün çalışmadığı için seçildiğinde bu bir sorundur" diye belirttiği için muhtemelen bu makalede bir yazım hatası vardır. Bu nedenle "/ dev / urandom ile ilgili sorunlardan kaynaklanan" sonucunuz yanlıştır. Varsayılan (/ dev / random) yerine / dev / urandom seçimiyle ilgili bir açıklama için kabul edilen cevaba bakınız. Çoğu durumda iyi bir fikirdir.

— Kamal