CN119254454B

CN119254454B - Data security protection method based on link layer transparent encryption

Info

Publication number: CN119254454B
Application number: CN202411070954.XA
Authority: CN
Inventors: 王弘远; 杨柳; 罗桂民; 段佳蕊; 许萱; 王一
Original assignee: Future Gene Beijing Artificial Intelligence Research Institute Co ltd
Current assignee: Future Gene Beijing Artificial Intelligence Research Institute Co ltd
Priority date: 2024-08-06
Filing date: 2024-08-06
Publication date: 2025-07-11
Anticipated expiration: 2044-08-06
Also published as: CN119254454A

Abstract

The application discloses a data security protection method based on link layer transparent encryption, which comprises the steps of determining a plurality of network interfaces of a transparent encryption model, setting the network interfaces into a hybrid mode, starting the hybrid mode, capturing all original data packets passing through a target link, filtering to obtain a plurality of original data packets needing encryption, analyzing the original data packets to obtain information of an IP header, determining the starting position and the length of an IP packet data load, further determining the target data load, encrypting the target data load based on a preset encryption algorithm and an encryption key to obtain an encrypted data load, dynamically updating the information of the IP header based on the encrypted data load, recombining the updated information of the IP header and the encrypted data load into the encrypted data packet, and forwarding the encrypted data packet to the target interface. The method encrypts the network link layer and only encrypts the IP packet data load without configuring IP addresses or modifying network structures, thereby ensuring the normal operation of the existing network system and various devices.

Description

Data security protection method based on link layer transparent encryption

Technical Field

The disclosure relates to the technical field of network data, in particular to a data security protection method based on link layer transparent encryption.

Background

With the rapid development of information technology and the wide spread of network applications, data security has become one of the major challenges facing today's society. Conventional data encryption methods are usually implemented in an application layer or a transport layer, and these methods often need to modify existing network structures or application programs, resulting in problems of high implementation cost, poor compatibility, and the like.

Specifically, the encryption technology disclosed in the prior art mainly comprises the following aspects of 1) encryption at an application layer, namely application programs need to be modified, implementation is complex, seamless integration is difficult to be carried out on an existing system, 2) encryption at a transmission layer, such as SSL/TLS, is widely used, but processing overhead is possibly increased, network performance is affected, 3) encryption at a network layer, such as IPSec, generally needs to be modified, network configuration is increased, deployment difficulty is increased, 4) an end-to-end encryption method is high in safety, but monitoring and management functions of network intermediate equipment are difficult to realize, and 5) encryption at a traditional link layer is generally needed, and the method is high in cost and poor in flexibility.

Disclosure of Invention

In view of this, the embodiments of the present disclosure provide a data security protection method based on link layer transparent encryption, which can solve the problem that the encryption scheme in the prior art affects the existing network structure and application.

In a first aspect, an embodiment of the present disclosure provides a data security protection method based on link layer transparent encryption, where the method specifically includes the following scheme:

determining a plurality of network interfaces of the configured transparent encryption model based on the configuration file or user input information, and setting the modes of the network interfaces as promiscuous modes;

starting a promiscuous mode, capturing all original data packets passing through a target link based on the transparent encryption model, filtering the original data packets to obtain a plurality of original data packets needing encryption, and marking the plurality of original data packets as a plurality of first data packets;

Analyzing the first data packet based on the transparent encryption model to acquire information of an IP header;

Determining the initial position and the length of an IP packet data load based on the information of the IP header, and determining a target data load based on the initial position and the length;

Encrypting the target data load based on a preset encryption algorithm and an encryption key to obtain an encrypted data load;

dynamically updating information of the IP header based on the encrypted data payload;

and reorganizing the updated information of the IP header and the encrypted data load into an encrypted data packet, and forwarding the encrypted data packet to a target interface.

Optionally, the transparent encryption model includes a data packet capturing policy, a data packet filtering policy, a data packet analyzing policy, a data packet encrypting policy and a forwarding policy;

The data packet capturing strategy comprises capturing filter information, capturing buffer area size information, capturing mode information, size information of a data packet to be captured and a preset function.

Optionally, the dynamically updating the information of the IP header based on the encrypted data payload includes:

Based on the encrypted data load, changing the total length of the IP header, wherein the sum of the total length of the changed IP header and the total length of the encrypted data load is consistent with the total length of the original data packet;

And updating the checksum of the IP header based on the total length of the changed IP header, and obtaining the updated IP header.

Optionally, the reorganizing the updated information of the IP header and the encrypted data payload into an encrypted data packet includes:

Configuring a reorganization buffer, wherein the size of the reorganization buffer is not smaller than the sum of the size of the updated IP header and the size of the encrypted data load;

and reorganizing the updated IP header and the encrypted data load in the reorganization buffer area to obtain an encrypted data packet.

Optionally, the reorganizing the updated IP header and the encrypted data payload in the reorganizing buffer to obtain an encrypted data packet includes:

Copying the updated IP header to the starting position of the reorganization buffer;

And placing the encrypted data load after the copy position of the updated IP header, wherein the setting position of the encrypted data load is adjacent to the copy position of the updated IP header.

Optionally, metadata is added in the encryption process, wherein the metadata comprises one or more of an initialization vector and an authentication tag;

the size of the reorganization buffer is not smaller than the sum of the size of the updated IP header, the size of the encrypted data load and the size of the metadata;

In the reassembly buffer, the copy position of the metadata is a position between after the copy position of the updated IP header and before the set position of the encrypted data payload.

Optionally, if the original data packet is a slice, updating a slice offset based on the size of the encrypted data packet;

If the encrypted data packet needs to be transmitted in a slicing way, dividing the encrypted data packet into a plurality of blocks, and updating the slicing offset and more slicing marks of each block.

Optionally, the preset encryption algorithm includes an AES algorithm or a ChaCha20 algorithm;

The method for acquiring the encryption key comprises the following steps:

determining initial parameters of a preset key negotiation mechanism;

Obtaining a local key pair of each communication party based on the initial parameters, wherein the local key pair comprises a local private key and a local public key;

Exchanging a local public key of each communication party based on a preset security protocol;

The method comprises the steps of obtaining a shared secret key based on a local private key and a counterpart public key, wherein the counterpart public key is a local public key sent by an exchange party and received by a communication party corresponding to the local public key;

an encryption key is generated from the shared key using a key derivation function.

Optionally, exchanging the local public key of each communication party based on the preset security protocol includes:

Determining certificate information of a digital certificate, wherein the certificate information comprises a certificate standard, a certificate format, certificate chain information, a certificate verification mechanism and a certificate storage mechanism;

formulating a mutual authentication protocol policy based on the certificate information;

based on the bidirectional authentication protocol strategy and the certificate information, carrying out identity authentication of a first end and a second end, and exchanging a local public key of each communication party based on a preset security protocol after passing the identity authentication;

The first end is a first communication party, and the second end is a second communication party to be subjected to public key exchange.

Optionally, the transparent encryption model further comprises a storm control strategy;

Before forwarding the encrypted data packet, analyzing a traffic mode in a network where the encrypted data packet is located, and determining a traffic type inducing storm;

dynamically regulating and controlling based on the flow type and the storm control strategy;

The storm control strategy comprises one or more of a rate limiting strategy, a token bucket algorithm strategy, a leaky bucket algorithm, a broadcast storm control strategy, a multicast storm control strategy and a priority queue strategy.

In a second aspect, an embodiment of the present disclosure further provides a data security protection system based on link layer transparent encryption, including:

the setting module is used for determining a plurality of network interfaces of the configured transparent encryption model based on the configuration file or the user input information and setting the modes of the network interfaces into a promiscuous mode;

The filtering module is used for starting a hybrid mode, capturing all original data packets passing through a target link based on the transparent encryption model, filtering the original data packets to obtain a plurality of original data packets needing encryption, and marking the plurality of original data packets as a plurality of first data packets;

The acquisition module is used for analyzing the first data packet based on the transparent encryption model and acquiring information of an IP header;

A determining module, configured to determine a start position and a length of an IP packet data load based on the information of the IP header, and determine a target data load based on the start position and the length;

the encryption module is used for encrypting the target data load based on a preset encryption algorithm and an encryption key to obtain an encrypted data load;

an updating module, configured to dynamically update information of the IP header based on the encrypted data payload;

and the reorganization module is used for reorganizing the updated information of the IP header and the encrypted data load into an encrypted data packet and forwarding the encrypted data packet to a target interface.

In a third aspect, an embodiment of the present disclosure further provides a computer apparatus, which adopts the following technical scheme:

the computer apparatus includes:

at least one processor, and

A memory communicatively coupled to the at least one processor, wherein,

The memory stores instructions executable by the at least one processor to enable the at least one processor to perform any one of the link layer transparent encryption based data security protection methods described above.

In a fourth aspect, the disclosed embodiments also provide a computer-readable storage medium storing computer instructions for causing a computer to perform any of the above-described link layer transparent encryption-based data security protection methods.

In a fifth aspect, the presently disclosed embodiments also provide a computer program product comprising a computer program/instruction which, when executed by a processor, implements the steps of the method of any of the preceding claims.

The application discloses a data security protection method based on link layer transparent encryption, which captures all data packets when data is transmitted through a link, filters out the data to be protected in real time and carries out encryption processing, thus realizing the encryption of the data at a network link layer, namely the method can directly start the protection when the data enters a physical link, avoid the exposure of the data on other network layers, improve the instantaneity and reliability of encryption, ensure the confidentiality and the integrity of the data in the transmission process, and simultaneously, carry out encryption technology only for the data load of an IP packet, so that encryption equipment (namely a transparent encryption model) can be directly connected in series to a network without configuring an IP address or modifying a network structure, namely the traditional network structure and application are not influenced, and the normal operation of the traditional network system and various equipment can be effectively ensured. The data security protection method based on the link layer transparent encryption disclosed by the application not only improves the security of data transmission, but also ensures the compatibility and expandability of the network.

The foregoing description is only an overview of the disclosed technology, and may be implemented in accordance with the disclosure of the present disclosure, so that the above-mentioned and other objects, features and advantages of the present disclosure can be more clearly understood, and the following detailed description of the preferred embodiments is given with reference to the accompanying drawings.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings that are needed in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present disclosure, and other drawings may be obtained according to these drawings without inventive effort to a person of ordinary skill in the art.

Fig. 1 is a flow chart of a data security protection method based on link layer transparent encryption according to an embodiment of the disclosure.

Fig. 2 is a flowchart illustrating a method for dynamically updating information of an IP header according to an embodiment of the present disclosure.

Fig. 3 is a flowchart illustrating a method for reorganizing an encrypted data packet according to an embodiment of the present disclosure.

Fig. 4 is a flow chart of the method of reorganizing an updated IP header and encrypted data payload in the reorganization buffer in fig. 3.

Fig. 5 is a flowchart illustrating a method for obtaining an encryption key according to an embodiment of the present disclosure.

Fig. 6 is a flowchart of a method for local public key exchange by different communication parties according to an embodiment of the present disclosure.

Fig. 7 is a schematic block diagram of a data security protection system based on link layer transparent encryption according to an embodiment of the present disclosure.

Fig. 8 is a schematic structural diagram of a computer device according to an embodiment of the disclosure.

Detailed Description

Embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

It should be appreciated that the following specific embodiments of the disclosure are described in order to provide a better understanding of the present disclosure, and that other advantages and effects will be apparent to those skilled in the art from the present disclosure. It will be apparent that the described embodiments are merely some, but not all embodiments of the present disclosure. The disclosure may be embodied or practiced in other different specific embodiments, and details within the subject specification may be modified or changed from various points of view and applications without departing from the spirit of the disclosure. It should be noted that the following embodiments and features in the embodiments may be combined with each other without conflict. All other embodiments, which can be made by one of ordinary skill in the art without inventive effort, based on the embodiments in this disclosure are intended to be within the scope of this disclosure.

It is noted that various aspects of the embodiments are described below within the scope of the following claims. It should be apparent that the aspects described herein may be embodied in a wide variety of forms and that any specific structure and/or function described herein is merely illustrative. Based on the present disclosure, one skilled in the art will appreciate that one aspect described herein may be implemented independently of any other aspect, and that two or more of these aspects may be combined in various ways. For example, an apparatus may be implemented and/or a method practiced using any number of the aspects set forth herein. In addition, such apparatus may be implemented and/or such methods practiced using other structure and/or functionality in addition to one or more of the aspects set forth herein.

It should also be noted that the illustrations provided in the following embodiments merely illustrate the basic concepts of the disclosure by way of illustration, and only the components related to the disclosure are shown in the drawings and are not drawn according to the number, shape and size of the components in actual implementation, and the form, number and proportion of the components in actual implementation may be arbitrarily changed, and the layout of the components may be more complicated.

In addition, in the following description, specific details are provided in order to provide a thorough understanding of the examples. However, it will be understood by those skilled in the art that the aspects may be practiced without these specific details.

Referring to fig. 1, the application discloses a data security protection method based on link layer transparent encryption, which comprises the following steps:

S100, configuring a transparent encryption model.

Specifically, the transparent encryption model comprises a data packet capturing strategy, a data packet filtering strategy, a data packet analyzing strategy, a data packet encrypting strategy and a forwarding strategy, wherein the data packet capturing strategy preferably comprises capturing filter information, capturing buffer area size information, capturing mode information, size information of a data packet to be captured and a preset function.

By setting the size information of the capturing buffer area, the device can adapt to a high-flow environment so as to capture as many data packets as possible in the high-flow environment, because too small a buffer area may cause the data packets to be lost, and too large a buffer area may occupy too much memory.

By setting the capturing filter information, only the data packet of interest can be ensured to be captured, unnecessary data packet capturing is reduced, and the processing efficiency is improved.

By setting the capture mode information, it is possible to choose whether promiscuous mode is enabled or not in order to capture all data packets passing through the network interface, not just data packets sent to the local address.

By setting size information of the data packet to be captured, determining the size of the captured data packet, including whether to capture the entire data packet or just the header of the data packet, capturing the entire data packet may provide more detailed information, but may increase the burden of storage and processing.

The preset function may be a callback function that is triggered whenever a new data packet arrives, and the capture process needs to be efficient and reliable to ensure that no data packet is lost.

The setting of the forwarding strategy can realize the data packet forwarding function and ensure normal network communication, and specifically, a continuously running cycle can be designed for reading the data packets from the network interface, and each captured data packet needs to be processed and forwarded. This flow is the core of the packet forwarding function, and efficiency and reliability need to be considered.

The setting of the data packet analysis strategy can be used for analyzing the content of the data packet after capturing the data packet, which comprises the steps of extracting key information such as a source MAC address, a target MAC address, a protocol type and the like, and the analysis process needs to understand the structures of various network protocols so as to correctly identify and process the data packets of different types.

In order to forward data packets efficiently, the system needs to implement a MAC address learning function, which involves creating and maintaining a MAC address table, and recording the egress interface corresponding to each MAC address. Each time a packet is received, the table is updated to reflect the change in network topology.

Based on the parsed information and the MAC address table, forwarding decisions may be made, including determining to which interface the packet should be forwarded, or whether broadcast is required, and if the destination MAC address is unknown, the system may need to perform a flooding operation.

Once a forwarding decision is made, the next step is to actually send the data packet, which involves transmitting the data packet to the destination interface using the appropriate network API, and the sending process needs to handle errors that may occur, ensuring that the data packet is successfully transmitted.

Further, the transparent encryption model may be a transparent encryption device configured between a core switch and a department switch of an enterprise intranet, or the transparent encryption model may be a transparent encryption function module integrated in a virtual network management platform, or the transparent encryption model may be a transparent encryption module integrated in an IoT gateway device.

S200, determining a plurality of network interfaces of the transparent encryption model based on the configuration file or the user input information, and setting the modes of the plurality of network interfaces to be promiscuous modes.

Promiscuous mode allows the network card to capture all packets transmitted over the physical link, not just the data of the target interface.

In this step the system needs to identify the available network interfaces, typically by using network APIs or specialized network libraries provided by the operating system, and will obtain a list of all available network interfaces, including their names, types and current status, and in particular, select the specific interfaces that need to be set to promiscuous mode based on a profile or user input.

After the interface is selected, the next step is to set it to promiscuous mode, which typically involves using specific system calls or network library functions, in which the network interface will capture all passing packets, not just packets targeted to the host.

Further, after the promiscuous mode is set, it also includes verifying whether promiscuous mode was successfully enabled, which may be done by checking the interface status or specific system files, the verification process ensuring that the interface is indeed in the expected mode of operation, ready for subsequent data packet capture.

S300, starting a promiscuous mode, capturing all original data packets passing through a target link based on a transparent encryption model, filtering the original data packets to obtain a plurality of original data packets needing encryption, and marking the plurality of original data packets as a plurality of first data packets.

Wherein the target link refers to a target network link.

The captured original data packets are filtered, only the data packets needing to be encrypted can be selected to form a first data packet set (namely a plurality of first data packets), namely only the data portions needing to be protected are encrypted, and therefore the efficiency and the response speed of the system can be effectively improved.

S400, analyzing the first data packet based on the transparent encryption model to obtain information of the IP header.

For each selected original data packet, analyzing the first data packet through a transparent encryption model, extracting information of an IP header in the first data packet, wherein the IP header contains important information such as the starting position and the length of a target data load.

Specifically, the information of the IP header may include important information such as a source IP address, a destination IP address, and protocol type information.

S500, determining the initial position and length of the IP packet data load based on the information of the IP header, and determining the target data load based on the initial position and length.

In this step, the first data packet includes an IP header and an IP packet data payload, where the data payload is actually transmitted data content, and the starting position and length of the target data payload in the original data packet are determined according to the IP header information obtained by parsing, which is to accurately determine the target data payload.

After identifying the IP packet structure, the next step is to extract the data payload portion from the entire IP packet, which requires extra care to ensure that header information is not contained in error, and thus requires accurate calculation of the start position and length of the data payload from the information in the IP header, such as the total length field and the header length field.

S600, encrypting the target data load based on a preset encryption algorithm and an encryption key to obtain an encrypted data load.

The preset encryption algorithm comprises an AES algorithm or a Chacha20 algorithm and other algorithms, and the selection of the encryption algorithm needs to consider factors such as security, performance, resource consumption and the like.

The extracted data payload is encrypted using the prepared encryption algorithm and key. This process needs to be done efficiently to minimize impact on network performance, encryption operations should be atomic to ensure data integrity, and if the data load is large, block encryption may need to be considered to optimize performance.

The encrypted data payload ensures confidentiality of the data, i.e. only the authorized recipient can decrypt and read its content.

In this step, only the target data payload is encrypted, the original IP header information is retained, i.e. during encryption the original IP header information has to be fully retained. This includes all fields for source IP address, destination IP address, protocol type, time-to-live (TTL), etc., and preserving this information is critical to ensure that the packet is routed correctly to the destination.

And S700, dynamically updating the information of the IP header based on the encrypted data load.

In particular, while most IP header information remains unchanged, certain fields may need to be updated. In particular, if the encryption process changes the total length of the data packet, the total length field in the IP header needs to be updated accordingly.

S800, the updated information of the IP header and the encrypted data load are recombined into an encrypted data packet, and the encrypted data packet is forwarded to the target interface.

If the size, length or other information of the IP header is not changed during the encryption of the target data payload, the actual operation corresponding to the dynamic update instruction in S700 is not processed, and the updated information of the IP header included in the reassembled encrypted data packet is still the original information of the IP header.

Referring to fig. 2, the method for dynamically updating the information of the ip header specifically includes the steps of:

S710, based on the encrypted data load, changing the total length of the IP header, and the sum of the total length of the changed IP header and the total length of the encrypted data load is consistent with the total length of the original data packet.

When a data packet needs to be encrypted, the encryption process may cause the size of the data packet to change, for example, adding additional information required for encryption, so as to ensure that the size of the whole data packet is consistent with the size of the original data packet, the total length field of the IP header needs to be adjusted.

Specifically, assuming that the original packet size is X bytes, the encrypted packet size is Y bytes, wherein the encryption adds Z bytes of additional information. The new IP header length should be x+z.

By the method, the integrity of the data packet can be maintained, the data packet is ensured not to be discarded or processed by errors due to size change in the transmission process, and the data content is hidden when the data load is encrypted, so that the safety of information protection is improved.

S720, updating the checksum of the IP header based on the total length of the changed IP header, and obtaining the updated IP header.

The IP header contains a header checksum field for verifying the integrity of the header during transmission. This step is important to ensure that the packet is properly handled by the network device, since some fields (e.g., the total length) may be modified, requiring the checksum to be recalculated and updated.

When the total length of the IP header changes, the original checksum needs to be recalculated to accommodate the new header structure.

After the total length of the IP header is changed, the checksum of the IP header is recalculated, specifically, if the IP header length and the checksum of the original data packet are L1 and C1, respectively, and the IP header length of the encrypted data packet becomes L2, the updated IP header checksum C2 should be the checksum calculated based on the new IP header length L2.

In the step, the integrity of the data packet in the transmission process is ensured by updating the checksum, so that transmission errors caused by the change of the IP header are avoided, the integrity of the data packet can be ensured to be correctly verified by a receiving party, and the reliability and the stability of communication are improved.

In the method for dynamically updating the information of the IP header disclosed by the embodiment, the encryption data load ensures the privacy and the safety of data, and the dynamic updating of the IP header ensures the high efficiency and the reliability of data packet transmission, so that the method can be compatible with the existing network communication protocol and does not influence the normal operation of network communication.

In this embodiment, if the original IP contains IP options that typically lie behind the standard IP header and in front of the data payload, special care is required to be taken that the encryption process should not change or encrypt these options, but their location may need to be adjusted to accommodate the encrypted data structure.

Some protocols (such as ICMP) may operate depending on the content of the IP data payload. In this case, special handling mechanisms may need to be implemented to ensure that the encrypted packets are still compatible with these protocols.

After all necessary adjustments are made, the modified IP header may be fully validated to ensure that all necessary fields remain unchanged or are updated correctly to maintain the integrity and validity of the data packet.

Through the detailed steps, the encryption of the IP packet data load can be realized, meanwhile, the IP header information is kept unchanged, the method ensures the safety of the data, and meanwhile, the normal routing and processing functions of a network layer are not influenced.

Referring to fig. 3, the method for reorganizing the encrypted data packet specifically includes the following steps:

S810, configuring a reorganization buffer, wherein the size of the reorganization buffer is not smaller than the sum of the size of the updated IP header and the size of the encrypted data load.

Through the step, the memory space of the configured reorganization buffer area can be ensured to be large enough, and the reorganized IP packets can be accommodated.

Further, if additional metadata (such as initialization vector or authentication tag) is added during encryption, the space for such additional data needs to be considered.

The method comprises the steps of updating the IP header and the encrypted data load, calculating the minimum size of a reorganization buffer according to the updated IP header and the encrypted data load, ensuring that the sum of the two parts can be accommodated, and allocating a memory block with enough size as the reorganization buffer by using a memory management function provided by a programming language or an operating system, wherein the size of the reorganization buffer is not smaller than the sum of the updated IP header and the encrypted data load so as to avoid the problems of overflow or data loss.

In the step, the efficiency and stability of program operation can be improved by pre-distributing and optimizing the memory space, and the recombination buffer area is ensured to be large enough, so that data interception or accidental modification can be effectively prevented.

S820, reorganizing the updated IP header and the encrypted data load in the reorganization buffer to obtain the encrypted data packet.

The method comprises the steps of updating the content of an IP header, copying the content of the updated IP header to the initial position of a reorganization buffer, copying the content of an encrypted data load to the reorganization buffer immediately following the IP header, and tightly connecting to the back of the IP header, wherein the data in the reorganization buffer is a complete encrypted data packet and comprises the updated IP header and the encrypted data load.

In this step, the IP header and the encrypted data payload can be ensured to be correctly combined together to form a complete encrypted data packet, so that overhead generated due to scattered data in the network transmission process can be reduced, and the data transmission efficiency can be improved.

The method for reorganizing the encrypted data packet ensures the consistency and the correctness of the data in the reorganized encrypted data packet through the step-by-step processing, improves the resource utilization efficiency of a system through reasonably configuring the size of a reorganizing buffer area and the memory management, can avoid the system breakdown or the safety problem caused by improper data processing, and improves the stability and the safety of the system.

Referring to fig. 4, a flow chart of a method for reorganizing an updated IP header and an encrypted data payload in a reorganization buffer in fig. 3 specifically includes:

And S821, copying the updated IP header to the starting position of the reorganization buffer.

The method comprises the steps of obtaining data content of an updated IP header, wherein the data content generally comprises information such as a source address, a target address, a protocol type, a data packet length and the like, copying the obtained IP header data to a starting position of a reorganization buffer area according to bytes or bits, and confirming the exact position of the copied IP header in the reorganization buffer area so that an inserting point of an encrypted data load can be correctly positioned in a subsequent step.

In the step, the correct IP header information of the beginning part of the encrypted data packet can be ensured, the identification and processing capacity of the data packet in network transmission can be ensured, the IP header can be quickly embedded through simple copying operation, and the complex data processing steps are reduced.

S822, the encrypted data payload is placed after the updated copy position of the IP header, and the setting position of the encrypted data payload is adjacent to the updated copy position of the IP header.

Specifically, the exact location where the encrypted data payload should be inserted is calculated from the updated position of the IP header in the reassembly buffer, typically after the end of the IP header copy, and then the contents of the encrypted data payload are copied byte-wise or bit-wise to the calculated insertion location, while confirming that the entire contents of the encrypted data payload have been properly inserted into the reassembly buffer.

In the step, the integrity and the correctness of the encrypted data load can be ensured, the risk of data loss or tampering is avoided, and the efficiency and the speed of data processing are improved by directly inserting the data without additional complex calculation.

The scheme disclosed by the embodiment can effectively manage and reorganize the network data packets, is particularly suitable for network communication scenes in which the data packets are required to be encrypted and transmitted, and ensures safe transmission and efficient processing of the data.

The data security protection method based on link layer transparent encryption also comprises the steps of adding metadata in the encryption process, wherein the metadata comprises one or more of an initialization vector and an authentication label;

The benefits of this approach are mainly reflected in the data security protection. Specifically, by adding metadata (such as initialization vector and authentication tag) during encryption, the security and reliability of data encryption can be improved. In addition, the design of the reorganization buffer area considers the size of the updated IP header, the size of the encrypted data load and the size of the metadata, and ensures the integrity and usability of the encrypted data. The copy position of the metadata is set at a proper position between the updated IP header and the encrypted data load, which is helpful for effectively managing the processing and reorganization process of the encrypted data, and further enhances the security in the data transmission process. In summary, this approach focuses not only on the cryptographic protection of data, but also on metadata management and reorganization design during protection to ensure the security and integrity of data in transmission and storage.

In this application, if the original packet is a slice, the slice offset is updated based on the size of the encrypted packet;

if the encrypted data packet needs to be transmitted in a slicing way, dividing the encrypted data packet into a plurality of blocks, and updating the YY+242200P of each block

Slice offset and more slice flags.

In this embodiment, the determination of whether the encrypted data packet needs to be transmitted in slices specifically includes determining whether the size of the encrypted data packet exceeds the maximum slice size allowed by the transmission protocol, and if so, determining that the encrypted data packet needs to be transmitted in slices.

In this embodiment, the encryption process should not affect these fields to ensure proper reassembly of the fragments.

In the case of handling encrypted packet fragmented transmissions, two main steps are involved, updating the fragmentation offset and the fragmentation flag. When the original packet is a slice, the slice Offset (Fragment Offset) refers to the Offset of the slice relative to the start position of the original packet. When reassembling encrypted data packets, the offset of each fragment needs to be updated according to the size of the encrypted data packet to ensure that they correctly correspond to the locations in the encrypted data packet.

Specifically, assuming that the encrypted packet size exceeds the maximum capacity of a single slice, the offset of each slice needs to be adjusted accordingly to reflect its correct position in the encrypted packet. This is typically accomplished by recalculating the fragment offset to ensure that all fragments are correctly restored to a complete encrypted data packet after reassembly.

If the encrypted packet needs further fragmented transmission, even the encrypted packet needs to be split into smaller blocks (fragments) during transmission, each block requiring updated information including a fragment offset and more fragment flags.

Specifically, each fragment needs to update its fragment offset to ensure that the original encrypted data packet can be correctly reassembled at the receiving end. At the same time, more Fragments (MF) flags need to be set to indicate whether there are more fragments waiting to be transmitted.

The more fragments flag specifically includes that the MF flag of the first fragment is set to 1, which indicates that there are more fragments in the back, the MF flag of the middle fragment is also set to 1, which indicates that there are more fragments in the back, and the MF flag of the last fragment is set to 0, which indicates that this is the last fragment.

For example, assuming that the original packet size is 5000 bytes, the maximum slice size allowed by the protocol is 1000 bytes, so the original data needs to be divided into 5 slices for transmission. After encryption, the packet size becomes 5500 bytes, and therefore needs to be divided into 6 fragments.

The original shards include shard 1:1000 bytes, mf=1, shard 2:1000 bytes, mf=1, shard 3:1000 bytes, mf=1, shard 4:1000 bytes, mf=1, shard 5:1000 bytes, mf=0.

In this example, the encrypted packet requires an additional slice, thus updating the MF flag for all slices and ensuring that the MF flag for the last slice is 0.

The method has the advantages that the problem of transmission delay or packet loss caused by overlarge single data packet can be avoided through the split transmission, the data transmission efficiency is improved, the receiving end can be ensured to correctly reconstruct the encrypted data packet by updating the split offset and the split mark, the data integrity and the reliability are ensured, the method can adapt to different network environments and transmission conditions, and the data packet can be effectively transmitted and reconstructed in a network.

The fragmentation offset and the fragmentation mark are updated, so that the fragmentation of the encrypted data packet can be effectively managed and transmitted, the safe transmission and efficient processing of the data are ensured, and meanwhile, the stability and reliability of the system under various network environments are ensured.

The addition of encrypted data payload to the buffer, immediately following the IP header (and possibly the encrypted metadata), is required to ensure alignment and integrity of the data, especially when handling large data packets. If the encryption process generates metadata (e.g., initialization vectors) that needs to be transmitted with the data, the data typically needs to be inserted at a location after the IP header and before the data payload is encrypted, by carefully designing the format and location of the metadata to ensure that the recipient can properly identify and use them.

Referring to fig. 5, the method for obtaining the encryption key specifically includes the following steps:

a100, determining initial parameters of a preset key negotiation mechanism.

Specifically, the Diffie-Hellman (DH) variants used are determined, such as classical DH, elliptic Curve DH (ECDH), etc., and appropriate security parameters are selected, including prime numbers p, generator g, or appropriate elliptic curves (for ECDH) for the Diffie-Hellman (DH) variants, to ensure that the selected parameters meet the latest security standards and recommendations.

In this step, determining the initial parameters ensures that all parties use consistent basic settings, simplifying implementation of key negotiations, and selecting standardized key negotiating mechanisms and parameters improves system compatibility and interoperability.

A200, obtaining a local key pair of each communication party based on the initial parameters, wherein the local key pair comprises a local private key and a local public key.

The method comprises the steps of generating a private key for each communication party, wherein the private key is a large random integer, calculating a public key based on the private key and initial parameters, ensuring that each communication party generates a secret key pair, namely each communication party has a secret key pair, ensuring the privacy and the safety of secret key generation, and simultaneously, generating the secret key pairs independently, wherein each communication party only needs to generate a secret key of itself without depending on secret key information of other parties.

Wherein a cryptographically secure random number generator (cspng) may be used to generate the private key.

A300, exchanging the local public key of each communication party based on a preset security protocol.

A secure protocol may be designed to exchange public keys, which may involve using pre-established secure channels or using digital signatures to implement the serialization and de-serialization mechanisms of public keys to ensure integrity during network transmission, while adding time stamps or sequence numbers may also be considered to prevent replay attacks.

Specifically, public keys of each communication party are exchanged by using a preset security protocol (such as TLS), the communication party A sends a local public key Q _A of the public key to the communication party B, the communication party B also sends a local public key Q _B of the public key to the communication party A, and the public key exchange is performed through an encryption channel (such as TLS) so as to protect data security in the exchange process.

Through the step, all communication parties can be ensured to obtain public keys of other parties so as to calculate the shared secret key, and the public keys are exchanged through the encrypted channel, so that man-in-the-middle attacks and other potential security threats are reduced.

Further, the received public key may also be verified, i.e. a public key verification mechanism is implemented, checking if the received public key is valid and not tampered with.

For ECDH, it is ensured that the received public key is indeed located on the specified elliptic curve, and additional security measures to enable public key verification, such as the use of certificates or pre-shared keys, may also be considered.

A400, obtaining a shared key based on the local private key and the opposite party public key, wherein the opposite party public key is the local public key sent by the exchange party and received by the communication party corresponding to the local public key.

Specifically, the DH shared secret is calculated using the local private key and the received partner public key.

Where for classical DH this involves modular exponentiation and for ECDH this involves point multiplication, a special large database may be used in order to ensure that the implemented algorithm is capable of handling large integers.

Each communicating party calculates a shared key using its own local private key and the public key of the other party. For example, communication party a calculates a shared key k=d _A times Q_B using its own private key d _A and communication party B's public key Q _B. Communication party B then calculates the shared key k=d _Btimes Q_A using its own private key d _B and communication party a's public key Q _A.

In this step, the calculation process of the shared key uses the mathematical characteristics of the key pair, ensuring the security and uniqueness of the generated shared key, and simultaneously ensuring that both parties can generate the same shared key for subsequent encryption and decryption operations.

A500, an encryption key is generated from the shared key using a key derivation function.

In particular, a key derivation function (e.g., HKDF, PBKDF2, etc.) may be used to generate the actual session key from the DH shared key.

The final encryption key is generated by a key derivation function using the shared key as input. The key derivation function may further process the shared key, add salt values (salt), iteration number, etc., to enhance the security of the key.

It is considered to generate multiple keys for different purposes (e.g. encryption keys, authentication keys), and further, other context information (e.g. both identities, protocol versions) can be included to enhance security during the key derivation process.

The key derivation function can enhance the security of the key, resist various attacks such as brute force cracking, and can generate a plurality of keys for different purposes (such as encryption, signature and the like) so as to meet different security requirements.

The method for acquiring the encryption key disclosed by the embodiment ensures the safety and reliability of the encryption key through a standardized key negotiation and generation mechanism, ensures the compatibility and interoperability of a system by using standard protocols and methods (such as Diffie-Hellman, ECDH, TLS and the like), provides strong data protection by using encryption key generation and key derivation functions, ensures the confidentiality and integrity of information, and reduces potential safety risks such as man-in-the-middle attacks and key leakage by using modern encryption technology in the whole process.

Further, the application comprises verifying the key agreement result, in particular, implementing a key confirmation step, ensuring that both parties successfully generate the same session key, which can be done by exchanging and verifying predefined messages encrypted using the new key, considering the use of a key-based authentication method, such as HMAC, to verify the correctness of the key.

The application also includes periodically updating the session key through a key update policy to improve security. The key updating strategy comprises the steps of determining conditions such as time intervals, data volume thresholds or session duration, which trigger key updating, and designing a flexible strategy which can allow updating frequency to be adjusted according to actual requirements by considering network environment and application scene and balancing security and performance requirements.

The application also includes implementing a key update protocol, specifically, designing a secure protocol to coordinate the key update process of both parties, including version numbers or time stamps, to prevent degradation attacks and replay attacks, considering the use of the current session key to protect the key update process itself.

The application also includes generating new keying material, specifically creating a new DH private key using a cryptographically secure random number generator, and then computing a corresponding new public key, and may also consider using different DH parameters (e.g., different primes or elliptic curves) to increase diversity.

The application also includes a secure exchange of the new public key, specifically, encrypting the new public key for transmission using the current session key, a mechanism can be implemented to confirm that both parties successfully received the new public key, and additional authentication mechanisms, such as digital signatures, can be considered to be added to verify the authenticity of the new public key.

The application also includes calculating a new shared key, specifically, calculating a new DH shared key using the new private key and the received new public key, verifying that the newly generated shared key is different from the previous key, and implementing an error handling mechanism to cope with a failure of the key calculation.

The application also includes deriving a new session key, specifically, generating a new session key from a new shared key using a key derivation function, and may also consider adding additional context information, such as update times or time stamps, during the key derivation process, ensuring secure isolation of new and old key materials, preventing potential key leakage.

The application further includes synchronous switching to new keys, specifically a mechanism can be designed to coordinate both parties to switch to new session keys at the same time, a short transition period can be considered to be implemented, new and old keys can be accepted simultaneously during the period to process network delay, and further a rollback mechanism can be considered to be implemented to cope with problems possibly occurring in the process of updating the keys.

The application also includes the secure destruction of the old key, in particular to implement a secure memory erasure technique to thoroughly remove the old key material. Special secure memory management techniques, such as memory overwriting or using encrypted memory regions, are contemplated to ensure that sensitive key information is not revealed in the log and error report.

The application also includes verification and record key updates, implementing a process to verify the correctness and validity of the new key. Key update events are recorded, including time stamps and associated metadata, but no actual key material is recorded. An audit mechanism is contemplated to be implemented to track and analyze the key update pattern.

Through the detailed steps, a secure key negotiation mechanism based on a Diffie Hellman algorithm can be realized, and a session key is updated periodically to improve the security, so that the method ensures that both communication parties can establish and maintain a secure encryption channel, and simultaneously potential key leakage risks are reduced through periodic updating. In practical implementation, factors such as performance optimization, error recovery, compatibility, expandability and the like also need to be considered, so that the system can safely and efficiently operate under various network environments and use scenes.

Referring to fig. 6, a method for local public key exchange by different communication parties provided in an embodiment of the present disclosure specifically includes the following steps:

B100, determining the certificate information of the digital certificate, wherein the certificate information comprises a certificate standard, a certificate format, certificate chain information, a certificate verification mechanism and a certificate storage mechanism.

The certificate standard may be x.509, which is a widely used standard for defining the format and content of digital certificates.

The certificate format may be PEM (Privacy EnhancedMail) code format or DER (Distinguished Encoding Rules) code format, which specify the manner in which the certificate data is encoded.

The certificate chain information includes a hierarchical relationship defining a certificate chain including a root certificate issued by a trusted Certificate Authority (CA), an intermediate certificate for verifying the root certificate, and a terminal certificate for a specific communication party.

Certificate verification mechanisms include how to verify the validity, integrity and authenticity of a certificate, such as by Certificate Revocation Lists (CRLs) or Online Certificate Status Protocols (OCSP).

Certificate storage mechanisms are used to determine the location and manner in which certificates are stored, for example in a local disk, in a Hardware Security Module (HSM), or through a public certificate store.

In the step, the consistency and interoperability of the system can be ensured by following a standardized certificate format and a standardized verification mechanism, the security and the credibility of the certificate are enhanced by defining a detailed certificate chain and a detailed verification mechanism, and the use and maintenance process of the certificate are simplified by a systematic certificate storage and management strategy.

Further, a certificate error processing mechanism, namely a detailed error reporting mechanism is developed, so that the reason of the certificate verification failure can be accurately described, a flexible error processing strategy is realized, and certain verification steps are allowed to be bypassed under certain conditions (such as emergency). User-friendly false alarms may be designed to help an administrator or user understand and resolve the credential problem.

B200, formulating a mutual authentication protocol strategy based on the certificate information.

The two-way authentication protocol policy comprises a first end identity authentication policy, a second end identity authentication policy and an authentication sequence policy, namely, the authentication of each end identity can be realized through the two-way authentication protocol policy.

In particular, standard protocols such as TLS WITH CLIENT authentication or custom protocols may be used, where protocol message formats may include certificate exchanges, challenge response mechanisms, and the like.

B300, carrying out identity authentication of the first end and the second end based on a bidirectional authentication protocol strategy and certificate information, and exchanging a local public key of each communication party based on a preset security protocol after passing the identity authentication;

In this embodiment, the second party forms a set of key exchange groups with the first party.

Specifically, for identity authentication of a first end (e.g., a server), the first communication party (first end) sends its digital certificate to a second communication party (second end), and the second end verifies the validity and authenticity of the certificate, verifying the identity of the first end.

For authentication of the identity of the second end (e.g., client), the second party (second end) also sends its digital certificate to the first party, which verifies the validity and authenticity of the certificate, verifying the identity of the second end.

Further, the identity authentication includes verification of a digital certificate and/or key authentication.

The verification method for the digital certificate specifically comprises verifying the validity of the digital certificate, wherein the certificate chain verification process comprises checking whether the certificate is issued by a trusted CA and the validity of the intermediate certificate and the root certificate, which involves verifying the signature, i.e. ensuring that the signature of the server certificate is signed by the trusted CA and can be verified by the root certificate chain, checking the validity period, requiring that the validity period of the certificate is within the current date, checking whether the certificate has been revoked, i.e. verifying whether the certificate has been revoked by means of a Certificate Revocation List (CRL) or an Online Certificate Status Protocol (OCSP), and hostname verification, i.e. the client also needs to verify whether the hostname in the certificate matches the actually accessed server hostname.

This process includes extracting the hostname, i.e., from the "Subject" or "SubjectAlternative Name" fields in the certificate, and matching the extracted hostname with the server hostname requested by the client to ensure that they are consistent.

The method for key authentication specifically includes taking identity authentication of a first end as an example, the first end can sign some data by using its private key to prove that the first end does hold the corresponding private key, the first end signs a piece of data by using the private key, and adds the signature to a certificate or sends the signature to a second end in a handshake protocol, and the second end can use a public key of a server (extracted from the certificate) to verify validity of the signature. The second end uses the public key to verify the signature, ensuring that the first end does hold a private key that matches the public key in the certificate.

The second end can confirm that the certificate of the server is legal through the key holding proof, and the first end does possess the secret key matched with the certificate, thereby further guaranteeing the safety of communication.

After the two parties successfully pass the identity authentication, the two parties of the communication are confirmed to be authenticated legal entities.

The successful identity authentication establishes a trust basis between the two communication parties, lays a foundation for subsequent public key exchange and encrypted communication, can prevent malicious attackers from forging identities or interfering with the communication process, and can effectively improve the security of the system.

Exchanging the local public key of each communication party based on a preset security protocol includes selecting a preset security protocol, such as TLS (transport layer security protocol), for encrypting the public key exchange process, and exchanging the local public keys of the two parties through the security protocol after the mutual authentication is successful. The first end sends the public key to the second end, the second end also sends the public key to the first end, and the security protocol is used for encrypting the public key exchange process to ensure that the public key is not stolen or tampered in the transmission process.

In the step, the public key is protected from being attacked or tampered by a man-in-the-middle or data by the security protocol encryption public key exchange process, the received public key is ensured to be really from a legal communication party by the public key exchange after the two-way authentication, and the public key exchange process is integrated into the existing security protocol, so that the implementation process is simplified and the efficiency is improved.

The method for carrying out local public key exchange by different communication parties disclosed by the embodiment ensures the authenticity of the identities of the communication parties through the digital certificate and the two-way authentication mechanism, encrypts the public key exchange process through the security protocol, improves the overall security of the system, adopts the standardized certificate and authentication mechanism, improves the compatibility and interoperability of the system, establishes the trust basis between the communication parties through successful two-way authentication, provides guarantee for safe data transmission and key exchange, simultaneously can reduce the security risks such as man-in-the-middle attack, counterfeiting of the identities and the like, and improves the protection capability of the system.

Further, the application also includes integrating the mutual authentication process with the Diffie-Hellman key exchange while ensuring that the integrity of the authentication process is not affected by the key exchange process.

Furthermore, the application also comprises binding the negotiated session key with the authenticated identity to ensure that the generated key corresponds to the actual authenticated identity, which is helpful to prevent the key from being used for other communication sessions without authentication, and through the identity binding, the key can be verified to be really used for the session with authentication, thereby improving the credibility of the communication.

Further, the application also includes implementing a session recovery mechanism that allows re-use of authenticated sessions in a short period of time, thereby avoiding the overhead of each re-authentication and key agreement for improving performance and efficiency, in particular, authenticated session information (e.g., session key, authentication state) may be cached for quick retrieval and use upon session recovery, and a specific protocol or identifier may be used to confirm and recover the prior session state upon session recovery, instead of re-authenticating and key exchanging, thereby effectively reducing the frequency of re-authentication and key exchanging, improving the response speed and performance of the system, and at the same time effectively reducing the computation and network overhead due to re-authentication and key agreement.

Further, the application also contemplates implementing a key derivation function for deriving additional key material, i.e., the key derivation function allows other key material to be derived from the session key that has been negotiated, which may be used for different purposes such as encryption, message Authentication Code (MAC), or other security operations. In particular, additional keying material is generated from the session key using key derivation functions that ensure that the generated keying material has the required security and randomness, define the type and purpose of the derived key, and ensure that the key derivation process meets the security requirements without revealing or misusing the session key.

Further, the application also comprises integrating the authentication result with the access control system, realizing fine granularity authority control based on the certificate attribute (such as an extension field), developing a dynamic authority adjustment mechanism, and allowing the user authority to be adjusted in real time based on the authentication result.

Specifically, the results (such as user identity, role and authority) in the authentication process are combined with the access control system, so that the authenticated user can access the system resources according to the identity and authority of the authenticated user.

Further, interfaces or modules are developed so that the authentication system and the access control system can exchange information in real time. For example, after the user successfully authenticates, the system can configure corresponding rights in the access control system according to the identity information of the user.

Through integration, the user identity and authority can be managed in a system, the management efficiency is improved, only authenticated users can access specific resources, and the security of the system is enhanced.

Implementing fine-grained rights control based on certificate attributes refers to using attributes in a digital certificate (e.g., extension fields, certificate issuer information, etc.) to achieve fine-grained access control. In particular, attribute information in the credentials, such as roles, departments, permissions, etc. of the user may be extracted, and then detailed permission rules may be defined in the access control system based on these attributes, e.g., a "department" field included in the user credentials may be used to restrict access to certain department resources, may provide more detailed and accurate permission management, so that the user may only access resources for which they are authorized, may define different permission rules based on different attributes in the credentials, and may improve the flexibility of the permission management.

The developed dynamic authority adjustment mechanism allows the system to adjust the authority of the user according to the real-time situation or the authentication result after the user authentication, and the mechanism is generally used for coping with the dynamically-changed requirement or safety requirement. Specifically, the implementation mechanism may monitor the status of the user and the permission request in real time to decide whether to adjust the permissions, automatically adjust the permissions of the user based on the authentication results and policies in the system, e.g., if the authentication information of the user indicates that they have completed additional training, their permissions may be automatically promoted.

Further, a policy engine can be designed, the user authority can be dynamically adjusted according to the authentication result and the current environmental condition, the user identity change or service demand change can be rapidly adapted, the flexibility of the system is improved, and potential security threats can be responded in time by dynamically adjusting the authority, so that risks are reduced.

Furthermore, the application also comprises the management of the authentication session, in particular comprising the creation, maintenance and destruction mechanisms of the authentication session, developing the session timeout and reauthentication strategies and realizing the safe session cancellation mechanism.

Creation of an authentication session includes creating a session after the user has successfully completed authentication, typically including user identity information, permissions, session identifiers, etc., which may be stored on a server side (e.g., memory, database) or on a client side (e.g., in a browser's session store).

Wherein the session identifier is a generated unique session ID as an identification identifying the user session.

The maintenance of the authentication session refers to maintaining the state of the session during the validity period of the session, so as to ensure that the operation and access rights of the user are correctly processed.

The destruction mechanism of the authentication session refers to that the session needs to be destroyed when the session is no longer needed (such as user logout, session expiration, etc.) so as to release resources and protect user privacy, in particular, delete session data from storage, terminate the validity of the session ID, and prevent the session from being maliciously used.

Further, the present application also includes recording all authentication related activities, including authentication attempts and results, which can help monitor authentication processes, diagnose problems, track security events, etc. Wherein, the authentication attempt includes recording the time of each authentication attempt, the identity (or identifier) of the user, the authentication mode (such as password and fingerprint), the authentication result (success or failure), etc.

Further, the application also comprises a safe log storage and transmission mechanism, which aims to prevent the log data from being tampered, lost or leaked and ensure the integrity and confidentiality of the log data. In particular, the log data may be encrypted using encryption techniques to prevent unauthorized access or tampering, and may be stored in a protected storage medium, such as a controlled server or a dedicated log storage service.

Furthermore, the application also comprises an audit function which allows an administrator to trace back and analyze the authentication history to carry out security audit and compliance check.

Further, the present application also includes a configuration error handling and failure recovery mechanism that provides a friendly and useful error message when user authentication fails, while handling the failure situation to ensure that the user experience is not unduly impacted.

In particular, friendly and useful means providing clear, concise and technical details-free error messages, such as "user name or password incorrect", avoiding the disclosure of too much information (such as whether a specific user name is present) to reduce potential security risks.

Further, a retry strategy may be developed to handle temporary authentication failures, implementing mechanisms to prevent brute force cracking, such as failure frequency limitation or progressive delay. The retry strategy is used for handling temporary authentication failure situations, such as failures due to network problems or short service interruption, specifically, after authentication failure, re-authentication is automatically attempted, especially for temporary problems such as network fluctuation, reasonable retry interval time can be set, so that the system is prevented from being burdened by too frequent attempts, for example, the retry interval is increased after each failure, the waiting time is gradually increased, and feedback is provided to a user in the retry process, for example, the system is retrying login and is later.

Preventing brute force cracking refers to preventing malicious users from cracking account passwords through exhaustion by limiting the number of attempts or increasing delays. Specifically, after a certain number of authentication failures (e.g., 5 times), the account is temporarily locked, preventing further attempts, notifying the user and providing an indication to unlock the account when the account is locked (e.g., sending a registration mailbox that is unlocked to the user).

The delay time may be increased after each authentication failure. For example, a delay of 10 seconds is added after each failure, so that the number of attempts is slower and slower.

An upper limit may be set, for example, up to 5 minutes delay, preventing the delay time from being too long to affect the user experience.

After multiple failures, the user is required to complete CAPTCHA authentication to ensure that manual users are operating instead of automated attack tools.

Furthermore, the application also comprises a certificate caching mechanism which is used for reducing the expenditure of repeated verification, and by caching the verified certificate or authentication data, repeated verification operation during each authentication is avoided. Specifically, the verification result, authentication information, or session data of the certificate may be cached. Common caching technologies include memory caching, distributed caching (such as Redis) and the like, and reasonable caching expiration time can be set to ensure the effectiveness and the safety of cached data. For example, the cache authentication result may be set to several minutes to several hours, adjusted according to specific requirements.

Updating the cache to maintain the accuracy of the data when the certificate or authentication information changes, and re-verifying and updating the cache when the cache is out of date or invalid.

Further, it is also contemplated that hardware acceleration (e.g., dedicated encryption hardware) may be used to accelerate encryption and decryption operations by using dedicated hardware (e.g., encryption chips or encryption cards) to increase the efficiency of the authentication process. The method comprises the steps of using a hardware encryption module (HSM, hardware security module) to execute encryption operation to provide high performance and security, installing a special encryption card in a server to process encryption and decryption tasks, relieving the burden of a main processor, integrating a hardware acceleration component into an authentication system to ensure compatibility with a software component, optimizing an encryption algorithm according to hardware characteristics, and improving acceleration effect.

Further, the application also comprises a strategy for configuring and processing a plurality of authentication requests simultaneously, and the strategy can process a plurality of authentication requests simultaneously, so that the throughput and the response capability of the system are improved. The method comprises the steps of managing and scheduling threads for processing a plurality of authentication requests by using a thread pool technology, improving concurrent processing capacity, adopting an asynchronous processing mechanism, allowing a system to continue to process other requests while waiting for an authentication result, reducing response time, distributing the authentication requests to a plurality of servers or processing units by using a load balancer, uniformly distributing loads, and expanding the processing capacity of the system by adding more server instances or processing nodes.

Through the scheme, a powerful digital certificate support and a bidirectional identity authentication mechanism can be realized, and the method ensures that two communication parties can reliably verify the identities of each other, and simultaneously provides a solid foundation for subsequent secure communication. In practical implementation, the factors such as expandability, interoperability and user experience are also required to be considered, so that the system can safely and efficiently run under various complex network environments and use scenes, and meanwhile, continuous safety evaluation and updating are also key for keeping the system safety.

Further, the application also comprises performance optimization and monitoring, wherein the performance optimization comprises hardware acceleration and packet processing flow optimization.

Hardware acceleration increases the performance of the system, particularly the efficiency of encryption operations, through dedicated hardware components (e.g., dedicated encryption chips), thereby reducing the burden on the CPU.

A dedicated encryption chip, such as an HSM, hardware security module, is a hardware device specifically designed to accelerate encryption and decryption operations.

Specifically, the encryption chip is integrated into the system to process the encryption and decryption tasks, so that all encryption operations are processed by special hardware instead of relying on a main CPU, and the speed and efficiency of the encryption operations are improved by selecting and optimizing a proper encryption algorithm according to the capability of the encryption chip.

The special encryption chip processes the encryption task faster than the general CPU, the encryption efficiency of the system is obviously improved, the encryption task is transferred to the special hardware, the occupation of the main CPU is reduced, and resources are vacated for processing other tasks.

The optimization of the data packet processing flow aims at improving the processing speed of the data packet and reducing the processing load of a CPU, especially when processing network data packets. Specifically, a Network Interface Card (NIC) or other hardware acceleration components are used for unloading the data packet processing task from the main CPU to the special hardware, so that the receiving, processing and transmitting processes of the data packet are optimized, and the processing time of the CPU is reduced. For example, the processing delay is reduced by processing a plurality of data packets at one time by a batch processing technology, and the frequent access to storage or network is reduced by using a cache (such as a memory cache), so that the processing efficiency of the data packets is further improved.

Monitoring may be based on a performance monitoring module that may be used to monitor the performance of the system in real time, including throughput and latency of encryption operations, as well as providing performance reporting and alerting mechanisms.

Preferably, the encryption throughput and delay can be monitored in real time, specifically, a monitoring tool or a custom script can be used to collect real-time performance data of the encryption operation, such as throughput, delay, error rate, etc., the performance indexes can be displayed in real time through a dashboard or monitoring interface, so that an administrator can conveniently check and analyze the performance state of the system, and a performance threshold, such as maximum allowable delay or minimum throughput, can be set so as to discover and process performance bottlenecks in time.

Performance reporting and alerting mechanisms may also be provided, specifically, generating periodic (e.g., daily, weekly) performance reports, aggregating data of metrics such as encrypted throughput, latency, etc., and analyzing trends, while allowing custom reports to be generated as needed, looking at data of specific time periods or specific performance metrics.

For the alarm mechanism, alarm rules can be set, when the performance index exceeds a preset threshold, alarm notification (such as mail, short message or system notification) is automatically sent, advice or operation steps for processing the alarm can be provided, and an administrator can be helped to quickly solve the problem.

Further, the present application also includes compatibility and extensibility design mechanisms to ensure that the system is capable of operating in different network environments and is capable of integrating with other systems through API interfaces.

The design mechanism can adapt to different network topologies, wherein the network topologies refer to the layout modes of all devices and nodes in a network, and the system can be ensured to normally operate under various network settings by adapting to different network topologies.

Specifically, when designing the system architecture, different network topologies (such as star, ring, mesh, etc.) are considered to ensure that the system components can be connected in different topologies, multiple network protocols (such as TCP/IP, UDP, etc.) can be supported to enable the system to be used in various network environments, a simple configuration interface can be provided to allow a user to flexibly adjust the system settings according to the specific network topology.

The design mechanism also supports virtual network environments (e.g., SDN, NFV), which refer to network architectures that use Software Defined Networking (SDN) and Network Function Virtualization (NFV) technologies, which can improve the flexibility and scalability of the system.

The system is designed to support SDN architecture, network resources can be configured dynamically under the condition of centralized control, the system can be deployed in an NFV environment, network functions are operated on standard hardware by using a virtualization technology, and management tools are provided, so that users can adjust virtual network resources dynamically to meet different requirements.

The design mechanism may provide an API interface to facilitate integration and interaction with other systems, supporting expansion and functional integration of the systems.

Specifically, RESTfulAPI may be designed to facilitate integration with other systems.

Plug-in mechanisms may also be implemented to support functionality expansion, i.e., allow a developer to add new functionality or expand existing functionality without modifying the system core.

In particular, a clear plug-in interface can be designed so that third party developers can develop their own plug-ins according to the interface specification, and plug-in management tools can be provided to allow users to easily install, uninstall, and enable/disable plug-ins. At the same time, the compatibility of the plug-in and the core system is ensured, and the backward compatible API and data structure are provided.

Further, the transparent encryption model also includes storm control policies for maintaining network stability and preventing broadcast storms.

Specifically, before forwarding the encrypted data packet, analyzing a traffic pattern in a network where the encrypted data packet is located, and determining a traffic type inducing storm;

dynamic regulation and control are carried out based on the flow type and storm control strategy;

Storm control policies include one or more of rate limiting policies, token bucket algorithm policies, leaky bucket algorithms, broadcast storm control policies, multicast storm control policies, priority queue policies.

Storm control strategies in transparent encryption models help to maintain network stability and prevent broadcast storms. The strategies can be dynamically adjusted according to the flow mode of the network where the encrypted data packet is located, and concretely comprise rate limitation, token bucket algorithm, leaky bucket algorithm, broadcast storm control, multicast storm control and the like, network congestion and breakdown caused by overload can be effectively prevented by limiting specific types of flows or adjusting the transmission rate of the flows, network resources can be effectively utilized by controlling and scheduling the flows, timely transmission of key data is ensured, malicious attacks or unexpected broadcast storm events are prevented, the network is protected from unauthorized access or destruction, and the strategies can be adjusted according to the real-time network flow conditions so as to adapt to different network environments and application requirements, thereby improving the adaptability and flexibility of the system.

The comprehensive application of the policies can effectively optimize the network performance and the security, and ensure the safe transmission and the stable operation of the encrypted data.

Further, the application also comprises a comprehensive error processing mechanism and a log system. This includes capturing and recording anomalies that may occur, as well as recording critical events and statistics, and good error handling and logging is critical to system maintainability and problem diagnosis.

In particular, rate limiting (RATE LIMITING) includes preventing the network from being overwhelmed by excessive traffic by limiting the sending rate of a device or application, which may be applied to a single device, a particular service, or the entire network.

The token bucket algorithm (Token BucketAlgorithm) is a traffic shaping technique that allows a network device to send a certain number of data packets in a certain time, generate tokens at a fixed rate and put them into a bucket, and the data packets need to be sent while consuming the tokens in the bucket. If the token is not sufficient, the packet may be delayed or discarded.

The leaky bucket algorithm (Leaky BucketAlgorithm) is another traffic shaping technique, similar to token buckets, but tokens are generated at a fixed rate and gradually consumed, and the leaky bucket can smooth bursty traffic and reduce network congestion.

The broadcast storm control is used for limiting broadcast traffic and preventing the occurrence of broadcast storm, and can be realized by a broadcast suppression function on network equipment.

The multicast storm control is used for limiting multicast traffic and preventing the occurrence of multicast storm, and can be realized by multicast rate limiting or multicast suppression function.

By the method, the network flow can be effectively controlled and managed, and the occurrence of network storm is prevented, so that the stability and the reliability of the network are ensured.

Further, some encryption algorithms may require that the length of the incoming data be a multiple of a particular value, in which case an appropriate stuffing mechanism would need to be implemented, stuffing following a standard protocol (e.g., PKCS 7) to ensure that the encrypted data can be decrypted correctly.

In the field of encryption, "padding" is a technique used to ensure that the length of data to be encrypted meets the requirements of a particular encryption algorithm. Many encryption algorithms, particularly block encryption algorithms (such as AES), require that the input data must be an integer multiple of the block size, and if the data length is not an integer multiple of the block size, it is necessary to increase the data length by padding to meet the requirements.

Specifically, the basic concept of padding includes a block size, which is the basic unit of processing data by an encryption algorithm, typically bytes of fixed length, and a padding operation. The padding operation specifically includes adding extra bytes at the end of the data to ensure that the data length is an integer multiple of the block size.

PKCS7 is a commonly used filling standard, proposed by the RSA laboratory. It ensures that the filled data blocks can be decrypted correctly and that the filled data can be identified and removed.

The basic steps of the PKCS7 padding mechanism are 1) determining the padding length, calculating the number of bytes that need to be padded. Assuming a block size of b and an original data length of l, the padding length p can be calculated by the following formula p=b- (l% b), where% represents a modulo operation.

2) Padding data-bytes of padding length p value are added to the end of the data. The padded byte value is the pad length itself.

3) And removing stuffing after decryption, namely removing corresponding stuffing bytes by identifying the byte value of stuffing after decryption, and recovering the original data.

Examples include assuming a block size of 16 bytes (128 bits) and an original data length of 15 bytes. Pad length p=16- (15% 16) =1, pad one byte, value 1.

When decrypting, the stuff bytes are identified as 1, one stuff byte is removed, and the original 15 bytes of data are restored.

In this way, the length of the encrypted data can be adjusted to meet the requirements of the encryption algorithm, while ensuring that the original data is correctly recovered when decrypted.

Further, in the IP packet, it is the IP header checksum that needs to be updated mainly. Furthermore, if the data packet contains upper layer protocols (such as TCP or UDP), the checksum of these protocols may also need to be recalculated. The system needs to identify all checksum fields that need to be updated.

The original checksum field needs to be cleared before starting to calculate a new checksum. This is because the checksum calculation process requires these fields to be zero in order to get the correct result.

The calculation of the IP header checksum involves accumulating all 16-bit words of the IP header and then taking the inverse code. This process requires consideration of byte order (big end or little end) issues. It is noted that the header length may vary due to IP options when computing.

If the data packet contains upper layer protocols such as TCP or UDP, the checksum calculation of these protocols typically involves some fields of the IP header (e.g., source IP, destination IP), protocol specific header, and data payload. Since the data payload is already encrypted, the calculation of this checksum becomes complex. There are several possible treatments:

the checksum is completely recalculated, including the encrypted data.

Using the delta update method, only the effect of the changed part is calculated.

In some cases, it may be desirable to set the checksum field of the upper layer protocol to a fixed value or all zeros and rely on the error detection mechanism of the link layer.

After the calculation is completed, the new checksum value is written into the corresponding field. For the IP header checksum, the corresponding field in the IP header is updated directly. For upper layer protocol checksums, it may be desirable to locate yy+242200P in the encrypted data payload

And updates these fields.

After updating the checksum, verification is performed to ensure that the calculation is correct. This may be done by recalculating the checksum and comparing it to the updated value. This step helps to capture potential errors and ensure packet integrity.

Additional considerations may be required for some special cases, such as checksum calculation when handling IP options, checksum update policies when handling fragmented packets, checksum handling when handling protocols with special requirements (e.g., ICMP).

Through these detailed steps, the encrypted data payload can be effectively recombined with the original IP header information and all associated checksum fields updated correctly, which ensures the integrity and validity of the encrypted data packet while maintaining compatibility with existing network infrastructure. In practical implementations, performance optimization, error handling, and management of anomalies are also considered to ensure that the system operates efficiently and reliably under a variety of network conditions.

The data security protection method based on the link layer transparent encryption ensures the real-time performance of data encryption processing, namely, the data is encrypted once captured, reduces the exposure risk of the data in the transmission process, avoids the performance loss caused by encryption processing of the whole network traffic through hybrid mode capturing and precise filtering, improves the overall efficiency of the system, encrypts the data by adopting a preset encryption algorithm and a key, ensures the confidentiality of the data, and only authorized receivers can decrypt and read the data.

Example 1 applying link layer transparent encryption in an intranet environment, for example, a large enterprise needs to improve the security of internal data transmission without changing the existing network architecture. By adopting the technical scheme, the transparent encryption equipment can be deployed on the key nodes of the enterprise intranet. The method comprises the specific implementation steps of 1) deploying transparent encryption equipment between a core switch and a department switch of an enterprise intranet, 2) configuring two network interfaces of the encryption equipment, wherein one network interface is connected with the core switch, the other network interface is connected with the department switch, 3) enabling a hybrid mode to capture all data packets passing through the link, 4) filtering the captured data packets to identify service data needing encryption, 5) encrypting data loads by using an AES256 algorithm, keeping IP header information unchanged, and 6) forwarding the encrypted data packets to a target interface.

By the deployment mode, enterprises can realize encryption protection of sensitive data under the condition of not affecting the existing network structure and application. The staff does not need to do any extra operations, all encryption processes are completely transparent to them.

Example 2 implementing transparent encryption in a cloud computing environment, e.g., a cloud service provider may wish to provide additional data security for a customer, while not affecting existing cloud service performance and availability. The method comprises the specific implementation steps of 1) integrating a transparent encryption function module in a management platform of a virtual network, 2) distributing independent encryption examples for the virtual network of each client, 3) configuring encryption strategies at the access points of the virtual network to define traffic types needing encryption, 4) utilizing a virtualization technology to achieve efficient data packet capturing and processing, 5) utilizing a hardware acceleration technology (such as INTELAESNI) to improve encryption efficiency, 6) achieving dynamic key management and periodically updating encryption keys.

In this way, the cloud service provider may provide end-to-end data encryption services to clients while maintaining high performance and flexibility of the cloud service. The client can configure and manage encryption policies through the control panel easily without modifying its application or network configuration.

Example 3 application of link layer transparent encryption in an internet of things scenario, for example, in an intelligent factory environment, there is a need to protect sensitive data generated by a large number of IoT devices, and due to the fact that these devices generally have limited computing power, complex encryption algorithms are difficult to implement.

The implementation steps comprise 1) integrating a transparent encryption module in an IoT gateway device, 2) configuring the IoT gateway to be capable of identifying and classifying different types of IoT device data, 3) enabling transparent encryption for sensitive data to be protected, such as production parameters, device states and the like, 4) encrypting the data by using a lightweight encryption algorithm (such as ChaCha 20) to adapt to low-delay requirements of the IoT environment, 5) realizing a device authentication mechanism to ensure that only authorized devices can access a network, and 6) providing centralized key management to simplify security management of large-scale IoT deployment.

By this approach, the intelligent factory can significantly improve the security of data transmission without upgrading existing IoT devices. Meanwhile, as the encryption process is carried out in the gateway, the calculation load of the IoT device is not increased, and the real-time performance and the reliability of the system are ensured.

These examples demonstrate the flexibility and effect of the application of the present solution in different scenarios. Whether in traditional enterprise networks, cloud computing environments, or emerging IoT domains, link layer-based transparent encryption techniques can provide efficient, seamless data security protection while maintaining good compatibility with existing systems.

Referring to fig. 7, a second aspect of the present application discloses a data security protection system based on link layer transparent encryption, comprising:

A setting module 11 for determining a plurality of network interfaces of the configured transparent encryption model based on the configuration file or the user input information, and setting a mode of the plurality of network interfaces as a promiscuous mode;

the filtering module 12 is configured to start a promiscuous mode, capture all original data packets passing through the target link based on the transparent encryption model, and filter the original data packets to obtain a plurality of original data packets to be encrypted, and record the plurality of original data packets as a plurality of first data packets;

an obtaining module 13, configured to parse the first data packet based on the transparent encryption model, and obtain information of the IP header;

a determining module 14, configured to determine a start position and a length of the IP packet data payload based on the information of the IP header, and determine a target data payload based on the start position and the length;

the encryption module 15 is configured to encrypt the target data payload based on a preset encryption algorithm and an encryption key, so as to obtain an encrypted data payload;

An updating module 16 for dynamically updating information of the IP header based on the encrypted data payload;

And the reassembling module 17 is configured to reassemble the updated information of the IP header and the encrypted data payload into an encrypted data packet, and forward the encrypted data packet to the target interface.

A computer device according to an embodiment of the present disclosure includes a memory and a processor. The memory is for storing non-transitory computer readable instructions. In particular, the memory may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and/or non-volatile memory. The volatile memory may include, for example, random Access Memory (RAM) and/or cache memory (cache), and the like. The non-volatile memory may include, for example, read Only Memory (ROM), hard disk, flash memory, and the like.

The processor may be a Central Processing Unit (CPU) or other form of processing unit having data processing and/or instruction execution capabilities, and may control other components in the computer device to perform the desired functions. In one embodiment of the present disclosure, the processor is configured to execute the computer readable instructions stored in the memory, to cause the computer apparatus to perform all or part of the steps of the link layer transparent encryption based data security protection method of the embodiments of the present disclosure described above.

It should be understood by those skilled in the art that, in order to solve the technical problem of how to obtain a good user experience effect, the present embodiment may also include well-known structures such as a communication bus, an interface, and the like, and these well-known structures are also included in the protection scope of the present disclosure.

Fig. 8 is a schematic structural diagram of a computer device according to an embodiment of the disclosure. A schematic diagram of a computer device suitable for use in implementing embodiments of the present disclosure is shown. The computer device illustrated in fig. 8 is merely an example and should not be construed as limiting the functionality and scope of use of the disclosed embodiments.

As shown in fig. 8, the computer device may include a processor (e.g., a central processing unit, a graphic processor, etc.), which may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) or a program loaded from a storage device into a Random Access Memory (RAM). In the RAM, various programs and data required for the operation of the computer device are also stored. The processor, ROM and RAM are connected to each other by a bus. An input/output (I/O) interface is also connected to the bus.

In general, devices may be connected to the I/O interface including input devices such as sensors or visual information gathering equipment, output devices such as display screens, storage devices such as magnetic tape, hard disk, and communication devices. The communication means may allow the computer means to communicate wirelessly or by wire with other devices, such as edge computing devices, to exchange data. While FIG. 8 illustrates a computer device having various devices, it is to be understood that not all illustrated devices are required to be implemented or provided. More or fewer devices may be implemented or provided instead.

In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a non-transitory computer readable medium, the computer program comprising program code for performing the method shown in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via a communication device, or installed from a storage device, or installed from ROM. All or part of the steps of the link layer transparent encryption based data security protection method of the embodiments of the present disclosure are performed when the computer program is executed by a processor.

The detailed description of the present embodiment may refer to the corresponding description in the foregoing embodiments, and will not be repeated herein.

A computer-readable storage medium according to an embodiment of the present disclosure has stored thereon non-transitory computer-readable instructions. All or part of the steps of the link layer transparent encryption based data security protection method of the various embodiments of the disclosure described above are performed when the non-transitory computer readable instructions are executed by a processor.

Such computer readable storage media include, but are not limited to, optical storage media (e.g., CD-ROM and DVD), magneto-optical storage media (e.g., MO), magnetic storage media (e.g., tape or removable hard disk), media with built-in rewritable non-volatile memory (e.g., memory card), and media with built-in ROM (e.g., ROM cartridge).

The basic principles of the present disclosure have been described above in connection with specific embodiments, but it should be noted that the advantages, benefits, effects, etc. mentioned in the present disclosure are merely examples and not limiting, and these advantages, benefits, effects, etc. are not to be considered as necessarily possessed by the various embodiments of the present disclosure. Furthermore, the specific details disclosed herein are for purposes of illustration and understanding only, and are not intended to be limiting, since the disclosure is not necessarily limited to practice with the specific details described.

In this disclosure, relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions, and the block diagrams of devices, apparatuses, devices, systems involved in this disclosure are merely illustrative examples and are not intended to require or implicate that connections, arrangements, configurations must be made in the manner shown in the block diagrams. As will be appreciated by one of skill in the art, the devices, apparatuses, devices, systems may be connected, arranged, configured in any manner. Words such as "including," "comprising," "having," and the like are words of openness and mean "including but not limited to," and are used interchangeably therewith. The terms "or" and "as used herein refer to and are used interchangeably with the term" and/or "unless the context clearly indicates otherwise. The term "such as" as used herein refers to, and is used interchangeably with, the phrase "such as, but not limited to.

In addition, as used herein, the use of "or" in the recitation of items beginning with "at least one" indicates a separate recitation, such that recitation of "at least one of A, B or C" means a or B or C, or AB or AC or BC, or ABC (i.e., a and B and C), for example. Furthermore, the term "exemplary" does not mean that the described example is preferred or better than other examples.

It is also noted that in the systems and methods of the present disclosure, components or steps may be disassembled and/or assembled. Such decomposition and/or recombination should be considered equivalent to the present disclosure.

Various changes, substitutions, and alterations are possible to the techniques described herein without departing from the teachings of the techniques defined by the appended claims. Furthermore, the scope of the claims of the present disclosure is not limited to the particular aspects of the process, machine, manufacture, composition of matter, means, methods and acts described above. The processes, machines, manufacture, compositions of matter, means, methods, or acts, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein may be utilized. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or acts.

The previous description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects without departing from the scope of the disclosure. Thus, the present disclosure is not intended to be limited to the aspects shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

The foregoing description has been presented for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of the disclosure to the form disclosed herein. Although a number of example aspects and embodiments have been discussed above, a person of ordinary skill in the art will recognize certain variations, modifications, alterations, additions, and subcombinations thereof.

Claims

1. The data security protection method based on link layer transparent encryption is characterized by comprising the following steps:

configuring a plurality of network interfaces of a transparent encryption model, and setting the modes of the network interfaces as a hybrid mode;

starting a hybrid mode, capturing an original data packet passing through a target link based on the transparent encryption model, filtering the original data packet, obtaining a plurality of original data packets needing encryption, and marking the plurality of original data packets as a plurality of first data packets;

Recombining the updated information of the IP header and the encrypted data load into an encrypted data packet, and forwarding the encrypted data packet to a target interface;

The transparent encryption model comprises a data packet capturing strategy, a data packet filtering strategy, a data packet analyzing strategy, a data packet encrypting strategy and a forwarding strategy, wherein the data packet capturing strategy comprises capturing filter information, capturing buffer area size information, capturing mode information, size information of a data packet to be captured and a preset function, and the information of the IP header is dynamically updated based on the encrypted data load, and the method comprises the following steps:

2. The link layer transparent encryption-based data security protection method according to claim 1, wherein the reorganizing the updated information of the IP header and the encrypted data payload into an encrypted data packet comprises:

3. The method for protecting data security based on link layer transparent encryption according to claim 2, wherein said reorganizing the updated IP header and the encrypted data payload in the reorganizing buffer to obtain encrypted data packets comprises:

4. The method for protecting data security based on link layer transparent encryption of claim 3 further comprising adding metadata during encryption, the metadata comprising one or more of an initialization vector, an authentication tag;

5. The method for protecting data security based on link layer transparent encryption according to claim 4, wherein if the original data packet is a slice, the slice offset is updated based on the size of the encrypted data packet;

6. The link layer transparent encryption-based data security protection method according to claim 1, wherein the preset encryption algorithm comprises an AES algorithm or a ChaCha20 algorithm;

The method for acquiring the encryption key comprises the following steps:

determining initial parameters of a preset key negotiation mechanism;

7. The link layer transparent encryption based data security protection method according to claim 6, wherein the exchanging local public keys of each communication party based on a preset security protocol comprises:

8. The link layer transparent encryption based data security protection method according to any one of claims 1-7, wherein the transparent encryption model further comprises a storm control strategy;