...
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 and EDDSA 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 to conduct runtime attacks undetected. TPM devices support both of these concepts, which is likely one of the reasons why TPM devices 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 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 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 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 problem 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.
...
TCG suggest that the Device ID is derived at the first mutable binary. On Armv8-A systems that would be BL2. However, 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 we from 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.
...
What is the minimum we need to do if we want to be pared 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. They However, they are however interested about to learn about the bare minimum amount of work that must be done in order start using DICE in the futurerequired 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 at 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 DICEGoogle, then there would be a need to derive more than a single CDI in the mask ROM.
...
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.
...
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 BL2As 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: |
|
...
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 Bl3BL3.1 (something that will be needed when generating Alias key-pairs).
...