Data security protection method based on link layer transparent encryption

Abstract

The invention discloses a data security protection method based on link layer transparent encryption, and the method comprises the steps: determining a plurality of network interfaces of a transparent encryption model, and setting the network interfaces in a promiscuous mode; the method comprises the following steps: starting a promiscuous mode, capturing all original data packets passing through a target link, filtering to obtain a plurality of original data packets needing to be encrypted, then analyzing to obtain information of an IP header, then determining the initial position and length of an IP packet data load, and further determining a target data load; encrypting the target data load based on a preset encryption algorithm and the encryption key to obtain an encrypted data load; dynamically updating the information of the IP header based on the encrypted data load; and 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 the target interface. According to the method, encryption is carried out on a network link layer, only the IP packet data load is encrypted, an IP address does not need to be configured or a network structure does not need to be modified, and normal operation of an existing network system and various devices is ensured.

Description

Technical Field

[0001] The present disclosure relates to the field of network data technology, and in particular to a data security protection method based on link layer transparent encryption. Background Art

[0002] With the rapid development of information technology and the widespread popularity of network applications, data security has become one of the major challenges facing today's society. Traditional data encryption methods are usually implemented at the application layer or transport layer. These methods often require modifying existing network structures or applications, resulting in high implementation costs and poor compatibility.

[0003] Specifically, the encryption technologies disclosed in the prior art mainly include the following aspects: 1) encryption at the application layer, which requires modification of the application program, is complex to implement, and is difficult to seamlessly integrate into the existing system; 2) encryption at the transport layer, such as SSL / TLS, although widely used, may increase processing overhead and affect network performance; 3) encryption at the network layer, such as IPSec, usually requires modification of the network configuration, which increases the difficulty of deployment; 4) end-to-end encryption methods, although highly secure, make it difficult to implement monitoring and management functions of network intermediate devices; 5) encryption in the traditional link layer, which usually requires dedicated hardware, is costly, and has poor flexibility. Summary of the invention

[0004] 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 applications.

[0005] In a first aspect, an embodiment of the present disclosure provides a data security protection method based on link layer transparent encryption, which specifically includes the following schemes:

[0006] Based on the configuration file or user input information, determine a number of network interfaces of the configured transparent encryption model, and set the mode of the number of said network interfaces to a promiscuous mode;

[0007] Starting the promiscuous mode, capturing all original data packets passing through the target link based on the transparent encryption model, and filtering the original data packets to obtain a number of original data packets that need to be encrypted, which are recorded as a number of first data packets;

[0008] Parsing the first data packet based on the transparent encryption model to obtain information of the IP header;

[0009] Determine the starting position and length of the IP packet data payload based on the information of the IP header, and determine the target data payload based on the starting position and the length;

[0010] Encrypting the target data payload based on a preset encryption algorithm and an encryption key to obtain an encrypted data payload;

[0011] Based on the encrypted data payload, dynamically update the information of the IP header;

[0012] The updated IP header information and the encrypted data payload are reassembled into an encrypted data packet, and the encrypted data packet is forwarded to a target interface.

[0013] Optionally, the transparent encryption model includes a data packet capture strategy, a data packet filtering strategy, a data packet parsing strategy, a data packet encryption strategy and a forwarding strategy;

[0014] The data packet capture strategy includes capture filter information, capture buffer size information, capture mode information, size information of the data packet to be captured and a preset function.

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

[0016] Based on the encrypted data payload, the total length of the IP header is changed, and the sum of the total length of the changed IP header and the total length of the encrypted data payload is consistent with the total length of the original data packet;

[0017] Based on the total length of the changed IP header, the checksum of the IP header is updated to obtain an updated IP header.

[0018] Optionally, the step of recombining the updated information of the IP header and the encrypted data payload into an encrypted data packet includes:

[0019] Configuring a reassembly buffer, wherein the size of the reassembly buffer is not less than the sum of the size of the updated IP header and the size of the encrypted data payload;

[0020] The updated IP header and the encrypted data payload are reassembled in the reassembly buffer to obtain an encrypted data packet.

[0021] Optionally, the reassembling the updated IP header and the encrypted data payload in the reassembly buffer to obtain an encrypted data packet includes:

[0022] Copying the updated IP header to the beginning of the reassembly buffer;

[0023] The encrypted data payload is placed after the copy position of the updated IP header, and the setting position of the encrypted data payload is adjacent to the copy position of the updated IP header.

[0024] Optionally, it further includes: adding metadata during the encryption process, wherein the metadata includes one or more of an initialization vector and an authentication tag;

[0025] The size of the reassembly buffer is not less than the sum of the size of the updated IP header, the size of the encrypted data payload and the size of the metadata;

[0026] 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 setting position of the encrypted data payload.

[0027] Optionally, if the original data packet is a fragment, updating the fragment offset based on the size of the encrypted data packet;

[0028] If the encrypted data packet needs to be transmitted in fragments, the encrypted data packet is divided into several blocks, and the fragment offset and more fragment flag of each block are updated.

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

[0030] The method for obtaining the encryption key includes:

[0031] Determine initial parameters of a preset key negotiation mechanism;

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

[0033] Exchange the local public key of each communication party based on a preset security protocol;

[0034] Based on the local private key and the other party's public key, a shared key is obtained; the other party's public key is the local public key sent by the exchange party and received by the communication party corresponding to the local public key;

[0035] An encryption key is generated from the shared key using a key derivation function.

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

[0037] Determine certificate information of the digital certificate, the certificate information including certificate standard, certificate format, certificate chain information, certificate verification mechanism and certificate storage mechanism;

[0038] Formulate a two-way authentication protocol strategy based on the certificate information;

[0039] Perform identity authentication of the first end and the second end based on the two-way authentication protocol strategy and the certificate information, and after the identity authentication is passed, exchange the local public key of each communication party based on a preset security protocol;

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

[0041] Optionally, the transparent encryption model also includes a storm control strategy;

[0042] Before forwarding the encrypted data packet, analyzing the traffic pattern in the network where the encrypted data packet is located to determine the traffic type that induces the storm;

[0043] Dynamically control based on the traffic type and the storm control strategy;

[0044] The storm control strategy includes 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.

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

[0046] A setting module, used for determining a number of network interfaces of the configured transparent encryption model based on a configuration file or user input information, and setting the mode of the number of said network interfaces to a promiscuous mode;

[0047] A filtering module, used to start the 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 number of original data packets that need to be encrypted, which are recorded as a number of first data packets;

[0048] An acquisition module, used for parsing the first data packet based on the transparent encryption model to obtain information of the IP header;

[0049] A determination module, used to determine the starting position and length of the IP packet data payload based on the information of the IP header, and determine the target data payload based on the starting position and the length;

[0050] An encryption module, used to encrypt the target data payload based on a preset encryption algorithm and an encryption key to obtain an encrypted data payload;

[0051] An updating module, used for dynamically updating the information of the IP header based on the encrypted data payload;

[0052] The reassembly module is used 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 a target interface.

[0053] In a third aspect, the embodiments of the present disclosure further provide a computer device, which adopts the following technical solution:

[0054] The computer device comprises:

[0055] at least one processor; and,

[0056] a memory communicatively connected to the at least one processor; wherein,

[0057] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute any of the above-mentioned data security protection methods based on link layer transparent encryption.

[0058] In a fourth aspect, an embodiment of the present disclosure further provides a computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable a computer to execute any of the above-mentioned data security protection methods based on link layer transparent encryption.

[0059] In a fifth aspect, an embodiment of the present disclosure further provides a computer program product, including a computer program / instruction, which implements the steps of any of the above methods when executed by a processor.

[0060] The data security protection method based on link layer transparent encryption disclosed in the present application captures all data packets when data is transmitted through the link, filters out the data that needs to be protected in real time and performs encryption processing, and realizes encryption of data at the network link layer, that is, the method can directly start protection when the data enters the physical link, avoiding the exposure of data at other network levels, improving the real-time and reliability of encryption, and ensuring the confidentiality and integrity of data during transmission; at the same time, the encryption technology that only encrypts the IP packet data payload enables the encryption device (i.e., the transparent encryption model) to be directly connected in series to the network without configuring the IP address or modifying the network structure, that is, it will not affect the existing network structure and applications, etc., and can effectively ensure the normal operation of the existing network system and various devices. The data security protection method based on link layer transparent encryption disclosed in the present application not only improves the security of data transmission, but also ensures the compatibility and scalability of the network.

[0061] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the following preferred embodiments are specifically cited and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0063] Figure 1 A flowchart of a data security protection method based on link layer transparent encryption provided in an embodiment of the present disclosure.

[0064] Figure 2 A flowchart of a method for dynamically updating information in an IP header provided in an embodiment of the present disclosure.

[0065] Figure 3 A flowchart of a method for reassembling an encrypted data packet provided in an embodiment of the present disclosure.

[0066] Figure 4 for Figure 3 A flow chart of a method for reassembling an updated IP header and an encrypted data payload in a reassembly buffer.

[0067] Figure 5 A flowchart of a method for obtaining an encryption key provided in an embodiment of the present disclosure.

[0068] Figure 6 A flowchart of a method for different communication parties to exchange local public keys provided in an embodiment of the present disclosure.

[0069] Figure 7 A principle block diagram of a data security protection system based on link layer transparent encryption provided in an embodiment of the present disclosure.

[0070] Figure 8 A schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0071] The embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0072] It should be clear that the following embodiments of the present disclosure are described by specific specific examples, and those skilled in the art can easily understand other advantages and effects of the present disclosure from the contents disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. The present disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present disclosure. It should be noted that the following embodiments and features in the embodiments can be combined with each other in the absence of conflict. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present disclosure.

[0073] It should be noted that various aspects of the embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein may be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on the present disclosure, it should be understood by those skilled in the art that an aspect described herein may be implemented independently of any other aspect, and two or more of these aspects may be combined in various ways. For example, any number of aspects described herein may be used to implement the device and / or practice the method. In addition, other structures and / or functionalities other than one or more of the aspects described herein may be used to implement this device and / or practice this method.

[0074] It should also be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present disclosure. The drawings only show components related to the present disclosure rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0075] Additionally, in the following description, specific details are provided to facilitate a thorough understanding of the examples. However, it will be understood by those skilled in the art that the aspects described may be practiced without these specific details.

[0076] Reference Figure 1 The present application discloses a data security protection method based on link layer transparent encryption, comprising:

[0077] S100, configure the transparent encryption model.

[0078] Specifically, the transparent encryption model includes data packet capture strategy, data packet filtering strategy, data packet parsing strategy, data packet encryption strategy and forwarding strategy, wherein the data packet capture strategy preferably includes capture filter information, capture buffer size information, capture mode information, size information of the data packet to be captured and a preset function.

[0079] By setting the capture buffer size information, you can adapt to high traffic environments so as to capture as many packets as possible in high traffic environments. A buffer that is too small may cause packet loss, while a buffer that is too large may occupy too much memory.

[0080] By setting the capture filter information, you can ensure that only the data packets of interest are captured, which helps reduce unnecessary data packet capture and improve processing efficiency.

[0081] By setting the capture mode information, you can choose whether to enable the promiscuous mode to capture all data packets passing through the network interface, rather than just the data packets sent to the local address.

[0082] By setting the size information of the data packet to be captured, the size of the captured data packet is determined, including whether to capture the entire data packet or only the header of the data packet. Capturing the entire data packet can provide more detailed information, but it will increase the burden of storage and processing.

[0083] The preset function can be a callback function, which is triggered whenever a new data packet arrives. The capture process needs to be efficient and reliable to ensure that no data packets are lost.

[0084] The setting of forwarding strategy can realize the packet forwarding function and ensure normal network communication. Specifically, a continuously running loop can be designed to read packets from the network interface, and each captured packet needs to be processed and forwarded. This process is the core of the packet forwarding function, and efficiency and reliability need to be considered.

[0085] The packet parsing policy setting can be used to parse the contents of packets after they are captured, including extracting key information such as source MAC address, destination MAC address, protocol type, etc. The parsing process requires understanding the structure of various network protocols in order to correctly identify and process different types of packets.

[0086] In order to efficiently forward data packets, the system needs to implement MAC address learning, which involves creating and maintaining a MAC address table that records the egress interface corresponding to each MAC address. Every time a data packet is received, this table is updated to reflect changes in the network topology.

[0087] Based on the parsed information and the MAC address table, forwarding decisions can be made, which includes determining which interface the packet should be forwarded to or whether it needs to be broadcast; if the destination MAC address is unknown, the system may need to perform a flooding operation.

[0088] Once a forwarding decision is made, the next step is to actually send the packet, which involves using the appropriate network API to transfer the packet to the destination interface. The sending process needs to handle possible errors to ensure that the packet is successfully transmitted.

[0089] Furthermore, the transparent encryption model may be a transparent encryption device configured between the core switch and the department switch of the enterprise intranet, or the transparent encryption model may be a transparent encryption functional module integrated in the virtual network management platform, or the transparent encryption model may be a transparent encryption module integrated in the IoT gateway device.

[0090] S200, based on a configuration file or user input information, determining a number of network interfaces of a transparent encryption model, and setting the modes of the number of network interfaces to a promiscuous mode.

[0091] Promiscuous mode allows the NIC to capture all packets traveling over the physical link, not just those destined for the interface.

[0092] In this step, the system needs to identify the available network interfaces, which is usually achieved by using the network API provided by the operating system or a dedicated network library. The system obtains a list of all available network interfaces, including their names, types, and current status; specifically, based on the configuration file or user input, select the specific interface that needs to be set to promiscuous mode.

[0093] Once the interface has been selected, the next step is to put it into promiscuous mode. This usually involves using a specific system call or network library function. In promiscuous mode, the network interface will capture all packets passing through it, not just those destined for the local machine.

[0094] Furthermore, after the promiscuous mode is set up, it also includes: verifying whether the promiscuous mode is successfully enabled, which can be done by checking the interface status or specific system files. The verification process ensures that the interface is indeed in the expected working mode and is ready for subsequent data packet capture.

[0095] S300, start the 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 number of original data packets that need to be encrypted, which are recorded as a number of first data packets.

[0096] The target link refers to the target network link.

[0097] The captured original data packets are filtered, and only the data packets that need to be encrypted are selected to form a first data packet set (i.e., several first data packets), that is, only the data part that needs to be protected is encrypted, which can effectively improve the efficiency and response speed of the system.

[0098] S400, parsing the first data packet based on the transparent encryption model to obtain information of the IP header.

[0099] For each selected original data packet, the first data packet is parsed through the transparent encryption model to extract the IP header information therein. The IP header contains important information such as the starting position and length of the target data payload.

[0100] Specifically, the information in the IP header may include important information such as the source IP address, the destination IP address, and the protocol type information.

[0101] S500, determining the starting position and length of the IP packet data payload based on the information in the IP header, and determining the target data payload based on the starting position and length.

[0102] In this step, the first data packet includes an IP header and an IP packet data payload. The data payload is the data content actually transmitted. Based on the parsed IP header information, the starting position and length of the target data payload in the original data packet are determined. This step is to accurately determine the target data payload.

[0103] After identifying the IP packet structure, the next step is to extract the data payload from the entire IP packet. This process requires extra care to ensure that the header information is not mistakenly included; therefore, it is necessary to accurately calculate the starting position and length of the data payload based on the information in the IP header, such as the total length field and the header length field.

[0104] S600, encrypt the target data payload based on a preset encryption algorithm and an encryption key to obtain an encrypted data payload.

[0105] The preset encryption algorithms include AES algorithm, ChaCha20 algorithm and other algorithms. The selection of encryption algorithm needs to consider factors such as security, performance and resource consumption.

[0106] The extracted data payload is encrypted using the prepared encryption algorithm and key. This process needs to be efficient to minimize the impact on network performance; the encryption operation should be atomic to ensure data integrity; if the data payload is large, block encryption may be considered to optimize performance.

[0107] The encrypted data payload ensures the confidentiality of the data, meaning that only the authorized recipient can decrypt and read its contents.

[0108] In this step, only the target data payload is encrypted, and the original IP header information is retained, that is, during the encryption process, the original IP header information must be completely retained. This includes all fields such as source IP address, destination IP address, protocol type, and time to live (TTL). Retaining this information is crucial to ensure that the data packet can be correctly routed to the destination.

[0109] S700, dynamically update the IP header information based on the encrypted data payload.

[0110] Specifically, although most of the IP header information remains unchanged, some 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.

[0111] S800: Reassemble the updated IP header information and the encrypted data payload into an encrypted data packet, and forward the encrypted data packet to the target interface.

[0112] It should be noted that if the size, length or other information of the IP header does not change 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 IP header information contained in the reorganized encrypted data packet is still the original IP header information.

[0113] The data security protection method based on link layer transparent encryption disclosed in the present application captures all data packets when data is transmitted through the link, filters out the data that needs to be protected in real time and performs encryption processing, and realizes encryption of data at the network link layer, that is, the method can directly start protection when the data enters the physical link, avoiding the exposure of data at other network levels, improving the real-time and reliability of encryption, and ensuring the confidentiality and integrity of data during transmission; at the same time, the encryption technology that only encrypts the IP packet data payload enables the encryption device (i.e., the transparent encryption model) to be directly connected in series to the network without configuring the IP address or modifying the network structure, that is, it will not affect the existing network structure and applications, etc., and can effectively ensure the normal operation of the existing network system and various devices. The data security protection method based on link layer transparent encryption disclosed in the present application not only improves the security of data transmission, but also ensures the compatibility and scalability of the network.

[0114] Reference Figure 2 The method for dynamically updating the information of the IP header specifically includes the following steps:

[0115] S710, based on the encrypted data payload, the total length of the IP header is changed, and the sum of the total length of the changed IP header and the total length of the encrypted data payload is consistent with the total length of the original data packet.

[0116] When a data packet needs to be encrypted, the encryption process may cause the size of the data packet to change, such as adding additional information required for encryption. In order to ensure that the size of the entire data packet is consistent with the original data packet size, the total length field of the IP header needs to be adjusted.

[0117] Specifically, assuming that the original data packet size is X bytes, the encrypted data packet size is Y bytes, and the encryption process adds Z bytes of additional information, then the new IP header length should be X+Z.

[0118] This step can maintain the integrity of the data packet, ensuring that the data packet will not be discarded or processed incorrectly due to size changes during transmission; when encrypting the data payload, the data content is hidden, increasing the security of information protection.

[0119] S720, based on the total length of the changed IP header, update the checksum of the IP header to obtain an updated IP header.

[0120] The IP header contains a header checksum field that is used to verify the integrity of the header during transmission. Since some fields (such as the total length) may have been modified, this checksum needs to be recalculated and updated. This step is very important to ensure that the data packet can be processed correctly by the network equipment.

[0121] When the total length of the IP header changes, the original checksum needs to be recalculated to adapt to the new header structure.

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

[0123] In this step, the integrity of the data packet during transmission is ensured by updating the checksum, avoiding transmission errors caused by changes in the IP header. This can ensure that the receiver can correctly verify the integrity of the data packet and improve the reliability and stability of communication.

[0124] In the method for dynamically updating information in the IP header disclosed in the embodiment, the encrypted data payload ensures the privacy and security of the data, and the dynamic update of the IP header ensures the high efficiency and reliability of data packet transmission, which is compatible with the existing network communication protocol and does not affect the normal operation of network communication.

[0125] In this embodiment, if the original IP contains IP options, special care is required. These options are usually located after the standard IP header and before the data payload. The encryption process should not change or encrypt these options, but their position may need to be adjusted to adapt to the encrypted data structure.

[0126] Some protocols (such as ICMP) may rely on the contents of the IP data payload to operate. In this case, special processing mechanisms may need to be implemented to ensure that the encrypted data packets are still compatible with these protocols.

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

[0128] Through these detailed steps, the IP packet data payload can be encrypted while keeping the IP header information unchanged. This method ensures data security without affecting the normal routing and processing functions of the network layer. In actual implementation, factors such as performance optimization and exception handling need to be considered to ensure that the system can run stably and efficiently under various network conditions.

[0129] Reference Figure 3 , the method for reassembling the encrypted data packet specifically comprises the following steps:

[0130] S810, configuring a reassembly buffer, wherein the size of the reassembly buffer is not less than the sum of the size of the updated IP header and the size of the encrypted data payload.

[0131] This step ensures that the memory space of the configured reassembly buffer is large enough to accommodate the reassembled IP packets.

[0132] Furthermore, if additional metadata (such as an initialization vector or an authentication tag) is added during the encryption process, the space for this additional data also needs to be considered.

[0133] Specifically, the minimum size of the reassembly buffer can be calculated based on the size of the updated IP header and the encrypted data payload to ensure that it can accommodate the sum of these two parts; the memory management function provided by the programming language or the operating system can be used to allocate a sufficiently large memory block as the reassembly buffer, while ensuring that the size of the reassembly buffer is not less than the sum of the updated IP header and the encrypted data payload to avoid overflow or data loss.

[0134] In this step, by pre-allocating and optimizing memory space, the efficiency and stability of program operation can be improved; ensuring that the reorganization buffer is large enough can effectively prevent data truncation or accidental modification.

[0135] S820, reassemble the updated IP header and the encrypted data payload in the reassembly buffer to obtain an encrypted data packet.

[0136] Specifically, the content of the updated IP header is copied to the starting position of the reassembly buffer; following the IP header, the content of the encrypted data payload is copied to the reassembly buffer and closely connected to the IP header. At this time, the data inside the reassembly buffer is a complete encrypted data packet, including the updated IP header and the encrypted data payload.

[0137] In this step, it can be ensured that the IP header and the encrypted data payload are correctly combined to form a complete encrypted data packet, which can reduce the additional overhead caused by scattered data during network transmission and improve data transmission efficiency.

[0138] The encrypted data packet reassembly method disclosed in this embodiment ensures the consistency and correctness of the internal data of the reassembled encrypted data packet through step-by-step processing; improves the resource utilization efficiency of the system by reasonably configuring the reassembly buffer size and memory management, avoids system crashes or security issues caused by improper data processing, and improves the stability and security of the system.

[0139] Reference Figure 4 , which is Figure 3 The flowchart of the method for reassembling the updated IP header and the encrypted data payload in the reassembly buffer specifically includes:

[0140] S821, copy the updated IP header to the beginning position of the reassembly buffer.

[0141] Specifically, the data content of the updated IP header is obtained, which usually includes information such as the source address, destination address, protocol type, and packet length; the obtained IP header data is copied byte by byte or bit by bit to the starting position of the reassembly buffer; the exact position of the copied IP header in the reassembly buffer is confirmed so that subsequent steps can correctly locate the insertion point of the encrypted data payload.

[0142] In this step, it can be ensured that the beginning part of the encrypted data packet is the correct IP header information, ensuring the recognition and processing capabilities of the data packet during network transmission; through simple copy operations, the rapid embedding of the IP header is achieved, reducing complex data processing steps.

[0143] S822, placing the encrypted data payload after the copy position of the updated IP header, and the setting position of the encrypted data payload is adjacent to the copy position of the updated IP header.

[0144] Specifically, based on the position of the updated IP header in the reassembly buffer, the exact position where the encrypted data payload should be inserted is calculated, usually after the end of the IP header copy; then the content of the encrypted data payload is copied byte by byte or bit by bit to the calculated insertion position, and at the same time, it is confirmed that the entire content of the encrypted data payload has been correctly inserted into the reassembly buffer.

[0145] In this step, the integrity and correctness of the encrypted data payload can be ensured, avoiding the risk of data loss or tampering; by directly inserting data without the need for additional complex calculations, the efficiency and speed of data processing are improved.

[0146] The solution disclosed in this embodiment can effectively manage and reorganize network data packets, and is particularly suitable for network communication scenarios where data packets need to be encrypted and transmitted, ensuring secure transmission and efficient processing of data.

[0147] The data security protection method based on link layer transparent encryption disclosed in the present application also includes: adding metadata during the encryption process, the metadata including one or more of an initialization vector and an authentication tag;

[0148] The size of the reassembly buffer is not less than the sum of the size of the updated IP header, the size of the encrypted data payload, and the size of the metadata;

[0149] 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 setting position of the encrypted data payload.

[0150] The benefits of this approach are mainly reflected in data security protection. Specifically, by adding metadata (such as initialization vectors and authentication tags) during the encryption process, the security and reliability of data encryption can be improved. In addition, the design of the reassembly buffer takes into account the size of the updated IP header, the size of the encrypted data payload, and the size of the metadata, ensuring the integrity and availability of the encrypted data. The metadata copy location is set at a suitable position between the updated IP header and the encrypted data payload, which helps to effectively manage the processing and reassembly process of encrypted data, further strengthening the security during data transmission. In summary, this approach not only focuses on the encryption protection of data, but also pays attention to metadata management and reassembly design during the protection process to ensure the security and integrity of data during transmission and storage.

[0151] In the application, if the original data packet is a fragment, the fragment offset is updated based on the size of the encrypted data packet;

[0152] If the encrypted data packet needs to be transmitted in fragments, split the encrypted data packet into several blocks and update the segmentation of each block.

[0153] The fragment offset and more fragment flags.

[0154] In this embodiment, the determination of whether the encrypted data packet needs to be transmitted in fragments specifically includes: determining whether the size of the encrypted data packet exceeds the maximum fragment size allowed by the transmission protocol; if so, determining that the encrypted data packet needs to be transmitted in fragments.

[0155] In this embodiment, the encryption process should not affect these fields to ensure correct reassembly of the fragments.

[0156] In the case of fragmented transmission of encrypted data packets, there are two main steps involved: updating the fragment offset and the fragment flag. When the original data packet is a fragment, the fragment offset refers to the offset of the fragment relative to the starting position of the original data packet. When reassembling the encrypted data packet, 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 position in the encrypted data packet.

[0157] Specifically, if the encrypted data packet size exceeds the maximum capacity of a single shard, the offset of each shard needs to be adjusted accordingly to reflect its correct position in the encrypted data packet. This is usually achieved by recalculating the shard offset to ensure that all shards can be correctly restored to a complete encrypted data packet after reassembly.

[0158] If the encrypted data packet needs to be further fragmented for transmission, even the encrypted data packet needs to be divided into smaller blocks (fragments) during transmission, and the information that needs to be updated for each block includes the fragment offset and more fragment flags.

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

[0160] Among them, the more fragment flag specifically includes: the MF flag of the first fragment is set to 1, indicating that there are more fragments behind, the MF flag of the middle fragment is also set to 1, indicating that there are more fragments behind; the MF flag of the last fragment is set to 0, indicating that this is the last fragment.

[0161] For example, if the original data packet size is 5000 bytes and the maximum fragment size allowed by the protocol is 1000 bytes, the original data needs to be divided into 5 fragments for transmission. After encryption, the data packet size becomes 5500 bytes, so it needs to be divided into 6 fragments.

[0162] The original fragments include: fragment 1: 1000 bytes, MF=1; fragment 2: 1000 bytes, MF=1; fragment 3: 1000 bytes, MF=1; fragment 4: 1000 bytes, MF=1; fragment 5: 1000 bytes, MF=0.

[0163] In this example, the encrypted packet requires an additional fragment, so the MF flags of all fragments need to be updated and the MF flag of the last fragment must be set to 0.

[0164] Through fragmented transmission, transmission delays or packet loss caused by a single data packet being too large can be avoided, thereby improving data transmission efficiency; updating the fragment offset and fragment flag can ensure that the receiving end can correctly reassemble the encrypted data packet to ensure data integrity and reliability; at the same time, it can adapt to different network environments and transmission conditions to ensure that data packets can be effectively transmitted and reassembled in the network.

[0165] By updating the fragment offset and fragment flag, the fragments of the encrypted data packet can be effectively managed and transmitted, ensuring the secure transmission and efficient processing of data while ensuring the stability and reliability of the system in various network environments.

[0166] The encrypted data payload is appended to the buffer immediately after the IP header (and possible encryption metadata). This process needs to ensure the alignment and integrity of the data, especially when dealing with large packets. If the encryption process generates metadata that needs to be transmitted with the data (such as an initialization vector), this data usually needs to be inserted after the IP header and before the encrypted data payload. The format and location of this metadata are carefully designed to ensure that the receiver can correctly identify and use it.

[0167] Reference Figure 5 , the method for obtaining the encryption key specifically includes the following steps:

[0168] A100, determine initial parameters of a preset key negotiation mechanism.

[0169] Specifically, determine the Diffie-Hellman (DH) variant to use, such as classic DH, elliptic curve DH (ECDH), etc.; select appropriate security parameters. For Diffie-Hellman (DH) variants, these parameters include prime number p, generator g, or select a suitable elliptic curve (for ECDH), ensuring that the selected parameters meet the latest security standards and recommendations.

[0170] In this step, determining the initial parameters can ensure that all communicating parties use consistent basic settings, simplifying the implementation of key negotiation; selecting standardized key negotiation mechanisms and parameters can improve the compatibility and interoperability of the system.

[0171] A200, based on the initial parameters, obtain a local key pair of each communication party, where the local key pair includes a local private key and a local public key.

[0172] Specifically, a private key is generated for each communicating party, which is usually a randomly selected large integer; the public key is calculated based on the private key and the initial parameters to ensure that each communicating party generates its own key pair, that is, each communicating party has its own key pair, which ensures the privacy and security of key generation; at the same time, the key pair generation is independent, and each communicating party only needs to generate its own key without relying on the key information of other parties.

[0173] Among them, a cryptographically secure random number generator (CSPRNG) can be used to generate a private key.

[0174] A300, exchanges the local public key of each communicating party based on the preset security protocol.

[0175] A secure protocol can be designed to exchange public keys, which may involve the use of a pre-established secure channel or the use of digital signatures to implement a serialization and deserialization mechanism for public keys to ensure integrity during network transmission; at the same time, you can also consider adding timestamps or serial numbers to prevent replay attacks.

[0176] Specifically, a preset security protocol (such as TLS) is used to exchange the public keys of each communication party. Communication party A sends its local public key Q A Send it to communication party B, who also sends its local public key Q B Sent to communication party A; public key exchange is performed through an encrypted channel (such as using TLS) to protect data security during the exchange process.

[0177] This step ensures that all communicating parties can obtain the public keys of other parties in order to calculate the shared key; exchanging public keys through an encrypted channel reduces man-in-the-middle attacks and other potential security threats.

[0178] Furthermore, the received public key can also be verified, that is, a public key verification mechanism is implemented to check whether the received public key is valid and has not been tampered with.

[0179] For ECDH, ensure that the received public key is indeed on the specified elliptic curve; additional security measures to implement public key verification may also be considered, such as using certificates or pre-shared keys.

[0180] A400, based on the local private key and the other party's public key, obtain a shared key; the other party's public key is the local public key sent by the exchanging party and received by the communicating party corresponding to the local public key.

[0181] Specifically, the DH shared key is calculated using the local private key and the received public key of the other party.

[0182] For classic DH, this involves modular exponentiation; for ECDH, this involves point multiplication. In order to ensure that the implemented algorithm can handle large integers, a specialized big number library can be used.

[0183] Each communicating party uses its own local private key and the other party’s public key to calculate the shared key. For example, communicating party A uses its own private key d A and the public key Q of the communicating party B B , calculate the shared key K = d A times Q B The communication party B uses its own private key d B and the public key Q of the communicating party A A , calculate the shared key K = d B times Q A .

[0184] In this step, the calculation process of the shared key utilizes the mathematical properties of the key pair, ensuring the security and uniqueness of the generated shared key, while ensuring that both parties can generate the same shared key for subsequent encryption and decryption operations.

[0185] A500, generates encryption keys from a shared secret key using a key derivation function.

[0186] Specifically, a key derivation function (such as HKDF, PBKDF2, etc.) can be used to generate the actual session key from the DH shared key.

[0187] The shared key is used as input to generate the final encryption key through the key derivation function. The key derivation function can further process the shared key, add salt, number of iterations, etc. to enhance the security of the key.

[0188] Consider generating multiple keys for different purposes (such as encryption keys and authentication keys); further, other context information (such as the identities of both parties and the protocol version) can be included in the key derivation process to enhance security.

[0189] The key derivation function can enhance the security of the key and resist various attacks, such as brute force cracking. It can generate multiple keys for different purposes (such as encryption, signing, etc.) to meet different security requirements.

[0190] The method for obtaining encryption keys disclosed in this embodiment ensures the security and reliability of encryption keys through a standardized key negotiation and generation mechanism throughout the entire process; uses standard protocols and methods (such as Diffie-Hellman, ECDH, TLS, etc.) to ensure system compatibility and interoperability; provides strong data protection through encryption key generation and the use of key derivation functions to ensure the confidentiality and integrity of information; and uses modern encryption technology to reduce potential security risks throughout the process, such as man-in-the-middle attacks and key leaks.

[0191] Furthermore, the application also includes: verifying the key negotiation results, specifically, implementing a key confirmation step to ensure that both parties have successfully generated the same session key, which can be accomplished by exchanging and verifying predefined messages encrypted with the newly generated key; considering using key-based authentication methods, such as HMAC, to verify the correctness of the key.

[0192] The application also includes regularly updating session keys through a key update strategy to improve security. Specifically, the key update strategy includes: determining the conditions that trigger key updates, such as time intervals, data volume thresholds, or session durations; considering the network environment and application scenarios, balancing security and performance requirements, and designing a flexible strategy that allows the update frequency to be adjusted according to actual needs.

[0193] 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 timestamps to prevent downgrade attacks and replay attacks, and considering using the current session key to protect the key update process itself.

[0194] The application also includes generating new key material, specifically, using a cryptographically secure random number generator to create a new DH private key and then calculating the corresponding new public key; it is also possible to consider using different DH parameters (such as different prime numbers or elliptic curves) to increase diversity.

[0195] The application also includes securely exchanging new public keys. Specifically, the new public key is encrypted using the current session key for transmission. A mechanism can be implemented to confirm that both parties have successfully received the new public key. Additional authentication mechanisms, such as digital signatures, can also be considered to verify the authenticity of the new public key.

[0196] The application also includes calculating a new shared key, specifically, using a new private key and a received new public key to calculate a new DH shared key; verifying that the newly generated shared key is different from the previous key; and may also include implementing an error handling mechanism to deal with key calculation failures.

[0197] The application also includes deriving a new session key. Specifically, a new session key is generated from a new shared key using a key derivation function. Additional context information may also be added to the key derivation process, such as update times or timestamps, to ensure secure isolation of new and old key materials and prevent potential key leakage.

[0198] The application also 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; it can also be considered to implement a short transition period during which both old and new keys are accepted at the same time to deal with network delays; further, it can also be considered to implement a rollback mechanism to deal with problems that may arise during the key update process.

[0199] The application also includes secure destruction of old keys, specifically to implement secure memory wipe technology to completely remove old key material. Consider using specialized secure memory management techniques, such as memory rewriting or using encrypted memory areas to ensure that sensitive key information is not leaked in logs and error reports.

[0200] The application also includes verification and logging of key updates, implementing a process to verify the correctness and validity of new keys. Log key update events, including timestamps and relevant metadata, but not the actual key material. Consider implementing an audit mechanism to track and analyze key update patterns.

[0201] Through these detailed steps, a secure key negotiation mechanism based on the DiffieHellman algorithm can be implemented, and session keys can be updated regularly to improve security. This method ensures that both parties can establish and maintain a secure encryption channel, while reducing the potential risk of key leakage through regular updates. In actual implementation, factors such as performance optimization, error recovery, compatibility, and scalability need to be considered to ensure that the system can operate safely and efficiently in various network environments and usage scenarios.

[0202] Reference Figure 6 The method for different communication parties to exchange local public keys provided by the embodiment of the present disclosure specifically includes the following steps:

[0203] B100, determine the certificate information of the digital certificate, the certificate information includes the certificate standard, certificate format, certificate chain information, certificate verification mechanism and certificate storage mechanism.

[0204] Among them, the certificate standard may be X.509, which is a widely used standard for defining the format and content of a digital certificate.

[0205] The certificate format can be PEM (Privacy Enhanced Mail) encoding format or DER (Distinguished Encoding Rules) encoding format, which specifies the encoding method of certificate data.

[0206] The certificate chain information includes: defining the hierarchical relationship of the certificate chain, including the root certificate, intermediate certificates and terminal certificates; the root certificate is issued by a trusted certificate authority (CA), the intermediate certificate is used to verify the root certificate, and the terminal certificate is used for a specific communication party.

[0207] Certificate verification mechanisms include how to verify the validity, integrity, and authenticity of the signature of a certificate, such as through a Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP).

[0208] The certificate storage mechanism determines where and how certificates are stored, such as on a local disk, in a hardware security module (HSM), or through a public certificate repository.

[0209] In this step, following the standardized certificate format and verification mechanism can ensure the consistency and interoperability of the system; by defining a detailed certificate chain and verification mechanism, the security and credibility of the certificate are enhanced; and the systematic certificate storage and management strategy simplifies the use and maintenance process of the certificate.

[0210] Furthermore, it can also include: certificate error handling mechanism, that is, developing a detailed error reporting mechanism that can accurately describe the reason for certificate verification failure, implementing a flexible error handling strategy, allowing specific verification steps to be bypassed in certain situations (such as emergency situations). User-friendly error prompts can be designed to help administrators or users understand and solve certificate problems.

[0211] B200, formulates a two-way authentication protocol strategy based on certificate information.

[0212] The two-way authentication protocol strategy includes a first-end identity authentication strategy, a second-end identity authentication strategy, and an authentication sequence strategy, that is, the two-way authentication protocol strategy can be used to authenticate the identity of each end.

[0213] Specifically, a standard protocol such as TLS with client authentication or a custom protocol may be used; the protocol message format may include certificate exchange, challenge response mechanism, etc.

[0214] B300 performs identity authentication of the first and second ends based on the two-way authentication protocol strategy and certificate information. After identity authentication, the local public keys of each communication party are exchanged based on the preset security protocol.

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

[0216] In this embodiment, the second communication party and the first communication party form a key exchange group.

[0217] Specifically, for the identity authentication of the first end (eg, server), the first communication party (first end) sends its digital certificate to the second communication party (second end), and the second end verifies the validity and authenticity of the certificate and the identity of the first end.

[0218] For the identity authentication of the second end (eg, the client), the second communication party (second end) also sends its digital certificate to the first communication party, and the first end verifies the validity and authenticity of the certificate and the identity of the second end.

[0219] Furthermore, identity authentication includes verification of digital certificates and / or key authentication.

[0220] The verification method for digital certificates specifically includes: verifying the validity of digital certificates, where the certificate chain verification process includes checking whether the certificate is issued by a trusted CA, as well as the validity of the intermediate certificate and the root certificate, which involves: verifying the signature, that is, ensuring that the signature of the server certificate is signed by a trusted CA and can be verified by the root certificate chain; checking the validity period, requiring the validity period of the certificate to be within the current date; checking certificate revocation, that is, verifying whether the certificate has been revoked through the Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP); host name verification, that is, the client also needs to verify whether the host name in the certificate matches the actual server host name accessed.

[0221] This process includes: extracting the host name, that is, extracting the host name from the "Subject" field or "SubjectAlternative Name" field in the certificate; matching the extracted host name with the server host name requested by the client to ensure that they are consistent.

[0222] The key authentication method specifically includes: taking the identity authentication of the first end as an example, the first end can use its private key to sign certain data to prove that it actually holds the corresponding private key. The first end uses the private key to sign a piece of data and attaches the signature to the certificate or sends it to the second end in the handshake protocol. The second end can use the server's public key (extracted from the certificate) to verify the validity of the signature. The second end uses the public key to verify the signature to ensure that the first end actually holds the private key that matches the public key in the certificate.

[0223] The key possession proof verifies that the first end indeed possesses the private key corresponding to its certificate, enhancing the credibility of the first end's identity authentication; through the key possession proof, the second end can confirm that not only the server's certificate is legitimate, but also that the first end indeed possesses the key that matches it, further ensuring the security of communications.

[0224] After both parties successfully pass the identity authentication, it is confirmed that both parties in the communication are verified legal entities.

[0225] Through digital certificates and two-way authentication mechanisms, the authenticity and legitimacy of the identities of both communicating parties are ensured; successful identity authentication establishes a basis of trust between the two communicating parties, laying the foundation for subsequent public key exchange and encrypted communication, while preventing malicious attackers from forging identities or interfering with the communication process, which can effectively improve the security of the system.

[0226] The local public key of each communication party is exchanged based on a preset security protocol, including: selecting a preset security protocol, such as TLS (Transport Layer Security Protocol), to encrypt the public key exchange process; after the two-way authentication is successful, the two parties exchange their respective local public keys through the security protocol. The first end sends its public key to the second end, and the second end also sends its public key to the first end; the public key exchange process is encrypted using a security protocol to ensure that the public key is not stolen or tampered with during the transmission process.

[0227] In this step, the public key exchange process is encrypted through a security protocol to protect the public key from middleman attacks or data tampering. The public key exchange after two-way authentication ensures that the received public key is indeed from the legitimate communication party. The public key exchange process is integrated into the existing security protocol to simplify the implementation process and improve efficiency.

[0228] The method for local public key exchange between different communicating parties disclosed in this embodiment ensures the authenticity of the identities of the communicating parties through digital certificates and a two-way authentication mechanism, encrypts the public key exchange process through a security protocol, and improves the overall security of the system. It adopts standardized certificates and authentication mechanisms to improve the compatibility and interoperability of the system. Successful two-way authentication establishes a basis of trust between the communicating parties, provides guarantees for secure data transmission and key exchange, and can reduce security risks such as man-in-the-middle attacks and identity forgery, thereby improving the protection capabilities of the system.

[0229] Furthermore, the present application also includes: integrating the two-way 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.

[0230] Furthermore, the present application also includes: binding the negotiated session key to the authenticated identity to ensure that the generated key corresponds to the actual authenticated identity, which helps prevent the key from being used in other unauthenticated communication sessions. Through identity binding, it can be verified that the key is indeed used for the authenticated session, thereby improving the credibility of the communication.

[0231] Furthermore, the present application also includes: implementing a session recovery mechanism, allowing authenticated sessions to be reused in a short period of time, thereby avoiding the overhead of each re-authentication and key negotiation, for improving performance and efficiency. Specifically, authenticated session information (such as session keys, authentication status) can be cached so that it can be quickly retrieved and used when the session is restored. When restoring the session, a specific protocol or identifier is used to confirm and restore the previous session state instead of re-authenticating and exchanging keys. This can effectively reduce the frequency of re-authentication and key exchange, improve the response speed and performance of the system, and at the same time effectively reduce the computing and network overhead caused by re-authentication and key negotiation.

[0232] Furthermore, the present application also includes: considering implementing a key derivation function for deriving additional key materials, that is, the key derivation function allows other key materials to be derived from the negotiated session key, which can be used for different purposes, such as encryption, message authentication code (MAC) or other security operations. Specifically, additional key materials are generated from the session key using key derivation functions, which ensure that the generated key materials have the required security and randomness; define the derived key type and purpose, and ensure that the key derivation process meets security requirements and does not leak or abuse the session key.

[0233] Furthermore, the present application also includes: integrating the authentication results with the access control system to implement fine-grained permission control based on certificate attributes (such as extended fields), and developing a dynamic permission adjustment mechanism to allow real-time adjustment of user permissions based on the authentication results.

[0234] Specifically, the results of the authentication process (such as user identity, role, and permissions) are combined with the access control system so that authenticated users can access system resources based on their identities and permissions.

[0235] Furthermore, an interface or module is developed so that the authentication system and the access control system can exchange information in real time. For example, when a user is successfully authenticated, the system can configure the corresponding permissions in the access control system according to the user's identity information.

[0236] Through integration, user identities and permissions can be managed uniformly in one system, improving management efficiency and ensuring that only authenticated users can access specific resources, thereby enhancing system security.

[0237] Implementing fine-grained permission control based on certificate attributes means using the attributes in digital certificates (such as extended fields, certificate issuer information, etc.) to implement refined access control. Specifically, attribute information in the certificate can be extracted, such as the user's role, department, permissions, etc.; then detailed permission rules can be defined in the access control system based on these attributes. For example, the "department" field contained in the user certificate can be used to restrict access to certain department resources, which can provide more detailed and precise permission management, so that users can only access the resources they are authorized to. Different permission rules can be defined based on different attributes in the certificate, improving the flexibility of permission management.

[0238] The developed dynamic permission adjustment mechanism allows the system to adjust the user's permissions according to the real-time situation or authentication results after the user is authenticated. This mechanism is usually used to respond to dynamically changing needs or security requirements. Specifically, the implementation mechanism can monitor the user's status and permission requests in real time to decide whether to adjust the permissions. Based on the authentication results and the policies in the system, the user's permissions can be automatically adjusted. For example, if the user's authentication information indicates that they have completed additional training, their permissions can be automatically upgraded.

[0239] Furthermore, a policy engine can be designed to dynamically adjust user permissions based on authentication results and current environmental conditions. This can quickly adapt to changes in user identity or business needs, improve system flexibility, and dynamically adjust permissions to respond to potential security threats in a timely manner and reduce risks.

[0240] Furthermore, the present application also includes the management of authentication sessions, specifically including the creation, maintenance and destruction mechanisms of authentication sessions, the development of session timeout and re-authentication strategies, and the implementation of a secure session logout mechanism.

[0241] The creation of an authentication session includes creating a session after the user successfully completes the authentication, which usually contains the user's identity information, permissions, session identifier, etc. The session can be stored on the server side (such as memory, database) or the client side (such as the browser's session storage).

[0242] The session identifier is a unique session ID generated to identify the user session.

[0243] Maintenance of authentication sessions refers to maintaining the state of the session within the validity period of the session to ensure that user operations and access rights are processed correctly.

[0244] The destruction mechanism of the authentication session means that the session needs to be destroyed when it is no longer needed (such as user logout, session expiration, etc.) to release resources and protect user privacy. Specifically, the session data is deleted from the storage, the validity of the session ID is terminated, and the session is prevented from being used maliciously.

[0245] Furthermore, the present application also includes recording all authentication-related activities, including authentication attempts and results, which can help monitor the authentication process, diagnose problems, track security incidents, etc. Among them, authentication attempts include recording the time of each authentication attempt, user identity (or identifier), authentication method (such as password, fingerprint), authentication result (success or failure), etc.

[0246] Furthermore, the present application also includes configuring a secure log storage and transmission mechanism, which is intended to prevent the log data from being tampered with, lost or leaked, and to ensure the integrity and confidentiality of the log data. Specifically, encryption technology can be used to encrypt the log data to prevent unauthorized access or tampering, and the log data can be stored in a protected storage medium, such as a controlled server or a dedicated log storage service.

[0247] Furthermore, the present application also includes an audit function configured to allow administrators to trace back and analyze authentication history and conduct security audits and compliance checks.

[0248] Furthermore, the present application also includes a configuration error handling and failure recovery mechanism, which refers to providing friendly and useful error messages when user authentication fails, while handling failure situations to ensure that the user experience is not overly affected.

[0249] Specifically, friendly and useful means providing clear, concise error messages without technical details, such as "incorrect username or password", and avoiding revealing too much information (such as whether a specific username exists) to reduce potential security risks.

[0250] Furthermore, retry strategies can be developed to handle temporary authentication failures and implement mechanisms to prevent brute force cracking, such as failure limit or progressive delay. Retry strategies are used to handle temporary authentication failures, such as failures caused by network problems or short service interruptions; specifically, after authentication failure, automatic re-authentication attempts are made, especially for temporary problems such as network fluctuations. A reasonable retry interval can also be set to avoid burdening the system with too frequent attempts, for example, increasing the retry interval after each failure and gradually extending the waiting time; during the retry process, feedback is provided to the user, such as "The system is retrying to log in, please wait."

[0251] Preventing brute force cracking means preventing malicious users from cracking account passwords through brute force by limiting the number of attempts or adding delays. Specifically, after a certain number of authentication failures (such as 5 times), the account is temporarily locked to prevent further attempts. When the account is locked, the user is notified and instructions for unlocking the account are provided (for example, an unlocking link is sent to the user's registered email address).

[0252] After each authentication failure, you can add a delay of 10 seconds, for example, after each failure, the attempts will be made more and more slowly.

[0253] An upper limit can be set, for example, a maximum delay of 5 minutes, to prevent the delay from being too long and affecting the user experience.

[0254] After multiple failures, the user is asked to complete a CAPTCHA verification to ensure that the operation is performed by a human user and not an automated attack tool.

[0255] Furthermore, the present application also includes a certificate caching mechanism to reduce the overhead of repeated verification by caching verified certificates or authentication data to avoid repeated verification operations for each authentication. Specifically, the certificate verification results, authentication information or session data can be cached. Common caching technologies include memory caching, distributed caching (such as Redis), etc.; you can also set a reasonable cache expiration time to ensure the validity and security of the cached data. For example, the cached authentication results can be set to a few minutes to a few hours, adjusted according to specific needs.

[0256] When the certificate or authentication information changes, update the cache to maintain data accuracy; when the cache expires or is invalid, revalidate and update the cache.

[0257] Furthermore, hardware acceleration (such as dedicated encryption hardware) can also be considered. Hardware acceleration can accelerate encryption and decryption operations by using dedicated hardware (such as encryption chips or encryption cards) to improve the efficiency of the authentication process. Specifically, a hardware encryption module (HSM, hardware security module) is used to perform encryption operations to provide high performance and security; a dedicated encryption card is installed in the server to handle encryption and decryption tasks and reduce the burden on the main processor; the hardware acceleration component is integrated into the authentication system to ensure compatibility with the software component; the encryption algorithm is optimized according to the hardware characteristics to improve the acceleration effect.

[0258] Furthermore, the present application also includes a strategy for configuring concurrent processing of multiple authentication requests, which can process multiple authentication requests at the same time and improve the throughput and responsiveness of the system. Specifically, thread pool technology can be used to manage and schedule threads that process multiple authentication requests to improve concurrent processing capabilities; an asynchronous processing mechanism can be used to allow the system to continue processing other requests while waiting for authentication results, reducing response time; a load balancer can be used to distribute authentication requests to multiple servers or processing units to evenly distribute the load; and the processing capacity of the system can be expanded by adding more server instances or processing nodes.

[0259] Through the above scheme, strong digital certificate support and two-way identity authentication mechanism can be achieved. This method ensures that both parties in communication can reliably verify each other's identity and provides a solid foundation for subsequent secure communications. In actual implementation, factors such as scalability, interoperability, and user experience need to be considered to ensure that the system can operate safely and efficiently in various complex network environments and usage scenarios; at the same time, continuous security assessment and updates are also the key to maintaining system security.

[0260] Furthermore, the present application also includes performance optimization and monitoring, and performance optimization includes hardware acceleration and data packet processing flow optimization.

[0261] Hardware acceleration improves system performance, especially the efficiency of encryption operations, through dedicated hardware components (such as dedicated encryption chips), thereby reducing the burden on the CPU.

[0262] Dedicated cryptographic chips, such as HSM, hardware security module, are hardware devices specially designed to accelerate encryption and decryption operations.

[0263] Specifically, the encryption chip is integrated into the system to handle encryption and decryption tasks. In this way, all encryption operations will be handled by dedicated hardware instead of relying on the main CPU. According to the capabilities of the encryption chip, the appropriate encryption algorithm is selected and optimized to improve the speed and efficiency of encryption operations.

[0264] Dedicated encryption chips can process encryption tasks faster than general-purpose CPUs, significantly improving the encryption efficiency of the system. They transfer encryption tasks to dedicated hardware, reduce the occupancy of the main CPU, and free up resources to handle other tasks.

[0265] Packet processing process optimization aims to increase the processing speed of packets and reduce the processing burden of the CPU, especially when processing network packets. Specifically, use a network interface card (NIC) or other hardware acceleration components to offload packet processing tasks from the main CPU to dedicated hardware; optimize the process of receiving, processing, and sending packets to reduce CPU processing time. For example, batch processing technology can be used to process multiple packets at a time to reduce processing delays; use high-speed caches (such as memory caches) to reduce frequent access to storage or networks, further improving packet processing efficiency.

[0266] Monitoring can be performed based on the performance monitoring module, which can be used to monitor the performance of the system in real time, including the throughput and latency of encryption operations, and provide performance reports and alarm mechanisms.

[0267] Preferably, encryption throughput and latency can be monitored in real time; specifically, monitoring tools or custom scripts can be used to collect real-time performance data of encryption operations, such as throughput, latency, error rate, etc.; these performance indicators can be displayed in real time through a dashboard or monitoring interface, making it convenient for administrators to view and analyze the performance status of the system; performance thresholds can be set, such as the maximum allowable latency or minimum throughput, so that performance bottlenecks can be discovered and addressed in a timely manner.

[0268] It can also provide performance reports and alarm mechanisms. Specifically, it can generate periodic (such as daily and weekly) performance reports, summarize data on indicators such as encryption throughput and latency, and analyze trends. At the same time, it can allow custom reports to be generated according to needs to view data for specific time periods or specific performance indicators.

[0269] For the alarm mechanism, you can set alarm rules. When the performance indicators exceed the preset thresholds, alarm notifications (such as emails, text messages or system notifications) are automatically sent. Suggestions or operating steps for handling alarms can be provided to help administrators quickly solve problems.

[0270] Furthermore, the present application also includes compatibility and scalability design mechanisms, which are intended to ensure that the system can operate in different network environments and can be integrated with other systems through API interfaces.

[0271] This design mechanism can adapt to different network topologies, where the network topology refers to the layout of various devices and nodes in the network. Adapting to different network topologies can ensure the normal operation of the system under various network settings.

[0272] Specifically, when designing the system architecture, different network topologies (such as star, ring, mesh, etc.) are considered to ensure that 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 users to flexibly adjust system settings according to the specific network topology.

[0273] This design mechanism also supports virtual network environments (such as SDN, NFV). Virtual network environments refer to network architectures that use software-defined networking (SDN) and network function virtualization (NFV) technologies. Supporting these environments can improve the flexibility and scalability of the system.

[0274] Specifically, the system is designed to support the SDN architecture, which can dynamically configure network resources under centralized control; ensure that the system can be deployed in an NFV environment and use virtualization technology to run network functions on standard hardware; and provide management tools so that users can dynamically adjust virtual network resources to meet different needs.

[0275] This design mechanism can provide an API interface to facilitate integration and interaction with other systems, supporting system expansion and functional integration.

[0276] Specifically, a RESTful API can be designed to facilitate integration with other systems.

[0277] A plug-in mechanism can also be implemented to support functional extension, which allows developers to add new functions or expand existing functions without modifying the core of the system.

[0278] Specifically, a clear plug-in interface can be designed so that third-party developers can develop their own plug-ins according to the interface specifications; a plug-in management tool can be provided to allow users to easily install, uninstall, and enable / disable plug-ins. At the same time, the compatibility of plug-ins with the core system is ensured, and backward-compatible APIs and data structures are provided.

[0279] Furthermore, the transparent encryption model also includes a storm control strategy for maintaining network stability and preventing broadcast storms.

[0280] Specifically, before forwarding the encrypted data packet, the traffic pattern in the network where the encrypted data packet is located is analyzed to determine the type of traffic that induces the storm;

[0281] Dynamic regulation based on traffic type and storm control strategy;

[0282] The storm control strategy includes 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.

[0283] Storm control strategies in the transparent encryption model help maintain network stability and prevent broadcast storms. These strategies can be dynamically adjusted according to the traffic pattern of the network where the encrypted data packets are located, including rate limiting, token bucket algorithm, leaky bucket algorithm, broadcast storm control and multicast storm control. By limiting specific types of traffic or adjusting their transmission rates, network congestion and collapse caused by overload can be effectively prevented; controlling and scheduling traffic can make more efficient use of network resources and ensure the timely transmission of key data; prevent malicious attacks or unexpected broadcast storm events, and protect the network from unauthorized access or damage; strategies can be adjusted according to real-time network traffic conditions to adapt to different network environments and application requirements, thereby improving the adaptability and flexibility of the system.

[0284] The comprehensive application of these strategies can effectively optimize network performance and security, ensuring the secure transmission and stable operation of encrypted data.

[0285] Furthermore, the application also includes: implementing a comprehensive error handling mechanism and logging system. This includes capturing and recording possible abnormal situations, as well as recording key events and statistical information; good error handling and logging are essential for system maintainability and problem diagnosis.

[0286] Specifically, rate limiting includes: preventing the network from being overwhelmed by excessive traffic by limiting the sending rate of the device or application. It can be applied to a single device, a specific service, or the entire network.

[0287] The Token Bucket Algorithm is a traffic shaping technology that allows network devices to send a certain number of data packets within a certain period of time. Tokens are generated at a fixed rate and placed in a bucket. Tokens in the bucket are consumed when data packets are sent. If there are not enough tokens, the data packets will be delayed or discarded.

[0288] The leaky bucket algorithm is another traffic shaping technology, which is similar to the token bucket, but the tokens are generated at a fixed rate and gradually consumed. The leaky bucket can smooth out burst traffic and reduce network congestion.

[0289] Broadcast storm control is used to limit broadcast traffic and prevent the occurrence of broadcast storms. It can be achieved through the broadcast suppression function on network devices.

[0290] Multicast storm control is used to limit multicast traffic and prevent the occurrence of multicast storms. It can be achieved through multicast rate limiting or multicast suppression functions.

[0291] Through these methods, network traffic can be effectively controlled and managed, network storms can be prevented, and the stability and reliability of the network can be guaranteed.

[0292] Furthermore, some encryption algorithms may require that the length of the input data is a multiple of a specific value. In this case, an appropriate padding mechanism needs to be implemented; the padding follows a standard protocol (such as PKCS7) to ensure that the encrypted data can be correctly decrypted.

[0293] In the field of encryption, "padding" is a technique used to ensure that the length of the data to be encrypted meets the requirements of a specific encryption algorithm. Many encryption algorithms, especially block encryption algorithms (such as AES), require that the input data must be an integer multiple of the block size. If the data length is not an integer multiple of the block size, padding is needed to increase the length of the data to meet the requirements.

[0294] Specifically, the basic concepts of padding include block size and padding operations. Block size is the basic unit of data processed by the encryption algorithm, usually a fixed-length byte. 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.

[0295] PKCS7 is a commonly used padding standard proposed by RSA Laboratories. It ensures that padded data blocks can be decrypted correctly and the padded data can be identified and removed.

[0296] The basic steps of the PKCS7 padding mechanism are as follows: 1) Determine the padding length: Calculate the number of bytes required for padding. Assuming the block size is b and the original data length is l, the padding length p can be calculated by the following formula: p = b-(l%b); where % represents the modulo operation.

[0297] 2) Padding data: Add bytes of the padding length p value to the end of the data. The byte value of the padding is the padding length itself.

[0298] 3) Remove padding during decryption: After decryption, the original data is restored by identifying the padding byte value and removing the corresponding padding bytes.

[0299] Examples include: assuming the block size is 16 bytes (128 bits) and the original data length is 15 bytes, then the padding length p=16-(15%16)=1; one byte is padded, and the value is 1.

[0300] During decryption, the padding byte is identified as 1, and one padding byte is removed to restore the original 15 bytes of data.

[0301] 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 can be correctly restored when decrypted.

[0302] Furthermore, in an IP packet, the main thing that needs to be updated is the IP header checksum. In addition, if the packet contains upper layer protocols (such as TCP or UDP), the checksums of these protocols may also need to be recalculated. The system needs to identify all checksum fields that need to be updated.

[0303] Before starting to calculate a new checksum, the old checksum fields need to be cleared to zero. This is because the checksum calculation process requires these fields to be zero to get a correct result.

[0304] The calculation of the IP header checksum involves adding up all the 16-bit words in the IP header and then taking the complement. This process needs to take into account the byte order (big endian or little endian). When calculating, it is important to note that the header length may change due to IP options.

[0305] If the data packet contains upper layer protocols such as TCP or UDP, the checksum calculation of these protocols usually involves some fields in the IP header (such as source IP, destination IP), protocol-specific headers, and data payload. Since the data payload is encrypted, the calculation of this checksum becomes complicated. There are several possible processing methods:

[0306] Completely recalculate the checksum, including the encrypted data.

[0307] Using the incremental update method, only the impact of the changes is calculated.

[0308] In some cases, it may be necessary 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.

[0309] After the calculation is completed, the new checksum value is written to the corresponding field. For the IP header checksum, directly update the corresponding field in the IP header. For the upper layer protocol checksum, it may be necessary to locate YY+242200P in the encrypted data payload.

[0310] and update these fields.

[0311] After updating the checksum, verify that the calculation was correct. This can be done by recalculating the checksum and comparing it to the updated value. This step helps catch potential errors and ensures the integrity of the data packet.

[0312] Some special cases may require additional consideration, such as: checksum calculation when processing IP options, checksum update strategy when processing fragmented packets, checksum processing when processing protocols with special requirements (such as ICMP).

[0313] Through these detailed steps, the encrypted data payload can be effectively reassembled with the original IP header information and all relevant checksum fields can be correctly updated. This process ensures the integrity and validity of the encrypted data packet while maintaining compatibility with the existing network infrastructure. In actual implementation, performance optimization, error handling, and management of abnormal situations also need to be considered to ensure that the system can operate efficiently and reliably under various network conditions.

[0314] The data security protection method based on link layer transparent encryption disclosed in the present application is implemented at the link layer, which ensures the real-time performance of data encryption processing, that is, the data is encrypted once it is captured, reducing the risk of data exposure during transmission; through promiscuous mode capture and precise filtering, the performance loss caused by encryption processing of the entire network traffic is avoided, and the overall efficiency of the system is improved; the data is encrypted using a preset encryption algorithm and key, ensuring the confidentiality of the data, and only the authorized recipient can decrypt and read the data.

[0315] Example 1: Apply link layer transparent encryption in an enterprise intranet environment. For example, a large enterprise needs to improve the security of internal data transmission without changing the existing network architecture. With this technical solution, transparent encryption devices can be deployed at key nodes in the enterprise intranet. The specific implementation steps include: 1) Deploy transparent encryption devices between the core switch and department switches of the enterprise intranet; 2) Configure two network interfaces of the encryption device, one connected to the core switch and the other connected to the department switch; 3) Enable promiscuous mode to capture all data packets passing through the link; 4) Filter the captured data packets to identify the business data that needs to be encrypted; 5) Use the AES256 algorithm to encrypt the data payload, keeping the IP header information unchanged; 6) Forward the encrypted data packet to the target interface.

[0316] Through this deployment method, enterprises can implement encryption protection for sensitive data without affecting the existing network structure and applications. Employees do not need to perform any additional operations, and all encryption processes are completely transparent to them.

[0317] Example 2: Implementing transparent encryption in a cloud computing environment. For example, a cloud service provider wants to provide customers with additional data security without affecting the performance and availability of existing cloud services. This technical solution can be used to implement transparent encryption in a virtual network environment. The specific implementation steps include: 1) Integrating a transparent encryption function module in the virtual network management platform; 2) Allocating an independent encryption instance to each customer's virtual network; 3) Configuring encryption policies at the entrance and exit of the virtual network to define the types of traffic that need to be encrypted; 4) Using virtualization technology to achieve efficient data packet capture and processing; 5) Using hardware acceleration technology (such as Intel AESNI) to improve encryption efficiency; 6) Implementing dynamic key management and regularly updating encryption keys.

[0318] In this way, cloud service providers can provide customers with end-to-end data encryption services while maintaining the high performance and flexibility of cloud services. Customers can easily configure and manage encryption policies through the control panel without modifying their applications or network configurations.

[0319] Example 3: Apply link layer transparent encryption in IoT scenarios. For example, in a smart factory environment, it is necessary to protect sensitive data generated by a large number of IoT devices. Since these devices usually have limited computing power and it is difficult to implement complex encryption algorithms, this technical solution can achieve secure data transmission without increasing the burden on the equipment.

[0320] The specific implementation steps include: 1) integrating a transparent encryption module into the IoT gateway device; 2) configuring the IoT gateway to enable it to identify and classify different types of IoT device data; 3) enabling transparent encryption for sensitive data that needs to be protected, such as production parameters, device status, etc.; 4) using lightweight encryption algorithms (such as ChaCha20) for data encryption to meet the low latency requirements of the IoT environment; 5) implementing a device authentication mechanism to ensure that only authorized devices can access the network; 6) providing centralized key management to simplify the security management of large-scale IoT deployments.

[0321] Through this solution, smart factories can significantly improve the security of data transmission without upgrading existing IoT devices. At the same time, since the encryption process is performed at the gateway, it will not increase the computing burden of IoT devices, ensuring the real-time and reliability of the system.

[0322] These examples demonstrate the application flexibility and effectiveness of this technical solution in different scenarios. Whether in traditional enterprise networks, cloud computing environments or the emerging IoT field, link layer-based transparent encryption technology can provide efficient and seamless data security protection while maintaining good compatibility with existing systems.

[0323] Reference Figure 7 The second aspect of the present application discloses a data security protection system based on link layer transparent encryption, comprising:

[0324] A setting module 11, used to determine a number of network interfaces of the configured transparent encryption model based on a configuration file or user input information, and set the mode of the number of network interfaces to a promiscuous mode;

[0325] The filtering module 12 is used to start the 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 number of original data packets that need to be encrypted, which are recorded as a number of first data packets;

[0326] An acquisition module 13, configured to parse the first data packet based on a transparent encryption model to acquire information of an IP header;

[0327] A determination module 14 is used to determine the starting position and length of the IP packet data payload based on the information in the IP header, and determine the target data payload based on the starting position and length;

[0328] The encryption module 15 is used to encrypt the target data payload based on a preset encryption algorithm and an encryption key to obtain an encrypted data payload;

[0329] An updating module 16, used for dynamically updating information of the IP header based on the encrypted data payload;

[0330] The reassembly module 17 is used to reassemble the updated IP header information and the encrypted data payload into an encrypted data packet, and forward the encrypted data packet to the target interface.

[0331] The computer device according to the embodiment of the present disclosure includes a memory and a processor. The memory is used to store non-temporary computer-readable instructions. Specifically, the memory may include one or more computer program products, and the computer program product may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include a random access memory (RAM) and / or a cache memory (cache), etc. The non-volatile memory may, for example, include a read-only memory (ROM), a hard disk, a flash memory, etc.

[0332] The processor may be a central processing unit (CPU) or other forms of processing units with data processing capabilities and / or instruction execution capabilities, and may control other components in the computer device to perform desired functions. In one embodiment of the present disclosure, the processor is used to run the computer-readable instructions stored in the memory, so that the computer device performs all or part of the steps of the data security protection method based on link layer transparent encryption in the aforementioned embodiments of the present disclosure.

[0333] Those skilled in the art should be able to understand that in order to solve the technical problem of how to obtain a good user experience, the present embodiment may also include well-known structures such as a communication bus and an interface, and these well-known structures should also be included in the protection scope of the present disclosure.

[0334] like Figure 8 A schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure is shown, which is a schematic diagram of the structure of a computer device suitable for implementing the embodiment of the present disclosure. Figure 8 The computer device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0335] like Figure 8 As shown, the computer device may include a processor (e.g., a central processing unit, a graphics processing unit, etc.), which can 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 via a bus. An input / output (I / O) interface is also connected to the bus.

[0336] Typically, the following devices can be connected to the I / O interface: input devices such as sensors or visual information acquisition devices; output devices such as display screens; storage devices such as tapes, hard disks, etc.; and communication devices. The communication device can allow the computer device to communicate with other devices (such as edge computing devices) wirelessly or by wire to exchange data. Figure 8 A computer device having various devices is shown, but it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed instead.

[0337] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device, or installed from a ROM. When the computer program is executed by a processor, all or part of the steps of the data security protection method based on link layer transparent encryption of an embodiment of the present disclosure are executed.

[0338] For detailed description of this embodiment, reference may be made to the corresponding descriptions in the aforementioned embodiments, which will not be repeated here.

[0339] According to the computer-readable storage medium of the embodiment of the present disclosure, non-transitory computer-readable instructions are stored thereon. When the non-transitory computer-readable instructions are executed by the processor, all or part of the steps of the data security protection method based on link layer transparent encryption of the aforementioned embodiments of the present disclosure are executed.

[0340] The above-mentioned 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., magnetic tape or mobile hard disk), media with built-in rewritable non-volatile memory (e.g., memory card) and media with built-in ROM (e.g., ROM box).

[0341] For detailed description of this embodiment, reference may be made to the corresponding descriptions in the aforementioned embodiments, which will not be repeated here.

[0342] The basic principles of the present disclosure are described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, effects, etc. mentioned in the present disclosure are only examples and not limitations, and it cannot be considered that these advantages, strengths, effects, etc. are required by each embodiment of the present disclosure. In addition, the specific details disclosed above are only for the purpose of illustration and ease of understanding, and are not limitations. The above details do not limit the present disclosure to the necessity of adopting the above specific details to be implemented.

[0343] In the present disclosure, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. The block diagrams of the devices, devices, equipment, and systems involved in the present disclosure are only illustrative examples and are not intended to require or imply that they must be connected, arranged, and configured in the manner shown in the block diagram. As will be appreciated by those skilled in the art, these devices, devices, equipment, and systems can be connected, arranged, and configured in any manner. Words such as "including", "comprising", "having", etc. are open words, referring to "including but not limited to", and can be used interchangeably with them. The words "or" and "and" used here refer to the words "and / or" and can be used interchangeably with them, unless the context clearly indicates otherwise. The words "such as" used here refer to the phrase "such as but not limited to", and can be used interchangeably with them.

[0344] Additionally, as used herein, "or" used in a list of items beginning with "at least one" indicates a separate list, so that, for example, a list 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). Furthermore, the word "exemplary" does not mean that the example described is preferred or better than other examples.

[0345] It should also be noted that in the system and method of the present disclosure, each component or each step can be decomposed and / or recombined. Such decomposition and / or recombination should be regarded as equivalent solutions of the present disclosure.

[0346] Various changes, substitutions, and modifications of the techniques described herein may be made without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of the present disclosure is not limited to the specific aspects of the processes, machines, manufactures, compositions of events, means, methods, and actions described above. Currently existing or later to be developed processes, machines, manufactures, compositions of events, means, methods, or actions that perform substantially the same functions or achieve substantially the same results as the corresponding aspects described herein may be utilized. Thus, the appended claims include such processes, machines, manufactures, compositions of events, means, methods, or actions within their scope.

[0347] The above 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 general principles defined herein may be applied to other aspects without departing from the scope of the present disclosure. Therefore, the present disclosure is not intended to be limited to the aspects shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

[0348] The above description has been given for the purpose of illustration and description. In addition, this description is not intended to limit the embodiments of the present disclosure to the forms disclosed herein. Although multiple example aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, changes, additions and sub-combinations thereof.

Claims

1. A data security protection method based on link layer transparent encryption, characterized in that: include: Configuring a number of network interfaces of a transparent encryption model, and setting a mode of the number of said network interfaces to a promiscuous mode; Starting the promiscuous mode, capturing the original data packets passing through the target link based on the transparent encryption model, and filtering the original data packets to obtain a number of original data packets that need to be encrypted, which are recorded as a number of first data packets; Parsing the first data packet based on the transparent encryption model to obtain information of the IP header; Determine the starting position and length of the IP packet data payload based on the information of the IP header, and determine the target data payload based on the starting position and the length; Encrypting the target data payload based on a preset encryption algorithm and an encryption key to obtain an encrypted data payload; Based on the encrypted data payload, dynamically update the information of the IP header; The updated IP header information and the encrypted data payload are reassembled into an encrypted data packet, and the encrypted data packet is forwarded to a target interface.

2. The data security protection method based on link layer transparent encryption according to claim 1 is characterized in that: The transparent encryption model includes a data packet capture strategy, a data packet filtering strategy, a data packet parsing strategy, a data packet encryption strategy and a forwarding strategy; The data packet capture strategy includes capture filter information, capture buffer size information, capture mode information, size information of the data packet to be captured and a preset function.

3. The data security protection method based on link layer transparent encryption according to claim 1 is characterized in that: The dynamically updating the information of the IP header based on the encrypted data payload includes: Based on the encrypted data payload, the total length of the IP header is changed, and the sum of the total length of the changed IP header and the total length of the encrypted data payload is consistent with the total length of the original data packet; Based on the total length of the changed IP header, the checksum of the IP header is updated to obtain an updated IP header.

4. The data security protection method based on link layer transparent encryption according to claim 3 is characterized in that: The step of reorganizing the updated IP header information and the encrypted data payload into an encrypted data packet includes: Configuring a reassembly buffer, wherein the size of the reassembly buffer is not less than the sum of the size of the updated IP header and the size of the encrypted data payload; The updated IP header and the encrypted data payload are reassembled in the reassembly buffer to obtain an encrypted data packet.

5. The data security protection method based on link layer transparent encryption according to claim 4 is characterized in that: The step of reassembling the updated IP header and the encrypted data payload in the reassembly buffer to obtain an encrypted data packet includes: Copying the updated IP header to the beginning of the reassembly buffer; The encrypted data payload is placed after the copy position of the updated IP header, and the setting position of the encrypted data payload is adjacent to the copy position of the updated IP header.

6. The data security protection method based on link layer transparent encryption according to claim 5 is characterized in that: Also includes: Adding metadata during the encryption process, the metadata including one or more of an initialization vector and an authentication tag; The size of the reassembly buffer is not less than the sum of the size of the updated IP header, the size of the encrypted data payload 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 setting position of the encrypted data payload.

7. The data security protection method based on link layer transparent encryption according to claim 6 is characterized in that: If the original data packet is a fragment, updating the fragment offset based on the size of the encrypted data packet; If the encrypted data packet needs to be transmitted in fragments, the encrypted data packet is divided into several blocks, and the fragment offset and more fragment flag of each block are updated.

8. The data security protection method based on link layer transparent encryption according to claim 1 is characterized in that: The preset encryption algorithm includes AES algorithm or ChaCha20 algorithm; The method for obtaining the encryption key includes: Determine 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 includes a local private key and a local public key; Exchange the local public key of each communication party based on a preset security protocol; Based on the local private key and the other party's public key, a shared key is obtained; the other party's public key is the local public key sent by the exchange party and received by the communication party corresponding to the local public key; An encryption key is generated from the shared key using a key derivation function.

9. The data security protection method based on link layer transparent encryption according to claim 8 is characterized in that: The local public key of each communication party is exchanged based on the preset security protocol, YY+242200P include: Determine certificate information of the digital certificate, the certificate information including certificate standard, certificate format, certificate chain information, certificate verification mechanism and certificate storage mechanism; Formulate a two-way authentication protocol strategy based on the certificate information; Perform identity authentication of the first end and the second end based on the two-way authentication protocol strategy and the certificate information, and after the identity authentication is passed, exchange the local public key of each communication party based on a preset security protocol; The first end is a first communication party, and the second end is a second communication party to be subjected to public key exchange.

10. The data security protection method based on link layer transparent encryption according to any one of claims 1 to 9, characterized in that: The transparent encryption model also includes a storm control strategy; Before forwarding the encrypted data packet, analyzing the traffic pattern in the network where the encrypted data packet is located to determine the traffic type that induces the storm; Dynamically control based on the traffic type and the storm control strategy; The storm control strategy includes 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.

Images