[hedora]

You do know those are trivially bypassed with a signal processor, right? If physical access is outside your threat model, that's OK, but it makes (for example) the forced Win11 upgrade for DRM^H^H^H boot integrity enforcement seem ridiculous.

https://pulsesecurity.co.nz/articles/TPM-sniffing

[sq_]

Yeah, fair enough. "Compliance" is probably the phrasing I should've used, rather than "security".

I've been curious for a while about the overall taxonomy of security, especially for embedded platforms. It seems like the only hope is defense in depth, given the power glitching attacks and the like that you can find demonstrated.

Specific to the Raspberry Pi, I believe I even saw a thread at some point where one of their firmware engineers was making the case that secure boot on the Pi 5 was equivalent to a TPM in almost any reasonable threat model, since, in either case, you were out of luck if an attacker had physical access and was willing to put in enough effort.

[bradfa]

Normal secure boot does not use the TPM. Secure boot is the proactive process of ensuring only allowed code loads and executes.

The TPM is used for measured boot, the post process to understand what actually was booted and if the right set of things were booted then to allow unlocking of specific items like keys.

Both are important but they are not the same thing.

[bradfa]

The article you link to explains how to defeat the sniffing with TPM 2.0. But also, there’s no reason a physical TPM has to be a separate IC package.