Кратко

  • RFC 9708 задаёт представление ключей и подписей HSS/LMS в X.509, PKIX и CMS. Закрытый ключ LM-OTS предназначен для одной подписи, поэтому подписывающая система обязана надёжно помнить все израсходованные листья.
  • Проверка отдельной подписи не доказывает единство истории. Неудачная постоянная запись, откат виртуальной машины к снимку или клонирование могут снова выдать лист, с которого подпись уже ушла наружу.
  • Безопасность определяет порядок: зарезервировать и необратимо сохранить следующее состояние до выдачи подписи, оставить одного действующего писателя и сопоставить каждый результат с уникальным расходом.

После аварии оператор запускает проверенный снимок. Сервис отвечает, сертификат прежний, новые подписи успешно проходят проверку. Но восстановленная машина не знает о результатах, которые были выданы после создания снимка. Для инфраструктуры это возврат к рабочему состоянию; для одноразового ключа — возвращение уже потраченного прошлого.

Эту границу описывает RFC 9708. Документ Standards Track, опубликованный в январе 2025 года, обновляет применение Hierarchical Signature System и Leighton–Micali Signature scheme в сертификатах и Cryptographic Message Syntax. Он заменяет RFC 8708, уточняет кодирование, устраняет зарегистрированные ошибки и добавляет наборы параметров. Формат становится точнее, но HSS/LMS остаётся системой с состоянием.

Базовое правило находится в RFC 8554. Состояние закрытого ключа содержит индекс следующей одноразовой подписи. Операция подписи выдаёт не только подпись, но и следующее состояние закрытого ключа. Число листьев фиксировано; после исчерпания следующего состояния нет. Повторное использование одного секретного состояния лишает схему криптографических гарантий и может сделать подделку осуществимой.

Следовательно, охраняемый актив — не просто секретные данные. Это секрет вместе с достоверной и необратимой историей их расходования.

Проверка видит документ, уникальность охватывает все экземпляры

LM-OTS выделяет один закрытый ключ на одну подпись. LMS объединяет множество таких ключей под корнем Merkle, а HSS позволяет строить иерархию деревьев. Так возникает практичный, но конечный запас операций. В подписи указан лист и путь аутентификации, по которым проверяющий устанавливает математическую связь с открытым ключом.

Из одной подписи нельзя узнать, использовал ли другой экземпляр тот же лист. Проверка — локальное наблюдение над предъявленным объектом. Уникальность состояния — глобальное утверждение обо всех копиях, резервных образах, писателях и путях переключения. Поэтому нужны разные квитанции:

Квитанция Узкий вывод
открытый ключ принят политика допускает этот ключ HSS/LMS
идентификатор распознан кодирование и параметры понятны
подпись проверена объект удовлетворяет процедуре проверки
индекс листа виден подпись называет конкретную позицию
состояние зарезервировано писатель назначил эту позицию
следующее состояние сохранено энергонезависимая память не предложит её вновь
подпись выдана результат пересёк границу безопасности
история сверена другой результат не занимает ту же позицию
эффект наблюдался потребитель действовал по подписанным данным

Третья строка не заменяет восьмую. RFC 9708 требует отслеживать использованные листья и предупреждает: потеря целостности учёта может привести к повторному использованию одноразового ключа. Среди причин прямо названы сбой постоянной записи, создание снимка виртуальной машины и клонирование. Обычные операции инфраструктуры способны нарушить строгую криптографическую хронологию.

Сначала зафиксировать расход, затем отдать подпись

Представим сервис, который вычисляет подпись, возвращает её клиенту и лишь потом сохраняет увеличенный индекс. Сбой между ответом и записью оставляет подпись у клиента, но возвращает лист в доступный набор после перезапуска. Даже успешный системный вызов записи недостаточен, если данные остались в энергозависимом кэше.

NIST SP 800-208 называет управление состоянием центральной трудностью хеш-подписей с состоянием. В её профиле соответствующий модуль обязан увеличить идентификатор листа и сохранить изменение в энергонезависимой памяти до экспорта подписи или принятия следующего запроса. Безопасная последовательность такова: резервирование позиции, постоянная отметка о расходе, завершение подписи, выдача вместе с квитанцией и разбор неопределённого исхода без возврата позиции в свободный набор.

Сбой после сохранения, но до экспорта может напрасно сжечь лист. Теряется ёмкость, но сохраняется одноразовость. Обратный порядок экономит лист ценой риска повторения. Если судьба запроса неясна, пропуск в последовательности безопаснее двух публичных подписей на одном одноразовом секрете.

Из-за этого привычные термины меняют смысл. Повтор запроса не обязательно идемпотентен. Восстановление резервной копии не обязательно восстанавливает безопасность. Клонирование образа не обязательно означает горизонтальное масштабирование. Состояние активного ключа может идти только вперёд.

Высокая доступность способна удвоить полномочия

Два активных экземпляра с одним закрытым состоянием могут создавать отдельно проверяемые подписи и при этом назначать пересекающиеся листья. Общая база не спасает, если любой узел выпускает результат до устойчивого commit. Аппаратные модули также не спасают, если одинаковое состояние скопировано в несколько устройств без непересекающихся поддеревьев.

Можно сериализовать расход в одном авторитетном модуле, распределить независимые поддеревья, применить монотонный аппаратный счётчик или оградить прежнего писателя до включения нового. Но доказательство должно соответствовать свойству. «В аппаратуре» не означает «в единственном экземпляре», а «высокая доступность» не означает «один писатель».

Профиль NIST строже общего формата IETF: он ограничивает одобренные параметры, требует генерации ключей и подписей внутри аппаратных криптографических модулей и запрещает экспорт секретного ключа. Это требования к системам, заявляющим соответствие профилю, а не автоматические свойства любой реализации RFC 9708. Публикация стандарта доказывает существование правил, но не поведение конкретной системы при конкретном восстановлении.

Сертификат переносит открытый ключ, но не память подписанта

RFC 9708 задаёт объектный идентификатор, требует отсутствия параметров в AlgorithmIdentifier и переносит открытый ключ HSS/LMS без дополнительной оболочки ASN.1. В X.509 keyUsage должен соответствовать подписи, а не шифрованию или согласованию ключа. Представление согласовано с инфраструктурой RFC 5280 и модулями ASN.1 из RFC 5912.

В CMS из RFC 5652 подписываемые байты зависят от наличия signed attributes. Без них подписывается само содержимое. При их наличии содержимое хешируется, а подпись покрывает DER-кодирование SignedAttributes, включающее тип содержимого и дайджест сообщения. Поэтому контейнеры, в том числе доставка прошивок из RFC 4108, могут использовать HSS/LMS в знакомой структуре.

Эти нормы отвечают на вопрос о формате и проверяемых байтах. Сертификат связывает открытый ключ с субъектом по политике издателя, но не перечисляет старые снимки закрытого состояния. Проверяющий CMS видит защищённые атрибуты, но не потерянную дисковую запись внутри подписанта. Чем шире круг потребителей, тем важнее внутренние квитанции, которых нет в публичном объекте.

Конечный запас становится предметом управления

Набор параметров и устройство деревьев задают число подписей. Оператору нужны прогноз скорости, срок службы, резерв и время на сертификацию и распространение следующего ключа. Всплеск расхода может быть атакой, законным выпуском или ошибкой телеметрии, но во всех случаях сокращает запас. Откат индекса не добавляет ёмкости — он подделывает журнал.

Реестр LMS в IANA хранит стандартизованные коды типов. Страница RFC Editor, версии в тексте и XML, история IETF и перечень errata подтверждают статус и происхождение стандарта. Они не показывают остаток листьев у оператора и не удостоверяют его процедуру восстановления.

Принцип Heng Lu о работающем коде переводит вопрос к исполняемому переходу: стал ли расход необратимым до выхода подписи? Минимальная исходная спецификация создаёт общий уровень совместимости, но не отменяет локальные решения об изоляции и переключении. Разделение слоёв реальности не позволяет слить в один индикатор существование стандарта, проверку объекта и целостность эксплуатационной истории.

HSS/LMS не устраняет операционное доверие, а переносит его. Схема снижает зависимость от некоторых математических предположений, которым может угрожать квантовый компьютер, но взамен требует безошибочной памяти. Ключ — это секрет вместе с прошлым, которое система обязана никогда не забывать.

Источники