Securing communication with security processors using platform keys

Abstract

A computer platform comprises a security processor, at least one hardware processor, and memory. The security processor stores data representing a private platform key. The private platform key is part of an asymmetric key pair, and the asymmetric key pair contains a public platform key. The memory stores a firmware image. The firmware image contains data representing a root certificate of a public key infrastructure that signs a second certificate associated with the computer platform. The second certificate contains the public platform key and binding information that binds the second certificate to the computer platform.The firmware image contains instructions that, when executed by the hardware processor(s), cause the hardware processor(s) to access data representing the second certificate and, based on the root certificate and binding information, determine whether the second certificate is valid. Furthermore, when executed by the hardware processor(s), these instructions, in response to the determination that the second certificate is valid, cause the hardware processor(s) to use the public platform key to secure communication with the security processor.

Description

BACKGROUND

[0001] A computer platform can be vulnerable to a security attack in which a malicious organization attempts to access information stored on the platform or to damage its components. To prevent security attacks, or at least limit the extent of potential damage, the computer platform can have various levels of protection. For example, the platform can have various access control mechanisms, such as firewalls, passwords, keys, and so on. Another example is that the platform can have a secure cryptographic processor, which can provide a range of security features.The security-relevant features can, for example, serve to ensure that the computer platform behaves consistently in the expected manner and to prove that the computer platform is trustworthy.

[0002] From YLÖNEN, T.: “SSH - Secure Login Connections over the Internet”, in: 6th USENIX Security Symposium, July 22-25, 1996, San Jose, CA, USA, a secure protocol for logging in and transferring files over an insecure network is known, using an asymmetric key pair. The article “Public key certificate”, in: Wikipedia, the free encyclopedia, last edited on 28.12.2021, describes the general function of asymmetric encryption techniques, and HARRIS, B.: RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol, Network Working Group, RFC 4432, March 2006, concerns a method for exchanging keys for the Secure Shell (SSH) protocol based on the Rivest-Shamir-Adleman (RSA) public-key encryption. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 is a schematic diagram of a computer platform with functions for securing communication with a security processor using a platform key according to an example implementation. Fig. Figure 2 is a flowchart that illustrates a process for validating a certificate for security processor binding based on a signature of the certificate and the platform binding information contained in the certificate, according to a sample implementation. Fig. Figure 3 is an illustration of the binding information of a certificate for security processor binding according to a sample implementation. Fig. Figure 4 is a flowchart that represents a process executed by the platform firmware to establish and use a secure communication session with a security processor according to a sample implementation. Fig. Figure 5 is a flowchart that represents a process of the security processor to enable the use of the platform key for secure communication with the security processor according to a sample implementation. Fig. Figure 6 is a schematic representation of a computer platform that uses a public platform key to secure communication with a computer platform security processor according to an example implementation. Fig. Figure 7 is a flowchart that illustrates a process for using a public platform key to establish a secure communication session with a security processor and for communicating with the security processor using the secure communication session, according to an example implementation. Fig. Figure 8 is an illustration of machine-executable instructions stored on a machine-readable, non-transferable storage medium which, when executed by a machine, cause the machine to establish a secure communication session with a security processor of the machine using a public platform key according to an example implementation. DETAILED DESCRIPTION

[0003] A secure cryptographic processor, or security processor, for a computer platform can provide trusted computational operations to ensure that the platform behaves consistently as expected. Examples of trusted computational operations include: generating cryptographic keys; storing security artifacts (such as cryptographic keys and certificates); accessing security artifacts; deleting security artifacts; storing integrity measurement dumps; providing signed integrity measurement dumps for remote attestation; encrypting data; decrypting data; and binding cryptographic keys to specific integrity measurement dump states (e.g.,Examples of trusted computational operations include binding a storage device's encryption key to a set of integrity measures; unsealing cryptographic keys; providing nonces for cryptographic communications; signing certificates; providing random or pseudorandom numbers; and so on. Trusted computational operations can also include operations for configuring the security processor and operations for owning the security processor. A Trusted Platform Module (TPM) is an example of a security processor.

[0004] Requests to and responses from the security processor can be transmitted via a security processor bus. This bus may be vulnerable to interception. Such interception could expose sensitive or confidential information about the computer platform, such as cryptographic keys, authorization passwords, etc.

[0005] One solution to prevent, if not completely eliminate, eavesdropping on the security processor bus is to encrypt communication over the bus using a cryptographic session key. For example, a caller or requester of a service provided by the service processor can generate a symmetric session key and pass it to the service processor, thus encrypting communication over the service processor bus with the session key. To enable the requester to pass the session key to the service process, they can first generate a random or pseudorandom value, known as a "salt." The salt can then be used by the requester as input for a specific algorithm to generate a corresponding session key.According to example implementations, the salt can be part of a seed used to generate the session key using a specific algorithm, and the other parts of the seed can be known. The requester can encrypt the salt with a public key (or "public part") of an asymmetric cryptographic key (also called an "asymmetric key pair") and send the encrypted salt to the service processor. Since the security processor has the private key (or "private part") of the asymmetric key, it can decrypt the salt and use it as input for the same algorithm to generate the session key for its own use.

[0006] One way to distribute the session key as described above is to use an asymmetric annotation key. The annotation key can be part of the security processor's encryption hierarchy. However, this type of session key distribution is not available for platform firmware because the operating system controls the acknowledgment hierarchy (to the exclusion of the platform firmware). Furthermore, the annotation key must not be tied to a specific computer platform.

[0007] In accordance with the example implementations described here, the platform firmware can secure communication with a security processor using a secure communication session whose session key is distributed using an asymmetric platform key. The asymmetric platform key can be part of a platform hierarchy of the security processor, and the asymmetric platform key can consist of two parts: a private platform key (securely stored in the security processor) and a public platform key.

[0008] The public platform key can be contained in a certificate. Before the platform firmware uses the public platform key provided by the certificate to distribute the session key, it first validates the certificate; that is, it determines whether the certificate is trusted. In accordance with example implementations, the platform firmware performs a two-part certificate validation. In the first part of the validation, the platform firmware validates the signature of the public key infrastructure (PKI) that signed the certificate. The PKI comprises a chain of certificates of trust, starting with a root certificate authority (CA) certificate (or "root certificate"), which is part of the platform firmware, including zero, one, or more intermediate certificates, and ending with the certificate containing the public platform key.

[0009] According to example implementations, the certificate containing the public platform key also includes platform binding information that binds the specific computer platform to the security processor (since the security processor possesses the corresponding private platform key). Because the binding information is part of the certificate, the vendor can bind the security processor to the platform identity by signing the certificate. A certificate containing a public platform key and platform binding information is referred to here as a "security processor binding certificate."

[0010] The second part of the two-part validation process involves the platform firmware validating the platform binding information contained in the security processor's binding certificate. As the name suggests, the binding information binds the security processor binding certificate to the specific computer platform. In accordance with some implementations, the binding information includes, for example, an inventory of the computer platform, such as platform-specific information like a computer platform serial number, identifiers for hardware components, identifiers for software components, hashes of software components on the computer platform, and so on. The platform firmware can then compare a platform manifest (i.e., an inventory obtained from the platform firmware) with the inventory represented by the binding information.If the two inventories match, the security processor's binding certificate passes the second part of the two-part validation (see example implementations).

[0011] As in Fig. As illustrated in Figure 1 as a more specific example, a computer platform 100, according to some implementations, comprises a security processor 160 and one or more main processing cores 110 (i.e., hardware processors, such as CPU processing cores, graphics processing units (GPUs), and so on). The computer platform 100 can, according to examples, be a modular unit comprising a frame or enclosure. Furthermore, this modular unit can include hardware attached to the enclosure that is capable of executing machine-executable instructions. A blade server is one example of a computer platform 100 according to one example implementation. However, according to other implementations, the computer platform 100 can be any number of different platforms besides a blade server, for example...for a rack server, a standalone server, a client, a desktop, a smartphone, a portable computer, a network component, a gateway, a network switch, a storage array, a portable electronic device, a portable computer, a tablet computer, a thin client, a laptop computer, a television, a modular switch, a consumer electronics device, a device, an edge processing system, a sensor system, a clock, a removable peripheral card, and so on.

[0012] One or more main processing cores 110 of the computer platform 100 can execute machine-executable instructions 109 (stored in system memory 114) that cause the main processing core(s) 110 to construct various firmware and software components of the computer platform 100. For example, one or more main processing cores 110 can execute platform firmware instructions, such as platform firmware instructions derived from a Unified Extensible Firmware Interface (UEFI) image 196, to construct a UEFI 132. The UEFI 132 can provide pre-boot and runtime services for the computer platform 100. In this context, a "pre-boot service" (also called a "boot service") refers to a service or function provided by the UEFI 132 after the computer platform 100 is powered on or reset and before control is transferred to an operating system 130.Pre-boot services can include services such as initializing hardware components like the main processing cores 110 and system memory 114, loading and executing drivers in a specific order to initialize the computer platform 100, performing hardware and software security checks, loading a bootloader for the operating system 130, validating and loading drivers for I / O peripheral devices such as PCIe (Peripheral Component Interconnect Express) devices 105, and so on. "Runtime services" refer to services provided by UEFI 132 after control of the computer platform 100 has been transferred to the operating system 130.

[0013] As part of providing pre-boot and runtime services, the UEFI 132 can communicate with the security processor 160 to perform trusted computations, and these trusted computations can potentially be vulnerable to eavesdropping on a security processor bus 159. For example, data representing platform secrets 162 stored in the security processor 160 can potentially be transmitted over the security processor bus 159. Platform secrets 162 might include passwords, encryption keys that secure data on storage drives (not shown) of the computer platform 100, and so on. The security processor bus 159 could be, for example, an SPI (Serial Peripheral Interface) bus, an enhanced SPI bus, an I3C (Improved Inter-Integrated Circuit) bus, or another bus, depending on the specific implementation.To prevent eavesdropping on bus 159 from intercepting sensitive information (e.g., data constituting secrets 162), communication over bus 159 can be encrypted using cryptographic session keys.

[0014] In particular, communication via bus 159 can occur in communication sessions with the security processor 160, as shown in the example implementations. In this context, a "session" (or "communication session") with the security processor 160 refers to a communication exchange between the security processor 160 and a caller (or "requester"). A session might, for example, involve the transmission of data related to a trusted computing operation and may include a request (e.g., a request containing a command) from a caller or requester (e.g., the UEFI 132) and a corresponding response from the security processor 160.A session might include, for example: a requester requesting a secret 162 from security processor 160, and security processor 160 providing the secret 162; a requester requesting an extension of the platform configuration register (PCR), and security processor 160 acknowledging the request; a requester requesting the unsealing of a cryptographic key, and security processor 160 responding to the request; a requester requesting the binding of a cryptographic key to a specific PCR state, and security processor 160 responding to the request; a requester requesting a random number, and security processor 160 providing the random number; and so on.

[0015] In accordance with example implementations, a session may include communications relating to trusted computational operations described in the Trusted Platform Module Library Specification, Family 2.0, Level 00, Revision 01.59 (November 2019) published by the Trusted Computing Group (hereinafter referred to as the "TPM 2.0 Specification"). In accordance with some implementations, a communication session may include communications relating to a trusted computational operation not described in the TPM 2.0 Specification.

[0016] The data for a given communication session between the UEFI 132 and the security processor 16 can be encrypted using a symmetric session key generated by the UEFI 132 and distributed by the UEFI 132 to the security processor 160. In accordance with example implementations, the UEFI 132 uses an asymmetric cryptographic key (i.e., a key pair containing a public key and a corresponding private key) to distribute the session key to the security processor 160, so that the security processor 160 can use the session key to encrypt and decrypt data transmitted over bus 159 during the session.In accordance with example implementations, the asymmetric key comprises a public part, a public platform key 186, provided by a binding certificate 182 of the security processor, and a private part, or private platform key 168, stored in the secure memory 166 of the security processor 160. The manufacturer of the computer platform 100 equips the security processor 160 with the private platform key 168, as per the example implementations.

[0017] According to example implementations, UEFI image 196 contains data representing a Platform Key Root Certificate 134 (referred to here as "Platform Key Root Certificate 134"), and as such, Platform Key Root Certificate 134 is part of UEFI 132. Platform Key Root Certificate 134 is part of the Platform Key that signed the Security Processor Binding Certificate 182 (assuming it is validated by UEFI 132). Platform Key Root Certificate 134 is trusted by UEFI 132 and forms the root of a chain of trust, which is validated by UEFI 132 as part of the first part of the two-part validation of the Security Processor Binding Certificate 182.The trust chain comprises the binding certificate 182 of the security processor at the end of the trust chain, the root certificate 134 of the platform key at the beginning of the trust chain, and zero, one or more intermediate certificates 194 between the root certificate 134 of the platform key and the binding certificate 182 of the security processor. As in . Fig. As shown in Figure 1, a persistent or non-volatile memory 180 of the computer platform 100 can store data representing the security processor binding certificate 182, the UEFI image 196 and one or more intermediate certificates 194.

[0018] In this context, a "platform key" refers to a key that is part of a platform hierarchy of the Security Processor 160. A "hierarchy" generally refers to a group of objects that are related to one another and can be managed as a group. In addition to the platform hierarchy, the Security Processor 160 may have one or more other hierarchies, such as a memory hierarchy and a memorization hierarchy. According to the example implementations, the platform hierarchy is used by the manufacturer of the Computer Platform 100, and the platform firmware, such as UEFI 132, owns the platform hierarchy.

[0019] In accordance with example implementations, during the manufacture of computer platform 100, the manufacturer equips the computer platform 100 with the security processor binding certificate 182 by storing data representing the security processor binding certificate 182 in non-volatile memory 180. The manufacturer may also equip the security processor 160 with the private platform key 168. In accordance with example implementations, the security processor binding certificate 182 contains the public platform key 186, which corresponds to the private platform key 168.

[0020] In addition to the public platform key 186, the security processor binding certificate 182, in accordance with example implementations, contains a signature 184 and platform binding information 188. In accordance with some implementations, a security processor binding certificate validation engine 136 of the UEFI 132 performs a two-part validation of the security processor binding certificate 182. The first part of the validation is a signature-based validation, in which the certificate validation engine 136 validates the signature of the PKI that signed the security processor binding certificate 182. This validation includes validating the chain of trust, which ends with the security processor binding certificate 182 and begins with the root certificate of the platform key 134.

[0021] If the security processor binding certificate 182 passes signature-based validation, the security processor binding certificate validation engine 136, according to example implementations, performs the second part of the validation, which involves validating the security processor binding certificate 182 based on the platform binding information 188 contained in the certificate 182. In this way, according to some implementations, the UEFI 132 can determine a platform inventory or manifest 111 for the computer platform 100 when it boots. The platform manifest 111 can contain, for example, a model of the computer platform 100, a serial number of the computer platform 100, identifiers for hardware components installed in the computer platform 100, identifiers or hashes for software components installed in the computer platform 100, and so on.The security processor binding certificate validation system 136 can compare the platform binding information 188 contained in the security processor binding certificate 182 with the platform manifest 111. If, according to example implementations, the inventory of platform binding information 188 matches the inventory of the platform manifest 111, the security processor binding certificate 182 passes the second part of the validation; otherwise, the second part of the validation fails.

[0022] After validating the security processor binding certificate 182, the UEFI 132 can then use the public platform key 186 to distribute a salt to the security processor 160, allowing the security processor 160 and the UEFI 132 to use a session key generated from the salt. In some implementations, the UEFI 132 validates the security processor binding certificate 182 before each communication session with the security processor 160. In other implementations, the session key can be used for multiple sessions, and the UEFI 132 can validate the security processor binding certificate 182 before a series of multiple communication sessions with the security processor 160.

[0023] According to example implementations, the UEFI 132 includes a communication engine 138 that performs functions related to the communication between the UEFI 132 and the security processor 160. These functions, according to example implementations, can include generating salts, encrypting the salts with the public platform key 186, submitting requests to establish secure communication sessions with the security processor 160, submitting the encrypted salts to the security processor 160, generating symmetric session keys using the salts as inputs, encrypting data using symmetric session keys, decrypting data using symmetric session keys, and so on.

[0024] As in Fig. As shown in Figure 1, in accordance with example implementations, a Baseboard Management Controller (BMC) 123 of the computer platform 100 can control access to the non-volatile memory 180. For example, according to one example implementation, the platform key validation engine 136 can send a request to the BMC 123 to read the security processor binding certificate 182, and in response to the request, the BMC 123 can provide the engine 136 with data representing the contents of the security processor binding certificate 182.

[0025] The BMC 123, as part of its management layer, can perform various administrative tasks for the computer platform 100, including monitoring sensors (e.g., temperature sensors, fan speed sensors), monitoring the operating system status, monitoring the power status, logging computer system events, verifying the UEFI image 196 when the main processing core 110 instantiates the UEFI 132, and providing administrative functions that can be remotely controlled by a remote management server. Furthermore, the BMC 123 can enable operations to be performed when the computer platform 100 is powered off and before the operating system has booted; and the BMC 123 can be used to perform recovery operations after an operating system or computer system failure.In accordance with example implementations, the BMC 123 can include a network interface for communication with a remote management server (not shown). In accordance with other implementations, the BMC 123 can communicate with the remote management server via passthrough communication through a PCle device 105 of the computer platform 100.

[0026] As part of its security layer, the BMC 123 can perform various security-related tasks for the computer platform 100, such as validating BMC firmware before it is executed. Security-related tasks can also include validating the UEFI image 196 after powering on or resetting the computer platform 100, before the firmware instructions contained in the UEFI image 196 are executed by the main processing kernel(s) 110. Monitoring software measurements (operating system kernel measurements) to detect security issues can also be a security-related task. Updating the firmware can also be a security-related task. Furthermore, as part of its security-related tasks, the BMC 123 can measure a UEFI boot block and extend a PCR state stored in the security processor 160 to include the measured UEFI boot state.The BMC 123 can perform a number of other security-related tasks for the Computer Platform 100.

[0027] A Baseboard Management Controller (BMC) is a specialized service processor that monitors the physical state of a server or other hardware using sensors and communicates with a management system over a management network. The BMC can also communicate with applications running at the operating system level through an IOCTL (Input / Output Controller) interface driver, a REST (Representational State Transfer) API, or another system software proxy that facilitates communication between the BMC and the applications. The BMC can access hardware devices located within a server chassis, including system memory, at the hardware level. The BMC may also be able to directly modify these 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 of the server or other device being monitored. The fact that a baseboard management controller is mounted on the motherboard of the server / hardware being monitored, or otherwise connected or attached to it, does not prevent the baseboard management controller from being considered "disconnected" from the server / hardware being monitored. As used herein, a baseboard management controller has management functions for subsystems of a computer device and is separate from a processing resource that runs a computer device's operating system. The baseboard management controller is separate from a processor, for example.a central processing unit that runs a high-level operating system or hypervisor on a system.

[0028] In accordance with other implementations, the security processor binding certificate 182 can be stored in a memory that is not accessed via a BMC. For example, in accordance with other implementations, data representing the certificate for security processor binding 182 can be stored in a secure memory 166 of security processor 160, and the certificate validation engine for security processor binding 136 can request the security processor binding certificate 182 from security processor 160.

[0029] According to example implementations, the security processor 160 can be a "root of trust" for storage and a "root of trust" for reporting for the computer platform 100. In this context, a "root-of-trust device" or "RoT device" can be a device that behaves in an expected manner, as any misbehavior of the RoT device might not be detected. In other words, the RoT device can be inherently trusted software, hardware, or a combination of both. An RoT device can contain compute units. The compute engine can be software that works with hardware in the RoT device, hardware of the RoT device itself, or a combination of both. For example, an RoT device can contain a Root of Trust for Storage (RTS). The RTS can be a compute module capable of generating an accurate summary of values.

[0030] The security processor 160, according to example implementations, can take the form of a semiconductor package (or "chip") mounted on a mainboard of the computer platform 100. The secure memory 166 of the security processor can store platform secrets 162, such as cryptographic keys, passwords, sealed cryptographic keys, certificates, public keys, private keys, etc. In addition, the secure memory 166 can store data representing measured values. The security processor 160 can be designed according to industry standards to provide hardware-based security features while resisting tampering and malicious software. According to some implementations, the security processor 160 can be a TPM (Total Platform Module).

[0031] The security processor 160 can contain one or more processing cores 164 (i.e., hardware processors, such as CPU processing cores) to perform functions for the security processor 160, such as performing trusted computational operations, generating communication session keys based on information provided by the UEFI 132 (as further described herein), determining whether an entity other than the UEFI 132 is permitted to communicate with the security processor 160 using platform key-based secure communication, and so on. In this way, the processing core(s) 164 can execute machine-executable instructions 171 stored in a memory 170 of the security processor 160 to perform these functions.In accordance with other implementations, the Security Processor 160 can perform all or some of the functions using circuitry that does not execute machine-executable instructions, such as a Field Programmable Gate Array (FPGA), a Complex Programmable Logic Device (CPLD), or an Application Specific Integrated Circuit (ASIC).

[0032] In accordance with other implementations, the Security Processor 160 can be a virtual security processor formed by the execution of software or firmware. In some implementations, for example, the Security Processor 160 can be a virtual TPM (or "vTPM") that may be provided by a hypervisor or another entity of the Computer Platform 100.

[0033] According to example implementations, the system memory 114, the non-volatile memory 180, and the secure memory 166 are non-transient storage media that can be formed from semiconductor storage devices, memristor-based storage devices, magnetic storage devices, phase-change storage devices, a combination of devices from one or more of these storage technologies, etc. The system memory 114 can consist of both volatile and non-volatile storage devices.

[0034] Among other features, the computer platform 100, in accordance with example implementations, can include a bus infrastructure, I / O devices, etc. According to example implementations, the bus infrastructure can include one or more bridges 118 that can be connected to the main processing cores 110, the system memory 114, the PCle devices 105, the BMC 123, and the security processor 160 to establish communication between these components. In accordance with some implementations, the main processing cores 110 can contain one or more semiconductor packages (or "chips"), and the main processing core 110 can include a north bridge 118 that comprises a memory controller (for accessing the system memory 114) and PCle root ports.The Computer Platform 100 can also include a South Bridge 118, which provides I / O ports such as Serial Advanced Technology Attachment (SATA) ports, Universal Serial Bus (USB) ports, Low Pin Count (LPC) ports, SPI ports, eSPI ports, and so on. According to some implementations, the North Bridge 118 can be part of the main processing cores 110. According to other implementations, the North and South Bridges can be combined into a single Bridge 118; and according to some implementations, this single Bridge 118 can be part of the main processing cores 110.

[0035] Fig. Figure 2 shows a process 200 through the UEFI 132 for validating the security processor binding certificate 182 and for communicating with the security processor 160 according to a sample implementation. Referring to Fig. 2 in conjunction with Fig. Process 200 includes the UEFI 132 Security Processor Binding Certificate Validation Engine 136, which accesses the Security Processor Binding Certificate 182 according to Block 204. In accordance with example implementations, the Security Processor Binding Certificate Validation Engine 136 validates the Security Processor Binding Certificate 182. This validation, according to example implementations, consists of two parts: a first part in which the Security Processor Binding Certificate Validation Engine 136 validates the Security Processor Binding Certificate 182 based on the chain of trust associated with the certificate 182, and a second part in which the Security Processor Binding Certificate Validation Engine 136 validates the binding information 188.

[0036] Regarding the first part of the validation, the validation engine 136 of the security processor for binding certificates determines, according to process 200 (decision block 208), whether the binding certificate 182 of the security processor is signed by the issuer 190 of certificate 182. In this context, the certificate 182 binding the security processor identifies the issuer 190 of certificate 182 and contains a signature 184 of the issuer. The issuer can be an intermediate certificate 194 or the root certificate 134 of the platform key.To determine whether the security processor binding certificate 182 was signed by issuer 190, the security processor binding certificate validation engine 136 can, for example, obtain a hash of the contents of the security processor binding certificate 182, decrypt the signature 184 using issuer 190's public key, and compare the decrypted signature with the hash to determine whether these values ​​match (i.e., validation is successful) or do not match (i.e., validation fails). If, according to decision block 208, the security processor binding certificate validation engine 136 determines that the security processor binding certificate 182 was not signed by issuer 190, then the validation fails, and the validation failure is logged according to block 216.

[0037] If the binding certificate validation engine of security processor 136 determines, according to decision block 208, that the binding certificate of security processor 182 was signed by issuer 190, and if issuer 190 is the root certificate of platform key 134 (decision block 212), then the signature-based validation is complete. If the binding certificate validation engine of security processor 136 determines, according to decision block 212, that issuer 190 is not the root certificate of platform key 134, then the binding certificate validation engine of security processor 136 (decision block 216) determines whether to validate the remaining certificate(s) in the chain of trust. In this way, the binding certificate validation engine of security processor 136 can validate the signature of the certificate for each intermediate certificate.If the security processor validating the certificate determines, according to decision block 216, that the chain of trust has not been validated, i.e., the validation has failed, then the security processor validating the certificate logs the validation failure according to block 220.

[0038] Starting with decision block 224, the security processor binding certificate validation engine 136 performs the second part of the validation, in which engine 136 determines whether the binding information 188 matches the platform manifest 111. As in Fig. As shown in Figure 1, the platform manifest 111, for example, can be stored in a memory location of the computer platform, such as system memory 114, and represent an inventory of selected hardware and / or software components of the computer platform 100, a model of the computer platform 100, a serial number of the computer platform 100, and so on. If the inventory represented by the manifest 111 matches the inventory represented by the binding information 188, then the binding certificate 182 of the security processor passes validation, according to example implementations. In accordance with some implementations, the security processor binding certificate validation machine 136 compares the two inventories by comparing a hash of the binding information 188 with a hash of the manifest 111. If the two hashes match, the validation, according to example implementations, is successful.Otherwise, validation will fail, and UEFI 132 will log the validation error according to block 228.

[0039] According to block 232, after validation of the binding certificate 182 of the security processor, the UEFI 132 can proceed with communication with the security processor 160 using a salt communication session that uses the asymmetric platform key pair to distribute the session key, as described here.

[0040] In the context used here, a "hash" (also referred to as a "hash value") is generated by applying a cryptographic hash function to a value (e.g., an input such as an image). A cryptographic hash function can be a function provided by a processor (e.g., one or more central processing units (CPUs), one or more CPU cores, etc.) executing machine-readable instructions. The cryptographic hash function can receive an input and then generate a hexadecimal string corresponding to that input. The input might, for example, contain a data string (e.g., the data structure in memory characterized by a start and end memory address). In such an example, the cryptographic hash function outputs a hexadecimal string based on the data string.Furthermore, even the slightest change to the input can alter the output hexadecimal sequence. In another example, the cryptographic hash function could be a Secure Hash (SHA) function, a Federal Information Processing Standards (FIPS) approved hash function, a National Institute of Standards and Technology (NIST) approved hash function, or another cryptographic hash function. In some examples, a different format for the string might be used instead of a hexadecimal format.

[0041] Fig. Figure 3 is a representation of the binding information 188 according to an exemplary embodiment. In this example, the binding information 188 comprises specifically formatted fields 300 (in Fig. Figure 1 shows the P example fields 300-1 to 300-P, where each field 300 is intended to identify information corresponding to a specific component. For example, field 300-1 might be for data representing a serial number of computer platform 100, and another field 300-2 might be specifically for data representing a model identifier for computer platform 100. Another field (e.g., field 300-3 or field 300-N) might be a hardware identifier for a serial number of a specific type or category of hardware component. As yet another example, another field (e.g., field 300-N+2 or field 300-P) might be for a specific hash value or version number of a specific software component (e.g., a bootloader, an operating system, etc.).If a particular computer platform lacks a hardware or software component for a specific field 300 of the binding information 188, certain data indicating the absence of the component is entered into the field, in accordance with example implementations. Similarly, when creating the manifest 111, UEFI 132 adheres to the specifically designated fields 300 of the binding information 188, as per example implementations. Thus, the manifest 111 should be identical to the binding information 188, in accordance with example implementations, if the security processor 160 was specifically provided by the manufacturer for the specific computer platform 100.

[0042] Fig. Figure 4 shows a process 400, which is used by the UEFI 132's communication engine 138 to establish and use a secure communication session to communicate with the security processor 160, in accordance with example implementations. With reference to Fig. 4 in conjunction with Fig. In process 400, the communication engine 138 generates a salt (block 404). According to one example implementation, the communication engine 138 may contain a pseudorandom or random number generator to generate the salt. In this context, a "pseudorandom number" can be a near-random number, and in accordance with example implementations, the communication engine 138 may contain a pseudorandom number generator. For example, the pseudorandom number generator may be a seed-based generator that outputs a pseudorandom number. According to some implementations, the communication engine 138 may, for example, contain a polynomial-based pseudorandom number generator that outputs a pseudorandom number based on a seed value that serves as input to a polynomial function.The seed value can be derived, for example, from a state or condition at the time the pseudorandom number is to be generated, such as a real-time clock (RTC) value, a counter value, a measured noise value, a register value, and so on. In accordance with other example implementations, the Communications Module 138 can use a true random number generator. This type of generator provides an output that represents a true random number. A true random number generator might, for example, include an analog-to-digital converter (ADC) that provides a digital random output, and the ADC might sample a true analog random signal, such as a thermal noise signal (a Johnson-Nyquist noise signal supplied, for example, by a resistor, or an atmospheric noise signal received by an antenna).

[0043] According to block 408 of procedure 400, the communication module 138 encrypts the generated salt with the platform's public key 186 and generates (block 412) a symmetric session key using a key generation algorithm and the salt as input for the algorithm. The communication module 138 then transmits (block 416) the encrypted salt to the security processor 160. It is noted that the security processor 160 can decrypt the salt using the platform's asymmetric key pair's private key and use the salt as input for the same key generation algorithm to generate the same session key for the security processor 160.Since the communication machine 138 and the security processor 160 possess the session key, the session key can then be used for cryptographic communication of commands and responses between the UEFI 132 and the security processor 160 according to block 420.

[0044] Fig. Figure 5 shows a process 500 used by the security processor 160 to monitor or control the availability of the platform key for cryptographic communication with the security processor 160. This allows instances other than the UEFI 132, such as an application 139 ( Fig. 1) or an operating system 130 ( Fig. 1) the computer platform 100 uses the platform key-based secure communication described here to communicate with the security processor 160 when authorized by a policy 165 ( Fig. 1) is approved. In this way, according to example implementations, the private platform key can be used by the UEFI 132 without restrictions, while the security processor 160 can allow the operating system 130 and applications 139 to use the private platform key if these entities are granted access to the security processor 160 on behalf of the owner of the computer platform 100 (i.e., using endorsement hierarchy authorization). Furthermore, according to example implementations, another delegation policy can be used if the owner wishes to authorize the use of the private platform key without disclosing the owner's authorization authority.

[0045] Referring to Fig. 5 in conjunction with Fig. In process 500, security processor 160 receives a request to establish an encrypted communication session (block 504), where the request contains an ownership token and an encrypted salt. The ownership token can, in turn, be an index for authorization policy 165, which controls the use of security processor 160 based on the ownership token. According to block 508, security processor 160 checks whether authorization policy 165 permits access to security processor 160. If access is permitted according to decision block 512, security processor 160 responds (block 516) by granting access to security processor 160, decrypts (block 520) the encrypted salt based on the private platform key 168, and communicates (block 524) with the entity using a secure communication session, as described herein.Otherwise, if access to security processor 160 is denied according to decision block 512, security processor 160 (block 526) responds by denying the request for access to security processor 160.

[0046] Other embodiments are also conceivable that fall within the scope of the appended claims. For example, a computer platform in accordance with further implementations may have a different architecture than that described in Fig. 1. For example, according to another implementation, a computer platform may not contain a BMC. Another example is that, according to another implementation, a computer platform may have a BMC, but certificate-related content (e.g., a security processor binding certificate, intermediate certificates, etc.) may be stored in a memory or storage facility that is not behind the BMC. As yet another example, according to another implementation, a computer platform may have a BMC, and certain content (e.g., a UEFI image) may be stored in a memory that is behind a BMC, while other content (e.g., certificate content) may be stored in a memory or storage facility that is not behind a BMC.As another example, according to yet another implementation, a computer platform can have a management controller other than a BMC, such as a platform controller or a chassis management controller. According to yet another implementation, the computer platform can be something other than a server, such as a client, a desktop, a smartphone, a laptop, a network component, a gateway, a network switch, a storage array, a portable electronic device, a laptop, a tablet computer, a thin client, a laptop computer, a television, a modular switch, a consumer electronics device, an edge processing system, a sensor system, a clock, a removable peripheral card, and so on.

[0047] As in Fig. As shown in Figure 6, a computer platform 600, according to example implementations, comprises a security processor 604, at least one hardware processor 612, and a memory 630. The security processor 604 stores data representing a private platform key 608. The private platform key 608 is part of an asymmetric key pair, and the asymmetric key pair includes a public platform key 620. The memory 630 stores a firmware image 634. The firmware image 634 contains data representing a root certificate 638 of a public key infrastructure that signs a certificate 616 associated with the computer platform 600. The certificate 616 contains the public platform key 620 and binding information 624 that binds the certificate 616 to the computer platform 600.Firmware image 634 contains instructions 642 which, when executed by the hardware processor(s) 612, cause the hardware processor(s) 612 to access data representing certificate 616 and, based on the root certificate 638 and the binding information 624, to determine whether certificate 616 is valid. Furthermore, when executed by the hardware processor(s) 612, the instructions 642 cause the hardware processor(s) 612, in response to the finding that certificate 616 is valid, to use the public platform key 620 to secure communication with the security processor 604.

[0048] Referring to Fig. Section 7, in accordance with example implementations, involves a process (block 704) of accessing data representing a public-key root certificate of an infrastructure, corresponding to a second certificate, by at least one hardware processor of a computer platform. The second certificate contains a public platform key, and the public platform key is part of an asymmetric key pair that includes a private platform key. The second certificate contains binding information that binds the computer platform to the second certificate. Process 700 involves the determination (block 708) by the hardware processor(s) of whether the second certificate is valid, based on the root certificate and the binding information.According to block 712, in response to the finding that the second certificate is valid, process 700 includes the use of the platform public key by the hardware processor(s) to establish a secure communication session with a computer platform security processor. According to block 716, process 700 includes the communication of data to the security processor by the hardware processor(s) using the secure communication session.

[0049] Referring to Fig.8 stores machine-executable instructions 804 on a non-transitory machine-readable storage medium 800 according to example implementations. These instructions, when executed by a machine, cause the machine to validate the signature of a second certificate based on data representing a root certificate stored on the machine. The instructions 804, when executed by the machine, also cause the machine to validate binding information of the second certificate. The binding information represents a first inventory of the machine. The validation of the binding information involves comparing a second inventory of the machine with the first inventory.Furthermore, when executed by the machine, instructions 804 cause the machine, in response to the signature validation, which yields a result that the signature is valid, and the binding information validation, which yields a result that the binding information is valid, to establish a secure communication session with a security processor of the machine using a public platform key from the second certificate.

[0050] In accordance with example implementations, the binding information includes initial data corresponding to a first inventory of the computer platform. The instructions, when executed by the hardware processor(s), also cause the hardware processor(s) to generate second data representing a second inventory of the computer platform. Furthermore, the instructions cause the hardware processor(s), when executed, to validate the second certificate based on a comparison of the second data with the first. A particular advantage is that an asymmetric key pair for a platform can be bound to a specific computer platform.

[0051] In accordance with example implementations, the first data set comprises a first hash of data representing the first inventory, and the second data set comprises a second hash of data representing the second inventory. The instructions, when executed by the hardware processor(s), further instruct the hardware processor(s) to determine whether the second hash is identical to the first. A particular advantage is that an asymmetric key pair can be bound to a specific computer platform.

[0052] In accordance with example implementations, the binding information includes at least one of the following: a model number of the computer platform, a serial number of the computer platform, an identifier of a hardware component of the computer platform, or an identifier of a software component of the computer platform. A particular advantage is that an asymmetric key pair can be bound to a specific computer platform.

[0053] According to example implementations, when executed by the hardware processor(s), the instructions further cause the hardware processor(s) to generate a salt; to generate a session key based on the salt; and to encrypt the salt based on the platform's public key to provide an encrypted salt. The instructions, when executed by the hardware processor(s), further cause the hardware processor to transmit the encrypted salt to the security processor and use the session key in a communication session with the security processor. A particular advantage is that an asymmetric key pair can be bound to a specific computer platform.

[0054] In accordance with example implementations, when executed by the hardware processor(s), the instructions also cause the hardware processor(s) to provide pre-boot and post-boot environment services for the computer platform. A particular advantage is that communication between the platform firmware and a security processor can be secured.

[0055] In accordance with example implementations, the memory also stores other instructions associated with an operating system or application of the computer platform. The hardware processor(s) execute(s) these other instructions to instruct the hardware processor(s) to use the public platform key to secure communication with the security processor. A particular advantage is that communication between the operating system or application and the security processor can be secure.

[0056] Although the present disclosure has been described with respect to a limited number of implementations, those skilled in the art who have the advantages of this disclosure will appreciate numerous modifications and variations thereof. It is intended that the appended claims cover all such modifications and variations.

Claims

[1] A computer platform (100; 600) comprising the following: a security processor (160; 604) for storing data representing a private platform key (168; 608), wherein the private platform key (168; 608) is part of an asymmetric key pair and the asymmetric key pair includes a public platform key (186; 620); at least one hardware processor (164; 612); and a memory (180; 630) for storing a firmware image (196; 634), wherein: the firmware image (196; 634) includes data representing a root certificate (638) of a public key infrastructure that signs a second certificate (182; 616) associated with the platform (100; 600); the second certificate (182; 616) contains the public platform key (186; 620) and binding information (188; 624) that binds the second certificate (182; 616) to the platform (100; 600), wherein the binding information (188; 624) includes at least one of the following elements: a model number of the computer platform (100; 600), a serial number of the computer platform (100; 600), an identifier of a hardware component of the computer platform (100; 600), or an identifier of a software component of the computer platform (100; 600); and the firmware image (196; 634) corresponds to platform firmware and includes instructions (642) which, when executed by the at least one hardware processor (164; 612), cause the at least one hardware processor (164; 612) to: access data representing the second certificate (182; 616); to determine whether the second certificate (182; 616) is valid, based on the root certificate (638) and the binding information (188; 624), wherein the binding information (188; 624) is compared with a platform manifest (111) which is determined for the computer platform (100; 600) when the computer platform (100; 600) is booted, and the second certificate (182; 616) is determined to be valid only if the binding information (188; 624) matches the platform manifest (111); in response to the finding that the second certificate (182; 616) is valid, to generate a session key; and to distribute the session key to the security processor (160; 604), wherein the distribution includes communicating content to the security processor (160; 604), and wherein the content is encrypted with the public platform key (186; 620) and is related to the session key; and in conjunction with a session between the platform firmware and the security processor (160; 604), to communicate with the security processor (160; 604) data that is encrypted by the session key. [2] Computer platform (100; 600) according to claim 1, wherein: the binding information (188; 624) includes initial data corresponding to an initial inventory of the computer platform (100; 600); and the instructions, when executed by the at least one hardware processor (164; 612), also cause the at least one hardware processor (164; 612) to generate second data, which represents a second inventory of the computer platform (100; 600), and to validate the second certificate (182; 616) based on a comparison of the second data with the first data. [3] Computer platform (100; 600) according to claim 2, wherein: the first data includes an initial hash of data representing the first inventory; the second data includes a second hash of data representing the second inventory; and the instructions, when executed by the at least one hardware processor (164; 612), also cause the at least one hardware processor (164; 612) to determine whether the second hash is identical to the first hash. [4] Computer platform (100; 600) according to claim 1, wherein the instructions (642), when executed by the at least one hardware processor (164; 612), further cause the at least one hardware processor (164; 612) to: to create a salt; to generate the session key based on the salt; to encrypt the salt based on the public platform key (186; 620) to obtain an encrypted salt; and where distributing the session key includes transmitting the encrypted salt to the security processor (160; 604). [5] Computer platform (100; 600) according to claim 1, wherein the instructions (642), when executed by the at least one hardware processor (164; 612), further cause the at least one hardware processor (164; 612) to provide pre-boot environment services and post-boot environment services for the computer platform (100; 600). [6] Computer platform (100; 600) according to claim 5, wherein: the memory (180; 630) is designed to store further instructions associated with an operating system or application of the computer platform (100; 600); and the at least one hardware processor (164; 612) is configured to execute the other instructions which cause the at least one hardware processor (164; 612) to use the public platform key (186; 620) to secure communication with the security processor (160; 604). [7] Computer platform (100; 600) according to claim 6, wherein: the further instructions, when executed by the at least one hardware processor (164; 612), further cause the at least one hardware processor (164; 612) to transmit a request for a secure communication session to the security processor (160; 604), the request including an ownership token; and The security processor (160; 604) determines whether the secure communication session should be allowed, based on the ownership token and an authorization policy. [8] Computer platform (100; 600) according to claim 1, wherein: the instructions (642), when executed by the at least one hardware processor (164; 612), further cause the at least one hardware processor (164; 612) to submit a request for a secure communication session to the security processor (160; 604), the request including an ownership token; and The security processor (160; 604) determines whether the secure communication session should be allowed, based on the ownership token and an authorization policy. [9] Computer platform (100; 600) according to claim 1, wherein the instructions (642), when executed by the at least one hardware processor (164; 612), further cause the at least one hardware processor (164; 612) to: Establish a secure communication session with the security processor (160; 604) using the public platform key (186; 620); and in the secure communication session, transmission of data that constitutes a secret of the computer platform (100; 600) to the security processor (160; 604). [10] Computer platform 8100) according to claim 1, wherein the security processor (160; 604) comprises a trusted platform module. [11] A procedure comprising the following: Accessing data representing a root certificate (638) of a public-key infrastructure corresponding to a second certificate (182; 616) by at least one hardware processor (164; 612) of a computer platform (100; 600), wherein the second certificate (182; 616) includes a public platform key (186; 620), the public platform key (186; 620) is part of an asymmetric key pair, the asymmetric key pair includes a private platform key (168; 608), and the second certificate (182; 616) includes binding information (188; 624) that binds the computer platform (100; 600) to the second certificate (182; 616). wherein the binding information (188; 624) includes at least one of the following elements: a model number of the computer platform (100; 600), a serial number of the computer platform (100; 600), an identifier of a hardware component of the computer platform (100; 600) or an identifier of a software component of the computer platform (100; 600); Determine, by means of at least one hardware processor (164; 612), whether the second certificate (182; 616) is valid, based on the root certificate (638) and the binding information (188; 624), wherein the binding information (188; 624) is compared with a platform manifest (111) which is determined for the computer platform (100; 600) when the computer platform (100; 600) is booted, and the second certificate (182; 616) is determined to be valid only if the binding information (188; 624) matches the platform manifest (111); in response to the finding that the second certificate (182; 616) is valid, the at least one hardware processor (164; 612) uses the public platform key (186; 620) to establish a secure communication session between a requester of a security service and a security processor (160; 604) of the computer platform (100; 600) providing the security service, wherein establishing the secure communication session includes generating a session key for the secure communication session and distributing the session key to the security processor (160; 604); and Communication, in the secure communication session, of encrypted data between the requester and the security processor (160; 604), wherein the encrypted data includes data encrypted by the session key. [12] The method of claim 11, further comprising: Transmitting a request to establish a secure communication session with the security processor (160; 604) by the at least one hardware processor (164; 612), wherein the request is associated with an ownership token; and Determine, through the security processor (160; 604), whether the communication session should be allowed based on the application of an ownership policy to the ownership token. [13] The method of claim 11, further comprising: Executing platform firmware instructions to access the data representing the root certificate (638), to determine if the second certificate (182; 616) is valid, to use the platform public key (186; 620) to establish the secure communication session, and to communicate the data with the security processor (160; 604) using the secure communication session. [14] The method of claim 11, further comprising: Executing operating system instructions to access the data representing the root certificate (638), to determine if the second certificate (182; 616) is valid, to use the public platform key (186; 620) to establish the secure communication session, and to transmit the data to the security processor (160; 604) using the secure communication session. [15] The method of claim 11, further comprising: Storing a firmware image (196; 634) in non-volatile memory (180; 630) of the computer platform (100; 600), wherein the firmware image (196; 634) includes the instructions (642) and the root certificate (638). [16] A non-transitory, machine-readable storage medium that stores machine-executable instructions which, when executed by a computer platform (100; 600), cause the computer platform (100; 600) to: to validate a signature of a second certificate (182; 616) on the basis of data representing a root certificate (638) stored on the computer; to validate binding information (188; 624) of the second certificate (182; 616), wherein the binding information (188; 624) comprises at least one of the following: a model number of the computer platform (100; 600), a serial number of the computer platform (100; 600), an identifier of a hardware component of the computer platform (100; 600), or an identifier of a software component of the computer platform (100; 600), wherein the binding information (188; 624) represents a first inventory of the computer platform (100; 600), and the validation of the binding information (188; 624) comprises comparing a second inventory of the computer platform (100; 600) with the first inventory, wherein the binding information (188; 624) is compared with a platform manifest (111) which is generated when the computer platform (100; 600) is intended for the computer platform (100; 600), and the second certificate (182;616) is only determined to be valid if the binding information (188; 624) matches the platform manifest (111); and; as a response to the validation of the signature, which produces a result that the signature is valid, and the validation of the binding information (188; 624), which produces a result that the binding information (188; 624) is valid, to establish a secure communication session between a requester of a security service and a security processor (160; 604) of the computer platform (100; 600) providing the service, wherein the establishment of the secure communication session includes generating a session key for the secure communication session and distributing the session key to the security processor (160; 604), and wherein data communicated between the requester and the security processor (160; 604) in the secure communication session are encrypted by the session key. [17] The storage medium according to claim 16, wherein the instructions, when executed by the computer platform (100; 600), also cause the computer platform (100; 600) to: to create a salt; to generate the session key based on the salt; to encrypt the salt based on a public platform key (186; 620) of the second certificate (182; 616) to obtain an encrypted salt; and where distributing the session key includes transmitting the encrypted salt to the security processor (160; 604). [18] The storage medium according to claim 16, wherein the instructions are associated with at least one pre-boot firmware service or one post-boot firmware service.

Images