Linux and Secure Boot certificate expiration

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.

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…

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.

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).

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.

It's just a default. You can override it with your own platform key.

But you can turn it off or en-roll your own keys.

[dead]

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.

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.

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)

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.

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 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.

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.

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 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.

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.

> 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.

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...

it is

mokutil

Check its various options

The 'Validity' field in the output will tell you the expiration date.

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.