As a member of the wolfSSL team, each day is a new opportunity to learn. This time, we delve into Caliptra and our plans for it in the near future.
Architecture and Purpose
Caliptra isn’t just a piece of software or hardware, it is a specification for software combined with hardware as its own module, independently running within the silicon. This module acts as something that combines the functionality of an embedded HSM, the root in a chain of bootloaders, and an attestation agent. Caliptra is not meant for embedded systems. The main use case is for high-performance systems in data centres to satisfy requirements related to remote attestation and supply chain integrity.
The title refers to Caliptra as the chaperone. This is because, similar to wolfHSM, it runs as a completely separate module independent of the main application processors, accompanying them throughout the lifetime of the system.
From an attestation perspective, this is useful as it means the private keys that identify the device are populated at manufacturing time and never seen by anyone and can never be accidentally exposed by the application. We’ve all heard stories of AI agents being tricked into sending their private keys to malicious actors. Well, this can’t happen if nothing has access to those keys.
From a supply chain perspective, Caliptra can guarantee that only application firmware that is meant to run on that device can live on that device. Upon boot up of the silicon, Caliptra is the very first module that will execute. A public key used for verification of the next bootloader in the boot chain is populated at manufacturing time, so the next bootloader must be signed by the corresponding private key. For example, the next element in the boot chain could be wolfBoot. Since this is the first element of the boot chain, it is known as the “root of trust,” and thus the name Caliptra was born. In Spanish, Caliptra translates to “root cap”.
Firmware measurement is the process of computing a cryptographic hash of a firmware image or configuration data at boot time, before execution is transferred to that component. The resulting hash value which is the measurement, serves as a compact, tamper-evident fingerprint of exactly what software was loaded. If the firmware has been modified in any way the measurement will differ. These measurements are recorded in a tamper-resistant store so that later, any party can determine whether the system booted the expected, unmodified software. Note that a cryptographic verification also achieves the same goal.
All of this is guaranteed by the strength of cryptographic algorithms. The specification is forward looking in that it requires support for conventional and quantum-safe algorithms (ECC, RSA, LMS, ML-DSA, ML-KEM, etc.). Operations for these algorithms are done by Caliptra using a special mailbox protocol. This is done for the purposes of OCP-LOCK and SPDM.
OCP-LOCK stands for Open Compute Project Layered Open-source Cryptographic Key-management. It is a methodology that guarantees keys are always wrapped, plaintext keys never leave Caliptra, and erasure of storage can be cryptographically attested.
SPDM stands for Security Protocol and Data Model. This is the protocol that is used when a third party needs the machine to identify itself. Caliptra holds that identity information and is the only thing that can attest to that identity.
DICE (Device Identifier Composition Engine) is a specification that establishes a layered cryptographic identity rooted in a hardware secret provisioned at manufacturing time. At each stage of the boot sequence, a unique identity called a Compound Device Identifier (CDI) is derived by combining the previous layer’s identity with a measurement of the next component to be loaded. This creates a chain where each layer’s identity is mathematically bound to everything that ran before it.
DPE (DICE Protection Environment) is another specification that takes DICE a step further: rather than having firmware components handle raw CDI values directly, all DICE derivation and key operations are delegated to an isolated execution environment which is called the DPE. Firmware components interact with the DPE only through opaque context handles, so CDI values and private keys never leave the protected environment. DICE defines the cryptographic construction; DPE defines the isolated service that performs that construction safely on behalf of the rest of the system.
A Platform Configuration Register (PCR) is a special hardware register with an unusual write constraint: it cannot be overwritten directly. The only permitted operation is Extend — a one-way cryptographic accumulation where the new value is computed as a hash of the current register contents concatenated with the incoming measurement. This ratchet property means that once a measurement has been recorded, it cannot be erased or rendered irrelevant without a full power cycle. A PCR Vault is a hardware-protected collection of these registers, held in an isolated domain inaccessible to application firmware. Together, the vault’s registers accumulate a tamper-evident record of every component measured during the boot sequence, which can later be referenced for attestation or as inputs to key derivation.
Of particular note, the reference software for Caliptra (which can be found at https://github.com/chipsalliance/Caliptra) is written in Rust but does not actually have any algorithm implementations; there are callback registration APIs that are supposed to be set to hardware-accelerated functions. The exception is LMS, where, similar to wolfBoot, there is a verification-only implementation for verifying the boot chain.
So what does any of this have to do with wolfSSL?
Cryptographic Implementations
While the registered callbacks are meant to call hardware accelerators, some of our silicon partners that are looking to quickly start prototyping their Caliptra implementations might want to do a quick start with implementations from wolfCrypt. If you are such a partner, please do reach out and contact us; we can help! We will even implement it in Rust.
wolfSPDM
The SPDM software stack runs on the application processor. When an attestation response or a measurement quote is required, it calls into Caliptra via the mailbox protocol. Here at wolfSSL, we have implemented the SPDM stack as a library that is called wolfSPDM. Let us know about your plans for DICE (Device Identifier Composition Engine) and your needs for wolfSPDM.
Finally, the real big picture item is too big for this already long blog post. Tune in and watch out for part 2!
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247
Download wolfSSL Now