Firmware encryption system and method based on RISC-V architecture server

Abstract

The invention relates to a firmware encryption method based on an RISC-V architecture server, and belongs to the field of computer security, a storage medium of the RISC-V architecture server comprises an immutable storage medium ROM and a variable storage medium EMMC, the ROM and the RISC-V architecture server are packaged into a core of a CPU together, meanwhile, a firmware code used for storing a ZSBL stage is solidified in the ROM, and the firmware code is used for storing the ZSBL stage. Firmware of the FSBL stage, the SBI stage, the UEFI stage and the GRUB stage is stored in the EMMC. Multi-level encryption and verification operations are implemented in each key stage of server startup to form a seamlessly connected safety chain, the system is ensured to start from a safe and credible starting point, and a startup loading program is prevented from being maliciously repaired by selecting a non-tampering ROM as a ZSBL storage medium, so that the security of the system is ensured. And the overall security level and the operation stability of the system are obviously improved.

Description

Technical Field

[0001] The present invention relates to a firmware encryption system and method based on a RISC-V architecture server, and belongs to the technical field of computer security. Background Art

[0002] In today's digital age, with the popularity of the Internet and cloud services, data security and server reliability have become more important. Servers, especially those in data centers, carry a large amount of sensitive data, including user personal information, financial records, and corporate trade secrets. The security of this information is directly related to user trust and corporate reputation. Therefore, improving the security protection capabilities of servers, especially the security of server firmware, has become a challenge that cannot be ignored.

[0003] Server firmware acts as a bridge between hardware and operating systems, and its security vulnerabilities may provide attackers with sufficient attack surface, making the entire system vulnerable to targeted malicious activities, such as firmware tampering or backdoor implantation. Although existing security strategies, such as access control, firmware signing, and hardware encryption, provide protection to a certain extent, as attack methods continue to evolve and become more complex, traditional protection measures often fail to meet high security requirements.

[0004] In addition, the complexity of the data center environment, including hardware diversity, frequent system updates, and changes in operation and maintenance strategies, has brought additional challenges to firmware security management. An effective firmware security strategy needs to provide a flexible and reliable protection mechanism without affecting the normal operation and performance of the server, which requires the security solution to be highly adaptable and forward-looking.

[0005] In the above context, the emergence of RISC-V architecture provides new possibilities for firmware security. As an open source instruction set architecture, RISC-V supports a high degree of customization and modularity, which provides flexibility for designing targeted security features and mechanisms. Compared with closed or proprietary architectures, RISC-V allows developers to go deep into the architecture level to implement and verify security solutions, such as implementing advanced encryption technology and access control strategies through customized security extensions. Although this architecture shows great potential in security, it is still an urgent task to convert these theoretical advantages into actual security gains and develop encryption methods that are suitable for firmware of RISC-V servers and meet current and future security needs.

[0006] Although existing research and solutions provide a certain degree of protection for firmware security, they are often limited by lack of flexibility, insufficient encryption strength, or failure to fully utilize the characteristics of the RISC-V architecture. In addition, many solutions fail to effectively respond to increasing security threats, resulting in risks to data and system security. Therefore, exploring and developing a firmware encryption method based on the RISC-V architecture that can provide efficient, reliable, and flexibly configurable security is crucial to enhancing the security of servers and their data. Summary of the invention

[0007] In order to overcome the deficiencies in the prior art, the present invention provides a firmware encryption system and method based on a RISC-V architecture server, which implements multi-level encryption and verification operations at various key stages of server startup (including FSBL, SBI, UEFI and GRUB) to form a seamless security chain, ensuring that the system starts from a secure and reliable starting point, and prevents the boot loader from being maliciously modified by selecting an unalterable ROM as the ZSBL storage medium, thereby significantly improving the overall security level and operational stability of the system.

[0008] Terminology explanation:

[0009] 1. ZSBL: ZSBL (Zero Stage Boot Loader), also known as the zero-stage boot loader, is the boot loader at the earliest stage of system startup, usually located in the processor's internal memory or read-only memory. ZSBL is responsible for initializing basic hardware configuration and transferring control to the next startup stage (usually FSBL).

[0010] 2. FSBL: FSBL (First Stage Boot Loader), also known as the first-level boot loader, is a boot loader executed after ZSBL. It further initializes hardware devices, loads and starts the operating system kernel or transfers control to the next boot stage (such as UEFI or other boot loaders).

[0011] 3. SBI: SBI (Supervisor Binary Interface), also known as the system boot interface, is a set of standard interfaces in the RISC-V architecture for communication between the operating system and the underlying hardware (usually firmware or a hypervisor). SBI provides a standardized method for the operating system to request and control privileged operations.

[0012] 4. UEFI: UEFI (Unified Extensible Firmware Interface), also known as the Unified Extensible Firmware Interface, is a modern firmware interface standard that replaces the traditional BIOS. It provides a set of standardized boot services and runtime services, allowing more complex and flexible interactions between the operating system and firmware. UEFI also supports advanced features such as graphical user interface and network boot.

[0013] 5. GRUB: GRUB (GRand Unified Bootloader), also known as boot loader, is a universal boot loader commonly used in Linux and other Unix-like operating systems. It can load and boot multiple operating system kernels from multiple file systems, and supports users to select different kernels or operating systems at startup. GRUB also provides a command line interface that allows users to perform manual startup configuration and troubleshooting.

[0014] The technical solution of the present invention is as follows:

[0015] A firmware encryption system based on a RISC-V architecture server. The storage medium of the RISC-V architecture server includes an immutable storage medium ROM and a mutable storage medium EMMC. The ROM and the RISC-V architecture server are packaged into the core of a CPU. At the same time, firmware code for storing a ZSBL stage is solidified in the ROM. Firmwares of FSBL, SBI, UEFI and GRUB stages are stored in the EMMC. The EMMC provides a larger storage space and better read and write performance, and supports the update and management of these firmwares.

[0016] An encryption method based on the firmware encryption system based on the RISC-V architecture server comprises the following steps:

[0017] S1: The system is powered on and the firmware code of the ZSBL stage is run to initialize the hardware and encryption and decryption chips to establish a security baseline.

[0018] S2: In the first-level boot loader FSBL stage, the firmware is encrypted and a high-strength encryption algorithm such as AES or RSA is used to ensure the confidentiality and integrity of the firmware during loading and execution. The firmware is decrypted and the FSBL signature is verified. If the signature verification passes, the FSBL is executed. If the signature verification fails, the boot is stopped.

[0019] S3: Perform firmware verification in the SBI, UEFI, and GRUB stages respectively to ensure that only firmware and operating systems that pass the verification can be loaded and executed. When one of them fails the verification, the startup is stopped. Through this series of sophisticated security operations, the present invention significantly improves the startup and operation security of the RISC-V architecture server, and effectively protects the system from unauthorized access and tampering. The present invention can select all loaded programs to ensure their authenticity and security, and prevent the execution of any unauthorized or malicious code. Through this series of technical strategies, the present invention realizes the security reinforcement of the entire process of the firmware stage of the RISC-V architecture server.

[0020] Preferably, step S1 comprises the following process:

[0021] S11: After the system is powered on, the hardware environment first performs an initialization operation and runs the firmware code of the ZSBL stage stored in the ROM;

[0022] S12: Execute the firmware code of the ZSBL stage, the process includes: power-on reset and initialization, chip self-test, memory self-test, peripheral device self-test and CPU self-test;

[0023] S13: Select an appropriate communication interface;

[0024] S14: Initialize the encryption and decryption chip and perform a power-on reset operation on the encryption and decryption chip to ensure that the chip is in an initial state;

[0025] S15: Load the driver module and establish an application layer protocol for secure communication between the RISC-V architecture CPU and the encryption and decryption chip.

[0026] Preferably, the encryption process in step S2 includes:

[0027] a. First, generate a random symmetric key and encrypt the FSBL firmware file using the AES algorithm and the generated symmetric key;

[0028] b. Then use the recipient's public key to encrypt the symmetric key, specifically use the OAEP padding scheme of the RSA algorithm to encrypt the symmetric key to generate an encrypted symmetric key;

[0029] c. Calculate the hash value of the FSBL firmware, sign the hash value with the private key, generate a digital signature, and attach the digital signature to the encrypted FSBL firmware to obtain the packaged FSBL firmware package.

[0030] Preferably, the decryption process in step S2 includes:

[0031] A. Load the encrypted FSBL firmware package from the external storage device EMMC, and use the private key in the encryption chip to decrypt the symmetric key to obtain the symmetric key;

[0032] B. Decrypt the encrypted FSBL firmware using the symmetric key decrypted by the private key to obtain the original FSBL firmware;

[0033] C. Use the SHA-256 algorithm to recalculate the hash value of the decrypted FSBL firmware, use the public key to verify the digital signature, and compare whether the calculated hash value is consistent with the hash value in the signature. If they are consistent, the signature verification passes and the FSBL continues to execute; otherwise, the boot process is stopped.

[0034] Preferably, in step S3, the processes of firmware verification in the SBI, UEFI, and GRUB stages are the same, and the process of firmware verification in the SBI stage is as follows:

[0035] S31: Generate the signature of the firmware in the development environment, calculate the hash value of the SBI firmware, and sign the calculated hash value using the RSA private key;

[0036] S32: Recalculate the hash value of the loaded SBI firmware, and send the recalculated hash value and signature of the SBI firmware to the encryption chip for verification through the encryption chip API; the encryption chip verifies the signature using its internally stored public key and returns the verification result to ensure that the hash value of the signature is consistent with the recalculated hash value. If they are consistent, the verification passes and the SBI firmware is executed; otherwise, the verification fails and the startup stops.

[0037] Preferably, in step S31, the hash value of the SBI firmware is calculated using the SHA-256 algorithm; in step S32, the hash value of the loaded SBI firmware is recalculated using the SHA-256 algorithm, and the recalculation process is the same as the process of calculating the hash value in the development environment, both of which use the SHA-256 algorithm to perform hash calculation on the same data.

[0038] Similarly, the process of firmware verification at the UEFI stage is as follows:

[0039] Generate the firmware signature in the development environment, calculate the hash value of the UEFI firmware, and sign the calculated hash value using the RSA private key;

[0040] Recalculate the hash value of the loaded UEFI firmware, and send the recalculated hash value and signature of the SBI firmware to the encryption chip for verification through the encryption chip API; the encryption chip verifies the signature using its internally stored public key and returns the verification result to ensure that the hash value of the signature is consistent with the recalculated hash value. If they are consistent, the verification passes and the UEFI firmware is executed; otherwise, the verification fails and the boot is stopped.

[0041] The process of firmware verification at the GRUB stage is as follows:

[0042] Generate the firmware signature in the development environment, calculate the hash value of the GRUB firmware, and sign the calculated hash value using the RSA private key;

[0043] Recalculate the hash value of the loaded GRUB firmware, and send the recalculated hash value and signature of the SBI firmware to the encryption chip for verification through the encryption chip API; the encryption chip verifies the signature using its internally stored public key and returns the verification result to ensure that the hash value of the signature is consistent with the recalculated hash value. If they are consistent, the verification passes and the GRUB firmware is executed; otherwise, the verification fails and the boot is stopped.

[0044] For any details not provided in the present invention, please refer to the prior art.

[0045] The beneficial effects of the present invention are:

[0046] 1. Improve system security: By implementing multi-level encryption and verification operations at each key stage of server startup (including FSBL, SBI, UEFI and GRUB), a seamless security chain is formed by combining hardware-level encryption chips (such as TPM chips) and software-level encryption and verification operations to ensure that the system starts from a safe and reliable starting point, and by selecting a tamper-proof ROM as the ZSBL storage medium, the boot loader is prevented from being maliciously modified, and high-intensity encryption technology is used to protect the integrity and confidentiality of firmware data, ensuring that only verified and trusted firmware or operating systems can be executed, effectively preventing the implantation and tampering of malicious software, and providing users with a safer and more reliable computing environment, significantly improving the operational credibility and security level of the system. By describing the encryption and verification operations of each startup stage in detail, the present invention provides a specific and comprehensive security solution to ensure that the server runs reliably and safely, significantly improves the overall security level and operational stability of the system, and provides a substantial security improvement solution for the data center.

[0047] 2. Ensure the confidentiality and integrity of the firmware: This invention uses advanced AES encryption technology and SHA-256 hash algorithm to effectively protect the confidentiality and integrity of firmware data during storage and execution. Through these technical means, the risk of malicious access or tampering of the firmware is avoided, ensuring the security of system data.

[0048] 3. Enhance system reliability: The present invention not only ensures the security of system firmware and software, but also improves the stability and reliability of the server system by adopting fault-tolerant mechanisms and redundancy technologies. For example, the dual-system startup mechanism can ensure that when one system fails, the other system can start normally, thereby continuously providing users with a safe, stable and reliable computing environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The drawings in the specification, which constitute a part of the present application, are used to provide further understanding of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute improper limitations on the present application.

[0050] Figure 1 The overall framework diagram of the firmware encryption method based on the RISC-V architecture server of the present invention;

[0051] Figure 2 It is a verification flow chart of all stages in the firmware encryption method based on the RISC-V architecture server of the present invention;

[0052] Figure 3 It is a firmware encryption flow chart of the FSBL stage in the firmware encryption method based on the RISC-V architecture server of the present invention;

[0053] Figure 4 This is a firmware decryption flow chart of the FSBL stage in the firmware encryption method based on the RISC-V architecture server of the present invention. DETAILED DESCRIPTION

[0054] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of the present invention are clearly and completely described below in conjunction with the drawings in the implementation of this specification, but are not limited to this. Anything not fully described in the present invention shall be based on the conventional technology in the art.

[0055] Example 1

[0056] A firmware encryption system based on a RISC-V architecture server, whose hardware environment is as follows Figure 1 As shown in the figure, the basic storage devices and other hardware devices required for each stage of the firmware on the RISC-V architecture server are specifically the RISC-V server CPU processing core, encryption and decryption chip, EMMC, and ROM.

[0057] The storage media on the RISC-V architecture server can be divided into two types of media, one is the immutable storage medium ROM, and the other is the mutable storage medium EMMC.

[0058] The ROM is packaged into the CPU core together with the RISC-V architecture server, and the firmware code for storing the ZSBL stage is solidified in the ROM;

[0059] EMMC stores firmware at the FSBL, SBI, UEFI, and GRUB stages. EMMC provides a large storage space and better read and write performance, while supporting the update and management of these firmware. ZSBL is the first part executed after the system is powered on. It is responsible for initializing the most basic hardware environment and preparing to load the first-level boot loader (FSBL). ROM is selected as the ZSBL storage medium mainly because of its tamper-proof characteristics, ensuring that the system can start from a safe and reliable starting point.

[0060] This embodiment uses a variable storage medium EMMC, and uses EMMC as a storage solution for subsequent boot-up phase firmware such as FSBL, SBI, UEFI, and GRUB. EMMC provides a larger storage space and better read and write performance, while supporting the update and management of these firmware. In this implementation, the eMMC storage medium is responsible for storing the firmware of the boot loader, SBI (system boot interface), UEFI (unified extensible firmware interface), and GRUB (boot loader) in the FSBL phase.

[0061] The encryption and decryption chip has certificate storage, key storage, and supports encryption and decryption chips such as AES and RSA.

[0062] The chip has certificate storage: The chip has a built-in secure storage area dedicated to storing digital certificates. This area is protected by hardware encryption and access control mechanisms to ensure that only authorized operations can access and modify certificates. Certificates in the storage area can include root certificates, intermediate certificates, and device certificates to establish and verify the trust chain.

[0063] The chip has key storage: There is a dedicated key storage area in the chip, which uses hardware encryption technology to protect the stored keys. This area is partitioned and different keys have different storage locations and access rights. The key storage area supports the storage of symmetric keys (such as AES keys) and asymmetric keys (such as RSA keys). The key management module in the chip is responsible for key generation, storage, update, and destruction.

[0064] The chip supports algorithms such as AES and RSA: A hardware accelerator is integrated in the chip to perform AES encryption and decryption operations. The hardware accelerator can significantly improve the speed and efficiency of AES encryption and decryption while reducing power consumption. It supports multiple AES modes (such as ECB, CBC, GCM, etc.) to meet the needs of different application scenarios.

[0065] A dedicated RSA accelerator is integrated in the chip, which can efficiently perform RSA encryption, decryption and signature verification operations. It supports multiple key lengths (such as 1024 bits, 2048 bits, 4096 bits, etc.) and can provide different levels of security. The hardware-implemented RSA algorithm is efficient and secure, and can meet the requirements of high performance and high security.

[0066] The overall architecture design of the chip focuses on security, including multiple security mechanisms such as physical protection, access control, and hardware encryption. Through hardware isolation and encryption technology, sensitive data and keys stored in the chip are protected from being stolen and tampered with. The chip also has anti-attack detection and response functions, which can detect and resist physical attacks and side-channel attacks.

[0067] Example 2

[0068] The software implementation method of firmware encryption and decryption of RISC-V architecture servers is designed with multiple startup stages in the startup process of RISC-V architecture servers, and each stage is composed of independent firmware files. For example, the server based on RISC-V architecture uses the UEFI type of startup method, specifically the interface firmware involved in the UEFI protocol used in the startup. This startup process involves multiple stages of startup firmware files. Specifically, they are ZSBL stage firmware, FSBL stage firmware, SBI stage firmware, UEFI stage firmware, GRUB stage firmware, and finally the operating system OS. It can be seen that in this startup process, the startup process is divided into five firmware stage processes, and finally GRUB is used to pass it to the OS stage to execute the operating system. The specific process is as follows Figure 2 As shown. In the firmware stage, each stage is an independent binary file. By writing to the location of the specified memory where the firmware is stored, the firmware content of a certain stage can be replaced. Therefore, this boot process is a very safe boot process. The firmware of each stage is in an unknown state to the firmware of the next stage. Therefore, in order to ensure that each stage is in a controllable stage, an encryption and decryption chip is introduced to complete the secure boot process of the firmware stage.

[0069] A firmware encryption method based on a RISC-V architecture server includes the following steps:

[0070] S1: The system is powered on and the firmware code of the ZSBL stage is run to initialize the hardware and encryption and decryption chips to establish a security baseline.

[0071] S2: In the first-level boot loader FSBL stage, the firmware is encrypted and a high-strength encryption algorithm such as AES or RSA is used to ensure the confidentiality and integrity of the firmware during loading and execution. The firmware is decrypted and the FSBL signature is verified. If the signature verification passes, the FSBL is executed. If the signature verification fails, the boot is stopped.

[0072] S3: Perform firmware verification in the SBI, UEFI, and GRUB stages respectively to ensure that only firmware and operating systems that pass the verification can be loaded and executed. When one of them fails the verification, the startup is stopped. Through this series of sophisticated security operations, the present invention significantly improves the startup and operation security of the RISC-V architecture server, and effectively protects the system from unauthorized access and tampering. The present invention can select all loaded programs to ensure their authenticity and security, and prevent the execution of any unauthorized or malicious code. Through this series of technical strategies, the present invention realizes the security reinforcement of the entire process of the firmware stage of the RISC-V architecture server.

[0073] Example 3

[0074] A firmware encryption method based on a RISC-V architecture server, as described in Example 2, except that step S1 includes the following process:

[0075] S11: After the system is powered on, basic hardware initialization is performed, including configuring the memory controller, setting the interrupt vector table, etc., running the firmware code of the ZSBL stage stored in ROM, performing chip self-test, ensuring that the basic functions of the chip are intact, and preparing for subsequent more complex operations; ZSBL is designed for the initial startup stage of the RISC-V chip to perform necessary pre-startup configuration for the chip. Since the ZSBL program code is stored in ROM, this means that once manufacturing is completed, the ZSBL code will not be tampered with, replaced or accessed externally, thus providing a layer of solidified security protection at the bottom of the system.

[0076] S12: Execute the firmware code of the ZSBL stage, the process includes: power-on reset and initialization, chip self-test, memory self-test, peripheral device self-test and CPU self-test;

[0077] Power-on reset and initialization: After power-on, the ZSBL code first performs a hardware reset, initializes basic hardware resources and registers, and ensures that the basic operating environment of the chip is normal.

[0078] Chip self-test: Perform chip self-test operations to check memory, peripheral devices, and CPU core functions to ensure that the basic functions of these hardware components are intact. The specific process includes:

[0079] Memory self-test: Checks the basic read and write functions of RAM and ROM.

[0080] Peripheral device self-test: Check whether peripheral devices such as clock and input and output interfaces are working properly.

[0081] CPU self-test: Checks the instruction set support and register read and write functions of the CPU core to ensure that the CPU can execute code normally.

[0082] S13: Select an appropriate communication interface, such as SPI or I2C interface protocol, and configure hardware and software parameters so that the RISC-V CPU can communicate with the encryption and decryption chip;

[0083] S14: Initialize the encryption and decryption chip, perform a power-on reset operation on the encryption and decryption chip to ensure that the chip is in the initial state; load the pre-generated key into the encryption and decryption chip in a secure manner. The key loading process must ensure the confidentiality of the key, and usually uses encrypted transmission or a secure hardware module to protect the key. Configure the security functions of the encryption and decryption chip, including enabling the hardware encryption module, setting the security area and access control, etc. Specific operations may include setting the access control register, configuring the encryption algorithm parameters, etc.

[0084] S15: Load the driver module and establish the application layer protocol for secure communication between the RISC-V architecture CPU and the encryption and decryption chip. Provide an API interface for encryption and decryption functions so that user space programs can easily call the encryption and decryption chip to perform encryption, decryption, signing and verification operations.

[0085] Example 4

[0086] A firmware encryption method based on a RISC-V architecture server, as described in Example 2, except that Figure 3 As shown, the encryption process in step S2 includes:

[0087] a. In the development environment, first generate a random symmetric key for encrypting the firmware. Specifically, you can use os.urandom(32) to generate a 256-bit (32-byte) random symmetric key. Use the AES algorithm and the generated symmetric key to encrypt the FSBL firmware file; select CFB mode and generate a 16-byte initialization vector (IV). The encrypted data is stored together with the IV.

[0088] b. Then use the recipient's public key to encrypt the symmetric key, specifically use the OAEP padding scheme of the RSA algorithm to encrypt the symmetric key to generate an encrypted symmetric key;

[0089] c. Calculate the hash value (such as SHA-256) of the FSBL firmware, sign the hash value with the private key to generate a digital signature, and attach the digital signature to the encrypted FSBL firmware to obtain the packaged FSBL firmware package.

[0090] When the device starts, the FSBL firmware is decrypted by the encryption chip, such as Figure 4 As shown, the decryption process in step S2 includes:

[0091] A. Load the encrypted FSBL firmware package from the external storage device EMMC, and use the private key in the encryption chip to decrypt the symmetric key to obtain the symmetric key;

[0092] B. Decrypt the encrypted FSBL firmware using the symmetric key decrypted by the private key to obtain the original FSBL firmware;

[0093] C. Use the SHA-256 algorithm to recalculate the hash value of the decrypted FSBL firmware, use the public key to verify the digital signature, and compare whether the calculated hash value is consistent with the hash value in the signature. If they are consistent, the signature verification passes and the FSBL continues to execute; otherwise, the boot process is stopped.

[0094] Example 5

[0095] A firmware encryption method based on a RISC-V architecture server, as described in Example 4, is different in that, in step S3, to ensure the integrity and authenticity of the firmware of the RISC-V architecture server in the SBI, UEFI and GRUB stages, it is necessary to perform signature verification on these firmware. The following is a specific implementation process, including detailed steps of firmware signature generation and firmware signature verification, taking the SBI stage firmware verification as an example for explanation, the process is as follows:

[0096] S31: Generate the signature of the firmware in the development environment, use the SHA-256 algorithm to calculate the hash value of the SBI firmware, and use the RSA private key to sign the calculated hash value;

[0097] S32: Use the SHA-256 algorithm to recalculate the hash value of the loaded SBI firmware, and send the recalculated hash value and signature of the SBI firmware to the encryption chip for verification through the encryption chip API; the encryption chip verifies the signature using its internally stored public key and returns the verification result to ensure that the hash value of the signature is consistent with the recalculated hash value. If they are consistent, the verification passes and the SBI firmware is executed; otherwise, the verification fails and the startup stops.

[0098] The implementation process of UEFI and GRUB firmware verification is the same as the implementation process of SBI mentioned above.

[0099] In summary, Example 1 and Example 2 provide two specific ways to ensure the firmware security of the RISC-V architecture server during its startup process. Example 1 focuses on the allocation of storage media at the hardware level, and uses two storage media, ROM and EMMC, to distinguish the storage location of the firmware. ROM is used to store the immutable zero-level boot loader (ZSBL) code to ensure that the system starts from a safe and reliable starting point; and EMMC, as a mutable storage medium, is responsible for storing the firmware files of the subsequent startup stages (FSBL, SBI, UEFI, GRUB), providing a large storage space and flexibility.

[0100] Example 2 implements the secure boot process of firmware encryption and decryption at the software level. It includes multiple stages of the boot process, and the firmware in each stage ensures the security and integrity of the firmware through encryption and signature verification. From the initial hardware initialization and initialization of the encryption and decryption chip to the encryption processing and signature verification of the firmware in the subsequent stage, each step is to ensure the security of the firmware throughout the entire boot process.

[0101] The two implementation methods provide a solid guarantee for the firmware security of RISC-V architecture servers through their own methods. Whether through physical hardware or software encryption and signing methods, these measures together constitute a multi-level security strategy. This not only ensures the security of the system at startup, but also provides a reliable foundation for the stable operation of RISC-V architecture servers. Through these carefully designed security measures, potential security threats can be effectively prevented to ensure the security and reliability of the system.

[0102] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A firmware encryption system based on a RISC-V architecture server, characterized in that: The storage media of the RISC-V architecture server include the immutable storage medium ROM and the mutable storage medium EMMC. The ROM is encapsulated into the core of the CPU together with the RISC-V architecture server. At the same time, the firmware code for storing the ZSBL stage is solidified in the ROM. The firmware of the FSBL, SBI, UEFI, and GRUB stages are stored in the EMMC. The EMMC supports firmware updates and management.

2. An encryption method based on the firmware encryption system based on the RISC-V architecture server according to claim 1, characterized in that: The steps include: S1: The system is powered on and the firmware code of the ZSBL stage is run; S2: In the first-level boot loader FSBL stage, the firmware is encrypted and decrypted, and the FSBL signature is verified. If the signature verification passes, the FSBL is executed. If the signature verification fails, the boot is stopped; S3: Perform firmware verification at the SBI, UEFI, and GRUB stages to ensure that only firmware and operating systems that pass the verification can be loaded and executed. If one of them fails the verification, the boot is stopped.

3. The encryption method of the firmware encryption system based on the RISC-V architecture server according to claim 2, characterized in that: Step S1 includes the following process: S11: After the system is powered on, the hardware environment first performs an initialization operation and runs the firmware code of the ZSBL stage stored in the ROM; S12: Execute the firmware code of the ZSBL stage, the process includes: power-on reset and initialization, chip self-test, memory self-test, peripheral device self-test and CPU self-test; S13: Select a communication interface; S14: Initialize the encryption and decryption chip and perform a power-on reset operation on the encryption and decryption chip to ensure that the chip is in an initial state; S15: Load the driver module and establish an application layer protocol for secure communication between the RISC-V architecture CPU and the encryption and decryption chip.

4. The firmware encryption method based on the RISC-V architecture server according to claim 3 is characterized in that: The encryption process in step S2 includes: a. First, generate a random symmetric key and encrypt the FSBL firmware file using the AES algorithm and the generated symmetric key; b. Then use the recipient's public key to encrypt the symmetric key, specifically use the OAEP padding scheme of the RSA algorithm to encrypt the symmetric key to generate an encrypted symmetric key; c. Calculate the hash value of the FSBL firmware, sign the hash value with the private key, generate a digital signature, and attach the digital signature to the encrypted FSBL firmware to obtain the packaged FSBL firmware package.

5. The firmware encryption method based on the RISC-V architecture server according to claim 4 is characterized in that: The decryption process in step S2 includes: A. Load the encrypted FSBL firmware package from the external storage device EMMC, and use the private key in the encryption chip to decrypt the symmetric key to obtain the symmetric key; B. Decrypt the encrypted FSBL firmware using the symmetric key decrypted by the private key to obtain the original FSBL firmware; C. Recalculate the hash value of the decrypted FSBL firmware, use the public key to verify the digital signature, and compare whether the calculated hash value is consistent with the hash value in the signature. If they are consistent, the signature verification passes and the FSBL continues to execute; otherwise, the boot process is stopped.

6. The firmware encryption method based on the RISC-V architecture server according to claim 4 is characterized in that: In step S3, the firmware verification process in the SBI, UEFI, and GRUB stages is the same. The firmware verification process in the SBI stage is as follows: S31: Generate the signature of the firmware in the development environment, calculate the hash value of the SBI firmware, and sign the calculated hash value using the RSA private key; S32: Recalculate the hash value of the loaded SBI firmware, and send the recalculated hash value and signature of the SBI firmware to the encryption chip for verification through the encryption chip API; the encryption chip verifies the signature using its internally stored public key and returns the verification result to ensure that the hash value of the signature is consistent with the recalculated hash value. If they are consistent, the verification passes and the SBI firmware is executed; otherwise, the verification fails and the startup stops.

7. The firmware encryption method based on the RISC-V architecture server according to claim 6 is characterized in that: In step S31, the hash value of the SBI firmware is calculated using the SHA-256 algorithm; in step S32, the hash value of the loaded SBI firmware is recalculated using the SHA-256 algorithm.

Images