简介面向需要实现SM2签名验证的C语言开发者该资源基于goldboar的SM2签名程序改写专注验签场景符合GM/T 0003.5-2012规范参数。压缩包共3个文件包括2个C源文件与1个头文件体积仅5KB代码精简。已有3065人学习适合研究国密算法或集成SM2验证逻辑的工程师参考。函数以外部传入的(x,y)公钥和(r,s)签名作为输入仅执行验签操作同时优化内存释放并在Release编译时利用_DEBUG宏跳过椭圆曲线参数重复校验兼顾安全与效率。改动思路清晰对比原始实现能帮助理解国密算法工程化中的参数选择与代码裁剪方法是轻量实用的SM2验签参考实现。 接手一个物联网网关项目时客户要求在固件启动流程里加入SM2签名验证用于校验升级包的完整性和合法性。MCU主频只有200MHz左右跑不了完整的Linux环境只能用C语言在裸机代码里做验签。这个场景在嵌入式开发里越来越常见设备端持有SM2公钥上位机或产线工具用私钥签名固件在启动时用公钥验签。折腾两周之后我把验签链路完整跑通了这里把关键思路和踩过的坑都整理出来给同样需要做国密SM2验签的朋友一个参考。1. 为什么偏偏用C语言做SM2验签1.1 从业务需求到技术选型在智能设备、电力终端、工业控制器这类场景里签名验证通常是“启动时做一次”而不是像PC端那样可以随时调用成熟库。目标平台可能只有几十KB内存没有操作系统除了标准库之外没有任何依赖。C语言在这种环境里几乎是唯一选择既能直接操作内存和寄存器又能把编译产物控制得很小。我当时的嵌入式工程里RTOS占用资源已经不少留给验签功能的预算只有几十KB Flash和几KB RAM所以从需求阶段就排除了Java、Python这些方案。还有一点经常被忽略验签是要公开验证的所以公钥和验签代码可以放在设备端而私钥永远只存在于签名端。这种不对称结构决定了验签侧不需要处理私钥、不需要生成随机数代码路径比签名要简单很多也更容易用C语言从一个比较轻量的角度实现。需求评估时先把这点想清楚后面开发和测试的范围都会清晰很多。1.2 C语言相比其他语言的三个优势在SM2验签这件事上C语言的优势主要体现在三个方面。第一是可控性你可以精确管理每个字节的字节序、每个缓冲区的大小尤其是在处理ASN.1 DER格式时C语言能够直接按字节解析不容易被框架“帮你做掉一些事”之后反而搞不清楚数据格式。第二是可移植性编译一次就能放到M0、M3、M4甚至MIPS核上跨架构迁移成本低。第三是性能可预测通过内联函数和查表优化可以让点乘运算的耗时落在可接受的范围内这对于有实时性要求的启动流程很重要。当然C语言的缺点也很明显没有现成的对象模型大数运算要自己管理进位和借位内存溢出和指针错误随时可能让固件崩溃。但反过来看正是因为这些“麻烦”让开发者对SM2算法本身的每个细节都理解得更深遇到问题排查起来反而更直接。我在调试字节序问题时就体会到如果当时用的是带自动字节序转换的高层语言很可能根本不会意识到问题出在格式转换上。1.3 用库还是自己造轮子实际开发中要不要从零实现SM2验签是个需要认真权衡的问题。如果你的目标平台是资源充足的Linux网关完全可以使用OpenSSL、mbedTLS这类成熟密码库它们已经支持SM2验签直接调用接口就能跑通省时省力。但如果你和我一样要把代码放到一个没有操作系统、没有动态链接库的MCU里那么就需要考虑两种路线要么移植一个裁剪过的密码库比如mbedTLS去掉不需要的算法要么基于大数运算自己实现SM2验签。我最终的选择是“中间路线”用OpenSSL在PC上做测试向量和结果对比在MCU端用轻量级大数运算库实现验签核心流程。这样既能快速验证算法正确性又能保证嵌入式端的代码完全可控。后面章节我会把这两种方案的接口和关键数据结构都展示出来大家可以根据自己的工程条件做选择。2. 验签前必须吃透的SM2数学流程2.1 验签标准流程拆解SM2数字签名验证的标准流程在GB/T 32918.2里写得很清楚但刚接触时容易被术语绕进去。我习惯把验签拆成五个步骤第一步拿到签名值(r, s)先检查它们是否都在[1, n-1]区间内这里n是SM2椭圆曲线的阶第二步用签名者身份标识、曲线参数和公钥计算ZA再用SM3对ZA和原文M的拼接做哈希得到摘要e第三步计算t(rs) mod n如果t等于0直接判定验签失败第四步计算椭圆曲线点(x1, y1) [s]G [t]P其中G是SM2曲线基点P是签名者公钥第五步计算R(ex1) mod n如果R等于r说明签名有效。这个流程里最容易被忽视的是为什么验签用的是[s]G [t]P而不是很多资料里写的只算[s]P因为SM2签名生成时实际构造了s (1d)^-1 * (k - r*d) mod n这类关系验签时把s和t分别作为G和P的倍数相加才能通过椭圆曲线离散对数关系把签名者的私钥d消掉。推导过程虽然需要翻一下线代和群论的底子但工程实现时直接按流程算就行。2.2 ZA、e、签名值这些“零件”是怎么组装的ZA的组成相当繁琐顺序是ENTLA、IDA用户身份标识、a、b、xG、yG、xA、yA其中ENTLA是身份标识的比特长度换算成2字节后的值a和b是SM2曲线方程y^2 x^3 ax b里的系数G是基点A是公钥点。默认用户身份标识IDA常取“1234567812345678”这一串ASCII字符对应的ENTLA是0x0080。这块组装顺序只要错一位最后验签结果就不可能通过而它又是纯内存拼接逻辑不会报错只能靠对比测试向量去定位。摘要e则是SM3(ZA || M)这里M是原始消息原文。注意SM3是国密哈希算法不是SHA-256也不是MD5。之前有人直接把e用SHA256算结果当然验不过。在C语言实现里建议先把ZA和M放进同一个缓冲区再一次性做SM3避免多次Update导致拼接管理的麻烦。缓冲区大小ZA固定64字节M根据实际长度动态处理。2.3 为什么一定要验证 r 和 s 的范围这一步看起来是纯防御实际是安全审计的硬要求。如果签名值r或s为0或者大于等于n那么攻击者可以构造一些边界情况绕过校验。比如不检查范围时r0且s0可能让(t0)分支走到而(t0)直接判失败还算好但在某些实现里模运算结果可能没有归一化导致后续点乘结果超出预期行为不可控。因此标准里明确要求先验区间规范之外的安全建议是任何非法范围内的签名值都直接返回失败不要继续走后续流程。范围检查还有一个工程上的好处它能提前把明显异常的报文过滤掉避免SM3和点乘这些相对耗时的计算被恶意输入触发变相提供了一点抗拒绝服务的能力。我在实现时单独写了一个check_range()函数循环体里用常数时间比较来处理避免基于比较时间泄露大数信息这部分后续会细说。2.4 不同编码方式下r和s的读取顺序网上很多SM2示例在签名时输出的是(r,s)但部分接口因为DER编码头不同会把s放前面导致验签方按r,s读到时完全对不上。这里要明确SM2标准签名输出是(r,s)DER编码SEQUENCE里同样先r后s。如果你的数据来源是OpenSSL的SM2签名结果需要注意OpenSSL对SM2签名默认会做DER编码解码时也要按SEQUENCE的顺序取出两个整数。另外在某些自定义协议里签名值可能直接被截断成两个32字节小端序整数这就要求在进入验签逻辑前先把字节序统一成大端因为椭圆曲线点运算和模运算都默认大端表示。可以在代码里写一个load_bignum_be()函数把输入的字节流按大端读取。把这层字节序问题处理清楚能避免一多半的“验签失败”排查时间。3. C语言实现的路由两种主流方案对比3.1 基于OpenSSL的快速验证方案如果你的目标环境是Linux或者可以链接OpenSSL那么直接用OpenSSL的EVP接口做SM2验签是最快的方式。OpenSSL 1.1.1及以后版本原生支持SM2核心思路是创建一个EVP_PKEY_CTX设置EVP_PKEY_SM2然后传入SM2公钥和SM3摘要上下文即可。不过OpenSSL的API封装层次比较高底层细节被隐藏如果后续要剪裁到MCU端还是要回到“裸”实现。下面这个简化伪代码展示了验签主流程的基本形态注意省略了错误处理和密钥导入细节#include openssl/evp.h #include openssl/ec.h #include openssl/sm2.h int sm2_verify_openssl(const unsigned char *msg, size_t msg_len, const unsigned char *der_pubkey, int pubkey_len, const unsigned char *der_sig, int sig_len) { const unsigned char *p der_pubkey; EVP_PKEY *pkey d2i_PUBKEY(NULL, p, pubkey_len); if (!pkey) return 0; EVP_MD_CTX *mdctx EVP_MD_CTX_new(); EVP_PKEY_CTX *pctx NULL; int ret EVP_DigestVerifyInit(mdctx, pctx, EVP_sm3(), NULL, pkey); if (ret 1) { ret EVP_DigestVerify(mdctx, der_sig, sig_len, msg, msg_len); } EVP_MD_CTX_free(mdctx); EVP_PKEY_free(pkey); return ret 1; }这段代码用的是EVP_DigestVerify接口它内部会自动做ZA和摘要拼接。前提是公钥里已经写入了ID信息或者使用默认IDA。如果你需要自定义IDA可以在EVP_PKEY_CTX里通过EVP_PKEY_CTX_set1_id()设置。不过OpenSSL的SM2实现要求使用SM3作为摘要不能换成SHA256这一点和国密标准是一致的。3.2 不依赖大数库的底层实现要点到了MCU端通常没有OpenSSL这时就需要自己管理256位大整数、椭圆曲线点乘和点加。很多人一听“自己实现大数”就害怕其实对于SM2验签来说我们只需要有限域Fp上的加减乘除、模逆、模乘以及椭圆曲线点加、倍点、点乘这几个核心运算。为了节省Flash建议使用固定长度的数组来表示256位大数而不是使用动态内存的多精度库。点乘运算建议采用“从左到右的二进制展开法”结合“预计算倍点表”。虽然不如Montgomery点乘优化彻底但在资源受限环境下可读性强也容易加入简单的功耗/时间侧信道防护。实际代码里我会维护一个bn_t类型本质是32字节数组再加一个溢出标志位模运算用Barrett reduction或者Montgomery reduction后者在硬件乘法器较快的Cortex-M上收益明显。3.3 核心数据结构与验签函数骨架不管用哪种大数实现验签的数据结构都可以抽象成三块公钥结构体、签名结构体和验签上下文。typedef struct { uint8_t x[32]; // 公钥点横坐标大端 uint8_t y[32]; // 公钥点纵坐标大端 } sm2_pubkey_t; typedef struct { uint8_t r[32]; // 签名r值大端 uint8_t s[32]; // 签名s值大端 } sm2_signature_t; typedef struct { uint8_t id[16]; // 默认用户标识 size_t id_len; sm2_pubkey_t pub; } sm2_verify_ctx_t;验签函数骨架如下它按前面2.1的五个步骤执行每步都写清注释方便对照标准int sm2_verify(const sm2_verify_ctx_t *ctx, const uint8_t *msg, size_t msg_len, const sm2_signature_t *sig) { bn_t r, s, n, t; bn_t e, R, x1; ec_point_t G, P, Q; bn_load(r, sig-r, 32); bn_load(s, sig-s, 32); bn_load(n, sm2_params_n, 32); if (bn_is_zero(r) || bn_is_zero(s)) return 0; if (bn_cmp(r, n) 0 || bn_cmp(s, n) 0) return 0; // 1. 计算 ZA 和摘要 e sm3_za_digest(ctx, msg, msg_len, e); // 2. t (r s) mod n bn_add_mod(t, r, s, n); if (bn_is_zero(t)) return 0; // 3. Q [s]G [t]P ec_point_t Qs, Qt; ec_mul(Qs, G, s); // [s]G ec_mul(Qt, P, t); // [t]PP 从 ctx-pub 导入 ec_add(Q, Qs, Qt); // 4. R (e Q.x) mod n bn_from_point_x(x1, Q); bn_add_mod(R, e, x1, n); // 5. 比较 R 与 r return bn_cmp(R, r) 0; }这个骨架忽略了误差处理和点无穷远判断实际工程中要补充当Q为无穷远点时验签失败t0已提前拦截。核心思想是把签名值、公钥点都转成大数然后按公式展开点乘点加。建议先实现一个ec_add并反复对照标准测试向量验证再往上叠验签流程。3.4 字节序和ASN.1 DER格式转换最容易被忽略的坑SM2签名值在标准接口里通常是ASN.1 DER编码的SEQUENCE里面包含两个INTEGER。但在裸机协议里很多设备为了省流量会把r和s各按32字节直接打包。所以C语言实现一定要有一个“输入适配层”先把外部格式统一成固定长度大端。比如从DER里解析时要检查INTEGER头里的长度字节防止多字节前导0带来的长度变化从原始32字节读取时要注意对方用的是大端还是小端。我见过不少联调半天不通过的情况最后发现只是公钥坐标的字节序反了。处理办法很简单写一个buf_to_bn()函数显式指定参数big_endian并在函数内部把每个字节按正确顺序填入256位数组。在解析DER时用ASN.1的TLV结构扫描一遍不要试图用memcpy直接拷贝因为DER整数可能带有前导0x00。这个适配层单独测试可以省下后面联调大量时间。4. 调试期内我踩过的几个坑4.1 公钥格式压缩、未压缩、混合格式别认错SM2公钥点在标准里可以有三种编码方式未压缩格式以0x04开头后跟64字节的x和y压缩格式以0x02或0x03开头后跟32字节xy需要根据x的奇偶性和曲线方程解出来混合格式以0x06或0x07开头x和y都有后再加一个冗余头。我在联调时客户设备传过来的公钥是压缩格式但我的代码只实现了未压缩解析结果每次验签都失败。后来加了压缩点的解压逻辑才算跑通。解压点其实不复杂先根据x计算右侧y^2 x^3 ax b mod p再在模p下开平方。SM2曲线参数a、b、p都是固定的直接硬编码即可。要注意开平方结果有两个取哪个y由压缩头0x02/0x03的奇偶性决定。这个逻辑在很多密码库里有现成实现但如果你打算纯手工实现需要准备一个模平方根函数可以用Tonelli-Shanks但SM2的p满足p mod 4 3可以直接用(p1)/4次幂计算。4.2 SM3拼接顺序对摘要的影响摘要e的计算顺序是SM3(ZA || M)这个顺序在标准里写得很明确但实际编码时每次都容易搞反。有相当一部分验签失败是“把这个顺序写成SM3(M || ZA)”导致的。为什么顺序这么重要因为哈希算法不具备交换性输入顺序变了摘要完全不同。解决办法是不要在验签函数内部临时拼接而是在定义SM3接口时专门提供一个两步调用sm3_update(za, 64); sm3_update(msg, msg_len);。这样代码读起来直观也不容易出错。还有一个坑是ZA里的IDA默认值。很多设备没有设置用户标识就直接用空字符串或设备序列号。标准里默认IDA是“1234567812345678”但只有双方协商一致时才有效。如果是跟某个不规范的第三方平台对接一定要确认对方使用的IDA到底是什么否则ZA算出来完全不同签名永远验不过。建议在调试阶段把ZA打印成HEX和标准测试向量或对方提供的值对一下能快速定位问题。4.3 大整数比较和模运算的常量时间问题签名验证虽然不需要保密私钥但它会处理不可信的输入数据。如果大整数比较函数在遇到不相等时提前返回攻击者可以通过测量通信耗时来推测签名值的有效位数从而逐位恢复数据。所以比较两个大数是否相等时我建议使用固定循环次数把所有字节都异或一遍再累加校验最后判断累加值是否为0。代码写起来很简单static int bn_eq_consttime(const uint8_t *a, const uint8_t *b, size_t len) { uint8_t diff 0; for (size_t i 0; i len; i) { diff | a[i] ^ b[i]; } return diff 0; }同样范围检查if (r n)不能用普通的大数比较后提前退出最好也采用常数时间实现。虽然嵌入式设备侧信道攻击的威胁等级通常不高但既然实现了验签顺手把比较函数写成常量时间并不难避免留下明显隐患。4.4 点加和倍点里的无穷远点处理这个坑比较隐蔽。在验签流程中如果计算出的Q点刚好是无穷远点也就是单位元那么Q.x并不存在直接取坐标去算R会得到随机结果。标准流程里t0已经拦截了一部分情况但依然存在t非0但[s]G [t]P等于无穷远的合法概率极低的情况。处理方式是在点加函数里增加一个检测如果结果是无穷远立即返回验签失败而不是继续用零坐标计算。我在实现时专门用一个字节标志位记录“点是否无穷远”所有点运算都检查这个标志位。用OpenSSL时它会自动处理无穷远情况。但在自研实现里这一小节往往被省略导致偶发验签失败且难以复现。我在排查一个“偶尔验签失败”的问题时最后发现就是点加返回了无穷远点而调用方没有检查将全零坐标当成了有效坐标。这个问题概率很低但一旦遇到排查要花很久。5. 关于工程落地我想再补充几句5.1 测试向量和回归测试怎么设计做SM2验签最怕的是“算法实现看起来对但拿到真实签名后要么总失败要么偶然失败”。我的建议是准备三类测试向量第一类来自国密标准文档里的官方示例包含固定私钥、公钥、消息和签名这是验证实现的底线第二类用OpenSSL的SM2接口自己生成签名再拿到C实现里验签可以批量构造几百组随机数据做压力测试第三类是异常输入比如r0、sn、DER格式截断、公钥不在曲线上、长度为0的消息这些用例用来保证非法输入不会被误判为有效签名。把这些用例固化成一个自动化测试脚本每次修改大数运算或点乘实现后都跑一遍。我在开发中因为改了一个模乘的进位逻辑结果导致边界输入验签失败如果没有回归测试这种问题很容易发散。测试本身不复杂但能省下后续很多排查时间。5.2 安全提醒常量时间比较和输入校验除了大数比较需要注意常量时间还有两个安全细节值得留意。一是验签结果的应用方式建议用volatile变量暂时保存结果再用一个延迟跳转或位掩码来决定是否接受升级包避免编译器优化掉安全检查也避免旁路攻击者通过功耗判断验签结果。二是所有来自外部的公钥和签名都要先做基础合法性检查公钥点坐标是否在曲线上可以代入曲线方程验证、签名值是否在合法区间、消息长度是否有上限。这些检查不需要花太多时间但能挡住大量无效报文。我见过某个实现把公钥点校验收在了SM3之后这虽然从算法上看不影响正确性但从安全角度看尽早丢弃非法公钥可以减少攻击面。推荐顺序是先解析输入再校验公钥和签名格式最后进入计算流程。5.3 横向扩展从验签走向签名、加密和密钥交换SM2算法族包含签名、加密和密钥交换三部分。如果C语言验签已经跑通再往上扩展签名生成和加密就顺理成章。签名生成比验签多一个随机数k和私钥d的处理需要额外实现一个安全的随机数发生器加密和解密则涉及KDF和异或运算整体复杂度会增加不少。不过验签核心的点乘、点加、域运算函数完全复用后续扩展成本并不高。我在项目里就是先做通验签再做签名和密钥交换的。整个过程总结成一条经验实现密码算法时先把数学公式翻译成模块再逐层组合最后补足边界条件和输入校验比直接抄一个整体流程安全得多也更容易测试和排查。每次改动后我都会先用标准测试向量验证一遍再丢一组随机数据跑回归这个习惯帮我挡住了不少潜在问题。本文还有配套的精品资源点击获取
嵌入式C语言实现SM2验签：从数学流程到工程踩坑实录
简介面向需要实现SM2签名验证的C语言开发者该资源基于goldboar的SM2签名程序改写专注验签场景符合GM/T 0003.5-2012规范参数。压缩包共3个文件包括2个C源文件与1个头文件体积仅5KB代码精简。已有3065人学习适合研究国密算法或集成SM2验证逻辑的工程师参考。函数以外部传入的(x,y)公钥和(r,s)签名作为输入仅执行验签操作同时优化内存释放并在Release编译时利用_DEBUG宏跳过椭圆曲线参数重复校验兼顾安全与效率。改动思路清晰对比原始实现能帮助理解国密算法工程化中的参数选择与代码裁剪方法是轻量实用的SM2验签参考实现。 接手一个物联网网关项目时客户要求在固件启动流程里加入SM2签名验证用于校验升级包的完整性和合法性。MCU主频只有200MHz左右跑不了完整的Linux环境只能用C语言在裸机代码里做验签。这个场景在嵌入式开发里越来越常见设备端持有SM2公钥上位机或产线工具用私钥签名固件在启动时用公钥验签。折腾两周之后我把验签链路完整跑通了这里把关键思路和踩过的坑都整理出来给同样需要做国密SM2验签的朋友一个参考。1. 为什么偏偏用C语言做SM2验签1.1 从业务需求到技术选型在智能设备、电力终端、工业控制器这类场景里签名验证通常是“启动时做一次”而不是像PC端那样可以随时调用成熟库。目标平台可能只有几十KB内存没有操作系统除了标准库之外没有任何依赖。C语言在这种环境里几乎是唯一选择既能直接操作内存和寄存器又能把编译产物控制得很小。我当时的嵌入式工程里RTOS占用资源已经不少留给验签功能的预算只有几十KB Flash和几KB RAM所以从需求阶段就排除了Java、Python这些方案。还有一点经常被忽略验签是要公开验证的所以公钥和验签代码可以放在设备端而私钥永远只存在于签名端。这种不对称结构决定了验签侧不需要处理私钥、不需要生成随机数代码路径比签名要简单很多也更容易用C语言从一个比较轻量的角度实现。需求评估时先把这点想清楚后面开发和测试的范围都会清晰很多。1.2 C语言相比其他语言的三个优势在SM2验签这件事上C语言的优势主要体现在三个方面。第一是可控性你可以精确管理每个字节的字节序、每个缓冲区的大小尤其是在处理ASN.1 DER格式时C语言能够直接按字节解析不容易被框架“帮你做掉一些事”之后反而搞不清楚数据格式。第二是可移植性编译一次就能放到M0、M3、M4甚至MIPS核上跨架构迁移成本低。第三是性能可预测通过内联函数和查表优化可以让点乘运算的耗时落在可接受的范围内这对于有实时性要求的启动流程很重要。当然C语言的缺点也很明显没有现成的对象模型大数运算要自己管理进位和借位内存溢出和指针错误随时可能让固件崩溃。但反过来看正是因为这些“麻烦”让开发者对SM2算法本身的每个细节都理解得更深遇到问题排查起来反而更直接。我在调试字节序问题时就体会到如果当时用的是带自动字节序转换的高层语言很可能根本不会意识到问题出在格式转换上。1.3 用库还是自己造轮子实际开发中要不要从零实现SM2验签是个需要认真权衡的问题。如果你的目标平台是资源充足的Linux网关完全可以使用OpenSSL、mbedTLS这类成熟密码库它们已经支持SM2验签直接调用接口就能跑通省时省力。但如果你和我一样要把代码放到一个没有操作系统、没有动态链接库的MCU里那么就需要考虑两种路线要么移植一个裁剪过的密码库比如mbedTLS去掉不需要的算法要么基于大数运算自己实现SM2验签。我最终的选择是“中间路线”用OpenSSL在PC上做测试向量和结果对比在MCU端用轻量级大数运算库实现验签核心流程。这样既能快速验证算法正确性又能保证嵌入式端的代码完全可控。后面章节我会把这两种方案的接口和关键数据结构都展示出来大家可以根据自己的工程条件做选择。2. 验签前必须吃透的SM2数学流程2.1 验签标准流程拆解SM2数字签名验证的标准流程在GB/T 32918.2里写得很清楚但刚接触时容易被术语绕进去。我习惯把验签拆成五个步骤第一步拿到签名值(r, s)先检查它们是否都在[1, n-1]区间内这里n是SM2椭圆曲线的阶第二步用签名者身份标识、曲线参数和公钥计算ZA再用SM3对ZA和原文M的拼接做哈希得到摘要e第三步计算t(rs) mod n如果t等于0直接判定验签失败第四步计算椭圆曲线点(x1, y1) [s]G [t]P其中G是SM2曲线基点P是签名者公钥第五步计算R(ex1) mod n如果R等于r说明签名有效。这个流程里最容易被忽视的是为什么验签用的是[s]G [t]P而不是很多资料里写的只算[s]P因为SM2签名生成时实际构造了s (1d)^-1 * (k - r*d) mod n这类关系验签时把s和t分别作为G和P的倍数相加才能通过椭圆曲线离散对数关系把签名者的私钥d消掉。推导过程虽然需要翻一下线代和群论的底子但工程实现时直接按流程算就行。2.2 ZA、e、签名值这些“零件”是怎么组装的ZA的组成相当繁琐顺序是ENTLA、IDA用户身份标识、a、b、xG、yG、xA、yA其中ENTLA是身份标识的比特长度换算成2字节后的值a和b是SM2曲线方程y^2 x^3 ax b里的系数G是基点A是公钥点。默认用户身份标识IDA常取“1234567812345678”这一串ASCII字符对应的ENTLA是0x0080。这块组装顺序只要错一位最后验签结果就不可能通过而它又是纯内存拼接逻辑不会报错只能靠对比测试向量去定位。摘要e则是SM3(ZA || M)这里M是原始消息原文。注意SM3是国密哈希算法不是SHA-256也不是MD5。之前有人直接把e用SHA256算结果当然验不过。在C语言实现里建议先把ZA和M放进同一个缓冲区再一次性做SM3避免多次Update导致拼接管理的麻烦。缓冲区大小ZA固定64字节M根据实际长度动态处理。2.3 为什么一定要验证 r 和 s 的范围这一步看起来是纯防御实际是安全审计的硬要求。如果签名值r或s为0或者大于等于n那么攻击者可以构造一些边界情况绕过校验。比如不检查范围时r0且s0可能让(t0)分支走到而(t0)直接判失败还算好但在某些实现里模运算结果可能没有归一化导致后续点乘结果超出预期行为不可控。因此标准里明确要求先验区间规范之外的安全建议是任何非法范围内的签名值都直接返回失败不要继续走后续流程。范围检查还有一个工程上的好处它能提前把明显异常的报文过滤掉避免SM3和点乘这些相对耗时的计算被恶意输入触发变相提供了一点抗拒绝服务的能力。我在实现时单独写了一个check_range()函数循环体里用常数时间比较来处理避免基于比较时间泄露大数信息这部分后续会细说。2.4 不同编码方式下r和s的读取顺序网上很多SM2示例在签名时输出的是(r,s)但部分接口因为DER编码头不同会把s放前面导致验签方按r,s读到时完全对不上。这里要明确SM2标准签名输出是(r,s)DER编码SEQUENCE里同样先r后s。如果你的数据来源是OpenSSL的SM2签名结果需要注意OpenSSL对SM2签名默认会做DER编码解码时也要按SEQUENCE的顺序取出两个整数。另外在某些自定义协议里签名值可能直接被截断成两个32字节小端序整数这就要求在进入验签逻辑前先把字节序统一成大端因为椭圆曲线点运算和模运算都默认大端表示。可以在代码里写一个load_bignum_be()函数把输入的字节流按大端读取。把这层字节序问题处理清楚能避免一多半的“验签失败”排查时间。3. C语言实现的路由两种主流方案对比3.1 基于OpenSSL的快速验证方案如果你的目标环境是Linux或者可以链接OpenSSL那么直接用OpenSSL的EVP接口做SM2验签是最快的方式。OpenSSL 1.1.1及以后版本原生支持SM2核心思路是创建一个EVP_PKEY_CTX设置EVP_PKEY_SM2然后传入SM2公钥和SM3摘要上下文即可。不过OpenSSL的API封装层次比较高底层细节被隐藏如果后续要剪裁到MCU端还是要回到“裸”实现。下面这个简化伪代码展示了验签主流程的基本形态注意省略了错误处理和密钥导入细节#include openssl/evp.h #include openssl/ec.h #include openssl/sm2.h int sm2_verify_openssl(const unsigned char *msg, size_t msg_len, const unsigned char *der_pubkey, int pubkey_len, const unsigned char *der_sig, int sig_len) { const unsigned char *p der_pubkey; EVP_PKEY *pkey d2i_PUBKEY(NULL, p, pubkey_len); if (!pkey) return 0; EVP_MD_CTX *mdctx EVP_MD_CTX_new(); EVP_PKEY_CTX *pctx NULL; int ret EVP_DigestVerifyInit(mdctx, pctx, EVP_sm3(), NULL, pkey); if (ret 1) { ret EVP_DigestVerify(mdctx, der_sig, sig_len, msg, msg_len); } EVP_MD_CTX_free(mdctx); EVP_PKEY_free(pkey); return ret 1; }这段代码用的是EVP_DigestVerify接口它内部会自动做ZA和摘要拼接。前提是公钥里已经写入了ID信息或者使用默认IDA。如果你需要自定义IDA可以在EVP_PKEY_CTX里通过EVP_PKEY_CTX_set1_id()设置。不过OpenSSL的SM2实现要求使用SM3作为摘要不能换成SHA256这一点和国密标准是一致的。3.2 不依赖大数库的底层实现要点到了MCU端通常没有OpenSSL这时就需要自己管理256位大整数、椭圆曲线点乘和点加。很多人一听“自己实现大数”就害怕其实对于SM2验签来说我们只需要有限域Fp上的加减乘除、模逆、模乘以及椭圆曲线点加、倍点、点乘这几个核心运算。为了节省Flash建议使用固定长度的数组来表示256位大数而不是使用动态内存的多精度库。点乘运算建议采用“从左到右的二进制展开法”结合“预计算倍点表”。虽然不如Montgomery点乘优化彻底但在资源受限环境下可读性强也容易加入简单的功耗/时间侧信道防护。实际代码里我会维护一个bn_t类型本质是32字节数组再加一个溢出标志位模运算用Barrett reduction或者Montgomery reduction后者在硬件乘法器较快的Cortex-M上收益明显。3.3 核心数据结构与验签函数骨架不管用哪种大数实现验签的数据结构都可以抽象成三块公钥结构体、签名结构体和验签上下文。typedef struct { uint8_t x[32]; // 公钥点横坐标大端 uint8_t y[32]; // 公钥点纵坐标大端 } sm2_pubkey_t; typedef struct { uint8_t r[32]; // 签名r值大端 uint8_t s[32]; // 签名s值大端 } sm2_signature_t; typedef struct { uint8_t id[16]; // 默认用户标识 size_t id_len; sm2_pubkey_t pub; } sm2_verify_ctx_t;验签函数骨架如下它按前面2.1的五个步骤执行每步都写清注释方便对照标准int sm2_verify(const sm2_verify_ctx_t *ctx, const uint8_t *msg, size_t msg_len, const sm2_signature_t *sig) { bn_t r, s, n, t; bn_t e, R, x1; ec_point_t G, P, Q; bn_load(r, sig-r, 32); bn_load(s, sig-s, 32); bn_load(n, sm2_params_n, 32); if (bn_is_zero(r) || bn_is_zero(s)) return 0; if (bn_cmp(r, n) 0 || bn_cmp(s, n) 0) return 0; // 1. 计算 ZA 和摘要 e sm3_za_digest(ctx, msg, msg_len, e); // 2. t (r s) mod n bn_add_mod(t, r, s, n); if (bn_is_zero(t)) return 0; // 3. Q [s]G [t]P ec_point_t Qs, Qt; ec_mul(Qs, G, s); // [s]G ec_mul(Qt, P, t); // [t]PP 从 ctx-pub 导入 ec_add(Q, Qs, Qt); // 4. R (e Q.x) mod n bn_from_point_x(x1, Q); bn_add_mod(R, e, x1, n); // 5. 比较 R 与 r return bn_cmp(R, r) 0; }这个骨架忽略了误差处理和点无穷远判断实际工程中要补充当Q为无穷远点时验签失败t0已提前拦截。核心思想是把签名值、公钥点都转成大数然后按公式展开点乘点加。建议先实现一个ec_add并反复对照标准测试向量验证再往上叠验签流程。3.4 字节序和ASN.1 DER格式转换最容易被忽略的坑SM2签名值在标准接口里通常是ASN.1 DER编码的SEQUENCE里面包含两个INTEGER。但在裸机协议里很多设备为了省流量会把r和s各按32字节直接打包。所以C语言实现一定要有一个“输入适配层”先把外部格式统一成固定长度大端。比如从DER里解析时要检查INTEGER头里的长度字节防止多字节前导0带来的长度变化从原始32字节读取时要注意对方用的是大端还是小端。我见过不少联调半天不通过的情况最后发现只是公钥坐标的字节序反了。处理办法很简单写一个buf_to_bn()函数显式指定参数big_endian并在函数内部把每个字节按正确顺序填入256位数组。在解析DER时用ASN.1的TLV结构扫描一遍不要试图用memcpy直接拷贝因为DER整数可能带有前导0x00。这个适配层单独测试可以省下后面联调大量时间。4. 调试期内我踩过的几个坑4.1 公钥格式压缩、未压缩、混合格式别认错SM2公钥点在标准里可以有三种编码方式未压缩格式以0x04开头后跟64字节的x和y压缩格式以0x02或0x03开头后跟32字节xy需要根据x的奇偶性和曲线方程解出来混合格式以0x06或0x07开头x和y都有后再加一个冗余头。我在联调时客户设备传过来的公钥是压缩格式但我的代码只实现了未压缩解析结果每次验签都失败。后来加了压缩点的解压逻辑才算跑通。解压点其实不复杂先根据x计算右侧y^2 x^3 ax b mod p再在模p下开平方。SM2曲线参数a、b、p都是固定的直接硬编码即可。要注意开平方结果有两个取哪个y由压缩头0x02/0x03的奇偶性决定。这个逻辑在很多密码库里有现成实现但如果你打算纯手工实现需要准备一个模平方根函数可以用Tonelli-Shanks但SM2的p满足p mod 4 3可以直接用(p1)/4次幂计算。4.2 SM3拼接顺序对摘要的影响摘要e的计算顺序是SM3(ZA || M)这个顺序在标准里写得很明确但实际编码时每次都容易搞反。有相当一部分验签失败是“把这个顺序写成SM3(M || ZA)”导致的。为什么顺序这么重要因为哈希算法不具备交换性输入顺序变了摘要完全不同。解决办法是不要在验签函数内部临时拼接而是在定义SM3接口时专门提供一个两步调用sm3_update(za, 64); sm3_update(msg, msg_len);。这样代码读起来直观也不容易出错。还有一个坑是ZA里的IDA默认值。很多设备没有设置用户标识就直接用空字符串或设备序列号。标准里默认IDA是“1234567812345678”但只有双方协商一致时才有效。如果是跟某个不规范的第三方平台对接一定要确认对方使用的IDA到底是什么否则ZA算出来完全不同签名永远验不过。建议在调试阶段把ZA打印成HEX和标准测试向量或对方提供的值对一下能快速定位问题。4.3 大整数比较和模运算的常量时间问题签名验证虽然不需要保密私钥但它会处理不可信的输入数据。如果大整数比较函数在遇到不相等时提前返回攻击者可以通过测量通信耗时来推测签名值的有效位数从而逐位恢复数据。所以比较两个大数是否相等时我建议使用固定循环次数把所有字节都异或一遍再累加校验最后判断累加值是否为0。代码写起来很简单static int bn_eq_consttime(const uint8_t *a, const uint8_t *b, size_t len) { uint8_t diff 0; for (size_t i 0; i len; i) { diff | a[i] ^ b[i]; } return diff 0; }同样范围检查if (r n)不能用普通的大数比较后提前退出最好也采用常数时间实现。虽然嵌入式设备侧信道攻击的威胁等级通常不高但既然实现了验签顺手把比较函数写成常量时间并不难避免留下明显隐患。4.4 点加和倍点里的无穷远点处理这个坑比较隐蔽。在验签流程中如果计算出的Q点刚好是无穷远点也就是单位元那么Q.x并不存在直接取坐标去算R会得到随机结果。标准流程里t0已经拦截了一部分情况但依然存在t非0但[s]G [t]P等于无穷远的合法概率极低的情况。处理方式是在点加函数里增加一个检测如果结果是无穷远立即返回验签失败而不是继续用零坐标计算。我在实现时专门用一个字节标志位记录“点是否无穷远”所有点运算都检查这个标志位。用OpenSSL时它会自动处理无穷远情况。但在自研实现里这一小节往往被省略导致偶发验签失败且难以复现。我在排查一个“偶尔验签失败”的问题时最后发现就是点加返回了无穷远点而调用方没有检查将全零坐标当成了有效坐标。这个问题概率很低但一旦遇到排查要花很久。5. 关于工程落地我想再补充几句5.1 测试向量和回归测试怎么设计做SM2验签最怕的是“算法实现看起来对但拿到真实签名后要么总失败要么偶然失败”。我的建议是准备三类测试向量第一类来自国密标准文档里的官方示例包含固定私钥、公钥、消息和签名这是验证实现的底线第二类用OpenSSL的SM2接口自己生成签名再拿到C实现里验签可以批量构造几百组随机数据做压力测试第三类是异常输入比如r0、sn、DER格式截断、公钥不在曲线上、长度为0的消息这些用例用来保证非法输入不会被误判为有效签名。把这些用例固化成一个自动化测试脚本每次修改大数运算或点乘实现后都跑一遍。我在开发中因为改了一个模乘的进位逻辑结果导致边界输入验签失败如果没有回归测试这种问题很容易发散。测试本身不复杂但能省下后续很多排查时间。5.2 安全提醒常量时间比较和输入校验除了大数比较需要注意常量时间还有两个安全细节值得留意。一是验签结果的应用方式建议用volatile变量暂时保存结果再用一个延迟跳转或位掩码来决定是否接受升级包避免编译器优化掉安全检查也避免旁路攻击者通过功耗判断验签结果。二是所有来自外部的公钥和签名都要先做基础合法性检查公钥点坐标是否在曲线上可以代入曲线方程验证、签名值是否在合法区间、消息长度是否有上限。这些检查不需要花太多时间但能挡住大量无效报文。我见过某个实现把公钥点校验收在了SM3之后这虽然从算法上看不影响正确性但从安全角度看尽早丢弃非法公钥可以减少攻击面。推荐顺序是先解析输入再校验公钥和签名格式最后进入计算流程。5.3 横向扩展从验签走向签名、加密和密钥交换SM2算法族包含签名、加密和密钥交换三部分。如果C语言验签已经跑通再往上扩展签名生成和加密就顺理成章。签名生成比验签多一个随机数k和私钥d的处理需要额外实现一个安全的随机数发生器加密和解密则涉及KDF和异或运算整体复杂度会增加不少。不过验签核心的点乘、点加、域运算函数完全复用后续扩展成本并不高。我在项目里就是先做通验签再做签名和密钥交换的。整个过程总结成一条经验实现密码算法时先把数学公式翻译成模块再逐层组合最后补足边界条件和输入校验比直接抄一个整体流程安全得多也更容易测试和排查。每次改动后我都会先用标准测试向量验证一遍再丢一组随机数据跑回归这个习惯帮我挡住了不少潜在问题。本文还有配套的精品资源点击获取
