終於!國密演算法被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 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 演算法和國密證書的實現。再經過幾輪打磨,並做了充分的測試後,就有了最初的這組修補程式: //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:

//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 對國密的支援當然不能落下,附上相關的提交:

//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 私鑰簽名是對最終的哈希結果做簽名,這一規範定義是有點另類,這是與國際通用演算法的一個主要差異: 

終於!SM2國密演算法被Linux內核社區接受了

正常情況下,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,這個是與規範的一點差異。

終於!SM2國密演算法被Linux內核社區接受了