Encryption and decryption authentication system and method, electronic equipment and computer program product

Abstract

The invention provides an encryption and decryption authentication system and method, an electronic device and a computer program product, the encryption and decryption authentication system comprises a processor core and a hardware accelerator, key operation of an AES-GCM algorithm is mapped into a specific user-defined storage instruction, and the specific user-defined storage instruction is executed by the special hardware accelerator, so that the key operation of the AES-GCM algorithm is mapped into the specific user-defined storage instruction. Therefore, while the program control flexibility of the processor is maintained, the algorithm execution delay and the processor load are greatly reduced, and high-efficiency encryption and decryption authentication of software and hardware collaboration is realized.

Description

Technical Field

[0001] This application belongs to the field of data security technology, and in particular relates to an encryption / decryption authentication system, method, electronic device, and computer program product. Background Technology

[0002] With the rapid development of the Internet of Things, edge computing, and high-speed communication technologies, the demand for secure data transmission and processing is increasing. Advanced Encryption Standard - Galois / Counter Mode (AES-GCM), as an encryption algorithm that simultaneously provides data confidentiality, integrity, and authentication, has been widely used in network protocols, secure storage, and other fields.

[0003] In related technologies, implementing the AES-GCM algorithm generally relies on executing software code on a general-purpose processor. While this pure software implementation offers good versatility and flexibility, it faces significant bottlenecks in computational performance and energy efficiency. Because the algorithm itself involves a large number of complex iterative operations, executing general-purpose instructions sequentially consumes excessive processor clock cycles, resulting in high processing latency and low throughput, making it difficult to meet the real-time requirements of high-speed data stream encryption. Summary of the Invention

[0004] This application provides an encryption / decryption authentication system, method, electronic device, and computer program product that can reduce algorithm execution latency and processor load while maintaining the flexibility of processor program control.

[0005] A first aspect of this application provides an encryption / decryption authentication system, including a processor core and a hardware accelerator. The processor core is configured to execute a first custom storage instruction, wherein the first custom storage instruction encodes a first source memory address pointing to target parameters and a key, instructing the processor core to retrieve the target parameters and key from the first source memory address and transmit the target parameters and key to the hardware accelerator; the processor core is further configured to execute a second custom storage instruction, wherein the second custom storage instruction encodes a second source memory address pointing to a data block to be processed and a target memory address pointing to a result storage area, instructing the processor core to send a computation instruction to the hardware accelerator and send the source memory address and the target memory address to the hardware accelerator; the hardware accelerator is configured to respond to the computation instruction, execute the AES-GCM algorithm on the data block to be processed read from the second source memory address according to the target parameters and the key, obtain algorithm result data and an authentication tag, and write the algorithm result data and the authentication tag to the target memory address.

[0006] In the technical solution of this application, by mapping the key operations of the AES-GCM algorithm to specific custom storage instructions and entrusting them to a dedicated hardware accelerator for execution, the algorithm execution latency and processor load are significantly reduced while maintaining the flexibility of processor program control, thus achieving high-efficiency encryption and decryption authentication through software and hardware collaboration.

[0007] Optionally, in one possible implementation of the first aspect, the aforementioned hardware accelerator includes a counter-mode encryption / decryption unit and a Galois hash authentication unit. When the AES-GCM algorithm is used for encryption calculation, the algorithm result data is ciphertext data; when the AES-GCM algorithm is used for decryption calculation, the algorithm result data is plaintext data. The counter-mode encryption / decryption unit is used to perform encryption calculations on the data block to be processed according to the target parameters and the key to obtain ciphertext data, or to perform decryption calculations on the data block to be processed to obtain plaintext data. The Galois hash authentication unit is used to perform authentication calculations on the additional authentication data portion and the ciphertext data in the data block to be processed when the AES-GCM algorithm is used for encryption calculation, to obtain an authentication tag. The counter-mode encryption / decryption unit and the Galois hash authentication unit are configured to execute in parallel. Therefore, by setting parallel counter-mode encryption / decryption units and Galois hash authentication units within the hardware accelerator, encryption / decryption calculations and authentication calculations can be performed synchronously, significantly improving the processing throughput of a single data block.

[0008] Optionally, in another possible implementation of the first aspect, the hardware accelerator further includes a scheduling unit, a counter-mode encryption / decryption unit comprising multiple first parallel computing sub-units, and a Galois hash authentication unit comprising multiple second parallel computing sub-units. The scheduling unit is used to split the data block to be processed into multiple sub-data blocks and send each sub-data block to the corresponding first or second parallel computing sub-unit for processing. Thus, by splitting the data block to be processed into multiple sub-data blocks through the scheduling unit and allocating them to multiple parallel computing sub-units for processing, parallel pipelined computation of multiple data blocks is achieved, greatly improving the system's overall processing capacity and throughput for large amounts of data.

[0009] Optionally, in another possible implementation of the first aspect, the format of the first custom memory instruction and the second custom memory instruction is a memory type instruction format based on the Reduced Instruction Set Computer Fifth Generation (RISC-V) instruction set architecture; the processor core is specifically used for: determining the first source memory address based on the source register field of the first custom memory instruction; determining the data length of the target parameter and key based on the immediate numeric field of the first custom memory instruction; and performing the operation of obtaining the target parameter and key and transmitting the target parameter and key to the hardware accelerator based on the first source memory address and the data length of the target parameter and key; the processor core is also specifically used for: determining the second source memory address based on the first source register field of the second custom memory instruction; determining the target memory address based on the second source register field of the second custom memory instruction; determining the length of the data block to be processed based on the immediate numeric field of the second custom memory instruction; and performing the operation of sending arithmetic instructions to the hardware accelerator based on the second source memory address, the target memory address, and the length of the data block to be processed. Therefore, by adopting an instruction format based on the RISC-V standard memory type and explicitly defining the fields (such as the source register field and the immediate number field) for carrying address and length parameters, the processor core can efficiently and accurately parse and execute custom instructions, ensuring the standardization and reliability of the hardware and software interface.

[0010] Optionally, in another possible implementation of the first aspect, the processor core further includes a random delay control unit; specifically, the processor core is configured to: before transmitting the target parameters and key to the hardware accelerator, invoke the random delay control unit to insert a random number of clock cycles of waiting. Thus, by inserting random waiting cycles generated by the random delay control unit before the processor core transmits the critical key parameters, the timing characteristics of the operation execution are disrupted, effectively increasing the difficulty of implementing side-channel attacks through precise timing analysis.

[0011] Optionally, in another possible implementation of the first aspect, the hardware accelerator further includes a key expansion unit. The key pointed to by the first custom storage instruction includes a key length identifier. The key expansion unit is used to perform an expansion operation on the key for the corresponding number of rounds based on the key length identifier. Thus, by carrying the key length identifier in the instruction and having the key expansion unit in the hardware accelerator perform the corresponding expansion operation based on this identifier, the same hardware system can dynamically adapt to and support AES algorithms with different key lengths, enhancing the system's flexibility and applicability.

[0012] Optionally, in another possible implementation of the first aspect, the hardware accelerator is specifically used for: determining whether the length of the data block to be processed exceeds a preset single processing capacity during the execution of the AES-GCM algorithm; if the length of the data block to be processed exceeds the single processing capacity, dividing the data block to be processed into multiple sequential sub-data blocks according to the single processing capacity; sequentially executing the AES-GCM algorithm on each sub-data block, and sequentially writing the corresponding partial algorithm result data of each sub-data block to the target memory address, until the last sub-data block is completed, and generating an authentication tag. Thus, by enabling the hardware accelerator to automatically determine the data block size and process it in segments according to a preset capacity, it can transparently process data exceeding its single physical computation capacity, providing a unified and concise big data processing interface to the upper-layer software.

[0013] A second aspect of this application provides an encryption / decryption authentication method, comprising: executing a first custom storage instruction through a processor core, wherein the first custom storage instruction encodes a first source memory address pointing to target parameters and a key, to instruct the processor core to obtain the target parameters and the key from the first source memory address and transmit the target parameters and the key to a hardware accelerator; executing a second custom storage instruction through the processor core, wherein the second custom storage instruction encodes a second source memory address pointing to a data block to be processed and a target memory address pointing to a result storage area, to instruct the processor core to send a computation instruction to the hardware accelerator and send the source memory address and the target memory address to the hardware accelerator; and, through the hardware accelerator, responding to the computation instruction, executing the AES-GCM algorithm on the data block to be processed read from the second source memory address according to the target parameters and the key, obtaining algorithm result data and an authentication tag, and writing the algorithm result data and the authentication tag to the target memory address.

[0014] A second aspect of this application provides an encryption / decryption authentication device, comprising: The first execution module is used to execute a first custom storage instruction through the processor core. The first custom storage instruction encodes a first source memory address pointing to the target parameters and key, instructing the processor core to obtain the target parameters and key from the first source memory address and transmit the target parameters and key to the hardware accelerator.

[0015] The second execution module is used to execute a second custom memory instruction through the processor core. The second custom memory instruction encodes a second source memory address pointing to the data block to be processed and a target memory address pointing to the result storage area, so as to instruct the processor core to send arithmetic instructions to the hardware accelerator and send the source memory address and the target memory address to the hardware accelerator.

[0016] The third execution module is used to respond to the operation instructions through the hardware accelerator, and execute the AES-GCM algorithm on the data block to be processed read from the second source memory address according to the target parameters and the key, so as to obtain the algorithm result data and the authentication tag, and write the algorithm result data and the authentication tag to the target memory address.

[0017] A fourth aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the encryption / decryption authentication method of the second aspect described above.

[0018] The fifth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the encryption / decryption authentication method of the second aspect described above.

[0019] A sixth aspect of this application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the encryption / decryption authentication method described in the second aspect.

[0020] It is understood that the beneficial effects of the second to sixth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram of the architecture of an encryption / decryption authentication system provided in an embodiment of this application; Figure 2 This is a schematic diagram of the RISC-V instruction format provided in the embodiments of this application; Figure 3 This is a diagram of the S-type RISC-V instruction format provided in the embodiments of this application; Figure 4 This is a schematic diagram of a custom instruction random delay generation circuit provided in an embodiment of this application; Figure 5 This is a schematic diagram of the encryption circuit of the AES-GCM algorithm engine provided in the embodiments of this application; Figure 6 This is a schematic diagram of a two-level concurrent pipeline structure provided in an embodiment of this application; Figure 7This is a flowchart illustrating an encryption / decryption authentication method provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an encryption / decryption authentication device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0023] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0024] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of a described feature, integral, step, operation, element, and / or component, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. It should also be understood that, as used in this specification and the appended claims, the term "and / or" refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0025] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrases "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]." Furthermore, in the description of this specification and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0026] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0027] It should be understood that the sequence number of each step in this embodiment does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of this application embodiment.

[0028] In related technologies, implementing the AES-GCM algorithm generally relies on executing software code on a general-purpose processor. While this pure software implementation offers good versatility and flexibility, it faces significant bottlenecks in computational performance and energy efficiency. Because the algorithm itself involves a large number of complex iterative operations, executing general-purpose instructions sequentially consumes excessive processor clock cycles, resulting in high processing latency and low throughput, making it difficult to meet the real-time requirements of high-speed data stream encryption.

[0029] In view of this, embodiments of this application provide an encryption / decryption authentication system, method, electronic device, and computer program product. The encryption / decryption authentication system includes a processor core and a hardware accelerator: the processor core is used to execute a first custom storage instruction, wherein the first custom storage instruction encodes a first source memory address pointing to target parameters and a key, to instruct the processor core to obtain the target parameters and the key from the first source memory address and transmit the target parameters and the key to the hardware accelerator; the processor core is also used to execute a second custom storage instruction, wherein the second custom storage instruction encodes a second source memory address pointing to a data block to be processed and a target memory address pointing to a result storage area, to instruct the processor core to send a computation instruction to the hardware accelerator and send the source memory address and the target memory address to the hardware accelerator; the hardware accelerator is used to respond to the computation instruction, perform the AES-GCM algorithm on the data block to be processed read from the second source memory address according to the target parameters and the key, obtain algorithm result data and an authentication tag, and write the algorithm result data and the authentication tag to the target memory address. Therefore, by mapping the key operations of the AES-GCM algorithm to specific custom storage instructions and entrusting them to a dedicated hardware accelerator for execution, the algorithm execution latency and processor load are significantly reduced while maintaining the flexibility of processor program control, thus achieving high-efficiency encryption and decryption authentication through software and hardware collaboration.

[0030] To illustrate the technical solution of this application, specific embodiments are described below.

[0031] Figure 1 This is a schematic diagram of the architecture of an encryption / decryption authentication system provided in an embodiment of this application. Figure 1 As shown, Figure 1 As shown, the system mainly consists of a processor core, hardware accelerators, instruction RAM (IRAM), and data RAM (DRAM). The system is based on the RISC-V architecture and has undergone custom extensions to its instruction set.

[0032] The processor core can be a Central Processing Unit (CPU) core that supports the RISC-V instruction set architecture and has the ability to extend custom instructions. It is responsible for reading instruction sequences from IRAM, decoding them, and executing all operations, including custom instructions. One of its key functions is to identify and execute two types of custom memory instructions (the first custom memory instruction and the second custom memory instruction, which will be explained in detail below) specifically designed for the AES-GCM algorithm, thereby enabling efficient invocation and parameter configuration of dedicated hardware acceleration modules.

[0033] The hardware accelerator, also known as the AES-GCM algorithm coprocessor, is a dedicated computing module independent of the processor core. It connects to the processor core and memory via the system bus, receives configuration information and computational tasks from the processor core, and offloads the computationally intensive AES-GCM algorithm process, which was originally implemented in software. Internally, the hardware accelerator is not a single logical module, but rather a hardware-based design and optimized integration based on the two core stages of the AES-GCM algorithm: encryption / decryption (Countermode, CTR) and authentication (Galois Hash, GHASH).

[0034] Instruction RAM (IRAM) stores the sequence of instructions executed by the processor core, including custom instructions specific to the AES-GCM algorithm. By embedding key algorithm steps into these dedicated instructions, the total number of instructions and memory accesses required to complete an encryption / decryption authentication task can be significantly reduced.

[0035] The data memory DRAM is used to store various data required by the AES-GCM algorithm, including target parameters (e.g., initialization vector IV) and keys pointed to by the first custom storage instruction, data blocks to be processed (e.g., data packets containing additional authentication data AAD and plaintext / ciphertext) pointed to by the second custom storage instruction, and algorithm result data and authentication tags that need to be written back after the operation is completed.

[0036] The basic workflow of the aforementioned encryption / decryption authentication system is as follows: The processor core sequentially fetches the first custom memory instruction and the second custom memory instruction from the IRAM and executes them. When executing the first instruction, the processor reads the algorithm parameters and key from the specified address in DRAM (the first source memory address) and configures them to the hardware accelerator. When executing the second instruction, the processor issues a computation command to the hardware accelerator, informing it of the location of the data to be processed in DRAM (the second source memory address) and the location of the result (the target memory address). Subsequently, the hardware accelerator automatically completes all operations from data transfer and AES-GCM calculation to result write-back, thereby achieving the synergy between flexible software scheduling and efficient hardware computation.

[0037] In this embodiment of the application, the processor core is used to execute a first custom storage instruction.

[0038] It should be noted that the execution process of the first custom store instruction is crucial for completing system initialization. The encoding format of the first custom store instruction in instruction memory can follow the specification structure of storage type (S-Type) instructions in the RISC-V architecture. Its opcode and function code fields are jointly defined with specific values ​​to be recognized by the processor core as algorithm parameter loading instructions.

[0039] In the embodiments of this application, reference can be made to, as follows Figure 2 The diagram illustrates the RISC-V instruction format. The RISC-V instruction set defines several basic instruction formats, including register types (R-Type) for inter-register operations, immediate types (I-Type) for immediate operations, S-Type for store operations, and branch types (B-Type) for conditional branching. Each format has different field definitions and uses. The main reasons for choosing the S-Type instruction format as the basis for custom instructions are as follows: First, the AES-GCM algorithm involves multiple rounds of iterative computation, and its hardware accelerator requires tens or even hundreds of clock cycles to execute. It is impossible to immediately produce the final result and return it to the general-purpose register within a few cycles of instruction execution. The destination register (rd) field in R-type and I-type instruction formats is used to store immediate results, and therefore is not suitable for this application. S-type and B-type instructions do not have an rd field, and their execution does not depend on immediately writing the result back to the register, making them more suitable for triggering asynchronous hardware acceleration tasks.

[0040] Secondly, the core function of type B instructions is to execute program branches based on conditions (e.g., jumping if an equality is found). The AES-GCM operation is a deterministic data transformation, and its results (ciphertext / plaintext and authentication tags) are batch data, requiring no changes to the program's execution flow based on intermediate operation results. Therefore, the branching functionality attached to type B instructions is redundant and unnecessary.

[0041] Thirdly, the inherent semantics of S-type instructions is to store data from registers to memory. Although the custom instructions in this embodiment do not directly perform the storage operation, their core operation mode is highly similar: the processor core initiates a data transfer operation to memory or a hardware accelerator based on the address information (register indication) encoded by the instruction. Specifically, the first custom storage instruction moves data from memory (source) to the hardware accelerator (target), and the second custom storage instruction triggers the hardware accelerator to move data from memory (source) to itself, perform calculations, and then write it back to memory (target). This "source address-target operation" model is logically isomorphic to the "source register-memory address" model of S-type instructions; therefore, the S-type instruction format is the most natural and efficient choice.

[0042] Therefore, this application's embodiments abandon instruction formats with rd fields or branch functions, and explicitly select the S-type instruction format as the hardware interface specification for implementing custom AES-GCM acceleration instructions. For example... Figure 3 The S-class RISC-V instruction format diagram shown clearly illustrates its structure, which includes an opcode, a function code (funct3), two source registers (rs1, rs2), and a 12-bit immediate value (imm). This provides a framework for the coding design of custom instructions in this application.

[0043] In one embodiment, the processor core is specifically configured to: determine a first source memory address based on the source register field of a first custom memory instruction; determine the data length of the target parameters and key based on the immediate numeric field of the first custom memory instruction; and, based on the first source memory address and the data length of the target parameters and key, execute the operation of acquiring the target parameters and key and transmitting them to the hardware accelerator. Thus, by adopting an instruction format based on the RISC-V standard memory type and explicitly defining the fields used to carry address and length parameters, the processor core can efficiently and accurately parse and execute custom instructions, ensuring the standardization and reliability of the hardware and software interface.

[0044] It should be noted that during the instruction fetch and decode phase, the processor core performs the following specific operations: First, it determines the first source memory address based on the source register (rs1) field of the first custom store instruction: The processor core's decoding logic reads the rs1 field (5 bits) of the instruction, which encodes an index of a general-purpose register (numbered 0~31). The processor retrieves the stored value from the general-purpose register specified by this index, which is interpreted as the first source memory address, pointing to the starting position of the target parameters and key in data memory. Then, it determines the data length of the target parameters and key based on the immediate field of the first custom store instruction: The processor core's decoding logic simultaneously reads the 12-bit immediate value (imm[11:0]) of the instruction. This immediate value directly represents the total number of data bytes to be read continuously starting from the first source memory address, i.e., the data length of the target parameters and key. Next, based on the first source memory address and the data length of the target parameters and key, the process of acquiring the target parameters and key and transmitting them to the hardware accelerator is executed. After decoding and acquiring the address and length parameters, the processor core's execution unit or load-store unit (LSU) initiates one or more memory reads based on the first source memory address, reading a continuous stream of data totaling bytes. This data constitutes the target parameters and key. Subsequently, the processor core transmits the read data block to the corresponding configuration interface of the hardware accelerator by writing to the configuration register, completing its initialization.

[0045] The data read from the first source memory address can have a specific format: the first byte represents the expected length of the authentication tag (in bits or bytes), the next byte represents the key length (e.g., 0x10 represents 128 bits, 0x18 represents 192 bits, and 0x20 represents 256 bits), and the remaining data is the original key data itself. This formatted data block allows a single instruction to convey multiple configuration information required by the algorithm.

[0046] The 12-bit immediate value (imm) of the instruction represents the data length, which can be composed of its lower 5 bits (imm[4:0], denoted as Length_l) and higher 7 bits (imm[11:5], denoted as Length_h) during actual encoding to support a more flexible length representation. The processor core concatenates these bits to form the complete length value during decoding.

[0047] In one embodiment, the processor core further includes a random delay control unit; specifically, the processor core is configured to: before transmitting the target parameters and key to the hardware accelerator, invoke the random delay control unit to insert a random number of clock cycles of waiting. Thus, by inserting random waiting cycles generated by the random delay control unit before the processor core transmits the critical key parameters, the timing characteristics of the operation execution are disrupted, effectively increasing the difficulty of carrying out side-channel attacks through precise timing analysis.

[0048] It should be noted that, to enhance the system's ability to resist side-channel timing analysis attacks, this embodiment integrates a random delay control unit into the processor core. After reading the target parameters and key from the data memory and before transmitting this data to the hardware accelerator via the configuration bus, the processor invokes this random delay control unit. This unit may contain a pseudo-random number generator, such as a linear-feedback shift register (LFSR). See also... Figure 4 The diagram shown illustrates a custom instruction random delay generation circuit, which can employ a 4-bit LFSR based on a specific polynomial (e.g., x). 4The processor core generates a pseudo-random sequence (+ x¹+1) and maps the lower bits of the output value to a random number between 1 and 4. Based on this random number, the processor core inserts a corresponding number of no-ops (NOPs) or clock cycle waits, causing unpredictable, minute fluctuations in the execution time of the critical key loading operation with each call. This mechanism aims to disrupt the fixed correspondence between operation execution and physical time, effectively increasing the difficulty for attackers to infer key information by precisely measuring execution time. After completing the random wait, the processor core writes the read target parameters and key into the corresponding configuration register inside the hardware accelerator, completing its initialization configuration. Thus, while pursuing high performance, security considerations are deeply integrated into instruction-level hardware interaction.

[0049] In this embodiment of the application, after the initialization configuration of the algorithm parameters and the key is completed, the processor core is also used to execute a second custom storage instruction, wherein the second custom storage instruction encodes a second source memory address pointing to the data block to be processed and a target memory address pointing to the result storage area, so as to instruct the processor core to send the operation instruction to the hardware accelerator and send the source memory address and the target memory address to the hardware accelerator.

[0050] The second custom memory instruction is crucial for triggering the hardware accelerator to execute computations. Its function is to efficiently pass a description of a complete AES-GCM computation task (including data input, computation, and result output) to the hardware accelerator. The processor core executes the second custom memory instruction by sending a computation instruction (or task descriptor) to the hardware accelerator, which contains the source location of the data block to be processed and the storage location of the computation result.

[0051] In one embodiment, the processor core is further configured to: determine a second source memory address based on a first source register field of a second custom memory instruction; determine a target memory address based on a second source register field of the second custom memory instruction; determine the length of the data block to be processed based on the immediate numeric field of the second custom memory instruction; and execute an operation to send arithmetic instructions to the hardware accelerator based on the second source memory address, the target memory address, and the length of the data block to be processed. Thus, by adopting an instruction format based on the RISC-V standard memory type and explicitly defining the fields used to carry address and length parameters, the processor core can efficiently and accurately parse and execute custom instructions, ensuring the standardization and reliability of the hardware and software interface.

[0052] It should be noted that the processor core's decoding and execution process for the second custom memory instruction follows the same S-shaped format specification as the first custom memory instruction, but the parsed information is used for different purposes. During the decoding phase, the processor core first addresses the instruction based on the first source register field (rs1 field) of the second custom memory instruction. This field encodes the number of a general-purpose register, and the processor core reads the stored value from this register; this value is determined as the second source memory address for this operation. This address indicates the starting location of the original data block to be processed in data memory. Next, the processor core addresses the instruction based on the second source register field (rs2 field). Similarly, this field encodes the number of another general-purpose register, and the value read from it is determined as the target memory address. This address defines the starting location where the hardware accelerator needs to write the final result (including algorithm result data and authentication tags) back to data memory after completing the computation. Simultaneously, the processor core extracts the crucial length information of the data block to be processed from the 12-bit immediate number field (imm[11:0]) of the instruction. This length value indicates the number of bytes of valid encryption / decryption data that need to be read and processed by the hardware accelerator, starting from the second source memory address. This length information can be composed of the lower 5 bits (Length_l) and the higher 7 bits (Length_h) of an immediate value to allow for more flexible encoding.

[0053] In this embodiment, after successfully obtaining the second source memory address, the target memory address, and the length of the data block to be processed, the processor core executes the operation of sending computation instructions to the hardware accelerator. This operation does not directly move the data, but rather combines these three parameters, along with the operation type (encryption or decryption) information implied in the opcode and function code, into a complete task descriptor. Subsequently, the processor core writes this task descriptor into the instruction / command register of the hardware accelerator via the system bus or a dedicated coprocessor interface. This writing action constitutes "sending computation instructions," which explicitly informs the hardware accelerator of the complete boundaries and location of the task: where to retrieve data, how much data to process, and where to store the results.

[0054] It's important to note that the execution of the second custom memory instruction is non-blocking for the processor core. After issuing the instruction, the processor core considers it complete and can immediately continue executing the subsequent program flow. Meanwhile, the hardware accelerator begins asynchronous data transfer and computation, notifying the processor core upon completion via an interrupt mechanism. This approach significantly improves the processor core's execution efficiency. The functionality of the hardware accelerator is described below.

[0055] In this embodiment, a hardware accelerator is used to respond to computation instructions, execute the AES-GCM algorithm on the data block to be processed read from the second source memory address according to the target parameters and the key, obtain the algorithm result data and the authentication tag, and write the algorithm result data and the authentication tag into the target memory address.

[0056] Upon receiving computation instructions from the processor core, the hardware accelerator enters autonomous operation mode. Its workflow can be summarized in three main stages: data acquisition, core computation, and result write-back. First, the bus interface logic unit (or direct memory access controller) within the hardware accelerator actively initiates and controls the process of reading the entire data block from the data memory based on the second source memory address carried in the computation instructions and the length of the data block to be processed. This process requires no further intervention from the processor core. Next, the core computation engine of the hardware accelerator uses previously configured target parameters (such as initialization vectors) and keys to execute the complete AES-GCM algorithm on the read data block, generating algorithm result data (encrypted ciphertext or decrypted plaintext) and an authentication tag. Finally, the hardware accelerator again writes the computed algorithm result data and authentication tag back to the data memory through its bus interface unit, according to the target memory address specified in the computation instructions. The entire process is completed independently and in a streamlined manner by the hardware accelerator, achieving complete offloading of the computation task and thus freeing up the processing power of the processor core.

[0057] In one embodiment, the hardware accelerator further includes a key expansion unit. The key pointed to by the first custom storage instruction includes a key length identifier. The key expansion unit is used to perform an expansion operation on the key for the corresponding number of rounds based on the key length identifier. Thus, by carrying the key length identifier in the instruction and enabling the key expansion unit within the hardware accelerator to perform the corresponding expansion operation based on this identifier, the same hardware system can dynamically adapt to and support AES algorithms with different key lengths, enhancing the system's flexibility and applicability.

[0058] It's important to note that before the hardware accelerator performs core computations, its internal configurable key expansion unit begins operation. This unit is crucial for the hardware accelerator's ability to support various AES algorithm variants. When the processor core transmits the key to the hardware accelerator via the first custom store instruction, the key data includes a key length identifier. The key expansion unit first parses this identifier to determine whether the original input key is 128-bit, 192-bit, or 256-bit. Based on the determined key length, the key expansion unit then initiates the corresponding number of rounds of the key expansion algorithm. Specifically, for AES-128, 10 rounds of expansion are performed; for AES-192, 12 rounds; and for AES-256, 14 rounds. Each round of expansion strictly follows the AES standard key expansion algorithm, generating a new round key based on the key material from the previous round. All generated round keys are stored sequentially in a dedicated key memory or register file within the hardware accelerator for quick retrieval by the subsequent counter-mode encryption / decryption unit during each round of encryption / decryption. With this design, the system can flexibly and efficiently support AES algorithms with different security levels without replacing the hardware, simply by configuring different key length identifiers in the software. This significantly improves the chip's versatility and the range of applicable scenarios.

[0059] In one embodiment, the hardware accelerator includes a counter-mode encryption / decryption unit and a Galois hash authentication unit. When the AES-GCM algorithm is used for encryption, the resulting data is ciphertext; when the AES-GCM algorithm is used for decryption, the resulting data is plaintext. The counter-mode encryption / decryption unit is used to perform encryption calculations on the data block to be processed according to the target parameters and the key to obtain ciphertext data, or to perform decryption calculations on the data block to be processed to obtain plaintext data. The Galois hash authentication unit is used to perform authentication calculations on the additional authentication data portion and the ciphertext data in the data block to be processed when the AES-GCM algorithm is used for encryption, to obtain an authentication tag. The counter-mode encryption / decryption unit and the Galois hash authentication unit are configured to execute in parallel. Therefore, by setting up parallel counter-mode encryption / decryption units and Galois hash authentication units within the hardware accelerator, encryption / decryption calculations and authentication calculations can be performed synchronously, significantly improving the processing throughput of a single data block.

[0060] It's worth noting that the core computing engine of the hardware accelerator consists of two highly specialized and parallel units: a counter-mode encryption / decryption unit and a Galois hash authentication unit. This parallel hardware architecture design is key to achieving high-performance throughput.

[0061] The counter-mode encryption / decryption unit is specifically responsible for AES algorithm encryption or decryption operations. For hardware implementation details, please refer to [reference needed]. Figure 5The diagram shows the encryption circuit of the AES-GCM algorithm engine. This unit is typically implemented as a deeply optimized AES round function pipeline, capable of continuously throughput data at high clock frequencies. The counter-mode encryption / decryption unit obtains all round keys from the key expansion unit and generates an initial counter value based on the configured initialization vector. Its operation strictly follows the AES-GCM standard counter mode: using the current counter value as input, a 128-bit keystream block is generated through multiple rounds of AES encryption (using the round keys); then, this keystream block is XORed with a 128-bit input data block (plaintext during encryption, ciphertext during decryption) to produce an output data block (ciphertext during encryption, plaintext during decryption). After processing a data block, the counter increments, and the above process is repeated.

[0062] The Galois hash authentication unit is specifically responsible for generating authentication tags used to verify data integrity. The unit's input consists of two parts: first, the additional authentication data portion of the data block to be processed; and second, the ciphertext data stream generated in real-time by the counter-mode encryption / decryption unit (it should be understood that in the decryption process, the input to the GHASH calculation is also the received ciphertext stream, not the decrypted plaintext). The core of this unit is a hardware module (multH) that performs multiplication in the Galois field. Its calculation process is an iterative chain operation: starting with the initial authentication value (usually 0), it is first operated on with blocks of additional authentication data; then, for each received ciphertext block, the current intermediate authentication value is XORed with that ciphertext block, and the result is used as the multiplicand and multiplied by a fixed multiplier H (this value is obtained from the encrypted all-zero data block and pre-calculated) in the Galois field. After processing all the data, the final intermediate authentication value is XORed with a specific keystream block generated by the initial counter, thus obtaining the final authentication tag.

[0063] It should be noted that, Figure 5 The data path from the initialization vector (IV) and key input to the final generation of ciphertext and authentication tag is clearly depicted. The core of the engine lies in two parallel and cooperative computational paths: a counter-mode encryption path and a Galois hash authentication path.

[0064] In the counter-mode encryption path, an initialization vector is used to generate an initial counter value. This counter value is fed into a module labeled Ek. The Ek module is essentially a hardware unit that performs AES (Electronic Codebook, ECB) encryption, using an extended round key to fully encrypt the input 128-bit data. After encrypting the counter, Ek generates a 128-bit keystream block. This keystream block is XORed with a 128-bit plaintext block (for encryption) or ciphertext block (for decryption) to output a 128-bit ciphertext block (for encryption) or plaintext block (for decryption). After processing each data block, the counter value is incremented (usually by 1) to generate the next keystream block. This process is entirely controlled by hardware logic without software intervention, and the Ek module is typically implemented with a highly pipelined design to maintain continuous data throughput at high frequencies.

[0065] In the Galois hash authentication path, the core operational unit is a module that performs multiplication over a Galois field (GF(2^128)), labeled multH in the diagram. The multiplier H is a crucial authentication key, obtained by AES-ECB encryption of a 128-bit all-zero data block using the current key (i.e., through the same Ek module), and pre-computed and stored during initialization. The authentication computation is an iterative chained process: first, the additional authentication data AAD is decomposed into 128-bit blocks, XORed sequentially with the current intermediate authentication value (initially 0), and the result is input into the multH module and multiplied by H to update the intermediate authentication value; subsequently, for each ciphertext block generated by the encryption path (it should be understood that the input during decryption verification is also the received ciphertext block), the same "XOR-Galois field multiplication" step is repeated. After processing all data, the final intermediate authentication value is XORed with a specific keystream block encrypted by the initial counter, thus generating the authentication tag that provides integrity guarantees for the entire data block.

[0066] In one embodiment, to achieve efficient collaboration with commonly used system data bus widths (e.g., 32 bits) and further hide computational latency, this application employs a specially designed pipelined architecture for the multH multiplier. A standard 128-bit Galois field multiplication requires multiple cycles. This embodiment decomposes the multH module, enabling it to process data segments of the same width as the bus width within a single hardware cycle. For example, when the system data bus width is 32 bits, a 128-bit data block requires four bus transfers to load. Correspondingly, the multH module is designed to pipeline the complete multiplication of this 128-bit data block through four consecutive hardware clock cycles.

[0067] For example, in the first cycle, the multH module receives and processes the lowest 32 bits (D0) of the input data, performs a partial calculation of D0 × H, and temporarily stores the intermediate result. In the second cycle, it receives the next lowest 32 bits (D1) of the data, XORs the stored result with the result of D1 × (H << 32), and accumulates the result. In the third and fourth cycles, it processes D2 and D3 (the highest 32 bits) sequentially, multiplies them with the corresponding shifted H values, and XORs them. At the end of the fourth cycle, it outputs the complete multiplication result for the 128-bit data block. This design allows the multiplier's computation progress to closely match the speed at which data is loaded from memory to the accelerator via the bus, achieving overlap between computation and data transport. This eliminates idle cycles caused by waiting for complete data loading, greatly improving hardware utilization and overall efficiency.

[0068] In one embodiment, the counter-mode encryption / decryption unit and the Galois hash authentication unit are configured to execute in parallel. See, for details, as shown below. Figure 6 The schematic diagram of the two-stage concurrent pipeline structure shown is as follows: Figure 6 As shown, once the counter-mode encryption / decryption unit starts outputting the first ciphertext block, the Galois hash authentication unit can immediately begin processing that ciphertext block without waiting for the entire data block to be encrypted. This design allows the encryption / decryption and authentication stages, which are originally dependent on each other in the algorithm definition, to overlap in time at the hardware level, thereby greatly reducing the overall processing latency and improving the system throughput.

[0069] It should be noted that, Figure 6 This comprehensively demonstrates the parallel execution of the counter-mode encryption / decryption unit and the Galois hash authentication unit, as well as the internal pipeline of the multH module. For example... Figure 6 As shown, the encryption path CTR and the authentication path GHASH are performed simultaneously as two main processing stages (secondary). Once the encryption path produces the first ciphertext block, the authentication path can begin operation immediately. Simultaneously, within the authentication path, the multH module can perform pipelined computation at a finer granularity (such as the 32-bit segmentation mentioned above). Furthermore, by setting up buffer queues (First In First Out, FIFO) and scheduling logic for multiple data blocks, cross-parallel processing of multiple data blocks across these two pipeline stages can be achieved. That is, when the bus transmits data, it does not need to transmit an entire data block before transmitting the next data block, thus achieving a higher order of parallelism. When the system is configured with multiple first and second parallel computing subunits, Figure 6The pipelined structure shown can be replicated across multiple sub-units to form a large-scale parallel processing array, enabling a final throughput of n times the bus bandwidth, where n is the number of data blocks processed in parallel. For example, when n=256, the bus width is 32 bits, and the clock frequency is 100MHz, the theoretical throughput can reach 81.92Gbps.

[0070] In one embodiment, the hardware accelerator further includes a scheduling unit; the counter-mode encryption / decryption unit includes multiple first parallel computing sub-units; and the Galois hash authentication unit includes multiple second parallel computing sub-units. The scheduling unit is used to split the data block to be processed into multiple sub-data blocks and send each sub-data block to the corresponding first or second parallel computing sub-unit for processing. Thus, by splitting the data block to be processed into multiple sub-data blocks and allocating them to multiple parallel computing sub-units for processing through the scheduling unit, parallel pipelined computation of multiple data blocks is achieved, greatly improving the system's overall processing capacity and throughput for large amounts of data.

[0071] It should be noted that, to further improve data processing throughput and fully utilize hardware parallelism, deeper levels of parallelization can be extended. Specifically, the counter-mode encryption / decryption unit may not be a single logic circuit, but rather composed of multiple first parallel computing sub-units; similarly, the Galois hash authentication unit is also composed of multiple second parallel computing sub-units. The hardware accelerator also includes a scheduling unit responsible for managing and coordinating these parallel computing resources to achieve efficient pipelined processing of large data blocks. The scheduling unit operates as follows: when the hardware accelerator's bus interface unit begins reading the data block to be processed from the second source memory address, the scheduling unit intervenes. Based on a preset, hardware-implementation-dependent sub-data block size (e.g., 128 bytes or 256 bytes), the scheduling unit logically divides the entire data stream into multiple consecutive sub-data blocks. Subsequently, the scheduling unit performs its core scheduling function. Instead of waiting for one sub-data block to be completely processed before processing the next, the scheduling unit sequentially and cyclically distributes the divided sub-data blocks to idle first and second parallel computing sub-units. Specifically, a sub-data block is sent to an idle first parallel computing sub-unit for counter mode encryption / decryption operations; almost simultaneously, related parts of the sub-data block (such as ciphertext streams) or the intermediate authentication state generated by the previous sub-data block are guided by the scheduling unit to an idle second parallel computing sub-unit for Galois hash authentication calculation.

[0072] The aforementioned fine-grained scheduling allows multiple sub-data blocks to simultaneously be in different processing stages within different computational sub-units. For example, one could refer to... Figure 6While the first sub-data block is being encrypted in a first parallel computing sub-unit and its ciphertext is being authenticated by the corresponding second parallel computing sub-unit, the second sub-data block may already be being encrypted in another first parallel computing sub-unit, and the third sub-data block is being read from memory by the bus interface unit. Through the coordination of the scheduling unit and multiple parallel computing sub-units, the hardware accelerator can process data at a rate close to the theoretical limit of bus bandwidth, significantly improving the system's ability to process continuous large data streams.

[0073] In one embodiment, the hardware accelerator is specifically configured to: determine whether the length of the data block to be processed exceeds a preset single processing capacity during the execution of the AES-GCM algorithm; if the length of the data block exceeds the single processing capacity, divide the data block into multiple sequential sub-data blocks according to the single processing capacity; sequentially execute the AES-GCM algorithm on each sub-data block, and sequentially write the corresponding partial algorithm result data of each sub-data block to the target memory address, until the last sub-data block is completed, and generate an authentication tag. Thus, by enabling the hardware accelerator to automatically determine the data block size and process it in segments according to a preset capacity, it can transparently process data exceeding its single physical processing capacity, providing a unified and concise big data processing interface to upper-layer software.

[0074] It should be noted that although parallel sub-units can efficiently process data streams, hardware accelerators still have a physical upper limit to their single-processing capacity, which is typically determined by the size of their internal buffers, state machine design, or the range of parameters that can be configured at one time. To transparently support the processing of data blocks of arbitrary size, hardware accelerators have built-in automatic data block management logic.

[0075] Specifically, when the hardware accelerator begins execution, it first determines whether the length of the data block to be processed obtained from the operation instructions is greater than its internal preset single-processing capacity. The single-processing capacity is a fixed value; for example, in one embodiment, this capacity is designed to be 4KB (4096 bytes). If the length of the data block to be processed is less than or equal to the single-processing capacity, the hardware accelerator treats it as a whole and completes all calculations at once through the aforementioned parallel computing unit, generating the final algorithm result data and authentication tag. If the length of the data block to be processed is greater than the single-processing capacity, the hardware accelerator initiates a segmented processing mechanism. It first logically divides the entire data block to be processed into multiple sequential sub-data blocks according to the single-processing capacity. The size of each sub-data block is equal to the single-processing capacity, and the size of the last sub-data block may be smaller than this capacity. After the division is completed, the hardware accelerator sequentially executes the complete AES-GCM algorithm flow for each sub-data block. Here, "sequential execution" means processing according to the original order of the sub-data blocks, but the operations within each sub-data block can still be accelerated using the aforementioned parallel computing sub-unit.

[0076] During segmented processing, for the first N-1 data segments (N being the total number of segments), after completing the calculation for that segment, the hardware accelerator sequentially writes the corresponding partial algorithm result data (ciphertext or plaintext) into the corresponding location in the target memory address, while saving the intermediate authentication state generated by the calculation for that segment, but does not generate the final authentication tag. When processing the last data segment, the hardware accelerator combines the previously accumulated intermediate authentication state with the calculation result of the last data segment, performs a complete Galois hash authentication finalization calculation, thereby generating a unique and complete authentication tag for the entire data block to be processed. Finally, the algorithm result data of the last data segment and this complete authentication tag are written into the remaining location in the target memory address. This mechanism allows the software to process data far exceeding the single physical processing capacity of the hardware with only one computation instruction call, providing a simple and unified interface for upper-layer applications, and ensuring the uniqueness and correctness of the authentication tag for the entire data block.

[0077] To facilitate understanding of the above embodiments, a specific example is provided below. Please refer to Table 1 below for the custom instruction sequence encoding format: Table 1

[0078] The AES_GCM_INIT1 instruction loads the initialization data (Init Data1) for the AES-GCM algorithm, including the length of the authentication tag, the key, and its length. The Init Data1 format is shown in Table 2 below. Table 2

[0079] The storage address of Init Data1 is stored in general registers (0~31) represented by Rs1. The Length field indicates the number of bytes in Init Data1, consisting of the lower 5 bits Length_l and the higher 7 bits Length_h. When the processor core executes the AES_GCM_INIT1 instruction, after completing the instruction fetch and decode operations, it obtains the storage address and length of Init Data1 through the Rs1 and Length fields of the instruction and notifies the hardware accelerator. The hardware accelerator automatically loads the Init Data1 initialization data and automatically configures the length of the authentication tag, the length of the key, and the key.

[0080] The AES_GCM_INIT2 instruction loads the initialization data (Init Data2) for the AES-GCM algorithm, including the Initialization Vector (IV) and its length, and the length of the Additional Authentication Data (AAD). The Init Data2 format is shown in Table 3 below. Table 3

[0081] The storage address of Init Data2 is also stored in the general register (0~31) represented by Rs1; the Length field is used to indicate the number of bytes of Init Data2, and Length is also composed of the lower 5 bits Length_l and the higher 7 bits Length_h. When the processor core executes the AES_GCM_INIT2 instruction, after completing the instruction fetch and decode operations, it obtains the storage address and length of Init Data2 through the Rs1 and Length fields of the instruction, and notifies the AES-GCM coprocessor unit, which automatically loads the Init Data2 initialization data, and after loading, automatically configures the initialization vector IV and its length, as well as the length of the additional authentication data AAD.

[0082] The AES_GCM_ENC instruction encrypts IData data, which contains Additional Authentication Data (AAD) and plaintext data. The encrypted data is stored in OData, and can encrypt data blocks up to 4KB in a single operation. The IData data format is shown in Table 4 below. Table 4

[0083] The length of AAD is specified in the Init Data2 parameter of the AES_GCM_INIT2 instruction; the Length field indicates the number of bytes of plaintext, and Length is also composed of the lower 5 bits Length_l and the higher 7 bits Length_h; the storage address of IData data is stored in the general register (0~31) represented by Rs1; the storage address of OData data is stored in the general register (0~31) represented by Rs2; the OData data format is shown in Table 5 below: Table 5

[0084] When the processor core executes the AES_GCM_ENC instruction, after completing the instruction fetch and decoding operations, it obtains the storage address and length of IData through the Rs1 and Length fields of the instruction, and obtains the storage address of OData through Rs2. It then notifies the AES-GCM coprocessing unit, which automatically loads AAD and plaintext data, performs AES-GCM algorithm calculations, writes the results into OData, and sends an interrupt notification to the processor core that the task is complete.

[0085] The AES_GCM_DEC instruction decrypts IData data, which contains ciphertext and an authentication tag. The decrypted data is stored in OData, and can decrypt data blocks up to 4KB in size at a time. The IData data format is shown in Table 6 below. Table 6

[0086] The length of AAD is specified in the Init Data2 parameter of the AES_GCM_INIT2 instruction; the length of Tag is specified in the Init Data1 parameter of the AES_GCM_INIT1 instruction; the Length field indicates the number of bytes of the ciphertext, and Length is also composed of the lower 5 bits Length_l and the higher 7 bits Length_h; the storage address of IData data is stored in the general register (0~31) represented by Rs1; the storage address of OData data is stored in the general register (0~31) represented by Rs2; the OData data format is shown in Table 7 below: Table 7

[0087] When the processor core executes the AES_GCM_DEC instruction, after completing the instruction fetch and decoding operations, it obtains the storage address and length of IData through the Rs1 and Length fields of the instruction, and obtains the storage address of OData through Rs2. It then notifies the AES-GCM coprocessor unit, which automatically loads the ciphertext, AAD, and Tag data, performs AES-GCM algorithm calculations, and compares the calculated Tag with the Tag in IData. If the comparison results match, the decrypted plaintext data is written into OData; otherwise, an error message is recorded, and an interrupt is sent to notify the processor core that the task is complete.

[0088] As can be seen from the above examples, when encrypting / decrypting a 4KB data block, only three instructions need to be called: AES_GCM_INIT1, AES_GCM_INIT2, and AES_GCM_ENC / AES_GCM_DEC. When the data to be encrypted / decrypted is larger than 4KB, the data blocks can be divided into 4KB blocks. The AES_GCM_INIT1 instruction only needs to be executed once, and the AES_GCM_INIT2 and AES_GCM_ENC / AES_GCM_DEC instructions are executed again for each data block. This significantly reduces the number of instruction calls and frequent memory accesses.

[0089] The encryption / decryption authentication system disclosed in the above embodiments of this application includes a processor core and a hardware accelerator: the processor core is used to execute a first custom storage instruction, wherein the first custom storage instruction encodes a first source memory address pointing to a target parameter and a key, to instruct the processor core to obtain the target parameter and key from the first source memory address and transmit the target parameter and key to the hardware accelerator; the processor core is also used to execute a second custom storage instruction, wherein the second custom storage instruction encodes a second source memory address pointing to a data block to be processed and a target memory address pointing to a result storage area, to instruct the processor core to send an operation instruction to the hardware accelerator and send the source memory address and the target memory address to the hardware accelerator; the hardware accelerator is used to respond to the operation instruction, according to the target parameter and key, to execute the AES-GCM algorithm on the data block to be processed read from the second source memory address, to obtain algorithm result data and an authentication tag, and to write the algorithm result data and the authentication tag to the target memory address. Therefore, by mapping the key operations of the AES-GCM algorithm to specific custom storage instructions and entrusting them to a dedicated hardware accelerator for execution, the algorithm execution latency and processor load are significantly reduced while maintaining the flexibility of processor program control, thus achieving high-efficiency encryption and decryption authentication through software and hardware collaboration.

[0090] The encryption and decryption authentication system provided in this application embodiment can be widely used in various computing scenarios that require high performance, high energy efficiency, or high flexibility in data security processing. The following are examples illustrating the application scenarios of the encryption and decryption authentication system provided in this application embodiment.

[0091] 1. The Internet of Things (IoT) and edge computing field: This field is extremely sensitive to device power consumption and cost. The embodiments of this application, through customized instructions and hardware co-design, significantly improve encryption efficiency while substantially reducing system power consumption, meeting the low-power secure communication needs of devices such as smart terminals and industrial sensor nodes.

[0092] 2. High-performance computing and cloud computing: Data centers, cloud servers, and other scenarios require extremely high data encryption throughput to ensure the security of massive data transmission. The embodiments of this application, through an efficient instruction set and parallel hardware architecture, can achieve line-speed encryption processing, meeting the needs of high-speed network applications such as Transport Layer Security (TLS) / SSL (Secure Sockets Layer) offloading.

[0093] 3. Automotive electronics and industrial control: In-vehicle networks, industrial control systems, and other scenarios have stringent requirements for real-time performance, reliability, and functional safety. The deterministic execution timing and scalable hardware architecture provided in this application's embodiments can meet the reliability standards for real-time safe processing in such scenarios.

[0094] 4. In the field of network security equipment: devices such as firewalls and Virtual Private Network (VPN) gateways need to perform real-time and stable encryption processing on variable-length network data packets. The configurable processing architecture of this application embodiment can adapt to data packets of different sizes, achieve stable line-speed encryption, and avoid performance fluctuations.

[0095] 5. In the field of independently controllable chips: The open-source and scalable nature of the RISC-V instruction set provides a technical path for the independent and controllable design of chips. This application's embodiment, based on a custom instruction extension method for RISC-V, provides a key technical solution for building a high-performance, secure chip core with independent intellectual property rights.

[0096] Reference Figure 7 The diagram illustrates a flowchart of an encryption / decryption authentication method provided in an embodiment of this application. This encryption / decryption authentication method can be applied to the aforementioned display control system. Figure 7 As shown, the encryption / decryption authentication method may include the following steps: Step 701: Execute a first custom storage instruction through the processor core. The first custom storage instruction encodes a first source memory address pointing to the target parameters and key, instructing the processor core to retrieve the target parameters and key from the first source memory address and transmit the target parameters and key to the hardware accelerator.

[0097] Step 702: Execute a second custom memory instruction through the processor core. The second custom memory instruction encodes a second source memory address pointing to the data block to be processed and a target memory address pointing to the result storage area, so as to instruct the processor core to send arithmetic instructions to the hardware accelerator and send the source memory address and the target memory address to the hardware accelerator.

[0098] Step 703: Using a hardware accelerator, responding to the computation instructions, and according to the target parameters and key, execute the AES-GCM algorithm on the data block to be processed read from the second source memory address to obtain the algorithm result data and authentication tag, and write the algorithm result data and authentication tag to the target memory address.

[0099] The specific implementation process and principle of steps 701-703 above can be found in the detailed description of the above embodiments, and will not be repeated here.

[0100] The encryption / decryption authentication method disclosed in the above embodiments of this application first executes a first custom storage instruction, wherein the first custom storage instruction encodes a first source memory address pointing to the target parameters and key, so as to obtain the target parameters and key from the first source memory address; then executes a second custom storage instruction, wherein the second custom storage instruction encodes a second source memory address pointing to the data block to be processed and a target memory address pointing to the result storage area; finally, according to the target parameters and key, the AES-GCM algorithm is executed on the data block to be processed read from the second source memory address to obtain algorithm result data and authentication tag, and the algorithm result data and authentication tag are written to the target memory address. Therefore, by executing first and second custom storage instructions that respectively encode the target parameters and key at the first source memory address, the second source memory address of the data block to be processed, and the target memory address of the result storage area, the target parameters, key, and data block to be processed can be obtained accurately and quickly, and the result storage direction can be clearly defined. This avoids the redundant clock cycle consumption of complex iterative operations executed sequentially by general instructions in pure software implementation, simplifies data transmission and instruction scheduling processes, reduces data handling and invalid operation overhead, breaks through the computational performance and energy efficiency bottleneck of pure software implementation, improves the overall operation speed, throughput, and energy efficiency ratio of the AES-GCM algorithm, reduces processing latency, and meets the real-time requirements of high-speed data stream encryption.

[0101] Furthermore, in one possible implementation of this application embodiment, the aforementioned hardware accelerator includes a counter-mode encryption / decryption unit and a Galois hash authentication unit. When the AES-GCM algorithm performs encryption calculations, the algorithm result data is ciphertext data; when the AES-GCM algorithm performs decryption calculations, the algorithm result data is plaintext data. The execution of the first custom storage instruction includes: performing encryption calculations on the data block to be processed according to the target parameters and the key to obtain ciphertext data, or performing decryption calculations on the data block to be processed to obtain plaintext data. The execution of the second custom storage instruction includes: when the AES-GCM algorithm performs encryption calculations, performing authentication calculations on the additional authentication data portion and ciphertext data in the data block to be processed to obtain an authentication tag. The counter-mode encryption / decryption unit and the Galois hash authentication unit are configured to execute in parallel. Therefore, by setting parallel counter-mode encryption / decryption units and Galois hash authentication units within the hardware accelerator, encryption / decryption calculations and authentication calculations can be performed synchronously, significantly improving the processing throughput of a single data block.

[0102] Furthermore, in another possible implementation of this application embodiment, the hardware accelerator further includes a scheduling unit, the counter mode encryption / decryption unit includes multiple first parallel computing subunits, and the Galois hash authentication unit includes multiple second parallel computing subunits; the above method further includes: splitting the data block to be processed into multiple sub-data blocks through the scheduling unit, and sending each sub-data block to the corresponding first parallel computing subunit or second parallel computing subunit for processing. Thus, by splitting the data block to be processed into multiple sub-data blocks through the scheduling unit and allocating them to multiple parallel computing subunits for processing, parallel pipelined computation of multiple data blocks is achieved, greatly improving the system's overall processing capacity and throughput for large amounts of data.

[0103] Furthermore, in another possible implementation of this application embodiment, the format of the first custom storage instruction and the second custom storage instruction is a storage type instruction format based on the RISC-V instruction set architecture; the execution of the first custom storage instruction includes: determining a first source memory address based on the source register field of the first custom storage instruction; determining the data length of the target parameter and key based on the immediate numeric field of the first custom storage instruction; and performing the operation of obtaining the target parameter and key and transmitting the target parameter and key to the hardware accelerator based on the first source memory address and the data length of the target parameter and key; the execution of the second custom storage instruction includes: determining a second source memory address based on the first source register field of the second custom storage instruction; determining a target memory address based on the second source register field of the second custom storage instruction; determining the length of the data block to be processed based on the immediate numeric field of the second custom storage instruction; and performing the operation of sending an operation instruction to the hardware accelerator based on the second source memory address, the target memory address, and the length of the data block to be processed. Therefore, by adopting an instruction format based on the RISC-V standard memory type and explicitly defining the fields (such as the source register field and the immediate number field) for carrying address and length parameters, the processor core can efficiently and accurately parse and execute custom instructions, ensuring the standardization and reliability of the hardware and software interface.

[0104] Furthermore, in another possible implementation of this application embodiment, the processor core further includes a random delay control unit; the method further includes: before transmitting the target parameters and key to the hardware accelerator, the processor core calls the random delay control unit to insert a random number of clock cycle waits. Thus, by inserting random wait cycles generated by the random delay control unit before the processor core transmits the key parameters, the timing characteristics of the operation execution are disrupted, effectively increasing the difficulty of implementing side-channel attacks through precise timing analysis.

[0105] Furthermore, in another possible implementation of this application embodiment, the hardware accelerator further includes a key expansion unit, and the key pointed to by the first custom storage instruction includes a key length identifier; the method further includes: performing an expansion operation on the key corresponding to the number of rounds based on the key length identifier by the key expansion unit. Thus, by carrying the key length identifier in the instruction and having the key expansion unit within the hardware accelerator perform the corresponding expansion operation based on this identifier, the same hardware system can dynamically adapt to and support AES algorithms with different key lengths, enhancing the system's flexibility and applicability.

[0106] Furthermore, in another possible implementation of this application embodiment, based on the target parameters and key, the AES-GCM algorithm is executed on the data block to be processed read from the second source memory address to obtain algorithm result data and authentication tags, and the algorithm result data and authentication tags are written to the target memory address. This includes: during the execution of the AES-GCM algorithm, determining whether the length of the data block to be processed is greater than a preset single processing capacity; if the length of the data block to be processed is greater than the single processing capacity, dividing the data block to be processed into multiple sequential sub-data blocks according to the single processing capacity; sequentially executing the AES-GCM algorithm on each sub-data block, and sequentially writing the corresponding partial algorithm result data of each sub-data block to the target memory address, until the last sub-data block is completed, and generating an authentication tag. Thus, by enabling the hardware accelerator to automatically determine the size of the data block and process it in segments according to a preset capacity, it can transparently process data exceeding its single physical computation capacity, providing a unified and concise big data processing interface for upper-layer software.

[0107] The encryption and decryption authentication method provided in this application can be applied to the aforementioned system embodiments. For details, please refer to the description of the above system embodiments, which will not be repeated here.

[0108] See Figure 8 The diagram shows a schematic of an encryption / decryption authentication device provided in an embodiment of this application. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0109] The encryption / decryption authentication device may specifically include the following modules: The first execution module 801 is used to execute a first custom storage instruction through the processor core. The first custom storage instruction encodes a first source memory address pointing to the target parameters and key, instructing the processor core to obtain the target parameters and key from the first source memory address and transmit the target parameters and key to the hardware accelerator.

[0110] The second execution module 802 is used to execute a second custom memory instruction through the processor core. The second custom memory instruction encodes a second source memory address pointing to the data block to be processed and a target memory address pointing to the result storage area, so as to instruct the processor core to send arithmetic instructions to the hardware accelerator and send the source memory address and the target memory address to the hardware accelerator.

[0111] The third execution module 803 is used to respond to the operation instructions through the hardware accelerator, and execute the AES-GCM algorithm on the data block to be processed read from the second source memory address according to the target parameters and the key, so as to obtain the algorithm result data and the authentication tag, and write the algorithm result data and the authentication tag to the target memory address.

[0112] The encryption / decryption authentication device disclosed in the above embodiments of this application first executes a first custom storage instruction, wherein the first custom storage instruction encodes a first source memory address pointing to the target parameters and key, so as to obtain the target parameters and key from the first source memory address; then executes a second custom storage instruction, wherein the second custom storage instruction encodes a second source memory address pointing to the data block to be processed and a target memory address pointing to the result storage area; finally, according to the target parameters and key, the AES-GCM algorithm is executed on the data block to be processed read from the second source memory address to obtain algorithm result data and authentication tag, and the algorithm result data and authentication tag are written to the target memory address. Therefore, by executing first and second custom storage instructions that respectively encode the target parameters and key at the first source memory address, the second source memory address of the data block to be processed, and the target memory address of the result storage area, the target parameters, key, and data block to be processed can be obtained accurately and quickly, and the result storage direction can be clearly defined. This avoids the redundant clock cycle consumption of complex iterative operations executed sequentially by general instructions in pure software implementation, simplifies data transmission and instruction scheduling processes, reduces data handling and invalid operation overhead, breaks through the computational performance and energy efficiency bottleneck of pure software implementation, improves the overall operation speed, throughput, and energy efficiency ratio of the AES-GCM algorithm, reduces processing latency, and meets the real-time requirements of high-speed data stream encryption.

[0113] The encryption / decryption authentication device provided in this application embodiment can be applied in the foregoing method embodiments. For details, please refer to the description of the above method embodiments, which will not be repeated here.

[0114] Figure 9 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. For example... Figure 9 As shown, the electronic device 900 of this embodiment includes: at least one processor 910 ( Figure 9 The diagram shows only one processor, a memory 920, and a computer program 921 stored in the memory 920 and executable on the at least one processor 910. When the processor 910 executes the computer program 921, it implements the steps in the above-described encryption / decryption authentication method embodiments.

[0115] The electronic device 900 can be a desktop computer, laptop, handheld computer, cloud server, or other computing device. This electronic device may include, but is not limited to, a processor 910 and a memory 920. Those skilled in the art will understand that... Figure 9 This is merely an example of electronic device 900 and does not constitute a limitation on electronic device 900. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0116] The processor 910 may be a central processing unit, or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0117] In some embodiments, the memory 920 may be an internal storage unit of the electronic device 900, such as a hard disk or memory of the electronic device 900. In other embodiments, the memory 920 may be an external storage device of the electronic device 900, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 900. Furthermore, the memory 920 may include both internal and external storage units of the electronic device 900. The memory 920 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 920 can also be used to temporarily store data that has been output or will be output.

[0118] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0119] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0120] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0121] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0122] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0123] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0124] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0125] The implementation of all or part of the processes in the methods of the above embodiments can also be accomplished by a computer program product. When the computer program product is run on an electronic device, the electronic device can implement the steps in the various method embodiments described above.

[0126] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application 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 of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. An encryption / decryption authentication system, characterized in that, The encryption / decryption authentication system includes a processor core and a hardware accelerator: The processor core is configured to execute a first custom storage instruction, wherein the first custom storage instruction encodes a first source memory address pointing to a target parameter and a key, to instruct the processor core to retrieve the target parameter and the key from the first source memory address and transmit the target parameter and the key to the hardware accelerator; The processor core is further configured to execute a second custom storage instruction, wherein the second custom storage instruction encodes a second source memory address pointing to the data block to be processed and a target memory address pointing to the result storage area, so as to instruct the processor core to send a computation instruction to the hardware accelerator and send the source memory address and the target memory address to the hardware accelerator. The hardware accelerator is used to respond to the operation instruction, execute the AES-GCM algorithm on the data block to be processed read from the second source memory address according to the target parameters and the key, obtain algorithm result data and authentication tag, and write the algorithm result data and the authentication tag into the target memory address.

2. The system according to claim 1, characterized in that, The hardware accelerator includes a counter mode encryption / decryption unit and a Galois hash authentication unit. When the AES-GCM algorithm is used for encryption calculation, the algorithm result data is ciphertext data; when the AES-GCM algorithm is used for decryption calculation, the algorithm result data is plaintext data. The counter mode encryption / decryption unit is used to perform encryption calculations on the data block to be processed to obtain the ciphertext data according to the target parameters and the key, or to perform decryption calculations on the data block to be processed to obtain the plaintext data. The Galois hash authentication unit is used to perform authentication calculations on the additional authentication data portion and the ciphertext data in the data block to be processed, when the AES-GCM algorithm is used for encryption calculation, to obtain the authentication tag; wherein, the counter mode encryption / decryption unit and the Galois hash authentication unit are configured to execute in parallel.

3. The system as described in claim 2, characterized in that, The hardware accelerator also includes a scheduling unit, the counter mode encryption / decryption unit includes multiple first parallel computing subunits, and the Galois hash authentication unit includes multiple second parallel computing subunits. The scheduling unit is used to split the data block to be processed into multiple sub-data blocks, and send each sub-data block to the corresponding first parallel computing sub-unit or second parallel computing sub-unit for processing.

4. The system according to claim 1, characterized in that, The first custom storage instruction and the second custom storage instruction are in the storage type instruction format based on the RISC-V instruction set architecture; The processor core is specifically configured to: determine the first source memory address based on the source register field of the first custom storage instruction; determine the data length of the target parameter and the key based on the immediate number field of the first custom storage instruction; and, based on the first source memory address and the data length of the target parameter and the key, perform the operation of acquiring the target parameter and the key and transmitting the target parameter and the key to the hardware accelerator. The processor core is further configured to: determine the second source memory address based on the first source register field of the second custom storage instruction; determine the target memory address based on the second source register field of the second custom storage instruction; and determine the length of the data block to be processed based on the immediate number field of the second custom storage instruction. Based on the second source memory address, the target memory address, and the length of the data block to be processed, an operation is performed to send computation instructions to the hardware accelerator.

5. The system according to claim 1, characterized in that, The processor core further includes a random delay control unit; the processor core is specifically used for: Before transmitting the target parameters and the key to the hardware accelerator, the random delay control unit is invoked to insert a random number of clock cycles to wait.

6. The system according to claim 1, characterized in that, The hardware accelerator also includes a key expansion unit, wherein the key pointed to by the first custom storage instruction includes a key length identifier. The key expansion unit is used to perform an expansion operation on the key for the corresponding number of rounds according to the key length identifier.

7. The system according to claim 1, characterized in that, The hardware accelerator is specifically used for: During the execution of the AES-GCM algorithm, it is determined whether the length of the data block to be processed is greater than the preset single processing capacity; If the length of the data block to be processed is greater than the single processing capacity, the data block to be processed is divided into multiple sequential sub-data blocks according to the single processing capacity. The AES-GCM algorithm is executed sequentially on each of the sub-data blocks, and the partial algorithm result data corresponding to each sub-data block is sequentially written to the target memory address until the last sub-data block is completed, at which point the authentication tag is generated.

8. An encryption / decryption authentication method, characterized in that, Applied to the encryption / decryption authentication system as described in any one of claims 1-7, the method includes: The processor core executes a first custom storage instruction, wherein the first custom storage instruction encodes a first source memory address pointing to the target parameters and the key, to instruct the processor core to retrieve the target parameters and the key from the first source memory address and transmit the target parameters and the key to the hardware accelerator; The processor core executes a second custom memory instruction, wherein the second custom memory instruction encodes a second source memory address pointing to the data block to be processed and a target memory address pointing to the result storage area, so as to instruct the processor core to send a computation instruction to the hardware accelerator and send the source memory address and the target memory address to the hardware accelerator. The hardware accelerator responds to the computation instructions and executes the AES-GCM algorithm on the data block to be processed read from the second source memory address according to the target parameters and the key, to obtain algorithm result data and authentication tag, and writes the algorithm result data and the authentication tag into the target memory address.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the method as described in claim 8.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when run on an electronic device, causes the electronic device to perform the method as described in claim 8.

Images