Device Identifier Composition Engine (DICE)

DICE creates a compound device identity by cryptographically layering each stage of the boot process. Each firmware layer receives a unique secret derived from the previous layer's identity and the hash of the next layer's code. This creates a chain of trust where:

• The Unique Device Secret (UDS) is fused into silicon at manufacturing
• Each boot layer generates a Compound Device Identifier (CDI)
• If any firmware layer changes, all subsequent CDIs change
• This enables automatic identity rotation on firmware updates

DICE eliminates the need for a discrete Trusted Platform Module (TPM) by embedding attestation directly into the boot sequence. The engine generates cryptographically verifiable evidence of the device's firmware state:

• Each layer signs an attestation certificate with its derived key
• A verifier can reconstruct the chain to validate firmware integrity
• Supports remote attestation without additional hardware cost
• Ideal for constrained IoT and edge devices where a TPM is impractical

DICE uses HMAC-based key derivation to generate cryptographic identities. The process combines the previous layer's secret with a measurement of the next layer:

• CDI = HMAC(Previous_Secret, Hash(Next_Layer_Code))
• This ensures forward secrecy between boot stages
• Compromising one layer does not expose previous layer secrets
• Enables sealed storage where data is encrypted to a specific firmware configuration

DICE provides cryptographic proof of silicon provenance from fabrication through deployment. The immutable UDS fused during manufacturing establishes the root identity:

• Enables Hardware Bill of Materials (HBOM) verification
• Detects counterfeit or tampered components before deployment
• Supports secure provisioning workflows in untrusted factories
• Integrates with Platform Firmware Resiliency (PFR) for recovery

DICE inherently prevents firmware downgrade attacks through its layered identity model. Since each CDI is a function of the firmware hash:

• Rolling back to a vulnerable version produces a different CDI
• Sealed data becomes cryptographically inaccessible to downgraded firmware
• Attackers cannot replay old attestation certificates
• Works alongside hardware monotonic counters for defense-in-depth

DICE is standardized by the Trusted Computing Group (TCG) and referenced in multiple security frameworks:

• TCG DICE Architecture Specification defines the core layering model
• Aligned with NIST SP 800-193 Platform Firmware Resiliency guidelines
• Supports FIPS 140-3 cryptographic module validation
• Adopted in Open Compute Project (OCP) security profiles for data center hardware
• Complements Secure Boot and Measured Boot implementations

DICE divides the boot process into discrete layers, each with its own code and secrets. A typical layering includes:

• Layer 0: Immutable ROM boot code (the DICE engine itself)
• Layer 1: Device firmware or bootloader
• Layer 2: OS kernel or runtime environment
• Layer 3+: Application-level components Each layer receives a secret from the prior layer, measures the next layer's code, and derives a new secret. This transitive trust model means a compromised layer automatically invalidates all downstream identities, providing cryptographic proof of tampering.

DICE enables a device to cryptographically prove its firmware state to a remote verifier. The process:

1. The final DICE layer derives an attestation key pair from the CDI.
2. The device signs a challenge with this key.
3. The verifier validates the signature against a known-good public key or certificate chain. Because the key is derived from the UDS and firmware measurements, a valid signature proves both device authenticity and software integrity simultaneously. This is foundational for zero-trust device onboarding in sovereign AI infrastructure.