Firmware secure boot method and system thereof

Abstract

The application relates to a firmware security starting method and system, which comprises the following steps: when a system on chip (SOC) is powered on, an SCP runs a boot loader image SCP_BL1 of the SCP stored in a ROM; the SCP_BL1 loads a boot loader image SCP_BL2 of the SCP from a SCP_QSPI_FLASH into a SCP_SRAM; the SCP_BL1 reads an algorithm flag bit in an eFuse, and obtains a preset signature authentication algorithm corresponding to the algorithm flag bit; the SCP_BL1 verifies the SCP_BL2 according to the preset signature authentication algorithm; when the SCP_BL2 fails to pass the verification, the SCP terminates the running; and when the SCP_BL2 passes the verification, the SCP jumps to run the SCP_BL2. Through the application, the technical problems that the existing SOC chip has high cost and development verification cost and the starting time of the whole system is long can be solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the SOC technical field, and particularly to a firmware security starting method and system thereof. BACKGROUND

[0002] In the current ARM platform System-on-Chip (SOC), there are two read-only memories (ROMs) in the SOC, one of which stores the boot loader image AP_BL1 of the application processor (AP), and the other stores the boot loader image SCP_BL1 of the system control processor (SCP). The versions of the two ROMs are considered to be secure. The SCP is the first part of the SOC to start, and is responsible for waking up the AP core. In this chip architecture, SCP_BL1 and AP_BL1 together act as the trusted root of the system, and together are responsible for the boot of the SOC. The specific process is shown in (1)-(12) as follows:

[0003] (1) The SOC is powered on, and SCP_BL1 in the ROM of the SCP is run from a specified address;

[0004] (2) SCP_BL1 resets the AP, and AP_BL1 in the ROM of the AP is run from a specified address;

[0005] (3) The SCP waits for an AP message;

[0006] (4) AP_BL1 loads AP_BL2, and the AP runs AP_BL2;

[0007] (5) AP_BL2 moves SCP_BL2 from an external non-volatile storage unit to the random access memory (RAM) of the AP;

[0008] (6) AP_BL2 performs security authentication on SCP_BL2, and sends a message to SCP_BL1 after the authentication is passed. If the authentication is not passed, the starting fails;

[0009] (7) SCP_BL1 receives the message sent by AP_BL2, parses the message, and sends a response message (handshake process) for further communication to the AP after the parsing is passed;

[0010] (8) AP_BL2 receives the response message sent by SCP_BL1, and further sends a DATA command to SCP_BL1 to transmit the image;

[0011] (9) After receiving the DATA command sent by AP, SCP_BL1 retrieves SCP_BL2 from the specified address and verifies SCP_BL2;

[0012] (10) After the verification is successful, SCP_BL1 sends a completion response message to AP_BL2. At this point, the inter-core communication process between AP_BL2 and SCP_BL1 ends.

[0013] (11) SCP_BL1 jumps to SCP_BL2 and continues running;

[0014] (12) AP continues to run AP_BL31, AP_BL32, AP_BL33 in sequence.

[0015] In the process of realizing this invention, the inventors discovered that the prior art has at least the following technical problems:

[0016] (i) There are two roots of trust in the SOC, which are stored in two ROMs respectively, resulting in high chip cost and development and verification cost.

[0017] (ii) During the SOC startup process, after AP_BL1 loads AP_BL2, AP_BL2 first moves SCP_BL2 from the external non-volatile storage unit to the AP's RAM. After verifying that SCP_BL2 is successful, it notifies SCP_BL1, which then moves SCP_BL2 from the AP's RAM to the SCP RAM. After the move is completed, SCP_BL1 jumps to SCP_BL2 to continue running. During this process, SCP_BL2 is moved twice, which increases the overall system startup time.

[0018] (iii) During the initial power-on startup phase of the SOC, there are multiple inter-core communications between AP_BL2 and SCP_BL1. After SCP_BL1 resets AP core0, AP_BL2 verifies SCP_BL2 and then notifies SCP_BL1. SCP_BL1 responds to AP_BL2 after moving SCP_BL2. This process involves multiple communications, and both sides are in a waiting state until the communication is completed. During this process, the inter-core communication between the two sides increases the overall startup time of the system. Summary of the Invention

[0019] The purpose of this invention is to propose a firmware secure boot method and system to solve the technical problems of high cost and development and verification cost of existing SOC chips, and long overall system boot time.

[0020] To achieve the above objectives, a first aspect of the present invention provides a firmware secure boot method, the method comprising:

[0021] When the System-on-Chip (SoC) is powered on, the System Control Processor (SCP) runs the bootloader image SCP_BL1 of the SCP stored in the Read-Only Memory (ROM).

[0022] The SCP_BL1 loads the SCP's bootloader image SCP_BL2 from the SCP's flash memory SCP_QSPI_FLASH into the SCP's static random access memory SCP_SRAM;

[0023] The SCP_BL1 reads the algorithm flag bit in the one-time programmable memory eFuse and obtains the corresponding preset signature authentication algorithm based on the algorithm flag bit;

[0024] The SCP_BL1 verifies the SCP_BL2 according to the preset signature authentication algorithm; when the SCP_BL2 fails to verify, the SCP terminates its operation; when the SCP_BL2 passes the verification, the SCP jumps to run the SCP_BL2.

[0025] Preferably, the bootloader image SCP_BL2 includes the version information, root public key, and signature of SCP_BL2;

[0026] Wherein, SCP_BL1 verifies SCP_BL2 according to the preset signature authentication algorithm, including:

[0027] The root public key of SCP_BL2 is hashed according to the preset signature authentication algorithm to obtain the first calculation result;

[0028] Read the preset hash value from the eFuse and compare the first calculation result with the preset hash value;

[0029] If the first calculation result is not equal to the preset hash value, then the SCP_BL2 verification fails;

[0030] If the first calculation result is equal to the preset hash value, then the version information of SCP_BL2 is hashed using the preset signature authentication algorithm to obtain the second calculation result; and the signature of SCP_BL2 is decrypted using the preset signature authentication algorithm and the root public key of SCP_BL2 to obtain the third calculation result.

[0031] Compare the second calculation result with the third calculation result;

[0032] If the second calculation result and the third calculation result are not equal, then the SCP_BL2 verification fails.

[0033] If the second calculation result and the third calculation result are equal, then the SCP_BL2 verification is successful.

[0034] Preferably, the SCP_BL1 verifies the SCP_BL2 according to the preset signature authentication algorithm, specifically including:

[0035] The SCP_BL1 configures the preset signature authentication algorithm to the security module, calculates the first calculation result through the Hash engine of the security module, and calculates the second calculation result and the third calculation result through the RSA engine of the security module.

[0036] Preferably, the method further includes:

[0037] The SCP_BL2 loads the bootloader image AP_BL2 of the application processor AP from the SCP_QSPI_FLASH into the double data rate synchronous dynamic random access memory DDR;

[0038] The SCP_BL2 reads the algorithm flag bit in the eFuse and obtains the corresponding preset signature authentication algorithm based on the algorithm flag bit;

[0039] The SCP_BL2 verifies the AP_BL2 according to the preset signature authentication algorithm; when the AP_BL2 verification fails, the SCP_BL2 does not wake up the AP; when the AP_BL2 verification succeeds, the SCP_BL2 wakes up the AP.

[0040] After being woken up, the AP runs AP_BL2.

[0041] Preferably, the bootloader image AP_BL2 includes AP_BL2 version information, root public key, and signature;

[0042] The SCP_BL2 verifies the AP_BL2 according to the preset signature authentication algorithm, including:

[0043] The root public key of AP_BL2 is hashed according to the preset signature authentication algorithm to obtain the fourth calculation result;

[0044] Read the preset hash value from the eFuse and compare the fourth calculation result with the preset hash value;

[0045] If the fourth calculation result is not equal to the preset hash value, then the AP_BL2 verification fails.

[0046] If the fourth calculation result is equal to the preset hash value, then the version information of AP_BL2 is hashed using the preset signature authentication algorithm to obtain the fifth calculation result; and the signature of AP_BL2 is decrypted using the preset signature authentication algorithm and the root public key of AP_BL2 to obtain the sixth calculation result.

[0047] Compare the fifth calculation result with the sixth calculation result;

[0048] If the fifth calculation result and the sixth calculation result are not equal, then the AP_BL2 verification fails.

[0049] If the fifth calculation result and the sixth calculation result are equal, then the AP_BL2 verification is successful.

[0050] Preferably, the SCP_BL2 verifies the AP_BL2 according to the preset signature authentication algorithm, specifically including:

[0051] The SCP_BL2 configures the preset signature authentication algorithm to the security module, calculates the fourth calculation result through the Hash engine of the security module, and calculates the fifth and sixth calculation results through the RSA engine of the security module.

[0052] Preferably, the method further includes:

[0053] When the AP runs AP_BL2, AP_BL2 loads the AP's bootloader image AP_BL31 from the AP's flash memory AP_QSPI_FLASH into the DDR;

[0054] The AP_BL2 reads the algorithm flag bit in the eFuse and obtains the corresponding preset signature authentication algorithm based on the algorithm flag bit;

[0055] The AP_BL2 verifies the AP_BL31 according to the preset signature authentication algorithm; when the AP_BL31 fails to verify, the AP terminates its operation; when the AP_BL31 passes the verification, the AP jumps to run the AP_BL31.

[0056] Preferably, the bootloader image AP_BL31 includes version information of AP_BL31, root public key, and signature;

[0057] Wherein, AP_BL2 verifies AP_BL31 according to the preset signature authentication algorithm, including:

[0058] The root public key of AP_BL31 is hashed according to the preset signature authentication algorithm to obtain the seventh calculation result;

[0059] Read the preset hash value from the eFuse and compare the seventh calculation result with the preset hash value;

[0060] If the seventh calculation result is not equal to the preset hash value, then the AP_BL31 verification fails.

[0061] If the seventh calculation result is equal to the preset hash value, then the version information of AP_BL31 is hashed using the preset signature authentication algorithm to obtain the eighth calculation result; and the signature of AP_BL31 is decrypted using the preset signature authentication algorithm and the root public key of AP_BL31 to obtain the ninth calculation result.

[0062] Compare the eighth calculation result with the ninth calculation result;

[0063] If the eighth calculation result and the ninth calculation result are not equal, then the AP_BL31 verification fails.

[0064] If the eighth calculation result is equal to the ninth calculation result, then the AP_BL31 verification is successful.

[0065] Preferably, AP_BL2 verifies AP_BL31 according to the preset signature authentication algorithm, specifically including:

[0066] The AP_BL2 configures the preset signature authentication algorithm to the security module, calculates the seventh calculation result through the Hash engine of the security module, and calculates the eighth and ninth calculation results through the RSA engine of the security module.

[0067] Preferably, the method further includes:

[0068] When the AP finishes running AP_BL31, the AP jumps to run AP_BL2. At this time, AP_BL2 loads the AP's bootloader image AP_BL32 from the AP_QSPI_FLASH into the DDR.

[0069] The AP_BL2 reads the algorithm flag bit in the eFuse and obtains the corresponding preset signature authentication algorithm based on the algorithm flag bit;

[0070] The AP_BL2 verifies the AP_BL32 according to the preset signature authentication algorithm; when the AP_BL32 verification fails, the AP terminates its operation; when the AP_BL32 verification passes, the AP jumps to run the AP_BL32.

[0071] Preferably, the bootloader image AP_BL32 includes AP_BL32 version information, root public key, and signature;

[0072] Wherein, AP_BL2 verifies AP_BL32 according to the preset signature authentication algorithm, including:

[0073] The root public key of AP_BL32 is hashed according to the preset signature authentication algorithm to obtain the tenth calculation result;

[0074] Read the preset hash value from the eFuse and compare the tenth calculation result with the preset hash value;

[0075] If the tenth calculation result is not equal to the preset hash value, then the AP_BL32 verification fails.

[0076] If the tenth calculation result is equal to the preset hash value, then the version information of AP_BL32 is hashed using the preset signature authentication algorithm to obtain the eleventh calculation result; and the signature of AP_BL32 is decrypted using the preset signature authentication algorithm and the root public key of AP_BL32 to obtain the twelfth calculation result.

[0077] Compare the eleventh calculation result with the twelfth calculation result;

[0078] If the eleventh calculation result and the twelfth calculation result are not equal, then the AP_BL32 verification fails.

[0079] If the eleventh calculation result is equal to the twelfth calculation result, then the AP_BL32 verification is successful.

[0080] Preferably, AP_BL2 verifies AP_BL32 according to the preset signature authentication algorithm, specifically including:

[0081] The AP_BL2 configures the preset signature authentication algorithm to the security module, calculates the tenth calculation result through the Hash engine of the security module, and calculates the eleventh and twelfth calculation results through the RSA engine of the security module.

[0082] Preferably, the method further includes:

[0083] When the AP finishes running AP_BL32, the AP jumps to run AP_BL2. At this time, AP_BL2 loads the AP's bootloader image AP_BL33 from AP_QSPI_FLASH into the DDR.

[0084] The AP_BL2 reads the algorithm flag bit in the eFuse and obtains the corresponding preset signature authentication algorithm based on the algorithm flag bit;

[0085] The AP_BL2 verifies the AP_BL33 according to the preset signature authentication algorithm; when the AP_BL33 verification fails, the AP terminates its operation; when the AP_BL33 verification passes, the AP jumps to run the AP_BL33 and starts the kernel through the AP_BL33.

[0086] Preferably, the bootloader image AP_BL33 includes AP_BL33 version information, root public key, and signature;

[0087] Wherein, AP_BL2 verifies AP_BL33 according to the preset signature authentication algorithm, including:

[0088] The root public key of AP_BL33 is hashed according to the preset signature authentication algorithm to obtain the thirteenth calculation result;

[0089] Read the preset hash value from the eFuse and compare the thirteenth calculation result with the preset hash value;

[0090] If the thirteenth calculation result is not equal to the preset hash value, then the AP_BL33 verification fails.

[0091] If the thirteenth calculation result is equal to the preset hash value, then the version information of AP_BL33 is hashed using the preset signature authentication algorithm to obtain the fourteenth calculation result; and the signature of AP_BL33 is decrypted using the preset signature authentication algorithm and the root public key of AP_BL33 to obtain the fifteenth calculation result.

[0092] Compare the fourteenth calculation result with the fifteenth calculation result;

[0093] If the fourteenth calculation result and the fifteenth calculation result are not equal, then the AP_BL33 verification fails.

[0094] If the fourteenth calculation result and the fifteenth calculation result are equal, then the AP_BL33 verification is successful.

[0095] Preferably, AP_BL2 verifies AP_BL33 according to the preset signature authentication algorithm, specifically including:

[0096] The AP_BL2 configures the preset signature authentication algorithm to the security module, calculates the thirteenth calculation result through the Hash engine of the security module, and calculates the fourteenth and fifteenth calculation results through the RSA engine of the security module.

[0097] Preferably, the method further includes:

[0098] The SCP_BL2 loads the manageability control processor MCP bootloader image MCP_BL from the SCP_QSPI_FLASH into the MCP's static random access memory MCP_SRAM.

[0099] The SCP_BL2 reads the algorithm flag bit in the eFuse and obtains the corresponding preset signature authentication algorithm based on the algorithm flag bit;

[0100] The SCP_BL2 verifies the MCP_BL according to the preset signature authentication algorithm; when the MCP_BL verification fails, the SCP_BL2 does not wake up the MCP; when the MCP_BL verification passes, the SCP_BL2 wakes up the MCP.

[0101] Preferably, the bootloader image MCP_BL includes the version information, root public key, and signature of MCP_BL;

[0102] Wherein, SCP_BL2 verifies MCP_BL according to the preset signature authentication algorithm, including:

[0103] The root public key of MCP_BL is hashed according to the preset signature authentication algorithm to obtain the sixteenth calculation result;

[0104] Read the preset hash value from the eFuse and compare the sixteenth calculation result with the preset hash value;

[0105] If the sixteenth calculation result is not equal to the preset hash value, then the MCP_BL verification fails.

[0106] If the sixteenth calculation result is equal to the preset hash value, then the version information of the MCP_BL is hashed using the preset signature authentication algorithm to obtain the seventeenth calculation result; and the signature of the MCP_BL is decrypted using the preset signature authentication algorithm and the root public key of the MCP_BL to obtain the eighteenth calculation result.

[0107] Compare the seventeenth calculation result with the eighteenth calculation result;

[0108] If the seventeenth calculation result and the eighteenth calculation result are not equal, then the MCP_BL verification fails.

[0109] If the seventeenth calculation result and the eighteenth calculation result are equal, then the MCP_BL verification is successful.

[0110] Preferably, the SCP_BL2 verifies the MCP_BL according to the preset signature authentication algorithm, specifically including:

[0111] The SCP_BL2 configures the preset signature authentication algorithm to the security module, calculates the sixteenth calculation result through the Hash engine of the security module, and calculates the seventeenth and eighteenth calculation results through the RSA engine of the security module.

[0112] A second aspect of the present invention provides a firmware secure boot system, comprising a system control processor (SCP), a read-only memory (ROM), a flash memory (SCP_QSPI_FLASH), a static random access memory (SCP_SRAM), and a one-time programmable memory (eFuse).

[0113] A third aspect of the present invention provides a firmware secure boot system, comprising a system control processor (SCP), a read-only memory (ROM), a flash memory (SCP_QSPI_FLASH), a static random access memory (SCP_SRAM), a one-time programmable memory (eFuse), and a security module, wherein the security module includes a hash engine and an RSA engine.

[0114] The fourth aspect of the present invention provides a firmware secure boot system, comprising a system control processor (SCP), a read-only memory (ROM), a flash memory (SCP_QSPI_FLASH), a static random access memory (SCP_SRAM), a one-time programmable memory (eFuse), a security module, an application processor (AP), and a double-rate synchronous dynamic random access memory (DDR), wherein the security module includes a hash engine and an RSA engine.

[0115] The fifth aspect of the present invention provides a firmware secure boot system, comprising a system control processor SCP, a read-only memory ROM, a flash memory SCP_QSPI_FLASH, a static random access memory SCP_SRAM, a one-time programmable memory eFuse, a security module, an application processor AP, a double rate synchronous dynamic random access memory DDR, a manageability control processor MCP, and a static random access memory MCP_SRAM, wherein the security module includes a hash engine and an RSA engine.

[0116] Compared with the prior art, the present invention has the following beneficial effects:

[0117] (1) In the SOC system of the present invention, only one ROM is set up. The ROM stores SCP_BL1. SCP is the only root of trust of the entire SOC. External access to SCP is strictly restricted. At the same time, all external access to SCP is regarded as secure access. Compared with the SOC that uses two roots of trust, the present invention can reduce chip cost and development and verification costs of the correctness and stability of the image version in ROM.

[0118] (2) In the secure boot process of SCP firmware, SCP starts from ROM to perform secure boot and runs SCP_BL1, which is responsible for the secure boot of the first stage of software. During the loading of SCP_BL2 by SCP_BL1, SCP does not need to communicate with AP between cores, which helps to reduce the overall boot time of the system. It is suitable for scenarios with strict requirements for boot and reset time, such as cloud servers and data centers.

[0119] Other features and advantages of the present invention will be set forth in the following description. Attached Figure Description

[0120] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings required in the description of the embodiments or the prior art based on the preset signature authentication algorithm will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0121] Figure 1 This is a flowchart of a firmware secure boot method according to Embodiment 1 of the present invention.

[0122] Figure 2 This is a flowchart of a firmware secure boot method according to Embodiment 3 of the present invention.

[0123] Figure 3 This is a flowchart of a firmware secure boot method according to Embodiment 4 of the present invention. Detailed Implementation

[0124] The detailed description of the accompanying drawings is intended to illustrate the presently preferred embodiments of the invention and is not intended to represent only the forms in which the invention can be implemented. It should be understood that the same or equivalent functions can be accomplished by different embodiments intended to be included within the spirit and scope of the invention.

[0125] Example 1

[0126] Embodiment 1 of the present invention proposes a firmware secure boot method, see below. Figure 1 The method in Example 1 includes the following steps S1 to S4:

[0127] Step S1: When the system on-chip (SOC) is powered on, the system control processor (SCP) runs the bootloader image SCP_BL1 of the SCP stored in the read-only memory (ROM).

[0128] Specifically, the Boot Loader is a small program that runs before the operating system kernel. This program initializes hardware devices and establishes a memory space mapping, thereby bringing the system's hardware and software environment to a suitable state to prepare the correct environment for the final call to the operating system kernel. This small program is the bootloader. In this embodiment, the bootloader is divided into multiple parts, and firmware images of them are created. Each image contains corresponding version information, root public key, and signature. Each image is backed up in a trusted area. Here, an image is a form of file storage and a type of redundancy. A mirror is a copy of data on one disk that exists exactly on another disk.

[0129] For SCP, there are two bootloader images: SCP_BL1 (first stage) and SCP_BL2 (second stage). SCP_BL1 serves as the sole root of trust for the SOC and is the first to be automatically started and run after the SOC is powered on.

[0130] Step S2: SCP_BL1 loads the bootloader image SCP_BL2 of the SCP from the flash memory SCP_QSPI_FLASH of the SCP into the static random access memory SCP_SRAM of the SCP;

[0131] Specifically, when SCP_BL1 is running, SCP_BL1 loads SCP_BL2 into SCP_SRAM and then performs security verification on it, as shown in steps S3-S4 below;

[0132] Step S3: The SCP_BL1 reads the algorithm flag bit in the one-time programmable memory eFuse, and obtains the corresponding preset signature authentication algorithm according to the algorithm flag bit;

[0133] Specifically, the eFuse writes an algorithm flag bit at the factory, and this algorithm flag bit cannot be changed after it is written.

[0134] Step S4: SCP_BL1 verifies SCP_BL2 according to the preset signature authentication algorithm; when SCP_BL2 fails verification, the SCP terminates operation; when SCP_BL2 passes verification, the SCP jumps to run SCP_BL2.

[0135] Specifically, when the SCP runs SCP_BL2, the firmware secure boot of this SCP is successful; when the SCP terminates, the firmware secure boot of this SCP fails.

[0136] It should be noted that SCP_BL1 is stored in a read-only memory (ROM). Since the entity in the ROM is burned once at the factory, the entity cannot be tampered with during startup, ensuring the integrity of the startup entity. At the same time, it can also be understood that since SCP_BL1 cannot be modified or adjusted later, its version correctness and stability requirements are very high. Existing chip architectures that use two ROMs to store SCP_BL1 and AP_BL1 as two roots of trust respectively require repeated verification of the correctness and stability of the SCP_BL1 and AP_BL1 versions in the two ROMs. This results in a large number of ROMs, which increases chip cost, and repeated verification of the correctness and stability of the SCP_BL1 and AP_BL1 versions, which increases development and verification costs. In contrast, the SOC system in this embodiment of the invention only sets up one ROM, which stores SCP_BL1. SCP is the only root of trust for the entire SOC. External access to SCP is strictly restricted, and all external access to SCP is considered secure access. Compared with the SOC using two roots of trust, the AP ROM is reduced, which can reduce chip cost and development and verification costs for the correctness and stability of the image version in the ROM.

[0137] Furthermore, it should be noted that in the secure boot process of the SCP firmware in this embodiment of the invention, the SCP starts secure boot from the ROM and runs SCP_BL1, which is responsible for the secure boot of the first stage of the software. During the loading of SCP_BL2 by SCP_BL1, the SCP does not need to communicate with the AP between cores, which helps to reduce the overall system boot time. This is suitable for scenarios with strict requirements for boot and reset time, such as cloud servers and data centers.

[0138] Furthermore, the bootloader image SCP_BL2 includes the version information, root public key, and signature of SCP_BL2;

[0139] In step S4, SCP_BL1 verifies SCP_BL2 according to the preset signature authentication algorithm, including:

[0140] Step S41: Perform a hash calculation on the root public key of SCP_BL2 according to the preset signature authentication algorithm to obtain the first calculation result;

[0141] Step S42: Read the preset hash value in the eFuse and compare the first calculation result with the preset hash value;

[0142] Specifically, the preset hash value is written to the eFuse at the time of manufacture, and the preset hash value cannot be changed after it is written.

[0143] Step S43: If the first calculation result is not equal to the preset hash value, then the SCP_BL2 verification fails;

[0144] Specifically, if the first calculation result is not equal to the preset hash value, it means that the SCP_BL2 was not issued by the signature center;

[0145] Step S44: If the first calculation result is equal to the preset hash value, then perform SHA256 hash calculation on the version information of SCP_BL2 according to the preset signature authentication algorithm to obtain the second calculation result; and decrypt the signature of SCP_BL2 according to the preset signature authentication algorithm and the root public key of SCP_BL2 to obtain the third calculation result.

[0146] Specifically, if the first calculation result is equal to the preset hash value, it indicates that the SCP_BL2 was issued by the signature center;

[0147] SHA256 is a hash function, a sub-algorithm of SHA-2. SHA-2 stands for Secure Hash Algorithm 2, a cryptographic hash function algorithm standard, one of the SHA algorithms, and the successor to SHA-1. SHA-2 can be further divided into six different algorithm standards, including: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512 / 224, and SHA-512 / 256.

[0148] Step S45: Compare the second calculation result and the third calculation result; if the second calculation result and the third calculation result are not equal, the SCP_BL2 verification fails; if the second calculation result and the third calculation result are equal, the SCP_BL2 verification passes.

[0149] Specifically, if the second calculation result and the third calculation result are not equal, it means that SCP_BL2 has been tampered with; if the second calculation result and the third calculation result are equal, it means that SCP_BL2 has not been tampered with.

[0150] It should be noted that the SCP jump to run SCP-BL2 mentioned in this embodiment refers to the version information of SCP-BL2. Version information is firmware code. In order to facilitate the differentiation of different versions of firmware code, different versions of firmware code are also referred to as version information in this field.

[0151] In this embodiment, SCP-BL1 is used to load and run SCP-BL2. SCP-BL2 is mainly used to implement functions such as MHU (inter-core communication), power management, power domain management, temperature monitoring, and peripheral initialization (I2C, PLL). It should be noted that SCP-BL1 and SCP-BL2 are two-level bootloaders for SCP. In practical applications, the program code of SCP-BL1 and SCP-BL2 can be customized to adjust / extend their functions. This is only a brief introduction to the functions of SCP-BL2. The purpose of this embodiment is mainly to improve the secure boot of SCP firmware to solve the technical problems of high cost and development verification cost of existing SOC chips and long overall system boot time. Therefore, other specific functions of SCP-BL2 will not be described in detail.

[0152] Example 2

[0153] Based on the above embodiment one, the method of embodiment two of the present invention further includes:

[0154] In step S4, SCP_BL1 verifies SCP_BL2 according to the preset signature authentication algorithm, specifically including:

[0155] The SCP_BL1 configures the preset signature authentication algorithm to the security module, calculates the first calculation result through the Hash engine of the security module, and calculates the second calculation result and the third calculation result through the RSA (Rivest-Shamir-Adleman) engine of the security module;

[0156] Specifically, the security module Crypto in this embodiment is a module that performs security authentication on the image during the secure boot process. It includes a hash engine and an RSA engine. During the secure boot phase, Crypto's hash engine and RSA engine will verify the image SCP_BL2 in the SCP_SRAM according to the preset signature authentication algorithm.

[0157] Example 3

[0158] Based on the above embodiments one and two, this invention proposes embodiment three, see below. Figure 2 The method in Embodiment 3 of the present invention further includes:

[0159] Step S5: The SCP_BL2 loads the bootloader image AP_BL2 of the application processor AP from the SCP_QSPI_FLASH into the double data rate synchronous dynamic random access memory DDR;

[0160] Step S6: The SCP_BL2 reads the algorithm flag bit in the eFuse and obtains the corresponding preset signature authentication algorithm based on the algorithm flag bit;

[0161] Step S7: SCP_BL2 verifies AP_BL2 according to the preset signature authentication algorithm; when AP_BL2 fails verification, SCP_BL2 does not wake up AP; when AP_BL2 passes verification, SCP_BL2 wakes up AP.

[0162] Step S8: After the AP is woken up, the AP runs AP_BL2.

[0163] Specifically, for AP, it includes bootloader images AP_BL2, AP_BL31, AP_BL32, and AP_BL33;

[0164] It should be noted that in the existing firmware secure boot method, after AP_BL1 loads AP_BL2 during the boot process, AP_BL2 first moves SCP_BL2 from the external non-volatile memory to the AP's RAM. After verifying SCP_BL2, it notifies SCP_BL1, which then moves SCP_BL1 from the AP's RAM to the SCP RAM. After the move is complete, SCP_BL1 jumps to SCP_BL2 to continue running. During this process, SCP_BL2 is moved twice, increasing the overall system boot time. There are multiple inter-core communications between AP_BL2 and SCP_BL1, and SCP_BL1 resets the AP... After core0 is completed, AP_BL2 verifies SCP_BL2 and then notifies SCP_BL1. SCP_BL1 then responds to AP_BL2 after moving SCP_BL2, which involves multiple communications. Compared with the existing firmware secure boot method, the method of Embodiment 3 of this invention saves the image AP_BL1. It is equivalent to SCP_BL2 already containing the functions of the original AP_BL1, which can reduce the AP's SRAM. In terms of boot time, the inter-core communication process is eliminated. SCP_BL2 decrypts and authenticates the image AP_BL2. After successful authentication, the AP can be de-reset and booted from the specified address. After the AP runs AP_BL2, it automatically loads authentication and runs images AP_BL31, AP_BL32, and AP_BL33 in sequence.

[0165] Furthermore, the bootloader image AP_BL2 includes AP_BL2 version information, root public key, and signature;

[0166] In step S7, SCP_BL2 verifies AP_BL2 according to the preset signature authentication algorithm, including:

[0167] Step S71: Perform a hash calculation on the root public key of AP_BL2 according to the preset signature authentication algorithm to obtain the fourth calculation result;

[0168] Step S72: Read the preset hash value in the eFuse and compare the fourth calculation result with the preset hash value;

[0169] Step S73: If the fourth calculation result is not equal to the preset hash value, then the AP_BL2 verification fails;

[0170] Specifically, if the fourth calculation result is not equal to the preset hash value, it means that AP_BL2 was not issued by the signature center;

[0171] Step S74: If the fourth calculation result is equal to the preset hash value, then perform SHA256 hash calculation on the version information of AP_BL2 according to the preset signature authentication algorithm to obtain the fifth calculation result; and decrypt the signature of AP_BL2 according to the preset signature authentication algorithm and the root public key of AP_BL2 to obtain the sixth calculation result.

[0172] Specifically, if the fourth calculation result is equal to the preset hash value, it indicates that AP_BL2 was issued by the signature center;

[0173] Step S75: Compare the fifth calculation result with the sixth calculation result; if the fifth calculation result and the sixth calculation result are not equal, the AP_BL2 verification fails; if the fifth calculation result and the sixth calculation result are equal, the AP_BL2 verification passes.

[0174] Specifically, if the fifth calculation result and the sixth calculation result are not equal, it means that AP_BL2 has been tampered with; if the fifth calculation result and the sixth calculation result are equal, it means that AP_BL2 has not been tampered with.

[0175] Further, in step S7, SCP_BL2 verifies AP_BL2 according to the preset signature authentication algorithm, specifically including:

[0176] The SCP_BL2 configures the preset signature authentication algorithm to the security module, calculates the fourth calculation result through the Hash engine of the security module, and calculates the fifth and sixth calculation results through the RSA engine of the security module.

[0177] It should be noted that the security authentication method for AP_BL2 in this embodiment is similar to the security authentication method for SCP_BL2 described above. Both methods configure the preset signature authentication algorithm into the security module and use the preset signature authentication algorithm for authentication.

[0178] Furthermore, the method in this embodiment also includes:

[0179] Step S9: When the AP runs AP_BL2, AP_BL2 loads the AP's bootloader image AP_BL31 from the AP's flash memory AP_QSPI_FLASH into the DDR;

[0180] Step S10: AP_BL2 reads the algorithm flag bit in the eFuse and obtains the corresponding preset signature authentication algorithm according to the algorithm flag bit;

[0181] Step S11: AP_BL2 verifies AP_BL31 according to the preset signature authentication algorithm; when AP_BL31 fails verification, AP terminates operation; when AP_BL31 passes verification, AP jumps to run AP_BL31.

[0182] Furthermore, the bootloader image AP_BL31 includes AP_BL31 version information, root public key, and signature;

[0183] In step S11, AP_BL2 verifies AP_BL31 according to the preset signature authentication algorithm, including:

[0184] Step S111: Perform a hash calculation on the root public key of AP_BL31 according to the preset signature authentication algorithm to obtain the seventh calculation result;

[0185] Step S112: Read the preset hash value in the eFuse and compare the seventh calculation result with the preset hash value;

[0186] Step S113: If the seventh calculation result is not equal to the preset hash value, then the AP_BL31 verification fails;

[0187] Specifically, if the seventh calculation result is not equal to the preset hash value, it means that AP_BL31 was not issued by the signature center;

[0188] Step S114: If the seventh calculation result is equal to the preset hash value, then perform SHA256 hash calculation on the version information of AP_BL31 according to the preset signature authentication algorithm to obtain the eighth calculation result; and decrypt the signature of AP_BL31 according to the preset signature authentication algorithm and the root public key of AP_BL31 to obtain the ninth calculation result.

[0189] Specifically, if the seventh calculation result is equal to the preset hash value, it indicates that AP_BL31 was issued by the signature center;

[0190] Step S115: Compare the eighth calculation result with the ninth calculation result; if the eighth calculation result and the ninth calculation result are not equal, the AP_BL31 verification fails; if the eighth calculation result and the ninth calculation result are equal, the AP_BL31 verification passes.

[0191] Specifically, if the eighth calculation result and the ninth calculation result are not equal, it indicates that AP_BL31 has been tampered with; if the eighth calculation result and the ninth calculation result are equal, it indicates that AP_BL31 has not been tampered with. Further, in step S11, AP_BL2 verifies AP_BL31 according to the preset signature authentication algorithm, specifically including:

[0192] The AP_BL2 configures the preset signature authentication algorithm to the security module, calculates the seventh calculation result through the Hash engine of the security module, and calculates the eighth and ninth calculation results through the RSA engine of the security module.

[0193] It should be noted that the security authentication method for AP_BL31 in this embodiment is similar to the security authentication methods for SCP_BL2 and AP_BL2 described above. In both cases, the preset signature authentication algorithm is configured in the security module and the preset signature authentication algorithm is used for authentication.

[0194] Furthermore, the method in this embodiment also includes:

[0195] Step S12: When the AP finishes running AP_BL31, the AP jumps to run AP_BL2. At this time, AP_BL2 loads the AP's bootloader image AP_BL32 from AP_QSPI_FLASH into the DDR.

[0196] Step S13: AP_BL2 reads the algorithm flag bit in the eFuse and obtains the corresponding preset signature authentication algorithm according to the algorithm flag bit;

[0197] Step S14: AP_BL2 verifies AP_BL32 according to the preset signature authentication algorithm; when AP_BL32 fails verification, AP terminates operation; when AP_BL32 passes verification, AP jumps to run AP_BL32.

[0198] Furthermore, the bootloader image AP_BL32 includes AP_BL32 version information, root public key, and signature;

[0199] In step S14, AP_BL2 verifies AP_BL32 according to the preset signature authentication algorithm, including:

[0200] Step S141: Perform a hash calculation on the root public key of AP_BL32 according to the preset signature authentication algorithm to obtain the tenth calculation result;

[0201] Step S142: Read the preset hash value in the eFuse and compare the tenth calculation result with the preset hash value;

[0202] Step S143: If the tenth calculation result is not equal to the preset hash value, then the AP_BL32 verification fails;

[0203] Specifically, if the tenth calculation result is not equal to the preset hash value, it means that AP_BL32 was not issued by the signature center;

[0204] Step S144: If the tenth calculation result is equal to the preset hash value, then perform SHA256 hash calculation on the version information of AP_BL32 according to the preset signature authentication algorithm to obtain the eleventh calculation result; and decrypt the signature of AP_BL32 according to the preset signature authentication algorithm and the root public key of AP_BL32 to obtain the twelfth calculation result.

[0205] Specifically, if the tenth calculation result is equal to the preset hash value, it indicates that AP_BL32 was issued by the signature center;

[0206] Step S145: Compare the eleventh calculation result with the twelfth calculation result; if the eleventh calculation result and the twelfth calculation result are not equal, the AP_BL32 verification fails; if the eleventh calculation result and the twelfth calculation result are equal, the AP_BL32 verification passes.

[0207] Specifically, if the eleventh calculation result and the twelfth calculation result are not equal, it means that AP_BL32 has been tampered with; if the eleventh calculation result and the twelfth calculation result are equal, it means that AP_BL32 has not been tampered with.

[0208] Further, in step S14, AP_BL2 verifies AP_BL32 according to the preset signature authentication algorithm, specifically including:

[0209] The AP_BL2 configures the preset signature authentication algorithm to the security module, calculates the tenth calculation result through the Hash engine of the security module, and calculates the eleventh and twelfth calculation results through the RSA engine of the security module.

[0210] It should be noted that the security authentication method for AP_BL32 in this embodiment is similar to the security authentication methods for SCP_BL2, AP_BL2, and AP_BL2 described above. In both cases, the preset signature authentication algorithm is configured in the security module and the preset signature authentication algorithm is used for authentication.

[0211] Furthermore, the method in this embodiment also includes:

[0212] Step S15: When the AP finishes running AP_BL32, the AP jumps to run AP_BL2. At this time, AP_BL2 loads the AP's bootloader image AP_BL33 from the AP_QSPI_FLASH into the DDR.

[0213] Step S16: AP_BL2 reads the algorithm flag bit in the eFuse and obtains the corresponding preset signature authentication algorithm according to the algorithm flag bit;

[0214] Step S17: AP_BL2 verifies AP_BL33 according to the preset signature authentication algorithm; when AP_BL33 fails verification, AP terminates operation; when AP_BL33 passes verification, AP jumps to run AP_BL33 and starts the kernel through AP_BL33.

[0215] Furthermore, the bootloader image AP_BL33 includes AP_BL33 version information, root public key, and signature;

[0216] In step S17, AP_BL2 verifies AP_BL33 according to the preset signature authentication algorithm, including:

[0217] Step S171: Perform a hash calculation on the root public key of AP_BL33 according to the preset signature authentication algorithm to obtain the thirteenth calculation result;

[0218] Step S172: Read the preset hash value in the eFuse and compare the thirteenth calculation result with the preset hash value;

[0219] Step S173: If the thirteenth calculation result is not equal to the preset hash value, then the AP_BL33 verification fails.

[0220] Specifically, if the thirteenth calculation result is not equal to the preset hash value, it means that AP_BL33 was not issued by the signature center;

[0221] Step S174: If the thirteenth calculation result is equal to the preset hash value, then perform SHA256 hash calculation on the version information of AP_BL33 according to the preset signature authentication algorithm to obtain the fourteenth calculation result; and decrypt the signature of AP_BL33 according to the preset signature authentication algorithm and the root public key of AP_BL33 to obtain the fifteenth calculation result.

[0222] Specifically, if the thirteenth calculation result is equal to the preset hash value, it indicates that AP_BL33 was issued by the signature center;

[0223] Step S175: Compare the fourteenth calculation result with the fifteenth calculation result; if the fourteenth calculation result and the fifteenth calculation result are not equal, the AP_BL33 verification fails; if the fourteenth calculation result and the fifteenth calculation result are equal, the AP_BL33 verification passes.

[0224] Specifically, if the fourteenth calculation result and the fifteenth calculation result are not equal, it means that AP_BL33 has been tampered with; if the fourteenth calculation result and the fifteenth calculation result are equal, it means that AP_BL33 has not been tampered with.

[0225] Further, in step S17, AP_BL2 verifies AP_BL33 according to the preset signature authentication algorithm, specifically including:

[0226] The AP_BL2 configures the preset signature authentication algorithm to the security module, calculates the thirteenth calculation result through the Hash engine of the security module, and calculates the fourteenth and fifteenth calculation results through the RSA engine of the security module.

[0227] It should be noted that the security authentication method for AP_BL33 in this embodiment is similar to the security authentication methods for SCP_BL2, AP_BL2, AP_BL31, and AP_BL32 described above. In both cases, the preset signature authentication algorithm is configured in the security module and the preset signature authentication algorithm is used for authentication.

[0228] It should be noted that in this embodiment, the AP running AP-BL2, AP-BL31, AP-BL32, and AP-BL33 refers to the version information of AP running AP-BL2, AP-BL31, AP-BL32, and AP-BL33. Version information is firmware code. To facilitate the differentiation of different versions of firmware code, in this field, different versions of firmware code are also referred to as version information. In addition, in the ARM ATF system, AP-BL2, AP-BL31, AP-BL32, and AP-BL33 in this embodiment are also called ATF-BL2, ATF-BL31, ATF-BL32, and ATF-BL33. ATF is short for ARM Trusted firmware, which is a security solution introduced by ARM in Armv8, providing a comprehensive security solution. It includes privilege level division during startup and operation, improves TrustZone (TZ) in Armv7, supplements the transmission of trust chain during startup, and refines the privilege level range during operation. The biggest change brought by ATF is the establishment of trust chain, which includes the establishment of trust relationship from EL3 to EL0 throughout the startup process.

[0229] Traditionally, ATF-BL1 is mainly used to load ATF-BL2. ATF-BL1 primarily initializes the CPU, sets exception vectors, loads the ATF-BL2 image into secure RAM, and then jumps to ATF-BL2 for execution. However, in this embodiment of the invention, ATF-BL1 is eliminated, and SCP-BL2 takes over the functions of ATF-BL1. A significant difference between ATF-BL2 and ATF-BL1, which also run on EL3, is that ATF-BL2 is on Flash as an external firmware. Its trustworthiness is based on the verification by ATF-BL1, while in this embodiment, it is based on the verification by SCP-BL2. In the ARM ATF architecture, many CPUs initialize some critical security hardware and software frameworks in their secondary bootloader. The other specific functions of ATF-BL31, ATF-BL32, and ATF-BL33 can be understood based on the ARM ATF architecture and will not be elaborated here. ATF-BL33 can be understood as UEFI firmware or uboot, and some implementations directly place the Linux Kernel here.

[0230] Example 4

[0231] It should be noted that in a complex and highly integrated chip architecture like the DPU with multiple Cortex-M cores and multiple Cortex-A cores, the method in this embodiment can be used to perform security authentication on the images of other Cortex-M cores and Cortex-A cores in sequence during the SCP BL2 stage. After the authentication is successful, the many cores, such as the AP core and the MCP core, are unlocked in sequence.

[0232] Therefore, based on the above embodiments one, two, and three, the present invention proposes embodiment four, which can be found in the following reference. Figure 3 The method in Embodiment 4 of the present invention further includes:

[0233] Step S18: The SCP_BL2 loads the bootloader image MCP_BL of the manageability control processor MCP from the SCP_QSPI_FLASH into the static random access memory MCP_SRAM of the MCP;

[0234] Step S19: The SCP_BL2 reads the algorithm flag bit in the eFuse and obtains the corresponding preset signature authentication algorithm according to the algorithm flag bit;

[0235] Step S20: The SCP_BL2 verifies the MCP_BL according to the preset signature authentication algorithm; when the MCP_BL verification fails, the SCP_BL2 does not wake up the MCP; when the MCP_BL verification passes, the SCP_BL2 wakes up the MCP.

[0236] Furthermore, the bootloader image MCP_BL includes the version information, root public key, and signature of MCP_BL;

[0237] In step S20, SCP_BL2 verifies the MCP_BL according to the preset signature authentication algorithm, including:

[0238] Step S201: Perform a hash calculation on the root public key of MCP_BL according to the preset signature authentication algorithm to obtain the sixteenth calculation result;

[0239] Step S202: Read the preset hash value in the eFuse and compare the sixteenth calculation result with the preset hash value;

[0240] Step S203: If the sixteenth calculation result is not equal to the preset hash value, then the MCP_BL verification fails;

[0241] Step S204: If the sixteenth calculation result is equal to the preset hash value, then perform SHA256 hash calculation on the version information of MCP_BL according to the preset signature authentication algorithm to obtain the seventeenth calculation result; and decrypt the signature of MCP_BL according to the preset signature authentication algorithm and the root public key of MCP_BL to obtain the eighteenth calculation result.

[0242] Step S205: Compare the seventeenth calculation result with the eighteenth calculation result; if the seventeenth calculation result and the eighteenth calculation result are not equal, the MCP_BL verification fails; if the seventeenth calculation result and the eighteenth calculation result are equal, the MCP_BL verification passes.

[0243] Further, in step S20, SCP_BL2 verifies the MCP_BL according to the preset signature authentication algorithm, specifically including:

[0244] The SCP_BL2 configures the preset signature authentication algorithm to the security module, calculates the sixteenth calculation result through the Hash engine of the security module, and calculates the seventeenth and eighteenth calculation results through the RSA engine of the security module.

[0245] It should be noted that the security authentication method for MCP_BL in this embodiment is similar to the security authentication methods for SCP_BL2, AP_BL2, AP_BL31, AP_BL32, and AP_BL33 described above. In both cases, the preset signature authentication algorithm is configured into the security module and the preset signature authentication algorithm is used for authentication.

[0246] Example 5

[0247] Embodiment 5 of the present invention proposes a firmware secure boot system, which can be used to implement the firmware secure boot method described in Embodiment 1 above, including a system control processor SCP, a read-only memory ROM, a flash memory SCP_QSPI_FLASH, a static random access memory SCP_SRAM, and a one-time programmable memory eFuse.

[0248] It should be noted that the firmware secure boot system described in this embodiment five corresponds to the firmware secure boot method described in embodiment one above. Therefore, the parts of the firmware secure boot system described in this embodiment five that are not described in detail can be obtained by referring to the content of the firmware secure boot method described in embodiment one above, so they will not be described in detail here.

[0249] Example 6

[0250] Embodiment 6 of the present invention proposes a firmware secure boot system, which can be used to implement the firmware secure boot method described in Embodiment 2 above. It includes a system control processor (SCP), a read-only memory (ROM), a flash memory (SCP_QSPI_FLASH), a static random access memory (SCP_SRAM), a one-time programmable memory (eFuse), and a security module. The security module includes a hash engine and an RSA engine.

[0251] It should be noted that the firmware secure boot system described in this embodiment six corresponds to the firmware secure boot method described in embodiment two above. Therefore, the parts of the firmware secure boot system described in this embodiment six that are not described in detail can be obtained by referring to the content of the firmware secure boot method described in embodiment two above, so they will not be described in detail here.

[0252] Example 7

[0253] Embodiment 7 of the present invention proposes a firmware secure boot system, which can be used to implement the firmware secure boot method described in Embodiment 3 above. It includes a system control processor SCP, a read-only memory ROM, a flash memory SCP_QSPI_FLASH, a static random access memory SCP_SRAM, a one-time programmable memory eFuse, a security module, an application processor AP, and a double rate synchronous dynamic random access memory DDR. The security module includes a hash engine and an RSA engine.

[0254] It should be noted that the firmware secure boot system described in this embodiment seven corresponds to the firmware secure boot method described in embodiment three above. Therefore, the parts of the firmware secure boot system described in this embodiment seven that are not described in detail can be obtained by referring to the content of the firmware secure boot method described in embodiment three above, so they will not be described in detail here.

[0255] Example 8

[0256] Embodiment 8 of the present invention proposes a firmware secure boot system, which can be used to implement the firmware secure boot method described in Embodiment 4 above. It includes a system control processor SCP, a read-only memory ROM, a flash memory SCP_QSPI_FLASH, a static random access memory SCP_SRAM, a one-time programmable memory eFuse, a security module, an application processor AP, a double rate synchronous dynamic random access memory DDR, a manageability control processor MCP, and a static random access memory MCP_SRAM. The security module includes a hash engine and an RSA engine.

[0257] It should be noted that the firmware secure boot system described in this embodiment eight corresponds to the firmware secure boot method described in embodiment four above. Therefore, the parts of the firmware secure boot system described in this embodiment eight that are not described in detail can be obtained by referring to the content of the firmware secure boot method described in embodiment four above, and will not be described in detail here.

[0258] As can be seen from the above description of the embodiments, the embodiments of the present invention have the following advantages:

[0259] (1) The entire system uses a single ROM, with SCP serving as the root of trust for the entire chip, reducing the cost of version maintenance and stability development verification due to multiple ROMs.

[0260] (2) Simplify the boot process by having the SCP move the authentication image from the external storage device. After authentication, the CPU cores such as AP / MCP are de-reset, simplifying the inter-core communication process during boot.

[0261] (3) Using SCP as the core, it moves and authenticates the images of other CPUs only once, without the need for multiple moves, simplifying the communication process between cores. This not only reduces the dependence between cores, but also effectively shortens the startup time. Effectively shortening the startup time can better adapt to scenarios with strict startup time requirements, such as cloud servers and data centers.

[0262] (4) Save hardware costs, which can save at least the physical cost of one ROM and one RAM.

[0263] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A firmware secure boot method, characterized in that, The method includes: When the System-on-Chip (SoC) is powered on, the System Control Processor (SCP) runs the bootloader image SCP_BL1 of the SCP stored in the Read-Only Memory (ROM). The SCP_BL1 loads the SCP's bootloader image SCP_BL2 from the SCP's flash memory SCP_QSPI_FLASH into the SCP's static random access memory SCP_SRAM; The SCP_BL1 reads the algorithm flag bit in the one-time programmable memory eFuse and obtains the corresponding preset signature authentication algorithm based on the algorithm flag bit; The SCP_BL1 verifies the SCP_BL2 according to the preset signature authentication algorithm; when the SCP_BL2 fails verification, the SCP terminates its operation; when the SCP_BL2 passes verification, the SCP jumps to run the SCP_BL2. The SCP_BL2 loads the bootloader image AP_BL2 of the application processor AP from the SCP_QSPI_FLASH into the double data rate synchronous dynamic random access memory DDR; The SCP_BL2 reads the algorithm flag bit in the eFuse and obtains the corresponding preset signature authentication algorithm based on the algorithm flag bit; The SCP_BL2 verifies the AP_BL2 according to the preset signature authentication algorithm; when the AP_BL2 verification fails, the SCP_BL2 does not wake up the AP; when the AP_BL2 verification succeeds, the SCP_BL2 wakes up the AP. After being woken up, the AP runs AP_BL2.

2. The firmware secure boot method as described in claim 1, characterized in that, The bootloader image SCP_BL2 includes SCP_BL2 version information, root public key, and signature; Wherein, SCP_BL1 verifies SCP_BL2 according to the preset signature authentication algorithm, including: The root public key of SCP_BL2 is hashed according to the preset signature authentication algorithm to obtain the first calculation result; Read the preset hash value from the eFuse and compare the first calculation result with the preset hash value; If the first calculation result is not equal to the preset hash value, then the SCP_BL2 verification fails; If the first calculation result is equal to the preset hash value, then the version information of SCP_BL2 is hashed using the preset signature authentication algorithm to obtain the second calculation result; and the signature of SCP_BL2 is decrypted using the preset signature authentication algorithm and the root public key of SCP_BL2 to obtain the third calculation result. Compare the second calculation result with the third calculation result; If the second calculation result and the third calculation result are not equal, then the SCP_BL2 verification fails. If the second calculation result and the third calculation result are equal, then the SCP_BL2 verification is successful.

3. The firmware secure boot method as described in claim 2, characterized in that, The SCP_BL1 verifies the SCP_BL2 according to the preset signature authentication algorithm, specifically including: The SCP_BL1 configures the preset signature authentication algorithm to the security module, calculates the first calculation result through the Hash engine of the security module, and calculates the second calculation result and the third calculation result through the RSA engine of the security module.

4. The firmware secure boot method as described in claim 1, characterized in that, The bootloader image AP_BL2 includes AP_BL2 version information, root public key, and signature; The SCP_BL2 verifies the AP_BL2 according to the preset signature authentication algorithm, including: The root public key of AP_BL2 is hashed according to the preset signature authentication algorithm to obtain the fourth calculation result; Read the preset hash value from the eFuse and compare the fourth calculation result with the preset hash value; If the fourth calculation result is not equal to the preset hash value, then the AP_BL2 verification fails. If the fourth calculation result is equal to the preset hash value, then the version information of AP_BL2 is hashed using the preset signature authentication algorithm to obtain the fifth calculation result; and the signature of AP_BL2 is decrypted using the preset signature authentication algorithm and the root public key of AP_BL2 to obtain the sixth calculation result. Compare the fifth calculation result with the sixth calculation result; If the fifth calculation result and the sixth calculation result are not equal, then the AP_BL2 verification fails. If the fifth calculation result and the sixth calculation result are equal, then the AP_BL2 verification is successful.

5. The firmware secure boot method as described in claim 4, characterized in that, The SCP_BL2 verifies the AP_BL2 according to the preset signature authentication algorithm, specifically including: The SCP_BL2 configures the preset signature authentication algorithm to the security module, calculates the fourth calculation result through the Hash engine of the security module, and calculates the fifth and sixth calculation results through the RSA engine of the security module.

6. The firmware secure boot method as described in claim 1, characterized in that, The method further includes: When the AP runs AP_BL2, AP_BL2 loads the AP's bootloader image AP_BL31 from the AP's flash memory AP_QSPI_FLASH into the DDR; The AP_BL2 reads the algorithm flag bit in the eFuse and obtains the corresponding preset signature authentication algorithm based on the algorithm flag bit; The AP_BL2 verifies the AP_BL31 according to the preset signature authentication algorithm; when the AP_BL31 fails to verify, the AP terminates its operation; when the AP_BL31 passes the verification, the AP jumps to run the AP_BL31.

7. The firmware secure boot method as described in claim 6, characterized in that, The bootloader image AP_BL31 includes AP_BL31 version information, root public key, and signature; Wherein, AP_BL2 verifies AP_BL31 according to the preset signature authentication algorithm, including: The root public key of AP_BL31 is hashed according to the preset signature authentication algorithm to obtain the seventh calculation result; Read the preset hash value from the eFuse and compare the seventh calculation result with the preset hash value; If the seventh calculation result is not equal to the preset hash value, then the AP_BL31 verification fails. If the seventh calculation result is equal to the preset hash value, then the version information of AP_BL31 is hashed using the preset signature authentication algorithm to obtain the eighth calculation result; and the signature of AP_BL31 is decrypted using the preset signature authentication algorithm and the root public key of AP_BL31 to obtain the ninth calculation result. Compare the eighth calculation result with the ninth calculation result; If the eighth calculation result and the ninth calculation result are not equal, then the AP_BL31 verification fails. If the eighth calculation result is equal to the ninth calculation result, then the AP_BL31 verification is successful.

8. The firmware secure boot method as described in claim 7, characterized in that, The AP_BL2 verifies the AP_BL31 according to the preset signature authentication algorithm, specifically including: The AP_BL2 configures the preset signature authentication algorithm to the security module, calculates the seventh calculation result through the Hash engine of the security module, and calculates the eighth and ninth calculation results through the RSA engine of the security module.

9. The firmware secure boot method as described in claim 6, characterized in that, The method further includes: When the AP finishes running AP_BL31, the AP jumps to run AP_BL2. At this time, AP_BL2 loads the AP's bootloader image AP_BL32 from the AP_QSPI_FLASH into the DDR. The AP_BL2 reads the algorithm flag bit in the eFuse and obtains the corresponding preset signature authentication algorithm based on the algorithm flag bit; The AP_BL2 verifies the AP_BL32 according to the preset signature authentication algorithm; when the AP_BL32 verification fails, the AP terminates its operation; when the AP_BL32 verification passes, the AP jumps to run the AP_BL32.

10. The firmware secure boot method as described in claim 9, characterized in that, The bootloader image AP_BL32 includes AP_BL32 version information, root public key, and signature; Wherein, AP_BL2 verifies AP_BL32 according to the preset signature authentication algorithm, including: The root public key of AP_BL32 is hashed according to the preset signature authentication algorithm to obtain the tenth calculation result; Read the preset hash value from the eFuse and compare the tenth calculation result with the preset hash value; If the tenth calculation result is not equal to the preset hash value, then the AP_BL32 verification fails. If the tenth calculation result is equal to the preset hash value, then the version information of AP_BL32 is hashed using the preset signature authentication algorithm to obtain the eleventh calculation result; and the signature of AP_BL32 is decrypted using the preset signature authentication algorithm and the root public key of AP_BL32 to obtain the twelfth calculation result. Compare the eleventh calculation result with the twelfth calculation result; If the eleventh calculation result and the twelfth calculation result are not equal, then the AP_BL32 verification fails. If the eleventh calculation result is equal to the twelfth calculation result, then the AP_BL32 verification is successful.

11. The firmware secure boot method as described in claim 10, characterized in that, The AP_BL2 verifies the AP_BL32 according to the preset signature authentication algorithm, specifically including: The AP_BL2 configures the preset signature authentication algorithm to the security module, calculates the tenth calculation result through the Hash engine of the security module, and calculates the eleventh and twelfth calculation results through the RSA engine of the security module.

12. The firmware secure boot method as described in claim 9, characterized in that, The method further includes: When the AP finishes running AP_BL32, the AP jumps to run AP_BL2. At this time, AP_BL2 loads the AP's bootloader image AP_BL33 from AP_QSPI_FLASH into the DDR. The AP_BL2 reads the algorithm flag bit in the eFuse and obtains the corresponding preset signature authentication algorithm based on the algorithm flag bit; The AP_BL2 verifies the AP_BL33 according to the preset signature authentication algorithm; when the AP_BL33 verification fails, the AP terminates its operation; when the AP_BL33 verification passes, the AP jumps to run the AP_BL33 and starts the kernel through the AP_BL33.

13. The firmware secure boot method as described in claim 12, characterized in that, The bootloader image AP_BL33 includes AP_BL33 version information, root public key, and signature; Wherein, AP_BL2 verifies AP_BL33 according to the preset signature authentication algorithm, including: The root public key of AP_BL33 is hashed according to the preset signature authentication algorithm to obtain the thirteenth calculation result; Read the preset hash value from the eFuse and compare the thirteenth calculation result with the preset hash value; If the thirteenth calculation result is not equal to the preset hash value, then the AP_BL33 verification fails. If the thirteenth calculation result is equal to the preset hash value, then the version information of AP_BL33 is hashed using the preset signature authentication algorithm to obtain the fourteenth calculation result; and the signature of AP_BL33 is decrypted using the preset signature authentication algorithm and the root public key of AP_BL33 to obtain the fifteenth calculation result. Compare the fourteenth calculation result with the fifteenth calculation result; If the fourteenth calculation result and the fifteenth calculation result are not equal, then the AP_BL33 verification fails. If the fourteenth calculation result and the fifteenth calculation result are equal, then the AP_BL33 verification is successful.

14. The firmware secure boot method as described in claim 13, characterized in that, The AP_BL2 verifies the AP_BL33 according to the preset signature authentication algorithm, specifically including: The AP_BL2 configures the preset signature authentication algorithm to the security module, calculates the thirteenth calculation result through the Hash engine of the security module, and calculates the fourteenth and fifteenth calculation results through the RSA engine of the security module.

15. The firmware secure boot method as described in claim 1, characterized in that, The method further includes: The SCP_BL2 loads the manageability control processor MCP bootloader image MCP_BL from the SCP_QSPI_FLASH into the MCP's static random access memory MCP_SRAM. The SCP_BL2 reads the algorithm flag bit in the eFuse and obtains the corresponding preset signature authentication algorithm based on the algorithm flag bit; The SCP_BL2 verifies the MCP_BL according to the preset signature authentication algorithm; when the MCP_BL verification fails, the SCP_BL2 does not wake up the MCP; when the MCP_BL verification passes, the SCP_BL2 wakes up the MCP.

16. The firmware secure boot method as described in claim 15, characterized in that, The bootloader image MCP_BL includes the version information, root public key, and signature of MCP_BL; Wherein, SCP_BL2 verifies MCP_BL according to the preset signature authentication algorithm, including: The root public key of MCP_BL is hashed according to the preset signature authentication algorithm to obtain the sixteenth calculation result; Read the preset hash value from the eFuse and compare the sixteenth calculation result with the preset hash value; If the sixteenth calculation result is not equal to the preset hash value, then the MCP_BL verification fails. If the sixteenth calculation result is equal to the preset hash value, then the version information of the MCP_BL is hashed using the preset signature authentication algorithm to obtain the seventeenth calculation result; and the signature of the MCP_BL is decrypted using the preset signature authentication algorithm and the root public key of the MCP_BL to obtain the eighteenth calculation result. Compare the seventeenth calculation result with the eighteenth calculation result; If the seventeenth calculation result and the eighteenth calculation result are not equal, then the MCP_BL verification fails. If the seventeenth calculation result and the eighteenth calculation result are equal, then the MCP_BL verification is successful.

17. The firmware secure boot method as described in claim 16, characterized in that, The SCP_BL2 verifies the MCP_BL according to the preset signature authentication algorithm, specifically including: The SCP_BL2 configures the preset signature authentication algorithm to the security module, calculates the sixteenth calculation result through the Hash engine of the security module, and calculates the seventeenth and eighteenth calculation results through the RSA engine of the security module.

18. A firmware secure boot system, characterized in that, The firmware secure boot system is used to implement the firmware secure boot method described in claim 1 or 2 above. The firmware secure boot system includes a system control processor (SCP), a read-only memory (ROM), a flash memory (SCP_QSPI_FLASH), a static random access memory (SCP_SRAM), and a one-time programmable memory (eFuse).

19. A firmware secure boot system, characterized in that, The firmware secure boot system is used to implement the firmware secure boot method according to any one of claims 1-3. The firmware secure boot system includes a system control processor (SCP), a read-only memory (ROM), a flash memory (SCP_QSPI_FLASH), a static random access memory (SCP_SRAM), a one-time programmable memory (eFuse), and a security module. The security module includes a hash engine and an RSA engine.

20. A firmware secure boot system, characterized in that, The firmware secure boot system is used to implement the firmware secure boot method according to any one of claims 1-14. The firmware secure boot system includes a system control processor (SCP), a read-only memory (ROM), a flash memory (SCP_QSPI_FLASH), a static random access memory (SCP_SRAM), a one-time programmable memory (eFuse), a security module, an application processor (AP), and a double-rate synchronous dynamic random access memory (DDR). The security module includes a hash engine and an RSA engine.

21. A firmware secure boot system, characterized in that, The firmware secure boot system is used to implement the firmware secure boot method according to any one of claims 1-17. The firmware secure boot system includes a system control processor (SCP), a read-only memory (ROM), a flash memory (SCP_QSPI_FLASH), a static random access memory (SCP_SRAM), a one-time programmable memory (eFuse), a security module, an application processor (AP), a double-rate synchronous dynamic random access memory (DDR), a manageability control processor (MCP), and a static random access memory (MCP_SRAM). The security module includes a hash engine and an RSA engine.

Images