DICE Protocol: A Practical Guide to X.509 Extensions for Device Identity and Attestation

By /

Introduction

The Trusted Computing Group (TCG) defines the Device Identifier Composition Engine (DICE) as a lightweight architecture for establishing hardware-rooted identity and enabling measured boot attestation in embedded and constrained systems.

Unlike traditional PKI models where identities are provisioned and stored, DICE derives identities dynamically from device state. This makes X.509 certificate extensions central to the design—they encode measurements, identity lineage, and trust relationships.

This post provides a structured overview of the key extensions used in DICE, how they are defined by TCG, and how they are used in real-world implementations.

TCG’s Role in DICE and Extensions

The Trusted Computing Group standardizes:

  • The DICE architecture and derivation model
  • OID namespaces for DICE-specific extensions
  • Interoperability guidance for attestation

DICE-related extensions are defined under the TCG OID arc:

  • 2.23.133.5.4.x

These extensions ensure that device identity is not just cryptographic, but also context-aware and verifiable across vendors and ecosystems.

Why Extensions Are Fundamental in DICE

In traditional PKI (per RFC 5280), extensions provide additional metadata. In DICE, they are core to the trust model because they:

  • Bind firmware measurements to identity
  • Enable stateless verification
  • Represent device state at each boot layer
  • Establish cryptographic linkage across layers

Without extensions, a DICE certificate is just a public key. With them, it becomes a complete attestation statement.

Key X.509 Extensions in DICE

1. TCG DICE Attestation Extensions

Defined by TCG under:

  • 2.23.133.5.4.x

Common examples:

  • 2.23.133.5.4.9 → DICE attestation evidence
  • 2.23.133.5.4.100.6 → platform or compound identity attributes

These extensions typically include:

  • Firmware/code hashes
  • Configuration state
  • Security version numbers

They allow a relying party to reconstruct the measured boot state directly from the certificate.

2. Subject Key Identifier (SKI)

  • OID: 2.5.29.14

The SKI uniquely identifies a certificate’s public key.

In DICE:

  • Derived from the public key generated using the Compound Device Identifier (CDI)
  • Represents the identity of a specific boot layer

Each layer produces:

CDI → Key Pair → SKI

This forms a chain of identities tied to device state.

3. Authority Key Identifier (AKI)

  • OID: 2.5.29.35

Links a certificate to its issuer.

In DICE:

AKI (layer n) = SKI (layer n-1)

This creates a verifiable chain:

Layer N → Layer N-1 → ... → Root (UDS)

No external lookup is required—the trust chain is self-contained.

4. Basic Constraints

  • OID: 2.5.29.19

Defines CA capability.

Typical DICE usage:

  • Root / UDS-derived certificate → CA: TRUE
  • Intermediate layers → optional CA capability
  • Final device certificate → CA: FALSE

Architectural note:
Keep pathLenConstraint flexible if you anticipate hierarchy growth (e.g., additional firmware layers or services).

5. Key Usage

  • OID: 2.5.29.15

Defines permitted operations.

Typical usage:

  • digitalSignature → attestation signing
  • keyCertSign → if acting as CA

Best practice:

  • Apply least privilege per layer
  • Avoid overloading a single certificate with multiple roles

6. TCG + Vendor-Specific Extensions

While TCG defines the base OIDs, real systems extend them with vendor-specific data.

Typical fields:

  • Device model / SKU
  • Firmware version
  • Security patch level
  • Lifecycle state

Example conceptual ASN.1:

DeviceInfo ::= SEQUENCE {
    firmwareHash      OCTET STRING,
    deviceModel       UTF8String,
    securityVersion   INTEGER
}

These extensions are essential for:

  • Device fleet management
  • Compliance enforcement
  • Risk and policy decisions

7. CoRIM and Reference Integrity

The IETF CoRIM complements DICE by defining reference measurements.

Relationship:

  • DICE extensions → carry actual device measurements
  • CoRIM → defines expected measurements

Verification becomes:

Device Evidence + Reference Values → Trust Decision

This separation enables scalable and maintainable attestation systems.

How Everything Fits Together

End-to-end DICE flow:

  1. UDS (Unique Device Secret) derives initial CDI
  2. CDI generates key pair and certificate
  3. Certificate includes:
    • SKI (identity)
    • TCG DICE extensions (measurements)
  4. Each subsequent layer:
    • Derives new CDI
    • Generates new certificate
    • Links via AKI
  5. Verifier:
    • Walks chain using SKI/AKI
    • Evaluates TCG extensions
    • Optionally validates against CoRIM

The result is a cryptographically bound, measurement-driven identity chain.

Design Considerations

1. Size and Efficiency

Keep extensions compact for constrained environments.

2. Deterministic Encoding

Consistent ASN.1 encoding is critical for reproducibility.

3. Algorithm Agility

Design for future cryptographic transitions (including PQC).

4. Extensibility

Allow room for:

  • Additional layers
  • Hybrid identity models
  • Future TCG extension updates

5. Privacy

Avoid exposing sensitive identifiers directly; use hashed representations where possible.

Example DICE Certificate Structure

A typical certificate includes:

  • Subject: Device public key
  • SKI: Derived identifier
  • AKI: Parent linkage
  • Basic Constraints: CA: FALSE
  • Key Usage: digitalSignature
  • TCG DICE extension (2.23.133.5.4.9):
    • Firmware hash
    • Boot measurements
  • Vendor extension:
    • Device model
    • Security version

Conclusion

DICE, as defined by the Trusted Computing Group, redefines device identity as a function of measured state rather than static provisioning.

X.509 extensions are the mechanism that makes this possible. They transform certificates into self-contained attestation artifacts that can be verified without relying on external systems.

For platform security architects, mastering these extensions is essential to building scalable, interoperable, and future-ready trust systems.

Scroll to Top