...
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 form of external modules connected via a 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.
...
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?
...
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
...
Priority | Description | Jira | |
|---|---|---|---|
| 1 | Must have: |
| |
| 2 | Nice to have: |
| |
| 3 | Not in scope: |
|
...
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”.
Priority | Description | Jira | |
|---|---|---|---|
| 1 | Must have: |
| |
| 2 | Nice to have: |
| |
| 3 | Not in scope: |
|
...
Priority | Description | Jira | |
|---|---|---|---|
| 1 | Must have: |
| |
| 2 | Nice to have: | ||
| 3 | Not in scope: |
|
Objective#3 - DICE support in
...
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.
Acceptance criteria:
BL2 doesn’t no longer contain DeviceID key generation code.
BL2 doesn’t no longer contain DeviceID CSR generation code.
BL2 shall start execute code when BL1.5 has completed.
Objective#4 - U-Boot Alias Key pair and certificate generation
This objective is about making sure that U-Boot is capable of generating Alias key-pair and certificate.
Acceptance criteria:
...
U-boot shall be capable of creating the Alias-key pair and Alias certificate.
...
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
...
\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
...