直播回顧：如何基于Linux核心建構起商用密碼基礎設施？| 龍蜥技術

編者按：本文整理自 龍蜥大講堂技術解讀 ，分享主題為《建構商用密碼作業系統》，直播視訊回放已上線至龍蜥社群官網： 商用密碼作業系統如何建構？

，歡迎觀看。

作者張天佳，來⾃阿⾥雲作業系統團隊，是龍蜥社群商密軟體棧 SIG 負責人。主要研究⽅向為 OS 安全，包括可信計算，機密計算，⽬前專注于國内商⽤密碼的⼯程開發以及推廣⼯作，我們團隊主導開發了 Linux 核心、libgcrypt、OpenSSL 等多個項⽬中主要的商密算法⼯程化以及優化實作。

緣起

說到密碼算法，⼤家⼀定很熟悉 MD5、AES、RSA 這些通用的國際标準算法，這也是目前我們普遍采⽤的密碼學算法，它們在資料安全、網際網路、通信、區塊鍊等衆多領域都有着⼴泛的應用。

衆所周知，這些算法标準都是國外制定的，⼯程實作也主要由國外主導，在某些情況下這會對國内資訊安全有不利影響。當下有實力的國家，甚⾄有些大公司都制定了自己的算法标準。

密碼算法是保障資訊和資料安全的核⼼技術，随着近年來外部的國際貿易沖突和技術封鎖，國内網際網路的快速發展，我們不能單⼀依賴國外的的技術标準和産品，增強我國⾏業資訊系統的安全可信顯得尤為必要和迫切。商⽤密碼算法給我們提供了⼀個新的選擇，使得我們可以完全使用商密技術來建構⽹絡和資料安全環境。

是以，建立⼀套商⽤密碼的基礎設施就顯得尤為必要和迫切，本次分享帶給⼤家我們是如何基于 Linux 核心建構起商⽤密碼基礎設施，基于商⽤密碼的應⽤，以及未來的思考和規劃。

商用密碼簡介及現狀

商⽤密碼标準完全由中國密碼管理局制定，作為中國⾃主研發可控的密碼算法，主要的⼯程實作也基本是國内開發⼈員完成的，這對于擺脫國外的密碼技術和産品依賴，以及保護國内資料和網絡安全是非常有利的。

商用密碼，簡稱商密，拼⾳縮寫是 SM，⼝語中⼀般稱呼為國密，通俗來說可以認為是密碼算法的國産化，跟其它領域⼀樣，中國的商密算法為我們提供了⼀個新的選擇，在必要的場合中可以選擇替代那些國際主流算法，尤其是當下國際貿易沖突，技術封鎖不可忽視的⼤環境下，⼤規模推⼴和采⽤商密算法将為國内重要的網絡基礎設施提供可靠的資料安全保障。

近⼗多年來，國家密碼管理局陸續釋出了多項商⽤密碼⾏業标準，其中⼀些成為國家标準，很多基礎類的算法标準也陸續成為 ISO/IEC 國際标準，到⽬前為⽌，商⽤密碼标準已經⾮常成熟，也提供了完全⼀緻的算法接⼝和⽤戶體驗，完全可以⽤來替代主流的國際算法。

商密算法并不是⼀新技術，⾃ 2012 年以來，SM2/3/4 的商密标準陸續公布，⾄今⼗多年，商密商業應⽤基本處于⼀個相對空⽩的狀态，國内的商密軟硬體⽣态，技術⽅案實作存在很嚴重的碎⽚化情況，我們經常可以看到各種個⼈或組織名義開源的⽀持商密算法的庫，技術⽅案參差不齊，在安全更新和社群活躍度也做的不夠好，這也⼀定程度上限制了商⽤密碼的⼤規模應用；商密的推⼴仍然任重道遠，需要我們中國基礎軟體的開發者和⽤戶共同努力。

碎⽚化的⽣态就導緻沒有統⼀的技術⽅案，進而造成商密的産業化應⽤就特别的慢，導緻鮮有⼈願意為反哺商密⽣态，造成這樣⼀種惡性循環。尤其是目前的⼤背景下，密碼算法的國産化已經勢不可擋，這也是我們必須要做的事情。

2020 年 1 ⽉ 1 ⽇，《中華⼈⺠共和國密碼法》正式實施，從法律層⾯規範了國家商⽤密碼的應⽤和管理，這也為推⼴和應⽤商⽤密碼提供了必要的法律保障。

與國際算法的對比

這⾥是商密算法和國際通⽤算法的⼀個對⽐，可以直覺地看到商密的⼀個基本情況：

針對各種常⽤的國際能⽤算法類型，⽐如對稱算法，公鑰算法和消息摘要算法，商密标準都定義了對應的相同功能的商密算法，⽐如 SM4 提供了與 AES 同樣的加密強度，并且⽀持各種加密模式；SM2 是基于橢圓曲線的公鑰算法，同時定義了⾮對稱加解密，數字簽名和密鑰交換标準，相對于 RSA、SM2 的密鑰更短，但⽀持的加密強度卻更⾼；SM3 是商密定義的消息摘要算法标準，摘要⻓度是固定的 256 位，強度等同于 SHA256。

除了基礎的算法，商密标準也定義了 TLCP 商密雙證書協定，⽤以⽀持國内的傳輸層安全協定。這⾥還有⼀個好消息，今年三⽉份，TLS1.3+ 商密單證書協定正式被國際标準所承認，并且以 RFC8998 标準釋出，這意味着我們可以選擇在 TLS1.3 協定中使⽤完整的商密套件，⽬前我們也在聯系正規浏覽器⼚商⽀持這個标準的實施和應⽤。

同時商密标準也定義了使⽤商密算法的 X509 證書，使⽤ SM3 雜湊演算法，SM2 算法作為數字簽名，證書類型 SM2-with-SM3。

對開發者來說，商密提供了⼀個選擇，可以選擇從國際通⽤算法平滑遷移過來。除此之外，商密還有其它⼀些算法标準，是不太常⽤的，⽐如 SM9、ZUC 算法等。

商密基礎設施架構

萬事俱備，有了基礎商密算法⽀持，我們便可以建構出⼀個圍繞商密算法展開的基礎軟體⽣态。這是⼀個商密⽣态的垂直場景，也是我們在 Anolis OS 上的商密⽣态架構，同時它也是⼀個全棧商密解決⽅案：從底層固件、核心、到基礎密碼學庫，在主要鍊路上做商密改造，最終形成⼀個完整的基于商密的安全信任鍊條。

圖上右邊是⼀些垂直的商密應⽤場景，⽐如 SecureBoot、IMA、核心子產品簽名、⽂件完整性校驗等。

到⽬前為⽌，我們已經在 Linux 核心、BabaSSL、libgcrypt、Gnulib 等主流的基礎元件中⽀持了商密算法，這部分的⼯作都已經回饋到了上遊開源社群，有興趣的開發者可以直接拿來使⽤或者作為參考，⽬前實作的特性已經全部通過 Anolis 商密版 OS 輸出，關于這個商密版的 OS，後⾯會做⼀個詳細介紹。

從中也能看到，商密⽣态涉及到的軟體棧⾮常多，形态也是各種各樣，要逐漸完善這個⽣态，還有很⻓的路要⾛。近⼏年的國際技術封鎖也給了我們做這件事的決⼼和動⼒。

⽬前我們已經和 ARM，海光等⼚商有⼀些合作，也⾮常歡迎業界有興趣的開發者能夠參與到社群，⼀起來做這個事情，之後我們的⼯作都會在 Anolis 社群以開源⽅式運作，秉着開放包容态度，繼續補充完善這個⽣态，最終達到的⼀個⽬标是：整個安全信任鍊是完全建⽴在商密算法之上。

BabaSSL前世今⽣

BabaSSL 是主打商密的密碼算法庫，與 OpenSSL1.1.1 保持相容，作為商密的密碼算法解決⽅案⽽誕⽣。

BabaSSL 是基于之前螞蟻集團和阿⾥集團内部的 OpenSSL 版本合并⽽來，我們希望将 BabaSSL 打造成⼀個靈活、⼩巧并且健壯的基礎密碼學庫，項⽬主體已于2020 年 10 ⽉在 Github 開源（連結見文末），目前開源的版本是 8.2.1，也是⽬前最新的穩定版本。

BabaSSL 的主要發起者是螞蟻集團的楊洋，楊洋也是 OpenSSL 項⽬在國内唯⼀的 Maintainer，主導開發了其中商密相關的算法，并且組織制定了 RFC8998 規範，關于這個規範，後⾯也會詳細介紹。

BabaSSL ⽬前完全以社群⽅式動作，已經組建了技術委員會，由阿⾥和⾏業内其它公司主要開發者組成，技術委員會決策項⽬的發展⽅向以及營運⼯作。

BabaSSL ⽬前在阿⾥集團和螞蟻集團内部得到了⾮常⼴泛的使⽤。從具體場景來看，有如下三個⽅⾯，分别是存儲、網絡和端上的裝置。其中網絡服務的場景，是 BabaSSL 最⼤的⽀撐場景，例如淘寶、天貓、阿⾥雲等各種涉及到鍊路加密的伺服器端。此外移動端 App，例如⽀付寶⼿機 App 中內建了 BabaSSL 來實作多種密碼學的能力。

特⾊功能

以下是 BabaSSL 目前最新穩定版本 8.2.1 的主要特⾊功能特性：

• 基于 OpenSSL1.1.1，具備 OpenSSL1.1.1 的全部能⼒并且保持相容
• ⽀持商密 SM2、SM3 和 SM4，SM4GCM/CCM 模式算法
• 更加完善的 SM2 算法⽀持，⽐如 X.509 證書簽發、驗簽的⽀持，這是 OpenSSL1.1.1 欠缺的能力
• GM/T0024 和 TLCP 商密雙證書 TLS 協定
• ⽀持 RFC8998：TLS1.3+ 商⽤密碼算法套件
• 提供了對 IETF 正在标準化過程中的 DelegatedCredentials
• ⽀持 IETFQUICAPI 底層密碼學能力
• 正在申請軟體密碼子產品⼀級資質

與 OpenSSL 對⽐

接下來是⼤家很關⼼的 BabaSSL 和 OpenSSL 這種⽼牌的密碼算法庫之間的差別：

從圖上可以看到⼀些主要差別：

• 對于⼀些新的密碼學技術标準，BabaSSL 會采取⼀種相對激進的政策快速跟進，⽐如在 IETF 中⼀些正在标準化流程中的技術⽅案，例如 delegatedcredentials、compactTLS 等，會進⾏原型的實作和快速跟進，⽽ OpenSSL 則是相對保守，因為 OpenSSL 社群的政策是原則上隻實作已經釋出了的國際标準和國家标準。
• 在對于商密算法、商密協定、商密的監管合規、雲計算⼚商的深度內建、以及國産化硬體等⽅⾯，BabaSSL 會進⾏更加深度和⼴泛的⽀持，而 OpenSSL 則⽀持的⽐較有限。
• 對于 API 的易⽤程度，由于沒有曆史包袱，是以 BabaSSL 可以提供更加簡單易⽤的 API，而 OpenSSL 的 API 則相對複雜。
• 對于資源受限的嵌⼊式裝置，BabaSSL會進⾏體積裁剪和記憶體使⽤量的規劃，OpenSSL 則明确表示沒有相關的計劃。

社群回饋情況

我們在商密⽣态多年的開發⼯作已經全部回饋到了社群，其中絕⼤部分貢獻到了主流開源項⽬的上遊，包括 OpenSSL、Linux核心、libgcrypt、Gnulib 等，代碼量超過 23000 ⾏，圖中綠⾊打勾部分都是我們⾃主開發的。

以下是這些貢獻主要的成果：

• Gnulib 庫中實作了SM3 算法的基礎實作，Gnulib 是 GNU 軟體棧中⼀個通⽤的基礎庫
• 實作了 libgcrypt 中基礎的商密算法 SM2/3/4
• 實作了 Linux 核心⾥ SM2 算法，以及⽀持了使⽤ SM2/3 算法的 pkcs#7 簽名，X509 證書
• 使⽤ x86AVX2 指令集優化核心的 SM4 算法，相⽐于純軟體實作，有接近 8 倍的性能提升
• Linux 核心 Kernel TLS ⽀持使⽤ SM4GCM/CCM 算法
• IMA 場景⽀持使⽤ SM2/3 算法組合，包括核心和⽤戶态⼯具 ima-evm-utils 的⽀持
• 在 Rust ⽣态中主流算法庫 RustCrypto 中實作了 SM3 算法
• ⽀持 coreutils 社群實作 sm3sum ⼯具，⽬前以cksum -a sm3 方式在上遊社群支援
• OpenSSL 的 KTLS ⽀持以及商密實作上的若⼲問題修複
• QUIC、證書壓縮等還處于 RFC 階段的特性

經過幾年的努力，我們基本建起了商密的基礎軟體設施，當然這個⽣态不管是橫向還是縱向還有很多⼯作要做，需要更多開發者參與進來⼀起建設，我們⾮常歡迎與⼤家⼀起合作。

技術解讀

OpenSSLASYNC機制

OpenSSL ⾥的異步協程機制，這其實是⼀個與今天主題關系不⼤的技術點，主要是國為 OpenSSL ⾥實作了協程，我們也做了⼀些優化，是以做⼀個簡單介紹。

協程是近⼏年⽐較⽕的⼀個技術，⼀些主流語⾔都或多或少⽀持了協程，⽐如 rust 和 go，Nodejs 和 C 語⾔也有相應的技術或者協程庫。但是協程并不是⼀個新技術，Lua 在 18 年前的 5.0 版本中就已經原生⽀持了協程。

協程是⽤戶⾃主要制的任務排程單元，對作業系統來說是透明的，協程主要應⽤于異步⾼性能場景，⽤戶實作負責抽象異步的⾮阻塞和任務單元的排程，提供⼀個協程的開發和運⾏環境。

相比于其它⾼性能場景的解決⽅案，協程主要有以下優勢：

相⽐于線程，協程更輕量，協程占⽤的資源⾮常少，建立釋放也隻是⼀個函數調⽤，不需要核心參與。協程是⾃主排程的，⼀般隻在阻塞時主動選擇排程到其它協程，比起線程的搶占式排程，可控性更⾼，排程的成本也⾮常低，往往隻是⼀個函數調⽤。

也由于⾃主排程的特點，協程是沒有競争條件的，也就不需要同步，我們知道，同步問題往往是造成多線程程式設計的惡夢。

同步書寫，異步執⾏，這是協程相⽐于 nginx、nodejs 這種回調式⾼性能⽅案的最⼤優點，nginx 和 nodejs ⼯程⾥為了實作異步，使⽤了⼤量的回調，甚⾄是多級回調的嵌套，把同步⽅式中的串⾏流程打斷到多個回調函數中去執⾏，這當然是很⾼效的模式，也是他們的程式設計模型決定的，這⼀定程度也導緻了程式的可讀性差，可維護性低。

協程完美的解決了這個問題，在⼏乎不影響性能的前提下，把原來分散到若⼲回調函數中的⽚斷代碼集中起來，我們可以⽤串⾏⽅式來寫異步代碼，由協程背後的異步機制來負責排程串⾏的代碼⽚斷，達到同步書寫，異步執⾏的⼀個效果，左圖對這個概念表達的不太完整，每個協程是分散在若⼲的⽚斷中被執⾏的，但是我們作為開發者，不⽤考慮這些細節，隻需要采⽤同步的⽅式來編碼即可。

⽬前也已經有很多架構采⽤了這種模式，⽐如 openresty，rust ⾥的協程也是這樣的模式。

圖上是⼀個⾮常簡單的 TCPecho 伺服器僞代碼，采⽤了協程機制來實作，這可以讓我們對協程有⼀個直覺的感受，雖然是僞代碼，已經很接近真實的代碼實作，在⼀個協程⾥ listen，針對每個連接配接過來的用戶端，再開⼀個協程負責與這個用戶端互動，看起來跟同步多線程模型⾮常像，整個過程是⼀個同步的書寫模式，但背後是異步的協程在負責排程，性能也⽐同步多線程⾼了許多。

這是⼀個非常典型的場景，OpenSSL 由于需要實作異步 TLS，也實作了⼀個簡單的協程機制 ASYNC，可能由于 OpenSSL ⾥場景⽐較簡單的緣故，ASYNC 并不⽀持左圖中的這種程式設計模式，主要是它實作的⼀些缺陷造成的：

• 引⼊了 dispatcher 作為排程器，并存儲協程狀态
• 同⼀時間隻能存在⼀個協程
• 隻能在 dispatcher 和唯⼀的協程之間切換
• ⽆法⽀持左圖中的場景

是以我們在 BabaSSL 中引⼊了相應修複⽅案，⽬前已經在 BabaSSL 中得到了⽀持，同時也把這個修複以PR形式送出給了OpenSSL社群。

TLS證書壓縮

TLS 協定是基于 TCP 協定，但也有點類似于 TCP，TLS 連接配接建⽴之前會有⼀個握⼿過程，作為⼀個安全協定，用戶端⼀般會驗證服務端的身份，這是通過服務端的證書來完成的，經過我們調研，TLS 握⼿過程中的主要⽹絡流量就是消耗在證書傳輸上，尤其是存在過多的中間 CA 會導緻證書鍊成倍的增⼤，這種情況在雙向認證時也很明顯。

是以，在握⼿過程中對證書進⾏壓縮就很有必要，從握⼿過程上來看，用戶端會在 ClientHello 的擴充中告訴伺服器⽀持的壓縮算法清單，如果服務端也⽀持壓縮，會把壓縮過的證書傳輸給用戶端，進而減少不必要的流量消耗。

TLS 證書壓縮已經是 RFC 的标準規範，已經率先在 BabaSSL 中得到了⽀持，由于 OpenSSL 相對保守，現在仍然不⽀持這個特性。

證書壓縮⽬前⽀持三個壓縮算法，也⽀持使⽤字典⽅式壓縮。

開發者可以在 BabaSSL 中體驗證書壓縮特性：

#編譯時需要開啟TLS證書壓縮功能
./config enable-cert-compression
#如果是應⽤開發者，調⽤該API開啟證書壓縮功能
SSL_CTX_add_cert_compression_alg();
#s_server/s_client指令體驗
openssl s_server/s_client -tls1_3 -cert_comp zlib      

BabaSSL 在編譯時提供了⼀個開關選項，需要在編譯配置時打開，如果是應⽤開發者，需要調⽤圖中這個 API 在 SSLCTX 中⽀持使⽤證書壓縮。

⼀般⽤戶也可以通過 s_servers_client 指令來體驗這個功能，在指令⾏中指定證書壓縮選項以及對應的算法。

從我們的測試資料來看，普遍可以達到 70% 多的壓縮率，甚⾄在使⽤ zstd+ 字典模式時，壓縮率可以達到不到 1%，也就是說證書的流量被壓縮到了原來的 1% 不到。

使⽤證書壓縮功能，可以⼤⼤降低握⼿過程中的⽹絡傳輸消耗。

從實驗資料可以看到，就算加上除證書之外的其它握⼿階段，在整個握⼿過程中，傳輸的流量最低隻有原來的 20% 多⼀點，我們節省了 80% 的帶寬。

核心 SM4 算法優化

圖中是我們在 Linux 核心對 SM4 算法做的⼀個優化之後的性能資料，對⽐了純軟體實作，AVX 優化實作，AVX2 優化實作的性能，在 1024 ⼤⼩的 block 下，AVX2 的優化相⽐于純軟體實作，CTR 模式下的性能提升了近 8 倍。因為 CBC 和 CFB 加密時有塊依賴關系，⽆法進⾏并⾏的優化。

不像 AES 這種國際主流算法，各種架構 CPU 都有提供相應的指令集來做加速，SM4 就沒有這麼好的待遇了，x86 的 CPU 都是沒有這樣的指令集的，⽬前隻有 ARM 的 spec ⾥有優化指令集的定義，因為這是個可選的指令集擴充，是以主流的 ARM 芯⽚預設都選擇了不⽀持，當然這也與國密的整個⽣态影響力有關。

不過我們可以借助于 aesni 和 avx 指令集間接優化 SM4，通過兩次矩陣轉換和⼀次 AESSBOX 查表來實作⼀輪 SM4 優化，并且把這⼀系列操作⽤ AVX 指令集來并⾏化，最⾼可以達到 16 個塊并⾏計算，雖然看起來鍊路更⻓了，但都是在硬體層⾯的優化，實際的性能提升⾮常明顯。

Anolis商密版OS

以上我們主要介紹了 BabaSSL 和商密基礎軟體⽣态上做的事情，為了讓⽤戶能有⼀個直覺的體感，更快速的使⽤到商密的技術，我們把所有的技術⽅案都⽀持到了 OS 裡，以作業系統的形式提供給有需求的⽤戶。

為此，龍蜥社群開發了⽀持商⽤密碼的 OS 鏡像，⽀持了商⽤密碼基礎設施和應⽤開發⼯具包，同時⽀持了諸多商⽤密碼的應⽤場景，對安全合規，資料機密性，以及安全性要求較⾼的⽤戶可以基于這個商密⽣态開發出豐富的符合⾃身需求的商密應⽤。

Anolis 商密版 OS 是國内⾸家從作業系統層⾯提供商⽤密碼的 OS 解決⽅案，在保持 100% 相容普通 Linux OS 的基礎上，從核心到應⽤層基礎算法庫的全鍊路上完整⽀持了商密算法，以及基于商密算法的安全認證機制，完全抹平了商密使⽤⻔檻，提供給有需求的⽤戶⼀個開箱即⽤的作業系統環境。這⾥⾮常感謝 OpenAnolis 社群提供給我們這樣⼀個平台，⽬前項⽬源碼完全在社群開源，也歡迎⼤家能夠參與以及貢獻。

有興趣的⽤戶可以從以下位址下載下傳體驗，為了⽅便⽤戶體驗，同時提供了 ISO 鏡像和虛拟機鏡像（連結見文末）。

Anolis 商密版 OS ⽀持以下主要的特⾊功能：

• 使⽤ BabaSSL 替代 OpenSSL 作為系統預設的基礎密碼算法庫
• linuxkernel ⽀持完整的 SM2/3/4 算法以及使⽤商密算法的 PKCS#7 簽名和 X509 證書
• 提供給開發者 SM2/3/4 商密算法基礎庫以及使⽤商密算法的 X509 證書以及 SM2 簽名能⼒
• 提供 GM/T0024 和 TLCP 商密雙證書協定基礎庫
• ⽀持 RFC8998 協定開發，在 TLS1.3 中使⽤商密算法套件
• 内置了sm3sum⼯具，提供與sha256sum，md5sum類似⼯具⼀緻的⽤戶體驗

除此之外，對于業界領先的 QUICAPI 底層密碼學能力，以及 IETF 正在标準化過程中的 DelegatedCredentials 也做了⽀持。

商密應用場景

基于 Linux 核心和 BabaSSL 提供的通⽤的商密技術⽅案，可以開發出各種使⽤商密的産品和應⽤，以下⼏個場景是我們做的商密化改造的典型場景。

HTTPS、Web 場景的商密化改造

目前的互聯⽹時代，密碼學應⽤最⼴泛的⽆疑是 HTTPS，衆所周知，HTTPS 是建構在 TLS 協定之上的，TLS 是當之⽆愧的網際網路通信背後的安全基⽯，是以，我們要在 HTTPS 中使⽤商密算法，隻需要考慮在 TLS 協定中⽀持商密算法。

⾮常榮幸，IETFRFC8998 規範在 2021 年 3 ⽉正式釋出，這個規範是由螞蟻集團主導完成的，規範完整定義了在 TLS1.3 協定中使⽤商密算法套件的辨別，以及 TLS1.3 要求的算法定義。主要内容包括兩個對稱加密算法 TLS_SM4_GCM_SM3， TLS_SM4_GCM_SM3、數字簽名sm2sig sm3以及在密鑰交換中使⽤ SM2 曲線的辨別。 

目前版本的 BabaSSL 已經完整實作了 TLS1.3 和 RFC8998 中定義的商密套件，圖中是 Wireshark 的⼀個抓包，可以看到 TLS 協定是完全建構在商密算法之上的。

另⼀⽅⾯，TLS 的産業化應⽤還要考慮很多問題，從技術上來說，商密的性能是不⾜的，為此，我們為 TLS 商密化做了很多的優化，降低了商密的應⽤成本，使得⼤規模商⽤變得可能。

我們主要以以下⼏個⽅⾯做了優化：

• ⽀持了 TLS 的 offload 到核心，⽬前是純軟的 SWKTLS，這在資料量較⼤的 TLS 場景下減少了不必要的兩次資料拷⻉，性能提升⽐較明顯
• 更進⼀步的，使⽤AVX2指令集優化了核心SM4算法，達到了近8倍的性能提升，讓KTLS可以充分利⽤到這部分性能優化，這個優化⼤幅度提升了TLS商密的性能

還有更徹底的NIC KTLS優化，TLS offload 到硬體⽹卡上去，這需要業界同胞們的共同努力。

IMA 和 modsign 商密化

我們知道，密碼學算法從來就是為安全服務的，我們來看兩個在安全領域具體商密改造的例⼦。 

IMA 是 Linux 核心提供⼀個⽂件完整性度量架構，⽤于檢測⽂件是否被惡意篡改，核心子產品簽名的⽬的是類似的，⽤于檢測子產品的發⾏源頭是否可信，是否在分發途中被惡意篡改。它們都提供了自己的簽名⼯具，簽名⼯具依賴BabaSSL提供的SM2 簽名⽂件的能⼒，⽤于在⽤戶态做簽名。

⽂件簽名的驗證是在核心⾥完成的，由于核心不能直接使⽤應⽤層的庫，為了⽀持在 Linux 核心⾥驗證⽂件簽名，我們在核心⾥實作了商密 SM2/3/4 算法以及商密證書的⽀持，⽤來驗證簽名是否合法。

通過對相應軟體棧的改造，我們完全基于商密算法建構了 IMA 和核心子產品簽

名的安全機制，⽽這些之前都是由國際算法來保證的。

Anolis 商密軟體棧 SIG

以下是我們在 OpenAnolis 上的商密軟體棧 SIG，⾮常歡迎有興趣的開發能參與到社群中來，為中國的基礎軟體安全添磚加瓦。 

SIG位址：

https://openanolis.cn/sig/crypto

代碼庫：

https://codeup.openanolis.cn/codeup/crypto

Github開源連結：

https://github.com/BabaSSL/BabaSSL

ISO 鏡像和虛拟機鏡像：

https://mirrors.openanolis.cn/anolis/8.2/isos/ShangMi/

相關閱讀：

Anolis商密OS最佳實踐之核心子產品簽名商密化 國内首家商密OS重磅釋出，Anolis商密版OS為使用者資料保駕護航 Anolis商密OS最佳實踐之IMA商密化

—— 完 ——

加入龍蜥社群

加入微信群：添加社群助理-龍蜥社群小龍（微信：openanolis_assis），備注【龍蜥】拉你入群；加入釘釘群：掃描下方釘釘群二維碼。歡迎開發者/使用者加入龍蜥社群（OpenAnolis）交流，共同推進龍蜥社群的發展，一起打造一個活躍的、健康的開源作業系統生态！

關于龍蜥社群

龍蜥社群(OpenAnolis)是由企事業機關、高等院校、科研機關、非營利性組織、個人等按照自願、平等、開源、協作的基礎上組成的非盈利性開源社群。龍蜥社群成立于2020年9月，旨在建構一個開源、中立、開放的Linux上遊發行版社群及創新平台。

短期目标是開發龍蜥作業系統(Anolis OS)作為CentOS替代版，重新建構一個相容國際Linux主流廠商發行版。中長期目标是探索打造一個面向未來的作業系統，建立統一的開源作業系統生态，孵化創新開源項目，繁榮開源生态。

龍蜥OS 8.4

已釋出，支援x86_64和ARM64架構，完善适配Intel、飛騰、海光、兆芯、鲲鵬晶片。

歡迎下載下傳：

https://openanolis.cn/download

加入我們，一起打造面向未來的開源作業系統！

https://openanolis.cn