Home › IP Core › Attestation Engine
DICE ATTESTATION ENGINE

Device Identity Composition Engine — Deep Dive

The zeroRISC attestation engine implements DMTF DSP0267 DICE, generating a layered certificate chain from the on-chip Unique Device Secret through to the application layer. Hardware-rooted, verified at every boot stage.

Schedule Technical Briefing
ABOUT DICE

What DICE is and why it matters for silicon

DICE (Device Identity Composition Engine) is a DMTF specification (DSP0267) that defines how a device establishes its hardware-rooted identity. It establishes a layered identity chain: each boot stage measures the next stage's code, derives a fresh identity key, and signs a certificate attesting to the measurement.

Unlike TPM-centric approaches, DICE operates with a hardware-isolated Unique Device Secret (UDS) that is never exposed after provisioning — all derived keys are generated on-chip and certificate signing uses ephemeral keys derived from the CDI chain.

The practical result: a remote verifier can cryptographically confirm not just that a device is authentic, but exactly what firmware it is running — stage by stage — without sharing any device secret off-chip.

REFERENCE STANDARD
DMTF DSP0267 v1.2.0
Device Identity Composition Engine (DICE) Architecture
KEY PROPERTIES
  • Hardware-isolated UDS — never exported
  • Per-boot CDI derivation — replay-resistant
  • X.509 attestation certificates — standard format
  • Composable with TPM 2.0 PCR-based attestation
CERTIFICATE CHAIN

UDS → CDI_0 → CDI_1 → Application Certificate

Each stage in the derivation chain is anchored to the previous stage's measurement and bound to the firmware hash of the next stage. Certificates are in standard X.509 DER format and can be verified by any DICE-aware verifier.

UDS
256-bit hardware secret, OTP-provisioned at manufacturing. Never exported. Protected by physical isolation and FIPS 140-3 Level 3 tamper response.
HKDF-SHA256(UDS ‖ ROM_hash)
CDI_0
Compound Device ID bound to ROM hash. Signs the CDI_0 attestation certificate, which vouches for the ROM layer's integrity.
HKDF-SHA256(CDI_0 ‖ FW_hash)
CDI_1
Compound Device ID bound to first-stage firmware hash. Signs the CDI_1 certificate vouching for firmware layer integrity.
ECDSA-P384 signing key derived from CDI_1
App Cert
Application-layer X.509 certificate. Presented to remote verifiers. Contains firmware version, measured hash, and device identity extension fields.
CERTIFICATE FORMAT
Format: X.509 v3, DER-encoded
Signature: ECDSA-P384 with SHA-384
Extensions: DICE TcbInfo, FIDO Device Onboard
Lifetime: Per-boot regeneration (ephemeral)
WHAT THE CHAIN PROVES
  • Device is genuine (UDS provisioned by zeroRISC)
  • ROM has not been modified since provisioning
  • First-stage firmware matches expected hash
  • Certificate chain is cryptographically unforgeable
ATTESTATION API

Register interface and command surface

Register Offset Access Description
ATTEST_CTRL 0x000 RW Attestation command register. Write command opcode to initiate sequence.
ATTEST_STATUS 0x004 RO Completion status, error code, and chain-valid bit.
CDI0_CERT_ADDR 0x010 RO Base address pointer to CDI_0 X.509 DER certificate in SRAM output buffer.
CDI0_CERT_LEN 0x014 RO Byte length of CDI_0 certificate. Valid after ATTEST_STATUS.VALID = 1.
CDI1_CERT_ADDR 0x018 RO Base address pointer to CDI_1 X.509 DER certificate in SRAM output buffer.
CDI1_CERT_LEN 0x01C RO Byte length of CDI_1 certificate.
APP_CERT_ADDR 0x020 RO Base address of application-layer certificate.
ATTEST_INTR_STATE 0x030 RW1C Interrupt state. Bit[0]: done; Bit[1]: error. Write 1 to clear. 
// Example: initiate full attestation chain
REG32(ATTEST_BASE + ATTEST_CTRL) = 0x01;  // cmd: ATTEST_FULL_CHAIN

// Poll until complete
while (!(REG32(ATTEST_BASE + ATTEST_STATUS) & 0x01));

// Read certificate length and copy from SRAM buffer
uint32_t len = REG32(ATTEST_BASE + APP_CERT_LEN);
uint8_t *cert = (uint8_t *)REG32(ATTEST_BASE + APP_CERT_ADDR);
Schedule Briefing Full API Reference