增強(qiáng)TLS 1.3中Early data安全性的協(xié)議

張興隆，程慶豐,，馬建峰

?

增強(qiáng)TLS 1.3中Early data安全性的協(xié)議

張興隆1，程慶豐1,2，馬建峰2

（1. 信息工程大學(xué)，河南 鄭州 450004；2. 西安電子科技大學(xué)計(jì)算機(jī)學(xué)院，陜西 西安 710071）

將新型0-RTT密鑰交換協(xié)議思想借鑒到TLS 1.3會(huì)話重用階段，構(gòu)建rFSOPKE協(xié)議，改進(jìn)了Early data的加密和傳輸過程。rFSOPKE協(xié)議可以在Ticket有效期內(nèi)保護(hù)Early data的前向安全性并使其抵抗重放攻擊。與改進(jìn)前Early data的發(fā)送過程相比，本協(xié)議大幅增強(qiáng)了Early data的安全性。在實(shí)現(xiàn)效率方面，由于在發(fā)送Early data時(shí)增加了本協(xié)議的計(jì)算和傳輸開銷，所以實(shí)現(xiàn)效率有所降低。但是本協(xié)議可以根據(jù)應(yīng)用場(chǎng)景的不同嵌入適合的算法，所以可以選擇更加高效的算法提高協(xié)議實(shí)現(xiàn)速度。

0-RTT；Early data；前向安全；重放攻擊；rFSOPKE

1 引言

傳統(tǒng)網(wǎng)絡(luò)協(xié)議中的認(rèn)證密鑰協(xié)商協(xié)議（AKE, authenticated key exchange）在完成正式的應(yīng)用數(shù)據(jù)傳輸之前需要產(chǎn)生很大延遲。學(xué)術(shù)界一般以往返時(shí)間（RTT, round-trip time）來表示這種時(shí)延。傳統(tǒng)的高效AKE協(xié)議（如HMQV[1]）在完成會(huì)話密鑰建立之前也需要至少2個(gè)消息的延遲，即需要1-RTT。隨著網(wǎng)絡(luò)通信量的巨大增長，高延遲的AKE協(xié)議顯然已經(jīng)不能滿足用戶的需求了。

對(duì)連接效率的需求催生了對(duì)于0-RTT（0-RTT, zero round-trip time）密鑰交換協(xié)議的研究。0-RTT協(xié)議是一種允許客戶端在零往返時(shí)間內(nèi)發(fā)送經(jīng)過加密的有效載荷的密鑰交換協(xié)議?？紤]到它的高效性，很多網(wǎng)絡(luò)安全協(xié)議都將0-RTT納入為一種應(yīng)用模式。2015年7月，谷歌為了解決瀏覽器高延遲問題，制定了一種低時(shí)延的網(wǎng)絡(luò)傳輸協(xié)議——QUIC[2]。QUIC支持0-RTT握手并且已經(jīng)在最新版本的Google Chrome和Opera網(wǎng)絡(luò)瀏覽器中實(shí)施。2014年4月，IETF發(fā)布TLS 1.3第一個(gè)版本的草案，此后不斷對(duì)各個(gè)版本進(jìn)行修改完善，截至2017年7月3日，共有22個(gè)版本的草案面世。2015年7月，TLS 1.3第7個(gè)版本草案增添了對(duì)初始0-RTT的支持[3]。

近年來，學(xué)術(shù)界對(duì)0-RTT協(xié)議的安全性研究呈上升態(tài)勢(shì)，尤其是對(duì)TLS 1.3的研究更為突出。2014年，F(xiàn)ischlin和Günther等[4]正式分析了QUIC協(xié)議的安全性，建立了一個(gè)關(guān)于多階段密鑰交換協(xié)議安全性的模型，F(xiàn)ischlin和Günther等使用該模型對(duì)QUIC進(jìn)行分析，包括其對(duì)0-RTT的支持，基本證明QUIC是一個(gè)充分安全的多階段密鑰交換協(xié)議。但是該模型不夠完善，在該模型下無法證明SSL/TLS是安全的。2015年，Krawczyk和Wee[5]提出了用于TLS 1.3協(xié)議的密鑰交換協(xié)議OPTLS，具體給出了OPTLS的設(shè)計(jì)原理和密碼性質(zhì)分析。OPTLS的主要目的就是保證TLS 1.3的“0-RTT”要求，同時(shí)使前向安全性成為強(qiáng)制性要求，并且使橢圓曲線成為協(xié)議的主要加密基礎(chǔ)。為了滿足這些要求，需要移除傳統(tǒng)的以RSA算法為基礎(chǔ)的設(shè)計(jì)思想。同時(shí)該協(xié)議統(tǒng)一和模塊化的邏輯有助于協(xié)議的規(guī)范、分析、性能優(yōu)化和未來維護(hù)。TLS 1.3第9版本的草案（draft-ietf-tls- tls13-09）采用了OPTLS框架的4種工作模式和密鑰導(dǎo)出方法，但是Krawczyk和Wee并沒有全面介紹TLS 1.3所有方面，在會(huì)話恢復(fù)和客戶端認(rèn)證方面并沒有深入分析。2016年，Cremers和Horvat等[6]使用形式化分析工具Tamarin對(duì)TLS 1.3第10版本草案[7]進(jìn)行分析，其中包括0-RTT握手模式，該分析無法論證0-RTT的安全性，反之也證明了其存在不安全的可能。2017年，F(xiàn)ischlin和Günther[8]分析了draft-ietf-tls-tls13-12中基于Diffie-Hellman的0-RTT握手的密鑰保密性和draft-ietf-tls-tls13-14中基于預(yù)共享密鑰的0-RTT握手的密鑰保密性。Fischlin和Günther擴(kuò)展了以前的安全模型，同時(shí)闡明重放攻擊下0-RTT安全性的限制。2017年，Hale和Jager等[9]建立了一個(gè)安全模型，提出強(qiáng)密鑰獨(dú)立性的概念?；诎踩姆墙换ナ矫荑€交換存在的通用假設(shè)，他們還給出了在這個(gè)模型中安全的0-RTT 密鑰交換協(xié)議的第一個(gè)結(jié)構(gòu)體?？傮w來說，關(guān)于0-RTT握手消息，前向安全性和重放攻擊是關(guān)于其安全性討論的焦點(diǎn)。

基于層次化身份加密的前向安全思想于2003年由Canetti和Halevi等[10]提出。2014年，Pointcheval和Sanders[11]提出了基于多線性映射研究非交互式密鑰交換協(xié)議的前向安全問題。然而，這2種方法只是對(duì)粗粒度時(shí)間段提供前向保密，無法提供細(xì)粒度時(shí)間段的前向安全。2015年，Hale等[12]給出了來自其他加密原語的0-RTT密鑰交換的基礎(chǔ)定義和通用結(jié)構(gòu)。但是所有這些工作都只考慮到安全模型和結(jié)構(gòu)，而不涉及Early data的前向安全性。2016年，Cohn-Gordon等[13]在考慮使用密鑰交換協(xié)議的密碼安全性時(shí)，其中會(huì)話密鑰在單個(gè)會(huì)話的生命周期內(nèi)經(jīng)常更新，可以保證細(xì)粒度時(shí)間段內(nèi)的前向安全。2017年，Günther和Hale等[14]提出了一種新的0-RTT密鑰交換協(xié)議的構(gòu)想，即利用同步時(shí)間來構(gòu)建一個(gè)0-RTT密鑰協(xié)商協(xié)議，該文章只討論了協(xié)議架構(gòu)而并未涉及具體算法。另外，近年來，關(guān)于TLS 1.3中0-RTT握手以及其他0-RTT密鑰交換協(xié)議的研究還有很多[15,16]。

本文借鑒了Günther和Hale等[14]提出的新型0-RTT密鑰交換協(xié)議的思想，將細(xì)粒度時(shí)間段內(nèi)前向安全與具體網(wǎng)絡(luò)協(xié)議結(jié)合起來，構(gòu)建rFSOPKE協(xié)議，對(duì)TLS 1.3中Early data的加密過程和傳輸過程進(jìn)行了改進(jìn)，彌補(bǔ)了其在前向安全和重放攻擊方面的缺陷。

2 預(yù)備知識(shí)

2.1 基于Diffie–Hellman密鑰交換的0-RTT

圖1 基于Diffie-Hellman交換的0-RTT協(xié)議框架

2.2 基于預(yù)共享密鑰的0-RTT

在零往返時(shí)間建立密鑰的另一個(gè)模式是基于預(yù)共享密鑰（PSK, pre-shared key）。從草案13[17]開始，基于Diffie-Hellman的0-RTT的選項(xiàng)優(yōu)先級(jí)被降低，PSK模式成為TLS 1.3指定的0-RTT握手模式的基礎(chǔ)?；赑SK模式下的0-RTT中，0-RTT密鑰1從先前建立的密鑰導(dǎo)出。例如，在TLS 1.3中，這個(gè)“先前建立的密鑰”就是指在一般握手中為會(huì)話恢復(fù)而建立的密鑰。當(dāng)會(huì)話重用時(shí)，客戶端不需要與服務(wù)器進(jìn)行通信就可以計(jì)算密鑰，可以用密鑰1立即發(fā)送加密數(shù)據(jù)。用于后續(xù)加密消息的完整密鑰2由預(yù)共享密鑰和更多密鑰信息導(dǎo)出?？蛻舳撕头?wù)器通過更新2來保證會(huì)話安全。

2.3 當(dāng)前0-RTT協(xié)議的缺陷

2.3.1 重放攻擊

2.3.2 前向安全性

2.4 TLS 1.3會(huì)話重用流程

TLS 1.3的主要改進(jìn)如下（截至本文尚處在draft-21）。

1) 在密鑰協(xié)商方面禁用RSA算法，使用AEAD算法[20]。

2) 棄用PRF算法[21]，使用HKDF密鑰導(dǎo)出算法[22]。

3) 移除更改密碼規(guī)范協(xié)議。

4) 對(duì)會(huì)話重用機(jī)制進(jìn)行完善，將PSK的機(jī)制作為主要模式。

5) 在Session ticket中添加了過期時(shí)間。

6) 支持0-RTT Early data發(fā)送。

完整的TLS 1.3握手的消息流程如圖2所示?？蛻舳嗽贑lient hello中發(fā)送Key_share，Key_share包括每個(gè)公鑰和對(duì)應(yīng)的曲線。服務(wù)器端接收Key_share之后，生成ECDHE公私鑰，然后協(xié)商出密鑰ECDHE secret。在此之后，服務(wù)器端同樣在Server hello的拓展中發(fā)送Key_share。

圖2 完整TLS1.3握手的消息流程

TLS 1.3的一個(gè)變化是規(guī)定Server hello之后的握手消息需要加密。握手加密密鑰的導(dǎo)出過程是通過Early secret和ECDHE secret導(dǎo)出Server_handshake_traffic_secret，再從Server_ handshake_traffic_ secret中導(dǎo)出key和iv，使用該key和iv對(duì)之后的消息進(jìn)行加密。當(dāng)會(huì)話結(jié)束，發(fā)送Finished消息時(shí)，服務(wù)器通過Server_ handshake_traffic_secret導(dǎo)出Server finished key，使用Hmac計(jì)算Finished消息后發(fā)送給客戶端。導(dǎo)出對(duì)稱密鑰的過程如圖3所示。

Finished消息發(fā)送完后，客戶端和服務(wù)器端分別通過主密鑰Master secret和整個(gè)握手消息的摘要計(jì)算用于會(huì)話重用的Resumption secret。此后服務(wù)器發(fā)送一個(gè)New session ticket消息，該消息包含整個(gè)會(huì)話信息，使用Server_application_ traffic_secret加密。

收到New session ticket消息后，客戶端將收到的Ticket和本地發(fā)送Finished后計(jì)算的Resumption secret組成PSK（pre shared key），保存在本地緩存中。當(dāng)會(huì)話重用時(shí)，客戶端在本地緩存中查找Server Name對(duì)應(yīng)的PSK，然后在Client hello消息中將PSK 發(fā)送至服務(wù)器端。會(huì)話重用時(shí)查找PSK過程如圖4所示。

發(fā)送Client hello后，客戶端使用Resumption secret導(dǎo)出的Client_early_traffic_key 和iv，對(duì)Early data進(jìn)行加密后發(fā)送。

2.5 Günther等所提出的0-RTT協(xié)議

2017年，Günther等[14]提出了一種新的0-RTT密鑰交換協(xié)議的構(gòu)想，即利用同步時(shí)間來構(gòu)建一個(gè)0-RTT密鑰協(xié)商協(xié)議，只討論了協(xié)議架構(gòu)而并未涉及具體算法。

作者為了解決密鑰長度隨著會(huì)話數(shù)量線性增長從而影響效率的問題，提出了增加一個(gè)時(shí)間元件，這個(gè)時(shí)間元件要求客戶端和服務(wù)器維護(hù)一個(gè)同步時(shí)鐘。在每個(gè)時(shí)間間隔內(nèi)，密鑰長度線性增長，但是在一個(gè)時(shí)間段結(jié)束時(shí)，服務(wù)器可以“清空”密鑰，就是說將密鑰長度減少到時(shí)間間隔的對(duì)數(shù)因子。

圖3 導(dǎo)出對(duì)稱密鑰過程

圖4 會(huì)話重用時(shí)查找PSK過程

為了實(shí)現(xiàn)上述操作，構(gòu)建了一個(gè)特殊的可穿透的前向安全的密鑰封裝算法（PFSKEM, puncturable forward-secret key encapsulation）。

定義1 PFSKEM：一個(gè)PFSKEM方案由以下概率性多項(xiàng)式時(shí)間算法組成。

在此之前，構(gòu)建了一個(gè)一次性簽名（OTSIG, one-time signatures）算法和一個(gè)層次化的基于身份的密鑰封裝系統(tǒng)（HIBKEM, hierarchical identity-based key encapsulation scheme）?；谝陨纤惴?gòu)建了一種前向安全的0-RTT密鑰交換協(xié)議（FSOPKE, forward –secret one-pass key exchange）。

Günther等采用可證明安全的思想對(duì)協(xié)議的正確性和安全性給出了證明，證明了該協(xié)議滿足前向安全并且可以抵抗重放攻擊。

3 TLS 1.3中Earlydata的安全性缺陷

分析TLS 1.3會(huì)話重用流程，注意到在Ticket的有效期內(nèi)，Early data無法抵抗重放攻擊，同時(shí)也不具有前向安全性。進(jìn)一步查閱資料[17]得知，TLS 1.3的Ticket有效期限定在一周，這對(duì)攻擊者來說是有足夠操作時(shí)間的。

1) 無法抵抗重放攻擊

假如攻擊者在同一個(gè)Ticket的有效期內(nèi)截獲了會(huì)話重用時(shí)的Client hello消息，并向服務(wù)器發(fā)送該消息從而進(jìn)行重放攻擊，收到重放消息的服務(wù)器檢查Client hello的PSK拓展，將Ticket解密，在驗(yàn)證Ticket未過期之后，驗(yàn)證HMAC并且檢查Binder是否正確。一般情況下，這2個(gè)步驟都不會(huì)出現(xiàn)問題。

此后服務(wù)器通過Ticket中的Resumption secret導(dǎo)出Early data的解密密鑰。至此，服務(wù)器對(duì)Ticket以及相應(yīng)拓展的驗(yàn)證通過解密密鑰可以正確解密，所以服務(wù)器正常處理消息，敵手重放攻擊目的達(dá)成。

2) 不具有前向安全性

假如攻擊者在某一次服務(wù)器解密Early data時(shí)獲取了Early data的解密密鑰，那么由于在一個(gè)Ticket有效期內(nèi)解密密鑰沒有發(fā)生變化，在這個(gè)Ticket有效期內(nèi)的所有Early data都可以被敵手解密，無法滿足前向安全性。

4 改進(jìn)TLS 1.3會(huì)話重用階段Early data密鑰

本文考慮將Günther等所提出的0-RTT密鑰協(xié)商協(xié)議FSOPKE應(yīng)用于TLS 1.3協(xié)議的會(huì)話重用階段，構(gòu)建重用階段0-RTT協(xié)議rFSOPKE。首先設(shè)置客戶端和服務(wù)器時(shí)鐘同步。rFSOPKE在TLS 1.3會(huì)話重用階段運(yùn)行如下。

下面考慮Early data的發(fā)送過程。

圖5 導(dǎo)出Early data密鑰的過程

5 安全性及效率分析

5.1 安全性分析

假定攻擊者掌控網(wǎng)絡(luò)，并且有任意篡改、竊聽和重新排列消息順序的能力。他通過以下查詢與rFSOPKE協(xié)議進(jìn)行交互。

5.1.1 前向安全和后向安全

5.1.2 重放攻擊

結(jié)合以上分析，將本文改進(jìn)后的協(xié)議與改進(jìn)前的協(xié)議對(duì)比，如表1所示。

表1 Early data安全性對(duì)比

5.2 效率分析

6 結(jié)束語

本文致力于解決TLS 1.3協(xié)議會(huì)話重用時(shí)Early data在同一Ticket時(shí)間間隔內(nèi)無法滿足前向安全和無法抵抗重放攻擊的問題，分析Günther等提出的新型0-RTT密鑰交換協(xié)議，將其思想借鑒到TLS 1.3會(huì)話重用階段，構(gòu)造了rFSOPKE協(xié)議。通信雙方運(yùn)行此協(xié)議可以有效改進(jìn)Early data的加密和傳輸過程，保護(hù)了Early data的前向安全性并且可以抵抗重放攻擊。下一步的工作將圍繞尋找適應(yīng)的協(xié)議嵌入算法達(dá)到安全性和高效性的平衡展開。

表2 公鑰和密文空間的增量

[1] KRAWCZYK H. HMQV: a high-performance secure Diffie-Hellman protocol[C]//The International Cryptology Conference. 2005: 546-566.

[2] CUI Y, LI T, LIU C, et al. Innovating transport with QUIC: design approaches and research challenges[J]. IEEE Internet Computing, 2017, 21(2): 72-76.

[3] RESCORLA E. The transport layer security (TLS) protocol version 1.3-draft-ietf-tls-tls13-07[DB/OL].https://tools.ietf.org/html/draft-ietf-tls-tls13-07.

[4] FISCHLIN M, GüNTHER F. Multi-stage key exchange and the case of Google's QUIC protocol[C]//The ACM CCS. 2014: 1193-1204.

[5] KRAWCZYK H, WEE H. The OPTLS protocol and TLS 1.3[C]// The IEEE European Symposium on Security and Privacy. 2016:81-96.

[6] CREMERS C, HORVAT M, SCOTT S, et al. Automated analysis and verification of TLS 1.3: 0-RTT, resumption and delayed authentication[C]// Security and Privacy. 2016:470-485.

[7] RESCORLA E. The transport layer security (TLS) protocol version 1.3-draft-ietf-tls-tls13-10[DB/OL].https://tools.ietf.org/html/draft-ietf-tls-tls13-10.

[8] FISCHLIN M, GüNTHER F. Replay attacks on zero round-trip time: the case of the TLS 1.3 handshake candidates[C]//IEEE European Symposium on Security and Privacy. 2017:82-113.

[9] HALE B, JAGER T, LAUER S, et al. Simple security definitions for and constructions of 0-RTT key exchange[C]// The International Conference on Applied Cryptography and Network Security. 2017: 20-38.

[10] CANETTI R, HALEVI S, KATZ J. A forward-secure public-key encryption scheme[J]. Journal of Cryptology, 2007, 20(3): 265-294.

[11] POINTCHEVAL D, SANDERS O. Forward secure non-interactive key exchange[C]//The International Conference on Security and Cryptography for Networks . 2014: 21-39.

[12] HALE B, JAGER T, LAUER S, et al. Simple security definitions for and constructions of 0-RTT key exchange[C]//The International Conference on Applied Cryptography and Network Security. 2017: 20-38.

[13] COHN-GORDON K, CREMERS C, GARRATT L. On post-compromise security[C]//Computer Security Foundations Symposium. 2016: 164-178.

[14] GüNTHER F, HALE B, JAGER T, et al. 0-RTT key exchange with full forward secrecy[C]//The International Conference on the Theory and Applications of Cryptographic Techniques. 2017: 519-548.

[15] DELIGNAT-LAVAUD A, FOURNET C, KOHLWEISS M, et al. Implementing and proving the TLS 1.3 record layer[C]//The 2017 Security and Privacy. 2017: 463-482.

[16] BHARGAVAN K, BLANCHET B, KOBEISSI N. Verified models and reference implementations for the TLS 1.3 standard candidate[C]//The 2017 Security and Privacy. 2017: 402-422.

[17] RESCORLA E. The transport layer security (TLS) protocol version 1.3-draft-ietf-tls-tls13-13[DB/OL].https://tools.ietf.org/html/draft-ietf-tls-tls13-13.

[18] RESCORLA E. The transport layer security (TLS) protocol version 1.3–draft-ietftls-tls13-12[DB/OL]. https://tools.ietf.org/html/draft-ietf- tls-tls13-12.

[19] RESCORLA E. The transport layer security (TLS) protocol version 1.3–draft-ietf-tls-tls13-18[DB/OL]. https://tools.ietf.org/html/draft- ietf-tls-tls13-18.

[20] KRAWCZYK H. The order of encryption and authentication for protecting communications (or: how secure is SSL?)[C]// CRYPTO. 2001: 310-331.

[21] GOLDREICH O, GOLDWASSER S, MICALI S. How to construct random functions[C]//Foundations of Computer Science. 1984: 464-479.

[22] KRAWCZYK H. Cryptographic extraction and key derivation: the HKDF scheme[C]//CRYPTO. 2010:631-648.

[23] GROTH J. Simulation-sound NIZK proofs for a practical language and constant size group signatures[C]//The International Conference on Theory and Application of Cryptology and Information Security. 2006: 444-459.

[24] BLAZY O, KILTZ E, PAN J. (Hierarchical) Identity-based encryption from affine message authentication[C]//The International Cryptology Conference. 2014: 408-425.

Protocol to enhance the security of Early data in TLS 1.3

ZHANG Xing-long1, CHENG Qing-feng1,2, MA Jian-feng2

(1. Information Engineering University, Zhengzhou 450004, China;2. College of Computer Science, Xidian University, Xi’an 710071, China)

The new 0-RTT Internet key exchange was drawn on the TLS 1.3 session resumption phase, the rFSOPKE protocol was constructed, and the Early data encryption and transmission process were improved. The rFSOPKE protocol can protect the forward security of Early data and protect it from replay attacks during the validity period of the Ticket. Compared with the previous Early data transmission process, rFSOPKE greatly enhanced the security of Early data. Due to the increase in the calculation and transmission overhead of this protocol when sending Early data, the efficiency of the protocol is reduced. However, rFSOPKE can embed the appropriate algorithm according to the different application environment, so more efficient algorithms should be chosen to improve the protocol implementation speed.

0-RTT, Early data, forward security, replay attack, rFSOPKE

TP309

A

10.11959/j.issn.2096-109x.2017.00224

2017-11-05；

2017-11-28。

程慶豐，qingfengc2008@sina.com

國家高技術(shù)研究發(fā)展計(jì)劃（“863”計(jì)劃）基金資助項(xiàng)目（No.2015AA016007）；密碼科學(xué)技術(shù)國家重點(diǎn)實(shí)驗(yàn)室開放課題基金資助項(xiàng)目（No.MMKFKT201514）

The National High Technology Research and Development Program (863 Program)(No.2015AA016007), The National Key Laboratory Foundation of Cryptography (No.MMKFKT201514)

張興?。?994-），安徽滁州人，信息工程大學(xué)碩士生，主要研究方向?yàn)槊艽a學(xué)和信息安全。

程慶豐（1979-），遼寧朝陽人，博士，信息工程大學(xué)副教授，主要研究方向?yàn)槊艽a學(xué)和信息安全。

馬建峰（1963-），男，陜西西安人，西安電子科技大學(xué)教授、博士生導(dǎo)師，主要研究方向?yàn)槊艽a學(xué)、無線和移動(dòng)安全。