4. 后量子密钥的存储安全
后量子密码（PQC）解决了“密钥交换与签名算法能否抵抗量子攻击”的问题，但密钥本身仍要落地存放。如果一把 ML-KEM 私钥以明文形式躺在磁盘上，攻击者根本不需要量子计算机——直接读文件即可。因此本节的核心问题是：PQC 密钥生成之后，存放在哪里、由谁保护、以什么形式加密、边界在哪里。我们围绕硬件安全模块（HSM）与可信平台模块（TPM）两条主线展开，并给出可落地的密钥封装与加密存储方案。
一、HSM 与 TPM 的定位差异
两者都提供“密钥不出硬件”的保护，但设计目标不同。HSM 是独立的密码设备（PCIe 卡、网络设备或云服务），具备高吞吐、多租户、密钥备份与集群能力，通常通过 PKCS#11、KMIP 或厂商 API 访问，适合保护 CA 根密钥、签名密钥、批量密钥封装等场景。TPM 是焊接在主板上的低成本安全芯片，遵循 TCG 规范，核心能力是平台度量（PCR）、密封存储（Seal/Unseal）和受限的密钥操作，适合保护设备本地密钥、磁盘加密密钥、启动链相关秘密。
关键区别在于：HSM 通常允许在内部生成并长期持有通用密钥，支持对称与非对称运算的完整集合；TPM 的密钥槽有限、运算能力弱，且密钥往往与平台状态绑定。因此 PQC 迁移中，HSM 承担“密钥生产与密码服务”，TPM 承担“平台信任根与本地密钥解封”。
二、PQC 算法支持现状
截至当前工程实践，支持情况可概括为三层：
- 算法层：ML-KEM（FIPS 203）、ML-DSA（FIPS 204）、SLH-DSA（FIPS 205）已标准化，主流密码库（OpenSSL 3.5+、BoringSSL、liboqs）已提供实现。
- HSM 层：部分厂商通过固件升级支持 ML-KEM/ML-DSA 的密钥生成与运算，但普遍存在密钥长度、API 结构、性能上的适配问题；不少设备仍只支持“导入导出”而非“内部生成”。
- TPM 层：TCG 已发布 PQC 相关规范草案，但商用 TPM 2.0 芯片对 ML-KEM/ML-DSA 的原生支持仍不普及，多数设备只能通过“TPM 保护对称密钥 + 软件实现 PQC”的混合方式落地。
三、密钥封装与加密存储方案
在硬件原生支持不完整时，工程上常用“信封加密 + 硬件根密钥”的组合。其思路是：PQC 私钥不直接交给 HSM/TPM 长期保存，而是用一把由硬件保护的对称密钥（KEK）加密后落盘；使用时在硬件内部解封 KEK，再在受控内存中解密私钥。下图展示了这一数据流与信任边界。
具体实现可参考以下步骤（示例参数，非实测结果）：
- 生成 KEK：在 HSM 内生成 AES-256 密钥，标记为不可导出；若用 TPM，则创建一个受 PCR 策略约束的对称密钥对象。
- 生成 PQC 密钥对：在主机侧用 OpenSSL 生成 ML-KEM-768 密钥对，私钥仅存在于内存。
- 封装私钥：用 KEK 以 AES-256-GCM 加密私钥，随机 96 位 IV，得到密文与 128 位认证标签，写入磁盘。
- 解封使用：应用请求签名时，将密文送入 HSM 解封，私钥在受控内存中完成运算后立即清零。
- 密钥轮换：KEK 按周期轮换，旧 KEK 解密后由新 KEK 重新加密，密文文件同步更新。
四、方案选择与判断依据
若业务要求高吞吐、多租户、集中审计，优先选择支持 PQC 的 HSM，并确认其固件与 API 真正支持目标算法；若场景是终端设备、边缘节点或启动链保护，TPM 更合适，但需接受“TPM 保护对称密钥、PQC 由软件实现”的混合模式。无论哪种，都应遵循三条底线：私钥明文不落盘、KEK 不出硬件、解封操作有审计日志。迁移初期可采用“双栈”策略——传统算法与 PQC 并行，逐步将密钥生命周期迁入硬件信任边界，避免一次性切换带来的兼容性风险。