Starting March 27, 2025, we recommend using android-latest-release instead of aosp-main to build and contribute to AOSP. For more information, see Changes to AOSP.
Device Identifier Composition Engine
Stay organized with collections
Save and categorize content based on your preferences.
The Device Identifier Composition Engine (DICE) is a
Trusted Computing Group (TCG) specification
that has been adopted into Android.
It creates a set of strong, immutable cryptographic identities for each piece of firmware loaded
during the boot sequence. These identities enable remote verification of a device's security
posture, which can only be evaded by compromising the ROM.
DICE derivation process
Figure 1. Simplified DICE derivation process.
The DICE derivation process ensures that any change to any firmware image results in a new unique
identifier for that stage and every stage thereafter. This is because each loaded firmware stage
measures and certifies the next, generating unique identities and associated keys that prevent
bypassing or tampering. The read-only memory (ROM)
processes the measurement, configuration, and unique device secret (UDS) with a key derivation
function (KDF) to derive the secret for the next stage to be loaded. This secret is referred to as
a compound device identifier (CDI).
Stage 0: Initialization
The DICE process begins with the chipset’s ROM loading the UDS from a bank of immutable data,
typically fuses. This UDS is securely provisioned with a cryptographically random value during the
chip production process. After reading the UDS, the ROM uses a vendor-dependent hardware-locking
mechanism such as a latch to lock UDS access until the next boot.
Stage 1: Initial key derivation
The ROM uses the UDS as input to a key derivation function (KDF)
to generate the permanent asymmetric key pair that uniquely identifies that device. It measures
the next firmware stage, including metadata about the boot environment such as whether secure boot
is enabled. The ROM then combines the UDS, firmware measurement, and configuration data in the KDF
to derive the first CDI, which is passed to the next stage as a secret.
Stage 2 to n: Recursive key derivation
The process then repeats. In all subsequent stages, the CDI from the previous stage serves as the
input for a new KDF. This KDF uses the CDI and the hash of the next firmware image to produce a
new derived CDI. Each stage generates its own key pair and uses it to sign a certificate
containing stage-specific measurements and other associated metadata.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2025-06-18 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-06-18 UTC."],[],[],null,["# Device Identifier Composition Engine\n\nThe Device Identifier Composition Engine (DICE) is a\n[Trusted Computing Group (TCG) specification](https://trustedcomputinggroup.org/what-is-a-device-identifier-composition-engine-dice/)\nthat has been [adopted into Android](https://pigweed.googlesource.com/open-dice/+/refs/heads/android16-release/docs/android.md).\nIt creates a set of strong, immutable cryptographic identities for each piece of firmware loaded\nduring the boot sequence. These identities enable remote verification of a device's security\nposture, which can only be evaded by compromising the ROM.\n\nDICE derivation process\n-----------------------\n\n***Figure 1.** Simplified DICE derivation process.*\n\n\nThe DICE derivation process ensures that any change to any firmware image results in a new unique\nidentifier for that stage and every stage thereafter. This is because each loaded firmware stage\nmeasures and certifies the next, generating unique identities and associated keys that prevent\nbypassing or tampering. The [read-only memory (ROM)](https://en.wikipedia.org/wiki/Read-only_memory)\nprocesses the measurement, configuration, and unique device secret (UDS) with a key derivation\nfunction (KDF) to derive the secret for the next stage to be loaded. This secret is referred to as\na compound device identifier (CDI).\n\n### Stage 0: Initialization\n\n\nThe DICE process begins with the chipset's ROM loading the UDS from a bank of immutable data,\ntypically fuses. This UDS is securely provisioned with a cryptographically random value during the\nchip production process. After reading the UDS, the ROM uses a vendor-dependent hardware-locking\nmechanism such as a latch to lock UDS access until the next boot.\n\n### Stage 1: Initial key derivation\n\n\nThe ROM uses the UDS as input to a [key derivation function (KDF)](https://en.wikipedia.org/wiki/Key_derivation_function)\nto generate the permanent asymmetric key pair that uniquely identifies that device. It measures\nthe next firmware stage, including metadata about the boot environment such as whether secure boot\nis enabled. The ROM then combines the UDS, firmware measurement, and configuration data in the KDF\nto derive the first CDI, which is passed to the next stage as a secret.\n\n### Stage 2 to n: Recursive key derivation\n\n\nThe process then repeats. In all subsequent stages, the CDI from the previous stage serves as the\ninput for a new KDF. This KDF uses the CDI and the hash of the next firmware image to produce a\nnew derived CDI. Each stage generates its own key pair and uses it to sign a certificate\ncontaining stage-specific measurements and other associated metadata."]]
