docs/designs/redfish-spdm-attestation.md

14 [TPM](https://trustedcomputinggroup.org/resource/trusted-platform-module-tpm-summary/)
18 generic implementation for the SPDM D-Bus Daemon.
27 [libspdm](https://github.com/DMTF/libspdm) provides an open-source
30 adds support for doing SPDM-based device attestation over Redfish API.
40 - New D-Bus interfaces for Redfish resources `ComponentIntegrity` and
42 - BMCWeb changes for supporting the above Redfish resources.
43 - Design for SPDM Attestation D-Bus Daemon, demonstrating how to fetch the
44   attestation results over D-Bus.
48 ### Attestation related D-Bus Interfaces
51 D-Bus:
59 So far, phosphor-dbus-interfaces lacks interfaces defined for attestation
62 - `Attestation.ComponentIntegrity`
63 - `Attestation.IdentityAuthentication`
64 - `Attestation.MeasurementSet`
81 The proposed Phosphor D-Bus Interfaces is here:
82 [component-integrity](https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/64354).
84 ### TrustedComponent related D-Bus Interfaces
94 - `AttachmentType`, which gives information on whether this trusted component is
101 The proposed Phosphor D-Bus Interfaces for `TrustedComponent` is here:
102 [trusted-component](https://gerrit.openbmc.org/c/openbmc/phosphor-dbus-interfaces/+/64355).
104 ### SPDM Attestation D-Bus Daemon
108 to support it. But BMCWeb collects the information from D-Bus. The SPDM
109 Attestation D-Bus Daemon does the actual work.
113 be MCTP, PCIe-DOE, or even TCP socket. For MCTP, the lower physical layer can be
114 PCI-VDM, SMBus/I2C, and so on. Note,
115 …binding](https://github.com/DMTF/libspdm/blob/main/include/internal/libspdm_common_lib.h#L445-L446)
118 PCIe-DOE, or TCP setting up the transport layer connection could be easy. In
119 this design, we only consider SPDM over standard MCTP,TCP & PCIe-DOE connection.
121 For SPDM-over-MCTP, SPDM daemon can query the mctpd for information about MCTP
125 For SPDM-over-TCP, SPDM daemon can query [entity-manager][entity-source] for
126 information about remote TCP endpoints, including the `hostname / ip-address` &
129 over TCP specification][spdm-tcp-spec]
131 [entity-source]: https://github.com/openbmc/entity-manager
132 [spdm-tcp-spec]:
135 For SPDM-over-PCIe-DOE, SPDM daemon need the PCIe device BDF to handle DOE
158 daemon in dbus-sensors to handle the configuration. The proposed
159 [implementation](https://gerrit.openbmc.org/c/openbmc/dbus-sensors/+/69111); the
164 up a connection with the SPDM-capable endpoints to get certificates and
171 the `Hostname` & `Port` of the remote entity. For signals sent before SPDM
172 daemon launches, SPDM daemon should query the `entity-manager` for any detected
175 Below is a high-level diagram showing the relationship between different
179     +------+            +---------+
181     +--+---+            |Manager  |
182        |                +---^-----+           +-------+
184     +--v---+            +---+---+------------>|Device |
185     |BMCWeb+----------->|SPDM   |             +-------+
186     +------+            |Daemon |
187                         +---+---+------------>+-------+
189                         +---v---+             |Device |
190                         |mctpd  |             +-------+
191                         +-------+
194 A reference D-Bus Daemon workflow would be like this:
196 0. (Probing phase) Entity Manager will parse the configuration file for trusted
200    that support SPDM; For PCIe-DOE, it performs DOE mailbox discovery with the
201    PCIe device ID; For TCP, it queries entity-manager to gather the remote IP
203 2. For each endpoint, which could be MCTP, PCIe-DOE or TCP, SPDM daemon query
204    Entity Manger for the matching trusted component configuration. It then
205    creates and initializes the corresponding D-Bus object for `TrustedComponent`
209 4. Set up a connection between the BMC and each SPDM-capable device;
214 8. Wait on D-Bus and serve any runtime `SPDMGetSignedMeasurements` requests.
219 [certificate manager](https://github.com/openbmc/phosphor-certificate-manager),
221 the existing certificates manager is designed for managing server/client
223 Existing cert manager has several limitations:
225 - Each manager can only manage one certificate.
226 - Each manager assumes access to both the private key and the public key (e.g.,
231 - Device certificate manager manages several certificates for a group of
233 - Device certificate does not assume private key access. It is used for identity
238 need for a global cert manager that "manages" the device certificates. SPDM
239 D-Bus daemon can simply talk to the devices, get the certificates from them, and
240 create D-Bus object for the certificates.
243 `/redfish/v1/Chassis/{ChassisId}/Certificates/`. Existing cert manager
249 chassisId on D-Bus.
257 - `/redfish/v1/ComponentIntegrity/`
258 - `/redfish/v1/Chassis/{ChassisId}/TrustedComponents/`
265 - `/redfish/v1/Chassis/{ChassisId}/TrustedComponents/{TrustedComponentId}/`
267 - `/redfish/v1/Chassis/{ChassisId}/TrustedComponents/{TrustedComponentId}/`
270 On the D-Bus Daemon side, we propose that the dbus objects are organized in the
273 - `/xyz/openbmc_project/component_integrity/{component_integrity_id}`
274 - `/xyz/openbmc_project/trusted_components/{trusted_component_id}`
275 - `/xyz/openbmc_project/certs/devices/{chassis_id}/{cert_id}`
280 - `/redfish/v1/Chassis/{ChassisId}/TrustedComponents/{TrustedComponentId}`
285 [phosphor-certificate-manager](https://github.com/openbmc/phosphor-certificate-manager).
289 - Step 1: fetch device certificate by exchange SPDM messages with device.
290 - Step 2: create or update a dbus certificate object.
293 handled by the D-Bus daemon, too. It would be a over-kill to modify existing
294 phosphor-certificate-manager for the sole purpose.
300 - Create a SPDM daemon that can do SPDM attestation for SPDM-capable devices
302 - Add `ComponentIntegrity` and `TrustedComponent` related D-Bus interfaces in
303   phosphor-dbus-interfaces.
304 - Extend existing certificate service in BMCWeb.
305 - Add SPDM support in BMCWeb with new routes.
313 - <https://github.com/openbmc/bmcweb>
314 - <https://github.com/openbmc/phosphor-dbus-interfaces>
323 For the SPDM Attestation D-Bus Daemon, unit tests should cover the following
326 - Set up a transport layer connection with the device.
327 - Unit tests should be implemented to ensure the infrastructure functions
329 - SPDM connection setup, including get capabilities, negotiate algorithms.
330 - Get device certificates from device and create D-Bus object.
331 - `SPDMGetSignedMeasurements` method test.
332 - Enumerate trusted component D-Bus objects and check properties and
334 - Enumerate component integraty D-Bus objects and check properties and
339 BMCWeb/D-Bus Daemon integration test should cover the following type of
342 - Get a collection of `ComponentIntegrity` resources.
343 - Get a collection of `TrustedComponent` resource.
344 - Get properties of a `ComponentIntegrity` resources.
345 - Get properties of a `TrustedComponent` resource.
346 - Follow the resouces link to get the device certificates and verify that they
348 - Get properties of `Certificate` resource and verify responses match with leaf
350 - Call Action on the `ComponentIntegrity` resource to get measurements.
353 …ult/files/standards/documents/DSP0268_2024.4.html#resource-collection-uris-in-redfish-v16-and-later