Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux and Secure Boot certificate expiration

lwn.net

Post reply on HN
Print view View original

91–100 of 272 posts

Re: Linux and Secure Boot certificate expiration

#91

Post by vbezhenar »

ChocolateGod wrote: post #23
mormegil wrote: post #17

Earlier quoted context omitted.

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?

Well you can tie it to TPM to store your encryption key which should only produce the key when the boot parameters match the key. This is what Windows already does but its not fully supported under Linux and somewhat insecure as you can't encrypt the initramfs (so someone can infect boot process there instead).

There are ways to solve that issue. But I think that you're correct, pinpointing the core issue with popular Linux distributions. It doesn't have to be this way, though.

1. You can sign and verify initramfs, it's supported by bootloaders.

2. You can merge kernel and initramfs into UKI and sign the whole image.

I don't know why that's not implemented.

Re: Linux and Secure Boot certificate expiration

#92

Post by fsflover »

flexagoon wrote: post #61
fsflover wrote: post #50

Earlier quoted context omitted.

Consider using Heads with TPM and Librem Key to detect possible compromise of your boot stage. It doesn't obey MS but you.

With Heads, the firmware measures itself and sends the results to the TPM. If an attacker flashes a modified firmware that simply lies about the measurement results, the entire security system will be bypassed.

This is not true:

https://forum.qubes-os.org/t/discussion-on-purism/2627/187

https://forum.qubes-os.org/t/discussion-on-purism/2627/177

Re: Linux and Secure Boot certificate expiration

#93

Post by blendergeek »

flexagoon wrote: post #66
ACCount36 wrote: post #49

Earlier quoted context omitted.

Who controls the fucking certs? "My computer was compromised with an early boot stage hypervisor backdoor" happens basically never. It's an attack vector that exists almost entirely in the minds of infosec fucktards. "My brand new device ships with vendor-selected boot certificates that can't be changed, can't be overridden, and control what software I can install onto my own device" happens with every other smartpho…

> Who controls the fucking certs? Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet? > vendor-selected boot certificates that can't be changed That's a lie. Certain drivers are signed with a specific key, and they can only be used when this key is installed, which makes sense. The same thing happens with SSL - if you remove pre-installed CA cert…

> How often are you trying to install custom drivers on a smartphone, console or car? Why would you have secure boot issues on those?

The only reason there isn't a thriving community of third party OS's on most smartphones is because secure boot prevents it. And no, users do not have the freedom and choice to disable it (except on a very few models where the manufacturer has graciously allowed users to use their own devices how they want).

Re: Linux and Secure Boot certificate expiration

#94

Post by 71bw »

repstosb wrote: post #34
blkhawk wrote: post #21

Earlier quoted context omitted.

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

There are things like Roblox that are really only usable under Windows due to a perverse idea of what "anti-cheat" should look like.

https://sober.vinegarhq.org/

Re: Linux and Secure Boot certificate expiration

#95

Post by WhyNotHugo »

sugarpimpdorsey wrote: post #16
greatgib wrote: post #3

It's totally crazy that we have to go through Microsoft to sign things to be able to have our OS run on third parties computers, and that Microsoft manage to win about this so easily as it was never seriously challenged.

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.

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.

Re: Linux and Secure Boot certificate expiration

#96

Post by A4ET8a8uTh0_v2 »

flexagoon wrote: post #66
ACCount36 wrote: post #49

Earlier quoted context omitted.

Who controls the fucking certs? "My computer was compromised with an early boot stage hypervisor backdoor" happens basically never. It's an attack vector that exists almost entirely in the minds of infosec fucktards. "My brand new device ships with vendor-selected boot certificates that can't be changed, can't be overridden, and control what software I can install onto my own device" happens with every other smartpho…

> Who controls the fucking certs? Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet? > vendor-selected boot certificates that can't be changed That's a lie. Certain drivers are signed with a specific key, and they can only be used when this key is installed, which makes sense. The same thing happens with SSL - if you remove pre-installed CA cert…

I might be misremembering it, but initial plans for Secure Boot were less open. It was only the stink raised that resulted in it being an option.

Does it matter? Is it mine? If yes, then it should my concern. But that is the entire problem with trusted computing and recent trends in general. Corps become operators, users are downgraded to consumers.

Re: Linux and Secure Boot certificate expiration

#97

Post by RedShift1 »

jeroenhd wrote: post #52
mkj wrote: 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…

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.

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.

Re: Linux and Secure Boot certificate expiration

#98

Post by account42 »

jeroenhd wrote: post #52
mkj wrote: 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…

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.

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

Re: Linux and Secure Boot certificate expiration

#99

Post by account42 »

flexagoon wrote: post #66
ACCount36 wrote: post #49

Earlier quoted context omitted.

Who controls the fucking certs? "My computer was compromised with an early boot stage hypervisor backdoor" happens basically never. It's an attack vector that exists almost entirely in the minds of infosec fucktards. "My brand new device ships with vendor-selected boot certificates that can't be changed, can't be overridden, and control what software I can install onto my own device" happens with every other smartpho…

> Who controls the fucking certs? Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet? > vendor-selected boot certificates that can't be changed That's a lie. Certain drivers are signed with a specific key, and they can only be used when this key is installed, which makes sense. The same thing happens with SSL - if you remove pre-installed CA cert…

> Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet?

Yes, the way trust is delegated in web PKI is absolutely insane as well. It should have been something more lilke DANE from the start.

Re: Linux and Secure Boot certificate expiration

#100

Post by numpad0 »

jeroenhd wrote: post #52
mkj wrote: 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…

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.

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.
Post reply on HN