增强TLS 1.3中Early data安全性的协议

张兴隆，程庆丰,，马建峰



增强TLS 1.3中Early data安全性的协议

张兴隆1，程庆丰1,2，马建峰2

（1. 信息工程大学，河南 郑州 450004；2. 西安电子科技大学计算机学院，陕西 西安 710071）

将新型0-RTT密钥交换协议思想借鉴到TLS 1.3会话重用阶段，构建rFSOPKE协议，改进了Early data的加密和传输过程。rFSOPKE协议可以在Ticket有效期内保护Early data的前向安全性并使其抵抗重放攻击。与改进前Early data的发送过程相比，本协议大幅增强了Early data的安全性。在实现效率方面，由于在发送Early data时增加了本协议的计算和传输开销，所以实现效率有所降低。但是本协议可以根据应用场景的不同嵌入适合的算法，所以可以选择更加高效的算法提高协议实现速度。

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

1 引言

传统网络协议中的认证密钥协商协议（AKE, authenticated key exchange）在完成正式的应用数据传输之前需要产生很大延迟。学术界一般以往返时间（RTT, round-trip time）来表示这种时延。传统的高效AKE协议（如HMQV[1]）在完成会话密钥建立之前也需要至少2个消息的延迟，即需要1-RTT。随着网络通信量的巨大增长，高延迟的AKE协议显然已经不能满足用户的需求了。

对连接效率的需求催生了对于0-RTT（0-RTT, zero round-trip time）密钥交换协议的研究。0-RTT协议是一种允许客户端在零往返时间内发送经过加密的有效载荷的密钥交换协议。考虑到它的高效性，很多网络安全协议都将0-RTT纳入为一种应用模式。2015年7月，谷歌为了解决浏览器高延迟问题，制定了一种低时延的网络传输协议——QUIC[2]。QUIC支持0-RTT握手并且已经在最新版本的Google Chrome和Opera网络浏览器中实施。2014年4月，IETF发布TLS 1.3第一个版本的草案，此后不断对各个版本进行修改完善，截至2017年7月3日，共有22个版本的草案面世。2015年7月，TLS 1.3第7个版本草案增添了对初始0-RTT的支持[3]。

近年来，学术界对0-RTT协议的安全性研究呈上升态势，尤其是对TLS 1.3的研究更为突出。2014年，Fischlin和Günther等[4]正式分析了QUIC协议的安全性，建立了一个关于多阶段密钥交换协议安全性的模型，Fischlin和Günther等使用该模型对QUIC进行分析，包括其对0-RTT的支持，基本证明QUIC是一个充分安全的多阶段密钥交换协议。但是该模型不够完善，在该模型下无法证明SSL/TLS是安全的。2015年，Krawczyk和Wee[5]提出了用于TLS 1.3协议的密钥交换协议OPTLS，具体给出了OPTLS的设计原理和密码性质分析。OPTLS的主要目的就是保证TLS 1.3的“0-RTT”要求，同时使前向安全性成为强制性要求，并且使椭圆曲线成为协议的主要加密基础。为了满足这些要求，需要移除传统的以RSA算法为基础的设计思想。同时该协议统一和模块化的逻辑有助于协议的规范、分析、性能优化和未来维护。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年，Fischlin和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 密钥交换协议的第一个结构体。总体来说，关于0-RTT握手消息，前向安全性和重放攻击是关于其安全性讨论的焦点。

基于层次化身份加密的前向安全思想于2003年由Canetti和Halevi等[10]提出。2014年，Pointcheval和Sanders[11]提出了基于多线性映射研究非交互式密钥交换协议的前向安全问题。然而，这2种方法只是对粗粒度时间段提供前向保密，无法提供细粒度时间段的前向安全。2015年，Hale等[12]给出了来自其他加密原语的0-RTT密钥交换的基础定义和通用结构。但是所有这些工作都只考虑到安全模型和结构，而不涉及Early data的前向安全性。2016年，Cohn-Gordon等[13]在考虑使用密钥交换协议的密码安全性时，其中会话密钥在单个会话的生命周期内经常更新，可以保证细粒度时间段内的前向安全。2017年，Günther和Hale等[14]提出了一种新的0-RTT密钥交换协议的构想，即利用同步时间来构建一个0-RTT密钥协商协议，该文章只讨论了协议架构而并未涉及具体算法。另外，近年来，关于TLS 1.3中0-RTT握手以及其他0-RTT密钥交换协议的研究还有很多[15,16]。

本文借鉴了Günther和Hale等[14]提出的新型0-RTT密钥交换协议的思想，将细粒度时间段内前向安全与具体网络协议结合起来，构建rFSOPKE协议，对TLS 1.3中Early data的加密过程和传输过程进行了改进，弥补了其在前向安全和重放攻击方面的缺陷。

2 预备知识

2.1 基于Diffie–Hellman密钥交换的0-RTT

图1 基于Diffie-Hellman交换的0-RTT协议框架

2.2 基于预共享密钥的0-RTT

在零往返时间建立密钥的另一个模式是基于预共享密钥（PSK, pre-shared key）。从草案13[17]开始，基于Diffie-Hellman的0-RTT的选项优先级被降低，PSK模式成为TLS 1.3指定的0-RTT握手模式的基础。基于PSK模式下的0-RTT中，0-RTT密钥1从先前建立的密钥导出。例如，在TLS 1.3中，这个“先前建立的密钥”就是指在一般握手中为会话恢复而建立的密钥。当会话重用时，客户端不需要与服务器进行通信就可以计算密钥，可以用密钥1立即发送加密数据。用于后续加密消息的完整密钥2由预共享密钥和更多密钥信息导出。客户端和服务器通过更新2来保证会话安全。

2.3 当前0-RTT协议的缺陷

2.3.1 重放攻击

2.3.2 前向安全性

2.4 TLS 1.3会话重用流程

TLS 1.3的主要改进如下（截至本文尚处在draft-21）。

1) 在密钥协商方面禁用RSA算法，使用AEAD算法[20]。

2) 弃用PRF算法[21]，使用HKDF密钥导出算法[22]。

3) 移除更改密码规范协议。

4) 对会话重用机制进行完善，将PSK的机制作为主要模式。

5) 在Session ticket中添加了过期时间。

6) 支持0-RTT Early data发送。

完整的TLS 1.3握手的消息流程如图2所示。客户端在Client hello中发送Key_share，Key_share包括每个公钥和对应的曲线。服务器端接收Key_share之后，生成ECDHE公私钥，然后协商出密钥ECDHE secret。在此之后，服务器端同样在Server hello的拓展中发送Key_share。

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

TLS 1.3的一个变化是规定Server hello之后的握手消息需要加密。握手加密密钥的导出过程是通过Early secret和ECDHE secret导出Server_handshake_traffic_secret，再从Server_ handshake_traffic_ secret中导出key和iv，使用该key和iv对之后的消息进行加密。当会话结束，发送Finished消息时，服务器通过Server_ handshake_traffic_secret导出Server finished key，使用Hmac计算Finished消息后发送给客户端。导出对称密钥的过程如图3所示。

Finished消息发送完后，客户端和服务器端分别通过主密钥Master secret和整个握手消息的摘要计算用于会话重用的Resumption secret。此后服务器发送一个New session ticket消息，该消息包含整个会话信息，使用Server_application_ traffic_secret加密。

收到New session ticket消息后，客户端将收到的Ticket和本地发送Finished后计算的Resumption secret组成PSK（pre shared key），保存在本地缓存中。当会话重用时，客户端在本地缓存中查找Server Name对应的PSK，然后在Client hello消息中将PSK 发送至服务器端。会话重用时查找PSK过程如图4所示。

发送Client hello后，客户端使用Resumption secret导出的Client_early_traffic_key 和iv，对Early data进行加密后发送。

2.5 Günther等所提出的0-RTT协议

2017年，Günther等[14]提出了一种新的0-RTT密钥交换协议的构想，即利用同步时间来构建一个0-RTT密钥协商协议，只讨论了协议架构而并未涉及具体算法。

作者为了解决密钥长度随着会话数量线性增长从而影响效率的问题，提出了增加一个时间元件，这个时间元件要求客户端和服务器维护一个同步时钟。在每个时间间隔内，密钥长度线性增长，但是在一个时间段结束时，服务器可以“清空”密钥，就是说将密钥长度减少到时间间隔的对数因子。

图3 导出对称密钥过程

图4 会话重用时查找PSK过程

为了实现上述操作，构建了一个特殊的可穿透的前向安全的密钥封装算法（PFSKEM, puncturable forward-secret key encapsulation）。

定义1 PFSKEM：一个PFSKEM方案由以下概率性多项式时间算法组成。

在此之前，构建了一个一次性签名（OTSIG, one-time signatures）算法和一个层次化的基于身份的密钥封装系统（HIBKEM, hierarchical identity-based key encapsulation scheme）。基于以上算法构建了一种前向安全的0-RTT密钥交换协议（FSOPKE, forward –secret one-pass key exchange）。

Günther等采用可证明安全的思想对协议的正确性和安全性给出了证明，证明了该协议满足前向安全并且可以抵抗重放攻击。

3 TLS 1.3中Earlydata的安全性缺陷

分析TLS 1.3会话重用流程，注意到在Ticket的有效期内，Early data无法抵抗重放攻击，同时也不具有前向安全性。进一步查阅资料[17]得知，TLS 1.3的Ticket有效期限定在一周，这对攻击者来说是有足够操作时间的。

1) 无法抵抗重放攻击

假如攻击者在同一个Ticket的有效期内截获了会话重用时的Client hello消息，并向服务器发送该消息从而进行重放攻击，收到重放消息的服务器检查Client hello的PSK拓展，将Ticket解密，在验证Ticket未过期之后，验证HMAC并且检查Binder是否正确。一般情况下，这2个步骤都不会出现问题。

此后服务器通过Ticket中的Resumption secret导出Early data的解密密钥。至此，服务器对Ticket以及相应拓展的验证通过解密密钥可以正确解密，所以服务器正常处理消息，敌手重放攻击目的达成。

2) 不具有前向安全性

假如攻击者在某一次服务器解密Early data时获取了Early data的解密密钥，那么由于在一个Ticket有效期内解密密钥没有发生变化，在这个Ticket有效期内的所有Early data都可以被敌手解密，无法满足前向安全性。

4 改进TLS 1.3会话重用阶段Early data密钥

本文考虑将Günther等所提出的0-RTT密钥协商协议FSOPKE应用于TLS 1.3协议的会话重用阶段，构建重用阶段0-RTT协议rFSOPKE。首先设置客户端和服务器时钟同步。rFSOPKE在TLS 1.3会话重用阶段运行如下。

下面考虑Early data的发送过程。

图5 导出Early data密钥的过程

5 安全性及效率分析

5.1 安全性分析

假定攻击者掌控网络，并且有任意篡改、窃听和重新排列消息顺序的能力。他通过以下查询与rFSOPKE协议进行交互。

5.1.1 前向安全和后向安全

5.1.2 重放攻击

结合以上分析，将本文改进后的协议与改进前的协议对比，如表1所示。

表1 Early data安全性对比

5.2 效率分析

6 结束语

本文致力于解决TLS 1.3协议会话重用时Early data在同一Ticket时间间隔内无法满足前向安全和无法抵抗重放攻击的问题，分析Günther等提出的新型0-RTT密钥交换协议，将其思想借鉴到TLS 1.3会话重用阶段，构造了rFSOPKE协议。通信双方运行此协议可以有效改进Early data的加密和传输过程，保护了Early data的前向安全性并且可以抵抗重放攻击。下一步的工作将围绕寻找适应的协议嵌入算法达到安全性和高效性的平衡展开。

表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

国家高技术研究发展计划（“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-），男，陕西西安人，西安电子科技大学教授、博士生导师，主要研究方向为密码学、无线和移动安全。