随机性决定密钥上限
密钥再长，如果生成时的随机源可预测，整条防线就塌了。正确做法只有一条：交给操作系统的密码学安全随机数发生器（CSPRNG）或平台密钥生成接口，例如 OpenSSL 的 genpkey、HSM 内部的密钥生成命令。自己拿时间戳、进程号或普通伪随机函数拼出来的「随机」，在同一秒内可能完全重复；更隐蔽的风险来自环境本身——虚拟机镜像克隆后没有重新生成主机密钥与证书私钥，模板里那套密钥就会在成百上千台机器上重复。
基本信息
| 正确来源 | /dev/urandom、getrandom()、系统 CSPRNG、HSM 内生成 |
|---|---|
| 风险做法 | 时间戳、进程号或自研伪随机函数拼凑 |
| 生成命令 | openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out key.pem |
| 环境检查 | cat /proc/sys/kernel/random/entropy_avail 查看熵池状态 |
| 镜像场景 | 克隆镜像后必须重新生成主机密钥与证书私钥 |
| 嵌入式设备 | 首次启动要确认随机源就绪，再生成长期密钥 |
典型使用场景
- 批量部署：从镜像派生实例后重新生成主机密钥与 TLS 私钥。
- 设备出厂：嵌入式与 IoT 设备首次上电时生成设备密钥。
- 容器与 CI：确认生成过程使用宿主机 CSPRNG，而不是脚本里的伪随机数。
- 密钥恢复演练：验证重新生成后的公钥指纹确实与旧值不同。
- 安全评审：说明密钥来源与熵源，作为合规证据。
生成与检查
生成与检查
# 使用 OpenSSL 生成密钥：交由系统 CSPRNG 提供随机性
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out key.pem
openssl genpkey -algorithm ED25519 -out ed.key
# 查看熵池可用量（较新的内核与虚拟化环境下更多是参考值）
cat /proc/sys/kernel/random/entropy_avail
# 记录公钥指纹，便于确认实例间没有重复密钥
openssl pkey -in key.pem -pubout | openssl sha256场景与风险对照
| 场景 | 常见问题 | 正确做法 |
|---|---|---|
| 镜像克隆 | 所有实例共用模板密钥 | 首次启动重新生成并记录指纹 |
| 容器启动 | 脚本自造随机数生成密钥 | 调用 openssl 或系统 CSPRNG 接口 |
| 嵌入式首启 | 熵源未就绪就生成密钥 | 等待随机源可用或使用硬件随机源 |
| 批量脚本 | 循环内重复使用同一随机种子 | 每次调用独立获取随机性 |
| 密钥导入 | 外部生成后手工搬运 | 核对来源可信并校验指纹 |
历史上有设备因启动阶段熵不足而生成弱密钥的公开案例，尤其是首次启动即自动生成密钥的镜像与固件；上线前应连带验证并留存指纹记录。
低熵问题的发现往往滞后：批量生成的密钥若彼此相同或高度相关，只有做指纹比对或统计检查才能看出来，因此每次生成后记录公钥指纹是值得的例行动作。