SSD Secure Boot: Caliptra, SPDM, and PQC Working Together
A working page synthesizing three others into one boot-time narrative: caliptra (the silicon root of trust that measures and derives identity), spdm (the wire protocol that reports that identity externally), and pqc (the algorithms doing the actual signing/key-establishment throughout). This page adds the piece none of the three cover alone: where each step actually falls on the clock relative to NVMe boot-timing gates — CAP.TO/CSTS.RDY, namespace readiness, and first read/write — and whether security work is on or off that critical path.
1. The Three Roles, in One Sentence Each
- Caliptra measures every firmware layer before running it, derives a DICE identity chain (
IDevID → LDevID → Alias Keys) bound to exactly what's running, and holds every private key inside a hardware key vault that firmware never touches directly. - SPDM is the protocol a host, BMC, or platform verifier uses to ask the drive to prove that identity and report those measurements —
GET_CERTIFICATE→CHALLENGE→GET_MEASUREMENTS, optionally followed by aKEY_EXCHANGE/FINISHsecure session. - PQC (ML-DSA / ML-KEM via Caliptra's Adams Bridge engine) is the actual cryptography underneath both of the above — verifying firmware signatures during boot, and signing/negotiating keys during the SPDM exchange — replacing or hybridizing with ECDSA/ECDH ahead of the CNSA 2.0 deadlines.
None of the three is optional if the goal is "prove this drive is running unmodified, authentic firmware to something outside itself": Caliptra without SPDM has no way to report itself off-chip; SPDM without a real RoT behind it is an unenforceable claim; neither is quantum-safe without PQC doing the signing math.
2. Where Each Step Falls on the Clock
NVMe boot has a small number of well-defined timing gates. This is where the security chain from caliptra and spdm actually lands relative to them:
| NVMe gate | What it means | Defined by |
|---|---|---|
| CC.EN = 1 | Host has enabled the controller (register write) — the starting gun | NVMe base spec, Controller Configuration register |
| CSTS.RDY = 1 | Controller has finished internal bring-up and will accept admin commands | NVMe base spec, Controller Status register; worst-case bound set by CAP.TO (Controller Capabilities Timeout field, expressed in 500 ms units) |
| Namespace visibility | Identify Namespace / Active Namespace List succeeds for a given NSID |
Not a separate hardware "ready" bit like CSTS.RDY — it's a command that succeeds once the controller is ready and the namespace exists; see §2.4 below for why capacity still matters here |
| First Read / First Write completion | The actual I/O path is live | Requires admin queue setup (AQA/ASQ/ACQ) and at least one I/O Submission/Completion Queue pair created first |
t0 t1 t2 t3 t4
│ │ │ │ │
Power/PERST# CC.EN=1 CSTS.RDY=1 I/O SQ/CQ created First
deasserted, (host enables (worst case bounded (admin commands Read/Write
rail stable controller) by CAP.TO; real after CSTS.RDY) completes
│ │ enterprise drives │ │
├── Caliptra ROM ├── NAND init, FTL/ run ~8–20s typical ├── Identify │
│ (RTM): measure │ mapping-table load, — see §2.3) │ Controller/ │
│ + PQC-verify FMC │ PLP cap check — │ │ Namespace │
│ before executing │ dominant cost here │ │ │
│ │ │ │ │
├── FMC measures + ├── SPDM responder │ │ │
│ PQC-verifies │ comes alive as part │ │ │
│ runtime firmware, │ of runtime firmware │ │ │
│ derives Alias Key │ init (in-band, on │ │ │
│ (DICE chain done │ this same clock) │ │ │
│ by t1 — see §2.2) │ │ │ │
│ │
└────────────────────────────── all of this is BEFORE the host can talk to the controller ───────┘
│
├── [optional, policy-gated] host/BMC
│ runs SPDM: GET_CERTIFICATE →
│ CHALLENGE → GET_MEASUREMENTS
│ (§2.5 — off critical path if BMC/
│ NVMe-MI driven; in series, adding
│ real wall-clock, if the host must
│ attest before mounting/unlocking)
│
└── [if encrypted] TCG Opal / OCP L.O.C.K.
MEK unlock, possibly gated on the
attestation result above
2.1 Before CC.EN: silicon and PCIe link bring-up
Before the host ever writes CC.EN=1, the controller's own power-on sequencing has already run — PCIe link training, clocks, and Caliptra's ROM executing as the very first instructions on the controller's RISC-V core (its RTM role). This is invisible to the host; it happens inside whatever time the controller takes to present a working PCIe endpoint at all.
2.2 Between CC.EN and CSTS.RDY: the DICE chain completes here
This is the window where the entire measured-boot chain from caliptra has to finish, because CSTS.RDY=1 is the controller telling the host "I am ready to be trusted with commands" — it would be backwards for that bit to go high before the controller has verified its own firmware:
- ROM measures and PQC-signature-verifies FMC before executing it.
- FMC measures and PQC-signature-verifies runtime firmware, deriving
LDevID→Alias Keysin the process. - Runtime firmware starts, which is also when the SPDM responder itself comes up — it's part of the same runtime firmware image that just got measured and verified, so by the time SPDM can answer a request, its own integrity is already the thing that was just checked.
How much clock time this actually costs: from caliptra's Adams Bridge performance figures (600 MHz), an ML-DSA-87 verification is ≈18,252 cycles (~0.030 ms) and a signature is ≈134,473 cycles (~0.224 ms). Even a boot chain that does several such checks (ROM→FMC, FMC→runtime FW, maybe a config/manifest check) and runs each one in hybrid mode — both a classical ECDSA check and a PQC check, per the dual-signing transition pattern in pqc — is spending on the order of a millisecond or two of pure cryptographic verification time. That's negligible next to §2.3's number.
2.3 The dominant cost: CSTS.RDY itself
CAP.TO sets the worst-case bound the host will wait (500 ms increments — a drive can legally take a while before a host gives up). What real enterprise NVMe drives actually take in practice is a useful anchor: Samsung's PM9A3 datasheet specifies a typical Drive Ready Time of 8 seconds for its 960 GB–7.68 TB capacities and 20 seconds for the 15.36 TB model, defined explicitly as "maximum time to be ready for receiving commands after power-up (CSTS.RDY=1)." That capacity scaling is the tell: the dominant cost here is NAND initialization and FTL/mapping-table load (see ftl), not the security chain — the security chain's millisecond-or-two from §2.2 is riding inside a multi-second budget that's already dominated by something else entirely. Put differently: secure boot doesn't meaningfully move CSTS.RDY on a drive that was already taking seconds to load its mapping tables.
2.4 Namespace readiness isn't a separate hardware gate
Unlike CSTS.RDY, there's no distinct "namespace ready" bit in the NVMe base spec — a namespace becomes usable once Identify Namespace / the Active Namespace List succeeds against a controller that's already at CSTS.RDY=1. In practice, per-namespace state (particularly for very large capacities, or many namespaces on one controller) can still be warming up in the background after CSTS.RDY, which is the practical reason vendor documentation ties "time to ready" to capacity the way the PM9A3 numbers above do. None of that is security-chain-related — it's the same FTL/mapping-table story, just sliced per-namespace instead of per-controller.
2.5 SPDM attestation: the one piece that's a genuine policy choice, not a fixed step
Everything in §2.2 happens unconditionally, inside the drive, before CSTS.RDY — there's no "skip Caliptra" option. SPDM attestation by an external verifier is different: it's a request the host, a BMC, or a platform verifier chooses to make, and where it falls on the timeline depends entirely on deployment policy:
- Out-of-band (NVMe-MI, BMC-driven) — can run on a completely separate physical interface (SMBus/I2C) in parallel with host-side boot, or even before the host is allowed to see the drive at all in a supply-chain-attestation-gated platform. This is off the host's critical path entirely.
- In-band (DSP0286, host-driven, over Security Send/Receive) — this happens after CSTS.RDY, since it rides the same admin command path everything else in §2.4 uses. Whether it blocks first read/write is a policy decision: a platform that treats "unattested" the same as "untrusted" will hold off issuing I/O (or unlocking TCG Opal/OCP L.O.C.K. media keys, per caliptra's key hierarchy) until
CHALLENGE_AUTH/GET_MEASUREMENTScome back clean; a platform that treats attestation as monitoring/audit rather than a gate can issue I/O immediately and attest concurrently or after the fact.
The actual added latency if it is made blocking is small relative to §2.3's multi-second budget — a CHALLENGE/GET_MEASUREMENTS round trip is dominated by one signature operation (again sub-millisecond per §2.2's numbers) plus ordinary command round-trip time — but it's the one place in this whole chain where "does this add to time-to-first-I/O" is a deployment decision rather than a fixed architectural fact.
3. Summary Table: What's Fixed vs. What's a Policy Choice
| Step | On critical path to CSTS.RDY? | Adds meaningful latency? |
|---|---|---|
| Caliptra ROM measures/verifies FMC | Yes, always | No — sub-ms, dwarfed by NAND/FTL init |
| FMC measures/verifies runtime FW, derives Alias Keys | Yes, always | No — same order of magnitude |
| SPDM responder init | Yes (part of runtime FW bring-up) | No — not a distinct step, rides along |
| NAND init / FTL mapping-table load | Yes, always | Yes — this is the actual multi-second cost |
| SPDM attestation, out-of-band (NVMe-MI/BMC) | No — parallel, separate bus | No, by construction |
| SPDM attestation, in-band (DSP0286), non-blocking policy | No — happens after CSTS.RDY, concurrent with/after first I/O | Minimal |
| SPDM attestation, in-band (DSP0286), blocking policy | Effectively yes, for first I/O even though CSTS.RDY already happened | Small but real — one round trip + one signature |
| TCG Opal / OCP L.O.C.K. MEK unlock gated on attestation | Only if policy requires it | Adds the KMS round trip from caliptra's HPKE exchange, on top of the SPDM cost above |
4. Open Questions / Next Steps
- [ ] Pin down the actual NVMe base spec CAP.TO default/max value and confirm the 500 ms unit from primary spec text rather than secondary sources — this session's fetch attempts against nvmexpress.org's own spec PDFs were inconclusive.
- [ ] Find a primary-source (not paywalled/403'd) copy of the OCP Datacenter NVMe SSD Specification's exact Time-to-Ready requirement language, including whether it defines a separate "Extended Time to Ready" for post-firmware-activation boots — this document's numbers came from one vendor datasheet (Samsung PM9A3), not the OCP spec text itself.
- [ ] Check whether any shipping drive's datasheet breaks out attestation/SPDM latency as a distinct line item, the way PM9A3 breaks out Drive Ready Time — would confirm or correct the "negligible" claim in §2.5 with real silicon numbers instead of derived Adams Bridge cycle counts.
- [ ] Determine whether the Linux kernel's in-progress CMA-SPDM reauthentication (noted in spdm §5a) triggers on every NVMe resume-from-suspend, and if so, whether that's a bigger contributor to resume latency than boot-time attestation is to cold-boot latency.
- [ ] Confirm whether OCP L.O.C.K.'s remote-KMS HPKE exchange (caliptra §"OCP L.O.C.K.") is architecturally required to happen after SPDM attestation succeeds, or whether they're actually independent gates that a platform integrator could sequence either way.
Sources
- Samsung — PM9A3 NVMe U.2 Datasheet (Drive Ready Time / CSTS.RDY specification, Table 6)
- metebalci.com — A Quick Tour of NVM Express (NVMe): CAP.TO, CC.EN, CSTS.RDY, admin queue setup walkthrough
- NVM Express — NVMe Readiness, Part Three
- OCP — Hyperscale NVMe Boot SSD Specification v1.0
- OCP — Datacenter NVMe SSD Specification v2.6
- caliptra, spdm, pqc, ftl (this project) — the four docs this page synthesizes