TLS構(gòu)建安全數(shù)據(jù)鏈路的研究

崔寧寧

摘 要：文章介紹了如何構(gòu)建數(shù)據(jù)應(yīng)用層之間的安全鏈路。在鏈路層將物聯(lián)網(wǎng)傳輸協(xié)議與TLS傳輸鏈路層加密相結(jié)合，通過SM2—TLS，SM9—TLS構(gòu)建不同環(huán)境下的鏈路層安全。同時(shí)，在傳輸層通過TLS最新版本1.3版構(gòu)建鏈路安全，實(shí)現(xiàn)平臺(tái)之間的高強(qiáng)度鏈路加密保障，保證重要數(shù)據(jù)在傳輸過程中的完整性。

關(guān)鍵詞：數(shù)控設(shè)備;數(shù)據(jù)安全

中圖分類號(hào)：TP309 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1674-1064（2022）03-0-03

DOI：10.12310/j.issn.1674-1064.2022.03.026

當(dāng)今，密碼技術(shù)是與核技術(shù)、航天技術(shù)并列的國(guó)家三大安全核心技術(shù)之一，在保障信息安全，建設(shè)行業(yè)網(wǎng)絡(luò)安全環(huán)境，增強(qiáng)我國(guó)行業(yè)信息系統(tǒng)的“安全可控”能力等方面發(fā)揮著至為關(guān)鍵的作用。

隨著物聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)領(lǐng)域的大力發(fā)展和建設(shè)，可以通過在物聯(lián)網(wǎng)網(wǎng)關(guān)中部署支持SM2、SM9算法的客戶端、標(biāo)識(shí)解析客戶端、TLS加密通信客戶端，針對(duì)業(yè)務(wù)數(shù)據(jù)上傳和維護(hù)數(shù)據(jù)下行的典型通信場(chǎng)景，進(jìn)行設(shè)備和操作的身份認(rèn)證、授權(quán)、審計(jì)和通信加密。基于TLS 1.3協(xié)議中的SM2、SM9算法，能夠?qū)崿F(xiàn)網(wǎng)關(guān)與平臺(tái)之間的高強(qiáng)度安全數(shù)據(jù)鏈路加密保障，保證重要數(shù)據(jù)在傳輸過程中的完整性。

1 TLS的安全強(qiáng)化和性能提升

相比TLS 1.2版，TLS 1.3版在安全強(qiáng)化、效率提升等方面進(jìn)行了大量修改。

1.1 安全強(qiáng)化

TLS 1.3版移除并修復(fù)了舊版本協(xié)議中的密鑰交換、對(duì)稱加解密、壓縮等環(huán)節(jié)中可能存在的安全隱患，防患于未然[1]。

1.1.1 密鑰交換方面

完全支持PFS：TLS 1.3協(xié)議中選取的密鑰交換算法均支持前向安全性。斯諾登事件之后互聯(lián)網(wǎng)企業(yè)開始重視加密算法的前向安全性，防止私鑰被破解之后歷史數(shù)據(jù)也能被解密成明文。為了達(dá)到上述安全目的，TLS 1.3協(xié)議中廢除了不支持前向安全性的RSA和靜態(tài)DH密鑰交換算法。

廢棄DSA證書：DSA證書作為歷史遺留產(chǎn)物，因安全性差，從未被大規(guī)模應(yīng)用，故在TLS 1.3協(xié)議中被廢棄。

RSA填充模式更改：協(xié)議中規(guī)定RSA填充模式使用PSS。

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

1.1.2 對(duì)稱加密方面

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

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

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

禁用SHA1：早在2005年研究機(jī)構(gòu)就發(fā)現(xiàn)SHA1存在理論上的漏洞，可能造成碰撞攻擊。

1.1.3 禁用TLS壓縮

由于TLS壓縮存在安全漏洞，TLS 1.3協(xié)議刪除了該特性。該漏洞表現(xiàn)為通過CRIME攻擊可竊取啟用數(shù)據(jù)壓縮特性的HTTPS或SPDY協(xié)議傳輸?shù)腃ookie。在成功解讀身份驗(yàn)證Cookie后，攻擊者可實(shí)行會(huì)話劫持并發(fā)動(dòng)進(jìn)一步攻擊。

1.1.4 加密握手消息

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

1.2 性能提升

TLS 1.3版在提高效率方面進(jìn)行了大量改進(jìn)，特別是對(duì)SSL握手過程進(jìn)行了重新設(shè)計(jì)，將握手交互延時(shí)從2—RTT降低至1—RTT甚至是0—RTT。在網(wǎng)絡(luò)環(huán)境較差或節(jié)點(diǎn)距離較遠(yuǎn)的情況下，這種優(yōu)化能節(jié)省幾百毫秒的時(shí)間[3]。

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

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

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

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

客戶端接收到Key Share消息后，使用證書公鑰進(jìn)行簽名驗(yàn)證，獲取服務(wù)器端的ECDH臨時(shí)公鑰，生成會(huì)話所需要的共享密鑰。

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

2 TLS安全傳輸（SM2—TLS）

TLS協(xié)議用于在兩個(gè)通信實(shí)體間建立安全的信息傳輸通道，以實(shí)現(xiàn)身份認(rèn)證、數(shù)據(jù)加密傳輸?shù)裙δ堋Ｄ壳埃琓LS協(xié)議是互聯(lián)網(wǎng)應(yīng)用最為廣泛的安全通信協(xié)議，主要包含握手協(xié)議與記錄協(xié)議等協(xié)議。記錄協(xié)議通過添加消息認(rèn)證碼和加密數(shù)據(jù)的方式保證數(shù)據(jù)的完整性，握手協(xié)議作為TLS協(xié)議的核心，通過驗(yàn)證通信雙方持有的證書及驗(yàn)證通信雙方對(duì)握手參數(shù)簽名的方式實(shí)現(xiàn)身份認(rèn)證，通過密鑰交換協(xié)議使通信雙方在公開信道中安全地共享密鑰。

將安全性更高的商密算法應(yīng)用于TLS 1.3協(xié)議中，增大數(shù)據(jù)傳輸?shù)陌踩浴?/p>

建立通道的方法，在密鑰交換階段，采用SM2算法，在密鑰交換時(shí)即發(fā)送SM2曲線的參數(shù)和密鑰協(xié)商時(shí)的公鑰，即使用SM2密鑰協(xié)商發(fā)送兩個(gè)公鑰到對(duì)端[4]。其中，一個(gè)公鑰在key_share擴(kuò)展中傳輸，該公鑰每次握手都會(huì)重新產(chǎn)生;另一個(gè)公鑰在新增的SM2_key_share擴(kuò)展中傳輸，作為用戶公鑰使用，通過計(jì)算得出共享密鑰，并對(duì)serverhello之后的報(bào)文進(jìn)行加密發(fā)送，在身份認(rèn)證階段引入SM2_SM3簽名算法，避免了在握手階段密鑰及所傳輸?shù)膱?bào)文內(nèi)容被竊取，增大了數(shù)據(jù)傳輸?shù)陌踩浴?/p>

3 TLS安全傳輸（SM9—TLS）

將SM9密鑰用于TLS加密通信是一種很常用、具有現(xiàn)實(shí)意義的SM9基礎(chǔ)應(yīng)用場(chǎng)景。當(dāng)TLS支持SM9密鑰后，SM9私鑰持有方（如物聯(lián)網(wǎng)設(shè)備）以自己的身份接入網(wǎng)絡(luò)，進(jìn)行通信身份認(rèn)證、密鑰協(xié)商和加密通信。使TLS同時(shí)支持SM2和SM9算法，可以更好地促進(jìn)互聯(lián)網(wǎng)、物聯(lián)網(wǎng)的融合，支撐組織、個(gè)人及設(shè)備的實(shí)名入網(wǎng)、認(rèn)證聯(lián)網(wǎng)[5]。

為實(shí)現(xiàn)通信節(jié)點(diǎn)間安全高效的通信，針對(duì)雙向認(rèn)證TLS協(xié)議通信開銷及證書管理負(fù)擔(dān)大的問題，擬基于SM9商密算法對(duì)雙向認(rèn)證TLS協(xié)議進(jìn)行改進(jìn)。改進(jìn)關(guān)鍵在于用SM9商密算法代替證書體系，由于SM9商密算法中用戶公鑰由用戶標(biāo)識(shí)唯一確定，所以改進(jìn)后的雙向認(rèn)證TLS協(xié)議中，用戶公鑰的真實(shí)性不依賴于證書而依賴于用戶標(biāo)識(shí)。這也就需要密鑰生成中心在為用戶生成并分發(fā)密鑰后，維護(hù)合法的用戶標(biāo)識(shí)列表。

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

客戶端向服務(wù)端發(fā)送Client Hello消息，與改進(jìn)前相比，該消息增加了支持SM9-TLS的選項(xiàng)。

服務(wù)端向客戶端發(fā)送Server Hello、Server Certificate、Server Key Exchange、Certificate Request、Server Hello Done消息，與改進(jìn)前相比，Server Certificate消息含有服務(wù)器的標(biāo)識(shí)而非證書，Server Key Exchange消息含有SM9簽名。

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

服務(wù)端向密鑰生成中心發(fā)送請(qǐng)求，查詢Client Certificate消息中的服務(wù)端標(biāo)識(shí)是否合法，如得到有效的合法回復(fù)，服務(wù)端通過該身份標(biāo)識(shí)計(jì)算出客戶端公鑰，用該公鑰驗(yàn)證Certificate Verify消息中的SM9簽名，驗(yàn)證通過后計(jì)算會(huì)話密鑰，用會(huì)話密鑰解密收到的Encrypted Handshake Message消息，并驗(yàn)證解密后的握手參數(shù)是否正確，如驗(yàn)證通過，用會(huì)話密鑰加密握手參數(shù)，并向客戶端發(fā)送含有加密握手參數(shù)的Encrypted Handshake Message消息。

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

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

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

4 結(jié)語(yǔ)

作為TLS 1.3證書的核心，基于ECC橢圓曲線的SM2算法，單位安全強(qiáng)度相對(duì)較高。安全數(shù)據(jù)鏈路解決方案適合采用輕量級(jí)密碼算法和優(yōu)化的安全傳輸協(xié)議TLS。通過應(yīng)用SM2、SM9算法，實(shí)現(xiàn)操作人員、設(shè)備、云端服務(wù)器彼此之間的身份認(rèn)證，實(shí)現(xiàn)終端數(shù)據(jù)、云端服務(wù)器通信鏈路的加密傳輸及加密存儲(chǔ)。通過建設(shè)工業(yè)信息安全密碼支撐系統(tǒng)及安全數(shù)據(jù)鏈路，可以全面提供安全可靠的網(wǎng)絡(luò)環(huán)境和數(shù)據(jù)加密服務(wù)，能夠?qū)崿F(xiàn)雙向身份鑒別、精準(zhǔn)權(quán)限控制、數(shù)據(jù)傳輸安全、控制指令防篡改和數(shù)據(jù)存儲(chǔ)安全保護(hù)等安全需求。

參考文獻(xiàn)

[1] 邢彥辰.數(shù)據(jù)通信與計(jì)算機(jī)網(wǎng)絡(luò)（第3版）[M].北京：人民郵電出版社，2020.

[2] 郭德仁.數(shù)據(jù)通信網(wǎng)絡(luò)技術(shù)[M].北京：電子工業(yè)出版社，2021.

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

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

[5] 國(guó)家密碼管理局.GM/T 0085—2020基于SM9標(biāo)識(shí)密碼算法的技術(shù)體系框架[S].2020.

[6] 國(guó)家密碼管理局.GM/T 0025—2014 SSL VPN網(wǎng)關(guān)產(chǎn)品規(guī)范[S].2014.