3. 密钥生成安全：HSM vs 软件密钥，密钥强度与算法选择

密钥生成，是整个设备证书生命周期的起点。起点要是歪了，后面所有环节都是白搭。我见过太多案例，证书体系看着挺完善，结果密钥生成环节出了纰漏，整个信任链瞬间崩塌。今天咱们就聊聊这个最基础也最关键的话题。

3.1 硬件安全模块(HSM) vs 软件密钥

说白了，密钥存在哪儿、怎么生成的，决定了它的安全底线。HSM 和软件密钥，是两条完全不同的路。

3.4.1 硬件安全模块(HSM)

HSM 是一种专用的硬件设备，专门干一件事：在物理隔离的环境里生成、存储和使用密钥。密钥从生到死，从未离开过这个黑盒子。

HSM 的核心优势：

• 物理隔离：密钥材料不出设备，操作系统看不到，进程也读不到
• 防篡改：一旦检测到物理攻击，自动销毁密钥
• 合规认证：FIPS 140-2 Level 3、Common Criteria EAL4+ 是基本门槛
• 高性能：专用硬件加速，RSA 4096 签名每秒能跑几千次

3.1.2 软件密钥

软件密钥就是密钥以文件形式存在磁盘上，或者由操作系统管理。常见的有 PKCS#12 文件、JKS 密钥库、或者直接裸存的 PEM 文件。

软件密钥的风险点：

• 内存泄露：密钥可能在 swap 分区、core dump 里留下痕迹
• 文件权限：一不小心 chmod 777，密钥就裸奔了
• 备份泄露：备份磁带、云存储里可能藏着密钥副本
• 侧信道攻击：CPU 缓存、时序分析都能偷密钥

3.1.3 对比表格

3.2 密钥强度与算法选择

算法选不对，密钥再长也没用。我见过有人用 RSA 512 位给 IoT 设备做证书，结果被破解只用了几个小时。你想想看，设备部署出去，密钥强度不够，等于把大门钥匙挂在门框上。

3.2.1 主流算法对比

3.2.2 算法选择的决策树

怎么选？我一般按这个逻辑来：

1. 合规要求：国密场景必须 SM2，金融行业可能要求 RSA 4096
2. 设备性能：MCU 资源有限，ECDSA 比 RSA 省电省内存
3. 互操作性：老旧系统可能只支持 RSA，需要兼容
4. 未来抗量子：现在就开始关注 Dilithium、Falcon 等后量子算法

3.3 密钥生成流程与最佳实践

光知道选什么算法还不够，怎么生成才是关键。我总结了一套流程，基本每个项目都这么干：

3.3.1 生成步骤

1. 初始化随机数生成器：确保熵源充足，Linux 下用 /dev/urandom，HSM 用内置 TRNG
2. 设置密钥属性：不可导出、不可备份、仅签名/仅加密
3. 执行生成操作：调用 HSM API 或 OpenSSL 命令
4. 验证密钥对：签名-验签测试，确保公私钥匹配
5. 安全存储公钥：公钥可以导出，但必须校验完整性

# 使用 OpenSSL 生成 ECDSA P-256 密钥对（软件方式，仅用于测试）
openssl ecparam -genkey -name prime256v1 -out device.key

# 使用 HSM 生成（以 PKCS#11 接口为例）
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so \
  --keypairgen --key-type EC:prime256v1 \
  --id 01 --label "device-key-01" \
  --usage-sign --extractable=false

3.4 密钥生成的核心逻辑

下面这张图，是我每次做架构设计时都会画的。它把密钥生成的核心决策点串起来了：

3.5 常见陷阱与避坑指南

• 随机数质量：嵌入式设备刚启动时熵源不足，生成密钥可能被预测。我建议在系统启动完成、网络服务就绪后再生成密钥。
• 密钥备份：HSM 的密钥备份方案要提前设计。我曾经遇到客户 HSM 坏了，密钥没备份，整个 CA 重建，所有设备证书要重新签发。
• 测试与生产混用：测试密钥和生产密钥必须物理隔离。我见过测试 HSM 里的密钥被误用到生产环境，结果测试证书被当作正式证书信任。
• 密钥轮换：生成时就规划好密钥有效期和轮换策略。设备证书一般 1-3 年，CA 根密钥 5-10 年。