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.
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?".
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.
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.
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.
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'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 :)
> 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
Is Microsoft REALLY cares about security, they should fix their bugs and not make "new features" at every release.
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.
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?
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.
> 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.
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.
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.
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?
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.
"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.
Readit News
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.
Code signing certificates are trending down in length. Ot recently dropped down from a max of 39 months to about 15 months.
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?".
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.
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.
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).
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.
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.
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 :)
Is Microsoft REALLY cares about security, they should fix their bugs and not make "new features" at every release.
Especially when most relevant attacks occur in the scenario where attacker has control over the system clock.
It certainly wouldn't be the first evidence of that…
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.
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.
Fine for systems you physically manage, anything remote in a datacenter I wouldn't bother (without external motivation)
Still on Windows only for kids games. Linux user since last millennium.
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.
[0] https://github.com/Foxboron/sbctl
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.
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.
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).
Windows 10 and then 11
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...
“Just” is doing a lot of heavy lifting in that solution.
https://wiki.archlinux.org/title/Unified_Extensible_Firmware...