Trusted computing was never about security, it’s a way to take ownership of computers away from users and give it to computer manufacturers and Microsoft. It’s also not a good security model.
well Android Verified Boot also allows changing keys! but like 15 niche phones implement that function out of thousands. out of which it is broken on several such thatit bricks the phone permanently. further, android hardware attestation can make use of AVB, but virtually no apps use it, every app doing such a verification depends on google play integrity, for which you can’t change keys and still pass the ckecks.
google has already implemented on android what microsoft is only just dreaming of to pull off, despite preparing it since much earlier. I don’t know what they are waiting for, everyone knows there would be no negative consequences to them.
These protections work at different layers and hence, you use both.
First off, you can’t really encrypt the first boot loader by design, your UEFI needs something it can read and run. You need to protect this first boot stage somehow, and this is what Secure Boot is for; it verifies the signature of the payload it starts to protect it against tampering.
My disk and bootloader are both encrypted but I can get to my UEFI menu without decrypting. I’ve been meaning to password protect that but I get nervous about changing anything in UEFI.
I didn’t know much about secure boot or TPM or PAM so I was planning on setting those up, but I’ll skip it if it’s just about corporate capture. Not that my hardware is from some big name corpo or anything, it came with linux by default. But still.
Also I’m worried about locking myself out of booting from live USBs, especially if I ever need to use a recovery drive. But I think if I understand correctly then most official ISOs should still work, but I’m not 100% certain.
Trusted computing was never about security, it’s a way to take ownership of computers away from users and give it to computer manufacturers and Microsoft. It’s also not a good security model.
well Android Verified Boot also allows changing keys! but like 15 niche phones implement that function out of thousands. out of which it is broken on several such thatit bricks the phone permanently. further, android hardware attestation can make use of AVB, but virtually no apps use it, every app doing such a verification depends on google play integrity, for which you can’t change keys and still pass the ckecks.
google has already implemented on android what microsoft is only just dreaming of to pull off, despite preparing it since much earlier. I don’t know what they are waiting for, everyone knows there would be no negative consequences to them.
For #2, Full Disk Encryption (including bootloader)
These protections work at different layers and hence, you use both.
First off, you can’t really encrypt the first boot loader by design, your UEFI needs something it can read and run. You need to protect this first boot stage somehow, and this is what Secure Boot is for; it verifies the signature of the payload it starts to protect it against tampering.
My disk and bootloader are both encrypted but I can get to my UEFI menu without decrypting. I’ve been meaning to password protect that but I get nervous about changing anything in UEFI.
I didn’t know much about secure boot or TPM or PAM so I was planning on setting those up, but I’ll skip it if it’s just about corporate capture. Not that my hardware is from some big name corpo or anything, it came with linux by default. But still.
Also I’m worried about locking myself out of booting from live USBs, especially if I ever need to use a recovery drive. But I think if I understand correctly then most official ISOs should still work, but I’m not 100% certain.
Clearly, I still have a lot to learn…