Page Comparison

...

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

...

...

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”.

...

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

...

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 to Grub, Linux or something similar.

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

	Priority	Description	Jira
1	Must have:

It shall not be possible to read out the private key via U-boot commands

	Ability to create Alias-key pair. Alias Key is used as input for the generation of the Alias key certificate. The Alias key certificate shall have a statistically unique serial number (see 7.3.2). Ability to save and retrieve DICE data from memory (RAM).
2	Nice to have:	Store DICE data to secure storage.
3	Not in scope:	Other extensions, like the Google Open Profile for DICE. Creating TA’s / interface to be able to respond to attestation requests.

\uD83D\uDDD3 Timeline

\uD83D\uDEA9 Milestones and deadlines

...

\uD83D\uDD17 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

...