摘要

  • RFC 9529 公布两套带注释的 EDHOC 轨迹，把固定输入、协议消息、转录哈希、中间 PRK、密文、导出器结果、OSCORE 参数和密钥更新结果连成可核对的证据链。
  • 全部字节吻合，只能证明这条固定计算路径被正确复现；它不证明随机数新鲜、私钥受控、异常输入检查完备、凭据拥有业务权限，或真实设备完成了预期动作。
  • 可用于决策的保证至少要连接五张独立收据：向量复现、负面输入覆盖、熵与密钥保管、凭据与策略权限、真实会话与应用结果。

持续集成页面一片绿色。message_1、TH_2、PRK_3e2m、CIPHERTEXT_3、PRK_exporter 以及最后的 OSCORE 主密钥，都与 RFC 的参考字节完全一致。团队于是把结论写成了“EDHOC 已验证”。

但设备每次重启后都重复使用同一把临时私钥。

这是用于说明证据边界的场景，并非某家厂商的真实事故。RFC 9529 的价值，在于把通常很难观察的密钥交换计算拆开：实现者不必只盯着最后一个成功或失败，而可以找到第一处偏离。两套独立实现核验过这些轨迹，这比一个代码库自证更有分量。

问题不在于轨迹不可靠，而在于它从未声称覆盖固定输入之外的属性。

一条轨迹把多层计算暴露出来

EDHOC 面向受限设备，但一次会话仍要连接方法与密码套件选择、连接标识、临时 Diffie-Hellman 材料、身份凭据、转录哈希、MAC 或签名输入、认证加密、密钥导出以及常见的 OSCORE 参数。

RFC 9529 给出两条完整路径。第一条使用签名认证双方，以 x5t 标识 X.509 凭据，用 X25519 完成临时—临时 DH，用 EdDSA 认证。第二条使用静态 DH 与由 kid 标识的 CBOR Claims Set 凭据，采用 P-256，并通过一次错误和第二次 message_1 展示密码套件协商。

文档没有停在三条主要消息。它列出 TH_2、TH_3、TH_4 的输入和结果，中间伪随机密钥，明文、密文与关联数据，PRK_out、PRK_exporter、OSCORE Master Secret、Master Salt，以及 KeyUpdate 之后的新结果。只要保留这些中间状态，工程师便能从第一处差异向前追，而不是在“握手失败”四个字上争论。

这正是参考轨迹的授权范围：在这些明确输入之下，规定的计算应该得到这些字节。

公开私钥是测试条件，不是部署条件

要让所有实现得到相同输出，输入必须固定。因此 RFC 9529 在需要时公开双方的私钥、公钥和凭据。安全注意事项写得很明确：示例中的密钥不能被视为秘密，绝不能投入使用。

这并非缺陷。测试向量需要已知秘密，才能让任何人复现相同的 DH、签名和 KDF 结果；生产系统则需要不可预测、受控生成、受控使用并及时销毁的秘密。同一组字节不可能同时承担这两个角色。

所以，向量通过不回答以下问题：设备的随机数发生器是否健康；冷启动、回滚或克隆后是否生成独立临时密钥；私钥能否被导出；用完后内存是否清除；所谓硬件边界是否真的限制了操作；并发会话是否共享了本应独立的状态。

更好的记录不会只留下“RFC 9529 通过”。它应把向量编号、实现版本、硬件与编译环境，与熵健康结果、密钥生成来源、密钥保管证据、重启和并发测试分别保存。

转录一致不是在线身份

转录哈希是极有价值的连接点。TH_2 连接响应方临时公钥与 message_1 的哈希；后续哈希再把前一状态、认证明文和凭据并入。派生密钥和密文都依赖这条历史。一处不同的 CBOR 序列、遗漏的凭据、错误的套件或 KDF 上下文，最终都会留下可定位的差异。

但参考转录中的凭据和密钥已经由文档提供。真实会话仍要解析凭据，按照正确规则验证它，把它映射到设备或运营主体，再判断该主体是否有权执行本次操作。密码学认证通过，完全可能与本地身份映射错误或业务授权错误同时存在。

转录一致也不是应用结果。RFC 9529 展示了固定输入下如何导出 OSCORE 材料，却不证明后续应用消息被接收、重放窗口生效、传感器数据新鲜，或执行器完成了动作。导出器结果位于这些事件的上游，不能替它们签字。

无效样例是探针，不是完整攻击面

第四节给出实现不应生成、并应按 EDHOC、CBOR、COSE 和 NIST 规则拒绝的消息。其中包括：把 CBOR 序列误写为数组；给连接标识或凭据标识多套一层容器；元素数量或类型错误；把临时密钥写成文本字符串；使用非确定性编码。

密码学错误还包括：密钥长度不合套件要求；横坐标超出域；坐标不在曲线上；Curve25519 低阶点；MAC 太短；椭圆曲线编码遗漏前导零。

RFC 同时限定了这份清单的权力：它只是一小组例子，相同类型的错误还可能出现在其他字段和消息中。全部拒绝公开的无效向量，不能证明解析器能安全处理任意嵌套、长度、状态转换和资源消耗。模糊测试、属性测试、差分测试、资源上限测试和代码审查仍各有自己的证据范围。

采购语言也应遵守这一区分。“能拒绝 RFC 9529 所列无效轨迹”可以审计；“能稳健抵御畸形 EDHOC 输入”则是更广的声明，需要更广的测试。

确定性 CBOR 属于密码学状态

一些看似密码学的失败，其实发生在编码层。RFC 9529 反复区分原始字节串与其 CBOR 编码，并指出 CBOR 序列和数组的元素本身也是编码后的数据项。它把不必要的长整数形式、在要求确定性编码时使用不定长数组，都列为无效样例。

这不是格式美观问题。转录哈希、签名输入、MAC 上下文和 KDF 输入处理的是字节。调试器里看起来相同的两个对象，只要编码不同，就可能形成不同的密码学状态。

因此，合格的测试收据需要保存原始消息、确定性编码判断、首个分歧的中间值、实际套件和凭据形式。若日志只留下解析后的对象，解释失败所需的证据可能已经被清理掉。

互操作性是真证据，但不是无限证明

RFC 9529 的轨迹经两套独立实现核验，致谢也记录了测试向量和互操作工作。独立一致显著降低了某个私有约定被误当成协议规则的风险。

它仍然是对选定样例的一致。它不证明所有注册套件、方法、凭据类型、外部授权数据项和错误路径都已实现。IANA EDHOC 注册表 说明一个值已按程序获得语义；它并不证明某产品支持该值，更不证明某次部署应该启用它。

把可移植的最低共同层写成最高保证，是基础设施治理中常见的错位。标准与轨迹提供共同起点，厂商和运营者仍要对实现范围、启用策略、生命周期和可观察故障负责。

把保证拆成五张收据

第一张是向量复现：记录具体轨迹、实现版本、平台、编译器、密码后端，以及每个中间值是否一致。不要在保存首个差异之前，把上百项比较压成一个徽章。

第二张是负面输入：哪些公开无效轨迹被拒绝，在哪一层拒绝，还测试了哪些生成或变异样例；被拒绝后，协议状态是否保持一致。

第三张是熵与密钥：启动和连续健康状态，跨重启、回滚、克隆与并发会话的临时公钥重复情况，私钥来源、隔离与清除证据。

第四张是凭据与权限：x5t 或 kid 如何解析，使用哪个信任锚和验证规则，凭据对应哪个运营主体，允许哪些方法与套件，该主体获准做什么。

第五张才是运行结果：对端状态、会话标识、重放判断、导出器用途、OSCORE 上下文、受保护应用消息和实际效果。

这正符合 Heng Lu 对现实层的区分。规范不是实现；计算吻合不是新鲜密钥；凭据有效不是操作获准；密钥导出成功不是应用动作完成。把各层连接起来，才能保留因果；把它们压成一个绿色状态，只会制造没有控制力的信心。

来源没有证明什么

闭合的来源没有指向某个真实厂商重复临时密钥，也没有给出 EDHOC 部署数量、设备群故障率、侧信道结论或通用认证承诺。开篇只是一种可发生的控制失配。

这也不是削弱 RFC 9529。恰恰因为它把复杂密钥交换拆成可执行、可比较的证据，边界才值得认真维护。参考轨迹可以证明计算被复现；真实部署的其他层，仍应各自留下收据。

来源