It's totally crazy that we have to go through Microsoft to sign things to be able to have our OS run on third parties computers, and that Microsoft manage to win about this so easily as it was never seriously challenged.
replies(7):
AFAICT you can still disable Secure Boot in most UEFI firmware, and boot anything you like (or not like, if an attacker tampers with your system).
Microsoft showed they can semi-competently run a PKI. The end.
Now had the Linux folks stepped up to the plate early on, instead of childishly acting like Secure Boot was the computing antichrist, the story might be different. But they didn't. We only have shim because some people at Red Hat had the common sense to play ball.
"attacker tampers with your system" does not happen at least in the way you think it does or it does not protect you against meaningful attack at all.
This kind of victim blaming gets annoying very quick, as if the Linux ecosystem had any leverage at all on PC manufacturers…
I'd love to know if my machine has been compromised with early boot stage "meta-hypervisor" or not.
the promise of secure boot and trusted computing is backdoor-free boot.
what is in your eyes evil and garbage about that?
"My computer was compromised with an early boot stage hypervisor backdoor" happens basically never. It's an attack vector that exists almost entirely in the minds of infosec fucktards.
"My brand new device ships with vendor-selected boot certificates that can't be changed, can't be overridden, and control what software I can install onto my own device" happens with every other smartphone, gaming console, car, and even some PCs.
"Trusted Computing" is, and always was, about making sure that the user doesn't actually own his device. This is the real, tangible attack vector - and the target of this attack is user freedom and choice.
On Windows, secure boot has worked pretty well when it comes to rootkits. MBR rootkits were trivial to write, but UEFI rootkits require UEFI firmware changes or exploiting the bootloader process itself, both of which are much more complex. If malware uses the Linux shim, the TPM will notice and refuse to provide the Bitlocker key, so your computer won't boot without going to the IT office and asking for the recovery key (which should prompt more investigation).
and secure boot is still the antichrist, but we have to live with them.
Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet?
> vendor-selected boot certificates that can't be changed
That's a lie. Certain drivers are signed with a specific key, and they can only be used when this key is installed, which makes sense. The same thing happens with SSL - if you remove pre-installed CA certs from your device, HTTPS sites will stop working. However, nothing is stopping you from adding your own keys to the system and signing your own software with it.
> happens with every other smartphone, gaming console, car, and even some PCs
How often are you trying to install custom drivers on a smartphone, console or car? Why would you have secure boot issues on those?
> the target of this attack is user freedom and choice.
Which is exactly why users have the freedom and choice to just disable Secure Boot?
The reason why Apple or Nintendo go out of their way to make this impossible isn't user security. It's the "security" of their 30% App Store cut.
Out in the wild, Secure Boot exists to "secure" vendor revenue streams - and PCs are the only devices where it's even possible for the user to disable it. Most of the time.
What's happening in smartphone space is enough of a reason to treat Secure Boot on PC like an ongoing attack. The only reason why there are still legitimate ways to disable or adjust it is that most PC manufacturers don't have their own app store.
Boot from read-only media you control, or set up network boot from a source you trust - you have to trust the firmware anyway. Secure Boot itself is quite pointless.
There's some x86 hardware in the wild where the option to disable Secure Boot does not work. Which is part of the reason why Shim exists in the first place - it allows you to boot unsigned code with the machine owner's consent, even with Secure Boot enabled.
If it were not for Let's Encrypt, YES!
Secure boot would not be a problem if it were trivial to enroll keys. Give me a big message like:
"The OS you are trying to run is signed by an unknown key
sha256:whateverthefuck
IF YOU ARE NOT RUNNING AN INSTALLER YOU ARE MOST LIKELY CURRENTLY BEING ATTACKED AND SHOULD NOT PROCEED.
If you are running an installer VERIFY THE KEY with the one your OS vendor gave you.
Proceed? (Add the key as trusted)
yes NO"
The only reason there isn't a thriving community of third party OS's on most smartphones is because secure boot prevents it. And no, users do not have the freedom and choice to disable it (except on a very few models where the manufacturer has graciously allowed users to use their own devices how they want).
I don’t care if it’s required for every installation of if it’s once per hardware. I want to install software without asking a third party for permission. I want this to be doable entirely offline.
Plus, keeping Microsoft’s CA installed greatest reduces any security which I’d get from SecureBoot.
I might be misremembering it, but initial plans for Secure Boot were less open. It was only the stink raised that resulted in it being an option.
<< How often are you trying to install custom drivers on a smartphone, console or car? Why would you have secure boot issues on those?
Does it matter? Is it mine? If yes, then it should my concern. But that is the entire problem with trusted computing and recent trends in general. Corps become operators, users are downgraded to consumers.
Yes, the way trust is delegated in web PKI is absolutely insane as well. It should have been something more lilke DANE from the start.
That, and fear of antitrust enforcement. The only reason we're still allowed to disable secure boot, or enroll our own keys, is that alternative PC operating systems already existed and were popular enough, that attempting to restrict PCs to only run Microsoft-approved operating systems would raise serious antitrust concerns.
But we're still at a serious risk. Microsoft still has enough influence over PC manufacturers to dictate their hardware requirements, and it would only take them being less afraid of antitrust to require them to no longer allow an override. They are already making things harder with "Secured-core PCs" (https://download.lenovo.com/pccbbs/mobiles_pdf/Enable_Secure...).
Boot sector viruses, or their modern equivalents. Basically, anything which injects itself into the boot chain before the antivirus can start; after that point, the antivirus is supposed to be able to stop any malware. That is, they wanted to prevent malware from being able to hide from the antivirus by loading before it.
Can't you just remove all CAs from the UEFI and import only your own anyways with most mainboard vendors?
You can? Delete the default (ie Windows certs) and import your own.
The more realistic scenario would be exploiting a privilege escalation bug. Of which there have been and will be plenty of on both Windows and Linux.
On ARM for example the hardware, including some hardware shipping with ARM version of Windows, does not need to provide the option to add custom certs and remove existing ones, so AFAIK in most cases it is not possible.
Weirdly I had to leave secure boot option turned off too after a while, because more and more games started to have issues with the nVidia GPU. There was a RPG I forgot the name, isometricish that would outright crash if secure boot was turned on.
I mean, your statement is self contradictory. Linux users demanded no signing etc. So, had the industry listened to Linux users, there would be no signing. We do not live in that universe.
There are some vendors that don't have secureboot. They are e.g. System76. You can enable your own SecureBoot if you want[1], though some things may not work, like checking GPU firmware signatures, because they are signed by Microsoft only (there are other issues, depending on how deeply Microsoft is assumed in your system, see e.g "On some devices, removing either of these keys could disable all video output.")
Honestly I wish they(where they is them that designed this whole broken system) did it it right. On first boot you would set up some keys, now you are your own trust root, and when you you want Microsoft to manage your system, perfectly reasonable, managing systems is scary, you sign their keys and add them to the store. The problem is at a low level it all sort of just works, but nobody want to design that user interface. nobody wants to write the documentation required to explain it to joe random user. Nobody wants to run the call center dealing 24/7 walking people through a complicated process, patiently getting them unstuck when they loose their keys, explaining what a trust root is and why they now have to jump through hoops to set one up.
I like to believe that had they done it right initially, the ui would have been molded into something that just works and the client base would also get molded into expecting these key generations steps. But I am also an optimist, so perhaps not and it is exactly as scary and thankless a task as I described above. But we will never know, Microsoft took the easy way out, said we will hold the keys. And now you are a serf on your own machine. Theoretically there is a method to install your own keys, and it may even work, but the process is awkward(never really being meant for mass use) and you are dependent on the vendor to care enough to enable it. Many don't.
Not out of malice, necessarily, but at least incompetence.
Likewise, having Microsoft signing the shim also means that any Linux installation with the signed shim can install on any system that supports Windows, whereas if RedHat had their own 100% comptent, rock-star PKI then a huge proportion of systems sold today would not be able to run Linux unmodified because the manufacturers wouldn't bother.
A public signing institution (or at least, a not-for-profit one) would be a great idea, but it wouldn't solve the core issue that we're worried about.
The firmware validates the shim. The shim validates the boot loader. The boot loader validates the kernel. The kernel validates the kernel modules.
Once you have that chain of trust, you can also add in other factors; encrypt your disk using a key, seal the key in the TPM, and lock that key behind validation of the firmware and the boot loader. Your system boots, those different components are measured into the PCRs, and if the combination is correct the key is released and your disk can be decrypted automatically. Now if someone boots your system using a different firmware or boot loader, the TPM won't release the key, and your disk can't be decrypted except by someone with the passphrase, recovery key, etc.
Without secure boot, you can't trust that any of those components aren't reporting falsified measurements to the PCRs, lying to the TPM, and getting access to the key to decyrpt your disk despite booting from a compromised USB drive. That, of course, means you can just encrypt your disk using only a passphrase that you manually enter, but for a lot of users (sadly) that's too complex and they'll choose not to use disk encryption at all.
Case in point, TouchID and FaceID are seen as alternatives to using a PIN or passphrase to unlock your iPhone, but they're actually meant as alternatives to not locking your phone at all - a way to make device security transparent enough that everyone will use it. Without a secure chain of trust from the firmware to the kernel, that's not really an option.
Which basically are exactly what "infosec fucktards" as you named them warned about.
MS uses three separate CA's to sign Windows boot loaders, third party bootloaders (including Linux bootloaders) and UEFI Option ROMs.
In theory, no manufacturer has to install all three as trusted. But it makes no business sense to do so - why have two separate hardware SKUs for the sole purpose of lock-in? Once word got out no one would buy from that manufacturer.
Microsoft uses separate CAs (read: separate root certificates) to sign Windows vs Linux bootloaders.
Both CAs have to be trusted. They could also, in theory, be revoked separately.
There is no reason the "third party" CA couldn't be run by Red Hat. It's done by MS out of convenience.
Linux has 63% of the server marketshare, which is where Secure Boot and the whole chain-of-trust has utmost importance. Of course they have leverage.
Do you think overall Secure Boot is more important in the context of securing your bank's servers, or some porno jack machine throwaway laptop?
[1] https://discuss.privacyguides.net/t/grapheneos-is-taking-act...
Secure Boot being "a choice" on PC is an exception, not the norm. On just about every other device, the vendor is going to take a boot, shove it up your ass, and say "it's there to make your ass more secure" if you complain.
fine with me. I read GP as rejecting the whole idea.
to point at another elephant in the room: at some point I came to realize that the ME is a x468 running some BSD. that little bitch has full access to your machine.
if trust and security is the objective, we're in for a hard ride to find trustworthy hardware.
That’s what trusted boot is, as predicted in 1997. It will come eventually.
Reminds me back in the day some vendors of Win 9x systems put something in the BIOS to prevent one from installing NT/2000. Gotta get the corporate model for that.
> most PC manufacturers don't have their own app store.
I feel like you misunderstand what Secure Boot does. It has absolutely nothing to do with userspace apps or app sideloading. It's true that you can't easily sideload apps on Apple devices - but that has absolutely nothing to do with Secure Boot, neither do userspace apps have anything to do with it on any other device.
Not saying all of the web should switch to that while keeping everything else the same, but in some contexts it is just nice to use something simpler, as long as the risks are known to users.
If it's FLOSS wirh reproducible builds, your trust can be minimized, since the community verification is going on constantly. Also, your suggestion is quite inconvenient and cumbersome to use and set up.
But yeah, many ARM boards don't use open UEFI firmware
EU mandates any hardware sold will only boot software signed by EU private key, with signatures only provided to software including government spyware and passing a billion euro certification process.
"No not like that!"
Can someone give a _rational_ reason about why Google, Microsoft, Let's encrypt, Go lDaddy, Cloudfare etc. shall be "trusted" as opposed to "Achmed used cars and certificates" ?