Кратко

  • RFC 9783 описывает Entity Attestation Token для PSA Initial Attestation с ограниченными утверждениями о nonce, client ID, instance ID, implementation ID, жизненном цикле и программных компонентах.
  • Защищённый токен может служить основанием для оценки Verifier, но сам не доказывает, что Relying Party обязана зарегистрировать устройство, дать доступ, сохранить статус или выполнить следующий шаг.

Смысл стандарта лучше всего виден через распределение ролей из RFC 9334. Attester производит Evidence; Verifier оценивает его; Relying Party использует Attestation Result для собственной цели. RFC 9783 делает PSA-свидетельство переносимым и понятным для этого процесса. Он не превращает один удачно проверенный пакет в полномочие, способное заменить оценку и решение того, кто несёт последствия.

Nonce показывает предел очень наглядно. Профиль требует ровно один nonce длиной 32, 48 или 64 байта. Он связывает отчёт с конкретным вызовом и даёт Verifier возможность убедиться в свежести доказательства, а не принять повтор старого отчёта. Это важная защита от воспроизведения. Но свежесть относится к времени и к запросу. Она не подтверждает право отправителя на услугу, согласие оператора, принадлежность к утверждённому парку или необходимость выдать постоянный доступ. Новое доказательство не равно разрешению.

Client ID имеет иной, столь же узкий смысл. Он обозначает домен безопасности, из которого был вызван Initial Attestation. RFC 9783 требует проверять его, чтобы одна конечная точка не выдала себя за другой домен. Несоответствие должно остановить использование отчёта для данного запроса. Однако совпадение устанавливает только домен вызова. Оно не назначает владельца учётной записи, не подтверждает договорную роль и не определяет объём прав. Разделить вызывающие домены необходимо; раздать им привилегии — другое решение.

Не менее важна разница между instance ID и implementation ID. Первый указывает на конкретный ключ Initial Attestation и экземпляр. Второй указывает на неизменную аппаратную сборку PSA Root of Trust, а не на отдельный экземпляр; по нему Verifier может найти материал Endorser, например сведения изготовителя или статус сертификации. Это ответы на разные вопросы: какой экземпляр подписал отчёт и какая реализация заявлена. Оба могут быть нужны для строгой оценки, но ни один не отвечает, какое действие сервис должен совершить сейчас.

Утверждения о жизненном цикле и программных компонентах требуют той же аккуратности. Жизненный цикл содержит старшее и младшее значения; профиль определяет состояния, в которых отчёту нельзя доверять. Компоненты описывают код, конфигурацию и иные загруженные элементы в измеряемом диапазоне PSA Root of Trust. Эти данные позволяют Verifier отказать, сузить профиль оценки или запросить дополнительные материалы. Они не подтверждают текущую цель нагрузки, согласие клиента, мандат оператора, оправданность сохранённого исключения или эффект команды после её выполнения.

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

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