背景
国密，是国家商用密码的简称，由国家密码管理局制定算法标准，同时也制定了大量的产品及接口规范以及应用场景。
随着近年来外部的国际贸易冲突和技术封锁，内部互联网的快速发展，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 位，用于替换 MD5/SHA1/SHA256 等国际算法
SM4：对称加密算法，密钥长度和分组长度均为 128 位，主要用于无线局域网标准，用于替换 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 规范开始编码，但结果有点遗憾，这个椭圆算法在 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 referencedpapers (in comments).
总结原因：这个算法是经过高度优化的算法，是精确适配过 NIST 和 ECRDSA 椭圆曲线参数的，并不一定适合国内的 SM2 曲线参数，看来这条路是走不通了......
......哭泣中，别理我。
......擦干眼泪，看成败，人生豪迈，不过是从头再来......
第三回
经过反复探索，发现内核中 RSA 算法是基于一个 mpi（高精度整数）库实现的，这个库来源于 libgcrypt（这是知名隐私保护软件 GnuPG 的底层算法实现）。内核中已经实现了一个早期版本的 mpi，当时就是为了实现 RSA 引入的。
现在的 libgcrypt 已经有了完整的椭圆曲线基础算法，于是抱着试试看的心态基于 libgcrypt 测试 SM2 算法曲线，苍天保佑，这次的惊喜没有变成惊吓，实验结果与 SM2 规范一致。
第四回
libgcrypt 中的 ECC 算法是个通用的算法，实现耦合度低。于是有了一个想法，可以尝试先在 libgcrypt 中实现 SM2，小试牛刀之后再把这一套东西全部移植到内核，进一步推进到社区，看起来这也是能被社区接受的方式。
有了计划后，索性摆个安逸的造型，庄严肃穆地将双手放在键盘上，让思维随着手指自然流淌，接下来的开发调试就比较顺利了，很快便有了公钥算法的四件套：加密，解密，签名，验签。
一鼓作气把这些实现提交到了 libgcrypt 社区，经过两轮的审核再修改之后，最终 SM2 算法作为 ECC 的一个子算法被社区接受，这里要感谢 libgcrypt 的维护者之一的 NIIBE Yutaka，耐心友好，对中国传统文化也很了解。整体过程比较顺利，表过不提。附上相关提交：
第五回
趁热打铁，由于内核中的 lib/mpi 库是一个较老的版本并且是为 RSA 服务的，相对于 libgcrypt 中的 mpi，是一个阉割的版本，需要移植缺失的函数以及 ECC 算法，这没什么技术难度，却也是一个精细活，工作量也不小。
在实践中，把实现 SM2 的过程中所缺失的东西都移植过来，很快便有了相应的 SM2 算法和国密证书的实现。再经过几轮打磨，并做了充分的测试后，就有了最初的这组补丁： https://lkml.org/lkml/2020/2/16/43
第六回
中国古语曰过，一鼓作气，再而衰，三而竭，事情的进展再次遇到阻碍。Linux 内核比不得专用的密码学库，对于这么一个不怎么知名的算法，社区并没有表现出什么兴趣，甚至鲜有人问津，最终以没有实际应用场景而被拒绝。事情当然不能就这么结束，考虑到代码量大，维护者审核意愿低，果断裁剪掉了 SM2 的加解密和签名，只保留了支持国密证书必要的验签功能，后来陆陆续续又做了一些小修小补，同时给 IMA 的上游做了国密算法的增强以便将国密功能在 IMA 场景的应用作为实际案例。
同时，随着跟相关开发者和维护者不断的软si磨chan硬lan泡da，不断地发送新的补丁，最后甚至都摸透了维护者习惯性的回复时间和补丁的合入规律，持续地缓慢推进 SM2 进入社区的步伐。这期间没有波澜壮阔的故事，也没有狗血的剧情，balabalabala......，省略while (1) {...} 循环。
第七回
年过中秋月过半， 历时半年多时间，SM2 早已不是那个最熟悉的娃，不知不觉补丁也更新到了 v7 版本。中秋月圆之夜向来都是有大事要发生的。是夜，一个盖世英雄，头顶锅盖，腰缠海带，脚踩七彩祥云飞过来了，SM2 终于等到了它的至尊宝。言归正传，这个版本的补丁最终被社区接受，目前已经合并到了 Linux 主线的 5.10-rc1：
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=Tianjia+Zhang
如不出意外会在 5.10 内核版本中正式发布。
libgcrypt 全面支持国密算法
后来有幸在某个机缘巧合之下，在 libgcrypt 中实现了 SM4。作为国密开发过程的一个附属产物，目前 libgcrypt 已经全面支持了国密算法 SM2/3/4，这些实现都会在下一个版本 1.9.0 正式发布。其中 SM3 由相关同事在 2017 年开发。
ima-evm-utils 支持 SM2-with-SM3 国密签名
内核已经支持了 SM2 和国密证书，作为 IMA 完整性签名的用户态工具，ima-evm-utils 对国密的支持当然不能落下，附上相关的提交：
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 只能支持内建编译（Y），而不支持编译成模块（M），让 X509 在编译时就知道已经支持 SM2，才能正常验签国密证书。从实现上看，也有一些动态加载 SM2 模块获取获取函数指针的方法，相比于框架层的支持，都不是很友好。
IMA 签名在计算文件哈希的时候，内核是直接计算文件哈希的，这块并没有针对是否使用 SM2 签名而做特殊处理（指上图中的增加 Za 值）。当下内核做的 IMA 国密签名验证的支持，同时也支持了 ima-evm-utils 的国密 sm2+sm3 签名（依赖最新的 openssl），目前这块都是直接计算文件哈希，没有加 Za 值，这也是当下最优的方案。
需要说明的一点是，Za 是国密签名以及验签里要求的，只是签名验签的流程里需要，但是国密这个流程跟目前主流的算法是相悖的，如果要支持，内核和 ima-evm-utils 工具都需要较大修改，内核要涉及到架构修改，社区也不愿意接受，所以目前就按主流方式支持了 sm2+sm3 的 IMA 签名。
总而言之，言而总之两条：
要支持国密证书验证，SM2 要么不编译，要么必须内建编译，不支持编译成模块。当然了，SM2 作为一个非对称算法，只签名一个哈希或者基于国密的 IMA 验证，并没有这个限制。IMA 签名工具 ima-evm-utils 以及内核计算文件 SM3 哈希所用的国密算法没有加 Za，这个是与规范的一点差异。
