Page Comparison

...

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

...

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.

...

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.

...