Кратко

  • RFC 10013 описывает измеренный компонент обязательными именем и сырым либо хешированным значением; версия, подписавшие компонент стороны и профильные флаги остаются дополнительными. Объект можно передать в JSON или CBOR в составе измерений EAT.
  • Совпадение дайджеста не доказывает полноту замера, актуальность эталона, принадлежность устройства или его право на ресурс. Подписант установленного компонента и подписант самого EAT — разные роли, а результат сравнения не равен общему решению проверяющей стороны.
  • Защищаемая цепочка должна сохранять область и момент измерения, свежесть EAT, профиль, происхождение эталона, версию политики Verifier и отдельное правило Relying Party для запрошенной операции. Один зелёный статус скрывает именно те границы, которые понадобятся при расследовании.

После неудачного обновления парк выглядел одинаково

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

Один терминал отправляет свежий Entity Attestation Token. Подпись проверяется ожидаемым ключом Attester. В измерениях указан компонент с именем загрузчика, версией и SHA-256-дайджестом. Идентификатор подписавшей компонент стороны соответствует утверждённому поставщику. Профиль известен, значение совпадает с эталоном, а Verifier сообщает об успешной оценке.

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

Все эти утверждения могут быть верны одновременно с корректным дайджестом.

RFC 10013, опубликованный в июле 2026 года как Proposed Standard, стандартизирует описание измеренного компонента в EAT. Он не объявляет устройство безопасным, принадлежащим нужной стороне или уполномоченным на действие. Узость стандарта — не пробел, который должен заполнить удобный зелёный индикатор. Это граница между переносимым свидетельством и локальным решением с реальными последствиями.

Измеренный компонент — выбранный срез, а не вся система

Под компонентом RFC понимает объект в целевой среде, состояние которого можно получить измерением. Это может быть прошивка во flash-памяти, код, загруженный при старте, результат проверки целостности во время работы, файл, конфигурационный блок или регистр процессора.

Такой охват нужен потому, что CoSWID по RFC 9393 хорошо описывает программные артефакты и инвентаризацию, но не всякое раннее загрузочное или аппаратное состояние естественно представляется программным идентификатором. RFC 10013 вводит общий объект там, где одного инвентарного ярлыка недостаточно.

Однако общий объект не выбирает, какие байты должны попасть в замер.

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

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

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

Поля объекта говорят о разных вещах

В информационной модели обязательны имя компонента и одно значение — сырое или хешированное. Дополнительно можно передать версию и массив authorities. Конкретные модели JSON и CBOR добавляют восьмибайтовое поле флагов.

Имя предназначено для человека. Его соглашение зависит от типа компонента. Стандарт рекомендует сохранять имя между выпусками, чтобы Verifier мог прослеживать один компонент сквозь обновления. Из этого не возникает глобального пространства имён. Одинаковая строка у двух производителей может означать разные объекты, а путь к файлу может остаться прежним после смысловой замены содержимого.

Необязательная версия добавляет контекст выпуска. Она может использовать словарь схем версий из CoSWID; Semantic Versioning рекомендован, но не навязан регистру, конфигурации или каждой прошивке. Строка версии заслуживает доверия лишь вместе с правилом её выпуска и доказуемой связью с измеренными байтами.

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

Хешированное значение содержит идентификатор алгоритма и байты дайджеста. Алгоритм интерпретируется по реестру IANA Named Information Hash Algorithms, а RFC требует стойкий криптографический хеш. Стойкость защищает само сравнение от слабого алгоритма. Она не доказывает, что сборщик прочёл правильную область, что эталон выражает сегодняшнюю политику или что замер относится к текущему запуску.

Два подписанта нельзя слить в одну роль

Массив authorities создаёт особенно опасную двусмысленность интерфейса.

В RFC 10013 component authority — сторона, способная авторитетно идентифицировать установленный компонент, подписав его. Идентификатором может быть сертификат X.509, открытый ключ, отпечаток ключа или иное значение, однозначно связанное с подписывающей стороной. Подпись могла проверяться при установке, как в архитектуре обновлений RFC 9019, либо загрузочной прошивкой, операционной системой или приложением.

Это прямо не подпись Attester над содержащим свидетельство EAT.

Один ключ свидетельствует о происхождении установленного артефакта. Другой защищает набор claims и связывает его с аттестующей средой. Если панель называет component authority «подписантом токена», она стирает целый переход доверия и приписывает одной стороне действие другой.

Authorities могут включать несколько значений: например, поставщика обновления, владельца парка и внешнего аудитора. Порядок записей способен иметь смысл. Базовый стандарт этого смысла не назначает. Применимый профиль EAT обязан объяснить, используется ли массив, кого означает каждая позиция и как читать её байты.

То же верно для flags. Поле имеет ровно восемь байтов, однако RFC 10013 не задаёт значения ни одного бита. Если authorities или flags присутствуют, а профиль потребителю неизвестен, EAT должен быть отвергнут. Сохранить данные и угадать знакомое значение — значит не обеспечить совместимость, а незаметно придумать политику.

JSON и CBOR переносят смысл, но не выносят вердикт

Стандарт согласует две модели данных. CBOR EAT может нести CBOR-объект напрямую или туннелировать JSON. JSON EAT может нести JSON-объект либо base64url-кодированный CBOR. В реестре типов данных IANA находятся application/measured-component+cbor и application/measured-component+json, а реестр CoRE Content-Formats назначает им значения 295 и 296.

Регистрация делает представление распознаваемым. Она не удостоверяет производителя, Verifier или Relying Party и не превращает синтаксически правильный объект в допустимое состояние.

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

Официальный поиск errata для RFC 10013 30 августа 2026 года не показывал подходящих записей. Это датированное состояние реестра, а не гарантия единой интерпретации во всех реализациях.

Подлинный EAT всё ещё может быть слабым свидетельством

RFC 9711 определяет EAT как сообщение с утверждениями. Он подчёркивает ограничение: общая семантика claims не требует определённого уровня защищённости их реализации или самого Attester.

Получатель оценивает надёжность, понимая, как поставщик реализовал Attester и какие проверки выполнил Verifier. В одном устройстве claims создаёт хорошо изолированный аппаратный корень доверия, в другом — обычный процесс приложения. Единое кодирование не делает эти источники равноценными.

Для каждого применения EAT обязательна свежесть. Nonce, метка времени или иной механизм мешает выдать старое подписанное сообщение за нынешнее. Но свежесть токена не обязательно означает свежесть каждого измерения. Загрузчик мог быть измерен при старте, а токен выпущен позже. Нужно отдельно сохранять время выборки, время выдачи и эпоху загрузки, которая связывает их.

EAT также различает claim с измерениями и measres, где сообщается результат сравнения с ожидаемыми значениями: успех, неудача, отсутствие сравнения либо отсутствие результата. RFC 9711 отдельно говорит, что measres не является общим результатом Verifier. Интерфейс, который отображает measres=success как «устройству доверяют», сжимает сравнение, оценку и выдачу права в поле, не предназначенное для такого полномочия.

PSA Attestation Token в RFC 9783 показывает, насколько различаются допустимые правила. Одна политика требует точного измерения, другая принимает несколько выпусков, третья больше опирается на известного подписанта. Они отвечают на разные вопросы риска. Токен не может выбрать политику за организацию.

Эталон меняет решение, не меняя устройство

Совпадение всегда относительно набора Reference Values. У такого набора есть поставщик, происхождение, версия, время вступления в силу и история отзыва.

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

Поэтому Reference Value Provider фактически управляет частью производственного решения, даже не имея доступа к терминалу. Задержка публикации, ошибочный набор, неясная юрисдикция обновления или невозможность воспроизвести прошлую версию влияют на весь парк сразу.

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

Verifier оценивает, Relying Party распоряжается доступом

Архитектура RATS в RFC 9334 даёт цепочке отдельные имена. Attester создаёт Evidence. Reference Value Provider предоставляет ожидаемые значения. Endorser сообщает о возможностях или основаниях доверия. Verifier применяет Appraisal Policy for Evidence и выпускает Attestation Result. Relying Party рассматривает этот результат по своей Appraisal Policy for Attestation Results и решает, какую операцию разрешить.

Один сервис может технически объединять несколько ролей. Их логическая ответственность от этого не исчезает.

Verifier способен свести неоднородные, зависящие от производителя свидетельства к понятному результату. Это полезно и одновременно концентрирует власть. Relying Party должен знать, какой Verifier, какая версия политики, какая сила evidence и какая свежесть лежат за результатом.

Главное: исправность не означает правомочие. RFC 9334 приводит смысловой пример предприятия, которому недостаточно знать, что ноутбук здоров по правилам производителя: перед сетевым доступом нужно также доказать принадлежность конкретного устройства предприятию. Исправный терминал подрядчика остаётся терминалом подрядчика.

Последнее решение должно оставаться там, где наступает последствие. Relying Party знает ресурс, операцию, учётную запись, регистрацию устройства, владельца, сумму транзакции и текущий режим инцидента. Verifier сообщает, что именно он оценил. Он не должен незаметно решать все последующие бизнес-разрешения.

Аудит должен пройти по всей цепочке

Восстановимая запись выглядит не как один boolean, а как последовательность:

область компонента → сборщик и время → сырое либо хешированное значение → соглашение об имени → смысл component authority → подписант и свежесть EAT → профиль → Reference Value и его поставщик → политика и результат Verifier → политика Relying Party → разрешённая операция → наблюдаемый исход.

При инциденте эти переходы различают причины. Если устройство получило лишний доступ, сборщик мог пропустить важный модуль, эталон мог одобрить уязвимый выпуск, Verifier мог применить не ту политику, а Relying Party — выдать больше прав, чем оправдывал результат. Без промежуточных записей каждая команда укажет на один зелёный значок, и ни одна не будет владеть решением.

Анализ слоёв реальности Хэн Лу помогает удержать границу. Имя, версия, дайджест, идентификатор подписанта и результат — символические представления выбранного физического и операционного состояния. Их доказательная сила растёт, когда пределы явны. Риск появляется, когда представление начинают считать самой реальностью.

Конфиденциальность продолжается после расшифрования

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

Один сервис может расшифровать и проверить EAT, а затем передать части claims специализированным потребителям. RFC 9711 требует эквивалентной защиты связи после снятия исходной защиты токена и рекомендует ограничивать сведения нуждами каждого получателя.

Формальная собственность на терминал не показывает, кто фактически читает evidence. Различие между техническим и практическим суверенитетом данных требует перечня каждого получателя, журнала, трассировки, аналитического хранилища и внешнего оценщика, где могут остаться имя компонента или сырое состояние. Организация может владеть устройством, пока чужая проверочная цепочка владеет более подробной картой его эксплуатации.

Нормой должна быть выборочная передача по назначению. Сетевой шлюз может нуждаться в актуальном Attestation Result, но не в полном конфигурационном блоке. Службе ремонта может быть нужна версия компонента, но не постоянный идентификатор владельца. Повторное использование следует обосновывать для каждого claim отдельно.

Ценность стандарта — в отказе от лишнего полномочия

RFC 10013 достигает цели, не называя устройство хорошим.

Он даёт разным системам общий объект измеренного компонента, согласует JSON и CBOR, требует от профиля объяснять authorities и flags, указывает на стойкие хеши и обязывает отвергать данные, если профильные поля невозможно истолковать. Он также предупреждает о раскрытии стабильных имён и версий.

Всё последующее — не отсутствующий протокол, а распределённая ответственность. Сборщик отвечает за границу. Attester — за происхождение evidence. Component authority — за происхождение артефакта. Reference Value Provider — за опубликованное ожидаемое состояние. Verifier — за оценку. Relying Party — за разрешение. Оператор — за последствия их соединения.

Прошивка может совпасть с эталоном. Вернуться в сеть она вправе только после решения всей цепочки.