2. 密钥生成合规：随机数生成器标准与密钥强度
密钥生成，是整个密码体系的起点。起点要是歪了，后面做得再漂亮也没用。我见过不少项目，算法选得挺高级，密钥长度也够，结果一查随机数生成器，用的是 rand()——嗯，那基本等于没锁门。
这一节，咱们就聊聊密钥生成合规的几个硬骨头：随机数生成器标准、密钥生成策略，以及算法与强度的选择。
2.1 随机数生成器标准：FIPS 140-2/3 与 AIS 20/31
随机数生成器（RNG）分两种：真随机数生成器（TRNG）和伪随机数生成器（PRNG）。合规审计里，这两者都要过标准。
2.1.1 FIPS 140-2/3 的要求
FIPS 140-2 和 140-3 是美国 NIST 发布的密码模块安全标准。140-3 是 140-2 的升级版，2020 年开始正式替代。我个人习惯直接对标 140-3，因为很多监管机构已经开始引用它了。
FIPS 140-2/3 对 RNG 的核心要求是：
- 连续性测试：每次生成随机数时，必须对输出进行实时检测，防止硬件故障或攻击导致输出固定值。
- 统计随机性测试：必须通过 NIST SP 800-22 规定的 15 项统计测试（如频数测试、游程测试、块内频数测试等）。
- 熵源健康测试：TRNG 的熵源必须定期做健康检查，确保熵的充足性。
关键点：FIPS 140-3 新增了对“熵源”的明确要求，不再像 140-2 那样只关注输出。审计时，如果只提供了 PRNG 的测试报告，没有熵源的健康数据，会被直接打回。
2.1.2 AIS 20/31 标准
AIS 20/31 是德国 BSI 的标准，在欧洲合规审计中非常常见。AIS 20 针对 PRNG，AIS 31 针对 TRNG。说实话，AIS 31 比 FIPS 140-3 还要严格一些。
| 标准 | 适用对象 | 核心要求 | 常见应用场景 |
|---|---|---|---|
| FIPS 140-2/3 | TRNG + PRNG | 统计测试 + 连续性测试 + 熵源健康 | 北美、全球金融、政府项目 |
| AIS 20 | PRNG (DRG.2/3/4) | 前向安全、后向安全、种子更新 | 欧洲银行、德国政府系统 |
| AIS 31 | TRNG (PTG.2/3) | 熵源建模、在线测试、物理攻击防护 | 高安全等级芯片、HSM |
我在做欧洲某银行项目时，客户明确要求 RNG 必须通过 AIS 31 PTG.3 等级。当时我们用的硬件熵源是环形振荡器，为了通过在线测试，光调整采样参数就花了三周。嗯，那段时间真是……印象深刻。
我的建议：如果你的产品要同时过 FIPS 和 AIS，优先选支持双认证的硬件 RNG 芯片。自己从头实现？除非团队有密码学博士，否则别碰。
2.2 密钥生成策略
有了合规的随机数，接下来就是怎么生成密钥。这里有几个策略层面的问题，审计时一定会被问到。
2.2.1 直接生成 vs. 派生生成
- 直接生成：从 RNG 直接输出密钥比特。优点是简单，缺点是每次生成都需要熵源参与，速度慢。
- 派生生成：用主密钥 + 密钥派生函数（KDF）生成子密钥。优点是速度快，且可以实现密钥分层管理。
合规审计中，派生生成更常见。为什么呢？因为很多标准要求密钥必须可更新、可撤销。如果每个密钥都是直接生成的，撤销一个就得重新跑一遍 RNG，管理成本太高。
2.2.2 密钥生成的生命周期控制
密钥生成不是“点一下按钮就完事”。合规要求你记录：
- 生成时间：精确到毫秒，且时间源必须同步 NTP。
- 生成者：哪个模块、哪个用户触发的。
- 生成参数：算法、长度、使用的 RNG 实例。
- 生成结果：密钥的哈希值（用于后续验证，不能记录明文）。
避坑指南：我曾经审计过一个项目，他们的密钥生成日志里记录了完整的密钥明文。理由是“方便排查问题”。这要是被监管看到，直接就是严重不合规。记住：日志里永远不能出现密钥明文，最多存个哈希。
2.3 密钥强度与算法选择
密钥强度不是越长越好，而是“够用且合规”。
2.3.1 算法与密钥长度的对应关系
不同算法对密钥长度的要求不同。我整理了一个常用对照表：
| 算法类型 | 算法示例 | 最低合规长度 | 推荐长度 | 安全等级 |
|---|---|---|---|---|
| 对称加密 | AES | 128 bit | 256 bit | 128-256 bit |
| 非对称加密 | RSA | 2048 bit | 3072 bit | 112-128 bit |
| 非对称加密 | ECC (P-256) | 256 bit | 384 bit | 128-192 bit |
| 哈希 | SHA-2 | 256 bit | 384 bit | 128-192 bit |
注意：RSA 2048 在 NIST SP 800-57 中只被认定为 112 位安全强度，到 2030 年之后可能不再被认可。我个人建议新项目直接上 ECC P-384 或 RSA 3072 以上。
2.3.2 算法选择的合规红线
有些算法已经被明确禁止或限制使用：
- DES：全面禁止。56 位密钥在现代计算能力下就是纸糊的。
- RC4：禁止。已知多种攻击方法。
- MD5 / SHA-1：禁止用于签名和证书。SHA-1 在 2017 年已被 Google 成功碰撞。
- RSA 1024：禁止。2015 年之后所有合规标准都不认。
一句话总结：对称密钥至少 128 位，推荐 256 位；非对称密钥 RSA 至少 2048 位，推荐 3072 位；ECC 至少 256 位，推荐 384 位。哈希至少 SHA-256。
2.4 知识体系结构图
下面这张图梳理了本章的核心逻辑：从随机数生成器标准出发，到密钥生成策略，再到算法与强度选择，最终落地到合规审计要点。
2.5 审计实战：检查清单
最后，分享一份我在审计中常用的检查清单。每次做密钥生成合规审计，我都会拿着这份清单逐项过：
- RNG 认证：是否持有 FIPS 140-2/3 或 AIS 20/31 认证？证书编号多少？是否在有效期内？
- 熵源健康：TRNG 的熵源是否做了健康测试？测试频率是多少？
- 统计测试：是否通过了 NIST SP 800-22 全部 15 项测试？测试报告在哪里？
- 密钥派生：如果用了 KDF，是否遵循了 NIST SP 800-108 或 SP 800-56C？
- 日志完整性：密钥生成日志是否包含时间、生成者、参数？是否加密存储？
- 算法合规：是否使用了禁止算法（DES、RC4、MD5、SHA-1、RSA 1024）？
- 密钥长度：是否满足最低长度要求？是否考虑了未来 5-10 年的安全余量？
一个小技巧：审计时别只看文档，要实际跑一遍 RNG 的测试代码。我遇到过文档写得漂漂亮亮，结果一跑测试，连续性测试直接挂掉的案例。嗯，那场面……客户脸色很精彩。