Introduction
Every connected device faces a fundamental security challenge:
How can another system determine whether the device is genuine and running trusted software?
Passwords, API keys, and software certificates help identify users and applications, but they don’t prove the integrity of the device itself. An attacker who compromises firmware or clones a device may still appear legitimate.
This is the problem that DICE (Device Identifier Composition Engine), developed by the Trusted Computing Group (TCG), is designed to solve.
DICE enables a device to generate cryptographic identities that are directly tied to its hardware and software state. These identities allow cloud services, enterprise networks, and other devices to make informed trust decisions based on verifiable evidence rather than assumptions.
What is DICE?
Device Identifier Composition Engine (DICE) is a security architecture that creates unique cryptographic identities during the device boot process.
Unlike a traditional device certificate that is permanently programmed during manufacturing, DICE identities are derived from the software that is actually running.
This means the device identity changes whenever the measured software changes.
In simple terms:
DICE creates identities that represent both the device and its current software state.
Why Was DICE Created?
Modern devices are becoming increasingly complex.
Examples include:
- IoT sensors
- Smart cameras
- Industrial controllers
- Medical devices
- Automotive control units
- Networking equipment
- Servers
- Edge computing platforms
These devices often operate in remote or untrusted environments.
Organizations need to answer questions such as:
- Is this the original device?
- Has the firmware been modified?
- Is Secure Boot working correctly?
- Is the device running approved software?
- Can this device be trusted to access sensitive services?
Traditional PKI alone cannot answer these questions.
DICE extends device identity by incorporating measured software into the identity itself.
The Core Idea Behind DICE
The fundamental concept is surprisingly simple.
During boot:
- A trusted component measures the next software stage.
- The measurement is used to derive a new cryptographic secret.
- That secret generates a new key pair.
- A certificate is created for that key.
- The process repeats for the next boot stage.
Each layer builds trust in the next.
The resulting certificate chain represents the software that actually booted.
Understanding Measurements
A measurement is a cryptographic hash of software.
For example:
Firmware Image
│
▼
SHA-384
│
▼
8F34A91C...
A cryptographic hash acts like a digital fingerprint.
Even changing a single bit in the firmware produces a completely different hash.
Because of this property, measurements provide a reliable way to detect software changes.
What Makes DICE Different?
Traditional device certificates are usually created once during manufacturing.
Factory
│
▼
Generate Certificate
│
▼
Store Forever
If the device firmware changes later, the certificate typically remains the same.
DICE works differently.
Boot
│
Measure Firmware
│
Derive New Secret
│
Generate Identity
The identity reflects the software that actually booted.
This provides much stronger assurance during remote attestation.
The Chain of Trust
DICE establishes trust one stage at a time.
A simplified boot flow looks like this:
Immutable ROM
│
Measures
▼
Bootloader
│
Measures
▼
Operating System
│
Measures
▼
Application
Each stage verifies and measures the next before handing over control.
Every new identity is derived from the previous trusted stage, creating a cryptographically linked chain of trust.
Compound Device Identifiers (CDIs)
One of the most important concepts in DICE is the Compound Device Identifier (CDI).
A CDI is not a certificate and not a private key.
Instead, it is a secret value derived from two primary inputs:
- A secret from the previous trusted stage
- The measurement of the next software stage
Conceptually:
Previous Secret
+
Software Measurement
│
▼
KDF
│
▼
CDI
The CDI is then used to derive:
- Private keys
- Public keys
- Device identities
- Additional secrets for the next stage
Because each CDI depends on the measured software, any software change results in a different CDI and, ultimately, a different cryptographic identity.
Why Is This Important?
Suppose an attacker modifies the bootloader.
The measurement changes.
Because the measurement changes:
- The CDI changes.
- The derived keys change.
- The certificates change.
- Remote attestation detects the difference.
Instead of trusting version numbers or configuration files, a relying party can trust cryptographic evidence.
DICE and Remote Attestation
Remote attestation is the process of proving a device’s identity and software state to another system.
A typical workflow looks like this:
Device
│
Generates Attestation
│
▼
Verifier
│
Validates Certificate Chain
│
Checks Measurements
│
Evaluates Policy
│
▼
Grant or Deny Access
The verifier can determine:
- Whether the device identity is valid
- Whether approved software is running
- Whether the platform is in an acceptable security state
This enables stronger security decisions than identity alone.
Where Is DICE Used?
DICE is applicable across a wide range of systems, including:
- Internet of Things (IoT)
- Industrial automation
- Automotive systems
- Network infrastructure
- Medical devices
- Edge computing
- Data center hardware
- Embedded systems
Its lightweight design makes it suitable even for resource-constrained devices.
How Does DICE Relate to Other Technologies?
DICE is often used alongside other security technologies rather than replacing them.
| Technology | Role |
|---|---|
| Secure Boot | Verifies software before execution |
| TPM | Securely stores keys and platform measurements |
| PKI | Provides certificate-based identity |
| Remote Attestation | Allows a verifier to assess device trust |
| DICE | Derives identities from measured software |
Together, these technologies create a layered security architecture.
Common Misconceptions
“DICE replaces PKI.”
No. DICE complements PKI by providing identities that are derived from measured software. Those identities are typically represented using standard X.509 certificates.
“DICE requires a TPM.”
No. While DICE can coexist with a Trusted Platform Module (TPM), it does not require one. DICE is designed to be lightweight and can be implemented without dedicated TPM hardware.
“DICE is only for IoT.”
No. Although it is well suited to IoT, DICE can be applied anywhere a device needs a trustworthy identity, from embedded controllers to enterprise infrastructure.
“DICE prevents attacks.”
Not by itself. DICE does not stop an attacker from modifying software. Instead, it provides cryptographic evidence that software has changed, allowing a relying party to detect the change and apply policy.
Why DICE Matters
Modern security is shifting from implicit trust to verifiable trust.
Organizations increasingly expect devices to prove:
- Who they are
- What software they are running
- Whether that software has been modified
- Whether the device should be trusted
DICE provides a standardized way to generate this evidence.
Instead of relying on assumptions or manually maintained inventories, trust decisions can be based on cryptographically verifiable measurements.
Final Thoughts
Device identity is no longer just about possessing a private key—it is about demonstrating that the device is running the software it claims to be running.
DICE brings these two concepts together by deriving cryptographic identities from measured software. The result is a scalable, standards-based foundation for secure boot, remote attestation, and zero-trust device authentication.
As connected devices continue to grow in number and importance, technologies like DICE will play an increasingly central role in establishing trust across embedded systems, cloud services, and enterprise infrastructure.
In the next article, we’ll explore how DICE works during the boot process and see how trust is established one software layer at a time.