NIST SP 800-90A: стандарты DRBG

Криптографическим операциям нужны высококачественные случайные числа: для генерации ключей, одноразовых значений, векторов инициализации, солей и токенов сеанса. Генераторы истинных случайных чисел (TRNG) получают энтропию из физических источников (аппаратный шум, прерывания, тепловой шум), но работают медленно и доступны не всегда — особенно в виртуальных машинах или на раннем этапе загрузки. Детерминированные генераторы случайных битов (DRBG) решают эту проблему: DRBG инициализируется небольшим количеством истинной энтропии, а затем криптографический алгоритм растягивает ее в большой поток псевдослучайных битов, вычислительно неотличимый от истинно случайного. NIST SP 800-90A определяет три одобренных механизма DRBG, используемых практически во всех современных криптографических реализациях.

DRBG работает посредством трех основных операций. Instantiate: инициализирует внутреннее состояние DRBG с использованием entropy_input (из источника энтропии), nonce (одноразовое значение, обеспечивающее уникальность) и, возможно, personalization_string (контекст, специфичный для приложения). Generate: выдает запрошенное число псевдослучайных битов и обновляет внутреннее состояние, чтобы предотвратить восстановление предыдущего состояния. Reseed: добавляет свежую энтропию в состояние DRBG для обеспечения устойчивости к предсказанию — после повторной инициализации даже злоумышленник, знавший предыдущее состояние, не может предсказать будущие выходные данные. NIST задает максимальные интервалы генерации (reseed_interval): 2^48 запросов до обязательной повторной инициализации для всех трех типов DRBG.

NIST SP 800-90A определяет четыре уровня криптографической стойкости: 112, 128, 192 и 256 бит. Уровень стойкости определяет минимальную энтропию, необходимую при инициализации, и качество генерируемых выходных данных. Для стойкости 128 бит входные данные должны содержать не менее 128 бит энтропии. Связь такова: security_strength бит энтропии -> выход DRBG, вычислительно неотличимый от случайного для злоумышленника, выполняющего 2^security_strength операций. Выбор длины ключа (AES-128 или AES-256) и хеша (SHA-256 или SHA-512) должен соответствовать желаемому уровню стойкости или превосходить его. Избыточный выбор параметров (SHA-512 для стойкости 128 бит) безопасен, но неэффективен; недостаточный выбор параметров нарушает безопасность.

Hash_DRBG хранит два значения состояния: V (значение, порождающее выходные данные) и C (константа, добавляемая при генерации). Generate: hash_gen вырабатывает биты, последовательно вычисляя H(0x01 || V), H(0x01 || V+1), ... пока не будет получено достаточно выходных данных; затем V обновляется по формуле V = V + H(0x03 || V) + C + reseed_counter. Reseed: использует Hash_df (функция выработки ключа на основе хеша), объединяя текущее V со свежей энтропией для получения новых V и C. Hash_DRBG просто реализовать, и его легко анализировать с точки зрения безопасности, поэтому он подходит для сред с ограниченными ресурсами. NIST рекомендует инициализацию с SHA-256 или SHA-512. Hash_DRBG используется в SHA1PRNG (устаревшем) в Java и в устаревшем DRBG OpenSSL.

HMAC_DRBG хранит состояние (ключ K, значение V). Generate: последовательно вычисляет V = HMAC(K, V), пока не будет получено достаточно выходных данных; затем K = HMAC(K, V || 0x00) и V = HMAC(K, V). Update: получает additional_input и обновляет K и V с помощью операций HMAC. HMAC_DRBG имеет ясное доказательство безопасности, основанное на безопасности HMAC (предположение о PRF для HMAC). Это наиболее широко рекомендуемый DRBG: OpenSSL (начиная с 1.1.1), mbedTLS, wolfSSL и большинство стеков TLS используют HMAC_DRBG. Конструкция HMAC обеспечивает встроенное перемешивание между последовательными вызовами, затрудняя атаки на восстановление предыдущего состояния, даже если состояние раскрыто частично.

CTR_DRBG использует блочный шифр (AES) в режиме счетчика. Состояние: ключ K и счетчик V. Generate: шифрует последовательные значения счетчика E(K, V), E(K, V+1), ... и увеличивает V. Update: использует Block_Cipher_df для получения новых K и V из additional_input. CTR_DRBG — самый быстрый DRBG: аппаратное ускорение AES-NI делает его на порядки быстрее DRBG на основе хешей на современных процессорах. Это DRBG по умолчанию в Windows CNG (CryptGenRandom использует CTR_DRBG с AES-256), OpenSSL 3.0 (по умолчанию) и генераторе случайных чисел ядра Linux (системный вызов getrandom). Безопасность CTR_DRBG зависит от того, что AES является псевдослучайной перестановкой; это подтверждено десятилетиями анализа.

Устойчивость к предсказанию — это свойство, при котором выходные данные DRBG остаются непредсказуемыми даже для злоумышленника, ранее скомпрометировавшего состояние DRBG, при условии, что при повторной инициализации добавляется свежая энтропия. DRBG с параметром prediction_resistance_flag=true обращается к источнику энтропии перед каждым вызовом Generate, чтобы добавить свежую энтропию. Без устойчивости к предсказанию компрометация состояния в момент T позволяет вычислить все будущие выходные данные (прямая секретность нарушается). Обратная безопасность (также называемая устойчивостью к восстановлению предыдущего состояния) означает, что прошлые выходные данные остаются непредсказуемыми даже при известном текущем состоянии. HMAC_DRBG и CTR_DRBG обеспечивают это благодаря операциям обновления, которые после каждого Generate выводят новый ключ из текущего состояния.

SP 800-90A определяет алгоритмы DRBG, но не источник энтропии. SP 800-90B устанавливает требования к источникам энтропии: аппаратные источники шума должны быть исследованы и проверены, оценки энтропии должны быть консервативными, а проверки работоспособности должны обнаруживать сбои источника энтропии. SP 800-90C определяет способы объединения источников энтропии с DRBG в полноценные генераторы случайных битов. Типичные источники энтропии: CPU RDRAND/RDSEED (аппаратный генератор случайных чисел, доступный в процессорах Intel/AMD с 2012 года), энтропия OS (/dev/urandom в Linux, BCryptGenRandom в Windows), аппаратные модули безопасности, генератор случайных чисел TPM 2.0 и шум окружающей среды (время операций с диском, сетевая нестабильность). Условия низкой энтропии (виртуальные машины, ранний этап загрузки) требуют специальной обработки, чтобы избежать слабых начальных значений.

FIPS 140-3 (действующий стандарт проверки криптографических модулей) требует использования DRBG по NIST SP 800-90A для всей генерации случайных чисел внутри сертифицированных модулей. Модуль должен: использовать одобренный DRBG (Hash, HMAC или CTR), инициализировать его из одобренного источника энтропии, соответствующего требованиям SP 800-90B, выполнять самотестирование при включении питания (POST), проверяющее работу DRBG, реализовывать непрерывные проверки RNG (CRNGT), обнаруживающие сбои энтропии типа «залипание на нуле» или «залипание на единице», и поддерживать повторную инициализацию, когда источник энтропии сообщает о наличии доступной энтропии. HSM (Thales Luna, AWS CloudHSM, Utimaco), карты ускорения TLS и сетевые устройства шифрования обычно требуют модулей, прошедших проверку по FIPS 140-3, что способствует распространению SP 800-90A.

Современные операционные системы поддерживают DRBG на уровне ядра, инициализированный источниками аппаратной энтропии. В Linux используется DRBG на основе ChaCha20 (начиная с версии ядра 5.17 он заменил более старую конструкцию, подобную Fortuna), инициализируемый с помощью RDRAND, прерываний и событий диска и сети. /dev/urandom возвращает выход DRBG и после первоначальной инициализации работает без блокировки. /dev/random блокирует выполнение, пока не станет доступно достаточно энтропии (устаревшее поведение, в новых ядрах в основном устранённое). Системный вызов getrandom(2) — современный интерфейс; он блокируется только на раннем этапе загрузки, пока DRBG не инициализирован. В Windows в RNG ядра используется CTR_DRBG (AES-256), инициализируемый из TPM и аппаратных событий. Приложениям следует использовать DRBG операционной системы через высокоуровневые интерфейсы, а не инициализировать собственные DRBG метками времени или PID.

В реальных системах уязвимости DRBG возникают из-за ошибок реализации, а не слабости алгоритма. (1) Недостаточная инициализация: инициализация только текущей меткой времени или PID даёт атакующим начальное значение, которое легко угадать. (2) Неучёт fork: при создании копии процесса оба процесса — родительский и дочерний — используют одно и то же состояние DRBG и генерируют одинаковые случайные числа. Исправление: выполнить повторную инициализацию после fork (с помощью pthread_atfork или явного вызова getrandom). (3) Повторное использование снимка VM: при восстановлении снимка VM состояние DRBG возвращается к состоянию на момент создания снимка, и генератор выдаёт уже виденный результат. Исправление: внедрять уникальную энтропию при запуске VM (VIRTIO RNG). (4) Молчаливое игнорирование сбоев проверок работоспособности: DRBG, который продолжает генерировать данные после обнаружения сбоя источника энтропии, выдаёт результат, предсказуемый для атакующего. (5) Повторное использование одноразовых значений в разных экземплярах DRBG.

Какое свойство обеспечивает повторное заполнение DRBG свежей энтропией?

NIST SP 800-90A определяет три одобренных механизма DRBG: Hash_DRBG (итеративное хеширование, простая конструкция), HMAC_DRBG (на основе HMAC, со строгим доказательством безопасности, широко применяемый) и CTR_DRBG (режим счётчика AES, самый быстрый благодаря AES-NI, используемый по умолчанию в Windows и OpenSSL). Все они используют жизненный цикл создания экземпляра, генерации и повторного заполнения с ограничением интервала повторного заполнения, равным 2^48. Стойкость (112–256 бит) определяет требования к энтропии. Сопротивление предсказанию требует повторного заполнения перед каждой генерацией. FIPS 140-3 требует применения DRBG из SP 800-90A с источниками энтропии из SP 800-90B. Неучёт ветвления процессов, повторное использование снимков VM и недостаточная инициализация — основные практические ошибки реализации.