Entropi Tükenmesi ve Zayıf Anahtar Hataları

Entropi tükenmesi, bir sistemde CSPRNG'sini tohumlamak için yeterli öngörülemez girdi bulunmadığında meydana gelir. Bu durum yeni başlatılmış gömülü cihazlarda, sanallaştırılmış sunucularda veya kullanıcı girdisi bulunmayan sistemlerde görülür. RNG çıktısı öngörülebilir hâle gelir.

2006'da bir Debian geliştiricisi, Valgrind tarafından işaretlenen şu satırı kaldırdı: MD_Update(&m, buf, j). Bu satır entropi kaynağıydı. Sonuç olarak Debian üzerindeki OpenSSL yalnızca PID ile tohumlandı (en fazla 32.768 değer). 2006-2008 arasında üretilen tüm anahtarlar 32.768 olasılıktan oluşan bir kümededir.

2006-2008 arasında Debian/Ubuntu sistemlerinde üretilen RSA, DSA ve ECDSA anahtarları, SSH ana bilgisayar anahtarları, TLS sertifikaları ve SSL VPN anahtarları ele geçirildi. Etkilenen sistemler: Debian Etch, Debian Lenny, Ubuntu 7.04-8.04. Kara listeler yayımlandı; sertifikalar iptal edildi.

Sanal makineler aynı disk durumuyla kopyalanabilir. Her iki sanal makine de anahtarları aynı CSPRNG durumundan üretirse aynı anahtarları oluşturur. Hiper yöneticiler artık VirtIO RNG veya ACPI tabloları aracılığıyla entropi enjekte ediyor; ancak hatalı yapılandırılmış sanal makineler önyükleme sırasında hâlâ bu riskle karşı karşıyadır.

IoT cihazları (yönlendiriciler, kameralar), entropi biriktirmeden önce ilk önyüklemede SSH/TLS anahtarları üretir. Araştırmalar, milyonlarca cihazın birkaç bin RSA anahtar çiftini paylaştığını ortaya koydu; çünkü hepsi aynı düşük entropili önyükleme durumundan tohumlanmıştı.

Lenstra ve diğerleri (2012), 11,7 milyon TLS sertifikası topladı ve çiftler hâlinde GCD'ler hesapladı. Bir asal çarpanı paylaşan 12.720 RSA anahtarı bulundu — bu, her iki anahtarın da tamamen çarpanlarına ayrılabileceği anlamına geliyordu. Tüm açık anahtarların %0,2'si kırılmıştı. Neden: yetersiz önyükleme entropisi.

ECDSA, imza başına benzersiz bir rastgele tek kullanımlık sayı k gerektirir. k yeniden kullanılırsa (veya zayıfsa) özel anahtar hemen kurtarılabilir: d = (s1-s2)^{-1} * (z1-z2) * k / (r1-r2) mod n. Sony'nin PS3'ünde k=constant kullanıldı — kurtarılan anahtarla tüm oyunlar imzalanabildi.

Android 4.x'te Java SecureRandom, belirli koşullarda sistem zamanıyla tohumlanıyordu. Birden fazla Bitcoin cüzdanı uygulaması aynı k tek kullanımlık sayısıyla imzalar üreterek özel anahtarları açığa çıkardı. Milyonlarca dolar çalındı. Google, SecureRandom uygulamasına düzeltme yayımladı.

Araçlar: ssh-vulnkey (Debian zayıf anahtar kara listesine göre kontrol eder), badkeys (TLS sertifikalarını bilinen zayıf asal sayılara karşı kontrol eder), toplu RSA anahtarı denetimi için GCD-toplu işlem algoritması. Certificate Transparency günlükleri, tüm nüfus ölçeğinde çözümlemeyi mümkün kılar.

İlk anahtar üretiminde getrandom(GRND_RANDOM) kullanın. İlk tohumlamanın tamamlanmasını bekledikten sonra /dev/urandom'dan okuyun (/proc/sys/kernel/random/entropy_avail > 128 değerini kontrol edin). Tamamlayıcı entropi olarak donanım RNG'si (RDRAND) kullanın. Gecikme olmadan ilk önyüklemede asla anahtar üretmeyin.

CSPRNG durumunu yeniden başlatmalar arasında koruyun: kapatma sırasında /dev/urandom'dan 32 bayt okuyup bir tohum dosyasına kaydedin; önyükleme sırasında okuyup geri besleyin. Bu, soğuk açılışlar arasında entropi sürekliliği sağlar. Linux bunu otomatik olarak yapar; gömülü sistemler ise çoğu zaman yapmaz.

Debian OpenSSL entropi hatasının temel nedeni neydi?

Entropi tükenmesi, öngörülebilir anahtarlara yol açar. Gerçek dünyadaki kırılmalar: Debian OpenSSL (yalnızca PID ile tohumlama), IoT GCD saldırıları, PS3'te ECDSA tek kullanımlık sayısının yeniden kullanılması ve Android Bitcoin cüzdanı. Her zaman işletim sistemi entropisinden tohumlayın; gömülü anahtar üretimini dikkatle denetleyin. Sıradaki konu: anahtarları, tek kullanımlık sayıları ve IV'leri güvenli biçimde üretmek.