Firmware startup method, chip and computing device

Abstract

The present invention provides a method for starting firmware, which is applied to a baseboard management controller (BMC). The BMC includes a processor and a first memory, and the processor includes a business core and a security core. When the processor is started, the security core obtains a second key from the second memory and uses the second key to verify the firmware in the security core; if the firmware in the security core is successfully verified, the firmware is run; the security core obtains a first key from the first memory and uses the first key to verify the firmware in the business core; if the business core firmware is successfully verified, the firmware is run. The key for secure firmware startup is divided into a first key and a second key, and the first key and the second key are stored in different storage media. On the basis of ensuring the security of the firmware, the business core can be opened to users, and users can independently develop and modify the business core code according to their needs.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and in particular to a firmware startup method, chip, and computing device. Background Art

[0002] During server startup, the secure boot of the server's security core and business core involves a root of trust (ROT), and both the security core and business core use the same ROT to achieve secure boot. Typically, server manufacturers program the ROT into a one-time programmable (OTP) memory during the equipment production phase. Once the root public key is programmed, it cannot be modified. However, in actual use, users may require development of the business core firmware. When the business core firmware manufacturer modifies the business core firmware to meet user requirements, they cannot obtain the ROT signature for the modified code in the OTP area. Summary of the Invention

[0003] The present invention provides a firmware boot method, chip, and computing device. The root public key for secure firmware boot is divided into a security core root public key and a business core root public key. The security core root public key is stored in the OTP area, while the business core root public key is encrypted and stored on a non-volatile storage medium. While ensuring firmware security, this method facilitates user modification of the business core root public key information and allows the business core to be open to users, allowing them to independently develop and modify the business core code as needed.

[0004] In the first aspect, the present application provides a firmware startup method, which is applied to a baseboard management controller BMC. The BMC includes a processor and a first memory. The processor includes multiple cores, wherein the multiple cores include a business core and a security core. The business core is used to perform business-related tasks, and the security core is used to perform secure startup tasks. The security core includes a second memory. The method includes: starting the processor, the security core obtains a second key from the second memory, and verifies the firmware in the security core according to the second key; if the verification of the firmware in the security core is successful, the security core runs the firmware in the security core; the security core obtains a first key from the first memory, and verifies the firmware in the business core according to the first key; if the verification of the firmware in the business core is successful, the business core runs the firmware in the business core.

[0005] That is, when the processor boots, the secure core can verify the modified firmware in the service core using the user-set service core root public key. This means the root public key for secure firmware boot is divided into two separate keys: the secure core root public key and the service core root public key. These keys are stored separately. This ensures firmware security while facilitating user modification of the service core root public key. Furthermore, the service core is open to users, allowing them to independently develop and modify the service core code as needed.

[0006] In one possible implementation, the method also includes: the security core obtains a first key and verifies the first key, where the first key is used to verify the business core firmware; if the security core successfully verifies the first key, the security core stores the first key in a first memory.

[0007] That is, when a user needs to modify the service core firmware (i.e., modify the service core code), the user can use the private key in the service core key (i.e., the first key) that the user has set to sign the modified service core firmware. The user can then send the public key of the service core key (i.e., the service core's root public key) that the user has set to the service core. The service core then sends the received service core root public key to the security core. After verifying the received service core root public key, the security core stores the service core root public key.

[0008] In one possible implementation, before starting the processor, the method also includes: the security core obtains a first message sent by the business core, the first message is used to instruct the security core to clear the first key in the first memory; the security core uses the second key to verify the first message; if the verification of the first message is successful, the security core clears the first key in the first memory.

[0009] That is, after opening the service core to the user, the user can also clear the pre-stored service core root public key information. Clearing the service core root public key will affect the booting of the service core firmware. Therefore, to prevent malicious attacks or other misoperations, the security core must carefully clear the service core root public key. Specifically, the security core must verify the legitimacy of the clearing operation before executing it.

[0010] In a possible implementation, before the security core obtains the first message sent by the service core, the method further includes: the service core obtains the first message, where the first message is used to instruct the security core to clear the first key in the first memory.

[0011] In other words, since the security core cannot directly receive information sent by external devices, the service core needs to receive it and then send it to the security core.

[0012] In a possible implementation, after the security core obtains the first key, the method further includes: the security core obtains a second message sent by the service core, where the second message is used to instruct the security core to store the first key in the first memory.

[0013] That is, after the service core sends the first key to the security core, the service core may further send a second message to the security core to instruct the security core to save the first key in the first memory.

[0014] In one possible implementation, the second memory is a one-time programmable memory.

[0015] In a possible implementation, the first memory is a serial peripheral interface memory chip or a replay protection memory block in an embedded multimedia card.

[0016] In one possible implementation, when the first memory is a serial peripheral interface memory chip, the security core stores the first key in the first memory, including: the security core uses a non-reversible encryption algorithm to generate a third key; the security core encrypts the first key based on the third key using a symmetric encryption algorithm; the security core stores the encrypted first key in the first memory.

[0017] That is, when the serial peripheral interface memory chip is used as a memory for storing the service core root public key, in order to ensure the security of the stored service core root public key, the service core root public key needs to be encrypted before being stored.

[0018] In a second aspect, the present application provides a chip, comprising a processor and an interface circuit, the processor and the interface circuit being electrically connected, the processor comprising multiple cores, wherein the multiple cores include a business core and a security core, the business core being used to execute business-related tasks, the security core being used to execute secure boot tasks, and the security core comprising a second memory;

[0019] The processor is started, the security core obtains the second key from the second memory, and verifies the firmware in the security core according to the second key;

[0020] When the firmware in the safety core is successfully verified, the safety core runs the firmware in the safety core;

[0021] The security core obtains the first key from the first memory and verifies the firmware in the service core according to the first key;

[0022] When the firmware in the service core is successfully verified, the service core runs the firmware in the service core.

[0023] In one possible implementation, the security core is used to:

[0024] Obtaining a first key and verifying the first key, where the first key is used to verify the service core firmware;

[0025] When the security check verifies the first key successfully, the security core stores the first key in the first memory.

[0026] In one possible implementation, the security core is also used to:

[0027] Receive a first message sent by the service core, where the first message is used to instruct the security core to clear the first key in the first memory;

[0028] verifying the first message using the second key;

[0029] When the first message is successfully verified, the first key in the first memory is cleared.

[0030] In one possible implementation, the service core is further used to:

[0031] A first message is obtained, where the first message is used to instruct the security core to clear a first key in the first memory.

[0032] In one possible implementation, the security core is also used to:

[0033] A second message sent by the business core is obtained, where the second message is used to instruct the security core to store the first key in the first memory.

[0034] In one possible implementation, the second memory is a one-time programmable memory.

[0035] In a possible implementation, the first memory is a serial peripheral interface memory chip or a replay protection memory block in an embedded multimedia card.

[0036] In one possible implementation, when the first memory is a serial peripheral interface memory chip, the security core is configured to:

[0037] Generate a third key using a non-reversible encryption algorithm;

[0038] encrypting the first key using a symmetric encryption algorithm based on the third key;

[0039] The encrypted first key is stored in the first memory.

[0040] In a third aspect, the present application provides a computing device comprising a processor, a memory, and a BMC; the BMC is configured to execute the method described in the first aspect or any possible implementation of the first aspect.

[0041] In a fourth aspect, the present application provides a computer-readable medium, in which instructions are stored. When the instructions are executed on a computer, the computer executes the method described in the first aspect or any possible implementation of the first aspect.

[0042] In a fifth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computer, causes the computer to execute the method described in the first aspect or any possible implementation of the first aspect.

[0043] It can be understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0045] Figure 1 A flowchart of a firmware startup method provided in an embodiment of the present application;

[0046] Figure 2 A schematic diagram of the structure of a BMC provided in an embodiment of the present application;

[0047] Figure 3 A flowchart of a firmware startup method provided in an embodiment of the present application;

[0048] Figure 4 A flowchart of a method for burning service core root public key information provided in an embodiment of the present application;

[0049] Figure 5a A flowchart of another method for burning service core root public key information provided in an embodiment of the present application;

[0050] Figure 5b A flowchart of another method for burning service core root public key information provided in an embodiment of the present application;

[0051] Figure 6 A schematic diagram of a process for generating other keys based on a security core key provided in an embodiment of the present application;

[0052] Figure 7 A schematic diagram of a verification process for other keys based on a security core key provided in an embodiment of the present application;

[0053] Figure 8A flowchart of a method for clearing a service core root public key provided in an embodiment of the present application;

[0054] Figure 9a A flowchart of another method for clearing a service core root public key provided in an embodiment of the present application;

[0055] Figure 9b A flowchart of another method for clearing a service core root public key provided in an embodiment of the present application;

[0056] Figure 10 A schematic diagram of the structure of a server provided in an embodiment of the present application;

[0057] Figure 11 A schematic diagram of the structure of a chip provided in an embodiment of the present application. DETAILED DESCRIPTION

[0058] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings.

[0059] In the description of the embodiments of this application, any embodiment or design scheme using "exemplary," "for example," or "for example" should not be understood as being more preferred or advantageous than other embodiments or designs. Rather, the use of words such as "exemplary," "for example," or "for example" is intended to present the relevant concepts in a concrete manner.

[0060] 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 identifying the technical features being referred to. Thus, features specified as "first" or "second" may explicitly or implicitly include one or more of such features. The terms "include," "comprising," "having," and their variations all mean "including but not limited to," unless otherwise specifically emphasized.

[0061] Before introducing the solutions of the present invention, the key terms required to be used in the embodiments of the present invention are first explained.

[0062] 1. The production equipment stage refers to the stage when a single board of an electronic device is in the process of being produced or programmed. A single board may refer to a circuit board with components soldered onto it. In embodiments of the present invention, a single board may be a circuit board that integrates a central processing unit (CPU), a baseboard management controller (BMC), flash memory, a bus, or other components.

[0063] 2. Live network stage, corresponding to the production equipment stage. In the embodiment of the present application, the live network stage may refer to the stage where the single board of the electronic device has been packaged into a corresponding device and can be used by the user.

[0064] 3. Business core: For heterogeneous multi-core processors, the core in the processor used to perform business-related tasks (including log storage, communication, upgrades, etc.) can be called a business core.

[0065] 4. Security core: For heterogeneous multi-core processors, the core used to perform secure boot tasks can be called a security core. The security level of the security core is higher than that of the business core, and the security core is independent of the business core. In other words, to ensure system security, the security core cannot be accessed by the business core or external devices.

[0066] 5. Firmware refers to the program written into erasable programmable read only memory (EPROM) or electrically erasable programmable read-only memory (EEPROM).

[0067] 6. Business core firmware. The firmware in the business core can be called business core firmware.

[0068] 7. Security core firmware. The firmware in the security core can be called security core firmware.

[0069] Next, the technical solutions involved in this application are introduced.

[0070] With the rapid development of networks and data centers, electronic devices in data centers face various internal and external security risks. Electronic device management systems provide server hardware management. The hardware security of electronic devices relies on the security of their own firmware (including security core firmware and service core firmware).

[0071] Figure 1 A method for starting a firmware is shown. Figure 1 As shown, during the booting process of the firmware, the security verification process of the firmware includes: S101-S107.

[0072] S101, read the root public key information from the OTP register.

[0073] S102: Use the read root public key information to verify the security core firmware.

[0074] S103, determine whether the security core firmware has passed the verification, if the verification has passed, execute S104, otherwise the security boot fails.

[0075] S104, running the security core firmware.

[0076] S105: Use the read root public key information to verify the service core firmware.

[0077] S106, determine whether the business core firmware has passed the verification, if the verification has passed, execute S107, otherwise the safe boot fails.

[0078] S107, start the service core and run the service core firmware.

[0079] exist Figure 1 The firmware boot process shown in the figure is as follows. During the equipment production phase, the manufacturer will burn the root public key into the OTP register. This burned-in root public key is the trusted root and cannot be changed. When the electronic device boots up, the root public key burned into the OTP register is used to verify the security core firmware and the business core firmware. Only after the verification passes will the corresponding firmware be booted.

[0080] Although, Figure 1 The firmware startup method shown in [1] can verify the security of the firmware. However, because the security core firmware and the business core firmware use the same root public key for verification during secure startup, and this root public key is burned into the OTP register during the equipment production phase and cannot be changed, it will result in the user being unable to sign the modified code after making changes to the business core firmware in the live network phase (the user cannot obtain the private key corresponding to the root public key stored in the OTP register). In other words, the security of the modified business core firmware cannot be guaranteed.

[0081] As open source products become increasingly popular, users have also had an increasing demand for the development of business core firmware. Therefore, in order to solve the problem in the above solution that the security core firmware and the business core firmware use the same root public key for verification during secure boot, and the root public key is burned into the OTP register during the equipment production stage, the device manufacturer cannot change it. The embodiment of the present application provides a firmware startup method that can be applied to the secure boot of electronic devices. The root public key for secure boot of electronic devices is divided into the root public key of the security core and the root public key of the business core. The root public key of the security core is stored in the OTP register, and the root public key of the business core is encrypted and stored on a non-volatile storage medium, such as a serial peripheral interface memory chip (Serial Peripheral Interface flash, SPI flash). This allows manufacturers to open the business core to users while ensuring security, and users can modify the business core according to the manufacturer's requirements.

[0082] A firmware startup method is provided in an embodiment of the present application. During the firmware startup process, the security core obtains the root public key of the security core stored in the OTP register by executing the secure boot code (boot ROM secure boot code, BSBC), and verifies the security core firmware based on the obtained root public key of the security core. After the security core firmware passes the verification, the security core runs the security core firmware. Then, the security core reads the root public key of the business core from the non-volatile storage medium of the electronic device. At this time, since the root public key of the business core read from the non-volatile storage medium is the encrypted root public key of the business core, when the security core uses the root public key of the business core to verify the business core firmware, it is also necessary to decrypt the root public key of the business core. After the security core completes the decryption of the root public key of the business core, the security core verifies the business core firmware using the decrypted root public key of the business core, and starts the business core after the business core firmware passes the verification. After the business core is started, the business core firmware runs.

[0083] The verification keys of the security core firmware and the business core firmware are separated, that is, the security core firmware is verified by the root public key of the security core stored in the OTP register, and the business core firmware is verified by the root public key of the business core stored in the non-volatile storage medium. Furthermore, in order to ensure the security and legitimacy of the root public key of the business core, before the root public key of the business core is imported into the non-volatile storage medium, it is necessary to use the root public key of the security core to verify the root public key of the business core, and encrypt the verified root public key of the business core. Therefore, after reading the root public key of the business core from the non-volatile storage medium, it is necessary to decrypt the read root public key of the business core.

[0084] The firmware startup method provided in the embodiment of the present application can be applied to the BMC on an electronic device. The BMC is a control unit with independent power supply and independent I / O interface deployed on a single board of an electronic device. It does not rely on the processor, BIOS or operating system of the electronic device to work. It is an agentless management subsystem running alone in the electronic device. When the BMC is a heterogeneous multi-core processor, the core in the processor can be divided into a security core and a business core, wherein the security core is used to perform tasks related to BMC security such as secure boot security verification inside the BMC, and the business core is used to perform tasks related to business within the BMC. Since the BMC is powered on first during the power-on process of the electronic device, the BMC is started, and after the BMC is started, the electronic device is started. Since the BMC is powered on first, it can obtain control of the electronic device system, so the BMC is particularly important for the security of the electronic device. Therefore, during the BMC startup phase, it is necessary to verify the security of the firmware (security core firmware and business core firmware) stored in the BMC.

[0085] The following describes the secure boot of firmware on a BMC as an example. It is understood that the embodiments of the present invention are not only applicable to BMCs, but are also applicable to other devices with the same structure as a BMC.

[0086] For example, the present application embodiment also provides a structural diagram of a BMC. Figure 2 As shown, the BMC may include: a processor 210, a network interface 220, and a memory 230. The processor 210, the network interface 220, and the memory 230 may be connected via a bus or other means.

[0087] In the embodiments of the present application, processor 210 (or CPU) is the computing and control core of the BMC. In one example, the CPU includes a security core and a service core. The security core is used to perform BMC security-related tasks such as secure boot and security verification within the BMC, while the service core is used to perform service-related tasks within the BMC. In one possible example, the security core also includes an OTP register.

[0088] The network interface 220 may include a standard wired interface or a wireless interface (such as Wi-Fi or a mobile communication interface), and is controlled by the processor 210 to send and receive data, for example, to receive root public key information input by a user from the network. Operations such as receiving root public key information input by a user from the network are primarily performed by the BMC's service core.

[0089] Memory 230 (memory) is a memory device of the server, which is used to store programs and data. It is understandable that the memory 230 this time can be a high-speed RAM memory, or a non-volatile memory (non-volatile memory), for example, SPI flash, at least one disk memory, or a replay protected memory block (rpmb) of an embedded Multi Media Card (eMMC); optionally, it can also be at least one storage device located away from the aforementioned processor 210. The memory 230 provides a storage space that stores the operating system and executable program code of the server, which may include but is not limited to: Windows system (an operating system), Linux system (an operating system), Hongmeng system (an operating system), etc., which are not limited here.

[0090] It is understandable that the embodiments of this application Figure 2The illustrated structure does not constitute a specific limitation on the BMC. In other embodiments of the present application, the BMC may include more or fewer components than shown, or may combine or separate certain components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0091] For example, the present application also provides a method for starting a firmware, which may be but is not limited to: Figure 2 It is understood that the business core described in this example is the BMC business core, and the security core is the BMC security core. Figure 3 , the method includes: S301-S309.

[0092] S301, the security core starts, and the security core reads the root public key information of the security core from the OTP register.

[0093] In this embodiment, the OTP register may also be referred to as the second memory, and the root public key of the secure core may also be referred to as the second key. After the BMC is powered on, the secure core starts and reads the root public key information of the secure core from the OTP register for verification of the secure core firmware.

[0094] In one possible example, if the secure core firmware is signed by the secondary key of the secure core, then after the secure core is started, the secure core reads the public key information of the secondary key of the secure core from the OTP register.

[0095] S302: The security core verifies the security core firmware using the read root public key information.

[0096] In this embodiment, the secure core uses the acquired root public key of the secure core to verify the code signature in the secure core firmware.

[0097] S303, the security core determines whether the security core firmware passes verification. If the verification passes, execute S304, otherwise the security boot fails.

[0098] In this embodiment, when the secure core uses its root public key to verify the code signature in the secure core firmware, it decrypts the code signature using the root public key to obtain a code digest of the secure core firmware. The secure core then processes the code of the secure core firmware using a one-way hash function to obtain another code digest of the secure core firmware. The secure core compares the two digests. If the two digests are equal, the security core verifies that the security core firmware has passed verification. If the two digests are unequal, the security core verifies that the security core firmware has failed verification.

[0099] S304, the security core runs the security core firmware.

[0100] In this embodiment, if the security core passes the verification, the security core runs the security core firmware. Otherwise, the security core determines that the startup has failed.

[0101] S305: The security core uses a derived key algorithm to generate encryption and decryption keys for the root public key of the service core.

[0102] In this embodiment, the root public key of the business core can also be referred to as the first key. In the process of writing the root public key of the business core to the storage medium of the BMC, in order to ensure the security of the root public key of the business core after writing, the root public key of the business core is encrypted. Therefore, when the security core needs to obtain the root public key of the business core from the storage medium of the BMC, it needs to generate an encryption and decryption key for regenerating the root public key of the business core, which can also be referred to as the third key. It can be understood that the security core uses a derived key algorithm to generate a symmetric key for the encryption and decryption of the root public key of the business core, that is, the encryption key and the decryption key are the same.

[0103] S306 , the security core reads the encrypted root public key information of the service core from the non-volatile storage medium of the BMC, and decrypts the encrypted root public key information of the service core using the generated encryption and decryption key.

[0104] In this embodiment, the non-volatile storage medium of the BMC can also be referred to as the first memory. The security core can obtain a key for decrypting the root public key of the service core using a non-reversible encryption algorithm (e.g., the HMAC algorithm). Then, based on the obtained key, the security core can use a symmetric encryption algorithm (e.g., the AES algorithm) to decrypt the obtained root public key information of the service core.

[0105] It is understood that there is no sequential order between S304, S305, and S306, and S304, S305, and S306 can be executed simultaneously. In some possible examples, S305 is optional. When the service core's root public key is stored in the rpmb area of ​​the eMMC, the security core does not need to decrypt the service core's root public key read from rpmb (it is not encrypted when stored).

[0106] S307 , the security core uses the decrypted root public key of the service core to verify the service core firmware.

[0107] In this embodiment, the security core uses the obtained root public key of the business core to verify the code signature in the business core firmware. Specifically, the security core uses the decrypted root public key of the business core to decrypt the code signature of the business core firmware to obtain a summary of the code of the business core firmware. Then, the security core uses a one-way hash function to process the code of the business core firmware to obtain another summary of the code of the business core firmware. The security core compares the two summaries. If the two summaries are equal, it is considered that the security check has passed the verification of the business core firmware. If the two summaries are not equal, it is considered that the security check has failed the verification of the business core firmware.

[0108] S308, the security core determines whether the business core firmware has passed the verification. If the verification has passed, execute S309, otherwise the security boot fails.

[0109] In this embodiment, since the security core is used to perform the BMC's secure boot and BMC's security verification tasks, the security core is responsible for verifying the service core firmware.

[0110] S309: Start the service core, and the service core runs the service core firmware.

[0111] In this embodiment, after the service core is started, the service core begins to run the service core firmware.

[0112] In an embodiment of the present application, the root public key for BMC secure boot is divided into the root public key of the security core and the root public key of the business core. The root public key of the security core is placed in the OTP area, and the root public key information of the business core is encrypted and stored on non-volatile media. While ensuring security, it is convenient for users to change the root public key information of the business core, reducing the use of the OTP area and reducing costs. After the root public key for BMC secure boot is divided into the root public key of the security core and the root public key of the business core, the business core can be opened to customers. Customers can modify the root public key of the business core according to the manufacturer's requirements and guidance, and customers can independently develop and modify the business core code according to their needs.

[0113] In one possible embodiment, before executing S301, it is also necessary to burn the service core root public key provided by the user into the non-volatile storage medium of the BMC. For example, the embodiment of the present application provides a method for burning the root public key information of the service core. The method can be but is not limited to Figure 2 It is understood that the business core described in this example is the BMC business core, and the security core is the BMC security core. Figure 4 , the method includes: S401-S404.

[0114] S401, the service core obtains the root public key information of the service core.

[0115] In this embodiment, as open source BMC (OpenBMC) becomes increasingly popular, manufacturers can open the BMC's service core to users, allowing users to modify the BMC's service core firmware (the code of the service core firmware) on their computing devices. After a user modifies the service core firmware on the BMC, to ensure the security of the modified service core firmware, the user needs to set a corresponding service core key, also known as a first key, to sign the modified service core firmware. The key information for the service core set by the user is an asymmetric key, consisting of a public key and a private key. The private key is used to sign the modified service core firmware, and the public key is used to verify the signature of the service core firmware. An asymmetric encryption algorithm can be used to obtain the public key or private key. The public key in the key set by the user for the service core can be called the service core's root public key. The service core's root public key can be generated based on the service core's private key set by the user. In other words, the service core's root public key is generated based on user-set information, such as one or more numbers set by the user. The user-set information can be, for example, the user-set private key.

[0116] It is understood that in the embodiments of the present application, the method for generating the public key and private key is not limited. The "signature" in the embodiments of the present application refers to a "digital signature." A digital signature (also known as a public key digital signature) is a string of digits that can only be generated by the sender of the information and cannot be forged by others. This string of digits also effectively proves the authenticity of the information sent by the sender.

[0117] In one possible example, after the user generates the key information of the business core, the user can send the root public key information of the business core in the business core key to the manufacturer. After the manufacturer receives the root public key information of the business core sent by the user, it needs to sign the root public key information of the business core sent by the user again. Since the security core in the BMC performs tasks related to BMC security such as secure boot security verification within the BMC. Therefore, in order to ensure the security of the security core, the root key of the security core is generally not used directly to sign the security core firmware or other information. In specific implementation, the manufacturer can use other keys obtained based on the root key of the security core to sign the security core firmware and other information. Among them, the security core root key, and other keys obtained based on the root key of the security core can be collectively referred to as the security core key or the second key.

[0118] In one possible example, Figure 5aAs shown in the figure, after the manufacturer receives the service core root public key sent by the user, it can use the private key in the security core's secondary key to sign the service core root public key information sent by the user. After the manufacturer completes the signature of the service core root public key sent by the user, it can send the signed service core root public key to the BMC service core. In other words, the service core root public key information received by the BMC service core is the service core root public key information signed with the BMC security core's secondary key.

[0119] In another possible example, in addition to signing the root public key information of the business core, the secondary key of the security core is also used to sign the security core firmware code. Signing the root public key information of the business core involves external business. In order to ensure the security of the security core firmware, in theory, the secondary key of the security core should not be used (that is, the key used to sign the root public key of the business core should be distinguished from the key used to sign the security core firmware code). Therefore, the tertiary key of the root public key of the security core can be used to sign the root public key information of the business core generated by the user. Figure 5b As shown in the figure, after the manufacturer receives the service core root public key sent by the user, it can use the private key in the third-level key of the security core root public key to sign the service core root public key information sent by the user. After the manufacturer completes the signature of the service core root public key sent by the user, it can send the signed service core root public key to the BMC service core. In other words, the service core root public key information received by the BMC service core is the service core root public key information signed with the BMC security core third-level key.

[0120] S402: After the service core obtains the root public key information of the service core, the service core sends the obtained root public key information of the service core to the security core.

[0121] In this embodiment, after the service core receives its root public key information, since the service core does not perform tasks related to BMC security, the service core also needs to send the public key information to the security core for processing.

[0122] In one possible example, after the service core sends the service core's root public key information to the security core, the BMC also needs to send an enable command to the security core, which is used to instruct the security core to enable the service core's root public key. Specifically, the service core can execute a preset code to trigger the service core to generate an enable command. The enable command is used to trigger the security core to burn the service core's root public key information into the BMC's non-volatile storage medium, and burn the enable information corresponding to the service core's root public key into the BMC's non-volatile storage medium.

[0123] S403: The security check verifies the received root public key information of the service core.

[0124] In this embodiment, in order to ensure that the security core key is not leaked and the security of the security core firmware. When the security core uses the security core key to sign the security core firmware, the security core can use other keys obtained based on the root key of the security core to encrypt the security core firmware. Among them, the root key of the security core includes: the root public key of the security core and the root private key of the security core. Other keys obtained based on the root key of the security core can be the secondary key, tertiary key, etc. of the security core key. Among them, the public key certificate of the secondary key of the security core can be verified using the root public key of the security core, and the public key certificate of the tertiary key of the security core can be verified using the public key of the secondary key of the security core. Therefore, the secondary key of the security core can also refer to the secondary key of the root public key of the security core, and the tertiary key of the security core can also refer to the tertiary key of the public key of the secondary key of the security core.

[0125] In one possible example, when the secondary key of the security core is used to sign the security core firmware code, in order to ensure the security of the security core firmware, the tertiary key of the security core can be derived based on the secondary key of the security core, and the tertiary key of the security core can be used for other services. Figure 6 As shown, the third-level key of the security core can be used for the business core's root public key import business or the business core's root public key clear business. At this time, the generated third-level key certificate of the security core can also be called the business core's root public key import certificate or the business core's root public key clear certificate.

[0126] In a possible example, if the root public key information of the service core received by the security core is signed by the manufacturer using the private key of the secondary key of the security core, then Figure 5a As shown, after receiving the service core's root public key information, the security core needs to obtain the security core's secondary key. Specifically, the security core can obtain the security core's secondary key public key by obtaining the secondary key certificate of the security root public key. The security core can then use the secondary key public key to verify the service core's root public key information to ensure that the service core's root public key information received by the security core is the service core's root public key information that the user needs to write to the BMC's non-volatile storage medium.

[0127] In another possible example, if the root public key information of the service core received by the security core is signed by the manufacturer using the private key of the third-level key of the security core, then Figure 5bAs shown, after the security core receives the root public key information of the business core, it needs to obtain the secondary key of the security core and use the secondary key of the security core to verify the third-level key certificate of the security core (also known as the root public key import certificate of the business core) to ensure that the third-level key used to verify the root public key of the business core is correct and legal. After the security core verifies the third-level key certificate, the security core obtains the secure third-level key public key in the third-level key certificate. Then, the security core can use the third-level key public key to verify the root public key information of the business core to ensure that the root public key information of the business core received by the security core is the root public key information of the business core that the user needs to write to the BMC storage medium.

[0128] After the security core uses the third-level key of the security core, the second-level key certificate and the third-level key certificate also need to be placed in the security firmware, so that the security core can perform step-by-step verification when using the security core key (including the second-level key and the third-level key) for verification. At this time, a certificate chain can be formed between the security core root key, the second-level key certificate of the security core, and the third-level key certificate of the security core. Take the root public key information of the business core verified by the security core as an example. The process of the security core using the third-level key of the security core to verify the root public key information of the business core is as follows: Figure 7 As shown. The security core's root public key can verify the security core's secondary key certificate. Based on the security core's secondary key certificate verification, the security core extracts the secondary key public key from the secondary key certificate and uses it to verify the security core's tertiary key certificate. Based on the security core's tertiary key certificate verification, the security core extracts the tertiary key public key from the tertiary key certificate and uses it to verify the service core's root public key information.

[0129] S404 , based on the security verification of the root public key information of the service core, the security verification root public key information of the service core is verified to be passed, and the encrypted root public key information of the service core is stored in the non-volatile storage medium of the BMC.

[0130] In this embodiment, after the security core verifies the received root public key information of the business core, the security core can write the verified root public key information of the business core to the non-volatile storage medium of the BMC, which can also be called the first memory. Since the root public key information of the security core stored in the BMC storage medium is at risk of being tampered with, in order to ensure the security of the root public key information of the business core after storage, the security core needs to encrypt the root public key information of the verified business core. Then, the security core stores the encrypted root public key information of the business core in the non-volatile storage medium of the BMC.

[0131] In one possible example, the security core can store the encrypted root public key information of the service core in the BMC's SPI flash. When the security core stores the verified root public key information of the service core in the BMC's SPI flash, the security core can use the HMAC algorithm to obtain the key used to encrypt the service core's root public key, also known as the third key. Then, based on the obtained key, the security core can use the AES algorithm to encrypt and store the verified root public key information of the service core.

[0132] In another possible example, for electronic devices that use eMMC for booting, the security core may have stored the encrypted root public key information of the business core in the rpmb area of ​​the eMMC. Because rpmb is securely stored, the security core does not need to perform encryption and decryption operations when reading and writing the root public key of the business core. However, accessing rpmb requires a key. Specifically, the security core can obtain the key for accessing rpmb through the hmac algorithm. For single boards that use eMMC for booting, the rpmb area is used directly to reduce encryption and decryption operations and accelerate secure booting.

[0133] It is understood that in this embodiment, the root public key information of the user-generated business core is stored in the BMC's non-volatile storage medium through the BMC's security core. This allows the user to use the user-generated business core private key to sign the modified business core firmware code after modifying the BMC business core firmware code. Furthermore, when the BMC starts the modified business core firmware, the business core firmware can be verified using the business core's root public key stored in the BMC's non-volatile storage medium to complete the secure startup of the business core firmware.

[0134] In one possible example, after the user obtains the open source code of the BMC business core firmware, the user can modify the open source code of the business core firmware as needed. After the user completes the code modification of the business core firmware, the user uses the private key in the business core key generated by the user to sign the business core firmware code and generate a new business core firmware installation package. The user then sends the newly generated business core firmware installation package to the BMC business core, so that the BMC business core can upgrade the business core firmware according to the newly generated business core firmware installation package. When the upgraded business core firmware is securely booted, it needs to use the business core private key that signed the business core firmware and the corresponding business core root public key for verification.

[0135] Before the user modifies the BMC's business core firmware, the user needs to generate business core key information for signing and verifying the business core firmware. After the user completes the modification of the BMC business core firmware, the user needs to use the pre-generated business core private key to sign the modified business core firmware. After the user completes signing the modified business core firmware, the user also needs to generate an installation package for the business core firmware and send the installation package to the BMC business core so that the BMC business core can upgrade the business core firmware according to the installation package. It can be understood that there is no order between the two actions of the user sending the generated business core firmware installation package to the BMC business core and the user sending the generated business core root public key information to the BMC business core through the manufacturer. As long as it can be ensured that when the modified business core firmware is started, the business core root public key information used to verify the business core firmware has been written into the non-volatile storage medium of the BMC.

[0136] In an embodiment of the present application, during the secure boot process of the BMC, the security core firmware and the business core firmware use different root public keys, which can facilitate the original equipment manufacturer (OEM) customers to set their own business core root public key. In most cases, the development and modification of OEM customers are mainly concentrated on the business core. The root public key of the security core can ensure that the import and deletion of the business core root public key are legal. The security core can import and erase the business core root public key information in the live network.

[0137] After the user imports the service core's root public key into the BMC's non-volatile storage medium, the user can modify the service core's root public key. It is understood that after the user changes the service core's root public key stored in the BMC, the service core firmware must also be updated simultaneously to ensure that the BMC's service core firmware can be correctly started after the service core's root public key is updated.

[0138] Exemplarily, the present invention provides a method for clearing the root public key of the service core. The method can be but is not limited to Figure 2 BMC implementation shown. Figure 8 , the method includes: S801-S804.

[0139] S801: The service core receives a service core root public key clearing command sent by the manufacturer.

[0140] In this embodiment, the manufacturer may send a command to clear the root public key of the service core by sending a first message to the service core, wherein the first message is used to instruct the security core to clear the service core root public key information (i.e., the first key in the above embodiment) in the non-volatile storage medium of the BMC (i.e., the first memory in the above embodiment).

[0141] To clear the service core's root public key information pre-written to the BMC's non-volatile storage medium, the user sends a command to the manufacturer to clear the service core's root public key. After receiving the command, the manufacturer signs the command using the security core's root public key information.

[0142] In one possible example, Figure 9a As shown, after the manufacturer receives the service core root public key clearing command sent by the user, the manufacturer can use the private key in the secondary key of the security core to sign the service core root public key clearing command sent by the user. After the manufacturer completes the signature of the service core root public key clearing command sent by the user, it can send the signed service core root public key clearing command to the BMC service core. In another possible example, Figure 9b As shown, after the manufacturer receives the service core root public key clearing command sent by the user, the manufacturer can use the private key in the third-level key of the security core root public key to sign the service core root public key clearing command sent by the user. After the manufacturer completes the signature of the service core root public key clearing command sent by the user, it can send the signed service core root public key clearing command to the BMC service core.

[0143] S802: The business core sends a root public key clearing command of the business core to the security core.

[0144] In this embodiment, after the business core receives the business core root public key clearing command, since the business core does not perform tasks related to BMC security, the business core also needs to send the received business core root public key clearing command to the security core for processing.

[0145] S803, the security check verifies the service core root public key clearing command sent by the service core.

[0146] In this embodiment, clearing the service core's root public key from the BMC storage medium will affect the startup of the service core firmware on the BMC. Therefore, to prevent malicious attacks or other misoperations, the security core must carefully clear the service core's root public key. Specifically, before executing the clear command, the security core must verify the legitimacy of the clear command.

[0147] In one possible example, if the root public key clearing command received by the security core from the service core is signed by the manufacturer using the private key of the secondary key of the security core, then Figure 9a As shown, after receiving the service core's root public key clear command, the security core needs to obtain the security core's secondary key. Specifically, the security core can obtain the security core's secondary key public key by obtaining the secondary key certificate for the security root public key. The security core can then use this secondary key public key to verify the service core's root public key clear command to ensure that the received service core root public key clear command is legitimate.

[0148] In another possible example, if the root public key clearing command received by the security core from the service core is signed by the manufacturer using the private key of the third-level key of the security core, then Figure 9b As shown, after the security core receives the root public key clearing command of the business core, it needs to obtain the secondary key of the security core and use the secondary key of the security core to verify the third-level key certificate of the security core (also called the root public key clearing certificate of the business core) to ensure that the third-level key used to verify the root public key clearing command of the business core is correct and legal. After the security core verifies the third-level key certificate, the security core obtains the secure third-level key public key in the third-level key certificate. Then, the security core can use the third-level key public key to verify the root public key clearing command of the business core to ensure that the received root public key clearing command of the business core is legal.

[0149] S804: If the service core's root public key clearing command is verified to be successful, the security core clears the service root public key information from the storage area of ​​the BMC.

[0150] In this embodiment, after the security core verifies and passes the received root public key clearing command of the service core, the security core may execute the root public key clearing command of the service core.

[0151] In one possible embodiment, after clearing the root public key of the service core, the user can import the root public key information of a new service core. After the user imports the root public key information of the new service core, the service core firmware corresponding to the newly imported root public key information must also be upgraded simultaneously.

[0152] Based on the method in the above embodiment, the present application embodiment also provides a server, see Figure 10 , Figure 10 This is a schematic diagram of the structure of a server provided in an embodiment of the present application. Figure 10 As shown, the server includes: a processor, a memory, a network interface and a BMC. The BMC deployed on the server can be as follows Figure 2 When the BMC on the server is running, the BMC can execute the method in the above embodiment.

[0153] Based on the method in the above embodiment, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method in the above embodiment.

[0154] Based on the method in the above embodiment, an embodiment of the present application provides a computer program product, characterized in that when the computer program product runs on a processor, the processor executes the method in the above embodiment.

[0155] Based on the methods in the above embodiments, an embodiment of the present application provides a computing device, which includes a motherboard and a chip. The chip is integrated on the motherboard, and the chip includes at least one memory for storing programs; and at least one processor for executing the programs stored in the memory. When the programs stored in the memory are executed, the processor is used to execute the methods in the above embodiments. In the embodiments of the present application, the computing device can be a network device such as a server or a host. The chip can be a BMC, a chip storing BIOS, etc. In the embodiments of the present application, there is no limitation on the type of computing device and the type of chip.

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

[0157] Based on the method in the above embodiment, the present application embodiment also provides a chip. Figure 11 , Figure 11 This is a schematic diagram of the structure of a chip provided in an embodiment of the present application. Figure 11 As shown, the chip 1100 includes one or more processors 1101 and an interface circuit 1102. Optionally, the chip 1100 may further include a bus 1103, and the processor 1101 may further include a business core and a security core, and the security core may further include an OTP register ( Figure 11 not shown).

[0158] The processor 1101 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by an integrated logic circuit of hardware in the processor 1101 or instructions in the form of software. The above-mentioned processor 1101 can be a general-purpose processor, a digital communicator (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component. The various methods and steps disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc.

[0159] The interface circuit 1102 can be used to send or receive data, instructions or information. The processor 1101 can use the data, instructions or other information received by the interface circuit 1102 to process it, and can send the processing completion information through the interface circuit 1102.

[0160] Optionally, the chip 1100 further includes a memory, which may include a read-only memory and a random access memory, and provides operation instructions and data to the processor. Part of the memory may also include a non-volatile random access memory (NVRAM).

[0161] Optionally, the memory stores an executable software module or a data structure, and the processor can perform corresponding operations by calling an operation instruction stored in the memory (the operation instruction may be stored in an operating system).

[0162] Optionally, the interface circuit 1102 may be configured to output the execution result of the processor 1101 .

[0163] It should be noted that the corresponding functions of the processor 1101 and the interface circuit 1102 can be implemented through hardware design, software design, or a combination of hardware and software, and there is no limitation here.

[0164] It should be understood that each step of the above method embodiment can be completed by a hardware-based logic circuit or a software-based instruction in a processor.

[0165] It is understood that the order of execution of the steps in the above embodiments does not necessarily imply a specific order of execution. The order of execution of each process should be determined by its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. In addition, in some possible implementations, the steps in the above embodiments can be selectively executed according to actual circumstances, and can be executed partially or completely, which is not limited here.

[0166] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part 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, the process or function described in the embodiment of the present application is generated in whole or in part. 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 via 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 a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. 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 includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state drive (SSD)).

[0167] It will be understood that the various numerical numbers involved in the embodiments of the present application are merely distinctions for the convenience of description and are not intended to limit the scope of the embodiments of the present application.

Claims

1. A method for starting a firmware, characterized in that: Applied to a baseboard management controller (BMC), the BMC includes a processor and a first memory, the processor includes multiple cores, wherein the multiple cores include a business core and a security core, the business core is used to perform business-related tasks, the security core is used to perform secure boot tasks, the security core includes a second memory, wherein the first memory is a non-volatile storage medium of the BMC, and the second memory is a one-time programmable memory (OTP), the method includes: Starting the processor, causing the security core to obtain a second key from the second memory, and verifying the firmware in the security core according to the second key; In the case where the firmware in the security core is successfully verified, the security core runs the firmware in the security core; The security core obtains a first key from the first memory, and verifies the firmware in the service core according to the first key; When the firmware in the service core is successfully verified, the service core runs the firmware in the service core.

2. The method according to claim 1, characterized in that Before starting the processor, the method further includes: The security core obtains a first key and verifies the first key, where the first key is used to verify the service core firmware; When the security core verifies the first key successfully, the security core stores the first key in the first memory.

3. The method according to claim 1, characterized in that The method further comprises: The security core obtains a first message sent by the service core, where the first message is used to instruct the security core to clear a first key in the first memory; The security core verifies the first message using the second key; When the first message is successfully verified, the security core clears the first key in the first memory.

4. The method according to claim 3, characterized in that Before the security core obtains the first message sent by the service core, the method further includes: The service core obtains the first message, where the first message is used to instruct the security core to clear the first key in the first memory.

5. The method according to claim 2, characterized in that After the security core obtains the first key, the method further includes: The security core obtains a second message sent by the service core, where the second message is used to instruct the security core to store the first key in the first memory.

6. The method according to any one of claims 1 to 5, characterized in that The first memory is a serial peripheral interface memory chip or a replay protection memory block in an embedded multimedia card.

7. The method according to claim 6, characterized in that When the first memory is a serial peripheral interface memory chip, the security core stores the first key in the first memory, including: The security core generates a third key using a non-reversible encryption algorithm; The security core encrypts the first key using a symmetric encryption algorithm based on the third key; The security core stores the encrypted first key in the first memory.

8. A chip comprising a processor, a first memory, and an interface circuit, wherein the processor and the interface circuit are electrically connected, the processor comprising multiple cores, wherein the multiple cores comprise a business core and a security core, the business core being configured to execute business-related tasks, the security core being configured to execute secure boot tasks, and the security core comprising a second memory, wherein: The first memory is a non-volatile storage medium of the BMC, and the second memory is a one-time programmable memory OTP; Starting the processor, causing the security core to obtain a second key from the second memory, and verifying the firmware in the security core according to the second key; In the case where the firmware in the security core is successfully verified, the security core runs the firmware in the security core; The security core obtains a first key from the first memory, and verifies the firmware in the service core according to the first key; When the firmware in the service core is successfully verified, the service core runs the firmware in the service core.

9. The chip according to claim 8, characterized in that The safety core is used to: Obtaining a first key and verifying the first key, where the first key is used to verify the service core firmware; When the security core verifies the first key successfully, the security core stores the first key in the first memory.

10. The chip according to claim 8, characterized in that The safety core is also used to: Receiving a first message sent by the service core, where the first message is used to instruct the security core to clear a first key in the first memory; verifying the first message using the second key; If the first message is successfully verified, the first key in the first memory is cleared.

11. The chip according to claim 10, characterized in that The business core is also used for: Obtain the first message, where the first message is used to instruct the security core to clear the first key in the first memory.

12. The chip according to claim 9, characterized in that The safety core is also used to: A second message sent by the business core is obtained, where the second message is used to instruct the security core to store the first key in the first memory.

13. The chip according to any one of claims 8 to 12, characterized in that: The first memory is a serial peripheral interface memory chip or a replay protection memory block in an embedded multimedia card.

14. The chip according to claim 13, characterized in that When the first memory is a serial peripheral interface memory chip, the security core is used to: Generate a third key using a non-reversible encryption algorithm; Encrypting the first key using a symmetric encryption algorithm based on the third key; The encrypted first key is stored in the first memory.

15. A computing device, characterized in that The computing device includes a processor, a memory, and a BMC, and the BMC is configured to execute the method according to any one of claims 1 to 7.

Images