Ever been in a meeting where someone drops terms like “TEE,” “TPM,” or “FIPS-certified” and everyone nods along, pretending they understand? Yeah, me too.
Last night I saw JP Aumasson tweet something that hit home:
“Some discussions would be so much easier if people knew the definitions of ‘TEE’, ‘TPM’, ‘Secure element’, ‘Secure enclave’, ‘HSM’, ‘Trusted computing’, ‘FIPS(140-2/3)-certified’, ‘Common criteria’, ‘security target’, etc. Plus now the marketing-oriented term ‘confidential computing’ is used to mean a variety of things with varying security properties.”
He’s right – the security tech space is a mess of overlapping terms, marketing buzzwords, and genuine technical concepts. So I threw together a guide to sort this stuff out.
What’s Actually Different Between These Things?
At their core, these technologies do three things:
- Minimize what code you need to trust (the TCB)
- Create isolation between different parts of a system
- Establish trust across different machines
A TPM is not the same as a TEE. Intel SGX is not identical to AMD SEV. And no, slapping “FIPS-certified” on your product doesn’t automatically make it secure.
The Real-World Impact
When your vendor says they use “Confidential Computing,” do you know what that actually means for your data? Could be anything from “your data is encrypted in memory” to “we’ve got a fancy marketing term for standard virtualization.”
The differences matter. A secure element in your phone has around 10-50KB of trusted code. A standard Linux kernel? About 27.8 MILLION lines. One of these is much easier to secure than the other.
When Things Break
Even the most certified security tech fails. Hardware Security Modules (HSMs) with FIPS 140-2 certification—supposedly the gold standard for cryptographic security—have been compromised by design flaws. Look at the 2015 Safenet HSM vulnerability where API flaws in the PKCS#11 interface allowed full key extraction. Attackers with authenticated access could exploit weak key derivation mechanisms to extract the very keys the HSM was designed to protect.
Bottom line: No security technology is perfect. Each has its place, limitations, and potential failure modes.
I’ve put together a full technical deep-dive on this topic: From TPMs to TEEs: How Security Technologies Work—and Where They Fail.
As Winston Churchill observed, “He who fails to plan is planning to fail.” Understanding what’s under the hood of these technologies isn’t just academic—it’s essential for building systems that can actually withstand the threats they’ll face.
Very commendable effort and great result!
I have a comment for this paragraph:
“TPMs primarily verify system integrity at boot time. They’re part of your TCB and operate in a hardware-isolated domain that remains separate from the main operating system. When your laptop verifies that its bootloader hasn’t been altered by malware, it’s likely using a TPM.”
TPMs don’t verify integrity by themselves; they just help to record integrity evidence (measurement) and report them for a verifier to decide if they’re as expected or not.
That’s because TPMs are passive devices. While some roots of trust that “speak TPM” do also verifications as an extra feature (e.g. Secure Boot), platform integrity verification is deliberately left outside the scope of the TPM specification.
Perhaps you refer to TPM sealing? That does come close to verification, but it’s “just” a versatile way to release access to keys depending on measurements (or, more generally, policies). The TPM has no clue what the sealed measurements mean, and that’s a function of the OS or other platform software to say. The TPM merely checks if what a key was sealed to has been recorded again.
Another small comment:
Discrete TPMs are HSMs with some specific extra platform measurement capabilities, so it may help the reader to read about HSMs first (yes, HSMs are not just the big, networked ones).
Again, great work. I’ll try to read more of it.
I’ve added “it’s likely using a TPM to provide the measurements needed for that check.” to make that more explicit.