CN109600226A - 基于随机数隐式协商的tls协议会话密钥还原方法 - Google Patents

基于随机数隐式协商的tls协议会话密钥还原方法 Download PDF

Info

Publication number
CN109600226A
CN109600226A CN201910072962.0A CN201910072962A CN109600226A CN 109600226 A CN109600226 A CN 109600226A CN 201910072962 A CN201910072962 A CN 201910072962A CN 109600226 A CN109600226 A CN 109600226A
Authority
CN
China
Prior art keywords
key
client
message
server
secret
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201910072962.0A
Other languages
English (en)
Other versions
CN109600226B (zh
Inventor
陈荣茂
李�杰
苏金树
陈曙晖
王小峰
张博锋
孙品
孙一品
王飞
刘宇靖
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
National University of Defense Technology
Original Assignee
National University of Defense Technology
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by National University of Defense Technology filed Critical National University of Defense Technology
Priority to CN201910072962.0A priority Critical patent/CN109600226B/zh
Publication of CN109600226A publication Critical patent/CN109600226A/zh
Application granted granted Critical
Publication of CN109600226B publication Critical patent/CN109600226B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Algebra (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Mathematical Physics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)

Abstract

针对现有TLS中间件安全防护方法无法满足目前以及未来的TLS中间件使用场景，本发明提供一种基于随机数隐式协商的TLS协议会话密钥还原方法：1.中间件生成公私钥对，将公钥发送给客户端；2.客户端保存公钥，和服务器进行握手，构造握手报文发送给服务器；3.中间件保存握手报文并转发到服务器；4.服务器向客户端发送报文；5.中间件计算握手报文加密密钥；6.中间件对报文进行解密，并通过计算，还原会话密钥，同时转发收到的报文；7.客户端收到服务器报文后，向中间件发送报文；8.中间件将报文转发给服务器，并生成会话复用主密；9.中间件解密TLS流量，执行中间件功能。本发明可用于TLS中间件技术，提供基于网络的安全属性，且大幅减少中间件的计算开销。

Description

基于随机数隐式协商的TLS协议会话密钥还原方法
技术领域
本发明属于计算机网络安全技术领域，涉及一种安全传输协议会话密钥还原方法，具体涉及一种基于随机数隐式协商的传输层安全(Transport Layer Security，TLS)协议会话密钥还原方法。
背景技术
计算机时代，终端面临的最大安全威胁是各类计算机病毒，防毒卡、杀毒软件等能够提供有效的安全防护。而网络时代，终端所面临的安全威胁剧增起来：包括木马、间谍软件、劫持攻击、钓鱼邮件、钓鱼网络等等。此时除了在终端上安装安全软件外，还需要在网络边界架设防火墙、入侵检测系统IDS/IPS、内容审核、数据审计等更多的基于网络的安全防御方法。不同于基于主机的各种安全软件，基于网络的安全设施并不能对主机环境进行深度扫描监测，但是，这些设施却构成了一个更全面、更通用的安全体系。基于网络流量的安全检查，不特别针对某一主机，而是针对网络内的所有主机，因此其检查的范围更广，能搜集的决策信息也更多，更有利于探查、评估网络威胁。同时，它不依赖主机环境，使用上更通用、普遍，特别是对于资源有限、缺乏“自我保护”的IoT设备，其效用更加明显。另外，这种安全机制，也是对主机安全软件的一种补充增强，一些安全检查设备能够帮助抵御内部人员安装未授权软件，并在一个受感染的主机禁用安全软件时提供反馈。
基于网络的安全设施中，一个重要组成部分是TLS中间件。TLS中间件能被用于监视、拦截或者转发企业环境和移动网络中的HTTPS流量。比如，防火墙和IDS依赖于网络流量的检查以实现基于边界的安全策略。根据安全功能需求的不同，这些中间件可以被部署为流量监控设备或在线设备。一个流量监控中间件可执行威胁监测、入侵检测、加密审计、合规监视等功能。一个在线设备中间件可能适用于防止非法下载、阻止已知威胁URLs、强制使用强安全密码、阻止数据泄露等应用场景。
目前的TLS中间件安全防护方法主要包括以下五种：
1)中间人技术(Man-in-the-middle attack，简称MITM)。使用中间人技术来获取四层以上流量的明文信息。该方法适用于客户端位于企业网络内部的应用场景。企业网络内部生成根证书，安装到TLS客户端中，并将根证书的私钥交给中间件。客户端发起和服务器之间的TLS握手时，中间件伪造服务器的证书，与客户端建立连接；同时，中间件与服务器建立TLS连接。所有在客户端和服务器之间通信的加密数据，实际都被TLS中间件进行了重新加密，然后转发。但中间人技术存在以下技术问题：
使用在客户端安装定制根证书的中间人技术中，由于客户端实质是与中间件建立了TLS连接，这实际上是破坏了密钥协商的“抗未知密钥共享”安全，因此客户端建立的TLS连接失去了应有的源认证性，即客户端不能对与之通信的服务器的身份进行认证，也不能保证中间件会对服务器的身份进行认证。另外，使用该技术的中间件需要解密和重新加密转发流量，计算开销大。
2)中间件内置服务器私钥方法。该方法适用于服务器位于企业网络内部的应用场景，并且使用静态RSA和静态Diffie-Hellman进行密钥交换的TLS密码套件。企业管理员将服务器的私钥内置于TLS中间件，中间件监听客户端和服务器之间的握手过程，使用服务器的私钥计算会话密钥。
但中间件内置服务器私钥方法存在以下技术问题：TLS的新标准版本1.3中，已经放弃了静态RSA和静态Diffie-Hellman握手，改用(EC)Diffie-Hellman握手。每次握手时，客户端和用户端都会产生临时密钥对用于密钥计算。因此，中间件内置服务器私钥的方法不适用于TLS1.3。
3)BlindBox。学术工作BlindBox使用一种可搜索加密方案。在正常的TLS加密流量之外，BlindBox要求客户端或服务器将流量明文使用可搜索加密方案进行加密，与正常TLS流量同时传输。中间件可在BlindBox可搜索加密流量上执行一些特定的检测功能。
但BlindBox使用可搜索加密技术的问题在于，它只满足一部分中间件的需求——例如入侵检测这种主要运用模式匹配的中间件。而另一些中间件，比如压缩代理(compression proxies)需要进行任意计算(arbitrary computation)，就无法使用可搜索加密技术。
4)mcTLS。mcTLS修改原有TLS协议，使中间件参与握手过程密钥协商，细粒度控制中间件对TLS流量的读写权限。mcTLS将数据按照中间件的读写权限进行切分，握手完成后为每块数据生成多个对称密钥，拥有对应读写权限的中间件可生成相应的密钥。
mcTLS方案的问题：首先，mcTLS大幅修改原有协议，不兼容现有协议，难以部署使用；其次，mcTLS的握手过程引入了大量额外的通信开销和计算开销。
5)带外密钥传输。该方案在TLS握手完成后，由客户端或服务器将会话密钥传输给中间件。但带外密钥传输的方法引入了额外的网络通信开销。
发明内容
针对现有TLS中间件安全防护方法均无法满足目前以及未来的TLS中间件使用场景，本发明提供一种基于随机数隐式协商的TLS协议会话密钥还原方法，可用于TLS中间件技术，提供基于网络的安全属性。本发明的目的是提供一种基于随机数隐式协商的TLS协议会话密钥还原方法，并满足以下特征：
1)是一种通用方法，能用于任何TLS中间件；
2)适用于TLS各个版本，包括最新版本TLS1.3；
3)无需额外的TLS连接传输密钥，也无需使用中间人技术将TLS连接分割为两条TLS连接；
4)兼容原有TLS协议，支持普通TLS客户端与增强的TLS客户端的通信；
5)不破坏TLS连接的源认证性；
6)一条TLS会话只需一个密钥，无需额外的密钥管理；
7)能进行权限限制，即可限定中间件是否能访问TLS会话的加密数据。
技术方案如下：
第一步，中间件生成公私钥对(skm，pkm)，skm为中间件的私钥，pkm为中间件的公钥，其中g为椭圆曲线x25519的生成元。中间件将私钥skm秘密保存，将公钥pkm发送给客户端；
第二步，客户端收到公钥pkm后，保存到本地，用于后续建立TLS连接时生成握手临时私钥。客户端和服务器进行握手，使用中间件公钥pkm构造握手报文ClientHello，并将握手报文发送给服务器。具体步骤如下：
2.1)客户端发起TLS连接，选择随机数r，计算gr，客户端将gr填充到握手报文ClientHello的随机数字段。
2.2)对于客户端支持ECDHE密钥交换的每条椭圆曲线，客户端计算握手临时密钥其中，HKDF函数定义参见RFC 8446，name为椭圆曲线的名称，len为客户端握手临时密钥长度。客户端将eskc对应的公钥填充到握手报文ClientHello的密钥交换扩展key_share中。
2.3)客户端将构造好的握手报文ClientHello发送给服务器。
第三步，中间件监听到握手报文ClientHello后，保存到本地，并将握手报文ClientHello转发到服务器。
第四步，服务器收到握手报文ClientHello，向客户端发送ServerHello报文、EncryptedExtensions报文、Certificate报文、CertificateVerify报文、server Finished报文，其中，ServerHello报文为服务器握手报文，EncryptedExtensions报文为服务器加密扩展报文，Certificate报文为证书报文，CertificateVerify报文为证书判定报文，serverFinished报文为服务器握手结束报文。
第五步，中间件监听到ServerHello报文，根据报文key_share扩展中选择的椭圆曲线计算客户端的握手临时私钥并计算Diffie-Hellman密钥交换结果其中epks为服务器所选择的临时握手公钥。然后，中间件计算握手报文加密密钥，其中，HKDF-Extract、HKDF-Expand-Label和Derive-Secret等函数的定义参见RFC 8446，具体包括以下步骤：
5.1)利用HKDF-Extract(0,psk)生成初期密钥early_secret，其中psk为服务器和客户端之间的预共享密钥，early_secret为生成的初期密钥，用于生成后续其他密钥；
5.2)利用Derive-Secret(early_secret,“derived”,“”)生成第一临时密钥temp_secret_1，其中early_secret为步骤5.1中生成的初期密钥，temp_secret_1为第一临时密钥，用于生成后续其他密钥；
5.3)利用HKDF-Extract(temp_secret_1,Z)生成握手密钥handshake_secret，其中temp_secret_1为步骤5.2中生成的第一临时密钥，Z为服务器和客户端之间Diffie-Hellman密钥协商结果；
5.4)利用Derive-Secret(handshake_secret,“c hs traffic”,ClientHello…ServerHello)生成客户端握手流量密钥client_handshake_traffic_secret，其中handshake_secret为步骤5.3中生成的握手密钥，ClientHello…ServerHello为从客户端ClientHello报文到服务器ServerHello报文之间的所有报文内容；
5.5)利用Derive-Secret(handshake_secret,“s hs traffic”,ClientHello…ServerHello)生成服务器握手流量密钥server_handshake_traffic_secret，其中handshake_secret为步骤5.3中生成的握手密钥，ClientHello…ServerHello为从客户端ClientHello报文到服务器ServerHello报文之间所有的报文内容；
5.6)利用HKDF-Expand-Label(client_handshake_traffic_secret,“iv”,“”,iv_length)生成客户端加密握手报文初始向量client_handshake_write_iv，其中client_handshake_traffic_secret为步骤5.4中生成的客户端握手流量密钥，iv_length为客户端加密握手报文初始向量长度；
5.7)利用HKDF-Expand-Label(client_handshake_traffic_secret,“key”,“”,key_length)生成客户端加密握手报文密钥client_handshake_write_key，其中client_handshake_traffic_secret为步骤5.4中生成的客户端握手流量密钥，key_length为客户端加密握手报文密钥长度；
5.8)利用HKDF-Expand-Label(server_handshake_traffic_secret,“iv”,“”,iv_length)生成服务器加密握手报文初始向量server_handshake_write_iv，其中server_handshake_traffic_secret为步骤5.5中生成的服务器握手流量密钥，iv_length为服务器加密握手报文初始向量长度；
5.9)利用HKDF-Expand-Label(server_handshake_traffic_secret,“key”,“”,key_length)生成服务器加密握手报文密钥server_handshake_write_key，其中server_handshake_traffic_secret为步骤5.5中生成的服务器握手流量密钥，key_length为服务器加密握手报文密钥长度；
第六步，中间件收到EncryptedExtensions、Certificate、CertificateVerify、server Finished报文后，使用server_handshake_write_iv和server_handshake_write_key对报文进行解密，并通过计算，还原会话密钥，同时转发收到的EncryptedExtensions、Certificate、CertificateVerify、server Finished报文给客户端，具体包括以下步骤：
6.1)利用Derive-Secret(handshake_secret,“derived”,“”)生成第二临时密钥temp_secret_2，其中handshake_secret为步骤5.3中生成的握手密钥；
6.2)利用HKDF-Extract(temp_secret_2,0)生成主密钥master_secret，其中temp_secret_2为步骤6.1中生成的第二临时密钥；
6.3)利用Derive-Secret(master_secret,“c app traffic”,ClientHello…server Finished)生成客户端应用流量密钥client_application_traffic_secret，其中master_secret为步骤6.2中生成的主密钥，ClientHello…server Finished为从客户端ClientHello报文到服务器Finished报文之间的所有报文内容；
6.4)利用Derive-Secret(master_secret,“s app traffic”,ClientHello…server Finished)生成服务器应用流量密钥server_application_traffic_secret，其中master_secret为步骤6.2中生成的主密钥，ClientHello…server Finished为从客户端ClientHello报文到服务器Finished报文之间的所有报文内容；
6.5)利用HKDF-Expand-Label(client_application_traffic_secret,“iv”,“”,iv_length)生成客户端加密应用流量初始向量client_application_write_iv，其中client_application_traffic_secret为步骤6.3中生成的客户端应用流量密钥，iv_length为客户端加密应用流量初始向量长度；
6.6)利用HKDF-Expand-Label(client_application_traffic_secret,“key”,“”,key_length)生成客户端加密应用流量密钥client_application_write_key，其中client_application_traffic_secret为步骤6.3中生成的客户端应用流量密钥，key_length为客户端加密应用流量密钥长度；
6.7)利用HKDF-Expand-Label(server_application_traffic_secret,“iv”,“”,iv_length)生成服务器加密应用流量初始向量server_application_write_iv，其中server_application_traffic_secret为步骤6.4中生成的服务器应用流量密钥，iv_length为服务器加密应用流量初始向量长度；
6.8)利用HDKF-Expand-Label(server_application_traffic_secret,“key”,“”,key_length)生成服务器加密应用流量密钥server_application_write_key，其中server_application_traffic_secret为步骤6.4中生成的服务器应用流量密钥，key_length为服务器加密应用流量密钥的长度；
第七步，客户端收到服务器报文后，向中间件发送客户端证书报文Certificate、证书判定报文CertificateVerify，以及客户端握手结束报文client Finished。
第八步，中间件收到客户端发送的Certificate、CertificateVerify和clientFinished报文后，将报文转发给服务器，并利用Derive-Secret(master_secret,“resmaster”,ClientHello…client Finished)生成会话复用主密钥resumption_master_secret，其中master_secret为步骤6.2中生成的主密钥，ClientHello…client Finished为从客户端握手报文到客户端握手结束报文之间所有的报文内容。
第九步，客户端和服务器握手完成，之后的会话流量被加密传输，中间件解密TLS流量，执行中间件功能。中间件对会话流量进行转发，同时使用server_application_write_iv和server_application_write_key对服务器发出的流量进行解密，使用client_application_write_iv和client_application_write_key对客户端发出的流量进行解密。之后，中间件可在解密之后的流量上执行病毒检测等功能。
与现有技术相比，本发明的有益效果是：
●相比于传统中间人技术，本发明维护了密钥协商的“抗未知密钥共享”安全，客户端可对服务器的身份进行认证；本发明提供粗粒度的访问控制，客户端可选择能够解密流量的中间件；此外，本发明中间件不需要对流量进行重新加密，大幅减少了中间件的计算开销；
●相比于中间件内置服务器私钥的方案，本发明适用于TLS的各个版本，包括TLS1.3；
●相比于BlindBox，本发明支持任何功能的中间件，而非特定的搜索功能；
●相比于mcTLS，本发明可兼容原有TLS协议，在TLS握手过程中并不引入额外的通信开销；计算开销方面，本发明相对于mcTLS带来的额外计算开销可忽略不计；
●相比于带外密钥传输方案，本发明不引入额外的通信开销，在软件兼容性方面也更胜一筹。
附图说明
图1是本发明以客户端与中间件进行随机数同步为例，中间件还原TLS1.3会话密钥流程图；
图2是本发明和正常TLS1.3协议连接建立时间对比图；
图3是使用本发明的流量审查中间件对数据传输吞吐率的影响；
图4是TLS终端之间使用chacha20加密算法时，使用本发明的流量审查中间件对响应时间的影响；
图5是TLS终端之间使用aes128gcm加密算法时，使用本发明的流量审查中间件对响应时间的影响；
图6是TLS终端之间使用aes256gcm加密算法时，使用本发明的流量审查中间件对响应时间的影响；
图7是使用本发明的流量审查中间件的内存使用量。
具体实施方式：
以下结合说明书附图和具体优选的实施例对本发明作进一步描述，步骤包括：
第一步，中间件随机生成公私钥对(skm，pkm)，其中g为椭圆曲线x25519的生成元。中间件将私钥skm秘密保存，将公钥pkm发送给客户端。
第二步，客户端收到公钥pkm后，保存到本地，用于后续建立TLS连接时生成握手临时私钥。客户端和服务器进行握手，在构造握手报文时，客户端选择随机数r，将gr填充到握手报文的随机数字段。对于客户端选择用于ECDHE密钥交换的椭圆曲线，客户端计算握手临时密钥客户端将eskc对应的公钥填充到ClientHello报文的密钥交换扩展key_share中。
第三步，中间件监听到ClientHello报文后，保存到本地，并转发给服务器。
第四步，服务器收到ClientHello报文，向客户端发送ServerHello、EncryptedExtensions、Certificate、CertificateVerify、server Finished报文。
第五步，中间件监听到ServerHello报文后，还原客户端的握手临时私钥，进而生成客户端和服务器之间的握手报文加密密钥。
第六步，中间件监听到余下服务器握手报文后，使用握手报文加密密钥进行解密，进而生成客户端和服务器之间加密会话流量的会话密钥，同时转发收到的报文给客户端。
第七步，客户端收到服务器报文后，向中间件发送Certificate、CertificateVerify报文以及client Finished报文。
第八步，中间件收到客户端发送的Certificate、CertificateVerify和clientFinished报文后，将报文转发给服务器，并计算会话复用主密钥resumption_master_secret。
第九步，客户端和服务器握手完成，之后的会话流量被加密传输。中间件对会话流量进行解密，在解密之后的流量上执行病毒检测等功能，并转发流量。
为评估本发明的实用性，本发明实现了一个TLS流量检测中间件，并与原有TLS1.3协议在连接建立时间、数据传输吞吐率和响应速度等方面进行了对比。
实验设置
客户端使用开源库tlslite-ng实现，客户端和服务器运行于两台物理机器上，配置为Intel i5-7200U CPU，8GB内存，CentOS 7操作系统；流量审查中间件运行于另一台物理机器上，配置为Intel i7-6700CPU，16GB内存，CentOS 7操作系统；三台机器之间通过100Mbps网络连接。
TLS连接建立时间对比
我们对比支持本发明的增强型TLS1.3连接建立时间和原有TLS1.3连接建立时间。实验中调整握手阶段密钥交换模式和所使用的椭圆曲线，实验结果如图2所示。从图2中可以看到，当握手阶段密钥交换模式和所使用的曲线固定后，本发明的增强型TLS连接建立时间与原有TLS连接建立时间基本相同，因此，可得出以下结论：本发明给TLS客户端带来的额外计算开销可忽略不计，连接建立时间基本不受影响。
数据传输吞吐率对比
许多应用使用TLS传输数据，在大数据量传输的应用场景下，数据传输速率成为关键的性能指标。在此我们衡量使用本发明对TLS流量进行检测的中间件对数据传输速率带来的影响。流量检测规则采用ClamAV规则集，实验中控制中间件使用的流量检测数量，以及TLS终端之间加密流量的对称加密算法，实验结果如图3所示。从图3中可以看出，数据传输吞吐率和流量审查规则数量无关。实验中测试了TLS流量不经过中间件审查时的数据吞吐率，经计算得出，中间件审查流量使数据传输吞吐率下降2.81％～7.99％，在可接受的合理范围内。
响应时间对比
微博等应用通常会产生较小的TLS报文，对于此类应用，响应时间是影响用户体验的关键性能指标。我们评估使用本发明进行TLS流量审查的中间件对响应时间的影响。实验中，客户端发送请求给服务器，服务器返回响应报文，实验中客户端和服务器重复上述步骤1000次以获取平均响应时间。实验中控制服务器响应报文长度和TLS终端之间加密流量的对称加密算法，结果如图4、图5、图6所示。对于不同的对称加密算法，我们计算使用本发明的流量审查中间设备对响应时间带来的影响平均值，如表1所示，可以看出，使用本发明的流量审查中间件对响应时间带来的影响在合理的可接受范围内。
表1流量审查中间件对响应时间的影响
加密算法 chacha20 aes128gcm aes256gcm
响应时间增长 23.3％ 16.8％ 7.4％
中间件内存使用量
我们对使用本发明的中间件的内存使用量进行评估，实验中控制客户端和服务器之间并发TLS连接的数量，并记录中间件处理这些并发TLS连接所使用的内存量，结果如图7所示。从图7中可以看出，使用本发明的中间件内存使用量随着并发TLS连接数量线性增长。当并发连接数量达到5000时，中间件的内存使用量不超过800MB，说明本发明具有良好的可扩展性，适合实际部署使用。
最后说明的是，以上仅是本发明的优选实施例，并非对本发明作任何形式上的限制。虽然本发明已以优选实施例揭露如上，然而并非用以限定本发明。任何熟悉本领域的技术人员，在不脱离本发明技术方案范围的情况下，都可利用上述揭示的技术内容对本发明技术方案做出许多可能的变动和修饰，或修改为等同变化的等效实施例。因此，凡是未脱离本发明技术方案的内容，依据本发明技术实质对以上实施例所做的任何简单修改、等同变化及修饰，均应落在本发明技术方案保护的范围内。

Claims (5)

1.基于随机数隐式协商的TLS协议会话密钥还原方法，其特征在于，包括以下步骤：
第一步，中间件生成公私钥对(skm，pkm)，skm为中间件的私钥，pkm为中间件的公钥，其中g为椭圆曲线x25519的生成元；中间件将私钥skm秘密保存，将公钥pkm发送给客户端；
第二步，客户端收到公钥pkm后，保存到本地；客户端和服务器进行握手，使用中间件公钥pkm构造握手报文ClientHello，并将握手报文发送给服务器；
第三步，中间件监听到握手报文ClientHello后，保存到本地，并将握手报文ClientHello转发到服务器；
第四步，服务器收到握手报文ClientHello，向客户端发送ServerHello报文、EncryptedExtensions报文、Certificate报文、CertificateVerify报文、server Finished报文，其中，ServerHello报文为服务器握手报文，EncryptedExtensions报文为服务器加密扩展报文，Certificate报文为证书报文，CertificateVerify报文为证书判定报文，serverFinished报文为服务器握手结束报文；
第五步，中间件监听到ServerHello报文，根据报文key_share扩展中选择的椭圆曲线计算客户端的握手临时私钥并计算Diffie-Hellman密钥交换结果其中epks为服务器所选择的临时握手公钥，HKDF函数定义参见RFC8446；然后，中间件计算握手报文加密密钥；
第六步，中间件收到EncryptedExtensions、Certificate、CertificateVerify、serverFinished报文后，对报文进行解密，并通过计算，还原会话密钥，得到主密钥master_secret，同时转发收到的EncryptedExtensions、Certificate、CertificateVerify、serverFinished报文给客户端；
第七步，客户端收到服务器报文后，向中间件发送客户端证书报文Certificate、证书判定报文CertificateVerify，以及客户端握手结束报文client Finished；
第八步，中间件收到客户端发送的Certificate、CertificateVerify和clientFinished报文后，将报文转发给服务器，并利用函数Derive-Secret(master_secret，“resmaster”，ClientHello...client Finished)生成会话复用主密钥resumption_master_secret，其中master_secret为第六步生成的主密钥，ClientHello...client Finished为从客户端握手报文到客户端握手结束报文之间所有的报文内容，其中，Derive-Secret函数的定义参见RFC 8446；
第九步，客户端和服务器握手完成，中间件解密TLS流量，执行中间件功能。
2.如权利要求1所述的基于随机数隐式协商的TLS协议会话密钥还原方法，其特征在于，所述第二步具体包括以下步骤：
2.1)客户端发起TLS连接，选择随机数r，计算gr，客户端将gr填充到握手报文ClientHello的随机数字段；
2.2)对于客户端支持ECDHE密钥交换的每条椭圆曲线，客户端计算握手临时密钥其中，HKDF函数定义参见RFC 8446，name为椭圆曲线的名称，len为客户端握手临时密钥长度；客户端将eskc对应的公钥填充到握手报文ClientHello的密钥交换扩展key_share中；
2.3)客户端将构造好的握手报文ClientHello发送给服务器。
3.如权利要求1所述的基于随机数隐式协商的TLS协议会话密钥还原方法，其特征在于，所述第五步中间件计算握手报文加密密钥，具体包括下述步骤，其中，HKDF-Extract、HKDF-Expand-Label和Derive-Secret等函数的定义参见RFC 8446：
5.1)利用HKDF-Extract(0，psk)生成初期密钥early_secret，其中psk为服务器和客户端之间的预共享密钥，early_secret为生成的初期密钥，用于生成后续其他密钥；
5.2)利用Derive-Secret(early_secret，“derived”，“”)生成第一临时密钥temp_secret_1，其中early_secret为步骤5.1中生成的初期密钥，temp_secret_1为第一临时密钥，用于生成后续其他密钥；
5.3)利用HKDF-Extract(temp_secret_1，Z)生成握手密钥handshake_secret，其中temp_secret_1为步骤5.2中生成的第一临时密钥，Z为服务器和客户端之间Diffie-Hellman密钥协商结果；
5.4)利用Derive-Secret(handshake_secret，“c hs traffic”，ClientHello...ServerHello)生成客户端握手流量密钥client_handshake_traffic_secret，其中handshake_secret为步骤5.3中生成的握手密钥，ClientHello...ServerHello为从客户端ClientHello报文到服务器ServerHello报文之间的所有报文内容；
5.5)利用Derive-Secret(handshake_secret，“s hs traffic”，ClientHello...ServerHello)生成服务器握手流量密钥server_handshake_traffic_secret，其中handshake_secret为步骤5.3中生成的握手密钥，ClientHello...ServerHello为从客户端ClientHello报文到服务器ServerHello报文之间所有的报文内容；
5.6)利用HKDF-Expand-Label(client_handshake_traffic_secret，“iv”，“”，iv_length)生成客户端加密握手报文初始向量client_handshake_write_iv，其中client_handshake_traffic_secret为步骤5.4中生成的客户端握手流量密钥，iv_length为客户端加密握手报文初始向量长度；
5.7)利用HKDF-Expand-Label(client_handshake_traffic_secret，“key”，“”，key_length)生成客户端加密握手报文密钥client_handshake_write_key，其中client_handshake_traffic_secret为步骤5.4中生成的客户端握手流量密钥，key_length为客户端加密握手报文密钥长度；
5.8)利用HKDF-Expand-Label(server_handshake_traffic_secret，“iv”，“”，iv_length)生成服务器加密握手报文初始向量server_handshake_write_iv，其中server_handshake_traffic_secret为步骤5.5中生成的服务器握手流量密钥，iv_length为服务器加密握手报文初始向量长度；
5.9)利用HKDF-Expand-Label(server_handshake_traffic_secret，“key”，“”，key_length)生成服务器加密握手报文密钥server_handshake_write_key，其中server_handshake_traffic_secret为步骤5.5中生成的服务器握手流量密钥，key_length为服务器加密握手报文密钥长度。
4.如权利要求1所述的基于随机数隐式协商的TLS协议会话密钥还原方法，其特征在于，所述第六步具体包括以下步骤：
6.1)利用Derive-Secret(handshake_secret，“derived”，“”)生成第二临时密钥temp_secret_2，其中handshake_secret为步骤5.3中生成的握手密钥；
6.2)利用HKDF-Extract(temp_secret_2，0)生成主密钥master_secret，其中temp_secret_2为步骤6.1中生成的第二临时密钥；
6.3)利用Derive-Secret(master_secret，“c app traffic”，ClientHello...serverFinished)生成客户端应用流量密钥client_application_traffic_secret，其中master_secret为步骤6.2中生成的主密钥，ClientHello...server Finished为从客户端ClientHello报文到服务器Finished报文之间的所有报文内容；
6.4)利用Derive-Secret(master_secret，“s app traffic”，ClientHello...serverFinished)生成服务器应用流量密钥server_application_traffic_secret，其中master_secret为步骤6.2中生成的主密钥，ClientHello...server Finished为从客户端ClientHello报文到服务器Finished报文之间的所有报文内容；
6.5)利用HKDF-Expand-Label(client_application_traffic_secret，“iv”，“”，iv_length)生成客户端加密应用流量初始向量client_application_write_iv，其中client_application_traffic_secret为步骤6.3中生成的客户端应用流量密钥，iv_length为客户端加密应用流量初始向量长度；
6.6)利用HKDF-Expand-Label(client_application_traffic_secret，“key”，“”，key_length)生成客户端加密应用流量密钥client_application_write_key，其中client_application_traffic_secret为步骤6.3中生成的客户端应用流量密钥，key_length为客户端加密应用流量密钥长度；
6.7)利用HKDF-Expand-Label(server_application_traffic_secret，“iv”，“”，iv_length)生成服务器加密应用流量初始向量server_application_write_iv，其中server_application_traffic_secret为步骤6.4中生成的服务器应用流量密钥，iv_length为服务器加密应用流量初始向量长度；
6.8)利用HDKF-Expand-Label(server_application_traffic_secret，“key”，“”，key_length)生成服务器加密应用流量密钥server_application_write_key，其中server_application_traffic_secret为步骤6.4中生成的服务器应用流量密钥，key_length为服务器加密应用流量密钥的长度。
5.如权利要求1所述的基于随机数隐式协商的TLS协议会话密钥还原方法，其特征在于，所述第九步中间件具体执行以下功能：对会话流量进行转发，对服务器发出的流量进行解密，对客户端发出的流量进行解密，然后，中间件在解密后的流量上执行病毒检测功能。
CN201910072962.0A 2019-01-25 2019-01-25 基于随机数隐式协商的tls协议会话密钥还原方法 Active CN109600226B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910072962.0A CN109600226B (zh) 2019-01-25 2019-01-25 基于随机数隐式协商的tls协议会话密钥还原方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910072962.0A CN109600226B (zh) 2019-01-25 2019-01-25 基于随机数隐式协商的tls协议会话密钥还原方法

Publications (2)

Publication Number Publication Date
CN109600226A true CN109600226A (zh) 2019-04-09
CN109600226B CN109600226B (zh) 2020-05-05

Family

ID=65966574

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910072962.0A Active CN109600226B (zh) 2019-01-25 2019-01-25 基于随机数隐式协商的tls协议会话密钥还原方法

Country Status (1)

Country Link
CN (1) CN109600226B (zh)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111431887A (zh) * 2020-03-19 2020-07-17 深信服科技股份有限公司 一种反向Shell的监测方法、装置、终端设备及介质
CN111510291A (zh) * 2020-04-20 2020-08-07 重庆邮电大学 基于双线性对的高效身份认证密钥协商协议
CN111800416A (zh) * 2020-07-03 2020-10-20 西南大学 基于非单调性动态认知逻辑的密码协议分析方法
CN111835688A (zh) * 2019-04-22 2020-10-27 中国科学院声学研究所 一种基于ssl/tls协议的流量快速转发方法及系统
CN112311544A (zh) * 2020-12-31 2021-02-02 飞天诚信科技股份有限公司 一种服务器与认证器进行通信的方法及系统
CN112511550A (zh) * 2020-12-02 2021-03-16 迈普通信技术股份有限公司 通信方法、装置、电子设备及存储介质
CN112507373A (zh) * 2020-11-02 2021-03-16 北京迅达云成科技有限公司 一种工业互联网中工业现场数据远程访问方法
CN114139192A (zh) * 2022-02-07 2022-03-04 奇安信科技集团股份有限公司 加密流量处理方法、装置、电子设备、介质及程序
CN114499913A (zh) * 2020-10-26 2022-05-13 华为技术有限公司 加密报文的检测方法及防护设备
CN114679265A (zh) * 2022-03-22 2022-06-28 奇安信科技集团股份有限公司 流量获取方法、装置、电子设备和存储介质
CN117424742A (zh) * 2023-11-03 2024-01-19 中国人民解放军国防科技大学 一种无感知传输层安全协议会话密钥还原方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1889433A (zh) * 2006-07-20 2007-01-03 上海交通大学 基于隐式公钥证书的双方认证密钥协商方法及系统
CN106790049A (zh) * 2016-12-19 2017-05-31 北京中电普华信息技术有限公司 基于混合密码套件中间件的数据安全传输方法与装置
US20180060608A1 (en) * 2016-08-30 2018-03-01 Wacom Co., Ltd. Authentication and secure transmission of data between signature devices and host computers using transport layer security

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1889433A (zh) * 2006-07-20 2007-01-03 上海交通大学 基于隐式公钥证书的双方认证密钥协商方法及系统
US20180060608A1 (en) * 2016-08-30 2018-03-01 Wacom Co., Ltd. Authentication and secure transmission of data between signature devices and host computers using transport layer security
CN106790049A (zh) * 2016-12-19 2017-05-31 北京中电普华信息技术有限公司 基于混合密码套件中间件的数据安全传输方法与装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
董海韬等: "适用于网络内容审计的SSL/TLS保密数据高效明文采集方法", 《计算机应用》 *

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111835688A (zh) * 2019-04-22 2020-10-27 中国科学院声学研究所 一种基于ssl/tls协议的流量快速转发方法及系统
CN111835688B (zh) * 2019-04-22 2021-07-30 中国科学院声学研究所 一种基于ssl/tls协议的流量快速转发方法及系统
CN111431887A (zh) * 2020-03-19 2020-07-17 深信服科技股份有限公司 一种反向Shell的监测方法、装置、终端设备及介质
CN111431887B (zh) * 2020-03-19 2022-09-30 深信服科技股份有限公司 一种反向Shell的监测方法、装置、终端设备及介质
CN111510291A (zh) * 2020-04-20 2020-08-07 重庆邮电大学 基于双线性对的高效身份认证密钥协商协议
CN111800416A (zh) * 2020-07-03 2020-10-20 西南大学 基于非单调性动态认知逻辑的密码协议分析方法
CN114499913A (zh) * 2020-10-26 2022-05-13 华为技术有限公司 加密报文的检测方法及防护设备
CN114499913B (zh) * 2020-10-26 2022-12-06 华为技术有限公司 加密报文的检测方法及防护设备
CN112507373A (zh) * 2020-11-02 2021-03-16 北京迅达云成科技有限公司 一种工业互联网中工业现场数据远程访问方法
CN112511550A (zh) * 2020-12-02 2021-03-16 迈普通信技术股份有限公司 通信方法、装置、电子设备及存储介质
CN112511550B (zh) * 2020-12-02 2022-02-22 迈普通信技术股份有限公司 通信方法、装置、电子设备及存储介质
WO2022142717A1 (zh) * 2020-12-31 2022-07-07 飞天诚信科技股份有限公司 一种服务器与认证器进行通信的方法及系统
CN112311544B (zh) * 2020-12-31 2021-03-16 飞天诚信科技股份有限公司 一种服务器与认证器进行通信的方法及系统
CN112311544A (zh) * 2020-12-31 2021-02-02 飞天诚信科技股份有限公司 一种服务器与认证器进行通信的方法及系统
CN114139192A (zh) * 2022-02-07 2022-03-04 奇安信科技集团股份有限公司 加密流量处理方法、装置、电子设备、介质及程序
CN114139192B (zh) * 2022-02-07 2022-07-05 奇安信科技集团股份有限公司 加密流量处理方法、装置、电子设备、介质及程序
CN114679265A (zh) * 2022-03-22 2022-06-28 奇安信科技集团股份有限公司 流量获取方法、装置、电子设备和存储介质
CN114679265B (zh) * 2022-03-22 2024-03-01 奇安信科技集团股份有限公司 流量获取方法、装置、电子设备和存储介质
CN117424742A (zh) * 2023-11-03 2024-01-19 中国人民解放军国防科技大学 一种无感知传输层安全协议会话密钥还原方法
CN117424742B (zh) * 2023-11-03 2024-03-26 中国人民解放军国防科技大学 一种无感知传输层安全协议会话密钥还原方法

Also Published As

Publication number Publication date
CN109600226B (zh) 2020-05-05

Similar Documents

Publication Publication Date Title
CN109600226A (zh) 基于随机数隐式协商的tls协议会话密钥还原方法
US11165757B2 (en) Method and apparatus for securing communications using multiple encryption keys
US20190334950A1 (en) Private key operations
CN105027493B (zh) 安全移动应用连接总线
US9176838B2 (en) Encrypted data inspection in a network environment
Wilson et al. Trust but verify: Auditing the secure Internet of things
Lee et al. maTLS: How to Make TLS middlebox-aware?
CN106790090A (zh) 基于ssl的通信方法、装置及系统
EP3461097A1 (en) Encrypted content detection method and apparatus
Petullo et al. MinimaLT: minimal-latency networking through better security
CN105429962B (zh) 一种通用的面向加密数据的中间网络服务构建方法与体系
Li et al. ME-TLS: middlebox-enhanced TLS for internet-of-things devices
de Carné de Carnavalet et al. A Survey and Analysis of TLS Interception Mechanisms and Motivations: Exploring how end-to-end TLS is made “end-to-me” for web traffic
Poh et al. A survey of privacy-preserving techniques for encrypted traffic inspection over network middleboxes
CN113904767A (zh) 一种基于ssl建立通信的系统
Atighetchi et al. Safe configuration of TLS connections
Hussain et al. Boost Secure Sockets Layer against Man-in-the-Middle Sniffing Attack via SCPK
CN117424742B (zh) 一种无感知传输层安全协议会话密钥还原方法
Faisal et al. Graphene: a secure cloud communication architecture
Gagana et al. Secure Authentication and Security System for IoT Environment
King et al. HTTPA/2: a Trusted End-to-End Protocol for Web Services
EP3051770A1 (en) User opt-in computer implemented method for monitoring network traffic data, network traffic controller and computer programs
Das et al. QoS web service Security Access Control case study using HTTP Secured Socket Layer Approach
Tselios et al. Improving Network, Data and Application Security for SMEs
Zeidler et al. Performance Evaluation of Transport Layer Security in the 5G Core Control Plane

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant