Hewlett Packard Enterprise Development LP

Shiva R Dasari

Thomas M Laffey

Nigel John Edwards

Ludovic Emmanuel Paul Noel Jacquin

Suhas Shivanna

Kenneth J Geer

Melvin K Benedict

Michael R Krause

Luis E Luciani, Jr

Theofrastos Koulouris

Theodore F Emerson

Dwight D Riley

David F Heinrich

Kevin G Depew

Fraser John Dickin

Robert L Noonan

Naysen J Robertson

Kevin Edward Boyum

Patrick L Gibbons

Terry Ping-Chung Lee

Christopher M Wesneski

William Norwood Scherer, Iii

Sridhar Bandi

Luis E Luciani

Luis Luciani

Christopher Hillier

Nicholas Ramirez

Yelaka Surya Prakash

Dilip Kumar Ramakrishna Reddy

Examples disclosed herein relate to systems and methods for assigning an identifier to a node-based system. For example, systems and methods may: discover the plurality of nodes; determine a node of the plurality of nodes to be a controller node: authenticate, at a management component of the controller node, a respective identifier associated with each node of the plurality of nodes; and based on the authentication, assign a complex identifier to a complex comprising the plurality of nodes, wherein the complex identifier comprises the identifier associated with the controller node.

Systems and methods for assigning a cryptographic identity to node-based systems

A method for securing a plurality of compute nodes includes authenticating a hardware architecture of each of a plurality of components of the compute nodes. The method also includes authenticating a firmware of each of the plurality of components. Further, the method includes generating an authentication database comprising a plurality of authentication descriptions that are based on the authenticated hardware architecture and the authenticated firmware. Additionally, a policy for securing a specified subset of the plurality of compute nodes is implemented by using the authentication database.

Securing node groups

A process includes accessing by a management controller of a computer platform, a platform certificate that is stored in a secure memory. The platform certificate includes data representing a reference inventory for the computer platform. The platform certificate includes data representing information designated to bind the platform certificate to a security processor. The security processor is accessible by the management controller. The security processor is inaccessible by an operating system of the computer platform. The process includes verifying the platform certificate. Verifying the platform certificate includes validating, by the management controller, a signature of the platform certificate; and validating, by the management controller, the information designated to bind the platform certificate to the security processor. Verifying the platform certificate includes comparing, by the management controller, a second inventory of the computer platform to the reference inventory.

Management controller-based verification of platform certificates

An apparatus includes a host and a baseboard management controller. The baseboard management controller includes a semiconductor package; and the semiconductor package includes a memory, a security hardware processor; and a main hardware processor. The main hardware processor causes the baseboard management controller to serve as an agent that, independently from the host, responds to communications with a remote management entity to manage the host. The security hardware processor manages the storage of a secret of the host in the memory.

Managing storage of secrets in memories of baseboard management controllers

A process includes a first tenant of a plurality of tenants communicating with a security processor of a computer platform, via a first physical request interface of the security processor, to acquire ownership of a first command execution engine of the security processor associated with the first physical request interface. The process includes a second tenant of the plurality of tenants communicating with the security processor, via a second physical request interface of the security processor, to acquire ownership of a second command execution engine of the security processor associated with the second physical request interface. The process includes the security processor receiving a first request from the first tenant in the first physical interface, and the second processor receiving a second request from the second tenant in the second physical request interface. The process includes, pursuant to block, the first command execution engine processing the first request and the second command execution engine processing the second request to perform corresponding trusted computing operations.

Multiple physical request interfaces for security processors

In some examples, a system receives input information relating to a security level for an information technology (IT) stack comprising a plurality of layers including a hardware layer and a software layer, where the input information is technology and product agnostic. The system discovers components of the plurality of layers of the IT stack, accesses a knowledge base that maps the security level and the discovered components to configuration instructions relating to security controls, and configures the IT stack with the security controls using the configuration instructions.

Information technology stack security control configuration

A technique includes detecting a presence of a hardware security module in a computer. The hardware security module performs trusted computing base measurements in response to the boot of the computer. The technique includes detecting an intention to change firmware of the computer and regulating providing a message warning about an impact of the change based on the determination. The regulation includes determining whether an operating system of the computer binds operations to the trusted computing base measurements and allowing communication of the message based on the determination.

Regulating messages warning about impacts of firmware changes

Examples disclosed herein relate to performing an action based on a pre-boot measurement of a firmware image. In an example, at a firmware component in a system, a measurement of a firmware image may be determined prior to booting of the system, beginning from a hardware root of trust boot block, by a Trusted Platform Module (TPM) emulator engine that emulates a hardware-based TPM. A pre-determined measurement of the firmware image may be retrieved from a storage location within the system. The measurement of the firmware image may be compared with the pre-determined measurement of the firmware image prior to booting of the system. In response to a determination that the measurement of the firmware image is different from the pre-determined measurement of the firmware image, performing an action.

Using trusted platform module (TPM) emulator engines to measure firmware images

In exemplary aspects described herein, system memory is secured using protected memory regions. Portions of a system memory are assigned to endpoint devices, such as peripheral component interconnect express (PCIe) compliant devices. The portions of the system memory can include protected memory regions. The protected memory regions of the system memory assigned to each of the endpoint devices are configured to control access thereto using device identifiers and/or process identifiers, such as a process address space ID (PASID). When a transaction request is received by a device, the memory included in that request is used to determine whether it corresponds to a protected memory region. If so, the transaction request is executed if the identifiers in the request match the identifiers for which access is allowed to that protected memory region.

Securing transactions involving protected memory regions having different permission levels

An example computing system in accordance with an aspect of the present disclosure includes a first controller and a second controller. The first controller is to verify integrity of a first root of trust (ROT), and generate an integrity signal indicating the results. The second controller is to verify integrity of a second ROT, write the firmware image to the first controller, and verify integrity of the written firmware image.

Multiple roots of trust to verify integrity

Various examples described herein provide for firmware verification on a peripheral device that can couple to a computing device. Before operating firmware is executed on the peripheral device, boot firmware can execute on the peripheral device and cause the peripheral device to generate a hash of the operating firmware. The peripheral device can transmit the hash to a validator external to the peripheral device, such as a management processor. The peripheral device can receive, from the validator, a validation decision based on the transmitted hash. In response to the validation decision indicating invalidity of the operating firmware, the peripheral device can execute recovery firmware to cause the peripheral device to retrieve replacement firmware. Depending on the example, the retrieved replacement firmware may replace the operating firmware or the operating firmware may be updated based on the retrieved replacement firmware.

Validating operating firmware of a periperhal device

In some examples, a computing device includes a data port, device memory to store firmware for the computing device, and verification circuitry. The verification circuitry may override operation of the data port responsive to a determination that firmware verification mode criteria are satisfied. The verification circuitry may also extract firmware data from the device memory for verification of the firmware and provide the firmware data to an external device connected to the computing device through the data port.

Growing community of inventors

Houston, TX, United States of America

Shiva R Dasari