A method for starting firmware, a chip and a computing device

Abstract

A firmware starting method can include: obtaining a customer root public key, verifying the customer root public key by using an original root public key pre-stored in the firmware, storing the customer root public key if the customer root public key is verified successfully, wherein the customer root public key is generated based on information set by a user; verifying the firmware according to the customer root public key in the case of restarting the firmware; and starting the target firmware based on the firmware verification success. When a customer does not trust the key security of a firmware manufacturer provider, customer root key information can be burned in an OTP through a live network, and the security of the firmware can be verified by the burned customer root key in a subsequent firmware starting process.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a firmware boot method, a chip, and a computing device. Background Technology

[0002] With the rapid development of networks and data centers, servers, as the core of data centers, face various internal and external security risks. Server management systems provide hardware management, and the security of server hardware depends on the security of the firmware provided by the server itself. Firmware security is ensured through verification; only firmware that passes verification can boot normally. Because the key used to verify the target firmware is stored in one-time programmable (OTP) memory, if a hacker compromises the signing server or the key used to verify the target firmware is leaked, the target firmware will be at security risk. Summary of the Invention

[0003] This application provides a firmware boot method, chip, and computing device. When a customer does not trust the security of the firmware manufacturer's key, the customer's root public key information can be burned into the OTP via the existing network, and the security of the firmware can be verified through the burned customer root public key during the subsequent firmware boot process.

[0004] In a first aspect, this application provides a firmware booting method, comprising: obtaining a client root public key; verifying the client root public key using the original root public key pre-stored in the firmware; if the client root public key verification is successful, storing the client root public key, wherein the client root public key is generated based on user-defined information; verifying the firmware according to the client root public key when restarting the firmware; and booting the target firmware based on successful firmware verification.

[0005] In this solution, when customers do not trust the security of the keys provided by the firmware manufacturer during use, they can write their own set key information (root public key) into the OTP during the live network phase. This allows the firmware to be verified using the customer-defined root public key when booting, enhancing firmware security.

[0006] In one possible implementation, the method further includes: obtaining the signature of the client root public key; verifying the client root public key using the original root public key pre-stored in the firmware; if the client root public key verification is successful, storing the client root public key, including: verifying the signature of the client root public key using the original root public key pre-stored in the firmware; if the signature verification of the client root public key by the original root public key is successful, verifying the firmware using the client root public key; if the verification of the firmware by the client root public key is successful, storing the client root public key.

[0007] In other words, the client root public key needs to be verified twice before being stored in the OTP. The first verification uses the original root public key to verify the client root public key, ensuring that the client root public key stored in the OTP is the one set by the user. The second verification uses the client root public key to verify the firmware, ensuring the legitimacy of the client root public key burned to the storage area and that the client root public key burned to the storage area can verify the target firmware, thus preventing the target firmware from failing to boot after enabling the client root.

[0008] In one possible implementation, the method further includes: obtaining the firmware's original root public key and verifying the original root public key; if the verification of the original root public key is successful, using the original root public key to verify the customer's root public key.

[0009] In other words, before using the original root public key to verify the client's root public key, the validity of the original root public key must be verified to ensure the accuracy of the verification. Only after confirming that the original root public key is valid can it be used to verify the client's root public key.

[0010] In one possible implementation, storing the client root public key includes storing the client root public key and its enable information in a one-time programmable OTP memory.

[0011] In one possible implementation, the specific method for verifying the firmware based on the client's root public key includes: obtaining the code signature of the client's root public key, and verifying the firmware using the client's root public key through code signature verification.

[0012] Secondly, this application provides a chip including a processor and an interface circuit, the processor and the interface circuit being electrically connected, the processor storing firmware, and the processor being used for:

[0013] Obtain the customer's root public key, verify the customer's root public key using the original root public key pre-stored in the firmware, and if the customer's root public key is successfully verified, store the customer's root public key, which is generated based on the information set by the user.

[0014] Upon firmware reboot, the firmware is verified using the customer's root public key.

[0015] Based on successful firmware verification, start the target firmware.

[0016] In one possible implementation, the processor is also used for:

[0017] Obtain the signature of the client's root public key;

[0018] Verify the signature of the client's root public key using the original root public key pre-stored in the firmware;

[0019] If the signature verification of the original root public key against the customer's root public key passes, the firmware is verified using the customer's root public key.

[0020] If the client's root public key is successfully verified against the firmware, the client's root public key is stored.

[0021] In one possible implementation, the processor is also used for:

[0022] Obtain the original root public key of the firmware and verify the original root public key;

[0023] If the original root public key is successfully verified, the client's root public key is verified using the original root public key.

[0024] In one possible implementation, the processor is also used for:

[0025] Store the client's root public key and its enable information in a one-time programmable OTP memory.

[0026] Thirdly, this application provides firmware, which includes:

[0027] The acquisition module is used to obtain the client's root public key;

[0028] The processing module is used to verify the client's root public key using the original root public key pre-stored in the firmware. If the client's root public key is successfully verified, the client's root public key is stored. The client's root public key is generated based on the information set by the user.

[0029] The processing module is also used to verify the firmware based on the customer's root public key in the event of a firmware reboot.

[0030] The startup module is used to start the target firmware after successful verification.

[0031] In one possible implementation, the acquisition module is also used to: acquire the signature of the client's root public key;

[0032] The processing module is also used for:

[0033] Verify the signature of the client's root public key using the original root public key pre-stored in the firmware;

[0034] If the signature verification of the original root public key against the customer's root public key passes, the firmware is verified using the customer's root public key.

[0035] If the client's root public key passes the firmware verification, the client's root public key is stored.

[0036] In one possible implementation, the acquisition module is also used to: acquire the firmware's original root public key;

[0037] The processing module is also used to: verify the original root public key; if the verification of the original root public key is successful, verify the client's root public key using the original root public key.

[0038] In one possible implementation, the processing module is also used for:

[0039] Store the client's root public key and its enable information in a one-time programmable OTP memory.

[0040] Fourthly, this application provides a computing device, which includes a motherboard and a chip, wherein the chip is integrated on the motherboard and includes:

[0041] At least one memory for storing programs;

[0042] At least one processor is configured to execute a program stored in memory, wherein, when the program stored in memory is executed, the processor is configured to perform the method described in the first aspect or any possible implementation thereof.

[0043] Fifthly, this application provides an electronic device, characterized in that it comprises:

[0044] At least one memory for storing programs;

[0045] At least one processor is configured to execute a program stored in memory, wherein, when the program stored in memory is executed, the processor is configured to perform the method described in the first aspect or any possible implementation thereof.

[0046] In a sixth aspect, this application provides a computer-readable medium storing instructions that, when executed on a computer, cause the computer to perform the method described in the first aspect or any possible implementation thereof.

[0047] In a seventh aspect, this application provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the method described in the first aspect or any possible implementation thereof.

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

[0049] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the 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.

[0050] Figure 1 This is a flowchart of a firmware boot method;

[0051] Figure 2 A schematic diagram of a firmware startup scenario provided in an embodiment of this application;

[0052] Figure 3 A schematic diagram of a BMC structure provided in an embodiment of this application;

[0053] Figure 4 A flowchart illustrating a method for writing customer root public key information via OTP, as provided in this application embodiment;

[0054] Figure 5 A schematic diagram of the structure of an executable file for a target firmware provided in an embodiment of this application;

[0055] Figure 6 A flowchart illustrating a method for burning customer root public key information is provided in this application embodiment;

[0056] Figure 7 A flowchart illustrating another method for writing customer root public key information via OTP, as provided in this application embodiment;

[0057] Figure 8(a) is a schematic diagram of the structure of an OTP provided in an embodiment of this application;

[0058] Figure 8(b) is a schematic diagram of the structure of an OTP provided in an embodiment of this application;

[0059] Figure 9 A flowchart illustrating another method for writing customer root public key information via OTP, as provided in this application embodiment;

[0060] Figure 10 A flowchart illustrating a firmware startup method provided in an embodiment of this application;

[0061] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0062] Figure 12 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be described below with reference to the accompanying drawings.

[0064] In the description of the embodiments in this application, any embodiment or design that is “exemplary,” “for example,” or “by way of example” should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as “exemplary,” “for example,” or “by way of example” is intended to present the relevant concepts in a concrete manner.

[0065] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and their variations all mean "including but not limited to," unless otherwise specifically emphasized.

[0066] First, the terminology used in the embodiments of this application will be introduced.

[0067] 1. A single board can refer to a circuit board on which components are soldered. In the embodiments of this invention, a single board can be a circuit board that integrates a CPU, a baseboard management controller (BMC), flash memory, a bus, or other components.

[0068] 2. The production equipment stage refers to the stage where the single board is in production or programming. At this time, the single board has not yet been packaged into a device that can be used by the user.

[0069] 3. The live network stage, corresponding to the production equipment stage. In this application embodiment, the live network stage can refer to the stage where the single board has been packaged into the corresponding device and is usable by the user.

[0070] Firmware is stored in the CPU, BMC, or other chips of the single-board unit. To ensure firmware security, the manufacturer signs the firmware. When signing the firmware, the manufacturer generates a key pair, including a private key and a public key (hereinafter referred to as the root public key). The manufacturer then uses the private key to sign the firmware and writes the root public key into the OTP register. When the single-board unit boots, it can verify the firmware using the root public key stored in the OTP register. Only firmware that passes verification can boot normally. The firmware can be BMC firmware, for example, firmware for the BMC security core, or firmware used to provide business functions. The firmware can also be uboot, used to boot the BMC system. The firmware can also be BIOS firmware.

[0071] It should be noted that in other embodiments, the BMC has different names in different computing devices. For example, the BMC of Huawei servers and Super Fusion servers is called BMC, the BMC of HPE servers is called iLO, and the BMC of DELL servers is called iDRAC.

[0072] Figure 1 A firmware boot method is shown. For example... Figure 1 As shown, the firmware security verification process during firmware startup includes:

[0073] S101, Read the root public key key_i that has not been used during this boot process from the OTP register.

[0074] S102, determine if i is less than or equal to n. If i <= n, execute S103; otherwise, execute S106.

[0075] S103 uses the root public key key_i to verify the firmware.

[0076] S104. Determine whether the firmware verification is successful. If the firmware verification is successful, execute S105. Otherwise, set i = i + 1 and execute S101.

[0077] S105, firmware boots normally.

[0078] S106, firmware boot failed.

[0079] exist Figure 1 As shown in the firmware boot process, during the production equipment stage, the manufacturer burns the root public keys key_1 to key_n into the OTP register. These keys are trusted roots and cannot be changed. When the board boots, it uses the root public keys stored in the OTP register to verify the firmware's security, ensuring that the firmware has not been tampered with or forged. Specifically, the firmware reads key_1 from the OTP register and uses key_1 to verify itself. If the verification passes, the board boots normally. If key_1 verification fails, the firmware continues to read key_2 from the OTP area and continues verification. This process continues until all keys have been verified.

[0080] Although, Figure 1 The firmware boot method shown can verify the security of the firmware. However, the above method still has the following drawbacks.

[0081] 1. The root public key in the OTP register is written once during the production equipment stage and cannot be changed during subsequent use, which fails to meet customers' diverse security needs. When customers do not trust the security of the server provider's root public key (or when customers want to replace it with the national cryptographic algorithm), they cannot burn the new root public key information into the production network stage, nor can they directly use the single-board products that are currently in the production network stage.

[0082] 2. When hackers compromise the signing server or the encryption public key becomes invalid, all signed firmware becomes vulnerable. Furthermore, the inability to modify the root public key information in the OTP register exposes all manufactured circuit boards to security risks.

[0083] 3. When booting the firmware on the board, multiple keys in the OTP register are used to verify the firmware in an OR manner. If even one key in the OTP register is leaked, the firmware's secure boot will fail, putting the firmware at significant risk. Furthermore, when using key_n to sign the firmware, n-1 invalid verifications are required each time the firmware boots, increasing boot time and impacting the user experience.

[0084] Therefore, to address the issue in the above solutions where the root public key burned during the production equipment stage is leaked, or when a new root public key is needed, the public key cannot be securely changed, this application provides a firmware booting method. By logically dividing the OTP register into different parts (e.g., logically dividing the OTP register into a first OTP area and a second OTP area), when a customer does not trust the security of the server provider's root public key during use, the customer's root public key information can be burned into the OTP register during the live network stage. In subsequent firmware boot processes, the security of the firmware is verified using the burned customer root public key.

[0085] For example, Figure 2 A schematic diagram of a firmware boot scenario is shown. Figure 2 As shown, during the firmware startup process, it needs to obtain the root public key information stored in either the first OTP zone or the second OTP zone. The root public key information stored in the first OTP zone is the root public key information burned during the production equipment stage. The root public key information stored in the second OTP zone is the root public key information burned during the live network stage. In this embodiment, the root public key stored in the first OTP zone can be referred to as root public key 1 or the original root public key, and the root public key information stored in the second OTP zone can be referred to as customer root public key information or customer root public key 2, where customer root public key 2 is a user-defined public key. When starting the firmware, the root public key information is read from the first OTP zone by default, and the firmware is verified based on this root public key information. Once the firmware verification is successful, the firmware is started.

[0086] When the root public key in the first OTP zone does not meet security requirements, the firmware first verifies the client's root public key information using the root public key in the first OTP zone. After successful verification, the firmware burns the client's root public key information into the second OTP zone, and simultaneously writes the client's root enable information (en) into the second OTP zone. Upon firmware reboot, the firmware needs to read the verification information from the second OTP zone to verify and boot the corresponding firmware. In a possible example, situations where the root public key in the first OTP zone does not meet security requirements include: key leakage due to a hacker attack on the signature server, or the client's distrust of the key provided by the manufacturer.

[0087] In one possible example, the firmware boot method provided in this application embodiment can be applied to a baseboard management controller (BMC) on a server. The BMC is a control unit deployed on a server board with independent power supply and independent I / O interfaces. It does not rely on the server's processor, basic input / output system (BIOS), or operating system to operate; it is a standalone agentless management subsystem running within the server. During the power-on process of the server board, the BMC is powered on first, enabling it to boot. The BMC then drives the server boot process. Because the BMC powers on first, it can gain control of the server system, making the BMC particularly important for server security. Therefore, during the BMC boot phase, the security of the firmware stored in the BMC needs to be verified.

[0088] For example, this application also provides a schematic diagram of the structure of a BMC. Figure 3 As shown, the BMC may include: a processor 310, a network interface 320, and a memory 330. The processor 310, network interface 320, and memory 330 may be connected via a bus or other means.

[0089] In this embodiment, the processor 310 (or central processing unit, CPU) is the computing and control core of the BMC. In one possible example, the processor 310 also includes an OTP register. This OTP register can be logically divided into, for example... Figure 2 The diagram shows the first OTP area and the second OTP area. The programming stages for the first and second OTP areas differ. The first OTP area can only be programmed during the production equipment stage. The second OTP area can be programmed during either the production equipment stage or the live network stage.

[0090] The network interface 320 may include a standard wired interface, a wireless interface (such as Wi-Fi, mobile communication interface, etc.), and is controlled by the processor 310 to send and receive data, such as receiving root public key information input by the user from the network.

[0091] Memory 330 is the server's memory device used to store programs and data. It is understood that memory 330 can be high-speed RAM or non-volatile memory, such as at least one disk drive; alternatively, it can also be at least one storage device located remotely from the aforementioned processor 310. Memory 330 provides storage space for storing the server's operating system and executable program code, which may include, but is not limited to: Windows (an operating system), Linux (an operating system), HarmonyOS (an operating system), etc., without limitation.

[0092] It is understood that the embodiments of this application Figure 3 The illustrated structure does not constitute a specific limitation on the BMC. In other embodiments of this application, the BMC may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0093] For example, this application also provides a method for programming customer root public key information into an OTP register. This method can be, but is not limited to, [the method described above]. Figure 3 The processor in the BMC shown executes. See also Figure 4 The method includes S401-S403.

[0094] S401, the processor obtains the client's root public key information.

[0095] It's important to note that when a client distrusts the security of a specific target firmware on the server—that is, when the client distrusts the security of root public key 1—the client can generate their own key information and use it to sign and verify the target firmware. This key information includes a public key and a private key. The private key is used to sign the target firmware, and the public key is used to verify the signature. It's also important to note that both the private and public keys are essentially numbers. Any number can be used as a private key, and an elliptic curve cryptography algorithm can be used to generate the corresponding public key. In other words, the client's root public key is formed based on the private key; that is, it is generated based on user-defined information, such as the client's private key.

[0096] The customer signs the target firmware using their self-defined key information as follows:

[0097] In one possible example, after the server receives the installation package of the target firmware from the manufacturer, the server first determines whether the version of the received installation package is the same as the version of the currently installed target firmware. If the server determines that the version of the received installation package is the same as the currently installed target firmware, it can display an editing interface for the target firmware installation package on the server's display screen. Users can enter their private key information in this editing interface to sign the target firmware, and also enter a public key to verify the signature of the target firmware.

[0098] In one possible example, a customer can obtain the target firmware installation package from the manufacturer via a server or other terminal device. The executable file in the target firmware installation package carries information such as... Figure 5 As shown in (a) in the figure. Figure 5 Version (a) in the diagram represents the root public key 1 version of the executable file of the target firmware. The root public key 1 version contains the root public key 1 information burned into the OTP area of ​​the target firmware during the production equipment stage, as well as the code signature of the root public key 1. The code signature of the root public key 1 refers to the signature obtained after signing the code of the target firmware using the private key corresponding to the root public key 1. It should be noted that "signature" in this example refers to a "digital signature." A digital signature (also known as a public-key digital signature) is a string of numbers that only the sender of the information can generate and that cannot be forged by others. This string of numbers also serves as valid proof of the authenticity of the information sent by the sender. A digital signature is similar to a regular physical signature written on paper, but it uses public-key cryptography techniques to authenticate digital information.

[0099] After obtaining the target firmware installation package from the manufacturer, the user can sign the target firmware using their own key. In some implementations, the customer can sign the target firmware code using their private key, obtaining a target firmware signature, which can also be called the code signature of customer root public key 2. The customer then writes the customer root public key 2 corresponding to this private key, along with the code signature of customer root public key 2, into the executable file of the target firmware. Specifically, a one-way hash function can be used to process the target firmware code, obtaining a 128-bit digest (this digest is equivalent to the fingerprint of the target firmware, uniquely identifying it). Then, the user-defined private key is used to encrypt this 128-bit digest, obtaining an encrypted digest (this digest can also be called the target firmware signature).

[0100] After signing the target firmware, the customer can send the signed target firmware installation package (i.e., the installation package containing the encrypted digest) to the manufacturer via the server. Alternatively, in other embodiments, the customer can also send the signed target firmware installation package to the manufacturer via other terminal devices.

[0101] After receiving the target firmware installation package from the customer, the manufacturer needs to re-sign the target firmware within the installation package. In some implementations, after obtaining the customer's root public key 2 information, the manufacturer writes the OTP information of the customer's root public key 2 into the executable file of the target firmware based on the obtained customer root public key 2. The OTP information of customer root public key 2 refers to the information related to customer root public key 2 that needs to be written into the OTP register. The OTP information of customer root public key 2 at least contains customer root public key 2 or its hash value. Then, the manufacturer signs the OTP information of customer root public key 2 using the private key corresponding to root public key 1, obtaining the OTP information signature of customer root public key 2, and writes this OTP information signature into the executable file of the target firmware.

[0102] In one possible example, after the manufacturer signs the target firmware in the installation package sent to the customer, the executable file of that target firmware carries information such as... Figure 5 As shown in (b) of the diagram. Figure 5 Version (b) in the diagram represents the dual-signed intermediate version of the executable file of the target firmware. The dual-signed intermediate version contains the root public key 1 information, the code signature of root public key 1, the customer root public key 2 information, the code signature of customer root public key 2, the OTP information of customer root public key 2, and the OTP information signature, which are burned into the OTP register by the target firmware during the production equipment stage.

[0103] After the manufacturer signs the target firmware in the installation package sent by the customer, the manufacturer can send the installation package, which has been signed by both the customer and the manufacturer, to the BMC. After receiving the installation package from the manufacturer, the BMC's processor can obtain the customer root public key information (e.g., customer root public key 2) used to verify the target firmware from the executable file of the target firmware installation package.

[0104] S402, the processor obtains the enable information of the client's root public key.

[0105] After the BMC obtains the client root public key information, it can trigger the processor to generate an enable client root command by executing pre-defined code. This enable client root command triggers the processor to write the client root public key information and its corresponding enable information to the OTP register. Once the OTP register is filled with the client root public key's enable information, the BMC can directly use the client root public key to verify the firmware running on it during startup.

[0106] S403, the processor verifies the client root public key information. If the client root public key information is verified, the processor writes the client root public key information and its enable information to the second OTP area.

[0107] In this embodiment, the BMC verifies the client root public key 2 based on the key information (including the information of root public key 1 and client root public key 2) carried in the executable file of the received target firmware.

[0108] Specifically, such as Figure 6 As shown, it includes steps S4031-S4039.

[0109] S4031, the processor obtains the OTP information of the root public key 1 and the customer root public key 2 of the target firmware from the executable file of the target firmware.

[0110] S4032, the processor verifies the root public key 1. If the verification of the root public key 1 is successful, proceed to S4033; otherwise, proceed to S4039.

[0111] In this scheme, after the processor obtains the root public key 1 and the client root public key 2 of the target firmware, it first verifies the root public key 1 to ensure that the root public key 1 obtained by the processor is the same as the root public key 1 pre-stored in the OTP register. Specifically, during the production equipment stage, when the root public key 1 is written into the OTP register, a hash calculation is also performed on the root public key 1, and the resulting hash value is stored. Therefore, when verifying the root public key 1, the processor needs to use the same hash algorithm as the one used in the production equipment stage to perform the hash calculation on the root public key 1. Then, the processor compares the hash value obtained from the hash calculation of the root public key 1 with the hash value obtained in the production equipment stage. If the two hash values ​​obtained from the hash calculation of the root public key 1 are the same, the verification of the root public key 1 is considered successful; otherwise, the verification of the root public key 1 fails.

[0112] S4033, the processor uses root public key 1 to verify the OTP information of the client's root public key 2. If the OTP information of the client's root public key 2 is verified, S4034 is executed; otherwise, S4039 is executed.

[0113] In this scheme, after the processor verifies the root public key 1, it also needs to use root public key 1 to verify the OTP information of the client's root public key 2. Since the manufacturer signs the OTP information of the client's root public key 2 with the private key corresponding to root public key 1 before sending the target firmware installation package to the BMC, obtaining the OTP information signature of the client's root public key 2, i.e., the signature of the client's root public key, the processor can use the root public key 1 carried in the executable file of the target firmware to verify the signature of the client's root public key 2's OTP information, thereby achieving the purpose of verifying the OTP information of the client's root public key 2.

[0114] In one possible example, the processor can use root public key 1 to decrypt the OTP message signature of root client public key 2, obtaining a digest of the client root public key 2's OTP message. Then, the processor processes the client root public key 2's OTP message using a one-way hash function, obtaining another digest of the client root public key 2's OTP message. The processor compares the two digests of the client root public key 2's OTP message. If the two digests are equal, it means that the client root public key 2's OTP message has not been altered during transmission; that is, the verification of the client root public key 2's OTP message is successful. If the two digests are different, it means that the client root public key 2's OTP message has been altered during transmission; that is, the verification of the client root public key 2's OTP message fails.

[0115] S4034, the processor obtains the customer root public key 2 information and the code signature of customer root public key 2 from the executable file of the target firmware.

[0116] S4035, the processor uses the verified OTP information of the client root public key 2 to verify the code signature of the client root public key 2.

[0117] S4036, If the code signature verification of the client's root public key 2 passes, execute S4037; otherwise, execute S4039.

[0118] In this scheme, before writing the client root public key 2 to the OTP register, it is necessary to ensure that the client root public key 2 written to the OTP register can verify the target firmware after being enabled. That is, before writing the client root public key 2 to the OTP register, it is necessary to verify the target firmware using the client root public key 2. Since verifying the target firmware mainly involves verifying the target firmware's code, when using the client root public key 2 to verify the target firmware, the code signature of the client root public key 2 can be verified using the client root public key 2.

[0119] In one possible example, the processor uses the client root public key 2 contained in the OTP information to decrypt the code signature of client root public key 2, obtaining a digest of the target firmware code. Then, the processor processes the target firmware code using a one-way hash function, obtaining another digest of the target firmware code. The processor compares the two digests. If the two digests are equal, the processor considers its verification of the client root public key 2's code signature to be successful (i.e., the client root public key's verification of the firmware is successful). If the two digests are not equal, the processor considers its verification of the client root public key 2's information and its verification of the client root public key 2's code signature to be unsuccessful (i.e., the client root public key's verification of the firmware is unsuccessful).

[0120] S4037, the processor calls the hardware to burn the client root public key 2 in the second OTP area.

[0121] In one possible example, when the processor calls the hardware to write the client root public key 2 to the second OTP area, it can do so by calling the registers on the chip.

[0122] S4038, the processor calls the hardware to burn the enable information of the client root public key 2 in the second OTP area.

[0123] S4039, programming failed.

[0124] After the processor obtains the client root public key 2 and its enable information through the executable file of the target firmware, it needs to verify the client root public key information carried in the executable file of the target firmware twice before writing the client root public key 2 and its enable information to the second OTP area.

[0125] The first verification occurs in S4031. After obtaining the client root public key 2, it needs to be verified to ensure that the client root public key 2, which is to be written to the second OTP area of ​​the BMC, is secure and legitimate. Specifically, before sending the target firmware installation package to the BMC, the manufacturer signs the OTP information of the client root public key using the private key corresponding to root public key 1. Therefore, the processor can use the root public key 1 carried in the executable file of the target firmware to verify the signature of the OTP information of the client root public key 2, ensuring that the client root public key 2 obtained by the processor is the public key information that the client needs to write to the second OTP area.

[0126] In the S4035, the second verification involves the processor verifying the legitimacy of the target firmware using the client root public key 2 before writing it to the second OTP area. This prevents the target firmware from failing to boot after enabling the client root public key 2 following its writing to the second OTP area. Only after both verifications pass will the processor invoke hardware to write the client root public key 2 and its enable information to the second OTP area.

[0127] In one possible example, after the processor writes the client root public key 2 and its enable information to the second OTP area, the executable version of the target firmware can be upgraded to the client root public key 2 version. The executable version of client root public key 2 is as follows: Figure 5 As shown in (c) above. The client root public key version 2 contains client root public key 2 information and the code signature of client root public key 2.

[0128] It should be noted that before the processor verifies the OTP information of the client's root public key 2 using root public key 1, the processor also needs to verify root public key 1 to determine its legitimacy. When verifying the legitimacy of root public key 1, the processor can perform a hash calculation on root public key 1 to obtain its corresponding hash value, and then compare this hash value with the hash value of root public key 1 stored in the first OTP area. When the hash value of root public key 1 calculated by the processor is the same as the hash value of root public key 1 stored in the first OTP area, the processor determines that root public key 1 is legitimate.

[0129] In this embodiment, by logically adding an additional OTP area, when a customer does not trust the security of the firmware manufacturer's key during use, they can burn their own generated customer root key information into the additional OTP area. During subsequent firmware boot, the security of the firmware is verified using the burned customer root key. This satisfies the customer's need for diverse trusted roots and addresses the need for live network modifications after root public key leakage.

[0130] In one possible example, when Figure 3 When the processor in the BMC shown is heterogeneous and multi-core, S401-S403 can be executed by multiple cores of the processor. For example, the BMC includes a security core and a service core. By default, both the security core and the service core can program the OTP area. During the production setup phase, the BMC service core programs information to the OTP register. After the production setup phase is completed, programming information to the OTP register via the BMC service core is prohibited. During the live network phase, the security core programs information to the OTP register.

[0131] For example, based on Figure 3The processor in the BMC shown is a heterogeneous multi-core processor. This application also provides a method for programming the client root public key information into the OTP register. See also... Figure 7 The method includes: S701-S706.

[0132] S701, BMC business core obtains customer root public key information.

[0133] In this embodiment, the BMC service core can obtain the client root public key information from the version of the target firmware to be upgraded. Specifically, after the BMC obtains the installation package of the version of the target firmware that needs to be upgraded, the BMC can output an upgrade prompt for the target firmware on the display of the electronic device (e.g., a server) where the BMC is located. This upgrade prompt is used to ask the user whether the target firmware needs to be upgraded. When the user selects to upgrade the target firmware, the BMC service core upgrades the target firmware according to the installation package and obtains the client root public key information carried in the upgrade installation package of the target firmware.

[0134] In one possible example, the executable file carried in the target firmware upgrade installation package is as follows: Figure 5 As shown in (b) above, the BMC service core obtains the client root public key information of the target firmware by parsing the executable file.

[0135] S702, after the BMC service core obtains the customer's root public key information, the BMC service core imports the obtained customer's root public key information into the security core.

[0136] In this embodiment, after obtaining the customer root public key information, the BMC service core cannot program the OTP register in the current network stage. Therefore, the BMC service core needs to import the obtained customer root public key information into the security core.

[0137] S703, the BMC service core sends an enable client root command to the security core to trigger the security core to write the client root public key information to the BMC's OTP register.

[0138] In this embodiment, the BMC service core sends an enable client root command to the security core only after the BMC service core has imported the client root public key information into the security core. The enable client root command is used to trigger the security core to write the client root public key information into the BMC's OTP register.

[0139] S704, the security check verifies the customer root public key information obtained by the BMC business core.

[0140] In this embodiment, after the security core receives the enable client root command sent by the BMC service core, the security core needs to read and verify the client root public key information. Only after the client root public key information is verified, the security core will call the hardware to write the client root public key information and the client root public key enable information to the OTP register.

[0141] The security kernel can perform two layers of verification when verifying the client root public key information. First, it verifies the legitimacy of the client root public key by using the root public key burned into the OTP register during the production equipment phase. After the legitimacy verification of the client root public key is successful, the security kernel also needs to use the verified client root public key to verify the legitimacy of the upgraded target firmware, in order to prevent the target firmware from failing to boot after enabling the client root during the BMC boot process. The specific verification process of the security kernel for the client root public key information can be referred to S403 in the above embodiment, and will not be repeated here.

[0142] S705 verifies the customer root public key information obtained from the BMC service core based on the security core. The security core then writes the customer root public key information and the customer root public key enable information into the corresponding OTP register.

[0143] In this embodiment, after the security core verifies the client root public key information, it calls the hardware to write the client root public key information and the client root enable information to the corresponding OTP register.

[0144] It should be noted that the OTP register is a one-time programmable register inside the CPU. Logically, based on the type of root public key information stored, the OTP register can be divided into a first OTP area, a second OTP area, and a security enable area, as shown in Figure 8(a). The first OTP area stores the root public key information (root public key 1) burned into the OTP area during the production equipment stage. The second OTP area stores the customer root public key information (customer root public key 2) burned into the OTP area during the live network stage. The security enable area stores security enable information (such as security enable), which can be used to trigger the target terminal device to perform secure boot. The security enable area also stores the enable information (such as customer root enable) of the customer root public key stored in the second OTP area.

[0145] In implementation, security enable and client root enable can be represented by a single bit or multiple bits. From a security perspective, it is better to use multiple bits.

[0146] In one possible example, as shown in Figure 8(b), the OTP register can logically be divided into a first OTP area and a second OTP area for the client. The first OTP area is also programmed with security enable information (e.g., security enable), and the second OTP area for the client is also programmed with enable information for the client root public key 2 (e.g., client root enable).

[0147] In one possible embodiment, based on the different programming times of the OTP area, the OTP register can be divided into an OTP production equipment domain segment and an OTP live network domain segment. The production equipment domain segment must be programmed during the production equipment stage. The live network domain segment can be programmed either during the production equipment stage or the live network stage.

[0148] S706, the security kernel triggers a BMC restart.

[0149] In this embodiment, after the security core calls the hardware to write the client root public key information and its enable information to the OTP register, both the software and hardware within the BMC will use the client root public key to boot when the BMC restarts.

[0150] In this embodiment, the processor is divided into a security core and a service core. The OTP register is divided into a production equipment domain segment and a live network domain segment. The security core is used to program the live network domain segment, while programming the production equipment domain segment is prohibited, thus increasing security. Furthermore, when programming the customer root public key information, the public key programmed in the production equipment domain segment is used to verify the customer root public key to be programmed in the live network domain segment, and the verified customer root public key is used to verify the target firmware, ensuring the security and correctness of the customer root public key information programmed in the live network domain segment.

[0151] In another possible example, when Figure 3 The processor in the BMC shown does not distinguish between security cores and service cores; when there is only one CPU core, S401-S403 can be executed by the CPU core. The execution process of the CPU core is as follows: Figure 9 As shown. It should be noted that when there is only one CPU core in the BMC, the BMC can interact with the user, allowing the user to trigger the CPU core to generate a client root enable command. After the CPU core successfully verifies the client root public key information, the BMC can also automatically trigger the CPU core to generate the client root enable command by executing pre-written code within the BMC. In this embodiment, the specific method by which the CPU core generates the client root enable command is not limited.

[0152] For example, embodiments of this application also provide a firmware boot method. This method can be, but is not limited to, a method for booting firmware. Figure 3 The BMC execution shown is described in the following example. Figure 10 The method includes S1001-S1003.

[0153] S1001, retrieve the client root public key stored in the one-time programmable memory.

[0154] In this embodiment, the target firmware can be booted in two ways: insecure boot and secure boot. When no security enable information is written to the OTP register, the target firmware performs an insecure boot. When security enable information is written to the OTP register but no client root enable information is written, the target firmware performs a secure boot using the root public key written during the production equipment phase. When both security enable information and client root enable information are written to the OTP register, a secure boot using the client root public key written during the live network phase is performed. After the processor determines that the target firmware's boot mode is client root public key boot, the processor obtains the client root public key information used to verify the target firmware from the OTP register. The client root public key information refers to the client root public key written to the live network domain segment during the live network phase.

[0155] It should be noted that, in this embodiment, the OTP register is logically divided into at least two parts according to the type of information stored: a first OTP area and a second OTP area. The first OTP area stores the root public key 1, and the second OTP area stores the client root public key 2. The OTP register can be divided into the OTP live network domain segment and the OTP production equipment domain segment according to the timing of its programming. The production equipment domain segment can only be programmed during the production equipment stage, while the live network domain segment can be programmed during both the production equipment stage and the live network stage. That is, in this embodiment, the first OTP area corresponds to the production equipment domain segment, and the second OTP area corresponds to the live network domain segment.

[0156] S1002, verify the target firmware based on the obtained customer root public key.

[0157] In this embodiment, after the processor obtains the client root public key information from the OTP register, it verifies the signature of the target firmware based on the client root public key information. Since the processor upgrades the client-signed version when upgrading the target firmware, it needs to use the client root public key burned into the live network for verification when starting the target firmware.

[0158] S1003, based on successful verification of the target firmware, the target firmware is started.

[0159] In this application embodiment, when the customer does not trust the root public key that the target firmware is burned into the OTP register during the production equipment stage, or when the root public key that the target firmware is burned into the OTP register during the production equipment stage is leaked, the user can use the new root public key that is burned into the OTP register during the live network stage to verify the target firmware, thereby enhancing the security of the firmware.

[0160] Based on the methods in the above embodiments, this application also provides an electronic device, please refer to... Figure 11 , Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 11 As shown, the electronic device 1100 includes: a receiving module 1110, a processing module 1120, and a storage module 1130.

[0161] The receiving module 1110 is used to receive the upgrade installation package of the target firmware sent by the manufacturer.

[0162] Storage module 1130 is used to store the upgrade installation package of the target firmware received by receiving module 1110.

[0163] The processing module 1120 is used to upgrade the target firmware according to the target firmware upgrade installation package, and to write the client root public key information carried in the target firmware upgrade installation package into the OTP register in the processing module 1120.

[0164] In one possible example, the processing module 1120 includes: a control unit, an OTP storage unit, and a processing unit. Figure 11 (Not shown in the diagram), where the OTP storage unit is a software-level description of the OTP register. The control unit obtains the target firmware's client root public key information from the target firmware's upgrade installation package. The arithmetic unit verifies the obtained client root public key information. After successful verification of the client root public key information, the control unit calls the hardware in the electronic device to write the target firmware's client root public key information to the OTP storage unit. The specific process of the processing module 1120 writing the target firmware's client root public key information to the OTP register can be referred to the descriptions in S401-S403, and will not be repeated here.

[0165] In another possible example, the processing module 1120 includes: a control unit, an OTP storage unit, a first arithmetic unit, and a second arithmetic unit. Figure 11 (Not shown in the image). The control unit obtains the target firmware's client root public key information from the target firmware's upgrade installation package. The first processing unit imports the target firmware's client root public key information into the second processing unit. The second processing unit verifies the obtained client root public key information. After successful verification of the client root public key information, the control unit writes the target firmware's client root public key information to the OTP storage unit by calling the hardware in the electronic device. In this example, the first processing unit of the processing module can correspond to... Figure 7 The BMC service core in the middle. The second processing unit can correspond to Figure 7The security kernel in the process. The specific process of the processing module 1120 writing the client root public key information of the target firmware to the OTP register can be referred to the descriptions in S701-S706, and will not be repeated here.

[0166] Figure 11 The described embodiments of the electronic devices are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. The functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0167] For example, Figure 11 The various modules can be implemented either in hardware or as software functional modules. For example, when implemented in software, the aforementioned processing module 1120 can be implemented by an attached... Figure 3 The software function module is generated by at least one processor 310 reading the program code stored in the memory 330. Figure 11 The aforementioned modules can also be implemented separately by different hardware components in the electronic device. For example, the processing module 1120 is implemented by an attached... Figure 3 At least a portion of the processing resources of at least one processor 310 (e.g., one core of a multi-core processor) are used for implementation, while the receiving module 1110 is attached. Figure 3 The network port 320 and the remaining processing resources of at least one processor 310 (e.g., other cores in a multi-core processor) can be used, or programmable devices such as FPGAs or coprocessors can be employed. Clearly, the above functional modules can also be implemented using a combination of software and hardware. For example, the receiving module 1110 can be implemented using a hardware programmable device, while the processing module 1120 is a software functional module generated by the CPU after reading the program code stored in memory.

[0168] Based on the methods in the above embodiments, this application provides a computer-readable storage medium storing a computer program that, when run on a processor, causes the processor to execute the methods in the above embodiments.

[0169] Based on the methods in the above embodiments, this application provides a computer program product, characterized in that, when the computer program product is run on a processor, the processor executes the methods in the above embodiments.

[0170] Based on the methods in the above embodiments, this application provides a computing device, which includes a motherboard and a chip. The chip is integrated on the motherboard and includes at least one memory for storing a program; and at least one processor for executing the program stored in the memory. When the program stored in the memory is executed, the processor executes the methods in the above embodiments. In this application, the computing device can be a server, host, or other network device. The chip can be a BMC, a chip storing BIOS, etc. This application does not limit the type of computing device or the type of chip.

[0171] It should be noted that in other embodiments, the BMC has different names in different computing devices. For example, the BMC of Huawei servers and Super Fusion servers is called BMC, the BMC of HPE servers is called iLO, and the BMC of DELL servers is called iDRAC.

[0172] Based on the methods described in the above embodiments, this application also provides a chip. Please refer to... Figure 12 , Figure 12 This is a schematic diagram of a chip structure provided in an embodiment of this application. Figure 12 As shown, chip 1200 includes one or more processors 1201 and interface circuitry 1202. Optionally, chip 1200 may also include a bus 1203. Wherein:

[0173] Processor 1201 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by integrated logic circuits in the hardware of processor 1201 or by instructions in software form. The processor 1201 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods and steps disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor.

[0174] The interface circuit 1202 can be used to send or receive data, instructions or information. The processor 1201 can use the data, instructions or other information received by the interface circuit 1202 to process the data, instructions or other information, and can send the processed information out through the interface circuit 1202.

[0175] Optionally, chip 1200 also includes memory, which may include read-only memory and random access memory, and provides operation instructions and data to the processor. A portion of the memory may also include non-volatile random access memory (NVRAM).

[0176] Optionally, the memory stores executable software modules or data structures, and the processor can execute corresponding operations by calling the operation instructions stored in the memory (which may be stored in the operating system).

[0177] Optionally, the interface circuit 1202 can be used to output the execution results of the processor 1201.

[0178] It should be noted that the functions of the processor 1201 and the interface circuit 1202 can be implemented through hardware design, software design, or a combination of hardware and software; no restrictions are imposed here.

[0179] It should be understood that each step of the above method embodiments can be completed by hardware logic circuits or software instructions in a processor.

[0180] It is understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. In addition, in some possible implementations, each step in the above embodiments may be selectively executed according to the actual situation, and may be partially or fully executed, which is not limited here.

[0181] The method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an ASIC.

[0182] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0183] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application.

Claims

1. A firmware boot method, characterized in that, include: Obtain the client root public key and its signature; wherein the client root public key is generated based on information set by the user; Obtain the original root public key of the firmware and verify the original root public key; If the verification of the original root public key is successful, the signature of the client root public key is verified using the original root public key; If the signature verification of the client root public key by the original root public key is successful, the firmware is verified using the client root public key; If the client root public key verifies the firmware, the client root public key and its enable information are stored in a one-time programmable OTP memory. If the firmware is restarted, the firmware is verified using the client root public key; Based on the successful firmware verification, the target firmware is launched.

2. The method according to claim 1, characterized in that, The specific method for verifying the firmware based on the client root public key includes: Obtain the code signature of the customer's root public key, and verify the firmware using the code signature of the customer's root public key.

3. A chip, the chip comprising a processor and an interface circuit, the processor and the interface circuit being electrically connected, the processor storing firmware, the processor being used for: Obtain the client's root public key; where, The client root public key is generated based on information set by the user. Obtain the original root public key of the firmware and verify the original root public key; If the verification of the original root public key is successful, the signature of the client root public key is verified using the original root public key; If the signature verification of the client root public key by the original root public key is successful, the firmware is verified using the client root public key; If the client root public key is successfully verified against the firmware, the client root public key and its enable information are stored in a one-time programmable memory. If the firmware is restarted, the firmware is verified using the client root public key; Based on the successful firmware verification, the target firmware is launched.

4. A computing device, the computing device comprising a motherboard and a chip, the chip being integrated on the motherboard, the chip comprising: At least one memory for storing programs; At least one processor is configured to execute a program stored in the memory, wherein when the program stored in the memory is executed, the processor is configured to perform the method as described in any one of claims 1-2.

Images