Кратко

  • suit-report-reason-invoke-pending нужен, когда Evidence подписывается перед вызовом кода, который может не вернуть управление; итог в этот момент неизвестен.
  • SUIT_Record хранит координаты в манифесте, а не самодостаточный журнал. Без точного манифеста, проверенного по digest, реконструкция запрещена.
  • Операционный вывод требует отдельных чеков на свежесть, среду отчёта, передачу управления, первое исполнение, устойчивую работу и эффект сервиса.

Момент, когда нельзя обещать результат

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

Для remote attestation отчёт часто приходится подписывать заранее. Записать success удобно: наверх уйдёт завершённый объект, а процессор сможет продолжить. Но это будет подписанная догадка о будущем.

draft-ietf-suit-report-22 вводит точную формулировку: suit-report-reason-invoke-pending означает, что вызов сейчас будет предпринят, а окончательный исход пока неизвестен. В документе прямо сказано, что безусловный успех ввёл бы в заблуждение, если invocation впоследствии завершится неудачей.

Pending здесь не является ошибкой. Это граница осведомлённости. Подпись удостоверяет высказывание на этой границе, но не добавляет к нему события из будущего.

Координаты без манифеста не образуют маршрут

Формат экономит место: манифест служит словарём. SUIT_Record указывает путь в дереве зависимостей, секцию команд, смещение, индекс компонента и измеренные свойства. Полный смысл команды остаётся в исходном манифесте.

Получатель должен найти совпадающий манифест и проверить его через suit-report-manifest-digest. Если root manifest содержит reference URI, в отчёте требуется в точности то же значение. Без совпадающего манифеста использовать records для реконструкции нельзя.

Sequence number для этого недостаточно. Несколько доверенных подписантов способны выпустить разные манифесты с одинаковым номером. Digest выбирает конкретные байты, относительно которых имеют смысл offset и component index.

system-property-claims несут собственный идентификатор компонента и могут обрабатываться раньше. Это ограниченное исключение показывает разницу между самостоятельным claim и ссылкой на позицию в чужом документе.

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

Свежесть не равна завершению

suit-report-nonce может защищать от replay. Если внешний контейнер уже предоставляет freshness, например challenge в процедуре attestation, отдельный nonce необязателен.

У каждой проверки своя область. Подпись отвечает за происхождение и целостность. Freshness — за принадлежность текущему обмену. Digest — за словарь. Измерения — за приемлемость программ, создавших evidence. Result — за состояние, которое процессор мог утверждать при подписи.

Свежий invoke-pending не становится success. Старый success может быть подлинным и относиться к прошлой загрузке. Совпавший digest ничего не говорит о том, был ли Report Generator ожидаемой версии.

Статус «verified» без расшифровки скрывает, какой вопрос вообще проверялся.

Среда измерения тоже является объектом измерения

Для использования SUIT Report как Attestation Evidence редакция 22 требует измерить среду его создания. Обычно это Manifest Processor, Report Generator, а также bootloader и операционная система, обеспечивающие их работу.

Законный ключ может остаться доступен изменённому генератору. Тогда контейнер пройдёт криптографическую проверку, хотя claims выбрало не то ПО. Измерения позволяют оценить автора содержания, а не только защиту результата.

RFC 9334 разделяет роли. Attester выпускает Evidence. Verifier применяет политику и формирует Attestation Results. Relying Party принимает решение о доверии. В SUIT Verifier дополнительно получает соответствующий манифест, восстанавливает waypoints и преобразует их в понятные claims.

Подпись не передаёт Relying Party чужое решение. Trust остаётся выбором, основанным на оценённой trustworthiness.

Защищённый канал доставляет неопределённость без искажений

Удалённые отчёты должны идти по аутентифицированному и конфиденциальному каналу либо внутри равноценной защиты. Подходят защищённые claims EAT, COSE и безопасный транспорт. Если локальная политика требует аутентификации, нельзя отправлять неаутентифицированную замену; частичный отчёт подчиняется той же политике целостности.

Это предотвращает подмену и утечку. Но безопасная доставка не является свидетелем исполнения. Полученный invoke-pending всё ещё говорит только о предстоящем вызове.

После handoff нужны новые наблюдения: достижение entry point, жизнеспособность в заданном интервале и внешний результат сервиса. Эти три свойства не следует объединять.

Цепочка, сохраняющая время

Сначала сохраняются исходные байты, способ защиты, подписант, результат валидации и источник freshness. Затем — root manifest digest, точный манифест и восстановленные путь, секция, offset и компонент. После этого оцениваются измерения processor, generator, bootloader и OS.

Исходный result не переписывается позднейшим успехом. К нему добавляются чеки runtime:

подлинный отчёт → freshness → точный манифест → реконструкция → измеренная среда → handoff → исполнение → эффект

На момент исследования редакция 22 оставалась активным Internet-Draft с предполагаемым статусом Proposed Standard. Она находилась в очереди RFC Editor и была заблокирована ссылкой второго поколения. Это не RFC и не свидетельство внедрения.

Источники