Really it seems like having any expiry date for these certificates is a mistake. The one thing it might protect against is a compromised signing key, but if you have to wait 15 years for a compromised key to stop being valid, it's not very useful!
Don't worry, the replacement MS certs expire in 2038 (a couple of months after the 32-bit unix time rollover).
The mistake was not to put an expiry date on the certificates, but to trust hardware vendors to do even basic firmware maintenance after motherboards and laptops leave the warehouse.
In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do.
In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.
Which to me leads me to a bigger problem, UEFI is trash, too complicated, too bloated, too hard to implement all the various bits and pieces.
In my opinion the system firmware should do the absolute minimum possible. Find a piece of data somewhere that the processor can start executing, like in the BIOS days where it would just load in the first 512 bytes and start running that. Anything else like hardware configuration, power management, etc... should be left to the operating system.
Mobile phones and a lot of embedded systems have minimal system firmware like this and it is a total disaster, basically forcing you to have per device special software releases with all the hardware specific things EFI would abstract for you, enabling a generic system software image supporting many devices.
As a result, many of these devices are buggy, insecure & are never updated once shipped or updates get abandoned soon after.
That's not realistic. Too much stuff is board-dependent and trusting vendors to upstream it (or even disclose documentation) isn't going to work never ever. I think what should be done instead is to swap privilege levels so that after-boot firmware services runs under operating systems, not above it. ACPI, with all it's sins, is pretty close. On the other hand, RISC-V made same old mistake of introducing SMM under other name into their supervisor spec and addeed their own secret sauce of forcing damn TIMER interface to go via SBI (seriously, WHY? High timer latency was known to be a problem om x86s requiring all sorts of weird tricks since Win95 or so).
The real myth here is that the BIOS did nothing more than load 512 bytes and start executing. It was already doing tons of stuff to configure hardware and provide information to OSs well before UEFI came along.
All the "PnP"/"ESCD" stuff the pre-UEFI BIOS did was to support DOS or because of DOS. APM leveraged SMI for fan and power control so DOS would work on 90's era laptops. That whole mess morphed into the nightmare of ACPI and UEFI.
The only thing a firmware really needs to is A) initialize RAM, B) initialize a display or serial port for boot comms, and C) load an OS. Anything else modern firmware does would be better as normal devices controlled by OS drivers without the ACPI/UEFI layer.
A third thing: it is of course super convenient if firmware provides some way to reliably identify the platform and provide data on devices that aren't connected to discoverable buses (such as bus controllers themselves), but even that's not really required. Linux lets you build a devicetree as part of the kernel.
UEFI standardizes the things vendors and operating system manufacturers were already doing anyway. Even in the BIOS days, firmware was doing PXE boot and things like modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs.
You can flash all kinds of alternative firmwares to many motherboards if you know where to look, but those firmwares often end up reimplementing everything UEFI does to get an operating system to work in the first place. Some firmware distributions even use a full Linux kernel as a UEFI replacement.
I'll take UEFI over BIOS any time if only because it finally solved dual booting.
> modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs.
Wait, what? Did this thing at least have the courtesy to check that you were indeed booting Windows or would you just get random crashes if you tried to use the mainboard(!) with any other OS?
This stuff seems inches away from a supply chain attack.
It's more that Microsoft would read & execute a binary from a specific place in memory, allowing companies to maintain persistence / ensure their drivers are always installed / ...
There is no basic firmware maintenance to do. Firmware is supposed to be properly engineered, immutable, still to this day sometimes physically wired as 1s and 0s. It doesn't make sense to have expiry dates carved in stone.
Firmware needs maintenance because unless you're doing stuff for the aerospace industry, you're not mathematically proving that your firmware is bug-free. Eventually someone will need to install updates.
Well-written firmware doesn't need to be updated for the key database to get updated. However, some vendors messed up and now require firmware updates, while others simply store the new key in NVRAM.
Not to mention that firmware updates are often necessary for things like supporting new CPUs. Immutable firmware means that your system can never improve or expand to support new hardware, and I would hate to have to buy a new motherboard to support a new CPU.
You shouldn't need new improved proprietary software to support new hardware, that's just wrong. They're just bundling free apps into hardware at that point.
"New CPU needs a new software" shouldn't be an excuse to just let CPUs becoming its own computer with the real CPU you're paying for as one of many features. That's just fundamentally wrong.
The user can load their own keys into their secure boot storage and use those keys without any interference from pre-installed certificate authorities.
This issue only affects the people who don't want to bother being the root of trust.
What purpose does the expiry date have? There might be something I've missed, but I really can't see one apart from needless complication, which is what makes it a mistake. (There are other problems in the UEFI/firmware ecosystem yes, but that doesn't excuse expiry dates)
I don't know if this is why the people behind secure boot adopted this design, but expiry dates make CRLs smaller, at least in theory. If a revoked certificate expires, you don't need to add it to the CRL because trust is invalidated automatically. By rotating root keys occasionally, you can also keep the revocation list for vulnerable bootloaders smaller, as you can remove any vulnerable bootloader when its signatory key expires.
With the kind of penny-pinching that happens with NVRAM storage on boards like these, being able to reduce the size of CRLs can make a difference.
I'm feeling/guessing the expiration is more of a flow-with-tradition thing. TLS certificates expires, it's part of the security feature, so why not Secure Boot certificates too?
And of course, it gives the root certificate issuer enormous amount of power as well, good riddance from the POV of Microsoft.
However, I think if Microsoft REALLY care about security, they should not let application installed on their system to do anything that is unapproved by the user (such as installing a virus that encrypts all their data), which could actually enhance the user experience and security. But, with secure boot, at least you can be sure that your Windows kernel is not tampered so it can serve the virus correctly :)
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.
It makes more sense if you view it for what it is: Honest Satya's Certificate Authority.
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.
Secure Boot is the computing antichrist, and Linux folk were 100% right to rally against it. As well as a whole bunch of other "Trusted Computing" garbage.
Trusted Computing is to trust the NSA with your computing. They need to have access, right? And since they cannot control all hardware vendors, they opted to control Microsoft instead, and forced UNIX to play ball.
"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.
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?
Take an iPhone or a Switch. Then disable Secure Boot on it. Good fucking luck.
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.
> 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 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).
<< Which is exactly why users have the freedom and choice to just disable Secure Boot?
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.
> Which is exactly why users have the freedom and choice to just disable Secure Boot?
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.
I think it is only required on x86 EFI machines due to some old antitrust rulings. Provided the firmware vendor actually implements it right.
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.
> I'd love to know if my machine has been compromised with early boot stage "meta-hypervisor" or not.
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.
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.
With Heads, the firmware measures itself and sends the results to the TPM. If an attacker flashes a modified firmware that simply lies about the measurement results, the entire security system will be bypassed.
that's still secure boot, isn't it? just not uefi but homegrown?
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.
Call me childish, but I don’t want to ask Microsoft to sign a certificate for me before I install software onto my own hardware.
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.
Yeah that's how my systems are set up. I also appreciate that each firmware let's me restore the original keys just in case without me having to manually back them up -- but they're not active for secure boot.
Maybe this isn't a great take, but RedHat/LKF/etc could obviously run a 'semi-competent' PKI, and probably should be. But doing so would allow PC vendors to cleanly segment machines between Windows and Linux (+$$), so perhaps it made the best sense to lay-low and use MS infrastructure for this.
Can easily imagine companies like Dell selling you a system with Ubuntu preinstalled but without Windows signing keys so you can't run Windows on an Ubuntu laptop (or vice-versa) with Secure Boot on an unmodified system.
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.
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.
Sure they would, if it would make them a buck. Lenovo for example already has separate models for pro ThinkPads with 'certified' Linux support versus the consumer line. Dell too. PC vendors already have 9000 SKUs, what's a few more?
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.
If Linux users had "stepped up to the plate" and demanded their own separate PKI, nothing would be different, except that every system that shipped with Windows would be locked to Windows. Dual booting would not be a thing.
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.")
orrr we just have official institutions which do this and enforce vendors to add certificates from other trusted parties. not only microsoft is able to do this. also microsoft already also had fallout regarding signing.
and secure boot is still the antichrist, but we have to live with them.
The problem here isn't that Microsoft is the one signing the shim, but that we can't trust systems manufacturers to update their systems, or even to have systems that can be correctly updated.
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.
Basically every x64 computer is intended to be able to run Windows. Hence MS had to be involved, and I suppose nobody else with serious money wanted the burden.
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).
Secure boot belongs to a class of security that while clearly giving a theoretical benefit in practice it falls far short of providing any benefit whatsoever at least to the user of a system. Its introduction was mostly part of a wider (probably partially defunct and failed regarding mobile x86) strategy to lock down the PC so the Microsoft store and purchased apps through it would be more secure from the end-user. Secondary was in my opinion better security for handheld phones and tablets running x86 but there the "App store" aspect is even more clear.
"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.
What kinds of attacks was Secure Boot designed to mitigate? Is it the evil maid attack? Or an accidentally ran with `sudo` program can indeed screw your entire boot process and inject rootkits etc.? Or is it something else?
> What kinds of attacks was Secure Boot designed to mitigate?
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.
Another example: a custom kernel build or kernel module that backdoors your system or steals data at the kernel level. Secure boot provides the opportunity for a chain of trust that goes from the firmware manufacturer all the way down to your individual kernel modules.
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.
Evil maid and rootkits, mostly. It's also part of the trust chain that unlocks an encrypted disk without having to enter a password.
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).
That is sorta the rub - the treat profile "evil maid" is mainly governmental actors for most people even for Orgs. Your example shows mostly how an org can secure their own devices against casual misuse by unprivileged users.
This does not help against any serious attack. It only protects against stuff you don't need to worry about generally.
Anything that locks you out of your own computer is at absolute best an availability failure but more often than not forces you to use compromised system software.
MS did not "Have" to be involved. The problem is that doing it right is hard, not hard as in "it was tricky to figure it out but once we did everything works" but hard as in "every single user now has an additional impossible to remember key they have to keep track of or they get locked out of their system", basically the mother of all support nightmares. so Microsoft took the easy(perhaps realistically, the only) way out. they said "we are not going to have the end user own their keys, we will own the keys"
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.
Eh, that's basically what we have now with boards where you can delete the MS keys and enroll your own. Just with different defaults and no support nightmare
Only legal requirements can change it. Nowadays, the mokutil is good enough that linux users can build a good tool around it to automate registration at boot that should ease some pain. But otherwise, it is a big mess and still needs legal requirement.
The EU should step in and make sure that any critical OS attestation is taken out of the hands of the big players. Look at GrapheneOS is being denied Google Play Integrity [1] on pretty much no grounds with large consequences. Such security infrastructure is to easily abused to put bias into the market. On the other hand funding is needed to professionally run this stuff.
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.
Things that might not get updates shouldn't use the current date/time when checking certificates. Instead, they should see if the certificate would have been valid on the day the firmware was compiled (ie. behaviour will never change through the passage of time alone).
Expired certificates should also at worst be a skippable warning. No one’s relying on certificates expiring for security. If you did you might have to wait many years for the expiration of a stolen certificate - lol!
It’s absolutely a minor “hey btw the certificate expired, check for an update” yet various systems treat certificate expiration as an end of the world lock it down scenario.
There's gonna be a bunch of linux users who write a shutdown script to set the date back to 2015 then poweroff... And at startup, reset the date back to today using the internet.
Sounds like a cleaner solution than any of the ones in the article too!
That seems to almost completely defeat the purpose of expiration. One could do a bit better by requiring the signed object to be timestamped by some sort of secure timestamping service. But then one should seriously consider the threat model that Secure Boot with default certificates is intended to defend against.
The day infosec nerds get rid of their unhealthy obsession with expiration and realize that systems irrecoverably breaking on an arbitrary random instant or requiring a true source of time to work are REALLY FUCKING INCOMPATIBLE with the real world, they might actually get something done. Until then, please don't bother the rest of us trying to get work done (and having to cleanup the mess you made - what do you mean you can't just update it?!)
There is no purpose to the expiration in this particular case. If you have an expiry of say 24hours and constantly update that makes some sense - stolen certs get a very short time window.
If however you have an expiry of multiple years you clearly have no reason to have an expiry date at all. You can't possibly justify a security benefit, imagine reassuring people with "the stolen certificate is only valid for a few years!"
As in it was clearly a mistake to have an expiry date at all for this use case and the multi-year expiry date should have been a smell that tipped people off and made them ask "why do we have an expiry date at all for this?".
If there were no certificate expiry, I could break into your system by finding some bankrupt company last trading in 1980 and stealing their keys to mint my own certificate.
With expiry dates, at least the pool of places you can break into to steal certificate signing keys isn't growing without bound.
there is a difference between the expiration of signing keys, and the expiration of the signature signed with those keys. the signature for a contract, or a bootloader, should remain valid indefinitely, even if the person/key is no longer allowed to sign contracts/bootloaders after some point of time.
That sounds impossible to enforce. Key signing is done offline. If I have an expired signing key, what’s stopping me setting my clock back a few years, creating a new signature and signing it?
If the resulting key works indefinitely, the expiration date on my signing key is utterly meaningless.
Microsoft's Authenticode has been doing this for a long time, allowing a signature to be considered as valid long after the signing certificate expired.
And what stops people from just logging into the bios and changing the date or pulling the clock battery? The point we're all making here is, at least for this application, is that an expiration is pointless.
You can do almost as well by finding a piece of software with a code execution exploit early in boot that’s signed by the bank.
A different model would be to only allow a given EFI binary to be booted if it was installed before the deadline, but that might well have a different set of complications.
Even more, the "current date" comes from an external source that anyone with access to get new images on the machine can probably also manipulate. Setting the hardware clock is a normal operation available to the kernel.
Lenovo, in their infinite wisdom, has decided to load an Nvidia blob signed by Microsoft before even being able to access the UEFI firmware interface. People who have tried to install their own secure boot keys found out the hard way that you can't even get into the firmware configuration interface to undo the change.
Their official workaround is to only load secure boot keys through their firmware interface (rather than the standard Linux utility) which refuses to wipe the certificate used to sign the Nvidia firmware. However, that workaround will obviously stop working when that certificate expires.
The Framework laptop with the AMD 7840U works perfectly without any microsoft keys enrolled.
For your current laptop, you might be able to use the `--tpm-eventlog` to `sbctl enroll-keys` to enroll hashes of your OptionROM to whitelist that blob.
Using "Secure Boot" with MS keys is not real Secure Boot. It's "Microsoft decides what you may boot". Enrolling your own keys should be the standard way of operating. shim is a joke.
Just out of curiosity, how good is the secure boot experience these days?
I've had to disable it on all my installations because of either nvidia drivers or virtual box modules. In general Arch based distros didn't seem too friendly for secure boot set up.
If you use a major distro like Ubuntu, you might find Secure Boot works out-of-the-box, with no need to dick about with 'machine owner keys' and suchlike.
Ubuntu has packages like "linux-modules-nvidia-550-generic" containing a version of nvidia's 550 drivers signed with canonical's keys. If the stars align and that package gets installed, you'll have nvidia drivers that work under secure boot.
They also have a second mechanism. You can set up a 'machine owner key' (MOK) then software updates will trigger automatically building new nvidia kernel modules, using 'dkms' then sign them with the MOK allowing them to work under secure boot.
The problem is this process can be a bit wonky. The MOK setup process involves rebooting and going through the "MOK Manager", an interface that looks like something from the 1980s. If you didn't know to expect it, or what it's there for, or you don't speak English, it's easy to hit the wrong thing and not set up your MOK. And it only shows up for a single boot, unless you know an arcane terminal command.
And if you run into any problems during the setup process - you're going to be researching the fix on your phone, because your PC isn't booting.
Meanwhile, the third option of just turning off secure boot is easy (assuming you know what the BIOS is) and it works every time. So a lot of 'how to set up nvidia drivers' guides just recommend doing that.
Although I complain about it, I find it impressive things like dynamically compiling and signing kernel modules works as well as it does - especially as so much of it is maintained by volunteers, selflessly giving up their free time when they could have simply turned off secure boot in their BIOS too.
My experience as a long time Linux user (since 1997, so admittedly stuck with some bad habits from when things were actually hard to get working) has been that things are kind of confusing if you deviate from the golden path, but if you are on the golden path you won't ever notice that it is turned on.
The laptops I have gotten from eg Dell with Linux pre installed have just worked. Machines I have upgraded through many versions of Ubuntu (lts versions of 16-24) were weirdly broken for a while when I first turned secure boot on while I figured it out, but that seemed reasonable for such a pathological case. Machines I have installed Debian on in the last few years have been fine, except for some problems when I was booting from a software raid array, but that is because I was using 2 identical drives and I kept getting them confused in the UEFI boot configuration.
I have not used them on machines with nvidia, vbox, or other out-of kernel-tree modules though.
Every couple of years MS do an update that messes up multi-boot/dual boot. I'm sure it's on purpose at this point, and relatively sure "Secure Boot" is how they achieve it.
Still on Windows only for kids games. Linux user since last millennium.
I've stopped trying to fight to install things on Linux. Anything with kernel level anticheat it seems is torment. They okay Fortnite, and quite a bit of Marvel Rivals (which initially worked, then stopped, I see reports suggesting it's working again but I don't have time to be full-time support to keep things running smoothly).
We do use Kubuntu for games that run in it without drama - Risk of Rain, Roblox (via Sober), browser games, CS2.
They also are expected to use Microsoft Office for school (UK), it's possible to work that online, but the experience is worse, slower, more prone to issues it seems.
Fwiw, I've been a Linux distro user for decades and was Linux only until the first child got to highschool. Microsoft's "educational" policy works for them!
> Every couple of years MS do an update that messes up multi-boot/dual boot
IIRC the last time this happened it was the fault of Linux distros not updating their packages, it was just a Microsoft update updating the security requirements that affected distros that were caught slacking.
No it's not. Microsoft has to disable outdated and vulnerable signed bootloaders to stop them being used for secure boot bypasses. Microsoft worked with RH to get things updated which they did, it's just distros for caught slacking and were shipping an outdated vulnerable boot loader.
I know it's the norm to bash Microsoft and they do a lot of crappy things, but in this case it was just certain distros not taking security updates seriously, which is why a lot never broke (such as Fedora)
So Windows installs something that brakes Linux boot. How are you supposed to boot Linux to install a fix? Am I expected to reboot into a different OS twice a day and check for updates? Am I slacking for not doing so?!
I use Fedora and have it enabled. Every time there is a kernel update I have to run a script to re-compile and sign the vmware drivers. I could probably figure out how to do it with dkms at some point. Every now and then, there's a kernel change big enough to make the vmware drivers stop working so I have to get a new patch.
Signature maintenance for modules can be fully automated. Enrollment requires navigating a mildly-intimidating interface a single time to accept the new PKI.
Fine for systems you physically manage, anything remote in a datacenter I wouldn't bother (without external motivation)
Which is strange because secure boot should be useful in _exactly_ the situation you don't have physical control of the HW, shouldn't it? I guess the threat model for a common not-that-important company does not include evil data center (and it's dubious if SecureBoot would protect you in reality), but wasn't that one of the motivations?
Well you can tie it to TPM to store your encryption key which should only produce the key when the boot parameters match the key. This is what Windows already does but its not fully supported under Linux and somewhat insecure as you can't encrypt the initramfs (so someone can infect boot process there instead).
There are ways to solve that issue. But I think that you're correct, pinpointing the core issue with popular Linux distributions. It doesn't have to be this way, though.
1. You can sign and verify initramfs, it's supported by bootloaders.
2. You can merge kernel and initramfs into UKI and sign the whole image.
For UKI I imagine a big hurdle is the size of the images (given /boot/efi is usually only big enough for bootloaders, not kernels and initram) and custom kernel modules (e.g. Nvidia).
There was some systemd work on a spec for a boot partition to extend the efi partition for storing kernel images and initramfs, but I don't think any distro currently defaults to it on.
I think hibernation is currently also broken, since the hibernation file is stored unencrypted by default and thus can't be used with secure boot.
> Which is strange because secure boot should be useful in _exactly_ the situation you don't have physical control of the HW, shouldn't it?
One of the ways you can introduce your own signing key is as a Machine Owner Key, using the "MOK Manager"
But a design goal of this software was: We don't want malware with root to be able to introduce a MOK without the user's consent, as then the malware could sign itself. So "MOK Manager" was deliberately designed to require keyboard-and-mouse interaction, early in boot before the network has been brought up.
Of course if your server has a KVM attached, you can still do this remotely, I guess.
It works pretty well out of the box unless you're trying to combine Linux with Nvidia hardware. Even with Nvidia hardware it doesn't take that much effort to make it work, but as usual, Nvidia requires taking extra steps.
What Linux is really lacking is a user-friendly method for enrolling your own keys, which would instantly solve all the Nvidia/firmware updater/custom bootloader problems. The command line tools are slowly getting easier to use, but there's no guided instruction flow.
I'm using Arch and it was very easy to configure secure boot. I don't know why you think it's not friendly. I'm using UKI, so no bootloader at all, my UKI is signed by my own key which is installed into UEFI. Most of sign process is handled by systemd, so most of it is already integrated into the base system.
I just finished setting this up and it's definitely this easy. The hardest part was growing the ESP to dual boot with Windows but that is basically just copy/paste the files to a bigger partition and change the partition type GUIDs.
Most of the guides focus on creating the PK, KEK, and db certs for enrolling/updating certs from userspace with signed .auth files but that is kind of pointless and seriously over-complicates it. I just created a 20-year db key pair with openssl (and PK and KEK just to make sbctl happy due to a bug), then installed the public db cert into the UEFI manually via the ESP. Didn't even need to use setup mode, although I suspended BitLocker on the Windows partition to let it reseal its key with the new PCR 7 measurement after the db update.
To finish securing it I have a separate key for PK and KEK and have already installed Microsoft's 2023 UEFI certs in the db (and added the 2011 cert to dbx with the updated bootmgr).
just doublechecked with "Confirm-SecureBootUEFI" - says True on my laptop which used > 1 year. I'm pretty sure on the previous system which was used for 4 years it was on too - have not noticed any issues.
Reading into the history of Secure Boot. Discovered Intel and AMD processors have back doors via Intel Management Engine [1] and AMD Platform Security Processor [2]. Both are closed source and have had a number of vulnerabilities over the years. They are essentially backdoors.
Seems disabling these "features" is nearly impossible as well.
Or you could just remove microsoft's keys from your systems and sign your bootloader with your own key. That's what I do on all of my systems so I am unimpacted by this.
Warning: Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the firmware settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware (OpROMs), that get executed during boot, are signed using Microsoft 3rd Party UEFI CA certificate or vendor certificates. This is the case in many Lenovo Thinkpad X, P and T series laptops which uses the Lenovo CA certificate to sign UEFI applications and firmware.
“Just” is doing a lot of heavy lifting in that solution.
Sure, but that's a lot more work than just disabling Secure Boot, and for most people's threat models, there's zero actual security benefit gained in return.
There should be some “Sane Usage” certification that a device doesn’t do secure boot, provides fully open and self-maintainable hardware, is independent of all external entities for ongoing use, provides hardware switches to turn off built-ins like ports, mics, and cameras, for power-savings and security.
To be able to get Windows licenses and preload Windows on your system, put that little Windows sticker and sell your machine to the masses, you need a Windows Compatibility certificate, and that certificate needs you to have Secure Boot and enabled by default.
Sounds anti-competitive as fuck to me. Maybe we should, I don't know; do something about companies using contractual requirements to lock key industrial into one way of doing things in order to shut down such efforts?
"Will this piss off or delight Microsoft?" is probably a thought that goes through the heads of many OEMs when they decide how to design their machines.
Microsoft has been trying to tread a fine line between exerting subtle pressure on OEMs to make Linux annoying to boot so it doesnt become more popular and not violating the terms of its antitrust agreement.
I didn't realize that the Secure Boot certificates that allow us to boot Linux at Microsoft's pleasure are things that expire. So all Microsoft has to do to kill end-user Linux is... nothing.
How the hell did we get ourselves into this situation? After Microsoft spent years secretly threatening people with lawsuits for running Samba and Linux VFAT, and describing open source as "cancer"?
The article should include a very obvious way for someone to test if they are affected. How does one verify (in an in a VERY clear and straightforward way) if some arbitrary system will run into this issue in September?
It's possible and it's what you should be doing. "sbctl" (https://github.com/Foxboron/sbctl) AFAIK has a reasonable frontend for doing that on Linux (don't know, I did it manually). You have to put the system in "secure boot setup mode" in BIOS/UEFI options before booting, which enables changing the PK (Platform Key) which is used to chain off all the other keys. (Setup mode should be automatically exited when you install a new PK.)
You can keep the Microsoft keys in there if you want to dual boot Windows, you just need to re-sign the keys themselves with your own PK.
That would be a disaster. Or imagine what would happen if you just disabled secure boot, your computer will be infected with viruses and your bank account emptied instantly I reckon
It irks me that Microsoft managed to shim their way into the Linux boot process like this. No key signed by Microsoft should ever come into play when booting Linux, on a moral basis.
Libre operating systems are coded to run on machines that conform to Microsoft's hardware standards and conformance tests (Windows HLK) that define Windows compatible hardware. Linux is shimming its way into Windows' boot process, not the other way around, even on machines sold with Linux from the manufacturer.
If you want to be clean on "a moral basis", whatever that means, the FSF would have to create their own hardware standard and persuade OEMs to adhere to it. Good luck.
This is only the case because we let it be the case. Microsoft should have had zero influence on this. Consumer protection laws have utterly failed us.
It's not just secure boot. Modern OS have certificates all over the place. These are ticking self-destruct time bombs in those machines that the manufacturers of hardware based on these OS may not necessarily realize. I am thinking ATM machines, voting machines, medical equipment, smart-fridges and other IOT, probably many cars, etc.
Oh, they realize it just fine. To them it is just another source of revenue. Planned obsolescence is going to wipe out our digital heritage at some point.
So is it a possibility that a grub update breaks an existing bootable node? That worries me as I have a couple of Linux desktops in the field which I can’t remember if secure boot is enabled on.
If users don't update their keyrings or firmware (through fwupdmgr for instance), Grub will probably stop booting with secure boot on when the certificate expires.
If users update Grub once the old certificate is no longer used to sign the bootloader without updating their keyrings or firmware, Grub will probably stop booting with secure boot on when the certificate expires.
If users do update their systems and software, Grub will keep working.
Not updating is not a solution, unless the motherboard manufacturer really fucked up and doesn't validate the expiration date.
Luckily, fwupdmgr is integrated in the GUI updater tool on just about any Linux distro I know. As long as users don't ignore the "there are system updates available" popup and as long as the desktop vendor put out bare basic software support, things will probably go down fine.
> Not updating is not a solution, unless the motherboard manufacturer really fucked up and doesn't validate the expiration date.
The article mentions that most motherboards will probably not validate the expiration date. There is a residual concern that new versions of the Shim will not be signed with the expired key, and thus be unbootable on hardware that doesn't accept the new key.
Secure Boot's benefits are definitely not as strong (I don't think flashing custom backdoored firmware is a common attack vector for personal computers), but FDE is still useful in case your laptop gets stolen, because thieves looking for sensitive data on a hard drive is a thing that does actually happen.
I also wouldn't really say it's much trouble. If you have a TPM and use systemd, you can set it up to unlock FDE automatically on boot, otherwise, you just have to input an extra password when turning on your machine.
No, SB starts with actually firmware already booting something. It is just one link in the chain. You can also look up Trusted Boot and Secure Launch, how this entire chain can/could be secured.
> SB starts with actually firmware already booting something.
I don't understand that sentence. So instead of a bootloader in the ROM that starts the next bootloader and verifies that it is signed (I think that's how it is on Android?), on a laptop the first bootloader can be installed by the user and nothing checks its signature?
EDIT: what I read here [1] is that Secure Boot is verified from the ROM to the moment it starts "the Windows kernel" (on Windows). But it's not completely clear to me: say on Linux, if Secure Boot verifies up to my /boot partition (does it?), then it should be okay because I have FDE on the rest, right?
> on a laptop the first bootloader can be installed by the user and nothing checks its signature?
It should be signed by the manufacturer, so you shouldn't be able to. Loaded by a shim even smaller in the CPU, part of Boot Guard and Platform Secure Boot, if I'm not remembering wrong.
> say on Linux, if Secure Boot verifies up to my /boot partition (does it?)
No. It verifies one signed file, usually Grub EFI shim. Which then should check everything you want. Unlike Windows, desktop Linux distros rarely have the best SB system. Poettering has described this issue in depth.
So in 2025,2026 the simplicity of BIOS still haunts us. I realize this time it is a one-off cert issue, but there have been so many other non-trivial paper cuts in secure boot and UEFI implementation that I can't help but see this upcoming fix as spinning a roulette wheel of fixed/failed/bricked.
Well I can say that the update is not going 100% smoothly. I have a pending KEK update in Fedora but it's a test key (bug filed but no progress as of yet).
[Warning: I'm not interested in sarcasm or uninformed rants against secure boot, there are plenty already]
I'm hoping to get insights from people who understand secure boot well here. My understanding on Android (for the minority of Android manufacturers that do it correctly) is that there is a "manufacturer key" burnt somewhere on the ROM that cannot ever be changed, and once a first system is installed properly:
1. It is impossible to overwrite the system partitions unless the bootloader is unlocked from the already-installed OS (I assume that something makes sure that only the signed OS can unlock the bootloader?).
2. Once the bootloader is unlocked, it is impossible to overwrite only parts of the system: it's all or nothing, such that one cannot inject stuff into an existing system (evil maid style).
Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use.
How is it on UEFI? It sounds like the "manufacturer keys" are always from Microsoft, but is there not a way to use custom keys?
Of course it is possible to use custom keys. At least it was possible on all EFI computers I owned. There are no "manufacturer keys". There's usually an option in BIOS to restore default configuration which resets to MS keys, but you can delete all MS keys.
Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys and if you delete MS keys, you might brick your laptop, because GPU won't start anymore. That said, I'm using Lenovo Thinkpad T14s Gen4 Intel right now with all keys deleted and my custom key added and it works just fine. May be it's AMD issue.
> Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys
Oh right! Yeah if you want to use custom keys, you need to be able to build and sign your OS, and proprietary firmwares are then a problem. Now I wonder why this is not a problem on Android... Is it because the firmware blobs come from the image that you sign yourself?
Would the solution be that the GPU should load the firmware from the OS?
You don't need to be able to build them. Just sign them or sign the keys that sign the third party blobs/binaries.
Then your motherboard firmware will be able to load your GPU and other third party blobs to UEFI memory. Similarly OSes like Linux and Windows enforce the same chain of trust (they don't have to but otherwise it is not really secure, just like a website can lie to you about encrypted storage) so you need your drivers/OS loaded firmware to be signed as well.
What Android does and what UEFI does are not really related. It is like comparing how SSH does authentication vs how HTTP with TLS does. Former is a SSH-specific open-ended implementation detail, latter is standardized by IETF.
Similarly UEFI standardizes how a motherboard manufacturer can write a compatible firmware and Secure Boot (capital letters) is a sub specification of UEFI. It is not the only secure boot implementation scheme.
With Android device manufacturers have complete control over the early boot firmware and the OS. As long as they boot the OS to run apps, how they do it is up to them. Only things like Google's SafetyNet will put certain requirements on them. No standard like UEFI exists in Android phone world or anywhere else except PCs / Servers.
> Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use.
AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted. Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.
> AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted.
You're right! That's what I mentioned the few manufacturers who do it correctly. GrapheneOS only supports Pixels for other reasons than that. CalyxOS supports other devices (one constraint being to be able to relock the bootloader). /e/OS doesn't seem care so much about the secure boot.
> Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.
That raises a question: what is the point of relocking the bootloader? If overwriting the keys means that the whole system will be formatted, then I don't see why it should ever be prevented at all? If an evil maid wants me to lose my data, they can leave with the laptop, right?
> It sounds like the "manufacturer keys" are always from Microsoft,
The primary key is called "Platform Key" (PK) on UEFI, there can be only one, and it is generated by the mainboard manufacturer, not Microsoft. The PK is then used to sign Key Exchange Keys (KEK) which you will generally have 2…4 of, the Microsoft self-use one, the Microsoft third party one, a board vendor one, and a system/board specific one.
You need to replace the PK with one of your own, because that is used to sign all the other keys, and generally there can only be one PK. You can then re-sign the existing keys with your own PK (e.g. if you want to dual boot Windows) — or just ditch the existing ones¹, and/or you can generate your own keys of the other types (KEK & DB).
Ed.: ¹ there are cases where ditching the existing keys breaks the system, because the board vendor was stupid and signed the VGA UEFI driver with one of those keys instead of tying it directly into the BIOS/UEFI image. AFAIK this only affects a specific series of Lenovo laptops, but Google the details before breaking your system.
Ed.#2: actually I think the PK signature is only checked while installing keys into the KEK/DB list, so you don't need to re-sign the existing Microsoft keys, they just stay in the list by default. (Unless they got cleared somehow.) It's been a little while since I did this.
It should be noted, it is 100% possible to use Secure Boot with Linux and not be impacted at all. AFAIK, most (if not all) UEFI firmwares allow enrolling your own keys. Managing secure boot these days is as easy as installing sbctl and adding a hook to sign your kernel when rebuilding the initramfs. For the same price, as noted by the article, the key new key can be updated while the system is online without anyone being the wiser.
The FUD that gets spread around SB helps no one, and other than a small list of exceptions, you are always in control of your system.
SB allows MS to transparently enable Full Disk Encryption by default, which I think is a win for all users. It allows you to do the same on Linux. It lets server operators be sure their systems have not been tampered with. While there are many problems with UEFI, SB is not one of them.
There is hardware that requires drivers to even reach the bios. The drivers are signed with the MSFT key. And if you change to your own key you'll find you can't even get into the bios anymore.
Can't you just disable the internet connection, set the BIOS clock to a date before the expiration date to boot from the secure installation media and then reset it to the proper time after the installation is complete?
mokutil is technically the wrong tool for this, it lists shim-installed machine owner keys (MOK). This is about UEFI-installed key exchange keys (KEK). If you don't know what's going on you'll be very confused about empty key lists. It can in fact show KEKs but you need to know that this is a KEK thing to begin with…
mokutil --kek | egrep '(Not |Subject:|^[^ ])'
is the magic incantation if you really want to use mokutil
>Currently, shim is signed with a Microsoft key from 2011 that expires on September 11.
What security benefit did adding an expiry date to the certificate provide? "Oh no! Someone has gotten our secret key and is certifying new shims! ... Not to worry, the certificate will expire in 14 years. Everything is fine!"
Just another factor creating electro-junk. Currently I can install 30 year old system on 30 year old hardware (assuming that I keep both the machine and the installation media in a good shape). With current computers it will be impossible because they will be "unsupported".
Fuck secure boot. A fun project, even if mostly for educational purposes, would be to collect all the different exploits that have been found over the past years and try to create a universal secure boot bypass loader that targets as many of those as possible. I guess chances are that if your vendor didn't update the firmware to include the newer ms keys, they also didn't patch any of the exploits. So we just need to also get this super exploit loader signed so that it works everywhere :o)
TLDR Linux systems using Secure Boot rely on a Microsoft certificate (from 2011) that will expire on September 11, 2024. After that, new Linux installs using Secure Boot may fail to boot unless the system firmware includes Microsoft’s newer 2023 key and updating the key often requires a firmware update from hardware vendors which doesn’t always happen. It’s crazy that many users are relying on an outdated Microsoft key unknowingly (I will be checking if I’m among them smh) Also great that people are bringing awareness to this
> Any installed distribution should have a bootloader signed with its own key that will continue to boot
I'm kinda concerned here: as long as there's no mandatory security upgrade requiring a reboot, I'm the kind of person to reach six months of uptime with my desktop (yup, Linux is that stable, a far cry from Windows).
So I'm concerned about not being about to boot in x months and forgetting why (ah, yes, Microsoft having a key expiring).
Am I correct in my understanding that this only affects my installation media and not my already installed systems?
Lastest Debian stable FWIW.
Oh well, I take it it's going to be mokutil and whatnots when I get back home.
There's some link between secure boot and encryption.
If you don't do secure boot, you need to secure your boot chain in other ways, to prevent attacker from modifying your software to log entered passphrase.
Secure boot allows to build a verifiable chain of software (UEFI -> Bootloader -> Kernel -> Initrd) which will protect against any modification, so you can be sure that your key presses are not being logged by the malicious software. That said, commonly used Linux distros have some problems protecting initrd, but that's issue of those distros.
Another link is TPM. I set up my system in a way to keep encryption key in TPM and release it only when secure boot is enabled. This allows to decrypt root automatically, without entering passphrase and my configuration only allows to boot UKI kernel signed with my key. It trades security with convenience, of course (because now attacker, who stolen my computer, only has to break through gdm or perform other ways of attacks like extracting RAM sticks), but for me it's acceptable.
That's like saying there is some link between putting locks on your doors and setting up booby traps because if you don't lock your doors then you need to set up booby traps to prevent a thief from stealing your stuff. They're both trying to mitigate the same threat, but there is no connection between the 40 pounds of explosives I have wired to my front door and an intricate metal cylinder that can only be manipulated by another piece of metal in a specific shape.
No, it’s like saying there is a link between putting locks on your door and making sure the lock can’t be replaced with one that takes someone else’s key, or worse one that copies the key that’s put into it. The threat models directly overlap.
That's a good analogy to point out the weakness behind relying on encryption without secure boot but without going into the mechanism behind "making sure the lock can’t be replaced" people might incorrectly think "they're both about setting up locks and therefore they are linked" whereas "making sure the lock can’t be replaced" involves securing the environment that the lock is placed in, like "Make sure your hinges are not exposed so the door cannot be taken off its hinges from the outside and replaced with a seemingly identical door."
I think it’s primarily to avoid someone just putting your SSD into any other computer and access all files. Anything more is probably not a realistic threat to most people.
for most people that is an irrelevant threat model. people can steal my laptop, but if they don't know my passport they can't access my data. end of story. they would have to break into my laptop without stealing it to install any kind of tool that can read the password. how/when is that going to happen ever without you knowing it? you would have to be working on highly sensitive, and sought after stuff for someone to try that.
Unless you're using a SED, your EFI system partition is unencrypted. It would be trivial to build a malicious copy of popular open source UEFI bootloaders (grub, refind, zfsbootmenu, etc), and a bootable USB stick that scans your EFI system partition, replacing your unencrypted bootloader with a malicious one. This attack could then be applied by relatively unskilled people in a couple minutes ("boot this flash drive, wait until the screen says "done", power it off"). I hope your laptop is never out of your possession for more than a couple of minutes! (For example, the TSA at the airport, geek squad or other repair centers, or classically an evil maid).
By default, the secure boot status is part of the TPM registers that are used to unseal the encryption key for your drive. That's because if you disable secure boot, or reconfigure it with different keys, any bootloader could just replay measurements from a normal Linux system to the TPM and unlock your drive.
Calling systemd-cryptenroll with --tpm2-pcrs would allow you to manually pick a set of options. I believe Bitlocker uses 0, 2, 7, and 11 (11 being an OS specific register rather than a spec-defined one), which is why firmware updates often make you re-enter your Bitlocker key. Some people choose to only record the secure boot state, relying on the firmware to validate its own updates and config, which means you don't need your recovery key after firmware updates as long as the secure boot state remains the same.
Not taking secure boot state into account makes the entire setup rather easy to bypass, but you could do it to make your setup harder to break while still protecting against the "thief steals my SSD but not my laptop" scenario.
In addition to the great answer by jeroenhd, you also might have encrypted your secure boot signing keys with your TPM. This has the advantage that your signing keys can't be stolen so you know that your bootloader was signed on your specific physical machine. But this is not necessary, you can just store your signing keys on your SSD or anywhere/anyway you want.
No it's not. Secure boot without user control is evil. UEFI generally allows user control. Of course a vendor can make an UEFI system that doesn't allow user keys… don't buy that.
It's not just Linux - certificates to sign Windows are also affected in 2026.
https://support.microsoft.com/en-us/topic/windows-secure-boo...
https://techcommunity.microsoft.com/blog/windows-itpro-blog/...
Really it seems like having any expiry date for these certificates is a mistake. The one thing it might protect against is a compromised signing key, but if you have to wait 15 years for a compromised key to stop being valid, it's not very useful!
Don't worry, the replacement MS certs expire in 2038 (a couple of months after the 32-bit unix time rollover).
The mistake was not to put an expiry date on the certificates, but to trust hardware vendors to do even basic firmware maintenance after motherboards and laptops leave the warehouse.
In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do.
In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.
Which to me leads me to a bigger problem, UEFI is trash, too complicated, too bloated, too hard to implement all the various bits and pieces.
In my opinion the system firmware should do the absolute minimum possible. Find a piece of data somewhere that the processor can start executing, like in the BIOS days where it would just load in the first 512 bytes and start running that. Anything else like hardware configuration, power management, etc... should be left to the operating system.
Mobile phones and a lot of embedded systems have minimal system firmware like this and it is a total disaster, basically forcing you to have per device special software releases with all the hardware specific things EFI would abstract for you, enabling a generic system software image supporting many devices.
As a result, many of these devices are buggy, insecure & are never updated once shipped or updates get abandoned soon after.
That's not realistic. Too much stuff is board-dependent and trusting vendors to upstream it (or even disclose documentation) isn't going to work never ever. I think what should be done instead is to swap privilege levels so that after-boot firmware services runs under operating systems, not above it. ACPI, with all it's sins, is pretty close. On the other hand, RISC-V made same old mistake of introducing SMM under other name into their supervisor spec and addeed their own secret sauce of forcing damn TIMER interface to go via SBI (seriously, WHY? High timer latency was known to be a problem om x86s requiring all sorts of weird tricks since Win95 or so).
The real myth here is that the BIOS did nothing more than load 512 bytes and start executing. It was already doing tons of stuff to configure hardware and provide information to OSs well before UEFI came along.
All the "PnP"/"ESCD" stuff the pre-UEFI BIOS did was to support DOS or because of DOS. APM leveraged SMI for fan and power control so DOS would work on 90's era laptops. That whole mess morphed into the nightmare of ACPI and UEFI.
The only thing a firmware really needs to is A) initialize RAM, B) initialize a display or serial port for boot comms, and C) load an OS. Anything else modern firmware does would be better as normal devices controlled by OS drivers without the ACPI/UEFI layer.
A third thing: it is of course super convenient if firmware provides some way to reliably identify the platform and provide data on devices that aren't connected to discoverable buses (such as bus controllers themselves), but even that's not really required. Linux lets you build a devicetree as part of the kernel.
> Linux lets you build a devicetree as part of the kernel.
And it's absolutely awful as an end user if you have anything even slightly unusual.
UEFI standardizes the things vendors and operating system manufacturers were already doing anyway. Even in the BIOS days, firmware was doing PXE boot and things like modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs.
You can flash all kinds of alternative firmwares to many motherboards if you know where to look, but those firmwares often end up reimplementing everything UEFI does to get an operating system to work in the first place. Some firmware distributions even use a full Linux kernel as a UEFI replacement.
I'll take UEFI over BIOS any time if only because it finally solved dual booting.
> modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs.
Wait, what? Did this thing at least have the courtesy to check that you were indeed booting Windows or would you just get random crashes if you tried to use the mainboard(!) with any other OS?
This stuff seems inches away from a supply chain attack.
https://view.officeapps.live.com/op/view.aspx?src=https%3A%2...
It's more that Microsoft would read & execute a binary from a specific place in memory, allowing companies to maintain persistence / ensure their drivers are always installed / ...
You do also need to assist the OS in doing hardware probing. Even older BIOS systems had ACPI and other standards.
EFI was part of the itanium culture at Intel to reinvent the IBM PC. I think it's one of the few surviving legacies of all of that.
There is no basic firmware maintenance to do. Firmware is supposed to be properly engineered, immutable, still to this day sometimes physically wired as 1s and 0s. It doesn't make sense to have expiry dates carved in stone.
Firmware needs maintenance because unless you're doing stuff for the aerospace industry, you're not mathematically proving that your firmware is bug-free. Eventually someone will need to install updates.
Well-written firmware doesn't need to be updated for the key database to get updated. However, some vendors messed up and now require firmware updates, while others simply store the new key in NVRAM.
Not to mention that firmware updates are often necessary for things like supporting new CPUs. Immutable firmware means that your system can never improve or expand to support new hardware, and I would hate to have to buy a new motherboard to support a new CPU.
You shouldn't need new improved proprietary software to support new hardware, that's just wrong. They're just bundling free apps into hardware at that point.
"New CPU needs a new software" shouldn't be an excuse to just let CPUs becoming its own computer with the real CPU you're paying for as one of many features. That's just fundamentally wrong.
That is reality though. It happens all the time.
Modern computers are distributed systems of components. Each component has its own cpu and OS running in firmware. And they talk over the system bus.
No, the real mistake was putting the root of trust anywhere else than the user.
The user can load their own keys into their secure boot storage and use those keys without any interference from pre-installed certificate authorities.
This issue only affects the people who don't want to bother being the root of trust.
From Microsoft's point of view, that's not a mistake. It's the whole point! The user is a potential pirate, after all.
What purpose does the expiry date have? There might be something I've missed, but I really can't see one apart from needless complication, which is what makes it a mistake. (There are other problems in the UEFI/firmware ecosystem yes, but that doesn't excuse expiry dates)
I don't know if this is why the people behind secure boot adopted this design, but expiry dates make CRLs smaller, at least in theory. If a revoked certificate expires, you don't need to add it to the CRL because trust is invalidated automatically. By rotating root keys occasionally, you can also keep the revocation list for vulnerable bootloaders smaller, as you can remove any vulnerable bootloader when its signatory key expires.
With the kind of penny-pinching that happens with NVRAM storage on boards like these, being able to reduce the size of CRLs can make a difference.
UEFI's equivalent of the CRL is the "forbidden signature database" (or DBX) - but as far as I can see, it only has 658 entries (the source appears to be https://github.com/microsoft/secureboot_objects/blob/main/Pr... )
Another potential use is to facilitate managed deprecation of obsolete crypto functions / protocols / hash suites / etc.
That fits pretty well with a 10 year rotation period, and is probably more valuable in the long term than minimising DBX size.
Hm, I guess that's one point. 15 years worth of accumulated revoked certs is a pretty big list though, not sure how much they win there.
Idle thought - wonder if there are perfect hash-like constructions they could use for revoked certificate lists.
As a Linux user, I am shocked--shocked!--to hear that consumer hardware vendors are taking shortcuts and abandoning maintenance as soon as they can.
I'm feeling/guessing the expiration is more of a flow-with-tradition thing. TLS certificates expires, it's part of the security feature, so why not Secure Boot certificates too?
And of course, it gives the root certificate issuer enormous amount of power as well, good riddance from the POV of Microsoft.
However, I think if Microsoft REALLY care about security, they should not let application installed on their system to do anything that is unapproved by the user (such as installing a virus that encrypts all their data), which could actually enhance the user experience and security. But, with secure boot, at least you can be sure that your Windows kernel is not tampered so it can serve the virus correctly :)
> Really it seems like having any expiry date for these certificates is a mistake.
Especially when most relevant attacks occur in the scenario where attacker has control over the system clock.
Is that really a mistake? Or Microsoft just has no interest to care about computers not working as intended anymore.
It certainly wouldn't be the first evidence of that…
Being cynic, there was the expectation that computers would get replaced before the certification expiration date.
Disaster recovery planning must be fun - 'take a fresh machine from store A, and use the Windows CDs stored in box B, and....'
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.
It makes more sense if you view it for what it is: Honest Satya's Certificate Authority.
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.
Secure Boot is the computing antichrist, and Linux folk were 100% right to rally against it. As well as a whole bunch of other "Trusted Computing" garbage.
Trusted Computing is to trust the NSA with your computing. They need to have access, right? And since they cannot control all hardware vendors, they opted to control Microsoft instead, and forced UNIX to play ball.
Yeah, it opened up the door for us not owning not even our phones anymore, and soon even the browser itself.
mind to elaborate?
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?
Who controls the fucking certs?
"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.
> Who controls the fucking certs?
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?
Take an iPhone or a Switch. Then disable Secure Boot on it. Good fucking luck.
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.
> Is SSL also an evil technology designed to take away freedom from the internet?
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"
> 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 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).
<< Which is exactly why users have the freedom and choice to just disable Secure Boot?
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.
> Which is exactly why users have the freedom and choice to just disable Secure Boot?
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.
> Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet?
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.
> Who controls the fucking certs?
You can? Delete the default (ie Windows certs) and import your own.
I think it is only required on x86 EFI machines due to some old antitrust rulings. Provided the firmware vendor actually implements it right.
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.
Lol you never read about all the Lenovo malware fuckups, apparently.
Which basically are exactly what "infosec fucktards" as you named them warned about.
I do.
> I'd love to know if my machine has been compromised with early boot stage "meta-hypervisor" or not.
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.
> you have to trust the firmware anyway
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.
Consider using Heads with TPM and Librem Key to detect possible compromise of your boot stage. It doesn't obey MS but you.
With Heads, the firmware measures itself and sends the results to the TPM. If an attacker flashes a modified firmware that simply lies about the measurement results, the entire security system will be bypassed.
This is not true:
https://forum.qubes-os.org/t/discussion-on-purism/2627/187
https://forum.qubes-os.org/t/discussion-on-purism/2627/177
that's still secure boot, isn't it? just not uefi but homegrown?
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.
ME is disabled and neutralized on my Librem 15: https://puri.sm/learn/intel-me/
Now do Systemd...
Call me childish, but I don’t want to ask Microsoft to sign a certificate for me before I install software onto my own hardware.
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.
> Plus, keeping Microsoft’s CA installed greatest reduces any security which I’d get from SecureBoot.
Can't you just remove all CAs from the UEFI and import only your own anyways with most mainboard vendors?
Yeah that's how my systems are set up. I also appreciate that each firmware let's me restore the original keys just in case without me having to manually back them up -- but they're not active for secure boot.
Maybe this isn't a great take, but RedHat/LKF/etc could obviously run a 'semi-competent' PKI, and probably should be. But doing so would allow PC vendors to cleanly segment machines between Windows and Linux (+$$), so perhaps it made the best sense to lay-low and use MS infrastructure for this.
Can easily imagine companies like Dell selling you a system with Ubuntu preinstalled but without Windows signing keys so you can't run Windows on an Ubuntu laptop (or vice-versa) with Secure Boot on an unmodified system.
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.
This isn't really true.
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.
Sure they would, if it would make them a buck. Lenovo for example already has separate models for pro ThinkPads with 'certified' Linux support versus the consumer line. Dell too. PC vendors already have 9000 SKUs, what's a few more?
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.
Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=647959
If Linux users had "stepped up to the plate" and demanded their own separate PKI, nothing would be different, except that every system that shipped with Windows would be locked to Windows. Dual booting would not be a thing.
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.")
[1] https://wiki.gentoo.org/wiki/Secure_Boot
This makes no sense.
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.
> Now had the Linux folks stepped up to the plate early on, instead of childishly acting
This kind of victim blaming gets annoying very quick, as if the Linux ecosystem had any leverage at all on PC manufacturers…
> as if the Linux ecosystem had any leverage at all on PC manufacturers…
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?
orrr we just have official institutions which do this and enforce vendors to add certificates from other trusted parties. not only microsoft is able to do this. also microsoft already also had fallout regarding signing.
and secure boot is still the antichrist, but we have to live with them.
The problem here isn't that Microsoft is the one signing the shim, but that we can't trust systems manufacturers to update their systems, or even to have systems that can be correctly updated.
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.
Basically every x64 computer is intended to be able to run Windows. Hence MS had to be involved, and I suppose nobody else with serious money wanted the burden.
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).
Secure boot belongs to a class of security that while clearly giving a theoretical benefit in practice it falls far short of providing any benefit whatsoever at least to the user of a system. Its introduction was mostly part of a wider (probably partially defunct and failed regarding mobile x86) strategy to lock down the PC so the Microsoft store and purchased apps through it would be more secure from the end-user. Secondary was in my opinion better security for handheld phones and tablets running x86 but there the "App store" aspect is even more clear.
"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.
What kinds of attacks was Secure Boot designed to mitigate? Is it the evil maid attack? Or an accidentally ran with `sudo` program can indeed screw your entire boot process and inject rootkits etc.? Or is it something else?
> What kinds of attacks was Secure Boot designed to mitigate?
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.
Another example: a custom kernel build or kernel module that backdoors your system or steals data at the kernel level. Secure boot provides the opportunity for a chain of trust that goes from the firmware manufacturer all the way down to your individual kernel modules.
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.
Evil maid and rootkits, mostly. It's also part of the trust chain that unlocks an encrypted disk without having to enter a password.
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).
That is sorta the rub - the treat profile "evil maid" is mainly governmental actors for most people even for Orgs. Your example shows mostly how an org can secure their own devices against casual misuse by unprivileged users. This does not help against any serious attack. It only protects against stuff you don't need to worry about generally.
> Or an accidentally ran with `sudo` program can indeed screw your entire boot process and inject rootkits etc.?
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.
Anything that locks you out of your own computer is at absolute best an availability failure but more often than not forces you to use compromised system software.
MS did not "Have" to be involved. The problem is that doing it right is hard, not hard as in "it was tricky to figure it out but once we did everything works" but hard as in "every single user now has an additional impossible to remember key they have to keep track of or they get locked out of their system", basically the mother of all support nightmares. so Microsoft took the easy(perhaps realistically, the only) way out. they said "we are not going to have the end user own their keys, we will own the keys"
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.
Eh, that's basically what we have now with boards where you can delete the MS keys and enroll your own. Just with different defaults and no support nightmare
We don't even reap the benefits of autocratic decisions from Microsoft in this area. Boards always come out with things like messed up ACPI, etc.
Boards' ACPI etc. is still better than what it would be without "certified for Windows" (whatever name of the hour is) programs
Only legal requirements can change it. Nowadays, the mokutil is good enough that linux users can build a good tool around it to automate registration at boot that should ease some pain. But otherwise, it is a big mess and still needs legal requirement.
The EU should step in and make sure that any critical OS attestation is taken out of the hands of the big players. Look at GrapheneOS is being denied Google Play Integrity [1] on pretty much no grounds with large consequences. Such security infrastructure is to easily abused to put bias into the market. On the other hand funding is needed to professionally run this stuff.
[1] https://discuss.privacyguides.net/t/grapheneos-is-taking-act...
"The EU should step in"
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!"
You don't. I remove microsoft's keys from all of my systems and enroll my own key.
But you can turn it off or en-roll your own keys.
It's just a default. You can override it with your own platform key.
[dead]
Things that might not get updates shouldn't use the current date/time when checking certificates. Instead, they should see if the certificate would have been valid on the day the firmware was compiled (ie. behaviour will never change through the passage of time alone).
Expired certificates should also at worst be a skippable warning. No one’s relying on certificates expiring for security. If you did you might have to wait many years for the expiration of a stolen certificate - lol!
It’s absolutely a minor “hey btw the certificate expired, check for an update” yet various systems treat certificate expiration as an end of the world lock it down scenario.
Oh it's skippable all right. Just pull the cmos battery and wait a few seconds before putting it back in.
There's gonna be a bunch of linux users who write a shutdown script to set the date back to 2015 then poweroff... And at startup, reset the date back to today using the internet.
Sounds like a cleaner solution than any of the ones in the article too!
That's risky, an unclean shutdown would require resetting the clock which is a bother.
It's much more likely that someone will write a driver that adds an offset to the clock, keeping the hw date in a safe range.
You can simply avoid adjusting the hardware clock. The kernel clock is not tied to it and can be modified separately. chrony can do that, for example.
https://wiki.archlinux.org/title/Chrony#Real-Time_Clock
Infosec engineers hate this one trick!
>years for the expiration of a stolen certificate
Code signing certificates are trending down in length. Ot recently dropped down from a max of 39 months to about 15 months.
That seems to almost completely defeat the purpose of expiration. One could do a bit better by requiring the signed object to be timestamped by some sort of secure timestamping service. But then one should seriously consider the threat model that Secure Boot with default certificates is intended to defend against.
The day infosec nerds get rid of their unhealthy obsession with expiration and realize that systems irrecoverably breaking on an arbitrary random instant or requiring a true source of time to work are REALLY FUCKING INCOMPATIBLE with the real world, they might actually get something done. Until then, please don't bother the rest of us trying to get work done (and having to cleanup the mess you made - what do you mean you can't just update it?!)
[flagged]
And what is the purpose of expiration in this case?
There is no purpose to the expiration in this particular case. If you have an expiry of say 24hours and constantly update that makes some sense - stolen certs get a very short time window.
If however you have an expiry of multiple years you clearly have no reason to have an expiry date at all. You can't possibly justify a security benefit, imagine reassuring people with "the stolen certificate is only valid for a few years!"
As in it was clearly a mistake to have an expiry date at all for this use case and the multi-year expiry date should have been a smell that tipped people off and made them ask "why do we have an expiry date at all for this?".
If there were no certificate expiry, I could break into your system by finding some bankrupt company last trading in 1980 and stealing their keys to mint my own certificate.
With expiry dates, at least the pool of places you can break into to steal certificate signing keys isn't growing without bound.
there is a difference between the expiration of signing keys, and the expiration of the signature signed with those keys. the signature for a contract, or a bootloader, should remain valid indefinitely, even if the person/key is no longer allowed to sign contracts/bootloaders after some point of time.
That sounds impossible to enforce. Key signing is done offline. If I have an expired signing key, what’s stopping me setting my clock back a few years, creating a new signature and signing it?
If the resulting key works indefinitely, the expiration date on my signing key is utterly meaningless.
Trusted timestamp services. https://en.wikipedia.org/wiki/Trusted_timestamping
Microsoft's Authenticode has been doing this for a long time, allowing a signature to be considered as valid long after the signing certificate expired.
https://learn.microsoft.com/en-us/windows/win32/seccrypto/ti...
And what stops people from just logging into the bios and changing the date or pulling the clock battery? The point we're all making here is, at least for this application, is that an expiration is pointless.
You can do almost as well by finding a piece of software with a code execution exploit early in boot that’s signed by the bank.
A different model would be to only allow a given EFI binary to be booted if it was installed before the deadline, but that might well have a different set of complications.
Even more, the "current date" comes from an external source that anyone with access to get new images on the machine can probably also manipulate. Setting the hardware clock is a normal operation available to the kernel.
I wonder what my laptop will do soon.
Lenovo, in their infinite wisdom, has decided to load an Nvidia blob signed by Microsoft before even being able to access the UEFI firmware interface. People who have tried to install their own secure boot keys found out the hard way that you can't even get into the firmware configuration interface to undo the change.
Their official workaround is to only load secure boot keys through their firmware interface (rather than the standard Linux utility) which refuses to wipe the certificate used to sign the Nvidia firmware. However, that workaround will obviously stop working when that certificate expires.
The Framework laptop with the AMD 7840U works perfectly without any microsoft keys enrolled.
For your current laptop, you might be able to use the `--tpm-eventlog` to `sbctl enroll-keys` to enroll hashes of your OptionROM to whitelist that blob.
Using "Secure Boot" with MS keys is not real Secure Boot. It's "Microsoft decides what you may boot". Enrolling your own keys should be the standard way of operating. shim is a joke.
Just out of curiosity, how good is the secure boot experience these days?
I've had to disable it on all my installations because of either nvidia drivers or virtual box modules. In general Arch based distros didn't seem too friendly for secure boot set up.
I would rate the experience as 6.5/10
If you use a major distro like Ubuntu, you might find Secure Boot works out-of-the-box, with no need to dick about with 'machine owner keys' and suchlike.
Ubuntu has packages like "linux-modules-nvidia-550-generic" containing a version of nvidia's 550 drivers signed with canonical's keys. If the stars align and that package gets installed, you'll have nvidia drivers that work under secure boot.
They also have a second mechanism. You can set up a 'machine owner key' (MOK) then software updates will trigger automatically building new nvidia kernel modules, using 'dkms' then sign them with the MOK allowing them to work under secure boot.
The problem is this process can be a bit wonky. The MOK setup process involves rebooting and going through the "MOK Manager", an interface that looks like something from the 1980s. If you didn't know to expect it, or what it's there for, or you don't speak English, it's easy to hit the wrong thing and not set up your MOK. And it only shows up for a single boot, unless you know an arcane terminal command.
And if you run into any problems during the setup process - you're going to be researching the fix on your phone, because your PC isn't booting.
Meanwhile, the third option of just turning off secure boot is easy (assuming you know what the BIOS is) and it works every time. So a lot of 'how to set up nvidia drivers' guides just recommend doing that.
Although I complain about it, I find it impressive things like dynamically compiling and signing kernel modules works as well as it does - especially as so much of it is maintained by volunteers, selflessly giving up their free time when they could have simply turned off secure boot in their BIOS too.
Mok has a big problem where malware can get you to sign malicious code with it. Having the signing keys be accessible to the end user is dangerous.
My experience as a long time Linux user (since 1997, so admittedly stuck with some bad habits from when things were actually hard to get working) has been that things are kind of confusing if you deviate from the golden path, but if you are on the golden path you won't ever notice that it is turned on.
The laptops I have gotten from eg Dell with Linux pre installed have just worked. Machines I have upgraded through many versions of Ubuntu (lts versions of 16-24) were weirdly broken for a while when I first turned secure boot on while I figured it out, but that seemed reasonable for such a pathological case. Machines I have installed Debian on in the last few years have been fine, except for some problems when I was booting from a software raid array, but that is because I was using 2 identical drives and I kept getting them confused in the UEFI boot configuration.
I have not used them on machines with nvidia, vbox, or other out-of kernel-tree modules though.
Every couple of years MS do an update that messes up multi-boot/dual boot. I'm sure it's on purpose at this point, and relatively sure "Secure Boot" is how they achieve it.
Still on Windows only for kids games. Linux user since last millennium.
As a Linux-only gamer since 2019 I wonder what kids games you are talking about?
I've stopped trying to fight to install things on Linux. Anything with kernel level anticheat it seems is torment. They okay Fortnite, and quite a bit of Marvel Rivals (which initially worked, then stopped, I see reports suggesting it's working again but I don't have time to be full-time support to keep things running smoothly).
We do use Kubuntu for games that run in it without drama - Risk of Rain, Roblox (via Sober), browser games, CS2.
They also are expected to use Microsoft Office for school (UK), it's possible to work that online, but the experience is worse, slower, more prone to issues it seems.
Fwiw, I've been a Linux distro user for decades and was Linux only until the first child got to highschool. Microsoft's "educational" policy works for them!
There are things like Roblox that are really only usable under Windows due to a perverse idea of what "anti-cheat" should look like.
https://sober.vinegarhq.org/
I can confirm Sober works really well, possibly slightly smoother than the Windows client.
I couldn't get it to run via Proton/Wine at all.
ah, I almost mentioned roblox but checking protondb it has gold status. So it should work?
> Every couple of years MS do an update that messes up multi-boot/dual boot
IIRC the last time this happened it was the fault of Linux distros not updating their packages, it was just a Microsoft update updating the security requirements that affected distros that were caught slacking.
The idea that MS should be able make orders that distros then have to follow is insane. If MS breaks something it absolutely is their fault.
No it's not. Microsoft has to disable outdated and vulnerable signed bootloaders to stop them being used for secure boot bypasses. Microsoft worked with RH to get things updated which they did, it's just distros for caught slacking and were shipping an outdated vulnerable boot loader.
I know it's the norm to bash Microsoft and they do a lot of crappy things, but in this case it was just certain distros not taking security updates seriously, which is why a lot never broke (such as Fedora)
So Windows installs something that brakes Linux boot. How are you supposed to boot Linux to install a fix? Am I expected to reboot into a different OS twice a day and check for updates? Am I slacking for not doing so?!
No, Windows updated a UEFI component that disables outdated and vulnerable bootloaders to stop them being used as secure boot bypasses.
I use Fedora and have it enabled. Every time there is a kernel update I have to run a script to re-compile and sign the vmware drivers. I could probably figure out how to do it with dkms at some point. Every now and then, there's a kernel change big enough to make the vmware drivers stop working so I have to get a new patch.
Signature maintenance for modules can be fully automated. Enrollment requires navigating a mildly-intimidating interface a single time to accept the new PKI.
Fine for systems you physically manage, anything remote in a datacenter I wouldn't bother (without external motivation)
Which is strange because secure boot should be useful in _exactly_ the situation you don't have physical control of the HW, shouldn't it? I guess the threat model for a common not-that-important company does not include evil data center (and it's dubious if SecureBoot would protect you in reality), but wasn't that one of the motivations?
Well you can tie it to TPM to store your encryption key which should only produce the key when the boot parameters match the key. This is what Windows already does but its not fully supported under Linux and somewhat insecure as you can't encrypt the initramfs (so someone can infect boot process there instead).
There are ways to solve that issue. But I think that you're correct, pinpointing the core issue with popular Linux distributions. It doesn't have to be this way, though.
1. You can sign and verify initramfs, it's supported by bootloaders.
2. You can merge kernel and initramfs into UKI and sign the whole image.
I don't know why that's not implemented.
For UKI I imagine a big hurdle is the size of the images (given /boot/efi is usually only big enough for bootloaders, not kernels and initram) and custom kernel modules (e.g. Nvidia).
There was some systemd work on a spec for a boot partition to extend the efi partition for storing kernel images and initramfs, but I don't think any distro currently defaults to it on.
I think hibernation is currently also broken, since the hibernation file is stored unencrypted by default and thus can't be used with secure boot.
With a UKI the initramfs gets signed too, doesn't it?
> Which is strange because secure boot should be useful in _exactly_ the situation you don't have physical control of the HW, shouldn't it?
One of the ways you can introduce your own signing key is as a Machine Owner Key, using the "MOK Manager"
But a design goal of this software was: We don't want malware with root to be able to introduce a MOK without the user's consent, as then the malware could sign itself. So "MOK Manager" was deliberately designed to require keyboard-and-mouse interaction, early in boot before the network has been brought up.
Of course if your server has a KVM attached, you can still do this remotely, I guess.
Aye, though an evil maid has higher barriers and more paperwork in a DC.
I hesitate based on that mitigation and the untold operational pain. Sometimes it's worth it, other times it isn't.
With Arch, I've been using SecureBoot since sbctl [0] was released with 0 issues. Granted, I don't use any Nvidia hardware.
[0] https://github.com/Foxboron/sbctl
It works pretty well out of the box unless you're trying to combine Linux with Nvidia hardware. Even with Nvidia hardware it doesn't take that much effort to make it work, but as usual, Nvidia requires taking extra steps.
What Linux is really lacking is a user-friendly method for enrolling your own keys, which would instantly solve all the Nvidia/firmware updater/custom bootloader problems. The command line tools are slowly getting easier to use, but there's no guided instruction flow.
I'm using Arch and it was very easy to configure secure boot. I don't know why you think it's not friendly. I'm using UKI, so no bootloader at all, my UKI is signed by my own key which is installed into UEFI. Most of sign process is handled by systemd, so most of it is already integrated into the base system.
UKI + secure boot works really well, but it is somewhat manual of a set up on Arch (what isnt).
If properly set up the only files you generate are:
- /efi/loader/random-seed
- /efi/EFI/Linux/arch-linux.efi
- /efi/EFI/Linux/arch-linux-fallback.efi
and the .efi are all automatically signed by hooks.
You can even skip a bootloader and boot the images directly.
I just finished setting this up and it's definitely this easy. The hardest part was growing the ESP to dual boot with Windows but that is basically just copy/paste the files to a bigger partition and change the partition type GUIDs.
Most of the guides focus on creating the PK, KEK, and db certs for enrolling/updating certs from userspace with signed .auth files but that is kind of pointless and seriously over-complicates it. I just created a 20-year db key pair with openssl (and PK and KEK just to make sbctl happy due to a bug), then installed the public db cert into the UEFI manually via the ESP. Didn't even need to use setup mode, although I suspended BitLocker on the Windows partition to let it reseal its key with the new PCR 7 measurement after the db update.
To finish securing it I have a separate key for PK and KEK and have already installed Microsoft's 2023 UEFI certs in the db (and added the 2011 cert to dbx with the updated bootmgr).
I just used sbctl to generate and install a platform key in setup mode. It worked well.
One checkbox during install when using Ubuntu with custom DKMS modules. That's it. For the past five or more years.
just doublechecked with "Confirm-SecureBootUEFI" - says True on my laptop which used > 1 year. I'm pretty sure on the previous system which was used for 4 years it was on too - have not noticed any issues.
Windows 10 and then 11
Reading into the history of Secure Boot. Discovered Intel and AMD processors have back doors via Intel Management Engine [1] and AMD Platform Security Processor [2]. Both are closed source and have had a number of vulnerabilities over the years. They are essentially backdoors.
Seems disabling these "features" is nearly impossible as well.
[1] https://en.m.wikipedia.org/wiki/Intel_Management_Engine
[2] https://en.m.wikipedia.org/wiki/AMD_Platform_Security_Proces...
And this is why I avoid and will always avoid "Secure Boot". I can see many newer Linux people being locked out starting in Sept.
Or you could just remove microsoft's keys from your systems and sign your bootloader with your own key. That's what I do on all of my systems so I am unimpacted by this.
Warning: Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the firmware settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware (OpROMs), that get executed during boot, are signed using Microsoft 3rd Party UEFI CA certificate or vendor certificates. This is the case in many Lenovo Thinkpad X, P and T series laptops which uses the Lenovo CA certificate to sign UEFI applications and firmware.
“Just” is doing a lot of heavy lifting in that solution.
https://wiki.archlinux.org/title/Unified_Extensible_Firmware...
Sure, but that's a lot more work than just disabling Secure Boot, and for most people's threat models, there's zero actual security benefit gained in return.
do you have any source on how to do that?
The arch wiki has the best source https://wiki.archlinux.org/title/Unified_Extensible_Firmware...
Note sbctl is one of the easier tools to do this.
I followed https://github.com/nix-community/lanzaboote/blob/master/docs... but naturally you don't want to include the `--microsoft` flag when running `sbctl enroll-keys` if you want to avoid microsoft keys. Also Lanzaboote is only for NixOS.
There should be some “Sane Usage” certification that a device doesn’t do secure boot, provides fully open and self-maintainable hardware, is independent of all external entities for ongoing use, provides hardware switches to turn off built-ins like ports, mics, and cameras, for power-savings and security.
To be able to get Windows licenses and preload Windows on your system, put that little Windows sticker and sell your machine to the masses, you need a Windows Compatibility certificate, and that certificate needs you to have Secure Boot and enabled by default.
Sounds anti-competitive as fuck to me. Maybe we should, I don't know; do something about companies using contractual requirements to lock key industrial into one way of doing things in order to shut down such efforts?
What is the something we can do?
"Will this piss off or delight Microsoft?" is probably a thought that goes through the heads of many OEMs when they decide how to design their machines.
Weirdly Microsoft has been one of the companies ensuring Linux remains bootable on PCs.
Microsoft has been trying to tread a fine line between exerting subtle pressure on OEMs to make Linux annoying to boot so it doesnt become more popular and not violating the terms of its antitrust agreement.
Bill Gates famously asked: "Can we create a standard or expand something like ACPI, so Linux becomes unbootable on PCs?"
So, believing this is very, very hard.
Newer Linux people will presumably be using the new key though?
I didn't realize that the Secure Boot certificates that allow us to boot Linux at Microsoft's pleasure are things that expire. So all Microsoft has to do to kill end-user Linux is... nothing.
How the hell did we get ourselves into this situation? After Microsoft spent years secretly threatening people with lawsuits for running Samba and Linux VFAT, and describing open source as "cancer"?
The article should include a very obvious way for someone to test if they are affected. How does one verify (in an in a VERY clear and straightforward way) if some arbitrary system will run into this issue in September?
Set your clock to December, reboot, and see what happens.
I'm sure this is a naive take, but why is it not possible to enter a new key into the BIOS (dating myself, I know it's EFI) by hand?
It's possible and it's what you should be doing. "sbctl" (https://github.com/Foxboron/sbctl) AFAIK has a reasonable frontend for doing that on Linux (don't know, I did it manually). You have to put the system in "secure boot setup mode" in BIOS/UEFI options before booting, which enables changing the PK (Platform Key) which is used to chain off all the other keys. (Setup mode should be automatically exited when you install a new PK.)
You can keep the Microsoft keys in there if you want to dual boot Windows, you just need to re-sign the keys themselves with your own PK.
It should be, at least on higher-end boards, no?
You'd have control over what boots on your computer then...
you literally have though. you can self sign everything and set up uefi to only boot your signature
Only on x86 secure boot implementations. On most devices with trusted boot, you don't have this option.
uefi on non x86 is a non starter for most people anyways. not that uboot is better
That would be a disaster. Or imagine what would happen if you just disabled secure boot, your computer will be infected with viruses and your bank account emptied instantly I reckon
Secure boot doesn't stop user-space malicious activity.
I'd argue that it only helps check a tick box on corporate security manifest, as it indicates the kernel being booted, is not tampered with.
OP was being sarcastic
it is
It irks me that Microsoft managed to shim their way into the Linux boot process like this. No key signed by Microsoft should ever come into play when booting Linux, on a moral basis.
you dont have to use the shim, just follow this https://www.rodsbooks.com/efi-bootloaders/controlling-sb.htm...
Libre operating systems are coded to run on machines that conform to Microsoft's hardware standards and conformance tests (Windows HLK) that define Windows compatible hardware. Linux is shimming its way into Windows' boot process, not the other way around, even on machines sold with Linux from the manufacturer.
If you want to be clean on "a moral basis", whatever that means, the FSF would have to create their own hardware standard and persuade OEMs to adhere to it. Good luck.
This is only the case because we let it be the case. Microsoft should have had zero influence on this. Consumer protection laws have utterly failed us.
TIL UEFI is apparently a "Windows boot process" /s
You would think it would be illegal to sell compute resources into Europe without an artificial expiration date controlled by a US company.
It's not just secure boot. Modern OS have certificates all over the place. These are ticking self-destruct time bombs in those machines that the manufacturers of hardware based on these OS may not necessarily realize. I am thinking ATM machines, voting machines, medical equipment, smart-fridges and other IOT, probably many cars, etc.
Oh, they realize it just fine. To them it is just another source of revenue. Planned obsolescence is going to wipe out our digital heritage at some point.
So is it a possibility that a grub update breaks an existing bootable node? That worries me as I have a couple of Linux desktops in the field which I can’t remember if secure boot is enabled on.
If users don't update their keyrings or firmware (through fwupdmgr for instance), Grub will probably stop booting with secure boot on when the certificate expires.
If users update Grub once the old certificate is no longer used to sign the bootloader without updating their keyrings or firmware, Grub will probably stop booting with secure boot on when the certificate expires.
If users do update their systems and software, Grub will keep working.
Not updating is not a solution, unless the motherboard manufacturer really fucked up and doesn't validate the expiration date.
Luckily, fwupdmgr is integrated in the GUI updater tool on just about any Linux distro I know. As long as users don't ignore the "there are system updates available" popup and as long as the desktop vendor put out bare basic software support, things will probably go down fine.
> Not updating is not a solution, unless the motherboard manufacturer really fucked up and doesn't validate the expiration date.
The article mentions that most motherboards will probably not validate the expiration date. There is a residual concern that new versions of the Shim will not be signed with the expired key, and thus be unbootable on hardware that doesn't accept the new key.
Secure boot, disk encryption, etc are more trouble than they are worth IME. I have them all off.
Qualifier: for personal computers that you don't take regular backups of, test backups, etc
Secure Boot's benefits are definitely not as strong (I don't think flashing custom backdoored firmware is a common attack vector for personal computers), but FDE is still useful in case your laptop gets stolen, because thieves looking for sensitive data on a hard drive is a thing that does actually happen.
I also wouldn't really say it's much trouble. If you have a TPM and use systemd, you can set it up to unlock FDE automatically on boot, otherwise, you just have to input an extra password when turning on your machine.
SB does not protect against backdoored firmware at all. You would need something like BootGuard which is a separate feature.
Can you elaborate on that? Isn't it the whole point of secure boot?
My understanding is that at least on Android you can't modify the system: you have to format everything if you want to make a change at this level.
No, SB starts with actually firmware already booting something. It is just one link in the chain. You can also look up Trusted Boot and Secure Launch, how this entire chain can/could be secured.
> SB starts with actually firmware already booting something.
I don't understand that sentence. So instead of a bootloader in the ROM that starts the next bootloader and verifies that it is signed (I think that's how it is on Android?), on a laptop the first bootloader can be installed by the user and nothing checks its signature?
EDIT: what I read here [1] is that Secure Boot is verified from the ROM to the moment it starts "the Windows kernel" (on Windows). But it's not completely clear to me: say on Linux, if Secure Boot verifies up to my /boot partition (does it?), then it should be okay because I have FDE on the rest, right?
[1]: https://learn.microsoft.com/en-us/windows/security/operating...
> on a laptop the first bootloader can be installed by the user and nothing checks its signature?
It should be signed by the manufacturer, so you shouldn't be able to. Loaded by a shim even smaller in the CPU, part of Boot Guard and Platform Secure Boot, if I'm not remembering wrong.
> say on Linux, if Secure Boot verifies up to my /boot partition (does it?)
No. It verifies one signed file, usually Grub EFI shim. Which then should check everything you want. Unlike Windows, desktop Linux distros rarely have the best SB system. Poettering has described this issue in depth.
So in 2025,2026 the simplicity of BIOS still haunts us. I realize this time it is a one-off cert issue, but there have been so many other non-trivial paper cuts in secure boot and UEFI implementation that I can't help but see this upcoming fix as spinning a roulette wheel of fixed/failed/bricked.
Well I can say that the update is not going 100% smoothly. I have a pending KEK update in Fedora but it's a test key (bug filed but no progress as of yet).
[Warning: I'm not interested in sarcasm or uninformed rants against secure boot, there are plenty already]
I'm hoping to get insights from people who understand secure boot well here. My understanding on Android (for the minority of Android manufacturers that do it correctly) is that there is a "manufacturer key" burnt somewhere on the ROM that cannot ever be changed, and once a first system is installed properly:
1. It is impossible to overwrite the system partitions unless the bootloader is unlocked from the already-installed OS (I assume that something makes sure that only the signed OS can unlock the bootloader?).
2. Once the bootloader is unlocked, it is impossible to overwrite only parts of the system: it's all or nothing, such that one cannot inject stuff into an existing system (evil maid style).
Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use.
How is it on UEFI? It sounds like the "manufacturer keys" are always from Microsoft, but is there not a way to use custom keys?
Of course it is possible to use custom keys. At least it was possible on all EFI computers I owned. There are no "manufacturer keys". There's usually an option in BIOS to restore default configuration which resets to MS keys, but you can delete all MS keys.
Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys and if you delete MS keys, you might brick your laptop, because GPU won't start anymore. That said, I'm using Lenovo Thinkpad T14s Gen4 Intel right now with all keys deleted and my custom key added and it works just fine. May be it's AMD issue.
> Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys
Oh right! Yeah if you want to use custom keys, you need to be able to build and sign your OS, and proprietary firmwares are then a problem. Now I wonder why this is not a problem on Android... Is it because the firmware blobs come from the image that you sign yourself?
Would the solution be that the GPU should load the firmware from the OS?
You don't need to be able to build them. Just sign them or sign the keys that sign the third party blobs/binaries.
Then your motherboard firmware will be able to load your GPU and other third party blobs to UEFI memory. Similarly OSes like Linux and Windows enforce the same chain of trust (they don't have to but otherwise it is not really secure, just like a website can lie to you about encrypted storage) so you need your drivers/OS loaded firmware to be signed as well.
What Android does and what UEFI does are not really related. It is like comparing how SSH does authentication vs how HTTP with TLS does. Former is a SSH-specific open-ended implementation detail, latter is standardized by IETF.
Similarly UEFI standardizes how a motherboard manufacturer can write a compatible firmware and Secure Boot (capital letters) is a sub specification of UEFI. It is not the only secure boot implementation scheme.
With Android device manufacturers have complete control over the early boot firmware and the OS. As long as they boot the OS to run apps, how they do it is up to them. Only things like Google's SafetyNet will put certain requirements on them. No standard like UEFI exists in Android phone world or anywhere else except PCs / Servers.
> Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use.
AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted. Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.
> AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted.
You're right! That's what I mentioned the few manufacturers who do it correctly. GrapheneOS only supports Pixels for other reasons than that. CalyxOS supports other devices (one constraint being to be able to relock the bootloader). /e/OS doesn't seem care so much about the secure boot.
> Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.
That raises a question: what is the point of relocking the bootloader? If overwriting the keys means that the whole system will be formatted, then I don't see why it should ever be prevented at all? If an evil maid wants me to lose my data, they can leave with the laptop, right?
> It sounds like the "manufacturer keys" are always from Microsoft,
The primary key is called "Platform Key" (PK) on UEFI, there can be only one, and it is generated by the mainboard manufacturer, not Microsoft. The PK is then used to sign Key Exchange Keys (KEK) which you will generally have 2…4 of, the Microsoft self-use one, the Microsoft third party one, a board vendor one, and a system/board specific one.
And next to those you can load your custom keys?
You need to replace the PK with one of your own, because that is used to sign all the other keys, and generally there can only be one PK. You can then re-sign the existing keys with your own PK (e.g. if you want to dual boot Windows) — or just ditch the existing ones¹, and/or you can generate your own keys of the other types (KEK & DB).
Ed.: ¹ there are cases where ditching the existing keys breaks the system, because the board vendor was stupid and signed the VGA UEFI driver with one of those keys instead of tying it directly into the BIOS/UEFI image. AFAIK this only affects a specific series of Lenovo laptops, but Google the details before breaking your system.
Ed.#2: actually I think the PK signature is only checked while installing keys into the KEK/DB list, so you don't need to re-sign the existing Microsoft keys, they just stay in the list by default. (Unless they got cleared somehow.) It's been a little while since I did this.
It should be noted, it is 100% possible to use Secure Boot with Linux and not be impacted at all. AFAIK, most (if not all) UEFI firmwares allow enrolling your own keys. Managing secure boot these days is as easy as installing sbctl and adding a hook to sign your kernel when rebuilding the initramfs. For the same price, as noted by the article, the key new key can be updated while the system is online without anyone being the wiser.
The FUD that gets spread around SB helps no one, and other than a small list of exceptions, you are always in control of your system.
SB allows MS to transparently enable Full Disk Encryption by default, which I think is a win for all users. It allows you to do the same on Linux. It lets server operators be sure their systems have not been tampered with. While there are many problems with UEFI, SB is not one of them.
There is hardware that requires drivers to even reach the bios. The drivers are signed with the MSFT key. And if you change to your own key you'll find you can't even get into the bios anymore.
Can't you just disable the internet connection, set the BIOS clock to a date before the expiration date to boot from the secure installation media and then reset it to the proper time after the installation is complete?
Is there a reliable command in Ubutu to check for the secure boot key and its expiration date?
mokutil
Check its various options
The 'Validity' field in the output will tell you the expiration date.
mokutil is technically the wrong tool for this, it lists shim-installed machine owner keys (MOK). This is about UEFI-installed key exchange keys (KEK). If you don't know what's going on you'll be very confused about empty key lists. It can in fact show KEKs but you need to know that this is a KEK thing to begin with…
is the magic incantation if you really want to use mokutil>Currently, shim is signed with a Microsoft key from 2011 that expires on September 11.
What security benefit did adding an expiry date to the certificate provide? "Oh no! Someone has gotten our secret key and is certifying new shims! ... Not to worry, the certificate will expire in 14 years. Everything is fine!"
Does anyone know the rationale for such expiry?
Knowing that any quicker rollover would've hindered or even stopped uptake before the technology got established?
Luckily I only use hardware from dumpsters that is old enough to have BIOS boot mode.
Just another factor creating electro-junk. Currently I can install 30 year old system on 30 year old hardware (assuming that I keep both the machine and the installation media in a good shape). With current computers it will be impossible because they will be "unsupported".
Just disable secure boot if you can't update the certificate. You can still use your computer.
I always have
Secure boot off Disk encryption off Tpm off mitigations=off in linux kernel cmdline
Fuck secure boot. A fun project, even if mostly for educational purposes, would be to collect all the different exploits that have been found over the past years and try to create a universal secure boot bypass loader that targets as many of those as possible. I guess chances are that if your vendor didn't update the firmware to include the newer ms keys, they also didn't patch any of the exploits. So we just need to also get this super exploit loader signed so that it works everywhere :o)
could we just set the clock backwards on shutdown and forwards on boot? or do the keys delete themselves after the date?
TLDR Linux systems using Secure Boot rely on a Microsoft certificate (from 2011) that will expire on September 11, 2024. After that, new Linux installs using Secure Boot may fail to boot unless the system firmware includes Microsoft’s newer 2023 key and updating the key often requires a firmware update from hardware vendors which doesn’t always happen. It’s crazy that many users are relying on an outdated Microsoft key unknowingly (I will be checking if I’m among them smh) Also great that people are bringing awareness to this
> Linux users who have Secure Boot enabled on their systems knowingly or unknowingly rely on a key from Microsoft that is set to expire in September.
No I don't because I installed my own keys, and so should you, and can we please stop assuming that Secure Boot means Microsoft keys?
> Any installed distribution should have a bootloader signed with its own key that will continue to boot
I'm kinda concerned here: as long as there's no mandatory security upgrade requiring a reboot, I'm the kind of person to reach six months of uptime with my desktop (yup, Linux is that stable, a far cry from Windows).
So I'm concerned about not being about to boot in x months and forgetting why (ah, yes, Microsoft having a key expiring).
Am I correct in my understanding that this only affects my installation media and not my already installed systems?
Lastest Debian stable FWIW.
Oh well, I take it it's going to be mokutil and whatnots when I get back home.
This is yet another why I do not encrypt.
Secure boot has nothing to do with encryption. It is verifying crytographic signatures. The bootloader is signed, not encrypted.
There's some link between secure boot and encryption.
If you don't do secure boot, you need to secure your boot chain in other ways, to prevent attacker from modifying your software to log entered passphrase.
Secure boot allows to build a verifiable chain of software (UEFI -> Bootloader -> Kernel -> Initrd) which will protect against any modification, so you can be sure that your key presses are not being logged by the malicious software. That said, commonly used Linux distros have some problems protecting initrd, but that's issue of those distros.
Another link is TPM. I set up my system in a way to keep encryption key in TPM and release it only when secure boot is enabled. This allows to decrypt root automatically, without entering passphrase and my configuration only allows to boot UKI kernel signed with my key. It trades security with convenience, of course (because now attacker, who stolen my computer, only has to break through gdm or perform other ways of attacks like extracting RAM sticks), but for me it's acceptable.
That's like saying there is some link between putting locks on your doors and setting up booby traps because if you don't lock your doors then you need to set up booby traps to prevent a thief from stealing your stuff. They're both trying to mitigate the same threat, but there is no connection between the 40 pounds of explosives I have wired to my front door and an intricate metal cylinder that can only be manipulated by another piece of metal in a specific shape.
Personally, I do both secure boot and encryption.
No, it’s like saying there is a link between putting locks on your door and making sure the lock can’t be replaced with one that takes someone else’s key, or worse one that copies the key that’s put into it. The threat models directly overlap.
That's a good analogy to point out the weakness behind relying on encryption without secure boot but without going into the mechanism behind "making sure the lock can’t be replaced" people might incorrectly think "they're both about setting up locks and therefore they are linked" whereas "making sure the lock can’t be replaced" involves securing the environment that the lock is placed in, like "Make sure your hinges are not exposed so the door cannot be taken off its hinges from the outside and replaced with a seemingly identical door."
I think it’s primarily to avoid someone just putting your SSD into any other computer and access all files. Anything more is probably not a realistic threat to most people.
Secure Boot does nothing whatsoever to prevent that. Disk Encryption has got nothing to do with Secure Boot.
for most people that is an irrelevant threat model. people can steal my laptop, but if they don't know my passport they can't access my data. end of story. they would have to break into my laptop without stealing it to install any kind of tool that can read the password. how/when is that going to happen ever without you knowing it? you would have to be working on highly sensitive, and sought after stuff for someone to try that.
Unless you're using a SED, your EFI system partition is unencrypted. It would be trivial to build a malicious copy of popular open source UEFI bootloaders (grub, refind, zfsbootmenu, etc), and a bootable USB stick that scans your EFI system partition, replacing your unencrypted bootloader with a malicious one. This attack could then be applied by relatively unskilled people in a couple minutes ("boot this flash drive, wait until the screen says "done", power it off"). I hope your laptop is never out of your possession for more than a couple of minutes! (For example, the TSA at the airport, geek squad or other repair centers, or classically an evil maid).
Secure boot doesn't encrypt, secure boot only signs.
But it's very much a part of boot verification to unlock a TPM with your encryption keys on it.
You're conflating secure boot with measured/verified boot.
They don't work in tandem? I enable secureboot with sbctl(securebootctl) and enroll keys in a TPM using the same tool as far as I can remember.
Or is this just some technical detail that in practice is under the same tools and settings?
By default, the secure boot status is part of the TPM registers that are used to unseal the encryption key for your drive. That's because if you disable secure boot, or reconfigure it with different keys, any bootloader could just replay measurements from a normal Linux system to the TPM and unlock your drive.
If you want, you can pick a different set of registers to use. The Arch wiki has a bunch of them: https://wiki.archlinux.org/title/Trusted_Platform_Module#Acc...
Calling systemd-cryptenroll with --tpm2-pcrs would allow you to manually pick a set of options. I believe Bitlocker uses 0, 2, 7, and 11 (11 being an OS specific register rather than a spec-defined one), which is why firmware updates often make you re-enter your Bitlocker key. Some people choose to only record the secure boot state, relying on the firmware to validate its own updates and config, which means you don't need your recovery key after firmware updates as long as the secure boot state remains the same.
Not taking secure boot state into account makes the entire setup rather easy to bypass, but you could do it to make your setup harder to break while still protecting against the "thief steals my SSD but not my laptop" scenario.
In addition to the great answer by jeroenhd, you also might have encrypted your secure boot signing keys with your TPM. This has the advantage that your signing keys can't be stolen so you know that your bootloader was signed on your specific physical machine. But this is not necessary, you can just store your signing keys on your SSD or anywhere/anyway you want.
Every single time when this concern is being raise, people get called "conspiracy theorist" and get "flagged" or muted, aka censored
Fast forward today, yall are getting fucked deep in the ass
Fuck Microsoft
[dead]
Secure boot is so evil.
No it's not. Secure boot without user control is evil. UEFI generally allows user control. Of course a vendor can make an UEFI system that doesn't allow user keys… don't buy that.