常衛(wèi), 浮明軍, 徐亞超, 黃顯果, 劉靜靜

(1.許繼電氣股份有限公司,河南,許昌 461000; 2.許繼電源有限公司,河南,許昌 461000)

0 引言

隨著電力行業(yè)安全性標準的提高,基于GMSSL庫的應用已經(jīng)成為基礎設施的一部分。SSL/TLS協(xié)議可以有效保證通信[1]的機密性。鑒于SSL/TLS安全協(xié)議的通信重要性及廣泛性,針對TLS協(xié)議實現(xiàn)及國密算法的安全審查漏洞檢測及應用研究已成為了熱點。目前研究的已知漏洞,包括BEAST攻擊、BREACH攻擊、CRIME攻擊等,相關研究發(fā)現(xiàn)開源工具testssl.sh能夠檢測出這些漏洞[2-3];基于圖像密文重構與卷積神經(jīng)網(wǎng)絡[4-5]等手段的分析方法,對主流密碼算法的密文隨機性進行了分析,這也為TLS密碼套件選擇與加密流量的深層分析提供了參考;對SM2加密算法的核心加密流程[6]進行優(yōu)化,在不影響算法安全性的前提下,提出基于優(yōu)化的SM2國密算法替換ECDSA公鑰簽名算法的區(qū)塊鏈設計;區(qū)塊鏈技術結合簽名密鑰算法[7]提高電子存證數(shù)據(jù)的安全性。以上都是對TLS協(xié)議實現(xiàn)庫存在的安全漏洞、國密算法優(yōu)化等方面進行的相關研究,但GMSSL庫中的接口實現(xiàn)只是對核心功能進行了設計,目前業(yè)界對公用接口的封裝使用漏洞缺乏相關研究分析,因此本文的研究很有必要性。

1 TLS通信實現(xiàn)機制

1.1 TLS簡介

TLS(安全傳輸層),TLS[8-10]是建立在傳輸層TCP協(xié)議之上的協(xié)議,服務于應用層,它的前身是SSL(安全套接字層),實現(xiàn)了將應用層的報文進行加密后再交由TCP進行傳輸?shù)墓δ堋?/p>

圖1 TLS通信層

1.2 通信機制

TLS通信機制可以分為兩步[11]:服務器端和客戶端進行“握手”,身份驗證通過后分別生成對稱密鑰;客戶端使用對稱密鑰加密,服務端使用對稱密鑰解密,雙方通過“對稱密鑰”進行加密通信?？梢约毞譃樗牟?

1) 客戶端向服務器發(fā)送TLS協(xié)議的版本號、一個隨機數(shù)A、以及所支持的加密算法(如RSA)。

2) 服務器確認是否支持客戶端發(fā)送的TLS協(xié)議版本,同時給出數(shù)字證書(包含服務器的公鑰)以及一個隨機數(shù)B。

3) 客戶端驗證數(shù)字證書有效后,生成一個新隨機數(shù)C,并且使用證書中的公鑰加密此隨機數(shù),最后將加密后的隨機數(shù)發(fā)送到服務器。

4) 服務器使用自己的私鑰解密被加密后的隨機數(shù)C,使用加密算法對隨機數(shù)A、B、C進行加密,生成對稱密鑰?？蛻舳耸褂猛瑯拥募用芩惴ㄉ膳c服務器相同的對稱密鑰。

SSL/TLS協(xié)議本身的復雜性為應用者增加了負擔,為了減輕開發(fā)者的負擔及防范由代碼缺陷導致的安全風險,SSL/TLS協(xié)議實現(xiàn)細節(jié)通常被封裝在OpenSSL,NSS等開源軟件庫中。而國密算法[12-13]是國家密碼局制定標準的一系列算法,其中包括SM2橢圓曲線非對稱加密算法、SM3雜湊算法、SM4[14-15]對稱加密算法。

1.3 本文工作

GMSSL是支持國密算法和標準的OpenSSL分支,增加了對國密SM2/SM3/SM4算法和ECIES、CPK、ZUC算法的支持。GMSSL庫對TLS協(xié)議通信、國密算法的核心功能進行了封裝,應用者只需要調(diào)用提供的接口即可實現(xiàn)所需的功能。本文首先介紹了TLS通信機制及被測軟件功能,重點闡述了基于被測軟件設計的軟件測試框架,最后對GMSSL庫提供的SM2、SM3、SM4國密算法及常規(guī)的數(shù)字證書操作接口、TLS通信接口進行的二次封裝軟件進行了測試,發(fā)現(xiàn)對GMSSL庫函數(shù)的調(diào)用漏洞,將會導致TLS通信初始化錯誤、加解密錯誤等問題。本文的研究對于正確實現(xiàn)TLS加密通信具有重要的參考意義。

2 測試環(huán)境搭建

二次封裝完畢后,需要確認功能、性能、效率及內(nèi)存等是否滿足要求。此時,測試就是重要的保障環(huán)節(jié)。功能測試用于確保接口實現(xiàn)的全面性及功能正確性;性能測試用于考核加解密速度能力;內(nèi)存測試主要考核最大資源消耗情況。應設計測試驅(qū)動測試上述項目符合相關標準或要求。

2.1 靜態(tài)測試環(huán)境

測試環(huán)境搭建要從靜態(tài)測試和動態(tài)測試兩方面考慮。靜態(tài)測試主要通過checkmarx、CoBot和fortify、polyspace等工具按照源代碼編譯環(huán)境、工具配置要求及選擇編碼規(guī)則對靜態(tài)測試環(huán)境進行搭建。測試工具通過掃描源代碼分析程序的系統(tǒng)結構、數(shù)據(jù)結構、數(shù)據(jù)接口、內(nèi)部控制邏輯等內(nèi)部結構并形成掃描結果報告文件,測試員閱讀報告文件檢查代碼中那些違反編碼規(guī)則的地方是否存在潛在的風險。此次測試是對于接口的靜態(tài)掃描,對于公共庫的源碼部分未能檢測到,所以靜態(tài)測試結果只是表明在接口二次封裝源代碼中的一些變量定義未使用、變量未初始化等編碼規(guī)范問題,其他安全性問題本次不進行研究。

2.2 動態(tài)測試環(huán)境

如圖2所示,TLS通信軟件測試框架主要包括客戶端測試驅(qū)動和服務器端測試驅(qū)動2個大模塊。通過設計客戶端和服務端測試驅(qū)動,調(diào)用GMSSL庫中相關接口實現(xiàn)通信。

圖2 測試驅(qū)動軟件框架

客戶端驅(qū)動實現(xiàn)包括通信初始化(初始化socket、讀取CA證書、客戶端證書、客戶端私鑰、網(wǎng)絡初始化)、連接服務器、發(fā)送/接收數(shù)據(jù)、通信反初始化(釋放資源)。

服務器端驅(qū)動實現(xiàn)包括初始化服務器網(wǎng)絡(初始化網(wǎng)絡環(huán)境、初始化TLS環(huán)境)、啟動監(jiān)聽、接收tcp連接-創(chuàng)建tls連接-接受tls連接、接收客戶端數(shù)據(jù)、定時發(fā)送數(shù)據(jù)。通信效果如圖3所示。

(a) 服務器端

3 功能測試及效果

基于上述軟件測試框架的動態(tài)測試主要對接口的功能實現(xiàn)正確性、功能實現(xiàn)的完備性、是否存在內(nèi)存泄漏等進行測試。各類功能的測試項目如表1～表3所示。

表1 TLS通信測試項目

表2 讀證書接口測試項目

表3 SM2/SM3/SM4測試項目

3.1 TLS通信測試

通過場景測試法設計測試用例對TLS通信進行接口功能驗證。TLS通信初始化階段,需要進行客戶端或服務端的證書驗證、證書是否與私鑰匹配、私鑰是否正確等操作。當加載經(jīng)CA簽發(fā)但不匹配的證書與私鑰文件時,先加載證書進行證書驗證,然后加載私鑰檢查私鑰正確性,最后進行證書與私鑰匹配性檢查,預期實現(xiàn)功能是證書與私鑰不匹配。

通過測試發(fā)現(xiàn),若按如上步驟操作,匹配性檢查的結果是私鑰不正確,沒有正確實現(xiàn)匹配性檢查的功能。

修改接口調(diào)用先后順序如下。

先檢查私鑰正確性,在保證私鑰文件正確的前提下進行證書與私鑰的匹配性檢查,此操作的表現(xiàn)能夠正確實現(xiàn)匹配性檢查的功能要求。

3.2 讀證書接口的測試

通過設計測試用例對讀證書接口進行調(diào)用,測試項目覆蓋了表2中的內(nèi)容,通過測試發(fā)現(xiàn)很有價值的問題。對于加密的P12證書文件和加密的私鑰文件,在解析這兩種文件時,庫函數(shù)的處理方式是不一樣的。讀私鑰文件,文件解析之前就可以知道是否需要密碼,如果不需要就直接丟棄輸入的密碼;讀P12文件時,無法區(qū)分該類文件是否需要密碼,所以在給一個不加密的P12文件輸入密碼時密碼就使用了。對不加密的P12證書接口進行封裝時,務必采取相應措施確保密碼為空,否則當用戶調(diào)用該接口輸入密碼會引起功能的錯誤實現(xiàn)。

3.3 加密算法的測試

通過設計測試用例對SM2、SM3、SM4算法進行測試,通過測試發(fā)現(xiàn),對于SM4加密,當加密模式為CFB和OFB時,若在調(diào)用ssl庫函數(shù)EVP_sms4_cfb()和EVP_sm4_ofb()時數(shù)據(jù)長度傳入為0(異常調(diào)用),庫函數(shù)仍能成功加密。若封裝該庫函數(shù)時沒有考慮此情況,將會實現(xiàn)錯誤的功能。

4 性能測試及效果

基于測試框架,設計多次調(diào)用加密算法接口并自動統(tǒng)計平均耗時。加解密算法在不同的應用平臺,計算能力差別較大,沒有統(tǒng)一標準,以下記錄均在Win 10,64位操作系統(tǒng),i7-9700 CPU,3.0 GHz處理器上進行測試,針對SM2、SM3、SM4加解密接口,分別統(tǒng)計調(diào)用10 000次、100 000次的平均耗時,結果如表4～表6所示。

表4 SM2簽名/驗簽速度

測試結果表明:SM2簽名、SM2驗簽在調(diào)用10 000次和調(diào)用100 000次時的平均耗時均比較穩(wěn)定,說明SM2算法在對消息進行簽名和驗簽時不受次數(shù)的影響,同時被簽名的消息長度對簽名和驗簽速度的影響也是不存在的。但從上述結果中可以看出,SM2簽名平均耗時幾乎是SM2驗簽的2倍,原因在于SM2簽名和SM2驗簽的算法復雜度的不同,在簽名過程中,R、S值和橢圓曲線點計算占用了大量的時間資源。

表5是不同長度消息SM3摘要計算的平均耗時測試結果,從該結果可以看出,隨著消息長度的增大,消息摘要計算平均耗時逐漸增多;對于同一消息,單次計算和分次計算雜湊值的時間開銷存在著很大的差別,如當消息長度為1024 Byte時,分512次計算和單次計算的耗時差達到了10 μs,而對于同一消息相同長度的雜湊值分次計算,調(diào)用10 000次和調(diào)用100 000次的平均耗時卻幾乎無差別,也同時驗證了該算法比較穩(wěn)定。

表6為SM4對于不同長度的消息進行加解密速度測試結果,可以看出,隨著數(shù)據(jù)長度的增大,加解密的耗時也逐漸增多,當數(shù)據(jù)長度為1024 Byte時,耗時達到了26 μs,說明消息長度對于算法的影響較大。

表6 SM4加解密計算速度

5 總結

隨著配電信息數(shù)據(jù)規(guī)模的逐漸增大,對數(shù)據(jù)安全性的要求越來越高,安全通信的正確實現(xiàn)及數(shù)據(jù)加解密速度是電網(wǎng)數(shù)據(jù)交互的重要指標。本文通過對GMSSL庫的二次封裝程序進行測試,發(fā)現(xiàn)對GMSSL庫中公用接口不能夠正確調(diào)用時,可能會造成功能實現(xiàn)的不正確;通過對加解密速度進行分析,為國密算法對不同數(shù)據(jù)長度的加密通信提供了資源消耗的參考。

本文對GMSSL庫中的部分接口在實現(xiàn)加密通信過程中的封裝使用方法提出了建議,設計的測試環(huán)境和測試用例只能覆蓋一些基本功能的測試,仍需繼續(xù)深化開發(fā)研究測試方法,進一步拓展測試深度。