A method and system for iSCSI protocol data security services

Abstract

This invention provides a method and system for iSCSI protocol data security services, belonging to the field of data management technology. The invention includes: on the first and second CPUs of an encryption / decryption device, directly sending and receiving Ethernet data packets from the network card via user-mode DPDK, and implementing some functions of the TCP / IP protocol stack through software simulation; parsing the received data packets using the iSCSI protocol, and performing group alignment, splicing, or restoration operations on the data to obtain data units aligned with the encryption block size; before sending the data units to the encryption / decryption module for encryption / decryption, dynamically extracting a ternary key information consisting of a device identifier, a logical unit number identifier, and a logical block address identifier from the iSCSI protocol interaction, and filling this ternary key information and control information into an internal header format, adding it to the end of the data unit to guide the encryption / decryption module in completing the encryption / decryption operation.

Description

Technical Field

[0001] This invention relates to the field of data management technology, and in particular to a method and system for iSCSI protocol data security services. Background Technology

[0002] iSCSI (Internet Small Computer System Interface) is a network storage protocol that encapsulates SCSI commands within TCP / IP packets for transmission. Due to its inherent block storage characteristics, data transmitted via iSCSI is well-suited for data protection using fixed-length block encryption algorithms (such as AES-XTS). However, in practical applications, achieving transparent and high-speed encryption and decryption of iSCSI data streams faces several technical challenges.

[0003] First, the iSCSI protocol runs on top of the TCP protocol layer, and TCP is a streaming protocol. To adapt to the MTU (Maximum Transmission Unit) of the underlying network, the TCP protocol stack segments application layer data into multiple TCP packets at the sending end and reassembles them at the receiving end. This mechanism means that a complete iSCSI command or a data block aligned with the encryption block size may be arbitrarily segmented into different TCP packets during network transmission, or a single TCP packet may contain multiple iSCSI Protocol Data Units (PDUs), resulting in "packet merging." This randomness of data boundaries directly undermines the fundamental premise of block cipher algorithms requiring fixed-length data blocks and aligned boundaries, creating a fundamental difficulty in achieving transparent online encryption and decryption.

[0004] To address the aforementioned issues, a known solution involves leveraging the operating system kernel protocol stack to establish independent TCP connections between the encryption / decryption device and both the initiator and target of the data, forming a proxy. This proxy device first receives and reassembles data from one end, performs encryption / decryption at the application layer, and then sends it out through the other end. While this method can alleviate the encryption alignment problem caused by data segmentation to some extent, it suffers from a significant performance bottleneck. Because the operating system kernel protocol stack is not designed for high-speed network processing, its complex protocol processing, frequent kernel-to-user context switching, and data copying operations introduce substantial processing latency and CPU overhead. This makes the encryption / decryption device the performance bottleneck of the entire storage link, failing to meet the demands of modern data centers for high-bandwidth, low-latency storage networks.

[0005] On the other hand, the Data Plane Development Kit (DPDK) technology makes it possible to achieve high-speed network packet transmission and reception in user space. By bypassing the kernel protocol stack, directly manipulating the network card hardware, and utilizing multi-core CPU affinity, DPDK can significantly improve network throughput and reduce latency. However, after bypassing the kernel protocol stack with DPDK, basic functions originally handled by the kernel, such as TCP connection management, data ordering, packet loss retransmission, and out-of-order reassembly, are lost. To implement iSCSI protocol data encryption and decryption on this basis, a complete TCP / IP protocol processing logic must be implemented in the application layer software, and a series of complex problems must be solved, such as iSCSI data stream parsing, command and data packet alignment, and dynamic generation and transmission of encryption and decryption keys.

[0006] Therefore, there is an urgent need for a method and system for iSCSI protocol data security services to address the technical problem that existing technologies do not yet have a mature solution that can organically integrate the above-mentioned aspects to achieve a transparent, uncomplicated, and high-performance iSCSI protocol data security service method. Summary of the Invention

[0007] The purpose of this invention is to overcome the shortcomings of the prior art and provide a new technical solution that can systematically solve the problem of iSCSI data stream segmentation and packet merging at the transport layer while bypassing the kernel protocol stack and making full use of the user-space high-speed data channel. This ensures that data blocks can be accurately aligned and restored before and after encryption, and can dynamically extract and transmit the key information required for encryption and decryption during data transmission. Thus, it can provide high-performance end-to-end data encryption protection without making complex configuration changes to the existing iSCSI storage system.

[0008] To achieve the above objectives, this application proposes a method for iSCSI protocol data security services, applied to an encryption / decryption device. The encryption / decryption device includes a first CPU, a second CPU, and an encryption / decryption module. The first CPU is used to process plaintext, and the second CPU is used to process ciphertext. The method includes: On the first CPU and the second CPU, Ethernet packets are sent and received directly from the network card through the user-mode data plane development kit DPDK, and some TCP / IP protocol stack functions are simulated by software to replace the operating system kernel protocol stack in processing the received packets. On the first CPU and / or the second CPU, the data packets processed by the TCP / IP protocol stack are parsed using the iSCSI protocol, and the parsed data is grouped, aligned, spliced, or restored to obtain data units aligned with the encrypted block size. Before the data unit is sent from the first CPU to the encryption / decryption module for encryption, or before the data unit is sent from the second CPU to the encryption / decryption module for decryption, ternary key information is extracted from the iSCSI protocol interaction, and the ternary key information is filled into an internal header format. The internal header format is added to the end of the data unit to guide the encryption / decryption module to perform encryption / decryption operations.

[0009] As a further solution, the first CPU is a front-end CPU connected to the data initiator, and the second CPU is a back-end CPU connected to the data target. Alternatively, when the data transmission direction is from the data target to the data initiator, the second CPU is the front-end CPU and the first CPU is the back-end CPU.

[0010] As a further solution, the method of directly sending and receiving Ethernet packets from the network interface card (NIC) via the user-space Data Plane Development Kit (DPDK) includes: By configuring the receiver to scale RSS, data packets for the same TCP connection can be distributed to the same queue on the network card. The data plane development kit (DPDK) is used to bind the network card's queues to the CPU's processing cores one-to-one. By configuring CPU affinity, the processing threads for sending and receiving packets are bound to the processing core.

[0011] As a further solution, the software simulation of some TCP / IP protocol stack functions specifically includes: TCP connection management, TCP packet ordering, TCP out-of-order packet management, TCP packet sending record management, TCP retransmission mechanism, and active acknowledgment mechanism.

[0012] As a further solution, the TCP retransmission mechanism includes retransmitting old packets and retransmitting new packets; wherein, the processing of retransmitting old packets includes: When the front-end CPU receives an old packet that has been acknowledged by the other end, it strips off the TCP payload, keeps only the header, sets a retransmission flag in the internal header, and then passes it to the back-end CPU. The backend CPU, based on the retransmission flag, searches for the corresponding TCP payload in its own maintained historical packet sending records, fills it into the packet header, recalculates the checksum, and sends it to the peer.

[0013] As a further solution, the iSCSI protocol parsing and data grouping, alignment, splicing, or restoration operations include: When an iSCSI command is split into two or more TCP packets for transmission, the first arriving packet is buffered. When subsequent packets arrive, the complete command is assembled and parsed. The assembly information is recorded in the internal header so that the CPU at the other end can reconstruct the packet length. When the iSCSI data block length is not an integer multiple of the encrypted block size or the boundaries are not aligned, a portion of the data in the next data packet is borrowed, the data is concatenated to the encrypted block size alignment, and the starting offset and number of the aligned data blocks are recorded in the internal header so that the peer CPU can reconstruct the original data. When multiple iSCSI protocol data units (PDUs) are transmitted in a single TCP packet, the packet is identified and split into multiple independent data units for separate processing. The packet-merging information is recorded in the internal header so that the peer CPU can reassemble these independent data units into the original packet.

[0014] As a further solution, the extraction of ternary key information includes: Parse the target name Target IQN from the interaction messages during the iSCSI Login phase and map it to a device identifier as the first meta key device-id; The logical unit number (LUN) is parsed from the iSCSI read / write command and used as the second meta key (LUN-id). The starting logical block address (LBA) and write length are parsed from the iSCSI write command. Based on the group alignment result, the starting logical block address (LBA) corresponding to each encrypted block in the current data packet is dynamically calculated and used as the third meta key (LBA-id).

[0015] As a further solution, the internal header format is defined as a 32-byte data structure containing: The fields used for the encryption / decryption module include the ternary key information, the start offset of the encryption / decryption data block, the block encryption / decryption flag, the data flow flag, and the error flag. Fields used for synchronization between the first CPU and the second CPU include connection status information, retransmission status information, data splicing / splitting information, and control command information.

[0016] On the other hand, the present invention also provides a system for iSCSI protocol data security services, including a first CPU, a second CPU, and an encryption / decryption module, wherein the first CPU is used to process plaintext, and the second CPU is used to process ciphertext; the first CPU and the second CPU are configured to cooperate in performing a method for iSCSI protocol data security services as described above.

[0017] As a further solution, the first CPU and the second CPU are two physically independent CPUs.

[0018] Compared with related technologies, the method and system for providing iSCSI protocol data security services provided by this invention have the following advantages: 1. This invention eliminates the significant performance overhead caused by frequent kernel-user mode context switching, data copying, and multi-core resource mutual exclusion in traditional kernel protocol stack schemes by employing a user-space packet sending and receiving mechanism based on DPDK and combining it with a three-level binding strategy of "queue-CPU core-processing thread". All data packets of the same TCP connection are always processed on the same CPU core, significantly improving the cache hit rate and enabling the entire encryption / decryption device to handle network data streams of 10G or even higher bandwidth at near-line speed throughput. Test data shows that after adding the encryption / decryption device of this invention, the storage read / write bandwidth can reach more than 90% of the direct connection performance.

[0019] 2. This invention, by deeply participating in the iSCSI protocol interaction process, automatically and dynamically extracts a three-factor key composed of the Target IQN, LUN, and LBA from Login messages and read / write commands. It intelligently handles issues such as command splitting, data block misalignment, and PDU packet fragmentation caused by TCP streaming transmission, ensuring that the data delivered to the encryption / decryption module is always a standard data block with aligned boundaries. Users only need to connect the device to the network between the Initiator and the Target and configure a simple mapping relationship between the Target IQN and device-id to achieve high-strength encryption, without requiring any modifications to existing servers, storage arrays, or iSCSI application software.

[0020] 3. This invention achieves fine-grained block encryption bound to storage addresses by extracting a ternary key composed of a device identifier, a logical unit number identifier, and a logical block address identifier. Data from different targets on the same storage array, different LUNs under the same target, and different LBA locations under the same LUN are all encrypted using different keys, achieving a "one key per data block" security effect. Simultaneously, the physically isolated architecture of the first CPU processing plaintext and the second CPU processing ciphertext ensures that plaintext data never appears on the network side connected to the storage array, physically guaranteeing the security boundary.

[0021] 4. This invention designs a compact internal header format of only 32 bytes, which simultaneously carries key and control information for the encryption / decryption module, as well as TCP protocol synchronization information between the two CPUs, within an integrated data structure. This "in-band" information transmission mechanism achieves fully stateless and efficient operation of the encryption / decryption module with minimal bandwidth overhead, and precise synchronization of the TCP connection state between the two CPUs, ensuring protocol consistency and transmission reliability of the entire system during bidirectional full-duplex data stream processing.

[0022] 5. This invention simulates a subset of necessary TCP / IP protocol stack functions (including connection management, order preservation, packet scrambling management, retransmission, and active acknowledgment) in user-space software, enabling the encryption / decryption device to operate independently of the operating system's complete protocol stack behavior, thus avoiding complex system optimization and compatibility issues. Long-term operational testing shows that the system operates stably 24 / 7 with stable bandwidth, without data errors or connection interruptions, demonstrating excellent enterprise-level application reliability and deployment flexibility. Attached Figure Description

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

[0024] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0025] Figure 1 This is a flowchart illustrating a method for providing iSCSI protocol data security services according to an embodiment of the present invention; Figure 2 This is a system network topology diagram according to an embodiment of the present invention; Figure 3 This is a flowchart of the business processing core in an embodiment of the present invention; Figure 4 This is a flowchart illustrating the packet receiving process according to an embodiment of the present invention; Figure 5 This is a flowchart of the TCP packet reception and order preservation process according to an embodiment of the present invention; Figure 6 This is a flowchart of TCP out-of-order packet processing according to an embodiment of the present invention; Figure 7 This is a schematic diagram of block data splicing in an embodiment of the ISCSI invention; Figure 8 This is a schematic diagram illustrating packet splicing and reconstruction during ISCSI data writing in an embodiment of the present invention. Figure 9 This is a schematic diagram illustrating packet splicing and reconstruction during ISCSI data reading in an embodiment of the present invention. Figure 10 This is a schematic diagram of unpacking the ISCSI paste package according to an embodiment of the present invention; The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0027] Example 1 Please see Figure 1 This embodiment provides a method for iSCSI protocol data security services, applied to an encryption / decryption device. The encryption / decryption device includes a first CPU, a second CPU, and an encryption / decryption module. The first CPU is used to process plaintext, and the second CPU is used to process ciphertext. The method includes: On the first CPU and the second CPU, Ethernet packets are sent and received directly from the network card through the user-mode data plane development kit DPDK, and some TCP / IP protocol stack functions are simulated by software to replace the operating system kernel protocol stack in processing the received packets. On the first CPU and / or the second CPU, the data packets processed by the TCP / IP protocol stack are parsed using the iSCSI protocol, and the parsed data is grouped, aligned, spliced, or restored to obtain data units aligned with the encrypted block size. Before the data unit is sent from the first CPU to the encryption / decryption module for encryption, or before the data unit is sent from the second CPU to the encryption / decryption module for decryption, ternary key information is extracted from the iSCSI protocol interaction, and the ternary key information is filled into an internal header format. The internal header format is added to the end of the data unit to guide the encryption / decryption module to perform encryption / decryption operations.

[0028] It should be noted that this embodiment constructs a system architecture that deeply integrates "user-space high-performance data processing", "hardware-isolated encryption and decryption" and "protocol-aware key and data block alignment" to solve the performance bottlenecks and protocol complexity problems encountered when implementing transparent encryption and decryption in iSCSI network storage.

[0029] Specifically, this solution abandons the heavy processing mode of traditional proxy solutions that rely on the operating system kernel protocol stack. Instead, it directly introduces user-space DPDK technology on two CPUs of a dedicated encryption / decryption device (to process plaintext and ciphertext respectively), and implements the necessary TCP / IP protocol stack functions by software simulation.

[0030] This reconstruction of the basic processing layer not only eliminates the performance overhead caused by kernel-mode and user-mode context switching and data copying at the source, enabling the device to have line-speed processing capabilities, but more importantly, it gives developers the ability to perform fine-grained management of TCP packets, providing a technical foundation for subsequent precise control of iSCSI protocol data.

[0031] Building upon this foundation, this solution further leverages the deep analysis capabilities of the iSCSI protocol to proactively identify and address data segmentation and packet fragmentation issues caused by TCP streaming. During transmission, it dynamically aligns or reassembles data into groups, ensuring that the data delivered to the encryption / decryption module is always a standard data block that conforms to the requirements of the block encryption algorithm.

[0032] Furthermore, this embodiment seamlessly integrates protocol parsing and encryption / decryption operations through a sophisticated in-band information transmission mechanism called the "internal header" defined in the technical disclosure. Before sending data blocks to the encryption / decryption module, the system automatically extracts a three-factor key consisting of the target ID, logical unit number ID, and logical block address ID from the iSCSI protocol interaction context in real time, and writes it along with control information into the internal header added before the data unit. This allows the encryption / decryption module to obtain accurate block keys and data processing instructions simply by parsing the internal header, without being aware of the complex details of the iSCSI protocol.

[0033] Finally, the encrypted and decrypted data and synchronization information are accurately restored at the peer CPU via the internal header. The entire method achieves a complete closed loop in the process, from network packet reception and transmission to protocol parsing, data shaping, key distribution, encryption and decryption operations, and final restoration. This provides high-performance data security protection that is completely transparent to the original iSCSI storage system and requires no complex user configuration.

[0034] Furthermore, the first CPU is a front-end CPU connected to the data initiator, and the second CPU is a back-end CPU connected to the data target. Alternatively, when the data transmission direction is from the data target to the data initiator, the second CPU is the front-end CPU and the first CPU is the back-end CPU.

[0035] Specifically, in this embodiment, the "first CPU (processing plaintext)" and the "second CPU (processing ciphertext)" do not always play the roles of front-end or back-end. Instead, they switch roles symmetrically according to the different directions of data transmission, thereby constructing a full-duplex encryption and decryption processing architecture that is universally applicable to bidirectional data streams.

[0036] Specifically, when the Initiator writes data to the Target, the data flow is from the Initiator to the Target. At this time, the first CPU directly connected to the Initiator acts as the "front-end CPU" and is responsible for receiving plaintext data. After protocol parsing, data block alignment, and adding an internal header, it is sent to the encryption / decryption module for encryption. After the ciphertext data reaches the second CPU, the second CPU acts as the "back-end CPU" and completes protocol restoration and forwards it to the Target for storage.

[0037] Conversely, when the Initiator reads data from the Target, the data flow reverses. At this time, the second CPU directly connected to the Target switches to the "front-end CPU," which is responsible for receiving the ciphertext data returned from the storage array, aligning the blocks in the same way, and then sending it to the decryption module for decryption. The decrypted plaintext is then handed over to the first CPU connected to the Initiator (which switches to the "back-end CPU" at this time) for protocol restoration and returned to the Initiator.

[0038] This bidirectional symmetrical role definition ensures that, regardless of whether it is a read or write operation, the data is always shaped by the front-end CPU, which is more sensitive to the data format on that side, before entering the encryption / decryption module. The other end CPU is specifically responsible for restoring the shaped data to its original state, making the encryption / decryption process completely symmetrical and transparent in bidirectional transmission.

[0039] Furthermore, the method of directly sending and receiving Ethernet packets from the network card via the user-space Data Plane Development Kit (DPDK) includes: By configuring the receiver to scale RSS, data packets for the same TCP connection can be distributed to the same queue on the network card. The data plane development kit (DPDK) is used to bind the network card's queues to the CPU's processing cores one-to-one. By configuring CPU affinity, the processing threads for sending and receiving packets are bound to the processing core.

[0040] Specifically, the current technical background is that when traditional kernel protocol stacks process network data packets, the data packets may be interrupted and processed by different CPU cores, resulting in problems such as low cache hit rate, frequent context switching, and resource mutual exclusion overhead between multiple cores, which seriously restricts the throughput of high-speed networks.

[0041] To address this performance bottleneck, this embodiment employs refined hardware affinity configuration to rigidly bind the network packet receiving path to the CPU core, thereby maximizing the utilization of modern multi-core CPU hardware features. Specifically, this "three-level binding" mechanism consists of three interconnected layers: The first layer is data flow classification at the network card hardware level. By configuring the network card's RSS (Receiver Scaling) function, the hash value is calculated based on the five-tuple of the data packet (source IP, destination IP, source port, destination port, protocol number), and all data packets belonging to the same TCP connection are allocated to the same hardware receive queue of the network card.

[0042] The second layer is the binding of queues to CPU cores, which uses the interface provided by DPDK to associate a specific queue of the network card with a specific CPU processing core one-to-one.

[0043] The third layer is the binding of threads to CPU cores. That is, by configuring CPU affinity, the thread responsible for processing the sending and receiving of packets in the queue is locked to run on the associated CPU core.

[0044] With these three layers of configuration, throughout the entire data flow from the Initiator to the Target or vice versa, all Ethernet packets on a TCP connection, from network card reception to software processing, are handled by the same thread on the same CPU core from beginning to end.

[0045] On the one hand, all data packets of the same TCP connection are processed on the same CPU core, which allows the state information of the connection (such as TCP sequence number, connection table entry, out-of-order packet list, etc.) to reside in the local cache of the core for a long time, greatly improving the cache hit rate; On the other hand, since each CPU core independently processes its bound queues and connection sets, there is no need for mutual exclusion access or locking operations on shared data between different cores, completely eliminating resource contention and context switching overhead between multiple cores.

[0046] Therefore, the lock-free, switchless, and highly cache-friendly packet sending and receiving mechanism in this embodiment provides solid high-performance underlying support for subsequent complex TCP protocol software simulation and iSCSI protocol deep parsing, enabling the entire encryption and decryption device to process network data streams with bandwidths of 10G or even higher at near-line-speed throughput.

[0047] Furthermore, the software simulation of some TCP / IP protocol stack functions specifically includes: TCP connection management, TCP packet ordering, TCP out-of-order packet management, TCP packet sending record management, TCP retransmission mechanism, and active acknowledgment mechanism.

[0048] Specifically, the technical background of this embodiment is that when this solution uses DPDK to bypass the operating system kernel protocol stack, the key mechanisms such as connection state tracking, data order guarantee, and data loss recovery, which were originally automatically completed by the kernel TCP / IP protocol stack, are lost; while the iSCSI protocol relies precisely on the reliable and ordered byte stream transmission service provided by TCP.

[0049] Therefore, a "sufficient" subset of protocol stack functions must be implemented in user-space software to ensure the correct operation of the iSCSI upper-layer protocol while avoiding the complexity of fully implementing all kernel protocol stack functions.

[0050] The six sub-functions listed in this embodiment form an organically cooperating whole, working together to provide reliable and orderly data flow services for the iSCSI protocol layer in user space.

[0051] Among them, "TCP Connection Management" is responsible for sensing the lifecycle of TCP connections, including creating connections through SYN packets, destroying connections through RST or FIN packets, and cleaning up idle connections that have timed out. It is the basis for this solution to dynamically track each iSCSI session. "TCP Packet Order Preservation Processing" and "TCP Out-of-Order Packet Management" work together. The former determines whether each arriving packet is in order, out-of-order, or a retransmission packet based on the TCP sequence number and processes it accordingly. The latter maintains an ordered linked list with the sequence number as the key to temporarily store out-of-order packets that arrive prematurely, and submits them to the upper layer in order when the gaps are filled, thereby ensuring that the data delivered to the iSCSI parsing module is always strictly in order.

[0052] "TCP packet sending record management" and "TCP retransmission mechanism" constitute the key links in this solution to ensure reliable data delivery. Data packets that have been sent but have not yet been acknowledged by the other end are not released immediately, but are stored in a historical sending record linked list in order of sequence number; when the local end detects that the ACK indicates that the data packet is lost (such as receiving three consecutive identical ACKs), it can quickly locate and retransmit the packet according to the linked list.

[0053] Building on this, the "active acknowledgment mechanism" further optimizes transmission efficiency and reliability. When out-of-order packets are received, a SACK (selective acknowledgment) is proactively sent to inform the peer of the missing sequence number range. When a retransmission packet is received, the latest ACK is proactively sent to guide the peer to send new data. These mechanisms draw on the ideas of mature TCP congestion control algorithms, enabling the software-simulated protocol stack to maintain high throughput performance even in complex network environments.

[0054] Therefore, this embodiment enables a high-performance encryption / decryption scheme that bypasses the kernel protocol stack through the coordinated operation of six sub-functions in user space.

[0055] Furthermore, the TCP retransmission mechanism includes retransmitting old packets and retransmitting new packets; wherein, the processing of retransmitting old packets includes: When the front-end CPU receives an old packet that has been acknowledged by the other end, it strips off the TCP payload, keeps only the header, sets a retransmission flag in the internal header, and then passes it to the back-end CPU. The backend CPU, based on the retransmission flag, searches for the corresponding TCP payload in its own maintained historical packet sending records, fills it into the packet header, recalculates the checksum, and sends it to the peer.

[0056] Specifically, in traditional TCP communication, when the sending end receives an "old packet" that has already been acknowledged by the receiving end, it is usually discarded directly. However, in the dual-CPU architecture of this invention, the situation is more complex—when the front-end CPU receives an old packet from the receiving end, although the TCP payload data of the packet is outdated and does not need to be processed, the retransmission of the old packet itself implies that the receiving end may not have received the acknowledgment from this end, or the receiving end believes that the packet still needs to be retransmitted. If the front-end CPU simply discards the packet, the TCP state of this end and the TCP state of the receiving end will be inconsistent, which may lead to connection interruption or transmission freeze.

[0057] Therefore, this embodiment designs an ingenious two-stage processing flow: In the first phase, after the front-end CPU identifies the received packet as an old packet already acknowledged by the peer, it does not discard it directly. Instead, it performs a "remove payload, retain header" operation: only the TCP payload data of the packet is stripped, while the complete Ethernet header, IP header, and TCP header are retained. A retransmission flag is set in the corresponding flags of the internal headers, and this lightweight "empty shell" packet is then passed to the back-end CPU through the internal channel. This operation avoids transmitting useless acknowledged data between the two CPUs, saving internal bandwidth.

[0058] In the second stage, after the backend CPU receives the internal packet with the retransmission flag, it searches for the corresponding original TCP payload data in the historical packet record list maintained by itself for this TCP connection based on the TCP sequence number and other information in the packet header. It then retrieves the original TCP payload data and fills it back into the packet, recalculates the checksum of the IP header and TCP header, and finally sends it to the external peer.

[0059] On the one hand, the task of finding stateful data required for retransmitting old packets is handed over to the backend CPU, which conforms to the principle of "whoever holds the historical data is responsible for recovery" in the dual-CPU architecture, and maintains the clarity and independence of the processing logic of each CPU. On the other hand, transmitting only the packet header on the internal network instead of repeatedly transmitting potentially large TCP payloads significantly saves bandwidth overhead in the internal channel between the two CPUs. This ensures that even in high-bandwidth, long-packet scenarios where old packets are frequently retransmitted, no additional pressure is placed on the internal communication link, thus guaranteeing the overall throughput performance of the entire encryption and decryption device.

[0060] Furthermore, the iSCSI protocol parsing and data grouping, alignment, splicing, or restoration operations include: When an iSCSI command is split into two or more TCP packets for transmission, the first arriving packet is buffered. When subsequent packets arrive, the complete command is assembled and parsed. The assembly information is recorded in the internal header so that the CPU at the other end can reconstruct the packet length. When the iSCSI data block length is not an integer multiple of the encrypted block size or the boundaries are not aligned, a portion of the data in the next data packet is borrowed, the data is concatenated to the encrypted block size alignment, and the starting offset and number of the aligned data blocks are recorded in the internal header so that the peer CPU can reconstruct the original data. When multiple iSCSI protocol data units (PDUs) are transmitted in a single TCP packet, the packet is identified and split into multiple independent data units for separate processing. The packet-merging information is recorded in the internal header so that the peer CPU can reassemble these independent data units into the original packet.

[0061] Specifically, the core problem this embodiment aims to solve is that while iSCSI commands and data have clear logical boundaries and block alignment requirements, the underlying TCP protocol may arbitrarily segment or merge iSCSI Protocol Data Units (PDUs) during transmission, causing the Ethernet packet payload seen by the receiving end to lose its correspondence with the iSCSI logical boundaries. Without this handling, the block encryption algorithm will be unable to correctly identify data block boundaries, and encryption / decryption will fail.

[0062] Regarding the issue of "iSCSI commands being split": When the fixed-length header (48 bytes) of an iSCSI command is split into two different data packets by the TCP protocol stack for transmission, the command cannot be parsed based on the content of a single packet.

[0063] When this scheme detects that the command bytes in a received data packet are incomplete, it first caches the received portion in the context of the TCP connection. When the next data packet arrives, it retrieves the remaining portion from the cache and appends it to the beginning of the current packet's payload, thus recovering the complete command for parsing. Simultaneously, it records in the internal header how many bytes were borrowed from the current packet for this appending, so that the receiving CPU can use this information to strip away the borrowed portion of the payload header and restore the original packet length and boundaries when it receives the processed packet. This "IOU"-like information transmission mechanism ensures that command splitting processing is precisely reversible during full-duplex processing.

[0064] Regarding the issue of "data alignment": The data alignment packet assembly process borrows the "borrowing" idea similar to command splitting, but the operation object is the data boundary of the encrypted block size: when the end of the payload in the data packet is not an integer multiple of the encrypted block size (such as 512 bytes), several bytes are borrowed from the beginning of the payload of the next sequential packet belonging to the same connection to make up a complete encrypted block before it is delivered to the encryption and decryption module.

[0065] Regarding the issue of "PDU packet merging": PDU packet merging is handled in the opposite way: when a TCP packet is identified to contain two or more independent iSCSI PDUs, it is split into two logical packets, aligned and encrypted separately, and a packet merging flag is set in the internal header. Upon recognizing this flag, the peer CPU performs a merge and restore operation, reassembling the split packets back into their original merged form, updating the IP and TCP headers, and then sending them to the external network.

[0066] Through the coordinated operation of the three processing mechanisms mentioned above, this embodiment achieves a precise “shaping-encryption-restoration” process for the original iSCSI data stream, making the intermediate encryption and decryption process completely transparent to the storage devices at both ends.

[0067] Furthermore, the extraction of the ternary key information includes: Parse the target name Target IQN from the interaction messages during the iSCSI Login phase and map it to a device identifier as the first meta key device-id; The logical unit number (LUN) is parsed from the iSCSI read / write command and used as the second meta key (LUN-id). The starting logical block address (LBA) and write length are parsed from the iSCSI write command. Based on the group alignment result, the starting logical block address (LBA) corresponding to each encrypted block in the current data packet is dynamically calculated and used as the third meta key (LBA-id).

[0068] Specifically, in an iSCSI storage environment, a single storage array may contain multiple targets, multiple LUNs, and a massive number of data blocks. If all data is encrypted using the same fixed key, security will be significantly compromised. An ideal security solution should use different encryption keys for data from different storage resources and different data locations, achieving a "one key per data block" effect. At the same time, the acquisition and management of these keys must be fully automated, and users should not be required to manually configure keys for each data block; otherwise, the meaning of transparent encryption and decryption will be lost.

[0069] To address this, this embodiment cleverly resolves the aforementioned contradiction by deeply participating in the iSCSI protocol interaction process and dynamically extracting the ternary key information from the protocol message itself in real time.

[0070] The first meta-key—the device identifier (device-id)—originates from the message exchanges during the iSCSI login phase. When the initiator actively logs into the target, the Login request message or the subsequent text response message from the target will carry the target's globally unique identifier name (Target IQN).

[0071] After parsing the Target IQN, this solution converts it into an integer device-id using a pre-configured mapping table. This device-id serves as the first distinguishing factor for encrypting all data blocks under that Target. Users only need to configure the mapping between the Target IQN and the device-id once.

[0072] The second key—the Logical Unit Number Identifier (LUN-id)—originates from the read and write commands initiated by the Initiator. Each read and write command carries a LUN field, which specifies the target logical unit operated on by the command. Extracting this LUN field serves as the second distinguishing factor.

[0073] Extracting the third-level key—the Logical Block Address Identifier (LBA-id)—is the most technically challenging aspect and best reflects the refined design of this scheme. In write operation scenarios, the write command carries the starting LBA and the write length, but these two parameters alone are insufficient to determine the specific LBA corresponding to each encrypted block in subsequent data packets.

[0074] After grouping, aligning, and piecing together the data, this scheme dynamically calculates the LBA value (incrementing from the initial LBA) for each data packet based on the starting position and number of the aligned data blocks, and then fills the internal header with these LBA values ​​as the third-level key.

[0075] Similarly, in a read operation scenario, the starting LBA and read length in the read command are used to calculate the LBA value corresponding to each data block in the data stream returned from the Target.

[0076] Through the hierarchical extraction and real-time calculation of the three-level keys described above, this embodiment ensures that data from different LUNs under the same Target is encrypted with different keys, and data from different LBA locations under the same LUN is also encrypted with different keys. This achieves fine-grained block encryption bound to the storage address, while the entire process is completely transparent to the user and requires no additional configuration.

[0077] Furthermore, the internal header format is defined as a 32-byte data structure, which includes: The fields used for the encryption / decryption module include the ternary key information, the start offset of the encryption / decryption data block, the block encryption / decryption flag, the data flow flag, and the error flag. Fields used for synchronization between the first CPU and the second CPU include connection status information, retransmission status information, data splicing / splitting information, and control command information.

[0078] Specifically, in the dual-CPU encryption / decryption architecture constructed in this invention, the first CPU, the encryption / decryption module, and the second CPU need to transmit two completely different types of information. One type is "encryption / decryption control information" for the encryption / decryption module, including the key, data offset, operation type, etc.; the other type is "protocol synchronization information" for the peer CPU, including connection status, retransmission flags, data concatenation status, etc. Designing independent communication mechanisms for these two types of information would increase system complexity and processing overhead.

[0079] The internal header format defined in this embodiment achieves unified carrying and efficient transmission of two types of information by dividing functional areas within a compact 32-byte structure. The fields of the internal header are clearly divided into two areas according to their functions: The first area is the "Fields for the Encryption / Decryption Module," which constitute the complete instruction set for encryption / decryption operations. Specifically, these include: the ternary key information extracted during the process (device-id, LUN-id, LBA-id), directly informing the encryption / decryption module what the key is for this operation; the encryption / decryption data block start offset (data_offset), indicating from which byte position in the Ethernet packet the encryption / decryption operation begins; the block encryption / decryption flag (crypt_bmp), specifying in a bitmap whether each of the maximum three encrypted blocks in a packet needs encryption / decryption; the data flow flag (storage), explicitly indicating whether the current packet originates from the storage side and requires decryption, or from the initiating end and requires encryption; and the error flag (error), used by the encryption / decryption module to report operational errors to the CPU. These fields allow the encryption / decryption module to function as a pure "operation executor," mechanically performing encryption / decryption operations block by block according to internal header instructions, without needing to understand the complex upper-layer iSCSI protocol.

[0080] The second area is "fields for synchronization between the first and second CPUs." These fields carry the TCP state and data processing context information required for the two CPUs to collaborate. For example, the retransmission status field tells the peer CPU whether the current packet is a normal packet, a retransmission of an old packet, or a retransmission of a new packet, so that the peer CPU can perform corresponding processing (table lookup and filling or sequence number update as described in claim 5); the data splicing information field records how many bytes the current packet lent to the previous packet, whether the current packet is a fragmented packet, and whether it is the last fragmented packet. This information enables the peer CPU to accurately perform the splicing restoration and packet merging operations; the expected sequence number and acknowledgment sequence number fields for the TCP reverse connection synchronize the TCP state maintained by the local CPU to the peer CPU in real time, enabling the two CPUs to collaboratively complete the active retransmission and active acknowledgment judgments.

[0081] Therefore, through the compact design of the aforementioned 32-byte internal header, this solution achieves integrated in-band transmission of encryption / decryption control information and protocol synchronization information under a dual-CPU architecture with minimal bandwidth overhead (only 32 bytes per data packet). This ensures that the encryption / decryption module can work efficiently without statelessness, and also ensures the consistency of TCP state between the two CPUs. It is a key link for the coordinated operation of the entire system.

[0082] Example 2 This embodiment also provides a system for iSCSI protocol data security services, including a first CPU, a second CPU, and an encryption / decryption module. The first CPU is used to process plaintext, and the second CPU is used to process ciphertext. The first CPU and the second CPU are configured to collaboratively execute a method for iSCSI protocol data security services as described in any one of Embodiments 1. The first CPU and the second CPU are two physically independent CPUs.

[0083] Please see Figure 2 The iSCSI encryption / decryption device consists of three main hardware modules: two CPUs and one encryption / decryption module. The software code runs on the two CPUs. CPUi is located in the red zone and processes plaintext, while CPUt is located in the black zone and processes ciphertext. The two CPUs isolate the red and black zones. When the initiator sends a packet to the target, CPUi is the front-end CPU, and CPUt is the back-end CPU; when the target sends a packet to the initiator, CPUt is the front-end CPU, and CPUi is the back-end CPU.

[0084] In one specific embodiment, the iSCSI protocol data security service system of this embodiment is executed through the following specific encryption and decryption steps: S1, User-space packet sending and receiving and software simulation of some TCP / IP protocol stack functions; includes the following sub-steps: Step S11: User-mode cores send and receive packets; When using DPDK to send and receive packets in user space, the data packet enters the network interface card (NIC) driver. The configured RSS (Receive Side Scaling) extracts the 5-tuple from the data packet to calculate its hash value. Based on the calculated hash value, the data packet is assigned to a queue. The 5-tuple is the same for the same TCP connection, so all packets transmitted within a TCP connection can go to a fixed queue on the network interface.

[0085] Secondly, DPDK is used to bind network interface queues to CPU cores, so that packets in a queue on the same network interface will be bound to a fixed CPU core for processing.

[0086] Secondly, DPDK is used to bind the packet receiving thread to the CPU core, i.e., configuring CPU affinity. With this configuration, once a data packet is received, it enters a fixed queue and is processed by a fixed packet receiving thread on a fixed CPU core. This improves cache hits and avoids context switching and resource mutual exclusion, both of which enhance processing performance.

[0087] The processing flow of each business processing core in a multi-core CPU is as follows: Figure 3As shown, each core is a loop that polls and sends / receives packets (the packet receiving process is as follows). Figure 4 As shown in the diagram, first, all packets in the queues bound to the current core are sent out (flush), and then packet reception is performed on all ports (N ports). The TCP timeout tick is currently 5ms, and TCP timeout processing is performed every 5ms.

[0088] Step S12, TCP connection management; TCP connection management is a preprocessing step of TCP order preservation. The data structure used is a four-tuple of source IP, destination IP, source port, and destination port, requiring fast lookup support. Currently, there are two implementation methods, which can be switched at compile time: a hash table and a red-black tree. This article uses a join table to represent the TCP connection data structure.

[0089] When a TCP SYN packet is received, a connection is created and added to the connection table. If the connection already exists in the connection table, the previous connection must be removed and destroyed before adding the new connection. When a TCP RST packet is received, the connection is removed from the connection table and the connection is destroyed. When a TCP FIN packet is received, if there is a payload, the packet is processed using TCP; otherwise, the connection is removed from the connection table and destroyed.

[0090] If a connection remains inactive for an extended period (currently one hour), it will be removed from the connection table and destroyed.

[0091] Step S13, TCP order preservation processing; After a TCP connection is established, subsequent received TCP packets are processed according to their sequence number to determine whether they are the next packet, an out-of-order packet, or a retransmission packet. The specific process is as follows: Figure 5 As shown: Based on the sequence of the received TCP packet and the expected sequence of the connection to which the current packet belongs, determine whether the packet is out-of-order, in-order, or a retransmitted packet (retransmitted packets also include retransmitting old packets and retransmitting new packets), and then perform different processing accordingly. Step S14, TCP out-of-order packet management; The data structure of out-of-order packets is an ordered list with TCP sequence as the key. When a TCP sequence of a packet is received from the Initiator side after the expected sequence of the connection, and the packet has a payload, the packet is added to the list of random packets. When adding a packet to the list, if a packet with the same key value (TCP sequence) is found in the list, the payload lengths of the two packets are compared, the packet with the longest payload is saved to the list, and the shorter packet is discarded. After the CPU core completes one round of packet reception processing, it retrieves packets from the listhead of all connections from the out-of-order list and performs the following... Figure 6 Processing operations: Retrieve packets from the list header node. If a packet has already been processed (the packet's next sequence is not after the connection's expected sequence), discard the packet. If a packet has been partially processed, retransmit the new packet (only extract the unprocessed payload and update the corresponding packet header). If the packet is exactly the next packet in the connection (the packet's sequence is equal to the connection's expected sequence), perform iSCSI processing. Continue until the packet in the list header node is a random packet (the packet's sequence is after the connection's expected sequence).

[0092] Step S15, TCP packet sending record management; After a packet is sent out from the port, it is not released immediately, but is placed into the TCP connection's historical packet sending record txlist. This list is an ordered list with sequence as the key. A TCP connection on a CPU has ports on both sides. For connections to the internal port, the node in the tx list is released with the synchronization flag added to the internal header as the release condition; for connections to the external port, the node in the tx list is released with the ACK received on the corresponding port as the release condition. When the corresponding TCP connection is destroyed, all nodes in the tx list on that connection must be released. When an external old packet is retransmitted, the front-end CPU directly deletes the packet's TCP payload and passes the packet header to the back-end CPU. The back-end CPU finds the corresponding payload in the tx list corresponding to the TCP connection, fills it into the packet, and sends it to the other end. When internal packet loss occurs, the backend CPU will actively request the frontend CPU to send the missing packets. The software will retrieve all packets corresponding to the missing packets from the tx list and retransmit them. The backend CPU obtains the status and progress of connection processing on the frontend CPU through the internal header added in the internal packet, determines whether there is a missing packet in the internal packet, and performs active retransmission to fill the gap between the two CPUs under certain conditions.

[0093] Step S16: TCP retransmits the old packet and retransmits the new packet; Retransmission of old packets: When the front-end CPU receives a packet from the Initiator, it finds that the packet has been acknowledged by the Target. The software will delete the TCP payload, only keeping the packet header (Ethernet header, IP header, TCP header), and set the retransmission flag in the internal header added to the packet. The packet is then sent to the back-end CPU through the internal header. The back-end CPU finds the corresponding TCP payload from the connection's historical packet sending record, fills it into the packet, recalculates the checksum, and then sends it to the Target. Conversely, the retransmission of old packets from the Target to the Initiator is handled in a similar way. Retransmitting new packets: When a packet received by the external port is partially acknowledged by the other end, the software directly deletes the acknowledged portion of the TCP payload, leaving the unacknowledged TCP payload. It then updates the IP total length and TCP sequence in the packet header for subsequent iSCSI processing. This operation is essentially an internal packet processing step, removing the overlapping parts of the TCP retransmission.

[0094] Step S17: TCP actively retransmits and actively acknowledges; Active retransmission includes active fast retransmission and active timeout retransmission; active acknowledgment includes active ACK acknowledgment and active SACK acknowledgment, which are explained in detail below: When three identical ACK packets with a TCP payload of 0 are received consecutively from an external port, and the window size of the corresponding connection remains unchanged, the packet corresponding to the reverse sequence of the ACK is found in the packet sending history of the reverse connection of that connection, and a fast retransmission is initiated. Every 5ms, the sending history list of all connections bound to each CPU core is aged. When a packet is found to be released without being confirmed by a reverse ACK within the timeout period, the packet is actively retransmitted after a timeout. Currently, the timeout period is tentatively set at 10ms for external ports and 20ms for internal ports. If it is found that the business is busy in the future, it can be adjusted or dynamically adjusted according to the packet processing time. When a retransmission packet is received from an external port, the system actively responds with an ACK confirmation packet for the latest reverse connection with a TCP payload of 0, in order to remind the external port to send the latest packet instead of a retransmission packet. When a packet is received from an external port, and the CPU on this side knows through its internal synchronization mechanism that the packet has already been received by the CPU on the other side as an ACK confirmation for the reverse connection, it discards the packet and actively responds with the latest ACK confirmation packet for the reverse connection whose TCP payload on the external port is 0. When an out-of-order packet is received from an external port, the most recent consecutive sequence of out-of-order packets is retrieved from the out-of-order packet list of the connection. The external port is actively responded with a SACK acknowledgment packet to inform it of the next sequence that has been received and the missing sequence (between ACK and left SACK). When processing the list of out-of-order packets received by the external port after each polling, if there are still nodes in the list of out-of-order packets after each connection has processed all available out-of-order packets, it actively responds to the external port with a SACK acknowledgment packet, informing it of the next sequence segment that has been received and the missing sequence (between ACK and left SACK).

[0095] S2, iSCSI data stream parsing and encryption / decryption, packet alignment, splicing, and restoration; includes the following sub-steps: Step S21: iSCSI connection management, login parsing, command parsing, task management; After being processed by S1, all packets are strictly handed over to the iSCSI module according to the TCP sequence. When the iSCSI module finds that there is no iSCSI connection for the corresponding TCP connection (the pointer is NULL in the code), it creates the corresponding iSCSI connection using the four-tuple of Initiator IP, Target IP, Initiator port, and Target port as the key. After an iSCSI connection is established, the system rigorously searches for the iSCSI LOGIN command for login resolution, proceeding through Phase I (Login request from Initiator to Target) and Phase II (Login response from Target to Initiator). Only after the response confirms "Login accept," is further iSCSI processing allowed. During login resolution, the Initiator name and Target name (if applicable) are recorded. If the Target name is not found during resolution, it will be located in the subsequent text response. The Target name is used as one of the subsequent block encryption ternary keys. Only after a successful iSCSI login can subsequent commands be parsed and processed. The iSCSI module categorizes iSCSI commands into three types for processing: 1. Commands that require detection and processing by both CPUs, such as Login; 2. Commands that only require detection and processing by the Initiator-side CPU, such as Write command; 3. Commands that require detection by the Initiator-side and processing by the Target-side CPU, such as Read command. Therefore, all commands are parsed and detected by the Initiator-side CPU. If a command requires processing by the CPU on the other side, it will be marked in the internal header so that the Target-side CPU can process it. The software abstracts iSCSI read and write PDU operations into a task. When the CPU on the initiator side detects a write command, it generates a task node in the software. The node records the LUN and base LBA of the write operation. In subsequent packet processing, it updates the processing progress of the write command and the number of data blocks processed to update the LBA value of the block encryption ternary key. This value is placed in the internal header as one of the keys for packet encryption and decryption. At the same time, the LUN value is also placed in the header as one of the keys.

[0096] Step S22, iSCSI command splitting process; When parsing a packet received from the Initiator or Target, if the software finds that the packet is less than 48 bytes long for an iSCSI command, it will mark how many bytes are left to process, then cache the packet and wait for the next packet to be received for processing. Upon receiving the next packet, the previously cached packet is retrieved from the connection, and the unprocessed data is extracted from the packet. This data is then pushed into the TCP payload header of the currently received packet. After iSCSI command parsing, the number of bytes pushed into the packet is marked in the internal header. When the CPU on the other side receives the packet and parses the iSCSI command, it pops the corresponding number of bytes from the beginning of the TCP payload based on the number of bytes in the internal header flags, restoring the original packet length.

[0097] Step S23: iSCSI data alignment, packet assembly, and restoration; Block encryption requires the encrypted data to be of a specified size. Therefore, the software concatenates iSCSI data according to the block size, currently described using a block size of 512 bytes, but other sizes are also supported. Figure 7As shown, if the data in the received packet is not aligned to 512 bytes, the data is borrowed from the payload of the next packet and rounded up to 512 bytes. Based on an MTU of 1500, the maximum TCP payload length can be calculated to be 1460 bytes. Therefore, a packet can have a maximum of three 512-byte blocks.

[0098] When writing data, please note the following: Figure 8 As shown, the CPU on the Initiator side assembles the iSCSI write data into packets according to the block size, and adds the starting offset byte of the data block to be encrypted in the packet and the number of blocks to the internal header, and passes it to the encryption unit for group encryption. After encryption, the CPU on the Target side restores the encrypted data it receives. It should be noted that among the iSCSI write commands, the write same command cannot be implemented in this solution. This iSCSI command needs to be disabled on the Initiator or Target.

[0099] The iSCSI Compare and Write command requires special handling during implementation. The data carried by the command is split into two equal-length blocks. For example, if the command carries 1024 bytes of data, it is split into 512 bytes plus 512 bytes, and then given to the encryption module for encryption using the same key (without adding LBA).

[0100] When reading data, as follows: Figure 9 As shown, the Target-side CPU assembles the read data into packets according to the block size. After assembling the packets, it adds the starting offset byte of the data block to be decrypted in the packet and the number of blocks to the internal header and sends it to the decryption unit for decryption. After decryption, the Initiator-side CPU restores the decrypted data it receives.

[0101] Step S24: Processing the splitting and merging of multiple PDU packets; like Figure 10 As shown, when the protocol stacks of the Initiator and Target send packets, the TCP protocol may paste multiple PDUs into a single packet. The front-end CPU of this software will recognize this situation and divide the multiple PDUs into two packets for separate processing. Part of the data of the first PDU1 is directly divided into the first packet (aligned to 512 bytes) or combined with the first packet of the TCP connection to form a 512-byte aligned packet; the remaining data is directly assembled into the second packet for further processing. Both of these packet divisions require updating the IP header and TCP header of the packet based on the actual content of the divided packet. The second packet generated in the previous step is then processed for packet reassembly. If there are still multiple PDUs in the remaining data, the packet reassembly process continues as in the previous step until only one PDU remains in the remaining data.

[0102] After the packet is split into multiple packets, the front-end CPU marks the packet as a pasted packet in its internal header. After the packet passes through the encryption or decryption unit, when it reaches the back-end CPU, it recognizes that the internal header is a pasted packet. It then merges these multiple packets into one packet and updates the IP header and TCP header based on the merged packet (at this point, the packet length and TCP sequence of the processed message correspond to the packet length and TCP sequence of the initial pasted packet received by the front-end CPU). It recalculates the checksum and sends it to the other end after processing.

[0103] S3, extraction of the ternary key for block encryption and definition of the internal header format; includes the following sub-steps: Step S31: Extract the ternary key for block encryption; Block encryption uses LBA block sizes for encryption, with three keys: device-id, LUN-id, and LBA-id, which are obtained from the following sources: After the TCP handshake connection is established, when the Initiator actively logs into the Target, it sends an iSCSI login packet. Through this login packet, or a subsequent text response packet from the Target, the Initiator parses the Target IQN and maps it to a pre-configured integer value. This is the device-id, one of the three keys for storage encryption and decryption. The Target IQN is a configurable string; therefore, users can configure the device-id value corresponding to the Target IQN. If a user modifies the Target IQN, the corresponding mapping must also be modified.

[0104] When performing read or write operations, the initiator sends a read command or write command, specifying a LUN value in the command. This LUN-id is used as the LUN-id for storing the second of the three encryption / decryption keys. In some cases, the LUN-id in the protocol command may change. Therefore, users can configure the mapping between the LUN-id and the LUN-key used for encryption / decryption, or use technical means to map the LUN-id in the command to the actual LUN value used as the key.

[0105] When performing a write operation, the write command contains the starting LBA and the write length. After the software processes the packets into data aligned by LBA blocks, each packet will have 0 to 3 blocks of data. When the packet is passed to the encryption unit, the LBA base and the number of LBA blocks of each packet will be stored in the internal header as the LBA-id of the third encryption ternary key. Similarly, during a read operation, the starting LBA and read length are parsed from the read command of the Initiator. Then, the corresponding data-in packets are sent from the Target. The software processes and splices the block data to align them. In the internal header added to each packet, the LBA base and the number of LBA blocks of the packet are indicated, which serve as the LBA-id for storing the third of the three-element key for decryption. Step S32, internal header format definition; The internal header serves two purposes: one is to contain keys and control information for encryption or decryption units, such as the start byte of block data and the number of blocks; the other is to provide synchronization information between the two CPUs. The internal header is 32 bytes long, and its format is defined as shown in Table 1 below. Table 1. Format Definition Comparison Table Example 3 In a test embodiment employing the scheme described in Embodiment 1 or Embodiment 2, the encryption / decryption verification system performs the following configuration steps: Add encryption / decryption devices between the server and the storage array. Configure the storage array to add an iSCSI storage mapping to this server, and allocate a 1GB disk for use by the server's IQN host.

[0106] Log in to the storage array on the server using the iscsiadm command. After logging in, lsblk will show an additional disk. Create a file system on this disk. Use the dd command to write two blocks of data (1024 bytes) with all zeros at lba=8192 on the disk. Remove the encryption / decryption devices from the server and storage array, allowing the server and storage array to be directly connected; Restart the server and wait for it to finish restarting. Log in to the storage array on the server using the `iscsiadm` command; after logging in, use `lsblk` to view the disks of the corresponding storage array. As can be seen, the server cannot recognize the file system of this disk. Furthermore, using the `dd` command to read two blocks of data (1024 bytes) at lba=8192 on this disk, the read data is garbled, not all zeros. Moreover, the first 512 bytes and the last 512 bytes are different types of garbled data.

[0107] The above steps confirm that the data was encrypted and stored on the storage array after passing through the encryption / decryption gateway, and that the encryption key involved LBA (the ciphertexts of the two 512 data blocks are different).

[0108] Performance verification (bandwidth, latency) The server and storage array are directly connected, each with four 10G optical ports, and configured with different network segments. Log in to the storage array on the server using the iscsiadm command. After logging in, check the corresponding SD card number. The SD disk was tested on the server using vdbench with the following parameters: I / O length 256K, thread=4, align=512, size=64M. The four disks dm-0 / dm-1 / dm-2 / dm-3, which were identified using the multipath command, were used as test targets. Three tests were performed: read-only, write-only, and read-write. Data was recorded from 1 / 2 / 4 10G optical ports connected to the storage array (2 disks were used for 1-way and 2-way, and 4 disks were used for 4-way). Add the encryption / decryption device between the server and the storage array, and then test again following the steps above. Record the test data, which is shown in Table 2 below. Table 2 Test Data Recording Table Performance loss can be observed through encryption / decryption devices; the bandwidth is approximately 90% of that of a direct connection for read-only operations and 92% for write-only operations. Read latency is greater than write latency.

[0109] Due to the limitations of the performance of a single server and the control card of an array, direct connection has reached its bottleneck. If each 10G port is connected to a server and a control card, with a total of 4 ports tested, the performance can be even better.

[0110] Stability verification The server connects to the storage array via encryption / decryption devices. Using vdbench software with the -vr option, data verification was performed for long-term testing. It ran stably 24 / 7 without error messages, and bandwidth data remained within a consistent range without sudden drops to very low levels or even zero.

[0111] It should be noted that the above performance test data is based on verification using simple and fast encryption / decryption algorithms (e.g., lightweight symmetric encryption algorithms). Its purpose is to evaluate the bandwidth and latency overhead introduced by the data processing framework proposed in this invention (including DPDK packet sending and receiving, protocol parsing, data block alignment, etc.). In actual deployment, the overall system performance will depend on the specific hardware implementation of the selected encryption / decryption algorithm (e.g., whether a hardware encryption / decryption accelerator card or instruction set acceleration is used) and the resulting processing latency. It is understandable that using encryption / decryption algorithms with different complexities, security strengths, and hardware acceleration features will have a corresponding impact on the final overall throughput and latency.

[0112] The above are only some embodiments of this application and do not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for providing iSCSI protocol data security services, characterized in that, Applied to an encryption / decryption device, the encryption / decryption device comprising a first CPU, a second CPU, and an encryption / decryption module, wherein the first CPU is used to process plaintext, and the second CPU is used to process ciphertext; the method includes: On the first CPU and the second CPU, Ethernet packets are sent and received directly from the network card through the user-mode data plane development kit DPDK, and some TCP / IP protocol stack functions are simulated by software to replace the operating system kernel protocol stack in processing the received packets. On the first CPU and / or the second CPU, the data packets processed by the TCP / IP protocol stack are parsed using the iSCSI protocol, and the parsed data is grouped, aligned, spliced, or restored to obtain data units aligned with the encrypted block size. Before the data unit is sent from the first CPU to the encryption / decryption module for encryption, or before the data unit is sent from the second CPU to the encryption / decryption module for decryption, ternary key information is extracted from the iSCSI protocol interaction, and the ternary key information is filled into an internal header format. The internal header format is added to the end of the data unit to guide the encryption / decryption module to perform encryption / decryption operations.

2. The method for providing iSCSI protocol data security service according to claim 1, characterized in that, The first CPU is a front-end CPU connected to the data initiator, and the second CPU is a back-end CPU connected to the data target. Alternatively, when the data transmission direction is from the data target to the data initiator, the second CPU is the front-end CPU and the first CPU is the back-end CPU.

3. The method for providing iSCSI protocol data security service according to claim 1, characterized in that, The method of directly sending and receiving Ethernet packets from the network card via the user-mode Data Plane Development Kit (DPDK) includes: By configuring the receiver to scale RSS, data packets for the same TCP connection can be distributed to the same queue on the network card. The data plane development kit (DPDK) is used to bind the network card's queues to the CPU's processing cores one-to-one. By configuring CPU affinity, the processing threads for sending and receiving packets are bound to the processing core.

4. The method for providing iSCSI protocol data security service according to claim 1, characterized in that, The software simulation of some TCP / IP protocol stack functions specifically includes: TCP connection management, TCP packet ordering, TCP out-of-order packet management, TCP packet sending record management, TCP retransmission mechanism, and active acknowledgment mechanism.

5. The method for providing iSCSI protocol data security service according to claim 4, characterized in that, The TCP retransmission mechanism includes retransmitting old packets and retransmitting new packets; wherein, the processing of retransmitting old packets includes: When the front-end CPU receives an old packet that has been acknowledged by the other end, it strips off the TCP payload, keeps only the header, sets a retransmission flag in the internal header, and then passes it to the back-end CPU. The backend CPU, based on the retransmission flag, searches for the corresponding TCP payload in its own maintained historical packet sending records, fills it into the packet header, recalculates the checksum, and sends it to the peer.

6. The method for providing iSCSI protocol data security service according to claim 1, characterized in that, The operations of parsing the iSCSI protocol and performing data grouping, alignment, splicing, or restoration include: When an iSCSI command is split into two or more TCP packets for transmission, the first arriving packet is buffered. When subsequent packets arrive, the complete command is assembled, parsed, and the splicing information is recorded in the internal header so that the peer CPU can reconstruct the packet length. When the iSCSI data block length is not an integer multiple of the encrypted block size or the boundaries are not aligned, a portion of the data in the next data packet is borrowed, the data is concatenated to the encrypted block size alignment, and the starting offset and number of the aligned data blocks are recorded in the internal header so that the peer CPU can reconstruct the original data. When multiple iSCSI protocol data units (PDUs) are transmitted in a single TCP packet, the packet is identified and split into multiple independent data units for separate processing. The packet-merging information is recorded in the internal header so that the peer CPU can reassemble these independent data units into the original packet.

7. The method for providing iSCSI protocol data security service according to claim 1, characterized in that, The extraction of the ternary key information includes: Parse the target name Target IQN from the interaction messages during the iSCSI Login phase and map it to a device identifier as the first meta key device-id; The logical unit number (LUN) is parsed from the iSCSI read / write command and used as the second meta key (LUN-id). The starting logical block address (LBA) and write length are parsed from the iSCSI write command. Based on the group alignment result, the starting logical block address (LBA) corresponding to each encrypted block in the current data packet is dynamically calculated and used as the third meta key (LBA-id).

8. The method for providing iSCSI protocol data security service according to claim 1, characterized in that, The internal header format is defined as a 32-byte data structure, which contains: The fields used for the encryption / decryption module include the ternary key information, the start offset of the encryption / decryption data block, the block encryption / decryption flag, the data flow flag, and the error flag. Fields used for synchronization between the first CPU and the second CPU include connection status information, retransmission status information, data splicing / splitting information, and control command information.

9. A system for iSCSI protocol data security services, characterized in that, It includes a first CPU, a second CPU, and an encryption / decryption module, wherein the first CPU is used to process plaintext and the second CPU is used to process ciphertext; the first CPU and the second CPU are configured to cooperate in performing a method for an iSCSI protocol data security service as described in any one of claims 1 to 8.

10. A system for iSCSI protocol data security service according to claim 9, characterized in that, The first CPU and the second CPU are two physically independent CPUs.

Images