5 ms·
> * Secure Boot (vendor-keyed deployments) I wish this myth would die at this point. Secure Boot allows you to enroll your own keys. This is part of the spec,
by Foxboron 8mo ago
> * Secure Boot (vendor-keyed deployments)
I wish this myth would die at this point.
Secure Boot allows you to enroll your own keys. This is part of the spec, and there are no shipped firmwares that prevents you from going through this process.
- digiown 8mo ago> Secure Boot allows you to enroll your own keys UEFI secure boot on PCs, yes for the most part. A lot of mobile platforms just never supported this. It's not a myth.
- 201984 8mo agoWhat about all those Windows on ARM laptops?
- yjftsjthsd-h 8mo ago> This is part of the spec, and there are no shipped firmwares that prevents you from going through this process. Microsoft required that users be able to enroll their own keys on x86. On ARM, they used to mandate that users could not enroll their own keys. That they later changed this does not erase the past. Also, I've anecdotally heard claims of buggy implementations that do in fact prevent users from changing secure boot settings.
- teddyh 8mo ago“buggy”
- yjftsjthsd-h 8mo agoDon't get me wrong, I'm happy to attribute a lot of malice to Microsoft, but in this case I really do believe that it was incompetence. Everything I've ever read about 90%+ of hardware vendors is that shipping hilariously broken firmware is an everyday occurrence for them. (This is separate from Windows RT, of course)
- NekkoDroid 8mo agoThis reminds me of when I enrolled only my own keys into a gigabyte AB350 and I just soft-bricked it because presumably some opt-rom required MS keys. I exchanged it for an Asrock board and there I can enable secure boot without MS keys and still have it boot cuz they actually let you choose what level of signing the opt-rom needs when you enable secure boot. What I want to say with this is that it requires the company to actually care to provide a good experience.
- LooseMarmoset 8mo agoAndroid lets you put your own signed keys in on certain phones. For now. The banking apps still won't trust them, though. To add a quote from Lennart himself: "The OS configuration and state (i.e. /etc/ and /var/) must be encrypted, and authenticated before they are used. The encryption key should be bound to the TPM device; i.e system data should be locked to a security concept belonging to the system, not the user." Your system will not belong to you anymore. Just as it is with Android.
- charcircuit 8mo agoThen work with the bank to prove the signer is trustworthy.
- tadfisher 8mo agoBanks do this because they have made their own requirement that the mobile device is a trust root that can authenticate the user. There are better, limited-purpose devices that can do this, but they are not popular/ubiquitous like smartphones, so here we are. The oppressive part of this scheme is that Google's integrity check only passes for _their_ keys, which form a chain of trust through the TEE/TPM, through the bootloader and finally through the system image. Crucially, the only part banks should care about should just be the TEE and some secure storage, but Google provides an easy attestation scheme only for the entire hardware/software environment and not just the secure hardware bit that already lives in your phone and can't be phished. It would be freaking cool if someone could turn your TPM into a Yubikey and have it be useful for you and your bank without having to verify the entire system firmware, bootloader and operating system.
- account42 8mo agoBanks do this because they can. If most consumer devices did not support the tech they would not be able to.
- Brian_K_White 8mo agoI wish the myth of the spec would die at this point. Many motherboards secure boot implimentation violates the supposed standard and does not allow you to invalidate the pre-loaded keys you don't approve of.