Author: Zhichuang Sun
Other contributors: Jerome Glisse, Ed Tanous
Created: June 27th, 2023 Last Updated: Oct 30th, 2023
Redfish added schema for ComponentIntegrity, which allows users to use SPDM or TPM to authenticate device identity, hardware configuration and firmware integrity. It would be useful to add SPDM attestation support in BMCWeb, which provides unified interface for device security attestation in data centers, and provide a generic implementation for the SPDM D-Bus Daemon.
This design focuses on SPDM.
SPDM (Security Protocols and Data Models) is a spec published by DMTF. It is designed for secure attestation of devices. GitHub repo libspdm provides an open-source implementation of the SPDM protocol. Redfish Schema ComponentIntegrity adds support for doing SPDM-based device attestation over Redfish API.
This feature aims at supporting SPDM attestation through Redfish API and providing system administrators and operators an easy way to remotely verify the identity and integrity of devices.
This design includes:
ComponentIntegrity and TrustedComponent.There are three type of information we will need from an attestation daemon on D-Bus:
So far, phosphor-dbus-interfaces lacks interfaces defined for attestation purpose. Thus, we propose three new interfaces:
Attestation.ComponentIntegrityAttestation.IdentityAuthenticationAttestation.MeasurementSetAttestation.ComponentIntegrity provides basic component integrity information, including the protocol to measure the integrity, last updated time, attestation enablement status, etc. There are also associations proposed for this interface, including a link to the trusted component that the component integrity object is reporting, and a link to the systems that the component integrity object is protecting. Note, the "trusted component" in this doc refers to a trusted device, such as a TPM, an integrated Root of Trust (ROT).
Attestation.IdentityAuthentication provides identity verification information. Two associations are proposed to link it to the requester and the responder's certificates.
Attestation.MeasurementSet defines the dbus method to get SPDM measurements. It can be extended to measurements fetched using other protocol in the future.
The proposed Phosphor D-Bus Interfaces is here: component-integrity.
We also propose to add one Inventory interface for TrustedComponent, namely Inventory.Item.TrustedComponent. TrustedComponent represents a trusted hardware component, typically known as Root of Trust(ROT). It can be an externally attached security chip, like a TPM, or a hardware IP integrated into a device. It can securely measure the integrity information of a device.
Inventory.Item.TrustedComponent interface defines the following properties
AttachmentType, which gives information on whether this trusted component is integrated into the device or is discrete from the device.A TrustedComponent is typically associated with other hardware components which it is protecting. It should also be associated with the component integrity object reported by this TrustedComponent.
The proposed Phosphor D-Bus Interfaces for TrustedComponent is here: trusted-component.
Experimental support for SPDM exists for bmcweb, which adds routes in the BMCWeb for ComponentIntegrity and TrustedComponent to support it. But BMCWeb collects the information from D-Bus. The SPDM Attestation D-Bus Daemon does the actual work.
SPDM protocol needs to be bound to a transport layer protocol, which transmits SPDM messages between the BMC and the device. The transport layer protocol can be MCTP, PCIe-DOE, or even TCP socket. For MCTP, the lower physical layer can be PCI-VDM, SMBus/I2C, and so on. Note, libspdm already provides transport layer protocol binding with message encoding/decoding support. The device send/receive function is left for SPDM daemon to implement If the transport layer is using standard MCTP or PCIe-DOE, setting up the transport layer connection could be easy. In this design, we only consider SPDM over standard MCTP and PCIe-DOE connection.
For SPDM-over-MCTP, SPDM daemon can query the mctpd for information about MCTP endpoint, including the endpoint id(eid) and upper layer responder, and create a connection only for endpoint that has SPDM as its upper layer responder.
For SPDM-over-PCIe-DOE, SPDM daemon need the PCIe device BDF to handle DOE mailbox discovery. Given that not all PCIe devices support DOE support SPDM, we cannot query about whether a DOE capable device supports SPDM. Therefore, we need a way to pass the device info to the dameon. However, PCIe device BDF(Bus:Device:Function) info are dynamically assigned during system boot. The same device may get assigned different BDF on different machine. What the daemon needs should be the PCIe device ID, which is identified by VendorId:DeviceId. For the convenience of configuration, we should pass PCIe device ID to the daemon, so that the daemon can enumerate all the PCIe devices and find the matching devices by their device ID. There are different ways to pass PCIe device ID info to the dameon, e.g., configuration file, command line parameters.
For PCIe DOE devices, SPDM daemon can enumerage all PCI devices under sysfs and find out all BDFs with matching VendorId:DeviceId. SPDM daemon also needs to query InventoryManager to get all PCI device inventory paths. By querying InventoryManager managed objects and checking object interface xyz.openbmc_project.Inventory.Item.PCIeDevice, which has property FunctionXVendorId and FunctionXDeviceId (X represents numbers from 0 to 7), we can find all PCI device inventory paths with matching VendorId:DeviceId. So far, there is no universal way to map a given device's BDF to its inventory path. It is up to the vendor to do the association.
For MCTP devices detection, the community has been working on mctpreactor daemon in dbus-sensors to handle the configuration. The link to implementation is here, the related PR discussion is here. SPDM daemon will monitor mctpd for InterfacesAdded signals providing the xyz.openbmc_project.MCTP.Endpoint interface, which exposes the message types supported by the endpoint in the SupportedMessageTypes member. SPDM daemon set up a connection with the SPDM-capable endpoints to get certificates and measurements. For signals sent before SPDM daemon launches, SPDM daemon should query the mctpd for any detected endpoints after it gets launched.
Below is a high-level diagram showing the relationship between different components.
+------+ +---------+
|Client| |Inventory|
+--+---+ |Manager |
| +---^-----+ +-------+
| | |PCIe |
+--v---+ +---+---+------------>|Device |
|BMCWeb+----------->|SPDM | +-------+
+------+ |Daemon |
+---+---+------------>+-------+
| |MCTP |
+---v---+ |Device |
|mctpd | +-------+
+-------+
A reference D-Bus Daemon workflow would be like this:
TrustedComponent and ComponentIntegrity with device specific information.SPDMGetSignedMeasurements requests.In OpenBMC, there is a certificate manager, which allows users to install or replace server/client certificates. However, the existing certificates manager is designed for managing server/client certificates for HTTPS/LDAP services. It's not suitable for device certificates. Existing cert manager has several limitations:
Device certificates have different requirements:
For device certificates, we only need to create/replace certificate objects, no need for a global cert manager that "manages" the device certificates. SPDM D-Bus daemon can simply talk to the devices, get the certificates from them, and create D-Bus object for the certificates.
In Redfish, device certificates are under Chassis, and are accessible via /redfish/v1/Chassis/{ChassisId}/Certificates/. Existing cert manager constructs cert path following the pattern "/xyz/openbmc_project/certs/{type}/{endpoint}". To comply with it, we propose to put device certificates under /xyz/openbmc_project/certs/chassis/{ChassisId}/{certsId}. So that for all device certificates on a chassis, we can find those certificates with its chassisId on D-Bus.
In BMCWeb, we need to add routes handler for ComponentIntegrity, TrustedComponent and Certificates. The corresponding URI are specified as follows according to Redfish spec:
/redfish/v1/ComponentIntegrity//redfish/v1/Chassis/{ChassisId}/TrustedComponents//redfish/v1/Chassis/{ChassisId}/Certificates/On the D-Bus Daemon side, we propose that the dbus objects are organized in the following way:
/xyz/openbmc_project/ComponentIntegrity/{ComponentIntegrityId}/xyz/openbmc_project/TrustedComponents/{TrustedComponentId}/xyz/openbmc_project/certs/devices/{ChassisId}/{CertId}In BMCWeb, we can reconstruct the following redfish URI by querying the associated Chassis from the trusted component:
/redfish/v1/Chassis/{ChassisId}/TrustedComponents/{TrustedComponentId}Alternative way to manage device certificates would be modifying existing phosphor-certificate-manager.
Device certificates management has two steps:
Step 1 can only be handled by the SPDM daemon. Step 2 is simple enough to be handled by the D-Bus daemon, too. It would be a over-kill to modify existing phosphor-certificate-manager for the sole purpose.
This change will:
ComponentIntegrity and TrustedComponent related D-Bus interfaces in phosphor-dbus-interfaces.This repository requires creating a new repository for the SPDM daemon. In addition, the following repositories are expected to be modified to execute this design:
For the BMCWeb changes, unit test can be done with the Redfish Service Validator.
For the SPDM Attestation D-Bus Daemon, unit tests should cover the following cases:
SPDMGetSignedMeasurements method test.BMCWeb/D-Bus Daemon integration test should cover the following type of requests:
ComponentIntegrity resources.TrustedComponent resource.ComponentIntegrity resources.TrustedComponent resource.ComponentIntegrity resource to get measurements.