Linux and Secure Boot certificate expiration

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.

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

And what is the purpose of expiration in this case?

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

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.

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

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.

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.

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.

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.

Infosec engineers hate this one trick!

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

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

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