The Trusted Computing Group (TCG) has published after two years of deliberation the Hardware Requirements for a Device Identifier Composition Engine (DICE). I was chair of the working group responsible for this document and editor of the specification. This process has taught me a lot of patience and showed me how to find compromise. This process also showed me that the English language can be interpreted in so many fascinating, different ways.
This specification defines the basis for architectures that can be built on top of hardware conforming to this specification. These architectures are discussed and evaluated in the DICE Architectures working group in the TCG. This work evolved out of Microsoft’s Robust Internet-of-Things idea, which is now its own DICE project at Microsoft Research.
The basic idea behind DICE is that with only a Unique Device Secret and a hashing or HMAC function implemented in hardware (or ROM), a device can cryptographically proof its state. Software layers running on top of DICE compliance hardware can create keys and identifiers that can be used to allow an attester to verify their firmware & hardware configuration. One prime scenario is IoT or embedded technology: Assume the software running on an IoT device has a vulnerability and the device provider wants to update the software. How can the device provider tell if the software update actually happened instead of the vulnerable software just reporting an “A-OK”? With hardware that meets DICE requirements and a software stack that makes proper use of this hardware, this report cannot be faked. The Device provider is able to identify all updated and still vulnerable devices.
The DICE team published a reference implementation of RIoT on GitHub to allow IoT vendors to include this technology into their own devices. It integrates with Azure IoT services to securely provision IoT devices implementing this technology.