I've not thought this through extensively, but couldn't you just flash signed firmwares onto those "single-purpose trusted devices"? If they were open to flashing that is.
What more to want from a security perspective? In-device protection from flashing? Sounds similar to security through obscurity. I'd prefer easy ways to check what a device is flashed with. Something like a checksum calculator device. Not sure if that's a reasonable idea.
There's a bunch of cases where you want these devices to be resilient against attackers who have physical access to the system. That means it has to be impossible to simply re-flash them given physical access, unless you can detect that this has happened. That's what the trusted boot side of this is - it gives you an indication that that reflashing has occurred.
Out of band firmware validation is a real thing (Google's Titan sits in between the firmware and the CPU and records what goes over the bus, and can attest to that later), but that's basically just moving who owns the root of trust, and if you don't trust your CPU vendor to properly record what firmware it executes you should ask whether you trust your CPU vendor to execute the instructions you give it. Pretty much every option we currently have is just in a slightly different part of the trade off space.
> There's a bunch of cases where you want these devices to be resilient against attackers who have physical access to the system.
I looked into TPM stuff a few years ago, and it all seemed pretty useless to me.
First of all, the entire key-protection house of cards relies on the assumption if you've booted the right OS, the keys can safely be unsealed. But the TPM does nothing to protect from security issues beyond that point, which is the vast majority of security issues.
Second of all, if you're worried about someone snatching your laptop or phone, full disk encryption where you type the password at boot gets you 99% of the protection with much less complexity. And the much lower complexity means many fewer places for security bugs to be accidentally introduced.
Third, if you're worried about evil maid attacks where someone dismantles your laptop and messes with its internals without you knowing then gives it back to you, then the TPM isn't sufficient protection anyway. They can simply put in a hardware keylogger, or get direct memory access, in which case it's game over anyway.
And fourth, the TPM doesn't have a dedicated hardware button (making it a shitty replacement for a U2F key) and doesn't have an independent clock (making it a shitty replacement for TOTP on your phone) so it's not even a good replacement for other security hardware.
About the only use I can see for this stuff is if you're some huge multinational company, and you think even the authorised users of your computers can't be trusted.
>the TPM does nothing to protect from security issues beyond that point, which is the vast majority of security issues.
I hear this type of thing often but it's the wrong mindset to take when dealing with this stuff. Security holes in one part of the stack are not an excuse to avoid fixing security holes in other parts -- if you do that, you now have multiple security bugs that are going unfixed.
>And the much lower complexity means many fewer places for security bugs to be accidentally introduced.
This doesn't seem to make any sense, avoiding securing the boot process does not mean the boot process is any less complicated or somehow has less parts that can be compromised. TFA is just describing how to secure the parts that are already there.
>They can simply put in a hardware keylogger, or get direct memory access, in which case it's game over anyway.
I'm not sure how this is related, building a tamper-proof case seems to be outside of the scope of this. This seems to cover only the software parts.
> avoiding securing the boot process does not mean the boot process is any less complicated
Of course it does: Not only does secure boot add an extra point of failure, it's a point of failure that's specifically designed to be highly sensitive, and to fail locked, and that hardly anyone in the kernel development community is testing with.
> I'm not sure how this is related
From a computer owner's point of view, the TPM's secure boot functionality exists only to protect against attackers with physical access to the device. After all, if a malicious attacker making a remote attack has the ability to replace your bootloader or reflash your BIOS, they've already got everything.
In other words, secure boot is there to protect against an evil maid [1] removing your hard drive, replacing your bootloader with one that logs your full disk encryption password, then subsequently stealing your laptop and password at the same time. Or something of that ilk.
However, the TPM is insufficient to protect against such attacks.
As such, secure boot fails to provide the one thing it claims to provide.
A serious system - like the xbox's security system - (a) has the functionality on the CPU die, and (b) has the hardware for full speed RAM, bus and disk crypto, all with keys that are inaccessible to the OS.
I don't understand what you mean extra point of failure. There is a boot process, you can't get rid of it because then you can't boot the machine. So you either secure it or you don't. I get the concern that the hardware implementation could contain bugs, and that's a real concern, but your system is not going to be less secure by having this -- at worst, it seems it can only be as insecure as it would be without it.
>However, the TPM is insufficient to protect against such attacks. As such, secure boot fails to provide the one thing it claims to provide.
I don't think anyone is saying TPM or secure boot alone is going to prevent against such attacks. It needs to be combined with some other physical protection measures, e.g. a tamper-proof case of some kind.
Likely what they are referring to is how UEFI has greatly complicated the nature of a computer's boot process by essentially inserting a firmware runtime into what was a simpler to understand chain of POST->Hand off to program at address.
I had issues wrapping my head around this as well with regards to things like Network Boot etc, where I could not for the life of me understand or justify a boot process having a runtime capable of doing all this extra cryptographic/network nonsense when all I bloody wanted was my OS, up, now.
Not to get nostalgic, but that magical era for a user around Windows XP with a <5 second boot was just that; magic.
I know all the oldtimers will come out of the woodwork with horror stories of competing, sloppily specified BIOS implementations, the pain of malware hiding in CMOS, the threat of rootkits, etc... And the admins will chime in with "How do you expect me to power on the thousands of servers in my datacenter without network access during boot"?
Those are valid and real situations in isolation I can stomach. I cannot, however, stomach a boot process whereby a non-owner arranges things in a way where it is guaranteed that they get the final word in deciding how hardware you paid for is used, which requires the composition of those services.
Note the term "appliance" in the submission title, and "single-purpose trusted devices" in the comment chain you replied to. General end-user desktop devices like your laptop indeed aren't that high on the list of use cases, at least not without further development in other areas. (although I think you are somewhat skipping over the part of being able to protect secrets stored in the TPM against being requested by an unverified system)
What more to want from a security perspective? In-device protection from flashing? Sounds similar to security through obscurity. I'd prefer easy ways to check what a device is flashed with. Something like a checksum calculator device. Not sure if that's a reasonable idea.