...
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.
...
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.
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: |
|
...
Priority | Description | Jira | |
|---|---|---|---|
| 1 | Must have: |
| |
| 2 | Nice to have: | ||
| 3 | Not in scope: |
|
...
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.
...
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 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.
...
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
Roadmap Planner
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:
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.
\uD83D\uDDD3 Timeline
| Roadmap Planner | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
\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