Live data from Hacker News

Linux and Secure Boot certificate expiration

lwn.net

221–230 of 272 posts

Re: Linux and Secure Boot certificate expiration

#221

Earlier quoted context omitted.

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

The real myth here is that the BIOS did nothing more than load 512 bytes and start executing. It was already doing tons of stuff to configure hardware and provide information to OSs well before UEFI came along.

Re: Linux and Secure Boot certificate expiration

#222

Earlier quoted context omitted.

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.

Secure Boot is the computing antichrist, and Linux folk were 100% right to rally against it. As well as a whole bunch of other "Trusted Computing" garbage.

Yeah, it opened up the door for us not owning not even our phones anymore, and soon even the browser itself.

Re: Linux and Secure Boot certificate expiration

#223
It's not just secure boot. Modern OS have certificates all over the place. These are ticking self-destruct time bombs in those machines that the manufacturers of hardware based on these OS may not necessarily realize. I am thinking ATM machines, voting machines, medical equipment, smart-fridges and other IOT, probably many cars, etc.

Re: Linux and Secure Boot certificate expiration

#224
post #216

Earlier quoted context omitted.

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.

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.

Re: Linux and Secure Boot certificate expiration

#225

Earlier quoted context omitted.

Not to mention that firmware updates are often necessary for things like supporting new CPUs. Immutable firmware means that your system can never improve or expand to support new hardware, and I would hate to have to buy a new motherboard to support a new CPU.

You shouldn't need new improved proprietary software to support new hardware, that's just wrong. They're just bundling free apps into hardware at that point. "New CPU needs a new software" shouldn't be an excuse to just let CPUs becoming its own computer with the real CPU you're paying for as one of many features. That's just fundamentally wrong.

That is reality though. It happens all the time.

Modern computers are distributed systems of components. Each component has its own cpu and OS running in firmware. And they talk over the system bus.

Re: Linux and Secure Boot certificate expiration

#226
post #223

It's not just secure boot. Modern OS have certificates all over the place. These are ticking self-destruct time bombs in those machines that the manufacturers of hardware based on these OS may not necessarily realize. I am thinking ATM machines, voting machines, medical equipment, smart-fridges and other IOT, probably many cars, etc.

Oh, they realize it just fine. To them it is just another source of revenue. Planned obsolescence is going to wipe out our digital heritage at some point.

Re: Linux and Secure Boot certificate expiration

#227
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 har…

This is only the case because we let it be the case. Microsoft should have had zero influence on this. Consumer protection laws have utterly failed us.

Re: Linux and Secure Boot certificate expiration

#228
post #216

Earlier quoted context omitted.

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.

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.

Re: Linux and Secure Boot certificate expiration

#229

Earlier quoted context omitted.

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.

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

Infosec engineers hate this one trick!

Re: Linux and Secure Boot certificate expiration

#230

Earlier quoted context omitted.

You shouldn't need new improved proprietary software to support new hardware, that's just wrong. They're just bundling free apps into hardware at that point. "New CPU needs a new software" shouldn't be an excuse to just let CPUs becoming its own computer with the real CPU you're paying for as one of many features. That's just fundamentally wrong.

That is reality though. It happens all the time. Modern computers are distributed systems of components. Each component has its own cpu and OS running in firmware. And they talk over the system bus.

it seems like you are talking about hardware controllers, vs CPUs.
Post reply on HN