CN115174267B - 一种tls协议协商方法、设备及介质 - Google Patents

一种tls协议协商方法、设备及介质 Download PDF

Info

Publication number
CN115174267B
CN115174267B CN202211067969.1A CN202211067969A CN115174267B CN 115174267 B CN115174267 B CN 115174267B CN 202211067969 A CN202211067969 A CN 202211067969A CN 115174267 B CN115174267 B CN 115174267B
Authority
CN
China
Prior art keywords
server
message
network card
tls
key exchange
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.)
Active
Application number
CN202211067969.1A
Other languages
English (en)
Other versions
CN115174267A (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.)
Shenzhen Xingyun Zhilian Technology Co ltd
Original Assignee
Shenzhen Xingyun Zhilian Technology Co ltd
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 Shenzhen Xingyun Zhilian Technology Co ltd filed Critical Shenzhen Xingyun Zhilian Technology Co ltd
Priority to CN202211067969.1A priority Critical patent/CN115174267B/zh
Publication of CN115174267A publication Critical patent/CN115174267A/zh
Application granted granted Critical
Publication of CN115174267B publication Critical patent/CN115174267B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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
    • 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
    • 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
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请提供一种TLS协议协商方法、设备及介质，包括：服务端网卡响应于接收到客户端招呼报文，提取报文中的客户端的随机数和密钥交换算法参数后上送到服务端软件；服务端软件生成随机数，标记服务端招呼报文中密钥交换算法参数的字段后下发到服务端网卡；服务端网卡，至少在发出服务端招呼报文之前，解析报文后进行密码学操作生成服务端的密钥交换算法参数，然后用其替换所标记的服务端招呼报文中服务端的密钥交换算法参数的字段。服务端网卡还用于至少在发出服务端改变密码标准报文之前计算出对称会话密钥。如此减少硬件交互和数据转移负担。

Description

一种TLS协议协商方法、设备及介质
技术领域
本申请涉及通信技术领域，尤其涉及一种TLS协议协商方法、设备及介质。
背景技术
为了保护通信过程中的信息安全和数据完整，一般采用安全通信协议对消息进行加密后传输以及进行身份认证。一种常见的安全通信协议是传输层安全协议（TransportLayer Security，TLS）。此外还广泛采用加解密技术和各种密码学算法来保护机密信息和防范安全攻击，但是这些也带来了巨大的负载和损耗。随着互联网技术和通信技术的发展，通信过程中涉及到的数据量变得异常巨大，经常发生高流量、高并发的情况，而现有技术中的通用处理器等难以高效可靠地进行处理，特别是难以应对TLS协议协商过程中采用密码学算法所导致的性能不足的问题。
综上所述，目前需要解决的问题是如何解决TLS协议协商过程中采用密码学算法所导致的性能不足。
发明内容
本申请实施例提供了一种TLS协议协商方法、设备及介质，用于解决现有技术中存在的问题也就是如何解决TLS协议协商过程中采用密码学算法所导致的性能不足。
第一方面，本申请提供了一种TLS协议协商方法。所述TLS协议协商方法包括：服务端网卡，响应于接收到客户端发出的客户端招呼报文，提取所述客户端招呼报文中的客户端的第一随机数和第一密钥交换算法参数，上送所述客户端招呼报文到服务端软件；所述服务端软件生成服务端的第二随机数，标记服务端招呼报文中服务端的第二密钥交换算法参数的字段，下发所述第二随机数和所述服务端招呼报文到所述服务端网卡；所述服务端网卡，至少在发出所述服务端招呼报文之前，解析所述服务端招呼报文后进行密码学操作生成所述第二密钥交换算法参数，然后用所述第二密钥交换算法参数替换所标记的所述服务端招呼报文中服务端的密钥交换算法参数的字段。其中，所述服务端网卡还用于，至少在发出服务端改变密码标准报文之前，结合所述第一随机数和所述密钥交换算法参数以及所述第二随机数和所述第二密钥交换算法参数计算出对称会话密钥。
通过本申请的第一方面，减少了硬件之间的交互，减少了数据转移负担以及数据拷贝需求，在短连接场景如语音通信下可以有效降低服务端处理TLS协商报文特别是其中的基于非对称加密算法的加解密操作而带来的负载，进而降低通信开销和提升系统效率。
在本申请的第一方面的一种可能的实现方式中，所述服务端软件通过第一报文描述符标记所述服务端招呼报文中服务端的密钥交换算法参数的字段，所述TLS协议协商方法还包括：所述服务端软件通过第二报文描述符标记服务端证书验证报文中签名字段后下发所述服务端证书验证报文到所述服务端网卡；所述服务端网卡，至少在发出所述服务端证书验证报文之前，用证书套件私钥对消息摘要签名并替换所标记的所述服务端证书验证报文中签名字段。
在本申请的第一方面的一种可能的实现方式中，所述服务端软件通过第一报文描述符标记所述服务端招呼报文中服务端的密钥交换算法参数的字段，所述TLS协议协商方法还包括：所述服务端软件通过第三报文描述符标记服务端握手结束报文中摘要字段后下发所述服务端握手结束报文到所述服务端网卡；所述服务端网卡，至少在发出所述服务端握手结束报文之前，填充握手数据摘要到所标记的所述服务端握手结束报文中摘要字段。
在本申请的第一方面的一种可能的实现方式中，所述服务端软件通过第一报文描述符标记所述服务端招呼报文中服务端的密钥交换算法参数的字段，所述TLS协议协商方法还包括：所述服务端软件跳过签名处理和摘要处理并且分别用第二报文描述符和第三报文描述符来标记服务端证书验证报文中签名字段和服务端握手结束报文中摘要字段；所述服务端网卡用于进行签名处理和摘要处理并且分别替换所标记的所述服务端证书验证报文中签名字段和所标记的所述服务端握手结束报文中摘要字段。
在本申请的第一方面的一种可能的实现方式中，所述客户端的密钥交换算法参数和所述服务端的密钥交换算法参数基于同一非对称加密算法，并且所述服务端软件跳过与所述非对称加密算法相关的密码学操作。在一些实施例中，所述非对称加密算法是ECDH密钥交换算法，所述第一密钥交换算法参数是所述客户端的第一ECDH密钥交换算法参数，所述第二密钥交换算法参数是所述服务端的第二ECDH密钥交换算法参数。在一些实施例中，所述非对称加密算法是RSA算法、DSA算法、ECC算法或者DH算法。在一些实施例中，所述对称会话密钥通过所述ECDH密钥交换算法共享给所述客户端。
在本申请的第一方面的一种可能的实现方式中，所述TLS协议协商方法还包括：所述服务端网卡用所述对称会话密钥加密并且发出被加密的扩展信息和被加密的证书。
在本申请的第一方面的一种可能的实现方式中，所述TLS协议协商方法还包括：所述服务端软件，至少在所述服务端网卡接收到所述客户端发出的所述客户端招呼报文之前，对所述服务端网卡进行初始化配置，所述初始化配置包括下发证书和服务端私钥到所述服务端网卡以及为所述服务端的公私钥对分配索引。在一些实施例中，所述TLS协议协商方法还包括：所述服务端软件，至少在所述服务端网卡接收到所述客户端发出的所述客户端招呼报文之前，指定所述服务端网卡监听给定TLS协议端口，所述客户端发出的所述客户端招呼报文通过所述给定TLS协议端口被所述服务端网卡接收。在一些实施例中，所述服务端网卡包括多个网络出口用于接收多个TLS协商请求，其中基于所述多个TLS协商请求的数量及性质确定每一个TLS协商请求所对应的网络出口是否为所述给定TLS协议端口。
第二方面，本申请实施例还提供了一种计算机设备，所述计算机设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现根据上述任一方面的任一种实现方式的方法。
第三方面，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机设备上运行时使得所述计算机设备执行根据上述任一方面的任一种实现方式的方法。
第四方面，本申请实施例还提供了一种计算机程序产品，其特征在于，所述计算机程序产品包括存储在计算机可读存储介质上的指令，当所述指令在计算机设备上运行时使得所述计算机设备执行根据上述任一方面的任一种实现方式的方法。
第五方面，本申请实施例还提供了一种网卡。所述网卡包括多个网络出口，该多个网络出口中的至少一个第一网络出口对应第一模式，该多个网络出口中的至少一个第二网络出口对应第二模式，所述网卡用于根据待处理的TLS协商请求的数量及性质分配TLS协商请求到第一网络出口或者第二网络出口，其中，被分配到第二网络出口的TLS协商请求的处理流程参照根据上述任一方面的任一种实现方式的方法。
附图说明
为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是TLS协议通信基本流程的示意图；
图2是服务端的结构框图；
图3是TLS协议的握手阶段流程示意图；
图4为本申请实施例提供的一种实现方式的TLS协议协商方法流程示意图；
图5为本申请实施例提供的一种实现方式的网卡的运行方法流程示意图；
图6是本申请实施例提供的一种计算设备的结构示意图。
具体实施方式
下面将结合附图对本申请实施例作进一步地详细描述。
本申请实施例提供了一种TLS协议协商方法、设备及介质，用于解决现有技术中存在的问题也就是如何解决TLS协议协商过程中采用密码学算法所导致的性能不足。其中，本申请实施例提供的方法和设备是基于同一发明构思的，由于方法及设备解决问题的原理相似，因此方法与设备的实施例、实施方式、示例或实现方式可以相互参见，其中重复之处不再赘述。
应当理解的是，在本申请的描述中，“至少一个”指一个或一个以上，“多个”指两个或两个以上。另外，“第一”、“第二”等词汇，除非另有说明，否则仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。
参见图1，图1是TLS协议通信基本流程的示意图。在安全通信管理、互联网安全加密、智能网卡等应用场景下，往往对消息进行加密后传输，可以通过安全套接字层（SecureSocket Layer，SSL）或者传输层安全协议（Transport Layer Security，TLS）来实现身份认证、加密数据以及维护数据完整性。其中，SSL或者TLS的通信基本流程都分成握手阶段和会话阶段。例如，图1的TLS协议通信基本流程包括握手阶段110和会话阶段120。握手阶段110是在双方之间协商用于会话阶段的密钥，握手阶段110的机密信息一般通过非对称加密算法进行加密，包括交换用于会话阶段的密钥。会话阶段120的机密信息用对称加密算法进行加密，因此用于会话阶段120的密钥是对称加密算法下的密钥。换句话说，握手阶段110也是建立TLS连接的过程。假设握手阶段110采用的非对称加密算法是椭圆曲线迪菲-赫尔曼密钥交换（Elliptic Curve Diffie–Hellman key Exchange，ECDH），也叫ECDH算法。基于ECDH算法来实现机密信息共享的方式是ECDH密钥交换算法。在握手阶段110客户端向服务端发送第一ECDH密钥交换算法参数和支持的密码套件等，服务端从客户端支持的密码套件中做出选择并将所选择的密码套件和第二ECDH密钥交换算法参数发送给客户端。服务端还结合来自客户端的第一ECDH密钥交换算法参数和服务端自身的第二ECDH密钥交换算法参数计算出对称会话密钥（作为基于ECDH密钥交换算法在客户端和服务端之间的通道上建立的共有加密资料）并通过ECDH密钥交换算法共享给客户端。客户端接收到通过ECDH密钥交换算法共享的加密资料，也就是对称会话密钥，后续采用该对称会话密钥与服务端进行会话阶段120的消息交互。
可以看出，在握手阶段110是通过ECDH密钥交换算法在服务端和客户端之间共享对称会话密钥，在会话阶段120是通过对称会话密钥来加密会话消息及其它信息。这里，除了上述的ECDH算法，还可以采用其它非对称加密算法，例如RSA算法（也叫公钥密码算法）、数字签名算法（Digital Signature Algorithm，DSA）、ECC算法（也叫椭圆曲线加密算法）和DH算法（也叫Diffie-Hellman密钥交换协议）。另外，ECDH算法是基于ECC算法的密钥协商。ECC算法或者说椭圆曲线加密算法可以理解为基于椭圆曲线的一系列非对称密码学算法，例如上述的ECDH算法还有ECDSA算法（ECDSA算法是基于ECC的签名）。这些非对称加密算法的原理相似，一般涉及到公钥和私钥组成的密钥对或者说公钥私钥对。其中，基于非对称加密算法的加解密技术，用公钥加密的数据只能用私钥解密，用私钥签名的机密信息可以用公钥验签。利用非对称加密算法进行机密信息交换的基本过程是，甲方生成密钥对，包括一对公钥和私钥；甲方将公钥发送给乙方；乙方用公钥加密机密信息后发送给甲方；甲方用私钥解密。因此私钥在生成之后不离开本地，而公钥即使泄露了也无法用来破解加密后的机密信息，这样就使得公钥可以用明文传输。并且通过用公钥验签可以验证信息来源合法性。图1所示的TLS协议通信基本流程，在握手阶段110在客户端和服务端之间协商出对称会话密钥，且客户端还可以基于公钥基础设施（Public Key Infrastructure，PKI）验证服务端证书及私钥，接着在会话阶段120客户端和服务端基于对称会话密钥进行后续应用数据的传输。因此，非对称加密算法如ECDH算法应用于握手阶段110从而保障通信报文的机密性和完整性，特别是确保与双方协商出对称会话密钥有关的报文的机密性和完整性。具体来说，在握手阶段110在客户端和服务端之间协商出对称会话密钥所涉及到的机密信息，可以作为基于ECDH密钥交换算法在客户端和服务端之间的通道上建立的共有加密资料，也可以理解为通过ECDH密钥交换算法在客户端和服务端之间共享的加密资料，例如服务端在握手阶段110中结合来自客户端的第一ECDH密钥交换算法参数和服务端自身的第二ECDH密钥交换算法参数计算出对称会话密钥。在握手阶段110采用非对称加密算法如ECDH算法，主要是用来在一个不安全的通道中建立起安全的共有加密资料。
但是，非对称加密算法的加解密速度很慢，远远慢于对称加密算法。特别是在握手阶段110还涉及到相对比较复杂的协商操作，包括证书交换、密码套件协商、密钥交换等，这些协商操作的复杂性以及非对称加密算法的应用使得难以通过通用处理器实现加速处理，也给握手阶段110带来巨大的负载和损耗，这一点下面结合图2详细说明。
参见图2，图2是服务端的结构框图。如图2所示，服务端包括中央处理器210，存储器220，网卡230，以及加速器240。这里，中央处理器210用于运行服务端软件，例如服务端的操作系统或者任意用来实现服务端和客户端之间的TLS协商操作的代码或者应用程序等。中央处理器210可以是通用处理器例如中央处理器（central processing unit，CPU），可以是包括一个或者多个CPU的计算架构，还可以包括单核CPU或者多核CPU，在此不做具体限定。存储器220与中央处理器210连接，用于存储代码、数据、指令、应用程序和操作系统等。网卡230指的是网卡（network interface card），也叫做网络接口控制器（networkinterface controller，NIC），或者叫做网络接口控制器、网络适配器（network adapter）、局域网接收器（LAN adapter）等。网卡230用于使得服务端在计算机网络上进行通讯。网卡230和加速器240分别通过总线与中央处理器210连接。如上所述，非对称加密算法的加解密速度很慢，远远慢于对称加密算法。特别是在握手阶段还涉及到相对比较复杂的协商操作，包括证书交换、密码套件协商、密钥交换等，这些协商操作的复杂性以及非对称加密算法的应用使得难以通过通用处理器实现加速处理，也给握手阶段带来巨大的负载和损耗。因此，中央处理器210一般是通用处理器架构如CPU，用于为服务端软件和服务端操作系统在其上运行提供硬件支持。但是，中央处理器210在处理非对称加密算法的加解密运算上，特别是处理基于非对称加密算法的握手阶段的协商操作上，面临性能不足、效率低下的问题。而且，握手阶段的协商操作的复杂性以及非对称加密算法的应用也使得难以通过现场可编程逻辑门阵列（field-programmable gate array，FPGA）和图形处理器（graphic processingunit，GPU）进行加速处理。相对的，会话阶段采用对称加密算法，其产生的加密数据流往往适合通过硬件加速器如FPGA、GPU来处理。也就是说，针对会话阶段优化的集成电路往往不适合应对握手阶段的复杂的协商操作特别是其中的非对称加密算法相关的加解密操作。因此，需要通过加速器240来满足建立安全通信信道的协商操作也即握手阶段的数据流。具体地，中央处理器210，或者与之连接的FPGA和GPU等，可以用于处理会话阶段的数据流，例如在会话阶段进行数据传输的加密后会话消息、加密后应用程序数据等，这些是采用对称加密算法。而握手阶段的数据流，例如握手阶段的协商操作所涉及到的加解密操作，如会话管理数据的加解密操作，则适合通过加速器240来处理，例如执行与会话协商相关联的非对称加解密操作。
继续参见图2，在TLS通信基本流程的握手阶段，例如图1的握手阶段110，或者说在安全通信信道建立之前的协商操作上，都需要将非对称签名算法参数或者基于非对称加密算法的密钥交换参数如ECDH密钥交换算法参数，发送给适合处理非对称密码学算法的逻辑电路或硬件，例如图2的加速器240。这样意味着，在服务端，需要通过内部总线将大量数据转移到加速器240，然后等加速器240处理完成后再将处理结果置于TLS协商报文中并封装成网络报文，接着再一次通过内部总线将大量数据发送到网卡230上，最后由网卡230发送网络报文给客户端。也就是说，上述的通过加速器240来处理握手阶段的数据流，例如握手阶段的协商操作所涉及到的基于非对称加密算法的加解密操作（例如ECDH算法相关操作），则必然导致中央处理器210与加速器240之间进行两次交互（第一次交互用于将大量数据转移到加速器240，第二次交互用于将处理结果封装成网络报文），此外还必然导致多次通过内部总线进行的数据转移。上面提到，网卡230和加速器240分别通过总线与中央处理器210连接，这里总线可以是内部总线，例如快捷外围部件互连标准（peripheral componentinterconnect express，PCIe）总线或者其它总线标准。因为在服务端的内部涉及到上述的中央处理器210与加速器240之间的两次交互以及多次通过总线如PCIE的数据转移，还有相应的数据拷贝、消息通知等操作，从而带来负载和通讯开销。
参见图1和图2，在如语音通信等存在大量短连接的场景下，往往每个会话持续时间都较短，也就需要频繁地建立新的TLS安全通信通道或者说频繁进行握手阶段的协商操作，例如两个人在通话期间断续地会话，每一段会话可能持续不到一分钟但是不同段会话之间间隔较久从而需要频繁地为每一段会话分别协商对称会话密钥。这样给服务端造成的影响是：处理TLS协商报文特别是其中的基于非对称加密算法的加解密操作而带来的负载，远高于数据面的对称加解密负载。也就是说，用在握手阶段或者建立安全通信信道上的资源要远大于用在会话阶段或者在安全通信信道建立之后的应用数据交互上的资源。具体地，以图2为例，每次建立新的会话，都需要完成图1所示的握手阶段110的协商操作，也就必然再服务端内部进行上述的中央处理器210与加速器240之间的两次交互以及多次通过总线如PCIE的数据转移，还有相应的数据拷贝、消息通知等操作。在存在大量短连接的场景下，例如语音通信场景下，每个会话建立后可能在很短时间如几分钟内就结束，这样就需要频繁地建立新的会话并进行新的握手阶段的协商操作。为此，本申请实施例通过结合密码学技术和对TLS协议通信基本流程的改进，实现了低交互、高性能的TLS协议协商方法，这一点下面详细说明。
参见图3，图3是TLS协议的握手阶段流程示意图。如图3所示，在服务端300和客户端302之间进行的TLS协议通信基本流程，其中的握手阶段包括以下步骤。
步骤S310：客户端发出客户端招呼报文。
在步骤S310中，客户端招呼报文由客户端发出，其中包括：由客户端生成的第一随机数，用于后续生成对称会话密钥；客户端支持的密码套件，一般格式为密码交换算法加上签名算法加上对称加密算法再加上摘要算法；由客户端生成的第一ECDH密钥交换算法参数，用于后续通过ECDH密钥交换算法共享对称会话密钥。其中，第一ECDH密钥交换算法参数是基于非对称加密算法，也可以采用其它非对称加密算法来实现后续共享对称会话密钥。客户端招呼（Client Hello）报文是客户端发起请求所采用的报文，其中携带上述的第一随机数、客户端所支持的密码套件以及其它信息等。本申请实施例所提及的客户端招呼报文可以理解为指代TLS协议通信基本流程例如TLS 1.3协议中提及的Client Hello报文或者类似的用于客户端发起通讯请求所采用的报文。
步骤S312：服务端生成第二随机数和第二ECDH密钥交换算法参数，选择密码套件。
在步骤S312中，由服务端生成的第二随机数，用于后续生成对称会话密钥。
步骤S314：服务端发出服务端招呼报文。
在步骤S314中，服务端招呼报文由服务端发出，其中包括：由服务端生成的第二随机数，用于后续生成对称会话密钥；服务端从客户端支持的密码套件中选择的密码套件；由服务端生成的第二ECDH密钥交换算法参数，用于后续通过ECDH密钥交换算法共享对称会话密钥。服务端招呼（Server Hello）报文是服务端响应客户端招呼报文所做出的回应，其中携带上述的第二随机数、服务端所选择的密码套件以及其它信息等。本申请实施例所提及的服务端招呼报文可以理解为指代TLS协议通信基本流程例如TLS 1.3协议中提及的Server Hello报文或者具有类似功能或数据格式的报文。
步骤S316：服务端发出服务端改变密码标准报文。
在步骤S316中，服务端改变密码标准（Server Change Cipher Spec）报文由服务端发出，用于指示加密传输过程中需要间隔地改变加解密参数的协议。在发出服务端改变密码标准报文之前，服务端接收了在步骤S310的客户端招呼报文中的由客户端生成的第一ECDH密钥交换算法参数，通过结合双方的ECDH密钥交换算法参数计算出对称会话密钥（也就是，结合由客户端生成的第一ECDH密钥交换算法参数以及由服务端生成的第二ECDH密钥交换算法参数从而实现通过ECDH密钥交换算法共享对称会话密钥），并且指示后续消息使用对称会话密钥加密后发送。本申请实施例所提及的服务端改变密码标准报文可以理解为指代TLS协议通信基本流程例如TLS 1.3协议中提及的Server Change Cipher Spec报文或者具有类似功能或数据格式的报文。
步骤S318：服务端发出被加密的扩展信息。
在步骤S318中，服务端加密扩展（Server Encrypted Extensions）信息由服务端发出，一般可以理解为服务端发送被加密的扩展信息，例如媒体扩展信息。本申请实施例所提及的被加密的扩展信息可以理解为指代TLS协议通信基本流程例如TLS 1.3协议中提及的Server Encrypted Extensions。
步骤S320：服务端发出被加密的证书。
在步骤S320中，服务端证书（Server Certificate）信息由服务端发出，一般可以理解为服务端发送被加密的证书或证书链。证书的信息中可以选择性地附带证书公钥。本申请实施例所提及的被加密的证书可以理解为指代TLS协议通信基本流程例如TLS 1.3协议中提及的Server Certificate。
步骤S322：服务端发出服务端证书验证报文和证书私钥签名握手数据。
在步骤S322中，服务端证书验证（Server Certificate Verify）报文由服务端发出，服务端使用与证书对应的证书私钥签名握手数据，使用共享的对称会话密钥加密后发送。服务端证书验证报文用于证明服务端持有合法证书。本申请实施例所提及的服务端证书验证报文可以理解为指代TLS协议通信基本流程例如TLS 1.3协议中提及的ServerCertificate Verify报文或者具有类似功能或数据格式的报文。
步骤S324：服务端发出服务端握手结束报文和握手数据摘要。
在步骤S324中，服务端握手结束（Server Handshake Finished）报文由服务端发出，用于指示握手阶段的结束。服务端对所有握手数据进行摘要，使用共享的对称会话密钥加密后发送。本申请实施例所提及的服务端握手结束报文可以理解为指代TLS协议通信基本流程例如TLS 1.3协议中提及的Server Handshake Finished报文或者具有类似功能或数据格式的报文。
步骤S326：客户端发出客户端改变密码标准报文。
在步骤S326中，客户端改变密码标准（ClientChange Cipher Spec）报文由客户端发出，用于指示加密传输过程中需要间隔地改变加解密参数的协议。在发出客户端改变密码标准报文之前，客户端接收了在步骤S324的服务端招呼报文中的由服务端生成的第二ECDH密钥交换算法参数，也计算出对称会话密钥。客户端完成证书校验后，发送消息表示后续消息采用共享的对称会话密钥加密。本申请实施例所提及的客户端改变密码标准报文可以理解为指代TLS协议通信基本流程例如TLS 1.3协议中提及的ClientChange CipherSpec报文或者具有类似功能或数据格式的报文。
步骤S328：客户端发出客户端结束报文。
在步骤S328中，客户端结束（Client Finished）报文由客户端发出，用于指示握手阶段结束。客户端对所有握手数据摘要后使用共享的对称会话密钥加密后发送。
参见图3的步骤S310至步骤S328，可以看出，一次TLS协议基本通信流程开始于服务端接收到客户端发出的请求也就是服务端接收到在步骤S310中客户端发出的客户端招呼报文。然后，服务端在步骤S314做出响应并发出服务端招呼报文。客户端招呼报文包括客户端支持的密码套件以及客户端的第一随机数，客户端的第一随机数后续用于跟服务端的第二随机数一起生成对称会话密钥，而客户端支持的密码套件指示了客户端对加解密算法的支持，这样服务端和客户端才能采用同一套加解密算法或者可以彼此适配的密码套件。服务端在步骤S314发出服务端招呼报文，在步骤S316发出服务端改变密码标准报文，在步骤S318发出被加密的扩展信息，在步骤S320发出被加密的证书，在步骤S322发出服务端证书验证报文和证书私钥签名握手数据，直到在步骤S324发出服务端握手结束报文和握手数据摘要。服务端从步骤S314到步骤S324发出的一系列报文和消息，可以是每条单独发送，也可以合并后一起发送，在此不做具体限定。应当理解的是，在步骤S316发出的服务端改变密码标准报文，用于向客户端告知，服务端已经切换到协商好的密码套件并且准备开始对实质数据传输进行加密。为此，服务端在步骤S316发出的服务端改变密码标准报文之前，结合由客户端生成的第一ECDH密钥交换算法参数以及由服务端生成的第二ECDH密钥交换算法参数，计算出对称会话密钥从而实现通过ECDH密钥交换算法共享对称会话密钥。
图3所示的TLS协议基本通信流程，适用于TLS协议的1.3版本。TLS协议的其它版本，或者与TLS协议接近的SSL协议的协商过程，可能采用有所不同的基本通信流程或者采用不同的非对称加密算法，并且可能省略证书套件和证书验证操作。但是，这些基本通信流程，都涉及到在握手阶段或者说协商操作中通过非对称加密算法例如ECDH算法来实现机密信息的协商，例如通过ECDH密钥交换算法参数来实现对称会话密钥的协商。因此，以TLS协议基本通信流程为代表的这些基本通信流程，只要涉及到在握手阶段或者协商操作中采用非对称加密算法来加密数据流或者进行机密信息如密钥的协商，则都面临因为要处理协商报文特别是其中的基于非对称加密算法的加解密操作而带来的巨大负载和损耗。并且，在如语音通信等存在大量短连接的场景下，往往每个会话持续时间都较短，也就需要频繁地建立新的TLS安全通信通道或者说频繁进行握手阶段的协商操作，但是每次建立新的会话都需要完成例如图3所示的TLS协议基本通信流程的握手阶段，其中服务端至少需要完成其中从步骤S314到步骤S324的一系列报文和消息的生成及发送。如上所述，如果将非对称签名算法参数或者基于非对称加密算法的密钥交换参数如ECDH密钥交换算法参数，发送给适合处理非对称密码学算法的逻辑电路或硬件，例如图2的加速器240，则涉及到中央处理器210与加速器240之间的两次交互以及多次通过总线如PCIE的数据转移，还有相应的数据拷贝、消息通知等操作，因此是不利于实现低交互、高性能的TLS协议协商方法。为此，本申请实施例通过结合密码学技术和对TLS协议通信基本流程的改进，对以图3所示的TLS协议基本通信流程为例的基本通信流程进行了改进，实现了低交互、高性能的TLS协议协商方法。这一点下面结合图4详细说明。
参见图4，图4为本申请实施例提供的一种实现方式的TLS协议协商方法流程示意图。如图4所示，服务端分成服务端软件400和服务端网卡402，服务端与客户端之间进行的TLS协议协商方法通过服务端网卡402与客户端404之间进行。而服务端内部的数据交互体现为服务端软件400和服务端网卡402之间的数据交互。其中，服务端软件400可以理解为服务端的操作系统，或者任意运行在服务端的中央处理器上的用于实现TLS协议协商的代码、应用程序等。值得注意的是，图4所示的TLS协议协商方法，在服务端内部，不涉及服务端软件400或者说服务端的中央处理器与加速器之间的交互，而是仅涉及服务端软件400与服务端网卡402之间的交互。相比于图2所示的服务端内部涉及中央处理器210与加速器240之间的两次交互以及多次通过总线如PCIE的数据转移，还有相应的数据拷贝、消息通知等操作，图4所示的TLS协议协商方法，省去了服务端软件与加速器之间的交互也省去了通过总线的数据转移及相应的数据拷贝、消息通知等操作。下面结合图4详细说明。
步骤S410：服务端软件提前配置服务端网卡，指定网卡监听的TLS协议端口，下发证书及服务端私钥到网卡上，以及给服务端公私钥对分配索引。
步骤S412：客户端发出客户端招呼报文。
步骤S414：服务端网卡在指定端口检测到客户端招呼报文，从客户端招呼报文中提取客户端的第一随机数和第一ECDH密钥交换算法参数，创建TLS握手上下文，然后上送客户端招呼报文和TLS握手上下文索引到服务端软件。
步骤S416：服务端软件解析客户端招呼报文，将证书套件与TLS握手上下文索引关联，以及下发证书套件到服务端网卡。
步骤S418：服务端软件跳过ECDH处理，用报文描述符标记报文中存放服务端的ECDH密钥交换算法参数的字段，选择密码套件，生成服务端的第二随机数，下发服务端招呼报文到服务端网卡。
其中，服务端的ECDH密钥交换算法参数也即服务端的第二ECDH密钥交换算法参数。
步骤S420：服务端网卡解析服务端招呼报文，根据所选择的密码套件进行ECDH处理，生成服务端的第二ECDH密钥交换算法参数并替换报文描述符所标记的报文中存放服务端的ECDH密钥交换算法参数的字段。
步骤S422：服务端网卡发出服务端招呼报文。
步骤S424：服务端网卡结合客户端的第一随机数和第一ECDH密钥交换算法参数，以及服务端的第二随机数和第二ECDH密钥交换算法参数，计算出对称会话密钥。
步骤S426：服务端软件下发服务端改变密码标准报文、扩展信息及消息到服务端网卡。
步骤S428：服务端网卡保存消息摘要，用对称会话密钥加密，发出服务端改变密码标准报文、被加密的扩展信息、被加密的证书。
步骤S430：服务端软件跳过签名处理，用报文描述符标记报文中签名字段，下发服务端证书验证报文到服务端网卡。
步骤S432：服务端网卡用证书套件私钥对消息摘要签名并替换签名字段，发出服务端证书验证报文和证书私钥签名握手数据。
步骤S434：服务端软件跳过摘要处理，用报文描述符标记摘要字段，下发服务端握手结束报文到服务端网卡。
步骤S436：服务端网卡填充握手数据摘要到摘要字段，发出服务端握手结束报文和握手数据摘要。
参见图4的TLS协议协商方法的步骤S410到步骤S436，可以看出，服务端软件400和服务端网卡402都在服务端，这两者之间的交互属于服务端内部的交互，因此服务端对外的与客户端404之间的交互是发生在服务端网卡402和客户端404之间。具体地，TLS协议协商方法开始于步骤S412中，服务端网卡402接收到在步骤S412中客户端发出的客户端招呼报文，然后服务端网卡402在步骤S422发出服务端招呼报文，在步骤S428发出服务端改变密码标准报文、被加密的扩展信息、被加密的证书，在步骤S432发出服务端证书验证报文和证书私钥签名握手数据，以及在步骤S436发出服务端握手结束报文和握手数据摘要。上面提到，在图3所示的TLS协议基本通信流程，服务端在步骤S314发出服务端招呼报文，在步骤S316发出服务端改变密码标准报文，在步骤S318发出被加密的扩展信息，在步骤S320发出被加密的证书，在步骤S322发出服务端证书验证报文和证书私钥签名握手数据，直到在步骤S324发出服务端握手结束报文和握手数据摘要。因此，图3所示的TLS协议基本通信流程中，服务端从步骤S314到步骤S324发出的一系列报文和消息，对应了在图4所示的TLS协议协商方法中，服务端网卡402在步骤S412、步骤S422、步骤S428、步骤S432和步骤S436发出的一系列报文和信息。换句话说，对于客户端404而言，图4的TLS协议协商方法与图3所示的TLS协议基本通信流程，两者对外的表现是一致的，这意味着图4的TLS协议协商方法不需要改动通用的TLS协议基本通信流程，也因此可以无需改动就替代通用的TLS协议例如TLS协议的1.3 版本，从而有利于便利地推广到各种现有的通讯协议、通讯节点、服务端运行方法、网卡运行方法等。
进一步地，对于服务端软件400而言，在步骤S414中由服务端网卡402上送客户端招呼报文到服务端软件400，然后服务端软件400选择密码套件和下发证书套件，以及生成服务端的第二随机数，后续也会下发报文和消息到服务端网卡402。因此，在服务端内部，服务端软件400所承担的图4的TLS协议协商方法中的操作，相比于图3所示的TLS协议基本通信流程，增加的负载主要体现在步骤S410的初始化操作，也就是提前配置服务端网卡，指定网卡监听的TLS协议端口，下发证书及服务端私钥到网卡上，以及给服务端公私钥对分配索引。另一方面，服务端软件400所承担的图4的TLS协议协商方法中的操作，相比于图3所示的TLS协议基本通信流程，减少的负载体现在步骤S418中服务端软件跳过ECDH处理并用报文描述符标记报文中存放服务端的第二ECDH密钥交换算法参数的字段，在步骤S430中服务端软件跳过签名处理并用报文描述符标记报文中签名字段，以及在步骤S434中服务端软件跳过摘要处理并用报文描述符标记摘要字段。因此，服务端软件400所承担的在整个图4的TLS协议协商方法中的操作，其负载得到了大幅减少，特别是在步骤S418中服务端软件跳过ECDH处理并用报文描述符标记报文中存放服务端的第二ECDH密钥交换算法参数的字段。如果需要通过服务端软件来处理协商报文特别是其中的基于非对称加密算法的加解密操作，服务端软件一般运行在中央处理器或者其它通用处理器上，这样的安排会带来巨大系统负担且占用本可以用于操作系统的资源，但是如果将这些发送给适合处理非对称密码学算法的逻辑电路或硬件，则又会导致中央处理器（服务端软件运行其上）与该逻辑电路或硬件（如图2的加速器240）之间的两次交互以及多次通过总线如PCIE的数据转移，还有相应的数据拷贝、消息通知等操作。基于这些考虑，图4的TLS协议协商方法中，服务端软件400所承担的操作得到了大幅减少，包括在步骤S418中服务端软件跳过ECDH处理并用报文描述符标记报文中存放服务端的第二ECDH密钥交换算法参数的字段。如此，因为服务端软件400跳过了ECDH处理，也就无需通过服务端软件400运行其上的中央处理器来处理协商报文特别是其中的基于非对称加密算法的加解密操作，从而省去了服务端软件与加速器之间的交互也省去了通过总线的数据转移及相应的数据拷贝、消息通知等操作。
进一步地，在步骤S418中服务端软件跳过ECDH处理并用报文描述符标记报文中存放服务端的第二ECDH密钥交换算法参数的字段，在步骤S430中服务端软件跳过签名处理并用报文描述符标记报文中签名字段，以及在步骤S434中服务端软件跳过摘要处理并用报文描述符标记摘要字段。因此，服务端软件400通过报文描述符来标记相应字段例如报文中的相应位置，而不是由服务端软件400来实质上进行这些处理，这样就实现了对服务端软件400的现有操作流程的最小限度的改动，也即服务端软件400可以通过报文描述符来替代实质处理从而在流程上等效于完成了分配给服务端软件400的任务，进而利于便利地推广到各种现有的通讯协议、通讯节点、服务端运行方法等，也有利于服务端软件400与其它部件、设备和系统的协作。
进一步地，服务端网卡402在步骤S414中生成TLS握手上下文并上送TLS握手上下文索引到服务端软件400，这是因为服务端网卡402将代替服务端软件400来完成服务端软件400跳过的实质处理，而通过TLS握手上下文索引，服务端软件400可以实现通过报文描述符来准确地在报文中标记后续需要服务端网卡402来替换或者补充的字段或位置。具体地，服务端网卡402在步骤S420中解析服务端招呼报文，根据所选择的密码套件进行ECDH处理，生成服务端的第二ECDH密钥交换算法参数并替换报文描述符所标记的报文中存放服务端的第二ECDH密钥交换算法参数的字段；在步骤S424中结合客户端的第一随机数和第一ECDH密钥交换算法参数，以及服务端的第二随机数和第二ECDH密钥交换算法参数，计算出对称会话密钥；在步骤S428中保存消息摘要，用对称会话密钥加密，发出服务端改变密码标准报文、被加密的扩展信息、被加密的证书；在步骤S432中用证书套件私钥对消息摘要签名并替换签名字段，发出服务端证书验证报文和证书私钥签名握手数据；以及在步骤S436中填充握手数据摘要到摘要字段，发出服务端握手结束报文和握手数据摘要。如此，服务端软件400跳过ECDH处理、签名处理以及摘要处理，并且用报文描述符标记相应字段，例如相应域段的tcpsequence位置，这样可以通知服务端网卡402进行相关的密码学操作。而服务端网卡402通过TLS握手上下文以及TLS握手上下文索引，可以解析从服务端软件400下发的报文，并进行相应的密码学操作，然后进行替换或者补充，从而最后封装成网络报文以便发送给客户端404。
图4的TLS协议协商方法，结合密码学技术和对TLS协议通信基本流程的改进，使得服务端软件400跳过ECDH处理、签名处理以及摘要处理并且用报文描述符标记相应字段，由服务端网卡402直接完成TLS协商报文收发以及内部域段的非对称加解密操作，而整体上的TLS协议控制等高灵活性处理任务还是由通用处理器例如CPU处理，这样省去了额外的数据路径、数据拷贝、事件通知等，特别是省去了服务端软件与加速器之间的交互也省去了通过总线的数据转移及相应的数据拷贝、消息通知等操作，并且对外如客户端404的表现与现有的TLS协议基本通信流程一致且对服务端软件400的现有操作流程只做出最小限度的改动，从而有利于便利地推广并改进现有的通讯协议、通讯节点、服务端运行方法、网卡运行方法等。
总之，图4的TLS协议协商方法，通过让网卡来处理TLS协商报文或者说TLS通信流程握手阶段或者说基于TLS协议的安全通信信道的建立，包括处理其中的基于非对称加密算法的加解密操作如ECDH密钥交换算法相关计算，从而减少了CPU与外设硬件之间的交互，减少了PCIE总线的数据转移负担以及数据拷贝需求，在短连接场景如语音通信下可以有效降低服务端处理TLS协商报文特别是其中的基于非对称加密算法的加解密操作而带来的负载，进而降低通信开销和提升系统效率。
并且，为了用网卡来替代服务端软件和外部加速器在处理TLS协商报文也就是建立TLS安全通信信道上的操作，一方面用网卡进行基于非对称加密算法的加解密操作，包括生成非对称加密算法下的公钥如ECDH公钥，另一方面也用网卡进行本应由服务端软件进行的操作，包括生成对称会话密钥。进一步地，相比于将外部加速器的处理结果置于TLS协商报文中封装成网络报文再通过总线如PCIE发送到网卡用于发送给客户端，本申请实施例中，因为处理结果直接在网卡生成，所以对封装步骤也做了改进。具体地，服务端跳过从外部加速器获得ECDH公钥的步骤以及跳过签名字段步骤，而是在报文描述符中标记相应字段，由网卡在收到报文后进行替换。如此实现了在网卡上以内嵌（inline）方式解决TLS协商过程中非对称算法性能不足的问题，并且不涉及到对服务端软件的操作流程上的改动。对于服务端来说，网卡仍然是视为用于收发报文的接口，这样有利于推广到各种现有网卡中。
应当理解的是，上述的TLS协议应理解为在客户端和服务端之间提供传输层安全协议从而为数据传输提供保密性和数据完整性。虽然本申请实施例是以TLS协议为案例，特别是TLS协议的1.3版本，来描述本申请实施例的各项改进，但是这些改进也可以适用于TLS协议的其它版本、或者与TLS协议接近的SSL协议的协商过程。其中，SSL协议和TLS协议的协商过程，都涉及到在实质数据传输之前由通讯双方，如客户端和服务端之间，进行身份认证、协商加密算法以及交换加密密钥等操作。因此，如果某种通信协议或者用于数据传输的安全协议的基本流程能大致上分成协商和交换加密密钥的握手阶段（例如，TLS协议通信基本流程的握手阶段）以及利用加密密钥对实质数据传输进行加密的会话阶段（例如，TLS协议通信基本流程的会话阶段），则在握手阶段或者协商操作时可以适用本申请实施对TLS协议通信基本流程的握手阶段做出的各项改进。
参见图5，图5为本申请实施例提供的一种实现方式的网卡的运行方法流程示意图。
步骤S502：提供带有多个网络出口的网卡，该多个网络出口中的至少一个第一网络出口对应第一模式，至少一个第二网络出口对应第二模式。
步骤S504：根据该网卡需要处理的TLS协商请求的数量及性质，分配TLS协商请求到第一网络出口或者第二网络出口。
这里，第一模式可以指的是常规模式也就是网卡不负责处理基于非对称加密算法的加解密操作的工作模式，而第二模式可以指的是网卡负责处理基于非对称加密算法的加解密操作的工作模式。第二模式的示例可参见图4所示的服务端网卡402。如果通过对应第二模式的第二网络出口来处理TLS协商报文，则意味着通过网卡来负责处理基于非对称加密算法的加解密操作。并且可选地，通过对应第二模式的第二网络出口来处理TLS协商报文还意味着通过网卡来负责图4所示的服务端网卡402的功能，包括ECDH处理、签名处理以及摘要处理。
在步骤S504中，可以选择性地分配TLS协商请求到第一网络出口或者第二网络出口，也就是等效于选择按照第一模式或者第二模式来处理TLS协商请求。在步骤S504中的分配，主要取决于应用场景中处理TLS协商报文特别是其中的基于非对称加密算法的加解密操作而带来的负载相对于数据面的对称加解密负载之间的关系。上面提到，在如语音通信等存在大量短连接的场景下，往往每个会话持续时间都较短，也就需要频繁地建立新的TLS安全通信通道或者说频繁进行握手阶段的协商操作，例如两个人在通话期间断续地会话，每一段会话可能持续不到一分钟但是不同段会话之间间隔较久从而需要频繁地为每一段会话分别协商对称会话密钥。这样造成的影响是：处理TLS协商报文特别是其中的基于非对称加密算法的加解密操作而带来的负载，远高于数据面的对称加解密负载。因此，在步骤S504中，根据该网卡需要处理的TLS协商请求的数量及性质，例如根据TLS协商请求中的被判断为语音通信或其它归类为短连接请求的数量、比例等，可以预计应用场景中基于非对称加密算法的加解密操作而带来的负载相对于数据面的对称加解密负载之间的关系，从而可以确定如何分配TLS协商请求。例如，假设TLS协商请求的性质可以分成预计持续时间不超过5分钟的短会话和预计持续时间超过15分钟的长会话，则通过代表短会话的TLS协商请求和代表长会话的TLS协商请求各自的数量、比例等可以确定如何分配TLS协商请求。在一些实施例中，可以通过解析TLS协商请求获取参考信息做出判断，例如客户端的IP地址，客户端的历史记录，客户端的名称等，在此不做具体限定。
参见图4和图5，本申请实施例提供了一种TLS协议协商方法。所述TLS协议协商方法包括：服务端网卡，响应于接收到客户端发出的客户端招呼报文，提取所述客户端招呼报文中的客户端的第一随机数和第一密钥交换算法参数，上送所述客户端招呼报文到服务端软件；所述服务端软件生成服务端的第二随机数，标记服务端招呼报文中服务端的第二密钥交换算法参数的字段，下发所述第二随机数和所述服务端招呼报文到所述服务端网卡；所述服务端网卡，至少在发出所述服务端招呼报文之前，解析所述服务端招呼报文后进行密码学操作生成所述第二密钥交换算法参数，然后用所述第二密钥交换算法参数替换所标记的所述服务端招呼报文中服务端的密钥交换算法参数的字段。其中，所述服务端网卡还用于，至少在发出服务端改变密码标准报文之前，结合所述第一随机数和所述第一密钥交换算法参数以及所述第二随机数和所述第二密钥交换算法参数计算出对称会话密钥。如此，通过让网卡来处理TLS协商报文或者说TLS通信流程握手阶段或者说基于TLS协议的安全通信信道的建立，包括处理其中的基于非对称加密算法的加解密操作如ECDH密钥交换算法相关计算，从而减少了CPU与外设硬件之间的交互，减少了PCIE总线的数据转移负担以及数据拷贝需求，在短连接场景如语音通信下可以有效降低服务端处理TLS协商报文特别是其中的基于非对称加密算法的加解密操作而带来的负载，进而降低通信开销和提升系统效率。
应当理解的是，图4的TLS协议协商方法以ECDH密钥交换算法或者说ECDH算法作为示例。本申请实施例所提供的TLS协议协商方法可以适用于除了ECDH算法以外的其它非对称加密算法或者类似的加解密算法。在一些示例性实施例中，客户端招呼报文中包括客户端的第一密钥交换算法参数，服务端招呼报文中包括服务端的第二密钥交换算法参数，通过结合第一密钥交换算法参数和第二密钥交换算法参数就可以通过在通信的双方之间交换信息的方式也就是基于密钥交换算法，来实现生成共享密钥例如共享的对称会话密钥。这种基于密钥交换算法来生成共享密钥的非对称加密算法的示例，包括但是不限于，上面提及的ECDH密钥交换算法，还有DH算法。在一些示例性实施例中，可以采用公钥加密和私钥解密的设计的非对称加密算法或者类似加解密手段来保护对称会话密钥，例如用私钥签名和用公钥验签，这方面的示例包括但是不限于，DSA算法、RSA算法和ECDSA算法。另外，本申请实施例所提供的TLS协议协商方法可以适用于通过密钥交换来生成共享密钥的方式，例如采用ECDH算法、DH算法和RSA算法的结合或者ECDSA算法，也就是利用基于密钥交换的非对称加密算法来对参数进行签名，服务端签名，客户端验签，从而保证服务端身份没有被冒充。这样具有更好的前向加密性。此外，本申请实施例所提供的TLS协议协商方法还可以适用于仅采用RSA算法的方式，也就是仅客户端生成会话密钥，使用RSA的公钥加密后发送给服务端，服务端私钥解密后保证通信双方拥有共享密钥。这种仅采用RSA算法的方式，通过让网卡来处理TLS协商报文或者说TLS通信流程握手阶段或者说基于TLS协议的安全通信信道的建立，包括处理其中的基于RSA算法的加解密操作，从而减少了CPU与外设硬件之间的交互，减少了PCIE总线的数据转移负担以及数据拷贝需求，在短连接场景如语音通信下可以有效降低服务端处理TLS协商报文特别是其中的基于非对称加密算法的加解密操作而带来的负载，进而降低通信开销和提升系统效率。
在一种可能的实施方式中，所述服务端软件通过第一报文描述符标记所述服务端招呼报文中服务端的密钥交换算法参数的字段，所述TLS协议协商方法还包括：所述服务端软件通过第二报文描述符标记服务端证书验证报文中签名字段后下发所述服务端证书验证报文到所述服务端网卡；所述服务端网卡，至少在发出所述服务端证书验证报文之前，用证书套件私钥对消息摘要签名并替换所标记的所述服务端证书验证报文中签名字段。
在一种可能的实施方式中，所述服务端软件通过第一报文描述符标记所述服务端招呼报文中服务端的密钥交换算法参数的字段，所述TLS协议协商方法还包括：所述服务端软件通过第三报文描述符标记服务端握手结束报文中摘要字段后下发所述服务端握手结束报文到所述服务端网卡；所述服务端网卡，至少在发出所述服务端握手结束报文之前，填充握手数据摘要到所标记的所述服务端握手结束报文中摘要字段。
在一种可能的实施方式中，所述服务端软件通过第一报文描述符标记所述服务端招呼报文中服务端的密钥交换算法参数的字段，所述TLS协议协商方法还包括：所述服务端软件跳过签名处理和摘要处理并且分别用第二报文描述符和第三报文描述符来标记服务端证书验证报文中签名字段和服务端握手结束报文中摘要字段；所述服务端网卡用于进行签名处理和摘要处理并且分别替换所标记的所述服务端证书验证报文中签名字段和所标记的所述服务端握手结束报文中摘要字段。
在一种可能的实施方式中，所述客户端的密钥交换算法参数和所述服务端的密钥交换算法参数基于同一非对称加密算法，并且所述服务端软件跳过与所述非对称加密算法相关的密码学操作。在一些实施例中，所述非对称加密算法是ECDH密钥交换算法，所述第一密钥交换算法参数是所述客户端的第一ECDH密钥交换算法参数，所述第二密钥交换算法参数是所述服务端的第二ECDH密钥交换算法参数。在一些实施例中，所述非对称加密算法是RSA算法、DSA算法、ECC算法或者DH算法。在一些实施例中，所述对称会话密钥通过所述ECDH密钥交换算法共享给所述客户端。
在一种可能的实施方式中，所述TLS协议协商方法还包括：所述服务端网卡用所述对称会话密钥加密并且发出被加密的扩展信息和被加密的证书。
在一种可能的实施方式中，所述TLS协议协商方法还包括：所述服务端软件，至少在所述服务端网卡接收到所述客户端发出的所述客户端招呼报文之前，对所述服务端网卡进行初始化配置，所述初始化配置包括下发证书和服务端私钥到所述服务端网卡以及为所述服务端的公私钥对分配索引。在一些实施例中，所述TLS协议协商方法还包括：所述服务端软件，至少在所述服务端网卡接收到所述客户端发出的所述客户端招呼报文之前，指定所述服务端网卡监听给定TLS协议端口，所述客户端发出的所述客户端招呼报文通过所述给定TLS协议端口被所述服务端网卡接收。在一些实施例中，所述服务端网卡包括多个网络出口用于接收多个TLS协商请求，其中基于所述多个TLS协商请求的数量及性质确定每一个TLS协商请求所对应的网络出口是否为所述给定TLS协议端口。
参见图4和图5，本申请实施例提供了一种网卡，所述网卡包括多个网络出口，该多个网络出口中的至少一个第一网络出口对应第一模式，该多个网络出口中的至少一个第二网络出口对应第二模式，所述网卡用于根据待处理的TLS协商请求的数量及性质分配TLS协商请求到第一网络出口或者第二网络出口，其中，被分配到第二网络出口的TLS协商请求的处理流程参照图4所述的方法实施例。如此，通过让网卡来处理TLS协商报文或者说TLS通信流程握手阶段或者说基于TLS协议的安全通信信道的建立，包括处理其中的基于非对称加密算法的加解密操作如ECDH密钥交换算法相关计算，从而减少了CPU与外设硬件之间的交互，减少了PCIE总线的数据转移负担以及数据拷贝需求，在短连接场景如语音通信下可以有效降低服务端处理TLS协商报文特别是其中的基于非对称加密算法的加解密操作而带来的负载，进而降低通信开销和提升系统效率。
参见图6，图6是本申请实施例提供的一种计算设备的结构示意图，该计算设备600包括：一个或者多个处理器610、通信接口620以及存储器630。所述处理器610、通信接口620以及存储器630通过总线640相互连接。可选地，该计算设备600还可以包括输入/输出接口650，输入/输出接口650连接有输入/输出设备，用于接收用户设置的参数等。该计算设备600能够用于实现上述的本申请实施例中设备实施例或者系统实施例的部分或者全部功能；处理器610还能够用于实现上述的本申请实施例中方法实施例的部分或者全部操作步骤。例如，该计算设备600执行各种操作的具体实现可参照上述实施例中的具体细节，如处理器610用于执行上述图4对应的实施例中服务端软件400负责的操作。再例如，计算设备600可以是用于实现图4对应的实施例中服务端网卡402的部分或者全部功能，计算设备600的处理器610可以是服务端网卡402上的处理器，计算设备600的存储器630可以是服务端网卡402上的存储器，计算设备600的通信接口620可以是用于服务端网卡402与计算机之间的通信。
应当理解的是，图6的计算设备600可以包括一个或者多个处理器610，并且多个处理器610可以按照并行化连接方式、串行化连接方式、串并行连接方式或者任意连接方式来协同提供处理能力，或者多个处理器610可以构成处理器序列或者处理器阵列，或者多个处理器610之间可以分成主处理器和辅助处理器，或者多个处理器610之间可以具有不同的架构如采用异构计算架构。另外，图6所示的计算设备600，图6所示的结构和上述描述是示例性且非限制性的。在一些示例性实施例中，计算设备600可以包括比图6所示的更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者具有不同的部件布置。
处理器610可以有多种具体实现形式，例如处理器610可以包括中央处理器（central processing unit，CPU）、图形处理器（graphic processing unit，GPU）、神经网络处理器（neural-network processing unit，NPU）、张量处理器（tensor processingunit，TPU）或数据处理器（data processing unit，DPU）等一种或多种的组合，本申请实施例不做具体限定。处理器610还可以是单核处理器或多核处理器。处理器610可以由CPU和硬件芯片的组合。上述硬件芯片可以是专用集成电路（application-specific integratedcircuit，ASIC），可编程逻辑器件（programmable logic device，PLD）或其组合。上述PLD可以是复杂可编程逻辑器件（complex programmable logic device，CPLD），现场可编程逻辑门阵列（field-programmable gate array，FPGA），通用阵列逻辑（generic array logic，GAL）或其任意组合。处理器610也可以单独采用内置处理逻辑的逻辑器件来实现，例如FPGA或数字信号处理器（digital signal processor，DSP）等。
通信接口620可以为有线接口或无线接口，用于与其他模块或设备进行通信，有线接口可以是以太接口、局域互联网络（local interconnect network，LIN）等，无线接口可以是蜂窝网络接口或使用无线局域网接口等。
存储器630可以是非易失性存储器，例如，只读存储器（read-only memory，ROM）、可编程只读存储器（programmable ROM，PROM）、可擦除可编程只读存储器（erasable PROM，EPROM）、电可擦除可编程只读存储器（electrically EPROM，EEPROM）或闪存。存储器630也可以是易失性存储器，易失性存储器可以是随机存取存储器（random access memory，RAM），其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器（static RAM，SRAM）、动态随机存取存储器（dynamic RAM，DRAM）、同步动态随机存取存储器（synchronous DRAM，SDRAM）、双倍数据速率同步动态随机存取存储器（double data rate SDRAM，DDR SDRAM）、增强型同步动态随机存取存储器（enhancedSDRAM，ESDRAM）、同步连接动态随机存取存储器（synchlink DRAM，SLDRAM）和直接内存总线随机存取存储器（direct rambus RAM，DR RAM）。存储器630也可用于存储程序代码和数据，以便于处理器610调用存储器630中存储的程序代码执行上述方法实施例中的部分或者全部操作步骤，或者执行上述设备实施例中的相应功能。此外，计算设备600可能包含相比于图6展示的更多或者更少的组件，或者有不同的组件配置方式。
总线640可以是快捷外围部件互连标准（peripheral component interconnectexpress，PCIe）总线，或扩展工业标准结构（extended industry standard architecture，EISA）总线、统一总线（unified bus，Ubus或UB）、计算机快速链接（compute express link，CXL）、缓存一致互联协议（cache coherent interconnect for accelerators，CCIX）等。总线640可以分为地址总线、数据总线、控制总线等。总线640除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
本申请实施例还提供一种系统，该系统包括多个计算设备，每个计算设备的结构可以参照上述图6所描述的计算设备的结构。该系统可实现的功能或者操作可以参照上述图4对应的实施例中服务端网卡402的部分或者全部功能，在此不再赘述。
本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，当所述计算机指令在计算机设备（如一个或者多个处理器）上运行时可以实现上述方法实施例中的方法步骤。所述计算机可读存储介质的处理器在执行上述方法步骤的具体实现可参照上述方法实施例图4对应的实施例中服务端网卡402的部分或者全部功能，在此不再赘述。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。本申请实施例可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时，上述实施例可以全部或部分地以计算机程序产品的形式实现。本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质上实施的计算机程序产品的形式。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载或执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线）或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集合的服务器、数据中心等数据存储设备。可用介质可以是磁性介质（如软盘、硬盘、磁带）、光介质、或者半导体介质。半导体介质可以是固态硬盘，也可以是随机存取存储器，闪存，只读存储器，可擦可编程只读存储器（电可擦可编程只读存储器，寄存器或任何其他形式的合适存储介质）。
本申请是参照根据本申请实施例的方法、设备（系统）、和计算机程序产品的流程图和/或方框图来描述。可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。显然，本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的精神和范围。本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并或删减；本申请实施例系统中的模块可以根据实际需要进行划分、合并或删减。如果本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (16)

1.一种TLS协议协商方法，其特征在于，所述TLS协议协商方法包括：
服务端网卡，响应于接收到客户端发出的客户端招呼报文，提取所述客户端招呼报文中的客户端的第一随机数和第一密钥交换算法参数，上送所述客户端招呼报文到服务端软件；
所述服务端软件生成服务端的第二随机数，标记服务端招呼报文中服务端的第二密钥交换算法参数的字段，下发所述第二随机数和所述服务端招呼报文到所述服务端网卡，其中，所述客户端的第一密钥交换算法参数和所述服务端的第二密钥交换算法参数基于同一非对称加密算法；
所述服务端网卡，至少在发出所述服务端招呼报文之前，解析所述服务端招呼报文后进行与所述非对称加密算法相关的密码学操作生成所述第二密钥交换算法参数，然后用所述第二密钥交换算法参数替换所标记的所述服务端招呼报文中服务端的第二密钥交换算法参数的字段，
其中，所述服务端网卡还用于，至少在发出服务端改变密码标准报文之前，结合所述第一随机数和所述第一密钥交换算法参数以及所述第二随机数和所述第二密钥交换算法参数计算出对称会话密钥。
2.根据权利要求1所述的TLS协议协商方法，其特征在于，所述服务端软件通过第一报文描述符标记所述服务端招呼报文中服务端的第二密钥交换算法参数的字段，所述TLS协议协商方法还包括：
所述服务端软件通过第二报文描述符标记服务端证书验证报文中签名字段后下发所述服务端证书验证报文到所述服务端网卡；
所述服务端网卡，至少在发出所述服务端证书验证报文之前，用证书套件私钥对消息摘要签名并替换所标记的所述服务端证书验证报文中签名字段。
3.根据权利要求1所述的TLS协议协商方法，其特征在于，所述服务端软件通过第一报文描述符标记所述服务端招呼报文中服务端的第二密钥交换算法参数的字段，所述TLS协议协商方法还包括：
所述服务端软件通过第三报文描述符标记服务端握手结束报文中摘要字段后下发所述服务端握手结束报文到所述服务端网卡；
所述服务端网卡，至少在发出所述服务端握手结束报文之前，填充握手数据摘要到所标记的所述服务端握手结束报文中摘要字段。
4.根据权利要求1所述的TLS协议协商方法，其特征在于，所述服务端软件通过第一报文描述符标记所述服务端招呼报文中服务端的第二密钥交换算法参数的字段，所述TLS协议协商方法还包括：
所述服务端软件跳过签名处理和摘要处理并且分别用第二报文描述符和第三报文描述符来标记服务端证书验证报文中签名字段和服务端握手结束报文中摘要字段；
所述服务端网卡用于进行签名处理和摘要处理并且分别替换所标记的所述服务端证书验证报文中签名字段和所标记的所述服务端握手结束报文中摘要字段。
5.根据权利要求1所述的TLS协议协商方法，其特征在于，所述服务端软件跳过与所述非对称加密算法相关的密码学操作。
6.根据权利要求5所述的TLS协议协商方法，其特征在于，所述非对称加密算法是ECDH密钥交换算法，所述第一密钥交换算法参数是所述客户端的第一ECDH密钥交换算法参数，所述第二密钥交换算法参数是所述服务端的第二ECDH密钥交换算法参数。
7.根据权利要求5所述的TLS协议协商方法，其特征在于，所述非对称加密算法是RSA算法、DSA算法、ECC算法或者DH算法。
8.根据权利要求6所述的TLS协议协商方法，其特征在于，所述对称会话密钥通过所述ECDH密钥交换算法共享给所述客户端。
9.根据权利要求1所述的TLS协议协商方法，其特征在于，所述TLS协议协商方法还包括：
所述服务端网卡用所述对称会话密钥加密并且发出被加密的扩展信息和被加密的证书。
10.根据权利要求1所述的TLS协议协商方法，其特征在于，所述TLS协议协商方法还包括：
所述服务端软件，至少在所述服务端网卡接收到所述客户端发出的所述客户端招呼报文之前，对所述服务端网卡进行初始化配置，所述初始化配置包括下发证书和服务端私钥到所述服务端网卡以及为所述服务端的公私钥对分配索引。
11.根据权利要求10所述的TLS协议协商方法，其特征在于，所述TLS协议协商方法还包括：
所述服务端软件，至少在所述服务端网卡接收到所述客户端发出的所述客户端招呼报文之前，指定所述服务端网卡监听给定TLS协议端口，所述客户端发出的所述客户端招呼报文通过所述给定TLS协议端口被所述服务端网卡接收。
12.根据权利要求11所述的TLS协议协商方法，其特征在于，所述服务端网卡包括多个网络出口用于接收多个TLS协商请求，其中基于所述多个TLS协商请求的数量及性质确定每一个TLS协商请求所对应的网络出口是否为所述给定TLS协议端口。
13.一种计算机设备，其特征在于，所述计算机设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现根据权利要求1至12中任一项所述的方法。
14.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机设备上运行时使得所述计算机设备执行根据权利要求1至12中任一项所述的方法。
15.一种计算机程序产品，其特征在于，所述计算机程序产品包括存储在计算机可读存储介质上的指令，当所述指令在计算机设备上运行时使得所述计算机设备执行根据权利要求1至12中任一项所述的方法。
16.一种网卡，其特征在于，所述网卡包括多个网络出口，该多个网络出口中的至少一个第一网络出口对应第一模式，该多个网络出口中的至少一个第二网络出口对应第二模式，所述网卡用于根据待处理的TLS协商请求的数量及性质分配TLS协商请求到第一网络出口或者第二网络出口，其中，被分配到第二网络出口的TLS协商请求的处理流程参照根据TLS权利要求1至12中任一项所述的方法。
CN202211067969.1A 2022-09-02 2022-09-02 一种tls协议协商方法、设备及介质 Active CN115174267B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211067969.1A CN115174267B (zh) 2022-09-02 2022-09-02 一种tls协议协商方法、设备及介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211067969.1A CN115174267B (zh) 2022-09-02 2022-09-02 一种tls协议协商方法、设备及介质

Publications (2)

Publication Number Publication Date
CN115174267A CN115174267A (zh) 2022-10-11
CN115174267B true CN115174267B (zh) 2022-11-18

Family

ID=83481912

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211067969.1A Active CN115174267B (zh) 2022-09-02 2022-09-02 一种tls协议协商方法、设备及介质

Country Status (1)

Country Link
CN (1) CN115174267B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116016302B (zh) * 2023-02-24 2023-06-23 星汉智能科技股份有限公司 基于https的智能卡数据加解密测试方法和系统
CN116055215B (zh) * 2023-03-02 2024-03-15 上海弘积信息科技有限公司 一种基于网络安全传输协议的通信方法、系统及设备
CN117294541B (zh) * 2023-11-27 2024-04-16 浙江深大智能科技有限公司 票务系统防刷票的多重加密方法、系统、设备和介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101790163A (zh) * 2010-01-08 2010-07-28 电子科技大学 面向Ad Hoc网络的动态密钥交换协议
CN110430266A (zh) * 2019-08-06 2019-11-08 腾讯科技（深圳）有限公司 一种边云协同数据传输方法、装置、设备及存储介质
CN110995414A (zh) * 2019-12-23 2020-04-10 中金金融认证中心有限公司 基于国密算法在tls1_3协议中建立通道的方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9184911B2 (en) * 2014-04-08 2015-11-10 Cloudflare, Inc. Secure session capability using public-key cryptography without access to the private key
ES2828948T3 (es) * 2015-07-02 2021-05-28 Telefonica Cibersecurity & Cloud Tech S L U Método, sistema y productos de programa informático para posibilitar de forma segura una funcionalidad en - red a lo largo de sesiones de datos cifradas

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101790163A (zh) * 2010-01-08 2010-07-28 电子科技大学 面向Ad Hoc网络的动态密钥交换协议
CN110430266A (zh) * 2019-08-06 2019-11-08 腾讯科技（深圳）有限公司 一种边云协同数据传输方法、装置、设备及存储介质
CN110995414A (zh) * 2019-12-23 2020-04-10 中金金融认证中心有限公司 基于国密算法在tls1_3协议中建立通道的方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
基于国密算法的Android智能终端SSL协议设计与实现;施晓芳等;《福建师大福清分校学报》;20190420(第02期);全文 *

Also Published As

Publication number Publication date
CN115174267A (zh) 2022-10-11

Similar Documents

Publication Publication Date Title
CN115174267B (zh) 一种tls协议协商方法、设备及介质
KR20200126320A (ko) 신뢰 실행 환경을 위한 분산 키 관리
CN110572460B (zh) 基于区块链系统的数据传输方法、装置及计算机设备
US11212265B2 (en) Perfect forward secrecy (PFS) protected media access control security (MACSEC) key distribution
US11375369B2 (en) Message authentication method and communication method of communication network system, and communication network system
WO2024001035A1 (zh) 基于区块链中继通信网络系统的消息传输方法及装置
CN112968778A (zh) 区块链国密算法的转换方法、系统、计算机设备及应用
CN113221146A (zh) 区块链节点间数据传输的方法和装置
CN115622772A (zh) 一种金融业务服务的金融数据传输方法及应用网关
CN114142995B (zh) 面向区块链中继通信网络的密钥安全分发方法及装置
CN109428876B (zh) 一种握手连接方法及装置
CN116132043B (zh) 会话密钥协商方法、装置及设备
CN112615838A (zh) 一种可扩展的区块链跨链通信方法
CN106487761B (zh) 一种消息传输方法和网络设备
WO2024001037A1 (zh) 一种消息传输方法、装置、电子设备和存储介质
CN111414640A (zh) 秘钥访问控制方法和装置
CN115021919A (zh) Ssl协商方法、装置、设备及计算机可读存储介质
CN112995210B (zh) 一种数据传输方法、装置及电子设备
CN114244513A (zh) 密钥协商方法、设备及存储介质
CN111901335B (zh) 基于中台的区块链数据传输管理方法及系统
CN114611129A (zh) 一种数据隐私保护方法和系统
CN113986464A (zh) 虚拟机安全迁移的方法和系统
CN113422753A (zh) 数据处理方法、装置、电子设备及计算机存储介质
CN116232944B (zh) 用于传输层安全协议报文业务的方法、设备及介质
CN116599772B (zh) 一种数据处理方法及相关设备

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