第3章 密钥生命周期管理
说起密钥管理，很多团队第一反应就是“生一个密钥，用到天荒地老”。
但我做过十几个HSM集成项目，几乎每个项目都在生命周期某环节出过问题。说白了，密钥从生成到销毁，每一环都有坑。今天我把五个阶段——生成、存储、使用、轮换、销毁——拆开讲透。
3.1 密钥生成
密钥生成是起点，也是最容易被轻视的一步。
HSM内部生成密钥时，随机数质量决定安全性。我曾经遇到一个项目，客户图省事用软件RNG生成种子再灌入HSM，结果被审计发现随机性不达标，整个项目重做。
C_GenerateKey 或等价API，利用硬件真随机数发生器（TRNG）生成主密钥。避免外部带入种子。生成策略要考虑以下几点：
- 算法与长度：AES-256、RSA-4096、ECC P-384等，按合规要求选
- 密钥类型：对称/非对称、签名/加密/派生区分清晰
- 标签与元数据：每个密钥必须关联唯一标识、用途、有效期
- 属性标记：不可导出、敏感、可轮换等标志位
3.2 密钥存储
存储阶段，HSM的核心优势是“密钥永不离硬件”。
实际项目中，很多客户为了省钱把密钥存在文件里再用密码加密，结果密码被泄露照样完蛋。
下表对比了主流存储方式：
| 存储方式 | 安全等级 | 性能 | 典型场景 |
|---|---|---|---|
| HSM内部（不可导出） | 极高 | 中 | 根密钥、CA密钥 |
| HSM内部（可导出加密包装） | 高 | 中 | 备份到其他HSM |
| 外部加密存储（密钥加密密钥KEK由HSM保护） | 高 | 低 | 大量会话密钥 |
| 明文文件 | 极低 | 高 | 严禁用于生产 |
3.3 密钥使用
使用阶段，重点在于控制谁、什么时候、用什么方式调用密钥。
我记得有个金融客户，应用程序通过TCP直接连HSM，每次请求都传明文密钥句柄，结果让攻击者利用调试接口拿到了句柄映射表。
正确的做法是：
- 通过HSM会话建立安全通道（TLS或专用协议）
- 使用密钥句柄而非明文值
- 最小权限原则：应用只能调用授权操作（如签名、加密），不能列出全量密钥
- 审计日志记录每次密钥使用的时间、操作、结果
3.4 密钥轮换
轮换不是简单替换。很多团队只换密钥不换加密后的数据，等于没换。
轮换触发条件一般有两种：
- 基于时间：比如每年、每季度自动生成新版本
- 基于事件：员工离职、安全事件、密码算法升级
实现时，HSM通常支持密钥版本链：新密钥继承旧密钥的标签和用途，旧密钥保留用于解密历史数据。
// 伪代码：密钥轮换示例（使用PKCS#11 API）
CK_ATTRIBUTE template[] = {
{CKA_CLASS, &keyClass, sizeof(keyClass)},
{CKA_KEY_TYPE, &keyType, sizeof(keyType)},
{CKA_, &trueVal, sizeof(trueVal)},
{CKA_ENCRYPT, &trueVal, sizeof(trueVal)},
{CKA_DECRYPT, &trueVal, sizeof(trueVal)},
{CKA_LABEL, "AES_EncKey_v3", 14} // 新版本号
};
CK_OBJECT_HANDLE hNewKey;
rv = C_GenerateKey(hSession, CKM_AES_KEY_GEN, template, 6, &hNewKey);
if (rv == CKR_OK) {
// 标记旧密钥为只解密
// 开始数据重加密流程
}3.5 密钥销毁
销毁是最容易被忽略的环节。很多人觉得删除数据库记录就行，但在HSM里，密钥可能还在芯片内存里残留。
安全销毁标准：
- HSM内部：调用
C_DestroyObject后，硬件执行零化操作（覆写所有位） - 外部包装密钥：先解引用再销毁KEK，确保包装层不可恢复
- 物理销毁：报废HSM时需切碎芯片或通过厂商安全返厂
还有一个容易被忽视的点：销毁后要验证。我习惯用HSM的 C_GetAttributeValue 检查密钥句柄是否返回 CKR_OBJECT_HANDLE_INVALID。有些HSM还支持 C_VerifyKeyZeroization 扩展命令。
看完这张图，你应该能理解为什么我反复强调“闭环”。密钥不是单独存在的对象，它从生成就决定了后面的命运。比如生成时忘了标记“可轮换”，轮换阶段就卡住了。
最后说一句：生命周期管理不是技术问题，是流程问题。工具HSM都给你了，但人把流程做错，再贵的硬件也救不了。