SM2 验签失败、跨系统不互认？新国标GB/T 35275‑2026 已正式施行
2026-11-05
项目联调中我们常常遇到：算法、密钥都符合国密要求，但 A 厂商生成的 SM2 签名报文，B 厂商验签却失败。问题大多不在算法运算本身，而在消息封装格式差异。
2026 年 11 月 1 日起，SM2 配套国标GB/T 35275-2026《网络安全技术 SM2 密码算法加密签名消息格式》正式实施，全面替代 2017 版。本次更新中，SM2 算法、SM3 杂凑算法、数字证书均无改动，变化集中在签名、加密结果的消息封装规则——正是为了解决SM2算法消息封装格式互通问题。
01、修订背景和主要内容
国密体系分工清晰：算法定义在 GB/T 32918，使用规范在 GB/T 35276，证书格式在 GB/T 20518，实体标识在 GB/T 33560；GB/T 35275 只守消息格式这一层，解决一份 SM2 签名、一次 SM2 加密的输出结果如何打包、接收方如何解析的问题。
可以用信封与印章类比理解：
算法决定印章计算是否正确，格式决定报文信封如何打包
印章本身没有更换，只是信封的制作规范更新
只有收发双方遵循同一套封装规范，报文才可以互相解析；如果格式不统一，即便使用同一套 SM2 算法，接收端也无法正常解析报文。
回看这几年的国密改造，大体走过三段：从「算法迁移」到「密码测评」，再到如今的「互认互通」。
GB/T 35275-2026 正是落在第三段：它不新造算法，只把 SM2 运算结果怎么封装、怎么标识、怎么解开，定成统一格式。
注意：本次修订与 HTTPS/SSL 证书握手无关，不存在更换 SSL 证书的要求——它管的是应用层 SM2 签名加密报文的封装，不属于传输层握手协议。
02、新旧 SM2 格式对比
先说缺口：2017 版卡在哪
2017 版标准经过多年项目落地实践，逐步显现三类现实缺口：缺少独立完整性报文类型、传统数字信封仅保障机密性、部分历史结构需要清理精简。
| 缺口 | 2017 版状态 | 2026 版回应 |
|---|---|---|
| 只要完整性、不要签名 | 无独立类型，要么套签名要么自造 | 新增 DigestedData |
| 信封只保密不保完整 | 解密不报错≠内容没被改 | 新增 AuthEnvelopedData，衔接 GB/T 36624 |
| 部分结构冗余 | 残留旧类型与缩略语 | 删除 CA/ECC 缩略语及两个旧基本类型 |
再看变化：8 处，真正动代码的 3 处
对比 2017 版本，新版共计 8 项主要变更，大部分属于文档、定义层面优化，真正需要改造代码的集中在 3 个点。
| # | 变化 | 是否动代码 |
|---|---|---|
| 1 | 删除缩略语 CA 与 ECC | 否，文档清理 |
| 2 | 新增摘要与鉴别数字信封数据类型的对象标识符 | 是，需注册新类型 |
| 3 | 删除两个旧基本类型 | 视产品是否用到 |
| 4 | 版本号取值调整为 2（6.8 条、表 3、表 4、表 8） | 是，按条目核对 |
| 5 | 新增 Attribute 基本类型 | 是，结构新增 |
| 6 | 新增签名的计算过程 | 否，文档明确 |
| 7 | 新增摘要数据类型 digestedData | 是，新类型实现 |
| 8 | 新增鉴别数字信封数据类型 authEnvelopedData | 是，新类型实现 |
这里做一个说明：该标准属于推荐性国标修订，并非强制全面换代。历史电子签章文件、归档报文继续沿用原有格式完成验证；产品需要支持新格式生成，同时兼容解析旧版报文，不能直接舍弃历史格式。
真正新增能力的是这两类
DigestedData 对数据计算 SM3 摘要、与数据一同封装，用于只需防篡改、不要签名身份的场景；但摘要算法是公开的，任何人都能算出同一结果，它不证明报文是谁发的，要身份鉴别与抗抵赖仍需 SignedData 数字签名。
AuthEnvelopedData 在传统信封之上，按 GB/T 36624-2018 以 SM4-GCM、SM4-CCM 在密钥层叠加完整性鉴别，密文一旦被改动即解密失败。
03、国密互操作影响测评的 5 个风险点
GB/T 35275-2026 是推荐性国家标准，不构成密评的强制门槛，落到项目现场，跨厂商能否验通、新旧格式能否衔接，并不都是直接测评项，但可能影响到上线后密码应用有效性，在跨系统互通上留下风险点，主要集中在五个方向。
一是签名验签跨厂商是否一致
同一份报文，一方验过、一方验不过，多半不是算法问题，而是签名值的编码写法、参与签名的用户标识约定、摘要算法是否显式声明这几处没对齐。
二是数字信封的密钥封装与接收方解密是否规范
发送方能加密、接收方解不开，常见于密钥派生参数不一致、接收者标识不完整、完整性保护未启用；密文被改动后应当直接解密失败，而不是输出一段异常明文。
三是密钥与证书凭据是否统一托管
私钥应驻留在密码硬件中，凭据集中管理、有效期可提前预警；凭据散落在各系统、到期无人知晓，是最容易被问到、却拿不出台账的一环。
四是算法与标识是否与实现一致
报文声明的算法与实体标识，要和实际运算、证书里的取值对得上；标识写错或新旧混用，对端就会解析到错误的算法。
五是新旧格式能否平滑衔接
双格式并行期间，旧格式的解析能力要保留，升级出问题能回退；异常输入的处理也要两端一致——报文被截断、内容被篡改、版本号超出预期时，收发双方应给出相同判定，避免一方判为非法、另一方直接放行。
建议消息结构样例、双向联调记录、凭据台账、算法标识对照表、双格式兼容测试记录，应作为项目材料留存。
04、现在该做的四件事
对国密项目负责人，落地动作可收敛为4 类、12 项可核对事项，无需替换底层算法库。按「核对项—达标判定—可留存材料」逐条过一遍，就能形成一份可直接用于验收与测评准备的自查表。
01签名验签
核对项 签名值编码一致；用户标识约定一致；摘要算法显式声明
达标判定 同一报文双向验签均通过，不出现一方通过、一方失败
可留存材料 跨厂商双向验签记录、签名值编码样例
02数字信封
核对项 密钥派生参数一致；接收者标识完整；完整性保护启用
达标判定 发送方可加密、接收方可解密；密文被改动后解密直接失败
可留存材料 信封加解密联调记录、篡改后失败验证记录
03密钥与凭据
核对项 私钥驻留密码硬件；凭据集中托管；有效期可预警
达标判定 私钥不出硬件、到期前可预警，凭据台账可追溯
可留存材料 密钥与证书台账、密钥使用审计记录
04新旧衔接
核对项 版本号按 6.8 条与表 3、表 4、表 8 核对；双格式并行可用；升级可回退
达标判定 新格式可生成、2017 版报文可验；回退后业务不中断
可留存材料 双格式兼容测试报告、回退演练记录
落地可按四阶段推进：
01摸底梳理 盘点在用消息类型与历史报文存量
02核对适配 按标准条目核对版本号与新增类型
03兼容验证 完成新旧格式双向测试
04联调举证 留存对端联调记录
各阶段形成可复查记录，作为验收与测评准备材料。
在产品落地形态上，签名验签服务器、电子签章系统、密码服务平台，是签名、验签、数字信封能力的载体。各产品对新版标准的适配支持情况，以产品实际版本与适配说明为准。
总结
算法没变，格式变了
本次 GB/T 35275-2026 修订，算法没变，格式变了，核心解决 SM2 报文跨系统互通问题，并非密码算法迭代升级。
打通新旧格式双向兼容通道，远比盲目优先上线新格式更关键。项目团队可结合自身业务存量，有序完成适配评估与验证。
