Внутреннее устройство Hash-DRBG, HMAC-DRBG и CTR-DRBG

Каждый из трёх механизмов DRBG поддерживает собственный набор компонентов внутреннего состояния, отражающий лежащий в его основе алгоритмический подход. Hash_DRBG хранит V (начальное значение размером с хеш) и C (константу, производную от V и используемую при генерации вывода). HMAC_DRBG хранит секретный ключ K размером с хеш и значение V размером с хеш, используемое для сцепления. CTR_DRBG хранит ключ K (ключ AES) и V (счётчик длиной в блок). Все три механизма поддерживают reseed_counter, отслеживающий число вызовов генерации с момента последнего заполнения. Размер состояния определяет занимаемый объём памяти: Hash_DRBG и HMAC_DRBG с SHA-256 используют 64 байта состояния, а CTR_DRBG с AES-256 — 48 байт (ключ размером 32 байта и счётчик размером 16 байт).

Hash_DRBG использует Hash_df (функцию выведения на основе хеша) для получения состояния из материала энтропии. Hash_df(input_string, no_of_bits_to_return) выполняет итерации: для counter = 1, 2, ... вычисляет H(counter || no_of_bits || input_string) и объединяет результаты, пока не будет получено достаточно битов. Это позволяет растянуть короткие входные данные энтропии до начального значения нужного размера. При генерации функция вывода вычисляет W = H(0x03 || V), где префикс 0x03 отличает эту операцию от других применений хеша. Цикл вывода: data = H(0x01 || V); V = V + 1; затем он повторяется для получения дополнительных данных. После генерации V обновляется: V = V + H(0x03 || V) + C + reseed_counter. Разделение доменов с помощью байтовых префиксов (0x01, 0x03) не позволяет спутать вывод фазы генерации с фазой обновления состояния.

Функция Update в HMAC_DRBG — основа всех переходов состояния. Update(provided_data, K, V): K = HMAC(K, V || 0x00 || provided_data); V = HMAC(K, V). Если provided_data не пусто: K = HMAC(K, V || 0x01 || provided_data); V = HMAC(K, V). Такое двухэтапное обновление гарантирует, что и новый ключ, и новое значение зависят от предыдущего состояния и любых новых данных энтропии. При генерации цикл выполняет V = HMAC(K, V) и добавляет результаты к выводу, пока не будет получено достаточно битов; затем вызывается Update с additional_input для продвижения состояния. Безопасность HMAC_DRBG сводится к предположению, что HMAC является безопасной PRF: противник, не способный отличить вывод HMAC от случайного, не сможет отличить вывод DRBG от случайного.

CTR_DRBG использует Block_Cipher_df (функцию выведения) для преобразования начального материала в формат ключа и счётчика. Block_Cipher_df(input_string, no_of_bits) использует конструкцию BCC (сцепление блочных шифров): итеративно применяет AES-CBC к фрагментам входных данных, чтобы получить результат нужной длины. Функция выведения необходима для обработки входных данных энтропии переменной длины и обеспечения разделения доменов. CTR_DRBG без функции выведения (разрешённый вариант для проверок FIPS при точно заданном формате входных данных) работает быстрее, но сильнее зависит от требований к формату входных данных. Цикл генерации: temp = E(K, V); V = V + 1; результат temp добавляется к выводу. Обновление: K || V = Block_Cipher_df(V || additional_input, seedlen); затем применяется XOR с текущим ключом.

Производительность существенно различается у разных типов DRBG. На современном CPU x86_64 с AES-NI CTR_DRBG (AES-256) обеспечивает примерно 5–10 GB/s псевдослучайного вывода — инструкция AES-NI делает вычисления AES почти бесплатными. HMAC_DRBG (SHA-256) обеспечивает примерно 200–400 MB/s — SHA-256 работает быстро, но не имеет аппаратного ускорения той же степени. Hash_DRBG (SHA-256) обеспечивает примерно 100–300 MB/s. Для массовой генерации ключей или замены потокового шифра CTR_DRBG значительно быстрее. Для задач с небольшим объёмом данных (создание ключей сеансов, выведение одноразовых значений) разница в производительности несущественна. По этой причине OpenSSL 3.0 использует CTR_DRBG (AES-256) по умолчанию.

При создании экземпляра все три DRBG принимают необязательную строку персонализации personalization_string, которая смешивается с входными данными энтропии, чтобы сделать экземпляр DRBG уникальным. Благодаря этому два одновременно созданных экземпляра DRBG с одинаковой энтропией не выдадут одинаковый результат — их потоки разойдутся на основе строки персонализации. Рекомендуемые компоненты строки персонализации: идентификатор приложения + идентификатор процесса + идентификатор потока + метка времени + аппаратный идентификатор. Даже если две VM получают одинаковую энтропию (проблема со снимками облачных VM), разные строки персонализации обеспечивают разные потоки DRBG. NIST SP 800-90C рекомендует всегда использовать строку персонализации. Параметр nonce выполняет аналогичную задачу: это уникальное короткое значение, гарантирующее, что никакие два экземпляра не начнут работу в одном и том же состоянии.

Все три DRBG поддерживают параметр additional_input в вызовах генерации. Он позволяет вызывающей стороне добавить дополнительный контекст или энтропию в один вызов генерации без полного повторного заполнения. Варианты использования: (1) добавление энтропии для каждого запроса из вторичного источника энтропии; (2) передача контекста уровня приложения (идентификатор запроса, метка времени), чтобы связать создаваемые значения с их назначением; (3) необязательное обеспечение сопротивления предсказанию за счёт добавления свежей энтропии из операционной системы. additional_input смешивается с состоянием DRBG перед генерацией вывода. Если additional_input содержит настоящую энтропию, он повышает безопасность без необходимости формального повторного заполнения, которое задействует интерфейс источника энтропии и связанные с ним накладные расходы.

После завершения работы экземпляра DRBG (или при переходе к новому экземпляру) внутреннее состояние необходимо надёжно обнулить. Состояния V и C (Hash_DRBG), K и V (HMAC_DRBG и CTR_DRBG), а также все промежуточные рабочие переменные должны быть перезаписаны нулями. Это называется явным обнулением и является обязательным требованием для модулей FIPS 140-3. В коде на C используйте explicit_bzero() или SecureZeroMemory() — оптимизируемый компилятором вызов memset может быть удалён как мёрдая запись, из-за чего материал ключей останется в памяти. Крейты Rust zeroize и аналогичные решения для конкретных языков обеспечивают переносимую обработку этой задачи. Безопасное уничтожение ключей важно в ситуациях, когда дампы памяти, атаки холодной загрузки или инструменты анализа процессов могут раскрыть остаточное состояние.

NIST предоставляет эталонные векторы проверок для всех DRBG из SP 800-90A. Виды проверок: (1) проверки на известный ответ (KAT) — при заданных входных данных энтропии, nonce и строке персонализации проверяется, что сгенерированный вывод совпадает с предварительно вычисленными значениями; (2) проверки повторного заполнения — проверяется состояние DRBG после операции повторного заполнения; (3) проверки PR (сопротивления предсказанию) — проверяется, что запрос prediction_resistance=true даёт правильный вывод после добавления свежей энтропии. Проверка CAVP обязательна для представления модуля на сертификацию FIPS 140-3. Библиотеки с открытым исходным кодом (OpenSSL, mbedTLS) включают эталонные векторы CAVP в свои наборы регрессионных проверок, чтобы выявлять ошибки в реализациях DRBG.

Реализации DRBG сталкиваются с тонкими рисками побочных каналов, выходящими за рамки алгоритмической модели безопасности. Атаки по времени доступа к кэшу на AES (в CTR_DRBG без AES-NI) могут раскрыть материал ключей раундов; AES-NI устраняет эту проблему, выполняя вычисления в регистрах без обращений к таблицам. HMAC_DRBG использует HMAC внутри, а он работает за постоянное время, если лежащая в его основе реализация SHA-256 также работает за постоянное время; SHA-256 обычно считают работающим за постоянное время, поскольку в нём нет ветвлений, зависящих от данных. Физические побочные каналы (анализ энергопотребления, излучение EM) для аппаратуры, генерирующей данные DRBG, представляют опасность для смарт-карт и устройств Интернета вещей; противодействуют им реализации с маскированием. Атака с копированием состояния: если противник может прочитать состояние DRBG через уязвимость, раскрывающую память (подобную Heartbleed), весь будущий вывод скомпрометирован до следующего повторного заполнения свежей энтропией.

Если состояние DRBG скомпрометировано (например, из-за уязвимости, раскрывающей содержимое памяти), для восстановления необходимо: (1) обнаружить компрометацию — утечки состояния DRBG не очевидны сами по себе, поэтому требуются внешний мониторинг или проверки целостности; (2) выполнить повторное заполнение свежей энтропией из доверенного источника, не затронутого компрометацией; (3) сменить все криптографические материалы, производные от скомпрометированного DRBG (ключи сеансов и ключи подписи, созданные после последнего успешного повторного заполнения); (4) в программных реализациях перезапустить процесс, чтобы создать чистый экземпляр DRBG. SP 800-90C рекомендует цепочки источников энтропии: если один источник скомпрометирован, комбинация сохраняет безопасность, когда другой источник предоставляет настоящую энтропию.

Hash_DRBG использует итеративное хеширование с Hash_df для выведения и формирует вывод в циклах H(0x01 || V). HMAC_DRBG использует HMAC как PRF с двухэтапной функцией Update (сначала ключ, затем значение), что обеспечивает строгое сведение безопасности. CTR_DRBG использует AES в режиме счётчика с Block_Cipher_df и достигает скорости 5–10 GB/s на оборудовании с AES-NI. Все механизмы принимают personalization_string при создании экземпляра для его уникальности и additional_input при каждой генерации для связывания с контекстом. Эталонные векторы CAVP проверяют реализации. После использования состояние необходимо надёжно обнулить. Компрометация состояния требует повторного заполнения свежей энтропией и смены ключей производных материалов.