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

Abstract

The method comprises the following steps: in the case that a TLS handshake of an application program process is completed, the application program process is used to call a first preset interface to send message data to a ULP framework, and a second preset interface is called to send a cipher suite to a hardware encryption and decryption module; the ULP framework is used to create a data structure, and the message data is stored in the data structure; a protocol stack is used to take the message data from the data structure, and the message data is encapsulated to obtain a corresponding data packet; a network device subsystem is used to store the data packet in a sending queue; a driver is used to take the data packet from the sending queue and store the data packet in a hardware queue; and the hardware encryption and decryption module is used to take the data packet from the hardware queue and encrypt the data packet based on the cipher suite.

Description

Technical Field

[0001] This disclosure relates to the field of data transmission technology, and in particular to a data transmission method, apparatus, device, and storage medium based on kTLS. Background Technology

[0002] With the rapid development of the internet, traditional HTTP protocol transmission methods face various threats in practical applications, such as data leakage. If in an untrusted network, data packets passing through intermediate nodes may be subject to interference from man-in-the-middle attacks, such as eavesdropping, tampering, or replaying. Therefore, the HTTPS protocol adds encryption mechanisms like SSL or TLS to HTTP to achieve data encryption and user authentication. TLS is a widely used encryption protocol, typically implemented in user space using OpenSSL or NGINX. To improve performance, Kernel TLS (kTLS) was developed. kTLS moves encryption and decryption from user space to kernel space, reducing the back-and-forth data transfer between user and kernel spaces and improving overall data transmission efficiency.

[0003] However, existing kTLS implementations are mainly based on software encryption / decryption libraries or hardware encryption / decryption chips, with encryption and decryption using a bypass call mode, and their performance still needs improvement. Summary of the Invention

[0004] To address or at least partially address the aforementioned technical problems, this disclosure provides a KTLS-based data transmission method, apparatus, device, and storage medium.

[0005] A first aspect of this disclosure provides a KTLS-based data transmission method applied at a sending end, wherein the method includes:

[0006] Once the application process completes the TLS handshake, the application process calls the first preset interface to send message data to the ULP framework and calls the second preset interface to send cipher suites to the hardware encryption / decryption module.

[0007] A data structure is created using the ULP framework, and the message data is stored in the data structure.

[0008] The message data is extracted from the data structure using the protocol stack, and the message data is encapsulated to obtain the corresponding data packet.

[0009] The data packets are stored in the sending queue through the network device subsystem;

[0010] The data packet is retrieved from the sending queue and stored in the hardware queue by the driver;

[0011] The hardware encryption / decryption module retrieves the data packet from the hardware queue and encrypts it based on the cipher suite.

[0012] A second aspect of this disclosure provides a KTLS-based data transmission method applied at a receiving end, the method comprising:

[0013] The hardware encryption / decryption module decrypts the received data packet (TLS packet) based on a cipher suite, and then writes the decrypted data packet into memory.

[0014] The driver retrieves the processed data packet from the memory and transmits it to the protocol stack.

[0015] The processed data packets are decapsulated using the protocol stack to obtain the corresponding message data, and the message data is sent to the ULP framework.

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

[0017] A third aspect of this disclosure provides a KTLS-based data transmission apparatus applied at a sending end, wherein the apparatus includes:

[0018] The first calling module is used to send message data to the ULP framework by calling the first preset interface through the application process after the application process completes the TLS handshake, and to send cipher suites to the hardware encryption and decryption module by calling the second preset interface.

[0019] The first storage module is used to create a data structure through the ULP framework and store the message data into the data structure.

[0020] The first encapsulation module is used to extract the message data from the data structure through the protocol stack and encapsulate the message data to obtain the corresponding data packet.

[0021] The second storage module is used to store the data packet into the sending queue through the network device subsystem;

[0022] The third storage module is used to retrieve the data packet from the sending queue and store the data packet into the hardware queue via a driver;

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

[0024] A fourth aspect of this disclosure provides a KTLS-based data transmission apparatus for use at a receiving end, wherein the apparatus includes:

[0025] The first decryption module is used to decrypt the received data packet based on a cipher suite using a hardware encryption / decryption module when the data packet is a TLS data packet, wherein the processed data packet is written into memory;

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

[0027] The first sending module is used to decapsulate 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 used to send the message data to the corresponding application process through the ULP framework.

[0029] A third aspect of this disclosure provides an electronic device, the server comprising: a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the method of the first aspect described above.

[0030] A fourth aspect of this disclosure provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the method of the first aspect described above.

[0031] The technical solution provided in this disclosure has the following advantages compared with the prior art:

[0032] This embodiment of the disclosure enables the application process to send message data to the ULP framework and send a cipher suite to the hardware encryption / decryption module via a first preset interface and a second preset interface, respectively, after completing the TLS handshake. The ULP framework creates a data structure and stores the message data within it. The protocol stack retrieves the message data from the data structure and encapsulates it to obtain the corresponding data packet. The network device subsystem stores the data packet in a transmission queue. The driver retrieves the data packet from the transmission queue and stores it in a hardware queue. The hardware encryption / decryption module retrieves the data packet from the hardware queue and encrypts it based on the cipher suite. Therefore, this embodiment of the disclosure utilizes the hardware encryption / decryption module to implement encryption in an inline manner, thereby improving encryption performance. Attached Figure Description

[0033] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0034] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This is a flowchart of a KTLS-based data transmission method provided in an embodiment of this disclosure;

[0036] Figure 2 This is a flowchart of a KTLS-based data transmission method provided in an embodiment of this disclosure;

[0037] Figure 3 This is a flowchart illustrating a KTLS-based data transmission process provided in an embodiment of this disclosure;

[0038] Figure 4 This is a flowchart illustrating a KTLS-based data reception process provided in an embodiment of this disclosure;

[0039] Figure 5 This is a schematic diagram of the structure of a KTLS-based data transmission device provided in an embodiment of this disclosure;

[0040] Figure 6 This is a schematic diagram of the structure of a KTLS-based data transmission device provided in an embodiment of this disclosure;

[0041] Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of this disclosure. Detailed Implementation

[0042] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0043] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0044] Figure 1 This is a flowchart illustrating a KTLS-based data transmission method provided in this disclosure, which can be executed by a sending end. The sending end can be exemplarily understood as a device such as a server or desktop computer running Linux. KTLS, or Kernel TLS (Transport Layer Security), is a feature of the Linux kernel designed to improve the performance of TLS (Transport Layer Security) connections. Traditional TLS connections are processed in user space, while Kernel TLS moves some or all of the TLS processing to the kernel, thereby reducing context switching between user space and kernel space and improving performance.

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

[0046] S110. After the application process completes the TLS handshake, the application process calls the first preset interface to send message data to the ULP framework and calls the second preset interface to send cipher suites to the hardware encryption / decryption module.

[0047] Specifically, once the TLS handshake is completed, the sender and receiver agree on how to communicate securely, including cipher suites, etc.

[0048] Specifically, application processes can include, but are not limited to, OpenSSL or Nginx processes. OpenSSL is an open-source software library that provides support for various encryption algorithms and protocols, primarily used for secure communication. It is widely used in various applications requiring encryption, including but not limited to web servers, mail servers, and virtual private networks (VPNs). Nginx is a high-performance HTTP and reverse proxy server, 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, which in turn can call the sendto interface to send message data to the ULP framework. Furthermore, the application process can call the setsockopt interface to send cipher suites to the hardware encryption / decryption module.

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

[0051] Specifically, the User-Level Protocol (ULP) allows applications to enable and manage upper-layer application protocols for TCP through standard interfaces provided by the kernel. This enables the insertion of custom processing logic 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. This new sendmsg interface performs TLS processing on the message data. Thus, when the sendto interface calls the new sendmsg interface, the message data can enter the kernel space. The kernel detects that kTLS has been enabled and performs TLS processing on the message data. This TLS processing includes creating a data structure (such as a linked list) and storing the message data in the data structure for processing by the protocol stack.

[0052] S130. The message data is extracted from the data structure through the protocol stack, and the message data is encapsulated to obtain the corresponding data packet.

[0053] Specifically, the TCP layer in the protocol stack takes over the message data, segments it into segments of the maximum size suitable for transmission, and adds header information such as sequence number and acknowledgment number to each segment to ensure reliable data transmission. After processing by the TCP layer, the data is handed over to the IP layer, which adds IP header information to each segment and determines the best routing path. Then, it reaches the data link layer, where appropriate frame headers and trailers are added to obtain the data packet. However, this process is not limited to this step.

[0054] S140. The data packet is stored in the sending queue through the network device subsystem.

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

[0056] S150: Through the driver, data packets are retrieved from the transmission queue and stored in the hardware queue.

[0057] In some embodiments, storing data packets into a hardware queue includes: determining whether the sequence number (seq) of the data packet is the expected value;

[0058] If the sequence number (seq) of the data packet is the expected value, then the data packet is stored in the hardware queue.

[0059] If the sequence number (seq) of a data packet is not the expected value, the data packet is determined to be 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.

[0060] Specifically, when a data packet is ready to be sent, the driver (i.e., the network device driver) is invoked to actually send the data. The driver can check the sequence number (seq) of the data packet to ensure that the data packets are sent in the correct order. Specifically, if the seq is the expected value, the data packet is stored in the hardware queue, ready for transmission; if the seq is not the 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 data packets corresponding to the same message to arrive, then reorder them, and store all data packets corresponding to the same message in the transmission queue in the reordered order. In this way, these data packets can be successfully stored in the hardware queue, ready for transmission.

[0061] Understandably, by synchronizing the TCP protocol's sequence number (seq), it can be ensured that the hardware encryption / decryption module can correctly handle out-of-order message encryption.

[0062] Of course, in other embodiments, the hardware encryption / decryption chip can be mounted on the DPU or smart network interface card (NIC). If the DPU or smart NIC supports GSO and GRO functions, it can perform fragmentation on excessively long packet data. In this way, for packet data that needs to be fragmented, there is no need to synchronize the TCP protocol's sequence number (seq); the ciphertext is encrypted first and then fragmented during the transmission phase.

[0063] S160. The data packet is retrieved from the hardware queue through the hardware encryption / decryption module, and the data packet is encrypted based on the cipher suite.

[0064] Specifically, hardware encryption / decryption modules (such as hardware encryption / decryption chips) can use symmetric encryption / decryption methods to encrypt data packets, but are not limited to this.

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

[0066] In this embodiment, data transfer between user space and kernel space is implemented based on application processes (such as OpenSSL or Nginx) in user space, the kTLS call logic is implemented based on the ULP framework in kernel space, and encryption processing is implemented inline using a DPU or smart network card equipped with hardware encryption / decryption chips, thereby improving encryption performance.

[0067] Figure 2 This is a flowchart illustrating a KTLS-based data transmission method provided in this disclosure, which can be executed by a receiving end. The receiving end can be exemplarily understood as a device such as a server or desktop computer running Linux. Figure 2 As shown, the method provided in this embodiment includes the following steps:

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

[0069] Specifically, the flow table in the DPU or smart NIC can be configured to identify TLS traffic. When a data packet is received from the network, the DPU or smart NIC can check if the received packet matches the characteristics of a TLS message. If a match is found, the packet is marked as a TLS packet. If the received packet is a TLS packet, the hardware encryption / decryption module in the DPU or smart NIC can decrypt the packet based on cipher suites and write the processed packet to memory using methods such as DMA (Direct Memory Access). Using DMA reduces the CPU load and improves data transmission efficiency. The hardware encryption / decryption module can use symmetric encryption / decryption to decrypt the received data packet, but it is not limited to this method.

[0070] S220: The driver retrieves the processed data packet from memory and transmits it to the protocol stack.

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

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

[0073] If the processed data packet has been decrypted, set the 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. The resynchronization seq flag 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 and decryption module so that the hardware encryption and decryption module can re-decrypt the processed data packet in the seq resynchronization queue.

[0075] Specifically, when the DMA operation is complete, the DPU or smart network card initiates a hardware interrupt to the CPU, notifying the CPU that a new processed data packet has arrived, and calls the interrupt handler to generate a software interrupt. The software interrupt calls the receive processing function (e.g., the poll function) to start polling for packets. Specifically, it checks if a new processed data packet has arrived in the pre-allocated memory. If a new processed data packet has arrived, it retrieves the processed data packet from the pre-allocated memory and adds it to the data receive queue. It checks whether the processed data packet has been decrypted by the hardware encryption / decryption chip. If it has been decrypted, a decryption flag is set. If it has not been decrypted, it indicates that the data packet may have arrived out of order, so a resynchronization seq flag is set, and the undeniable processed data packet is placed in the seq resynchronization queue. To ensure that subsequent processed data packets can be decrypted correctly, the driver updates the seq of the processed data packets 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, the decrypted processed data packet is placed in the data receive queue, and the processed data packets in the data receive queue are passed to the kernel protocol stack for further processing.

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

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

[0078] It is understandable that when there is data in the seq resynchronization queue, it means that previously processed data packets did not arrive in order, and the state of the hardware encryption and decryption module needs to be reset. The driver will reset the correct decryption parameters to the hardware encryption and decryption module to ensure that it can be decrypted correctly.

[0079] Of course, in other embodiments, the hardware encryption / decryption chip can be mounted on the DPU or smart network interface card (NIC). If the DPU or smart NIC supports GSO and GRO functions, it can aggregate multiple fragmented data packets into a large packet and then pass it to the protocol stack for processing. In this way, for packet data that needs to be fragmented, there is no need to synchronize the TCP protocol's sequence number (seq). During the receiving phase, the fragmented packets will be reassembled before decryption.

[0080] S230. Through the protocol stack, the processed data packet is decapsulated to obtain the corresponding message data, and the message data is sent to the ULP framework.

[0081] Specifically, the link layer, IP layer, and TCP layer in the protocol stack process the data packets sequentially to obtain the corresponding message data. Then, the message data is sent to the ULP framework for further processing.

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

[0083] Optionally, the message data is sent to the corresponding application process, including: determining whether the message data has a decryption flag bit;

[0084] If the message data has a decryption flag, the message data will be sent to the corresponding application process.

[0085] If the message data does not have a decryption flag, the message data is decrypted through a bypass call mode. The message data that belongs to the same TLS record as the message data is re-encrypted and then re-decrypted.

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

[0087] In this embodiment, the received data packets are first decrypted using a DPU or smart network card equipped with a hardware encryption / decryption chip, and then further processed by the decrypted data packets through drivers, protocol stacks, ULP frameworks, etc. In this way, decryption processing can be implemented in an inline manner, thereby improving decryption performance.

[0088] The following detailed explanation of the KTLS-based data transmission method provided in this disclosure embodiment, using a specific example, illustrates this method. This disclosure embodiment requires a TLS handshake process at the application layer. During this process, TLS version information, encryption / decryption algorithms, and key information are negotiated and generated. After completion, this information is sent to the hardware encryption / decryption module via the setsockopt interface. Subsequent packet payloads require symmetric encryption / decryption, which is offloaded and accelerated through hardware. The TLS hardware offload process is divided into sending and receiving directions, with each direction described in detail.

[0089] Sending process (sender), such as Figure 3 As shown: After the TLS handshake is complete, the user-space application process (such as the OpenSSL process or the Nginx process) calls the send interface, which in turn calls the sendto interface to send the message data. Then, the ULP framework processes the data. After implementing kLS, it replaces the original sendmsg interface with TLS processing, storing the TLS plaintext data (i.e., the message data) in a linked list for processing by the protocol stack. It should be noted that if the subsequent hardware encryption / decryption chip uses the AES-GCM or SM4-GCM encryption / decryption algorithm, padding needs to be added to the data length to ensure the correct length during message fragmentation by the protocol stack, since there will be a checksum after the plaintext data is encrypted. Then, the TCP layer, IP layer, and link layer in the protocol stack process the message data in sequence to obtain the corresponding data packets. The network device subsystem calls the driver send interface. The driver send interface will determine whether the sequence number (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 locally sent message is out of order. 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 smart network card with a hardware encryption / decryption chip) will encrypt the plaintext according to the encryption suite written during the TLS handshake phase before sending the message.

[0090] Receiving process, such as Figure 4As shown, when a data packet arrives at the hardware (e.g., a DPU or smart network card equipped with a hardware encryption / decryption chip), the hardware matches the TLS data packet according to the flow table, calls the encryption / decryption chip to decrypt the received TLS data packet, writes the data packet to memory via DMA, initiates an interrupt to the CPU, and calls the interrupt handler to generate a software interrupt. At this point, the packet payload is already plaintext. The software interrupt calls the poll function to start polling for packets. The polling process is divided into a data receive queue and a seq resynchronization queue. The data receive queue receives the data packets. By reading the hardware data, it is determined whether the packet has been decrypted. If it has been decrypted, a decryption flag is set. If it has not been decrypted, it means the packet arrived out of order, and a resynchronization seq flag is set. The software needs to decrypt the packet and resend the seq for hardware to continue decryption. After processing, the packet 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 the data and sends it to the ULP framework for processing. The ULP framework's TLS processing function is called to check the decryption flag set in the driver. If decryption fails, software or hardware chip encryption can be invoked. Due to integrity checks in AES-GCM and SM4-GCM algorithms, this process requires re-encrypting and then decrypting previously decrypted packets within the same TLS record to ensure the integrity of the decrypted data. The plaintext skb is then converted to msg and provided to the user application, such as OpenSSL / Nginx.

[0091] In this embodiment, kTLS is firstly used to reduce data transfer between user space and internal space in common TLS methods; secondly, the offloading scheme is inline, so the DPU or smart network card does not need to cache packets, reducing resource consumption and latency; and thirdly, the TCP protocol seq resynchronization mechanism can be implemented to ensure that the hardware encryption and decryption module can correctly handle out-of-order packet encryption and decryption.

[0092] Figure 5 This is a schematic diagram of a KTLS-based data transmission device provided in an embodiment of this disclosure. This KTLS-based data transmission device can be understood as the aforementioned sending end or a portion of the functional modules within the aforementioned sending end. For example... Figure 5 As shown, the KTLS-based data transmission device includes:

[0093] The first calling module 510 is used to send message data to the ULP framework by calling the first preset interface through the application process after the application process completes the TLS handshake, and to send cipher suites to the hardware encryption and decryption module by calling the second preset interface.

[0094] The first storage module 520 is used to create a data structure through the ULP framework and store the message data into the data structure;

[0095] The first encapsulation module 530 is used to extract the message data from the data structure through the protocol stack and encapsulate the message data to obtain the corresponding data packet.

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

[0097] The third storage module 550 is used to retrieve the data packet from the sending queue and store the data packet into the hardware queue via a driver.

[0098] The first encryption module 560 is used to retrieve the data packet from the hardware queue through the hardware encryption / decryption module and encrypt the data packet based on the cipher suite.

[0099] Optionally, the third storage module 550 is specifically used to retrieve the data packet from the sending queue via a driver;

[0100] Determine whether the sequence number (seq) of the data packet is the expected value;

[0101] If the sequence number (seq) of the data packet is the expected value, then the data packet is stored in the hardware queue.

[0102] If the sequence number (seq) of the data packet is not the expected value, the data packet is determined to be 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.

[0103] The apparatus provided in this embodiment can execute the methods of any of the above embodiments, and its execution method and beneficial effects are similar, so they will not be described again here.

[0104] Figure 6 This is a schematic diagram of a KTLS-based data transmission device provided in an embodiment of this disclosure. This KTLS-based data transmission device can be understood as the aforementioned receiving end or a portion of the functional modules within the aforementioned receiving end. For example... Figure 6 As shown, the KTLS-based data transmission device includes:

[0105] The first decryption module 610 is used to decrypt the received data packet based on a cipher suite by means of a hardware encryption and decryption module when the data packet is a TLS data packet, wherein the data packet after processing is written into memory;

[0106] The first transmission module 620 is used to retrieve the processed data packet from the memory and transmit the processed data packet to the protocol stack via a driver.

[0107] The first sending module 630 is used to decapsulate the processed data packet through the protocol stack to obtain the corresponding message data, and send the message data to the ULP framework;

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

[0109] Optionally, the first transmission module 620 is specifically used to retrieve the processed data packet from the memory and add the processed data packet to the data receiving queue via a driver;

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

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

[0112] 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 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 and decryption module so that the hardware encryption and decryption module can re-decrypt the processed data packet in the seq resynchronization queue.

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

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

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

[0116] If the message data does not have a decryption flag, the message data is decrypted through a bypass call mode, and the message data preceding the message data that belongs to the same TLS record as the message data is re-encrypted and then re-decrypted.

[0117] The apparatus provided in this embodiment can execute the methods of any of the above embodiments, and its execution method and beneficial effects are similar, so they will not be described again here.

[0118] This disclosure also provides an electronic device, which includes: a memory storing a computer program; and a processor for executing the computer program, wherein when the computer program is executed by the processor, it can implement the methods of any of the above embodiments.

[0119] Example, Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of this disclosure. See below for details. Figure 7 The diagram illustrates a structural schematic suitable for implementing the electronic device 700 in the embodiments of this disclosure. The electronic device 700 in the embodiments of this disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0120] like Figure 7 As shown, the electronic device 700 may include a processing unit (e.g., a central processing unit, a graphics processor, 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. The RAM 703 also stores various programs and data required for the operation of the electronic device 700. The processing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0121] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 708 including, for example, magnetic tapes, hard disks, etc.; and communication devices 709. Communication device 709 allows electronic device 700 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 7 An electronic device 700 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

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

[0123] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. 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 thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0124] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0125] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0126] The aforementioned computer-readable medium carries one or more programs. When the electronic device executes one or more of these programs, the electronic device causes the following: Upon completion of a TLS handshake by the application process, the application process calls a first preset interface to send message data to the ULP framework and calls a second preset interface to send a cipher suite to the hardware encryption / decryption module; the ULP framework creates a data structure and stores the message data in the data structure; the protocol stack retrieves the message data from the data structure and encapsulates the message data to obtain a corresponding data packet; the network device subsystem stores the data packet in a transmission queue; the driver retrieves the data packet from the transmission queue and stores the data packet in a hardware queue; and the hardware encryption / decryption module retrieves the data packet from the hardware queue and encrypts the data packet based on the cipher suite. Alternatively, when one or more of the above programs are executed by the electronic device, the electronic device may: use a hardware encryption / decryption module to decrypt the received data packet based on a cipher suite if the data packet is a TLS data packet, wherein the processed data packet is written into memory; use a driver to retrieve the processed data packet from memory and transmit the processed data packet to the protocol stack; use the protocol stack to decapsulate the processed data packet to obtain the corresponding message data and send the message data to the ULP framework; and use the ULP framework to send the message data to the corresponding application process.

[0127] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via 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 this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in 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 using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0129] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the units are not, in some cases, intended to limit the specific unit.

[0130] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0131] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, 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 machine-readable storage media 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 fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0132] This disclosure also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the methods of any of the above embodiments. The execution method and beneficial effects are similar, and will not be described again here.

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

[0134] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A kTLS-based data transmission method, characterized in that, Applied to a sending end, the method comprises: In the case that an application process completes a TLS handshake, the application process is used to call a first preset interface to send message data to a ULP framework and call a second preset interface to send a cipher suite to a hardware encryption and decryption module; The ULP framework is used to create a data structure and store the message data in the data structure; The protocol stack is used to take the message data from the data structure and perform encapsulation processing on the message data to obtain a corresponding data packet; The network device subsystem is used to store the data packet in a sending queue; The driver is used to take the data packet from the sending queue and store the data packet in a hardware queue; The hardware encryption and decryption module is used to take the data packet from the hardware queue and perform encryption processing on the data packet based on the cipher suite.

2. The method of claim 1, wherein, The storing of the data packet in the hardware queue comprises: determining whether the seq of the data packet is an expected value; if the seq of the data packet is the expected value, storing the data packet in the hardware queue; if the seq of the data packet is not the expected value, determining that the data packet is out of order, reordering all data packets corresponding to a message to which the data packet belongs to update the seq, and re-storing all data packets corresponding to the message in the sending queue in the order after reordering.

3. A kTLS-based data transmission method, characterized by, Applied to a receiving end, the method comprises: the hardware encryption and decryption module is used to, in the case that a received data packet is a TLS data packet, perform decryption processing on the data packet based on a cipher suite, wherein the processed data packet is written into a memory; the driver is used to take the processed data packet from the memory and transmit the processed data packet to a protocol stack; the protocol stack is used to perform unpacking processing on the processed data packet to obtain corresponding message data and send the message data to a ULP framework; the ULP framework is used to send the message data to a corresponding application process.

4. The method of claim 3, wherein, The taking of the processed data packet from the memory and the transmission of the processed data packet to the protocol stack comprises: the processed data packet is taken from the memory and added to a data receiving queue; it is determined whether the processed data packet has been decrypted; if the processed data packet has been decrypted, a decryption flag bit is set for the processed data packet, and the processed data packet is transmitted to the protocol stack; if the processed data packet has not been decrypted, it is determined that the processed data packet is out of order, a re-synchronization seq flag bit is set for the processed data packet, the processed data packet is added to a seq re-synchronization queue, the seq of the processed data packet in the seq re-synchronization 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-performs decryption processing on the processed data packet in the seq re-synchronization queue.

5. The method of claim 4, wherein, Further comprising: if the seq re-synchronization queue includes the processed data packet, corresponding decryption parameters are re-set to the hardware encryption and decryption module.

6. The method of claim 3, wherein, The sending the message data to the corresponding application process comprises: determining whether the message data has a decryption mark bit; if the message data has the decryption mark bit, sending the message data to the corresponding application process; if the message data does not have the decryption mark bit, performing decryption processing on the message data through a bypass calling mode, and re-performing encryption processing and then re-performing decryption processing on message data before the message data and belonging to the same TLS record as the message data.

7. A KTLS-based data transmission apparatus, characterized by comprising: The application is applied to a sending end, and the device comprises: a first calling module, configured to, in a case where a TLS handshake is completed by an application process, call a first preset interface to send message data to a ULP framework through the application process, and call a second preset interface to send a cipher suite to a hardware encryption and decryption module; a first storage module, configured to create a data structure through the ULP framework, and store the message data in the data structure; a first packaging module, configured to take out the message data from the data structure through a protocol stack, and perform packaging processing on the message data to obtain a corresponding data packet; a second storage module, configured to store the data packet in a sending queue through a network device subsystem; a third storage module, configured to take out the data packet from the sending queue through a driver, and store the data packet in a hardware queue; a first encryption module, configured to take out 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.

8. A KTLS-based data transmission apparatus, characterized by comprising: The application is applied to a receiving end, and the device comprises: a first decryption module, configured to, in a case where a received data packet is a TLS data packet, perform decryption processing on the data packet based on a cipher suite through a hardware encryption and decryption module, wherein a processed data packet is written into a memory; a first transmission module, configured to take out 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 perform unpacking processing on the processed data packet through the protocol stack to obtain corresponding message data, and send the message data to a ULP framework; a second sending module, configured to send the message data to a corresponding application process through the ULP framework.

9. An electronic device, comprising: The device comprises: a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the method in any one of claims 1-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 in any one of claims 1-6 is implemented.

Images