Would love to see actual security focused hardware/software features, like full OP-TEE, fTPM (or a more ideally a real physical TPM), and similar. For example, so that the OTP isn't the only way to store a disk encryption unlock key.
The existing secure boot mechanisms aren't bad, but allowing for more than one public key hash in OTP would be nice, too.
These kinds of things are expected to be on modern embedded SOCs and SOMs now.
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.
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.
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.
The existing secure boot mechanisms aren't bad, but allowing for more than one public key hash in OTP would be nice, too.
These kinds of things are expected to be on modern embedded SOCs and SOMs now.