Hash-DRBG, HMAC-DRBG ve CTR-DRBG İç Yapıları

Üç NIST DRBG mekanizmasının her biri, temelindeki algoritmik yaklaşımı yansıtan farklı iç durum bileşenlerini korur. Hash_DRBG, V'yi (karma uzunluğunda bir tohum) ve çıktı üretimi sırasında kullanılan, V'den türetilmiş bir sabit olan C'yi saklar. HMAC_DRBG, Key K'yi (karma uzunluğunda gizli bir anahtar) ve Value V'yi (karma uzunluğunda bir zincirleme değeri) saklar. CTR_DRBG, Key K'yi (bir AES anahtarı) ve V'yi (blok uzunluğunda bir sayaç) saklar. Bu üç mekanizma da son tohumlamadan bu yana yapılan üretim çağrılarını izleyen bir reseed_counter değerini korur. Durum boyutu bellek ayak izini belirler: SHA-256 kullanan Hash/HMAC_DRBG 64 baytlık duruma, AES-256 kullanan CTR_DRBG ise 48 bayta (32 baytlık anahtar + 16 baytlık sayaç) ihtiyaç duyar.

Hash_DRBG, entropi malzemesinden durum türetmek için Hash_df'yi (karma türetme işlevi) kullanır. Hash_df(input_string, no_of_bits_to_return), şu işlemi yineler: counter = 1, 2, ... için H(counter || no_of_bits || input_string) hesaplanır ve yeterli bit üretilene kadar çıktılar birleştirilir. Bu işlem, kısa entropi girdilerini durum boyutunda tohumlara genişletir. Generate sırasında çıktı işlevi, W = H(0x03 || V) değerini hesaplar; 0x03 öneki bu kullanımı diğer karma kullanımlarından ayırır. Çıktı döngüsü şöyledir: data = H(0x01 || V); V = V + 1; daha fazla çıktı için yinelenir. Üretimden sonra V güncellenir: V = V + H(0x03 || V) + C + reseed_counter. Önek baytları (0x01, 0x03) aracılığıyla yapılan alan ayrımı, üretim aşamasındaki çıktının durum güncelleme aşamasıyla karıştırılmasını önler.

HMAC_DRBG'nin Update işlevi, tüm durum geçişlerinin temelidir. Update(provided_data, K, V): K = HMAC(K, V || 0x00 || provided_data); V = HMAC(K, V). provided_data boş değilse: K = HMAC(K, V || 0x01 || provided_data); V = HMAC(K, V). Bu iki aşamalı güncelleme, yeni anahtarın ve değerin hem önceki duruma hem de yeni entropiye bağlı olmasını sağlar. Generate sırasında, yeterli bit üretilene kadar V = HMAC(K, V) yinelenir ve çıktıya eklenir; ardından durumu ilerletmek için additional_input ile Update çağrılır. HMAC_DRBG'nin güvenliği, HMAC'in güvenli bir sözde rastgele işlev olduğu varsayımına indirgenir: HMAC çıktısını rastgele çıktıdan ayırt edemeyen bir saldırgan, DRBG çıktısını da rastgele çıktıdan ayırt edemez.

CTR_DRBG, tohum malzemesini anahtar/sayaç biçimine dönüştürmek için Block_Cipher_df'yi (türetme işlevi) kullanır. Block_Cipher_df(input_string, no_of_bits), bir BCC (Blok Şifre Zincirleme) yapısı kullanır: gerekli uzunlukta çıktı üretmek için girdi parçaları üzerinde AES-CBC işlemini yineler. Türetme işlevi, değişken uzunluktaki entropi girdilerini işlemek ve alan ayrımı sağlamak için gereklidir. Türetme işlevi olmayan CTR_DRBG (FIPS sınamalarında tam biçimlendirilmiş girdiler için kullanılmasına izin verilir) daha hızlıdır, ancak girdi biçimi gereksinimlerine karşı daha hassastır. Generate döngüsü şöyledir: temp = E(K, V); V = V + 1; temp çıktıya eklenir. Update işlemi şöyledir: K || V = Block_Cipher_df(V || additional_input, seedlen); ardından geçerli anahtarla XOR uygulanır.

Performans, DRBG türleri arasında önemli ölçüde değişir. AES-NI destekli modern bir x86_64 CPU'da CTR_DRBG (AES-256), yaklaşık 5-10 GB/s sözde rastgele çıktı üretir; AES-NI yönergesi AES hesaplamasını neredeyse maliyetsiz hâle getirir. HMAC_DRBG (SHA-256), yaklaşık 200-400 MB/s hıza ulaşır; SHA-256 hızlıdır, ancak aynı ölçüde donanım hızlandırmalı değildir. Hash_DRBG (SHA-256), yaklaşık 100-300 MB/s hıza ulaşır. Toplu anahtar üretimi veya akış şifresinin yerine kullanım için CTR_DRBG çok daha hızlıdır. Düşük aktarım hızlı kullanımlarda (oturum anahtarı üretimi, tek kullanımlık değer türetme) performans farkı önemsizdir. OpenSSL 3.0 bu nedenle varsayılan olarak CTR_DRBG (AES-256) kullanır.

Başlatma sırasında üç DRBG'nin tümü, DRBG örneğini benzersiz kılmak üzere entropi girdisiyle birleştirilen isteğe bağlı bir personalization_string kabul eder. Bu, aynı entropiyle eşzamanlı olarak başlatılan iki DRBG'nin aynı çıktıyı üretmesini önler; örnekler personalization_string değerine göre farklı akışlar üretir. Önerilen personalization_string değerleri şunlardır: uygulama tanımlayıcısı + işlem kimliği + iş parçacığı kimliği + zaman damgası + donanım tanımlayıcısı. İki VM aynı entropiyi alsa bile (bulut VM anlık görüntülerinde görülen bir sorun), farklı kişiselleştirme dizeleri farklı DRBG akışlarını garanti eder. NIST SP 800-90C, her zaman bir kişiselleştirme dizesi kullanılmasını önerir. Tek kullanımlık değer parametresi de benzer bir amaca hizmet eder: hiçbir iki başlatmanın aynı durumda başlamamasını sağlayan benzersiz, kısa bir değer.

Üç DRBG'nin tümü, Generate çağrılarında bir additional_input parametresini destekler. Bu, çağıranın tam bir yeniden tohumlama yapmadan tek bir üretim çağrısına ek bağlam veya entropi eklemesine olanak tanır. Kullanım alanları: (1) ikincil bir entropi kaynağından istek başına entropi eklemek; (2) üretilen değerleri kullanımlarıyla ilişkilendirmek için uygulama düzeyinde bağlam sağlamak (istek ID'si, zaman damgası); (3) işletim sisteminden taze entropi ekleyerek isteğe bağlı öngörü direnci sağlamak. Additional_input, çıktı üretilmeden önce DRBG durumuna karıştırılır. additional_input gerçek entropi sağlıyorsa, entropi kaynağı arabirimini ve buna bağlı ek yükü içeren biçimsel bir yeniden tohumlama gerektirmeden güvenliği artırır.

Bir DRBG örneği kaldırıldıktan sonra veya yeni bir örneğe geçilirken iç durum güvenli bir şekilde sıfırlanmalıdır. State V, C (Hash_DRBG), K, V (HMAC/CTR_DRBG) ve tüm ara çalışma değişkenlerinin üzerine sıfırlar yazılmalıdır. Buna açıkça sıfırlama adı verilir ve FIPS 140-3 modüllerinde zorunludur. C kodunda explicit_bzero() veya SecureZeroMemory() kullanın; derleyici tarafından iyileştirilmiş bir memset, ölü depolama iyileştirmesi nedeniyle kaldırılabilir ve anahtar malzemesini bellekte bırakabilir. Rust'ın zeroize paketi ve dile özgü benzer çözümler bu işlemi taşınabilir biçimde gerçekleştirir. Güvenli anahtar yok etme, bellek dökümlerinin, soğuk başlatma saldırılarının veya süreç inceleme araçlarının artık durumu açığa çıkarabileceği bağlamlarda önemlidir.

NIST, tüm SP 800-90A DRBG'leri için Kriptografik Algoritma Doğrulama Programı (CAVP) sınama vektörleri sağlar. Sınama türleri: (1) Bilinen Yanıt Sınamaları (KAT'ler) — sabit bir entropi girdisi, tek kullanımlık değer ve kişiselleştirme dizesi verildiğinde üretilen çıktının önceden hesaplanmış değerlerle eşleştiğini doğrular. (2) Yeniden tohumlama sınamaları — yeniden tohumlama işleminden sonraki DRBG durumunu doğrular. (3) PR (Öngörü Direnci) sınamaları — prediction_resistance=true istenmesinin, taze entropi eklendikten sonra doğru çıktıyı ürettiğini doğrular. FIPS 140-3 başvurusu için CAVP doğrulaması gereklidir. Açık kaynaklı kitaplıklar olan OpenSSL ve mbedTLS, DRBG uygulamalarındaki gerilemeleri yakalamak için CAVP sınama vektörlerini gerileme sınaması takımlarına dâhil eder.

DRBG uygulamaları, algoritmik güvenlik modelinin ötesinde ince yan kanal riskleriyle karşı karşıyadır. AES-NI olmayan CTR_DRBG'de önbellek zamanlama saldırıları tur anahtarı malzemesini sızdırabilir; AES-NI, tablo araması yapmadan yazmaçlarda hesaplama gerçekleştirerek bunu ortadan kaldırır. HMAC_DRBG, temelindeki SHA-256 sabit zamanlı olduğu sürece sabit zamanlı olan HMAC'i dahili olarak kullanır; SHA-256'da veriye bağlı dallanmalar bulunmadığından genellikle sabit zamanlı kabul edilir. DRBG üreten donanıma yönelik fiziksel yan kanallar (güç analizi, EM yayılımı), akıllı kartlar ve nesnelerin interneti cihazları için bir endişe kaynağıdır; bunlar maskeleme uygulamalarıyla ele alınır. Durum yedekleme saldırısında, bir saldırgan bellek açığı aracılığıyla DRBG durumunu okuyabilirse (Heartbleed benzeri bir durumda), taze entropiyle yapılacak bir sonraki yeniden tohumlamaya kadar tüm gelecek çıktı tehlikeye girer.

Bir DRBG durumu ele geçirilirse (örneğin bir bellek açığı aracılığıyla), kurtarma şu adımları gerektirir: (1) Ele geçirilmeyi algılamak — DRBG durumu sızıntıları kendiliğinden belli olmaz; harici izleme veya bütünlük denetimleri gerekir. (2) Ele geçirmeye dâhil olmayan güvenilir bir kaynaktan alınan taze entropiyle yeniden tohumlamak. (3) Ele geçirilen DRBG'den türetilen tüm kriptografik malzemeyi yeniden anahtarlamak (oturum anahtarları ve son sağlıklı yeniden tohumlamadan bu yana üretilen imzalama anahtarları). (4) Yazılım uygulamalarında süreci yeniden başlatmak temiz bir DRBG başlatması sağlar. SP 800-90C, zincirlenmiş entropi kaynaklarını önerir; bir kaynak ele geçirilirse diğer kaynak gerçek entropi sağladığı sürece birleşim güvenliği korur.

Modern CPU'larda toplu sözde rastgele çıktı üretimi için hangi DRBG mekanizması en hızlıdır?

Hash_DRBG, türetme için Hash_df ile yinelemeli karma kullanır ve çıktıyı H(0x01 || V) döngüleriyle üretir. HMAC_DRBG, anahtardan sonra değeri güncelleyen iki aşamalı Update işleviyle bir sözde rastgele işlev olarak HMAC'i kullanır ve açık bir güvenlik indirgemesi sağlar. CTR_DRBG, Block_Cipher_df ile birlikte AES'i sayaç kipinde kullanır ve AES-NI donanımında 5-10 GB/s hıza ulaşır. Üçü de örnek benzersizliği için başlatma sırasında personalization_string ve bağlam ilişkilendirme için her üretim çağrısında additional_input kabul eder. CAVP sınama vektörleri uygulamaları doğrular. Durum kullanımdan sonra güvenli biçimde sıfırlanmalıdır. Durumun ele geçirilmesi, taze entropiyle yeniden tohumlama ve türetilen malzemenin yeniden anahtarlanmasını gerektirir.