Linux and Secure Boot certificate expiration

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.

No, the real mistake was putting the root of trust anywhere else than the user.

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)

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.

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

Being cynic, there was the expectation that computers would get replaced before the certification expiration date.

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.

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.

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.

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

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

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.

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.

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.

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.

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

Oh it's skippable all right. Just pull the cmos battery and wait a few seconds before putting it back in.

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

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?!)

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

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.

As a Linux-only gamer since 2019 I wonder what kids games you are talking about?

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

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?

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

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?

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.

you literally have though. you can self sign everything and set up uefi to only boot your signature

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

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

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

SB does not protect against backdoored firmware at all. You would need something like BootGuard which is a separate feature.

> Planned obsolescence is going to wipe out our digital heritage at some point.

I presume words like "Crowdstrike" or "Microsoft Update" don't say anything to you. /s

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

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

And next to those you can load your custom keys?

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:|^[^ ])'

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.

But it's very much a part of boot verification to unlock a TPM with your encryption keys on it.