What a TPM proves, and what it does not
A note on the difference between a measured boot and a protected runtime, and why the distinction matters when someone asks whether your hardware is confidential.
A question that comes up in every security review of an on-premises deployment: is this hardware confidential? And a Trusted Platform Module is often produced as the answer, because it is present, it is cryptographic, and it sounds like it should be.
It is not the answer. The distinction is worth stating precisely.
Measured boot
A TPM measures. As a machine boots, each stage hashes the next before handing over, and those hashes are extended into registers inside the module that cannot be rewound. Afterwards the module can sign a quote over those registers, and a relying party can check that the machine booted the firmware, bootloader and kernel it was supposed to.
That is a real and useful property. It gives you a hardware-rooted identity that survives restart, rebuild and reinstall, and it makes tampering with the boot chain detectable.
What it tells you about is the past.
Protected runtime
A trusted execution environment does something categorically different. It holds memory encrypted against the host, so the operating system, the hypervisor and anyone with physical access to the machine cannot read the workload while it runs. It attests to what is executing now, and it keeps protecting it.
A TPM proves what was loaded. A TEE proves what is running, and protects it while it runs.[src]
The two answer different questions. Confusing them in a security review is an error. Doing so in a datasheet is worse, because the customer making a decision on that basis is the one who finds out.
Why it is easy to get wrong
Partly vocabulary — measured, trusted, attested and secure all appear in both contexts. Partly configuration: platforms often ship with the module present in silicon but disabled in firmware, and frequently under a settings menu that has nothing to do with security, so the first discovery is that a machine which should have the capability reports none.
And partly incentive. One of these is a checkbox on a specification sheet and the other constrains which silicon you can buy.
How we handle it
Every system we ship has a hardware-rooted, persistent identity, and we describe that as exactly what it is. Where a configuration includes confidential-computing capability, that is stated separately and specifically, naming the mechanism. The two claims never stand in for each other.
This is a small piece of vocabulary discipline. It is also the kind of thing a customer’s security architect will check in the first meeting, and getting it right costs nothing.