TLS構建安全數據鏈路的研究

崔寧寧

摘 要：文章介紹了如何構建數據應用層之間的安全鏈路。在鏈路層將物聯網傳輸協議與TLS傳輸鏈路層加密相結合，通過SM2—TLS，SM9—TLS構建不同環境下的鏈路層安全。同時，在傳輸層通過TLS最新版本1.3版構建鏈路安全，實現平臺之間的高強度鏈路加密保障，保證重要數據在傳輸過程中的完整性。

關鍵詞：數控設備;數據安全

中圖分類號：TP309 文獻標識碼：A 文章編號：1674-1064（2022）03-0-03

DOI：10.12310/j.issn.1674-1064.2022.03.026

當今，密碼技術是與核技術、航天技術并列的國家三大安全核心技術之一，在保障信息安全，建設行業網絡安全環境，增強我國行業信息系統的“安全可控”能力等方面發揮著至為關鍵的作用。

隨著物聯網、工業互聯網領域的大力發展和建設，可以通過在物聯網網關中部署支持SM2、SM9算法的客戶端、標識解析客戶端、TLS加密通信客戶端，針對業務數據上傳和維護數據下行的典型通信場景，進行設備和操作的身份認證、授權、審計和通信加密。基于TLS 1.3協議中的SM2、SM9算法，能夠實現網關與平臺之間的高強度安全數據鏈路加密保障，保證重要數據在傳輸過程中的完整性。

1 TLS的安全強化和性能提升

相比TLS 1.2版，TLS 1.3版在安全強化、效率提升等方面進行了大量修改。

1.1 安全強化

TLS 1.3版移除并修復了舊版本協議中的密鑰交換、對稱加解密、壓縮等環節中可能存在的安全隱患，防患于未然[1]。

1.1.1 密鑰交換方面

完全支持PFS：TLS 1.3協議中選取的密鑰交換算法均支持前向安全性。斯諾登事件之后互聯網企業開始重視加密算法的前向安全性，防止私鑰被破解之后歷史數據也能被解密成明文。為了達到上述安全目的，TLS 1.3協議中廢除了不支持前向安全性的RSA和靜態DH密鑰交換算法。

廢棄DSA證書：DSA證書作為歷史遺留產物，因安全性差，從未被大規模應用，故在TLS 1.3協議中被廢棄。

RSA填充模式更改：協議中規定RSA填充模式使用PSS。

禁用自定義的DH組參數：如果選用了“不安全”的素數作為DH的主要參數，并且使用靜態DH密碼套件或使用默認OpenSSL配置的DHE加密套件（特別是SSL_OP_SINGLE_DH_USE選項未設置），就很容易受到Key Recovery Attack攻擊。因此TLS 1.3協議中禁用自定義的DH組參數。

1.1.2 對稱加密方面

禁用CBC模式：針對CBC模式加密算法的攻擊，歷史上出現過兩次，分別是2011年BEAST和2013年Lucky 13，實踐證明這種對稱加密模式確實存在安全隱患。

禁用RC4流加密算法：2011年9月，研究人員發現了BEAST攻擊，該攻擊針對所有基于CBC模式的加密算法。為解決這個問題，建議采用非CBC模式且普及率較高的RC4算法作為替代方案，由此RC4算法得到廣泛應用[2]。

隨著TLS版本的演進，BEAST攻擊可通過升級到新版本解決，不必要采用RC4這種陳舊算法來替代。

禁用SHA1：早在2005年研究機構就發現SHA1存在理論上的漏洞，可能造成碰撞攻擊。

1.1.3 禁用TLS壓縮

由于TLS壓縮存在安全漏洞，TLS 1.3協議刪除了該特性。該漏洞表現為通過CRIME攻擊可竊取啟用數據壓縮特性的HTTPS或SPDY協議傳輸的Cookie。在成功解讀身份驗證Cookie后，攻擊者可實行會話劫持并發動進一步攻擊。

1.1.4 加密握手消息

TLS 1.3協議中規定在Server Hello消息之后的握手信息需要加密。TLS 1.2及之前版本的協議中，各種擴展信息在Server Hello中以明文方式發送，新版本中可在加密之后封裝到Encrypted Extension消息中，在Server Hello消息之后發送，提高數據的安全性。

1.2 性能提升

TLS 1.3版在提高效率方面進行了大量改進，特別是對SSL握手過程進行了重新設計，將握手交互延時從2—RTT降低至1—RTT甚至是0—RTT。在網絡環境較差或節點距離較遠的情況下，這種優化能節省幾百毫秒的時間[3]。

TLS 1.3版提供1—RTT的握手機制，如圖1所示，以ECDHE密鑰交換過程為例，握手過程如下：

將客戶端發送ECDH臨時公鑰的過程提前到Client Hello，同時刪除了Change Cipher Spec協議簡化握手過程，使第一次握手時只需要1—RTT。

客戶端發送Client Hello消息，該消息主要包括客戶端支持的協議版本、DH密鑰交換參數列表Key Share。

服務端回復Server Hello，包含選定的加密套件;發送證書給客戶端;使用證書對應的私鑰對握手消息簽名，將結果發送給客戶端;選用客戶端提供的參數生成ECDH臨時公鑰，結合選定的DH參數計算出用于加密HTTP消息的共享密鑰;服務端生成的臨時公鑰通過Key Share消息發送給客戶端。

客戶端接收到Key Share消息后，使用證書公鑰進行簽名驗證，獲取服務器端的ECDH臨時公鑰，生成會話所需要的共享密鑰。

雙方使用生成的共享密鑰對消息加密傳輸，保證消息安全。

2 TLS安全傳輸（SM2—TLS）

TLS協議用于在兩個通信實體間建立安全的信息傳輸通道，以實現身份認證、數據加密傳輸等功能。目前，TLS協議是互聯網應用最為廣泛的安全通信協議，主要包含握手協議與記錄協議等協議。記錄協議通過添加消息認證碼和加密數據的方式保證數據的完整性，握手協議作為TLS協議的核心，通過驗證通信雙方持有的證書及驗證通信雙方對握手參數簽名的方式實現身份認證，通過密鑰交換協議使通信雙方在公開信道中安全地共享密鑰。

將安全性更高的商密算法應用于TLS 1.3協議中，增大數據傳輸的安全性。

建立通道的方法，在密鑰交換階段，采用SM2算法，在密鑰交換時即發送SM2曲線的參數和密鑰協商時的公鑰，即使用SM2密鑰協商發送兩個公鑰到對端[4]。其中，一個公鑰在key_share擴展中傳輸，該公鑰每次握手都會重新產生;另一個公鑰在新增的SM2_key_share擴展中傳輸，作為用戶公鑰使用，通過計算得出共享密鑰，并對serverhello之后的報文進行加密發送，在身份認證階段引入SM2_SM3簽名算法，避免了在握手階段密鑰及所傳輸的報文內容被竊取，增大了數據傳輸的安全性。

3 TLS安全傳輸（SM9—TLS）

將SM9密鑰用于TLS加密通信是一種很常用、具有現實意義的SM9基礎應用場景。當TLS支持SM9密鑰后，SM9私鑰持有方（如物聯網設備）以自己的身份接入網絡，進行通信身份認證、密鑰協商和加密通信。使TLS同時支持SM2和SM9算法，可以更好地促進互聯網、物聯網的融合，支撐組織、個人及設備的實名入網、認證聯網[5]。

為實現通信節點間安全高效的通信，針對雙向認證TLS協議通信開銷及證書管理負擔大的問題，擬基于SM9商密算法對雙向認證TLS協議進行改進。改進關鍵在于用SM9商密算法代替證書體系，由于SM9商密算法中用戶公鑰由用戶標識唯一確定，所以改進后的雙向認證TLS協議中，用戶公鑰的真實性不依賴于證書而依賴于用戶標識。這也就需要密鑰生成中心在為用戶生成并分發密鑰后，維護合法的用戶標識列表。

一種基于SM9簽名算法和DHE密鑰交換改進后的雙向認證TLS握手協議如圖2所示，其步驟下：

客戶端向服務端發送Client Hello消息，與改進前相比，該消息增加了支持SM9-TLS的選項。

服務端向客戶端發送Server Hello、Server Certificate、Server Key Exchange、Certificate Request、Server Hello Done消息，與改進前相比，Server Certificate消息含有服務器的標識而非證書，Server Key Exchange消息含有SM9簽名。

客戶端向密鑰生成中心發送請求，查詢Server Certificate消息中的服務端標識是否合法，如得到有效的合法回復，客戶端通過該身份標識計算出服務端公鑰，用該公鑰驗證Server Key Exchange消息中的SM9簽名，驗證通過后計算會話密鑰，用會話密鑰加密握手參數，向服務端發送Client Certificate、Client Key Exchange、Certificate Verify、Encrypted Handshake Message消息。與改進前相比，Client Certificate消息含有客戶端標識而非證書，Certificate Verify消息含有SM9簽名。

服務端向密鑰生成中心發送請求，查詢Client Certificate消息中的服務端標識是否合法，如得到有效的合法回復，服務端通過該身份標識計算出客戶端公鑰，用該公鑰驗證Certificate Verify消息中的SM9簽名，驗證通過后計算會話密鑰，用會話密鑰解密收到的Encrypted Handshake Message消息，并驗證解密后的握手參數是否正確，如驗證通過，用會話密鑰加密握手參數，并向客戶端發送含有加密握手參數的Encrypted Handshake Message消息。

客戶端用會話密鑰解密收到的Encrypted Handshake Message消息，驗證解密后的握手參數是否正確，驗證通過后用會話密鑰安全通信[6]。

另一種改進方案中，需要用SM9密鑰交換協議代替DHE密鑰交換協議。在該改進方案中，SM9密鑰交換過程中進行會話密鑰計算時需要自己的私鑰，所以只要通信雙方協商出一致的會話密鑰，就可以說明通信雙方持有各自私鑰，也就不依賴簽名實現了身份認證。

基于SM9密鑰協商協議的改進方案與基于SM9簽名算法的改進方案不同在于Server Key Exchange、Client Key Exchange消息中含有SM9密鑰交換參數，且Server Key Exchange和Client Verify消息中不再含有簽名信息。

4 結語

作為TLS 1.3證書的核心，基于ECC橢圓曲線的SM2算法，單位安全強度相對較高。安全數據鏈路解決方案適合采用輕量級密碼算法和優化的安全傳輸協議TLS。通過應用SM2、SM9算法，實現操作人員、設備、云端服務器彼此之間的身份認證，實現終端數據、云端服務器通信鏈路的加密傳輸及加密存儲。通過建設工業信息安全密碼支撐系統及安全數據鏈路，可以全面提供安全可靠的網絡環境和數據加密服務，能夠實現雙向身份鑒別、精準權限控制、數據傳輸安全、控制指令防篡改和數據存儲安全保護等安全需求。

參考文獻

[1] 邢彥辰.數據通信與計算機網絡（第3版）[M].北京：人民郵電出版社，2020.

[2] 郭德仁.數據通信網絡技術[M].北京：電子工業出版社，2021.

[3] 里斯蒂奇.HTTPS權威指南 在服務器和Web應用上部署SSL TLS和PKI[M].北京：人民郵電出版社，2016.

[4] 國家密碼管理局.GM/T 0009—2012 SM2密碼算法使用規范[S].2012.

[5] 國家密碼管理局.GM/T 0085—2020基于SM9標識密碼算法的技術體系框架[S].2020.

[6] 國家密碼管理局.GM/T 0025—2014 SSL VPN網關產品規范[S].2014.