商密SIG月度動態：檔案加密支援SM4演算法、Anolis 8.8將預設整合 | 龍蜥 SIG

商密軟體棧 SIG 目標：基於Anolis Linux，在整個系統軟體層面（包括硬體，韌體，bootloader，核心以及 OS）實現以商密演算法為主的全軟體棧商密作業系統，結束一直以來商密軟體生態碎片化的狀況，在技術方面打造社群和生態，在資質合規方面致力於為行業提供基於商密的作業系統資訊保安標準。

01 SIG 近況摘要

本月分別合入 Linux 核心上游和 Anolis 核心主線 commit 22個，程式碼量 6000 多行，包括效能最佳化，更多的國密場景支援，以及 Bugfix 等。

在保證相容性的同時，也為 OpenSSL 1.1.1 版本支援完整的 SM2 簽名和驗籤能力，會在即將釋出的 Anolis 8.8 中預設整合。

Linux 原生檔案系統加密子系統 fscrypt，支援使用 SM4 XTS/CTS 演算法加密檔案和目錄。

持續補齊 Linux 核心 Arm64 架構下的國密效能最佳化，涉及 SM3 以及 SM4 的諸多加密模式，包括 XTS/CTS/CMAC/GCM/CCM 等，Linux 核心上游也同步得到了支援，可以充分發揮出倚天的效能優勢。

商密 SIG 的重點專案 Tongsuo，成功獲得商用密碼產品認證，這是全球首個獲得該認證的開源專案，感謝螞蟻團隊對此專案的支援，點選 這裡瞭解詳細資訊。

02 SIG 月度詳細進展

1、國密 SM3/4 演算法效能最佳化

以下的最佳化全部針對 Arm64 架構，已在龍蜥核心 cloud-kernel 5.10 中得到支援，同時最佳化 patch 也都貢獻到了 Linux 核心上游。

以下各項的資料均是在倚天 710 的環境下，使用核心 tcrypt 模組測試得到的資料，資料經過了表格化處理，單位是 Mbyte/s。

• 支援了 SM3 的 NEON 指令集最佳化，相比於軟體實現，效能提升約 11%，下表是軟體實現 sm3-generic，NEON 最佳化和 Crypto Extension 最佳化的效能資料，其中橫座標是塊大小：

update-size    |      16      64     256    1024    2048    4096    8192
---------------+--------------------------------------------------------
sm3-generic    |  185.24  221.28  301.26  307.43  300.83  308.82  308.91
sm3-neon       |  171.81  220.20  322.94  339.28  334.09  343.61  343.87
sm3-ce         |  227.48  333.48  502.62  527.87  520.45  534.91  535.40

• 基於 SM4 的 MAC 演算法，支援了 CE 指令集的最佳化，效能提升約 85%，以下是最佳化前後的效能對比資料：

最佳化前：

update-size    |      16      64     256    1024    2048    4096    8192
---------------+--------------------------------------------------------
cmac(sm4-ce)   |  293.33  403.69  503.76  527.78  531.10  535.46  535.81
xcbc(sm4-ce)   |  292.83  402.50  504.02  529.08  529.87  536.55  538.24
cbcmac(sm4-ce) |  318.42  415.79  497.12  515.05  523.15  521.19  523.01

最佳化後：

update-size    |      16      64     256    1024    2048    4096    8192
---------------+--------------------------------------------------------
cmac-sm4-ce    |  371.99  675.28  903.56  971.65  980.57  990.40  991.04
xcbc-sm4-ce    |  372.11  674.55  903.47  971.61  980.96  990.42  991.10
cbcmac-sm4-ce  |  371.63  675.33  903.23  972.07  981.42  990.93  991.45

• SM4 演算法的 CTS/XTS 模式，支援了 CE 指令集最佳化，CTS 是 CBC 模式的一個變種，透過密文竊取技術支援加密任意長度的資料（CBC 只支援 16 位元組對齊的資料大小），主要用於檔名路徑的加密，XTS 模式在非變長的磁碟加密和檔案加密中應用廣泛，以下是最佳化前後的效能對比資料：

最佳化前：

block-size |      16       64      128      256     1024     1420     4096
------------+--------------------------------------------------------------
CTS-CBC enc |  286.09   297.17   457.97   627.75   868.58   900.80   957.69
CTS-CBC dec |  286.67   285.63   538.35   947.08  2241.03  2577.32  3391.14
    XTS enc |  117.17   430.56   732.92  1134.98  2007.03  2136.23  2347.20
    XTS dec |  116.89   429.02   733.40  1132.96  2006.13  2130.50  2347.92

最佳化後：

block-size |      16       64      128      256     1024     1420     4096
------------+--------------------------------------------------------------
CTS-CBC enc |  288.19   428.80   593.57   741.04   911.73   931.80   950.00
CTS-CBC dec |  292.22   468.99   838.23  1380.76  2741.17  3036.42  3409.62
    XTS enc |  224.68   798.91  1248.08  1714.60  2413.73  2467.84  2612.62
    XTS dec |  229.85   791.34  1237.79  1720.00  2413.30  2473.84  2611.95

• SM4 CCM/GCM 模式支援使用 CE 指令集最佳化，CCM 和 GCM 是帶認證的 AEAD 演算法，是 TLS 1.3 協議中非常主流的演算法模式，這也為 TLS 協議支援國密提供了效能保證。

CCM 模式是計算明文的 CBCMAC 認證碼，透過並行加解密操作和計算 CBCMAC 認證碼來達到最佳化的目的。GCM 模式是對密文計算 GHASH，因此加密時是先執行加密操作再計算 GHASH，透過同步加密四路的輸入來實現最佳化，解密時可以並行執行解密操作和計算 GHASH，但受 Arm64 SIMD 暫存器限制，只能同時處理三路的輸入，即便如此，解密的效能還是高於加密效能。

以下是最佳化前後的效能對比資料，測試環境同上，其中 mb 是核心使用 multi buffer 時的資料，最佳化前 CCM 的 driver 是 rfc4309(ccm_base(ctr-sm4-ce,cbcmac-sm4-ce))，GCM 的 driver 是 gcm_base(ctr-sm4-ce,ghash-generic)：

最佳化前：

block-size |     16      64      256      512     1024     1420     4096     8192
-----------+---------------------------------------------------------------------
CCM enc    |  35.07  125.40   336.47   468.17   581.97   619.18   712.56   736.01
CCM dec    |  34.87  124.40   335.08   466.75   581.04   618.81   712.25   735.89
CCM mb enc |  34.71  123.96   333.92   465.39   579.91   617.49   711.45   734.92
CCM mb dec |  34.42  122.80   331.02   462.81   578.28   616.42   709.88   734.19
GCM enc    |  25.24   64.65   104.66   116.69   123.81   125.12   129.67   130.62
GCM dec    |  25.40   64.80   104.74   116.70   123.81   125.21   129.68   130.59
GCM mb enc |  24.95   64.06   104.20   116.38   123.55   124.97   129.63   130.61
GCM mb dec |  24.92   64.00   104.13   116.34   123.55   124.98   129.56   130.48

最佳化後:

block-size |     16      64      256      512     1024     1420     4096     8192
-----------+---------------------------------------------------------------------
CCM enc    |  77.12  249.82   569.94   725.17   839.27   867.71   952.87   969.89
CCM dec    |  75.90  247.26   566.29   722.12   836.90   865.95   951.74   968.57
CCM mb enc |  75.98  245.25   562.91   718.99   834.76   864.70   950.17   967.90
CCM mb dec |  75.06  243.78   560.58   717.13   833.68   862.70   949.35   967.11
GCM enc    | 108.62  397.18   971.60  1283.92  1522.77  1513.39  1777.00  1806.96
GCM dec    | 116.36  398.14  1004.27  1319.11  1624.21  1635.43  1932.54  1974.20
GCM mb enc | 107.13  391.79   962.05  1274.94  1514.76  1508.57  1769.07  1801.58
GCM mb dec | 113.40  389.36   988.51  1307.68  1619.10  1631.55  1931.70  1970.86

2、檔案加密支援使用 SM4 演算法

fscrypt 是執行在核心檔案系統層面的加密庫，需要嵌入到真正的檔案系統中來提供檔案的加密功能，目前 ext4、f2fs、ubifs 已支援 fscrypt。fscrypt 的特點是不同的檔案可以使用不同的金鑰，同一檔案系統上也允許有加密和非加密的檔案，這對於多使用者非常有用。

fscrypt 除了檔名，不加密其它的檔案系統後設資料。fscrypt 透過 API 與使用者態互動，主要包括註冊金鑰和配置加密策略，使用者則透過使用者態命令列工具 fscryptctl 來完成互動。檔案加密被是國密一個重要的場景，因此我們為 fscrypt 和 fscryptctl 提供了國密的支援，SM4 XTS 模式用於加密檔案內容，SM4 CTS 模式用於加密檔名。

3、Anolis 8.8 將原生支援國密

一直以來，OpenSSL 1.1.1 都是國密的一個遺憾，也是一個痛點，這個版本的 SM2 簽名驗籤能力是有缺陷的，也不支援國密標準的 Za 值。但這個版本又是主流的發行版所使用的版本，也包括 Anolis 8 系列的系統。鑑於以上原因，龍蜥在保證相容的前提下，在系統預設原生的 OpenSSL 1.1.1 版本上支援了完整的 SM2 簽名能力，解決了上述的問題，該特性也會隨著下一個版本的 Anolis 8 系統的釋出而帶給使用者。

03 SIG 長期規劃

全棧商密演算法涉及到眾多的上下游元件、團隊、外部合作伙伴、上游社群，要儘可能團結其它團隊的力量，消除不必要的重複開發，擴大推廣和影響力，成為商密事實標準。

全棧商密演算法要求先具備從 boot 到業務執行環節各安全鏈路上所需的商密演算法，再針對各元件做針對性的最佳化，在社群版本擴大影響力後，也讓未來商業版相比社群版本帶來差異化優勢。

協助 BabaSSL 申請國密資質，為應用系統提供必要的合規屬性，也為有此需求的使用者可以遷移到這個系統上來，增加使用者的使用黏性，這也是一個主要的競爭優勢。

規劃支援的商密演算法場景：

• IMA 場景下使用商密演算法替代國際演算法

• 核心模組簽名認證流程的商密化支援

• Web 場景下的 RFC 8998 協議支援，即 TLS v1.3 協議中支援使用商密演算法套件

• 使用商密演算法支援 luks、dm-crypt 場景

• SecureBoot 中使用商密演算法替換國際演算法

• 核心 SM4 演算法的指令集加速實現

• coreutils 支援 sm3sum 工具

• WireGuard 場景國密化支援

• SM2 最佳化，類似於 NIST，主要最佳化點是 SM2 所用曲線的快速取模演算法

• 積極參與 OpenSSL 3.0.0 dev 開發，加速 release

• coreboot 等未來可能替代 UEFI 的韌體支援 SM 系統演算法

• gpg 支援使用商密演算法

• libssh 支援使用商密演算法

04 SIG 整體支援情況

當前相關的主要開源軟體棧對國密的支援情況以及社群回饋統計：

當前商密軟體棧的縱向指令集最佳化情況及效能提升：

• 效能提升資料是相比於純軟體實現的資料

• x86 架構的測試環境是 Intel i5-6200U 2.30GHz

• Arm 架構的測試環境是 T-Head Yitian-710 2.75 GHz

• ✅ 表示由 OpenAnolis 開發並已經貢獻到開源軟體中的特性

• “WIP”表示由 OpenAnolis 開發中的、或是開源軟體正在進行 review 的特性

• “Y”表示開源軟體已經支援且不是由 OpenAnolis 開發的

• ❌ 表示開源軟體尚未支援

• “-”表示開源軟體無需支援

更多詳情內容見商密軟體棧 SIG( openanolis.cn/sig/crypto )，歡迎各位感興趣的開發者加入共建。

—— 完 ——