摘要

  • RFC 9709 将内部内容加密 AlgorithmIdentifier 的完整 DER 编码——包括参数——与原内容加密密钥一起输入 HKDF。
  • 改写认证加密的算法标签或参数会使接收端派生出另一把密钥，攻击者因而得不到有用的 CBC 明文预言机。
  • 这项控制抵御的是一种机密性转换攻击；它不证明发送者身份、内容安全性，也不授予后续业务行动权限。

真正被攻击的是“解释方式”

传统直觉把算法标识符看成密钥旁边的说明书。LAMPS 工作组研究的攻击说明，这份说明书本身也可能成为攻击面：拦截者取出由 AES-GCM 或 AES-CCM 保护的 CMS 内容，把选定密文块重新包装为 AES-CBC 内容，再诱使持钥系统处理。攻击者没有获得密钥，而是利用接收端返回的明文、解析结果或行为差异验证对低熵结构化数据的猜测。

这不是对任意邮件都立即奏效的万能解密术。IETF 118 的演示指出，常规 S/MIME 邮件可能只会变成明显乱码，应用也可能先拒绝损坏的头部，当时更无法确认哪些已部署系统真实易受影响。然而，这些是具体应用环境里的摩擦，不是可依赖的密码学边界。另一种 CMS 工作流也许会显示字段、生成回执、触发解析器或改变自动化状态，足以把猜测变成信息。

RFC 9709 因此不只认证算法名称，而是把解释密文所需的精确编码绑定到密钥。接收者先在 S/MIME 能力中宣告 id-alg-cek-hkdf-sha256，该宣告的参数必须缺省。发送者启用缓解措施时，外层 contentEncryptionAlgorithm 使用这个 OID；其必需参数承载真正的内部内容加密 AlgorithmIdentifier，其中包含算法及其参数。

随后双方用 HKDF-SHA-256 派生工作密钥 CEK-prime。原内容加密密钥作为输入密钥材料；盐值固定为 ASCII 字符串“The Cryptographic Message Syntax”；HKDF 的 info 是内部算法标识符的完整 DER 编码，包括序列标签、长度、OID 与编码参数。输出长度与原密钥相同，受 SHA-256 HKDF 的 8,160 字节上限约束。

精确到字节才是安全性质。把 GCM 换成 CBC、更改初始化向量或改动任何编码参数，接收端就会得到不同密钥。为原密钥制作的密文，无法在攻击者指定的新解释下提供有用试验。如果攻击者干脆删除外层缓解 OID，接收端会使用原密钥而非 CEK-prime；消息将无法访问，但仍不会吐出受保护明文。这里发生的是可用性损失，而非机密性失守。

不能用一个“解密成功”概括七层事实

生产证据至少要分清七件事：接收端是否宣告能力；发送端是否真的选择外层缓解 OID；内部算法及参数究竟是什么；派生时是否使用原样 DER 字节；内部模式要求的认证解密和附加数据验证是否成功；是否有明文、解析产物或行为信号越过信任边界；最终又是哪条策略允许保存、显示、转发或触发业务动作。

把这些压缩成一个“成功”状态，会同时遮蔽兼容故障和篡改企图。反过来，能够解析或解密也不构成来源证明。RFC 9709 是密钥分离机制，不是数字签名、信誉系统、恶意内容检测器或业务授权。

认证属性也要单独看待。RFC 9709 警告，未加密的消息摘要属性可能帮助观察者确认明文猜测；加密的陌生来信也可能绕开专为垃圾邮件或网络钓鱼设置的检测。只允许已批准来源是一种可选补偿政策，但它回答的是“是否接收该发送者”，不是“算法身份是否绑定”。

最小公共规则，端点本地验证

该规范固定使用 SHA-256，而没有引入可协商的 KDF 菜单；未来若更换散列函数，应分配新的对象标识符。这让公共规则保持窄而确定：识别外层结构，保留内部精确编码，派生密钥，再按内部算法完成认证或解密。

普通密钥卫生并未因此消失。内容加密密钥仍须由高质量随机源生成并妥善保护。RFC 5652 的 CMS 结构、RFC 5083 的认证信封数据、RFC 5084 的 AEAD 约定、RFC 5869 的 HKDF、RFC 8551 的 S/MIME 能力以及 RFC 4086 的随机性指导，仍是彼此独立的依赖。弱密钥、失陷端点或虚假发送者身份，不会因 RFC 9709 而自动可信。

本次核查时，RFC Editor 的勘误检索未显示 RFC 9709 的已报告勘误；IANA 的 SMI 注册表也记录了相应模块与算法编号。这些事实证明标准协调状态，却不能代替对真实部署行为的测量。

来源