第3章 密钥生成审计：从熵源到密钥落地的全链路检查
密钥生成，说白了就是整个密钥生命周期的“出生证明”。这一步如果出了问题，后面所有的加密保护都是空中楼阁。我见过不少项目，密钥长度选了256位看起来很安全，结果随机数生成器本身就有后门——那你的密钥强度再高也白搭。
这一章我们聚焦四个核心问题：HSM到底怎么生成密钥的？随机数发生器靠不靠谱？算法和强度选对了没有？以及——审计日志记全了吗？
审计要点速览：
① 确认密钥只在HSM内部生成，永不明文出现
② 验证RNG通过了AIS-31或NIST SP 800-22测试
③ 检查密钥强度是否满足合规要求（如FIPS 140-3 Level 3）
④ 确保每次生成事件都有不可篡改的日志记录
3.1 HSM内部密钥生成机制
HSM生成密钥，和我们平常在软件里用OpenSSL跑个随机数完全是两码事。HSM的核心原则是：密钥的“原材料”和“生成过程”都必须待在硬件安全边界里，不允许以明文形式出现在外部总线上。
我检查过一款金融领域的HSM，它的密钥生成流程大致分四步：
- 熵源采集：从硬件噪声源（比如振荡器、热噪声）采集原始随机比特
- 去偏与蒸馏：通过硬件实现的DRBG（确定性随机数发生器）进行去偏处理
- 密钥材料组装：按照指定算法（AES、RSA、EC等）组装成密钥结构
- 安全注入：写入密钥槽或导出为加密后的密钥块
曾经有个厂商为了节省成本，在HSM里用了一个伪随机算法代替真正的硬件熵源。审计时我抓了100万条生成日志做随机性测试，发现周期性的重复模式——所有“随机”密钥其实都是可预测的。这种问题在HSM层面出现，基本就是致命级漏洞。
审计时我习惯逐项核验以下机制：
| 检查项 | 合规要求 | 常见违规 |
|---|---|---|
| 密钥生成位置 | 仅在HSM硬件内部完成 | 密钥在CPU内存中明文拼接 |
| 关键参数来源 | 使用硬件熵源，不依赖外部种子 | 通过API传入种子值 |
| 密钥导出保护 | 导出时必须加密，且受密钥包装策略控制 | 允许明文导出测试密钥 |
| 生成过程中密钥复用 | 每次生成独立密钥，禁止缓存 | 同一密钥被多次“生成” |
3.2 随机数生成器（RNG）审计方法
RNG是密钥生成的根基。根基不稳，上面盖的房子再漂亮也没用。我个人的习惯是，审计RNG时分开看两件事：熵源质量和DRBG实现。
3.2.1 熵源质量审计
HSM用的熵源通常是物理噪声源。你需要检查：
- 熵源多样性：是不是有多个独立噪声源？我之前见过一个HSM只有一个热噪声通道，结果温度稳定时熵输出骤降。
- 熵值评估报告：要求厂商提供NIST SP 800-90B的熵值评估结果，min-entropy不得低于声称值。
- 在线自检机制：HSM是否在每次上电或周期性执行熵源健康测试？
小技巧：很多HSM会提供“自检向量”功能，你可以要求它在自检模式下输出一段已知的随机数序列，然后独立验证其统计特性。我在一次验收测试中就用这招发现了一个熵源漂移的问题。
3.2.2 DRBG实现审计
DRBG的审计重点在于算法选择和状态管理。目前主流HSM支持的DRBG算法包括：
| DRBG算法 | 标准依据 | 审计要点 |
|---|---|---|
| Hash_DRBG | NIST SP 800-90A | 使用的哈希函数强度、种子生命期 |
| HMAC_DRBG | NIST SP 800-90A | 密钥更新频率、熵源重播种机制 |
| CTR_DRBG | NIST SP 800-90A | 计数器回绕处理、加密算法模式 |
| 符合AIS-31的物理RNG | BSI AIS-31 | 在线测试覆盖率、故障响应 |
审计时我会特别关注重播种机制。你想想看，如果一个DRBG长时间不更新种子，理论上输出序列的可预测性就会增加。我记得有次审计一个支付HSM，它的CTR_DRBG竟然连续生成了2^32个随机数才重播种一次——虽然合规，但我觉得风险太高，要求改成了每10万次重播种。
3.2.3 统计测试验证
不管厂商给什么报告，我建议你亲自跑一轮统计测试。常见的测试套件有：
- NIST SP 800-22：包含15项测试，如频率测试、游程测试、块内频数测试等
- Dieharder：更严苛的测试集，适合发现隐蔽的弱随机性
- TestU01：学术级测试，适合高安全场景
实操上，你只需要从HSM导出一段随机数样本（通常需要1~10Mbits），然后用测试工具跑一遍。不过要注意——有些HSM的“随机数导出”功能本身可能被策略禁用，你得先确认审计策略允许这么做。
3.3 密钥强度与算法选择审计
密钥强度不是越长越好，而是“匹配场景、符合标准”。我见过有人在HSM里生成1024位的RSA用于生产环境——按现在的标准，这已经属于弱密钥了。
3.3.1 密钥长度检查
目前各主流标准的最低要求如下：
| 算法 | FIPS 140-3最低要求 | 商用推荐（2025年） |
|---|---|---|
| AES | 128位 | 256位 |
| RSA | 2048位 | 3072位 |
| ECDSA | P-256 | P-384 或 P-521 |
| HMAC | 密钥 ≥ 112位 | 密钥 ≥ 256位 |
注意：有些HSM允许你生成低于标准长度的密钥“为了兼容旧系统”。作为审计方，你要确认这种操作是否被策略禁止、是否有审批流程、是否留下了合规日志。
3.3.2 算法合规性
除了长度，算法本身也得在合规清单上。我审计时会逐项核验：
- 算法是否在FIPS 140-3的Approved算法列表中
- 是否使用了已废弃的算法（如RC4、MD5、SHA-1用于签名）
- 密钥用途是否与算法匹配（比如用EC密钥做RSA操作，这就出问题了）
- 曲线参数是否来自标准规范（禁止使用自定义曲线）
3.3.3 强度审计实操步骤
嗯，这里我一般按以下流程走：
- 获取密钥清单：从HSM导出所有密钥的元数据（算法、长度、用途、生成时间）
- 对照合规矩阵：用公司的密钥策略文档逐条比对
- 标记异常项：标出弱密钥、过期算法、用途不匹配等
- 追溯生成记录：回查密钥生成时的审批单和日志
补充一点：密钥强度审计不是一次性工作。我建议每季度或者每次HSM固件升级后都重新检查一遍，因为合规标准在变，你的密钥库也需要跟着升级。
3.4 生成日志记录要求
最后来看日志——这一块经常被低估，但审计时如果日志不全，前面所有工作都等于白做。
3.4.1 必须记录的内容
按照PCI HSM和FIPS 140-3的要求，每次密钥生成至少需要记录：
| 字段 | 说明 | 审计验证方法 |
|---|---|---|
| 时间戳 | 精确到毫秒的UTC时间 | 与HSM系统时钟进行比对 |
| 操作员ID | 执行生成操作的用户或角色 | 检查是否与认证系统一致 |
| 密钥类型与算法 | AES-256、RSA-2048等 | 与密钥元数据交叉验证 |
| 密钥用途 | 加密、签名、密钥包装等 | 检查是否超出授权范围 |
| 密钥标识符 | HSM内的唯一ID | 确认该ID在密钥库中可追溯 |
| 生成结果 | 成功/失败 + 错误码 | 失败记录是否有对应处理流程 |
| 审计日志哈希 | 日志条目的完整性校验值 | 用HSM的审计公钥验证签名 |
3.4.2 日志的不可篡改性
我最看重这一点。HSM的审计日志必须做到写后不可改。具体来说：
- 每条日志应该有一条哈希链（chained hash），前后相互校验
- 日志存储区应该受到HSM硬件写保护，不能通过管理接口删除或修改
- 建议开启远程审计日志同步，实时备份到外部的SIEM系统
我遇到过的情况：某次审计发现日志记录中有30秒的时间断层。后来查出来是HSM的日志缓冲区满了之后开始覆盖旧记录。虽然HSM官方说“很少会发生”，但在生产环境里“很少”不等于“不会”。最终我们升级了日志存储方案，改为环形缓冲+远程实时同步。
3.4.3 日志审计的抽样策略
如果你管的是一个大型HSM集群，日志量可能大得吓人。我不建议逐条检查，而是按风险分层抽样：
- 高优先级：密钥生成失败记录、使用弱算法的记录 → 100%检查
- 中优先级：新密钥生成记录（特别是高权限角色执行的） → 按10%~30%抽样
- 低优先级：常规密钥生成、测试环境记录 → 按1%~5%抽样
抽样时我会随机选一些记录，然后追溯到HSM内部的实际密钥元数据，确认日志记录和实际情况一致。
我曾经踩过的坑：有些HSM的日志时间戳用的是本地时间，而不是UTC。结果跨时区审计时时间线完全对不上。从那以后，我每到一家客户，第一件事就是检查HSM的时间同步配置——NTP必须启用，而且只能指向内部可信时间源。
密钥生成审计不是一锤子买卖。它是持续性的合规活动，需要你定期检查、不断更新审计标准。嗯，这一章的内容就到这里，核心就是四个字：源头可控。