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: 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: 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 computer-executable instructions to receive a request for a secret known by the IHS, and attest the RAC by verifying that the public key exists in a manifest that is configured to store identifying information about a plurality of devices configured in the IHS. The request is signed using a private key of a first asymmetric key pair generated by a Remote Access Controller (RAC). Using a second public key of a second asymmetric key pair, the instructions encrypt the requested secret; and send the encrypted secret to the RAC, wherein the RAC is configured to use the second private key of the second asymmetric key pair to decrypt the encrypted secret.

Abstract: An information handling system includes a memory and a baseboard management controller (BMC). The memory stores a secure boot policy for multiple input/output (I/O) devices in the information handling system. The BMC extracts a new firmware hash value from a firmware update package. The new firmware hash value is associated with a new firmware image of a first I/O device of the I/O devices. The BMC performs a firmware update for the first I/O device. In response to the firmware update being successfully completed, the BMC replaces an old firmware hash value with the new firmware hash value in the secure boot policy.

Abstract: Embodiments of the present disclosure provide a system and method to scan open source code files to alleviate illicit changes to those files. According to one embodiment, an Information Handling System (IHS) includes executable instructions to obtain an executable image having a build time symbol table that was generated when the executable image was built, compare a reference symbol table with the build time symbol table from the software image, and when the build time symbol table and the reference symbol table do not match, perform at least one remedial action. The executable image is configured to be installed on the BMC and includes at least one open source file that when built, comprises a D-Bus interface.

Abstract: Systems and procedures are provided for validating an IHS (Information Handling System) as operating using only factory-provisioned I/O ports. During factory provisioning of the IHS, a signed inventory certificate that includes an inventory of factory-provisioned I/O ports of the IHS is uploaded to the IHS. Upon delivery and initialization of the IHS, the inventory certificate is retrieved by a pre-boot validation process. An inventory of detected I/O ports of the IHS is then collected. The validation process compares the collected inventory of detected I/O ports against the inventory of factory-provisioned I/O ports from the inventory certificate in order to validate the IHS is operating using only factory-provisioned I/O ports. Through embodiments, any I/O ports of the IHS other than the I/O ports validated as factory-provisioned are not usable by any software or hardware of the IHS.

Abstract: Various embodiments provide methods for validating secure assembly and delivery of an IHS (Information Handling System) by confirming that the detected hardware components of the IHS include only factory installed hardware components. During factory provisioning of an IHS, an inventory certificate is uploaded to the IHS, where the inventory certificate includes an inventory that identifies the hardware components installed during factory assembly of the IHS. An inventory is collected of the detected hardware components of the IHS. The collected inventory is compared against the inventory from the inventory certificate in order to validate the detected hardware components of the IHS as the same hardware components that were installed during factory assembly of the IHS. Embodiments provide a customer receiving an IHS with a capability of validating that a delivered IHS includes only factory installed hardware components.

Abstract: Systems and procedures are provided for tracking hardware components of an IHS (Information Handling System). During factory provisioning of an IHS, an inventory certificate to the IHS is stored to the IHS that includes an inventory identifying factory-installed hardware components of the IHS. Also during the factory provisioning, a record is stored in a component datastore of the factory-installed hardware specified in the inventory certificate. Upon initialization of the delivered IHS, a pre-boot validation environment is initialized on the IHS and the stored inventory certificate is retrieved and used to validate the detected hardware components of the IHS. The results of the validation are then reported to a component datastore, where they are used to identify any transfer of a factory-installed hardware component. The factory datastore is updated in subsequent validations to reflect any detected modifications to the IHS in tracking genuine components.

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: Various embodiments provide methods for validating hardware modifications of an IHS (Information Handling System) by confirming that a hardware modification corresponds to a hardware component supplied for installation in the IHS by a trusted entity. During factory provisioning of an IHS, an inventory certificate that specifies the factory installed IHS hardware is uploaded to the IHS and is also stored for ongoing support of the IHS. Upon a hardware component being supplied for installation in the IHS by a trusted entity, the inventory of the stored inventory certificate is updated to identify the supplied component and the updated certificate is transmitted to the IHS. An inventory of detected hardware components of the IHS is compared against the inventory from the updated inventory certificate in order to validate the detected hardware of the IHS includes the component, supplied by the trusted entity, that is identified in the updated inventory certificate.

Abstract: Various embodiments provide methods for validating hardware modifications of an IHS (Information Handling System) by confirming that a hardware modification corresponds to a hardware component supplied for installation in the IHS by a trusted entity. During factory provisioning of an IHS, an inventory certificate that specifies the factory installed IHS hardware is uploaded to the IHS and is also stored for ongoing support of the IHS. Upon a hardware component being supplied for installation in the IHS by a trusted entity, the inventory of the stored inventory certificate is updated to identify the supplied component and the updated certificate is transmitted to the IHS. An inventory of detected hardware components of the IHS is compared against the inventory from the updated inventory certificate in order to validate the detected hardware of the IHS includes the component, supplied by the trusted entity, that is identified in the updated inventory certificate.

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: According to embodiments of the present disclosure, an Information Handling System (IHS) including multiple Security Protocol and Data Model (SPDM)-enabled devices is configured to perform collective attestation. The collective attestation is provided by computer-executable instructions that, when executed by a processor of the IHS, receive an attestation request from a requesting device and a device identity certificate from each of the devices. Using the device identity certificates, the instructions perform a cryptographic hash over the received device identity certificates, and send the cryptographic hash to the requesting device in response to the request.

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 computer-executable instructions to receive a request for a secret known by the IHS, and attest the RAC by verifying that the public key exists in a manifest that is configured to store identifying information about a plurality of devices configured in the IHS. The request is signed using a private key of a first asymmetric key pair generated by a Remote Access Controller (RAC). Using a second public key of a second asymmetric key pair, the instructions encrypt the requested secret; and send the encrypted secret to the RAC, wherein the RAC is configured to use the second private key of the second asymmetric key pair to decrypt the encrypted secret.

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: 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 receive a request to boot a factory firmware on the BMC in which the factory firmware is signed by a first private key of a first asymmetric private/public key pair. Using the first private key, the instructions verify an authenticity of the factory firmware using a public key associated with the first private/public key pair, and allow booting of the factory firmware only when it is authenticated by the first public key.

Abstract: An information handling system includes a memory and a basic input/output system (BIOS). The memory stores a lookup table to associate each of a plurality of device firmware hashes with a corresponding one of a plurality of device identification strings. The BIOS calculates the each of the device firmware hashes. Each device firmware hash is associated with a different device firmware. The BIOS creates the lookup table based on the calculated device firmware hashes and the device identification strings. Based on the lookup table, the BIOS displays a secure boot allowed devices database list on a display device.

Abstract: Systems and procedures are provided for enforcing geographic restrictions on the operation of an IHS (Information Handling System). During factory provisioning of the IHS, a signed inventory certificate is uploaded to the IHS that specifies a plurality of allowed geographic locations at which the IHS is operational. Upon delivery and initial powering of the IHS, a validation environment is instantiated and further initialization of the IHS is halted until a location of the IHS can be determined. Once a geographic location of the IHS has been determined, it is compared to the allowed geographic locations from the inventory certificate stored during factory provisioning. When the location of the IHS is not at an allowed geographic location specified in the inventory certificate, the IHS is rendered non-operational. When the location of the IHS is at an allowed geographic location specified in the inventory certificate, further initialization of the IHS is enabled.

Abstract: An information handling system includes a memory, a baseboard management controller (BMC), and a basic input/output system (BIOS). The memory stores a secure boot policy for a plurality of input/output (I/O) devices in the information handling system. The BMC performs a firmware update for a first I/O device of the I/O devices. In response to the firmware update being completed successfully, the BMC creates a system management task. During a next boot after the creation of the system management task, the BIOS detects the system management task. The BIOS calculates a new hash value for a firmware image of the firmware update. The BIOS replaces a previous hash value with the new hash value in the secure boot policy.

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.