背景

國密，是國家商用密碼的簡稱，由國家密碼管理局制定算法標準，同時也制定了大量的產品及接口規范以及應用場景。

隨著近年來外部的國際貿易沖突和技術封鎖，內部互聯網的快速發展，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，這個是與規范的一點差異。
責編AJX