1. 引言
随着量子计算技术的快速发展，传统公钥密码体系（RSA、ECC 等）面临严峻挑战。与此同时，国家密码管理局持续推进商用密码应用安全性评估，要求政企系统逐步采用国密算法（SM2、SM3、SM4）。在这一背景下，如何在保障现有业务连续性的前提下，平稳实现从传统 TLS 向国密、再到抗量子密码（PQC）的过渡，成为政企信息化建设必须面对的现实课题。
本文从技术演进路径、共存过渡方案、迁移风险评估三个维度展开，为政企系统规划一条可落地、可验证、可回退的密码升级路线。
2. 背景与驱动因素
2.1 三重压力叠加
- 合规压力：等保 2.0、密评（商用密码应用安全性评估）要求重要网络与信息系统优先使用国密算法。
- 安全威胁：量子计算机的"先存储、后解密"攻击模式，使今天传输的敏感数据在未来面临被批量破解的风险。
- 生态兼容：浏览器、操作系统、中间件对国密与 PQC 的支持参差不齐，倒逼过渡方案必须兼顾兼容性。
2.2 算法对比概览
| 算法族 | 代表算法 | 密钥长度 | 抗量子能力 | 国密合规 |
|---|---|---|---|---|
| 传统公钥 | RSA-2048 / ECC P-256 | 2048 bit / 256 bit | 弱 | 否 |
| 国密 | SM2 / SM3 / SM4 | 256 bit | 弱 | 是 |
| PQC | Kyber / Dilithium / SPHINCS+ | 可变 | 强 | 待定 |
3. 共存过渡总体思路
3.1 过渡原则
- 双栈并行：新旧算法同时启用，按客户端能力协商选择。
- 渐进迁移：先试点、再推广、后收缩，避免"一刀切"切换。
- 可回退：任何阶段保留回退开关，确保业务连续性优先。
3.2 演进路线图
4. 阶段一：TLS 与国密双栈共存
4.1 双证书体系
在过渡初期，服务器同时部署传统 RSA/ECC 证书与国密 SM2 证书，通过 TLS 扩展字段（如signature_algorithms）与客户端协商：
- 支持国密的客户端自动选择 SM2 证书与 SM2 密码套件。
- 不支持国密的客户端回退到传统 TLS 证书，保证业务不中断。
4.2 密码套件配置示例（Nginx）
ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-SM2-SM4-CBC-SM3:ECDHE-RSA-AES256-GCM-SHA384; ssl_certificate /etc/nginx/certs/server_sm2.crt; ssl_certificate_key /etc/nginx/certs/server_sm2.key; ssl_certificate /etc/nginx/certs/server_rsa.crt; ssl_certificate_key /etc/nginx/certs/server_rsa.key;4.3 兼容性矩阵
| 客户端类型 | 国密支持 | 协商结果 |
|---|---|---|
| 国密浏览器（密信、红莲花） | 支持 | SM2 + SM4 |
| 主流浏览器（Chrome、Firefox） | 不支持 | RSA/ECC + AES |
| 移动端 App（自研） | 可定制 | 按 SDK 能力协商 |
4.4 项目案例：某省级政务云平台双栈迁移
项目背景
某省级政务云平台承载 120 余个委办局业务系统，高峰期并发连接数超过 8 万。平台原全部采用 RSA-2048 证书，面临密评整改要求，需在 6 个月内实现国密算法支持，同时不能影响存量业务。
问题与挑战
- 存量客户端类型繁杂：既有国密浏览器（红莲花、密信），也有大量 Chrome、Firefox 及自研移动端 App。
- 部分老旧中间件（如某品牌负载均衡器）不支持 SM2 证书链，直接切换会导致握手失败。
- 密评要求核心业务系统必须支持国密，但未强制要求立即关闭传统算法。
解决思路
采用"双证书 + 智能协商"方案：
- 在 Nginx 与 F5 负载均衡器上同时部署 SM2 与 RSA 双证书，通过
signature_algorithms扩展自动协商。 - 对不支持国密的中间件，前置一层密码网关（支持 SM2 卸载），将国密流量转换为内部 TLS 1.3 流量。
- 按业务敏感度分级：核心业务（社保、公积金）优先启用国密，一般业务（门户、资讯）保持双栈并行。
实施效果
- 6 个月内完成全部核心系统国密改造，密评顺利通过。
- 存量客户端零中断，握手成功率保持在 99.95% 以上。
- 国密流量占比从 0 提升至 78%，传统算法流量逐步收缩。
复盘总结
双栈并行的关键在于"协商能力"而非"强制切换"。密码网关作为过渡期的"翻译层"，有效解决了中间件生态滞后的问题。但需注意：密码网关本身成为新的性能瓶颈与单点，后续应逐步推动中间件原生支持国密，减少对网关的依赖。
5. 阶段二：国密为主 + PQC 混合
5.1 混合签名机制
在国密为主的基础上，叠加 PQC 签名作为额外安全层。典型做法是采用"SM2 + Dilithium"组合签名，同时满足国密合规与抗量子需求。
5.2 密钥封装混合（Hybrid KEM）
参考 IETF 的混合密钥封装草案，将 SM2 与 Kyber 的密钥交换结果同时纳入会话密钥派生：
会话密钥 = KDF(SM2 共享密钥 || Kyber 共享密钥 || 会话随机数)这样即使未来量子计算机破解 SM2，攻击者仍无法仅凭 SM2 共享密钥还原会话密钥。
5.3 实施要点
- 在 TLS 1.3 的
key_share扩展中同时携带 SM2 与 Kyber 参数。 - 服务端优先响应支持 PQC 的客户端，否则降级到纯国密。
- 对性能敏感场景，可配置 PQC 仅用于高敏感数据通道。
5.4 项目案例：某金融机构 PQC 混合加密试点
项目背景
某股份制银行在推进国密改造的同时，前瞻性启动抗量子密码试点。其网上银行与支付系统承载高敏感交易数据，需防范"先存储、后解密"的量子威胁。
问题与挑战
- 国密 SM2 虽满足合规要求，但抗量子能力弱，无法应对未来量子计算破解风险。
- 直接切换到纯 PQC 算法缺乏生态支持，且 PQC 算法（如 Kyber）计算开销大，可能影响交易时延。
- 监管机构尚未明确 PQC 合规标准，需在合规与前瞻性之间取得平衡。
解决思路
采用"SM2 + Kyber"混合密钥封装方案：
- 在 TLS 1.3 的
key_share扩展中同时携带 SM2 与 Kyber 参数，服务端优先响应支持 PQC 的客户端。 - 会话密钥派生采用混合模式：
KDF(SM2 共享密钥 || Kyber 共享密钥 || 会话随机数)，确保任一算法被破解都不影响会话安全。 - 对性能敏感的交易通道，配置 PQC 仅用于密钥协商阶段，数据加密仍使用 SM4，控制时延增量。
实施效果
- 试点覆盖网上银行登录、转账、支付三类高敏感场景，日均处理交易 50 万笔。
- 混合模式握手时延增量控制在 35ms 以内，满足业务 SLA。
- 通过攻防演练验证：即使模拟 SM2 被破解，攻击者仍无法还原会话密钥。
复盘总结
混合 KEM 是过渡期的"双保险"策略，既满足国密合规，又提前布局抗量子能力。但需注意：PQC 算法仍在标准化进程中（NIST 已发布首批标准，但国内商用密码体系尚未纳入 PQC），试点应限定在非核心生产环境，并保持算法可替换的架构设计，避免绑定单一 PQC 实现。
6. 阶段三：PQC 为主 + 国密兼容
6.1 主备切换策略
当 PQC 算法成熟、生态完善后，将 PQC 设为主算法，国密作为兼容层保留：
- 新建设备默认启用 PQC。
- 存量设备通过策略路由继续使用国密。
- 设置明确的 PQC 全量切换里程碑与验收标准。
6.2 证书体系演进
PQC 证书（如基于 Dilithium 的 X.509 证书）逐步替换国密证书，但保留国密根证书交叉信任，确保历史签名数据可验证。
7. 政企系统迁移风险评估清单
7.1 评估维度总览
| 风险类别 | 风险项 | 影响等级 | 缓解措施 |
|---|---|---|---|
| 技术风险 | 中间件不支持国密/PQC | 高 | 升级版本或引入密码网关 |
| 技术风险 | 性能下降（PQC 计算开销大） | 中 | 硬件加速卡、会话复用 |
| 业务风险 | 存量客户端无法升级 | 高 | 双栈并行、灰度发布 |
| 业务风险 | 证书链信任体系断裂 | 高 | 交叉认证、双证书部署 |
| 合规风险 | 密评不通过 | 中 | 提前预评估、整改闭环 |
| 管理风险 | 密钥管理复杂度上升 | 中 | 统一 KMS、分级密钥策略 |
7.2 迁移前检查清单
- 盘点全量资产：服务器、终端、中间件、自研系统的密码算法依赖。
- 评估客户端兼容性：浏览器版本、操作系统补丁、移动端 SDK。
- 确认合规要求：密评标准、行业监管细则、等保级别。
- 制定回退预案：明确回退触发条件与操作步骤。
- 建立灰度机制：按业务域、地域、用户群体分批切换。
7.3 迁移中监控指标
- 握手成功率：目标 ≥ 99.9%。
- 握手时延增量：PQC 混合模式控制在 50ms 以内。
- 国密/PQC 使用占比：按周跟踪，验证渐进迁移效果。
- 证书过期预警：提前 90 天自动告警。
7.4 迁移后验证
- 使用第三方工具（如
openssl s_client、gmssl）验证协商算法。 - 开展攻防演练，验证量子威胁场景下的数据保护能力。
- 定期复测密评项，确保持续合规。
8. 案例复盘与共性经验
综合上述三个项目案例，可以提炼出政企系统密码迁移的共性经验：
8.1 共性成功要素
- 资产盘点先行：三个案例均证明，完整、准确的资产清单是迁移成功的前提。某央企案例中，初盘遗漏的 232 套系统正是后续风险的来源。
- 分级灰度推进：按业务敏感度与客户端兼容性分级，避免"一刀切"切换。政务云平台按核心/一般业务分级，金融机构按交易场景分级，均有效控制了风险。
- 兼容层设计：密码网关、混合 KEM、双证书等兼容层设计，是解决生态滞后问题的关键手段。
8.2 共性风险与应对
| 风险类型 | 案例表现 | 共性应对 |
|---|---|---|
| 资产底数不清 | 央企初盘遗漏 232 套系统 | 流量镜像 + 配置扫描，建立常态化台账 |
| 客户端兼容性不足 | 政务云老旧浏览器、央企工业终端 | 双栈并行、密码网关、分级灰度 |
| 证书链信任断裂 | 央企二级单位自建 CA 未交叉认证 | 交叉认证、双证书部署 |
| 性能开销 | 金融机构 PQC 握手时延 | 混合 KEM、PQC 仅用于密钥协商 |
| 合规不确定性 | 金融机构 PQC 无监管标准 | 试点限定非核心环境，保持算法可替换 |
8.3 对后续 PQC 迁移的启示
三个案例虽聚焦国密改造，但其方法论可直接复用于 PQC 迁移：
- 架构可替换：保持算法抽象层设计，避免业务代码与具体算法强耦合，便于未来平滑切换到 PQC。
- 渐进式验证：先在非核心环境试点，积累性能与兼容性数据，再逐步扩大范围。
- 合规前置：密切关注监管动态，在标准明确前保持"合规 + 前瞻"的双轨策略。
7.5 项目案例：某大型央企迁移风险评估实战
项目背景
某大型能源央企下辖 30 余家二级单位，信息系统超过 400 套，涉及生产控制、经营管理、办公协同等多类业务。在推进国密改造过程中，因缺乏系统性风险评估，初期出现多起业务中断事件。
问题与挑战
- 资产底数不清：仅盘点出 180 套系统依赖密码算法，实际远超此数，存在大量"影子系统"。
- 客户端兼容性评估不足：部分老旧工业终端（Windows 7、IE 浏览器）不支持国密，导致生产控制系统无法访问。
- 证书链信任体系断裂：某二级单位自建 CA 未与集团根 CA 交叉认证，国密证书无法被验证。
解决思路
建立"三阶段"风险评估机制：
- 迁移前全面盘点：通过流量镜像 + 配置扫描，识别全部密码算法依赖，建立资产清单（最终发现 412 套系统，比初盘多出 232 套）。
- 迁移中分级灰度：按业务敏感度与客户端兼容性，将系统分为 A（核心生产）、B（经营管理）、C（办公协同）三级，逐级灰度切换。
- 迁移后持续验证：部署自动化监测工具，实时跟踪握手成功率、国密使用占比、证书过期预警。
实施效果
- 迁移周期从计划的 12 个月压缩至 9 个月，业务中断事件从初期的 7 起降至 0。
- 通过交叉认证解决证书链断裂问题，国密证书验证成功率提升至 99.8%。
- 建立常态化密码资产台账，后续 PQC 迁移可直接复用该评估框架。
复盘总结
风险评估的核心不是"一次性清单"，而是"持续运营的资产台账"。初期业务中断的根因在于资产盘点不完整与客户端兼容性评估缺失，而非算法本身。建议政企机构将密码资产盘点纳入常态化运维流程，并建立"评估-整改-复测"的闭环机制，为后续 PQC 迁移积累可复用的方法论。
8. 术语与缩略语对照表
为便于读者快速查阅，现将文中出现的核心术语与缩略语整理如下：
| 术语/缩略语 | 全称 | 中文释义 | 文中首次出现位置 |
|---|---|---|---|
| TLS | Transport Layer Security | 传输层安全协议，用于保障网络通信的机密性与完整性 | 1. 引言 |
| PQC | Post-Quantum Cryptography | 抗量子密码，能够抵御量子计算机攻击的密码算法体系 | 1. 引言 |
| KEM | Key Encapsulation Mechanism | 密钥封装机制，用于安全地协商会话密钥 | 5.2 密钥封装混合（Hybrid KEM） |
| KDF | Key Derivation Function | 密钥派生函数，从共享密钥等输入派生会话密钥 | 5.2 密钥封装混合（Hybrid KEM） |
| SM2 | SM2 Elliptic Curve Cryptography | 国密椭圆曲线公钥密码算法，用于签名与密钥交换 | 1. 引言 |
| SM3 | SM3 Cryptographic Hash Algorithm | 国密密码杂凑算法，输出 256 位摘要 | 1. 引言 |
| SM4 | SM4 Block Cipher | 国密分组密码算法，用于数据加密 | 1. 引言 |
| 密评 | Commercial Cryptography Application Security Evaluation | 商用密码应用安全性评估，检验系统是否合规使用国密算法 | 2.1 三重压力叠加 |
| 等保 | Cybersecurity Multi-Level Protection Scheme | 网络安全等级保护制度，对信息系统分等级实施安全保护 | 2.1 三重压力叠加 |
8. 总结
TLS、国密、PQC 的共存过渡不是简单的算法替换，而是一场涉及技术架构、运维流程、合规管理的系统工程。政企机构应坚持"双栈并行、渐进迁移、可回退"的原则，结合自身业务特点制定分阶段路线图，并通过系统化的风险评估清单控制迁移过程中的不确定性。唯有如此，才能在量子时代到来之前，构建起既合规又抗量子的密码安全底座。
