Live data from Hacker News

Linux and Secure Boot certificate expiration

lwn.net

211–220 of 272 posts

Re: Linux and Secure Boot certificate expiration

#211

Earlier quoted context omitted.

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.

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?

What is the something we can do?

Re: Linux and Secure Boot certificate expiration

#212

Earlier quoted context omitted.

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

Re: Linux and Secure Boot certificate expiration

#215
post #200

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.

Libre operating systems are coded to run on machines that conform to Microsoft's hardware standards and conformance tests (Windows HLK) that define Windows compatible hardware. Linux is shimming its way into Windows' boot process, not the other way around, even on machines sold with Linux from the manufacturer.

If you want to be clean on "a moral basis", whatever that means, the FSF would have to create their own hardware standard and persuade OEMs to adhere to it. Good luck.

Re: Linux and Secure Boot certificate expiration

#216

Earlier quoted context omitted.

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…

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

Re: Linux and Secure Boot certificate expiration

#217

Earlier quoted context omitted.

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

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

for most people that is an irrelevant threat model. people can steal my laptop, but if they don't know my passport they can't access my data. end of story. they would have to break into my laptop without stealing it to install any kind of tool that can read the password. how/when is that going to happen ever without you knowing it? you would have to be working on highly sensitive, and sought after stuff for someone to try that.

Re: Linux and Secure Boot certificate expiration

#219
post #12

It's not just Linux - certificates to sign Windows are also affected in 2026. 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 b…

Disaster recovery planning must be fun - 'take a fresh machine from store A, and use the Windows CDs stored in box B, and....'

Re: Linux and Secure Boot certificate expiration

#220

Earlier quoted context omitted.

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…

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.

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.

Post reply on HN