SM2 完整指南

SM2 是《中华人民共和国密码行业标准》（GM/T 0003-2012）中发布的非对称加密算法，基于椭圆曲线离散对数问题（Elliptic Curve Discrete Logarithm Problem, ECDLP）的数学难解性。它由国家密码管理局组织制定，自 2010 年底起在国内广泛落地，目前已成为金融支付、电子政务、身份认证等关键领域的标准配置。

从数学角度看，SM2 使用的椭圆曲线方程形式为 y² = x³ + ax + b，在一个 256 位的大素数域 GF(p) 上定义。与 RSA 依赖「大数分解」这一数学难题不同，SM2 依赖「在椭圆曲线上求解离散对数」这一更难的问题——这意味着在相同安全强度下，SM2 的密钥长度可以比 RSA 短得多。

具体来说，256 位 SM2 的安全强度约等于 3072 位 RSA，带来的直接好处是：

• 密钥体积更小（32 字节 vs 384 字节），传输与存储更经济；
• 签名与加密运算速度更快，对服务器 CPU 压力更低；
• 更适合在资源受限的物联网设备、智能卡、移动终端上实现。

SM2 标准实际上由四大部分组成：公钥加密算法、数字签名算法、密钥交换协议以及相应的参数定义。此外，SM2 还与 SM3（哈希摘要）和 SM4（对称加密）共同构成完整的国密算法家族，支持密钥加密、数字签名、密钥协商、数据认证等多种密码学原语。

理解 SM2 的第一步是理解它的密钥体系。一个合法的 SM2 密钥对由私钥和公钥两部分组成：

• 私钥（Private Key）：一段 256 位的随机整数（即 32 字节 / 64 个十六进制字符）。必须严格保密，任何泄露都会导致攻击者可以伪造签名或解密数据。
• 公钥（Public Key）：由私钥乘以椭圆曲线基点 G 得到的曲线点坐标（x, y），共 64 字节，通常以 04 前缀标识为未压缩形式（总 65 字节）。

这里的「乘以」是椭圆曲线上的标量乘法（Scalar Multiplication）运算，正向计算容易，但反向计算——已知公钥求解私钥——被认为是数学不可行的。这正是 SM2 安全性的基础。

在实际使用中，密钥通常以两种编码方式输出：

• Hex 编码：以连续的十六进制字符表示（64 字符私钥 / 130 字符未压缩公钥）。
• Base64 编码：将二进制内容编码为 MIME 兼容的 ASCII 字符串，适合在 HTTP Header、JSON、Email 中传输。

值得特别说明的是：公钥的前一个字节在标准中用来区分「未压缩形式」（04）、「仅 x 坐标的压缩形式」（02 / 03），使用时请与系统方约定一致。

SM2 加密后产出的密文由三部分组成：

• C1：随机数点（椭圆曲线上的点，65 字节未压缩），用于在解密时还原对称密钥；
• C2：明文与密钥流异或后的密文数据，长度与明文相同；
• C3：对明文内容计算的 SM3 摘要（32 字节），用于完整性校验。

围绕这三部分的拼接顺序，业界长期存在两种主流规范：

C1C2C3（旧标准 / OpenSSL 传统顺序）：按「随机点 → 密文 → 摘要」拼接。这是许多早期国密实现的默认顺序，也是 OpenSSL 以及部分国产 HSM 曾使用过的格式。

C1C3C2（现行国家标准 / GM 标准）：按「随机点 → 摘要 → 密文」拼接。这是 GM/T 0003-2012 最新修订版中推荐与默认使用的标准排序，也是金融支付、电子证照、国密浏览器等主流实现采用的格式。

需要特别注意：两种格式在字节层面完全不兼容。使用本工具或对接第三方系统时，必须提前确认对方使用的格式，否则会出现「解密失败但无明确错误提示」的常见问题，调试成本较高。

SM2 在国内的应用已从政策性合规走向实质性生产部署。以下是 7 个最常见的生产级应用场景：

1. 金融支付签名：银行、支付机构使用 SM2 签名交易报文，替代 RSA。中国银联、部分商业银行已在 IC 卡与手机银行中使用 SM2 签名，符合人民银行关于国产密码应用的指导意见。
2. 电子政务与数字证书：政府机构向公民发放的「数字证书」（USB Key、软证书）以 SM2 为签名与加密核心，用于网上办事、电子签章、公文流转。
3. 移动 App 身份认证：App 客户端生成 SM2 密钥对，将公钥上传至服务端，随后用私钥对登录请求签名，服务端使用公钥验签，配合设备指纹实现高强度无感登录。
4. API 接口签名：开放平台使用 SM2 作为签名算法，替代传统的 RSA-SHA256。合作方使用各自的私钥对请求参数签名，平台使用已登记的公钥验证，保障接口不可伪造。
5. 物联网设备安全：智能电表、摄像头、车联网 T-BOX 等设备出厂时预置 SM2 证书/公私钥对，用于向网关上报数据时的签名与数据加密，保障供应链及设备身份可信。
6. 电子签章与合同存证：电子合同平台使用 SM2 配合时间戳，对签署人身份、签署时间、合同原文做签名；发生争议时可由第三方机构进行公开验签，具备法律效力。
7. 数字身份与国产 VPN：国产 VPN、零信任（ZTNA）网关使用 SM2 进行设备鉴权与握手密钥协商，与国密浏览器的 TLS-SM 套件配合，构建端到端的可信通信链路。

SM2 只是可选的非对称算法之一。在落地之前，通常需要结合合规要求、性能预算、生态成熟度三方面进行选择：

与 RSA 对比：RSA 的最大优势是生态极其成熟，几乎所有语言、库、浏览器和证书体系都原生支持。但 RSA 在相同安全强度下密钥长度约为 SM2 的 12 倍，运算速度明显更慢。对于国内应用，若需要符合「等保 2.0」「金融科技安全」等政策要求，SM2 是更稳妥的选择；反之若主要服务海外用户，RSA 仍是默认。

与 NIST 曲线（ECDSA P-256 / secp256r1）对比：SM2 与 NIST P-256 在密钥长度、速度、数学原理上非常接近，区别主要在于曲线参数、哈希算法搭配与证书体系。SM2 搭配 SM3 使用，P-256 通常搭配 SHA-256；若系统只需对接国际标准体系，P-256 仍是最通用的选择。

综合选择建议：

• 国内金融/政务类系统或需符合国密政策要求的场景：默认选择 SM2；
• 出海项目、对接海外开放平台：选择 RSA-2048 或 ECDSA P-256；
• 系统内部使用且无合规要求：二者任选其一，但建议统一选择 ECC 族（ECDSA 或 SM2），长期来看更具性能优势。

在实际调试中，SM2 最常见的问题往往不是算法本身，而是参数、编码、格式与约定不一致。以下是高频错误及排查方向：

1. 密文顺序不匹配：最常见错误。一方按 C1C2C3 输出，另一方按 C1C3C2 解密。建议在接口文档中用字段名或明确标注「C1C3C2」/「C1C2C3」，并在联调前用一个已知对拍示例进行校验。
2. 签名的 UserID 不一致：SM2 数字签名需要双方约定一个「用户标识」（UserID，十六进制，常见默认值为 31323334353637383132333435363738，即 ASCII 的 "1234567812345678"）。任何一方忘记传 UserID 或使用默认字符串不一致，都会导致验签失败。
3. 公钥前导字节（04）处理不当：部分库会自动跳过/添加公钥前导的 04 字节，另一部分不会。请统一：要么永远传递 04 前缀的 130 Hex 字符，要么永远剥离 04 前缀传递 128 Hex 字符，并在文档中明确说明。
4. 编码混用（Hex vs Base64 vs 二进制）：签名结果/密文既可以 Hex 表示，也可以 Base64 表示，两者长度不同。如果客户端以 Base64 传密文，服务端按 Hex 解析，必然失败。建议在文档中对输入输出编码给出明确要求。
5. SM3 vs SHA-256 的混淆：SM2 标准中签名/摘要使用 SM3 哈希。若误以 SHA-256 替代 SM3，签名会看起来「格式正确」但验签不通过。请检查库的默认算法参数。
6. 密钥长度/格式异常：SM2 私钥必须恰好为 32 字节（64 Hex 字符）。若输入的是 30 字节或 33 字节的内容，部分库会静默截断或填充，导致「加解密成功但结果错误」这种难以排查的现象。

SM2 的数学安全是基础，而真正决定系统安全的是密钥的生成、存储、轮换与使用流程。以下是可落地的最佳实践建议：

• 密钥生成必须使用密码学安全的随机数（CSPRNG）。绝不要使用确定性方法或业务数据派生私钥。
• 生产私钥必须在加密容器中保存（HSM 硬件、Key Management Service、或至少以 PKCS#8 + 口令加密的文件），禁止以明文形式存放在代码仓库、配置文件或 Docker 镜像中。
• 定期轮换签名密钥。通常建议 6–12 个月更换一次，并在旧密钥失效前预留 1–2 周的交叉过渡期（两种密钥同时被认可）。
• 公钥可以公开分发，但需要可信路径。建议通过证书（X.509 证书或 SM2 国密证书）、JWKS/国密密钥服务等方式进行公钥发布，避免被中间人替换。
• 禁止将同一密钥对同时用于签名和加密。虽然 SM2 数学上都支持，但从审计与安全职责分离角度，建议为签名与加密分别生成不同密钥对。
• 所有私钥操作应审计可追溯。对 HSM、KMS 的每次签名、解密操作写审计日志，记录操作人、时间、调用方。
• 配合 SM3 / SM4 形成完整的国密链路：数据传输使用 SM2（协商/签名）+ SM4（加密）+ SM3（摘要）形成闭环；对外部暴露的 API 接口再叠加 HTTPS，形成纵深防御。

最后请记住：SM2 的优势来自于短密钥、高性能与合规。在工程实践中，它的安全性高度依赖密钥管理与操作流程；再优秀的算法，搭配一个「私钥被提交到 GitHub」的工程团队也会失去全部保护。