第3章：密钥生成策略与审计点归纳总结
密钥生成，说白了就是怎么安全地“造”一把锁。这把锁要是造得有问题，后面所有安全措施都是白搭。我在PCI DSS审计项目中看过太多案例，问题根源往往就出在“造锁”这一步。
3.1 密钥生成的核心原则
还记得PCI DSS的要求吗？密钥必须用强加密算法生成。但光有算法还不够。我总结了三要素，你想想看，缺一个都不行：
- 随机性——密钥不能被预测。伪随机数生成器（PRNG）要是种子泄露，整个密钥体系就完了。
- 唯一性——每个密钥只能用于一个目的。加密密钥和数据加密密钥必须分开。
- 强度——密钥长度要够。AES-128是底线，但我个人习惯推荐AES-256。
审计关注点：检查你的密钥生成工具是否经过了FIPS 140-2验证。没有？那审计基本过不去。
3.2 三种主流生成策略
| 策略类型 | 原理 | 典型场景 |
|---|---|---|
| 硬件安全模块（HSM）生成 | 在防篡改硬件内生成密钥 | 银行、支付网关等高安全环境 |
| 软件类库生成 | 使用经认证的加密库生成 | 一般应用服务器、开发环境 |
| 密钥协商派生 | 通过Diffie-Hellman等协议派生 | TLS握手场景 |
我在项目中遇到过一种情况：客户为了省钱，直接用openssl rand生成了主机密钥。但问题是这个命令没有指定硬件随机源，生成的密钥质量根本不行。
避坑指南：我曾经见过一个电商平台，他们用Java的
SecureRandom直接生成DEK，但由于JVM的熵池初始值不够，前100次调用生成的密钥几乎一样。审计时一下子就抓出来了。
3.3 密钥生成的时间与频率
密钥不是一次生成用一辈子的。PCI DSS要求定期更换。但什么时候换？怎么换？这是审计的重点。
- 初始部署——系统上线时必须首先生成根密钥
- 定期轮换——至少每12个月一次（我个人建议每半年）
- 泄密后立即更换——不解释，这是铁律
- 人员变动后——知道密钥的人离职了，相关密钥必须换
3.4 代码示例：合规的密钥生成
嗯，这里要注意。我们看看一个相对合规的生成方式。这不是唯一方式，但能通过大部分审计检查：
import java.security.KeyPairGenerator;
import java.security.SecureRandom;
// 必须从硬件随机源获取种子
SecureRandom sr = SecureRandom.getInstanceStrong();
KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
kpg.initialize(2048, sr);
KeyPair kp = kpg.generateKeyPair();
// 生成的密钥必须立即标记用途
// 比如：k1用途=加密主密钥，k2用途=会话密钥
这里有个坑。SecureRandom.getInstanceStrong()在某些Linux上可能会阻塞，因为熵池不够。我个人建议生产环境配上硬件随机数生成器。
3.5 审计关键点：五维检查法
做审计的时候，我主要查五个维度。你对照这个清单去查，基本不会漏：
- 来源检查——密钥是从HSM生成的，还是普通服务器？
- 算法检查——符合FIPS 140-2要求的算法列表吗？
- 长度检查——RSA至少2048位，AES至少128位
- 日志检查——生成操作记录了吗？谁做的？什么时间？
- 回收检查——生成失败的密钥碎片处理了吗？
实用技巧：检查日志的时候，看看有没有密钥生成失败的记录。生成失败通常意味着随机源有问题或者熵池耗尽，这是安全事件。我遇到过一例，系统日志里全是"Failed to generate key"警告，但运维团队没当回事。后果？三个月后密钥空间被彻底攻破。
3.6 密钥生成审计的常见失败模式
| 失败模式 | 风险等级 | 审计发现示例 |
|---|---|---|
| 使用弱随机数生成器 | 高 | Random()函数生成密钥 |
| 密钥硬编码在代码里 | 高 | 源码中发现密钥字符串 |
| 密钥生成没有访问控制 | 中 | 生成脚本所有人可执行 |
| 不记录生成操作 | 中 | 审计日志中没有相关事件 |
为什么业界这么强调这一点？因为一旦密钥生成出了问题，整个信任链就断了。加密再强，密钥本身是弱的那就是纸老虎。
3.7 本章知识脉络总结
下面这张图展示的是密钥生成策略与审计的核心逻辑。你可以把它当成检查清单来用：