Caliptra: Open-Source Silicon Root of Trust

A working page on Caliptra, the CHIPS Alliance / OCP open-source silicon root-of-trust (RoT) block. Cross-reference: pqc — Caliptra's Adams Bridge engine and OCP L.O.C.K. are essentially the reference silicon implementation of the firmware-signing / key-management story described there.

What It Is

Caliptra is a standardized, open-source RoT subsystem for datacenter System-on-Chip devices — CPUs, GPUs, DPUs, TPUs, and storage controllers. It originated as an Open Compute Project (OCP) specification and is now developed as open-source RTL/firmware within the CHIPS Alliance (a Project of LF Projects, LLC). The pitch is standardization: rather than every silicon vendor building a bespoke RoT, cloud operators get a common, auditable, open-source block they can require and verify across vendors.

It covers three RoT roles:

• RTM — Root of Trust for Measurement: measures and verifies code/configuration integrity at boot.
• RTI — Root of Trust for Identity: provides cryptographic device identity for attestation, built on TCG DICE.
• RTU/RTRec — Root of Trust for Update / Recovery: manages secure firmware updates and recovery.

Core backers include Microsoft, Google, NVIDIA, and AMD, with Intel, Meta, and other major datacenter operators contributing requirements and validation.

Hardware Architecture

• A RISC-V microcontroller core executes the immutable ROM plus mutable firmware layers (FMC — first mutable code — and runtime firmware).
• Crypto engines: SHA, HMAC, ECC, LMS (hash-based signatures), and — as of 2.0/2.1 — the Adams Bridge PQC accelerator (below).
• A hardware key vault holds sensitive key material; a watchdog timer monitors system health; fuses/OTP hold immutable per-device secrets (this is the hardware root that everything else derives from).
• DICE identity hierarchy: IDevID (hardware-rooted manufacturing identity, non-renewable) → LDevID (field-programmable, enables ownership transfer) → Alias Keys (firmware-specific signing credentials derived from the parent identity). Each layer's key is cryptographically bound to a measurement of the layer above it — classic DICE "measure then derive" composition.
• DPE (DICE Protection Environment) API — lets Caliptra act as a cryptographic oracle for SPDM (Security Protocol and Data Model) implementations elsewhere in the SoC, so other components can request attestation/signing services without needing their own RoT.

Three integration modes, increasing in scope:

1. Passive Mode — Caliptra anchors the boot chain of trust; the SoC's own logic handles updates.
2. Subsystem Mode — Caliptra is the full RoT, including streaming boot for resilient recovery.
3. Subsystem w/ OCP L.O.C.K. — adds hardware-isolated key management and media encryption support (this is the mode that matters for storage — see below).

Repository / Component Map

Repo	Contents
caliptra-rtl	Immutable RTL and hardware specification
caliptra-sw	ROM, FMC, and runtime firmware (1.x and 2.x branches)
caliptra-ss	Subsystem architecture, incl. Manufacturer Control Unit
adams-bridge	Post-quantum cryptography hardware accelerator
caliptra-dpe	TCG DICE Protection Environment implementation
caliptra-mcu-sw	MCU firmware and SDK

Components version independently (semver), with security version numbers tracked separately for mutable firmware.

Version History

Version	Highlights
1.x	ECC/LMS hardware acceleration, manifest-based image authorization, DPE CDI export
2.0	ML-DSA support (Adams Bridge introduced), OCP Recovery, Subsystem architecture, crypto offload services
2.1 (RTL released Oct 15, 2025)	Adams Bridge 2.0 — adds ML-KEM alongside ML-DSA, with side-channel protections; OCP L.O.C.K. for self-encrypting storage key management; ownership transfer; streaming boot; AES DMA mode

Adams Bridge — the PQC Hardware Engine

Adams Bridge is Caliptra's dedicated post-quantum crypto accelerator — pure hardware, not a software fallback, covering the NTT (Number Theoretic Transform), hashing, and rejection-sampling steps that dominate ML-DSA/ML-KEM cost.

• Implements ML-DSA-87 only (not the lower security levels) — this is a deliberate CNSA 2.0 alignment choice: "CNSA 2.0 only allows the highest security level (Level-5) for PQC, which is ML-DSA-87."
• 2.1 adds ML-KEM support to the same engine.
• Performance at 600 MHz: keygen ≈ 15,154 cycles (~~0.025 ms, ~39,600 ops/sec); signing ≈ 134,473 cycles average (~~0.224 ms, ~~4,460 ops/sec); verification ≈ 18,252 cycles (~~0.030 ms, ~32,900 ops/sec). Signing is the expensive operation, as expected for lattice schemes.
• Internals: a Keccak core (SHAKE128/256) for sampling/hashing, a merged-layer NTT engine with four pipelined butterfly cores for polynomial multiplication, FIFO-buffered rejection samplers to avoid stalls, and modular reduction hard-wired to ML-DSA's prime (q = 8,380,417).
• Side-channel masking countermeasures reportedly cost zero cycles — only silicon area — which is a notable design result if it holds up in independent review.

This directly answers the "who actually builds the PQC engine" question left open in pqc — Adams Bridge is a concrete, open-source answer for the signing/attestation side, separate from any given SSD controller vendor's own implementation.

OCP L.O.C.K. — the Storage Tie-In

L.O.C.K. = Layered Open-source Cryptographic Key-management. This is the piece that connects Caliptra directly to self-encrypting SSDs, and it's implemented as Caliptra Subsystem 2.1+'s storage mode.

The goal: manage Media Encryption Keys (MEKs) for a drive's TCG Opal / Enterprise SSC / Key-Per-I/O encryption without the drive's own firmware ever seeing a plaintext key. Three collaborating pieces:

• Drive firmware — orchestrates storage operations and MEK lifecycle, but only ever calls into Caliptra services; never handles plaintext key material directly.
• Caliptra Key Management Block (KMB) — the only component that can read MEKs and program them into the encryption hardware. Contains immutable ROM, runtime firmware, the hardware key vault, and an entropy source.
• Encryption engine — does the actual AES encrypt/decrypt, holding keys only in volatile cache during active I/O.

Key hierarchy (each layer requires the one below to unlock):

HEK (Hard Epoch Key)  — device-unique, derived from Caliptra's UDS (unique device secret)
  → SEK (Soft Epoch Key)  — firmware-rotatable
    → MPK (Master Protection Key)  — requires remote KMS authorization via HPKE-encrypted exchange
      → DPK (Data Protection Key)  — owner-managed credential

This is a multi-party authorization model: getting to a usable MEK requires satisfying several independent layers simultaneously (device identity, firmware state, remote key-manager approval, and owner credential), so no single compromised component — firmware, a stolen device, or a compromised KMS — is sufficient on its own to expose data.

OCP L.O.C.K. collaborators named alongside the 2.1 release: Samsung, Kioxia, Solidigm — i.e., the actual SSD/NAND vendors, not just the silicon-IP side. Kioxia in particular already showed up in pqc as an early NVMe 2.4 PQC silicon adopter (CM10 series), which makes it a good candidate to check for direct Caliptra/L.O.C.K. adoption.

Open Questions / Next Steps

• [ ] Confirm whether Kioxia CM10 / ScaleFlux FC6116 (referenced in pqc) actually embed a Caliptra subsystem, or an independent RoT implementation that happens to target the same NVMe 2.4 PQC hooks.
• [ ] Read the OCP L.O.C.K. spec (v1.1 RC4, opencompute.org) for the exact MEK provisioning protocol and the HPKE exchange with a remote KMS.
• [ ] Check silicon area/cost overhead of the full Caliptra subsystem + Adams Bridge — is this realistic for cost-sensitive client SSD controllers, or enterprise/datacenter only?
• [ ] Track the roadmap past 2.1 — next major version, and whether FN-DSA (Falcon) or SLH-DSA ever get added to Adams Bridge alongside ML-DSA/ML-KEM.
• [ ] Compare the DICE/SPDM attestation model here against the TPM 2.0 PQC integration mentioned in pqc — overlapping or complementary trust roots?