基于GMSSL公共庫應用的測試研究

常衛, 浮明軍, 徐亞超, 黃顯果, 劉靜靜

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

0 引言

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

1 TLS通信實現機制

1.1 TLS簡介

TLS(安全傳輸層),TLS[8-10]是建立在傳輸層TCP協議之上的協議,服務于應用層,它的前身是SSL(安全套接字層),實現了將應用層的報文進行加密后再交由TCP進行傳輸的功能。

圖1 TLS通信層

1.2 通信機制

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

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

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

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

4) 服務器使用自己的私鑰解密被加密后的隨機數C,使用加密算法對隨機數A、B、C進行加密,生成對稱密鑰。客戶端使用同樣的加密算法生成與服務器相同的對稱密鑰。

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

1.3 本文工作

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

2 測試環境搭建

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

2.1 靜態測試環境

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

2.2 動態測試環境

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

圖2 測試驅動軟件框架

客戶端驅動實現包括通信初始化(初始化socket、讀取CA證書、客戶端證書、客戶端私鑰、網絡初始化)、連接服務器、發送/接收數據、通信反初始化(釋放資源)。

服務器端驅動實現包括初始化服務器網絡(初始化網絡環境、初始化TLS環境)、啟動監聽、接收tcp連接-創建tls連接-接受tls連接、接收客戶端數據、定時發送數據。通信效果如圖3所示。

(a) 服務器端

3 功能測試及效果

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

表1 TLS通信測試項目

表2 讀證書接口測試項目

表3 SM2/SM3/SM4測試項目

3.1 TLS通信測試

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

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

修改接口調用先后順序如下。

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

3.2 讀證書接口的測試

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

3.3 加密算法的測試

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

4 性能測試及效果

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

表4 SM2簽名/驗簽速度

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

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

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

表6 SM4加解密計算速度

5 總結

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

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