True Random Number Generator, czyli TRNG, uzyskuje nowe, nieprzewidywalne dane przez pomiar procesu fizycznego. Różni się tym od generatora, który tylko oblicza kolejne wartości z zapisanego stanu. W praktyce oba mogą współpracować. Słowo „true” nie gwarantuje jednak jakości: źródło fizyczne też może być źle zaprojektowane lub uszkodzone.
Obwód może mierzyć drobne wahania elektryczne i zamieniać je w liczby. Ważne jest, jakiej części wyniku atakujący nie potrafi przewidzieć. Szybkie wytworzenie dużej ilości danych nie wystarczy. NIST SP 800-90B ocenia więc konkretne źródło szumu, próbkowanie, ewentualne przetwarzanie i kontrole działania. Sama nazwa zjawiska fizycznego nie zastępuje tej oceny. [1]
Źródło może dawać zera częściej niż jedynki. Przetwarzanie zwane conditioning pomaga zmniejszyć tę nierównomierność i skupić dostępną entropię, czyli niepewność z perspektywy atakującego, w krótszym wyniku. Nie tworzy brakującej niepewności. Dlatego NIST SP 800-90B wiąże uznaną entropię wyjściową z wejściem i metodą. Nawet hash, obliczony odcisk danych, nie dowodzi nieprzewidywalności: znając wejście, można ponownie obliczyć ten sam odcisk. [1]
Jeśli źródło stale zwraca tę samą wartość, urządzenie nie może tego przeoczyć. NIST SP 800-90B wykorzystuje Repetition Count Test do sprawdzania powtórzeń i Adaptive Proportion Test do nietypowych częstości. Te kontrole szukają określonych usterek; nie wykrywają automatycznie każdego ataku lub błędu. Po wykryciu trwałej awarii źródło nie powinno dalej dostarczać danych jak podczas zwykłej pracy. [1]
Sama obecność TRNG nie dowodzi bezpieczeństwa portfela. Liczy się też sposób wykorzystania danych i obsługi błędów w konkretnej wersji. NIST SP 800-90C rozpatruje więc źródła razem z dalszymi generatorami. Ocena jednego podzespołu nie jest oceną całego portfela. Nawet świetne źródło losowości nie ochroni kopii zapasowej, którą później ujawnisz. [4]
Długi zapis z działającego urządzenia pokazuje inne aspekty jego zachowania niż wielokrotne wyłączanie i uruchamianie. Dlatego NIST SP 800-90B obejmuje również testy restartu. Ocena musi odpowiadać konkretnemu źródłu i warunkom pracy. Wynik jednej próbki nie dotyczy automatycznie wszystkich urządzeń czy środowisk. Zmiana firmware, czyli programu wewnątrz urządzenia, także może wymagać ponownej oceny. [1]
W dokumentacji technicznej występują instrukcje RDRAND i RDSEED. Intel opisuje je w przewodniku po DRNG, sprzętowym generatorze liczb losowych. RDRAND dostarcza wyniki generatora deterministycznego, który oblicza kolejne wartości ze stanu wewnętrznego. RDSEED dostarcza przetworzoną entropię do inicjalizacji, czyli utworzenia stanu początkowego generatora. Obie drogi mogą zaczynać się od źródła fizycznego, lecz nie oznacza to bezpośredniego odczytu surowego szumu. [2]
Procesor nie zawsze ma gotowy wynik dla każdego żądania. Intel wymaga więc sprawdzenia flagi stanu CF przy RDRAND i RDSEED: 1 oznacza dostępny wynik, a 0 jego brak. Nie wystarczy szukać liczbowego zera w rejestrze docelowym, niewielkim miejscu przechowywania danych w procesorze. Program musi odczytać flagę powodzenia. Obsługa instrukcji przez procesor nie oznacza, że konkretne żądanie zakończyło się sukcesem. [2]
W Linuksie interfejs hw_random pozwala czytać źródło sprzętowe przez /dev/hwrng podobnie jak plik. Dokumentacja wyraźnie ostrzega jednak, że ten interfejs sam nie wykonuje testów jakości danych. Uszkodzony lub zmodyfikowany sprzęt może więc zwracać błędne dane, które aplikacja mimo to odczyta. Udany odczyt nie dowodzi dostatecznej entropii. Trzeba ocenić zarówno źródło, jak i sposób wykorzystania wyników przez program. [3]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Cryptographic Entropy, Random Number Generator, CSPRNG, Entropy Mixing. Do tego hasła prowadzą również odsyłacze z Entropy Mixing.