摘要
- CBOR 标签 601 只标明这是没有对象级签名、MAC 或加密的 CWT Claims Set,不证明发送者或内容真实性。
- 在 RATS 场景中,接收方必须在建链时认证发送方,信道必须保障完整性;保密、接收方身份与防重放仍需明确证明。
- UCCS 一旦离开信道进入接收方,原信道便不再保护它;接收方继续转发时,RFC 9781 将其视为源自该接收方的新陈述。
关掉连接,不能把“已认证”留在字段里
一次设备证明结束后,接收服务把 UCCS 解码为 JSON,写入日志,并把 authenticated=true 一同保存。几天后,分析程序读到这个布尔值,便把声明当成设备本人仍在背书的事实。
问题不在布尔值真假。问题在于它省略了保障的作用域。
普通 CWT 使用 COSE 包装,可以让对象携带端到端的来源认证与完整性证据。UCCS 则是为已经具备合适安全关联的部署节省资源:不再给每个 Claims Set 重复套一层 COSE,而由通信信道提供相应属性。其 CDDL 形式是 #6.601 包住一张声明映射。这个标签让解析器知道数据类型,却不包含签名者、会话、受众或新鲜度证明。
RFC 9781 对 RATS 传递提出了精确条件。接收方必须在建立安全信道时认证发送方,双方通信必须具备完整性保障。需要保密时,接收方也必须被认证,因为发送方是否可以披露设备声明,取决于对方身份与权限。TLS 1.3 可以承载这种信道,但“TLS 成功”还远远不够:必须记录版本、认证模式、凭据与信任锚、双方角色、具体连接以及哪些字节经由该连接到达。
防重放不能被藏进“安全”二字。RFC 对 Secure Channel 的定义包含重放保护,同时又明确指出可用 nonce claim 增加这一属性。TLS 的普通 1-RTT 数据与 0-RTT 数据也有不同风险。运行回执因而必须说明使用了什么挑战、接受窗口或会话绑定,不能从端点身份推导出声明新鲜。
信道身份还不能由同一份 UCCS 自我证明。若先用 UCCS 建立对凭据的信任,再用这些凭据证明传输 UCCS 的信道可信,逻辑会形成循环。端点认证必须有独立依据。即便端点身份正确,也只说明信道忠实传递了它发送的字节,不说明测量环境没有被篡改。
抽取不是复制动作,而是来源交接
RFC 9781 第 4 节划出硬边界:UCCS 从安全信道进入接收方后,信道的安全属性不再保护它,它与验证器环境中的其他无保护数据处于同一地位。接收方随后转发时,应把这些声明视为源自接收方。
这意味着接收服务不能继续冒充透明管道。它选择了哪些字节被接受、用何种解析器解码、是否重编码、保存多久、交给谁,以及下一跳采用什么保护。下游真正可验证的是接收方的新陈述:“我在某次已认证会话里收到这组字节,并按某项策略处理后交给你。”
因此,第一个必要回执是原始字节哈希与信道会话的绑定。若 CBOR 被规范化为另一种编码,还要同时保存转换前后哈希、解析器版本和转换规则。第二个是保管回执:写入主体、对象标识、访问控制、静态加密密钥、保留期限和删除结果。第三个是转发回执:输入哈希、新发送方身份、新信道或签名、受众、时间和确认状态。
哈希只能证明某两个副本相同,不能证明是谁在何种信道中取得它们。静态加密只能保护数据库,不能追认原始发送方。新的 TLS 连接只能认证转发服务,不能让下游重新见证早已结束的设备会话。
委托证明给出了正确的升级方式。没有签名密钥的子 Attester 可以经本地安全信道把 UCCS 交给主 Attester。主 Attester 计算 UCCS 哈希,再用自己的 Evidence 签名密钥保护该哈希,例如写入 detached EAT 结构。这不是恢复原本不存在的签名,而是主 Attester 明确接管来源责任。
完整 CWT 则不同。其 COSE 封装仍携带自己的来源和完整性证据,外层信道不会自动替内部签名者背书。只有在 UCCS 以信道替代对象保护时,抽取才会造成本文讨论的来源断点。
评估与行动仍然分开
完整链条至少有九个节点:格式与字节、信道建立、端点身份、重放与新鲜度、抽取、存储、转发、Verifier 评估、Relying Party 行动。任何一个后续“成功”都不能覆盖前一步的不确定性。
RFC 9334 区分产生 Evidence 的 Attester、依据参考值和策略进行评估的 Verifier,以及决定具体访问或操作的 Relying Party。当接收方成为转发来源时,Verifier 还必须知道自己评估的是原始环境、接收方重新保护的陈述,还是两者之间有证据连接的组合。
RFC 9781 的价值恰恰来自克制。它规定一个最小、可互操作的格式和信道边界,却不把标签、标准发布或握手状态夸大成普遍信任。按照 Heng Lu 对“符号层”与“现实层”的区分,标签是可识别的符号;只有实际运行的认证、完整性、新鲜度、保管与行动回执,才构成可执行的保障。
来源
- RFC 9781 — Unprotected CWT Claims Sets
- RFC 8392 — CBOR Web Token
- RFC 8446 — TLS 1.3
- RFC 8725 — JSON Web Token Best Current Practices
- RFC 9052 — COSE Structures and Process
- RFC 9334 — RATS Architecture
- RFC 9711 — Entity Attestation Token
- IANA CBOR 标签注册表
- IANA CWT 声明注册表
- Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Heng Lu — Running-Code Primacy
- Heng Lu — Reality Layers
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance

