Abstract: Systems and methods include an IHS (Information Handling System) that is a member of a computing cluster and that is configured to participate in collective management of the cluster, including generating a unique identifier for collective use and identification of the cluster. Cluster management functions of the IHS are configured to determine when the addition of another IHS as a member of the computing cluster requires an update to a cluster identifier that is used to task the computing cluster. When an update to the cluster identifier is required, the cluster management functions generate an updated cluster identifier that is amalgamation of identifiers of each member of the computing cluster and the updated cluster identity is transmitted to cluster members.

Abstract: Methods and system are provided for virtualizing root of trust (ROT) to serve devices that do not have built-in ROT functionality. A component of a computer system may provide root of trust functionality for the computer system generally. That component may also provide virtualized ROT functionality for a non-ROT component by generating a symmetric encryption key and an asymmetric encryption key pair using a unique identifier of the non-ROT component. The virtual ROT functionality may handle storage of the encryption keys as well as an ID certificate for the non-ROT component. Furthermore, the virtual ROT functionality may be configured to write encrypted data to an internal memory of the non-ROT component, read and decrypt that data, and write back further encrypted data.

Abstract: Systems and methods are provided for collective management of a computing cluster. Cluster management functions are implemented by a first IHS (Information Handling System) that is a member of the computing cluster. An indication is received of a second IHS that is added to the computing cluster. The identity of the second IHS is validated and cluster management functions determine when the addition of the second IHS to the computing cluster requires an update to a cluster identifier that is used to task the computing cluster. When an update to the cluster identifier is required, an updated cluster identifier is generated. Based on the validated identity of the second IHS, a secure communication channel is established for transmission of the updated cluster identifier to the second IHS.

Abstract: Systems and methods include Information Handling Systems (IHSs) that include one or more HPMs (Host Processor Modules), each comprising one or more CPLDs (Complex Programmable Logic Devices). Each CPLD is operated through execution of firmware, and is identified by unique hardware identifiers, and is operated using configurable settings. Each of the CPLDs is configured to transmit a bitstream of the firmware to a DC-SCM while loading the firmware for execution. The DC-SCM (Data Center Secure Control Module) determines whether the signed bitstream transmitted by each of the CPLDs matches a golden firmware measurement maintained for each respective CPLD. The DC-SCM also determines whether the unique identifiers of each of the CPLDs matches a golden hardware identity measurement maintained for each respective CPLD. The DC-SCM also determines whether the configurable settings in use by each of the CPLDs matches a golden configuration settings measurement maintained for each respective CPLD.

Abstract: An LCS trust system includes resource devices including respective resource device pTPMs, and an SCP device including an SCP device pTPM and providing a resource management system with a resource management system vTPM. The resource management system uses the resource management system vTPM to establish a first trust relationship with the SCP device via the SCP device pTPM, and respective second trust relationships with each of the resource devices via their respective resource device pTPMs. The resource management system the uses a subset of the resource devices to provide an LCS that includes an LCS vTPM and that uses the LCS vTPM to establish a respective third trust relationship with each of the subset of the resource devices via their respective resource device pTPMs. As such, a chain of trust is provided for the LCS that is based at least upon the first, respective second, and respective third trust relationships.

Abstract: In drift detection for complex IHS platforms comprised of replaceable components an IHS a security processor may present a number of hieratical sets of Platform Configuration Registers (PCRs) as Virtualized PCR Engines (VPEs) corresponding to IHS platform hardware, sub-domains, and/or central processing units. An IHS aggregation engine may collect measure(s) of platform components, populate the PCRs of the VPEs, and maintain a platform-level VPE and PCR event log from sub-domains of the platform. The measure(s) may be collected indirectly from component Security Protocols and Data Models (SPDM) and/or directly over Management Component Transport Protocol (MCTP), Inter-Integrated Circuit (I2C), Peripheral Component Interconnect Express (PCIe) and/or via Serial Peripheral Interconnect (SPI). The measure(s) may include vendor certificate authority (CA) certificates for feeding into the PCRs.

Abstract: Systems and methods for mutual trust establishment among components of an Information Handling System (IHS) are described. In an illustrative, non-limiting embodiment, an IHS may include: at least one processor; and at least one memory coupled to the processor, wherein the at least one memory comprises program instructions stored thereon that, upon execution by the at least one processor, cause the at least one processor to: obtain a plurality of identifiers for a respective plurality of CPLDs or FPGAs, including an identifier for a first CPLD or FPGA; and provide to a second CPLD or FPGA an expected handshake token for the first CPLD or FPGA, wherein the expected handshake token is based, at least in part, on the identifier for the first CPLD or FPGA, and wherein the second CPLD or FPGA uses the expected handshake token to establish trust for communication with the first CPLD or FPGA.

Abstract: Methods and system are provided for establishing and using a uniform device identity. For instance, an information handling system (IHS) may include multiple hardware components, each of the hardware components having a respective device identity. A device identity selector may be set, either at manufacture or by a trusted downstream partner, where the device identity selector identifies one of the device identities for use by the IHS. As remote nodes or applications perform attestation operations, the IHS may use the selected device identity for attestation.

Abstract: Systems and methods for secure modular hardware binding in a Data Center Modular Hardware System (DC-SCM) environment are described herein. According to one embodiment, an Information Handling System (IHS) includes multiple Complex Programmable Logic Devices (CPLDs), and computer-executable logic to, for each of the CPLDs: store an encrypted secret key in a platform Root-of-Trust (ROT) and the CPLD, and receive, by the platform ROT, a request to authenticate a firmware stack installed on the CPLD. The logic may then present, by the CPLD, an encrypted secret key to the platform ROT, authenticate, by the platform ROT, the firmware stack by comparing the encrypted secret key received from the CPLD with its stored version of the encrypted secret key, and allow operation of the CPLD based on the authentication.

Abstract: Systems and methods for cryptographic algorithm identity certificate selection in an Information Handling System (IHS) are described. In one embodiment, an IHS includes a processor, and a memory coupled to the processor. The memory stores program instructions that, upon execution, cause the processor to receive a Certificate Signing Request (CSR) from a server, sign the CSR with a first Cryptographic Algorithm Identity (CAI) key stored in the memory, and send the signed CSR to the server. The server is configured to identify a geographical region that is associated with the first CAI key, identify an approved cryptographic algorithm that is approved for use in the identified region, and send a second CAI key associated with the identified approved cryptographic algorithm. When the IHS receives the second CAI key from the server, it may perform a cryptographic operation using a cryptographic algorithm associated with the second CAI key.

Abstract: Techniques are provided for identity-based verification of software code layers. One method comprises obtaining, by a current layer of software code executing on a security processor of a security sub-system, in connection with a boot of the security sub-system, an identity key of the current layer, wherein the identity key of the current layer is based on a value generated during a provisioning of the security sub-system, wherein the value is based on a firmware image of at least one layer of the software code; obtaining an encrypted secure boot public key of a next layer; decrypting the encrypted secure boot public key of the next layer using the obtained identity key of the current layer; verifying the next layer using the decrypted secure boot public key of the next layer; and executing the next layer based at least in part on a result of the verifying.

Abstract: Techniques are provided for provisioning multiple platform root of trust (PRoT) entities using role-based identity certificates. One method comprises obtaining a designation of a PRoT entity of a hardware device as a PRoT leader associated with a leader role; recording the leader role as a role attribute in an identity certificate; and providing the identity certificate to the hardware device during a provisioning of the hardware device, wherein the given PRoT entity assumes the leader role of the hardware device and initiates security actions of the PRoT leader upon an initiation of the hardware device. Leader responsibilities can be assigned to the PRoT leader and the one or more leader responsibilities of the PRoT leader may be recorded as a leader responsibility attribute in the identity certificate.

Abstract: An Information Handling System (IHS) includes multiple hardware devices, and a baseboard Management Controller (BMC) in communication with the plurality of hardware devices. The BMC includes instructions for executing a first BMC firmware stack that uses certain data for its operation. The data used by the first BMC firmware stack is stored in a first memory location. The instructions are further configured to halt execution of the first BMC firmware stack, and begin execution of a second BMC firmware stack by copying the data from the first memory location to a second memory location used by the second BMC firmware stack.

Abstract: In drift detection for complex IHS platforms comprised of replaceable components an IHS a security processor may present a number of hieratical sets of Platform Configuration Registers (PCRs) as Virtualized PCR Engines (VPEs) corresponding to IHS platform hardware, sub-domains, and/or central processing units. An IHS aggregation engine may collect measure(s) of platform components, populate the PCRs of the VPEs, and maintain a platform-level VPE and PCR event log from sub-domains of the platform. The measure(s) may be collected indirectly from component Security Protocols and Data Models (SPDM) and/or directly over Management Component Transport Protocol (MCTP), Inter-Integrated Circuit (I2C), Peripheral Component Interconnect Express (PCIe) and/or via Serial Peripheral Interconnect (SPI). The measure(s) may include vendor certificate authority (CA) certificates for feeding into the PCRs.

Abstract: Systems and methods for producing, using, and managing Compounded Intrinsic Identities (CIIS) for Information Handling Systems (IHSs) are described. In an illustrative, non-limiting embodiment, an IHS may include a processor and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution by the processor, cause the IHS to: receive a first indication of a first variable associated with a unique physical or electrical aspect of a first IHS component, receive a second indication of a second variable associated with a unique physical or electrical aspect of a second IHS component, and produce at least one identity seed associated with the IHS based, at least in part, upon a combination of the first and second indications.

Abstract: Systems and methods for factory management of regional cryptographic algorithms in an Information Handling System (IHS) are described. In an embodiment, an IHS may include: a host processor; a security processor coupled to the host processor; and a memory coupled to the security processor, the memory having program instructions stored thereon that, upon execution, cause the security processor to: generate a Cryptographic Algorithm Identity (CAI) key pair comprising a CAI public key and a CAI private key; issue a CAI Certificate Signing Request (CSR) to a factory IHS, where the CAI CSR comprises the CAI public key; receive a signed CAI certificate from the factory IHS, where the signed CAI certificate is usable to activate a selected set of regional cryptographic algorithms among a superset of regional cryptographic algorithms stored, during manufacturing of the IHS, in a firmware of the security processor; and store the signed CAI certificate.

Abstract: Embodiments of systems and methods to provide multi-party authorized secure boot authentication are disclosed. In an illustrative, non-limiting embodiment, a processing device may include computer-executable instructions to, during a boot process of the processing device, identify two or more secure boot keys that may be used to authorize, using an authentication process, an ensuing phase of the boot process, identify a subset of the secure boot keys that are to be used to perform the authentication process, and using each of the subset of secure boot keys, perform the authentication process.

Abstract: Embodiments of systems and methods to provide a firmware update to devices configured in a redundant configuration in an Information Handling System (IHS) are disclosed. In an illustrative, non-limiting embodiment, an IHS may include a Baseboard Management Controller (BMC) having computer-executable instructions to, during a boot sequence of the BMC, determine a type of a firmware that is to be booted on the BMC, and selectively restrict access to the resources based upon the determined type of firmware.

Abstract: Systems and methods provide validation of hardware components of an IHS (Information Handling System). An attestation certificate stored to the IHS specifies authenticated instructions for operation of a hardware component of the IHS. This attestation certificate is endorsed by a self-signed root attestation certificate. An identity certificate, also stored to the IHS, specifies an identity of the hardware component and is endorsed using an embedded keypair of the hardware component. The root attestation certificate is validated to ensure it corresponds to the hardware component specified in the identity certificate, where this validation confirms that a public key included in the identity certificate is identical to a public key included in the attestation certificate.

Abstract: Embodiments of systems and methods for indicating a type of secure boot to endpoint devices by a security processor are described. In some embodiments, a security processor may include: a core and a memory coupled to the core, the memory having program instructions stored thereon that, upon execution by the core, cause the security processor to: identify a type of secure boot last performed to bootstrap an Information Handling System (IHS); and make an indication of the type of secure boot available to a host processor or Baseboard Management Controller (BMC) of the IHS.