12. 安全考虑事项

12. 安全考虑事项

本规范的实现者需要考虑若干安全事项. 虽然这里重点说明了一些考虑事项, 但在参考文献列出的文档中还可以找到其他考虑事项.

实现需要保护所有个人的私钥材料. 关于这一问题, 本文档中的一些情形需要特别指出.

• 将同一密钥用于两个不同算法可能泄露有关该密钥的信息. 因此建议将密钥限制为仅用于单个算法.

• 将 "direct" 用作 recipient 算法并与第二个 recipient 算法组合, 会把 direct 密钥暴露给第二个 recipient; Section 8.5 禁止将 "direct" recipient 算法与其他模式组合.

• [RFC9053] 中的若干算法对密钥在不泄露密钥信息的情况下可使用的次数有限制.

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

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

在使用密钥进行传输之前, 或在根据收到的信息采取行动之前, 需要对密钥做出信任决策. 数据或操作是否是与该密钥关联的实体有权查看或有权请求的? 许多因素与此信任决策相关. 这里重点列出一些:

• 密钥所有者关联了哪些权限?

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

• 是否已经检查与密钥关联的限制, 例如算法或新鲜度, 并且这些限制是否正确?

• 根据应用当前状态, 该请求是否合理?

• 消息中作为安全考虑事项的一部分是否已被强制执行 (按应用或 "crit" header 参数指定)?

一个逐渐受到关注的领域是基于消息长度对加密消息进行流量分析. 本规范未提供一种统一方法, 用于在消息结构中提供填充. 对于 [RFC9053] 中定义的所有内容加密算法, 观察者都可以基于长度区分两条不同消息 (例如 "YES" 和 "NO"). 这意味着应用需要自行记录如何进行内容填充, 以防止或抑制这类分析. (例如, 可以将文本字符串定义为 "YES" 和 "NO ".)