一种无感知传输层安全协议会话密钥还原方法

技术领域

本发明属于计算机网络安全技术领域，涉及一种安全的网络协议密钥还原方法，具体涉及一种无感知传输层安全(Transport Layer Security，TLS)协议会话密钥还原方法。

背景技术

在信息通信时代，计算机终端面临的最严重的安全威胁之一是各种计算机病毒。为了应对这些威胁，人们可以安装防毒卡或杀毒软件等安全工具，以提供有效的安全保护。然而随着网络技术的飞速发展，终端设备所面临的安全挑战变得更加复杂和多样化。这些挑战包括木马、间谍软件、劫持攻击、钓鱼邮件、钓鱼网站等等。这意味着人们不能仅仅依赖于在终端设备上安装安全软件来保护计算机系统。

因此，需要在网络边界部署更多的基于网络的安全防御方法，这些方法包括防火墙、入侵检测系统IDS/IPS、内容审核、数据审计等。与传统的基于主机的安全软件不同，基于网络的安全设施并不仅限于单个主机，它们构成了一个更全面、更通用的安全体系。基于网络流量的安全设施不限于特定主机，而是针对网络内的所有主机。这使得它们可以发现和应对更广泛的网络威胁，并收集更多的信息来评估网络的安全状况。此外，这些安全设施不依赖于特定主机环境，因此对于资源有限、缺乏自我保护机制的物联网设备来说尤其有用。这些网络安全设施提供了一种更通用、更全面的安全解决方案，与传统的主机安全软件相辅相成。一些安全设施还可以防止内部人员安装未经授权的软件，并在受感染的主机上禁用安全软件时提供反馈。

在基于网络的安全设施中，传输层安全检测(TLS Inspection)是一个关键组成部分。TLS检测可用于监视、拦截或转发企业网络或移动网络中的HTTPS流量。例如，防火墙和IDS需要检查网络流量以实施基于边界的安全策略。根据不同的安全功能需求，这些检测设备可以部署为流量监控设备或在线检测设备：流量监控设备可以执行威胁监测、入侵检测、加密审计、合规监视等功能；在线检测设备则可以用于防止非法下载、阻止已知威胁网址、强制使用强密码、阻止数据泄露等应用场景。

TLS检测是一种用于深度检查加密网络流量的技术，允许网络管理员解密、检查和监视传输道和从其网络中的加密通信。这一技术在企业数据中心网络安全中有重要的应用场景，尤其是当需要确保内部网络的安全性和合规性时。以下是TLS检测的应用场景：

1)恶意流量检测。TLS检测可以用于检测传入和传出企业网络的恶意流量。通过解密TLS流量，网络管理员可以分析流量中的恶意代码、恶意软件或攻击行为，并采取相应的措施来封锁或隔离恶意流量。

2)内部威胁检测。企业数据中心可能面临来自内部的威胁，如内部员工或合作伙伴的恶意行为。TLS检测可用于监视内部流量，以检测不寻常的活动，如数据泄露、未经授权的访问或未经授权的数据传输。

3)合规性和监管要求。一些合规性标准和监管要求会要求企业对其网络流量进行审计和监视，以确保数据的隐私和安全。TLS检测可以帮助企业满足这些要求，提供必要的审计和监视功能。

4)应用程序控制。通过解密TLS流量，企业可以实施应用程序控制策略，以限制或监视特定应用程序的使用。这对于阻止未经授权的应用程序或实施网络访问策略非常有用。

5)数据丢失预防。TLS检测可以与数据丢失预防解决方案集成，以监视和控制敏感数据的传输。如果发现敏感数据正在传输到未经授权的位置，系统可以采取措施，如阻止数据传输或生成警报。

6)恶意域名和URL检测。通过解密TLS流量，网络管理员可以检测和封锁恶意域名或URL，以防止员工访问恶意网站或受感染的资源。

TLS检测分为客户端侧和服务器侧，本发明主要关注服务器侧。目前服务器侧TLS网络中间设备密钥还原机制主要包括以下四种：

1)网络中间设备内置服务器私钥方法。该方法适用于服务器位于企业网络内部的应用场景，并且使用静态RSA和静态Diffie-Hellman进行密钥交换的TLS密码套件。企业管理员将服务器的私钥内置于TLS网络中间设备，网络中间设备监听客户端和服务器之间的握手过程，使用服务器的私钥计算会话密钥。

但网络中间设备内置服务器私钥方法存在以下技术问题：TLS的新标准版本1.3中，已经放弃了静态RSA和静态Diffie-Hellman握手，改用(EC)Diffie-Hellman握手。每次握手时，客户端和服务器都会产生临时密钥对用于密钥计算。因此，网络中间设备内置服务器私钥的方法不适用于TLS1.3。

2)带外密钥传输。该方案在TLS握手完成后，由客户端或服务器将会话密钥传输给网络中间设备，但带外密钥传输的方法引入了额外的网络通信开销。

3)BlindBox。学术工作BlindBox使用一种可搜索加密方案。在正常的TLS加密流量之外，BlindBox要求客户端或服务器将流量明文使用可搜索加密方案进行加密，与正常TLS流量同时传输。网络中间设备可在BlindBox可搜索加密流量上执行一些特定的检测功能。

但BlindBox使用可搜索加密技术的问题在于，它只满足一部分网络中间设备的需求——例如入侵检测这种主要运用模式匹配的网络中间设备。而另一些网络中间设备，比如压缩代理(compression proxies)需要进行任意计算(arbitrary computation)，就无法使用可搜索加密技术。

4)mcTLS。mcTLS修改原有TLS协议，使网络中间设备参与握手过程密钥协商，细粒度控制网络中间设备对TLS流量的读写权限。mcTLS将数据按照网络中间设备的读写权限进行切分，握手完成后为每块数据生成多个对称密钥，拥有对应读写权限的网络中间设备可生成相应的密钥。

mcTLS方案也存在如下问题：首先，mcTLS大幅修改原有协议，不兼容现有协议，难以部署使用；其次，mcTLS的握手过程引入了大量额外的通信开销和计算开销。

发明内容

针对现有TLS网络中间设备防护方案存在无法满足TLS加密流量高效还原的难题，本发明提出一种无感知TLS协议会话密钥还原方法，支持TLS加密流量高效还原，该还原方法可应用于TLS服务器侧的网络中间设备，并满足以下特征：

1)是一种面向TLS加密流量还原的方法，既可以应用于TLS服务器侧，也可以用于客户端侧；

2)兼容TLS各个版本，主要面向TLS1.3；

3)用户无感知，无需维护额外的TLS连接来传输密钥，也无需使用中间人技术将TLS连接分割为两条TLS连接，网络中间设备只需要被动监听即可还原会话密钥；

4)兼容原有TLS协议，支持标准TLS客户端与定制TLS服务器终端的通信；

5)不破坏TLS连接的源认证性；

6)无需额外的密钥管理，一条TLS连接只需一个管理密钥；

7)能进行粗粒度的访问控制，可限定网络中间设备是否能访问TLS会话的加密数据；

8)支持加密数据包离线检测，网络中间设备只需TLS加密流量，即可还原TLS会话密钥。

本发明提出一种无感知TLS协议会话密钥还原方法，该方法分为以下步骤：

第一步，对于服务器支持的每一条椭圆曲线(例如椭圆曲线X25519或椭圆曲线secp256r1)，网络中间设备生成公私钥对(sk

第二步，服务器保存网络中间设备公钥pk

第三步，客户端向服务器发送客户端ClientHello消息，请求建立TLS连接，客户端按照标准TLS协议，对于每一条客户端支持的椭圆曲线，依次生成客户端临时公私钥对(esk

第四步，网络中间设备监听到客户端ClientHello消息，将客户端ClientHello消息保存在本地，并转发客户端ClientHello消息至服务器。

第五步，服务器收到客户端ClientHello消息，构造服务器ServerHello消息；具体步骤如下：

5.1)服务器选择一条客户端支持的椭圆曲线curve，椭圆曲线curve的生成元为g；

5.2)服务器根据椭圆曲线curve，生成服务器临时公私钥对(esk

5.3)服务器计算加密密钥

5.4)服务器计算服务器随机数

5.5)服务器将epk

第六步，服务器回复服务器ServerHello消息给客户端，服务器计算与客户端的Diffie-Hellman密钥交换结果ECDHE，并回复给客户端加密的服务器EncryptedExtensions消息、服务器Certificate消息、服务器CertificateVerify消息和服务器ServerFinished消息，其中，服务器ServerHello消息为服务器握手消息，服务器EncryptedExtensions消息为服务器加密扩展消息，服务器Certificate消息为证书消息，服务器CertificateVerify消息为证书判定消息，服务器ServerFinished消息为服务器握手结束消；

第七步，网络中间设备监听到服务器ServerHello消息，保存服务器ServerHello消息，转发服务器ServerHello消息至客户端。网络中间设备从服务器ServerHello消息的Key Share扩展中提取服务器临时公钥epk

7.1)网络中间设备还原加密密钥k，网络中间设备计算

7.2)网络中间设备还原服务器临时私钥esk

第八步，网络中间设备计算客户端与服务器的Diffie-Hellman密钥交换结果，并进一步计算握手消息加密密钥，其中，HKDF-Extract、Derive-Secret和HKDF-Expand-Label函数参见标准RFC 8446，双引号所引的内容表示ASCII编码的字符串，特别的，""表示空字符串，具体步骤如下：

8.1)网络中间设备从客户端ClientHello消息的Key Share扩展中提取客户端公钥epk

8.2)网络中间设备计算客户端和服务器的Diffie-Hellman密钥交换结果

8.3)网络中间设备计算初始密钥early_secret＝HKDF-Extract(0,PSK)，PSK为客户端和服务器之间的预共享密钥，初始密钥early_secret用于生成后续其他密钥；

8.4)网络中间设备计算第一临时密钥temp_secret_1＝Derive-Secret(early_secret,"derived","")，其中early_secret为步骤8.3)生成的初始密钥；

8.5)网络中间设备计算握手密钥handshake_secret＝HKDF-Extract(temp_secret_1,ECDHE)，其中temp_secret_1为步骤8.4)生成的初始密钥，ECDHE是步骤8.2)生成的客户端和服务器的Diffie-Hellman密钥交换结果；

8.6)网络中间设备计算客户端握手流量密钥client_handshake_traffic_secret＝Derive-Secret(handshake_secret,"c hs traffic",ClientHello…ServerHello)，其中handshake_secret为步骤8.5)生成的握手密钥，ClientHello…ServerHello表示从客户端ClientHello消息到服务器ServerHello消息之间所有的握手消息；

8.7)网络中间设备计算服务器握手流量密钥server_handshake_traffic_secret＝Derive-Secret(handshake_secret,"s hs traffic",ClientHello…ServerHello)，其中handshake_secret为步骤8.5)生成的握手密钥，ClientHello…ServerHello表示从客户端ClientHello消息到服务器ServerHello消息之间所有的握手消息；

8.8)网络中间设备计算客户端握手消息加密密钥client_hs_key＝HKDF-Expand-Label(client_handshake_traffic_secret,"key","",key_length)，其中client_handshake_traffic_secret为步骤8.6)生成的客户端握手流量密钥，key_length是以字节为单位的客户端握手加密密钥长度；

8.9)网络中间设备计算客户端握手消息加密初始向量client_hs_iv＝HKDF-Expand-Label(client_handshake_traffic_secret,"iv","",iv_length)，其中client_handshake_traffic_secret为步骤8.6)生成的客户端握手流量密钥，iv_length是以字节为单位的客户端握手加密初始向量长度；

8.10)网络中间设备计算服务器握手消息加密密钥server_hs_key＝HKDF-Expand-Label(server_handshake_traffic_secret,"key","",key_length)，其中server_handshake_traffic_secret为步骤8.7)生成的服务器握手流量密钥，key_length是以字节为单位的服务器握手加密密钥长度；

8.11)网络中间设备计算服务器握手消息加密初始向量server_hs_iv＝HKDF-Expand-Label(server_handshake_traffic_secret,"iv","",iv_length)，其中server_handshake_traffic_secret为步骤8.7)生成的服务器握手流量密钥，iv_length是以字节为单位的服务器握手加密初始向量长度；

第九步，网络中间设备监听服务器发送的加密握手消息，包括加密的服务器EncryptedExtensions消息、服务器Certificate消息、服务器CertificateVerify消息和服务器ServerFinished消息，网络中间设备将加密的服务器EncryptedExtensions消息、服务器Certificate消息、服务器CertificateVerify消息和服务器ServerFinished消息转发至客户端。网络中间设备利用第八步生成的server_hs_key和server_hs_iv还原服务器EncryptedExtensions消息、服务器Certificate消息、服务器CertificateVerify消息和服务器ServerFinished消息，并计算应用流量加密密钥，具体步骤如下：

9.1)网络中间设备计算第二临时密钥temp_secret_2＝Derive-Secret(handshake_secret,"derived","")，其中handshake_secret为步骤8.5)生成的握手密钥；

9.2)网络中间设备计算主密钥master_secret＝HKDF-Extract(temp_secret_2,0)，其中temp_secret_2为步骤9.1)生成的第二临时密钥；

9.3)网络中间设备计算客户端应用流量密钥client_application_traffic_secret＝Derive-Secret(master_secret,"c app traffic",ClientHello…ServerFinished)，其中master_secret是步骤9.2)生成的主密钥，ClientHello…ServerFinished表示从客户端ClientHello消息到服务器ServerFinished消息之间所有的握手消息；

9.4)网络中间设备计算服务器应用流量密钥server_application_traffic_secret＝Derive-Secret(master_secret,"s app traffic",ClientHello…ServerFinished)，其中master_secret是步骤9.2)生成的主密钥，ClientHello…ServerFinished表示从客户端ClientHello消息到服务器ServerFinished消息之间所有的握手消息；

9.5)网络中间设备计算客户端应用流量加密密钥client_app_key＝HKDF-Expand-Label(client_application_traffic_secret,"key","",key_length)，其中client_application_traffic_secret为步骤9.3)生成的客户端应用流量密钥，key_length是以字节为单位的客户端应用流量加密密钥的长度；

9.6)网络中间设备计算客户端应用流量加密初始向量client_app_iv＝HKDF-Expand-Label(client_application_traffic_secret,"iv","",iv_length)，其中client_application_traffic_secret为步骤9.3)生成的客户端应用流量密钥，iv_length是以字节为单位的客户端应用流量加密初始向量的长度；

9.7)网络中间设备计算服务器应用流量加密密钥server_app_key＝HKDF-Expand-Label(server_application_traffic_secret,"key","",key_length)，其中server_application_traffic_secret为步骤9.4)生成的服务器应用流量密钥，key_length是以字节为单位的服务器应用流量加密密钥的长度；

9.8)网络中间设备计算服务器应用流量加密初始向量server_app_iv＝HKDF-Expand-Label(server_application_traffic_secret,"iv","",iv_length)，其中server_application_traffic_secret为步骤9.4)生成的服务器应用流量密钥，iv_length是以字节为单位的服务器应用流量加密初始向量的长度；

第十步，客户端收到服务器消息后，向服务器发送加密的客户端ClientCertificate消息、客户端ClientCertificateVerify消息和客户端ClientFinished消息，其中客户端ClientCertificate消息为客户端证书消息，客户端ClientCertificateVerify消息为客户端判定消息，客户端ClientFinished消息为客户端握手结束消息。

第十一步，网络中间设备捕获到客户端发送的加密握手消息，网络中间设备将加密的客户端ClientCertificate消息、客户端ClientCertificateVerify消息和客户端ClientFinished消息转发至服务器。网络中间设备利用第八步生成的client_hs_key和client_hs_iv对客户端加密握手消息进行解密，并计算会话恢复主密钥resumption_master_secret＝Derive-Secret(master_secret,"res master",ClientHello…ClientFinished)，其中master_secret是步骤9.2)生成的主密钥，ClientHello…ClientFinished是从客户端ClientHello消息到客户端ClientFinished消息之间所有的握手消息。

第十二步，客户端与服务器握手完成，之后的TLS流量被加密传输，网络中间设备还原TLS加密流量：网络中间设备使用client_app_key和client_app_iv还原客户端发出的TLS加密流量，使用servre_app_key和server_app_iv还原服务器发出的TLS加密流量。

在还原TLS加密流量基础上，网络中间设备可对解密流量进行深度检测等操作。

与现有技术相比，本发明的具有以下技术效果：

1.用户无感知，相比于带外密钥传输方案，本发明不需维护额外的安全连接，不引入额外的通信开销，在软件兼容性方面也更好；

2.相比于网络中间设备内置服务器私钥的方案，本发明适用于TLS的各个版本，包括TLS1.3；

3.相比于BlindBox，本发明支持任何功能的网络中间设备，而非特定的搜索功能；

4.相比于mcTLS，本发明可兼容原有TLS协议，在TLS握手过程中并不引入额外的通信开销；计算开销方面，本发明相对于mcTLS带来的额外计算开销可忽略不计；

5.本发明支持对离线TLS加密流量的分析，且无需额外的密钥管理机制。

附图说明

图1是本发明以服务器与网络中间设备进行随机数同步为例，网络中间设备还原TLS1.3会话密钥流程图；

图2是本发明系统测试部署图；

图3是本发明定制终端与标准TLS1.3终端连接建立时间对比；

图4是本发明定制终端与标准TLS1.3终端数据传输速率时间对比；

图5是本发明网络中间设备内存消耗量；

图6是本发明解析离线TLS加密流量平均时间。

具体实施方式：

以下结合说明书附图和具体优选的实施例对本发明作进一步描述，步骤包括：

第一步，对于服务器支持的每一条椭圆曲线，网络中间设备生成公私钥对(sk

第二步，服务器收到网络中间设备公钥pk

第三步，客户端请求建立TLS连接，向服务器发送客户端ClientHello消息。

第四步，网络中间设备监听到客户端ClientHello消息后，保存在本地，并转发服务器。

第五步，服务器收到客户端ClientHello消息，选择一条椭圆曲线curve，生成服务器临时公私钥对(esk

第六步，服务器回复服务器ServerHello消息给客户端，回复给客户端加密的服务器EncryptedExtensions消息、服务器Certificate消息、服务器CertificateVerify消息和ServerFinished消息。

第七步，网络中间设备监听到服务器ServerHello消息，将服务器ServerHello消息转发给客户端，网络中间设备还原服务器临时私钥esk

第八步，网络中间设备计算客户端与服务器Diffie-Hellman密钥交换结果，并进一步生成客户端与服务器之间加密握手消息的加密密钥。

第九步，网络中间设备监听到服务器发送的加密握手消息后，将加密握手消息转发至客户端，同时利用服务器握手消息加密密钥server_hs_key和服务器握手消息加密初始向量server_hs_iv进行解密，并进一步生成加密应用流量的加密密钥。

第十步，客户端收到服务器握手消息后，回复给服务器加密的客户端ClientCertificate消息、客户端ClientCertificateVerify消息和客户端ClientFinished消息。

第十一步，网络中间设备监听到客户端发送的加密的客户端ClientCertificate消息、客户端ClientCertificateVerify消息和客户端ClientFinished消息，将客户端加密握手消息转发至服务器，同时使用客户端握手消息加密密钥client_hs_key和客户端握手消息初始向量client_hs_iv进行解密，并进一步生成会话复用主密钥resumption_master_secret。

第十二步，客户端和服务器完成握手，之后加密传输应用流量。网络中间设备对应用流量进行解密，并对解密流量进行深度流量检测等操作。

为评估本发明的可行性和实用性，本发明实现了一个TLS流量检测网络中间设备，并与原有TLS1.3协议在连接建立时间、数据传输吞吐率和响应速度等方面进行了对比。

实验设置

客户端和服务器均使用开源库tlslite-ng实现，客户端和服务器运行于两台物理机器上，配置为Intel i7-7200U CPU，8GB内存，Ubuntu 20操作系统；网络中间设备运行于另一台物理机器上，配置为Intel i7-6700 CPU，16GB内存，Ubuntu 20操作系统；三台机器之间通过100Mbps网络连接。

TLS连接建立时间对比

连接建立时间指代的时间是，从TLS客户端发送ClientHello消息开始，到TLS客户端和TLS服务器双方都计算得到加密明文消息的对称密钥这一时间段。我们对比支持本发明的定制TLS1.3终端连接建立时间和标准TLS1.3连接建立时间。实验中调整握手阶段密钥交换模式和所使用的椭圆曲线，实验结果如图3所示。从图3中可以看到，当握手阶段密钥交换模式和所使用的曲线固定后，本发明的定制TLS连接在选择椭圆曲线X25519时，建立时间与原有TLS连接建立时间不超过5％；当选择椭圆曲线secp256r1时，不超过20％。因此，可以说明本发明给TLS服务器带来的额外计算开销较小，连接建立时间影响可接受。

数据传输吞吐率对比

在大数据量传输的应用场景下，数据传输速率成为关键的性能指标。实验中网络中间设备被动监听TLS流量，如图4所示，使用各加密套件的TLS流量传输速率差异可忽略。

网络中间设备内存使用量

我们对使用本发明的网络中间设备的内存使用量进行评估，实验中控制客户端和服务器之间并发TLS连接的数量，并记录网络中间设备处理这些并发TLS连接所使用的内存量，结果如图5所示。从图5中可以看出，使用本发明的网络中间设备内存使用量随着并发TLS连接数量线性增长。当并发连接数量达到5000时，网络中间设备的内存使用量不超过300MB，说明本发明具有良好的可扩展性，适合实际部署使用。

网络中间设备离线解析速率

通过对网络中间设备解析离线TLS流量的能力进行了评估，利用网络中间设备离线分析TLS加密流量，记录还原出TLS会话密钥的平均时间。对不同握手方式和密码套件进行测试，网络中间设备离线还原一条TLS连接的平均速率不超过40ms，最少只需要不到19ms，说明本发明具有良好的运行效率，适合大规模流量的应用场景。