DICE

Problem Statement and background

Traditionally we’ve been relying and using digital signatures and signature verification in the boot process to ensure the authenticity and integrity of the software we’re about to load and run. This is tied together into a chain of trust by having each boot component verifying the signature of the boot component it’s about to load. Typically this has involved RSA, but over the recent years we have seen ECDSA (Elliptic Curve Digital Signature Algorithm) and EDDSA (Edwards-curve Digital Signature Algorithm) gaining more momentum. Signature verification as described here is a fundamental building block for securely booting a device. Nonetheless, it is susceptible to runtime attacks. Introducing attestation and sealing are two methods making it more difficult (but not impossible) to conduct runtime attacks undetected. TPM devices support both of these concepts, which is likely one of the reasons why they have become so popular. However, the use of a TPM device is not always feasible. It could be due to cost reasons, physical space on a PCB, or the fact that you don't want to rely on a feature-rich stack, which sounds good, but requires you to maintain code you may not even need. The TCB will also grow quite a bit if for example ROM code needs to talk to a TPM device. Additionally, TPM devices comes in the form of external modules connected via a socket, soldered onto a PCB, or integrated into a chip, which in some instances makes them susceptible to physical attacks and probing.

With DICE, the TCG have tried to define a way to establish device unique identities, provide ways to do attestation and sealing. In short it can work as a lightweight mechanism for devices where a TPM device isn’t suitable. It also tries to address the fact that there are many different vendor specific solutions offering provisioning, secure boot, attestation etc. These solutions are not always compatible. This in turn makes it difficult for other companies to offer products based on hardware from various vendors, as they must deal with a wide range of vendor-specific solutions.

The main question about DICE seems to be that there is uncertainty about it’s user base. I.e., people wonder whether it’s actually being used and if it’s used, is the standard as suggested in the DICE TCG specification robust enough or is there room for interpretation that eventually open up for fragmentation? I.e., is there a risk that we see multiple implementations of DICE, that doesn’t play nicely together? In addition to that, there seems to be no good examples showing how to leverage this from a system fully booted up to the OS. Likewise, the TCG specification doesn’t mandate how to pass data between firmware entities.

Investigation

Linaro have seen that more and more members as well as non-member have started to use DICE or ask questions about it. Therefore we initiated an investigation which has been taking place in a couple of different steps, where we have touched the following topics:

Understand the DICE architecture

To be able to discuss DICE internally and with others, we had to read and understand the concepts ourselves. By now, we believe that we have a solid understanding of the concepts, how it’s meant to be implemented from a boot point of view. We still need more information about how to tie everything from a booted system to the OS level.

Adoption

An obvious question is whether this is already been used by others or whether it’ll become a mandate of some sort. We’ve been able to collect a list of various companies using it in one or another way.

• Google: They have created an open profile for DICE (with HAL documentation). In this profile, they have provided lots of details regarding their proposed implementation of DICE. Google have also suggested a couple of extensions to the TCG DICE specification. For example, they suggest that you create two CDI’s in every layer, one for attestation and one for sealing. Google are moving to require Open Profile for DICE implementations in Android. With regards to Google Widevine, we’ve already seen patches in flight in Trusted Firmware A for example. Google have also investigated whether DICE could be used to protect regular TPM commands from active imposers.

• Microsoft: Who was the original founders of DICE (it started out as RIoT). They use it on Azure IoT devices, Device Provisioning Service (DPS) (see this roundtable article for additional information).

• Micron: Features Authenta which is a technology meant to secure IoT device. Authenta leverage DICE as one of the building blocks to make sure that only trusted IoT devices with healthy software can gain access to the Microsoft Azure IoT cloud platform.

• Microchip: Use it in CEC1702 for Azure IoT Hub Device Provisioning Service (DPS) use cases.

• Nvidia: Created the ConnectX-7 OCP NIC 3.0 TSFF 400G card that implements DICE based attestation.

• STMicroelectronics: Unknown usage, but according to TCG the STM32L0\L4 family supports DICE.

• Windbond: Created TrustMe which is a secure flash adhering to the Common Criteria EAL5+ secure certification. This secure flash supports DICE as specified by TCG.

• TI: UniFlash CC3x20, CC3x3x SimpleLink™ belongs to one of TI’s MCU platforms, where they’ve implemented DICE as an optional feature. Here is a bit more information as well explaining how they use DICE.

Member discussions

We’ve been coming back to DICE a couple of times for a bit more than a year. We’ve been presenting DICE to various SC’s (LEDGE, Linaro TSC, Trusted Firmware TSC and LCG) and we’ve been having one on one discussions with various members and non-members. This has been done both to provide information about DICE to those who are unaware of its existence and more importantly, to collect feedback, open questions, ideas, etc.

Feedback

In this section we’ve written down most of the information and feedback we’ve collected from various sources.

Hardware

What is required from hardware point of view to be able to support DICE?

• In chapter 6 in the TCG DICE specification, we find the requirements as stated by TCG.

• Google have created a Hardware Implementation Checklist in Appendix B of their Open Profile for DICE.

• If we try to summarize the above, we get:

  • UDS: The Unique Device Secret (UDS) must be unique, cannot be used by others as an identifier, and must have the same level of security as the device's attestation process. The UDS should be at least 256 bits if the attestation process is determined by external software. It should not be rewritable as changes to the UDS can impact device attestation and access to stored secrets.

  • DICE engine: The DICE must have exclusive read access to the Unique Device Secret (UDS), meaning only it should be able to read it. Read access to the UDS is typically enabled when the DICE begins executing and can be disabled with a software command. This should happen in mask ROM when powering on the device. If the device has a debug port or mode, it should only be activated during reset or when explicitly activated by software after the DICE. Any attempt to read the UDS when the debug port or debug mode is enabled should be denied or output an uncorrelated value (such as all 0s). For DICE to be immutable, it must be rendered immutable during the manufacturing process. In contrast, an upgradable DICE can only be updated through a secure, manufacturer-controlled process. After updating, the DICE should continue to conform to the specification, and the Device Identifier Composition (CDI) should remain unchanged.

Software

Is there a standard implementation of some sort that all vendors are using?

No, from what we’ve understood so far after our investigation, there is no standard implementation. Those who support DICE in their products have created their own implementation based on their interpretation of the TCG DICE specification.

How will information be passed between boot stages?

The TCG DICE specification doesn’t mandate how that should happen. As we see it there are at least two ways how this can be done. One way is via DeviceTree, that Google has been doing in their patches to TrustedFirmware A. The other way is to use transfer lists and transfer entries as suggested by the Firmware Handoff Specification. We believe that the latter is the more correct one.

If there is no standard implementation, doesn’t that cause fragmentation?

One of the issues TCG have tried to address is the fact that there are multiple provisioning solutions out there. Almost every vendor have invented their own solution. Although vendor specific solutions on their own gets the job done, it doesn’t scale for companies who offers solutions and software that will run on lots of different hardware. The DICE requirements in the DICE specification is from a technical point of view easy to implement and should normally not take a lot of space in terms of memory footprint. However, the question of whether the lack of standard DICE implementation etc. would actually be counterproductive, i.e., create fragmentation rather than reduce it, is a valid one.

This is one of the key reasons we're looking at it, to put it simply. We seek clarity on implementing DICE support and understanding the process of passing information between boot stages up to the operating system. We also aim to provide implementation suggestions, PoC’s and demonstrate how to use it from an end user perspective. Additionally, we want to explore the possibility of achieving compatibility with other boot methods, such as TPM-based boot, allowing for seamless switching between the two.

What happens during software upgrades if the device ID is expected to remain unchanged?

TCG suggest that the Device ID is derived at the first mutable binary. On Armv8-A systems that would be BL2. However and although it’s probably not often that BL2 needs to be changed, it is still not unlikely that we would like to update it at some point. With BL2 being updated, we would derive a new CDI, that in turn would lead to a new Device Identity. This would be an undesirable consequence. Therefore Linaro have suggested that we introduce a BL1.5, that would be solely responsible for deriving the Device ID and the first Alias Key pair etc. We discuss this a bit more further down in one of the objectives, but the goal here is to create software layer that although is mutable, should be treated as immutable. Another positive side effect would be that it would be easier to certify this due to smaller TCB.

Will DICE require support from other secure elements?

The short answer is no. The nuanced answer is that having access to TPM, TEE, or similar secure enclaves can be useful and, for example, enable the storage of private keys and other data, that is coming from or needed by DICE. But that is something going beyond the specification. So, if and when we make changes like that, it should at least be compatible with the specification and even better make it into the specification as some kind of extension.

How will the private key of the Alias key-pair be protected if the last DICE layer is the OS?

Under normal circumstances, the Alias key-pair will be accessible to all clients running at the same exception level and runtime. That means that an Alias key-pair accessible to the Linux kernel will be accessible to all kernel code. Likewise if DICE is extended all the way to user space, the Alias keys would be exposed to everything running in userspace. Having said that, there are features like AppArmor, SELinux etc that eventually can address that to some extent.

In short, making the private key available to unauthenticated and unauthorized parties is problematic. But, we have to remember that the public key from the key-pair has been put into a certificate (Alias certificate), that in turn has been signed by the previous layer. This goes all the way back to the root of trust. I.e,. the certificate chain will ensure that this public key indeed belong to and comes from this particular device and manufacturer. If we imagine that we use the private Alias key to sign an attestation request, then the remote verifier will only be able to successfully verify that signature using the matching public key. Any other attempt to verify either a tampered signature or a signature made with another private key will fail.

But we still have the problem that if anyone can access this private key, then in theory an attacker could sign known good data and return that to an attestation request, while the attacker at the same time have modifier code and data elsewhere. What about encryption? It’s out of question since the private key is accessible to unauthorized parties.

For this reason we suggest that a TEE environment or similar, owns the last layers key-pair and that the TEE environment is responsible of responding to attestation requests.

General

What is the minimum we need to do if we want to be prepared to support DICE later on?

Some companies we've spoken with have decided to start by keeping an eye on this and see where it goes. However, they are interested to learn about the bare minimum amount of work required to prepare their devices for future use of DICE. There are two aspects to our recommendation:

1. If we strictly look at the TCG specification, then the hardware must be able to do what we mentioned further up in the section “What is required from hardware point of view to be able to support DICE?”.

2. If we want to support future extensions as for example the proposed Open Profile from Google, then there would be a need to derive more than a single CDI in the mask ROM.

For that reason, we believe the minimum should be what is mentioned at “1”. The rest is “just” software.

Suggested plan for enabling a DICE chain on AArch64 / Armv8-A

Since there still are a lots of open questions, we suggest that we try to do a couple of things in parallel. We suggest that we shall start working on implementing support for DICE in Trusted Firmware-A according to the TCG DICE Specification. That would should be pretty straightforward. That is Objective#1 below.

After that we suggest that move the DICE code we’ve added to BL2 and run that in a separate boot stage that we call BL1.5. That would give us a separate layer dealing with device identity, that should stay the same throughout the lifetime of the device. That is Objective#2 below.

Diagrams

This diagram is mean to visualize how the DICE boot flow could look like on an Armv8-A device.

Open

Objective#1 - DICE proof of concept, following the TCG specification

The first objective is about making an implementation for Armv8-A that follows the TCG specification. Since the TCG DICE specification only outlines DICE and the first two layers, this objective will be about adding the features to the BL1, BL2 and perhaps BL3.1.

We don’t mandate what device to use for this work, but it would probably make a lot of sense to base the work on a QEMU Armv8-A build, that runs TrustedFirmware-A, OP-TEE, U-Boot and Linux kernel with user space. We already have stripped down and small software stacks running that, for example the official OP-TEE QEMU v8 setup. The benefits with using a stack like that is that anyone can try it out, it doesn’t require additional hardware and it’s possible to debug all binaries.

Req#001 - BL1 runs DICE

This requirement is about implementing the DICE functionality into the code acting as mask ROM, that would be BL1 on an Armv8-A device. We don’t mandate how the handover of the CDI should be done, but we suggest to use transfer lists and transfer entries as suggested by the Firmware Handoff Specification.

Acceptance criteria:
At reset, BL1 reads the UDS, measure BL2 and compute the CDI according to section “6.4 DICE Operation”. As per “Note 11” in the same document, using the UDS as the key for the HMAC is inexpensive from an implementation standpoint, but significantly strengthens the security, therefore we believe it’s worth considering the HMAC variant of CDI generation. The CDI should be handed over to BL2 and be ready to be used there.

Req#002 - BL2 shall derive and hand over Device ID key-pair and certificate

This requirement is a continuation of Req#001. The goal with this requirement is to make sure that

• We can derive an asymmetric device identity key-pair , i.e., the Device ID public and private key pair.

• Create the Device ID certificate.

• Make the Device ID certificate available to to BL3.1.

Since this is solely about the Device ID key, there is no need to read and hash BL3.1 (something that will be needed when generating Alias key-pairs). The reference code here might be useful.

Acceptance criteria:
BL2 shall be able to take the CDI from BL1, generate a Device ID key-pair and Device ID certificates, according to section “5. Architecture”. The Device ID public key and certificate should be passed to BL3.1.

Req#003 - BL2 shall derive the Alias key-pair and hand it over to BL3.1

This requirement is a continuation of Req#001. The goal with this requirement is to make sure that we can derive the Alias public and private key pair. This should involve measuring BL3.1, which in addition to the CDI is taken as an input to the Alias Key generation.

Acceptance criteria:
BL2 shall be able to take the CDI from BL1, generate a Alias key-pair, according to section “5. Architecture”. The Alias key-pair should be passed to BL3.1 according to “8.1”.

Req#004 - BL2 shall create the Alias key certificate and hand it over to BL3.1

This requirement is a continuation of Req#003. The goal with this requirement is to make sure that we can create the Alias key certificate. This should involve the previously generated Alias Key and Device ID key.

Acceptance criteria:
The Alias Key Certificate shall be generated according to “5. Architecture”. The Alias key certificate should be passed to BL3.1.

Objective#2 - DICE Layer 0 running BL1.5

This objective is about moving out the DICE code previously running at BL2 to instead run in a new bootstage that we call BL1.5. In this layer should solely focus on the doing the DICE operations as specified in “Layer 0, 5. Architecture”. By doing so, we should have a bootstage that will never need to be changed during the device's lifetime. I.e., the DeviceID would stay intact throughout the lifetime of the device.

Req#005 - BL1.5 should provide DICE features previously done by BL2

Functionality wise, this shall offer the same features as BL2 provided after completing Req#001, 2, 3 and 4. BL1.5 shouldn’t contain BL2 code. I.e., BL1.5 should just be an intermediate step doing DICE operations before handing over runtime execution to BL2.

Note that, BL2 will still need to be able to derive Alias Key-pair and Alias certificate. So that code can probably stay as it is, but the code for deriving the Device ID key-pair and certificate should be removed from BL2, since that shall only be done by the first mutable binary.

Acceptance criteria:

• A new BL1.5 has been introduced.

• BL1.5 creates the Alias keys and certificates and also creates Device ID keys and certificate.

• The Alias key-pair, Alias certificate, Device ID public key and the Device ID certificate should be passed to BL2.

Objective#3 - DICE support in BL3.1

This objective is about adding support in BL3.1 so it also can generate the Alias key-pair and the Alias certificate corresponding to this layer. Note that BL3.1 will not pass execution directly to BL3.2 (TEE). Instead BL3.1 will return back to BL2, that in turn will setup and call BL3.2. Therefore the BL3.1 must pass it’s DICE data back to BL2 and BL2 in turn has to pass this onto BL3.2. The sequence diagram further up shows how the call chain would look like.

Req#006 - BL3.1 shall create Alias key-pair and Alias certificate

Similar to other layers, Bl3.1, should also be able to create the Alias key-pair and certificate.

Acceptance criteria:

• BL3.1 is able to generate Alias key-pair and Alias certificate.

• BL3.1 is able to return back the Alias data to BL2.

Objective#4 - DICE support in TEE

We envision that it is the TEE environment that ultimately will act as the attester. Therefore we believe that the DICE chain ends in the TEE and whenever a Verifier requests evidence in form a an attestation request it’s the TEE’s responsibility to gather data for those requests. That might be to make measurements of runtime such as U-Boot, Linux OS etc.

Req#007 - TEE shall create Alias key-pair and Alias certificate

Acceptance criteria:

• BL3.2 / TEE is able to generate Alias key-pair and Alias certificate.

• BL3.2 / TEE should leverage secure storage to save DICE data.

 Timeline

 Milestones and deadlines

 Reference materials

• DICE Attestation Architecture

• DICE - A Formally Verified Implementation of DICE Measured Boot

• Practical Runtime Attestation for Tiny IoT Devices

• Using DICE Attestation for SEV and SNP Hardware Rooted Attestation

• TCG Trusted Attestation Protocol (TAP) Information Model for TPM Families 1.2 and 2.0 and DICE Family 1.0

• The Lazarus Effect: Healing Compromised Devices in the Internet of Small Things

• https://github.com/microsoft/RIoT