A reprogrammable HSM is a neat idea, but I think the author has not really understood the use cases TPM 2.0 is trying to support. The TPM 2.0 architecture docum

A reprogrammable HSM is a neat idea, but I think the author has not really understood the use cases TPM 2.0 is trying to support. The TPM 2.0 architecture document contemplates three distinct roots of trust, and the TKey can't really serve as any of them, at least not while maintaining its operational flexibility and simplicity the author likes about it. 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. What about just embedding DICE into the application processor and having the system serve as "its own HSM"? That only works for the very simplest boot policy of "these secrets should only be accessible to a device running a single fixed image". Maybe you're fine with reprovisioning your EV charging stations after every software update, but my devices get updated more often than that. 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. You need this for audit logs, and also for any kind of policy that might change over time. What if I want to change my password? What if I want to revoke access to a secret from an old OS image? Or record all uses of a signing key? All of these require some kind of storage that can't be rolled back to an earlier state. I think you could have a scheme where the chip stores the root of a Merkle tree of the NV state for every trusted application and relies on the host to provide the actual state for a specific trusted application + a proof that it's in the Merkle tree at boot, which would allow different trusted applications to be run on the same physical chip without interfering with each others data, but that is going to drastically complicate the design of this system and require some kind of runtime OS on the chip to control how the root is updated (otherwise a trusted application could roll the state back for other trusted applications). Finally you have the root of trust for reporting, which can sign trustworthy assertions about the system state. For example, attesting that a key is actually bound to the secure element, or that the system booted is a particular state, or to the audit log. For this you need a key that relying parties already know is bound to the secure element for this purpose. If you have different trusted applications with different secrets, and you want them all to be able to provide remote attestation, then you need to either go through a manual provisioning process for each application (someone needs to connect the device to a trustworthy system and check the attestation key for the application), or you need the firmware to sign something derived from the CDI using something derived from the UDS (which the TKey doesn't). It doesn't require a trusted runtime OS on the secure element though, so at least it has that going for it. I think the hardest of these is the measured boot use case, because to be useful it needs to be combined with anything that relies on measured boot. There's no point in measuring your boot process if you can't either remotely attest to it, or bind a secret to it, and it needs to be able to support whatever the host OS needs it to do, so I think attempts at TPM 2.0 style fully general trusted applications are close to unavoidable here. Maybe with some very clever ideas you can make a secure element that can actually replace all these use cases while being reprogrammable at runtime and having only small, purpose-specific trusted applications, but the TKey that exists today isn't it.