4. 加密算法合规性：AES、RSA、ECC、SHA 等算法的 FIPS 认可列表与实现要求
这一章我要跟你聊聊加密算法的 FIPS 认可问题。你想想看，审计的时候最怕什么？我最怕那种「算法库全上了 FIPS 标记，但一检查实现细节就露馅」的情况。说白了，光有合法名字不行，得看它是不是真的按 FIPS 规定的方式干活。
我们先分清两个概念：算法标准 和 模块实现。NIST 发布 FIPS 标准（比如 FIPS 197 定义 AES），但真正要审计的是 实现了该算法的密码模块 是否通过了 CMVP（密码模块验证计划）认证。我曾在一次政府项目审计中，发现对方声称使用了「FIPS 认可的 AES」，结果查 CMVP 列表根本没有那个 vendor 的模块编号…… 踩过这个坑之后，我养成了一个习惯：验证算法合规性，一定先查 NIST 的 CMVP 数据库。
4.1 AES 的 FIPS 认可要求
AES 的依据是 FIPS 197。但审计时不只看算法名字，还要看 工作模式。为什么？因为 FIPS 140-3 IG (Implementation Guidance) 明确规定了哪些模式被允许。我个人习惯把可接受模式背下来：ECB, CBC, CFB, OFB, CTR, GCM, CCM, XTS。不过你注意了，ECB 虽然标准认可，但安全性审计时通常会被要求避免使用 —— 除非你能在安全策略里解释清楚为什么要用。
我在一次银行项目里遇到过供应商只实现了 AES-128-CBC，但审计要求 AES-256-GCM。结果不得不紧急补一个 GCM 模块，重新跑 ACVTS 测试…… 折腾了大半个月。所以建议你提前确认 密码模块支持的 AES 模式列表 是否覆盖业务场景。
关键审计点：
- CMVP 证书中列出的 AES 工作模式是否满足安全策略需求？
- 密钥大小：128/192/256 位必须在模块的安全边界内实现，且与 FIPS 140-3 安全级别对应。
- 如果使用 GCM 模式，必须检查 nonce 长度 和 加解密上下文绑定 是否符合 SP 800-38D。
4.2 RSA 与 ECC 的合规门槛
非对称算法的 FIPS 标准是 FIPS 186-5（数字签名标准，DSS）。这里面同时涵盖了 RSA 和 ECDSA。嗯，这里有个常见的误区：有人以为只要算法是 RSA 或 ECC 就算合规。其实不对。
你想想看，FIPS 186-5 规定了 密钥长度对应的安全强度。比如 RSA 至少 2048 位，ECC 至少 224 位（曲线 P-224）。我见过一份审计报告里发现 ECC 用了 secp192r1（即 P-192），虽然算法本身是合法的，但因为密钥长度不满足 2023 年后的安全强度要求（NIST SP 800-57 建议），直接被开了一个 Major Finding。
另外，ECC 的 曲线选择 也很关键。FIPS 认可的曲线只有 NIST 的 P-224、P-256、P-384、P-521，以及 K-233、K-283、K-409、K-571（K 系列）和 B-233、B-283、B-409、B-571（B 系列）。Brainpool 曲线、Curve25519 目前 不在 FIPS 认可列表内。虽然 NIST 正在评估后量子算法替代方案，但现阶段审计还是要按这张旧表来。
| 算法 | FIPS 标准 | 最小密钥长度 | 允许的曲线/参数 |
|---|---|---|---|
| RSA | FIPS 186-5 | 2048 位 | n 为两个安全素数的乘积，e 与 φ(n) 互质 |
| ECDSA | FIPS 186-5 | 224 位 | P-224, P-256, P-384, P-521 (NIST 曲线) |
| ECDH | NIST SP 800-56A Rev.3 | 224 位 | 同 ECDSA 曲线 + 基点和阶数验证 |
| DSA | FIPS 186-5 | 2048 位 / 256 位 (L,N) | L=2048, N=256 或 L=3072, N=256 |
我曾经踩过的一个雷：在一次金融系统审计中，对方使用了 ECDH 密钥协商，但模块只实现了 SP 800-56A 中规定的 基础 DH，没有实现 C(0e, 2s) 方案（即 static-ephemeral 组合的密钥确认步骤）。结果导致审计失败。ECDH 的合规不仅仅是算法计算，还包括 密钥协议方案步骤 必须完整。
4.3 SHA 哈希算法的认证细节
哈希部分参考 FIPS 180-4（SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256）和 FIPS 202（SHA-3 系列：SHA3-224 到 SHA3-512, 以及 SHAKE128/256）。
这里有个实际注意点：SHA-1 已经被 NIST 正式弃用（2022 年之后不再允许用于数字签名和证书）。但你可能想知道，为什么审计时还会看到它？因为有些老模块为了向后兼容，仍然保留了 SHA-1 的实现。FIPS 140-3 IG 允许 SHA-1 仅用于 验证遗留签名，而不能用于生成新签名。我在检查一个 VPN 网关时，就发现它在 IKE 重协商时用了 SHA-1 计算 HMAC，这直接违反了审计要求。
一个小技巧：审计时直接查看密码模块的 Security Policy 文件中的 算法列表表格。CMVP 证书里会明确列出每个算法适用的操作（生成、验证、密钥派生等）。如果列表中有 SHA-1，看它后面标注的「allowed for verification only」还是无限制。没有标注就是有问题。
SHA-3 目前使用量不大，但我个人建议你留意 SHAKE 可扩展输出函数 (XOF)。FIPS 202 允许 SHAKE128 和 SHAKE256，它们通常用于密钥派生和随机位生成。不过，大多数商用模块对 SHA-3 的支持还不够成熟，我在 2024 年见过的通过 CMVP 认证的 SHA-3 模块不超过 20 个。如果你遇到 SHA-3 需求，一定要确认 模块的 ACVTS 测试记录 中包含了 SHA3-256 或 SHAKE256 的测试向量。
4.4 实现要求——不仅仅是算法本身
FIPS 合规审计的残酷之处在于：你只实现了正确的算法还不够，还要满足 实现层面的约束。我把它归纳为三个检查层：
- 算法正确性层：必须通过 CAVP (Cryptographic Algorithm Validation Program) 测试，即 ACVTS 测试向量验证。每一个模式、密钥大小都必须有对应的测试记录。
- 模块安全层：算法必须运行在 FIPS 140-3 认证的密码模块内（硬件或软件）。软件模块的边界包括 OS 保护、密钥分离、错误状态处理等。
- 使用策略层：算法不得以不安全的方式被调用。比如不能同时使用同一个 AES 密钥在同一模块内进行加密和签名（违反分离策略），或者将 CBC 模式的 IV 设为固定值。
我刚入行时觉得第三层有点吹毛求疵。直到有一次审计，发现一个通信模块在重启后初始化 AES-GCM nonce 为全零 —— 虽然算法本身通过了 ACVTS，但 nonce 复用直接导致密钥泄露风险。那一次审计被我亲手开了一个 Critical Finding。
所以你看，FIPS 算法合规性不是检查一下名字就完事。你需要在 CMVP 网站 上逐个核对模块的 Security Policy，确认每一类算法、每一种操作、每一个密钥长度都落在许可范围内。然后，还要在系统级测试中验证 实际行为与策略描述一致。
审计自查清单（4 项）：
- ☑ 目标模块是否已在 CMVP 列表中？（查模块编号）
- ☑ 使用的算法（含模式、密钥长度）是否在模块证书的 Approved Security Function 表内？
- ☑ 对于 RSA/ECC，密钥生成是否在模块内部完成？不允许外部导入未验证密钥。
- ☑ 如果使用 SHA-1，确认仅用于验证已知签名，不得用于新签名或 MAC。
总结一下：算法合规是审计最基础也最容易出大坑的地方。你先拿 CMVP 证书开道，再用安全策略表格仔细比对，最后不能放过任何实现层面的细节。能做到这三点，至少这一步不会翻车。