背景

国密，是国家商用密码的简称，由国家密码管理局制定算法标准，同时也制定了大量的产品及接口规范以及应用场景。

随着近年来外部的国际贸易冲突和技术封锁，内部互联网的快速发展，IOT领域的崛起，以及金融领域的变革愈演愈烈。摆脱对国外技术和产品的过度依赖，建设行业网络安全环境，增强我国行业信息系统的安全可信显得尤为必要和迫切。

密码算法是保障信息安全的核心技术，尤其是最关键的银行业核心领域长期以来都是沿用3DES、SHA-1、RSA等国际通用的密码算法体系及相关标准。

2010年底，国家密码管理局公布了我国自主研制的“椭圆曲线公钥密码算法”（SM2算法）。为保障重要经济系统密码应用安全，国家密码管理局于2011年发布了《关于做好公钥密码算法升级工作的通知》，明确要求“自2011年3月1日起，在建和拟建公钥密码基础设施电子认证系统和密钥管理系统应使用国密算法。自2011年7月1日起，投入运行并使用公钥密码的信息系统，应使用SM2算法。”

自2012年以来，国家密码管理局以《中华人民共和国密码行业标准》的方式，陆续公布了SM2/SM3/SM4等密码算法标准及其应用规范。其中“SM”代表“商密”，即用于商用的、不涉及国家秘密的密码技术。

这其中值得我们关注的主要是以下公开的算法：

• SM2：基于椭圆曲线密码（ECC）的公钥密码算法标准，提供数字签名，密钥交换，公钥加密，用于替换RSA/ECDSA/ECDH等国际算法

• SM3：消息摘要算法，哈希结果为256 bits，用于替换MD5/SHA1/SHA256等国际算法

• SM4：对称加密算法，密钥长度和分组长度均为128 bits，主要用于无线局域网标准，用于替换DES/AES等算法

• 国密证书：这里的国密证书指的是使用国密算法（SM2-with-SM3）的标准X509格式证书，证书使用SM3作为哈希算法，使用SM2作为数字签名算法

• 国密SSL：采用国密算法，符合国密标准的安全传输协议，也就是SSL/TLS协议的国密版本

SM2进阶Linux内核之路

目前Linux内核已经较好的支持了SM3和SM4算法，这得益于无线局域网标准的广泛使用。但SM2算法和国密证书迟迟没有得到支持，也就无法基于国密来建立全栈可信和内核中的完整性验证，因此在内核中支持这一套体系也变得迫切起来。整个规划是：在内核中支持SM2算法和国密证书，在内部业务率先应用起来后，最终推进到社区。

整个流程下来，诸多不顺，权且记录下来。

第一回，有了规划，接下来就是考虑如何实施。但凡密码学算法，都会先考虑是否可以从openssl做移植。幸运的是，openssl对SM2/3/4支持得非常好，椭圆曲线算法的实现久经考验，非常成熟，而且最新版本也完整支持了国密证书。不幸的是，openssl的各个模块之间藕合度很高，要实现SM2和国密证书，需要移植openssl架构和基础设施代码，包括BIGNUM、ECC、X509等。这个工作量无疑是巨大的，即便实现了，这种方式也很难被社区接受，再三考虑权衡后，果断放弃了这条"捷径"。

第二回，发现了一个令人惊喜的事实：内核中已经有了一个椭圆算法的基础实现（crypto/ecc.c），何不尝试基于这个算法来做呢？于是参照SM2规范开始coding，但结果有点遗憾，这个椭圆算法在SM2上居然失效了，连最基本的点乘结果都是错的！纳尼？剧本不应该是这样的。于是发邮件咨询该算法的一个资深开发者，很快就得到了下面的回复（感叹天下还是好心人多）：

Shamir's trick algo is probably generic, but it's ecc_point_double_jacobian()
that is curve specific.

Algorithms are chosen that are fit curves I (and previous coders) used.
You need to check their properties carefully if you going to use them.

Some variants of used algos, that may fit other curves, are in referenced
papers (in comments).

总结原因：这个算法是经过高度优化的算法，是精确适配过NIST和ECRDSA椭圆曲线参数的，并不一定适合国内的SM2曲线参数，看来这条路是走不通了......

......哭泣中，别理我。 ......擦干眼泪，看成败，人生豪迈，不过是从头再来......

第三回，经过反复探索，发现内核中RSA算法是基于一个mpi（高精度整数）库实现的，这个库来源于libgcrypt（这是知名隐私保护软件GnuPG的底层算法实现）。内核中已经实现了一个早期版本的mpi，当时就是为了实现RSA引入的。现在的libgcrypt已经有了完整的椭圆曲线基础算法，于是抱着试试看的心态基于libgcrypt测试SM2算法曲线，苍天保佑，这次的惊喜没有变成惊吓，实验结果与SM2规范一致。

第四回，libgcrypt中的ECC算法是个通用的算法，实现藕合度低。于是有了一个想法，可以尝试先在libgcrypt中实现SM2，小试牛刀之后再把这一套东西全部移植到内核，进一步推进到社区，看起来这也是能被社区接受的方式。有了计划后，索性摆个安逸的造型，庄严肃穆地将双手放在键盘上，让思维随着手指自然流淌，接下来的开发调试就比较顺利了，很快便有了公钥算法的四件套：加密，解密，签名，验签。一鼓作气把这些实现提交到了libgcrypt社区，经过两轮的review再修改之后，最终SM2算法作为ECC的一个子算法被社区接受，这里要感谢libgcrypt的maintainer之一的NIIBE Yutaka，耐心友好，对中国传统文化也很了解。整体过程比较顺利，表过不提。附上相关commit：

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=search;s=Tianjia+Zhang;st=author

第五回，趁热打铁，由于内核中的 lib/mpi 库是一个较老的版本并且是为RSA服务的，相对于libgcrypt中的mpi，是一个阉割的版本，需要移植缺失的函数以及ECC算法，这没什么技术难度，却也是一个精细活，工作量也不小。在实践中，把实现SM2的过程中所缺失的东西都移植过来，很快便有了相应的SM2算法和国密证书的实现。再经过几轮打磨，并做了充分的测试后，就有了最初的这组patch：https://lkml.org/lkml/2020/2/16/43

第六回，中国古语曰过，一鼓作气，再而衰，三而竭，事情的进展再次遇到阻碍。Linux内核比不得专用的密码学库，对于这么一个不怎么知名的算法，社区并没有表现出什么兴趣，甚至鲜有人问津，最终以没有实际应用场景而被拒绝。事情当然不能就这么结束，考虑到代码量大，maintainer review意愿低，果断裁剪掉了SM2的加解密和签名，只保留了支持国密证书必要的验签功能，后来陆陆续续又做了一些小修小补，同时给IMA的upstream做了国密算法的增强以便将国密功能在IMA场景的应用作为实际案例。同时，随着跟相关开发者和maintainer不断的软（si）磨（chan）硬（lan）泡（da），不断地发送新的patch，最后甚至都摸透了maintainer习惯性的回复时间和patch的合入规律，持续地缓慢推进SM2进入社区的步伐。这期间没有波澜壮阔的故事，也没有狗血的剧情，balabalabala......，省略while (1) {...}循环。

第七回，年过中秋月过半， 历时半年多时间，SM2早已不是那个最熟悉的娃，不知不觉patch也更新到了v7版本。中秋月圆之夜向来都是有大事要发生的。是夜，一个盖世英雄，头顶锅盖，腰缠海带，脚踩七彩祥云飞过来了，SM2终于等到了它的至尊宝。言归正传，这个版本的patch最终被社区接受，目前已经merge到了Linux主线的5.10-rc1：

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=Tianjia+Zhang

，如不出意外会在5.10内核版本中正式release。

libgcrypt 全面支持国密算法

后来有幸在某个机缘巧合之下，在libgcrypt中实现了SM4。作为国密开发过程的一个附属产物，目前libgcrypt已经全面支持了国密算法SM2/3/4，这些实现都会在下一个版本1.9.0正式release。其中SM3由相关同事在2017年开发。

ima-evm-utils 支持SM2-with-SM3国密签名

内核已经支持了SM2和国密证书，作为IMA完整性签名的用户态工具，ima-evm-utils对国密的支持当然不能落下，附上相关的commit：

https://sourceforge.net/p/linux-ima/ima-evm-utils/ci/ceecb28d3b5267c7d32c6e9401923c94f5786cfb/log/?path=

已知问题

当下SM2还有一些问题需要注意：

• SM2 X509证书中没有为SM2公钥算法定义独立的OID标识，目前是识别OID_id_ecPublicKey标识默认当作SM2

• SM2规范没有为推荐的椭圆曲线参数定义OID标识，这也导致SM2算法仅有一个默认的椭圆曲线参数

• SM2规范中对消息签名时，除了要计算消息自身的SM3，同时SM2椭圆曲线参数和公钥都要参与到SM3的计算中来，SM2私钥签名是对最终的哈希结果做签名，这一规范定义是有点另类，这是与国际通用算法的一个主要差异：

正常情况下，X509证书解析与算法都被实现为独立的模块。正是由于SM2的这个规范会导致实现上的强藕合：X509证书验证时需要计算证书中tbs的SM3哈希，这个哈希同样需要椭圆曲线参数以及公钥数据，而这些数据是一次完整SM2验签过程中的临时数据，目前的内核中并没有提供这样的回调机制（当然这是SM2的特殊情况），这就把X509证书解析与SM2算法强绑到了一起，没法解藕。这也导致了应用该功能的一点限制，SM2只能支持builtin编译（Y），而不支持编译成模块（M），让X509在编译时就知道已经支持SM2，才能正常验签国密证书。从实现上看，也有一些动态加载SM2模块获取获取函数指针的方法，相比于框架层的支持，都不是很友好。

• IMA签名在计算文件哈希的时候，内核是直接计算文件哈希的，这块并没有针对是否使用SM2签名而做特殊处理（指上图中的增加Za值）。当下内核做的IMA国密签名验证的支持，同时也支持了ima-evm-utils的国密sm2+sm3签名（依赖最新的openssl），目前这块都是直接计算文件哈希，没有加Za值，这也是当下最优的方案。需要说明的一点是，Za是国密签名以及验签里要求的，只是签名验签的流程里需要，但是国密这个流程跟目前主流的算法是相悖的，如果要支持，内核和ima-evm-utils工具都需要较大修改，内核要涉及到架构修改，社区也不愿意接受，所以目前就按主流方式支持了sm2+sm3的IMA签名。

总而言之，言而总之两条：

• 要支持国密证书验证，SM2要么不编译，要么必须builtin编译，不支持编译成module。当然了，SM2作为一个非对称算法，只签名一个Hash或者基于国密的IMA验证，并没有这个限制

• IMA签名工具ima-evm-utils以及内核计算文件SM3哈希所用的国密算法没有加Za，这个是与规范的一点差异