Keystone-based risc-v small core firmware security loading method

Abstract

The application discloses a RISC-V small core firmware security loading method based on Keystone, and belongs to the technical field of firmware loading, and the method comprises the following steps: when small core firmware needs to be run, an Enclave is created on Keystone; the small core firmware is loaded from a file system to the shared memory of the Enclave and an operating system, and the small core firmware is previously added with a signature; after the Enclave verifies that the signature of the small core firmware is passed, the loading and running of the small core firmware are controlled. In the application, the small core firmware is located in the file system, so that the small core firmware can be conveniently modified and replaced; meanwhile, with the help of the Keystone software framework, a trusted execution environment is constructed in the user state of the RISC-V chip, the verification and loading of the small core firmware are safely and reliably completed, the small core firmware is safely loaded and the small core is started after the verification is passed, and the small core firmware is prevented from being tampered with by malicious programs in a non-secure execution environment.

Description

Technical Field

[0001] This invention relates to the field of firmware loading technology, and in particular to a secure firmware loading method for a RISC-V small core based on Keystone. Background Technology

[0002] The small core firmware stored in the file system may be maliciously modified. To ensure the integrity of the small core firmware, it is necessary to verify the firmware before loading it. Verification needs to be performed in a trusted execution environment to ensure the reliability of the results.

[0003] To address the issue of securely loading the little core firmware, one option is to directly boot the little core during the early stages of secure boot. However, this makes it inconvenient to modify the little core firmware and lacks flexibility. Alternatively, one could build a trusted execution environment after logging into the Linux system and securely load the little core firmware. The second approach has not yet been observed on the RISC-V platform. Summary of the Invention

[0004] The technical problem to be solved by this invention is to provide a secure loading method for Keystone-based RISC-V small core firmware that is easy to modify and has high security.

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0006] A secure firmware loading method for RISC-V little cores based on Keystone, comprising:

[0007] Step 1: When you need to run the small core firmware, create an Enclave on Keystone;

[0008] Step 2: Load the small kernel firmware from the file system into the shared memory of the Enclave and the operating system. The small kernel firmware is pre-signed.

[0009] Step 3: After Enclave verifies the signature of the small core firmware, it controls the loading and running of the small core firmware.

[0010] Furthermore, the procedure before step 1 includes:

[0011] Step 10: Add a signature to the small core firmware;

[0012] Step 10 includes:

[0013] Step 101: Generate a key pair, save the private key, and add the public key to Keystone's security monitor, SecureMonitor;

[0014] Step 102: Obtain the program header table of the small core firmware, calculate the hash value of all segments that need to be loaded, and combine these hash values ​​in order to form a hash table;

[0015] Step 103: Calculate the hash value of the hash table again and sign the value using the key generated in step 101;

[0016] Step 104: Append the signature, hash table, and file header indicating the location of the signature and hash table to the header of the small core firmware to form a small core firmware with signature.

[0017] Furthermore, in step 101, the key pair is the ed25519 key pair.

[0018] Furthermore, in steps 102 and 104, the small core firmware is the small core ELF firmware.

[0019] Furthermore, in steps 102 and 103, the hash value is calculated using the SHA3 algorithm.

[0020] Furthermore, in step 2, the file system is a Linux file system.

[0021] Furthermore, step 3 includes:

[0022] Step 31: Enclave copies the signature and hash table of the signed little-core firmware into Enclave's private secure memory;

[0023] Step 32: Calculate the hash value of the hash table in the private secure memory;

[0024] Step 33: Decrypt the signature value using the public key in the Secure Monitor;

[0025] Step 34: Compare the values ​​obtained in Step 32 and Step 33. If they are not equal, it means that the small core firmware is unauthorized firmware and the security loading fails. If they are equal, use PMP and IOPMP to protect the small core's running address space and continue loading the small core firmware in shared memory into the small core's running address space.

[0026] Furthermore, in step 32, the hash value is calculated using the SHA3 algorithm.

[0027] Furthermore, step 34 is followed by:

[0028] Step 35: After loading is complete, calculate the hash value of each segment in the small core's running address space according to the program header table of the small core firmware, and compare it with the hash table in the Enclave's private secure memory. If they are all consistent, the loading is successful and the small core is started; otherwise, the startup fails.

[0029] The present invention has the following beneficial effects:

[0030] Compared to traditional methods, verifying and loading the small core firmware during the initial boot process ensures secure startup, but firmware replacement is cumbersome. Storing the small core firmware in a higher-level file system facilitates replacement, but the user-space execution environment is less secure and vulnerable to attacks. In this invention, the small core firmware resides in the file system, facilitating modification and replacement. Furthermore, leveraging the Keystone software framework, a trusted execution environment is constructed in the user space of the RISC-V chip, securely and reliably completing the verification and loading of the small core firmware. Upon successful verification, the small core firmware is securely loaded and the small core is started, preventing malicious programs in insecure execution environments from tampering with the small core firmware. Attached Figure Description

[0031] Figure 1 This is a schematic diagram of the software architecture of Keystone in the prior art;

[0032] Figure 2 This is a flowchart illustrating the Keystone-based RISC-V small core firmware secure loading method of the present invention.

[0033] Figure 3 This is a schematic diagram of the process of adding a signature to the small core firmware in this invention;

[0034] Figure 4 This is a schematic diagram of the process for securely loading the small core firmware in this invention. Detailed Implementation

[0035] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0036] Keystone is an open framework for building Trusted Execution Environments (TEEs) on the RISC-V (Fifth Generation Reduced Instruction Set Computer) platform using Enclave. It allows users to flexibly build and run trusted applications without worrying about sensitive information leaks due to vulnerabilities in the Linux kernel and other software. Keystone's software architecture is as follows: Figure 1 As shown, where:

[0037] Trusted hardware is a combination of CPUs (central processing units) and other components built by a reliable vendor. It must include standard RISC-V cores compatible with Keystone and a root of trust. The hardware may also include optional features such as cache partitioning, memory encryption, and encrypted random sources.

[0038] Secure Monitor (SM) is M-mode (Machine mode) software with a small trusted computing base. SM provides an interface for managing the Enclave's lifecycle and utilizing platform-specific features. SM manages the isolation boundary between the Enclave and the untrusted operating system, providing security for Keystone.

[0039] An Enclave (an instance of a trusted execution environment, guaranteed by hardware isolation) is an environment isolated from untrusted operating systems and other Enclaves. Each Enclave has a private physical memory region accessible only to the Enclave and the Execution System (SM). Each Enclave consists of a User (U-mode) EnclaveApplication (eapp) and an Supervisor (S-mode) Runtime System (RT). In the diagram, the shaded boxes represent the untrusted region, App represents the application, and Operating System represents the operating system.

[0040] An Enclave Application (eapp) is a user-space application that runs within an Enclave. Users can build custom eapps from scratch.

[0041] The runtime system (RT) is S-mode software that implements functions such as system calls, trap handling, and virtual memory management.

[0042] This invention provides a secure firmware loading method for RISC-V little cores based on Keystone, such as... Figure 2 As shown, it includes:

[0043] Step 1: When you need to run the small core firmware, create an Enclave on Keystone;

[0044] Creating an Enclave in this step is a common technique in the field and will not be described in detail here.

[0045] Step 2: Load the small kernel firmware from the file system into the shared memory of the Enclave and the operating system. The small kernel firmware is pre-signed.

[0046] As an optional embodiment, in this step, the file system is preferably a Linux file system. In this case, the signed little kernel firmware is loaded from the file system into the shared memory of the Enclave and the Linux operating system.

[0047] As another optional embodiment, step 1 may be preceded by:

[0048] Step 10: Add a signature to the small core firmware;

[0049] refer to Figure 3 Step 10 may include:

[0050] Step 101: Generate a key pair, save the private key, and add the public key to Keystone's security monitor (SecureMonitor);

[0051] In this step, the key pair can be an ed25519 key pair. Specifically, a random number seed can be imported into the signature tool to generate an ed25519 key pair. This step corresponds to... Figure 3 The "Generate ed25519 key pair", "public key", "SecureMonitor", and "private key" are listed in the code.

[0052] Step 102: Obtain the program header table of the small core firmware, calculate the hash value of all segments that need to be loaded, and combine these hash values ​​in order to form a hash table.

[0053] In step 102 and subsequent step 104, the small-core firmware is preferably small-core ELF (binary format) firmware. In step 102 and subsequent step 103, the hash value calculation can both use the SHA3 (third-generation secure hash algorithm). Figure 3 As can be seen, the small-core ELF firmware includes n segments, namely Segment 1, Segment 2...Segment n; ELFHeader is the ELF file header, and Section Header Table is the section header table. This step 102 corresponds to... Figure 3 The options are "Hash(sha3)" and "Generate Hash Table" located at the bottom of the middle.

[0054] Step 103: Calculate the hash value of the hash table again, and sign the value using the key generated in step 101 (i.e., sign using the aforementioned private key);

[0055] This step corresponds to Figure 3 The top part of the text contains "Hash(sha3)" and "signature(ed25519)".

[0056] Step 104: Append the signature, hash table, and header indicating the location of the signature and hash table to the header of the small core firmware to form a small core firmware with signature.

[0057] The signed small-core firmware generated in this step corresponds to... Figure 3 The "Small Core Signed ELF Firmware" on the right side has added "Header", "Signature" and "Hash Table" compared to the original "Small Core ELF Firmware" on the left.

[0058] Thus, by following steps 101-104 above, a signature can be added to the small core firmware to facilitate security verification in subsequent steps.

[0059] Step 3: After Enclave verifies the signature of the small core firmware, it controls the loading and running of the small core firmware.

[0060] As an optional embodiment, refer to Figure 4 Step 3 may include:

[0061] Step 31: Enclave copies the signature and hash table of the signed small kernel firmware to Enclave's private secure memory;

[0062] This step corresponds to Figure 4 The word "Copy" in the text.

[0063] Step 32: Calculate the hash value of the hash table in the private secure memory;

[0064] In this step, the hash value can be calculated using the SHA3 algorithm. This step corresponds to... Figure 4 The "Hash(sha3)" in the Enclave.

[0065] Step 33: Decrypt the signature value using the public key in the Secure Monitor;

[0066] This step corresponds to Figure 4 "Decrypt" in Enclave.

[0067] Step 34: Compare the values ​​obtained in Step 32 and Step 33. If they are not equal, it means that the small core firmware is unauthorized firmware and the security loading has failed. If they are equal, use PMP (Physical Memory Protection) and IOPMP (I / O Physical Memory Protection) to protect the small core's running address space and continue loading the small core firmware in shared memory into the small core's running address space.

[0068] This step corresponds to Figure 4 The Enclave displays "Equal?", "Verification failed", and "Load small core firmware".

[0069] Thus, the secure loading of the small core firmware can be achieved through the above steps 31-34.

[0070] Furthermore, step 34 may be followed by:

[0071] Step 35: After loading is complete, calculate the hash value of each segment in the small core's running address space according to the program header table of the small core firmware, and compare it with the hash table in the Enclave's private secure memory. If they all match, the loading is successful and the small core is started; otherwise, the startup fails.

[0072] This allows for the secure operation of the small-core firmware. This step corresponds to... Figure 4 The Enclave displays the messages "Does segmenthash match hash table?", "Loading failed", and "Loading successful, starting small core".

[0073] In summary, in this invention, when the small core firmware needs to be run, an Enclave is first created, the small core firmware is loaded from the file system into shared memory, and after the Enclave verifies the firmware signature, it controls the loading and running of the small core firmware.

[0074] This invention proposes a secure loading method for RISC-V small core firmware based on Keystone. Relying on the trusted Secure Monitor firmware, it verifies the small core firmware stored in the Linux file system. After successful verification, the small core firmware is securely loaded and the small core is started, preventing malicious programs in insecure execution environments from tampering with the small core firmware.

[0075] Compared with traditional methods, the present invention has at least the following advantages:

[0076] 1. This invention is based on Keystone technology and utilizes PMP, IOPMP and different RISC-V privilege levels to build a trusted execution environment, which makes the verification loading of small core firmware safe and reliable.

[0077] 2. Compared to traditional methods, if the small core firmware is verified and loaded at the initial boot stage, it can ensure secure boot, but replacing the firmware is relatively cumbersome. If the small core firmware is stored in the upper-level file system, it is easy to replace, but the user-space execution environment is less secure and vulnerable to attacks. In this invention, the small core firmware is located in the file system, which is easy to modify and replace. At the same time, with the help of the Keystone software framework, a trusted execution environment is built in the user space of the RISC-V chip, which securely and reliably completes the verification and loading of the small core firmware.

[0078] 3. For heterogeneous multi-core systems, the boot process of the main core is basically the same as that of a single-core system, and common secure boot mechanisms can be used. However, the boot process of the small core also requires firmware verification to ensure its security and reliability. This invention, based on the Keystone software framework on the RISC-V architecture, implements secure verification and loading of the small core firmware in user space. It has broad application prospects in heterogeneous multi-core RISC-V chips.

[0079] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A secure firmware loading method for a RISC-V little core based on Keystone, characterized in that, include: Step 1: When you need to run the small core firmware, create an Enclave on Keystone; Step 2: Load the small kernel firmware from the file system into the shared memory of the Enclave and the operating system. The small kernel firmware is pre-signed. Step 3: After Enclave verifies the signature of the small core firmware, it controls the loading and running of the small core firmware; Step 3 includes: Step 31: Enclave copies the signature and hash table of the signed little core firmware to Enclave's private secure memory; Step 32: Calculate the hash value of the hash table in the private secure memory; Step 33: Decrypt the signature value using the public key in Secure Monitor; Step 34: Compare the values ​​obtained in Step 32 and Step 33. If they are not equal, it means that the small core firmware is unauthorized firmware and the security loading fails. If they are equal, use PMP and IOPMP to protect the small core's running address space and continue loading the small core firmware in shared memory into the small core's running address space.

2. The method according to claim 1, characterized in that, Before step 1, the following also applies: Step 10: Add a signature to the small core firmware; Step 10 includes: Step 101: Generate a key pair, save the private key, and add the public key to Keystone's security monitor, SecureMonitor; Step 102: Obtain the program header table of the small core firmware, calculate the hash value of all segments that need to be loaded, and combine these hash values ​​in order to form a hash table; Step 103: Calculate the hash value of the hash table again and sign the value using the key generated in step 101; Step 104: Append the signature, hash table, and file header indicating the location of the signature and hash table to the header of the small core firmware to form a small core firmware with signature.

3. The method according to claim 2, characterized in that, In step 101, the key pair is the ed25519 key pair.

4. The method according to claim 2, characterized in that, In steps 102 and 104, the small core firmware is the small core ELF firmware.

5. The method according to claim 2, characterized in that, In steps 102 and 103, the hash value is calculated using the SHA3 algorithm.

6. The method according to claim 1, characterized in that, In step 2, the file system is a Linux file system.

7. The method according to claim 1, characterized in that, In step 32, the hash value is calculated using the SHA3 algorithm.

8. The method according to claim 1, characterized in that, Step 34 is followed by: Step 35: After loading is complete, calculate the hash value of each segment in the small core's running address space according to the program header table of the small core firmware, and compare it with the hash table in the Enclave's private secure memory. If they are all consistent, the loading is successful and the small core is started; otherwise, the startup fails.

Images