Effectively just for secure boot?

Posted Aug 7, 2025 10:19 UTC (Thu) by noodles (subscriber, #39336)
In reply to: Effectively just for secure boot? by aragilar
Parent article: Don't fear the TPM

While TPMs provide a measurement component that is very useful in a secure boot environment (knowing the image is signed is not sufficient, you want to know _what_ image is signed too), I very much did not talk about secure boot as part of my talk because it's not relevant for the interesting use of TPMs within Debian. You can store a key in the TPM and attest that it's actually hardware backed and non-exfiltratable outside of any use you might be making of the TPM to measure boot state. Even under Windows.

Additionally, if you care about tying your personal keys to machine state, you can make use of the TPM telling you what's been booted (for avoiding Evil Maid attacks) without having any secure boot support.

A proper HSM is obviously more desirable for performance reasons, but then you're also dealing with increased cost.

Effectively just for secure boot?

Posted Aug 7, 2025 11:42 UTC (Thu) by aragilar (subscriber, #122569) [Link] (1 responses)

Ah, I probably misusing the term "secure boot" then, I had assumed it included anything related to checking about the boot state and its trust.

Can you store many non-boot-related keys in TPMs, I recall reading https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will... and the vibe I get about TPMs is that they are basically cheaper HSMs for the purposes of storing keys (on the device)?

Effectively just for secure boot?

Posted Aug 7, 2025 15:15 UTC (Thu) by muase (subscriber, #178466) [Link]

> Can you store many non-boot-related keys in TPMs, I recall reading https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will... and the vibe I get about TPMs is that they are basically cheaper HSMs for the purposes of storing keys (on the device)?

Yes, you can use a TPM to generate, import or even seal external keys in varying degrees; you can pin them to hardware/software state with PCRs, and you can also require a PIN or similar for quick-but-still-interactive access.

I'm also not too sold on the "strong" distinction between TPMs and HSMs – it not only causes confusion (like in your case), but from what I know, HSM is the general super-term for everything that can work as an isolated secure element and does cryptography internally without exposing the keys. Be it a SmartCard, a YubiKey, an USB-YubiHSM, a TPM 2.0 module, an Apple Secure Enclave, a high-throughput PCIe module, a Pluton security chip... from what I know, and how the term is used in my environment, those are all HSM – just with different optimization goals: SmartCards/SIMs are removable and quickly exchangeable, TPMs are built-in and tightly integrated into the boot-cycle which allows them some additional attestations, the Secure Enclave has an additional focus on embedded biometry validation, etc.

To make things worse, those distinctions are also not strict; for example, there are PKCS#11 PCIe-HSMs that are strictly focused on a user-interactive root-CA-like role, and have a very low throughput and are not at all usable for TLS-handshakes. And for a mass-built and -shipped device, Apple's Secure Enclave has the absolutely stunning track-record of ZERO scientifically or publicly documented full (private) key extractions[1]; which suddenly makes it a low-throughput, but security-wise top-tier candidate compared to a lot of TPMs or even HSMs.

-----

[1] There were some successful attacks on the SEP, like the Pangu one, but that is not well-documented and we don't know if key extraction would have been possible, nor is it scientifically credible; and we have the the checkm8te/checkrain combination, which exploited the T2 – but again, no documented key extraction. And while running custom code is a **very big and impressive feat**, it's still not key extraction (similar to how running code in userland is not a root- or kernel-exploit).