Data transmission method and device based on kTLS, equipment and storage medium

Abstract

The embodiment of the invention relates to a data transmission method and device based on kTLS, equipment and a storage medium, and the method comprises the steps: calling a first preset interface to send message data to a ULP frame through an application program process under the condition that the application program process completes TLS handshake, and calling a second preset interface to send a password suite to a hardware encryption and decryption module; creating a data structure through a ULP framework, and storing the message data into the data structure; extracting the message data from the data structure through a protocol stack, and packaging the message data to obtain a corresponding data packet; the data packets are stored in a sending queue through the network equipment subsystem; taking out the data packet from the sending queue through driving, and storing the data packet into a hardware queue; and taking out the data packet from the hardware queue through a hardware encryption and decryption module, and performing encryption processing on the data packet based on the cipher suite.

Description

Technical Field

[0001] The embodiments of the present disclosure relate to the technical field of data transmission, and in particular, to a kTLS-based data transmission method, apparatus, device, and storage medium. Background Art

[0002] With the rapid development of the Internet, the traditional HTTP protocol transmission method will face various threats such as data leakage in actual applications. If you are in an untrusted network, the data packet passes through the intermediate node, and the middleman may interfere with the transmitted data, such as eavesdropping, tampering, replaying, etc. Therefore, the HTTPS protocol adds encryption mechanisms SSL or TLS on the basis of the HTTP protocol to realize the functions of data encryption and user authentication. Among them, TLS is an extremely widely used encryption protocol, usually implemented in user space based on OpenSSL or NGINX. In order to improve performance, Kernel TLS (kTLS) came into being. kTLS moves encryption and decryption from user space to kernel space for execution, reducing the back and forth transmission of data between user space and kernel space, and improving the overall data transmission efficiency.

[0003] However, the existing kTLS implementation is mainly based on software encryption and decryption libraries or calling hardware encryption and decryption chips, with encryption and decryption in bypass call mode, and performance needs to be improved. Summary of the invention

[0004] In order to solve the above technical problems or at least partially solve the above technical problems, the embodiments of the present disclosure provide a data transmission method, apparatus, device and storage medium based on KTLS.

[0005] A first aspect of an embodiment of the present disclosure provides a KTLS-based data transmission method, which is applied to a sending end, wherein the method includes:

[0006] When the application process completes the TLS handshake, calling the first preset interface to send message data to the ULP framework through the application process, and calling the second preset interface to send the cipher suite to the hardware encryption and decryption module;

[0007] Creating a data structure through the ULP framework, and storing the message data in the data structure;

[0008] The message data is taken out from the data structure through the protocol stack, and the message data is encapsulated to obtain a corresponding data packet;

[0009] By means of a network device subsystem, storing the data packet into a sending queue;

[0010] By means of a driver, taking the data packet from the sending queue and storing the data packet into a hardware queue;

[0011] The data packet is taken out from the hardware queue through the hardware encryption and decryption module, and the data packet is encrypted based on the cipher suite.

[0012] A second aspect of an embodiment of the present disclosure provides a KTLS-based data transmission method, which is applied to a receiving end. The method includes:

[0013] By means of the hardware encryption and decryption module, when the received data packet is a TLS data packet, the data packet is decrypted based on the cipher suite, wherein the processed data packet is written into the memory;

[0014] By driving, taking the processed data packet out from the memory, and transmitting the processed data packet to the protocol stack;

[0015] Decapsulating the processed data packet to obtain corresponding message data through the protocol stack, and sending the message data to the ULP framework;

[0016] The message data is sent to the corresponding application process through the ULP framework.

[0017] A third aspect of an embodiment of the present disclosure provides a KTLS-based data transmission device, which is applied to a sending end, wherein the device includes:

[0018] A first calling module is used to call a first preset interface to send message data to a ULP framework through the application process when the application process completes the TLS handshake, and call a second preset interface to send a cipher suite to a hardware encryption and decryption module;

[0019] A first storage module, used for creating a data structure through the ULP framework, and storing the message data in the data structure;

[0020] A first encapsulation module, used to take out the message data from the data structure through a protocol stack, and encapsulate the message data to obtain a corresponding data packet;

[0021] A second storage module, used for storing the data packet into a sending queue through a network device subsystem;

[0022] A third storage module, used for taking the data packet from the sending queue and storing the data packet into a hardware queue through a driver;

[0023] The first encryption module is configured to retrieve the data packet from the hardware queue through the hardware encryption and decryption module, and encrypt the data packet based on the cipher suite.

[0024] The fourth aspect of the embodiments of the present disclosure provides a KTLS-based data transmission device, which is applied to a receiving end. The device includes:

[0025] The first decryption module is configured to decrypt the data packet based on the cipher suite through the hardware encryption and decryption module when the received data packet is a TLS data packet, and the processed data packet is written into the memory.

[0026] The first transmission module is configured to retrieve the processed data packet from the memory through the driver and transmit the processed data packet to the protocol stack.

[0027] The first sending module is configured to perform a de-encapsulation process on the processed data packet through the protocol stack to obtain the corresponding message data, and send the message data to the ULP framework.

[0028] The second sending module is configured to send the message data to the corresponding application process through the ULP framework.

[0029] The third aspect of the embodiments of the present disclosure provides an electronic device. The server includes: a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, the processor executes the method of the first aspect.

[0030] The fourth aspect of the embodiments of the present disclosure provides a computer-readable storage medium. The storage medium stores a computer program. When the computer program is executed by a processor, the method of the first aspect can be implemented.

[0031] The technical solutions provided by the embodiments of the present disclosure have the following advantages compared with the prior art:

[0032] In the embodiments of the present disclosure, when the application process completes the TLS handshake, the application process can call the first preset interface to send message data to the ULP framework and call the second preset interface to send the cipher suite to the hardware encryption / decryption module; through the ULP framework, a data structure is created and the message data is stored in the data structure; through the protocol stack, the message data is taken out from the data structure and encapsulated to obtain a corresponding data packet; through the network device subsystem, the data packet is stored in the sending queue; through the driver, the data packet is taken out from the sending queue and stored in the hardware queue; through the hardware encryption / decryption module, the data packet is taken out from the hardware queue and encrypted based on the cipher suite. It can be seen that the embodiments of the present disclosure can use the hardware encryption / decryption module to implement encryption processing in an inline manner, thereby improving the encryption performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The accompanying drawings herein are incorporated into the specification and form a part of the specification, showing embodiments consistent with the present disclosure and, together with the specification, are used to explain the principles of the present disclosure.

[0034] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, the following will briefly introduce the accompanying drawings required for use in the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without creative efforts.

[0035] Figure 1 is a flowchart of a data transmission method based on KTLS provided by the embodiments of the present disclosure;

[0036] Figure 2 is a flowchart of a data transmission method based on KTLS provided by the embodiments of the present disclosure;

[0037] Figure 3 is a flowchart of a data sending process based on KTLS provided by the embodiments of the present disclosure;

[0038] Figure 4 is a flowchart of a data receiving process based on KTLS provided by the embodiments of the present disclosure;

[0039] Figure 5 is a schematic structural diagram of a data transmission device based on KTLS provided by the embodiments of the present disclosure;

[0040] Figure 6 is a schematic structural diagram of a data transmission device based on KTLS provided by the embodiments of the present disclosure;

[0041] Figure 7 is a schematic structural diagram of an electronic device in the embodiments of the present disclosure. Detailed implementation manners

[0042] In order to more clearly understand the above-mentioned objects, features and advantages of the present disclosure, the solutions of the present disclosure will be further described below. It should be noted that, without conflict, the embodiments of the present disclosure and the features in the embodiments may be combined with each other.

[0043] Many specific details are set forth in the following description in order to provide a thorough understanding of the present disclosure, but the present disclosure may be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only a part of the embodiments of the present disclosure, rather than all of the embodiments.

[0044] Figure 1 is a flowchart of a data transmission method based on KTLS provided by an embodiment of the present disclosure, and this method can be executed by a sending end. The sending end can be exemplarily understood as a device such as a server or a desktop computer installed with Linux. Among them, KTLS, that is, Kernel TLS (Transport Layer Security), is a function of the Linux kernel, aiming to improve the performance of TLS (Transport Layer Security) connections. Traditional TLS connections are processed in user space, while Kernel TLS moves part or all of the TLS processing into the kernel, thereby reducing the context switching between user space and kernel space and improving the performance.

[0045] As Figure 1 shown, the method provided in this embodiment includes the following steps:

[0046] S110. When the application process completes the TLS handshake, through the application process, call the first preset interface to send message data to the ULP framework, and call the second preset interface to send the cipher suite to the hardware encryption and decryption module.

[0047] Specifically, once the TLS handshake is completed, the sending end and the receiving end reach an agreement on how to communicate securely, including the cipher suite and the like.

[0048] Specifically, the application process may include an OpenSSL process or an Nginx process, but is not limited thereto. Among them, OpenSSL is an open-source software library that provides support for various encryption algorithms and protocols, and is mainly used to implement secure communication. It is widely used in various applications that require encryption, including but not limited to web servers, mail servers, virtual private networks (VPNs), etc. Nginx is a high-performance HTTP and reverse proxy server, and is also commonly used for load balancing, caching, and as a web server. Nginx is suitable for large-scale websites and applications.

[0049] Specifically, the application process can call the send interface, and then the send interface can call the sendto interface to send message data to the ULP framework. Moreover, the application process can call the setsockopt interface to send the cipher suite to the hardware encryption and decryption module.

[0050] S120: Create a data structure through the ULP framework and store the message data in the data structure.

[0051] Specifically, the UserLevel Protocol (ULP) allows an application to enable and manage the upper-layer application protocol of TCP through the standard interface provided by the kernel, which enables custom processing logic to be inserted on top of TCP without changing the transport layer code. After implementing kTLS, the original sendmsg interface can be modified into a new sendmsg interface, which performs TLS processing on the message data. In this way, when the sendto interface calls the new sendmsg interface, the message data can enter the kernel space, and the kernel, detecting that kTLS has been enabled, performs TLS processing on the message data. TLS processing includes creating a data structure (such as a linked list, etc.) and storing the message data in the data structure for the protocol stack to process.

[0052] S130: Retrieve the message data from the data structure through the protocol stack and perform encapsulation processing on the message data to obtain the corresponding data packet.

[0053] Specifically, the TCP layer in the protocol stack takes over the message data, divides it into data segments of the maximum segment size suitable for transmission, and TCP also adds header information such as sequence numbers and acknowledgment numbers to each data segment to ensure reliable data transmission. After being processed by the TCP layer, it is handed over to the IP layer, which adds IP header information to each data segment to determine the optimal routing path. Subsequently, it reaches the link layer, where appropriate frame headers and tails are added to obtain the data packet. However, this is not limited to this.

[0054] S140: Deposit the data packet into the send queue through the network device subsystem.

[0055] Specifically, the data packet is usually encapsulated into a sk_buff structure (abbreviated as skb), and the network device subsystem can select an appropriate send queue and add the skb to the send queue to wait for transmission.

[0056] S150: Retrieve the data packet from the send queue through the driver and deposit the data packet into the hardware queue.

[0057] In some embodiments, storing a data packet in a hardware queue includes: determining whether the seq of the data packet is an expected value;

[0058] If the seq of the data packet is an expected value, store the data packet in the hardware queue;

[0059] If the seq of the data packet is not an expected value, determine that the data packet is out of order, reorder all the data packets corresponding to the message to which the data packet belongs to update its seq, and re-store all the data packets corresponding to the message to which the data packet belongs in the transmission queue in the reordered order.

[0060] Specifically, when the data packet is ready to be sent, the driver (i.e., the network device driver) is called to actually send the data. The driver can check the seq (i.e., the sequence number) of the data packet to ensure that the data packets are sent in the correct order. Specifically, if the seq is an expected value, the data packet is stored in the hardware queue for preparation of sending; if the seq is not an expected value, the data packet is marked as out of order. The driver can temporarily store these out-of-order data packets, wait for all the data packets corresponding to the same message to arrive, reorder them, and store all the data packets corresponding to the same message in the transmission queue in the reordered order, so that these data packets can be smoothly stored in the hardware queue for preparation of sending.

[0061] It can be understood that by synchronizing the seq of the TCP protocol, it can be ensured that the hardware encryption and decryption module can correctly process the encryption of out-of-order messages.

[0062] Of course, in some other embodiments, the hardware encryption and decryption chip can be mounted on a DPU or a smart network card. If the DPU or the smart network card supports the GSO and GRO functions, the DPU or the smart network card can perform the fragmentation work on the message data with an ultra-long payload. In this way, for the message data that needs to be fragmented, there is no need to synchronize the seq of the TCP protocol, and the encryption will be performed first in the sending stage and then the ciphertext will be fragmented.

[0063] S160: Retrieve a data packet from the hardware queue through the hardware encryption and decryption module, and perform encryption processing on the data packet based on the cipher suite.

[0064] Specifically, the hardware encryption and decryption module (such as a hardware encryption and decryption chip, etc.) can encrypt the data packet by using symmetric encryption and decryption methods, but is not limited thereto.

[0065] Specifically, the hardware encryption and decryption chip can be mounted on a DPU or a smart network card, and the DPU or the smart network card can send the encrypted data packet to the receiving end, but is not limited thereto.

[0066] In the embodiments of the present disclosure, data transfer between the user space and the kernel space is implemented based on an application process (such as OpenSSL or Nginx) in the user space, the call logic of kTLS is implemented based on the ULP framework in the kernel space, and a DPU or an intelligent network card equipped with a hardware encryption / decryption chip is used to implement encryption processing in an inline manner, thereby improving the encryption performance.

[0067] Figure 2 FIG. 4 is a flowchart of a data transmission method based on kTLS provided by the embodiments of the present disclosure. This method can be executed by a receiving end. The receiving end can be exemplarily understood as a device such as a server or a desktop computer installed with Linux. As Figure 2 shown, the method provided in this embodiment includes the following steps:

[0068] S210. When the received data packet is a TLS data packet, decrypt the data packet based on the cipher suite through a hardware encryption / decryption module, where the processed data packet is written into the memory.

[0069] Specifically, the flow table in the DPU or the intelligent network card can be configured to identify TLS traffic. Then, when a data packet is received from the network, the DPU or the intelligent network card can check whether the received data packet conforms to the characteristics of a TLS message. If the match is successful, the data packet will be marked as a TLS data packet. If the received data packet is a TLS data packet, the hardware encryption / decryption module installed in the DPU or the intelligent network card can decrypt the data packet based on the cipher suite and write the processed data packet into the memory through DMA (Direct Memory Access) or other means. Using the DMA method can reduce the burden on the CPU and improve the data transmission efficiency. Among them, the hardware encryption / decryption module can use symmetric encryption / decryption to decrypt the received data packet, but it is not limited to this.

[0070] S220. Through the driver, take out the processed data packet from the memory and transmit the processed data packet to the protocol stack.

[0071] In some embodiments, optionally, taking out the processed data packet from the memory and transmitting the processed data packet to the protocol stack includes: taking out the processed data packet from the memory and adding the processed data packet to the data reception queue;

[0072] judging whether the processed data packet has been decrypted;

[0073] if the processed data packet has been decrypted, set a decryption flag bit for the processed data packet and transmit the processed data packet to the protocol stack;

[0074] If the processed data packet is not decrypted, it is determined that the processed data packet is out of order. A resynchronization seq flag bit is set for the processed data packet, the processed data packet is added to the seq resynchronization queue, the seq of the processed data packet in the seq resynchronization queue is updated, and the updated seq is sent to the hardware encryption / decryption module so that the hardware encryption / decryption module can re-decrypt the processed data packet in the seq resynchronization queue.

[0075] Specifically, when the DMA operation is completed, the DPU or the intelligent network card will initiate a hardware interrupt to the CPU, notifying the CPU that a new processed data packet has arrived, and call the interrupt handling function to generate a soft interrupt. The soft interrupt calls the receive handling function (such as the poll function) to start polling for packet reception. Specifically, it checks whether a new processed data packet has arrived in the pre-allocated memory. If a new processed data packet has arrived, the processed data packet is extracted from the pre-allocated memory and added to the data reception queue. It is checked whether the processed data packet has been decrypted by the hardware encryption / decryption chip. If it has been decrypted, the decryption flag bit is set. If it has not been decrypted, it means that the data packet may have arrived out of order, and the resynchronization seq flag bit is set. The un-decrypted processed data packet is placed in the seq resynchronization queue. To ensure that subsequent processed data packets can be correctly decrypted, the driver updates the seq of the processed data packet in the seq resynchronization queue and sends the updated seq to the hardware encryption / decryption module. In this way, the hardware encryption / decryption module can use the updated seq to re-decrypt. After decryption is completed, the decrypted processed data packet is placed in the data reception queue, and the processed data packet in the data reception queue will be passed to the kernel protocol stack for further processing.

[0076] Optionally, the method further includes: if the seq resynchronization queue includes a processed data packet, reset the corresponding decryption parameters to the hardware encryption / decryption module.

[0077] Specifically, the decryption parameters refer to various configuration and status information required during the decryption process. The decryption parameters may include seq, etc., but are not limited thereto.

[0078] It can be understood that when there is data in the seq resynchronization queue, it means that some previous processed data packets have arrived out of order, and the status of the hardware encryption / decryption module needs to be reset. The driver will reset the correct decryption parameters to the hardware encryption / decryption module to ensure correct decryption.

[0079] Of course, in other embodiments, the hardware encryption and decryption chip can be mounted on the DPU or smart network card. If the DPU or smart network card supports GSO and GRO functions, the DPU or smart network card can aggregate multiple fragmented data packets into a large packet and then pass it to the protocol stack for processing. In this way, for message data that needs to be fragmented, there is no need to synchronize the seq of the TCP protocol. The receiving stage will first reassemble the fragmented message and then decrypt it.

[0080] S230 . Decapsulate the processed data packet through the protocol stack to obtain corresponding message data, and send the message data to the ULP framework.

[0081] Specifically, the link layer, IP layer and TCP layer in the protocol stack process the data packet in turn to obtain corresponding message data, and then send the message data to the ULP framework for further processing.

[0082] S240 . Send the message data to the corresponding application process through the ULP framework.

[0083] Optionally, sending the message data to the corresponding application process includes: determining whether the message data has a decryption mark bit;

[0084] If the message data has a decryption flag bit, the message data is sent to the corresponding application process;

[0085] If the message data does not have a decryption mark bit, the message data is decrypted through the bypass call mode, and the message data before the message data and belonging to the same TLS record as the message data are re-encrypted and then decrypted again.

[0086] Specifically, the ULP calls the TLS processing function to determine whether the processed data packet corresponding to the message data is set with a decryption flag bit, thereby determining whether the message data has been decrypted by the hardware encryption and decryption module. If the message data has been decrypted, the sk_buff structure of the message data is converted into a format suitable for the user application (such as structmsghdr), and the converted data (msg) is provided to the application process in the user space (such as OpenSSL process or Nginx process). If the message data is not decrypted, the message data is decrypted through the bypass call mode, such as calling the software encryption and decryption library or calling the hardware encryption and decryption chip for decryption processing, and the message data that has been decrypted before the current message data needs to be re-encrypted and decrypted to ensure the integrity of the decrypted data, and then it is sent to the corresponding application process.

[0087] In the embodiments of the present disclosure, a DPU or an intelligent network card equipped with a hardware encryption and decryption chip is used to decrypt the received data packet first, and then the decrypted data packet is further processed through a driver, a protocol stack, a ULP framework, etc. In this way, the decryption process can be implemented in an inline manner, thereby improving the decryption performance.

[0088] The following combines a specific example to elaborate on the KTLS-based data transmission method provided by the embodiments of the present disclosure. In the application layer of the embodiments of the present disclosure, the TLS handshake process needs to be completed. At this time, TLS version information, encryption and decryption algorithms, key information, etc. will be negotiated and generated. After completion, these information will be sent to the hardware encryption and decryption module through the setsockopt interface. The subsequent message payload needs to complete symmetric encryption and decryption, and this part is implemented by the hardware for offloading and acceleration. The TLS hardware offloading processing flow is introduced in detail for the sending direction and the receiving direction respectively.

[0089] Sending process (sender), as Figure 3 shown: After the TLS handshake process is completed, the application program process in the user space (such as the OpenSSL process or the Nginx process) calls the send interface, and the send interface then calls the sendto interface to send the message data. Then, it enters the ULP framework for processing. After implementing kLS, the original sendmsg interface is replaced and the TLS processing is added. The TLS plaintext data (i.e., the message data) is stored in a linked list and handed over to the protocol stack for processing. It should be noted that if the encryption and decryption algorithm used by the subsequent hardware encryption and decryption chip is AES-GCM or SM4-GCM, since there will be a check bit after the plaintext data is encrypted, padding needs to be added to the data length part to ensure the correct length during the process of the protocol stack processing the message fragmentation. Then, the TCP layer, IP layer, and link layer in the protocol stack process the message data in sequence to obtain the corresponding data packet. The network device subsystem calls the driver send interface, and the driver send interface will determine whether the seq of the data packet is the expected value. If it is the expected value, it will be stored in the hardware queue; if it is different from the expected value, it means that the local sent message is out of order, and the out-of-order message will be processed, and the plaintext data will be stored in the send queue in order. The hardware (such as a DPU or an intelligent network card equipped with a hardware encryption and decryption chip) will encrypt the plaintext according to the encryption suite written in the TLS handshake stage and then send the message.

[0090] Receiving process, as Figure 4As shown in the figure, when a data packet arrives at the hardware (such as a DPU or smart network card equipped with a hardware encryption and decryption chip), the hardware matches the TLS data packet according to the flow table, calls the encryption and decryption chip to decrypt the received TLS data packet. After completion, the data packet is written into the memory in the DMA manner, an interrupt is initiated to the CPU, and an interrupt handling function is called to generate a soft interrupt. At this time, the message payload is already in plaintext. The soft interrupt calls the poll function to start polling for packet reception. The polling process is divided into a data reception queue and a seq resynchronization queue. The data reception queue is for the received data packets. By reading the hardware data, it is judged whether decryption has been performed. If decryption has been performed, the decryption flag bit is set. If not, it means the message has arrived out of order, and the resynchronization seq flag bit is set. The seq that needs to be decrypted by software and redelivered to the hardware for continued decryption is processed, and after completion, the message data is sent to the kernel protocol stack for processing. If there is data in the seq resynchronization queue, the decryption parameters need to be reset to the hardware. The kernel protocol stack processes it and sends the message data to the ULP framework for processing. The ULP framework TLS processing function is called to judge the decryption flag bit set in the driver. If not decrypted, software or the hardware chip can be called for decryption. Since the AES-GCM and SM4-GCM algorithms have integrity checks, this process needs to re-encrypt and decrypt the previously decrypted messages before the same TLS record of this message to ensure the integrity of the decrypted data. The plaintext skb is converted into a msg and provided to the user application, such as OpenSSL / Nginx.

[0091] In the embodiments of the present disclosure, first, by using kTLS, the data transfer between the user space and the inner space of the common TLS method can be reduced; second, the offloading scheme is in the inline manner, and the DPU or smart network card does not need to cache the message, reducing resource occupation and latency; third, the TCP protocol seq resynchronization mechanism can be implemented to ensure that the hardware encryption and decryption module can correctly process the encryption and decryption of out-of-order messages.

[0092] Figure 5 It is a schematic structural diagram of a data transmission device based on KTLS provided by the embodiments of the present disclosure. The data transmission device based on KTLS can be understood as the above-mentioned sending end or some functional modules in the above-mentioned sending end. As Figure 5 shown, the data transmission device based on KTLS includes:

[0093] A first calling module 510, configured to, when the application process completes the TLS handshake, through the application process, call a first preset interface to send message data to the ULP framework, and call a second preset interface to send a cipher suite to the hardware encryption and decryption module;

[0094] A first storing module 520, configured to, through the ULP framework, create a data structure and store the message data in the data structure;

[0095] The first encapsulation module 530 is configured to extract the packet data from the data structure through a protocol stack, and perform encapsulation processing on the packet data to obtain a corresponding data packet;

[0096] The second storage module 540 is configured to store the data packet into a transmission queue through a network device subsystem;

[0097] The third storage module 550 is configured to extract the data packet from the transmission queue through a driver and store the data packet into a hardware queue;

[0098] The first encryption module 560 is configured to extract the data packet from the hardware queue through the hardware encryption and decryption module, and perform encryption processing on the data packet based on the cipher suite.

[0099] Optionally, the third storage module 550 is specifically configured to extract the data packet from the transmission queue through a driver;

[0100] Determine whether the seq of the data packet is an expected value;

[0101] If the seq of the data packet is an expected value, store the data packet into the hardware queue;

[0102] If the seq of the data packet is not an expected value, determine that the data packet is out of order, reorder all the data packets corresponding to the message to which the data packet belongs to update its seq, and re-store all the data packets corresponding to the message to which the data packet belongs into the transmission queue in the re-ordered order.

[0103] The device provided in this embodiment can execute the method of any of the above embodiments, and its execution manner and beneficial effects are similar, which will not be elaborated here.

[0104] Figure 6 It is a schematic structural diagram of a data transmission device based on KTLS provided by an embodiment of the present disclosure. The data transmission device based on KTLS can be understood as the above receiving end or some functional modules in the above receiving end. As Figure 6 shown, the data transmission device based on KTLS includes:

[0105] The first decryption module 610 is configured to perform decryption processing on the data packet based on the cipher suite through a hardware encryption and decryption module when the received data packet is a TLS data packet, wherein the processed data packet is written into the memory;

[0106] The first transmission module 620 is configured to extract the processed data packet from the memory through a driver and transmit the processed data packet to a protocol stack;

[0107] The first sending module 630 is configured to perform decapsulation processing on the processed data packet through a protocol stack to obtain corresponding message data, and send the message data to the ULP framework;

[0108] The second sending module 640 is configured to send the message data to a corresponding application process through the ULP framework.

[0109] Optionally, the first transmission module 620 is specifically configured to take out the processed data packet from the memory through a driver, and add the processed data packet to a data reception queue;

[0110] Determine whether the processed data packet has been decrypted;

[0111] If the processed data packet has been decrypted, set a decryption flag bit for the processed data packet, and transmit the processed data packet to the protocol stack;

[0112] If the processed data packet has not been decrypted, determine that the processed data packet is out of order, set a re-synchronization seq flag bit for the processed data packet, add the processed data packet to a seq re-synchronization queue, update the seq of the processed data packet in the seq re-synchronization queue, and send the updated seq to the hardware encryption / decryption module, so that the hardware encryption / decryption module re-decrypts the processed data packet in the seq re-synchronization queue.

[0113] Optionally, it further includes: a first reset module, configured to re-set corresponding decryption parameters to the hardware encryption / decryption module if the seq re-synchronization queue includes the processed data packet.

[0114] Optionally, the second sending module 640 is specifically configured to determine whether the message data has a decryption flag bit through the ULP framework;

[0115] If the message data has a decryption flag bit, send the message data to the corresponding application process;

[0116] If the message data does not have a decryption flag bit, perform decryption processing on the message data through a bypass call mode, and re-encrypt and then re-decrypt the message data before the message data that belongs to the same TLS record as the message data.

[0117] The device provided in this embodiment can execute the method of any of the above embodiments, and its execution manner and beneficial effects are similar, which will not be elaborated here.

[0118] Embodiments of the present disclosure also provide an electronic device, which includes: a memory storing a computer program; and a processor configured to execute the computer program, and when the computer program is executed by the processor, the methods of any of the above embodiments can be implemented.

[0119] Exemplarily, Figure 7 is a schematic structural diagram of an electronic device in embodiments of the present disclosure. Specifically, with reference to Figure 7 , which shows a schematic structural diagram of an electronic device 700 suitable for implementing embodiments of the present disclosure. The electronic device 700 in embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Tablet Computers), PMPs (Portable Multimedia Players), in-vehicle terminals (such as in-vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 7 The electronic device shown is only an example and should not impose any limitation on the functions and usage scope of embodiments of the present disclosure.

[0120] As Figure 7 shown, the electronic device 700 may include a processing device (such as a central processing unit, a graphics processing unit, etc.) 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage device 708 into a random access memory (RAM) 703. In the RAM 703, various programs and data required for the operation of the electronic device 700 are also stored. The processing device 701, the ROM 702, and the RAM 703 are connected to each other through a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0121] Generally, the following devices may be connected to the I / O interface 705: an input device 706 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 707 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 708 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 709. The communication device 709 can allow the electronic device 700 to communicate with other devices wirelessly or wiredly to exchange data. Although Figure 7 the electronic device 700 with various devices is shown, it should be understood that it is not required to implement or include all the shown devices. More or fewer devices may be alternatively implemented or included.

[0122] In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, an embodiment of the present disclosure includes a computer program product that includes a computer program carried on a non-transitory computer-readable medium, and the computer program includes program code for performing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device 709, or installed from a storage device 708, or installed from a ROM 702. When the computer program is executed by a processing device 701, the above-described functions defined in the methods of the embodiments of the present disclosure are performed.

[0123] It should be noted that the above-mentioned computer-readable medium in the present disclosure can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of a computer-readable storage medium can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium can be any tangible medium that contains or stores a program, and the program can be used by or in combination with an instruction execution system, apparatus, or device. In the present disclosure, a computer-readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, and the computer-readable signal medium can send, propagate, or transmit a program for use by or in combination with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted by any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0124] In some embodiments, the client and the server can communicate using any currently known or future-developed network protocol such as HTTP (HyperText Transfer Protocol), and can be interconnected with digital data communication in any form or medium (e.g., a communication network). Examples of communication networks include local area networks ("LANs"), wide area networks ("WANs"), the Internet (e.g., the Internet), and end-to-end networks (e.g., ad hoc end-to-end networks), as well as any currently known or future-developed networks.

[0125] The above computer-readable medium can be included in the above electronic device; or it can exist separately and not be assembled into the electronic device.

[0126] The above computer-readable medium carries one or more programs. When the above one or more programs are executed by the electronic device, the electronic device is caused to: in the case where the application process completes the TLS handshake, through the application process, call a first preset interface to send message data to the ULP framework, and call a second preset interface to send a cipher suite to the hardware encryption / decryption module; through the ULP framework, create a data structure and store the message data in the data structure; through the protocol stack, take out the message data from the data structure and perform encapsulation processing on the message data to obtain a corresponding data packet; through the network device subsystem, store the data packet in the send queue; through the driver, take out the data packet from the send queue and store the data packet in the hardware queue; through the hardware encryption / decryption module, take out the data packet from the hardware queue and perform encryption processing on the data packet based on the cipher suite. Or, when the above one or more programs are executed by the electronic device, the electronic device is caused to: through the hardware encryption / decryption module, in the case where the received data packet is a TLS data packet, perform decryption processing on the data packet based on the cipher suite, where the processed data packet is written into the memory; through the driver, take out the processed data packet from the memory and transmit the processed data packet to the protocol stack; through the protocol stack, perform de-encapsulation processing on the processed data packet to obtain a corresponding message data and send the message data to the ULP framework; through the ULP framework, send the message data to the corresponding application process.

[0127] Computer program code for performing the operations of this disclosure may be written in one or more programming languages or combinations thereof. The foregoing programming languages include, but are not limited to, object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or alternatively, may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0128] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, a segment of a program, or a part of code that contains one or more executable instructions for implementing a specified logical function. It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur in an order different from that noted in the drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, or they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or by a combination of dedicated hardware and computer instructions.

[0129] The units involved in the embodiments described in this disclosure may be implemented in software or in hardware. Wherein, the name of the unit does not constitute a limitation to the unit itself in some cases.

[0130] The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGA), application specific integrated circuits (ASIC), application specific standard products (ASSP), system on a chip (SOC), complex programmable logic devices (CPLD), and so on.

[0131] In the context of the present disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium would include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0132] Embodiments of the present disclosure also provide a computer-readable storage medium storing a computer program which, when executed by a processor, can implement the method of any of the foregoing embodiments. Their execution manners and beneficial effects are similar and will not be elaborated herein.

[0133] It should be noted that, in this document, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover a non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or device. Without further limitation, an element defined by the phrase "comprising a..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0134] The above are only specific embodiments of the present disclosure, enabling those skilled in the art to understand or implement the present disclosure. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure will not be limited to the embodiments described herein, but rather will be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A data transmission method based on kTLS, characterized in that: Applied to a transmitting end, wherein the method comprises: When the application process completes the TLS handshake, calling the first preset interface to send message data to the ULP framework through the application process, and calling the second preset interface to send the cipher suite to the hardware encryption and decryption module; Creating a data structure through the ULP framework, and storing the message data in the data structure; The message data is taken out from the data structure through the protocol stack, and the message data is encapsulated to obtain a corresponding data packet; By means of a network device subsystem, storing the data packet into a sending queue; By means of a driver, taking the data packet from the sending queue and storing the data packet into a hardware queue; The data packet is taken out from the hardware queue through the hardware encryption and decryption module, and the data packet is encrypted based on the cipher suite.

2. The method according to claim 1, characterized in that The step of storing the data packet in a hardware queue comprises: Determine whether the seq of the data packet is an expected value; If the seq of the data packet is an expected value, storing the data packet in the hardware queue; If the seq of the data packet is not the expected value, it is determined that the data packet is out of order, all data packets corresponding to the message to which the data packet belongs are reordered to update their seq, and all data packets corresponding to the message to which the data packet belongs are re-stored into the sending queue in the reordered order.

3. A data transmission method based on kTLS, characterized in that: Applied to the receiving end, the method includes: By means of the hardware encryption and decryption module, when the received data packet is a TLS data packet, the data packet is decrypted based on the cipher suite, wherein the processed data packet is written into the memory; By driving, taking the processed data packet out from the memory, and transmitting the processed data packet to the protocol stack; Decapsulating the processed data packet to obtain corresponding message data through the protocol stack, and sending the message data to the ULP framework; The message data is sent to the corresponding application process through the ULP framework.

4. The method according to claim 3, characterized in that The step of taking the processed data packet out of the memory and transmitting the processed data packet to the protocol stack includes: Taking the processed data packet out from the memory and adding the processed data packet to a data receiving queue; Determining whether the processed data packet has been decrypted; If the processed data packet has been decrypted, setting a decryption flag bit for the processed data packet, and transmitting the processed data packet to the protocol stack; If the processed data packet is not decrypted, it is determined that the processed data packet is out of order, a resynchronization seq flag is set for the processed data packet, the processed data packet is added to a seq resynchronization queue, the seq of the processed data packet in the seq resynchronization queue is updated, and the updated seq is sent to the hardware encryption and decryption module, so that the hardware encryption and decryption module re-decrypts the processed data packet in the seq resynchronization queue.

5. The method according to claim 4, characterized in that Also includes: If the seq resynchronization queue includes the processed data packet, the corresponding decryption parameters are reset to the hardware encryption and decryption module.

6. The method according to claim 3, characterized in that The sending of the message data to the corresponding application process includes: Determining whether the message data has a decryption flag bit; If the message data has a decryption mark bit, sending the message data to the corresponding application process; If the message data does not have a decryption mark bit, the message data is decrypted through a bypass call mode, and the message data before the message data and belonging to the same TLS record as the message data is re-encrypted and then re-decrypted.

7. A data transmission device based on KTLS, characterized in that: Applied to a transmitting end, wherein the device comprises: A first calling module is used to call a first preset interface to send message data to a ULP framework through the application process when the application process completes the TLS handshake, and call a second preset interface to send a cipher suite to a hardware encryption and decryption module; A first storage module, used for creating a data structure through the ULP framework, and storing the message data in the data structure; A first encapsulation module, used to take out the message data from the data structure through a protocol stack, and encapsulate the message data to obtain a corresponding data packet; A second storage module, used for storing the data packet into a sending queue through a network device subsystem; A third storage module, used for taking out the data packet from the sending queue and storing the data packet into a hardware queue through a driver; The first encryption module is used to take out the data packet from the hardware queue through the hardware encryption and decryption module, and encrypt the data packet based on the cipher suite.

8. A data transmission device based on KTLS, characterized in that: Applied to a receiving end, wherein the device comprises: A first decryption module, configured to decrypt the received data packet based on the cipher suite through the hardware encryption and decryption module when the received data packet is a TLS data packet, wherein the processed data packet is written into the memory; A first transmission module, configured to fetch the processed data packet from the memory through a driver, and transmit the processed data packet to a protocol stack; A first sending module, configured to decapsulate the processed data packet through a protocol stack to obtain corresponding message data, and send the message data to a ULP framework; The second sending module is used to send the message data to the corresponding application process through the ULP framework.

9. An electronic device, characterized in that: include: A processor and a memory, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images