RNG Uygulamalarını Test Etme ve Doğrulama

Rastgele sayı üreteci sınaması temel bir zorlukla karşı karşıyadır: Gerçekten rastgele diziler ile iyi bir PRNG'den üretilen sözde rastgele diziler, istatistiksel sınamalarda birbirinin aynısı görünür. Sonlu uzunluktaki hiçbir sınama bir dizinin rastgele olduğunu kanıtlayamaz; istatistik yalnızca rastgele olmama durumunu belirli bir güven düzeyiyle ortaya çıkarabilir. Sınama, bir RNG'nin bariz yanlılıklara veya örüntülere sahip olmadığını doğrular; ancak kriptografik güvenliği kanıtlayamaz. Kriptografik RNG sınamasının iki farklı amacı vardır: (1) istatistiksel kalite — çıktı dağılımının düzgün ve bağımsız göründüğünü doğrulamak; (2) kriptografik güç — DRBG algoritmasının doğru uygulandığını ve güvenlik iddialarının geçerli olduğunu doğrulamak. Bu amaçlar farklı sınama yaklaşımları gerektirir.

NIST SP 800-22, bit dizilerini değerlendirmek için 15 istatistiksel sınama sunar. Sınamalar şunları içerir: Frekans (tek bit) sınaması — 1'lerin oranı 0,5'e yakın olmalıdır. Blok frekansı sınaması — her m bitlik bloktaki 1'lerin frekansı. Seri sınaması — aynı bitlerden oluşan kesintisiz serilerin sayısı. En uzun seri sınaması — 1'lerden oluşan en uzun serinin uzunluğu. İkili matris rütbe sınaması — diziden oluşturulan ikili matrislerin rütbesi. Spektral sınama (DFT) — dönemsel örüntüleri saptar. Örtüşen şablon eşleştirme — belirli örüntülerin oluşumlarını sayar. Maurer'in evrensel istatistiksel sınaması — diziyi sıkıştırır ve ne kadar kısaldığını ölçer. Her sınama bir p-değeri üretir; p < 0,01 rastgele olmama durumuna işaret eder. Sınamalar 1 milyon ila 1 milyar bit üzerinde gerçekleştirilir.

TestU01 (L'Ecuyer ve Simard, 2007), RNG topluluğunda yaygın olarak kullanılan kapsamlı bir istatistiksel sınama paketidir. SmallCrush: 10 sınama, yaklaşık 35 saniye; hızlı kontroller için uygundur. Crush: 144 sınama, yaklaşık 2 saat. BigCrush: 160 sınama, yaklaşık 24 saat. BigCrush sınamaları, NIST SP 800-22'nin gözden kaçırdığı ince korelasyonları yakalar. İyi tasarlanmış kriptografik DRBG'ler (HMAC_DRBG, CTR_DRBG) BigCrush'tan kolayca geçer; çünkü çıktıları polinom zamanlı algoritmalar açısından rastgeleden hesaplamalı olarak ayırt edilemez. Kriptografik olmayan PRNG'ler (Mersenne Twister, doğrusal kongruans üreteçleri) bazı BigCrush sınamalarında başarısız olur. BigCrush'taki başarısızlık, RNG'nin kriptografik amaçlarla kullanılmaması gerektiğinin güçlü bir göstergesidir.

SP 800-90B ve 90A, DRBG'lerin çalışma sırasında sürekli gerçekleştirmesi gereken sağlık sınamalarını tanımlar. Sürekli RNG Sınaması (CRNGT): Üretilen her blok bir önceki blokla karşılaştırılır; eşit olmaları (RNG'nin takılı kalması) durumunda DRBG bir hata durumuna geçmeli ve üretimi durdurmalıdır. Tekrarlama Sayısı Sınaması: Ardışık örnekler, entropi tahmini göz önüne alındığında istatistiksel olarak beklenenden daha fazla kez aynı değeri tekrarlarsa başarısız olur. Uyarlanabilir Oran Sınaması: En sık görülen değer bir pencere içinde eşik sayısından daha fazla ortaya çıkarsa başarısız olur. Bu sağlık sınamaları, kriptografik anahtar üretimini fark ettirmeden tehlikeye atmadan önce entropi kaynağı arızalarını (takılı kalmış sensör, HWRNG donanım arızası) saptar.

PractRand, önceden belirlenmiş bir uzunluk gerektirmek yerine diziyi üretildiği sırada çözümlemek üzere tasarlanmış, çevrimiçi (akış) değerlendirme yapan modern bir RNG sınama aracıdır. Aralık sınamaları, bit dağılımı sınamaları ve uyarlamalı kesinliğe sahip spektral sınamalar da dâhil olmak üzere çeşitli sınamalar uygular. PractRand, kısa dizilerde iyi sonuç veren ancak milyarlarca bit boyunca örüntüler ortaya çıkaran RNG'leri saptamada özellikle etkilidir. Kriptografik DRBG'ler, uzunluk ne olursa olsun PractRand'ın çıktıyı rastgele olandan ayırt edemeyeceği biçimde üretir; bu, hesaplamalı ayırt edilemezliğin işlemsel tanımıdır. PractRand, donanım arızalarını veya sistematik yanlılıkları saptamak amacıyla entropi kaynaklarını değerlendirmek için de kullanılır (`/dev/urandom` çıktısını ve RDRAND çıktısını sınamak gibi).

Kriptografik Algoritma Doğrulama Programı (CAVP), SP 800-90A DRBG'leri için resmî sınama vektörleri sağlar. CAVP sınaması, bir uygulamanın bilinen yanıt sınaması (KAT) vektörleriyle NIST'in otomatik sınama sistemine gönderilmesini içerir: Belirli bir entropi girdisi, nonce, kişiselleştirme dizesi ve additional_input verildiğinde uygulama, beklenen çıktı bitlerini eksiksiz olarak üretmelidir. CAVP istatistiksel özellikleri sınamaz; algoritmik doğruluğu sınar. FIPS 140-3 sertifikasyonu, modül sınırları içinde kullanılan tüm kriptografik algoritmalar için CAVP doğrulaması gerektirir. CAVP sınama vektörleri NIST'in ACVP (Otomatik Kripto Doğrulama Protokolü) sunucusunda herkese açıktır ve OpenSSL, mbedTLS ve BoringSSL sınama paketlerine entegre edilmiştir.

Bir DRBG güvenli biçimde başlatılmadan önce entropi kaynağı doğrulanmalıdır. SP 800-90B şunları tanımlar: (1) Entropi tahmini — bit başına gerçek entropiyi istatistiksel sınamalarla ölçme (minimum entropi tahmini). (2) Başlangıç sınamaları — entropi kaynağının ilk kullanımdan önce geçerli çıktı ürettiğini doğrulama. (3) İsteğe bağlı sınamalar — uygulama tarafından tetiklenen isteğe bağlı sınamalar. (4) Gürültü kaynağı sağlık sınamaları — donanım bozulmasını saptama. Yaygın entropi kaynakları ve bit başına tahmini entropileri şöyledir: CPU RDRAND/RDSEED (bit başına yaklaşık 1 bit, donanım tarafından sertifikalandırılmış); /dev/urandom (birden çok kaynağı birleştirir, entropi tahmini ihtiyatlıdır); halka osilatörü TRNG'si (tasarıma bağlı olarak bit başına 0,5-0,9 bit); ADC gürültüsü (bit başına 0,1-0,5 bit). SP 800-90B doğrulaması, özel ekipmanla laboratuvar sınaması gerektirir.

Sanal ortamlar, RNG sınaması açısından özgül zorluklar ortaya çıkarır. VM'ler başlangıçta (donanım olayları yokken) veya anlık görüntü geri yüklendikten sonra (durum sıfırlandığında) düşük entropili koşullarla karşılaşabilir. Docker kapsayıcıları ana makinenin çekirdek RNG'sini paylaşır; bir kapsayıcı, altta yatan entropi kalitesini doğrudan sınayamaz. VM dağıtımları için sınamalar: (1) /dev/random okumasının tamamlanmasına kadar geçen süreyi ölçün; uzun beklemeler yetersiz entropiye işaret eder. (2) Paralel VM örneklerinde oluşturulan UUID'lerin veya anahtarların yinelenip yinelenmediğini sınayın (bulut dağıtımlarında belgelenmiş gerçek bir hata durumu). (3) VM'lerde VIRTIO-RNG'nin (virtio_rng.ko) yüklü olduğunu doğrulayın; bu, ana makineden konuk sisteme entropi aktarımı sağlar. (4) Uygulamanın başlatma sırasını denetleyin: yeterli entropi kullanılabilir olmadan önce anahtar oluşturma gerçekleşiyor mu?

RNG'nin çatallanma güvenliğini sınamak, incelikli bir güvenlik açığını önler: bir süreç çatallandığında üst ve alt süreç aynı DRBG durumunu paylaşır ve bu da aynı dizileri üretmelerine neden olur. Algılama yöntemi: N alt süreç oluşturun, her birinde bir UUID üretin ve tüm UUID'lerin benzersiz olduğunu doğrulayın. Herhangi iki UUID eşleşirse RNG çatallanma açısından güvenli değildir. OpenSSL, 2020'de çatallanma güvenliğiyle ilgili bir hatayı düzeltti (CVE-2020-1971 doğrudan DRBG ile ilgili değildi, ancak örüntü benzerdir). Güncel OpenSSL, PID tabanlı bir tohum güncellemesi kullanır: PID son çağrıdan bu yana değişmişse (bu durum bir çatallanmayı gösterir), DRBG otomatik olarak yeniden tohumlanır. Bunu sınamak için sınamayı çatallanmadan önce ve sonra çalıştırın; farklı çıktıları doğrulayarak yeniden tohumlamanın gerçekleştiğini teyit edin.

RNG gerçekleştirimleri için pratik bir denetim listesi: (1) RNG, zaman tabanlı tohumlar yerine OS'den (getrandom, BCryptGenRandom) başlatılıyor mu? (2) DRBG türü, NIST SP 800-90A tarafından onaylanmış bir mekanizma mı (Özet, HMAC, CTR)? (3) Tohum uzunluğu, belirtilen güvenlik gücü için yeterli mi? (4) Yeniden tohumlama, düzenli aralıklarla veya sabit sayıda üretim çağrısından sonra tetikleniyor mu? (5) Gerçekleştirim çatallanma güvenliğini ele alıyor mu (çatallanma sonrasında yeniden tohumlama)? (6) Sağlık sınamaları etkin mi ve başarısızlık durumunda sistemi durduruyor mu? (7) Kapanma sırasında durumun tümüyle sıfırlandığından emin olunuyor mu? (8) CAVP sınama vektörleri CI/CD'de çalıştırılıyor mu? (9) Entropi tahminleri belgelenmiş ve doğrulanmış mı? (10) FIPS gereksinimleri açısından modül FIPS 140-3 sertifikalı mı?

Tarihsel RNG arızaları, konunun önemini gösterir. Debian OpenSSL (2006-2008): Bir yama, entropi toplama kodunun iki satırını yanlışlıkla kaldırarak tohum havuzunu 15 bitlik bir PID alanına indirdi; Debian kullanıcılarının tamamı için yalnızca 32.767 olası SSH anahtarı üretildi. Debian tarafından oluşturulan tüm SSH ana bilgisayar anahtarlarının ve kullanıcı anahtarlarının değiştirilmesi gerekti. Android Bitcoin cüzdanları (2013): Android'in SecureRandom uygulaması, bazı cihazlarda başarısız olan Java düzeyinde bir tohumlama kullandı ve bu durum ECDSA imzalarında yinelenen k değerlerine yol açarak özel anahtarları doğrudan açığa çıkardı. Sony PS3 (2010): ECDSA üretici yazılımı imzalamada sabit bir tek kullanımlık değer kullandı; bu, iki imzadan özel anahtarın çıkarılmasına olanak verdi (farklı iletilerde aynı k kullanılması, basit cebir yoluyla anahtarı açığa çıkarır).

Aşağıdaki sınamalardan hangisi, bir DRBG'nin takılı kalmış çıktı üretiyor olabileceğini (aynı değeri art arda üretmesini) algılar?

İstatistiksel sınamalar (NIST SP 800-22, TestU01 BigCrush, PractRand) çıktı kalitesini doğrular, ancak kriptografik güvenliği kanıtlayamaz. CAVP bilinen yanıt sınamaları, SP 800-90A gerçekleştirimlerinin algoritmik doğruluğunu doğrular. SP 800-90B entropi kaynağı sınamaları (minimum entropi tahmini, sağlık sınamaları), tohum girdisini doğrular. Sürekli RNG Sınaması (CRNGT), takılı kalmış çıktıyı gerçek zamanlı olarak algılar. VM ve kapsayıcı dağıtımları, entropi aktarımı (VIRTIO-RNG) ve başlangıç entropisi denetimleri gerektirir. Çatallanma güvenliği sınaması, alt süreçlerin üst sürecin DRBG durumunu devralmadığını doğrular. Gerçek dünyadaki arızalar (Debian, Android), RNG hatalarının doğrudan kriptografik anahtarların ele geçirilmesine yol açtığını gösterir. Denetim listeleri, üretim dağıtımları için bu denetimleri biçimsel hâle getirir.