HKDF 的 FIPS 合规性

HKDF 是 RFC 5869 中指定的基于 HMAC 的密钥派生函数,我们通常喜欢使用它。FIPS 是美国国家标准与技术研究院发布的标准、建议和指南的统称,更具体地说,是关于加密模块验证的 FIPS 140 标准。许多监管设置(如 FedRAMP)要求符合 FIPS 140,这常常限制了我们使用某些功能。

今年早些时候,作者决定为 Go 加密标准库追求 FIPS 140 - 3 验证,同时保留尽可能多的好东西,并深入研究允许和不允许的细节。

FIPS 合规的 HKDF 是一个有些令人困惑和有争议的话题,部分原因是规范参考分散在至少四个单独的文档中,但实际上它几乎可用于任何目的。

[NIST SP 800 - 133 Rev. 2]讨论了对称密钥的派生,提出了两类密钥派生方法:一步 KDF 和两步提取 - 然后扩展密钥派生程序。

HKDF 作为密钥协商的一部分

在密钥协商的情况下,[NIST SP 800 - 56C Rev. 2]提出了两步密钥派生,当用 HMAC、空 IV 和反馈模式 KDF 进行扩展时,等同于 HKDF。盐可以协商、固定值或全零,使用一个提取步骤的输出进行多个扩展操作是明确批准的,输入密钥材料可以与其他值连接。HKDF 作为密钥协商的一部分可以作为“KDA HKDF Sp800 - 56Cr2”进行 CAVP 测试。

HKDF 作为通用 KDF

之前作者认为 HKDF 仅允许作为密钥协商的一部分,实际上并非如此。

HKDF - Expand 作为 SP 800 - 108 KDF

HKDF - Expand 本身是 [NIST SP 800 - 108 Rev. 1 Upd. 1]的一种模式,定义了批准的通用 KDF。ACVP 测试证明 HKDF - Expand 是 SP 800 - 108 的批准版本,但使用时 FIPS 140 加密模块需要在其证书中包含 SP 800 - 108 反馈 KDF。

HKDF - Extract

[NIST SP 800 - 133 Rev. 2]新增了一种方法,称为“密钥提取过程”,即 HKDF - Extract,它允许使用单个密钥作为输入。但有一个限制,即至少一个输入密钥必须由 DRBG 生成。

总结

如果进行密钥协商,可以使用 SP 800 - 56C Rev. 2 中的 HKDF 或 IG D.P 中的 HKDF - Extract;如果不进行密钥协商,可以使用 SP 800 - 133 Rev. 2(第 6.3 选项 #3)中的 HKDF - Extract 组合随机生成的密钥与其他密钥和/或数据,并使用 SP 800 - 108 中的 HKDF - Expand 作为通用 KDF。使用批准的算法只是合规的一半,还需要使用经过验证的模块。

作者的维护工作由 Geomys 客户资助,如 Latacora、Teleport、Ava Labs、SandboxAQ、Charm 和 Tailscale 等。

脚注:

  1. 为简单起见省略了与 HKDF 不相关的 SP 800 - 135 KDF 和 SP 800 - 132 基于密码的 KDF。
  2. 难以确定是类似 ML - KEM 的密钥协商还是密钥传输,可能需要等待 SP 800 - 227 以获得最终答案。
  3. https://github.com/usnistgov/... - Server/tree/master/gen - val/json - files 中的“HKDF - 1.0”含义不明。
阅读 18
0 条评论