3. 迁移风险与合规基线
密码迁移不是单纯的算法替换，而是一次跨技术、跨组织、跨监管的系统工程。在动手改造之前，必须先回答两个问题：外部合规要求我们做到什么程度、什么时间做到；我们当前离这些要求还差多远、差在哪里。前者是合规基线，后者是差距分析。二者共同决定了迁移的优先级、资源投入和验收标准。
一、四类合规基线的定位差异
NIST、国密、等保、PCI DSS 并非同一层面的要求，混为一谈会导致迁移目标失焦。可以按“约束性质”把它们分成四类：
- NIST（SP 800-57、SP 800-131A、SP 800-208 等）：属于技术标准与算法生命周期指引，给出密钥长度、算法强度、使用期限的建议。它不直接执法，但被大量行业规范引用，是国际互操作场景的事实基线。其核心信号是：RSA-1024 已不可用于数字签名，RSA-2048 在 2030 年前后逐步退出主流推荐，向 ECC P-256/P-384 及后量子算法过渡。
- 国密（SM2/SM3/SM4，GM/T 系列与《商用密码管理条例》）：属于强制性或准强制性合规要求，尤其在政务、金融、能源等关键信息基础设施领域。SM2 基于椭圆曲线，天然与 ECC 迁移方向一致，但曲线参数、签名格式、密钥编码与 NIST 体系不兼容，需要独立实现或双栈支持。
- 等保 2.0：属于等级保护制度，关注“密码技术应用”的合规性，例如身份鉴别、数据保密性、完整性、不可否认性是否使用了符合要求的密码算法。它不指定具体算法，但会引用国密或行业密码规范，是检查项的来源。
- PCI DSS v4.0：属于支付卡行业强制标准，明确要求淘汰弱加密与弱协议，对 TLS 版本、密钥长度、证书管理有具体条款。其迁移压力来自收单机构与卡组织的合规审计，时间节点通常比 NIST 建议更紧迫。
四者的关系可以概括为：NIST 提供技术方向，国密提供本土强制路径，等保提供检查框架，PCI DSS 提供行业硬约束。迁移方案必须同时满足“技术可行、监管认可、审计可查”三个条件。
二、RSA 退役时间表：不是一刀切，而是分层退出
RSA 退役并非某个日期全部停用，而是按密钥长度、用途、系统暴露面分层推进。下表给出一份可参考的退役节奏（示例性规划，具体以所在行业监管与自身风险容忍度为准）：
| 阶段 | 时间窗口 | RSA 密钥长度 | 典型用途 | 处置动作 |
|---|---|---|---|---|
| 立即淘汰 | 即刻 | ≤1024 位 | 签名、密钥交换、证书 | 停止签发，存量证书吊销或替换 |
| 限期退出 | 2025—2027 | 2048 位 | 对外 TLS、代码签名 | 新系统禁止使用，存量系统制定替换计划 |
| 过渡保留 | 2027—2030 | 2048/3072 位 | 内部系统、遗留接口 | 仅限封闭环境，需补偿性控制与审计 |
| 全面迁移 | 2030 以后 | — | 全部场景 | 以 ECC/PQC 为主，RSA 仅作兼容回退 |
需要特别注意的是“签名”与“加密”的退役节奏不同。RSA 签名受证书链和信任锚影响，替换周期长；RSA 密钥交换（如 TLS RSA 密钥传输）可以较快切换到 ECDHE。因此迁移排期应把密钥交换放在第一优先级，签名与证书体系放在第二优先级，历史数据解密单独处理。
三、ECC 迁移风险矩阵
ECC 迁移的风险不能只看算法本身，还要看它嵌入的系统、协议、硬件和流程。下面这张风险矩阵按“发生可能性”和“影响程度”两个维度，把常见风险定位到四个象限，便于决定先处理什么。
矩阵的使用方法是：右上象限（高影响、高可能）必须在迁移启动阶段就投入资源解决，例如证书链重建和 HSM 兼容性验证；左上象限（高影响、低可能）需要制定应急预案，例如历史签名数据的长期验证方案；右下象限（低影响、高可能）通过工程手段持续优化；左下象限（低影响、低可能）纳入常规培训与测试管理即可。
四、合规差距分析：从条款到证据
差距分析不能停留在“我们支持 ECC 吗”这种粗粒度问题，而要落到具体条款、具体系统、具体证据。建议按以下四步执行：
- 条款拆解：把 NIST、国密、等保、PCI DSS 中与密码算法相关的条款逐条列出，标注“强制/推荐”“适用系统范围”“验收证据类型”。例如 PCI DSS 要求 TLS 1.2 以上且禁用弱套件，证据是配置截图与扫描报告；等保要求身份鉴别使用合规算法，证据是算法清单与密钥管理记录。
- 现状盘点：对每个适用系统采集当前使用的算法、密钥长度、证书类型、协议版本、加密库版本。盘点结果应形成资产—算法映射表，而不是笼统的“已支持”。
- 差距判定：将现状与条款逐项比对，输出三类结论——已合规、部分合规（如支持 ECC 但未启用）、不合规（如仍在使用 RSA-1024）。部分合规项往往是最容易被审计挑战的，需要明确整改期限。
- 整改优先级：结合风险矩阵，把差距项按“合规紧迫度 × 技术风险”排序。对外暴露系统、支付链路、政务接口优先；内部封闭系统可适度延后，但必须有补偿性控制。
openssl s_client 验证真实套件，而不是只看配置文件。
五、把合规基线转成可执行的迁移约束
完成上述分析后，应输出一份迁移约束清单，作为后续架构设计和实施验收的依据。清单至少包含：
- 必须支持的算法集合：SM2/SM3/SM4（国密场景）、ECDSA P-256/P-384、ECDHE、以及必要的 RSA 兼容回退；
- 禁止使用的算法与密钥长度：RSA-1024 及以下、SHA-1、TLS 1.0/1.1、弱曲线；
- 证书与信任锚要求：根证书有效期、签名算法、密钥用法扩展；
- 硬件与中间件约束：HSM 支持的曲线与固件版本、加密机接口规范；
- 审计证据要求：配置基线、扫描报告、密钥生命周期记录、变更审批记录；
- 时间节点：各阶段退役与切换的截止日期，以及对应的验收标准。
这份清单的价值在于，它把分散的合规条文转化为工程团队可以直接执行的参数和检查项。后续的架构改造、代码迁移、测试验证，都应围绕这份清单展开，而不是等到审计前才回头补证据。合规基线不是迁移的终点，而是迁移的起点和验收标尺。