摘要

  • RFC 10021 要求失去安全上下文状态的 Group OSCORE 端点避免重复使用 nonce、避免把旧消息当新消息：先停下来，恢复相关上下文，再验证新鲜性。
  • 恢复上下文或通过新鲜性挑战，只能证明一项有限的协议条件；它不能重建先前指令、当前批准、安全条件或已完成的效果。

现场设备重启后，最容易造成误判的词往往是“已恢复”。它可能只是电源回来了，网络链路重新出现，密钥存储可访问，或者监控平台又看到了心跳。这些都是不同事实。任何一个都不应被悄悄改写成“可以继续刚才没做完的工作”。

RFC 10021 于 2026 年 7 月作为 IETF 标准轨 RFC 发布，定义了 Group OSCORE：让 CoAP 在群组成员之间进行受保护通信。在群组模式中，发送者保护 CoAP 消息并以私钥生成副签名；接收者用发送者公钥和安全上下文验证该副签名。协议可以就某条受保护消息及其源认证处理给出精确结论，但它不是业务流程调度器。

这种克制在易失状态消失时最有价值。Group OSCORE 把安全上下文分为较长期部分与可能在非计划重启中丢失的可变部分。端点一旦发现该丢失，就必须防止使用同一密钥重复使用 nonce，并处理重放消息。若无法取得更新后的参数，就不得继续用受影响的上下文保护消息；非静默端点若无法重新获得识别重放的能力，也不得接收群组入站消息。这是安全停机，而不是用一个“重启完成”标志绕过的麻烦。

当设备为了回收有限内存而删除接收者历史时，规则同样严格。重新派生的 Recipient Context 起始于无效的 Replay Window，因为设备已不知道足够多的先前流量，无法区分新请求与旧请求。RFC 10021 只给出受限路径：丢弃该消息、取得新的安全上下文参数，或使用 CoAP Echo 程序。它没有说，下一条看起来正确的报文就能补回过去。

Echo 特别容易被过度解释。RFC 9175 允许服务器发出挑战，由客户端回送，以便服务器按应用自行定义的要求检查请求新鲜性。在 Group OSCORE 中，正确回送的 Echo 可以使相关重放窗口变为有效，让新鲜请求进入应用层。这是对抗重放信心的定点恢复。Echo 不把请求绑定到某一个先前响应，不重建事务日志，不证明缺席操作员仍希望该动作发生，也不决定执行器是否可重新启动。

Group Manager 的职责重要但有限。RFC 10021 要求它核验加入端点是否有资格进入该群组，既可直接核验，也可依据受信实体先前提供的证据；授权细节明确不在 RFC 范围内。进入一个安全群组，不等于得到对后来经过该群组的一切操作的永久委托。上下文分发、成员资格与此刻的业务授权，属于不同记录，也按不同时间钟变化。

密钥轮换进一步说明，一个绿色状态远远不够。客户端可能刚用旧上下文保护请求，服务器就安装了新群组参数，随后服务器用新上下文保护响应。RFC 10021 规定了如何避免这个过渡中的 nonce 重用问题；它没有断言原请求仍及时、目标状态仍被希望，或迟到的响应足以证明流程完成。

这里的编辑判断是：把丢失检测、旧/新上下文标识、重新配置或新鲜性挑战、签名与重放结果、应用状态核对、本地批准和独立观察到的效果分别保存。这样，系统可以安全恢复消息保护基础，而不会把“恢复”偷换成“拥有下一步决定权”。

来源