Device Identifier Composition Engine (DICE) is an attestation standard developed by the Trusting Computing Group (TCG). DICE builds on the device identity and device attestation concepts introduced in Robust Internet-of-Things (RIoT) from Microsoft Research.
The DICE specification is split across the following core documents:
- Hardware Requirements, describing the DICE Root of Trust (RoT) and the construction of the (unique) Compound Device Identifier (CDI).
- Layering Architecture, describing the construction of a device's layered identity rooted in the CDI and obtained via the recursive invocation of a simple primitive based on measurements and per-device secret seeding.
- Attestation Architecture, describing how DICE-based attestation fits in the wider RATS architecture.
Other relevant documents include:
- Certificate Profiles, describing how X.509 certificates that carry public keys derived from DICE identities look like.
- Symmetric Identity Based Device Attestation, describing how to derive symmetric key material from DICE identities and how that could be used in authentication and attestation protocols.
A further "DICE Endorsements Architecture" document, describing the information model (IM) for endorsed and reference values, is currently under revision in the TCG. The official document is not yet published, but a data model based on the IM is available in the CoRIM repository of which Veraison provides a Golang implementation.
Google has released the specification of an Open Profile for DICE based on TCG's "Hardware Requirements" and "Layering Architecture" documents, along with a C99 implementation as part of the Pigweed project.
While the core concepts are unchanged, there are a few notable differences from TCG DICE, mainly around the encoding of payloads. See the Open DICE Formats section for the details.
-
DICE Hardware RoT - The HW implementation of the DICE processing engine, acting as the terminal trust anchor in a DICE device.
-
Unique Device Secret (UDS) - A permanent, (statistically) unique, secret value. Every instance of a DICE device has its own UDS stashed away in a location only accessible to the DICE engine. The UDS can be injected at manufacturing time, or generated by the device itself using a suitable PRNG.
-
Trusted Computing Base (TCB) : All the security relevant HW and SW in a DICE device. DICE organizes the TCB in multiple "components", which are grouped in "layers" stacked one on top of the other, starting with the DICE engine. A layer boundary represents an explicit handover point from one component to one or more components in the "next" stage of the boot chain.
-
TCB Component Identifier (TCI) - A (statistically) unique identifier for a TCB component. This value is computed by digesting the component's measurement along with other component-specific attributes, e.g., vendor name, version, etc.
-
TCB Info - The information model of a TCB component. It gathers a standard set of attributes (and associate types) that describe a TCB, for example: its model, vendor, Firmware digests, version, etc.
-
Compound Device Identifier (CDI) - This value represents the (statistically) unique identity of each layer in the bootstrap sequence. The CDI for a given layer is obtained by hashing together the predecessor CDI and the TCI for the current layer. This recursive construction is such that the resulting CDIs are inextricably chained: when one CDI changes (e.g., because the measured software component is updated, and the TCI mutates accordingly), all its successor CDIs change as well. Crucially, the CDI is directly used as a seed for deriving cryptographic credentials (e.g., an ECDSA key pair) for the corresponding TCB component.
NOTE: At first it might seem like the scalability properties of DICE verification vis-a-vis software & configuration updates of TCB components are terrible. The verifier would have to be re-provisioned with all the updated identities of all the devices of the same "class" if a bit was flipped in their TCB. Luckily, the situation is not so gloomy: as long as the lowest layer in the DICE chain is stable (as in "never updated") and the DICE compound identity is provided as a certification chain rooted either in the lowest layer or in an external CA that issues the cert for the lowest layer, an identity update of the i-th layer can be re-computed dynamically by a verifier without need to further interact with the supply chain -- except for re-provisioning the verifier with the updated measurement. The key requirement is the stability of the so-called "Layer 0" / "First Mutable Code" (FMC), and therefore of its cryptographic identity. The latter is a pretty important bit in DICE and it's given the proper name of "Device Id". The Device Id key pair is associated with an IEEE 802.1AR IDevID cert.
DICE models attestation evidence as a layered & chained set of claims. The claims in each layer are of two kinds:
- The cryptographic identity associated with the layer (typically, a public key),
- The layer's measurements used as input in the identity derivation function.
The recommended way to encode evidence is using standard X.509 scaffolding:
- A certificate for the layer's public key signed by the previous layer's private key,
- A set of custom certificate extensions to encode the TCB measurements.
Theoretically, other formats are acceptable; for example, Open-DICE envisages the use of chained CWTs).
tcg OBJECT IDENTIFIER ::= { 2 23 133 }
tcg-dice OBJECT IDENTIFIER ::= { tcg platformClass(5) 4 }TCB Info represents the data and metadata associated with the component identity. It can be roughly split into two logically separate parts: naming / identification attributes on one side (i.e., vendor, vendorInfo, model, version, svn, layer and index), measurement values on the other (i.e., fwids, flags and type)
See Section 6.1.1 of the Attestation Architecture document for a detailed description of the semantics associated with individual fields.
tcg-dice-TcbInfo OBJECT IDENTIFIER ::= {tcg-dice 1}
DiceTcbInfo ::== SEQUENCE {
vendor [0] IMPLICIT UTF8String OPTIONAL,
model [1] IMPLICIT UTF8String OPTIONAL,
version [2] IMPLICIT UTF8String OPTIONAL,
svn [3] IMPLICIT INTEGER OPTIONAL,
layer [4] IMPLICIT INTEGER OPTIONAL,
index [5] IMPLICIT INTEGER OPTIONAL,
fwids [6] IMPLICIT FWIDLIST OPTIONAL,
flags [7] IMPLICIT OperationalFlags OPTIONAL,
vendorInfo [8] IMPLICIT OCTET STRING OPTIONAL,
type [9] IMPLICIT OCTET STRING OPTIONAL
}
FWIDLIST ::== SEQUENCE SIZE (1..MAX) OF FWID
FWID ::== SEQUENCE {
hashAlg OBJECT IDENTIFIER,
digest OCTET STRING
}
OperationalFlags ::= BIT STRING {
notConfigured (0),
notSecure (1),
recovery (2),
debug (3)
}Multiple TCB Info payloads, each associated with a different component in the layer, can be put together into the same certificate using a DiceTcbInfoSeq:
tcg-dice-MultiTcbInfo OBJECT IDENTIFIER ::= { tcg-dice 5 }
DiceTcbInfoSeq ::= SEQUENCE SIZE (1..MAX) OF DiceTcbInfoEven though further extensions have been defined (for the full list see Section 6.1 of "Attestation Architecture" -- for example one that allows unsigned EAT claims to be embedded in an X.509 extension -- DiceTcbInfo is the (currently) preferred way.
In Open DICE, the equivalent of the TCB Info is called OpenDiceInput and has a very regular layout, with data and metadata for code, configuration and authority respectively:
Mode ::= INTEGER (0..3)
OpenDiceInput ::= SEQUENCE {
codeHash [0] EXPLICIT OCTET STRING OPTIONAL,
codeDescriptor [1] EXPLICIT OCTET STRING OPTIONAL,
configurationHash [2] EXPLICIT OCTET STRING OPTIONAL,
configurationDescriptor [3] EXPLICIT OCTET STRING OPTIONAL,
authorityHash [4] EXPLICIT OCTET STRING OPTIONAL,
authorityDescriptor [5] EXPLICIT OCTET STRING OPTIONAL,
mode [6] EXPLICIT Mode OPTIONAL,
}For further details regarding the Open DICE X.509 profile, see the Certificate Details section of the spec.
Open DICE also allows encoding UDS and CDI certificates in CBOR Web Tokens (CWT) similar to EAT. It also allows for hybrid cert chains, with co-existing X.509 and CWT certs in the same logical chain, to support legacy component integrations.
Miscellaneous implementation & deployment considerations.
Typically, DICE identities are associated with asymmetric key pairs.
NOTE: This mode is, from a security perspective, the most desirable. In fact, when using public keys for verification, the verifier only needs to take care of their availability and integrity.
Effectively a verifier only stores the device trust anchor, which could be an external root CA -- for example the ODM's -- or the self-signed certificate of the device in case there is no external CA to anchor the cert chain. The former providing a much more scalable solution, with individual device revocation handled via standard CRLs.
"Symmetric Identity Based Device Attestation" describes how to associate DICE identities with symmetric crypto keys.
In this case, the verifier must have a-priori knowledge of the device secret as well as a detailed understanding of the identity derivation algorithm in order to verify the device's authenticated assertions. This assumes a level of coupling between attesters and verifiers that, I reckon, is not achievable using only the available TCG standards, which tend to be quite liberal around the implementation details. The Open-DICE specification only allows identities based on asymmetric keys.
NOTE: This mode shifts all the costs on the verification infra. It is an operational nightmare with a vast attack surface and very limited scalability. It should be deemed acceptable only when the cost of a key compromise / disclosure is (very) low, and the device fleet is roughly static with very infrequent software updates.
We expect that, typically, DICE evidence submitted for verification is not bound to an explicit challenge-response session. This is likely to require defining a new Veraison API alongside the existing challenge-response endpoint.
Given the fact that TCG DICE has a few loose ends, mainly in terms of evidence encoding formats and the nature of cryptographic identities, Veraison will have to be as flexible as possible while clearly documenting the supported feature set.
Open-DICE defines a stricter (and smaller) set of requirements and therefore it'd be probably easier to implement fully.
Veraison DICE implementation will need to be extended with APIs for claims extraction. The existing certificate chain verification API should be OK as-is.
By definition, native CoRIM fully supports TCG DICE, so there should be no extra work needed to profile the corim API, which already implements the entirety of CoRIM.
Open-DICE has a slightly different description of the TCB which will need to be reflected in a CoRIM profile. It should be a pretty straightforward operation.