Skip to content(if available)orjump to list(if available)

Linux and Secure Boot certificate expiration

LocalH

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.

null

[deleted]

Maxious

you dont have to use the shim, just follow this https://www.rodsbooks.com/efi-bootloaders/controlling-sb.htm...

londons_explore

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

AnotherGoodName

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.

Tuna-Fish

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

londons_explore

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!

amluto

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.

montroser

And what is the purpose of expiration in this case?

AnotherGoodName

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

londons_explore

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.

Tuna-Fish

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.

jacquesm

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?

jmclnx

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.

craftkiller

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.

brudgers

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

josephcsible

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.

null

[deleted]

ekianjo

do you have any source on how to do that?

marcthe12

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.

craftkiller

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.

willa_bombadier

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.

bayindirh

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.

salawat

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?

pydry

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

msgodel

Weirdly Microsoft has been one of the companies ensuring Linux remains bootable on PCs.

Sophia95

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

RecycledEle

This is yet another why I do not encrypt.

craftkiller

Secure boot has nothing to do with encryption. It is verifying crytographic signatures. The bootloader is signed, not encrypted.

vbezhenar

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.

craftkiller

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.

ahoka

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.

asmor

Secure boot doesn't encrypt, secure boot only signs.

carlhjerpe

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

craftkiller

You're conflating secure boot with measured/verified boot.