Wewnętrzne działanie Hash-DRBG, HMAC-DRBG i CTR-DRBG

Każdy z trzech mechanizmów DRBG firmy NIST przechowuje inne składniki stanu wewnętrznego, co odzwierciedla zastosowane podejście algorytmiczne. Hash_DRBG przechowuje V (ziarno o długości skrótu) oraz C (stałą wyprowadzoną z V, używaną podczas generowania danych wyjściowych). HMAC_DRBG przechowuje klucz K (tajny klucz o długości skrótu) oraz wartość V (wartość łańcuchową o długości skrótu). CTR_DRBG przechowuje klucz K (klucz AES) oraz V (licznik o długości bloku). Wszystkie trzy mechanizmy utrzymują reseed_counter, który zlicza wywołania generate od ostatniej inicjalizacji. Rozmiar stanu określa zajmowany obszar pamięci: Hash/HMAC_DRBG z SHA-256 używają 64 bajtów stanu, a CTR_DRBG z AES-256 używa 48 bajtów (klucz 32-bajtowy + licznik 16-bajtowy).

Hash_DRBG używa Hash_df (funkcji wyprowadzania opartej na funkcji skrótu) do wyprowadzania stanu z materiału entropijnego. Hash_df(input_string, no_of_bits_to_return) wykonuje iteracje: dla counter = 1, 2, ... oblicza H(counter || no_of_bits || input_string) i łączy wyniki, aż powstanie wystarczająca liczba bitów. W ten sposób krótkie dane entropijne są rozwijane do ziaren o rozmiarze stanu. Podczas Generate funkcja wyjściowa oblicza W = H(0x03 || V), przy czym prefiks 0x03 odróżnia to zastosowanie od innych zastosowań funkcji skrótu. Pętla generowania danych wyjściowych wygląda następująco: data = H(0x01 || V); V = V + 1; operacja jest powtarzana w celu uzyskania większej ilości danych. Po wygenerowaniu danych V jest aktualizowane: V = V + H(0x03 || V) + C + reseed_counter. Separacja domen za pomocą bajtów prefiksu (0x01, 0x03) uniemożliwia pomylenie danych wyjściowych z fazy generowania z fazą aktualizacji stanu.

Funkcja Update w HMAC_DRBG jest podstawą wszystkich zmian stanu. Update(provided_data, K, V): K = HMAC(K, V || 0x00 || provided_data); V = HMAC(K, V). Jeśli provided_data nie jest puste: K = HMAC(K, V || 0x01 || provided_data); V = HMAC(K, V). Ta dwuetapowa aktualizacja gwarantuje, że zarówno nowy klucz, jak i nowa wartość zależą od poprzedniego stanu oraz wszelkiej nowej entropii. Generate: powtarzaj V = HMAC(K, V) i dołączaj wyniki do danych wyjściowych, aż uzyskasz wystarczającą liczbę bitów; następnie wywołaj Update z additional_input, aby przesunąć stan do przodu. Bezpieczeństwo HMAC_DRBG sprowadza się do założenia, że HMAC jest bezpieczną PRF: przeciwnik, który nie potrafi odróżnić danych wyjściowych HMAC od losowych, nie potrafi też odróżnić danych wyjściowych DRBG od losowych.

CTR_DRBG używa Block_Cipher_df (funkcji wyprowadzania) do przekształcania materiału inicjalizacyjnego w format klucza i licznika. Block_Cipher_df(input_string, no_of_bits) wykorzystuje konstrukcję BCC (Block Cipher Chaining): wykonuje iteracje AES-CBC na fragmentach danych wejściowych, aby uzyskać wynik o wymaganej długości. Funkcja wyprowadzania jest niezbędna do obsługi danych entropijnych o zmiennej długości oraz zapewnienia separacji domen. CTR_DRBG bez funkcji wyprowadzania (dopuszczany w testach FIPS dla precyzyjnie sformatowanych danych wejściowych) działa szybciej, ale jest bardziej wrażliwy na wymagania dotyczące formatu danych wejściowych. Pętla Generate: temp = E(K, V); V = V + 1; dołącz temp do danych wyjściowych. Aktualizacja: K || V = Block_Cipher_df(V || additional_input, seedlen); zastosuj XOR z bieżącym kluczem.

Wydajność różni się znacznie w zależności od typu DRBG. Na nowoczesnym procesorze x86_64 z AES-NI CTR_DRBG (AES-256) osiąga około 5–10 GB/s pseudolosowych danych wyjściowych — instrukcja AES-NI sprawia, że obliczenia AES mają niemal pomijalny koszt. HMAC_DRBG (SHA-256) osiąga około 200–400 MB/s — SHA-256 działa szybko, ale nie jest przyspieszany sprzętowo w takim samym stopniu. Hash_DRBG (SHA-256) osiąga około 100–300 MB/s. W przypadku masowego generowania kluczy lub zastępowania szyfru strumieniowego CTR_DRBG jest zdecydowanie szybszy. Przy zastosowaniach o małej przepustowości, takich jak generowanie kluczy sesyjnych czy wyprowadzanie wartości nonce, różnica wydajności jest nieistotna. Z tego powodu OpenSSL 3.0 używa domyślnie CTR_DRBG (AES-256).

Podczas inicjalizacji wszystkie trzy DRBG przyjmują opcjonalny personalization_string, który jest mieszany z danymi entropijnymi, aby nadać unikatowość instancji DRBG. Zapobiega to sytuacji, w której dwa równocześnie inicjalizowane DRBG z taką samą entropią generują te same dane wyjściowe — ich strumienie rozchodzą się dzięki ciągowi personalizacji. Zalecane ciągi personalizacji to: identyfikator aplikacji + identyfikator procesu + identyfikator wątku + znacznik czasu + identyfikator sprzętowy. Nawet jeśli dwie maszyny wirtualne otrzymają tę samą entropię (problem związany z migawką maszyny wirtualnej w chmurze), różne ciągi personalizacji zapewnią różne strumienie DRBG. NIST SP 800-90C zaleca zawsze używanie ciągu personalizacji. Parametr nonce pełni podobną funkcję: jest unikatową krótką wartością, która gwarantuje, że żadne dwie inicjalizacje nie rozpoczną pracy w tym samym stanie.

Wszystkie trzy DRBG obsługują parametr additional_input w wywołaniach Generate. Pozwala on wywołującemu wprowadzić dodatkowy kontekst lub entropię do pojedynczego wywołania generowania bez pełnego ponownego zainicjalizowania. Zastosowania: (1) wprowadzanie entropii dla każdego żądania z pomocniczego źródła entropii; (2) przekazywanie kontekstu na poziomie aplikacji (identyfikatora żądania, znacznika czasu) w celu powiązania wygenerowanych wartości z ich zastosowaniem; (3) opcjonalne zapewnienie odporności na przewidywanie przez wprowadzanie świeżej entropii z systemu operacyjnego. additional_input jest mieszane ze stanem DRBG przed wygenerowaniem danych wyjściowych. Jeśli additional_input dostarcza rzeczywistej entropii, zwiększa bezpieczeństwo bez konieczności formalnego ponownego zainicjalizowania, które wymaga interfejsu źródła entropii i wiąże się z dodatkowym kosztem.

Po usunięciu instancji DRBG lub przełączeniu na nową instancję stan wewnętrzny musi zostać bezpiecznie wyzerowany. Stan V, C (Hash_DRBG), K, V (HMAC/CTR_DRBG) oraz wszystkie pośrednie zmienne robocze muszą zostać nadpisane zerami. Nazywa się to jawnym zerowaniem i jest obowiązkowe w modułach FIPS 140-3. W kodzie C należy używać explicit_bzero() lub SecureZeroMemory() — kompilator może usunąć zoptymalizowane wywołanie memset jako niepotrzebny zapis, pozostawiając materiał kluczowy w pamięci. Pakiet Rust zeroize i podobne rozwiązania właściwe dla poszczególnych języków obsługują to w sposób przenośny. Bezpieczne niszczenie kluczy jest ważne w sytuacjach, w których zrzuty pamięci, ataki typu cold boot lub narzędzia do inspekcji procesów mogłyby ujawnić pozostałości stanu.

NIST udostępnia wektory testowe Cryptographic Algorithm Validation Program (CAVP) dla wszystkich DRBG zgodnych z SP 800-90A. Typy testów: (1) Known Answer Tests (KATs) — przy ustalonych danych entropijnych, wartości nonce i ciągu personalizacji należy sprawdzić, czy wygenerowane dane wyjściowe odpowiadają wcześniej obliczonym wartościom. (2) Testy ponownego zainicjalizowania — należy sprawdzić stan DRBG po operacji ponownego zainicjalizowania. (3) Testy PR (Prediction Resistance) — należy sprawdzić, czy żądanie prediction_resistance=true daje poprawne dane wyjściowe po wprowadzeniu świeżej entropii. Walidacja CAVP jest wymagana przy składaniu wniosku o certyfikację FIPS 140-3. Biblioteki open source, takie jak OpenSSL i mbedTLS, zawierają wektory testowe CAVP w swoich zestawach testów regresyjnych, aby wykrywać regresje w implementacjach DRBG.

Implementacje DRBG są narażone na subtelne zagrożenia kanałami bocznymi wykraczające poza model bezpieczeństwa algorytmu. Ataki czasowe wykorzystujące pamięć podręczną na AES (w CTR_DRBG bez AES-NI) mogą ujawnić materiał kluczy rund; AES-NI eliminuje ten problem, wykonując obliczenia w rejestrach bez odwołań do tablic. HMAC_DRBG wewnętrznie używa HMAC, który działa w czasie stałym, jeśli bazowa implementacja SHA-256 również działa w czasie stałym — SHA-256 jest zasadniczo uznawany za algorytm działający w czasie stałym, ponieważ nie zawiera rozgałęzień zależnych od danych. Fizyczne kanały boczne (analiza poboru mocy, promieniowanie elektromagnetyczne) dotyczące sprzętu generującego dane DRBG stanowią zagrożenie w przypadku kart inteligentnych i urządzeń IoT; przeciwdziała się im za pomocą implementacji z maskowaniem. Atak oparty na kopii stanu: jeśli przeciwnik może odczytać stan DRBG dzięki podatności ujawniającej pamięć (w stylu Heartbleed), wszystkie przyszłe dane wyjściowe są zagrożone aż do następnego ponownego zainicjalizowania z użyciem świeżej entropii.

Jeśli stan DRBG zostanie naruszony, na przykład w wyniku podatności ujawniającej pamięć, odzyskanie wymaga: (1) wykrycia naruszenia — wycieki stanu DRBG nie są oczywiste same z siebie, dlatego potrzebne jest zewnętrzne monitorowanie lub kontrole integralności; (2) ponownego zainicjalizowania z użyciem świeżej entropii z zaufanego źródła, które nie było objęte naruszeniem; (3) ponownego utworzenia wszystkich materiałów kryptograficznych wyprowadzonych z naruszonego DRBG, takich jak klucze sesyjne i klucze podpisu wygenerowane od ostatniego poprawnego ponownego zainicjalizowania; (4) w przypadku implementacji programowych ponownego uruchomienia procesu, co zapewnia czystą inicjalizację DRBG. SP 800-90C zaleca łańcuchowe źródła entropii — jeśli jedno źródło zostanie naruszone, połączenie nadal zapewnia bezpieczeństwo, o ile drugie źródło dostarcza rzeczywistej entropii.

Który mechanizm DRBG jest najszybszy przy masowym generowaniu pseudolosowych danych wyjściowych na nowoczesnych procesorach?

Hash_DRBG używa iteracyjnego haszowania z funkcją wyprowadzania Hash_df, generując dane wyjściowe w pętlach H(0x01 || V). HMAC_DRBG używa HMAC jako PRF oraz dwuetapowej funkcji Update (najpierw klucz, potem wartość), co zapewnia przejrzystą redukcję bezpieczeństwa. CTR_DRBG używa AES w trybie licznika wraz z Block_Cipher_df i osiąga 5–10 GB/s na sprzęcie z AES-NI. Wszystkie mechanizmy przyjmują personalization_string podczas inicjalizacji, aby zapewnić unikatowość instancji, oraz additional_input przy każdym generowaniu, aby powiązać dane z kontekstem. Wektory testowe CAVP służą do walidacji implementacji. Po użyciu stan musi zostać bezpiecznie wyzerowany. Naruszenie stanu wymaga ponownego zainicjalizowania z użyciem świeżej entropii oraz ponownego kluczowania wyprowadzonych materiałów.