Category: Trusted Computing Group

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.

If you are familiar with the Trusted Computing Group (TCG) and it’s  TPM 2.0 Library Specification, you probably heard that it was explicitly written in a way that allows it to be translated by a parser into (semi-) executable code. At least the code to marshal command and responses and perform validation checks is generated. The specification also comes with most of the logic inside the different TPM commands. To make a usable TPM implementation out of that specification one has to add a wrapper that funnels the commands into that generated code and the preferred crypto library to perform the math required by the TPM code.

Microsoft, as primary editor, has provided the parser for the specification and kept the reference implementation and the specification in sync. This reference implementation has always been available to members of the TCG. Especially TPM vendors used this reference code as blueprint to innovate on and add their improved cryptographic logic to it.

However, the only means for the general public to get access to the TPM 2.0 reference code was to parse the TPM 2.0 library specification and generate the reference code themselves. With the availability of the TPM 2.0 reference code on GitHub this hurdle has now been removed. This also allows researchers who were less interested in generating the reference code but more in using it to have free access to it.