張興隆,程慶豐,,馬建峰
?
增強TLS 1.3中Early data安全性的協(xié)議
張興隆1,程慶豐1,2,馬建峰2
(1. 信息工程大學,河南 鄭州 450004;2. 西安電子科技大學計算機學院,陜西 西安 710071)
將新型0-RTT密鑰交換協(xié)議思想借鑒到TLS 1.3會話重用階段,構建rFSOPKE協(xié)議,改進了Early data的加密和傳輸過程。rFSOPKE協(xié)議可以在Ticket有效期內保護Early data的前向安全性并使其抵抗重放攻擊。與改進前Early data的發(fā)送過程相比,本協(xié)議大幅增強了Early data的安全性。在實現(xiàn)效率方面,由于在發(fā)送Early data時增加了本協(xié)議的計算和傳輸開銷,所以實現(xiàn)效率有所降低。但是本協(xié)議可以根據(jù)應用場景的不同嵌入適合的算法,所以可以選擇更加高效的算法提高協(xié)議實現(xiàn)速度。
0-RTT;Early data;前向安全;重放攻擊;rFSOPKE
傳統(tǒng)網(wǎng)絡協(xié)議中的認證密鑰協(xié)商協(xié)議(AKE, authenticated key exchange)在完成正式的應用數(shù)據(jù)傳輸之前需要產生很大延遲。學術界一般以往返時間(RTT, round-trip time)來表示這種時延。傳統(tǒng)的高效AKE協(xié)議(如HMQV[1])在完成會話密鑰建立之前也需要至少2個消息的延遲,即需要1-RTT。隨著網(wǎng)絡通信量的巨大增長,高延遲的AKE協(xié)議顯然已經不能滿足用戶的需求了。
對連接效率的需求催生了對于0-RTT(0-RTT, zero round-trip time)密鑰交換協(xié)議的研究。0-RTT協(xié)議是一種允許客戶端在零往返時間內發(fā)送經過加密的有效載荷的密鑰交換協(xié)議??紤]到它的高效性,很多網(wǎng)絡安全協(xié)議都將0-RTT納入為一種應用模式。2015年7月,谷歌為了解決瀏覽器高延遲問題,制定了一種低時延的網(wǎng)絡傳輸協(xié)議——QUIC[2]。QUIC支持0-RTT握手并且已經在最新版本的Google Chrome和Opera網(wǎng)絡瀏覽器中實施。2014年4月,IETF發(fā)布TLS 1.3第一個版本的草案,此后不斷對各個版本進行修改完善,截至2017年7月3日,共有22個版本的草案面世。2015年7月,TLS 1.3第7個版本草案增添了對初始0-RTT的支持[3]。
近年來,學術界對0-RTT協(xié)議的安全性研究呈上升態(tài)勢,尤其是對TLS 1.3的研究更為突出。2014年,F(xiàn)ischlin和Günther等[4]正式分析了QUIC協(xié)議的安全性,建立了一個關于多階段密鑰交換協(xié)議安全性的模型,F(xiàn)ischlin和Günther等使用該模型對QUIC進行分析,包括其對0-RTT的支持,基本證明QUIC是一個充分安全的多階段密鑰交換協(xié)議。但是該模型不夠完善,在該模型下無法證明SSL/TLS是安全的。2015年,Krawczyk和Wee[5]提出了用于TLS 1.3協(xié)議的密鑰交換協(xié)議OPTLS,具體給出了OPTLS的設計原理和密碼性質分析。OPTLS的主要目的就是保證TLS 1.3的“0-RTT”要求,同時使前向安全性成為強制性要求,并且使橢圓曲線成為協(xié)議的主要加密基礎。為了滿足這些要求,需要移除傳統(tǒng)的以RSA算法為基礎的設計思想。同時該協(xié)議統(tǒng)一和模塊化的邏輯有助于協(xié)議的規(guī)范、分析、性能優(yōu)化和未來維護。TLS 1.3第9版本的草案(draft-ietf-tls- tls13-09)采用了OPTLS框架的4種工作模式和密鑰導出方法,但是Krawczyk和Wee并沒有全面介紹TLS 1.3所有方面,在會話恢復和客戶端認證方面并沒有深入分析。2016年,Cremers和Horvat等[6]使用形式化分析工具Tamarin對TLS 1.3第10版本草案[7]進行分析,其中包括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中基于預共享密鑰的0-RTT握手的密鑰保密性。Fischlin和Günther擴展了以前的安全模型,同時闡明重放攻擊下0-RTT安全性的限制。2017年,Hale和Jager等[9]建立了一個安全模型,提出強密鑰獨立性的概念?;诎踩姆墙换ナ矫荑€交換存在的通用假設,他們還給出了在這個模型中安全的0-RTT 密鑰交換協(xié)議的第一個結構體。總體來說,關于0-RTT握手消息,前向安全性和重放攻擊是關于其安全性討論的焦點。
基于層次化身份加密的前向安全思想于2003年由Canetti和Halevi等[10]提出。2014年,Pointcheval和Sanders[11]提出了基于多線性映射研究非交互式密鑰交換協(xié)議的前向安全問題。然而,這2種方法只是對粗粒度時間段提供前向保密,無法提供細粒度時間段的前向安全。2015年,Hale等[12]給出了來自其他加密原語的0-RTT密鑰交換的基礎定義和通用結構。但是所有這些工作都只考慮到安全模型和結構,而不涉及Early data的前向安全性。2016年,Cohn-Gordon等[13]在考慮使用密鑰交換協(xié)議的密碼安全性時,其中會話密鑰在單個會話的生命周期內經常更新,可以保證細粒度時間段內的前向安全。2017年,Günther和Hale等[14]提出了一種新的0-RTT密鑰交換協(xié)議的構想,即利用同步時間來構建一個0-RTT密鑰協(xié)商協(xié)議,該文章只討論了協(xié)議架構而并未涉及具體算法。另外,近年來,關于TLS 1.3中0-RTT握手以及其他0-RTT密鑰交換協(xié)議的研究還有很多[15,16]。
本文借鑒了Günther和Hale等[14]提出的新型0-RTT密鑰交換協(xié)議的思想,將細粒度時間段內前向安全與具體網(wǎng)絡協(xié)議結合起來,構建rFSOPKE協(xié)議,對TLS 1.3中Early data的加密過程和傳輸過程進行了改進,彌補了其在前向安全和重放攻擊方面的缺陷。
圖1 基于Diffie-Hellman交換的0-RTT協(xié)議框架
在零往返時間建立密鑰的另一個模式是基于預共享密鑰(PSK, pre-shared key)。從草案13[17]開始,基于Diffie-Hellman的0-RTT的選項優(yōu)先級被降低,PSK模式成為TLS 1.3指定的0-RTT握手模式的基礎?;赑SK模式下的0-RTT中,0-RTT密鑰1從先前建立的密鑰導出。例如,在TLS 1.3中,這個“先前建立的密鑰”就是指在一般握手中為會話恢復而建立的密鑰。當會話重用時,客戶端不需要與服務器進行通信就可以計算密鑰,可以用密鑰1立即發(fā)送加密數(shù)據(jù)。用于后續(xù)加密消息的完整密鑰2由預共享密鑰和更多密鑰信息導出??蛻舳撕头掌魍ㄟ^更新2來保證會話安全。
2.3.1 重放攻擊
2.3.2 前向安全性
TLS 1.3的主要改進如下(截至本文尚處在draft-21)。
1) 在密鑰協(xié)商方面禁用RSA算法,使用AEAD算法[20]。
2) 棄用PRF算法[21],使用HKDF密鑰導出算法[22]。
3) 移除更改密碼規(guī)范協(xié)議。
4) 對會話重用機制進行完善,將PSK的機制作為主要模式。
5) 在Session ticket中添加了過期時間。
6) 支持0-RTT Early data發(fā)送。
完整的TLS 1.3握手的消息流程如圖2所示。客戶端在Client hello中發(fā)送Key_share,Key_share包括每個公鑰和對應的曲線。服務器端接收Key_share之后,生成ECDHE公私鑰,然后協(xié)商出密鑰ECDHE secret。在此之后,服務器端同樣在Server hello的拓展中發(fā)送Key_share。
圖2 完整TLS1.3握手的消息流程
TLS 1.3的一個變化是規(guī)定Server hello之后的握手消息需要加密。握手加密密鑰的導出過程是通過Early secret和ECDHE secret導出Server_handshake_traffic_secret,再從Server_ handshake_traffic_ secret中導出key和iv,使用該key和iv對之后的消息進行加密。當會話結束,發(fā)送Finished消息時,服務器通過Server_ handshake_traffic_secret導出Server finished key,使用Hmac計算Finished消息后發(fā)送給客戶端。導出對稱密鑰的過程如圖3所示。
Finished消息發(fā)送完后,客戶端和服務器端分別通過主密鑰Master secret和整個握手消息的摘要計算用于會話重用的Resumption secret。此后服務器發(fā)送一個New session ticket消息,該消息包含整個會話信息,使用Server_application_ traffic_secret加密。
收到New session ticket消息后,客戶端將收到的Ticket和本地發(fā)送Finished后計算的Resumption secret組成PSK(pre shared key),保存在本地緩存中。當會話重用時,客戶端在本地緩存中查找Server Name對應的PSK,然后在Client hello消息中將PSK 發(fā)送至服務器端。會話重用時查找PSK過程如圖4所示。
發(fā)送Client hello后,客戶端使用Resumption secret導出的Client_early_traffic_key 和iv,對Early data進行加密后發(fā)送。
2017年,Günther等[14]提出了一種新的0-RTT密鑰交換協(xié)議的構想,即利用同步時間來構建一個0-RTT密鑰協(xié)商協(xié)議,只討論了協(xié)議架構而并未涉及具體算法。
作者為了解決密鑰長度隨著會話數(shù)量線性增長從而影響效率的問題,提出了增加一個時間元件,這個時間元件要求客戶端和服務器維護一個同步時鐘。在每個時間間隔內,密鑰長度線性增長,但是在一個時間段結束時,服務器可以“清空”密鑰,就是說將密鑰長度減少到時間間隔的對數(shù)因子。
圖3 導出對稱密鑰過程
圖4 會話重用時查找PSK過程
為了實現(xiàn)上述操作,構建了一個特殊的可穿透的前向安全的密鑰封裝算法(PFSKEM, puncturable forward-secret key encapsulation)。
定義1 PFSKEM:一個PFSKEM方案由以下概率性多項式時間算法組成。
在此之前,構建了一個一次性簽名(OTSIG, one-time signatures)算法和一個層次化的基于身份的密鑰封裝系統(tǒng)(HIBKEM, hierarchical identity-based key encapsulation scheme)?;谝陨纤惴嫿艘环N前向安全的0-RTT密鑰交換協(xié)議(FSOPKE, forward –secret one-pass key exchange)。
Günther等采用可證明安全的思想對協(xié)議的正確性和安全性給出了證明,證明了該協(xié)議滿足前向安全并且可以抵抗重放攻擊。
分析TLS 1.3會話重用流程,注意到在Ticket的有效期內,Early data無法抵抗重放攻擊,同時也不具有前向安全性。進一步查閱資料[17]得知,TLS 1.3的Ticket有效期限定在一周,這對攻擊者來說是有足夠操作時間的。
1) 無法抵抗重放攻擊
假如攻擊者在同一個Ticket的有效期內截獲了會話重用時的Client hello消息,并向服務器發(fā)送該消息從而進行重放攻擊,收到重放消息的服務器檢查Client hello的PSK拓展,將Ticket解密,在驗證Ticket未過期之后,驗證HMAC并且檢查Binder是否正確。一般情況下,這2個步驟都不會出現(xiàn)問題。
此后服務器通過Ticket中的Resumption secret導出Early data的解密密鑰。至此,服務器對Ticket以及相應拓展的驗證通過解密密鑰可以正確解密,所以服務器正常處理消息,敵手重放攻擊目的達成。
2) 不具有前向安全性
假如攻擊者在某一次服務器解密Early data時獲取了Early data的解密密鑰,那么由于在一個Ticket有效期內解密密鑰沒有發(fā)生變化,在這個Ticket有效期內的所有Early data都可以被敵手解密,無法滿足前向安全性。
本文考慮將Günther等所提出的0-RTT密鑰協(xié)商協(xié)議FSOPKE應用于TLS 1.3協(xié)議的會話重用階段,構建重用階段0-RTT協(xié)議rFSOPKE。首先設置客戶端和服務器時鐘同步。rFSOPKE在TLS 1.3會話重用階段運行如下。
下面考慮Early data的發(fā)送過程。
圖5 導出Early data密鑰的過程
假定攻擊者掌控網(wǎng)絡,并且有任意篡改、竊聽和重新排列消息順序的能力。他通過以下查詢與rFSOPKE協(xié)議進行交互。
5.1.1 前向安全和后向安全
5.1.2 重放攻擊
結合以上分析,將本文改進后的協(xié)議與改進前的協(xié)議對比,如表1所示。
表1 Early data安全性對比
本文致力于解決TLS 1.3協(xié)議會話重用時Early data在同一Ticket時間間隔內無法滿足前向安全和無法抵抗重放攻擊的問題,分析Günther等提出的新型0-RTT密鑰交換協(xié)議,將其思想借鑒到TLS 1.3會話重用階段,構造了rFSOPKE協(xié)議。通信雙方運行此協(xié)議可以有效改進Early data的加密和傳輸過程,保護了Early data的前向安全性并且可以抵抗重放攻擊。下一步的工作將圍繞尋找適應的協(xié)議嵌入算法達到安全性和高效性的平衡展開。
表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
國家高技術研究發(fā)展計劃(“863”計劃)基金資助項目(No.2015AA016007);密碼科學技術國家重點實驗室開放課題基金資助項目(No.MMKFKT201514)
The National High Technology Research and Development Program (863 Program)(No.2015AA016007), The National Key Laboratory Foundation of Cryptography (No.MMKFKT201514)
張興隆(1994-),安徽滁州人,信息工程大學碩士生,主要研究方向為密碼學和信息安全。
程慶豐(1979-),遼寧朝陽人,博士,信息工程大學副教授,主要研究方向為密碼學和信息安全。
馬建峰(1963-),男,陜西西安人,西安電子科技大學教授、博士生導師,主要研究方向為密碼學、無線和移動安全。