Apparatus, method, controller for managing storage of secrets in memory of a baseboard management controller

Abstract

An apparatus includes a host computer and a baseboard management controller. The baseboard management controller includes a semiconductor package; and the semiconductor package includes memory, a security hardware processor; and a main hardware processor. The main hardware processor enables the baseboard management controller to act as an agent, which manages the host independently of the host in response to communications with a remote management entity. The security hardware processor manages the storage of the host computer's secrets in the memory.

Description

Technical Field

[0001] This disclosure relates to the storage of secrets in the memory of a management controller for a management board. Background Technology

[0002] A computer platform (e.g., a server) may include a dedicated service processor, referred to as a "Baseboard Management Controller" or "BMC," which 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. Summary of the Invention

[0003] An apparatus for managing the storage of secrets includes: a host; and a substrate management controller, the substrate management controller including a semiconductor package, wherein the semiconductor package includes: a secure enclosing region having an associated cryptographic boundary; a memory within the cryptographic boundary; a main hardware processor outside the cryptographic boundary, wherein the main hardware processor is configured to cause the substrate management controller to act as an agent, the agent being independent of the host and responding to communications with a remote management entity to manage the host; and a secure hardware processor within the cryptographic boundary, wherein the secure hardware processor is separate from the main hardware processor, and wherein the secure hardware processor is configured to manage the storage of the host's secrets in the memory.

[0004] A method for managing the storage of secrets includes: communicating with a management entity via a baseboard management controller of a computer platform to manage a host of the computer platform, wherein the baseboard management controller includes a management plane and the management plane includes an agent; storing secure secrets of the computer platform in a secure memory of the baseboard management controller; and managing the storage of secrets by a secure hardware processor of the baseboard management controller, wherein the baseboard management controller further includes a security plane and the secure hardware processor is associated with the security plane; receiving a request from the host via the agent for managing the storage of secrets; forwarding the request to the secure hardware processor via the agent; providing a response to the request to the agent via the secure hardware processor; and forwarding the response to the requester via the agent.

[0005] A management controller includes: a semiconductor package including a main hardware processor and a secure enclosure separate from the main hardware processor, wherein the secure enclosure includes secure memory and a hardware security processor; a communication interface; wherein the main hardware processor is configured to execute instructions to communicate with a remote management server via the communication interface and to manage a host of a computer platform in response to the communication; wherein the hardware security processor is configured to provide an application programming interface (API) to manage a first secret stored by the host in the secure memory; wherein the main hardware processor is configured to act as a proxy for the hardware security processor in response to a first request from the host to manage the first secret; and wherein the main hardware processor is configured to submit a second request to the hardware security processor to manage a second secret associated with the management controller. Attached Figure Description

[0006] Figure 1 This is a schematic diagram of a computer platform with a baseboard management controller (BMC) according to an example embodiment, the baseboard management controller including a secure memory for storing secrets.

[0007] Figure 2 This is a schematic diagram of a secure enclave of a BMC, which contains a secure memory for storing secrets according to an example implementation.

[0008] Figure 3 and Figure 4 The packaging of components of a BMC according to an example embodiment is shown.

[0009] Figure 5 This is a flowchart depicting a process according to an example implementation, which is used by the BMC's secure enclosed zone to process application programming interface (API) requests for key encryption keys stored in the secure memory of the secure enclosed zone.

[0010] Figure 6 This is a flowchart depicting a process according to an example implementation, which is used by the BMC's security enclosed zone to handle API requests for updating or deleting certificates stored in the security enclosed zone's secure memory.

[0011] Figure 7 This is a schematic diagram of an apparatus according to an example embodiment, which includes a BMC that stores the secrets of the host that manages the apparatus.

[0012] Figure 8 This is a flowchart depicting the process of managing secrets stored in the secure memory of the BMC according to an example implementation.

[0013] Figure 9This is an illustration of machine-readable instructions stored on a non-transitory machine-readable storage medium according to an example embodiment, which enables a machine to manage secret storage in the secure memory of a management controller. Detailed Implementation

[0014] The BMC 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 functions of the computer platform. For example, remote management functions may include: keyboard and video mouse (KVM) functionality; virtual power functions (e.g., remote activation functions for remotely setting power states such as power-saving mode, power-on, reset, or power-off); virtual media management functions; and so on.

[0015] In addition to providing management functions for a computer platform, the BMC can provide security-related features to protect the computer platform from security threats. For example, the BMC may include a hardware (or “silicon”) root of trust (RoT) engine, or “SRoT engine,” for the computer platform. The SRoT engine can verify the firmware of the computing platform in various ways. For example, the firmware of the computing platform can be verified as a chain of verified firmware portions. For example, a hardware SRoT engine can verify a portion of the firmware in the hardware and load it into a secure enclosed region of the BMC. The secure enclosed region can then execute the verified portion of the firmware to further verify a second portion of the firmware, and so on, thereby establishing a chain of trust. Firmware verification can be performed by a single entity (e.g., solely as a function of the secure enclosed region) or by different entities, assuming each entity only executes the previously verified portion of the firmware. For example, the second portion of the firmware in the previous example could be additional firmware required by the secure enclosed region. This second portion is used to verify a third portion, which may correspond to machine-readable instructions of the BMC. This third portion can verify a fourth portion, which may correspond to machine-readable instructions of host system firmware such as Unified Extensible Firmware Interface (UEFI) firmware.

[0016] The BMC is a relatively complex subsystem capable of executing millions of instructions from the firmware management stack, even before the rest of the computer platform is powered on. While the BMC can verify the integrity of the firmware management stack before loading and executing it, the relatively large number of instructions in the stack can expose the computer platform to potential or undiscovered security vulnerabilities. Due to the lack of transparency and potential undiscovered security vulnerabilities inherent in proprietary management stacks, customers of computer platforms may want to use an open-source firmware management stack to manage their platforms. Furthermore, a given customer may want to use the same open-source firmware management stack to manage all of their computer platforms, regardless of the specific vendor(s) 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.

[0017] When allowing customers to provide BMC's firmware management stack, BMC may face challenges in providing security features for the computer platform. For example, a potential security feature for BMC could be storage of secrets belonging to the computer platform. As an example, "secrets" could be cryptographic keys, certificates, passwords, tokens, seeds, the platform's cryptographic identity, etc. Without appropriate measures, these secrets may be exposed to the firmware management stack and therefore vulnerable to security vulnerabilities within the firmware management stack.

[0018] According to the example implementation described herein, a management controller (such as a BMC) of a computer platform provides security features to the computer platform; executes a firmware management stack; and isolates the security features from the firmware management stack. According to a particular implementation, the firmware management stack may be a non-proprietary open-source firmware stack; a firmware stack otherwise provided by a computer platform customer; a proprietary firmware stack; and so on. According to the example implementation, as part of its security features, the BMC provides memory (referred to herein as "secure memory") to securely store the secrets of the computer platform. As an example, secure memory may be non-volatile random access memory (NVRAM) in which secrets can be stored, read, erased, and modified. According to the example implementation, the BMC strictly regulates access to secure secrets.

[0019] According to some implementations, the BMC provides a management plane and a security plane isolated from the management plane. The 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 using a security service application programming interface (API).

[0020] More specifically, according to the example implementation, the security plane of the BMC includes a secure enclosing zone, and the secure enclosing zone includes a secure memory that can store one or more secrets of the computer platform. These secrets may include host secrets, and these secrets may include BMC secrets. In this case, the "secure enclosing zone" refers to a subsystem of the BMC, and access to and from this subsystem is strictly controlled. According to the example implementation, the secure enclosing zone performs cryptographic functions for the computer platform and is completely set within a cryptographic boundary. In this case, the "cryptographic boundary" refers to a continuous boundary or perimeter that contains the logical and physical components of the cryptographic subsystem, such as the BMC components forming the secure enclosing zone. The "host" refers to a component of the computer platform (e.g., one or more central processing unit (CPU) cores and systems) that performs at least one of the following: providing an operating system (e.g., a Linux operating system) to create an operating system environment for the computer platform or providing a pre-boot environment (e.g., providing a Basic Input / Output System (BIOS) and / or a Unified Extensible Firmware Interface (UEFI)) to prepare the computer platform for the operating system environment.

[0021] Because the secure enclosed region is protected by a cryptographic boundary, access to secrets stored in secure storage can be strictly controlled. According to an example implementation, the secure enclosed region may provide one or more APIs (referred to herein as the "Secret Management API") for managing secrets stored in secure storage. In this way, as an example, according to some implementations, the Secret Management API may provide access functions for managing secrets, such as APIs for performing the following: reading secrets; writing secrets; deleting or clearing secrets; binding or sealing secrets to a specific Platform Configuration Register (PCR) state; unbinding or unsealing secrets based on a specific PCR state; creating secrets; storing secrets; and so on.

[0022] The BMC's management plane (specifically, one or more main processing cores of the management plane) can act as a proxy for the security enclosed zone for secret management-related exchanges or sessions between the host and the security enclosed zone. As used herein, a "proxy" for a given component (e.g., a security enclosed zone) refers to a relay or intermediate component that acts on behalf of the given component. As a proxy for the security enclosed zone, the BMC's management plane can receive calls or requests to the secret management API from a requester (e.g., UEFI or the operating system) and forward the requests to the security enclosed zone for processing. Furthermore, as a proxy, the BMC's management plane can further forward responses to these requests from the security enclosed zone back to the requester.

[0023] According to example implementations, in addition to secure memory, the secure enclosed region may include several other components. For example, according to some implementations, the secure enclosed region may include a secure processor (e.g., one or more hardware processing cores for executing firmware instructions to handle secret management API requests, verify firmware, and perform other security-related tasks); volatile memory (e.g., memory for storing firmware loaded into volatile memory and executed by the secure processor); a secure bridge for controlling access to the secure enclosed region and controlling communication outgoing from the secure enclosed region; cryptographic processing peripherals (e.g., cryptographic accelerators, random number generators, tamper detection circuitry, etc.); and a Silicon Root of Trust (SRoT) engine.

[0024] According to an example implementation, the BMC's (multiple) main processing cores (which execute firmware management stacks) and security enclosure can be housed within a semiconductor package (or "chip"). The semiconductor package can be any of a variety of package types, such as surface mount packages, through-hole packages, ball grid array packages, small outline packages, chip-scale packages, etc. Furthermore, depending on the specific implementation, the components of the security enclosure can be fabricated within one or more dies of the semiconductor package.

[0025] As a more specific example, according to some implementations, all components of the security enclosed region can be fabricated in two semiconductor dies of a semiconductor package. The security memory can be fabricated in the first semiconductor die, while the remaining components of the security enclosed region can be fabricated in another second semiconductor die. Furthermore, according to an example implementation, components of the BMC's management plane (e.g., (multiple) main processing cores, memory, etc.) can also be fabricated in the second semiconductor die.

[0026] According to a further exemplary embodiment, all components of the security enclosure can be manufactured in a single semiconductor die. Furthermore, components of the BMC's management plane can also be manufactured in this single semiconductor die.

[0027] Regardless of the specific implementation, according to the example implementation, the terminals of the secure memory (e.g., address, data, and control terminals) can be completely embedded within the semiconductor package, so that none of the terminals are exposed outside the semiconductor package. Therefore, the secure memory can be highly resistant to physical tampering (e.g., tampering involving the use of physical probes and logic analyzers), as well as other types of tampering (e.g., tampering exploiting vulnerabilities in the firmware management stack).

[0028] refer to Figure 1As a more specific example, according to some implementations, computer platform 100 includes a management controller (or "service processor") such as BMC 129. BMC 129 includes secure memory 144 located within a secure enclosure 140 of BMC 129. Secure memory 144 may store one or more secrets 145 of computer platform 100.

[0029] The host 101 of the computer platform 100 can manage secret 145 using one or more secret management APIs 147 provided by the security enclosure 140. For example, secret 145 may include one or more key encryption keys, and secret management APIs 147 may include one or more APIs 147 for obtaining and storing key encryption keys.

[0030] Generally, the self-encrypting storage device 122 of computer platform 100 (e.g., a Non-Volatile Memory Host Controller Interface Specification (NVMe) storage device) can use a key encrypting key (or "KEK"). More specifically, storage device 122 can internally store and use a media access key to encrypt and decrypt data stored on storage device 122, and can use a wrapper key or KEK to encrypt the media access key. The KEK can be considered a password provided by host 101 to self-encrypting storage device 122 to unlock access to device 122, because device 122 cannot decrypt the media access key without the KEK (and therefore cannot use the media access key to encrypt and decrypt data). Self-encrypting storage device 122 uses the KEK to decrypt the media encryption key, and self-encrypting storage device 122 does not store the KEK.

[0031] Continuing this example, the UEFI 111 of host 101 (e.g., CPU core 102 executing UEFI instructions) can detect the presence of the self-encrypting storage device 122 during the boot time of computer platform 100 and perform credential management on device 122. This credential management may include UEFI 111 performing actions such as determining whether a KEK has been set for the self-encrypting storage device 122. If a KEK has been set, UEFI 111 calls the secret management API 147 to retrieve the KEK from secure storage 144, allowing UEFI 111 to provide the retrieved KEK to driver 122.

[0032] As further described herein, according to a further implementation, secret 145 can be a secret other than a KEK. Generally, as used herein, "secret" refers to data representing a securely protected entity or artifacts such as cryptographic keys, credentials, certificates, measurement hashes, cryptographic platform identities, seeds, ciphers, etc. "Managing" secret 145 generally refers to controlling or regulating aspects related to the storage and access of secret 145, such as reading or retrieving secret 145 from secure storage 144; writing secret 145 to secure storage 144; generating secret 145 to be stored in secure storage 144 (e.g., generating a cryptographic key); deleting secret 145 from secure storage 144; sealing secret 145 to one or more measurement hashes or one or more measurement digest values ​​(e.g., PCR values); unsealing secret 145; and so on.

[0033] According to the example implementation, a blade server is an example of computer platform 100. However, according to a further implementation, 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.

[0034] 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.

[0035] As used herein, a “BMC” or “Baseboard Management Controller” 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 Baseboard Management Controller can also communicate with applications running at the operating system level via: Input / Output Controller (IOCTL) interface drivers, Representational State Transfer (REST) ​​application programming interfaces (APIs), or some system software agent that facilitates communication between the Baseboard Management Controller and the application. The Baseboard Management Controller has hardware-level access to hardware devices located in a server chassis, including system memory. The Baseboard Management Controller can directly modify hardware devices. The Baseboard Management Controller can operate independently of the operating system of the system in which it is located. The Baseboard Management Controller can reside on the motherboard or main board of a server or other device to be monitored. The fact that the Baseboard Management Controller is mounted on the motherboard of the managed server / hardware or otherwise connected or attached to the managed server / hardware does not prevent the Baseboard Management Controller from being considered “decoupled” from the server / hardware. As used herein, the Baseboard Management Controller has the ability to manage a subsystem of a computing device and is decoupled from the processing resources of the operating system running the computing device. The baseboard management controller is separate from the processor (such as the central processing unit) that executes the advanced operating system or management programs on the system.

[0036] 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 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; and so on. 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.

[0037] According to an example implementation, one of the plurality of 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 may be coupled to components of the BMC 129 via a bus 167 (e.g., a Serial Peripheral Interconnect (SPI) bus). According to an example embodiment, firmware 170 includes: instructions executed by a hardware security processor 142 (as part of the BMC's security plane) within the security enclosure 140 of the BMC 129; instructions executed by the BMC 129's (multiple) general-purpose processing cores 154 (i.e., a firmware stack corresponding to the BMC 129's management plane); and instructions executed by the (multiple) CPUs 102 to boot the computer system 100 and provide runtime services.

[0038] 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 storage 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.).

[0039] According to some implementations, one or more NICs 124 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 computer platform 100. According to some implementations, one or more PCIe devices 110 may be intelligent I / O peripherals.

[0040] BMC 129 may include a management plane and a security plane isolated from the management plane. More specifically, according to an example implementation, BMC 129 includes one or more main processing cores 154 that execute machine-executable instructions to perform management functions of computer platform 100. These instructions may correspond to the firmware management stack of BMC 129. As an example, by executing the firmware management stack through the main processing core 154, BMC 129 can perform various management roles for 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.

[0041] 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 161, even when the host 101 is powered off, or even when the software is not yet installed on the host 101. 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 161 to receive status information about host 101 (e.g., temperature sensor readings, tampered sensor readings, startup status, fault indications, security check failures, etc.); configure 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); configure boot path 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.

[0042] Furthermore, according to some implementations, the remote management server 190 can communicate with the BMC 129 to control whether the computer platform 100 can "join a cluster" or become active on a network of other platforms (e.g., a server network). For example, in response to the startup of the computer platform 100, as part of a cluster joining request, UEFI 11 or OS 113 can request (e.g., a security services API request) the security enclosed zone 140 to provide a key to the remote management server 190, thereby allowing the computer platform 100 to join the cluster. As an example, the key could be a signed list of BMC 129 and other hashes, a hardware identity certificate (e.g., an IDevID certificate), and a random number (to prevent reproducibility). In response to a request API call corresponding to the request for the key, the security enclosed zone 140 can extract the necessary hashes, extract the hardware identity certificate, generate the key, and provide the key to the remote management server 190.

[0043] Generally speaking, network architecture 161 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.

[0044] According to an example implementation, CPU core 102 executes machine-executable instructions (i.e., "software") to form one or more components that can invoke a secret management API 147 to manage secrets 145 stored in secure memory 144. These components may include, for example, UEFI 111, a basic input / output system (BIOS), an operating system 113, and applications 115. In this context, an "API" is a software interface associated with a set of rules governing how an entity can request or invoke one or more functions provided by the software interface. To manage secrets 144, a requester may submit an API call or request to the secret management API 147.

[0045] API calls may include: data representing a command (e.g., a write or read command) for managing secret 144; one or more parameters of the command; an identifier for secret 144; credentials of the requester issuing the API call; and so on. According to an example implementation, secret management API 147 can provide secure storage services for managing the storage of secure secret 145 in secure memory 144.

[0046] As an example of the storage services provided by the Secret Management API 147, the Secret Management API 147 can provide services for storing measurement hashes, loading reference measurement hashes, constructing at least a portion of a root of trust measurement chain, storing cryptographic keys, obtaining cryptographic keys, generating cryptographic keys, verifying firmware images, obtaining cryptographic platform identity, creating certificates, storing certificates, adding certificates, deleting certificates, sealing cryptographic keys, and unsealing cryptographic keys, etc. As an example, according to the example implementation, the API request can be a Redfish API request, an Intelligent Platform Management Interface (IPMI) API request, or other API requests.

[0047] API requests and corresponding API responses are associated with a session or exchange between a requester (e.g., an entity of host 101, such as operating system 113 or UEFI 111) and a “responder” or security enclosed zone 140. According to an example implementation, the processing core 154 of BMC 129 (as part of the BMC's management plane) can act as a proxy for the security enclosed zone 140 (and the security processor 142) to forward API requests from the requester to the security enclosed zone 140 and corresponding responses from the security enclosed zone 140 to the requester. For example, the requester can write data representing a request corresponding to a specific secret management API 147 to storage space associated with the BMC's management plane. The processing cores 154 can then communicate with the security enclosed zone 140 to forward the request to the security enclosed zone 140 for processing. Furthermore, the processing cores 154 can communicate with the security enclosed zone 140 to receive a response to the request and then forward that response to the requester.

[0048] To assure the requester that the exchange has not been tampered with, at least one of the request or response can be "wrapped." In this case, "wrapping" the request or response means applying cryptographic security protection to the request or response.

[0049] As a more specific example of the packaging, the requester can use a public key to apply asymmetric encryption to encrypt content corresponding to one or more predefined fields or parameters of the API call (e.g., requester identifier, command, etc.), thereby forming corresponding ciphertext. The public key can be part of a (public key, private key) pair used with asymmetric cryptography, and the secure enclosing zone 140 can possess the private key. The requester includes the ciphertext in the request, and the secure enclosing zone 140 uses the private key to decrypt the ciphertext. In this way, an entity other than the secure enclosing zone 140 (which possesses the private key) cannot decrypt the encrypted content of the request. According to a further implementation, the requester can generate a session key and use symmetric cryptography (instead of the asymmetric cryptography described above) to encrypt(multiple) predefined fields or(multiple) parameters of the API call to form corresponding ciphertext. For these implementations, the requester can use asymmetric cryptography to encrypt the session key with the public key of the (public key, private key) pair and include the ciphertext encrypted with the session key and the encrypted session key in the request. In response to receiving a request, the secure enclosing zone 140 can use the private key of the (public key, private key) pair to decrypt the encrypted session key, and the secure enclosing zone 140 can use the session key to decrypt the ciphertext encrypted by the session key.

[0050] Continuing this example, after decrypting the request, the secure enclosed zone 140 can continue processing the request and generate a corresponding response. According to the example implementation, the secure enclosed zone 140 can sign the content (corresponding to one or more predefined fields or parameters of the API response) using the private key of the (public key, private key) pair to generate a signature, which the secure enclosed zone 140 includes in the response. Thus, the requester can authenticate the response by verifying its origin from the secure enclosed zone 140 based on its calculation of the signature using the public key and a comparison of the calculated signature with the signature included in the response. According to a further implementation, the secure enclosed zone 140 can encrypt the content of the response using a session key.

[0051] According to an example implementation, one or more secrets 145 may be secrets of BMC 129, and requests to manage secrets 145 may originate from the BMC's management plane. For example, according to some implementations, in response to the execution management stack, the main processing core 154 may be the requester and provide a request to access secrets 145. Processor core 154 may transmit data representing the request to the secure enclosing region 140 and receive data representing a response to the request from the secure enclosing region 140. Therefore, according to some implementations, secure memory 144 may store secrets 145 of host 101 and secrets 145 of BMC 129.

[0052] According to an example implementation, the security enclosure 140 of the BMC 129 is isolated from the management plane (and other non-security components of the BMC 129 outside the security enclosure 140). According to an example implementation, the security enclosure 140 includes hardware or silicon RoT (referred to as "SRoT") that provides security features for the BMC 129.

[0053] More specifically, according to the example implementation, the secure enclosing region 140 stores an immutable fingerprint, which the SRoT engine 143 uses to verify portions of firmware 170. When the BMC 129 is powered on or reset, it remains on the main processing core 154 and the security processor 142. In response to power-on or reset, the SRoT engine 143 verifies an initial portion of firmware 170 and then loads that initial portion of firmware into the memory 151 of the secure enclosing region 140, making that portion of firmware now trustworthy. The BMC 129 then releases its hold on the security processor 142 to allow the security processor 142 to boot and execute the loaded firmware instructions. By executing the firmware instructions, the security processor 142 can then verify another portion of firmware 170 corresponding to a portion of the BMC-managed firmware stack and, after verification, load that portion of the firmware stack into the memory 155 of the BMC 129. This portion of the firmware stack can then be executed by (when released from reset) the main processing core(s) 154, 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 DDR4 specification). These instructions can be executed from the verified portion of the BMC firmware management stack in memory 155. According to an example implementation, a security enclosure 140 can lock memory 155 to prevent modification or tampering with the verified portions stored in memory 155.

[0054] Therefore, according to the example implementation, the trust chain can be extended from the BMC's SRoT to the firmware management stack executed by the BMC's main processing core 154.

[0055] 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.

[0056] 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 161) 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.

[0057] According to an example embodiment, BMC 129 includes a semiconductor package 153 (or "chip") that includes at least some components of BMC 129, such as main processing core 154 and secure enclosing region 140. Semiconductor package 153 may include one or more semiconductor dies. According to some embodiments, secure memory 144 may be fabricated in one semiconductor die, and the remaining components of BMC 129 may be fabricated in one or more additional semiconductor dies. According to an example embodiment, terminals of secure memory 144 (e.g., leads, pins, balls, etc., such as terminals for communicating data, control, and address signals with secure memory 144) are not exposed outside of semiconductor package 153. In other words, according to an example embodiment, terminals of secure memory 144 are physically isolated from areas outside semiconductor package 153, thereby preventing physical probe tampering from being used to compromise the integrity or security of data stored in secure memory 144.

[0058] refer to Figure 2According to an example implementation, the secure enclosed region 140 may be a complete system-on-a-chip (SOC) and may be contained within a tightly controlled cryptographic boundary 204. Generally, components of the secure enclosed region 140 may communicate via a bus infrastructure 205. According to an example implementation, the bus infrastructure 205 may include features such as a data bus, control bus, address bus, system bus, one or more buses, one or more bridges, etc. The secure processor 142 may include: one or more processing cores 208 (e.g., CPU cores); and instruction cache 209 and data cache 211. Volatile memory 151 may be, for example, static random access memory (SRAM) and may store data representing Trusted Computation Base (TCB) measurements, such as one or more PCR libraries. Secure memory 144 may be, for example, non-volatile RAM (NVRAM). The secure enclosed region 140 may include registers 240. Depending on the specific implementation, registers 240 may be software registers, hardware registers, or a combination of hardware and software registers. For example, according to some implementations, registers 240 include cryptographically secure registers such as software PCRs. Furthermore, according to the example implementation, register 240 may include operation registers, such as hardware registers that provide control, status, and configuration functions for the security enclosed zone 140.

[0059] According to an example implementation, the security perimeter 140 includes a security bridge 214 that controls access to the security perimeter 140 via a security service API (e.g., secret management API 147) (i.e., establishes a firewall for the security perimeter 140). Combined with Figure 1 refer to Figure 2According to an example implementation, when acting as a proxy, the main processing core 154 of BMC 129 can write data corresponding to a request and conforming to the security service API to the request buffer 270 of security bridge 214 via interconnect 218. As an example, interconnect 218 can be a bus 218 (e.g., an SPI bus) or an internal interconnect structure such as an Advanced Microcontroller Bus Architecture (AMBA) or Advanced Scalable Interface (AXI) structure. According to an example implementation, one or more security processing cores 208 can process secret management requests and store the data in a response buffer 272. This data represents a response to the secret management request (e.g., rejection, acknowledgment, data representing the requested data, etc.), and the main processing core 154 can read the data from the response buffer 272 and forward the response to the requester. According to some implementations, security bridge 214 can verify whether the requester has access rights to a given request (i.e., verify whether security bridge 214 can accept and process the request, or reject the request) based on one or more parameters of the request, such as parameters representing the requester's credentials (e.g., requester identifier and password, key, or certificate), commands, command operands, etc. According to some implementations, the Security Service API may be separate from the Secret Management API 147; and according to further example implementations, the Security Service API may be part of each Secret Management API 147.

[0060] Security bridge 214 can provide an additional upstream interface to allow security enclosure 140 to "reach out" to interconnect 218. Security enclosure 140 can use the upstream interface to obtain its firmware, and generally, to verify firmware 170 ( Figure 1 The security bridge 214 can employ filtering and monitoring on the interconnect 218 to prevent unauthorized access to the memory 151.

[0061] Similarly, Figure 2 As depicted, according to an example embodiment, the security enclosure 140 may include a tamper detection circuit 234 that receives various environmental sensor signals 236 (e.g., sensor signals representing temperature, clock rate, voltage, etc.) to detect malicious manipulation of the operating environment of the security enclosure, so that appropriate action can be taken when such manipulation occurs. In this way, according to the example embodiment, when the tamper detection circuit 234 detects tampering, it can initiate one or more corrective actions through the security enclosure 140 to address the detected security breach. As an example, when the tamper detection circuit 234 indicates that tampering has been detected, the security enclosure 140 may remove sensitive information (e.g., erase certain secrets, such as erasing secret 145 stored in secure memory 144); assert signals or messages to warn external components (e.g., main processing core 154, operating system 113, etc.). Figure 1 ), Remote Management Server 190 ( Figure 1 To prevent tampering; to suspend or reset external (multiple) main processing cores 154; etc. According to some implementations, such as Figure 2 As depicted, the secure enclosed area 140 may include an encryption engine 270 that encrypts data written to the secure memory 144 and decrypts data read from the secure memory 144. Depending on the specific implementation, encryption and decryption may use an Advanced Encryption Standard-XOR-Encryption-XOR-Adjusted Codebook Mode (or "AES-XTS") block cipher with ciphertext interception or another block cipher.

[0062] According to an example implementation, the secure enclosing region 140 may include a cryptographic accelerator 244 (such as a symmetric cryptographic accelerator and an asymmetric cryptographic accelerator) that assists the security processor 142 in performing operations such as key generation, signature verification, encryption, and decryption. Furthermore, the cryptographic accelerator 244 may include a true random number generator to provide a trusted entropy source for cryptographic operations.

[0063] According to an example implementation, the secure enclosing region 140 may, among other components, include a one-time programmable (OTP) fuse 258 storing data representing truly immutable properties, such as a Silicon Root of Trust Secure Hash Algorithm 2 (SHA-2) signature (e.g., an immutable fingerprint used by the SRoT engine 143), a unique identifier (e.g., an identifier used to determine the seed of a platform identity certificate), a security-supporting fingerprint, etc. Those skilled in the art will understand that the secure enclosing region 140 may have other components that can exist in a processor-based architecture, such as a timer 254, an interrupt controller 250 (which receives interrupt trigger stimuli from the timer 254 and other sources), etc.

[0064] Furthermore, the secure enclosed zone 140 may include interfaces for assisting in the initial development and debugging of the secure enclosed zone 140 (in the pre-production mode of the secure enclosed zone 140), but these interfaces may be completely disabled or their functionality may have changed when certain fuses (e.g., certain OTP fuses 258) are blown (for the production mode of the secure enclosed zone 140). For example, these interfaces may include a Universal Asynchronous Receiver / Transmitter (UART) 262, which can be used for debugging and development of the secure enclosed zone 140, and then fixed to a transmit-only configuration for the production mode of the secure enclosed zone 140. As an example, according to some implementations, the UART 262 may be configured by the OTP fuse 258 to provide one-way state health information from the secure enclosed zone 140 in the production mode of the secure enclosed zone 140. As another example, according to a further implementation, the OTP fuse 258 may disable the UART 262 for the production mode, thereby disabling all communication with the UART 262 to prevent all communication across the cryptographic boundary 204. As another example of an interface that can assist in the initial development and debugging of the security enclosure 140, but can be modified / disabled for production mode, the security enclosure 140 may include a Joint Test Action Group (JTAG) interface (not shown) for the security processor 142; and the JTAG interface can be disabled for production mode of the security enclosure 140.

[0065] Combination Figure 2 refer to Figure 3 According to an example embodiment, semiconductor package 153 may include a die 157-2 in which secure memory 144 is fabricated. In this way, the memory cells of secure memory 144 and additional components of secure memory 144 for storing and retrieving data from the memory cells (e.g., decoding logic, encoding logic, control signal generation logic, etc.) may be fabricated in semiconductor die 157-2. According to an example embodiment, semiconductor package 153 may include one or more additional dies 157-1, which contain other components of BMC 129. Figure 3 In the example implementation depicted, semiconductor die 157-1 includes other components 312 of a security enclosed region 140 and non-security management plane components 314 of BMC 129 (e.g., main processing core 154 and memory 155).

[0066] like Figure 3 As depicted, the secure memory 144 can be coupled to the remainder of the secure enclosure 140 via an interconnect 320 between dies 157-1 and 157-2. According to some embodiments, the interconnect 320 may correspond to the cryptographic processing engine 270 (see...). Figure 2The interconnect 320 is the physical communication interface between the secure memory 144 and the semiconductor die 153. The interconnect 320 is disposed together with the semiconductor die 153 and cannot be directly accessed from outside the semiconductor package 153. Due to this arrangement, the address, data, or control terminals of the secure memory 144 are not exposed outside the semiconductor package 153. In other words, the semiconductor package 153 may have external terminals 316, but these terminals 316 will not be probed to eavesdrop on communication with the secure memory 144. Therefore, Figure 3 The depicted arrangement can provide an additional level of protection for the data stored in the security memory 144.

[0067] Combination Figure 2 refer to Figure 4 According to a further exemplary embodiment, as depicted by reference numeral 408, all components of the security enclosure 140, including the security memory 144, can be fabricated in a single die 157 of the semiconductor package 400 (which replaces the semiconductor package 153). The main processing core 154 ( Figure 2 The secure memory 144 may be manufactured, for example, in another die of the semiconductor package 400. According to a further example embodiment, the semiconductor package 400 may include multiple semiconductor dies, and for these example embodiments, the secure memory 144 may not be separated into a die different from the other components of the secure enclosing region 140. According to yet another example embodiment, the main processing core 154 and all components of the secure enclosing region 140 are manufactured in a single semiconductor die of the semiconductor package. Thus, many embodiments within the scope of the appended claims are contemplated.

[0068] Return to reference Figure 1 According to an example implementation, storage device 122 may be an NVMe storage device, and secure memory 144 may store data representing a key encryption key (i.e., security secret 145) of the NVMe storage device 122. According to some implementations, CPU core 102 executing boot service firmware (e.g., UEFI 111 boot service firmware) may detect the NVMe storage device 122 and perform credential management on the storage device 122 in response to the boot of computer platform 100. Combined with... Figure 1 refer to Figure 2 As part of this credential management, CPU core 102 can submit API calls or requests to the secure enclosing zone 140 to request a key encryption key for the NVMe storage device 122. In this way, CPU core 102 can submit a request associated with a specific secret management API 147, which includes commands requesting the key encryption key, the identifier of the NVMe drive 122, security credentials, etc. The secure bridge 214 and security processing core 208 of the secure enclosing zone 140 can process the request and provide a corresponding response.

[0069] More specifically, combined Figure 1 and Figure 2 refer to Figure 5 According to an example implementation, secure enclosing zone 140 may execute process 500 to process a request for access to secret 145, where secret 145 is a key encryption key (or "KEK"). According to block 504, process 500 includes secure enclosing zone 140 receiving an API request that includes a command requesting the KEK. Secure enclosing zone 140 may perform one or more security checks on the API request (block 508). For example, secure bridge 214 may verify whether the requester has the appropriate credentials to submit the API request to secure enclosing zone 140; secure processing core 208 may execute instructions to verify whether the requester has the privileged access to request the KEK; and so on. In response to secure enclosing zone 140 determining (determination block 512) that the security checks have passed, secure processing core 208 may then execute instructions according to block 516 to cause processing core 208 to execute the command included in the API request to access the KEK. Execution of the command may include processing core 208 reading data representing the KEK from secure memory 144. According to box 520, the security bounding zone 140 can then provide a response to the API request, such as providing the KEK, rejecting the API request, providing a response that the KEK was not found, etc.

[0070] As another example, security secret 145 could be a certificate, and security enclosure 140 could be executed. Figure 6 The process 600 described herein is used to update or delete the certificate. As an example, a specific API request may be designed to update the certificate associated with the remote management server 190, update the certificate associated with the computer platform 100, update the root certificate, update the intermediate certificate, delete the certificate, and so on.

[0071] Combination Figure 1 and Figure 2 refer to Figure 6According to some implementations, process 600 includes a secure enclosing zone 140 receiving (box 604) an API request that includes a command to request the renewal or deletion of a certificate. According to box 608, the secure enclosing zone 140 may perform one or more security checks on the API request. These security checks may be performed by a secure bridge 214 and / or a secure processing core 208. For example, the secure bridge 214 may act as a gatekeeper for the secure enclosing zone to verify that the requester has the appropriate credentials to submit the API request to the secure enclosing zone 140; the secure processing core 208 may execute instructions to verify that the requester has the access privileges to request the renewal or deletion of a certificate; and so on. In response to the secure enclosing zone 140 determining (determination box 612) that the (multiple) security checks have been passed, the secure processing core 208 may then execute instructions according to box 616 to cause the processing core 208 to execute the command included in the API request to update or delete the certificate. Following box 620, the secure enclosed area 140 can then provide responses to API requests, such as confirming certificate deletion, confirming certificate updates, rejecting API requests, providing responses for certificates not found, etc.

[0072] refer to Figure 2 As another example of security secret 145 and secret management API 147, according to further embodiments, a particular secret management API 147 may involve sealing or desealing a cryptographic key (i.e., secret 145). For example, according to some embodiments, the volatile memory 151 of the secure enclosed region 140 may store data representing TCB measurements (such as PCR measurements). Furthermore, the operating system 113 of the computer platform 100 ( Figure 1 The system can perform operations bound to a TCB measurement. For example, the operating system 113 can use a TCB measurement to seal the KEK to a specific state of the computer platform 100, such as binding a key encryption hard disk encryption key to a specific set of PCR values. "Sealing" means that the secure enclosing zone 140 encrypts the KEK into a PCR value such that if the current PCR value does not match the PCR value to which the KEK was sealed, the secure enclosing zone 140 will not unseal or decrypt the KEK and will not provide the hard disk encryption key to the operating system 113.

[0073] As another example of security secret 145 and secret management API 147, according to a further implementation, a particular secret management API 147 may involve sealing or desealing a password (i.e., secret 145) for a specific set of PCR values. For example, operating system 113 ( Figure 1 The password can be sealed to a specific set of PCR values ​​to allow the sealed password to be provided to UEFI 111 after the computer platform 100 restarts. Figure 1Therefore, for this example, the secret management API 147 could include an API for sealing a password to a set of PCR measurements and an API 147 for desealing the password based on the provided set of PCR measurements.

[0074] Similarly, according to some implementations, security secret 145 may be a Virtual Private Network (VPN) key, and secret management API 147 may include API 147 for sealing the VPN key to a set PCR measurement and API 147 for unsealing the VPN key based on a provided set of PCR measurements. As other examples, according to further implementations, security secret 145 may be a file, a generated random number, a key, a hash, a public key, a private key, a password, etc. Regardless of its specific form, a requester can securely access security secret 145 using one or more secret management APIs 147.

[0075] refer to Figure 7 According to an example embodiment, device 700 includes a host 704 and a baseboard management controller 708. Baseboard management controller 708 includes a semiconductor package 712; and semiconductor package 712 includes memory 716, a security hardware processor 720; and a main hardware processor 724. The main hardware processor 724 causes baseboard management controller 708 to act as an agent that manages host 704 independently of host 704 in response to communications with a remote management entity. Security hardware processor 720 manages the storage of secrets 717 of host 704 in memory 716.

[0076] refer to Figure 8 According to an example implementation, process 800 includes a baseboard management controller of a computer platform communicating with a management entity (block 804) to manage the host of the computer platform. Process 800 includes storing secure secrets of the computer platform (block 808) in the secure memory of the baseboard management controller. The secure hardware processor of the baseboard management controller manages the storage of secrets (block 812).

[0077] refer to Figure 9 According to an example implementation, semiconductor package 902 includes a main hardware processor 924 and a secure enclosing region 904. The secure enclosing region 904 includes secure memory 908 and a hardware security processor 916. Management controller 900 also includes a communication interface 920. The main hardware processor 924 executes instructions to communicate with a remote management server via the communication interface 920 and, in response to this communication, manages the host of the computer platform. The hardware security processor 916 provides an application programming interface (API) 906 to the host to manage secrets 912 stored in the secure memory 908.

[0078] According to an example implementation, the main hardware processor acts as a proxy between the security hardware processor and the host. The proxy receives a request from a requester on the host to manage the storage of secrets. The proxy forwards the request to the security hardware processor. The security hardware processor provides the proxy with a response to the request. The proxy forwards the response back to the requester. A particular advantage is that the proxy restricts access to the security hardware processor.

[0079] According to an example implementation, the main hardware processing core can provide a request for managing a secret of the board management controller, which is stored in secure memory. The secure hardware processor manages the storage of the secret in response to the request. A particular advantage is that the board management controller can store both the host's secret and the board management controller's secret.

[0080] According to an example implementation, the memory includes terminals for communicating with the memory for data, address, and control signals; and all terminals are not exposed outside the semiconductor package. A particular advantage is that physical tampering can be prevented.

[0081] According to an example embodiment, the semiconductor package may further include a first die containing memory and a second die containing a security hardware processor. Furthermore, the semiconductor package may include interconnects coupling the first and second dies. A particular advantage is that physical tampering can be prevented.

[0082] According to the example implementation, the second die may also include a main hardware processor. A particular advantage is that it can prevent physical tampering.

[0083] According to an example implementation, the secure hardware processor executes instructions to provide an application programming interface for managing secret storage. A particular advantage is that access to the secure hardware processor is restricted.

[0084] According to an example implementation, the baseboard management controller also includes a secure enclosed region with an associated cryptographic boundary. The secure processor and memory are located within the cryptographic boundary; and the main hardware processor is located outside the cryptographic boundary. A particular advantage is that access to the secure hardware processor is restricted.

[0085] According to an example implementation, the board management controller's management of the host includes at least one of the following: controlling the host's system power state, controlling the host's boot path, performing host thermal management, managing the host's use of virtual media, controlling the host's boot, performing host security checks, performing host fault checks, verifying firmware executed by a second hardware processor, verifying firmware executed by a security processor, performing host fault recovery, or providing a remote console for a remote management entity. A particular advantage is that the board management controller can provide both management-related and security-related roles for the host.

[0086] 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. The appended claims are intended to cover all such modifications and variations.

Claims

1. An apparatus for managing storage of secrets, comprising: a host; and a baseboard management controller comprising a semiconductor package, wherein the semiconductor package comprises: a secure enclave having an associated cryptographic boundary; a memory within the cryptographic boundary; a host hardware processor outside the cryptographic boundary, wherein the host hardware processor is to cause the baseboard management controller to act as a proxy independent of the host to respond to communications with a remote management entity to manage the host; and a secure hardware processor within the cryptographic boundary, wherein the secure hardware processor is separate from the host hardware processor, and wherein the secure hardware processor is to manage storage of a secret of a host in the memory.

2. The apparatus of claim 1, wherein: the host hardware processor is to act as a proxy between the secure hardware processor and the host; the proxy is to receive a request from a requestor of the host to manage storage of the secret; the proxy is to forward the request to the secure hardware processor; the secure hardware processor is to provide a response to the request to the proxy; and the proxy is to forward the response to the requestor.

3. The apparatus of claim 1, wherein: the host hardware processor is to provide a request to manage storage of a secret of the baseboard management controller in the memory; and the secure hardware processor is to manage the secret in response to the request.

4. The apparatus of claim 1, wherein: the memory comprises terminals to communicate data, addresses, and control signals with the memory; and none of the terminals are exposed outside the semiconductor package.

5. The apparatus of claim 1, wherein, the semiconductor package further comprises: a first die containing the memory; a second die containing the secure hardware processor; and an interconnect coupling the first die and the second die.

6. The apparatus of claim 5, wherein, the second die further comprises the host hardware processor.

7. The apparatus of claim 1, wherein, the secure hardware processor is to execute instructions to provide an application programming interface to manage storage of the secret.

8. The apparatus of claim 1, wherein, the semiconductor package further comprises a die comprising the memory, the secure hardware processor, and the host hardware processor.

9. The apparatus of claim 1, wherein, the secret comprises a cryptographic key, a certificate, or a password.

10. The apparatus of claim 1, wherein, the management of the host by the baseboard management controller comprises at least one of controlling a system power state of the host, controlling a boot path of the host, performing thermal management of the host, managing use of virtual media by the host, controlling boot of the host, performing a security check of the host, performing a fault check of the host, verifying firmware executed by a second hardware processor, verifying firmware executed by the secure hardware processor, performing fault recovery of the host, or providing a remote console for a remote management server.

11. A method for managing storage of secrets, comprising: communicating, by a baseboard management controller of a computer platform, with a management entity to manage a host of the computer platform, wherein the baseboard management controller comprises a management plane and the management plane comprises an agent; storing a secret of the computer platform in a secure memory of the baseboard management controller; and managing, by a secure hardware processor of the baseboard management controller, storage of the secret, wherein the baseboard management controller further comprises a security plane and the secure hardware processor is associated with the security plane; receiving, by the agent from the host, a request to manage storage of the secret; forwarding, by the agent, the request to the secure hardware processor; providing, by the secure hardware processor to the agent, a response to the request; and forwarding, by the agent, the response to the requestor.

12. The method of claim 11, wherein, the communication comprises at least one of controlling a system power state of the host, controlling a boot path of the host, performing thermal management of the host, managing use of virtual media by the host, controlling boot of the host, performing a security check of the host, performing a fault check of the host, verifying firmware executed by a second hardware processor, verifying firmware executed by the secure hardware processor, performing fault recovery of the host, or providing a remote console for the management entity.

13. The method of claim 11, wherein: managing storage of the secret comprises executing, by the secure hardware processor, instructions associated with an application programming interface (API); and executing the instructions comprises the secure hardware processor performing at least one of managing access to a cryptography key, managing access to a key encryption key, creating a key, storing a certificate, creating a certificate, deleting a certificate, or updating a certificate.

14. The method of claim 11, wherein, managing storage of the secret comprises managing storage of the secret within a cryptography boundary that includes the secure hardware processor and the secure memory.

15. A management controller comprising: a semiconductor package comprising a host hardware processor and a secure enclave separate from the host hardware processor, wherein the secure enclave comprises a secure memory and a hardware security processor; a communication interface; wherein the host hardware processor is to execute instructions to communicate with a remote management server via the communication interface and manage a host of a computer platform in response to the communication; wherein the hardware security processor is to provide an application programming interface (API) to manage a first secret of the host stored in the secure memory; wherein the host hardware processor is to act as a proxy for the hardware security processor for a first request from the host intended to manage the first secret; and wherein the host hardware processor is to submit a second request to the hardware security processor intended to manage a second secret associated with the management controller.

16. The management controller of claim 15, wherein, the semiconductor package further comprises: a first die comprising the secure memory; a second die comprising the hardware security processor and the host hardware processor; and an interconnect coupling the first die and the second die.

17. The management controller of claim 15, wherein: the secure enclave has an associated cryptographic boundary; the hardware security processor and the secure memory are within the cryptographic boundary; and the host hardware processor is outside the cryptographic boundary.

18. The management controller of claim 17, wherein: the host hardware processor is configured to execute a cryptographic operation on a data item to be provided to the hardware security processor; and the hardware security processor is configured to execute a cryptographic operation on the data item to be provided to the secure memory.

19. The management controller of claim 18, wherein: the host hardware processor is configured to execute a cryptographic operation on a data item to be provided to the secure memory; and the hardware security processor is

Images