Category: TPM

Posted on

Trusted Computing Group publishes Hardware Requirements for DICE

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.

Posted on

Microsoft publishes TPM 2.0 reference code

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.

Posted on

TPM Return Code Decoder

Whenever working with Trusted Platform Modules (TPM) one stumbles over the responses and especially the error codes that are returned by the TPM and the software stack used to talk to the TPM. TPM error codes are not always straight forward, but encode more information, for instance, which parameter caused the error.

To make it easier to look up the TPM error codes, I wrote the  TPM Return Code Decoder app. In addition to the error code lookup, the app also provides a library of TPM command descriptions. On the left side menu, the input field  icon opens the Return Code Decoder page. When a TPM error code is entered, the description will be filled with the TPM 1.2 and TPM 2.0 description of the error. If the error code is incorrect for either TPM 1.2 or TPM 2.0, the description field will say that it’s not a valid error code.

The search icon in the menu will open the command code lookup page. Here, a short description of the TPM command will show up in the description field.

The numeric command codes between TPM 1.2 and TPM 2.0 do not overlap, so the lookup of command codes produces either a description for the TPM 1.2 command, or the TPM 2.0 command. Alternatively to entering the numerical command code, a user can select a command from the list of commands, which are sorted alphabetically.

For both, error code and command code lookup, the input field will accept either a decimal entry or a hexadecimal entry. The latter has to be preceded by “0x” to indicate the hexadecimal number. For instance the decimal error code 257 would have to be input as “0x101” in hexadecimal.

The command code lookup page takes the description from the published TPM specifications. It does not contain the full text of the specification, but often only the first paragraph for the respective commands. For a full description of the commands, the full specifications should be consulted. They can be obtained at the TCG website:

I hope that this app can help you look up the description for a command or error code for a TPM that you use or write software for.

Source code for the app can be found on GitHub.

Posted on

A hash calculator

This blog post will introduce the basic functionality of the TPM PCR Calculator app, which can be found in the Windows Store.

During the boot of a PC with measured boot enabled, firmware and early phases of the operating system protocol software and configuration data into a measurement log and “checksums” of these log entries into the Platform Configuration Registers (PCR) of a Trusted Platform Module (TPM). The checksums are recorded as hashes, which have been computed using secure hashing algorithms (SHA).

I work a lot with these measured boot logs, or TCG logs, generated as results of UEFI firmware or Windows boot loader. To validate the entries in these log file, I have to calculate hashes and PCR values from hand. This becomes tedious. That’s why I wrote the TPM PCR Calculator app.

The menu (column of icons) on the left navigates to different functionality of this app. The first icon, which looks like the search icon, opens the PCR calculator page. I’ll get back to that later. The first calculator icon opens the hash calculator page.

A hashing algorithm computes the cryptographic hash, or digest, from whatever data is presented to it. To allow users to either input text or a text representation of a byte array, the user can toggle a checkbox labeled “Input is raw bytes.” If the checkbox is clear, the text in the input box  is treated as plain text. If the checkbox is selected, the input is treated as hexadecimal text representation of a byte array. A value of zero of size four bytes would look like this: “00000000” (without the quotes). The “compute hash” button starts the computation of the hashes. The app currently supports the secure hash algorithms (SHA) SHA1 and, from the SHA2 class, SHA2-256, SHA2-384, and SHA2-512. If the checkbox is selected to interpret the input as bytes, but the input cannot be converted into a byte array, an error message is printed into the SHA1 output box.

The lower calculator icon opens the hash calculator with HMAC key page. This hash calculation uses an additional key to compute the hash of input data.

This page work essentially the same as the hash calculator page, except that the HMAC key has to be provided as well. The input format for the HMAC key is always assumed to be “raw bytes”, so the checkbox only controls the input parsing of the input data field.

Now let’s come back to the PCR calculator page: Platform Configuration Registers (PCR) can be manipulated using a one-way (or trap-door) function. This function – “Extend” in TPM terminology – performs two steps: first, it concatenates the input data to the current value of the register. Then a hash is computed of the concatenated value. The result is then stored as current value.  The PCR calculation page will show these steps as explanation of the Extend function.

A PCR is usually associated with a hashing algorithm. TPM version 1.2 devices only support the SHA1 algorithm with PCRs, whereas TPM version 2.0 devices can support multiple PCR with different hashing algorithms. I’ll write a different post that goes into the details of what exactly a PCR is at another time.

In summary, if you have the need to compute hashes or PCR values, this app might be for you.

Source code for the app can be found on GitHub.