Hardware implementation method and device of ipsec protocol processor based on ascon lightweight encryption algorithm

Abstract

The application belongs to the technical field of network communication. The application provides a hardware implementation method and device of an IPSec protocol processor based on an ASCON lightweight encryption algorithm. According to the method, the ASCON lightweight encryption algorithm and an optimized security policy matching algorithm are introduced, resource consumption is reduced and delay is lowered while high throughput is ensured, the hardware implementation of the ASCON algorithm is optimized for the application scenario of the IPSec protocol processing, the overall process of the ASCON algorithm is split into two stages of pre-computation and packet encryption, the initialization and associated data encryption intermediate state of each security alliance are pre-computed and stored, repeated computation is avoided, and the throughput is improved by single-cycle parallel execution of multiple rounds of transformation in the hardware implementation of the packet encryption module.

Description

Technical Field

[0001] This disclosure relates to the field of network communication technology, and in particular to a hardware implementation method and apparatus for an IPSec protocol processor based on the ASCON lightweight encryption algorithm. Background Technology

[0002] The Internet of Things (IoT) plays an increasingly important role in our daily lives. IoT technology has been widely applied in fields such as augmented reality, high-resolution video streaming, autonomous vehicles, smart environments, and e-healthcare. The IoT is a vast system comprised of sensors, electromechanical devices, software processing, and various intelligent devices and services. With numerous devices and services connected via the internet, the potential for cyberattacks and data breaches is also increasing, making security a critical issue for organizations that rely on IoT devices and services. In the context of IoT, optimizing for geographically confined environments is crucial. In certain scenarios, achieving high performance with lightweight encryption is prioritized to ensure the security of real-time communication, video processing, or large-scale data transmission. Furthermore, with the widespread deployment of 5G networks, the demand for high-speed, low-latency, and lightweight secure IoT networks is becoming even more significant.

[0003] IoT networks can utilize various network security protocols, among which IPSec can encrypt and authenticate network layer traffic and protect all data packets sent along the path. The implementation of the IPSec network protocol is complex, with intricate encryption and authentication algorithms. A purely software-based implementation of IPSec cannot meet the demands of high-speed IoT. However, offloading the complex algorithm implementation and IPSec processing operations to hardware significantly improves network security efficiency. In the context of IoT, optimizing for geographically limited environments is crucial. In certain scenarios, high performance with lightweight encryption is prioritized to ensure the security of real-time communication, video processing, or large-scale data transmission. Furthermore, with the widespread adoption of 5G networks, the demand for high-speed, low-latency, and lightweight secure IoT networks is becoming increasingly significant.

[0004] Existing IPSec protocol software implementations, such as Kame, Freeswan, and Strongswan, primarily rely on general-purpose processor platforms, utilizing CPU instruction sets for protocol parsing and data processing. While performance can be improved through software optimization, the CPU's dependence on protocol parsing and critical forwarding decisions can still lead to excessive CPU load in high-throughput scenarios, limiting overall performance, especially when a large amount of cryptographic computation is required. Furthermore, even software-level optimization techniques such as dynamic loading or lightweight algorithm extensions struggle to overcome the performance bottleneck of general-purpose CPUs.

[0005] Limitations of hardware and software acceleration technologies such as DPDK: To improve IPSec performance, the industry has introduced hardware and software acceleration technologies such as DPDK. However, for cryptographically computation-intensive applications such as IPSec VPNs, the CPU remains a performance bottleneck. Even with technologies like DPDK accelerating packet processing, the computational efficiency of each processor core remains limited, and relying on the DPDK framework may introduce additional latency. Furthermore, these technologies are not specifically optimized for cryptographic operations, so the efficiency improvement is relatively limited when handling a large number of encryption and decryption tasks. Although the overall throughput can still meet the requirements after offloading the encryption and decryption tasks to dedicated hardware, it requires multi-core CPUs to handle data offloading from the hardware accelerator, relies on the DPDK framework for packet forwarding, and the frequent switching of data between different modules leads to additional processing latency. Moreover, in resource-constrained IoT devices, multi-core CPU solutions are poorly suited due to high power consumption and computational burden, making it difficult to meet the needs of lightweight IPSec implementations.

[0006] Current IPSec hardware acceleration solutions lack support for lightweight encryption algorithms: Existing IPSec hardware protocol processors are mostly based on traditional encryption algorithms such as AES. While these offer high security, their hardware implementation is complex, computationally intensive, and requires additional hash functions like HMAC-SHA for authentication. This makes them unsuitable for low-power devices. Furthermore, current technologies lack hardware optimization for lightweight encryption algorithms. Even software-level implementations of lightweight encryption algorithms fail to fully leverage the advantages of hardware acceleration and parallel processing. This makes it difficult for these solutions to balance security and efficiency in low-power and resource-constrained IoT scenarios.

[0007] Regarding security policy matching algorithms: Current IPSec policy matching algorithms mainly include two methods: hash table-based lookup and TCAM-based parallel lookup. While hash table-based policy matching is simple to implement and suitable for small-scale data matching, it is prone to hash collisions, requiring additional collision handling mechanisms, thus reducing matching efficiency. On the other hand, TCAM-based parallel lookup, although offering high throughput, has a large area and high power consumption, posing significant challenges for on-chip implementation. It typically requires an external TCAM, which undoubtedly increases hardware costs.

[0008] Therefore, it is necessary to improve one or more of the problems existing in the above-mentioned related technical solutions.

[0009] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0010] The purpose of this disclosure is to provide a hardware implementation method and apparatus for an IPSec protocol processor based on the ASCON lightweight encryption algorithm, thereby overcoming at least to some extent one or more problems caused by the limitations and defects of related technologies.

[0011] According to a first aspect of the present disclosure, a hardware implementation apparatus for an IPSec protocol processor based on the ASCON lightweight encryption algorithm is provided, the apparatus comprising:

[0012] The pre-computation module is used to perform the ASCON algorithm initialization and associated data encryption phases on the key, random number, and associated data of each security association, and to generate and store intermediate states; wherein, the intermediate states are bound to the corresponding security association and stored in the pre-computation result RAM;

[0013] The security policy matching module uses a parallel sub-field matching algorithm with a two-dimensional pipeline structure to decompose the matching field into five sub-rule entries: source IP address, destination IP address, source port, destination port, and protocol number, and matches them in parallel. It also reduces invalid matching operations through an early termination policy for IPv4 data frames.

[0014] The message scheduling module is used to dynamically allocate data frames to be processed to the ESP message processing module group based on the polling arbitrator, and assign a unique ID to each data frame to mark the original order;

[0015] The ESP message processing module group includes several ESP message processing modules. Each ESP message processing module includes an ASCON message encryption unit and an ESP encapsulation unit. The ASCON message encryption unit is used to perform plaintext encryption and tag generation on data frames based on pre-calculation results. It adopts a single-cycle parallel multi-round transformation strategy, and processes m rounds of transformation in parallel within a single cycle by multiplexing round function units. The number of rounds b of the permutation operation is completed in b / m cycles. The ESP encapsulation unit is used to generate the ESP header and update the IP header fields, supporting tunnel mode and transmission mode.

[0016] The reordering module is used to store the ID, length information and corresponding ESP message processing module number of the data frame in dual-port RAM, and read and output the data frame in ascending order of ID to ensure the order of the data stream.

[0017] The control logic module is used to coordinate the state transitions and data flow control between modules, including pre-calculation triggering, distribution of security policy matching results, and scheduling of encryption processes.

[0018] Furthermore, the pre-computation process of the pre-computation module includes:

[0019] Generate initial state based on security association parameters. Initialization is completed through a round of transformation;

[0020] Perform b rounds of transformation on the associated data and generate intermediate states. The results are stored in the pre-calculated result RAM; the pre-calculation module is triggered when configuring a new security association, and all ESP message processing modules share the same pre-calculation result.

[0021] Furthermore, the two-dimensional pipeline structure of the security policy matching module includes:

[0022] The horizontal direction is divided into multiple processing units, and each processing unit matches a subfield with a fixed bit width;

[0023] The subfield information is passed vertically through the pipeline, and the priority encoder outputs the final matching result according to priority.

[0024] For IPv4 data frames, terminate subsequent matching operations early after matching the 32-bit address.

[0025] Furthermore, the single-cycle parallel multi-round transformation strategy of the ASCON message encryption unit includes:

[0026] Reuse m round function units and execute m round transformations in parallel within a single cycle;

[0027] The pre-computation stage adopts a single-cycle, single-round transformation strategy, while the message encryption stage adopts a single-cycle, m-round transformation strategy; where m ≥ 2.

[0028] Furthermore, the reordering module achieves order-preserving output through the following steps:

[0029] The message scheduling module assigns an incrementing ID to each data frame;

[0030] After each ESP message processing module completes its processing, it writes the data frame ID, length information, and module sequence number into the dual-port RAM.

[0031] The reordering module reads valid data from RAM in ascending order of ID and extracts data frames from the FIFO of the corresponding module.

[0032] Furthermore, the ASCON message encryption unit also includes:

[0033] After encrypting all message blocks, the final state is... Perform a specified number of permutations, XOR the permutation with the key to generate an authentication tag, which is used for data integrity verification.

[0034] According to a second aspect of the present disclosure, a hardware implementation method for an IPSec protocol processor based on the ASCON lightweight encryption algorithm is provided, comprising:

[0035] For each security association, the ASCON algorithm is executed to initialize the key, random number, and associated data, and the associated data encryption phase is performed to generate and store intermediate states. The intermediate states are bound to the corresponding security association and stored in the pre-calculated results RAM.

[0036] A parallel subfield matching algorithm with a two-dimensional pipeline structure is adopted, which decomposes the matching field into five sub-rule entries: source IP address, destination IP address, source port, destination port and protocol number, and performs parallel matching. Invalid matching operations are reduced by using an early termination strategy for IPv4 data frames.

[0037] The polling arbitrator dynamically allocates data frames to be processed to the ESP message processing module group and assigns a unique ID to each data frame to mark the original order.

[0038] Based on the pre-calculation results, plaintext encryption and tag generation are performed on the data frame. A single-cycle parallel multi-round transformation strategy is adopted, and m rounds of transformation are processed in parallel within a single cycle by reusing round function units. The number of rounds b of the permutation operation is completed in b / m cycles. Furthermore, an ESP header is generated and the IP header fields are updated, supporting both tunnel mode and transmission mode.

[0039] The dual-port RAM is used to store the ID, length information and corresponding ESP message processing module number of the data frame. The data frames are read and output in ascending order of ID to ensure the order of the data stream.

[0040] Coordinate state transitions and data flow control between modules, including pre-calculation triggering, distribution of security policy matching results, and scheduling of encryption processes.

[0041] The technical solutions provided by the embodiments of this disclosure may include the following beneficial effects:

[0042] In the embodiments of this disclosure, the hardware implementation method and apparatus for an IPSec protocol processor based on the ASCON lightweight encryption algorithm, by introducing the ASCON lightweight encryption algorithm and an optimized security policy matching algorithm, reduces resource consumption and latency while ensuring high throughput. For the application scenarios of IPSec protocol processing, the hardware implementation of the ASCON algorithm is optimized, and the overall ASCON algorithm process is divided into two stages: pre-computation and packet encryption. By pre-computing and storing the initialization and associated data encryption intermediate states of each security association, redundant calculations are avoided. Furthermore, in the hardware implementation of the packet encryption module, throughput is improved by executing multiple rounds of transformations in parallel within a single cycle. In addition, a fast security policy matching method using parallel subfields in a two-dimensional pipeline structure is combined to improve matching efficiency. And based on a dual-port RAM-based packet scheduling and reordering module, parallel processing of multiple ESP packet processing modules is achieved, thereby improving the throughput of the IPSec protocol processor.

[0043] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0044] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0045] Figure 1 This diagram illustrates the overall framework of a hardware implementation apparatus for an IPSec protocol processor based on the ASCON lightweight encryption algorithm in an exemplary embodiment of this disclosure.

[0046] Figure 2 This diagram illustrates the data frame processing flowchart before the ASCON algorithm process splitting in an exemplary embodiment of this disclosure.

[0047] Figure 3 This diagram illustrates the pre-computation stage after the ASCON algorithm flow is broken down in an exemplary embodiment of this disclosure.

[0048] Figure 4 This diagram illustrates the data frame encryption process after the ASCON algorithm process is split in an exemplary embodiment of this disclosure.

[0049] Figure 5 This diagram illustrates the hardware implementation principle of multiple ESP message processing modules sharing a pre-computed state in an exemplary embodiment of this disclosure.

[0050] Figure 6 This diagram illustrates the security policy matching results in an exemplary embodiment of this disclosure.

[0051] Figure 7 This diagram illustrates a single-round transformation flowchart of ASCON in an exemplary embodiment of this disclosure.

[0052] Figure 8 This diagram illustrates the implementation principle of ASCON parallel round transformation in an exemplary embodiment of this disclosure.

[0053] Figure 9 This diagram illustrates the hardware implementation principle of ASCON parallel round transformation in an exemplary embodiment of this disclosure.

[0054] Figure 10 This diagram illustrates the implementation principle of the security policy matching module in an exemplary embodiment of this disclosure.

[0055] Figure 11This diagram illustrates the structure of the processing unit in an exemplary embodiment of the present disclosure.

[0056] Figure 12 This diagram illustrates the effect of parallel matching in security policy lookup during an exemplary embodiment of this disclosure.

[0057] Figure 13 This diagram illustrates the reordering module in an exemplary embodiment of this disclosure.

[0058] Figure 14 This diagram illustrates the ESP message processing module group in an exemplary embodiment of this disclosure.

[0059] Figure 15 This diagram illustrates the overall block diagram of data frame preprocessing in an exemplary embodiment of this disclosure;

[0060] Figure 16 This diagram illustrates the IPSec protocol processor processing steps in an exemplary embodiment of this disclosure.

[0061] Figure 17 A graph showing the relationship between actual encryption throughput and data frame length in an exemplary embodiment of this disclosure is provided. Detailed Implementation

[0062] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that this disclosure will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0063] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0064] This example implementation first provides a hardware implementation device for an IPSec protocol processor based on the ASCON lightweight encryption algorithm. This device can be applied to a terminal device, such as a mobile terminal like a mobile phone, personal digital assistant, laptop, tablet, or smartwatch [adjusted flexibly according to specific circumstances, such as a server]. Reference Figure 1 As shown, the device may include:

[0065] The pre-computation module is used to perform the ASCON algorithm initialization and associated data encryption phases on the key, random number, and associated data of each security association, and to generate and store intermediate states; wherein, the intermediate states are bound to the corresponding security association and stored in the pre-computation result RAM;

[0066] The security policy matching module uses a parallel sub-field matching algorithm with a two-dimensional pipeline structure to decompose the matching field into five sub-rule entries: source IP address, destination IP address, source port, destination port, and protocol number, and matches them in parallel. It also reduces invalid matching operations through an early termination policy for IPv4 data frames.

[0067] The message scheduling module is used to dynamically allocate data frames to be processed to the ESP message processing module group based on the polling arbitrator, and assign a unique ID to each data frame to mark the original order;

[0068] The ESP message processing module group includes several ESP message processing modules. Each ESP message processing module includes an ASCON message encryption unit and an ESP encapsulation unit. The ASCON message encryption unit is used to perform plaintext encryption and tag generation on data frames based on pre-calculation results. It adopts a single-cycle parallel multi-round transformation strategy, and processes m rounds of transformation in parallel within a single cycle by multiplexing round function units. The number of rounds b of the permutation operation is completed in b / m cycles. The ESP encapsulation unit is used to generate the ESP header and update the IP header fields, supporting tunnel mode and transmission mode.

[0069] The reordering module is used to store the ID, length information and corresponding ESP message processing module number of the data frame in dual-port RAM, and read and output the data frame in ascending order of ID to ensure the order of the data stream.

[0070] The control logic module is used to coordinate the state transitions and data flow control between modules, including pre-calculation triggering, distribution of security policy matching results, and scheduling of encryption processes.

[0071] The aforementioned hardware implementation of an IPSec protocol processor based on the ASCON lightweight encryption algorithm, by introducing the ASCON lightweight encryption algorithm and an optimized security policy matching algorithm, reduces resource consumption and latency while ensuring high throughput. Targeting specific application scenarios for IPSec protocol processing, the hardware implementation of the ASCON algorithm is optimized by splitting the overall ASCON algorithm process into two stages: pre-computation and packet encryption. Pre-computing and storing the initialization and associated data encryption intermediate states of each security association avoids redundant calculations. Furthermore, the throughput is improved by executing multiple rounds of transformations in parallel within a single cycle in the hardware implementation of the packet encryption module. In addition, a fast security policy matching method using parallel subfields in a two-dimensional pipeline structure is combined to improve matching efficiency. A packet scheduling and reordering module based on dual-port RAM enables parallel processing of multiple ESP packet processing modules, thereby increasing the throughput of the IPSec protocol processor.

[0072] Below, we will refer to Figures 1 to 17 The various parts of the apparatus described in this example embodiment will be described in more detail.

[0073] In one embodiment, this application selects the lightweight encryption algorithm ASCON for hardware implementation and optimization when implementing the IPSec protocol processor. This completes the data authentication and encryption functions, minimizing resource consumption and achieving low-latency IPSec protocol processing while ensuring high throughput. This meets the low-latency and lightweight requirements of specific scenarios in the Internet of Things (IoT). The overall framework is as follows: Figure 1 As shown, in order to improve the throughput of the IPSec protocol processor, multiple protocol processing modules are used to process data frames in parallel. At the same time, a protocol processing scheduling module and a reordering module are designed to complete the scheduling and reordering of data frames.

[0074] 1. Hardware Implementation and Optimization of the ASCON Algorithm

[0075] The ASCON algorithm, as an emerging encryption algorithm, is particularly suitable for encryption operations in embedded hardware and network security processors due to its lightweight, high efficiency, and low power consumption. In the application of the IPSec protocol, optimizing encryption efficiency and reducing computational overhead are key to improving overall performance. The core idea of ​​this application is to improve encryption efficiency by splitting the entire ASCON algorithm process into a pre-computation stage and a message encryption stage. In the encryption stage, a parallel processing strategy for multiple rounds of transformations is adopted in the hardware implementation. The hardware multiplexes the round transformation circuit, allowing multiple rounds of transformations to be processed in parallel within a single cycle, thereby increasing throughput. Simultaneously, a single-cycle round transformation strategy is used in the pre-computation stage to balance throughput and resource consumption.

[0076] ASCON-128a employs a sponge structure. Its encryption process includes initialization, associated data encryption, plaintext encryption, and a generation phase. Throughout the encryption / decryption process, only state S continuously iterates. State S is a fixed 320 bits of data; the associated data and plaintext / ciphertext are simply data processed during the iteration of state S. Finally, a flag T is generated. The encryptor gives flag T to the decryptor, who uses flag T to verify successful decryption.

[0077] In the IPSec protocol processor, the ASCON algorithm flow is divided into a pre-computation stage and a message encryption stage. The principle behind this division is as follows: The IPSec protocol processor's security association library stores N security associations, each containing the key, random number, and associated data required for the encryption algorithm. The data frame processing flow before the ASCON algorithm flow is divided is as follows: Figure 2 As shown, after a data frame enters the IPSec protocol processor, it first needs to perform security policy matching based on the five-tuple of the data frame. Based on the matching result, the corresponding security association is obtained. The ASCON encryption algorithm completes the initialization and associated data encryption stages based on the key, random number and associated data in the security association. Then, it completes the plaintext encryption stage of the data frame and the tag generation stage.

[0078] Since data frames using the same security association have identical calculation results after the initialization and associated data encryption phases in each encryption process, this application breaks down the ASCON algorithm flow into a pre-calculation phase and a message encryption phase to avoid repetitive calculations in each data frame's ASCON encryption process. Figure 3 As shown, the pre-computation phase involves initializing the keys, random numbers, and associated data in N security associations using ASCON and encrypting the associated data, resulting in N pre-computation results. And it corresponds one-to-one with N security alliances. For example... Figure 4 As shown, when a data frame needs to be encrypted, the pre-calculated result can be directly obtained based on the security policy matching result. The encryption process can be directly based on the pre-calculated results. The subsequent plaintext encryption and tag generation stages of the data frame are completed. At this point, for k data frames using the same security association, it is only necessary to... Figure 4 The pre-computation stage shown performs one initialization and associated data encryption stage calculation, reducing the computational overhead by k-1 times.

[0079] ASCON Pre-calculation Module

[0080] The pre-computation phase mainly includes two processes: initialization and associated data encryption. For IPSec data frames using the same Security Association (SA), the key, nonce, and associated security data (such as authentication data) used in the encryption algorithm remain unchanged. Therefore, the calculation results of the initialization and associated data encryption phases are the same in multiple encryption processes. To avoid repeating these calculation processes with each encryption, the pre-computation module completes the initialization and associated data encryption for each security association in advance when creating the security association, and stores the calculation results (intermediate state S) in a dedicated pre-computation result RAM. In this way, in subsequent data frame encryption processes, the data in the pre-computation result RAM can be directly read, avoiding repeated initialization and associated data encryption calculations. The hardware implementation principle of the ASCON pre-computation module is as follows:

[0081] Whenever configuring new security association parameters, input the 128-bit key K, 128-bit random number N, 128-bit associated data A, and its address SA_index in RAM corresponding to the security association.

[0082] The ASCON algorithm is based on the permutation operation, and its formula is as follows. It requires the continuous execution of the round function multiple times. The round function (R) performs a nonlinear transformation on the state S, including three steps: round constant addition, S-box layer, and linear diffusion layer.

[0083]

[0084] Step 1. Initialization Phase (Preprocessing of State S and Key K):

[0085]

[0086]

[0087] Where IV represents the initialization vector, k, r, a, b are the parameters of the ASCON algorithm, K is the key, and N is a random number.

[0088] Step 2. Data Encryption Stage:

[0089]

[0090]

[0091] Step 3. Store the pre-calculated results :

[0092] ; where SA_index is the security association index address.

[0093] Hardware implementation method for shared pre-computed state

[0094] Multiple ESP message processing modules can share the pre-computed state, and its hardware implementation is as follows: Figure 5 As shown, the implementation steps include the following:

[0095] (a) The CPU configures security parameters and writes them into the Storage Security Association (SAD) and the Storage Security Policy (SPD). The security association contains the key K, random number N and associated data A used by the ASCON encryption algorithm in the initialization and associated data phases. Each data frame obtains the corresponding security association by matching the security policy results.

[0096] (b) Whenever a new security association is written to the SAD, the ASCON pre-computation module is triggered to complete the initialization and association data processing phases. It uses the key, random number, and association data from the SA to calculate the intermediate state S and stores it in the pre-computation result RAM. The pre-computation result corresponds one-to-one with each security association. The formula for the pre-computation module to calculate the intermediate state S is as follows:

[0097] (c) Extract the quintuple information from the input data frame, perform security policy matching, and obtain the corresponding security policy and the address of the security association in SAD, as well as the address in the pre-computation result RAM.

[0098] (d) In subsequent protocol processing and data frame encryption, multiple ESP message modules are used for parallel processing. The message scheduling module receives data frames and buffers them in RAM. Based on the ready signal of the ESP message processing module, a polling arbiter selects the module with the highest priority. Simultaneously, based on the memory address of the security policy matching result, the intermediate state S is read from the pre-calculated result RAM. The data frame and S are then distributed to multiple ESP message processing modules to support the ASCON message encryption module in each ESP message processing module to share the same pre-calculated state S. The subsequent encryption and tag generation stages can be completed directly based on the corresponding pre-calculated results.

[0099] ASCON message encryption module

[0100] The ASCON message encryption module can complete the message encryption stage and tag generation stage of plaintext data frames based on the pre-calculation results. The hardware implementation of the ASCON message encryption processing module adopts a parallel round transformation strategy, which processes multiple round transformations in parallel within a single cycle, thereby improving the throughput of the algorithm encryption.

[0101] Permutation is a fundamental computational module in the ASCON algorithm, requiring permutation operations at every stage of the algorithm. In the initialization and final stages of the ASCON-128a algorithm, each permutation requires a (a=12) rounds of transformations, while in the associated data processing and ciphertext generation stages, each permutation requires b (b=8) rounds of transformations. A single round of transformation is as follows: Figure 7 As shown, each permutation in the algorithm requires a fixed number of rounds of transformation. Utilizing hardware multiplexing, multiple rounds of transformation are processed in parallel within one cycle during the frame encryption phase, thereby improving the throughput of the encryption unit. Since the pre-computation phase does not involve real-time throughput requirements, a single-cycle, one-round-transformation strategy is adopted to balance throughput and resource consumption. As the smallest unit of data, if only one round of transformation is performed per cycle, it would require at least 8 cycles to complete a permutation operation for a 128-bit encrypted data block. In the implementation, multiple rounds of transformation are processed in parallel within one cycle. When the number of parallel rounds is m, a permutation operation can be completed in b / m cycles.

[0102] The parallel round-transform encryption process in the plaintext encryption stage is as follows: Figure 8 As shown, its mathematical principle is as follows:

[0103] Step 1: When the Start of Data Frame (SOP) signal is 1, obtain the Security Association Index (addr) based on the SPD lookup result and read the pre-calculated state.

[0104] Step 2: Divide the plaintext data frame into 128-bit blocks: Calculate the encryption result for each plaintext data block.

[0105] Step 3, Update Status After the state is updated, a permutation operation is performed. Each permutation operation in the plaintext encryption phase includes b rounds of transformation.

[0106] Step 4, the calculation formula using the parallel round transformation strategy is as follows, where This represents a single-cycle parallel round transformation function with m iterations, thus completing one permutation operation in b / m cycles. After each round transformation, the round counter is incremented by m. If the round counter equals b, the current permutation operation is complete; otherwise, the parallel round transformation steps continue until all rounds have been executed, resulting in the state after the permutation operation. Used for encryption of the next data block.

[0107]

[0108]

[0109] Step 5: Repeat Steps 2 through 4 until all plaintext blocks are encrypted and the current state is obtained. .

[0110] Step 6, After XORing with (the concatenated string of K and 0), perform a rounds of permutation (also using a parallel m-round transformation strategy), then XOR with K to generate a 128-bit tag.

[0111]

[0112]

[0113] The hardware implementation architecture of the ASCON algorithm's round transformation operation is as follows: Figure 9 As shown, it includes the following modules:

[0114] Control logic circuit: Responsible for starting and stopping the encryption process and controlling the operation of each module. It receives an external start signal to initiate the encryption process and determines whether the algorithm module should perform encryption or decryption based on the input signal enc. Internally, its core is a finite state machine (FSM), which performs state transitions according to different stages of the ASCON-128a algorithm, precisely controlling the data flow between modules. For example, in the pre-computation stage, the control logic circuit is responsible for storing the pre-computed intermediate states in RAM; in the message encryption stage, it is responsible for reading the intermediate states from RAM and passing them to the round-shifting module. Furthermore, it is responsible for sending a start signal to the round-counting module and, based on feedback from the round-counting module, determining whether the round transition of the current stage is complete, thereby performing state transitions to ensure the correct execution of the entire encryption process.

[0115] The round counting module is responsible for calculating and managing the number of round transitions during the encryption process and synchronizing the execution of multiple parallel rounds in a parallel design. In the ASCON-128a algorithm, different stages require different numbers of round transitions. The round counting module starts counting after receiving a start signal from the control logic circuit and increments it every clock cycle until the preset number of rounds for the current stage is reached. In an m-round parallel design, the core function of the round counting module is to ensure that the m round function units operate synchronously in each clock cycle, and after all m parallel rounds are completed, it sends a completion signal to the control logic circuit, informing it that all round transitions for the current stage have been completed, so that the control logic circuit can perform a state transition.

[0116] The round permutation module is the core computational unit of the ASCON algorithm hardware implementation, responsible for executing the most critical round permutation operation. This module reuses m identical round function units in its hardware design, enabling parallel execution of m rounds of transformations within a single clock cycle, thus significantly improving encryption throughput. Each round function unit internally implements the round function R defined by the ASCON algorithm, including three steps: round constant addition, S-box replacement, and linear diffusion. The round permutation module receives the state input S from the control logic circuit, performs m rounds of parallel permutations, and outputs the updated state S to the control logic circuit. This parallelization design is key to improving the performance of the ASCON algorithm hardware implementation.

[0117] Tag Verification Module: This module is primarily responsible for verifying the authentication tag at the final stage of the decryption process to ensure data integrity and authenticity. After all ciphertext blocks have been decrypted, this module calculates an authentication tag. It compares the calculated tag with the received original tag generated during encryption. If the two tags match, it indicates that the data has not been tampered with during transmission or storage, the decryption operation was successful, and data integrity is verified. Conversely, if the tags do not match, it indicates that the data may have been tampered with or corrupted, thus ensuring data integrity.

[0118] 2. Implementation of Security Policy Lookup Algorithm

[0119] All outbound traffic needs to query the SPD to obtain the security policy. Packets enforcing protection policies need to query the associated SA based on the packet's IP address, port, and selector composed of the upper-layer protocol. Theoretically, all inbound traffic should also first query the SPD to obtain the security policy after entering the network. The IPSec security protocol chip can be flexibly selected according to the actual application. Specifically, it uses the five-tuple: source IP address, destination IP address, source port, destination port, and protocol.

[0120] like Figure 10 As shown, this application decomposes the total N-bit matching field into five sub-rule entries for parallel matching operations in the SPD lookup strategy, and each sub-rule employs a fast matching algorithm implemented with a two-dimensional pipeline structure. This implementation outputs one matching result per cycle, achieving a high matching rate and meeting the requirements of high throughput. Furthermore, IPSec systems are highly sensitive to latency; to meet the real-time application requirements of bounded low latency in IoT scenarios, latency needs to be reduced. The improved solution is as follows:

[0121] 1) Since the difference between outbound and inbound traffic matching fields lies in the SPI security parameter, and source and destination ports do not need to be matched during inbound traffic, the 32-bit security parameter SPI and source / destination port matching fields can be merged for matching. This reduces the matching overhead of the 32-bit field.

[0122] 2) Since IPSec's matching fields are relatively fixed, requiring only five fields: source and destination addresses, source and destination ports (or SPI parameters), and protocol number, the 296-bit field to be matched can be decomposed into five sub-rule entries. These five fields can then be matched in parallel. Each field uses a two-dimensional pipelined matching rule. Finally, the matching results of the five fields are ANDed to obtain the final matching rule. This way, the maximum matching latency depends only on the latency of the longest matching field in the sub-rule table, significantly reducing the overall matching process latency.

[0123] The two-dimensional flow table lookup algorithm is as follows: data transmission can be divided into horizontal and vertical directions. For a flow table rule set with N bits and L rules, the horizontal direction is divided into... Each s-bit subfield is vertically divided into... A processing unit (PE) is the process of matching n rules for each s-bit subfield of a rule block. A two-dimensional pipelined structure is used to achieve pipelined matching in both horizontal and vertical directions, allowing for processing of the packet header vector once per clock cycle with a relative delay. At time 0: The first subfield of the first packet header vector is input to PE[0,0], and matching begins. At time t: PE[0,0] vertically passes the subfield to PE[1,0] and horizontally passes the matching result to PE[0,1]. PE[0,1] begins matching the second subfield of the first packet header vector. Simultaneously, PE[0,0] receives the first field of the second packet header vector. At time 2t: In the horizontal direction, PE[0,0] outputs the matching result of the first subfield of the second packet header vector to PE[0,1], PE[0,1] outputs the matching result of the second subfield of the first packet header vector to PE[0,2], and PE[0,2] performs matching on the third subfield. In the vertical direction, PE[2,0] receives the matching result from PE[1,0], PE[1,1] receives the matching result from PE[1,0], and so on, until the final matching result in the last stage of the horizontal pipeline is obtained. Vertical matching is performed through subfield pipelines, passing through the vertical pipeline to the last horizontal pipeline, where matching of the n rules in the last horizontal pipeline continues. The last stage of each horizontal pipeline is a priority encoder module, whose main function is to select the highest priority matching rule from the n rules contained in that pipeline. The absolute processing delay of the matching... Because it uses a pipelined mode, there is a result output every clock cycle.

[0124] Within each processing unit (PE) of this two-dimensional pipelined structure, the memory is implemented as RAM, with an address width of 4 bits and a data width of 8 bits. The specific structure of the processing unit PE is as follows: Figure 11 As shown, the `rule_in` field to be matched in the PE block is used as the read address of RAM to read the information stored in RAM. A bitwise AND operation is performed with the matching result `bv_in` from the previous level to obtain the matching result `bv_out`, which is then output horizontally to the next PE unit in the horizontal direction. Simultaneously, the field to be matched is registered and output vertically to the next PE unit in the vertical direction. When `bv_out` is all 0s, the horizontal enable output `en_out` is set to 0; otherwise, it is set to 1, serving as the enable input for the next PE unit in the horizontal direction.

[0125] 3) Further analysis reveals that the maximum latency in the matching process of the five sub-rule tables stems from the matching of source and destination addresses. IPv4 addresses are 32 bits, while IPv6 addresses are 128 bits. If the data frame type is IPv4, the last 96 bits must be wildcards when configuring the matching rules. Therefore, 96 bits of matching results are wasted in the source and destination address matching pipeline. In the design, when the data frame preprocessing module extracts the source and destination addresses required for matching, it adds an indication signal to indicate whether it is IPv4. If it is an IPv4 packet, the matching process will terminate early, and the final matching result can be output after matching 32 bits, reducing latency. Since the matching latency of the five sub-rule tables differs, it is necessary to store the matching results of the source port number, destination port number, and protocol number fields. After the source and destination IP address matching results are output, the stored results are read, and the matching results of the five fields are ANDed to obtain the final matching result. For example... Figure 12 As shown, by matching five fields in parallel, the matching results can be output in as little as 12 cycles.

[0126] 3. Implementation of the message processing scheduling and reordering module

[0127] The message processing scheduling module is located at the entry point of the multi-channel ESP message processing module. It is used to receive and distribute data frames to be processed by the protocol after packet processing. The protocol processing scheduling module determines the idle status of multiple ESP message processing modules, that is, whether they are allowed to receive new protocol processing data frames. From the ESP message processing modules that are allowed to receive new data frames, it selects the one with the highest current priority and sends the data frame to that protocol processing module. At this time, the ESP message processing module pulls the ready signal low until processing is completed, and then pulls the ready signal high again.

[0128] Multiple ESP message processing modules input their respective ready signals as polling request signals to the polling arbitrator module. The arbitrator module cyclically selects the highest priority signal from the request signals of each module and generates an arbitration result signal. After the data frame is output to the corresponding ESP message processing module according to the arbitration result, the arbitrator sets the priority of that ESP message processing module to the lowest, and the priorities of the remaining processing modules are simultaneously updated, increasing sequentially.

[0129] Because multiple ESP message processing modules process data frames in parallel, and the protocol processing time for data frames of different lengths varies, later input short data frames may have a shorter protocol processing time than earlier input long data frames, resulting in out-of-order data frames. To restore the original order as before protocol processing, the data frames should be reordered. The hardware structure of the reordering module is as follows: Figure 13 As shown, the processing flow is as follows:

[0130] (1) First, when the message processing scheduling module distributes the protocol to process data frames, each data frame is numbered sequentially by a counter. The ID number starts from 0 and increments sequentially as the original sequence information of the data frame.

[0131] (2) After the N ESP message processing modules complete the ESP protocol processing of the data frame, the data frame and its length information are buffered in the FIFO respectively. At the same time, the ready signal is pulled high, the ID number of the current data frame and the sequence number of the ESP message processing module are output, and the result is requested to be written to the reordering module.

[0132] (3) In the reordering module, the cyclic polling arbitration module is responsible for arbitration when multiple protocol processing modules request to write at the same time. It uses the ID number as the write address of RAM, and writes the frame length information and the sequence number of the ESP message processing module into the dual-port RAM through port A, and writes the valid bit to 1.

[0133] (4) The counter increments from 0 to serve as the read address of the RAM, thereby achieving the purpose of sequentially reading data frames. If the valid bit of the current read data is 1, the subsequent read control logic reads the data frame from the corresponding protocol processing module according to its frame length information and module number and outputs it.

[0134] (5) When a data frame is output, the counter value is incremented by one, and the valid data bit of that address in RAM is written back to 0 through port B.

[0135] (6) Add fixed-priority arbitration logic to the two write ports of the dual-port RAM, prioritize writing the processing results of out-of-order ESP messages, and then process write-back requests that clear the valid bits.

[0136] 4. ESP Message Processing Module (i.e., ESP Message Processing Module Group)

[0137] The ESP packet processing module performs IPSec protocol processing based on whether the data frame is outbound or inbound traffic. The structure of the protocol processing module is as follows: Figure 14 As shown, the various processes in ESP message processing are performed in parallel. After the data frame is input, the encryption module is activated according to the SOP signal of the data frame. Multi-process parallel processing technology is used to distribute the various functional items of the module to multiple processes for parallel processing according to their functions, thereby improving the system processing efficiency. The role of each module in ESP message processing during outbound traffic is described below:

[0138] The encryption preprocessing engine splits the input data frame, storing the Layer 2 MAC information, IP header, and the data frame to be encrypted in separate FIFOs. The SA Security Association defines two operating modes: transport mode and tunnel mode. In transport mode, only the data packet payload needs to be encrypted; in tunnel mode, the entire IP data packet needs to be encrypted. The encryption preprocessing process also extracts the Ethernet frame type, first determining if it is a VLAN data frame. If it is a VLAN, the Layer 2 MAC information length is 144 bits; otherwise, it is 112 bits. If the data packet is IPv4, 20 bytes are stored in the IP header FIFO; if the data packet is IPv6, the data packet header in the IP header FIFO is 40 bytes.

[0139] ASCON Encryption Control Module: After a data frame is input, the ASCON message encryption module will be started according to the SOP signal. The key K in the security association output by the message scheduling module and the pre-computed intermediate state Spre will be sent to the ASCON message encryption module. The module will wait for the preprocessing engine to split the data frame and then complete the entire encryption process, caching the encrypted data in the FIFO.

[0140] ESP encapsulation module: concatenates the input SPI security parameter index and SN serial number into an ESP header, and then stores the output to the data frame concatenation module.

[0141] IP Header Encapsulation Module: For IPv6 data frames, if the operating mode is tunnel mode, the source and destination IP addresses in the IPv6 header are updated based on the input SAD information, the nextheader field is changed to 50 (representing the ESP protocol), and the payloadlength field is updated based on the encapsulated ESP length calculated by the encryption preprocessing engine. If the operating mode is transport mode, the source and destination IP addresses in the IP header do not need to be updated; the other fields are modified in the same way as in tunnel mode. For IPv4 data frames, if the operating mode is tunnel mode, the source and destination IP addresses in the IPv4 header also need to be updated based on the input SAD information, the protocol field is changed to 50 (ESP protocol), and totallength is the encapsulated length calculated by the preprocessing engine. Unlike IPv6, a new checksum value needs to be calculated.

[0142] In one specific embodiment, in order to enable those skilled in the art to better understand this application, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0143] However, it should be noted that the examples described below are merely specific examples and are not intended to limit the embodiments of this application to the specific steps, values, conditions, data, order, etc. Those skilled in the art can utilize the concepts of this application to construct more embodiments not mentioned in this specification by reading this specification.

[0144] refer to Figure 16 The processing steps 1 to 7 of the IPSec protocol processor based on a lightweight encryption algorithm provided in this application are as follows:

[0145] Step 1a: The CPU initiates and manages key negotiation for the IPSec protocol, using the IKE protocol for key exchange. By exchanging necessary security parameters with the communication peer, such as encryption algorithm type and authentication method, a Security Association (SA) is established. During communication, the CPU dynamically maintains the contents of the Security Policy Detection (SPD) and Security Association Detection Address (SAD). For example, when a key is nearing its timeout, IKE negotiation is re-triggered to generate a new key. The CPU handles exceptions when the SPD lookup fails, notifying the IKE module to re-establish the security policy. The CPU writes the negotiated security policy into the SPD to define the processing method for data flows. The CPU configures the generated Security Association (SA) into the Security Association Database. The storage information for the SAD is shown in Table 1, and Table 2 provides a configuration example of the security policy database in an enterprise network scenario.

[0146] Table 1. Definitions of fields in the Security Alliance

[0147]

[0148] Table 2 Definitions of fields in the Security Alliance

[0149]

[0150] Step 1b: The ASCON pre-computation module uses the keys, random numbers and associated data in the security association to complete the initialization and associated data processing stages of each security association, calculates the intermediate state S, and stores it in the pre-computation result RAM.

[0151] Step 2: The data frame preprocessing module receives the input data packets. The overall block diagram is as follows: Figure 16 As shown, the preprocessing operation for data frames mainly includes the following three steps:

[0152] In step (2a), after receiving the data frame, the preprocessing module extracts the IP address, source and destination ports, and frame type of the data frame and sends them to the SPD matching module.

[0153] In step (2b), the security policy lookup module uses the stride-bv matching algorithm with two-dimensional pipeline to perform parallel matching of the five-tuple information, quickly outputs the security policy (such as discard, bypass, and protect) and parameters, and searches for the corresponding security association information in the security association database according to the matching results.

[0154] In step (2c), the preprocessing module finds the matching results output by the security policy lookup module, completes the correct transfer of data frames on the internal bus, and completes the three types of processing: dropping, bypassing, and IPSec processing.

[0155] Step 3, as follows Figure 15 The diagram shows the overall block diagram of data frame preprocessing. The protocol processing and scheduling module receives the data frames that need protocol processing after packet processing and distributes them to one of the multiple ESP message processing modules. While distributing data frames, the protocol processing and scheduling module counts the number of data frames needed, adds an ID number to each data frame, and outputs it along with the data frame to the protocol processing module. This is because processing modules of different frame lengths have different processing times, facilitating the subsequent reordering module to reorder the protocol-processed data frames and restore them to their original order.

[0156] Step 4: The protocol processing module performs ESP message processing based on whether the data frame is outbound or inbound traffic. The structure of the protocol processing module is as follows: Figure 16 As shown below, the ESP message processing flow for outbound traffic is described.

[0157] Step (4a): The encryption preprocessing engine splits the input data frame and stores the Layer 2 MAC information, IP header, and data frame to be encrypted in the FIFO.

[0158] Step (4b) completes the IPSec encapsulation process, which includes the encapsulation of the ESP header and the encapsulation of the IP data frame header. The ESP header encapsulation module concatenates the input SPI security parameter index and SN sequence number into an ESP header, and then outputs it to the data frame concatenation module.

[0159] Step (4c): After the data frame is input, the ASCON encryption control module will start the ASCON message encryption module according to the sop signal. The key K in the security association output by the message scheduling module and the pre-computed intermediate state Spre will be sent to the ASCON message encryption module. The preprocessing engine will split the data frame and then complete the entire encryption process. The encrypted data will be cached in the FIFO.

[0160] Step (4d) involves reassembling each field of the data frame after protocol processing and caching it in a FIFO to await sorting and output by the reordering module.

[0161] Steps 5a-5d describe the protocol processing procedure for inbound traffic, which is similar to that for outbound traffic. The key difference is that replay detection is performed before preprocessing the data frames. When the device receives an authenticated message, if the message's sequence number is the same as that of an already decapsulated message, or if the message's sequence number is smaller and not within the sliding window, then the message is considered a replay message. Since decapsulating replay messages has no practical effect and consumes significant device resources, leading to decreased service availability, enabling IPSec replay protection and discarding detected replay messages before decapsulation can reduce device resource consumption.

[0162] Step 6: Reorder the data frames processed by multiple ESP message modules. The reordering module collects and summarizes the outputs of multiple ESP message processing modules, and sorts the out-of-order processing results to restore them to the order before the data packets entered the protocol processing module.

[0163] like Figure 16 The diagram shows the processing steps of the IPSec protocol processor.

[0164] In one specific embodiment, the overall implementation result of this application is as follows:

[0165] The IPSec protocol processor employs a multi-stage pipelined architecture, comprising three main parts: data frame preprocessing, security policy lookup, and ESP packet processing. Since ESP packet processing includes encryption and decryption of data frames, it is the bottleneck for the overall throughput of the protocol processor. Therefore, to improve throughput, this paper designs multiple ESP packet processing modules to process the protocol in parallel. Each packet processing module contains an encryption core, and the optimization and selection of the ASCON-128a encryption algorithm are key aspects. The throughput calculation formula for the algorithm is as follows:

[0166]

[0167] This design uses the xcvu13p FPGA development board to synthesize and implement the ASCON-128a algorithm module. As shown in the table below, when the number of permutations P per cycle is 1, even though its maximum frequency is high, the overall throughput is very low. When P=4, although the throughput is high, the overall frequency is low, and the resource utilization is also low. Taking all factors into consideration, the single-cycle, two-permutation method is chosen, which has high resource utilization and high throughput.

[0168] Table 3. FPGA Implementation Results of ASCON Algorithm

[0169]

[0170] This application optimizes throughput for short frame data. Since the data frames are of random length, and the ASCON encryption process is divided into four parts: initialization, associated data encryption, plaintext data encryption, and tag generation, each permutation in the initialization and final stages of the ASCON-128a algorithm requires 12 rounds of transformations, necessitating one permutation operation. In the associated data processing and ciphertext generation stages, each permutation requires 8 rounds of transformations, and each 128-bit encryption block requires one permutation operation. Therefore, with a single-cycle permutation of 2 rounds, the initialization stage consumes 6 cycles, the associated data encryption stage 4 cycles, and the plaintext encryption stage consumes (bits / 128...). 4) cycles, the tag generation stage consumes 6 cycles. The actual data encryption throughput calculation formula is as follows: it decreases as the length of the data frame encrypted per instance decreases.

[0171] By pre-calculating and storing intermediate states S, the optimized calculation formula is as follows. For short frames, the impact of the initialization and associated data encryption phases becomes more pronounced due to their larger cycle size. This can significantly improve throughput. Figure 17 As shown, in the case of 64B short frames, the optimized throughput can be increased by 1.46 times, and the resource consumption of this implementation is less than that of the original implementation.

[0172]

[0173] This application implements IPSec protocol processors with throughputs of 10Gbps and 40Gbps, instantiating two and eight ESP packet processing modules respectively. The maximum throughputs achieved are 13.44Gbps and 53.96Gbps, respectively. The overall implementation results are as follows. Compared with other implementations, this application achieves higher throughput with lower resource requirements at the same throughput rate and with similar resources:

[0174] Table 4. Implementation Results of the IPSec Protocol Processor

[0175]

[0176] Furthermore, according to a second aspect of the embodiments of this disclosure, a hardware implementation method for an IPSec protocol processor based on the ASCON lightweight encryption algorithm is provided, the method comprising:

[0177] For each security association, the ASCON algorithm is executed to initialize the key, random number, and associated data, and the associated data encryption phase is performed to generate and store intermediate states. The intermediate states are bound to the corresponding security association and stored in the pre-calculated results RAM.

[0178] A parallel subfield matching algorithm with a two-dimensional pipeline structure is adopted, which decomposes the matching field into five sub-rule entries: source IP address, destination IP address, source port, destination port and protocol number, and performs parallel matching. Invalid matching operations are reduced by using an early termination strategy for IPv4 data frames.

[0179] The polling arbitrator dynamically allocates data frames to be processed to the ESP message processing module group and assigns a unique ID to each data frame to mark the original order.

[0180] Based on the pre-calculation results, plaintext encryption and tag generation are performed on the data frame. A single-cycle parallel multi-round transformation strategy is adopted, and m rounds of transformation are processed in parallel within a single cycle by reusing round function units. The number of rounds b of the permutation operation is completed in b / m cycles. Furthermore, an ESP header is generated and the IP header fields are updated, supporting both tunnel mode and transmission mode.

[0181] The dual-port RAM is used to store the ID, length information and corresponding ESP message processing module number of the data frame. The data frames are read and output in ascending order of ID to ensure the order of the data stream.

[0182] Coordinate state transitions and data flow control between modules, including pre-calculation triggering, distribution of security policy matching results, and scheduling of encryption processes.

[0183] The technical solutions provided by the embodiments of this disclosure may include the following beneficial effects:

[0184] 1. This application proposes a hardware implementation device for an IPSec protocol processor based on the ASCON lightweight encryption algorithm. The aim is to reduce resource consumption and latency while maintaining high throughput by introducing the ASCON lightweight encryption algorithm and an optimized security policy matching algorithm. For the application scenario of encryption algorithms in IPSec protocol processing, the initialization and associated data encryption intermediate states of each security association are pre-calculated and stored, avoiding redundant calculations. Through single-cycle parallel execution of multiple rounds of transformations, throughput is improved. Furthermore, by combining a fast security policy matching method with parallel subfields in a two-dimensional pipeline structure and a packet scheduling and reordering module based on dual-port RAM, parallel processing of multiple ESP packet processing modules is achieved, thereby improving the throughput of the IPSec protocol processor.

[0185] 2. This application provides a phased hardware implementation method for the ASCON algorithm, which divides the ASCON algorithm process into a pre-computation stage and a message encryption stage. In the pre-computation stage, ASCON initialization and associated data encryption are performed on the keys, random numbers, and associated data in N security associations to obtain N pre-computation results. Each data frame corresponds one-to-one with one of N security associations. When a data frame needs to be encrypted, the pre-calculated result can be directly obtained based on the security policy matching result. The encryption process can be directly based on the pre-calculated results. This completes the subsequent plaintext encryption and tag generation stages of the data frame. This avoids redundant calculations during the message encryption stage, improving encryption efficiency and reducing resource consumption.

[0186] 3. This application provides a hardware implementation method for multiple ESP message processing modules to share a pre-computation state. After configuring the security association and security policy on the CPU, the method performs the corresponding pre-computation stage through the pre-computation module and stores the result in the pre-computation result RAM. The message scheduling module reads the intermediate state S from the pre-computation result RAM according to the memory address of the security policy matching result, and distributes the data frame and S to multiple ESP message processing modules to support the ASCON message encryption module in each ESP message processing module to share the same pre-computation state S, and can directly complete the subsequent encryption and tag generation stages based on the corresponding pre-computation results.

[0187] This application provides an architecture for implementing the ASCON algorithm with single-cycle parallel multi-round transformations at the hardware level. The ASCON message encryption module employs a single-cycle parallel multi-round transformation strategy, allowing multiple rounds of transformations in the permutation operation to be executed in parallel within each clock cycle, thereby improving the throughput of the encryption process. When the number of parallel rounds is m, a permutation operation can be completed in b / m cycles. Since the pre-computation stage does not involve real-time throughput requirements, a single-cycle one-round transformation strategy is adopted to balance throughput and resource consumption.

[0188] 5. Considering the prevalence of short frame data in actual network transmission, this application avoids the additional overhead of short frame data in the initialization and associated data encryption stages by using pre-calculated results, making the throughput improvement more significant when processing short frame data.

[0189] 6. This application provides a security policy matching method based on a two-dimensional pipelined structure. The total N-bit matching field is decomposed into five sub-rule entries (including source IP address, destination IP address, source port number, destination port number, and protocol number) for parallel matching operations. Each sub-rule employs a fast matching algorithm implemented using a two-dimensional pipelined structure. Since this matching algorithm is compatible with both IPv4 and IPv6 data frames, and considering that the source and destination IP address lengths of IPv4 data frames are only one-quarter the length of IPv6 addresses, the matching module can prematurely terminate the matching operation on the remaining bits after recognizing an IPv4 data frame, reducing the matching latency to the time required to process only the IPv4 address.

[0190] 7. This application provides a mechanism for data reordering via dual-port RAM. In this mechanism, when distributing data frames, the message scheduling module sequentially numbers each data frame using a counter, uses this ID number as the write address to the RAM, and writes the data frame, its length information, and the corresponding ESP message processing module sequence number into a FIFO. A polling arbitrator selects the request with the highest priority and writes the data into the dual-port RAM. When reading data, the reordering module uses the incrementing counter as the address to read the data from the dual-port RAM, and reads the data frame from the corresponding ESP processing module according to the frame length information and module sequence number, and outputs it, thereby ensuring the sequential order of data output.

[0191] 8. This application provides a message scheduling module for scheduling data frames that require protocol processing after packet processing, and for selecting the module with the highest priority using a polling arbitrator based on the ready signal of the ESP message processing module, thereby achieving efficient scheduling and distribution of data frames.

[0192] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

Claims

1. A hardware implementation device of an IPSec protocol processor based on the ASCON lightweight encryption algorithm, characterized in that, The device comprises: A pre-computation module for performing the initialization and associated data encryption phase of the ASCON algorithm on the key, random number and associated data of each security alliance to generate and store an intermediate state; wherein the intermediate state is stored in the pre-computation result RAM in association with the corresponding security alliance; A security policy matching module for adopting a parallel sub-field matching algorithm of a two-dimensional flow structure to decompose the matching field into five sub-rule table items of source IP address, destination IP address, source port, destination port and protocol number for parallel matching, and to reduce invalid matching operations through the early termination strategy of the IPv4 data frame; wherein the two-dimensional flow structure of the security policy matching module comprises: a horizontal direction divided into a plurality of processing units, each processing unit matching a fixed bit width sub-field; a vertical direction passing the sub-field information through a pipeline, and a priority encoder outputting the final matching result according to the priority; and for the IPv4 data frame, the subsequent matching operation is terminated early after matching the 32-bit address; A packet scheduling module for dynamically allocating the data frames to be processed to the ESP packet processing module group based on a polling arbitrator, and allocating a unique ID to each data frame to mark the original order; The ESP packet processing module group comprises a plurality of ESP packet processing modules, each of which comprises an ASCON packet encryption unit and an ESP encapsulation unit; wherein the ASCON packet encryption unit is used for performing plaintext encryption and label generation on the data frame based on the pre-computation result, adopting a single-cycle parallel multi-round transformation strategy, and performing m-round transformation in parallel within a single cycle through multiplexing the round function unit, and the number of rounds b of the permutation operation is completed through b / m cycles; and the ESP encapsulation unit is used for generating an ESP header and updating the IP header field, and supports the tunnel mode and the transport mode; A reordering module for storing the ID, length information and corresponding ESP packet processing module sequence number of the data frame in a dual-port RAM, reading and outputting the data frame in the ID increasing order, and ensuring the ordering of the data stream; A control logic module for coordinating the state conversion and data flow control among the modules, including pre-computation triggering, security policy matching result distribution and encryption flow scheduling.

2. The hardware implementation device of the IPSec protocol processor based on the ASCON lightweight encryption algorithm according to claim 1, characterized in that, The pre-computation process of the pre-computation module comprises: Generating initial state according to security alliance parameters and completing initialization through a round transformation Performing b times round transformation on the associated data and generating an intermediate state , and storing into a pre-computation result RAM; wherein the pre-computation module is triggered when a new security association is configured, and all ESP packet processing modules share the same pre-computation result.

3. The hardware implementation device of the IPSec protocol processor based on the ASCON lightweight encryption algorithm according to claim 1, characterized in that, The single-cycle parallel multi-round transformation strategy of the ASCON packet encryption unit comprises: Multiplexing m round function units to perform m times of round transformation in parallel within a single cycle; The pre-computation stage adopts a single-cycle single-round transformation strategy, and the packet encryption stage adopts a single-cycle m-round transformation strategy; wherein m≥2.

4. The hardware implementation device of the IPSec protocol processor based on the ASCON lightweight encryption algorithm according to claim 1, characterized in that, The reordering module realizes the ordered output through the following steps: The packet scheduling module allocates an increasing ID to each data frame; After each ESP packet processing module completes the processing, the data frame ID, length information and module sequence number are written into the dual-port RAM; The reordering module reads the valid data in the RAM in the ID increasing order and extracts the data frame from the FIFO of the corresponding module.

5. The hardware implementation device of the IPSec protocol processor based on the ASCON lightweight encryption algorithm according to claim 1, characterized in that, The ASCON packet encryption unit further comprises: After all the blocks of messages are encrypted, the final state The specified round permutation is performed, and the authentication tag is generated by XORing with the key, for data integrity check.

6. A hardware implementation method of an IPSec protocol processor based on the ASCON lightweight encryption algorithm, characterized in that, The method comprises: The initialization and associated data encryption phase of the ASCON algorithm is performed on the key, random number and associated data of each security alliance to generate and store an intermediate state; wherein the intermediate state is stored in the pre-computation result RAM in association with the corresponding security alliance; A parallel sub-field matching algorithm with a two-dimensional pipeline structure is adopted to decompose the matching field into five sub-rule table items of source IP address, destination IP address, source port, destination port and protocol number for parallel matching, and an early termination strategy for IPv4 data frames is adopted to reduce invalid matching operations; wherein the two-dimensional pipeline structure of the security policy matching module includes: a horizontal direction is divided into multiple processing units, each processing unit matches a fixed bit width sub-field; a vertical direction passes the sub-field information through a pipeline, and a priority encoder outputs the final matching result according to priority; for IPv4 data frames, the subsequent matching operation is terminated after matching 32-bit address; Based on the polling arbitrator, the data frames to be processed are dynamically allocated to the ESP packet processing module group, and a unique ID is allocated to each data frame to mark the original order; Based on the pre-computation result, the plaintext encryption and label generation are performed on the data frame, a single-cycle parallel multi-round transformation strategy is adopted, and m rounds of transformation are processed in parallel in a single cycle through multiplexing of the round function unit; wherein the number of rounds b of the permutation operation is completed through b / m cycles; and the ESP header is generated and the IP header field is updated to support the tunnel mode and the transmission mode; The ID, length information and corresponding ESP packet processing module number of the data frame are stored in the dual-port RAM, the data frame is read and output in ID increasing order to ensure the order preservation of the data stream; The state conversion and data flow control among the modules are coordinated, including pre-computation triggering, security policy matching result distribution and encryption process scheduling.

Images