Skip navigation
TCG Rolls the DICE for Automotive Security

TCG Rolls the DICE for Automotive Security

The Trusted Computing Group’s Device Identifier Composition Engine (DICE) offers a platform for providing privacy and security in an automotive environment.

Not a week goes by without mentions of self-driving cars and security breaches of automotive platforms. Security is one of the main topics, alongside artificial intelligence and machine learning, when it comes to self-driving cars. Addressing security is more than just adding encryption to a communications link.

The Trusted Computing Group (TCG) addresses a range of security standards and topics, but most will know it for its Trusted Platform Module (TPM) that’s found on many motherboards. TPM provides a root of trust for secure boot. The challenge with TPM is that it’s a somewhat heavyweight solution.

TCG’s Device Identifier Composition Engine (DICE) architecture targets more embedded spaces like the Industrial Internet of Things (IIoT) and automotive applications that need security—with low overhead. DICE provides a root of trust like TPM, but with near zero cost.

1. DICE has access to a Unique Device Secret that’s used to compute secrets for subsequent layers.

Microsoft’s Dennis Mattoon presented the DICE: Foundational Trust for IoT at the Flash Memory Summit, introducing DICE to attendees. DICE starts at boot time with a Unique Device Secret (UDS) that has exclusive access (Fig. 1).

Each software layer receives a secret from the previous layer and generates a new secret for the next layer. Each layer needs to keep its own secret, and can use it for its own security purposes. Typically, the initial boot layer is stored ROM. Secrets, including the UDS, are normally discarded after using a hash function to generate the information, called the Compound Device Identifier, for the next level.

Changes are required if the software for a layer is altered, such as when there’s an update (Fig. 2). A new secret is generated for the new layer as well as subsequent layers, even if those haven’t changed.

2. A new secret will generate if the software changes (e.g., updates) in a given DICE software layer.

Microsoft’s Robust, Resilient, Recoverable IoT (RIoT) architecture is an implementation of DICE (Fig. 3). RIoT works with devices that communicate with applications on Microsoft’s Azure Cloud Computing Platform. The RIoT core (layer 0) generates an alias and device ID certificate based on the UDS.

The DICE support allows for hardware-based identification and authentication. DICE is designed to require minimal hardware support compared to TPM, which needs a separate module. As a result, even microcontrollers can provide the underlying support.

3. Microsoft’s Robust, Resilient, Recoverable IoT (RIoT) is an implementation of the DICE architecture.

Many microcontrollers already have unique identifiers or one-time-programmable (OTP) identifiers that can be used with DICE. Likewise, the hashing and cryptographic support is often available. The framework may be usable on many existing platforms, although proper support may require a redesign of the boot process to allow for hardware-based support that can’t be modified like that for a flash-based solution.

Applications such as advanced driver-assistance systems (ADAS) often incorporate a number of microcontrollers and microprocessors. A secure system will require each to provide some level of security like DICE to address communication as well as updates. DICE can support a range of hardware and encryption methodologies.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.