Safe starting system and method for RISC-V and FPGA system-on-chip

Abstract

The invention relates to a secure starting system and method for an RISC-V and FPGA system-on-chip, and the system comprises the steps: a starting management module constructed based on RISC-V resources controls a secure starting module to read encrypted firmware from a firmware storage module, and carries out the security verification operation; receiving the first feedback information and controlling the secure startup module to perform firmware decryption operation based on the first feedback information; receiving second feedback information, and running the decrypted firmware in the firmware storage module based on the second feedback information; the security startup module constructed based on the FPGA resources reads encrypted firmware from the firmware storage module under the control of the startup management module to perform security verification operation, and sends first feedback information to the startup management module after the security verification operation is completed; and the firmware decryption module is used for carrying out firmware decryption operation under the control of the starting management module, sending second feedback information to the starting management module after the firmware decryption operation is completed, and writing the decrypted firmware into the firmware storage module. Therefore, the RISC-V can be used for safe starting control, the FPGA resources are used for safe starting, and the safe starting speed is increased.

Description

TECHNICAL FIELD

[0001] The present application relates to a secure boot technology, in particular to a secure boot system and method of RISC-V and FPGA system-on-chip. BACKGROUND

[0002] With the rapid development of embedded systems, Internet of Things, industrial control and intelligent terminals, the requirements for system security, reliability and high performance are increasing, which promotes the evolution of SoC (system-on-chip) platform to heterogeneous integration. Under this background, as a key link from power-on to reliable execution of user firmware, secure boot bears the core responsibility of protecting the initial integrity and reliability of the system.

[0003] In related technologies, the secure boot scheme usually relies on the general CPU in the SoC to perform verification and decryption operations.

[0004] However, this way not only occupies valuable central processor resources, but also has performance bottlenecks when processing large-capacity firmware or high-security level algorithms, resulting in increased startup delay, which is difficult to meet the application scenarios with high requirements for startup speed and real-time performance. SUMMARY

[0005] The embodiments of the present application provide a secure boot system and method of RISC-V and FPGA system-on-chip, which can use RISC-V for secure boot control and use FPGA resources for secure boot, thereby improving the speed of secure boot.

[0006] The embodiments of the present application provide a secure boot system of RISC-V and FPGA system-on-chip, comprising: a firmware storage module, a boot management module constructed based on RISC-V resources, and a secure boot module constructed based on FPGA resources. The boot management module is configured to control the secure boot module to read encrypted firmware from the firmware storage module and perform a security check operation on the read encrypted firmware; receive first feedback information sent from the secure boot module after completing the security check operation, control the secure boot module to perform a firmware decryption operation based on the obtained first feedback information; receive second feedback information sent from the secure boot module after completing the firmware decryption operation, and run the decrypted firmware in the firmware storage module based on the obtained second feedback information. The secure boot module is configured to read the encrypted firmware from the firmware storage module under the control of the boot management module, perform the secure verification operation on the read encrypted firmware, and send first feedback information to the boot management module after the secure verification operation is completed; perform a firmware decryption operation under the control of the boot management module, and send second feedback information to the boot management module after the firmware decryption operation is completed, and write the decrypted firmware to the firmware storage module.

[0007] The embodiments of the present application also provide a secure boot method of a RISC-V and FPGA system-level chip, applied to the secure boot system of the RISC-V and FPGA system-level chip as described above, and the method comprises the following steps: The boot management module controls the secure boot module to read the encrypted firmware from the firmware storage module and perform a secure verification operation on the read encrypted firmware. The secure boot module is configured to read the encrypted firmware from the firmware storage module under the control of the boot management module, perform the secure verification operation on the read encrypted firmware, and send first feedback information to the boot management module after the secure verification operation is completed. The boot management module receives the first feedback information sent by the secure boot module after the secure verification operation is completed, controls the secure boot module to perform a firmware decryption operation based on the obtained first feedback information. The secure boot module performs a firmware decryption operation under the control of the boot management module, and sends second feedback information to the boot management module after the firmware decryption operation is completed, and transmits the decrypted firmware to the firmware storage module. The boot management module receives the second feedback information sent by the secure boot module after the firmware decryption operation is completed, and runs the decrypted firmware in the firmware storage module based on the obtained second feedback information.

[0008] The RISC-V and FPGA system-level chip secure starting system and method provided by the embodiment of the application, the starting management module based on the RISC-V resource construction controls the secure starting module to read the encrypted firmware from the firmware storage module, and performs a security check operation on the read encrypted firmware; receive the first feedback information sent by the secure starting module after completing the security check operation, control the secure starting module to perform a firmware decryption operation based on the obtained first feedback information; receive the second feedback information sent by the secure starting module after completing the firmware decryption operation, and run the decrypted firmware in the firmware storage module based on the obtained second feedback information; the secure starting module based on the FPGA resource construction reads the encrypted firmware from the firmware storage module under the control of the starting management module, performs a security check operation on the read encrypted firmware, and sends the first feedback information to the starting management module after the security check operation is completed; perform a firmware decryption operation under the control of the starting management module, and send the second feedback information to the starting management module after the firmware decryption operation is completed, and write the decrypted firmware to the firmware storage module; the secure starting module is used for reading the encrypted firmware from the firmware storage module under the control of the starting management module, performing a security check operation on the read encrypted firmware, and sending the first feedback information to the starting management module after the security check operation is completed; perform a firmware decryption operation under the control of the starting management module, and send the second feedback information to the starting management module after the firmware decryption operation is completed, and write the decrypted firmware to the firmware storage module, so that the RISC-V can be used for secure starting control, and the FPGA resource can be used for secure starting, and the speed of secure starting is improved.

[0009] Other features and advantages of the present application will be set forth in the following description, and in part will become apparent to those skilled in the art from the description, or can be learned by practice of the present application. Other advantages of the present application can be realized and obtained by the embodiments described in the specification and the drawings. BRIEF DESCRIPTION OF DRAWINGS

[0010] The accompanying drawings are included to provide an understanding of the present application, and constitute a part of the specification, together with the embodiments of the present application, for explaining the technical scheme of the present application, and do not constitute a limitation on the technical scheme of the present application.

[0011] Figure 1 The structure schematic diagram of a RISC-V and FPGA system-level chip secure starting system according to an embodiment of the application; Figure 2 The structure schematic diagram of another RISC-V and FPGA system-level chip secure starting system according to an embodiment of the application; Figure 3 The schematic diagram of a secure starting process according to an embodiment of the application; Figure 4A structural schematic diagram of a secure start module according to an embodiment of the present application; Figure 5 A flowchart of an RSA signature verification module according to an embodiment of the present application; Figure 6 A flowchart of a secure start method of a RISC-V and FPGA system-on-chip according to an embodiment of the present application. DETAILED DESCRIPTION

[0012] The present application describes a plurality of embodiments, but the description is exemplary rather than limiting, and it will be apparent to those of ordinary skill in the art that there can be many more embodiments and implementations within the scope of the embodiments described in the present application. Although many possible combinations of features are shown in the drawings and discussed in the specification, many other combinations of the disclosed features are possible. Unless specifically intended otherwise, any feature or element of any embodiment can be used with any other feature or element of any other embodiment, or in combination with any other feature or element of any other embodiment, or in the place of any other feature or element of any other embodiment.

[0013] The present application includes and contemplates combinations of features and elements known to those of ordinary skill in the art. The embodiments, features and elements disclosed in the present application can also be combined with any conventional features or elements to form unique inventive solutions. Any feature or element of any embodiment can also be combined with features or elements from other inventive solutions to form another unique inventive solution. Therefore, it should be understood that any feature shown and / or discussed in the present application can be implemented alone or in any appropriate combination. Accordingly, the embodiments are not to be restricted, except as by the appended claims and their equivalents. Furthermore, various modifications and changes can be made within the scope of the appended claims.

[0014] Furthermore, in describing representative embodiments, the specification can have presented the method and / or process as a particular sequence of steps. However, to the extent that the method or process depends on more than one step, the method or process should not be limited to the particular sequence of steps described. Other sequences of steps can be possible, and are within the scope of the embodiments. Therefore, the particular order in which the steps are presented in the specification is not an limitation on the embodiments. Moreover, the specification can present the steps of the method and / or process in a particular order, but the steps can be performed in any order that is practicable, as will be understood by those of ordinary skill in the art. The claims should not be limited to the steps in the order shown in the specification.

[0015] The embodiments of the present disclosure provide a secure start system of a RISC-V and FPGA system-on-chip, as shown in Figure 1As shown, it comprises: a firmware storage module 10, a startup management module 11 based on RISC-V resource construction, and a secure startup module 12 based on FPGA resource construction. The startup management module 11 is configured to control the secure startup module 12 to read encrypted firmware from the firmware storage module 10 and perform a security check operation on the read encrypted firmware; receive first feedback information sent by the secure startup module 12 after the security check operation is completed, control the secure startup module 12 to perform a firmware decryption operation based on the obtained first feedback information; receive second feedback information sent by the secure startup module 12 after the firmware decryption operation is completed, and run the decrypted firmware in the firmware storage module 10 based on the obtained second feedback information. The secure startup module 12 is configured to read the encrypted firmware from the firmware storage module 10 under the control of the startup management module 11, perform the security check operation on the read encrypted firmware, and send first feedback information to the startup management module 11 after the security check operation is completed; perform a firmware decryption operation under the control of the startup management module 11, and send second feedback information to the startup management module 11 after the firmware decryption operation is completed, and write the decrypted firmware to the firmware storage module 10.

[0016] The startup management module is responsible for the timing control, state management, resource scheduling and process arrangement of the whole system startup process, is the "control center" of the startup process, is responsible for deciding the loading order of the firmware, and coordinating the timing of calling the security verification module. Its technical basis is RISC-V architecture, which means that this module is implemented by a programmable processor core, can run complex control logic (such as startup strategy written in C language), has good flexibility and computing power, is suitable for processing complex startup strategies and efficiently communicating with other system components.

[0017] The secure startup module is responsible for verifying the integrity and authenticity of the startup code (such as Bootloader, operating system image), and is the "root of trust" of system security. Usually, through cryptographic means, only authorized and unaltered code can be executed. Its technical basis is FPGA (field programmable gate array), which is used to implement a hardwareized and highly customized security engine. This design has the following advantages: high performance - hardware circuit performs encryption and decryption operations much faster than software; high security - critical algorithms and keys can be fixed in hardware, effectively resisting software attacks such as memory dump; reconfigurability - supports updating security logic without changing physical chips, facilitating the response to new security threats.

[0018] The first feedback information is the information sent by the secure boot module to the boot management module after completing the security verification operation. Therefore, the first feedback information can reflect the execution status of the security verification operation. The boot management module then controls the secure boot module to perform firmware decryption operation based on the first feedback information. The second feedback information is the information sent by the secure boot module to the boot management module after completing the firmware decryption operation. Therefore, the second feedback information can reflect the decryption status of the encrypted firmware. The boot management module then runs the decrypted firmware in the firmware storage module based on the second feedback information.

[0019] The secure boot system and method for RISC-V and FPGA system-on-a-chip provided in this application embodiment control a secure boot module to read encrypted firmware from a firmware storage module and perform security verification on the read encrypted firmware using a boot management module built on RISC-V resources. The system receives first feedback information sent by the secure boot module after completing the security verification operation, and controls the secure boot module to perform firmware decryption based on the obtained first feedback information. It also receives second feedback information sent by the secure boot module after completing the firmware decryption operation, and runs the decrypted firmware in the firmware storage module based on the obtained second feedback information. The secure boot module, built on FPGA resources, reads encrypted firmware from the firmware storage module under the control of the boot management module, performs security verification on the read encrypted firmware, and performs security verification operations within the secure verification process. After completion, the system sends a first feedback message to the boot management module; under the control of the boot management module, it performs firmware decryption and sends a second feedback message to the boot management module after the firmware decryption is completed, and writes the decrypted firmware to the firmware storage module; the secure boot module, under the control of the boot management module, reads encrypted firmware from the firmware storage module, performs security verification on the read encrypted firmware, and sends a first feedback message to the boot management module after the security verification is completed; under the control of the boot management module, it performs firmware decryption and sends a second feedback message to the boot management module after the firmware decryption is completed, and writes the decrypted firmware to the firmware storage module. Therefore, it can use RISC-V for secure boot control and FPGA resources for secure boot, improving the speed of secure boot.

[0020] In one exemplary instance, such as Figure 2 As shown, the secure boot module 12 includes: a DMA engine 120 and an integrity verification unit 121; the security verification operation includes: an integrity verification operation; when the security verification operation is the integrity verification operation, the boot management module controls the secure boot module to perform a security verification operation on the read encrypted firmware, including: The start management module 11 sends a security check instruction to the DMA engine; wherein the security check instruction carries the storage information of the encrypted firmware in the firmware storage module 10; The secure start module reads the encrypted firmware from the firmware storage module under the control of the start management module, and performs the security check operation on the read encrypted firmware, including: The DMA engine 120 is configured to read the encrypted firmware from the firmware storage module 10 according to the storage information in the security check instruction and transmit the encrypted firmware to the integrity check unit 121. The integrity check unit 121 is configured to perform integrity check on the encrypted firmware to obtain an integrity check result.

[0021] The purpose of integrity check is to ensure that the data has not been tampered with, usually by generating a digest through a hash algorithm (such as SHA-256) and verifying it with a digital signature or HMAC.

[0022] In an exemplary instance, as shown in Figure 2 The secure start module further includes a key management unit 133 and a decryption unit 137; the start management module controls the secure start module to perform firmware decryption operation based on the obtained first feedback information, including: When the first feedback information indicates that the integrity check result is passed, the start management module 11 sends a decryption instruction to the DMA engine 130; The secure start module performs firmware decryption operation under the control of the start management module, including: The DMA engine 130 is configured to transmit the encrypted firmware to the decryption unit 134 according to the decryption instruction. The decryption unit 134 is configured to obtain a first key from the key management unit 133 and decrypt the encrypted firmware using the obtained first key to obtain decrypted firmware. The secure start module writes the decrypted firmware to the firmware storage module, including: The DMA engine 130 writes the decrypted firmware in the decryption unit 134 to the firmware storage module.

[0023] DMA usually supports burst transfer, which can transport large blocks of data at a rate close to the bus bandwidth, and is particularly suitable for transferring large firmware images. As a "data carrier", the DMA engine reads encrypted firmware data from the memory and directly pushes it to the input port of the decryption unit through the system bus. The entire process does not need to pass through the main memory or CPU cache.

[0024] The encryption firmware can use an asymmetric encryption algorithm to realize data confidentiality protection. Specifically, the firmware is encrypted by a public key in a non-symmetric key pair, and the decryption unit decrypts by using a corresponding private key. Since the private key is highly sensitive, it needs to be securely stored and accessed by the key management unit to prevent leakage. In this mechanism, the key provided by the key management unit for decryption operation during the startup process is the "first key", which is essentially the private key in the non-symmetric key pair.

[0025] In an exemplary instance, the integrity checking unit includes a hash sub-unit and a signature verification sub-unit, the encrypted firmware includes encrypted firmware content and a firmware header, the firmware header includes a firmware signature generated based on the encrypted firmware content; The integrity checking unit performs integrity checking on the encrypted firmware to obtain an integrity checking result, including: The hash sub-unit is configured to perform a hash operation on the encrypted firmware content to obtain a first hash value; The signature verification sub-unit is configured to obtain a second key from the key management unit, decrypt the firmware signature using the obtained second key to obtain a second hash value, and compare the second hash value with the first hash value to obtain the integrity checking result.

[0026] In asymmetric encryption, the content encrypted by the private key can be decrypted by the corresponding public key (for signature verification). If the two hash values are the same, it means that the firmware has not been modified and the integrity is good. If they are different, it means that the firmware has been tampered with, damaged, or the signature is invalid.

[0027] In an exemplary instance, as shown in Figure 2 The secure startup module further includes a control state machine 122. The startup management module is further configured to send an initialization instruction to the secure startup module. The control state machine is configured to initialize each unit in the secure startup module when detecting the initialization instruction. The secure startup module sends first feedback information to the startup management module after the security checking operation is completed, including: The control state machine monitors whether the security checking operation is completed, generates the first feedback information according to the integrity checking result after the security checking operation is completed, and sends it to the startup management module. The secure startup module sends second feedback information to the startup management module after the firmware decryption operation is completed, including: The control state machine monitors whether the firmware decryption operation is completed, generates the second feedback information according to the firmware decryption result after the firmware decryption operation is completed, and sends it to the startup management module.

[0028] The control state machine generally refers to a finite state machine (FSM), which is a kind of digital logic circuit, acting as the "commander" of the secure boot module, and it does not perform specific data processing, but coordinates and schedules the runtime sequence and state transition of each sub-component in the module.

[0029] In an exemplary instance, the encrypted firmware content includes a plurality of encrypted firmware sub-contents, and the firmware signature includes a respective firmware signature corresponding to each of the encrypted firmware sub-contents. The hash sub-unit performs a hash operation on the encrypted firmware content to obtain a first hash value, including: The hash sub-unit sequentially performs a hash operation on each of the encrypted firmware sub-contents to obtain a respective first hash value corresponding to each of the encrypted firmware sub-contents. The signature verification sub-unit decrypts the firmware signature using the obtained second key to obtain a second hash value, and compares the second hash value with the first hash value, including: The signature verification sub-unit decrypts the firmware signature corresponding to each of the encrypted firmware sub-contents using the obtained second key to obtain a second hash value corresponding to each of the encrypted firmware sub-contents, and compares the first hash value corresponding to each of the encrypted firmware sub-contents with the second hash value corresponding thereto.

[0030] In an exemplary instance, the decrypted firmware includes a plurality of decrypted sub-firmwares corresponding to the plurality of encrypted firmware sub-contents. The DMA engine reads the encrypted firmware from the firmware storage module according to the storage information in the security check instruction, including: The DMA engine sequentially reads the plurality of encrypted firmware sub-contents and the corresponding firmware signatures from the firmware storage module according to the storage information in the security check instruction. The DMA engine transmits the decrypted firmware in the decryption unit to the firmware storage module, including: The DMA engine sequentially writes the plurality of decrypted sub-firmwares in the decryption unit to the firmware storage module. The reading of the plurality of encrypted firmware sub-contents and the corresponding firmware signatures and the writing of the plurality of decrypted sub-firmwares are performed in a preset manner, and the preset manner includes a double buffering manner and an AXI-Stream handshake manner.

[0031] Double buffering is a commonly used technique, mainly used to reduce latency during data transfer, especially when high latency operations such as disk I / O or network communication are involved. The basic idea is to use two separate buffers: one buffer is used to read / receive data: while one buffer is being processed by the processor or hardware accelerator to decrypt firmware content, the other buffer can simultaneously prepare the next segment of data to be processed. The other buffer is used to process / send data: once the data processing of the current buffer is complete, the system switches to the other buffer that has already been prepared to continue processing, while the original buffer begins to prepare new data.

[0032] This approach allows data loading and processing to be done in parallel, significantly improving overall efficiency and reducing the pause caused by waiting for data loading.

[0033] AXI-Stream handshake AXI-Stream is part of the AMBA protocol, designed specifically for high-performance streaming data transfer. It does not contain an address channel, focusing on efficient data streaming. AXI-Stream handshake refers to the process of how the sender (Master) and receiver (Slave) synchronize data transmission: TVALID signal: driven by the sender, indicating that the current data is valid and ready to be received.

[0034] TREADY signal: driven by the receiver, indicating that the receiver is ready to accept data.

[0035] When the TVALID and TREADY signals are both high, a valid data transfer occurs.

[0036] Through this handshake mechanism, AXI-Stream can ensure that data is only transmitted when both the sender and receiver are ready, providing a reliable method to manage high-speed data stream transmission. This method is very suitable for applications that require real-time processing of large amounts of continuous data, such as video streaming, audio streaming, or the firmware decryption and verification process in this example.

[0037] In an exemplary instance, the encrypted firmware includes: encrypted firmware content and a firmware header, the firmware header includes: a magic number, a version number; The boot management module controls the secure boot module to read encrypted firmware from the firmware storage module, including: The boot management module acquires the firmware header of the encrypted firmware from the firmware storage module according to the preset address information, and verifies whether the magic number and version number therein are correct, in the case that the verification is passed and the secure boot marker is carried in the firmware header, controls the secure boot module to read encrypted firmware from the firmware storage module.

[0038] The encrypted firmware includes: encrypted firmware content and a firmware header, the firmware header includes: a magic number, a version number; The boot management module controls the secure boot module to read encrypted firmware from the firmware storage module, including: The boot management module acquires the firmware header of the encrypted firmware from the firmware storage module according to preset address information, and verifies whether the magic number and the version number therein are correct, in the case that the verification is passed and the secure boot flag is carried in the firmware header, controls the secure boot module to read encrypted firmware from the firmware storage module.

[0039] In the related art, in an ARM+FPGA platform, secure boot usually depends on fixed hardware security modules and a closed key management scheme, and the implementation is relatively mature but lacks flexibility.

[0040] For a RISC-V-based heterogeneous design, some open source projects have preliminarily implemented a secure boot process, but the following deficiencies exist: 1. Low integration of security modules The security module is separated from the main system, and lacks a mechanism for cooperative work with a multi-core system.

[0041] 2. Inflexible key management Key storage is mostly implemented by a fixed non-volatile storage scheme (such as eFuse), which is difficult to realize dynamic key update in some applications.

[0042] 3. Incomplete boot process The firmware loading, signature verification, and decryption process cannot be closely linked with the main system startup, and process interruption or delay may occur.

[0043] 4. Insufficient hardware acceleration Pure software is used to implement secure boot, which results in slow encryption and decryption process and increases system startup delay.

[0044] Embodiments of the present application provide a secure boot system of a RISC-V and FPGA system-level chip, which proposes a secure boot design integrated with hardware acceleration for a multi-core RISC-V and FPGA SoC platform, and the core idea is to complete firmware reading, signature verification, decryption, and secure transmission through Bootloader and a secure boot module, so as to ensure that the finally loaded and run firmware has passed integrity and credibility verification.

[0045] The overall architecture of the secure boot system includes a RISC-V side (PS) and an FPGA side (PL). The RISC-V side (PS) can include a multi-core RISC-V core responsible for executing application firmware after system boot. The FPGA side (PL) internally integrates a secure boot module, a DDR controller, etc., which can be flexibly customized. The interconnection network is responsible for data transmission and control signal transmission between PS and PL and between internal modules. The secure boot module internally integrates an AES accelerator, a SHA3 / hash module, an RSA signature verification module, a DMA engine, and a key management unit, which communicate with the PS through an AXI interface. The Bootloader is responsible for system initialization, firmware reading, and security marker judgment, and calls the secure boot module to complete firmware signature verification and decryption.

[0046] For the RISC-V side (PS), the Bootloader program is responsible for preliminary system initialization, firmware reading, and security marker detection. Only after detecting the security marker, the secure boot module is called. After booting, only the firmware that passes the secure boot verification will be loaded and executed, ensuring that the code running when the RISC-V core starts is securely authenticated.

[0047] For the FPGA side (PL), the secure boot module is implemented as a soft IP inside the PL. Its internal acceleration units work together to complete firmware hash calculation, signature verification, and decryption. The secure boot module in the PL communicates with the PS in real time through the AXI Slave interface, ensuring strict coordination between the two parts during the secure boot process. After successful system security boot, the secure boot module notifies the PS through a status signal, allowing the RISC-V core to jump to the secure firmware entry loaded in the DDR.

[0048] The secure boot process of the secure boot system of the RISC-V and FPGA system-level chip provided by the embodiments of the present application can be as shown in Figure 3 The whole process of the system from power-on, reset, Bootloader boot, firmware reading, to security marker detection, then entering the secure boot module for data hash, signature verification, AES decryption, and finally moving to the DDR memory through DMA and starting the system is shown. If the firmware does not have a security marker, it directly enters the normal boot process; if it has a security marker, it calls the security module for verification. The secure boot process specifically includes: 1. Power-on initialization and hardware configuration 1) Power-on and reset After the system is powered on, the global reset signal is first triggered to ensure that the PS (processor subsystem) and PL (programmable logic subsystem) enter the initial state at the same time. The FPGA side first loads the configuration file (bitstream) to complete the initialization of the internal logic of the PL, including the secure boot module, DDR controller, clock and reset generation unit, and AXI interconnection network configuration.

[0049] 2) Clock and reset synchronization Using internal PLL and frequency divider, each module obtains a stable clock signal. The reset synchronizer (using a double-edge synchronizer) ensures that the reset signals between the clock domains of PS and PL are consistent, avoiding metastable state phenomenon.

[0050] 2, Bootloader startup and firmware reading 1) Bootloader startup After the global reset is released, the Bootloader program is executed by default by core 0 of the RISC-V system (single-core startup), and the remaining cores enter a low-power sleep state. Bootloader is responsible for system basic initialization (such as peripheral configuration, memory detection) and preprocessing work before firmware loading.

[0051] 2) Firmware reading and security marker detection Bootloader reads the firmware stored in the external Flash through the QSPI or SPI Nor Flash interface. The firmware data structure contains security marker fields, firmware header information, digital signature, and encrypted data, etc. Bootloader parses the firmware header information and checks the security boot marker (such as fixed magic number or identification bit) to determine whether to enter the security boot process.

[0052] 3, Security boot module intervention 1) Firmware data transmission When the firmware is detected with a security marker, Bootloader sends the firmware data block (which can be segmented and transmitted according to fixed block size) into the security boot module through the AXI interface and the pre-configured DMA engine. DMA implements high-speed data transfer between PS and PL, and guarantees stable data transmission through FIFO buffer.

[0053] 2) State feedback and flow control The secure boot module feeds back the current processing state (such as "data receiving", "hash calculation completed", "signature verification success" or "error" and the like) to the Bootloader through the AXI Slave interface, and the Bootloader decides the next operation according to the feedback. Only when all the security verification processes are successfully completed, the Bootloader jumps to the decrypted firmware entry in the DDR memory to start the system formal operation.

[0054] 4. Multi-core secure boot coordination 1) Single-core master boot In the boot process, only core 0 executes the Bootloader and the security boot process to avoid resource competition and security process confusion caused by multi-core simultaneous operation.

[0055] 2) Security state broadcast After the security verification is successful, the secure boot module broadcasts the boot state to other cores in the sleep state through the AXI bus to wake up uniformly and ensure the consistency of the secure boot of the whole system.

[0056] 3) Secure boot module implementation The secure boot module is integrated in the FPGA side (PL) and implemented as a soft core IP, mainly including an AES decryption accelerator, a SHA3 / hash module, an RSA signature verification module, a DMA engine, a key management unit, an AXI Slave interface and a control unit and the like.

[0057] The internal function structure diagram of the secure boot module can be as shown in Figure 4 which describes the functions and connection relationships of the internal sub-modules of the secure boot module.

[0058] Among them, the AES accelerator uses the AES-GCM-256 algorithm to decrypt the firmware data and generates an authentication tag at the same time; the SHA3 / hash module calculates the hash of the firmware data and outputs a fixed-length hash value; the RSA signature verification module uses the RSA-4096 algorithm to verify the digital signature to ensure the source and integrity of the firmware; the DMA engine realizes data transfer, is responsible for transferring the firmware data from the external Flash to the secure boot module through the AXI interface, and transfers the decrypted and verified data to the DDR; the key management unit uses eFuse or similar secure storage to protect the key and provides the necessary security key to the AES and RSA modules; the AXI Slave interface module is used for communication with the PS side Bootloader to realize command transmission, state feedback and data interaction.

[0059] 1. The related content of the AES accelerator is as follows: 1) Algorithm and implementation AES-GCM-256 encryption algorithm is adopted to support packet encryption and data integrity authentication (Authentication Tag generation). The pipeline architecture is used internally, and parallel processing technology is used in each AES encryption round to significantly improve data throughput. The entire encryption and decryption process is controlled by a state machine to ensure that firmware data is processed in an orderly manner in blocks. After each data block is decrypted, a GCM authentication tag (Authentication Tag) is automatically generated for subsequent integrity verification.

[0060] 2) Internal interface Input: Receive encrypted firmware data stream from DMA controller.

[0061] Output: Write decrypted plaintext data to internal FIFO buffer, read by DMA engine and transmitted to DDR memory.

[0062] Key management: Obtain AES key and initial vector (IV) through secure key management unit to ensure secure distribution of keys.

[0063] Features: Hardware-level acceleration + authentication capability, suitable for firmware decryption scenarios with high security and high performance requirements.

[0064] 2. Related content of SHA3 / Hash module is as follows: 1) Algorithm and implementation Support SHA384 or SHA3 hash algorithm to calculate the digest value of firmware data and ensure firmware integrity. Implement complete hash flow: message blocking, padding, compression function iteration, all implemented through hardware pipeline to improve calculation efficiency. Output a fixed length hash value (such as SHA384 output 48 bytes) as the basis for subsequent digital signature verification.

[0065] 2) Internal interface Data input: Can directly receive raw firmware data stream, supporting parallel processing or serial cascade configuration with AES decryption module (e.g. decrypt first, then hash).

[0066] Result output: Pass the calculated hash value to the RSA verification module for signature comparison.

[0067] Application scenario: Can be independently run to verify the integrity of firmware whether it is encrypted or not.

[0068] 3. Related content of RSA verification module is as follows: 1) Algorithm and implementation The algorithm flow of RSA verification module can be as follows: Figure 5As shown, the RSA signature verification module uses the acquired RSA public key to perform modular exponentiation decryption on the digital signature attached in the firmware. Then it compares with the firmware hash value calculated by the SHA3 / Hash module. If they are consistent, it is considered that the firmware signature verification is passed.

[0069] The RSA-4096 public key cryptography system is adopted to realize the verification function of digital signature. The core operation is based on the efficient large number modular exponentiation algorithm, which uses Montgomery multiplication to optimize performance and reduce large integer operation delay.

[0070] The signature verification process is as follows: extract the original digital signature from the firmware header; use the RSA public key provided by the key management unit to decrypt the signature and restore the original hash value; compare the hash value with the current firmware hash value calculated by the SHA3 / Hash module in real time; if they are consistent, the signature verification is successful, indicating that the firmware source is trusted and has not been tampered with. Among them, the signature verification process combines asymmetric encryption and hash technology to form a complete "digital signature verification" mechanism.

[0071] 2) Internal interface Public key acquisition: load RSA public key from key management unit securely.

[0072] Hash input: receive real-time calculated hash value from SHA3 / Hash module.

[0073] Result output: send the signature verification result (pass / fail) to the state control unit; at the same time, feedback to the Bootloader to decide whether to allow the startup process to continue.

[0074] 4. The related content of the DMA engine is as follows: 1) Function and implementation Responsible for high-speed data transfer, transferring firmware data from external Flash to secure boot module, and writing decrypted firmware to DDR after verification. Internal FIFO buffer and pipeline data transmission are used to support burst mode and multiple data block continuous transmission. Interrupt and state feedback are supported to monitor data transmission status in real time.

[0075] 2) Internal interface Directly connected with AXI Slave interface to realize data interaction between PS. Connected with AES decryption, SHA3 and RSA modules as a data stream transfer path.

[0076] 5. The related content of the key management unit is as follows: 1) Function and implementation The key is stored in eFuse or other secure non-volatile memory, ensuring that the RSA public key, AES key and other security parameters cannot be changed. A secure interface is provided for the AES and RSA modules to read the key, supporting a key update interface (updated through secure authentication).

[0077] 2) Internal interface Connected to the AES decryption and RSA signature verification modules, providing real-time keys. Connected to the main control logic of the secure boot module, ensuring the secure management of the key in the startup process.

[0078] 6. The AXI Slave interface and the related content of the control unit are as follows: 1) Function and implementation Through the standard AXI Slave interface, the secure boot module communicates with the PS (Bootloader). The internal control unit uses a finite state machine (FSM) to manage the entire secure boot process, and each sub-module works in sequence. The control unit monitors the status of each module (such as data reception, hash calculation, signature verification result, decryption completion, etc.), and feeds back the final state to the Bootloader.

[0079] 2) Internal connection Concentrate on receiving data requests and status feedback from DMA. Distribute startup commands to each sub-module to ensure that data transmission, encryption and decryption, and signature verification processes are performed in sequence.

[0080] The collaborative work and overall process among the modules in the secure boot system provided by the embodiments of the present application are as follows: 1. Secure boot process 1) Firmware data transmission Bootloader reads the firmware and transmits the data block to the AXI Slave interface of the secure boot module through DMA.

[0081] 2) Integrity verification The SHA3 / Hash module in the secure boot module performs hash calculation on the received firmware data and passes the result to the RSA signature verification module.

[0082] At the same time, the digital signature attached in the firmware is verified by the RSA signature verification module to judge the integrity and legality of the firmware.

[0083] 3) Firmware decryption If the signature verification is successful, the AES accelerator starts to perform AES-GCM-256 decryption processing on the firmware data. The decrypted data is transmitted to the DMA engine through the internal FIFO, and written into the DDR memory by the DMA engine.

[0084] 4) State feedback and multi-core wake-up The control unit feeds back the secure boot state to the Bootloader after the whole process ends. The Bootloader decides whether to jump to the DDR firmware address to start the system according to the feedback, and broadcasts a signal of completion of secure boot to other cores in the sleep state, and wakes up all cores.

[0085] 2. Internal coordination mechanism Each sub-module is connected by AXI bus, and seamless data flow is realized through standard interface and internal FIFO buffer.

[0086] The FSM of the main control unit controls the whole process of the secure boot module, ensures the sequential execution of each processing stage, and interrupts the process in time in case of abnormality.

[0087] The key management unit and the accelerator module transmit the key through a special high-speed interface, ensuring no delay in the encryption and decryption process.

[0088] The DMA engine runs through the whole data transmission process, responsible for inputting and carrying the firmware data, and outputting the decrypted data to the DDR, providing a high-performance data path for the secure boot module.

[0089] Corresponding to the secure boot system of the RISC-V and FPGA system-level chip described above, the embodiment of the application further provides a secure boot method of a RISC-V and FPGA system-level chip. As shown in Figure 6 The secure boot method of the RISC-V and FPGA system-level chip provided by the embodiment of the application includes: Step 200, the secure boot module reads the encrypted firmware from the firmware storage module under the control of the startup management module, and performs a security check operation on the read encrypted firmware; Step 210, the secure boot module reads the encrypted firmware from the firmware storage module under the control of the startup management module, performs the security check operation on the read encrypted firmware, and sends first feedback information to the startup management module after the security check operation is completed; Step 220, the startup management module receives the first feedback information sent by the secure boot module after the security check operation is completed, controls the secure boot module to perform a firmware decryption operation based on the obtained first feedback information; Step 230, the secure boot module performs a firmware decryption operation under the control of the startup management module, sends second feedback information to the startup management module after the firmware decryption operation is completed, and transmits the decrypted firmware to the firmware storage module; Step 240, the start management module receives second feedback information sent by the secure start module after completing the firmware decryption operation, and runs the decrypted firmware in the firmware storage module based on the obtained second feedback information.

[0090] In an example embodiment, the secure start module comprises a DMA engine and an integrity verification unit; the secure verification operation comprises an integrity verification operation; when the secure verification operation is the integrity verification operation, the start management module controls the secure start module to perform the secure verification operation on the read encrypted firmware, comprising: The start management module sends a secure verification instruction to the DMA engine; wherein the secure verification instruction carries storage information of the encrypted firmware in the firmware storage module; The secure start module reads the encrypted firmware from the firmware storage module under the control of the start management module, and performs the secure verification operation on the read encrypted firmware, comprising: The DMA engine reads the encrypted firmware from the firmware storage module according to the storage information in the secure verification instruction, and transmits it to the integrity verification unit; The integrity verification unit performs integrity verification on the encrypted firmware to obtain an integrity verification result.

[0091] In an example embodiment, the secure start module further comprises a key management unit and a decryption unit; the start management module controls the secure start module to perform a firmware decryption operation based on the obtained first feedback information, comprising: When the first feedback information indicates that the integrity verification result is passed, the start management module sends a decryption instruction to the DMA engine; The secure start module performs a firmware decryption operation under the control of the start management module, comprising: The DMA engine transmits the encrypted firmware to the decryption unit according to the decryption instruction; The decryption unit obtains a first key from the key management unit, and decrypts the encrypted firmware using the obtained first key to obtain decrypted firmware; The secure start module writes the decrypted firmware to the firmware storage module, comprising: The DMA engine writes the decrypted firmware in the decryption unit to the firmware storage module.

[0092] In an example, the secure boot module further comprises a key management unit, the integrity check unit comprises a hash sub-unit and a signature verification sub-unit, the encrypted firmware comprises encrypted firmware content and a firmware header, and the firmware header comprises a firmware signature generated based on the encrypted firmware content. The integrity check unit performs integrity check on the encrypted firmware to obtain an integrity check result, comprising: The hash sub-unit performs hash operation on the encrypted firmware content to obtain a first hash value. The signature verification sub-unit obtains a second key from the key management unit, decrypts the firmware signature using the obtained second key to obtain a second hash value, and compares the second hash value with the first hash value to obtain the integrity check result.

[0093] In an example, the secure boot module further comprises a control state machine, and the method further comprises: The boot management module sends an initialization instruction to the secure boot module. The control state machine initializes each unit in the secure boot module when detecting the initialization instruction. The secure boot module sends first feedback information to the boot management module after the security check operation is completed, comprising: The control state machine monitors whether the security check operation is completed, generates the first feedback information according to the integrity check result after the security check operation is completed, and sends the first feedback information to the boot management module. The secure boot module sends second feedback information to the boot management module after the firmware decryption operation is completed, comprising: The control state machine monitors whether the firmware decryption operation is completed, generates the second feedback information according to the firmware decryption result after the firmware decryption operation is completed, and sends the second feedback information to the boot management module.

[0094] In an example, the encrypted firmware content comprises a plurality of encrypted firmware sub-contents, and the firmware signature comprises a firmware signature corresponding to each encrypted firmware sub-content. The hash sub-unit performs hash operation on the encrypted firmware content to obtain a first hash value, comprising: The hash sub-unit sequentially performs hash operation on each encrypted firmware sub-content to obtain a first hash value corresponding to each encrypted firmware sub-content. The signature verification sub-unit decrypts the firmware signature using the obtained second key to obtain a second hash value, and compares the second hash value with the first hash value, comprising: The signature verification subunit decrypts the firmware signature corresponding to each encrypted firmware subcontent by using the obtained second key to obtain a second hash value corresponding to each encrypted firmware subcontent, and compares the first hash value corresponding to each encrypted firmware subcontent with the second hash value corresponding thereto.

[0095] In an exemplary instance, the decrypted firmware includes: a plurality of decrypted subfirmwares corresponding to a plurality of encrypted firmware subcontents. The DMA engine reads the encrypted firmware from the firmware storage module according to the storage information in the security check instruction, including: The DMA engine sequentially reads a plurality of encrypted firmware subcontents and corresponding firmware signatures from the firmware storage module according to the storage information in the security check instruction. The DMA engine transmits the decrypted firmware in the decryption unit to the firmware storage module, including: The DMA engine sequentially writes a plurality of decrypted subfirmwares in the decryption unit to the firmware storage module. The reading of the plurality of encrypted firmware subcontents and corresponding firmware signatures and the writing of the plurality of decrypted subfirmwares are performed in a preset manner, including: a double buffering manner, an AXI-Stream handshake manner.

[0096] In an exemplary instance, the DMA engine sequentially reads a plurality of encrypted firmware subcontents and corresponding firmware signatures from the firmware storage module according to the storage information in the security check instruction, including: The DMA engine reads a next encrypted firmware subcontent and corresponding firmware signature from the firmware storage module when the integrity check unit performs integrity check on the encrypted firmware subcontent and corresponding firmware signature, until the last encrypted firmware subcontent and corresponding firmware signature are read.

[0097] In an exemplary instance, the encrypted firmware includes: an encrypted firmware content and a firmware header, the firmware header including: a magic number, a version number. The start management module controls the security start module to read the encrypted firmware from the firmware storage module, including: The starting management module acquires the firmware head of the encrypted firmware from the firmware storage module according to preset address information, and verifies whether the magic number and version number therein are correct, in the case that the verification is passed and the firmware head carries a secure starting mark, controls the secure starting module to read the encrypted firmware from the firmware storage module.

[0098] The key steps of the secure starting system and method provided in the application are as follows: 1. Bootloader joint verification mechanism After the Bootloader is initialized by power-on, it first automatically reads the firmware image head information from the fixed address of DDR, and judges the trustworthiness of the firmware according to the security mark field in the head. The firmware head can be designed to contain basic fields such as magic number, version number, length, and fields for security verification. For example, the security verification field can adopt the form of digital signature or hash value: the common practice is to reserve 32 bytes in the head for SHA-384 hash value storage, or to append a digital signature (such as RSA signature) after the head, and to contain the hash value in the signature data. By storing the hash or signature field in the head, the Bootloader can verify the integrity and source of the image when booting.

[0099] Security mark field format and verification algorithm: the security field predefined in the firmware image head usually includes: magic number (magic) to ensure the correctness of the head, version number and length information, and subsequent verification field. The verification field can be in the form of SHA-384 hash or digital signature. Taking SHA-384 verification as an example, the 0~31 bytes of the head store the expected hash value, and then the Bootloader runs the SHA-384 algorithm on the subsequent firmware content, and compares the calculated hash with the head value. If a digital signature is used, the Bootloader can use the pre-stored public key (stored in eFuse) to verify the signature field, thereby confirming the integrity and authenticity of the firmware. After the verification algorithm is selected, it should be ensured that it can be quickly executed by the CPU or hardware in the Boot phase (such as software SHA-384 acceleration or hardware public key accelerator), and a secure hash function or standard signature algorithm resistant to collision is used to prevent tampering with the firmware.

[0100] Verification process: At startup, the RISC-V side Bootloader reads and parses the header. First, check the magic number and version field to confirm that the image format is correct; then extract the firmware body data range according to the header information. Bootloader performs SHA-384 calculation on the firmware body, and compares the calculation result with the hash value stored in the header; if the header field is signed, use the public key algorithm to verify the legality of the signature. Only when the hash matches or the signature verification passes, the firmware is considered trustworthy, and the Bootloader continues to the next step; if the verification fails, the Bootloader can enter a safe exception handling (e.g. report an error, do not start or enter a safe dead state), preventing unauthorized firmware from running.

[0101] Call FPGA startup module: After verification, Bootloader needs to notify the FPGA side to start the security boot module. The usual approach is to design a specific control register or dedicated signal line interface between RISC-V and FPGA. Bootloader can write the firmware DDR start address, length and other parameters into the FPGA register, then pull high the "INIT" signal or set the startup bit in the control register to tell the FPGA security module to start working. At the same time, Bootloader waits for the handshake feedback signal from the FPGA side. FPGA detects the INIT signal and starts the internal process, and can set a "PROGRAM" or "BUSY" signal to inform RISC-V that it is currently processing; when FPGA completes integrity verification and decryption, it pulls high the "DONE" signal to inform Bootloader that its work is completed. In this scheme, the "INIT / PROGRAM / DONE" signals form the key startup handshake interface: RISC-V wakes up the FPGA module through INIT, FPGA pulls high the PROGRAM to indicate the busy state at the right time, and sets the DONE bit to feedback the result after the work is completed, to realize the state synchronization and feedback of software and hardware.

[0102] FPGA side security verification module structure: A complete security verification IP core is integrated in FPGA, which is used to receive initialization commands, transport firmware data, perform integrity verification and decryption. The module usually includes the following functional units: AXI-DMA engine: As an AXI master port, it efficiently transports firmware ciphertext data in DDR. After startup, the DMA engine reads the ciphertext block from DDR according to the configured address and length, sends it to the decryption unit, and writes the result back to DDR or the specified memory area after decryption.

[0103] Hardware AES decryption unit: Real-time decryption using symmetric key algorithm (AES-256). The FPGA's built-in AES core is tightly coupled with the DMA, allowing the read ciphertext to be pipelined to the AES module for decryption and then outputting the plaintext data. The AES key is stored in the FPGA's secure area (eFuse) for decryption of the firmware load.

[0104] Integrity checking unit: Used for hash verification or signature verification of the decrypted firmware. For example, integrate a SHA-384 calculator or public key verification circuit. The FPGA can verify data integrity at any stage before or after decryption: one solution is to verify the ciphertext with SHA before loading; another is to verify that the plaintext matches the header hash after decryption; or use a public key algorithm to verify the signature after decryption.

[0105] Control state machine: Responsible for coordinating the workflow of DMA and encryption unit, and managing the handshake signals with RISC-V. The state machine first detects the INIT signal to start, then configures and activates the DMA / decryption process. After the process is completed, the state machine decides whether to assert the DONE signal based on the verification result: if all checks pass, output DONE=1 and write the completion status to the feedback register; if the verification fails, assert the error flag or keep DONE low to indicate that the Bootloader fails to guide.

[0106] The above structure ensures the secure startup process of Bootloader and FPGA collaboration: the Bootloader on the RISC-V side is responsible for rough checking and initiating requests, and the FPGA side hardware module performs time-consuming integrity verification and decryption operations, and the two are synchronized through INIT / PROGRAM / DONE signals to ensure that only the firmware that has passed hardware verification can be loaded and executed.

[0107] 2. FPGA side dedicated DMA firmware transfer and decryption loading In the secure startup process, in order to accelerate the transfer and decryption of a large amount of firmware data, the FPGA side integrates a dedicated DMA engine. The FPGA DMA engine is connected to the DDR controller through the AXI bus and is responsible for efficiently reading firmware data from the DDR and writing decrypted data back to the DDR during the startup phase. The specific process is as follows: DMA initiation and data path: After triggering the FPGA to start, the RISC-V Bootloader configures the FPGA control register (source address register) to start the DMA. First, write the firmware source address, target address, and length parameters to the DMA engine, and then trigger the DMA start signal (initialize VS start). After that, the FPGA DMA reads the ciphertext from the DDR as the AXI master. The read ciphertext data is sent to the AES decryption unit through the AXI or AXI-Stream interface. The AES module outputs the plaintext after decryption, and the DMA engine receives the plaintext and writes it back to the DDR through AXI (can overwrite the original ciphertext address or write to a new free area). The transmission channel constructed in this way is: DDR (AXI) -> DMA -> decryption engine -> DMA -> DDR. Using the pipeline method, DMA and AES work in parallel, greatly speeding up the firmware loading speed. The FPGA DMA in this design exclusively accesses the DDR access channel in the startup phase, achieving high-speed data transfer.

[0108] DMA and decryption engine cooperation, multi-segment scheduling, and completion feedback: To support large-capacity firmware, the DMA engine usually has the ability of multi-segment transmission. Multiple sets of descriptors (scatter / gather) or circular mode can be used to let DMA process multiple segments of firmware in turn. The Bootloader can write the addresses and lengths of each segment to the DMA configuration list, and DMA automatically completes the transmission and decryption of each segment in order. The cooperation between DMA engine and AES decryptor can use double buffering or AXI-Stream handshake method: one side DMA reads the ciphertext and sends it to the AES decryption, and the other side DMA grabs the decrypted output and writes it back to the DDR, so as to keep the pipeline smooth. After the entire transmission is completed, the DMA controller will trigger an interrupt or write a status register flag to the RISC-V, notifying the Bootloader that the firmware transmission decryption has been completed. For example, the FPGA pulls up a "DMA_DONE" interrupt signal to the RISC-V after completing all segment decryption and write-back, triggering the CPU to respond. This feedback mechanism enables the Bootloader to accurately know the transmission status and decide the subsequent behavior (such as continuing to jump to the main firmware or handling exceptions). In summary, the DMA decryption loading process of this scheme realizes efficient startup through hardware pipeline and parallel processing: read ciphertext from DDR -> AES decryption -> write back to DDR -> feedback completion, each step has clear signals or interrupts to synchronize with RISC-V.

[0109] The above-mentioned hardware and software collaborative design provides clear and complete function implementation in the secure startup: the RISC-V bootloader is responsible for high-level decision and security tag verification, and the FPGA side DMA+decryption+integrity verification unit undertakes data-intensive and encryption tasks, and the two complete handshaking and feedback through the INIT / PROGRAM / DONE, interrupt and state register interfaces. In this way, the integrity and confidentiality of the firmware are ensured, and the startup speed and system stability are also taken into account.

[0110] The secure startup system and method provided by the embodiments of the present application establish a complete secure startup link from firmware reading, data transmission, hash calculation, digital signature verification to AES decryption by defining the system startup process and the implementation details of each sub-module in the secure startup module in detail. Each module uses hardware acceleration technology (AES-GCM-256, SHA3 / SH384, RSA-4096), high-speed DMA data transfer, and strict internal control and state feedback mechanism to realize a secure, reliable and high-performance startup process. The scheme ensures that the RISC-V system and the FPGA system are started after the firmware is verified for integrity and signature, effectively preventing malicious firmware injection and tampering, and providing unified and stable security startup protection for multi-core systems, while having good online debugging and expansion capabilities, providing a solid security foundation for the next-generation heterogeneous SoC platform.

[0111] The secure startup system and method provided by the embodiments of the present application can achieve the following technical effects: 1. Secure and reliable startup Through the hardware-accelerated AES, SHA3 and RSA modules, the firmware is ensured to be verified for integrity, signature and decryption before startup, effectively preventing malicious firmware injection and tampering.

[0112] 2. Fast startup Using a dedicated DMA engine and parallel acceleration, the data transfer and encryption / decryption delay in the secure startup process are significantly reduced, enabling the system to complete startup verification and enter normal working state in a short time.

[0113] 3. Multi-core collaborative security management Using single-core startup and security state broadcast mechanism, it is ensured that only the firmware that has passed security verification is executed in a multi-core system, ensuring the overall security and consistency of the system.

[0114] 4. Flexible customization and scalability Modular design and standard AXI interface make the secure startup module easy to integrate and extend, and users can customize security policies according to different application requirements, and support online debugging and dynamic configuration.

[0115] 5. Key protection and fault tolerance Employing secure storage technologies such as eFuse to protect critical keys, combined with error detection and retransmission mechanisms, ensures that fault-tolerant measures are taken immediately upon detection of anomalies during startup, thereby improving the overall reliability of the system.

[0116] The secure boot system and method provided in this application embodiment can also adopt the following solutions: 1. The external security chip solution implements some or all of the functions of the secure boot module by an external dedicated security chip, which communicates with the main system through interfaces such as SPI or I2C, and has higher security authentication capabilities.

[0117] 2. Software-assisted safe startup solution In some application scenarios, bootloader software can be used to verify and decrypt firmware signatures, supplemented by some functions of hardware accelerators, to achieve a secure boot process that combines software and hardware.

[0118] 3. Alternative Encryption Algorithms In addition to AES-GCM-256, SHA3 and RSA, other mature encryption, hashing and signature verification algorithms can be selected to meet specific security requirements.

[0119] Those of ordinary skill in the art will realize and understand that all or some of the steps in the methods disclosed above and the functional modules / units in the systems and devices can be implemented as software, firmware, hardware, and appropriate combinations thereof. In hardware implementation, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component can have multiple functions, or one function or step can be performed by several physical components in cooperation. Some or all of the components can be implemented as software executed by a processor, such as a digital signal processor or a microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on computer-readable media, which can include computer storage media (or non-transitory media) and communication media (or transitory media). As is well known to those of ordinary skill in the art, the term "computer storage media" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by a computer. Furthermore, it is common and well understood by those of ordinary skill in the art that communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and can include any information delivery media.

Claims

1. A secure boot system for RISC-V and FPGA system-on-a-chip, characterized in that, include: Firmware storage module, boot management module built based on RISC-V resources, and secure boot module built based on FPGA resources; The startup management module is used to control the secure startup module to read encrypted firmware from the firmware storage module and perform security verification on the read encrypted firmware. Receive first feedback information from the secure boot module after it completes the security verification operation, and control the secure boot module to perform firmware decryption operation based on the obtained first feedback information; Receive second feedback information from the secure boot module after it has completed the firmware decryption operation, and run the decrypted firmware in the firmware storage module based on the obtained second feedback information; The secure boot module is used to read the encrypted firmware from the firmware storage module under the control of the boot management module, perform the security verification operation on the read encrypted firmware, and send the first feedback information to the boot management module after the security verification operation is completed. The firmware decryption operation is performed under the control of the boot management module, and a second feedback message is sent to the boot management module after the firmware decryption operation is completed. The decrypted firmware is then written to the firmware storage module.

2. The safe start system according to claim 1, characterized in that, The secure boot module includes a DMA engine and an integrity verification unit; the security verification operation includes an integrity verification operation; when the security verification operation is the integrity verification operation, the boot management module controls the secure boot module to perform a security verification operation on the read encrypted firmware, including: The startup management module sends a security verification command to the DMA engine; wherein, the security verification command carries the storage information of the encrypted firmware in the firmware storage module; The secure boot module, under the control of the boot management module, reads the encrypted firmware from the firmware storage module and performs the security verification operation on the read encrypted firmware, including: The DMA engine is used to read the encrypted firmware from the firmware storage module according to the storage information in the security verification instruction, and transmit it to the integrity verification unit. The integrity verification unit is used to perform integrity verification on the encrypted firmware to obtain an integrity verification result.

3. The safe start system according to claim 2, characterized in that, The secure boot module further includes a key management unit and a decryption unit; the boot management module controls the secure boot module to perform firmware decryption operations based on the obtained first feedback information, including: If the first feedback information indicates that the integrity verification result is successful, the startup management module sends a decryption command to the DMA engine; The secure boot module performs firmware decryption under the control of the boot management module, including: The DMA engine is used to transmit the encrypted firmware to the decryption unit according to the decryption instruction; The decryption unit is used to obtain a first key from the key management unit and use the obtained first key to decrypt the encrypted firmware to obtain the decrypted firmware. The secure boot module writes the decrypted firmware to the firmware storage module, including: The DMA engine writes the decrypted firmware from the decryption unit to the firmware storage module.

4. The safe start system according to claim 3, characterized in that, The integrity verification unit includes a hash subunit and a signature verification subunit. The encrypted firmware includes encrypted firmware content and a firmware header. The firmware header includes a firmware signature generated based on the encrypted firmware content. The integrity verification unit performs integrity verification on the encrypted firmware to obtain an integrity verification result, including: The hash subunit is used to perform a hash operation on the encrypted firmware content to obtain a first hash value; The signature verification subunit is used to obtain a second key from the key management unit, use the obtained second key to decrypt the firmware signature to obtain a second hash value, and compare the second hash value with the first hash value to obtain the integrity verification result.

5. The safe start system according to claim 3, characterized in that, The secure startup module further includes: a control state machine; The startup management module is also used to send initialization instructions to the secure startup module; The control state machine is used to initialize each unit in the secure startup module when an initialization command is detected. The secure boot module sends first feedback information to the boot management module after the security verification operation is completed, including: The control state machine monitors whether the security verification operation is completed. After the security verification operation is completed, it generates the first feedback information based on the integrity verification result and sends it to the startup management module. The secure boot module sends a second feedback message to the boot management module after the firmware decryption operation is completed, including: The control state machine monitors whether the firmware decryption operation is completed. After the firmware decryption operation is completed, it generates a second feedback message based on the firmware decryption result and sends it to the startup management module.

6. The safe start system according to claim 4, characterized in that, The encrypted firmware content includes: multiple encrypted firmware sub-contents, and the firmware signature includes: the firmware signature corresponding to each encrypted firmware sub-content. The hash subunit performs a hash operation on the encrypted firmware content to obtain a first hash value, including: The hash sub-unit performs hash operations on each segment of encrypted firmware sub-content in sequence to obtain the first hash value corresponding to each segment of encrypted firmware sub-content. The signature verification subunit uses the obtained second key to decrypt the firmware signature to obtain a second hash value, and compares the second hash value with the first hash value, including: The signature verification subunit uses the obtained second key to decrypt the firmware signature corresponding to each encrypted firmware sub-content to obtain the second hash value corresponding to each encrypted firmware sub-content, and compares the first hash value corresponding to each encrypted firmware sub-content with its corresponding second hash value.

7. The safe start system according to claim 6, characterized in that, The decrypted firmware includes: multiple decrypted sub-firmware segments, each of which corresponds to a sub-content of an encrypted firmware segment. The DMA engine reads the encrypted firmware from the firmware storage module based on the stored information in the security verification instruction, including: The DMA engine reads multiple encrypted firmware sub-contents and corresponding firmware signatures sequentially from the firmware storage module according to the storage information in the security verification instruction; The DMA engine transfers the decrypted firmware from the decryption unit to the firmware storage module, including: The DMA engine sequentially writes multiple decrypted sub-firmware segments from the decryption unit to the firmware storage module; The reading of multiple encrypted firmware sub-contents and their corresponding firmware signatures, and the writing of multiple decrypted sub-firmwares, are performed using preset methods; the preset methods include: double buffering method and AXI-Stream handshake method.

8. The safe start system according to claim 7, characterized in that, The DMA engine sequentially reads multiple segments of encrypted firmware sub-content and corresponding firmware signatures from the firmware storage module based on the stored information in the security verification instruction, including: After the DMA engine reads a segment of encrypted firmware sub-content and the corresponding firmware signature from the firmware storage module according to the storage information in the security verification instruction and outputs it to the integrity verification unit, when the integrity verification unit performs integrity verification on the segment of encrypted firmware sub-content and the corresponding firmware signature, the DMA engine reads the next segment of encrypted firmware sub-content and the corresponding firmware signature from the firmware storage module until the last segment of encrypted firmware sub-content and the corresponding firmware signature are read.

9. The safe start system according to claim 1, characterized in that, The encrypted firmware includes: encrypted firmware content and firmware header, wherein the firmware header includes: magic number and version number; The boot management module controls the secure boot module to read encrypted firmware from the firmware storage module, including: The boot management module obtains the firmware header of the encrypted firmware from the firmware storage module according to the preset address information, and verifies whether the magic number and version number are correct. If the verification is successful and the firmware header carries a secure boot flag, the module controls the secure boot module to read the encrypted firmware from the firmware storage module.

10. A secure boot method for RISC-V and FPGA system-on-a-chip, characterized in that, The method, applied to a secure boot system for RISC-V and FPGA system-on-a-chip as described in any one of claims 1-9, comprises: The startup management module controls the secure startup module to read encrypted firmware from the firmware storage module and performs security verification on the read encrypted firmware. The secure boot module, under the control of the boot management module, reads the encrypted firmware from the firmware storage module, performs the security verification operation on the read encrypted firmware, and sends the first feedback information to the boot management module after the security verification operation is completed. The startup management module receives first feedback information from the secure startup module after it completes the security verification operation, and controls the secure startup module to perform firmware decryption operation based on the obtained first feedback information. The secure boot module performs firmware decryption under the control of the boot management module, and sends a second feedback message to the boot management module after the firmware decryption is completed, and transmits the decrypted firmware to the firmware storage module. The startup management module receives a second feedback message from the secure startup module after it completes the firmware decryption operation, and runs the decrypted firmware in the firmware storage module based on the obtained second feedback message.

Images