Кратко

  • CBOR-тег 601 обозначает незащищённый набор утверждений CWT: у объекта нет собственной подписи COSE, кода аутентификации или шифрования.
  • В модели RATS подлинность и целостность даёт подходящим образом аутентифицированный канал; свежесть, право на раскрытие и достоверность измерений подтверждаются отдельно.
  • После извлечения канал больше не защищает артефакт. При пересылке RFC 9781 считает оперативным источником получателя, поэтому цепочку происхождения приходится строить заново.

Один хеш, две истории

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

RFC 9781 стандартизует Unprotected CWT Claims Set — UCCS. Обычный CWT помещает утверждения в структуру COSE, которая может нести собственную подпись, контроль целостности или шифрование. UCCS убирает этот конверт, когда развёртывание уже располагает подходящим защитным механизмом: безопасным каналом или, в некоторых случаях, доверенной средой исполнения. Это осмысленная экономия для ограниченных устройств, а не переносимый знак доверия.

Тег #6.601 сообщает декодеру, как интерпретировать объект. Он не содержит скрытой подписи, имени отправителя или идентификатора сессии. Даже одинаковый номер 601 в реестрах CBOR-тегов и CoAP Content-Formats относится к разным регистрационным пространствам. Число помогает распознать форму сообщения, но не доказывает его происхождение.

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

Свежесть — отдельное свойство. RFC указывает на nonce как на способ противодействия повторному воспроизведению. TLS 1.3 дополнительно показывает, почему нельзя записывать только слово «TLS»: ранние данные и обычные прикладные данные имеют разные свойства повторения. Чек аутентификации конечной точки, чек защиты записи и чек nonce или временного окна должны существовать раздельно.

Получатель становится новым говорящим

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

Получатель контролирует выбор, декодирование, нормализацию, хранение, корреляцию и дальнейшую передачу утверждений. Он может переписать CBOR в иную каноническую форму, добавить контекст или удалить поля. Поэтому следующему участнику нужны сведения о преобразовании, исполнителе, входном и выходном хеше и новой защите. Поздняя подпись означает «этот получатель подтверждает эту копию»; она не превращает исходный UCCS в сообщение, подписанное первоначальным Attester.

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

RFC показывает корректный переход в сценарии делегированной аттестации. Sub-Attester без ключа подписи может передать UCCS ведущему Attester по локальному защищённому каналу. Ведущий вычисляет хеш UCCS и защищает его своим ключом доказательства, например в отделённой структуре EAT. Он не утверждает, будто внутри уже была подпись. Он создаёт новое, проверяемое и прослеживаемое заверение от собственного имени.

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

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

Девять квитанций до действия

Практическая цепочка состоит из девяти доказательств: формат и байты; установление канала; идентичность конечных точек; свежесть и защита от повтора; извлечение; хранение и владение; пересылка и новая защита; оценка Verifier; решение и действие Relying Party.

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

RFC 9781 задаёт небольшой общий слой с жёсткой границей. Внутри известного канала можно экономить на объектном конверте. За его пределами нельзя продлевать доверие одной лишь формулировкой в журнале. Тег относится к символическому слою; действующая гарантия возникает из кода, идентичностей и сохранённых квитанций.

Источники