摘要
- RFC 3537 在 HMAC 密钥前放入一个长度字节,再补上 3DES 或 AES 封装路径所需的随机填充。
- 解封成功可以恢复原始字节,但完整性检查本身不能说明 HMAC 算法、获准用途或报文来源。
设想邮件网关打开一个 CMS AuthenticatedData 报文。发给某个接收方的密钥受到保护;接收方系统解封后,得到了精确的一串字节。封套完成了它的工作。但这个结果究竟证明了什么?它回答的是一个有限的问题:该表示是否通过相应密钥封装算法的完整性检查?仅凭解封成功,系统还不知道应由哪种哈希函数使用这些字节、当前服务是否有权使用它、哪一方把它放进报文,或者这份内容现在是否仍然有效。
RFC 3537 的历史意义就在于划出这条边界。它于 2003 年 5 月以 IETF Standards Track Proposed Standard 发布,由 S/MIME 工作组推动,目的是把既有 3DES 和 AES 封装方法适配到长度和奇偶校验属性不符合旧格式假设的 HMAC 密钥。文档将 CMS AuthenticatedData 列为一种应用。它是密钥传输机制,不是完整的授权或来源证明格式。
一个字节计数,然后是密钥
两种方案都从 LENGTH || KEY 开始。LENGTH 是单字节,后面跟随相应数量的密钥字节。接着加入最少数量的随机填充,使整个记录达到 8 字节边界。因此,引言所说的“任意长度”,意思是密钥不必符合旧封装方案要求的固定尺寸;它并未把单字节字段变成无界计数器。RFC 3537 也没有替具体应用规定一个密钥最大长度。
填充不是游离在封套之外的注释。它属于被封装的表示,并由对应的完整性机制一并保护。解封时,接收方先检查对象完整性,再拆分长度、密钥和剩余部分;若填充超过 7 字节,就应拒绝。这样接收方无需猜测密钥在哪里结束。但这些随机字节不携带语义标签:它们不会说明“此密钥供这个客户的审计记录使用 HMAC-SHA-256”,也不会说明“有效期到下一次轮换为止”。
两条继承而来的保护路径
RFC 3537 没有创造一个适用于两种方案的统一密码变换。3DES 路径沿用 RFC 3217 的封装构造,考虑到 HMAC 密钥不受 3DES 奇偶校验约束,加入 8 字节校验值,并在最终固定 IV 步骤之前使用随机初始化向量。AES 路径则在加入长度和填充记录后,复用 RFC 3394 的 AES Key Wrap 算法。AES 的完整性值与 3DES 校验和不是可以互换的细节;它们各自依附于不同的构造。
因此,RFC 3394 中的 64 位 A 寄存器仍是另一个独立主题:它在 AES 变换的多轮计算中混入状态,并在释放候选明文前接受检查。RFC 3537 讨论的是围绕该算法构造的 HMAC 密钥封套:如何把可变长密钥编框,以便封装和恢复。此前 RFC 3058 的文章也保留其独立边界,讨论 IDEA 密钥封装、能力信息和校验和。RFC 3217 是 3DES 分支的背景,不是本文的论点。
算法标识符还呈现出另一层区分。RFC 3537 分别为 3DES 和 AES HMAC 密钥封装分配了 OID,并要求 NULL 参数。这些名称告诉 CMS 处理方,封套采用哪种封装操作;它们并不标识恢复后的密钥要供哪种 HMAC 摘要算法使用。RFC 2104 讨论 HMAC 密钥,RFC 3537 的 OID 讨论封套。把二者当成同一件事,就把两个协议层压成了一个。
完整性为真,来源仍可能未知
安全考量要求保护 KEK,并警告:KEK 一旦失陷,所有由它封装的 HMAC 密钥都可能泄露。接下来还有一个更微妙的限制:封装函数提供机密性和数据完整性,但不一定提供数据来源认证。任何持有 KEK 的人都能创建一个通过完整性检查的报文。若还要认证数据来源,KEK 的分发机制就必须认证其来源;或者可以使用数字签名。
这并不是说算法未能完成其规定的检查,而是在界定检查所能证明的范围。如果系统把“解封成功”解释为“预期授权方已批准此密钥用于这项操作”,它就把一种证明能力加到了封套并未承载的凭据上。对象可能格式正确且完整,但其来源、用途或授权仍未得到证明。
修正记录,不是修改算法
RFC Editor 的已验证编辑性勘误 254 修正了第 3.4 节 3DES 测试向量中的一个数值:PAD 行应为 be62fe,而非 38be62。修正后的值与紧接着的 LKEYPADICV 行所示字节一致。这是对已发布测试向量的编辑性修复,不是封装步骤的更改,也不是生产环境发生密码学故障的证据。
更广泛的教训属于架构,而非算法。系统可能需要一把可恢复的密钥,但仍需另行保存经过认证的证据,说明其摘要算法、预期操作、主体、来源和有效期。签名清单或协议专用的认证上下文可以承载这些决定;不能把封套没有编码的字段强加给它。RFC 3537 划定了一条有用的传输边界。系统保留这条边界,审计才有依据。
来源
- RFC 3537 — HTML
- RFC 3537 — 纯文本
- RFC Editor — RFC 3537 记录
- IETF Datatracker — RFC 3537
- IETF Datatracker — 文档历史
- RFC 3537 勘误查询
- RFC Editor — 已验证勘误内嵌版
- RFC 2104 — HMAC
- RFC 3217 — Triple-DES 与 RC2 密钥封装
- RFC 3394 — AES 密钥封装
- RFC 5652 — Cryptographic Message Syntax
- RFC 6031 — CMS Key Package 内容类型
- RFC 4868 — IPsec 中的 HMAC-SHA-256/384/512
- RFC 5649 — 带填充的 AES 密钥封装
- NIST SP 800-38F — 密钥封装方法
- IANA — SMI Numbers 注册表
- Heng Lu — Running Code Is Primary
- Heng Lu — On Reality Layers
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance
