METHOD TO SECURELY ALLOW A CUSTOMER TO INSTALL AND BOOT THEIR OWN FIRMWARE, WITHOUT COMPROMISING SECURE BOOT

• US 20200134185A1
• Filed: 10/26/2018
• Published: 04/30/2020
• Est. Priority Date: 10/26/2018
• Status: Active Grant

• Current Assignee: Dell Products LP (Dell Technologies Inc.)
• Original Assignee: Dell Products LP (Dell Technologies Inc.)
• Inventors: Cho, Eugene David, Brown, Michael Emery, Savage, Marshal F.
• Granted Patent: US 11,151,255 B2
• Time in Patent Office: Days
• CPC Class Codes: G06F 21/572 Secure firmware programming, e.g. of basic input output system [BIOS]
• CPC Class Codes: G06F 21/575 Secure boot
• CPC Class Codes: G06F 21/602 Providing cryptographic facilities or services

Abstract

In one or more embodiments, one or more systems, methods, and/or process may allow a customer to install and boot their own firmware securely, without compromising secure boot. A baseboard management controller (BMC) may include a BMC firmware stored via a BMC partition of a non-volatile storage, a customer firmware image including a customer firmware and a signed customer boot block (CBB) file including a CBB, a hidden root key (HRK) hash of the CBB based on a HRK, and a manufacturer signature. The BMC firmware may, when an alternate path to boot the CBB is detected, verify the manufacturer signature on the CBB and the HRK hash, verify the HRK hash based on the unique HRK, and when the manufacturer signature and the HRK hash have been verified, hardware lock the BMC partition, disable the HRK, and transfer control to the CBB.

Claims

1. A baseboard management controller (BMC), comprising:

a central processing unit (CPU) including a unique hidden root key (HRK) associated with the BMC;

a non-volatile storage including BMC partitions and a customer firmware partition, the BMC partitions including a non-volatile storage partition, a non-volatile storage boot block partition, a BMC firmware partition, and a recovery partition;

a customer firmware image stored via the customer firmware partition, the customer firmware image including a customer firmware and a signed customer boot block file, the signed customer boot block file including a customer boot block, a HRK hash of the customer boot block based on the unique HRK, and a manufacturer signature utilized to sign the customer boot block and the HRK hash; and

a BMC firmware stored via the BMC firmware partition, which when executed by the CPU, causes the BMC to;

when an alternate path to boot the customer boot block is detected, verify the manufacturer signature on the customer boot block and the HRK hash of the customer boot block; and

when the manufacturer signature has been verified, verify the HRK hash of the customer boot block based on the unique HRK.

2. The BMC of claim 1, wherein the customer boot block further includes a set of public keys, and wherein the customer boot block to:

verify each subsequent stage of the customer firmware based on a corresponding public key of the set public keys prior to executing the subsequent stage of the customer firmware.

3. The BMC of claim 1, wherein the BMC firmware further causes the BMC to:

when the manufacturer signature has been verified and when the HRK hash has been verified;

hardware lock, at a non-volatile storage boot block partition level, the BMC partitions of the non-volatile storage;

disable the HRK; and

when the BMC partitions have been hardware locked and the HRK has been disabled, transfer control to the customer boot block.

4. The BMC of claim 1,

wherein the HRK includes a symmetric advanced encryption standard (AES) cryptographic key based on one-time programmable (OTP) fuse bits fused in a first configuration;

and

wherein, during a re-manufacturing of the BMC, one or more additional OTP fuse bits are fused in a second configuration to cause the verification of the HRK hash of the customer boot block based on the OTP fuse bits fused in the first configuration to fail.

5. The BMC of claim 1, wherein the unique HRK associated with the BMC prevents the customer boot block and the HRK hash of the customer boot block from working on another BMC.

6. The BMC of claim 1, the BMC further comprising:

firmware update code to;

prior to the customer firmware image being stored via the customer firmware partition;

receive the customer firmware image uploaded to the BMC; and

write the customer firmware image only to the customer firmware partition to prevent the BMC partitions from being overwritten, wherein the customer firmware image is written as a file and used as a chain load from the BMC firmware.

7. The BMC of claim 1, wherein, prior to the customer firmware image being stored via the customer firmware partition, a customer authorization process was utilized to:

verify that a customer associated with the customer boot block file is authorized to run customer firmware on the BMC based on customer authorization information, a customer identification (ID) associated with the customer, and a BMC ID associated with the BMC; and

when the customer is authorized to run customer firmware on the BMC;

sign the customer boot block file using the manufacturer signature.

8. The BMC of claim 1, wherein, when at least one of the verification of the manufacturer signature has failed and the verification of the HRK hash has failed:

utilize a normal path to boot to a normal firmware image, the normal firmware image including normal firmware and a signed normal boot block file, the normal boot block file including a normal boot block.

9. A baseboard management controller (BMC) firmware verification system, comprising:

a manufacturer system; and

a BMC including;

a first central processing unit (CPU) including a unique hidden root key (HRK) associated with the BMC;

a non-volatile storage including BMC partitions and a customer firmware partition, the BMC partitions comprising a non-volatile storage partition, a non-volatile storage boot block partition, a BMC firmware partition, and a recovery partition;

a customer firmware image stored via the customer firmware partition, the customer firmware image including a customer firmware and a signed customer boot block file, the signed customer boot block file comprising a customer boot block, a HRK hash of the customer boot block based on the unique HRK, and a manufacturer signature utilized to sign the customer boot block and the HRK hash; and

a BMC firmware stored via the BMC firmware partition, which when executed by the first CPU, causes the BMC to;

when an alternate path to boot the customer boot block is detected, verify the manufacturer signature on the customer boot block and the HRK hash of the customer boot block; and

when the manufacturer signature has been verified, verify the HRK hash of the customer boot block based on the unique HRK.

10. The BMC firmware verification system of claim 9, wherein the customer boot block further includes a set of public keys, and wherein the customer boot block to:

verify each subsequent stage of the customer firmware based on a corresponding public key of the set public keys prior to executing the subsequent stage of the customer firmware.

11. The BMC firmware verification system of claim 9, wherein the BMC firmware further causes the BMC to:

when the manufacturer signature has been verified and when the HRK hash has been verified;

hardware lock, at a non-volatile storage boot block partition level, the BMC partitions of the non-volatile storage;

disable the HRK; and

when the BMC partitions have been hardware locked and the HRK has been disabled, transfer control to the customer boot block.

12. The BMC firmware verification system of claim 9,

wherein the HRK includes a symmetric advanced encryption standard (AES) cryptographic key based on one-time programmable (OTP) fuse bits fused in a first configuration;

and

wherein, during a re-manufacturing of the BMC, one or more additional OTP fuse bits are fused in a second configuration to cause the verification of the HRK hash of the customer boot block based on the OTP fuse bits fused in the first configuration to fail.

13. The BMC firmware verification system of claim 9, wherein the unique HRK associated with the BMC prevents the customer boot block and the HRK hash of the customer boot block from working on another BMC.

14. The BMC firmware verification system of claim 9, wherein the BMC further includes:

firmware update code, which when executed by the first CPU, causes the BMC to;

prior to the customer firmware image being stored via the customer firmware partition;

receive the customer firmware image uploaded to the BMC; and

write the customer firmware image only to the customer firmware partition to prevent the BMC partitions from being overwritten, wherein the customer firmware image is written as a file and used as a chain load from the BMC firmware.

15. The BMC firmware verification system of claim 9,

wherein the BMC firmware further causes the BMC to generate the HRK hash;

wherein the manufacturer system further comprises;

a memory;

a second CPU, different from the first CPU, coupled to the memory;

customer authorization information stored via the memory; and

a customer authorization process stored via the memory and executable by the second CPU; and

wherein, prior to the customer firmware image being stored via the customer firmware partition, the customer authorization process causes the manufacturer system to;

receive the customer boot block file, the HRK hash generated by the BMC, a customer identification (ID) associated with a customer, and a BMC ID associated with the BMC from a customer system;

verify that the customer is authorized to run customer firmware on the BMC based on the customer authorization information, the customer ID, and the BMC ID; and

when the customer is authorized to run customer firmware on the BMC;

sign the customer boot block file and the HRK hash using the manufacturer signature; and

send the signed customer boot block file and the HRK hash to the customer system.

16. The BMC firmware verification system of claim 9, wherein, when at least one of the verification of the manufacturer signature has failed and the verification of the HRK hash has failed:

utilize a normal path to boot to a normal firmware image, the normal firmware image including normal firmware and a signed normal boot block file, the normal boot block file comprising a normal boot block.

17. A method, comprising:

verifying, by a baseboard management controller (BMC) firmware, a manufacturer signature on a customer boot block of a signed customer boot block file and a hidden root key (HRK) hash of the customer boot block, when an alternate path to boot the customer boot block is detected,

wherein the BMC firmware stored via a BMC firmware partition of BMC partitions of a non-volatile storage of a BMC,

wherein the signed customer boot block file in a customer firmware image stored via a customer firmware partition of the non-volatile storage,

wherein the customer firmware image further includes a customer firmware,

wherein the HRK hash of the customer boot block is based on a unique HRK of a central processing unit (CPU) of the BMC,

wherein the signed customer boot block file further includes the HRK hash of the customer boot block and the manufacturer signature utilized to sign the customer boot block and the HRK hash, and

wherein the BMC partitions further comprise a non-volatile storage partition, a non-volatile storage boot block partition, and a recovery partition; and

when the manufacturer signature has been verified, verifying, by the BMC firmware, the HRK hash of the customer boot block based on the unique HRK.

18. The method of claim 17, wherein the customer boot block further includes a set of public keys;

the method further comprising;

verifying, by the customer boot block, each subsequent stage of the customer firmware based on a corresponding public key of the set public keys prior to executing the subsequent stage of the customer firmware.

19. The method of claim 17, wherein the HRK comprises a symmetric advanced encryption standard (AES) cryptographic key based on one-time programmable (OTP) fuse bits fused in a first configuration;

the method further comprising;

during a re-manufacturing of the BMC, fusing one or more additional OTP fuse bits in a second configuration to cause the verification of the HRK hash of the customer boot block based on the OTP fuse bits fused in the first configuration to fail.

20. The method of claim 17, further comprising:

when the HRK hash has been verified;

hardware locking, by the BMC firmware at non-volatile storage boot block partition level, the BMC partitions of the non-volatile storage;

disabling, by the BMC firmware, the HRK; and

when the BMC partitions have been hardware locked and the HRK has been disabled, transferring, by the BMC firmware, control to the customer boot block.