Live data from Hacker News

Linux and Secure Boot certificate expiration

lwn.net

181–190 of 272 posts

Re: Linux and Secure Boot certificate expiration

#181

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…

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.

Re: Linux and Secure Boot certificate expiration

#182
post #156

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.

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.

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.

Re: Linux and Secure Boot certificate expiration

#183

Earlier quoted context omitted.

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.

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.

[deleted]

Re: Linux and Secure Boot certificate expiration

#184

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…

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.

Re: Linux and Secure Boot certificate expiration

#186
post #156

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.

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.

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

Re: Linux and Secure Boot certificate expiration

#187
post #180

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

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

Re: Linux and Secure Boot certificate expiration

#188

Earlier quoted context omitted.

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…

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

No, it’s like saying there is a link between putting locks on your door and making sure the lock can’t be replaced with one that takes someone else’s key, or worse one that copies the key that’s put into it. The threat models directly overlap.

Re: Linux and Secure Boot certificate expiration

#189
post #163

Earlier quoted context omitted.

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

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

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

Re: Linux and Secure Boot certificate expiration

#190
post #180

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

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.

And what is the purpose of expiration in this case?
Post reply on HN