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.

Abstract: Systems and methods are provided for validating components of an Information Handling System (IHS). During factory provisioning of the IHS, an owner certificate is stored that specifies an identity of a motherboard installed during manufacture of the IHS. The owner certificate is signed by a certificate authority of an owner of the IHS that retains capabilities for specifying the use of boot code provided by successive renters of the IHS. A renter certificate is also stored that specifies an identity of a chassis to which the motherboard is installed during manufacture of the IHS. Upon a transfer of control or ownership of the IHS, boot code operations by the security processor identify a motherboard and chassis in use by the IHS and utilize the motherboard and chassis certificates to validate that the identified motherboard and chassis are the same motherboard and chassis installed during manufacture of the IHS.

Abstract: Techniques are provided for protecting devices having multi-port hardware components. One method comprises obtaining a configuration of a command from a user to an enabled state or a disabled state on a port (e.g., an in-band port or an out-of-band port) of a hardware component of a processing device; automatically sharing credentials of the user with a basic input/output system of the processing device using a secure channel, in response to the obtained configuration; and initiating processing of a given command from a user, associated with a particular port of the hardware component, responsive to an evaluation of the shared user credentials and the given command being in the enabled state on the particular port. Changes with respect to a current enabled state or a current disabled state of a given command may be locked or unlocked.

Abstract: Techniques are provided for dynamic transitioning among device security states based on server availability. One method comprises configuring a processing device to be in a first one of multiple security states, wherein the first security state comprises user authentication factors administered by one or more servers; transitioning the processing device to a different security state, in response to detecting a change in an availability status of a given one of the servers, wherein the different security state comprises a different user authentication factor administered by a different server than the given server; and initiating processing of a user request to perform a privileged action based on a result of an authentication performed using the different user authentication factor of the different security state. The first state and the different state may be associated with a different stage of a product lifecycle and/or with a different designated threat level.

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: 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 security key integrity verification using inventory certificates. One method comprises receiving a user request to perform an action: obtaining an inventory certificate associated with a device; extracting a security key identifier from a security key corresponding to the device; validating the security key by comparing the extracted security key identifier to a security key identifier in the inventory certificate; and authorizing a performance of the action based on a result of the comparison. A validity of the inventory certificate may be evaluated (e.g., by evaluating a signature associated with the inventory certificate). The inventory certificate may be stored in a secure memory of the device prior to a delivery of the device to a purchaser of the device.

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: 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 a first processor configured to execute a custom BMC firmware stack, and a second processor including executable instructions for receiving a request to perform a test on the first processor in which the request is received through a secure communication session established with a remote IHS. The instructions further perform the acts of controlling the first processor to perform the test according to the request, the first processor generating test results associated with the test, and transmitting the test results to the remote IHS through the secure communication session.

Abstract: A method for dynamic immutable security personalization for enterprise products. Specifically, the disclosed method describes how a computer processor (e.g., baseboard management controller) of an enterprise product can personalize security requirements in trusted facilities, along the supply chain route of the enterprise product, so that trusted assumptions concerning the enterprise product can be made. Further, through dynamic immutable security personalization, these trusted assumptions are allowed to change over time (e.g., from being less restrictive to more restrictive) as changing enterprise product configuration states are captured while the enterprise product traverses the supply chain route.

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: Systems and methods for securing Accounts of Last Resort (ALRs) 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 that, upon execution, cause the IHS to receive a credential from one of a plurality of users to log onto an ALR, where the credential is shared among the plurality of users, and log the user onto the ALR in response to verification of a signed digital certificate provided by the user.

Abstract: As part of a factory provisioning of an Information Handling System (IHS), a signed replaceable hardware certificate is stored that identifies any replaceable hardware components coupled to the IHS during the factory provisioning. Upon a transfer of control or ownership of the IHS, replaceable hardware components that are coupled to the IHS are detected, and the replaceable hardware certificate is utilized to validate that the identified replaceable hardware components detected as coupled to the IHS are the same replaceable hardware components coupled to the IHS during the factory provisioning. A security processor of the IHS may support boot code operations for generating additional replaceable hardware certificates that can be used to validate the integrity of any changes the replaceable hardware of the IHS, such as upon its next power cycle.

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 executable instructions for beginning execution of a first BMC firmware stack, and during execution of the first BMC firmware stack, halt execution of the first BMC firmware stack, and begin execution of a second BMC firmware stack. At least a portion of the executable instructions used to generate the first BMC firmware stack are different than the executable instructions used to generate the second BMC firmware stack.

Abstract: During factory provisioning of an Information Handling System (IHS), a key injection authorization certificate is stored that authorizes key injection by a renter of the IHS. An IHS owner retains capabilities for specifying the use of boot code of successive renters of the IHS. Upon a transfer of control or ownership of the IHS, a key injection request certificate provided by the renter is validated and use of the key injection request certificate is authorized for transferring cryptographic credentials to the IHS. The key injection authorization certificate specifies an identity of the IHS that is authorized for key injection by the renter and the key injection request certificate specifies an identity of the IHS that is requested for key injection by the renter. Transfer of credentials is authorized when the two certificates are both valid and the identity of the IHS specified in the two certificates is the same.

Abstract: As part of a factory provisioning of an Information Handling System (IHS), a configuration certificate is stored that identifies a pre-boot configuration of the IHS resulting from the factory provisioning. Upon a transfer of control or ownership of the IHS, a pre-boot configuration of the IHS is identified and the configuration certificate is utilized to validate that the identified pre-boot configuration is the same as the pre-boot configuration of the IHS resulting from the factory provisioning. A security processor of the IHS may support boot code operations for generating additional configuration certificates that can be used to validate the integrity of any changes the IHS configuration, such as upon its next power cycle.

Abstract: Embodiments of systems and methods for managing control of a security processor in a supply chain 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: store a first public key usable to initiate a first secure boot process and unusable to initiate a second secure boot process; store a second public key usable to initiate the second secure boot process and unusable to initiate the first secure boot process; and in response to a first change of control or ownership of the security processor, render the first public key unusable to initiate the first secure boot process.

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 bootloader to verify an integrity of a first firmware stack, and boot the first firmware stack on a first processor. Once booted, the first firmware stack verifies the integrity of a first code segment on a second processor that is also used to execute a custom BMC firmware stack. The first code segment is executed to verify the integrity of one or more vendor supplied code segments executed on the second processor.

Abstract: An Information Handling System (IHS) includes multiple hardware devices, and a baseboard Management Controller (BMC) in communication with multiple hardware devices of the IHS. The BMC includes executable instructions for monitoring a parameter of one or more of the hardware devices when a custom BMC firmware stack is executed on the BMC. The instructions that monitor the parameter are separate and distinct from the instructions of the custom BMC firmware stack. The instructions also control the BMC to perform one or more operations to remediate an excessive parameter when the parameter exceeds a specified threshold.