True Random Number Generator, або TRNG, отримує нові непередбачувані вхідні дані через вимірювання фізичного процесу. Цим він відрізняється від генератора, який лише обчислює наступні значення зі збереженого стану. На практиці вони можуть працювати разом. Але слово «true» не гарантує якості: фізичне джерело теж може бути погано спроєктованим або несправним.
Схема може вимірювати невеликі електричні коливання й перетворювати їх на числа. Важливо, яку частину результату нападник не зможе передбачити. Швидко створити багато даних недостатньо. Тому NIST SP 800-90B оцінює конкретне джерело шуму, його вибірку, можливу обробку та перевірки працездатності. Назва фізичного явища не замінює такої оцінки. [1]
Джерело може давати нулі частіше за одиниці. Обробка під назвою conditioning допомагає зменшити цю нерівномірність і зосередити наявну ентропію, тобто невизначеність з погляду нападника, у коротшому результаті. Вона не створює відсутньої невизначеності. Тому NIST SP 800-90B пов’язує зараховану вихідну ентропію із входом і методом. Навіть хеш, обчислений відбиток даних, не доводить непередбачуваності: знаючи вхід, можна знову обчислити той самий відбиток. [1]
Якщо джерело постійно повертає одне значення, пристрій не повинен цього пропустити. NIST SP 800-90B застосовує Repetition Count Test для повторень і Adaptive Proportion Test для незвичних частот. Ці перевірки шукають певні несправності, а не автоматично виявляють кожну атаку чи помилку. Після виявлення стійкої несправності джерело не має продовжувати видавати дані як під час нормальної роботи. [1]
Сама наявність TRNG не доводить безпеки гаманця. Важливо також, як конкретна версія використовує дані та реагує на помилки. Тому NIST SP 800-90C розглядає джерела разом із подальшими генераторами. Оцінка однієї деталі не є оцінкою всього гаманця. Навіть чудове джерело випадковості не захистить резервну копію, яку ви згодом розкриєте. [4]
Довгий запис із працюючого пристрою показує інші аспекти його поведінки, ніж повторні вимкнення й запуски. Тому NIST SP 800-90B включає також тести перезапуску. Оцінка має відповідати конкретному джерелу та умовам роботи. Результат однієї вибірки не можна автоматично поширити на всі пристрої чи середовища. Зміна прошивки, тобто програми всередині пристрою, також може вимагати нової оцінки. [1]
У технічній документації трапляються команди RDRAND і RDSEED. Intel описує їх у посібнику для DRNG, апаратного генератора випадкових чисел. RDRAND надає результати детермінованого генератора, який обчислює наступні значення з внутрішнього стану. RDSEED постачає оброблену ентропію для ініціалізації, тобто створення початкового стану генератора. Обидва шляхи можуть починатися з фізичного джерела, але це не означає прямого читання необробленого шуму. [2]
Процесор не обов’язково має готовий результат для кожного запиту. Тому Intel вимагає перевіряти прапорець стану CF для RDRAND і RDSEED: 1 означає доступний результат, 0 — його відсутність. Недостатньо шукати числовий нуль у цільовому регістрі, невеликому сховищі процесора. Програма має прочитати прапорець успіху. Підтримка команди процесором ще не означає, що конкретний запит виконався успішно. [2]
У Linux інтерфейс hw_random дозволяє читати апаратне джерело через /dev/hwrng подібно до файла. Документація прямо попереджає, що цей інтерфейс сам не перевіряє якість даних. Несправне або змінене обладнання може повертати хибні дані, які застосунок усе ж прочитає. Успішне читання не доводить достатньої ентропії. Потрібно оцінювати і джерело, і те, як програма використовує його результати. [3]
Для повної картини прочитайте також Cryptographic Entropy, Random Number Generator, CSPRNG, Entropy Mixing. На цю статтю також посилаються Entropy Mixing.