Password algorithm adaptation and hardware encryption and decryption acceleration method suitable for gateway protocol

Abstract

The invention discloses a cryptographic algorithm adaptation and hardware encryption and decryption acceleration method suitable for a gateway protocol, deep integration of a cryptographic algorithm is realized through protocol stack-level native transformation, software and hardware collaborative design is adopted, and through innovative mechanisms such as multi-thread concurrent encryption, asynchronous interrupt processing and DMA data interaction, the hardware encryption and decryption acceleration of the cryptographic algorithm is realized. The processing capability in a high throughput scene is improved; an intelligent strategy engine is introduced to realize data packet dynamic classification and encrypted resource optimization scheduling, and the system performance is maximized while the security is ensured; according to the technical scheme, key full-life-cycle management and control are achieved through the HSM, the requirement for equal insurance 2.0 is met, multi-platform deployment is supported by adopting modular design, and compared with the prior art, the method can be flexibly adapted to various application scenes such as various domestic chip architectures, embedded devices, security gateways and industrial controllers, and the method is suitable for large-scale popularization and application. The problems of high platform dependence, difficulty in transplantation and the like existing in national secret IPSec implementation are solved, and a better secure communication solution is provided for a localized environment.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of network communication security, and particularly relates to a method for cipher algorithm adaptation and hardware encryption and decryption acceleration suitable for gateway protocols. BACKGROUND

[0002] IPSec (Internet Protocol Security, IP layer encryption communication protocol) is a set of IP layer security protocol families defined by IETF, which is used to provide encrypted communication and data authentication network security protocol in IP network, and is widely used in VPN and other scenarios, such as Figure 1 As IP packets do not integrate any security features, IP packets transmitted in public networks (such as the Internet) may face the risk of being forged, stolen or tampered with. The communication parties establish an IPsec tunnel, and the IP packets are transmitted through the IPsec tunnel for encryption, which ensures the security of data transmission in an insecure network environment to a certain extent.

[0003] IPSec realizes end-to-end secure communication by providing data encryption and authentication protection at the IP layer, and the existing technical solutions widely use international general cipher algorithm systems such as AES, SHA and RSA. IPSec mainly includes three important protocols:

[0004] 1) IKE (Internet Key Exchange, Internet Key Exchange) protocol, a protocol for automatically negotiating security association (SA, Security Association) parameters and keys, which is a key component of IPSec, and supports multiple key exchange algorithms;

[0005] 2) AH (Authentication Header, Authentication Header) protocol;

[0006] 3) ESP (Encapsulating Security Payload, Encapsulating Security Payload) protocol, a core protocol in IPSec protocol, responsible for data encryption and / or authentication encapsulation processing, and is the main technical means to realize encrypted tunnel.

[0007] In the working process of IPSec, the IKE protocol (taking IKEv1 as an example) is responsible for the negotiation of SA (Security Association) security association and key management, to ensure that the communication parties can securely establish an encrypted channel. SA is an agreement between the communication parties on certain negotiation elements, such as the security protocol used by both parties, the encapsulation mode used for data transmission, the encryption and verification algorithm used by the protocol, the key used for data transmission, etc. Only after the SA is established between the communication parties, can the data transmission be securely performed.

[0008] The negotiation process of IKEv1 is divided into two stages: the first stage establishes IKE SA through the main mode or the brutal mode, exchanges Diffie-Hellman public key and generates a shared key, and completes identity authentication; the second stage quickly negotiates IPSec SA based on the established IKE SA, and determines the specific encryption and authentication parameters of ESP or AH. This mechanism enables IPSec to adapt to different network environment requirements while ensuring security. In terms of data encryption transmission, IPSec mainly relies on the ESP protocol to realize the confidentiality and integrity protection of data. The ESP protocol uses international standard algorithms such as AES to realize data encryption, and generates integrity check values through algorithms such as HMAC-SHA256, effectively preventing data tampering and replay attacks. In the data processing flow, the sending end first encrypts the original IP packet (such as using the AES-CBC algorithm), adds the ESP header and tail, and calculates the integrity check value (ICV); the receiving end performs the verification and decryption process in reverse. At the same time, IPSec supports transmission mode and tunnel mode, which provides flexible security solutions for different application scenarios. The transmission mode only encrypts the data payload, suitable for direct secure communication between hosts. In tunnel mode, the entire original IP packet is encrypted, and a new IP header is added to hide the real communication endpoint, making it an ideal choice for VPN gateway scenarios.

[0009] Through encryption protection at the IP layer, IPSec effectively prevents network monitoring, data tampering and other security threats, and becomes an important technology for building secure network infrastructure. With the continuous improvement of network security needs, IPSec protocol and its implementation technology are still evolving to cope with the increasingly complex network threat environment.

[0010] Although the IPSec protocol system has formed a relatively mature and stable implementation architecture internationally, it still faces many technical challenges and limitations in domestic practical application environment. First, the existing IPSec protocol stack is generally based on international standard algorithm system (such as AES, SHA, RSA) to build, which is difficult to meet the mandatory compliance requirements of domestic cryptographic algorithms (SM2, SM3, SM4, China Commercial Cryptographic Algorithm Standard issued by the National Cryptographic Administration, used for asymmetric encryption, hash digest and symmetric encryption) in key fields such as government affairs, finance and industry. Under the current technical scheme, the national cryptographic algorithm can only be integrated in a software simulation manner, lacking specific protocol adaptation mechanism and hardware acceleration support, resulting in a significant decrease in encryption and decryption performance, making it difficult to support secure communication needs in high-performance scenarios, especially in application environments such as gateways and edge computing that require line-speed processing.

[0011] Although the current mainstream implementation (such as the XFRM framework of the Linux kernel) has relatively mature kernel-level optimization on algorithms such as AES and SHA, it lacks underlying collaborative mechanisms for supporting national cryptographic algorithms, and related implementations mostly rely on user-mode software stack simulation execution, which seriously restricts the protocol performance and system throughput capacity. Even if some manufacturers try to introduce special encryption cards or FPGA solutions for performance improvement, these hardware mostly faces international standard algorithms, and it is difficult to be compatible with the instruction structure and operation mode of national cryptographic algorithms, and the deployment cost is high, the development is complex, and it is difficult to flexibly respond to dynamic business requirements. In addition, at the protocol level, the key negotiation protocols such as IKEv1 / v2 and national cryptographic algorithms have not established a unified interface standard, and the implementations of different manufacturers have great differences, which leads to insufficient interconnection and intercommunication capacity between systems, further limiting the widespread promotion and application of IPSec protocol in the domestic environment.

[0012] From the perspective of hardware resource utilization, the encryption acceleration instructions provided by the existing general-purpose CPU (such as Intel AES-NI) cannot directly support SM series algorithms, and the ASIC encryption chip lacking flexibility is difficult to quickly adapt to protocol evolution and algorithm update. This situation shows that, under the premise of guaranteeing national cryptographic compliance, to realize high-performance, secure and compatible IPSec communication, it is necessary to build an integrated technical mechanism with the ability to adapt to domestic cryptographic algorithms, the ability of software and hardware collaborative acceleration and the ability of dynamic key management at the protocol stack level, and to fundamentally break through the performance bottleneck and adaptation barrier of existing technologies. SUMMARY

[0013] In order to solve the problems of the prior art and realize the integrated national cryptographic IPSec communication with soft and hard collaboration, dynamic control and flexible deployment, the technical scheme adopted by the present application is as follows:

[0014] The method for adapting cryptographic algorithms suitable for gateway protocols and hardware encryption and decryption acceleration is based on the IP layer encryption communication protocol IPSec, and an IPSec protocol stack adaptation layer is constructed between the transmission layer and the IP layer to establish an IPsec tunnel. IP data packets are transmitted through the IPsec tunnel for encryption. The IPSec protocol stack adaptation layer includes a software end and a hardware end. The software end includes a scheduling layer, an IPsec protocol stack, an abstract driver layer and a key management module. The hardware end includes a domestic encryption chip and a hardware security module HSM (Hardware Security Module). The IPsec protocol stack includes an Internet Key Exchange IKE module and an Encapsulating Security Payload ESP module. The method includes the following steps:

[0015] Step 1: Software end IPsec protocol stack modification

[0016] The IKE module is used for negotiation of a security association (SA) and key management, so that the two communication parties establish a secure encrypted channel, the SA is an agreement of the two communication parties on negotiation elements, and data transmission is performed after the agreement; the negotiation process includes two stages, in the first stage, the SA is established through a main mode or a brutal mode, public keys are exchanged, a shared key is generated, and identity authentication is completed; in the second stage, the SA of the IPSec protocol is quickly negotiated based on the established SA, so that the encryption and authentication parameters of an encapsulating security payload (ESP) or an authentication header (AH) are determined, this mechanism enables the IPSec to flexibly adapt to different network environment requirements while ensuring security; the key exchange of the IKE module is replaced from the original DH algorithm to the national secret SM2 elliptic curve key negotiation algorithm; the ESP module is used for encryption and decryption of data and / or authentication encapsulation processing, so that the confidentiality and integrity of data are protected, the ESP module adopts the AES algorithm to perform data encryption, and generates an integrity check value (ICV) through an HMAC-SHA256 algorithm or the like, so that data tampering and replay attacks are effectively prevented; in the application, the encryption and decryption module and the integrity check module in the encapsulation of the ESP module are replaced in algorithm, the encryption and decryption is replaced from the original AES-CBC or AES-GCM to the SM4-CBC or SM4-CTR of the national secret SM4 algorithm, CBC represents cipher block chaining, CTR represents a counter, the block cipher is converted into a stream cipher through SM4, the message authentication is replaced from the original HMAC-SHA256 to the HMAC-SM3 of the national secret SM3 algorithm, HMAC represents a hash-based message authentication code; the encryption algorithm and the process are replaced in a native way from a bottom protocol layer, the traditional encryption algorithm and the process are replaced, and the consistency and compatibility of the system architecture are ensured.

[0017] Step two: hardware end cooperation; decoupling the IPSec protocol stack from the hardware end, so as to dynamically decide whether to enable hardware acceleration according to conditions;

[0018] Step three: scheduling control logic construction; the encryption and decryption path scheduling is referred to through a scheduling layer, and the encryption and decryption task is dynamically decided to execute software end encryption and decryption or hardware end encryption and decryption at runtime;

[0019] Step four: key management system integration; a complete key life cycle control mechanism is constructed through a key management module.

[0020] Further, in the IPSec protocol stack of step one, the Chinese national cryptographic SM4 algorithm includes the Chinese national cryptographic ciphertext block linking algorithm SM4-CBC or the Chinese national cryptographic counter algorithm SM4-CTR, which converts block ciphers into stream ciphers; the Chinese national cryptographic SM3 algorithm includes the Chinese national cryptographic hash-based message authentication code algorithm HMAC-SM3; based on the gateway platform, SM4-CBC, SM4-CTR, and HMAC-SM3 are registered to the cryptographic application programming interface CryptoAPI through the crypto_register_alg() or crypto_register_aead() interface, and attached to xfrm_algo.c, which manages encryption and authentication algorithms. In the relevant table entries; in the Security Association (SA) structure, the identification field for the national cryptographic algorithm type is extended to enable the coexistence of national cryptographic algorithms and traditional algorithms; in the IKEv2 implementation, the SM2 plugin of IKE tools such as StrongSwan is extended to perform national cryptographic certificate exchange and session key negotiation based on the national cryptographic SM2 elliptic curve key negotiation algorithm; the configuration method includes specifying key exchange through national cryptographic algorithms in the ipsec.conf configuration file (IKEike=sm2-sm3-sm4), configuring the national cryptographic certificate and private key path in the ipsec.secrets sensitive information configuration file, and calling the hardware private key through PKCS#11 or the domestic GMAPI interface.

[0021] Furthermore, in step one, the internal state length and initialization / release logic of the Chinese national cryptographic SM4 algorithm differ from the existing AES algorithm implementation in the kernel. When registering directly, the settings of fields such as cra_ctxsize and cra_u in the crypto_alg structure may lead to algorithm context mismatch, thereby causing kernel crashes, NULL references, or memory out-of-bounds issues. To avoid this situation, this invention redefines the relevant fields of the crypto_alg structure when registering the Chinese national cryptographic SM4 algorithm to align it with the internal state length of the Chinese national cryptographic SM4 algorithm. By adding a unified sm_ctx_adapter adaptation layer, the Chinese national cryptographic SM4 algorithm adapts to the memory layout of the context allocation and release phases, thereby achieving compatibility between the Chinese national cryptographic SM4 algorithm and the kernel encryption context. This avoids kernel crashes caused by algorithm context mismatch and ensures that the Chinese national cryptographic SM4 algorithm can be successfully integrated into the kernel encryption framework without affecting the stability of the existing system.

[0022] Existing SA / Policy structures are typically designed based on traditional algorithm families (such as AES / HMAC-SHA), lacking national cryptographic algorithm types and version identifiers, leading to negotiation or routing matching errors. To effectively support the coexistence of national cryptographic algorithms and traditional algorithms, this invention adds a gm_alg_flag identifier field to the SA structure to indicate whether the current SA has enabled national cryptographic algorithms. Through this field, we achieve dynamic coexistence and switching between traditional and national cryptographic algorithms. On the other hand, when the peer does not support national cryptographic algorithms or HSM is abnormal, without a smooth fallback mechanism, tunnel establishment will fail or traffic will be interrupted. Therefore, this invention uses the gm_alg_flag identifier field to automatically fall back to the traditional AES / SHA algorithm path when national cryptographic algorithms cannot be enabled, ensuring high availability and compatibility of the protocol, avoiding service interruption due to the unavailability of national cryptographic algorithms, improving system robustness, increasing the flexibility of the protocol stack, supporting the parallel operation of different algorithms, and meeting different security requirements.

[0023] The Chinese national cryptographic algorithm SM2 can be used for both signatures and key exchange, but its public key representation, KE payload, and derivation process when SM3 is used as a PRF differ from the traditional DH+PRF. For example, the Chinese national cryptographic algorithm SM2 uses fixed elliptic curve parameters and specific KDF functions, while the traditional DH protocol does not have these constraints. Therefore, direct replacement may lead to IKE negotiation failure or the generation of incorrect session keys. To solve this problem, this invention adds a dedicated SM2 Transform type and SM3-HMAC derivation function extension for Chinese national cryptographic algorithms to the StrongSwan IKE implementation. This ensures that IKEv2 correctly identifies the Chinese national cryptographic algorithm family and completes PRF key derivation during SA negotiation. At the same time, an automatic certificate OID identification mechanism is introduced to select the Chinese national cryptographic algorithm SM2 or RSA algorithm path based on the certificate OID field, thereby achieving hybrid compatibility and avoiding insufficient peer-to-peer interoperability and degradation strategies during runtime.

[0024] Furthermore, the software side also includes an abstract driver layer, and the hardware side includes a domestically produced encryption chip. In step two, the encryption process at the sending end involves registering the national cryptographic algorithms supported by the domestically produced encryption chip to the kernel's Crypto API framework for transparent calling by the IPSec protocol stack. The application layer initiates an encryption request, and the data is encapsulated by the transport layer and then enters the IPSec protocol stack adaptation layer. The ESP module uses the crypto_aead_encrypt() interface to communicate with the kernel's application programming interface Crypto. The API initiates an encryption request; the scheduling layer collects the running status and data packet characteristics in real time to decide whether to use the hardware acceleration path. If so, the scheduling layer decides to use the hardware encryption path. The abstract driver layer transfers the data block to be encrypted and the key context to the domestic encryption chip through direct memory access (DMA). The hardware module performs encryption using the national cryptographic SM4 algorithm and integrity calculation using the national cryptographic HMAC-SM3 algorithm. The data is directly transferred from memory to the internal cache of the domestic encryption chip, without the need for CPU involvement in data transfer, reducing bus occupancy. After receiving the data, the domestic encryption chip performs encryption operations to generate encrypted ciphertext data. After encryption is complete, it notifies the Linux kernel through an interrupt signal. The kernel triggers the interrupt handler function, reads the ciphertext data from the internal cache of the domestic encryption chip, and passes it back to the IPSec protocol stack. If not, software encryption is performed using kernel software. The scheduling layer decides to use the software encryption path. The kernel's application programming interface (API) Crypto API calls the software to implement the national cryptographic algorithm, uses the CPU to encrypt the plaintext data, generates ciphertext data, and passes it back to the IPSec protocol stack. The ciphertext data is encapsulated by the ESP module according to the IPSec ESP protocol format, adding ESP headers, verification data, etc., and then transmitted to the receiving end through the IP layer.

[0025] Furthermore, due to differences in vendor PKCS#11 and local GMAPI, interface versions, and context management, direct calls may result in handle leaks, blocking, or improperly handled exception returns. If the hardware is unavailable or the queue is blocked, a unified abstract driver is designed at the application layer to automatically retry or fall back to the software encryption path in case of hardware call failures using an asynchronous task queue. This allows encryption to be completed by calling the kernel's built-in SM4 / SM3 algorithm, ensuring that the key signing operation is not interrupted and thus guaranteeing the continuity and high availability of the key signing operation.

[0026] Furthermore, the software side also includes an abstraction driver layer, and the hardware side includes a domestically produced encryption chip;

[0027] In step two, the receiving end decryption process involves passing the ciphertext data received from the IP layer to the IPSec protocol stack adaptation layer to extract the ciphertext and authentication data. The ESP module initiates a decryption request to the kernel's Crypto API through the crypto_aead_encrypt() interface. The scheduling layer collects the running status and data packet characteristics in real time to decide whether to use the hardware acceleration path. If so, the scheduling layer decides to use the hardware decryption path. The abstract driver layer transmits the ciphertext to the domestic encryption chip through direct memory access (DMA). The hardware module performs decryption using the national cryptographic SM4 algorithm and verification using the national cryptographic HMAC-SM3 algorithm. After the domestic encryption chip completes decryption, it notifies the Linux kernel through an interrupt signal. The kernel triggers an interrupt handler function, reads the plaintext data from the domestic encryption chip's internal cache, and passes it back to the IPSec protocol stack. If not, the scheduling layer decides to use the software decryption path. The kernel's Crypto API calls the software to implement the national cryptographic algorithm, uses the CPU to decrypt the ciphertext data, generates plaintext data, and passes it back to the IPSec protocol stack. The plaintext data is then passed up to the transport layer.

[0028] Furthermore, if a hardware malfunction occurs or a response times out, a unified abstract driver is designed at the application layer. An asynchronous task queue is used to automatically retry or automatically fall back to the software decryption path for hardware call failures, and the kernel's built-in SM4 / SM3 algorithm is called to complete the decryption, thereby ensuring uninterrupted communication.

[0029] Furthermore, when hardware acceleration is enabled, the abstract driver layer directly transfers the data block to be encrypted from system memory to the buffer of the domestic encryption chip via Direct Memory Access (DMA). If page replacement or bus contention occurs during the DMA transfer, data fragments may be lost, rearranged, or overwritten, resulting in incomplete data received by the encryption chip, leading to incorrect encryption results or authentication failure. To ensure the integrity and consistency of data transmission, the abstract driver layer calls the `dma_map_single()` function to perform a fixed mapping of the memory region to be transferred before initiating the DMA transfer, ensuring that the corresponding memory pages are mapped during the transfer. During the process, the data is locked in physical memory, preventing it from being swapped out or modified by the kernel's memory management mechanism, thus ensuring the physical continuity of DMA access. After the transfer is completed, the mapping is released by dma_unmap_single(), releasing the locked memory resources. In addition, data verification mechanisms are introduced before and after direct memory access DMA transfer. Before the transfer, the checksum of the source data is calculated and transferred along with the data. After the transfer, the checksum is recalculated by the domestic encryption chip or abstract driver layer. If the checksum is inconsistent, a retransmission is triggered, which effectively prevents data errors caused by hardware contention or memory remapping during DMA transfer and significantly improves the reliability of data transmission.

[0030] After completing the encryption or decryption task, the domestic encryption chip will notify the driver layer to retrieve the result via an interrupt. However, when the system is under high load (such as when the kernel is performing scheduling or network interrupt handling), the interrupt response may be delayed, resulting in the ciphertext result not being returned in time, affecting the real-time performance of the VPN data stream, and even causing tunnel establishment timeout. Therefore, this invention combines interrupt priority with threading technology to ensure that hardware interrupt events are handled in a timely manner. Specifically, during the interrupt registration phase, the IRQF_HIGHPRI flag of the request_irq() function is used to set the interrupt of the domestic encryption chip to a high priority, so that the domestic encryption chip can respond first in the kernel scheduling competition. Then, the time-consuming task is put into the threaded interrupt request_threaded_irq() for execution, and the interrupt flag is quickly cleared only in the top half to shorten the execution time of the critical path and reduce the impact on other kernel interrupts.

[0031] During system operation, when hardware resources are unavailable, DMA tasks time out, or chip load is too high, the scheduling layer automatically switches the encryption path of the IPSec protocol stack from hardware mode to software mode. However, if the Security Association (SA) structure fails to correctly synchronize state information such as key, IV, and sequence number during the switching process, it may lead to subsequent encryption / decryption failures, packet authentication errors, or replay detection failures. To solve the problem of inconsistent states during hardware / software switching, this invention extends the path_status field in the SA structure to record the current encryption or decryption path state (hardware / software), switching time, switching reason, and other operational information. When the scheduling layer performs path switching, it first calls xfrm_state_lock() to lock the SA state to prevent it from being modified by other kernel threads or concurrent processes during the switching process. Then, according to the new path type (hardware or software), it synchronously updates the extended field path_status and key fields such as session key, IV, and sequence number to ensure that the security context of the two paths (hardware or software) remains consistent. After the switching is completed, xfrm_state_unlock() is called to release the lock resources to ensure that the switching process of the SA state between hardware and software paths is atomic and consistent.

[0032] Furthermore, in step four, taking the SM2 key management of a single IPSec communication as an example, the process is as follows: First, during the negotiation phase of the IKE module, after both communicating parties complete identity authentication, a session key pair is generated based on the national cryptographic SM2 algorithm, and a lifecycle parameter is bound to the key pair, such as setting the validity period to 24 hours and the maximum number of uses to 10,000 encryptions. During the key usage process, the usage status of the lifecycle parameter is monitored in real time. When the key lifecycle parameter is detected to reach the threshold, such as when the remaining validity period is less than 2 hours or the number of uses has reached 9,000, a key rotation warning will be triggered. After the warning is triggered, the system automatically initiates the IKE rekey process to negotiate with the other party to generate a new SM2 key pair. After the new key takes effect, the old key enters the "pending revocation" state. After all encrypted data based on the old key is decrypted, the old key is automatically revoked. All key status changes (generation, activation, rotation, revocation) will be written to the key management module, supporting external supervision and query of key lifecycle behavior, and providing technical support for the Information Security Protection 2.0 and cryptographic compliance management.

[0033] Furthermore, the IPSec protocol stack adaptation layer also includes a hardware security module (HSM) for storing encryption keys and performing encryption operations. It has a high level of security against tampering and leakage and is often used in compliant scenarios where keys cannot be exported. The private key of the domestic SM2 algorithm is written to the HSM security area through the PKCS#11 interface and cannot be exported. All signature operations are completed in the HSM. The private key in the HSM can be called through the libstrongswan-pkcs11 module using IKE tools such as StrongSwan, ensuring the security and trustworthiness of the identity authentication process.

[0034] The advantages and beneficial effects of this invention are as follows:

[0035] This invention, centered on seamless protocol stack-level modification and chip-level co-design, constructs a complete technical closed-loop, flexible deployment, and performance-compliant IPSec national cryptographic encryption communication solution. It is applicable to high-security data communication links and easily promoted to domestic information infrastructure, laying the foundation for fully domestically produced cryptographic communication. The method can be widely applied to VPN gateways, industrial edge communication gateways, and secure entry / exit firewalls in government, finance, and power sectors, adapting to VPN communication scenarios with high compliance requirements for encrypted data transmission. This invention directly serves the forwarding, control, and encrypted communication functions of gateway-related products, while also directly supporting sub-projects such as "standardization of national cryptographic protocols" and "enhanced edge security capabilities" in projects. It possesses significant engineering value and practical potential for achieving independent control of domestic platform security products. Attached Figure Description

[0036] Figure 1 This is an architecture diagram of the native IPsec protocol stack adaptation layer in existing technology.

[0037] Figure 2 This is a flowchart of the method in an embodiment of the present invention.

[0038] Figure 3 This is a schematic diagram of the protocol stack modification in an embodiment of the present invention.

[0039] Figure 4 This is a flowchart of the scheduling control in an embodiment of the present invention. Detailed Implementation

[0040] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0041] This invention proposes a method for cryptographic algorithm adaptation and hardware encryption / decryption acceleration suitable for gateway protocols. Aimed at network communication applications on domestic platforms in high-security environments, it aims to integrate and replace the SM series of Chinese cryptographic algorithms based on the existing IPSec protocol stack architecture without altering the communication logic. Furthermore, it combines the hardware acceleration capabilities provided by domestic encryption chips, designs a policy control module to achieve intelligent encryption path switching, and ensures controllable security for long-term communication through an automated key management mechanism. Figure 2 As shown, the specific steps include the following:

[0042] Step 1: Modify the software protocol stack.

[0043] In the IPSec protocol stack, the encryption / decryption and integrity verification modules within the ESP encapsulation undergo algorithm replacement: The symmetric encryption part replaces the original AES-CBC or AES-GCM with SM4-CBC or SM4-CTR, where CBC (Cipher Block Chaining) represents ciphertext block chaining, and CTR (Counter) represents a counter. SM4 converts block ciphers into stream ciphers. The message authentication part replaces HMAC-SHA256 with HMAC-SM3, where HMAC (Hash-based Message Authentication Code) represents a hash-based message authentication code. The IKE key exchange part replaces DH with the SM2 elliptic curve key exchange algorithm, such as... Figure 3 As shown.

[0044] Specifically, on a Linux-based gateway platform, the `crypto_register_alg()` or `crypto_register_aead()` interface is used to register SM4-CBC, SM4-CTR, and HMAC-SM3 to the CryptoAPI encryption application programming interface and attach them to the relevant entries in `xfrm_algo.c` for encryption and authentication algorithm management. In the Security Association (SA) structure, the identifier field for the Chinese national cryptographic algorithm type is extended to enable coexistence of Chinese national cryptographic algorithms and traditional algorithms. In the IKEv2 implementation, the SM2 plugin for IKE tools such as StrongSwan is extended to achieve the exchange of Chinese national cryptographic certificates and session key negotiation. Configuration methods include specifying `ike=sm2-sm3-sm4` in the `ipsec.conf` configuration file, configuring the Chinese national cryptographic certificate and private key paths in `ipsec.secrets`, and calling the hardware private key through PKCS#11 or the domestic GMAPI interface.

[0045] In actual replacement, the national cryptographic algorithm differs from the original kernel algorithm in key length, block length, padding method, and context management structure definition. Direct replacement may lead to the following problems:

[0046] 1. Kernel encryption context incompatibility

[0047] The internal state length and initialization / deletion logic of the SM4 algorithm differ from the existing AES implementation in the kernel. Direct registration can lead to kernel crashes, NULL references, or memory overflows due to mismatched algorithm context settings in the `crypto_alg` structure, resulting in issues such as SM4 crashes. To avoid this, this solution redefines the relevant fields of the `crypto_alg` structure during SM4 algorithm registration and adds a unified `sm_ctx_adapter` layer to ensure memory layout compatibility between SM4 and AES during context allocation and deallocation phases.

[0048] 2. Insufficient SA / strategy data structure and algorithm identifiers

[0049] Existing SA / Policy structures are typically designed using traditional algorithm families (such as AES / HMAC-SHA), lacking identification of the Chinese national cryptographic algorithm type and its version, leading to negotiation or route matching errors. To effectively support the coexistence of Chinese national cryptographic algorithms and traditional algorithms, this paper's solution adds a `gm_alg_flag` field to the SA structure. This field indicates whether the current SA uses a Chinese national cryptographic algorithm. Through this field, we achieve dynamic coexistence and switching between traditional and Chinese national cryptographic algorithms.

[0050] 3. IKEv2 negotiation (PRF / KDF / KE) is incompatible.

[0051] SM2 can be used for both signing and key exchange, but its public key representation, KE payload, and derivation process when SM3 is used as a PRF differ from traditional DH+PRF. For example, SM2 uses fixed elliptic curve parameters and specific KDF functions, which are not present in traditional DH protocols. Therefore, direct substitution may lead to IKE negotiation failure or the generation of incorrect session keys. To address this issue, this solution adds a dedicated SM2 Transform type and SM3-HMAC derivation function extension to the StrongSwan IKE implementation. This ensures that IKEv2 can correctly identify the Chinese cryptographic algorithm family and complete PRF derivation during SA negotiation. Simultaneously, an automatic certificate OID identification mechanism is introduced, allowing the system to automatically select the SM2 or RSA path based on the certificate OID field, thus achieving hybrid compatibility.

[0052] 4. Heterogeneous HSM / driver interfaces cause call failures.

[0053] Differences in vendor PKCS#11 and local GMAPI, interface versions, and context management can lead to handle leaks, blocking, or improperly handled exception returns if called directly. This solution employs a unified abstract driver at the application layer, using an asynchronous task queue to automatically retries and rollbacks for failed hardware calls, ensuring the continuity and high availability of key signing operations. Specifically, the asynchronous design enables the system to automatically retries hardware calls that fail and rollback to the software path to ensure uninterrupted key signing operations.

[0054] 5. Insufficient runtime peer-to-peer interoperability and degradation strategies.

[0055] If the peer does not support Chinese cryptographic algorithms or HSM is abnormal, the lack of a smooth fallback mechanism will cause tunnel establishment failure or traffic interruption. This solution uses the gm_alg_flag field to automatically fall back to the traditional AES / SHA algorithm path when Chinese cryptographic algorithms cannot be enabled, ensuring high availability and compatibility of the protocol and avoiding service interruption due to the unavailability of Chinese cryptographic algorithms.

[0056] To address these issues, this solution proposes the following technical improvements:

[0057] 1. Improved algorithm context compatibility

[0058] When registering the SM4 algorithm, the `cra_ctxsize` and `cra_u` fields of the `crypto_alg` structure were redefined to align with the internal state length of the SM4 algorithm. Furthermore, by adding a unified `sm_ctx_adapter` layer, memory layout compatibility between SM4 and AES during context allocation and deallocation phases was achieved, thus avoiding kernel crashes caused by algorithm context mismatch. This improvement ensures that the SM4 algorithm can be smoothly integrated into the kernel cryptographic framework without affecting the stability of existing systems.

[0059] 2. SA structure expansion and algorithm coexistence mechanism

[0060] A new `gm_alg_flag` field has been added to the Security Association (SA) structure to indicate whether the current SA uses the Chinese national cryptographic algorithm. This field enables dynamic coexistence and switching between traditional and Chinese national cryptographic algorithms, avoiding system instability caused by global replacement. When the kernel detects an HSM device failure or the unavailability of the Chinese national cryptographic algorithm, it can automatically fall back to the AES / SHA path, improving system robustness. This effectively enhances the flexibility of the protocol stack, supports the parallel operation of different algorithms, and meets diverse security requirements.

[0061] 3. Enhanced compatibility of IKEv2 national cryptographic negotiation

[0062] Because the SM2 key exchange algorithm differs from the traditional DH algorithm in public key parameters and derivation processes—for example, SM2 uses fixed elliptic curve parameters and specific KDF functions—this scheme adds an SM2-specific Transform type and SM3-HMAC derivation function extension to the StrongSwan IKE implementation. This ensures that IKEv2 correctly identifies the Chinese cryptographic algorithm family and completes PRF derivation during SA negotiation. Simultaneously, an automatic certificate OID identification mechanism is introduced, enabling the system to automatically select the SM2 or RSA path based on the certificate OID field, thus achieving hybrid compatibility. This measure allows the IKEv2 protocol to flexibly handle different encryption algorithms and certificate types, improving protocol interoperability.

[0063] 4. Hardware interface abstraction and fault tolerance mechanism

[0064] To address the call anomalies caused by differences in HSM vendor APIs, such as inconsistencies in function prototypes and handle management methods between PKCS#11 and GMAPI, this solution designs a unified abstract driver at the application layer. This driver uses an asynchronous task queue to automatically retry and rollback hardware call failures, ensuring the continuity and high availability of key signing operations. This improvement effectively resolves system call failures caused by hardware vendor interface differences, guaranteeing the continuity and security of key management operations.

[0065] Through the above improvements, not only have problems such as context incompatibility, negotiation failure, and driver call anomalies occurred when the national cryptographic algorithm directly replaced the kernel algorithm, and the IPSec protocol has achieved support for SM2 / SM3 / SM4 algorithms, but systematic technical optimizations have also been provided in terms of algorithm context compatibility, negotiation compatibility, and hardware fault tolerance. This avoids stability and interoperability issues caused by direct replacement, and achieves seamless coexistence and dynamic switching between the national cryptographic algorithm and traditional algorithms, thereby significantly improving the security and availability of gateway devices under the domestic cryptographic system.

[0066] This invention achieves a domestic upgrade of VPN communication encryption by deeply adapting the protocol stack to the existing IPSec protocol system and non-intrusively integrating the national commercial cryptography (SM) algorithm. Unlike traditional external national cryptography modules, this solution natively replaces the encryption algorithm and process at the underlying protocol layer, ensuring the consistency and compatibility of the system architecture.

[0067] Step 2: Hardware module collaboration.

[0068] To significantly improve encryption and decryption performance, this invention proposes a hardware-software co-operational encryption execution structure. This structure utilizes domestically produced encryption chips (such as Phytium and Zhaoxin chips with built-in security modules) to perform SM4 / SM3 / SM2 algorithm operations. This design decouples the protocol stack from the hardware through an abstract driver layer, allowing the main control system to dynamically determine whether to enable hardware acceleration based on conditions during runtime. Specifically:

[0069] 1. Hardware Algorithm Registration

[0070] The driver layer is developed based on crypto_engine or crypto_async within Linux, and registers the SM2, SM3, and SM4 algorithms supported by domestic encryption chips to the kernel's Crypto API framework for transparent calls by the IPSec protocol stack.

[0071] 2. Encryption at the sending end

[0072] (1) Application layer initiates request: When the application layer initiates a VPN tunnel communication request, the data is encapsulated by the transport layer and enters the protocol stack adaptation layer. The ESP module initiates an encryption request to the kernel Crypto API through the crypto_aead_encrypt() interface.

[0073] (2) Scheduling layer decision: The scheduling layer collects the system operating status and data packet characteristics in real time, such as CPU utilization, load rate of domestic encryption chip, and data block length, and decides whether to adopt the hardware acceleration path; otherwise, it adopts software encryption implemented by kernel software.

[0074] (3) When the scheduling layer decides to use the hardware path: The driver layer transfers the data block to be encrypted and the key context to the encryption chip via DMA. The hardware module performs SM4 encryption and HMAC-SM3 integrity calculation, directly transferring the data from system memory to the internal cache of the domestic encryption chip. No CPU is required to handle the data transfer, reducing bus usage. After receiving the data, the domestic encryption chip performs encryption operations to generate encrypted ciphertext data. After encryption is complete, it notifies the Linux kernel via an interrupt signal. The kernel triggers the interrupt handler function, reads the ciphertext data from the internal cache of the encryption chip, and passes it back to the protocol stack adaptation layer. If hardware unavailability or queue blocking is detected, the system automatically falls back to the software encryption path and calls the kernel's built-in SM4 / SM3 algorithm to complete the encryption.

[0075] (5) When the scheduling layer decides to use the software path: the kernel Crypto API calls the software to implement the national cryptographic algorithm, uses the CPU to perform encryption operations on the plaintext data, generates ciphertext data, and then passes it back to the protocol stack adaptation layer.

[0076] (6) Data encapsulation and transmission: The protocol stack adaptation layer encapsulates the encrypted ciphertext data according to the IPSec ESP protocol format, adding ESP header, verification data, etc., and then transmits it to the receiving end through the IP layer.

[0077] 3. Decryption at the receiving end

[0078] (1) Reception and decapsulation: After the receiving end IP layer receives the ciphertext data encapsulated by ESP, it passes it to the IPSec protocol stack adaptation layer. The protocol stack adaptation layer removes the ESP header, extracts the ciphertext and authentication data, and passes it to the ESP module.

[0079] (2) Initiating a decryption request: The protocol stack adaptation layer initiates a decryption request to the kernel Crypto API through the crypto_aead_decrypt() interface.

[0080] (3) Scheduling layer decision path: Similar to the scheduling logic of the sending end encryption, the hardware or software path is selected according to the system status and data characteristics. If it is the hardware path, the ciphertext is transmitted to the encryption chip via DMA to perform SM4 decryption and HMAC-SM3 verification. After the chip completes the decryption operation, it notifies the kernel with an interrupt signal. The driver layer fills the result back into the buffer and restores the network data flow. If the chip is abnormal or the response times out, it falls back to the software implementation to ensure that the communication is not interrupted. If it is the software path, the kernel Crypto API calls the software-implemented decryption function, uses the CPU to complete the decryption, and sends the plaintext data back to the protocol stack.

[0081] (4) Data is passed to the upper layer: The protocol stack adaptation layer passes the decrypted plaintext data to the transport layer, and then the transport layer passes it to the application layer for user use.

[0082] Under the aforementioned hardware-software collaborative mechanism, the IPSec protocol stack can dynamically select encryption and decryption paths based on runtime state, achieving adaptive execution of domestically developed cryptographic algorithms between software and hardware. However, in actual engineering implementation, the hardware-software collaborative execution structure involves multiple stages such as data transmission, driver scheduling, and security state synchronization. Improper handling may affect the integrity of encrypted data and the real-time performance of the system. Therefore, this invention identified the following key technical problems during implementation and proposed targeted improvement measures:

[0083] 1. DMA transfer carries data integrity risks.

[0084] When hardware acceleration is enabled, the driver layer uses DMA (Direct Memory Access) to directly transfer the data block to be encrypted from system memory to the buffer of the domestic encryption chip. If page replacement or bus contention occurs during the DMA transfer, data segments may be lost, rearranged, or overwritten, resulting in incomplete data received by the encryption chip, leading to incorrect encryption results or authentication failure.

[0085] To ensure the integrity and consistency of data transmission, the driver layer can call the `dma_map_single()` function before initiating a DMA transfer to perform a fixed mapping of the memory region to be transferred. This locks the memory page in physical memory during the transfer, preventing it from being swapped out or modified by the kernel's memory management mechanism, thus ensuring the physical continuity of DMA access. After the transfer is complete, the mapping is released using `dma_unmap_single()`, releasing the locked memory resources. Furthermore, data verification mechanisms are introduced before and after the DMA transfer. Before transfer, a checksum of the source data is calculated and transmitted along with the data. After transfer, the checksum is recalculated by the encryption chip or the driver layer. If the checksum is inconsistent, a retransmission mechanism is triggered. This effectively prevents data errors caused by hardware contention or memory remapping during DMA transfers, significantly improving the reliability of data transmission.

[0086] 2. Hardware interrupt and kernel scheduling conflict

[0087] After the encryption chip completes the encryption or decryption task, it notifies the driver layer to retrieve the result via an interrupt. However, when the system is under high load (such as when the kernel is performing scheduling or network interrupt handling), the interrupt response may be delayed, causing the encrypted result to fail to be returned in a timely manner, affecting the real-time performance of the VPN data stream, and even triggering tunnel establishment timeout.

[0088] By combining interrupt prioritization with threading techniques, timely handling of hardware interrupt events can be ensured. Specifically, during the interrupt registration phase, the `IRQF_HIGHPRI` flag of the `request_irq()` function is used to set the encryption chip interrupt to high priority, guaranteeing its priority response in kernel scheduling contention. Then, time-consuming tasks are executed within the threaded interrupt `request_threaded_irq()`, with the interrupt flag quickly cleared only in the top half, thereby shortening the critical path execution time and reducing the impact on other kernel interrupts.

[0089] 3. State synchronization during software and hardware path switching

[0090] During system operation, when hardware resources are unavailable, DMA tasks time out, or chip load is too high, the scheduling layer will automatically switch the encryption path of the IPSec protocol stack from hardware mode to software mode. However, if the Security Association (SA) structure fails to correctly synchronize state information such as keys, IVs, and sequence numbers during the switching process, it may lead to subsequent encryption / decryption failures, packet authentication errors, or replay detection failures.

[0091] To address the inconsistency in state during hardware / software switching, this invention extends the `path_status` field in the SA structure to record operational information such as the current encryption / decryption path state (hardware / software), switching time, and switching reason. When executing a path switch, the scheduling layer first calls `xfrm_state_lock()` to lock the SA state, preventing modification by other kernel threads or concurrent processes during the switch. Subsequently, based on the new path type (hardware or software), it synchronously updates key fields such as `path_status`, session key, IV, and sequence number to ensure consistency in the security context of the two paths. After the switch is complete, `xfrm_state_unlock()` is called to release the lock resources, ensuring atomicity and consistency in the SA state switching process between hardware and software paths.

[0092] The above improvements can solve the problems of DMA transmission integrity risk, interruption delay conflict and inconsistent software and hardware path state synchronization in the hardware acceleration of national cryptographic algorithms. They can achieve high reliability and integrity of encrypted data transmission, improve the real-time response capability of the system under high load, and ensure smooth switching and state consistency maintenance of software and hardware encryption paths.

[0093] Step 3: Constructing the scheduling control logic.

[0094] This invention introduces an encryption path scheduling module, which dynamically determines whether to use hardware acceleration for each encryption task at runtime, such as... Figure 4As shown, the scheduling module runs as a policy engine between the protocol stack and the hardware driver, monitoring data packet characteristics (such as length, source / destination port), system operating status (such as CPU utilization, chip load), and other indicators in real time, and determining whether the encryption task should take the software path or the hardware path according to preset rules.

[0095] Specifically, when the data packet length is greater than or equal to 1500 bytes (close to the MTU standard value, which is a large data packet scenario), the hardware path is preferred to improve encryption efficiency by utilizing the parallel processing capabilities of domestic encryption chips; when the data packet length is less than 256 bytes, the software path is selected to avoid the additional overhead caused by hardware calls.

[0096] From a system load perspective, if the CPU utilization exceeds 70%, newly initiated encryption tasks are forcibly switched to the hardware path to alleviate CPU computational pressure. If the load rate of the domestic encryption chip exceeds 90%, some encryption tasks are offloaded to the software path to prevent hardware overload. In addition, for designated ports of critical business such as government affairs and finance (such as the commonly used financial transaction port 4433), the hardware path is forcibly adopted to ensure the encryption performance and stability of critical business.

[0097] The scheduling strategy can be adjusted via configuration file and also supports dynamic updates. All encrypted task path selection records and abnormal path switching events are written to a log file for use in security monitoring and performance auditing.

[0098] This invention designs a switchable hardware and software encryption / decryption framework that automatically determines whether to enable a domestically produced encryption chip to perform encryption tasks based on the operating environment, exhibiting high flexibility and robustness. Based on this, a dynamically scheduled policy control module is proposed, which selects encryption paths according to data packet characteristics, system load, and other strategies, balancing performance and resource utilization.

[0099] Step 4: Integration of the key management system.

[0100] To further enhance security and key management efficiency, the system incorporates a key management module with a complete key lifecycle control mechanism. Taking the SM2 key management of a single IPSec communication as an example, the process is as follows: First, during the IKE negotiation phase, after both communicating parties complete authentication, the system generates a session key pair based on the SM2 algorithm. Then, lifecycle parameters are bound to this key pair, such as setting the validity period to 24 hours and the maximum number of encryption uses to 10,000. During key usage, the system monitors its usage status in real time. When it detects that the remaining validity period of the key is less than 2 hours, or the number of uses has reached 9,000, a key rotation warning is triggered. After the warning is triggered, the system automatically initiates the IKE rekey process, negotiating with the other end to generate a new SM2 key pair. After the new key takes effect, the old key enters a "pending revocation" state. Once all encrypted data based on the old key has been decrypted, the old key is automatically revoked.

[0101] Regarding private key protection, it supports integration with the nationally certified HSM hardware security module for storing encryption keys and performing encryption operations. It possesses high-level security against tampering and leakage, and is commonly used in compliant scenarios where keys cannot be exported. The SM2 private key is written to the HSM secure area via the PKCS#11 interface and cannot be exported; all signing operations are performed within the HSM. IKE tools such as StrongSwan use the libstrongswan-pkcs11 module to access the private key in the HSM, ensuring the security and trustworthiness of the authentication process.

[0102] All key status changes (generation, activation, rotation, revocation) are written to the key management module, supporting external monitoring and querying of key lifecycle behavior, and providing technical support for Cybersecurity Classified Protection 2.0 and cryptographic compliance management.

[0103] In terms of key management, this invention supports an automatic lifecycle management mechanism for SM2 keys and combines it with an HSM hardware security module to implement private key signing, thereby further improving the security and compliance of the overall communication system.

[0104] The invention adopts a modular design, with each functional unit independently decoupled, which facilitates the future integration with more types of hardware encryption devices or the functional customization and expansion on different platforms.

[0105] This invention boasts excellent technical scalability and deployment adaptability. Building upon the IPSec protocol, it can be further extended to national standard cryptographic adaptations of application-layer encryption protocols such as TLS, QUIC, and DTLS, enabling broader upgrades to network security standards. Furthermore, the architecture of this solution is also suitable for deployment scenarios of domestically developed critical infrastructure such as industrial edge computing gateways, domestically produced border protection devices, and secure egress gateways.

[0106] This invention possesses strong commercial potential and strategic value. As a complete VPN solution adapted to national cryptographic standards, it can be widely applied to network communication security protection scenarios in sectors such as government, finance, power, transportation, and industrial internet, and is particularly suitable for communication systems requiring Level 3 or higher of the graded protection system.

[0107] Meanwhile, this solution is flexible in structure, stable in performance, and has significant compatibility with domestic products. It can serve as a core encrypted communication component for domestic platforms under the "Information Technology Innovation" system, supporting the R&D of self-developed gateway devices, security chip modules, border firewalls, and other products.

[0108] The promotion and implementation of this invention can further advance the comprehensive application of national commercial cryptography in key areas, enhance my country's independent controllability in cyberspace security, and has significant engineering and policy value.

[0109] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for cryptographic algorithm adaptation and hardware encryption / decryption acceleration suitable for gateway protocols, based on the IP-layer encrypted communication protocol IPSec, constructs an IPSec protocol stack adaptation layer between the transport layer and the IP layer to establish an IPSec tunnel, through which IP data packets are transmitted encrypted, characterized in that: The IPSec protocol stack adaptation layer comprises software and hardware components. The software component includes a scheduling layer, the IPsec protocol stack, and a key management module. The IPsec protocol stack includes an Internet Key Exchange (IKE) module and an Encapsulated Security Payload (ESP) module. The method includes the following steps: Step 1: Modify the IPsec protocol stack on the software side; the key exchange of the IKE module adopts the national cryptographic SM2 algorithm, the encryption and decryption of the ESP module adopts the national cryptographic SM4 algorithm, and the message authentication adopts the national cryptographic SM3 algorithm. Step 2: Hardware-side collaboration; Decouple the IPSec protocol stack from the hardware to dynamically determine whether to enable hardware acceleration based on conditions; Step 3: Constructing the scheduling control logic; By referencing the encryption / decryption path scheduling through the scheduling layer, the encryption / decryption task is dynamically decided at runtime to execute either software-side encryption / decryption or hardware-side encryption / decryption; Step 4: Key management system integration; build a complete key lifecycle control mechanism through the key management module.

2. The method for cryptographic algorithm adaptation and hardware encryption / decryption acceleration suitable for gateway protocols according to claim 1, characterized in that: In the IPSec protocol stack of step one, the national cryptographic SM4 algorithm includes the national cryptographic ciphertext block linking algorithm SM4-CBC or the national cryptographic counter algorithm SM4-CTR, which converts block ciphers into stream ciphers; the national cryptographic SM3 algorithm includes the national cryptographic hash-based message authentication code algorithm HMAC-SM3. Based on the gateway platform, SM4-CBC, SM4-CTR, and HMAC-SM3 are registered to the encryption application interface through the interface and attached to the relevant entries in the encryption and authentication algorithm management table; in the security association SA structure, the identification field for the national cryptographic algorithm type is extended; the SM2 plugin of the IKE tool is extended to perform national cryptographic certificate exchange and session key negotiation based on the national cryptographic SM2 algorithm; In the IPsec configuration file, specify that key exchange should be performed using the Chinese national cryptographic algorithm, configure the Chinese national cryptographic certificate and private key path, and call the hardware private key through the interface.

3. The method for cryptographic algorithm adaptation and hardware encryption / decryption acceleration suitable for gateway protocols according to claim 2, characterized in that: In step one, when registering the national cryptographic SM4 algorithm, the relevant fields of the structure are redefined to align with the internal state length of the national cryptographic SM4 algorithm. By adding a unified adaptation layer, the national cryptographic SM4 algorithm adapts to the memory layout of the context allocation and release phases. A new identifier field has been added to the SA structure to indicate whether the current SA has enabled the national cryptographic algorithm. On the other hand, the identifier field enables automatic fallback of the algorithm path when the national cryptographic algorithm cannot be enabled, and the fallback is to the traditional algorithm path. The system adds a dedicated SM2 Transform type and SM3-HMAC derivation function extension for Chinese cryptographic algorithms, which can correctly identify the Chinese cryptographic algorithm family and complete key derivation during SA negotiation. At the same time, it introduces an automatic certificate identification mechanism to select the Chinese cryptographic SM2 algorithm path based on the certificate fields.

4. The method for cryptographic algorithm adaptation and hardware encryption / decryption acceleration suitable for gateway protocols according to claim 1, characterized in that: The software side also includes an abstract driver layer, and the hardware side includes a domestically produced encryption chip; in step two, the encryption process at the sending end involves registering the national cryptographic algorithm supported by the domestically produced encryption chip to the kernel framework for use by the IPSec protocol stack. The application layer initiates an encryption request. After the data is encapsulated by the transport layer, it enters the IPSec protocol stack adaptation layer. The ESP module initiates an encryption request to the kernel's application programming interface (API) through an interface. The scheduling layer collects the running status and data packet characteristics in real time to decide whether to use the hardware acceleration path. If so, the scheduling layer decides to use the hardware encryption path. The abstract driver layer transmits the data block to be encrypted and the key context to the domestic encryption chip through direct memory access. It performs encryption using the national cryptographic SM4 algorithm and integrity calculation using the national cryptographic SM3 algorithm. After the domestic encryption chip completes the encryption, it notifies the kernel through an interrupt signal. The kernel reads the ciphertext data from the domestic encryption chip's internal cache and passes it back to the IPSec protocol stack. If not, the scheduling layer decides to use the software encryption path. The kernel's API calls the software to implement the national cryptographic algorithm, encrypts the plaintext data, generates ciphertext data, and passes it back to the IPSec protocol stack. The encrypted data is encapsulated by the ESP module and then transmitted to the receiving end via the IP layer.

5. The method for cryptographic algorithm adaptation and hardware encryption / decryption acceleration suitable for gateway protocols according to claim 4, characterized in that: If the hardware is unavailable or the queue is blocked, an asynchronous task queue is used to automatically retry or fall back to the software encryption path when the hardware call fails, so that the key signing operation is not interrupted by designing a unified abstract driver at the application layer.

6. The method for cryptographic algorithm adaptation and hardware encryption / decryption acceleration suitable for gateway protocols according to claim 1, characterized in that: The software side also includes an abstract driver layer, and the hardware side includes a domestically produced encryption chip. In step two, the receiving end decryption process involves transmitting the ciphertext data received at the IP layer to the IPSec protocol stack adaptation layer to extract the ciphertext and authentication data. The ESP module initiates a decryption request to the kernel's application programming interface (API) through an interface. The scheduling layer collects the running status and data packet characteristics in real time to decide whether to use the hardware acceleration path. If so, the scheduling layer decides to use the hardware decryption path. The abstract driver layer transmits the ciphertext to the domestic encryption chip through direct memory access, performs decryption using the national cryptographic SM4 algorithm, and verifies it using the national cryptographic SM3 algorithm. After the domestic encryption chip completes decryption, it notifies the kernel through an interrupt signal. The kernel reads the plaintext data from the domestic encryption chip's internal cache and transmits it back to the IPSec protocol stack. If not, the scheduling layer decides to use the software decryption path. The kernel's API calls the software to implement the national cryptographic algorithm, decrypts the ciphertext data, generates plaintext data, and transmits it back to the IPSec protocol stack. The plaintext data is then passed up to the transport layer.

7. The method for cryptographic algorithm adaptation and hardware encryption / decryption acceleration suitable for gateway protocols according to claim 6, characterized in that: If a hardware malfunction occurs or a response times out, an asynchronous task queue is used to automatically retry or fall back to the software decryption path in case of hardware call failure by designing a unified abstract driver at the application layer.

8. The method for cryptographic algorithm adaptation and hardware encryption / decryption acceleration suitable for gateway protocols according to claim 4 or 6, characterized in that: When hardware acceleration is enabled, the abstract driver layer performs a fixed mapping on the memory region to be transmitted before initiating direct memory access transmission, so that the corresponding memory page is locked in physical memory during transmission. After the transmission is completed, the mapping is released and the locked memory resources are released. In addition, data verification mechanisms are introduced before and after direct memory access transmission. Before transmission, the verification value of the source data is calculated and transmitted with the data. After transmission, the verification value is recalculated by the domestic encryption chip or the abstract driver layer. If the verification is inconsistent, a retransmission is triggered. During the interrupt registration phase, the interrupt of the domestically produced encryption chip is set to high priority so that the domestically produced encryption chip can respond first in the kernel scheduling competition. Then, the time-consuming tasks are put into threaded interrupts for execution, and the interrupt flag is cleared only in the top half to shorten the execution time of the critical path. The SA structure includes extended fields to record the current encryption or decryption path status. When the scheduling layer performs a path switch, it first locks the SA state to prevent it from being modified by other kernel threads or concurrent processes during the switch. Then, based on the new path type, it synchronously updates the extended fields and key fields to keep the security context of the two paths (hardware or software) consistent. After the switch is completed, the lock resources are released.

9. The method for cryptographic algorithm adaptation and hardware encryption / decryption acceleration suitable for gateway protocols according to claim 1, characterized in that: In step four, during the negotiation phase of the IKE module, after both communicating parties complete identity authentication, a session key pair is generated based on the national cryptographic SM2 algorithm, and a lifecycle parameter is bound to the key pair. During the key usage process, the usage status of the lifecycle parameter is monitored in real time. When the key lifecycle parameter is detected to have reached the threshold, key rotation is triggered, and a new SM2 key pair is negotiated with the other party. After all encrypted data based on the old key is decrypted, the old key is automatically revoked. All key status changes are written to the key management module.

10. The method for cryptographic algorithm adaptation and hardware encryption / decryption acceleration suitable for gateway protocols according to claim 9, characterized in that: The IPSec protocol stack adaptation layer also includes a hardware security module (HSM) for storing encryption keys and performing encryption operations. The private key of the domestic SM2 algorithm is written to the HSM security area through the interface and cannot be exported. All signature operations are completed in the HSM, and the private key in the HSM is called through the IKE tool.

Images