CN115801405A

CN115801405A - SSL unloading equipment based on ULP framework and working method thereof

Info

Publication number: CN115801405A
Application number: CN202211435931.5A
Authority: CN
Inventors: 卢方勇; 薛坤; 李冠
Original assignee: Shandong Fangcun Microelectronics Technology Co ltd
Current assignee: Shandong Fangcun Microelectronics Technology Co ltd
Priority date: 2022-11-16
Filing date: 2022-11-16
Publication date: 2023-03-14

Abstract

The invention discloses SSL unloading equipment based on an ULP frame and a working method thereof, belonging to the technical field of SSL unloading, wherein the SSL unloading equipment based on the ULP frame comprises a network card NIC network interface, a network protocol analysis module, a cryptographic algorithm unloading module, an equipment operation register interface and a table search module, wherein: the network protocol analysis module is connected with the NIC network interface, the cryptographic algorithm unloading module, the equipment operation register interface and the table searching module; and a network flow management table is arranged in the table lookup module and maintains the corresponding relation between the network flow ID and the SSL session. The invention shows a method for customizing the idea of unloading by utilizing the kernel-state SSL unloading frame through the self-realized SSL unloading equipment, enriches and expands the functions of the kernel with the KTLS module, widens the access of the kernel with the SSL unloading equipment, and can improve the data receiving performance (especially the processing time delay of the network packet).

Description

SSL unloading equipment based on ULP framework and working method thereof

Technical Field

The invention relates to the technical field of SSL (secure socket layer) unloading, in particular to an SSL unloading device based on an ULP (ultra-low-level programming) framework and a working method thereof.

Background

At present, the security attention degree in the network data transmission process is higher and higher, and the wide application of an SSL (Secure Socket Layer) protocol is further promoted. Programming of the SSL protocol is more and more diversified, and the Linux Kernel also provides an optimized framework for the SSL protocol, KTLS (Kernel transport layer security protocol), from a system level. The framework may function as an SSL offload device to some extent, but there is room for improvement in data reception.

The SSL protocol is a widely used protocol for protecting data security during data transmission in network communication. The protocol provides data encryption service through algorithms such as AES (advanced encryption Standard), DES (data encryption Standard), 3DES (triple data encryption Algorithm), SM4 and the like, and provides message authentication service through algorithms such as HASH (Hash), MAC (message authentication code) authentication and the like. The SSL protocol has formed a variety of different protocol versions through continued development and sophistication, including SSL versions that have not been recommended and the latest TLS versions, such as SSLv3, tlsv1.0, tlsv1.1, tlsv1.3, etc. SSL is used herein as a generic term for both old SSL versions and new TLS versions.

OpenSSL is a representative one of many open source kits based on the SSL protocol for general cryptographic computation and network security transmission. The open source toolkit is widely applied to various application scenes based on cryptography and network transmission, but the implementation of the SSL related protocol by the open source toolkit is carried out in a user mode. With the widespread use of the SSL protocol, the Linux kernel directly supports the SSL protocol from the system level and slowly enters kernel community discussions. This implementation is proposed by means of a kernel Layer Protocol (ULP) framework. The ULP framework can be understood as an "arbitrary upper layer" (referring to an application layer, a presentation layer and a session layer) which is tiled above a "transport layer" in an Open System Interconnection (OSI) 7-layer model, so that the ULP framework can be used as a general framework to support the function implementation above the transport layer, which is typically a KTLS module introduced by the Linux kernel 4.14. KTLS does this by putting the process that the original SSL protocol was implemented into the kernel, and can use TLS offload devices for offload acceleration.

The KTLS module implements a core-state SSL Protocol partial function based on a session layer above a Transmission Control Protocol (TCP), and its operation is divided into 3 modes: TLS _ SW, TLS _ HW, and TLS _ HW _ RECORD.

1. TLS _ SW mainly encrypts and decrypts payload of SSL frame data by means of kernel crypto framework.

2. TLS _ HW is mainly a network packet based offload mode. A Network data packet (as shown in fig. 1, including an ethernet header, an IP (internet protocol) header, a TCP header, and a SSL header) encapsulating the SSL frame is processed by a Network protocol stack and then directly sent to a TLS offload device (e.g., a Network Interface Card (NIC)) by a device driver. The mode makes full use of the functions of the kernel network protocol stack, has good compatibility characteristics, and is mainly analyzed and discussed based on the mode.

3. TLS _ HW _ RECORD is mainly a TCP process in which the offload device replaces the kernel, and the SSL protocol process is directly performed, which is not friendly if the management is performed by using the network protocol stack of the kernel.

Disclosure of Invention

The technical problem to be solved by the invention is to provide an SSL unloading device based on an ULP framework and a working method thereof, wherein the SSL unloading device can improve data receiving performance.

In order to solve the technical problems, the invention provides the following technical scheme:

in one aspect, an SSL offload device based on ULP framework is provided, including a network card NIC network interface, a network protocol analysis module, a cryptographic algorithm offload module, a device operation register class interface, and a table lookup module, where:

the network protocol analysis module is connected with the NIC network interface, the cryptographic algorithm unloading module, the equipment operation register interface and the table searching module;

and a network flow management table is arranged in the table lookup module and maintains the corresponding relation between the network flow ID and the SSL session.

On the other hand, the working method of the SSL offload device is provided, and is used for a Linux operating system, where the Linux operating system includes a user mode and a kernel mode, the kernel mode includes a ULP protocol layer, a network protocol stack, and a device driver layer, the ULP protocol layer is provided with a ULP module, and the ULP module works in a TLS _ HW mode, and the working method includes an SSL control message transmission method, and the SSL control message transmission method includes:

step 101: when the user mode communicates with the opposite terminal device, after the two sides complete handshake negotiation based on an SSL protocol, the ULP module receives an encapsulation message of SSL initialization connection parameters from the user mode;

step 102: according to the encapsulation message, the ULP module sends a network flow ID represented by a socket in the SSL and corresponding SSL initialization connection parameters to the SSL unloading equipment;

step 103: and the SSL unloading equipment writes the network flow ID represented by the socket and the corresponding SSL initialization connection parameter into a network flow management table in the table lookup module.

The invention has the following beneficial effects:

according to the SSL uninstalling device based on the ULP frame and the working method thereof, the self-realized SSL uninstalling device is used for showing a method for customizing the kernel-state SSL uninstalling frame and using the device to uninstall, so that the functions of the kernel-state SSL uninstalling frame with the KTLS module are enriched and expanded, the access of the kernel-state SSL uninstalling device is widened, and the data receiving performance (especially the processing time delay of a network packet) can be improved.

Drawings

FIG. 1 is a diagram illustrating a packet format of SSL in each layer of a network in the prior art;

fig. 2 is a schematic flow diagram of an SSL offload device based on ULP framework and its operating method according to the present invention.

Detailed Description

In order to make the technical problems, technical solutions and advantages of the present invention more apparent, the following detailed description is given with reference to the accompanying drawings and specific embodiments.

The improvements herein are pointed out below by analyzing the workflow of the kernel KTLS module.

The SSL protocol overall work flow comprises the following steps: the two communication parties establish socket connection (a typical network communication quintuple uniquely corresponds to a network flow ID (identity identification number), and a special tunnel network and a virtual network are temporarily out of the discussion range), and then perform subsequent transmission operation of application data according to the negotiated secret key after handshake is successful. This is divided into the processing of control messages and application data of the SSL protocol.

For historical reasons, the support degree of the symmetric algorithm in the kernel is far greater than that of the asymmetric algorithm, so that the KTLS module only supports symmetric encryption and decryption processing in the application data transmission process, and control messages are transmitted to the kernel KTLS module by user-mode upper-layer applications (such as OpenSSL/application programs) for indirect use.

1. SSL control message CTRL (control):

the one-to-one correspondence relationship between the Socket-bound quintuple network traffic ID and the key parameter generated by SSL negotiation needs to be transmitted to the KTLS module through the control message, and then is transmitted to the inside of the device for use.

2. SSL application data TX (transmission):

in TLS _ HW mode, the payload encryption/decryption operation of the SSL frame is not processed in ULP layer, but is directly encapsulated by the network protocol stack and then forwarded to the SSL offload device driver, and then the driver constructs a context (bound to specific socket information) labeled with an offload flag, and sends the context together with the network packet to the device for processing and sending.

3. SSL application data RX (receive):

in the TLS _ HW mode, after some TLS offload devices receive a network packet, they try to perform decryption operation, set a flag indicating whether decryption is successful, and then forward the packet to the network protocol stack for processing, and after a network packet (skb (socket buffer) management) in the kernel reaches the ULP protocol layer, the KTLS module performs an operation of handing over data to a user state according to the check of the decryption flag or continuing decryption with the help of the kernel crypto framework. This is mainly because, during reception, there may be network events such as delay or packet loss during transmission of a network data packet, which may result in failure of parsing a TLS protocol frame. Moreover, decryption is performed inside the TLS offload device, which inevitably requires buffering the network packet for a certain time, and increases processing delay of the network packet to a certain extent, which may cause time jitter when a TCP transport layer in the kernel protocol stack processes data.

Based on this, an improved method for TLS device offloading when receiving network packets is proposed, which needs to operate with the TLS offload device specified herein. By using the method, when RX is received, the SSL uninstalling device does not need to perform best effort encryption and decryption operation, but only needs to pay attention to the network data flow ID and report the device internal association session ID (session identifier) to the ULP layer for use, so as to be used when the ULP layer reloads SSL frame data to the device.

In one aspect, the present invention provides an SSL offload device based on ULP framework, as shown in fig. 2, including a network card NIC network interface, a network protocol analysis module, a cryptographic algorithm offload module, a device operation register interface, and a table lookup module, where:

a network traffic management table is arranged in the table lookup module, and the network traffic management table maintains the corresponding relation between the network traffic ID and the SSL session (SSL session).

Preferably, the device operation register interface is a Ring interface; the equipment operation register interface comprises a flow inlet interface and a flow outlet interface, and the flow inlet interface and the flow outlet interface both comprise a control Ring and a data flow Ring.

The following briefly describes the structure of the ULP framework based SSL offload device of the present invention.

In the embodiment shown in the figure, the SSL offload device is named TIH _ DEV _ TLS. The main operation modules of the equipment are as follows:

a) NIC network interface. Can be composed of a plurality of interfaces and is responsible for the sending and receiving operation of network data packets.

b) And a network protocol analysis module. The system can be a TLS network Protocol analysis module, is not limited to analyzing the TLS Protocol, and can be upgraded and supported by expanding IPSec (Internet Protocol Security) and the like; the module can analyze the characteristics of the network data packet, identify the protocols such as the L2/L3/L4 protocol and the TLS of the network, calculate and check the checksum value of the network data packet, call a cryptographic algorithm unloading module and a table searching module according to the analysis result, and also carry out forwarding operation according to different data streams.

c) And a cryptographic algorithm unloading module. And a common cryptographic algorithm calculation unloading acceleration function is provided, such as common algorithms of AES/3DES/SM4, SHA1/SHA2/SM3, GCM AEAD and the like.

d) The device operation register interface may be specifically Ring queue interface. Each Ring is implemented by a fifo Queue managed by a lock-free mechanism. The kernel driver may communicate with the TIH _ DEV _ TLS through this interface. Ring can be divided into Ingress (Ingress Ring, i.e., TX Ring) and Egress (Egress Ring, i.e., RX Ring) traffic. However, for the consideration of the traffic classification and the response priority, it is preferable to classify into two categories, i.e., control Ring (1 Ring each of Queue _ ctrl, ingress/Egress) and data stream Ring (Ring rings of Queue _ dpM, ingress/Egress).

e) And a table lookup module. This module manages the network traffic management table. The table maintains the correspondence between the network traffic ID and the SSL session. The network traffic involved in this document is divided into three categories, TX _ NET _ PKG (network packet transmission), RX _ NET _ PKG (network packet reception), and RX _ TLS _ PKG (SSL packet transmission).

When the TIH _ DEV _ TLS device TX transmits, the data stream is in the TX _ NET _ PKG phase;

when the TIH _ DEV _ TLS RX device receives a data stream, the data stream is in the RX _ NET _ PKG phase, and when the data stream arrives at the ULP protocol layer after being forwarded to the kernel protocol stack, SSL frame data is restored, that is, the data stream is converted into the RX _ TLS _ PKG phase.

The network traffic management table in fig. 2 may specifically be shown as the following table:

session_ID	stream_type	stream_ID	param0＝key	param1＝iv	paramM
						0	TX_NET_PKG	M	…	…	…
1	RX_NET_PKG	N	…	…	…
						1	RX_TLS_PKG	N	…	…	…
2	RX_NET_PKG	W	…	…	…
						2	RX_TLS_PKG	W	…	…	…
…	…	…	…	…	…

in the above table, session _ ID is a session identifier, stream _ type is a network traffic type, stream _ ID is a network traffic identifier, param0 (parameter 0) is a stored private KEY (KEY), and the rest params can be flexibly set as required.

On the other hand, the present invention provides the above working method for the SSL offload device based on the ULP framework, as shown in fig. 2, the working method is used in a Linux operating system, the Linux operating system includes a user mode and a kernel mode, the kernel mode includes an ULP protocol layer, a network protocol stack and a device driver layer, the ULP protocol layer is provided with an ULP module, and the ULP module works in a TLS _ HW mode. In the embodiment shown in the figure, the ULP module may be based on the ULP protocol and written by referring to the KTLS module framework, named TIH _ TLS, in which the KTLS may be referred to by the overall initialization framework implementation. The network protocol stack is exemplified by a TCP protocol stack, the device Driver layer is exemplified by a Driver, and the PHY in the figure is an external physical device.

The working method comprises an SSL control message (CTRL) transmission method, and the SSL control message transmission method comprises the following steps:

step 103: and the SSL unloading equipment writes the network flow ID represented by the socket and the corresponding SSL initialization connection parameters into a network flow management table in the table lookup module.

In specific implementation, when an application program in a user mode or an OpenSSL client communicates with an opposite terminal, a socket interface is used to establish network connection between the two parties, then a handshake negotiation process between the two parties is performed based on an SSL protocol, and after the negotiation is completed, the two parties generate key parameters used for subsequent data transmission, such as a TX sending key parameter and an RX receiving key parameter. Specifically, messages and application data such as alert/handshake in the SSL protocol are sent to the kernel in a plaintext data manner based on the socket's interface functions sendmsg and send/sendfile, and do not belong to the domain of the SSL control message CTRL.

After the encapsulated messages of the SSL initial connection parameters are sent to the kernel TIH _ TLS module through the setsockopt (set socket option) function of the socket, the TIH _ TLS module will forward the network traffic ID represented by the socket and the corresponding SSL initial connection parameters to the TIH _ DEV _ TLS device driver through the "control flow" in fig. 2, and then the driver synchronizes to the network traffic management table of the device internal table lookup module in time. Therefore, the SSL connection established currently and the corresponding SSL session encryption and decryption connection parameter information can be stored in the equipment.

Further, the operating method may further include a SSL application data stream Transmission (TX) method, where the SSL application data stream transmission method includes:

step 201: the ULP module receives application data from the user mode, wherein the application data is plaintext data;

step 202: the ULP module packages the plaintext data into a frame format required by the SSL, packages the frame format through a skb structure, and then delivers the frame format to the network protocol stack for uniform packet processing to reach the device driver layer, after the device driver layer constructs TX Ring descriptor context information corresponding to a series of network packets, the device driver layer informs the SSL unloading device to process the context information, wherein the TX Ring descriptor context information sets the current network flow type as a network data packet sending stage;

step 203: the SSL unloading equipment acquires network frame data to be processed by inquiring data stream Ring, and a network protocol analysis module of the SSL unloading equipment acquires encryption parameters by analyzing TX Ring descriptor context and the network flow management table, and then the encryption parameters are sent to the cryptographic algorithm unloading module for processing and then sent to a corresponding NIC network interface for transmission.

In specific implementation, as shown in "data flow 2" in fig. 2, when an application program in a user mode or an OpenSSL client sends application data, plaintext data is sent to the TIH _ TLS module through a socket interface. The TIH _ TLS module is responsible for packaging plaintext data into a frame format required by SSL (including a storage space required by reserved equipment processing), packaging the plaintext data through a skb structure, and then delivering the packed plaintext data to a network protocol stack for unified packet processing to reach an equipment driving layer. After the device driver layer constructs TX Ring descriptor context information (abbreviated as ctx _ TX _ NET, and the current network traffic type is TX _ NET _ PKG) corresponding to a series of network packets, the device driver layer notifies the TIH _ DEV _ TLS device to process the TX Ring descriptor context information.

The TIH _ DEV _ TLS equipment can acquire the data of the network frame to be processed in time by inquiring the Ring of the data stream, and a network protocol analysis module of the equipment acquires the encryption parameters by analyzing the Ring descriptor context and the network traffic management table and then sends the encryption parameters to a cryptographic algorithm unloading module for processing and then sends the encryption parameters to a corresponding NIC for transmission. As shown in the internal flow 1- >5- >6- >2 of the equipment.

Further, the operating method may further include an SSL application data stream Reception (RX) method, where the SSL application data stream reception method includes:

step 301: when an NIC network interface in the SSL unloading equipment receives a new network packet, the network protocol analysis module analyzes and searches an SSL protocol frame header in real time, when the SSL protocol frame header in the network packet is found, decryption operation is not performed, then the network protocol analysis module searches the network traffic management table through the table search module to obtain an SSL session index corresponding to the network packet, records the SSL session index into RX Ring descriptor context information, and notifies the kernel-state equipment driving layer to receive the new network packet, wherein the RX Ring descriptor context information sets the current network traffic type as a network data packet receiving stage.

In specific implementation, when the NIC in the TIH _ DEV _ TLS device receives a new network packet, the network protocol analysis module of the device may perform analysis and search for the SSL protocol header in real time. When the SSL header is found in the network packet, since the SSL entire data frame may not be received completely, the decryption operation is not performed, which is different from the mechanism recommended by the KTLS module for processing the offload device. Then, after obtaining the SSL session index corresponding to the network packet by looking up the network traffic management table, the network protocol analysis module of the device records the SSL session index into an RX Ring descriptor context (abbreviated as ctx _ RX _ NET, and the current network traffic type is RX _ NET _ PKG), and notifies the kernel-state device driver layer to receive a new network packet. As shown in the apparatus internal scheme 3- >5- > 4.

In an alternative embodiment, the step 301 may be followed by:

step 302: after receiving the network packet, the kernel-state device driver layer encapsulates the network packet into a skb structure and carries out processing by the network protocol stack after context information of an RX Ring descriptor is carried, and after the network packet reaches the ULP protocol layer, the ULP module analyzes that data carried by the network packet is SSL frame data and records the context information carried by the network packet;

step 303: and after the ULP layer in the kernel state receives complete SSL frame data and reconstructs TX Ring descriptor context information according to the recorded context information, the complete SSL frame data is sent to the SSL unloading equipment for decryption operation, wherein the current network traffic type in the TX Ring descriptor context information is set as an SSL data packet sending stage.

In specific implementation, as shown in "data flow 1" in fig. 2, after receiving a network packet, the device driver layer encapsulates the network packet into a skb structure and carries context information of an RX Ring descriptor, and then sends the context information to the network protocol stack for processing. When a network packet reaches an ULP protocol layer, after the TIH _ TLS module analyzes that data carried by the packet is SSL frame data, the context information (ctx _ rx _ net) carried by the network packet is recorded, and then the subsequent decryption operation is triggered.

As shown in "data flow 3" in fig. 2, the data received by the ULP protocol layer is complete SSL frame data after the integrity and correctness of the received data have been ensured by the TCP layer. At this time, after the SSL frame data is re-entered into the SSL uninstalling device TIH _ DEV _ TLS once again, the device uninstalling problem encountered in the KTLS module analysis section above can be solved well. When the SSL frame data is re-entered into the SSL offload device, the TX Ring descriptor context information (abbreviated as ctx _ RX _ TLS, and the current network traffic type is RX _ TLS _ PKG) needs to be reconstructed according to the context information (ctx _ RX _ net). Finally, the TIH _ DEV _ TLS is handed to the processing.

In another alternative embodiment, the step 303 may be followed by:

step 304: the SSL unloading equipment acquires SSL frame data to be processed by inquiring data stream Ring, and a network protocol analysis module of the SSL unloading equipment acquires SSL encryption parameters by analyzing TX Ring descriptor context and the network traffic management table, then the SSL encryption parameters are processed by the cryptographic algorithm unloading module, and then the SSL unloading equipment is informed to the kernel-state equipment driving layer by RX Ring to be processed;

step 305: and after receiving the SSL frame data packet, the device driver layer in the kernel state does not reenter the network protocol stack, but directly informs the ULP module of carrying out receiving processing.

In specific implementation, after the TIH _ DEV _ TLS device obtains to-be-processed SSL frame data by querying a data stream Ring, a network protocol analysis module of the device obtains SSL encryption parameters by analyzing a Ring descriptor context and a network traffic management table, and then the SSL encryption parameters are processed by a cryptographic algorithm unloading module and then processed by an RX Ring notification kernel-state device driver. As shown in the internal flow scheme 1- >5- >6- >4 of the equipment.

As shown in "data flow 3" in fig. 2, after the device driver layer receives the SSL frame data packet, the device driver layer does not re-enter the network protocol stack, but directly notifies the TIH _ TLS module of the ULP layer to perform receiving processing. At this point, the application data returned to the user mode is the decrypted plaintext data.

In summary, the SSL offload device based on the ULP framework and the working method thereof provided by the present invention show a method for customizing the kernel-mode SSL offload framework using device to offload through self-implemented SSL offload device, enrich and expand the function of the kernel-mode SSL offload module, widen the path of the kernel-mode SSL offload device, and improve the data receiving performance (especially the processing delay of the network packet).

The invention also has the following beneficial effects:

1. the implementation of the patent expands the implementation thought of the kernel KTLS module, and provides an optimization thought and method for the implementation of domestic special SSL unloading equipment;

2. the problem (processing delay of network packets) encountered by RX in the Linux kernel KTLS module can be well solved by utilizing the unloading equipment to realize the idea;

3. the method provides an acceleration realization idea and method of the unloading equipment for realizing the unloading of a DTLS (data packet Transport Layer Security) protocol or a QUIC (Quick UDP Internet Connection) protocol in a kernel;

4. when SSL protocol communication is carried out, KEY SSL KEY (private KEY) can be stored in the unloading equipment, and KEY leakage is prevented.

The foregoing is a preferred embodiment of the present invention, and it should be noted that it would be apparent to those skilled in the art that various modifications and enhancements can be made without departing from the principles of the invention, and such modifications and enhancements are also considered to be within the scope of the invention.

Claims

1. An SSL uninstalling device based on ULP framework is characterized by comprising a network card NIC network interface, a network protocol analysis module, a cryptographic algorithm uninstalling module, a device operation register interface and a table lookup module, wherein:

2. The SSL offload device of claim 1, wherein the device operation register class interface is a Ring interface.

3. The SSL offload device of claim 2, wherein the device operation register class interface comprises a traffic ingress interface and a traffic egress interface, each comprising a control Ring and a data flow Ring.

4. The working method of the SSL offload device as recited in any one of claims 1-3, wherein the SSL offload device is used in a Linux operating system, the Linux operating system includes a user mode and a kernel mode, the kernel mode includes a ULP protocol layer, a network protocol stack and a device driver layer, the ULP protocol layer is provided with a ULP module, and the ULP module operates in a TLS _ HW mode, and the working method includes an SSL control message transmission method, and the SSL control message transmission method includes:

step 101: when the user mode communicates with the opposite terminal equipment, after handshake negotiation of both sides based on an SSL protocol is completed, the ULP module receives an encapsulation message of SSL initialization connection parameters from the user mode;

5. The operating method according to claim 4, characterized in that it comprises a SSL application data flow sending method comprising:

step 202: the ULP module packages the plaintext data into a frame format required by SSL, packages the frame format through a skb structure, and then sends the frame format to the network protocol stack for uniform packet processing to reach the device driver layer, and after the device driver layer constructs TX Ring descriptor context information corresponding to a series of network packets, the device driver layer informs the SSL unloading device to process the TX Ring descriptor context information, wherein the current network traffic type in the TX Ring descriptor context information is set as a network data packet sending stage;

6. The operating method of claim 4, wherein the operating method comprises a SSL application data stream receiving method, and wherein the SSL application data stream receiving method comprises:

7. The method of claim 6, wherein step 301 is followed by:

8. The method of claim 7, wherein step 303 is followed by: