DICE stands for Device Identifier Composition Engine. It is a hardware Root of Trust (RoT) as defined by the Trusted Computing Group (TCG). The core idea is simple but powerful: take a secret that is physically embedded in the silicon at manufacture, combine it with a measurement of the firmware that loads on that silicon, and derive a cryptographic key from the result. That key is hardware-bound in a way that software keys never are.
The TCG DICE Certificate Profiles Specification
The TCG DICE Certificate Profiles specification, Version 1.1 (published April 24, 2025), is the normative document that defines how DICE-derived keys are expressed as X.509 certificates. It defines four certificate profiles and the policy OIDs that accompany them. Everything in this section is drawn directly from the published specification.
What the specification defines
The specification assumes the reader is familiar with the TCG Hardware Requirements for DICE and the DICE Layering Architecture specification. Building on those foundations, it defines:
- X.509 certificate conventions for DICE-derived key pairs (serial number, validity, naming)
- Policy OIDs from the tcg-dice-kp namespace that identify the purpose and binding of each key
- Four certificate profiles: IDevID, LDevID, ECA, and Attestation
- Field-level requirements for each profile (Issuer, Subject, Key Usage, Extended Key Usage, Basic Constraints, CRLDistributionPoints)
Certificate conventions
- Serial number: Certificate Serial Numbers MUST be unique per CA for each Alias Key certificate. Different embedded CAs may issue certificates with the same serial number fields.
- Certificate lifetime: Devices with a secure clock set validity periods conventionally. Devices without a secure clock, which covers most AI accelerators and embedded hardware, set the notAfter to the X.509 GeneralizedTime value 99991231235959Z or non-expiring validity. The notBefore is set to a known date in the recent past, such as the TCB build time. This value indicates no defined expiration date.
- Subject naming: Subject names SHOULD identify the component environment where the private key resides. May contain device serial number, firmware identifiers, or DICE layering coordinates. Subject names MUST be formatted for byte array comparisons. Attestation verifiers are recommended not to obtain attestation claims from Subject or SubjectAltName fields.
- Issuer naming: The Issuer Name at layer n+1 MUST match the Subject Name of the issuing certificate at layer n. This is the chaining rule that allows the DICE identity to be traced from silicon up through every firmware layer.
Policy OIDs: the tcg-dice-kp namespace
The specification defines seven policy OIDs in the tcg-dice-kp namespace. These are placed in the Extended Key Usage extension of DICE certificates to identify what the key is authorized for and how it was bound. The OID arc from the specification (Appendix A):
tcg OBJECT IDENTIFIER ::= { 2 23 133 }
tcg-dice OBJECT IDENTIFIER ::= { tcg platformClass(5) dice(4) }
tcg-dice-kp OBJECT IDENTIFIER ::= { tcg-dice kp(100) }| OID Name | OID Value | Purpose and binding rule |
|---|---|---|
| tcg-dice-kp-identityInit | identity-init(6) | IDevID. Initial device identity. Key MUST be bound at manufacturing. Key MUST be certified by manufacturer. |
| tcg-dice-kp-identityLoc | identity-loc(7) | LDevID. Local device identity. Key SHOULD be bound post-manufacturing. Key MUST be certified by a local issuer. |
| tcg-dice-kp-attestInit | attest-init(8) | Initial attestation. Attestation key for signing device evidence. Key MUST be bound at manufacturing and certified by manufacturer. |
| tcg-dice-kp-attestLoc | attest-loc(9) | Local attestation. Attestation key, post-manufacturing binding. MUST be certified by local issuer. |
| tcg-dice-kp-assertInit | assert-init(10) | Initial assertion. Key for signing reference measurements about the device. Manufacturing-bound. |
| tcg-dice-kp-assertLoc | assert-loc(11) | Local assertion. Key for signing reference measurements. Post-manufacturing. MUST be certified by local issuer. |
| tcg-dice-kp-eca | eca(12) | Embedded CA. Authorises certificate issuance for keys on the current device. Issuer signing key MUST be certified by manufacturer or local issuer. |
The Four Certificate Profiles
The specification defines four certificate profiles. Each has a table of field-level requirements (Tables 14 in the specification). Below is a concise summary of what the X.509 certificate metadata is required for each certificate profile.
IDevID: Initial Device Identifier
Source: TCG DICE Certificate Profiles v1.1, Table 1
The IDevID is the device birth certificate or leaf certificate. It is issued at manufacturing time and cannot be reissued because the key is hardware-bound.
| Field | Requirement |
|---|---|
| Issuer | MUST identify or chain to the device manufacturer or supply chain entity. If the Issuer is an embedded CA, the ECA issuer MUST chain to the manufacturer CA. Therefore, the certificate chain MUST be validated |
| Subject | It typically utilizes Relative Distinguished Names (RDNs) like Common Name (CN), Organization (O), or Organizational Unit (OU) to designate the TCB class or instance. Often, unique hardware identifiers (like a Unique Device ID or UEID) are embedded as extensions or inside the SAN to uniquely identify the device instance Note: MUST identify the TCB (Trusted Computing Base) owning the IDevID private key. May be a class identifier (multiple device instances sharing the same name). |
| Subj. Public Key | Contains the public key and algorithm identifier. Key MUST be protected by an immutable TCB layer, or a TCB layer modifiable only by the Issuer. The private key MUST be secured in a hardware-based module, such as Hardware Security Module (HSM) |
| Key Usage | If Subject is an ECA: MUST contain keyCertSign, MUST NOT contain cRLSign. Otherwise: MUST NOT contain keyCertSign. |
| Extended Key Usage | MUST contain tcg-dice-kp-identityInit. MAY contain id-kp-clientAuth, tcg-dice-kp-eca, or tcg-dice-kp-attestInit. |
| Basic Constraints | If Subject is an ECA: MUST contain cA:TRUE and pathLengthConstraint. Otherwise: SHOULD NOT contain BasicConstraints. |
LDevID: Local Device Identifier
Source: TCG DICE Certificate Profiles v1.1, Table 2
The LDevID is issued post-manufacturing by the device owner. It establishes the device’s operational identity within the owner’s environment. The structural difference from IDevID is the Issuer (owner CA, not manufacturer CA) and the policy OID (identityLoc, not identityInit).
| Field | Requirement |
|---|---|
| Issuer | MUST identify or chain to the owner CA. If Issuer is an embedded CA, the ECA issuer MUST chain to the owner CA. |
| Subject | MUST identify the TCB owning the LDevID private key. MAY be a class identifier. |
| Subj. Public Key | Contains the public key and algorithm identifier. Key protected by immutable TCB layer or TCB modifiable only by Issuer. |
| Key Usage | If Subject is an ECA: MUST contain keyCertSign, MUST NOT contain cRLSign. Otherwise: MUST NOT contain keyCertSign. |
| Extended Key Usage | MUST contain tcg-dice-kp-identityLoc. MAY contain tcg-dice-kp-eca, tcg-dice-kp-attestLoc, and/or id-kp-clientAuth. |
| Basic Constraints | If Subject is an ECA: MUST contain cA:TRUE and pathLengthConstraint. Otherwise: SHOULD NOT contain BasicConstraints. |
ECA: Embedded Certificate Authority
Source: TCG DICE Certificate Profiles v1.1, Table 3 (§5.1.6.3)
The ECA is a CA that lives inside the device firmware. It issues certificates to firmware layers above it. The ECA itself must be certified by the manufacturer CA (or local issuer for LDevID contexts) during manufacturing.
| Field | Requirement |
|---|---|
| Issuer | MUST identify the CA or embedded CA that issues this certificate. Issuer MUST ensure the private portion of the Subject Public Key is protected by a TCB. If Issuer is an ECA, MUST identify the TCB instance. |
| Subject | The Subject name can be a class identifier, indicating that multiple device instances might share the same name. MUST identify the TCB containing ECA functionality. |
| Subj. Public Key | MUST contain the current TCB Layer ECA public key and algorithm identifier. |
| Key Usage | MUST contain keyCertSign. MUST NOT contain cRLSign. May contain other Key Usage attributes. |
| Extended Key Usage | MUST contain tcg-dice-kp-eca. MAY contain tcg-dice-kp-attestInit, tcg-dice-kp-attestLoc, tcg-dice-kp-identityInit, or tcg-dice-kp-identityLoc. |
| Basic Constraints | MUST contain cA:TRUE and pathLengthConstraint as appropriate. |
| CRLDistributionPoints | Extension MUST be present. |
Attestation Certificate
Source: TCG DICE Certificate Profiles v1.1, Table 4
Attestation certificates authorize a key to sign evidence about a device, firmware hash, hardware configuration, product name, or measurement state. Issued by either an ECA or an external CA.
| Field | Requirement |
|---|---|
| Issuer | MUST contain the name of the embedded CA or external CA that issues the certificate. If Issuer is an ECA, MUST identify the TCB instance. |
| Subject | MUST identify a TCB class or instance. |
| Subj. Public Key | MUST contain a current TCB attestation public key and algorithm identifier. |
| Key Usage | If Subject is an ECA: MUST contain keyCertSign, MUST NOT contain cRLSign. Otherwise: MUST NOT contain keyCertSign. |
| Extended Key Usage | MUST contain either tcg-dice-kp-attestInit or tcg-dice-kp-attestLoc. MAY contain id-kp-clientAuth and other appropriate values. |
| Basic Constraints | If Subject is an ECA: MUST contain cA:TRUE and pathLengthConstraint. Otherwise: SHOULD NOT contain BasicConstraints. |
Role of DICE in hardware identity
With the specification understood, the bigger question is why DICE matters for hardware identity use case, and what role it plays in the layered security stack for modern AI hardware.
DICE as the hardware root of trust
Every security system needs a starting point that is trusted by assumption. For software systems, this is typically an HSM, a TPM, or a secure enclave. For hardware identity, DICE is that starting point. The UDS is the root assumption it is the one value that is trusted because it was embedded by the manufacturer during a controlled process, and it cannot be read or copied by software.
Every identity claim derived from DICE is only as strong as the UDS. If the UDS is properly protected, the entire DICE chain above it is trustworthy. This is what makes DICE a true hardware root of trust: it anchors identity in physics, not policy.
DICE creates firmware-aware identity
Standard X.509 certificates bind a key to a name. DICE certificates bind a key to a specific hardware device running a specific firmware stack. The CDI derivation ensures that:
- Two devices with different hardware (different UDS values) produce different keys, even with identical firmware
- The same device running modified firmware produces a different key
- A certificate issued against CDI_n is verifiable as representing both the hardware and the exact TCB in use at the time of issuance
For AI hardware, such as GPUs, NPUs, DPUs, and inference accelerators, this firmware-awareness is critical. Supply chain attacks that modify accelerator firmware before deployment are a real threat vector. DICE makes such modifications detectable: the device will produce a different DICE identity post-modification, and that difference is cryptographically provable.
DICE in the IEEE 802.1AR framework
The IDevID and LDevID credential types are defined in IEEE 802.1AR-2018 (Secure Device Identity). DICE provides the key derivation mechanism that produces these credentials with hardware-rooted assurance. When a DICE-enabled device presents its IDevID to a 802.1AR-aware network infrastructure enterprise switches, access control systems, zero-trust platforms the infrastructure receives a credential that is verifiably linked to the manufacturer’s PKI and to the specific hardware shipped.
Without DICE, an IDevID is a software key in a certificate. With DICE, it is a hardware-bound key in a certificate, with a derivation chain that can be traced back to a silicon-level secret certified at manufacture. The 802.1AR framework is the same either way; DICE is what gives the credential its hardware assurance level.
DICE as the PKI anchor for agentic AI
In agentic AI deployments, an AI agent running on a hardware accelerator needs an identity that is:
- Unique to the specific hardware it runs on
- Verifiable by an orchestrator before the hardware is trusted with a workload
- Traceable back to the manufacturer’s assurance that the hardware is genuine
- Sensitive to firmware modification, so tampered hardware produces a different identity
DICE provides all four. The IDevID certificate rooted in the manufacturer CA, derived from the CDI chain, carrying the tcg-dice-kp-identityInit OID is the credential that the AI orchestrator checks via SPDM attestation before dispatching a sensitive workload. The DICE chain is the foundation; SPDM is the runtime protocol that uses it; the agent’s operational certificate is built on top of it.
Remove DICE, and the chain of hardware trust breaks at the first link. The agent’s certificate is then a software claim, not a hardware claim. Software claims can be forged. Hardware-rooted claims, properly implemented, cannot.
DICE and the certificate lifecycle
One aspect of DICE identity that is often overlooked: the certificate lifecycle is tied to the firmware lifecycle, not the calendar. In practice, devices implementing DICE will either recertify keys on each boot (because key pairs are re-derived on each boot) or persist keys when firmware remains unchanged.
This means the CLM (Certificate Lifecycle Management) model for DICE certificates is different from the model for TLS certificates:
- A firmware update triggers a new CDI derivation, a new key pair, and a new certificate request
- A device that boots unchanged firmware can present the same certificate it was issued at manufacture
- Certificate expiry is less relevant than firmware update cadence for managing DICE credential freshness
A PKI infrastructure supporting DICE must be designed around these characteristics. Static expiration-based lifecycle management, designed for server and user certificates, does not translate to DICE hardware certificates without modification.
How Encryption Consulting can help?
Building and operating a Manufacturer CA hierarchy that correctly supports DICE certificate profiles is not something most hardware vendors need to do in-house. The CA infrastructure required, offline root CA, manufacturing-integrated issuing CA, CRL publishing, OCSP infrastructure, HSM management, and the engineering to configure it all for DICE-specific profiles, is specialized work that consumes significant resources if built from scratch.
This is precisely the use case that Encryption Consulting’s PKIaaS offering is designed for.
What PKIaaS for hardware identity means
PKI as a Service (PKIaaS) means the CA hierarchy is designed, deployed, and operated by Encryption Consulting on behalf of the hardware vendor or deploying organisation. The vendor does not need to procure HSMs, configure CA software, manage root key ceremonies, or operate CRL infrastructure. EC does all of that. The vendor integrates with EC’s PKIaaS through APIs and management interfaces to issue and manage device certificates.
For DICE-based hardware identity, PKIaaS provides:
- DICE-aligned Manufacturer CA hierarchy: A root CA and issuing CA hierarchy configured for hardware certificate profiles. This includes the 40–50 year or non-expiring root CA validity required to coherently issue IDevID certificates with 99991231235959Z notAfter dates, the TCG DICE-kp OIDs registered in the CA’s OID database, and certificate templates for each profile type: IDevID, LDevID, ECA, and Attestation.
- Manufacturing workflow integration: The issuing CA is integrated into the device manufacturing process so that IDevID certificates are provisioned during production. For devices implementing the DICE layering architecture, this includes ECA key certification the manufacturer CA certifying the ECA public key before the device ships. EC designs and implements the manufacturing API integration.
- Hardware-specific certificate profile configuration: Standard CA platforms require configuration work to issue DICE-compliant certificates. EC configures the CA for: 99991231235959Z validity handling without triggering platform-level rejections; the mandatory TCG OIDs in Extended Key Usage; correct Key Usage for ECA vs. non-ECA certificates; the absence of BasicConstraints on non-ECA leaf certificates; and CRLDistributionPoints on ECA certificates as required by the spec.
- CRL and OCSP infrastructure: Hardware CA CRL infrastructure is built for low revocation frequency but must be highly available, because every SPDM attestation validates the certificate chain. EC operates the CRL and OCSP infrastructure at the availability level required by hardware deployments.
- Owner PKI bridging: When the hardware vendor’s IDevID PKI needs to be connected to the deploying organization’s LDevID and agent operational certificate PKI, EC designs and implements the bridge: the policy and technical connection between manufacturer-issued and owner-issued credentials in the same DICE trust chain.
- CertSecure Manager for agent CLM: As devices move into deployment and the owner PKI issues LDevID and agent operational certificates, CertSecure Manager handles the certificate lifecycle: automated renewal via EST, revocation management, fleet-level discovery, and audit trail. This is the operational layer above the DICE hierarchy that keeps the PKI running without manual intervention.
Conclusion
DICE certificate profiles, such as IDevID, LDevID, ECA, and Attestation are not abstract specifications. They are the technical foundation that transforms a hardware accelerator from an anonymous component into a verifiable, manufacturer-anchored identity. Every field requirement in the TCG DICE specification exists for a reason: to ensure that when an SPDM attestation verifier validates a device certificate chain, it can be certain the key was hardware-bound, the firmware was measured, and the chain traces back to a trust anchor that cannot be spoofed in software.
For AI infrastructure, where workloads run on hardware that may have crossed dozens of supply chain hands before deployment, this level of cryptographic assurance is not optional.
Building and operating a DICE-compliant CA hierarchy is demanding, specialized work. The root CA must carry non-expiring validity. Certificate templates must be configured for profiles that most CA platforms were not designed to issue out of the box. CRL and OCSP infrastructure must be available at every attestation event.
As the device fleet grows, the certificate lifecycle must track firmware updates, not just calendar expiry. Encryption Consulting’s PKIaaS removes that burden entirely: we build it, we manage it, you run your hardware. From the offline root CA and manufacturer issuing CA to the owner PKI bridge, OCSP responders, and CertSecure Manager for fleet-level CLM, the entire stack is designed, deployed, and operated by us, so your team focuses on shipping hardware, not running a CA.
