Attestation is the mechanism by which a remote verifier establishes confidence that a device is running the software it claims to be running, on hardware that has not been tampered with. For that assurance to be meaningful, the evidence must be rooted in hardware — specifically, in a measurement process that an attacker cannot forge without physical access to the device's unique secret material. DICE (Device Identity Composition Engine), specified by the DMTF as DSP0267, provides the compositional framework for constructing that chain of evidence from silicon to application layer.
This article traces the full DICE derivation from manufacturing seed through CDI_0, CDI_1, to the application certificate, explaining what each stage proves and what assumptions it requires. The implementation context is the OpenTitan-based key manager (keymgr) block as used in zeroRISC's root-of-trust IP core.
The DICE Trust Architecture: Three Core Concepts
Before tracing the derivation chain, three concepts need to be precise.
Unique Device Secret (UDS). The UDS is the device-unique root of trust for identity. It is provisioned at manufacturing into OTP storage and never leaves the device. The UDS must be accessible only to the first DICE layer — the immutable boot stage — and must be erased from hardware registers before any subsequent software layer begins execution. This destruction is not optional; it is the mechanism that prevents software from accessing the root key material.
Compound Device Identifier (CDI). A CDI is derived from a previous CDI (or from the UDS, for the first derivation) combined with a measurement of the next software layer. The measurement is typically a cryptographic hash of the firmware image and its configuration. The CDI derivation is one-way: given a CDI_N, it is computationally infeasible to recover the UDS or any CDI at a lower layer index. Each CDI is specific to the combination of the UDS (anchored in hardware) and the complete chain of software measurements from boot to the current layer.
Certificate chain. Each DICE layer generates an asymmetric key pair derived from its CDI and issues a certificate binding that key pair to the layer's identity and measurements. The chain of certificates from the device identity certificate (anchored to UDS) through the boot certificates constitutes the attestation evidence a remote verifier can evaluate.
Layer 0: UDS Provisioning and the Manufacturing Seed
UDS provisioning occurs at manufacturing, before the device enters the field. The provisioning process must occur in a controlled environment, because the UDS is the ultimate root of every identity the device will ever possess. The DICE specification does not mandate a specific provisioning mechanism, but the OpenTitan lifecycle and provisioning architecture defines a structured provisioning flow through the TEST_UNLOCKED lifecycle state.
In the OpenTitan model, the UDS is provisioned into a dedicated OTP partition that is access-controlled by the lifecycle controller. The partition is readable only by the ROM controller during the first boot layer's execution. When the lifecycle controller transitions the device from TEST_UNLOCKED to PROD (via a token-authenticated command), the OTP partition containing the UDS is locked against further write access, and the lifecycle state itself is programmed into a separate OTP partition with a one-way fuse structure that prevents reversal.
The UDS is typically 256 or 384 bits, depending on the chosen DICE implementation and the key derivation function in use. For an ECDSA-P384-based implementation, a 384-bit UDS provides sufficient entropy for the initial key derivation. The UDS must be generated with a physical true random number generator (TRNG) that meets SP 800-90B requirements — not with a PRNG seeded from a manufacturing fixture timestamp, which is a pattern that has appeared in embedded device UDS implementations and produces dramatically reduced effective entropy.
CDI Derivation: The Key Manager Ladder
The OpenTitan key manager (keymgr) implements the CDI derivation ladder. The derivation uses KMAC (Keccak Message Authentication Code, per NIST SP 800-185) as the core KDF operation. The keymgr advances through discrete stages, each corresponding to a DICE layer transition:
UDS (OTP, 256/384b)
|
v
[KMAC(UDS, ROM_digest || device_id)]
|
v
CDI_0 (Creator Identity)
|
v
[KMAC(CDI_0, owner_firmware_hash || owner_seed)]
|
v
CDI_1 (Owner Identity)
|
v
[KMAC(CDI_1, app_firmware_hash || app_seed)]
|
v
CDI_2 (Application Identity)
The keymgr hardware enforces stage ordering: it is impossible to advance from CDI_0 to CDI_1 without first completing the CDI_0 derivation, and the CDI_0 derivation requires that the ROM integrity check has passed. An attempt to advance the keymgr stage without providing the required measurement inputs triggers an alert and locks the keymgr.
At each stage, the keymgr exposes derived key outputs to authorized software — the current-stage CDI can be used to generate attestation signing keys or sealing keys, but the actual CDI value is not software-readable. This is a critical distinction: software gets key material derived from the CDI, not the CDI itself. An attacker who compromises the application layer cannot recover the CDI_1 or CDI_0 values; they can only use keys the current stage's software has already derived.
Attestation Certificate Generation
Each CDI layer generates an asymmetric key pair for attestation. In the OpenTitan model, this is an ECDSA P-384 key pair derived deterministically from the CDI using the keymgr's identity key generation function. The private key is ephemeral in the sense that it lives in hardware registers, not in persistent storage — it must be re-derived each boot. The public key is embedded in the attestation certificate for that layer.
The certificate structure follows X.509 v3 with DICE-specific extensions defined in the DMTF DSP0267 specification. Key fields include:
subjectAltNameextension containing the DICE hardware identity — a structured field encoding the firmware digest that went into the CDI derivationkeyUsagelimiting the certified key to digital signature and certificate signing (if the layer is a CA for sub-layer certificates)- Custom DICE extension OIDs encoding the firmware measurement algorithm, the firmware image digest, and the authority configuration digest
The Layer 0 certificate (Creator Identity Certificate) is self-signed or signed by a provisioning CA certificate whose key is stored in the OTP provisioning partition at manufacturing. The Layer 1 certificate (Owner Identity Certificate) is signed by the Creator Identity key. This signature chain allows a verifier who trusts the provisioning CA to verify the entire certificate chain without having prior knowledge of the specific device's identity.
What the Verifier Actually Receives
When a remote verifier requests attestation from a device, it receives a certificate chain: provisioning CA certificate (or self-signed device certificate) → Creator Identity Certificate → Owner Identity Certificate → Application Certificate. The verifier evaluates this chain by:
- Verifying each certificate's signature using the issuing certificate's public key
- Checking that the firmware digests in the DICE extensions match expected values for the software that should be running on the device
- Checking that the lifecycle state extension (if present) indicates PROD, not DEV (DEV-state devices have relaxed debug access and should not be trusted in production deployments)
- Verifying the certificate chain up to a trusted root — either the provisioning CA certificate stored in the verifier's trust store, or the device manufacturer's PKI root
The critical assurance DICE provides is measurement binding: the attestation key used to sign any application-layer data is only available if the complete boot sequence has run in its expected configuration. An attacker who modifies the firmware image cannot produce a valid attestation signature under the expected certificate, because modifying the firmware changes the CDI derivation input and therefore changes the derived attestation key.
The Limits of Hardware Attestation
We are not saying that DICE attestation eliminates all remote attestation attack surfaces. A device in PROD lifecycle state with an unmodified firmware stack will produce valid DICE attestation evidence — but DICE does not attest to the runtime behavior of software after boot. A firmware image that passes DICE measurement can still contain exploitable vulnerabilities that are exercised at runtime. DICE attestation tells you what ran at boot, not what the software did subsequently.
There are also documented attack scenarios against TEE attestation mechanisms that exploit cache timing and speculative execution side-channels to exfiltrate attestation key material after the CDI derivation has completed. These attacks — variants on the research following Spectre-class vulnerabilities applied to trusted execution environments — operate at a layer above DICE's hardware derivation chain, targeting the software that holds the derived attestation keys in working memory. Hardware attestation reduces the attack surface substantially; it does not eliminate software-layer key management vulnerabilities.
Additionally, DICE attestation relies on the integrity of the provisioning process. If UDS provisioning at manufacturing was performed incorrectly — for example, if UDS values were provisioned from a reduced-entropy source, or if the same UDS was provisioned to multiple devices — the attestation chain is structurally sound but the uniqueness guarantee is broken. Manufacturing process integrity is a prerequisite for DICE attestation integrity, not a consequence of it.
Integrating DICE Attestation into a Verification Infrastructure
Deploying DICE attestation in production requires a server-side verification infrastructure: a certificate transparency log or database of valid device certificates, a verification service that evaluates incoming attestation chains, and a trust store containing the provisioning CA certificates for all device families in deployment.
For OEMs building products with DICE-attested root-of-trust blocks, the provisioning CA key management is a significant operational consideration. The provisioning CA key must be available during manufacturing (to sign device certificates), must be protected against compromise (since compromise allows forging device certificates), and must have a defined rotation plan. Hardware Security Module (HSM) protection for the provisioning CA key is standard practice; the provisioning CA key should never exist in software-accessible memory during production manufacturing.
The verification infrastructure also needs to handle the case of legitimate firmware updates, which change the firmware digest in the DICE extensions and therefore produce different CDI values after update. This means the verifier's expected-measurement database must be updated to include new firmware digests before new firmware versions are deployed, and the update process must be authenticated end-to-end to prevent rollback attacks that revert devices to firmware versions with known vulnerabilities. DICE gives you the measurement substrate; the policy layer that acts on those measurements is the OEM's design responsibility.