NIST SP 800-90A: standardy DRBG

Operacje kryptograficzne wymagają losowych liczb wysokiej jakości: do generowania kluczy, wartości nonce, wektorów IV, soli i tokenów sesji. Generatory liczb prawdziwie losowych (TRNG) pobierają entropię ze źródeł fizycznych (szumu sprzętowego, przerwań, szumu termicznego), ale działają powoli i nie zawsze są dostępne — zwłaszcza na maszynach wirtualnych lub we wczesnej fazie uruchamiania systemu. Deterministyczne generatory bitów losowych (DRBG) rozwiązują ten problem: generator DRBG zasila się niewielką ilością prawdziwej entropii, a następnie używa algorytmu kryptograficznego do rozciągnięcia jej do długiego strumienia pseudolosowych bitów, obliczeniowo nierozróżnialnego od bitów prawdziwie losowych. NIST SP 800-90A definiuje trzy zatwierdzone mechanizmy DRBG używane praktycznie we wszystkich nowoczesnych implementacjach kryptograficznych.

DRBG działa w ramach trzech podstawowych operacji. Instantiate: inicjalizacja wewnętrznego stanu DRBG za pomocą entropy_input (pochodzącego ze źródła entropii), wartości nonce (jednorazowej wartości zapewniającej unikalność) oraz opcjonalnie personalization_string (kontekstu specyficznego dla aplikacji). Generate: wygenerowanie żądanej liczby pseudolosowych bitów i aktualizacja wewnętrznego stanu w celu zapobieżenia odtworzeniu wcześniejszego stanu. Reseed: wprowadzenie świeżej entropii do stanu DRBG w celu zapewnienia odporności na przewidywanie — po ponownym zasileniu nawet przeciwnik znający poprzedni stan nie może przewidzieć przyszłych wyników. NIST określa maksymalne odstępy generowania (reseed_interval): 2^48 żądań przed obowiązkowym ponownym zasileniem dla wszystkich trzech typów DRBG.

NIST SP 800-90A definiuje cztery poziomy siły bezpieczeństwa: 112, 128, 192 i 256 bitów. Siła bezpieczeństwa określa minimalną entropię wymaganą podczas inicjalizacji oraz jakość generowanych wyników. Dla bezpieczeństwa 128-bitowego dane wejściowe entropii muszą zapewniać co najmniej 128 bitów entropii. Zależność jest następująca: security_strength bitów entropii → wynik DRBG obliczeniowo nierozróżnialny od losowego dla przeciwnika wykonującego 2^security_strength operacji. Wybór długości klucza (AES-128 lub AES-256) oraz funkcji skrótu (SHA-256 lub SHA-512) musi odpowiadać docelowej sile bezpieczeństwa lub ją przewyższać. Zawyżenie parametrów (SHA-512 dla bezpieczeństwa 128-bitowego) jest bezpieczne, ale nieefektywne; zaniżenie parametrów narusza bezpieczeństwo.

Hash_DRBG przechowuje dwie wartości stanu: V (wartość generująca wynik) oraz C (stałą dodawaną podczas generowania). Generate: hash_gen generuje bity przez iteracyjne obliczanie H(0x01 || V), H(0x01 || V+1), ... aż do uzyskania wystarczającej liczby wyników; następnie V jest aktualizowane za pomocą V = V + H(0x03 || V) + C + reseed_counter. Reseed: używa Hash_df (funkcji wyprowadzania opartej na skrócie), łącząc bieżące V ze świeżą entropią w celu utworzenia nowych wartości V i C. Hash_DRBG jest prosty w implementacji i ma nieskomplikowaną analizę bezpieczeństwa, dzięki czemu nadaje się do środowisk o ograniczonych zasobach. NIST zaleca inicjalizację z SHA-256 lub SHA-512. Hash_DRBG jest używany w starszym SHA1PRNG w Javie oraz w starszym DRBG biblioteki OpenSSL.

HMAC_DRBG przechowuje stan (klucz K, wartość V). Generate: iteracyjnie oblicza V = HMAC(K, V) aż do wygenerowania wystarczającej ilości wyników; następnie oblicza K = HMAC(K, V || 0x00) i V = HMAC(K, V). Update: przyjmuje additional_input i ponownie zasila K oraz V za pomocą operacji HMAC. HMAC_DRBG ma przejrzysty dowód bezpieczeństwa oparty na bezpieczeństwie HMAC (założeniu, że HMAC jest funkcją pseudolosową, PRF). Jest to najczęściej zalecany DRBG: HMAC_DRBG jest używany w OpenSSL (od wersji 1.1.1), mbedTLS, wolfSSL i większości stosów TLS. Konstrukcja HMAC zapewnia wbudowane mieszanie między kolejnymi wywołaniami, dzięki czemu przeprowadzenie ataków polegających na odtworzeniu wcześniejszego stanu jest trudniejsze, nawet jeśli stan zostanie częściowo ujawniony.

CTR_DRBG używa szyfru blokowego (AES) w trybie licznikowym. Stan obejmuje klucz K i licznik V. Generate: szyfruje kolejne wartości licznika E(K, V), E(K, V+1), ... i zwiększa V. Update: używa Block_Cipher_df do wyprowadzenia nowych wartości K i V z additional_input. CTR_DRBG jest najszybszym DRBG — sprzętowa akceleracja AES-NI sprawia, że na nowoczesnych procesorach jest o rzędy wielkości szybszy od generatorów DRBG opartych na skrótach. Jest domyślnym DRBG w Windows CNG (CryptGenRandom używa CTR_DRBG z AES-256), w OpenSSL 3.0 (domyślnie) oraz w generatorze losowym jądra Linux (wywołanie systemowe getrandom). Bezpieczeństwo CTR_DRBG zależy od tego, czy AES jest pseudolosową permutacją, co jest dobrze potwierdzone przez dziesięciolecia analiz.

Odporność na przewidywanie to właściwość polegająca na tym, że wynik DRBG pozostaje nieprzewidywalny nawet dla przeciwnika, który wcześniej przejął stan DRBG, o ile podczas ponownego zasilania zostanie zmieszana świeża entropia. DRBG z prediction_resistance_flag=true odwołuje się do źródła entropii przed każdym wywołaniem Generate, aby wprowadzić świeżą entropię. Bez odporności na przewidywanie przejęcie stanu w chwili T pozwala obliczyć wszystkie przyszłe wyniki (bezpieczeństwo w przód zostaje złamane). Bezpieczeństwo wsteczne (nazywane także odpornością na odtwarzanie wsteczne) oznacza, że wcześniejszych wyników nie można przewidzieć nawet przy znajomości bieżącego stanu — HMAC_DRBG i CTR_DRBG osiągają to dzięki etapom aktualizacji, które po każdym Generate wyprowadzają nowy klucz z bieżącego stanu.

SP 800-90A określa algorytmy DRBG, ale nie określa źródła entropii. SP 800-90B definiuje wymagania dotyczące źródeł entropii: sprzętowe źródła szumu muszą zostać scharakteryzowane i zwalidowane, oszacowania entropii muszą być zachowawcze, a testy stanu technicznego muszą wykrywać awarie źródła entropii. SP 800-90C określa sposób łączenia źródeł entropii z generatorami DRBG w kompletne generatory bitów losowych. Typowe źródła entropii to: RDRAND/RDSEED procesora (sprzętowy generator losowy dostępny w procesorach Intel/AMD od 2012 r.), entropia systemu operacyjnego (/dev/urandom w systemie Linux, BCryptGenRandom w systemie Windows), moduły bezpieczeństwa sprzętowego, generator losowy TPM 2.0 oraz szum środowiskowy (czasy operacji dysku, fluktuacje opóźnień sieciowych). Warunki niskiej entropii (maszyny wirtualne, wczesna faza uruchamiania systemu) wymagają specjalnej obsługi, aby uniknąć słabych ziaren.

FIPS 140-3 (obowiązujący standard walidacji modułów kryptograficznych) wymaga stosowania generatorów DRBG zgodnych z NIST SP 800-90A do generowania wszystkich liczb losowych wewnątrz certyfikowanych modułów. Moduł musi: używać zatwierdzonego generatora DRBG (Hash, HMAC lub CTR), inicjalizować ziarno na podstawie zatwierdzonego źródła entropii spełniającego wymagania SP 800-90B, wykonywać testy własne podczas uruchamiania (POST) weryfikujące działanie DRBG, implementować ciągłe testy RNG (CRNGT) wykrywające awarie źródła entropii polegające na zablokowaniu wartości na zero lub jeden oraz obsługiwać ponowne zasilanie, gdy źródło entropii sygnalizuje dostępność entropii. Moduły HSM (Thales Luna, AWS CloudHSM, Utimaco), karty akcelerujące TLS i urządzenia sieciowe do szyfrowania często wymagają modułów zwalidowanych zgodnie z FIPS 140-3, co przyczynia się do upowszechnienia SP 800-90A.

Nowoczesne systemy operacyjne utrzymują DRBG na poziomie jądra, inicjalizowany z użyciem sprzętowych źródeł entropii. Linux używa DRBG opartego na ChaCha20 (od wersji jądra 5.17, zastępującego starszą konstrukcję podobną do Fortuny), zasilanego danymi z RDRAND, przerwań oraz zdarzeń związanych z dyskami i siecią. /dev/urandom zwraca dane wygenerowane przez DRBG i po początkowej inicjalizacji nie blokuje działania. /dev/random blokuje działanie do czasu udostępnienia wystarczającej ilości entropii (jest to zachowanie starszych wersji, w dużej mierze usunięte w nowszych jądrach). Wywołanie systemowe getrandom(2) to nowoczesny interfejs, który blokuje działanie tylko podczas wczesnego uruchamiania systemu, zanim DRBG zostanie zainicjalizowany. Windows używa CTR_DRBG (AES-256) w jądrze RNG, zasilanego danymi z TPM i zdarzeń sprzętowych. Aplikacje powinny korzystać z DRBG systemu operacyjnego za pośrednictwem wysokopoziomowych interfejsów, zamiast inicjalizować własne DRBG na podstawie znaczników czasu lub identyfikatorów PID.

Podatności DRBG występujące w rzeczywistych systemach wynikają z błędów implementacyjnych, a nie ze słabości algorytmu. (1) Niewystarczająca inicjalizacja: użycie wyłącznie bieżącego znacznika czasu lub PID jako ziarna daje atakującym ziarno, które można odgadnąć. (2) Nieuwzględnianie fork: po rozgałęzieniu procesu zarówno proces macierzysty, jak i potomny współdzielą ten sam stan DRBG — generują więc identyczne liczby losowe. Rozwiązanie: ponownie zainicjalizować DRBG po fork (pthread_atfork lub jawne wywołanie getrandom). (3) Ponowne użycie migawki maszyny wirtualnej: po przywróceniu migawki maszyny wirtualnej stan DRBG wraca do stanu z chwili wykonania migawki, co powoduje generowanie wcześniej obserwowanych danych wyjściowych. Rozwiązanie: wstrzyknąć unikatową entropię podczas uruchamiania maszyny wirtualnej (VIRTIO RNG). (4) Ciche ignorowanie nieudanych testów poprawności: DRBG, który po wykryciu awarii źródła entropii nadal generuje dane, dostarcza dane przewidywalne dla atakującego. (5) Ponowne używanie wartości nonce w różnych instancjach DRBG.

Jaką właściwość zapewnia ponowne zainicjalizowanie DRBG z użyciem świeżej entropii?

NIST SP 800-90A definiuje trzy zatwierdzone mechanizmy DRBG: Hash_DRBG (iteracyjne haszowanie, prosta konstrukcja), HMAC_DRBG (oparty na HMAC, z przejrzystym dowodem bezpieczeństwa, szeroko stosowany) oraz CTR_DRBG (tryb licznika AES, najszybszy dzięki AES-NI, domyślny w Windows/OpenSSL). Wszystkie mają cykl życia obejmujący Instantiate/Generate/Reseed oraz limit reseed_interval wynoszący 2^48. Siła zabezpieczeń (112–256 bitów) określa wymagania dotyczące entropii. Odporność na przewidywanie wymaga ponownego zainicjalizowania przed każdym wywołaniem Generate. FIPS 140-3 wymaga stosowania DRBG zgodnych z SP 800-90A oraz źródeł entropii zgodnych z SP 800-90B. Nieuwzględnianie fork, ponowne użycie migawki maszyny wirtualnej i niewystarczająca inicjalizacja to główne praktyczne problemy implementacyjne.