> The first is the root of trust for measurement which consists of the first immutable boot code run on the application processor, which must be trusted to meas

> The first is the root of trust for measurement which consists of the first immutable boot code run on the application processor, which must be trusted to measure the first mutable code correctly, and the trusted hardware that receives these measurements. This trusted hardware needs to be present and running from the very earliest boot stage, and must keep running until the system is reset. If the application processor can reset the TKey after boot, it could reset the measurements and then imitate the legitimate boot chain, defeating the purpose of measured boot. If it can't then the TKey is running fixed firmware that can, at best, be changed by rebooting the system, and needs to be shared by all applications simultaneously. For a general purpose operating system that needs to be able to run arbitrary applications that in turn need to be able to support a wide range of systems, this pushes you inevitably towards something like the TPM 2.0 spec that tries to support all use cases at once. First, as far as I could gather so far, measured boot and discrete TPMs are fundamentally incompatible. Just boot whatever you want on the application core, and when it sends the bootloader to be measured to the TPM, just MitM the thing with a TPM genie, and have the genie give another bootloader to measure, one that the TPM would approve of. This unlocks the TPM and we just broke the chain of trust (power to the people). So okay, the TPM must be fused next to the application core to prevent any kind of MitM. It still needs a default firmware that does whatever is needed for the measured boot. After that though, why would the original firmware be needed? You only need to measure the bootloader once. Once you did the measured bootloader can measure the kernel etc. all the way to user space. Similarly, once the TPM has given away the hard drive's encryption keys to the application core, those keys aren't needed any more. So why couldn't we reset the TPM after boot? Even if I missed something there, we could imagine going in stages: have a measured boot core that's always running, but allow running additional code on top of that basic firmware (and give it derived keys in a DICE fashion). That way the only use cases the immutable firmware has to solve are secure/trusted/measured boot, and loading custom firmware on top for arbitrary HSM functionality. Couldn't that work? > The second is the root of trust for storage, which is a container for non-volatile memory with read and/or write controls. This is an easy one, to serve in this role you need protected non-volatile storage, the TKey has none, gg. That memory is orthogonal to the DICE approach, we don't necessarily need to forego all persistent state like the TKey does.