Кратко

  • Measured component хранит стабильное имя, необязательную версию, raw-значение или digest с алгоритмом и, при необходимости, идентификаторы тех, кто подписывает или авторитетно определяет компонент. Они не называют attester, подписавшего внешний EAT.
  • Роли и порядок authorities, а также 64 бита flags задаёт EAT profile. Если consumer не знает profile и встречает эти поля, он обязан отклонить токен.
  • Полная квитанция связывает компонент, границу измерения, значение, component authority, profile, внешнюю подпись, свежесть, reference values, политику verifier, результат и отдельное решение relying party.

Фраза «подписано доверенным ключом» слишком коротка для удалённой аттестации.

Один ключ мог подписать firmware до установки. Другой — Evidence после измерения устройства. Третий защищает Attestation Result. Все подписи могут пройти проверку, но ни одна не получает полномочия соседней только потому, что они находятся в одной цепочке.

RFC 10013 опубликован в июле 2026 года авторами Simon Frost, Thomas Fossati, Hannes Tschofenig и Henk Birkholz. IETF Datatracker документирует многолетнюю работу Tschofenig в области безопасности, а Universität der Bundeswehr München называет его профессором Secure Networks с марта 2026 года. Это точная атрибуция, а не заявление о единоличном авторстве или контроле внедрений.

Измерение ещё не является оценкой

Компонентом может быть firmware, boot loader, загруженное ПО, файл, configuration blob или CPU register. Имя обязательно, версия опциональна. Значение передаётся raw либо как algorithm и digest.

Модель допускает authorities и восемь байтов profile flags. Но структура не подтверждает, что измерен правильный target, сборщик не был обманут, Evidence свежо, а reference value утверждено для этой операции.

Совпавший hash может принадлежать старому запуску. Неверный объект можно измерить без ошибки. RFC 9711 требует authenticity и integrity EAT, но не гарантирует одинаковую защищённость всех attesters и mechanisms сбора claims. Сильная оболочка не исправляет слабое наблюдение.

Authority ID относится к компоненту

RFC 10013 называет authority сущность, которая может авторитетно определить компонент цифровой подписью. Её проверяют при installation или execution. Идентификатором служит X.509 certificate, raw public key, thumbprint или другое уникальное представление ключа.

Спецификация сразу ограничивает вывод: эта component signature не связана автоматически с подписью attester на EAT Evidence. Authority identifier сам по себе не указывает подписанта внешнего токена.

Автор firmware, update system, fleet owner и auditor могут подтверждать компонент. Затем attesting environment измеряет target и подписывает Evidence другим ключом. Даже одна организация не делает роли тождественными.

RFC 9019 проводит такую же линию: authentication автора образа — вход для authorization, а не готовое разрешение. Критическое устройство может требовать подписи и автора, и оператора. Ключ делает голос различимым, policy ограничивает его мандат.

Profile превращает позиции в роли

В массиве может быть несколько authorities, и порядок зависит от deployment. Flags также имеют локальную семантику. Parser видит байты и позиции, но не знает, где производитель, владелец флота или аудитор.

EAT profile обязан объявить использование authorities, значение каждой записи и способ интерпретации. То же относится к flags. При неизвестном profile и наличии этих полей RFC 10013 требует отказа.

Нельзя выбросить неизвестное, позаимствовать порядок другого продукта или принять всё из-за правильной outer signature. Подпись защищает байты, но не создаёт отсутствующий словарь.

Это практическая Minimum Initial Specification: общий слой задаёт переносимую форму и границу против догадок; локальные роли остаются у оператора. Координация не присваивает authorization конкретного deployment.

Порядок rollout становится существенным. Ранний producer вызывает заметный отказ у conformant verifier. Silent fallback сохраняет доступность, но создаёт pass, значение которого невозможно восстановить.

После verifier решение остаётся у владельца ресурса

Attester формирует Evidence и защищает его; nonce или иной механизм даёт freshness. Verifier проверяет происхождение ключа, связь с target и силу attesting environment, затем применяет reference values и appraisal policy.

Он выпускает Attestation Result. RFC 9334 оставляет relying party собственную policy для ресурса и операции. Здоровое устройство может принадлежать другому tenant. Одобренный компонент может не иметь права управлять системой. Корректный result может быть слишком старым для чувствительной транзакции.

Четыре principals — component authority, attester, verifier и resource owner — не представляют друг друга автоматически. Общий token не является общей доверенностью. Именно здесь техническая цепочка встречает agency problem.

Стабильность облегчает учёт и усиливает корреляцию

Стабильное имя помогает отслеживать компонент между releases. RFC одновременно предупреждает, что имя и версия раскрывают ПО и конфигурацию, а постоянство может позволить tracking.

Долгоживущий authority key ID добавляет корреляцию. Profile должен определить получателей. Verifier может нуждаться в подробностях, а relying party — только в ограниченном результате с действием и сроком.

Минимизация не уничтожает внутренний audit trail. Она сохраняет его для проверки и не превращает в глобальный идентификатор устройства.

Состав квитанции

Сохраните точный EAT или content-addressed object, media type, encoding, profile/version. Запишите outer algorithm, attester key, provenance, nonce, время сбора/получения и версию verifier.

Для каждого component храните name, version convention, target, sampling boundary, raw/digest, algorithm/value. Сохраните порядок authorities, profile definition, component signature и результат. Flags нужны как raw bytes и как декодированное значение.

Appraisal-блок называет provider, set/version reference values, сравнения, отсутствующие измерения, policy/version и точный Attestation Result. Затем relying party записывает resource, operation, policy, решение, ограничения, expiry и remediation.

Так неизвестный profile, неприемлемый component signer, ошибочная outer signature, stale Evidence, digest mismatch и compliant-but-unauthorized становятся разными событиями. У них разные владельцы и исправления.

Running-Code Primacy требует видеть фактическое решение реализации. Pass/fail без входов, profiles и policies стирает наблюдаемость вместо того, чтобы доказать её.

Источники