Managing use of management controller secrets based on firmware ownership history

Abstract

The present disclosure relates to managing use of a management controller secret based on a history of ownership of firmware. A management controller of a computer platform determines whether a history of ownership of management firmware of the management controller represents multiple owners. The management controller includes a set of one-time programmable elements representing a first secret. The management controller manages use of the first secret based on the history of ownership. The management includes, in response to a determination by the management controller that the history of ownership represents multiple owners, generating, by the management controller, a second secret in place of the first secret. The management further includes, in response to a determination by the management controller that the history of ownership represents multiple owners, storing, by the management controller, the second secret in a non-volatile memory, and generating, by the management controller, a cryptographic key based on the second secret.

Description

Background Technology

[0001] A computer platform (e.g., a server) may include a dedicated service processor, referred to as a "Baseboard Management Controller" or "BMC," which, in addition to having other potential functions, monitors the physical state of the computer platform. The BMC can communicate with a remote management server via a management network to report information about the computer platform and allow the remote management server to control actions performed by the BMC. Examples of its role include: monitoring sensors (e.g., temperature sensors, cooling fan speed sensors); monitoring operating system status; monitoring power supply status; logging computer system events; performing remotely controlled computer platform functions (e.g., powering on and off the computer platform); and so on. Attached Figure Description

[0002] Figure 1 This is a schematic diagram of a computer platform with a baseboard management controller (BMC) according to an example embodiment, which provides firmware ownership history for BMC-managed firmware and includes features for securely transferring ownership of managed firmware.

[0003] Figure 2 It is a flowchart depicting the process by which the BMC, according to an example implementation, securely transfers ownership of the management firmware executed by the BMC from the computer platform manufacturer owner to another owner and updates the transfer bit.

[0004] Figure 3 It is a flowchart depicting the process by which, according to an example implementation, the BMC securely transfers ownership of the management firmware executed by the BMC from another owner to the owner of the computer platform manufacturer.

[0005] Figure 4 It is a flowchart depicting a process for managing the use of secrets of the management controller based on firmware ownership history, according to an example implementation.

[0006] Figure 5 This is a schematic diagram of a management controller that manages the use of secrets of the management controller based on firmware ownership history, according to an example implementation.

[0007] Figure 6 This is an illustration of machine-executable instructions stored on a non-transitory machine-readable storage medium according to an example embodiment, which, when executed by a machine, cause the board management controller to manage the use of the board management controller's secrets based on firmware ownership history. Detailed Implementation

[0008] The BMC (Binary Management Controller) can execute a set of firmware instructions, called the "firmware management stack," to perform various management-related functions of the computer platform. For example, the BMC can provide management-related functions such as operating system runtime services, resource detection and initialization, and pre-operating system services. Management-related functions can also include remote management capabilities for the computer platform. For example, remote management functions may include: keyboard and video mouse (KVM) functionality; virtual power functionality (e.g., remote activation for remotely setting power states such as power-saving, power-on, reset, or power-off); virtual media management functionality; and so on. In addition to providing management functions for the computer platform, the BMC can provide security-related features to protect the computer platform from security threats.

[0009] The computer platform manufacturer can provide a proprietary firmware management stack to the BMC. In this way, the computer platform can come with a firmware image (i.e., a collection of binary data representing a set of machine-executable instructions and data), which is stored in the platform's non-volatile memory and corresponds to the BMC's management stack. The manufacturer is considered the owner of the firmware image. In this context, the "owner" of the firmware image (or "firmware") refers to the owner of the asymmetric key used to sign the firmware image. Signing the firmware image allows the BMC to verify the firmware image, that is, to determine that the owner of the asymmetric key provided the firmware image and to determine that the firmware image has not been altered.

[0010] More specifically, the owner of a firmware image can sign the firmware image using the private key portion of their asymmetric key. As an example, the signature could be the hash of the firmware image encrypted with the private key portion of the owner's asymmetric key. One way to verify the firmware image is for the BMC to decrypt the signature based on the public key portion of the owner's asymmetric key (which is distributed via a public key infrastructure) to obtain a decrypted value. The BMC can then compare the hash of the firmware image with the decrypted value to verify that the two values ​​are the same (i.e., determine if a match has occurred, which results in the firmware image being "verified").

[0011] Some computer platform customers may rely on manufacturer-owned BMC firmware because they may prefer commercial solutions. Other customers may prefer using BMC-managed firmware rather than manufacturer-owned firmware, and therefore, these customers may rewrite (e.g., flash) the firmware memory of their computer platforms with different firmware images. For example, a given customer might want to use the same open-source BMC firmware management stack to manage all of the customer's computer platforms, regardless of the specific manufacturer of those platforms. As an example, the open-source firmware management stack could be firmware developed as part of the OpenBMC community, such as release version 2.7 or later.

[0012] Using non-manufacturer-owned BMC management firmware can present problems. For example, customers using open-source BMC management firmware may lack the resources to thoroughly analyze all potential security issues involved (e.g., vulnerabilities in the firmware itself, vulnerabilities in the firmware's use on a particular computer platform, etc.). Furthermore, using non-manufacturer-owned BMC management firmware can introduce trust issues, as the security assets or secrets of the BMC (and the computer platform) may be exposed to the firmware. Therefore, even if manufacturer-owned BMC management firmware is currently installed on a computer platform, the platform may be untrustworthy if, for example, open-source BMC management firmware was previously installed on it, because that other firmware could access the BMC's secrets. Trust issues can extend to computer platforms where the full ownership history of the BMC management firmware is unknown. For example, when a computer platform is refurbished and resold as a spare (e.g., a spare blade server), when a computer platform has more than one owner, and when the full ownership history of the BMC management firmware for a given computer platform may be unknown.

[0013] According to an example implementation, the BMC of a computer platform includes and maintains a one-time programmable element (e.g., a fuse) representing the history of ownership of the BMC management firmware of the computer platform. According to an example implementation, the one-time programmable element has one of two states: a first state indicating that the BMC management firmware owned by a certain owner (e.g., the manufacturer owner) is used only on the computer platform; and a second state indicating that the BMC management firmware has more than one owner.

[0014] For example, according to some implementations, when the BMC is first put into production, the ownership transfer bit of the BMC (referred to herein as the "transfer bit") may have an initial state (e.g., state "0" or "unset," corresponding to an unblown fuse). According to an example implementation, the transfer bit has the same initial value as long as ownership of the BMC management firmware remains with the original manufacturer owner. The BMC may allow the use of non-manufacturer-owned BMC management firmware. When a non-manufacturer-owned BMC firmware image is used on a computer platform (e.g., when memory storing a manufacturer-owned firmware image is overwritten with a new firmware image), the BMC changes the state of the transfer bit (e.g., blows a fuse to assign a state "1" or "set" to the transfer bit) to indicate or suggest that non-manufacturer-owned BMC management firmware has been used. According to an example implementation, the state of the transfer bit indicating the use of non-manufacturer-owned firmware cannot be restored to its initial state regardless of whether the manufacturer-owned firmware is reinstalled. Therefore, the trust level of the computer platform, i.e., whether non-manufacturer-owned BMC management firmware is being used, can be assessed based on the state of the transfer bit.

[0015] According to an example implementation, the BMC can take specific actions based on the state of the transition bits at each boot or startup. These actions can include actions taken by the BMC to manage the use of the master secret based on the state of the transition bits. In this case, the "master secret" refers to the secret from which the BMC derives other secrets. As an example, the master secret can be a cryptographic key or a seed. The BMC can use the master secret as a measure to circumvent potential tampering. For example, for security purposes, the BMC may not store certain cryptographic keys in non-volatile memory that remains even after power loss as a measure to prevent access to the cryptographic keys through tampering. At each boot, the BMC can use the master secret as input to various key generation algorithms to generate certain cryptographic keys instead of storing the cryptographic keys in non-volatile memory. For example, the cryptographic keys generated from the master secret can include one or more of the following: a key for encrypting secure storage areas; a Transport Layer Security (TLS) key; an Initial Device Identifier (IDevID) key; a key passed to the Unified Extensible Firmware Interface (UEFI); a key for encrypting the entire non-volatile memory; a key for encrypting configuration data stored in non-volatile memory; and so on.

[0016] According to an example implementation, the manufacturer encodes the BMC's key secret into a set of one-time programmable elements (e.g., fuses) within the BMC. This key secret is accessible to the BMC management firmware. Therefore, if non-manufacturer-owned BMC management firmware is installed or has been installed on a computer platform, a trust issue may arise. In other words, from a trust perspective, if non-manufacturer-owned BMC management firmware is installed on a computer platform, it can be assumed that the key secret stored in that set of one-time programmable elements has been compromised. Therefore, according to an example implementation, the BMC can generate a new key secret (instead of the key secret stored in the one-time programmable elements) in response to determining that a transfer bit (indicating a transfer of firmware ownership to a non-manufacturer owner) has been set. The BMC can store the newly generated key secret in: secure non-volatile memory (e.g., a Hardware Security Module (HSM)); the memory of a Trusted Platform Module (TPM); non-volatile random access memory (NVRAM); flash memory; persistent memory; a set of one-time programmable elements (e.g., one-time programmable fuses and / or antifuses); etc. The BMC can then use the master secret stored in secure memory (instead of the master secret stored in the BMC's one-time programmable element) to generate a cryptographic key. Furthermore, according to the example implementation, the BMC can generate a new master secret at any time when ownership of the BMC management firmware is transferred from a non-manufacturer owner to a manufacturer owner.

[0017] refer to Figure 1As a more specific example, according to some implementations, computer platform 100 includes a management controller (or "service processor") such as a BMC129. According to an example implementation, a blade server is an example of computer platform 100. However, according to further implementations, computer platform 100 can be a platform other than a blade server, such as a rack server, storage array, modular switch, laptop, smartphone, client, desktop, etc.

[0018] Regardless of its specific form, computer platform 100 includes hardware capable of processing machine-executable instructions, and a frame or chassis on which that hardware is mounted. For example, computer platform 100 may include one or more motherboards that can be mounted on a chassis, and each motherboard may contain one or more multi-core CPU semiconductor packages (or “slots” or “chips”). As an example, in an implementation where computer platform 100 is a blade server, the blade server may have a form factor, one or more mechanical latches, and corresponding electrical connectors for allowing the blade server to be installed in and removed from corresponding server blade openings or slots in a rack-mounted blade housing.

[0019] As used herein, the BMC is a dedicated service processor that uses sensors to monitor the physical status of servers or other hardware and communicates with the management system via a management network. The BMC can also communicate with applications running at the operating system level through: Input / Output Controller (IOCTL) interface drivers, Representational State Transfer (REST) ​​application programming interfaces (APIs), or some system software agent that facilitates communication between the board management controller and the application. The BMC has hardware-level access to hardware devices located in the server chassis, including system memory. The BMC can directly modify hardware devices. The BMC can run independently of the operating system of the system in which the BMC is configured. The BMC can reside on the motherboard or main board of the server or other device to be monitored. The fact that the BMC is mounted on the motherboard of the managed server / hardware or otherwise connected or attached to the managed server / hardware does not prevent the BMC from being considered "decoupled" from the server / hardware. As used herein, the BMC has the ability to manage subsystems of computing devices and is decoupled from the processing resources that execute the operating system of the computing device. The BMC is decoupled from the processor (such as the central processing unit) that executes the higher-level operating system or hypervisor on the system.

[0020] According to some implementations, the BMC 129 provides a management plane and a security plane that are isolated from each other. The BMC's firmware management stack executes in the management plane. According to an example implementation, components in the BMC's security plane are isolated from other components of the computer platform by a firewall. In this context, a "firewall" refers to a communication barrier that strictly controls communication. As an example, according to some implementations, communication through the firewall can be regulated by using a security service application programming interface (API).

[0021] More specifically, according to the example implementation, the security plane of the BMC includes a security enclosure 140, and the security enclosure 140 includes a security memory 144 that can store one or more secrets 145 of the computer platform 100. Secrets 145 may include secrets of the host 101 of the computer platform 100, and secrets 145 may include secrets of the BMC 129. "Host" refers to a component of the computer platform 100 (e.g., one or more central processing unit (CPU) cores 102 and system memory 104) that performs at least one of the following two actions: providing an operating system 113 (e.g., a Linux operating system) to create an operating system environment for the computer platform 100, or providing a pre-boot environment (e.g., providing a Basic Input / Output System (BIOS) and / or a Unified Extensible Firmware Interface (UEFI) 111) to prepare the computer platform for the operating system environment.

[0022] According to an example implementation, the security enclosure 140 may include one-time programmable elements 165 (e.g., a collection of fuses and / or antifuses) that may collectively indicate or represent a master secret 161, which the BMC 129 uses to generate a given set of cryptographic keys at each boot of the BMC 129 (i.e., the BMC 129 may not store the generated cryptographic keys in non-volatile memory (i.e., memory that persists after power loss)). Furthermore, according to an example implementation, the security enclosure 140 may include one-time programmable elements 160 (e.g., fuses or antifuses) that may indicate or represent the state of the BMC firmware management ownership transfer bit 162 (referred to herein as "transfer bit 162").

[0023] According to an example implementation, in response to a transfer bit 162 being in an initial state (e.g., an unset state), the BMC 129 uses a master secret stored in a one-time programmable element 165 to generate the given set of cryptographic keys. Here, "initial state" means that the manufacturer has always owned the BMC's administrative firmware for the firmware ownership history of the BMC 129. According to an example implementation, when the transfer bit 162 has a state other than the initial state (e.g., the transfer bit 162 is set), the BMC 129 does not use the master secret 161 encoded into the one-time programmable element 165 to generate the given set of cryptographic keys. Instead, the BMC 129 uses the master secret stored in the non-volatile memory 174 of a hardware security module (HSM) 172 external to the BMC 129. Note that, as further described herein, when the transfer bit 162 is first set to indicate a transfer of firmware ownership, the BMC 129 generates a new master secret and stores that master secret in the HSM 172.

[0024] As an example, HSM 172 may be a TA100 Trust Anchor HSM semiconductor package (or "chip") available from Microchip, or HSM 172 may be a semiconductor package available from another manufacturer. Furthermore, according to a further embodiment, BMC 129 may store the new master secret in secure non-volatile memory instead of in the HSM. For example, according to a further embodiment, BMC 129 may store the new master secret in the memory of a TPM or other secure processor. According to a further embodiment, BMC 129 may store the new master secret in the internal secure memory of BMC 129 (such as secure memory 144 of secure enclosure 140, another memory of secure enclosure 140, or another memory of the semiconductor package 153 of the BMC). Generally, according to the example embodiments, the secure non-volatile memory storing the new master secret can be associated with any of a variety of different memory technologies. For example, the non-volatile memory may be NVRAM, flash memory; persistent memory; a set of one-time programmable elements; and so on.

[0025] In the context used herein, a "one-time programmable element" refers to a component that represents a specific bit of information, and the state of that element (i.e., the value of the associated bit) can only be programmed or changed once. For example, a bit represented by a one-time programmable element may have an initial unprogrammed "0" value (i.e., the bit is "unset"). The bit can be programmed once to change its value to "1" (i.e., "set" the bit). According to an example implementation, the programming of the bit is irreversible because the value of the bit cannot be reversed (e.g., unset) once it has been programmed (e.g., set). According to a further example implementation, a "set" transition bit 162 may indicate that ownership of the BMC management firmware has changed, while a "set" transition bit 162 may indicate that ownership has never changed.

[0026] Depending on the specific implementation, the one-time programmable element can take any of a variety of different forms. For example, according to some implementations, the one-time programmable element 165 collectively representing the principal secret 161 can be a collection of semiconductor fuses and / or semiconductor antifuses of the semiconductor package 153 containing the BMC 129. In this way, in order to encode the principal secret 161 into this collection, the manufacturer can selectively activate or blow the collection of fuses and / or antifuses before the BMC 129 is put into production. Similarly, according to an example implementation, the one-time programmable element 160 can be a semiconductor fuse or antifuse of the semiconductor package 153. According to a further example implementation, the one-time programmable element 165 can be formed from a set of non-volatile memory locations with associated one-time programmable lock bits. For example, after data representing the principal secret 161 has been written to this set of non-volatile memory locations before the BMC 129 is put into production, the lock bits can correspond to fuses that can be blown. According to some embodiments, BMC 129 may include circuitry configured to fuse or activate (or set) element 160 to set transition bit 162 by applying a current and / or voltage exceeding the corresponding fuse-breaking threshold.

[0027] According to the example implementation, the security enclosure 140 of the BMC is a subsystem of the BMC 129, and access to and from this subsystem is strictly controlled. According to the example implementation, the security enclosure 140 performs cryptographic functions for the computer platform 100 and is entirely contained within a cryptographic boundary. In this context, a “cryptographic boundary” refers to a continuous boundary or perimeter that includes the logical and physical components of the cryptographic subsystem, such as the BMC components forming the security enclosure 140.

[0028] According to an example implementation, the security enclosing region 140 includes a hardware or silicon root of trust engine 151 (referred to herein as "SRoT engine 151") that provides security features for the BMC 129. More specifically, according to an example implementation, the security enclosing region 140 stores an immutable fingerprint, which the SRoT engine 151 uses to verify portions of the firmware 170 of the computer platform 100 stored in non-volatile memory 168. According to an example implementation, the firmware 170 may include: machine-readable instructions 139 stored in memory 143 of the security enclosing region 140 and executed by the security processor 142 of the security enclosing region 140; machine-executable instructions corresponding to the BMC's management stack firmware image and executed by one or more main processing cores 154 of the BMC 129; machine-readable instructions corresponding to UEFI 111 in the UEFI firmware image; and so on. According to an example implementation, when the BMC 129 is first powered on or reset, the BMC 129 remains on the main processing core 154 and the security processor 142.

[0029] In response to power-on or reset, the SRoT engine 151 verifies an initial portion of firmware 1 and then loads that initial portion into memory 143 of the secure enclosing region 140, making that firmware portion now trusted. The BMC 129 then releases its hold on the secure processor 142 to allow the secure processor 142 to boot and execute the loaded firmware instructions. By executing the firmware instructions, the secure processor 142 can then verify the firmware image 179 corresponding to the BMC's management firmware stack and, after verification, load the firmware image 179 into memory 155 of the BMC 129. The instructions for managing the firmware stack can then be executed by (when released from reset) the main processing core(s), causing the main processing core(s) 154 to load additional portions of firmware 170 and place the loaded portions into memory 164. Access to memory 164 may involve additional training and initialization steps (e.g., training and initialization steps as proposed by the DDR specification). These instructions can be executed from the verified portion of the BMC firmware management stack in memory 155. According to the example implementation, the security enclosure 140 can lock the memory 155 to prevent modification or tampering with the verified portions(s) stored in the memory 155. Therefore, according to the example implementation, the chain of trust can extend from the BMC's SRoT to the firmware management stack executed by the BMC's main processing core 154.

[0030] According to an example implementation, BMC 129 is configured to prevent a given domain or entity of BMC 129 from being powered on or exiting a reset until the security enclosure 140 verifies the domain / entity. Furthermore, according to an example implementation, BMC 129 can prevent components of BMC 129 from accessing resources of BMC 129 and resources of computer platform 100 until the security enclosure 140 approves / verifies those resources. BMC 129 can perform bus filtering and monitoring (e.g., for the SPI bus, System Management Bus (SMB), Internal Integration Components (I... 2 C) Bus, Improved I 2 C(I 3 C) Bus filtering and monitoring of buses, etc., to prevent unwanted access to bus devices. For example, BMC 129 can perform bus filtering and monitoring on bus 167.

[0031] According to an example implementation, the security processor 142 can execute machine-readable instructions 139 (stored in memory 143) to perform various security-related tasks for the BMC 129. For example, according to an example implementation, the security processor 142 can execute instructions 139 to form a firmware update engine 147 that replaces an existing BMC management firmware image with a new BMC management firmware image. Furthermore, according to an example implementation, the security processor 142 can execute instructions 139 to form a firmware transfer engine 149 configured to implement the various security features described herein related to firmware ownership transfer.

[0032] The main processing core 154 can execute machine-readable instructions to perform management functions corresponding to the firmware management stack of the BMC 129. As an example, by executing the firmware management stack through the main processing core 154, the BMC 129 can perform various management roles for the host 101, such as monitoring sensors; monitoring operating system status; monitoring power status; logging computer system events; providing a remote console; providing remote control functions and other virtual presence technologies; and so on.

[0033] Furthermore, the firmware management stack executed by the main processing core 154 enables the BMC 129 to act as a proxy for the host 101, allowing management entities such as a remote management server 190 to remotely manage the host 101. Depending on the specific implementation, the remote management server 190 may be physically located in a different rack, blade server, data center, and / or geographical location than the computer platform 100. As an example of the BMC 129 acting as a proxy for the host 101 to allow remote management of the host 101, the BMC 129 can provide the host 101 with a remote console for various purposes, such as providing KVM functionality, virtual power functionality, virtual media management functionality, etc. The remote management server 190 can communicate with the BMC 129 via network infrastructure 188, even when the host 101 is powered off, or even when software is not installed on the host 101.

[0034] As a further example of BMC 129 acting as a proxy for host 101, remote management server 190 can communicate with BMC 129 via network structure 188 to receive status information about host 101 (e.g., temperature sensor readings, tampered sensor readings, boot status, fault indications, security check failures, etc.); set up virtual media for host 101; power on host 101; power off host 101; initiate recovery actions for host 101 (e.g., initiate operating system recovery); set up boot paths for host 101; and so on. According to the example implementation, BMC 129's security enclosure 140 can provide remote management server 190 with a platform inventory (e.g., a list representing integrity measurements of software component identities and hardware component identities), allowing server 190 to verify the platform inventory.

[0035] Generally, network architecture 188 can be associated with one or more types of communication networks, such as (for example) Fibre Channel networks, Gen-Z architectures, private management networks, local area networks (LANs), wide area networks (WANs), global networks (e.g., the Internet), wireless networks, or any combination thereof.

[0036] like Figure 1 As depicted, according to an example embodiment, components of the BMC 129 (such as the main processing cores 154 and the security enclosure 140) may be disposed within a semiconductor package 153 (or "chip"). The semiconductor package 153 may be any of a variety of package types, such as a surface mount package, through-hole package, ball grid array package, small outline package, chip-scale package, etc. Furthermore, depending on the specific embodiment, components of the security enclosure 140 may be fabricated in one or more dies 157 of the semiconductor package 153, and management plane components of the BMC 129 (such as the main processing cores 154) may be fabricated in one or more other dies of the semiconductor package 153.

[0037] According to an example implementation, host 101 may include one or more CPU cores 102 (e.g., CPU processing cores, semiconductors containing CPU processor cores, etc.), and memory devices connected to CPU 102 to form system memory 104. CPU core 102 can execute machine-readable instructions to form various software and firmware components of computer platform 100, such as UEFI 111, operating system 113, one or more applications 115, etc. CPU core 102 may be coupled to one or more input / output (I / O) bridges 106, which allow communication between CPU core 102 and BMC 129, as well as communication with various I / O devices, such as memory drives 122; one or more network interface controllers (NICs) 124; one or more universal serial bus (USB) devices 126; I / O devices; video controllers; etc. Furthermore, similarly... Figure 1 The depicted computer platform 100 may include one or more Fast Peripheral Component Interconnect (PCIe) devices 110 (e.g., PCIe expansion cards) that can be coupled to the CPU core 102 via corresponding individual PCIe buses 108. According to a further example embodiment, the PCIe devices 110 may be coupled to the I / O bridges 106 instead of the CPU core 102. According to a further embodiment, the I / O bridges 106 and the PCIe interface may be part of the CPU core 102.

[0038] According to an example implementation, one or more memory modules of the computer platform 100 may form a non-volatile memory 168 storing firmware 170. For example... Figure 1 As depicted, according to some embodiments, the non-volatile memory 168 can be coupled to components of the BMC 129 via a bus 167 (e.g., a Serial Peripheral Interconnect (SPI) bus).

[0039] Generally, the storage device forming the system memory 104, firmware memory 168, and other memories and storage media described herein can be formed of a non-transitory memory device, such as a semiconductor memory device, a flash memory device, a memristor, a phase-change memory device, or a combination of one or more of the above-mentioned memory technologies. Furthermore, unless otherwise stated herein, the memory device can be a volatile memory device (e.g., a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, etc.) or a non-volatile memory device (e.g., a flash memory device, a read-only memory (ROM) device, etc.).

[0040] According to some implementations, one or more NICs 124 of the computer platform 100 may be intelligent input / output peripherals, or "intelligent I / O peripherals," which can provide backend I / O services for one or more applications 115 (or application instances) executing on the computer platform 100. According to some implementations, one or more PCIe devices 110 may be intelligent I / O peripherals.

[0041] According to an example implementation, BMC 129 may include a network interface controller (NIC) 158 (e.g., a semiconductor package or "chip") that allows BMC 129 to communicate (via network structure 188) with entities outside computer platform 100, such as remote management server 190, etc. BMC 129 may further include one or more additional communication interfaces 156, such as USB interfaces, PCI interfaces, SPI interfaces, I / O interfaces, etc. 3 C-bus interface, etc. Furthermore, according to the example implementation, BMC 129 may include... Figure 1 Components not specifically described in the text, such as physical memory interface, memory controller interface, video controller, etc.

[0042] Figure 2 The process 200 according to the example implementation is described, firmware ownership engine 149 ( Figure 1 ) and firmware update engine 147 ( Figure 1 This process can be used to transfer firmware ownership from the manufacturer to another owner. In other words, according to the example implementation, the security processor 142 ( Figure 1 It can execute machine-readable instruction 139 ( Figure 1 ), to be used for executing process 200. Combined with Figure 1 refer to Figure 2 According to an example implementation, process 200 includes BMC 129 receiving (box 204) a command to transfer firmware ownership from the manufacturer owner to a new owner. According to box 208, BMC 129 responds to the command by installing a new firmware key associated with the new owner (e.g., installing a firmware key owned by the new owner) in hardware security module 172.

[0043] According to box 212, BMC 129 receives a command to update BMC 129 with a new BMC management firmware image. In response to this command, BMC 129 verifies the new firmware image. For example, as part of the verification, BMC 129 may determine the hash value of the new firmware image, decrypt the signature provided with the new firmware image using the new owner firmware key, and compare the decrypted signature with the hash value to determine if the two values ​​match. In this way, BMC 129 can determine that the new firmware image is owned by the claimed new owner and has not been modified. According to decision box 216, BMC 129 determines whether the new firmware image passes verification. For example, passing verification may mean that the decrypted signature and hash value match.

[0044] If the new firmware image fails verification, BMC 129 deletes (box 220) the new firmware key and terminates process 200, according to the example implementation.

[0045] If the new firmware image passes verification, then according to the example implementation, BMC 129 continues with the actions of installing the new firmware image and protecting customer secrets. More specifically, according to box 224, BMC 129 deletes secret 145 stored in secure memory 144. According to box 228, BMC 129 sets transfer bit 162, that is, changes the transfer bit to a state (e.g., "1") to indicate that ownership has been transferred from the manufacturer owner. BMC 129 further deletes (box 232) any secrets stored in hardware security module 172. BMC 129 may also delete (box 236) the manufacturer firmware key from secure memory 144.

[0046] Next, according to box 240, BMC 129 submits the new firmware image 170 to non-volatile memory 168 and initiates a reboot of BMC 129 according to box 244. As depicted by reference numeral 250, BMC 129 can then execute management firmware corresponding to the new firmware image.

[0047] Figure 3 A process 300 of a BMC 129 according to an example implementation is depicted, which can be used to transfer firmware ownership from a non-manufacturer owner to a manufacturer owner. According to the example implementation, process 300 can be handled by the security processor 142 of the BMC 129. Figure 1 According to some implementations, as part of the execution process 300, the security processor 142 may execute machine-readable instructions to form the firmware ownership transfer engine 149. Figure 1 ), to be used for executing process 300.

[0048] Combination Figure 1 refer to Figure 3First, referring to procedure 300, the customer restores the manufacturer-owned firmware (i.e., installs the BMC management firmware owned by the manufacturer), as shown in reference numeral 304. Following box 308, the BMC 129 is then rebooted.

[0049] After booting, BMC 129 determines (decision box 312) whether transition bit 162 has been set. If not, BMC 129 performs actions to manage security assets associated with BMC 129, such as master secrets and customer secrets. More specifically, according to decision box 316, BMC 129 determines whether the master secret has been stored in hardware security module 172. In this way, via decision box 316, BMC 129 can determine whether this is the first boot after installing a new firmware image, and if so, the new master secret has not yet been generated and has not yet been stored in HSM 172. If not, according to box 320, BMC 129 re-encrypts the installed firmware image using the new manufacturer firmware ownership key. For example, according to some implementations, the currently installed manufacturer-owned firmware image can be encrypted with a first manufacturer-owned firmware key. According to box 320, BMC 129 may, for example: first decrypt the currently installed firmware image; install a new manufacturer-owned firmware key; encrypt the decrypted firmware image with the new manufacturer-owned firmware owner key; and then install (e.g., commit) the newly encrypted firmware image to non-volatile memory 168. According to box 324, BMC 129 then generates a new master secret and stores the generated master secret in hardware security module 172.

[0050] If, according to decision box 316, BMC 129 determines that the master secret is already stored in hardware security module 172, then according to box 328, BMC 129 uses the master secret stored in hardware security module 172 to generate a cryptographic key. If, according to decision box 312, BMC 129 determines that the transfer bit is not set, then according to box 332, BMC 129 generates a cryptographic key from master secret 161 stored in one-time programmable element 165.

[0051] According to box 336, BMC 129 can then perform actions related to its startup. For example, according to some implementations, BMC 129 can verify firmware (as described herein), perform security checks, perform fault checks, etc.; and if the criteria associated with these actions are met, BMC 129 releases main processing core 154 from reset, allowing core 154 to begin executing the firmware management stack. According to decision box 340, BMC 129 determines whether transfer bit 162 has been set, and if so, BMC 129 can transmit the status of the firmware ownership transfer history to remote management server 190. This notification can take any of a variety of different forms, such as updating the graphical user interface (GUI) of remote management server 190, sending a message to remote management server 190, etc. According to box 344, main processing core 154 of BMC 129 can then execute management firmware.

[0052] Other implementations within the scope of the appended claims are contemplated. For example, according to a further implementation, a management controller other than the BMC can store the history of firmware ownership and manage the transfer of firmware ownership, as described herein. For example, according to a further implementation, the management controller can be a platform controller or a chassis controller. Although the foregoing description discusses the first or initial owner of the management firmware as the manufacturer of the computer platform, according to a further implementation, the initial owner of the management firmware can be an owner other than the computer platform manufacturer. Thus, in general, according to the example implementations, regardless of the specific entity that is the initial owner, the management controller can maintain the ownership history of the management firmware and manage the use of the main secret (as well as other secrets described herein).

[0053] refer to Figure 4 According to an example implementation, process 400 includes a management controller of a computer platform determining (block 404) whether the ownership history of the management controller's management firmware indicates multiple owners. The management controller includes a set of one-time programmable elements representing a first secret. Process 400 includes managing (block 408) the use of the first secret based on the ownership history. This management includes, in response to the management controller determining that the ownership history indicates multiple owners, generating a second secret in place of the first secret. The management also includes, in response to determining that the ownership history indicates multiple owners, the management controller storing the second secret in non-volatile memory and generating a cryptographic key based on the second secret.

[0054] refer to Figure 5According to an example implementation, computer platform 500 includes a host 501 and a management controller 503 that manages the host 501. Management controller 503 includes a semiconductor package 502. Semiconductor package 502 includes a first one-time programmable element 508; a second one-time programmable element 517; a main hardware processor 524; and a hardware security processor 516. The first one-time programmable element 508 represents a first secret 512, and the second one-time programmable element 517 represents a firmware transfer history 519, i.e., whether the ownership of the management firmware executed by management controller 503 has changed from the initial owner to another owner in the usage history of management controller 503. Main hardware processor 524 executes the management firmware. The initial owner currently owns the management firmware. In response to the startup of management controller, security processor 516 determines, based on second data, whether the ownership of the firmware has changed from the initial owner in the usage history, and manages the use of the first secret 512 based on whether the ownership of the management firmware has changed.

[0055] refer to Figure 6 According to an example implementation, a non-transitory machine-readable storage medium 600 stores machine-executable instructions 604. When executed by the machine, instructions 604 cause the machine to instruct its baseboard management controller to determine whether a firmware ownership history stored in the baseboard management controller indicates a change of ownership from an initial owner to another owner during the use history of the baseboard management controller. This firmware corresponds to the management stack of the baseboard management controller. When executed by the machine, instructions 604 further cause the machine to instruct the baseboard management controller to manage the use of a first secret based on the firmware ownership history. The first secret is represented by a one-time programmable element of the machine. Managing the use of the first secret includes generating a cryptographic key based on the first secret in response to determining that ownership of the firmware was held by a first owner in the history and that ownership has not been transferred. Managing the use of the first secret further includes generating a cryptographic key based on a second secret stored in secure memory in response to determining that ownership has been transferred during the history.

[0056] According to an example implementation, the management controller can determine whether the ownership history indicates multiple owners based on the state of a one-time programmable element. A particular advantage is that the BMC can manage secrets based on a persistent firmware ownership history.

[0057] According to an example implementation, the baseboard management controller (BMC) determines whether a second secret is stored in non-volatile memory. The BMC can generate a second secret in response to determining that it is not stored in non-volatile memory. A particular advantage is that the BMC can manage secrets based on a persistent firmware ownership history.

[0058] According to an example implementation, the firmware image is encrypted with a first cryptographic key. In response to the baseboard management controller determining that a second secret is not stored in non-volatile memory, the baseboard management controller re-encrypts the firmware image with a second cryptographic key other than the first cryptographic key. A particular advantage is that the baseboard management controller can manage the secret based on a persistent firmware ownership history.

[0059] According to an example implementation, in response to determining that the ownership history indicates multiple owners, the BMC generates a notification of firmware ownership transfer and transmits the notification to a remote management server. A particular advantage is that the BMC can manage secrets based on a persistent firmware ownership history.

[0060] According to an example implementation, the hardware security processor receives a command to transfer ownership from an initial owner to a second owner. In response to this command, the security processor installs the firmware image associated with the initial owner and programs a second programmable element to indicate that ownership has been transferred. A particular advantage is that the BMC can manage secrets based on a persistent firmware ownership history.

[0061] According to an example implementation, the computer platform further includes a secure memory. A hardware security processor receives a command to transfer ownership from an initial owner to a second owner. In response to this command, the hardware security processor verifies the firmware image based on a cryptographic key associated with the second owner. In response to the verification of the firmware image, the hardware security processor removes the secret stored in the secure memory. A particular advantage is that the BMC can manage the secret based on a persistent firmware ownership history.

[0062] According to an example implementation, the computer platform further includes non-volatile memory. The hardware security processor further stores the firmware image in the non-volatile memory in response to firmware verification and the removal of secrets stored in the secure memory. A particular advantage is that the BMC can manage secrets based on a persistent firmware ownership history.

[0063] According to an example implementation, the hardware security processor further initiates a reboot of the management controller in response to the firmware image being stored in the non-volatile memory. A particular advantage is that the BMC can manage secrets based on a persistent firmware ownership history.

[0064] According to an example implementation, the hardware security processor further receives a command to install a firmware image associated with a second owner, other than the initial owner. The hardware security processor verifies the firmware image based on a password key associated with the second owner, and deletes the password key in response to a failure to verify the firmware image. A particular advantage is that the BMC can manage secrets based on a persistent firmware ownership history.

[0065] According to an example implementation, the hardware security processor, in response to booting from the management controller, determines whether ownership has changed based on the state of the first one-time programmable element, and in response to determining that ownership has not changed, generates a cryptographic key based on a first secret. A particular advantage is that the BMC can manage secrets based on a persistent firmware ownership history.

[0066] According to an example implementation, the computer platform further includes a secure memory. A hardware security processor determines whether ownership has changed based on the state of the first one-time programmable element. In response to determining that ownership has changed, the hardware security processor generates a second secret to replace the first secret, stores the second secret in the secure memory, initiates a restart of the management controller, and generates a cryptographic key based on the second secret in response to the restart. A particular advantage is that the BMC can manage secrets based on a persistent firmware ownership history.

[0067] According to an example implementation, the computer platform further includes a secure memory. A hardware security processor determines whether ownership has changed based on the state of a first one-time programmable element. In response to determining that ownership has changed, the hardware security processor deletes a secret stored in the secure memory, generates a second secret to replace the first secret, stores the second secret in the secure memory, initiates a restart of the management controller, and generates a cryptographic key based on the second secret in response to the restart. A particular advantage is that the BMC can manage secrets based on a persistent firmware ownership history.

[0068] According to an example implementation, the management controller includes a baseboard management controller. Furthermore, the management controller manages the host, including functions provided by the baseboard management controller that allow a remote management server to remotely control the host. A particular advantage is that the BMC can manage secrets based on a persistent firmware ownership history.

[0069] Although this disclosure has been described with respect to a limited number of embodiments, those skilled in the art who benefit from this disclosure will recognize many modifications and variations thereof. The appended claims are intended to cover all such modifications and variations.

Claims

1. A computer platform, comprising: Host; as well as A management controller for managing the host, wherein the management controller includes a semiconductor package, and the semiconductor package includes: A first one-time programmable memory element is used to represent a first secret; A second one-time programmable element is used to provide an indication of whether the ownership of the management firmware executed by the management controller has changed from the initial owner to another owner in the usage history of the management controller; A main hardware processor for executing the management firmware, wherein the initial owner currently owns the management firmware; and A hardware security processor, used in response to the startup of the management controller: Based on the representation provided by the second one-time programmable element, it is determined whether the firmware ownership has been changed from the initial owner in the usage history of the management controller; In response to determining that the firmware ownership has not changed from the initial owner in the usage history of the management controller, a key generation algorithm is applied to the first secret to generate a given cryptographic key; or In response to determining that the ownership of the firmware has changed from the initial owner in the usage history of the management controller, a second secret is generated in place of the first secret for generating the given password key.

2. The computer platform as described in claim 1, wherein, The hardware security processor is further used for: Receive an order to transfer ownership from the initial owner to a second owner; and In response to the command, a firmware image associated with the second owner is installed, and the second one-time programmable element is programmed to indicate that ownership has been transferred to the second owner.

3. The computer platform as described in claim 1, wherein, The hardware security processor is further used for: Receive a command to install a firmware image associated with a second owner other than the initial owner; The firmware image is verified based on a second cryptographic key associated with the second owner; as well as In response to the failure of verification of the firmware image, the second password key is deleted.

4. The computer platform as described in claim 1, wherein, The computer platform further includes secure storage, and the hardware security processor is further configured to: In response to determining that the firmware ownership has changed from the initial owner in the usage history of the management controller, the second secret is stored in the secure storage, a reboot of the management controller is initiated, and in response to the reboot, the given password key is generated based on the second secret.

5. The computer platform as described in claim 1, wherein, The computer platform further includes secure storage, and the hardware security processor is further configured to: In response to the determination that the ownership of the firmware has changed from the initial owner in the usage history of the management controller: Delete the secret stored in the secure storage, wherein the secret includes the first secret; Generate a second secret to replace the first secret; The second secret is stored in the secure memory; Initiate a restart of the management controller; and In response to the restart, the given cryptographic key is generated based on the second secret.

6. The computer platform as described in claim 1, wherein, The management controller includes a baseboard management controller, and the management controller manages the host by providing functionality that allows a remote management server to remotely control the host.

7. The computer platform as described in claim 1, wherein, The given cryptographic key includes the initial device identifier IDevID key.

8. The computer platform as described in claim 1, wherein, The management controller oversees whether to apply the key generation algorithm to the first secret based on the determination that the ownership of the firmware has been changed from the initial owner in the management controller's usage history.

9. The computer platform as described in claim 1, wherein, The first secret includes a master secret, from which other secrets are derived if the firmware ownership has not changed from the initial owner in the usage history of the management controller.

10. The computer platform as claimed in claim 1, wherein, The computer platform further includes secure storage, and the hardware security processor is further configured to: Receive an order to transfer ownership from the initial owner to a second owner; In response to the command, verify the firmware image based on the second encryption key associated with the second owner; as well as In response to the verification of the firmware image, the secret stored in the secure storage is removed.

11. The computer platform as described in claim 10, wherein, The computer platform further includes non-volatile memory, and the hardware security processor is further configured to: In response to the verification of the firmware image and the removal of the secret stored in the secure memory, the firmware image is stored in the non-volatile memory.

12. The computer platform as described in claim 11, wherein, The hardware security processor is further configured to initiate a restart of the management controller in response to the firmware image being stored in the non-volatile memory.

Images