...
For that reason, we believe the minimum should be what is mentioned at “1”. The rest is “just” software.
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”. The CDI should be handed over to BL2, ready to be used by BL2.
...
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 coming from BL1.
| 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.
...
Suggested plan for enabling a DICE chain on AArch64 / Armv8-A
Since there 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”. The CDI should be handed over to BL2, ready to be used by BL2.
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 can derive the Device ID public and private key pair, create the Device ID certificate and make it available to to BL2. 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 | |
|---|---|---|---|
| 1 | Must have: |
| |
| 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#001. The goal with this requirement is to make sure that we can derive the Device ID Alias public and private key pair, create the Device ID certificate and make it available to to BL2. 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). 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 Device ID Alias key-pair and Device ID certificates, according to section “5. Architecture”. The Device ID public key and certificate Alias key-pair should be passed to BL3.1.
Priority | Description | Jira | |
|---|---|---|---|
| 1 | Must have: |
|
|
|
|
|
|
| 2 | Nice to have: |
|
| 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#001Req#003. 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 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: |
|
Priority
Description
Jira
Must have:
CDI as given by BL1 must be used to generate the Alias key-pair.
The measurement of BL3.1 must be used to generate the Alias key-pair.
The Alias key-pair should be based on ED25519.
The Alias key-pair should be handed over to BL3.1.
The CDI should never be accessible by BL3.1.
Nice to have:
Firmware Security Descriptor support which complements purely hash based measurement of the BL3.1.
Not in scope:
Alias key certificate generation
Other extensions, like the Google Open Profile for DICE.
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
...
Must have:
...
Alias Key is use as input to the generation for the Alias key certificate.
Device ID Key is use as input to the generation for the Alias key certificate.
The Alias key certificate should be handed over to BL3.1.
...
Nice to have:
...
Not in scope:
...
Other extensions, like the Google Open Profile for DICE.
Objective#2 - DICE Layer 0 running BL1.5
...
| 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 “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 to BL2.
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: |
|
\uD83D\uDDD3 Timeline
| Roadmap Planner | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...