SM2 國密算法被Linux 內核社區接受
國密，是國家商用密碼的簡稱，由國家密碼管理局製定算法標準，同時也制定了大量的產品及接口規範以及應用場景。隨著近年來外部的國際貿易衝突和技術封鎖，內部互聯網的快速發展，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 referenced
papers (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 場景的應用作為實際案例。同時，隨著跟相關開發者和維護者不斷的軟磨硬泡，不斷地發送新的補丁，最後甚至都摸透了維護者習慣性的回复時間和補丁的合入規律，持續地緩慢推進SM2進入社區的步伐。這期間沒有波瀾壯闊的故事，也沒有狗血的劇情，balabalabala……，省略while (1) {...}循環。
第七回
年過中秋月過半， 歷時半年多時間，SM2 早已不是那個最熟悉的娃，不知不覺補丁也更新到了v7 版本。中秋月圓之夜向來都是有大事要發生的。是夜，一個蓋世英雄，頭頂鍋蓋，腰纏海帶，腳踩七彩祥雲飛過來了，SM2 終於等到了它的至尊寶。言歸正傳，這個版本的補丁最終被社區接受，目前已經合併到了Linux 主線的5.10-rc1：
如不出意外會在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 對國密的支持當然不能落下，附上相關的提交：
已知問題
當下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，這個是與規範的一點差異。
致謝
感謝相關同學在開發過程中所做的測試工作，技術支持以及在openssl 所做的大量的國密支持工作
感謝社區的熱心開發者，NIIBE Yutaka，Gilad Ben-Yossef，Vitaly Chikunov，Jussi Kivilinna，Herbert Xu