DMTF SPDM specification DSP0274 1.4 (FINISH transcript definition): A specification-level defect rather than

Impact

A specification-level defect rather than an implementation bug. SPDM 1.4 added OpaqueDataLength and OpaqueData fields to FINISH and FINISH_RSP, but the transcript definitions used to compute the FINISH signature and the verify-data HMACs were never updated to cover them. A literal implementation therefore authenticates a message while leaving part of that message unauthenticated - so an attacker in the path can alter the opaque fields without breaking the signature. This is exactly the class of flaw that undermines device attestation quietly: everything validates, and the validated thing is not what was sent.

Who can reach it

An attacker able to modify SPDM traffic between requester and responder - a PCIe interposer, a compromised switch or retimer in the path, or a malicious intermediary in a disaggregated fabric where SPDM crosses a network rather than a board trace.

What to do

Requires a specification erratum plus updated implementations on both ends, so the fix arrives as vendor firmware updates once DMTF publishes and vendors rebase - expect a long tail and no OS-level patch. Nothing to configure. The operator action today is to know that SPDM 1.4 opaque data is not integrity-protected in affected implementations, and not to build any policy decision on values carried there.

References