...
Objective | Establish DICE as an alternative to TPM | ||||||
Due date | TDBSee proposed schedule at the bottom of the page | ||||||
Key outcomes |
| ||||||
Status |
|
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 TPM devices 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. Additionally, TPM devices comes in the 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 could 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 for this out there. Solutions that 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 the 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.
...
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. Where we We still lack need more information is about how to tie it all together everything from a booted system that has booted all the way up 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.
Member discussions
...
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.
...
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.
...
What happens during software upgrades if the device ID is supposed to keep the sameexpected 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.
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:
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?”.
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.
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.
...
Priority
...
Description
...
Jira
...
Must have:
...
Hash (SHA-256 or better) based CDI.
Ability to generate a hash (SHA-256 or better) of the BL2 code.
UDS should not be accessible by BL2.
Only BL2 should be able to access the CDI, i.e., Bl3.1 and later boot stages should never get access to the CDI being passed from BL1 to BL2.
| Jira Legacy | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Nice to have:
...
HMAC based CDI.
Debug support, where the UDS is just zeroes.
...
Not in scope:
...
Other extensions, like the Google Open Profile for DICE.
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).
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.
...
Priority
...
Description
...
Jira
...
Must have:
...
CDI as given by BL1 must be used to generate the Device ID key-pair.
Device ID key-pair should be based on ED25519.
The device generated Device ID public key should be used when creating the Device ID certificate.
The Device ID public key should be handed over to BL3.1.
The Device ID certificate should be handed over to BL3.1.
CDI and the Device ID private key should never be accessible by BL3.1.
...
Nice to have:
...
Ability to generate CSR for the public Device ID key.
...
Not in scope:
...
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:
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?”.
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.
...
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.
Priority | Description | Jira | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Must have: |
|
| ||||||||||||||
| 2 | Nice to have: |
| |||||||||||||||
| 3 | Not in scope: |
|
...
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
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 Alias Device ID key-pair and Device ID certificates, according to section “5. Architecture”. The Alias key-pair Device ID public key and certificate should be passed to BL3.1.
Priority | Description | Jira | |
|---|---|---|---|
| 1 | Must have: |
|
|
The Alias key-pair should be based on ED25519.
|
| |
| 2 | Nice to have: |
| ||
| 3 | Not in scope: |
|
|
...
Req#003 - BL2 shall
...
derive the Alias key
...
-pair and hand it over to BL3.1
This requirement is a continuation of Req#003Req#001. The goal with this requirement is to make sure that we can create derive the Alias public and private key certificatepair. This should involve the previously generated Alias Key and Device ID keymeasuring BL3.1, which in addition to the CDI is taken as an input to the Alias Key generation.
Acceptance criteria:
The Alias Key Certificate BL2 shall be generated according to able to take the CDI from BL1, generate a Alias key-pair, according to section “5. Architecture”. The Alias key certificate -pair should be passed to BL3.1 according to “8.1”.
Priority | Description | Jira | |
|---|---|---|---|
| 1 | Must have: |
Alias Key is used as input for the generation of the Alias key certificate.
|
| |
| 2 | Nice to have: |
Not in scope:
Other extensions, like the Google Open Profile for DICE.
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 “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, since BL2 will 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.
...
Priority
...
Description
...
Jira
...
Must have:
...
Alias Key is used as input for the generation of the Alias key certificate.
Device ID Key is used as input for the generation of the Alias key certificate.
The Alias key certificate should be handed over to BL2.
The Device ID certificate should be handed over to BL2.
The Device ID public key should be handed over to BL2.
...
Nice to have:
...
Not in scope:
...
Other extensions, like the Google Open Profile for DICE.
Objective#3 - DICE support in BL2 revised
Since we’ve moved key functionality out from BL2 down to BL1.5, we need to clean up and make sure that BL2 is working as any other DICE layer except the first. I.e., it shall be able to derive it’s own Alias Key and certificate and it shall be able pass those to the next boot stage.
\uD83D\uDDD3 Timeline
...
| |||
| 3 | Not in scope: |
|
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.
Priority | Description | Jira | |
|---|---|---|---|
| 1 | Must have: |
| |
| 2 | Nice to have: | ||
| 3 | Not in scope: |
|
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.
Priority | Description | Jira | |
|---|---|---|---|
| 1 | Must have: |
| |
| 2 | Nice to have: | ||
| 3 | Not in scope: |
|
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.
Priority | Description | Jira | |
|---|---|---|---|
| 1 | Must have: |
| |
| 2 | Nice to have: |
| |
| 3 | Not in scope: |
|
\uD83D\uDDD3 Timeline
| Roadmap Planner | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
\uD83D\uDEA9 Milestones and deadlines
Milestone | Owner | Deadline | Status | ||||||
|---|---|---|---|---|---|---|---|---|---|
Objective#1 - Expand device compatibility |
|
|
...
| ||||||
\uD83D\uDD17 Reference materials
DICE - A Formally Verified Implementation of DICE Measured Boot
Using DICE Attestation for SEV and SNP Hardware Rooted Attestation
The Lazarus Effect: Healing Compromised Devices in the Internet of Small Things