跳到主要内容

11. 安全考量

  1. 安全考量

本规范的实现者需要考虑多项安全考量. 针对单个算法的安全考量放在该算法说明旁边. 虽然此处突出列出了一些考量, 但更多考量可在参考文献所列文档中找到.

实现需要保护所有主体的私钥材料. 关于这一问题, 本文档中的某些情况需要特别强调.

  • 对两个不同算法使用同一个 key 可能泄露关于该 key 的信息. 因此建议将 key 限制为只用于单个算法.

  • 将 "direct" 用作 recipient algorithm 并与第二个 recipient algorithm 组合, 会把 direct key 暴露给第二个接收者; [RFC9052] 第 8.5 节禁止将 "direct" recipient algorithm 与其他模式组合.

  • 本文档中的若干算法对 key 可使用次数有上限, 超过后可能泄露关于该 key 的信息.

使用 ECDH 和 direct plus KDF (无 key wrap) 不会直接导致私钥泄露; KDF 的单向函数会防止这种情况. 然而, 还有另一个需要处理的问题. 拥有两个接收者要求在两个接收者之间共享 CEK. 因此, 第二个接收者拥有一个由可用于弱来源证明的材料派生出的 CEK. 第二个接收者可以使用同一个 CEK 创建消息并发送给第一个接收者; 对于 Static-Static ECDH 或 direct plus KDF, 第一个接收者会假定该 CEK 可用于来源证明, 即使它来自错误的实体. 如果添加 key wrap 步骤, 则不会隐含来源证明, 此问题也就不存在.

虽然前文已经提到, 但值得重复的是, 在某些情况下已经证明单个 key 用于多个算法会泄露关于 key 的信息, 从而给攻击者伪造完整性标签或获取加密内容信息的机会. 将 key 绑定到单个算法可以防止这些问题. 强烈鼓励 key 创建者和 key 使用者不仅为每个不同算法创建新 key, 还要在任何 key material 分发中包含算法选择, 并严格强制 key 结构中的算法与消息结构中的算法匹配. 除了检查算法是否正确外, 还需要检查 key form. 在预期使用 "OKP" key 的地方不要使用 "EC2" key.

在使用 key 进行传输之前, 或在基于收到的信息采取行动之前, 需要对该 key 作出信任决策. 与该 key 关联的实体是否有权查看这些数据或请求该动作? 这一信任决策涉及多个因素. 此处重点列出其中一些:

  • 与 key owner 关联的权限是什么?

  • 该加密算法在当前上下文中是否可接受?

  • 是否已经检查与该 key 关联的限制, 例如算法或 freshness, 且这些限制是否正确?

  • 考虑到应用当前状态, 该请求是否合理?

  • 作为消息一部分的任何安全考量是否已经被强制执行 (按应用或 "crit" 头参数指定)?

本文档给出了大量使用 nonce 值的算法. 对本文档中定义的所有 nonce, 都存在某种限制, 要求 nonce 对某个 key 或在某些其他条件下是唯一值. 在所有这些情况下, 没有已知要求要求 nonce 同时唯一且不可预测; 在这些情形下, 使用 counter 创建 nonce 是合理的. 如果希望 nonce 模式既不可预测又唯一, 可以使用为此目的创建的 key 加密 counter 来生成 nonce 值.

一个越来越受到关注的领域是基于消息长度对加密消息进行流量分析. 本规范未提供一种统一方法, 将 padding 作为消息结构的一部分提供. 对于本文档中定义的所有内容加密算法, 观察者都可以基于长度区分两个不同消息 (例如 "YES" 和 "NO"). 这意味着应用需要自行记录如何执行内容 padding, 以防止或阻碍此类分析. (例如, text string 可定义为 "YES" 和 "NO ".)

[RFC9147] 中的分析基于所发送 record 的数量. 使用 COSE 时, 这应能很好地映射到所发送消息的数量, 因此在假设 COSE 消息与 DTLS record 大小大致相同的情况下, 该分析在此也应成立. 需要注意, 这些限制基于消息数量, 但 QUIC 和 DTLS 的端点始终是成对的. 相比之下, [OSCORE-GROUPCOMM] 在群组通信场景中使用 COSE. 在这种情况下, 可能没有任何单一实体会看到所有被加密的消息, 因此没有任何单一实体能够触发 rekey 操作.

最后于 更新