1. 课程导入与迁移工程全景

如果把传统公钥密码体系比作一座已经运行了三十年的城市,那么量子计算带来的威胁并不是某一天突然降临的洪水,而是一场可以提前数十年预报的地质沉降:地基正在缓慢失效,而城市必须在不停止运转的前提下完成整体加固。本课程讨论的,正是这场"不停止运转的加固工程"——PQC(后量子密码)证书与 PKI 迁移。

理解迁移工程,首先要理解驱动它的不是技术好奇心,而是三条同时逼近的时间线。第一条是量子计算能力线:Shor 算法在足够规模、足够纠错的量子计算机上可以多项式时间求解大整数分解与离散对数,这意味着 RSA、DH、ECDH、ECDSA、EdDSA 等当前主流算法在数学基础上会被整体击穿。第二条是标准与合规线:NIST 已于 2024 年正式发布 ML-KEM(FIPS 203)、ML-DSA(FIPS 204)与 SLH-DSA(FIPS 205)三项标准,算法选型从"研究议题"变成"可采购、可认证的产品参数"。第三条是数据保密寿命线:一份需要保密 15 年的病历、合同或固件签名,今天被截获的密文可能在 10 年后被解密,这就是"先存后破"(Harvest Now, Decrypt Later)攻击。三条线叠加,决定了迁移不是"等量子计算机造出来再说",而是现在就要启动的长期工程。

核心判断:迁移的紧迫性不取决于量子计算机何时出现,而取决于"数据保密期 + 系统改造周期"是否已经超过"量子威胁到达时间"。对多数机构而言,这个不等式早已成立。

那么,PQC 迁移到底难在哪里?难点并不在"换一个算法",而在于 PKI 是一个由信任锚、证书层级、协议握手、硬件模块、运维流程和外部依赖共同构成的耦合系统。改动其中任何一环,都会沿着信任链和协议栈向外传导。具体来说,迁移面临五类核心挑战:

  • 算法与参数膨胀:ML-KEM-768 的公钥约 1184 字节、密文约 1088 字节,ML-DSA-65 的公钥约 1952 字节、签名约 3309 字节,相比 ECC 的 32~64 字节量级增长数十倍。这会直接冲击 TLS 握手分片、证书链长度、UDP 载荷上限和嵌入式设备存储。
  • 混合模式与互操作:过渡期普遍采用"经典 + PQC"混合密钥交换(如 X25519MLKEM768)与混合签名,既要防量子,也要防新算法尚未被充分密码分析的风险,同时必须与不支持 PQC 的对端保持兼容。
  • 信任锚与根证书切换:根 CA 的更换是 PKI 中代价最高的操作之一,涉及交叉签名、双根并行、信任库更新和终端设备固件升级。
  • 硬件与生命周期错配:HSM、智能卡、TPM、车规芯片的密码能力往往固化,其更换周期以 5~10 年计,远长于软件迭代。
  • 资产可见性缺失:多数组织并不清楚自己有多少证书、多少协议端点、多少硬编码密钥,密码敏捷性(crypto agility)不足使"发现—评估—替换"难以闭环。

面对这样的系统,工程上不能靠"一次性替换"解决,而必须按生命周期推进。下图给出本节的核心视图:从驱动因素出发,经过资产盘点与密码敏捷性改造,进入混合部署与算法切换,最终收敛到纯 PQC 目标态,并由监控与治理贯穿全程。

PQC 证书与 PKI 迁移工程全景 驱动因素 → 资产与敏捷性 → 混合部署 → 纯 PQC 目标态,治理与监控贯穿全程 驱动因素 • Shor 算法威胁 RSA/ECC • NIST FIPS 203/204/205 • 先存后破(HNDL) • 合规与供应链要求 资产盘点与敏捷性 • 证书/密钥/协议清单 • CBOM 密码物料清单 • 算法可替换性改造 • 依赖方与终端梳理 混合部署过渡 • X25519MLKEM768 • 双证书/双根并行 • 交叉签名与信任库 • 分阶段灰度切换 纯 PQC 目标态 • ML-KEM / ML-DSA • 新根 CA 与信任锚 • 旧算法退役 • 长期运维与轮换 治理与持续监控:密码策略 · 证书生命周期管理 · 算法清单维护 · 兼容性回归 · 威胁情报跟踪 工程生命周期关键阶段 1. 发现与评估 密码资产测绘 风险与优先级排序 2. 规划与试点 算法选型与参数 小范围验证 3. 混合与迁移 双栈并行运行 分批切换与回退 4. 收敛与退役 纯 PQC 收敛 旧算法下线 5. 运维与演进 轮换与监控 应对新标准 兼容性异常时回退至混合模式 学习路线:密码基础 → PQC 算法与标准 → 证书与协议改造 → 混合部署实操 → 迁移治理与排障

这张全景图中有两个容易被忽视但决定成败的细节。第一,治理与监控不是最后一个阶段,而是横贯全程的底座。如果组织没有一份持续更新的密码物料清单(CBOM),那么"迁移完成"就只是一个无法验证的声明。第二,回退路径必须与前进路径同时设计。混合部署阶段之所以重要,正是因为它提供了可回退的安全边界:当某个对端、某台设备或某个协议栈在 PQC 参数下出现握手失败、分片异常或性能劣化时,系统可以退回经典算法继续服务,而不是整体中断。

从工程实践角度,一个可操作的起点是建立"密码资产台账"。台账不需要一开始就完美,但字段必须能支撑决策。下面给出一份可直接参考的示例结构(数据为教学示例,非实测结果):

资产标识 类型 当前算法 密钥/证书尺寸 协议端点 更换周期 迁移优先级
root-ca-g2 根 CA ECDSA P-384 证书约 1.2 KB 离线签发 15 年 高(信任锚)
tls-gw-01 TLS 网关 ECDHE + RSA2048 握手约 4 KB 443/tcp 3 年 高(对外暴露)
iot-sensor-A 嵌入式终端 ECC P-256 固件固化 MQTT/TLS 8 年 中(需固件升级)
code-sign-01 代码签名 RSA3072 签名约 384 B CI/CD 2 年 中(供应链)

有了台账,优先级判断就有了依据。通常遵循三条经验规则:对外暴露且数据保密期长的系统优先;处于信任链上游的根与中间 CA 优先;更换周期长、难以远程升级的硬件优先纳入早期规划。这三条规则共同指向一个结论:迁移的排期不是按"技术新旧"排,而是按"暴露面 × 数据寿命 × 更换难度"排。

在项目启动阶段,建议先完成一次"密码敏捷性自检":现有系统能否在不重新编译固件、不更换硬件的前提下替换签名算法与密钥交换算法?如果答案是否定的,那么敏捷性改造本身就应该成为迁移工程的第一批任务。

最后需要明确本课程的学习路线。我们将沿着"基础—算法—证书—协议—工程"的层次推进:先建立量子威胁与 PQC 标准的基本认知,再深入 ML-KEM、ML-DSA、SLH-DSA 的参数与适用边界;随后进入 X.509 证书结构改造、混合证书链、根 CA 切换与信任库更新;接着讨论 TLS 1.3 混合密钥交换、QUIC、IPsec、SSH 等协议栈的落地细节;最终落到迁移项目管理、灰度发布、性能评估与故障排查。每一章都会围绕真实对象、真实参数和可判断的结果展开,而不是停留在概念复述。

迁移工程的目标不是"用上 PQC",而是"在量子威胁到达之前,让系统中的每一段信任关系都完成可验证的算法替换,并且在整个过程中保持业务连续"。理解这一点,就理解了本课程全部内容的出发点。