- cross-posted to:
- [email protected]
You must log in or # to comment.
Few years ago I watched this engineer who used an rp3 to hack a bit locker encryption key.
That’s the scary part about security assumptions.
Unpopular opinion but I’m dying on this hill. Secure boot creates more problems than it solves.
That’s a very popular opinion.
I’d argue this is actually a popular opinion. IMO secureboot has just become a way for Microsoft to leverage it’s position and keep a strangle hold on industries they have no business being in.
The whole kernel level anti-cheat on win11 bullshit in the gaming industry is a good example. Essentially locking games to its platform and willing to sacrifice security to do so at our expense.
This is especially true on computers where it is impossible to change the signing keys. Smartphones, game consoles, many laptops, some desktops, smart TVs, IoT devices, modern cars, etc.
Only in tech circles, it says secure and that’s enough for most people.
Outside of tech circles most people think secure boot looks something like this
That’s like saying windows 11 doesn’t need tpm chips, an extremely popular opinion
What problem does it create? Its a good tech and we absolutely should be cryptographically verifying the boot process to ensure it hasnt been tampered with.
Because it’s proprietary and in 99% of cases actually means “Windows Boot”, and isn’t very compatible with other OS. Windows is basically in charge of the entire technology and doesn’t have a history of being friendly to other OS.
For a while Linux was completely blocked by this setting, which was yet another technical barrier to getting into Linux because you had to fuck around in your scary UEFI settings otherwise your PC would be soft-bricked after installing Linux. Nowadays it’s slightly supported by some distributions but Microsoft could of course change it at any time.
Further reading: https://wiki.ubuntu.com/UEFI/SecureBoot
The way it should work is that during the OS install the OS can ask to have a cert added to the keystore at which point UEFI pops up a screen that says something like:
An application has requested to add a new certificate to secure boot which will allow new software to run at boot up. This usually happens when installing or updating an OS. If you would like to allow this press and hold <5 randomly selected letters> on the keyboard for 5 seconds. If you don’t want to allow this press and hold escape for 3 seconds.
This would at least be a vendor agnostic way of enrolling certificates instead of the MS certificate just always being pre-installed. It should also of course be publicly documented exactly how the process works so everyone can use it.
Universal Blue distros do that. For some reason you need to enter a password though.
This is the MOK (Machine Owner Key), which is part of the shim bootloader, not UEFI secure boot.
The shim bootloader is signed by Microsoft UEFI secure boot keys, so Microsoft is the root of trust there.
On some systems you can delete all Secure Boot keys, and provision your own, then you don’t need the shim bootloader and can sign your own bootloader or Linux kernel directly. Windows would not be able to boot on those systems.
Problem being, of course, that you can add more certificates, but you can’t revoke the original M$ one. And since it’s vulnerable and you can’t get rid, then these exploits still work and there’s nothing you can do to stop it.
On some systems you can clear all secure boot keys, including Microsoft’s, then provision your own and sign your bootloader or kernel with it. Windows cannot boot from such systems.
Computers shouldn’t come with Microsoft keys preinstalled to begin with (or an operating system for that matter). Microsoft being able to have Windows preinstalled on the vast majority of non-Apple PCs is how they gained their monopoly in the first place.
My word of advice; any security implementation by an actor who has a fiscal responsibility and/or incentive is inherently flawed.
You are handing your keys to a whore.
Microsoft gave up over a decade ago so this seems about right. If you want something secure get a Mac.
Arch Wiki had pointed out for years that Secure Boot is a flawed mechanism.
It’s not flawed at all. But its purpose isn’t actually to secure anything. Its purpose is to complicate the installation of alternative OS and to perpetuate vendor lock in, while sounding like it’s “for your security”. In that regard, it has succeeded.
There is also TPM and Microsoft Pluton, which serve the same purpose.
11 old and forgotten UEFI shim bootloaders at versions 0.9 and below that can be used to bypass UEFI Secure Boot on any UEFI-based machine that trusts Microsoft’s Microsoft Corporation UEFI CA 2011 third-party UEFI certificate authority (CA) certificate, regardless of the installed operating system (OS).
This “Trust” is one of my pet peeves. It’s $$$.
IMO, broken ≠ vulnerable. Broken to me means it doesn’t work. There’s a difference, to me. 🤷♂️
Secure boot is supposed to be a lock.
Turns out there are 10 year old tricks that bypass that lock.
A lock that cannot deny access to people without proper key… is a bad lock.
There’s like dozens of ways to open a lock without the proper key, it’s probably not the best comparison…
I think that Victor may not have English as his primary/first language, I am trying to use a simple comparison that is more likely to convey the general, fundamental concepts.
If the “working” definition is “is secure”, and there’s 11 ways in which it’s not, is it not “insecure”, aka. “not working” then?
“Being secure” doesn’t seem to be the primary function of a “UEFI shim”, so no? 🤷♂️
Well considering that the “UEFI Shim’s” role is to sit in between a Microsoft owned certificate signing chain, it is certainly part of it’s primary role.
With Linux distributions supporting UEFI Secure Boot, the above-described Secure Boot mechanism built around Microsoft keys introduces some challenges. Every Linux distribution generates its own bootloader binaries, and each of them has a different hash. Getting every Linux bootloader signed directly by Microsoft would be slow, bureaucratic, and impractical (if not impossible) to maintain across all Linux distributions.
The solution to this problem is a shim: a small, minimal first-stage bootloader that Microsoft can vet and sign once, and which then creates a secondary trust anchor for the rest of the Linux distribution-specific boot stack – usually GRUB 2 and the Linux kernel. This trust anchor is another certificate, referred to as a vendor certificate (managed by the distribution vendor), added to the shim binary before it is signed by Microsoft.
Alright, good enough.
