How DICE Secures IoT Devices: From Unique IDs to Fast Boot

Background

With the rapid growth of the IoT ecosystem, the number of IoT devices worldwide has reached the hundred‑billion level. At the same time, attacks that use IoT devices are increasing year by year, making IoT security a severe challenge. Because IoT devices vary widely in type and computational capability, existing PC or mobile security policies cannot be fully reused.

The Trusted Computing Group (TCG) therefore introduced the DICE (Device Identity Composition Engine) standard to provide a unified device identity mechanism for various terminal devices and to enhance device security.

DICE has already gained support from ARM, Microsoft, Google, NXP and other companies, and will be further promoted in IoT, smartphones and other terminals.

Key Terminology

DICE engine: The program loaded from ROM at boot time that is executed with unconditional trust.

TCB (Trusted Computing Base): The set of components executed during system boot.

TCI (TCB Component Identifier): A measurement of the TCB, e.g., the hash of the TCB firmware.

UDS (Unique Device Secret): A device‑unique secret value accessible only to the DICE layer; lower TCB layers cannot read it directly.

CDI (Compound Device Identifier): The secret value of each TCB layer.

OWF (One Way Function): A one‑way function that generates a fixed‑length output from input parameters, such as HMAC‑SHA256.

ECA (Embedded Certificate Authority) Key: The asymmetric key that the current TCB layer uses to issue certificates for itself or the next TCB layer.

IDevID: Device ID controlled by the device manufacturer.

DevID: Device ID controlled by the device owner.

Chain‑Derived CDI Mechanism

DICE creates a unique secret for each TCB layer by chaining CDI derivation from the UDS. When a layer’s code or configuration changes, its secret changes as well, allowing patch‑based updates to generate new secrets automatically.

Key Derivation from CDI

Each TCB layer derives an asymmetric key pair (AKey) from its own CDI, and a symmetric key (SKey) from the combination of CDI and TCI.

Certificate Generation

Each TCB layer uses its AKey to generate its own ECA certificate.

The ECA certificate of layer Ln signs the AKey certificate of layer Ln+1.

Alternatively, an external CA can sign the AKey certificate of a layer.

Note: Certificates do not contain any private key material.

Business Scenarios

Device Identification

Manufacturer CA L0 certificate → TCB L0 → IDevID L0

ECA L0 certificate → TCB L1 → IDevID L1

Owner CA L2 certificate → TCB L2 → LDevID L2

External parties can identify each device and each TCB layer using the hierarchical DevID.

Device Proof

TCB derives an Alias Key from its CDI and current firmware information.

The DeviceID Key’s ECA certificate signs the Alias Key, producing an Alias Cert.

Alias Cert contains key information such as configuration, firmware version and hash.

Devices can present the Alias Cert to prove their state to external parties.

Secure Boot

DICE devices can use the automatically derived ECA certificate chain to implement secure boot, similar to Qualcomm’s secure‑boot chain.

Fast Startup

After a firmware update, the device validates the secure‑boot chain once, then uses the CDI‑derived symmetric key (SKey) to compute an HMAC of the firmware for subsequent rapid boots.

Data Protection

Using UDS and optional layer‑0 information, DICE derives symmetric keys to encrypt sensitive device data.

Firmware Upgrade

DICE devices can trigger secure OTA updates based on device proof. The upgrade flow includes reporting the Alias Cert, receiving signed upgrade commands, verifying signatures of the upgrade package, performing the firmware upgrade, and re‑deriving DICE keys and certificates after a successful update.

Summary

DICE provides a unified device identity mechanism supporting identification, proof, secure boot, fast startup and data protection, with strong security, robustness and scalability.

It is compatible with existing secure‑boot and OTA mechanisms, offering high flexibility.

TCB firmware can be upgraded independently without requiring higher‑level private keys for secure‑boot certificates.

CDI‑derived symmetric keys enable rapid startup for resource‑constrained IoT devices.