...
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 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.
...
The main 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.
...
What happens during software upgrades if the device ID is supposed to keep the sameexpected to remain unchanged?
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 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.
Will DICE require support from other secure elements?
...