Кратко

  • Без подписанных атрибутов чистый ML-DSA подписывает октеты содержимого напрямую. В digestAlgorithm следует указать SHA-512 для совместимости, но проверяющий обязан игнорировать это значение.
  • При наличии подписанных атрибутов дайджест содержимого входит в защищённые данные, должен быть пересчитан и сопоставлен и может ограничивать стойкость всей конструкции.
  • Воспроизводимое доказательство отдельно фиксирует ветвь CMS, точные байты, OID набора параметров, сравнение дайджеста, защиту алгоритмов, границы ключа и внешнего μ, полномочия и последующее действие.

В отчёте могут одновременно стоять три зелёные отметки: SHA-512, ML-DSA-65 и «подпись действительна». Все три записи способны быть верными. Но они не доказывают, что SHA-512 хешировал содержимое для ML-DSA, что закрытый ключ оставался в HSM или что указанному владельцу сертификата разрешалось санкционировать дальнейшее действие.

RFC 9882 опубликован в октябре 2025 года как предлагаемый стандарт IETF. Он определяет применение наборов ML-DSA-44, ML-DSA-65 и ML-DSA-87 из FIPS 204 в Cryptographic Message Syntax. Каждому набору соответствует собственный OID алгоритма подписи, а параметры в AlgorithmIdentifier должны отсутствовать. Документ описывает чистый ML-DSA и не задаёт использование HashML-DSA в CMS. Прежнее название Dilithium не означает совместимости форматов.

Смысл проверки зависит прежде всего от наличия signedAttrs.

Если подписанных атрибутов нет, на вход ML-DSA передаются октеты значения OCTET STRING в encapContentInfo eContent, без октетов тега и длины. Чистый ML-DSA работает непосредственно с сообщением. Поэтому SignerInfo.digestAlgorithm на этой ветви не имеет значения для вычисления подписи.

Тем не менее подписант должен поставить в поле SHA-512, чтобы снизить риск несовместимости реализаций. Получатель одновременно обязан игнорировать его содержимое. Здесь SHA-512 подтверждает соблюдение соглашения о совместимости, а не выполнение внешнего хеширования. Система может верно извлечь значение, после чего аналитик ошибочно припишет ему причинную роль.

При наличии подписанных атрибутов меняется сам объект подписи. На вход идёт полная DER-кодировка значения SignedAttrs вместе с тегом и длиной; используется тег EXPLICIT SET OF, а не IMPLICIT [0] из окончательного сообщения. Как минимум нужны атрибуты типа содержимого и дайджеста сообщения. Последний содержит хеш исходного содержимого, который получатель должен заново вычислить и сопоставить. На этой ветви выбор дайджеста действительно важен, а слабый вариант способен ограничить стойкость всей схемы. Поддержка SHA-512 обязательна, SHAKE256 рекомендована; параметры SHAKE256 также должны отсутствовать.

Небольшая разница в синтаксисе создаёт две разные доказательные ситуации. Если в журнале не указана ветвь, он не объясняет, что значил digestAlgorithm, какие байты проверялись ML-DSA и выполнялось ли сравнение содержимого. Слова «подпись действительна» сохраняют математический итог, но теряют основания решения.

Идентификатор алгоритма проверяется отдельно. OID должен соответствовать выбранному набору параметров ML-DSA, а недопустимые параметры требуют отказа. Определённый RFC 6211 атрибут CMSAlgorithmProtection помещает относящиеся к операции идентификаторы алгоритмов в подписанные данные. RFC 9882 рекомендует его для защиты от подмены алгоритма. Наличие и согласованность атрибута нельзя выводить из успешной проверки подписи.

Хранение закрытого ключа остаётся ещё одним слоем. Компрометация ключа ML-DSA позволяет создавать подделки. FIPS 204 по умолчанию предусматривает усиленное формирование подписи, совмещающее новую случайность с заранее подготовленными случайными данными ключа, и допускает детерминированный режим. RFC 9882 не рекомендует последний там, где существенны атаки по побочным каналам или внесению сбоев. Сам объект CMS не раскрывает применённую политику.

Аппаратный модуль не устраняет границу доказательств. При подписанных атрибутах в HSM можно передать компактную DER-структуру вместо полного содержимого. Представитель сообщения μ также может быть рассчитан другим криптографическим модулем и передан подписывающему устройству. Фраза «подпись создана в HSM» поэтому не подтверждает, что модуль видел оригинал или сам вычислял μ. Нужны сведения об интерфейсе и привязке к сохранённым байтам.

Защищаемая запись начинается с точного CMS-объекта. Затем фиксируются наличие атрибутов, реконструированные байты, OID и отсутствие параметров. На нужной ветви пересчитывается и сравнивается дайджест; далее проверяются защита алгоритмов и подпись. После этого отдельными выводами оцениваются режим случайности, источник μ, цепочка сертификатов, личность, прикладные полномочия и фактическое последствие.

Источники