SPDM

Security Updated Sep 2026

SPDM: Security Protocol and Data Model, and Its Role in SSD Storage Security

A working reference on SPDM (DMTF DSP0274) — the transport-agnostic device authentication/attestation protocol that underlies PCIe CMA/IDE/TDISP, NVMe-MI, and the SPDM-to-Storage binding (DSP0286). Cross-references: caliptra (Caliptra's DPE API exists specifically to act as SPDM's cryptographic oracle, and its DICE identity hierarchy is the certificate chain SPDM walks); pqc (SPDM's asymmetric signing/key-exchange operations are exactly the layer the PQC transition targets); cxl (CXL rides the same PCIe DOE/IDE/TDISP stack SPDM anchors).

1. What Problem SPDM Solves

Before SPDM, "is this NVMe drive/PCIe card/CXL device actually what it claims to be, running the firmware it claims to be running" had no standard answer. A compromised or counterfeit component — a drive with implanted malicious firmware, a rogue PCIe endpoint slipped into a supply chain, a device silently downgraded to a known-vulnerable firmware revision — looked identical to the host at the protocol level. SPDM (Security Protocol and Data Model, DMTF standard DSP0274) is the industry's answer: a message-level protocol for device authentication, firmware/configuration measurement (attestation), and secure session establishment, defined independently of any specific transport so the same protocol logic works over PCIe, NVMe, I2C/I3C (MCTP), USB, or anything else that can carry a byte stream.

SPDM answers three questions, corresponding to three protocol phases:

  1. Who are you? — certificate-based identity, rooted in a hardware root of trust.
  2. What state are you in? — signed measurements of firmware/configuration, so a verifier can detect tampering or a rollback to vulnerable firmware.
  3. Can we talk privately? — an optional secure session (encrypted + integrity-protected) layered on top, once identity and state are established.

This is the same three-part shape as the OCP attestation model described below, and it's why SPDM shows up as the common plumbing underneath several otherwise-unrelated specs (PCIe CMA, NVMe-MI, TDISP, the storage binding) rather than being reinvented per-transport.

2. Core Message Flow

SPDM defines a request/response exchange between a Requester (typically the host, BMC, or platform root of trust) and a Responder (the device — an SSD controller, a PCIe endpoint, an accelerator):

Requester                                          Responder
    │                                                   │
    │── GET_VERSION ───────────────────────────────────►│  negotiate SPDM version
    │◄───────────────────────────────────── VERSION ────│
    │                                                   │
    │── GET_CAPABILITIES ───────────────────────────────►│  what does each side support?
    │◄────────────────────────────────── CAPABILITIES ──│  (measurements? key exchange? PSK? mutual auth?)
    │                                                   │
    │── NEGOTIATE_ALGORITHMS ───────────────────────────►│  hash, signature, DHE/KEM algorithms
    │◄──────────────────────────── ALGORITHMS ───────────│
    │                                                   │
    │── GET_DIGESTS ─────────────────────────────────────►│  hash of each cert chain the device holds
    │◄──────────────────────────────────── DIGESTS ──────│
    │── GET_CERTIFICATE (per slot) ──────────────────────►│  retrieve the full chain (device cert → intermediate → root)
    │◄──────────────────────────────── CERTIFICATE ───────│
    │                                                   │
    │── CHALLENGE (nonce) ───────────────────────────────►│  prove possession of the private key
    │◄───────────────────────────── CHALLENGE_AUTH ───────│  signed response over the nonce + transcript hash
    │                                                   │
    │── GET_MEASUREMENTS ─────────────────────────────────►│  request signed firmware/config measurements
    │◄─────────────────────────────── MEASUREMENTS ───────│  (device is now authenticated *and* attested)
    │                                                   │
    │── KEY_EXCHANGE ─────────────────────────────────────►│  (optional) establish a secure session
    │◄──────────────────────── KEY_EXCHANGE_RSP ──────────│  DHE/ECDHE or PQC KEM, mutual or one-way auth
    │── FINISH ────────────────────────────────────────────►│
    │◄─────────────────────────────────── FINISH_RSP ──────│  session keys derived; traffic now encrypted+MAC'd

A verifier that only needs "prove you are who you say you are" can stop after CHALLENGE_AUTH. One that needs "prove your firmware hasn't been tampered with" adds GET_MEASUREMENTS. One that needs an ongoing protected channel (e.g., to carry PCIe IDE key material, or a storage vendor's own management commands) proceeds through KEY_EXCHANGE/FINISH into a Secure Session, inside which further SPDM or vendor-defined messages travel encrypted.

3. Certificate and Identity Model

SPDM identity is X.509-certificate-based, organized into slots (up to 8, Slot 0–Slot 7):

  • Slot 0 is special — it must hold either a Device Certificate (identity provisioned at manufacture, analogous to Caliptra's non-renewable IDevID) or an Alias Certificate (a certificate chain rooted in a device identity but with a leaf key tied to the currently-running firmware measurement — this is the DICE pattern: the identity itself changes if the firmware changes, so a tampered firmware image can't reuse a clean identity's signature).
  • Slots 1+ (added formally as a first-class model in SPDM 1.3) support Generic Certificates — more flexible, used for provisioned/owner-installed identities rather than the manufacturing-rooted chain in slot 0.
  • SPDM 1.3 also added multi-key support: up to 8 asymmetric key pairs per algorithm, each with its own KeyPairID, so a single device can hold separate signing keys for separate roles (e.g., one key for measurement signing, a different one for a KEY_EXCHANGE session) instead of overloading one key for everything.

This is the exact point where caliptra's DICE hierarchy plugs in: Caliptra's IDevID → LDevID → Alias Keys chain is a concrete implementation of SPDM's slot-0 identity model, and Caliptra's DPE (DICE Protection Environment) API exists specifically so other SoC blocks — an SSD controller's SPDM responder among them — can request signing/attestation operations from Caliptra's key vault without implementing their own root of trust. In other words: Caliptra is a RoT that speaks the credential format SPDM expects; SPDM is the wire protocol that lets a host actually ask for and verify that credential.

4. Version History

Version Released Headline additions
1.0 2020 Foundational message set: capability/algorithm negotiation, certificate retrieval, CHALLENGE authentication, GET_MEASUREMENTS
1.1 2021 Secure session infrastructure — KEY_EXCHANGE/FINISH, both PSK (pre-shared key) and public-key/DHE flows, mutual authentication
1.2 2022 Certificate installation (provisioning, not just retrieval), Alias Certificates formalized, chunked large-message support, Chinese national cryptographic algorithm support (SM2/SM3/SM4)
1.3 May 2023 Eventing (either side can asynchronously notify the other of a state change — all events flow inside a Secure Session), multi-key support, Generic Certificate model for slots 1–7, Measurement Extension Log (MEL) and Hash-Extended Measurement (HEM) for tracking cumulative state change (conceptually parallel to a TPM PCR extend)
1.4 published (DSP0274_1.4.0) Latest published revision at time of writing; DMTF's public documentation for the headline feature set was not confirmed during this research pass — worth reading DSP0274 1.4.0 directly before relying on specifics

SPDM maintains bit-wise/semantic backward compatibility for existing fields across versions — a 1.0 responder and a 1.3 requester negotiate down to the highest version both support via GET_VERSION, the same pattern CXL and PCIe generations use for their own version negotiation.

5. Transport Bindings — Where This Actually Touches an SSD

SPDM's message content is transport-independent, but it has to ride on something concrete to reach a drive. Three bindings matter for storage:

5a. PCIe: CMA → DOE → IDE → TDISP

This is the stack that matters for any NVMe SSD attached over PCIe (i.e., essentially all of them):

Layer Spec Role
DOE (Data Object Exchange) PCIe base spec, r6.1 §6.31 A generic PCIe Extended Capability mailbox for exchanging arbitrary data objects with a device — not security-specific by itself, just a transport primitive
CMA (Component Measurement and Authentication) PCIe spec Defines how SPDM messages are carried over a DOE mailbox — this is the PCIe-specific SPDM binding, same conceptual role as DSP0286 plays for storage protocols
IDE (Integrity and Data Encryption) PCIe spec, r6.1 §6.33 Real-time encryption + integrity protection of the PCIe link itself (TLP-level). IDE's key exchange (IDE-KM) depends on CMA/SPDM having already authenticated the device and established trust — SPDM doesn't do the link encryption itself, it bootstraps the keys IDE uses
TDISP (TEE Device Interface Security Protocol) PCIe spec Builds a trust relationship between a confidential-computing TEE (a TDX/SEV-SNP guest) and a passed-through device interface (TDI), so the guest — not just the host — can verify the device it's talking to directly. Depends on CMA/SPDM for device identity and IDE for the encrypted data path underneath it

The practical chain is: CMA/SPDM authenticates and measures the device → IDE encrypts the PCIe link using keys SPDM helped establish → TDISP extends that trust into a confidential-computing guest. Linux kernel work (RFC patch series, drivers/pci/cma.c + an in-kernel SPDM requester library) is actively adding native CMA-SPDM device authentication at enumeration time, with an in-kernel certificate keyring as the trust anchor and automatic reauthentication on device reset or system-sleep resume (notable because user space isn't available yet at that point in resume, so the kernel has to do it itself).

5b. Storage protocols directly: DSP0286 (SPDM-to-Storage Binding)

Published May 2025, DSP0286 defines how to carry SPDM messages over the storage command sets already used for TCG Opal/Enterprise SSC security provisioning — reusing existing plumbing rather than inventing a new one:

Storage interface Carrier commands
NVMe (including NVMe-oF) Security Send (IF-SEND) / Security Receive (IF-RECV) admin commands
SCSI SECURITY PROTOCOL OUT / SECURITY PROTOCOL IN
ATA TRUSTED SEND(/DMA) / TRUSTED RECEIVE(/DMA)

All three use Security Protocol code 0xE8, reserved for DMTF's use — sitting right alongside TCG's own reserved protocol code (0x01) that Opal/Enterprise SSC already uses for ComPacket-wrapped SESSION/method traffic on the exact same Security Send/Receive command pair. This is a clean parallel worth internalizing: an NVMe drive that supports both TCG Opal and SPDM is using the identical two admin commands for two different security protocols, distinguished only by the protocol code field — one negotiates encryption-at-rest bands and credentials, the other authenticates the drive itself and reports its firmware state. DSP0286 supports both plain SPDM Storage Messages and, once a Secure Session is up, encrypted Secured Messages per the base SPDM secure-messaging spec (DSP0277), and explicitly accounts for intermediate devices like HBAs sitting between the SPDM requester and the actual drive.

This binding is also what a reference implementation like QEMU's SPDM support exercises directly — QEMU's virtual NVMe/PCIe devices can be configured to speak SPDM either over a simulated DOE mailbox or over simulated NVMe Security Send/Receive, bridging to an external libspdm-based responder process. That two-transport support in a widely-used emulator is a reasonable signal that both bindings (PCIe-native and storage-native) are live, exercised code paths, not just paper specs.

5c. Out-of-band: NVMe-MI

NVMe-MI (the out-of-band management interface — SMBus/I2C or PCIe VDM, used by BMCs) is a separate binding target from the in-band Security Send/Receive path above; a drive can in principle expose SPDM both in-band (host-visible, via DSP0286) and out-of-band (BMC-visible, via NVMe-MI), which matters for platforms where the BMC — not the host OS — is the party doing supply-chain attestation before the host is even allowed to boot from the drive.

6. The OCP Attestation Model — Where SPDM Fits Organizationally

OCP's Attestation of System Components v1.0 (2020) defines the datacenter-operator-facing attestation architecture that SPDM implements the wire protocol for:

  • Attester — "a collection of hardware, software, firmware, and a root of trust (RoT) with the ability to provide reliable evidence of trustworthiness (measurements) to the verifier." The spec names an NVMe SSD explicitly as an example attester, alongside NICs and RAID controllers.
  • Verifier — a platform component (a server, a storage controller, or a trusted service) that assesses attester trustworthiness.
  • The document recommends SPDM's GET_CAPABILITIES/NEGOTIATE_ALGORITHMS message formats specifically, and mandates SPDM 1.0+ for any SPDM-based attester.

So the layering, top to bottom, for a datacenter NVMe SSD is roughly:

Datacenter operator's platform attestation policy      ← OCP Attestation v1.0 (verifier/attester roles)
        │
SPDM protocol (identity + measurement + secure session) ← DSP0274 (this doc)
        │
   ┌────┴────┐
DSP0286              PCIe CMA/DOE
(in-band, Security   (in-band, PCIe extended
 Send/Receive)         capability mailbox)
        │                    │
   NVMe SSD controller's SPDM responder
        │
Caliptra (or equivalent silicon RoT) — signs CHALLENGE_AUTH / MEASUREMENTS
using keys never exposed outside the RoT's key vault    ← [caliptra](https://globaltrendanalysis.com/caliptra/)

7. The PQC Angle

SPDM's CHALLENGE/GET_MEASUREMENTS signatures and KEY_EXCHANGE key establishment are exactly the asymmetric operations pqc identifies as exposed to "harvest now, decrypt later" and to Shor's-algorithm-scale quantum attack — SPDM is, concretely, where firmware-signing and key-exchange crypto-agility has to land for a PCIe/NVMe device, not an abstract requirement floating separately from any protocol. There's active academic work on this specifically (Post-Quantum Design in SPDM for Device Authentication and Key Establishment, eprint 2022/1049), and SPDM's algorithm-negotiation design (NEGOTIATE_ALGORITHMS already treats hash/signature/KEM choice as a per-session negotiated field, not a hardcoded constant) is exactly the kind of crypto-agility structure that makes a hybrid classical+PQC transition tractable without a protocol redesign — consistent with the hybrid/dual-signing transition strategy that document describes vendors (WD, Novachips) already using.

8. Open Questions / Next Steps

  • [ ] Read DSP0274 1.4.0 directly for the actual 1.4 feature list — the DMTF announcement page didn't cover it and this doc's version table has a gap there.
  • [ ] Check whether the drives named in pqc (Kioxia CM10, ScaleFlux FC6116, Novachips P2-series) advertise SPDM support alongside their NVMe 2.4 PQC hooks, or treat attestation and PQC media/session crypto as separate, unlinked feature sets.
  • [ ] Pull the Linux kernel PCI/CMA and PCI/TSM (TDISP) patch series once merged, to see the actual in-kernel SPDM requester's certificate-trust model in finished form rather than RFC form.
  • [ ] Read DSP0286 in full for the exact SPDM Storage Message header format and how it's distinguished from TCG's ComPacket framing at the byte level, given both ride Security Send/Receive.
  • [ ] Confirm whether current-generation OCP-qualified datacenter NVMe SSDs (the Datacenter NVMe SSD Spec line) have moved SPDM from optional/recommended to a hard requirement in the newest revision — the 2.0-era text treated it as a recommendation, worth checking the latest revision directly.
  • [ ] Map NVMe-MI's out-of-band SPDM path against DSP0286's in-band path for a drive that supports both — does a BMC-side attestation result get reconciled with a host-side one, or are they treated as independent trust decisions?

Sources

Contact

Have an Idea?
Let's Build It.

Whether you're a startup with a hardware concept, an established company needing deep design help, or an enthusiast with a wild project — we want to hear about it.

Emailaglucas@globaltrendanalysis.com
Phone(303) 921-4492
LocationBoulder, Colorado