資安

RFC8998+BabaSSL—讓國密駛向更遠的星辰大海

作者:曾柯
來源:金融級分佈式架構
本文主要介紹TLS 1.3 及國密。分成4部分
-01 引言-TLS 1.3 協議及 SM 算法
-02 why 國密?why not 國密?
-03 重磅推出,TLS 1.3+ 國密算法套件
-04 總結

01 引言-TLS 1.3 協議及 SM 算法

說起 TLS,大家一定不會陌生,TLS 可以說是整個互聯網安全的基石,保障著我們的通信數據的安全。自從 2014 年 Heartbleed 漏洞被發現以來,網絡安全受人關注的程度越來越高,出於更安全更快捷的需求,TLS 1.3 協議也隨之被提出,其相應的 RFC 於 2018 年正式發佈。隨著網絡安全越來越受到重視,安全戰略也逐步上升到國家戰略的高度,國家密碼局在 2010 年底公佈了我國自主研製的“橢圓曲線公鑰密碼算法”(SM2 算法),並隨後陸續發佈了國密算法 SM1-SM9(SM 代表商密的拼音大寫)。今天我們要分享的東西,就和 TLS 1.3 及國密有關。

首先先讓大家對這兩者之間的關係有一個基本的概念,我們以一個典型的 TLS 1.2 中的密鑰套件為例:

對應到我們的國密的算法上,則各個算法對應的套件如下:

1、密鑰交換算法:ECC-SM2,ECDHE-SM2(這裡先不詳細展開,只簡單介紹一下,國密的密鑰交換算法基於當前的橢圓曲線算法設計了兩種專門的算法,而對應的曲線則是 SM2 曲線);

2、數字簽名算法:SM2(SM2 既是簽名算法的名稱,同時在橢圓曲線算法中對應的曲線名也叫 SM2,有的博客文檔裡也將密鑰交換算法稱作 SM2,讀者請注意不要混淆);

3、對稱加密算法:SM4;

4、hash 算法:SM3。

也就是說,國密局針對安全握手各個階段所需要的算法都出臺了一份自主可控的算法。

02 why 國密?why not 國密?

先說說為什麼要用國密,國密算法作為國密局的主力產品,肯定是在很多地方有優勢的,先來總結下國密的典型優勢:

1、更安全:SM2 作為一種 ECC 算法(256 位)的安全性是要高於 2048 位的 RSA 的。同時 SM3 的摘要長度為 256 bit,安全強度也是要高於當時主流的 MD5 算法及 SHA1 算法的。

2、更快速:在通訊過程中,256 位的 SM2 算法相比於 2048 位的 RSA 算法(國密算法在設計時,RSA2048 是主流簽名算法,所以這裡暫不討論ECDSA等算法),可以傳輸更少的數據,也就意味著更少的傳輸時間,並且在理論上來說,SM2 簽名算法的計算速度是要快過 RSA2048 不少的。

3、自主可控:在目前這個國際形勢下,這是最最最關鍵的一點!

國密聽起來像是中國密碼的一次革新,但這些年卻一直沒有大面積推行開來,說明其本身肯定有一些問題的,這裡拋開一些細節的小問題,談一談國密算法在大規模落地過程中遇到的一些比較棘手的問題:

1.速度不夠快(麻煩指數★★★)

國密整個 TLS 會話流程中涉及到的幾個算法,相對主流國際算法來說,大部分情況下性能均相對弱勢,這裡針對一些給出一些簡單的性能對比表:

對稱加密算法性能對比

簽名算法性能對比

hash 算法性能對比

從對比中我們可以看到,國密的這些算法目前和國際算法性能常常不在一個量級,無論是對稱加密還是非對稱加密的部分。究極根本原因,還是由於各種通用的國際算法普及程度太大,在工程上有著相應的多層次的優化(硬件計算和各種軟加速手段),以對稱加密為例:國密對稱加密算法 SM4 對標的算法是 aes-128,從本身的加密原理上來看,SM4 在理論上不會和 aes-128 產生如此大的差距,然而 AES 由於普遍性實在太強,典型的 AES 實現都基於 Intel 的 SIMD 指令集對其進行了並行化加速,而 SM4 目前只有純軟的實現,性能上自然有不小的差距。不僅如此,目前的主流對稱加密模式為 GCM 及 CCM 模式,其背後的思想為加密即認證技術(AEAD),而國密算法尚不支持這種模式,在安全性上也存在著一些弱點。

2.需要雙證書(★★★★)

要把雙證書講清楚首先需要大家理解下 PKI 密鑰協商機制,典型的密鑰協商算法分為兩種:RSA,ECDHE。國密的 ECC-SM2 密鑰協商流程和 RSA 比較類似,算法核心的性質在於用公鑰加密的數據可以用私鑰解密,整個密鑰協商流程簡化如下圖:

而 ECDHE-SM2 比較類似 ECDHE 算法,均是基於 DH 和 ECC 的算法,理解起來更加容易,流程簡化如下圖:

我們再來談雙證書這個事情,雙證書分為簽名證書和加密證書,這套體系的目的是滿足國家對於敏感數據強管控訴求,即只要能抓到所有數據包,則管控機構則可以在理論上恢復出所有明文數據,由此催生出了加密證書這個東西,加密證書的私鑰需要在專門的機構留底。我們來看 RSA 的密鑰交換流程,只要擁有了私鑰,則中間的密鑰生成的材料(隨機數)也就可以在理論上進行導出。而對於 ECDHE-SM2 來說,對稱密鑰的導出流程不僅僅只由隨機數 a/c 來決定,同時也需要加密證書對應的私鑰參與到計算中(具體流程比較繁瑣,這裡不展開,讀者可參考 GM/T 0024 標準閱讀詳細的細節),也就意味著當私鑰被監管,則對稱密鑰可以理論上被導出。

這套體系很強悍,但難就難在目前所有主流密碼庫如 openssl,boringssl 都不支持,那麼這也就意味著如果要推進這套體系的普適度,要麼基於主流密碼庫開發,並推進開源社區接受,進而慢慢滲透到國內用戶把這套體系用起來,要麼在儘可能兼容目前密碼體系的情況下開發一套新的密碼庫並強制國內用戶替換,每一種辦法都存在不小的難度。

3.需要客戶端也持有證書(★★★★★)

國密在 GM/T 0024 標準裡面定義了基於 ECDHE-SM2 算法的密鑰交換流程,但這個算法的要求十分苛刻,必須要求 Client 也持有證書,的確這對於安全性有一定提升,但麻煩也就隨之而來,支付寶的客戶端目前沒有證書,如果加上證書會讓 App 更重,握手交互的數據更多,極大降低用戶體驗。這些問題還不夠致命,如何管理海量的端上證書,才是真正令人頭疼的麻煩。

也許你會問:不用 ECDHE 不就好了嘛,但從技術的演進趨勢來看,高效/安全是我們孜孜不倦的追求,而類 RSA 的握手流程則從根源上限制了國密 ECC 密鑰交換流程無法演進到 1-RTT 握手,0-RTT 信息傳輸。不僅如此,ECHDE 的安全性及性能,也要好很多。在 TLS 1.3 的 1RTT 標準握手流程中,明確定義了廢除 RSA 握手,只支持 ECDHE。目前這個情況就造成了一個死鎖,想用 TLS 1.3->需要 ECDHE->需要 Client 有證書->沒有證書且不想用證書->問題無解。

03 重磅推出,TLS 1.3+ 國密算法套件

針對國密落地過程中的這些痛點問題,2019 年 8 月份,由螞蟻的同學牽頭,撰寫了一份 TLS 1.3+ 國密算法 draft,並最終成為了一份 IETF 標準文檔:

整個標準設計的核心思想是:整合目前國密算法優勢,全面貼合國際上的安全技術思路,把不好用的東西先暫時剔除掉,提升國密算法在國內及國際上的影響力,從而讓更多組織及個人參與到國密算法的使用和建設中來。基於這個思路,我們聯合了 360 等公司,經過和國密局的多次溝通,正式推出了相關標準。在整個流程上,我們在 ECDHE 算法上取消了 Client 證書的要求,並暫時放寬了雙證書的需求,由此推出了兩個完整的國密算法套件,並確定了簽名算法及曲線的標準號。同時我們基於 TLS 1.3 的 AEAD 需求,定義了 SM4 的 GCM 模式和 CCM 模式,並對此做了實現。

整個 draft 定義了以下幾個標準(目前這幾個標準都已經拿到了對應的標準號):
國密 SM2 曲線的標準號:curveSM2(41),這個標準號的作用允許 Client 和 server 在進行 TLS 1.3 握手時,使用 curveSM2 作為約定曲線,相當於讓 ECDHE_SM2 成為了 TLS 1.3 中的國際標準(當然這裡不需要 Client 持有證書)。

基於 SM2 及 SM3 的簽名算法標準號:sm2sig_sm3(0x0708),這個標準號的功能在於以後在 TLS 1.3 的流程中,如果 server 持有的是國密證書,則可以默認採用 sm2sig_sm3 作為簽名算法,而它的意義在於:國密證書從此也成了標準。

基於 TLS 1.3 及 SM2,SM3,SM4 算法的密鑰套件:

TLS_SM4_GCM_SM3(0x00,0xC6)以及 TLS_SM4_CCM_SM3(0x00,0xC7),它意味著從此你可以按照標準使用 TLS 1.3 的 1RTT 握手 + 國密算法,既滿足國家標準要求,又能夠快速方便。同時 SM4 算法也用上了更安全的 GCM/CCM 模式。

當然,標準也需要工程化的落地實現,而往往工程實現才是真正決定一份算法是否好用的絕對因素。針對 SM2/3/4 性能較差的問題,我們設計並落地了很多方案來進行優化,諸如:異步化的 SM2 硬件加速流程;基於 SIMD 的 SM4 軟優化實現等。基於這些技術,真正做到了讓國密在生產可用,開銷可控。

04 總結

當日長纓在手,今朝終縛蒼龍。回頭看來,協議從一份草案落地成為正式的 IETF 標準文檔,差不多經過了兩年左右的時間,期間和 IETF 工作組進行多輪,多方的探討,草案也經過了多輪修訂,最終能修成正果,實屬不易。隨著 TLS 1.3+ 國密正式成為了國家/國際層面均認可的標準(RFC8998),我們也正式在 BabaSSL 中支持了相關能力並將其開源,並建設了 BabaSSL 社區。

所謂鵬北海,鳳朝陽,又攜書劍路茫茫,BabaSSL 建設的初心是為經濟體打造統一/易用的國密密碼庫,但僅僅一份國密的標準的落地與實現絕不會是 BabaSSL 的終點,BabaSSL 會一直朝著更遠的星辰大海奮鬥,我們正在積極落地著量子隨機數,MPK,Delegated Crendential 等前沿技術,當然,那又是另一些故事了。

本週推薦閱讀

更多文章請掃碼關注“金融級分佈式架構”公眾號

Leave a Reply

Your email address will not be published. Required fields are marked *