While exploring SPDM (Security Protocol and Data Model) as part of my deeper dive into platform security, I ran into several roadblocks. Coming from a background in classical cryptography and TLS, I brought along a lot of mental models that didn’t quite fit. What looked like a familiar protocol turned out to have very different principles and priorities.
Here are five key misunderstandings I had about SPDM during my learning process — and what helped me correct them.
❌ Misunderstanding #1: SPDM is Basically TLS for PCIe
At first glance, SPDM looked like TLS applied to hardware buses — so I expected it to behave similarly. I assumed it would provide end-to-end encryption over PCIe or MCTP, using standard certificates and handshake logic.
🔍 What I Realized
SPDM isn’t a drop-in transport-layer encryption protocol like TLS. Instead, it’s designed for low-level platform communication, focusing on:
- Lightweight identity authentication
- Secure firmware/attestation exchange
- Session key establishment between devices like BMCs and endpoints
It’s optimized for resource-constrained environments, and doesn’t carry the complexity (or assumptions) of TLS.
❌ Misunderstanding #2: SPDM Messages Are Just Stateless Requests
Initially, I treated SPDM like a stateless request/response protocol. I expected to send any command at any time — and didn’t account for protocol sequencing.
🔍 What I Realized
SPDM follows a strict state machine:
- Version Negotiation
- Capabilities Exchange
- Algorithm Negotiation
- Key Exchange / Session Setup
- Attestation or Certificate Exchange
Messages must be exchanged in order. Skipping or reordering them led to failures or unexpected behavior. Once I understood SPDM’s stateful nature, everything started falling into place.
❌ Misunderstanding #3: SPDM Requires X.509 Certificates
Coming from TLS and PKI-based systems, I defaulted to assuming that X.509 certificates were required for authentication.
🔍 What I Realized
SPDM supports multiple identity models, not just X.509:
- Raw public keys
- DICE-based identities (CDI and Device ID)
- Pre-Shared Keys (PSK)
In embedded environments, full X.509 parsing is often impractical. Once I experimented with raw public keys and DICE-style identity, the protocol became much more flexible and practical for constrained systems.
❌ Misunderstanding #4: Once a Session Is Established, Security Is Done
After setting up a session, I assumed encryption and authentication would just “work” — with no further effort. I overlooked how important ongoing state management was.
🔍 What I Realized
SPDM sessions rely on:
- Proper session ID tracking
- Sequence numbers to prevent replay
- AEAD encryption using derived session keys
- Explicit message integrity checks
Without managing these, messages silently failed or were rejected. I had to implement proper state tracking, key lifecycle management, and error handling to maintain stable sessions.
❌ Misunderstanding #5: SPDM Works the Same Across All Transports
I originally assumed SPDM would behave the same regardless of whether it ran over PCIe, MCTP, or PLDM. So I built transport-agnostic logic — which didn’t work as expected.
🔍 What I Realized
Different transport bindings introduce:
- Fragmentation and reassembly constraints
- Retry and timeout handling
- Framing formats unique to each medium
After reading the DMTF transport binding specs (like DSP0275 for MCTP), I realized I had to customize message handling depending on the transport layer — especially for message size and timing behavior.
✅ Final Reflection
SPDM challenged many assumptions I had from working with TLS and classic crypto protocols. The protocol is powerful but nuanced, and getting it right requires a shift in thinking — especially when it comes to trust models, message sequencing, and hardware-level integration.
Quick Recap
| My Initial Assumption | What I Learned |
|---|---|
| SPDM ≈ TLS | SPDM is optimized for firmware and hardware-level identity, not general-purpose transport security |
| Messages are stateless | SPDM requires strict state-machine sequencing |
| X.509 is mandatory | SPDM supports DICE, raw public keys, and PSK |
| Session setup is enough | Ongoing session state management is critical |
| Same logic works on all buses | Transport bindings must be handled separately |
🚀 What’s Next?
For anyone learning SPDM, my recommendation is to:
- Read DMTF specs (DSP0274, DSP0275)
- Experiment with libSPDM
- Start small with one transport (e.g., MCTP) and one identity model (e.g., PSK or DICE)
It’s not as plug-and-play as TLS — but once understood, SPDM becomes a very elegant and efficient protocol for building trusted computing platforms.