[HN Gopher] Secure boot certificate rollover is real but probabl...
       ___________________________________________________________________
        
       Secure boot certificate rollover is real but probably won't hurt
       you
        
       Author : zdw
       Score  : 83 points
       Date   : 2025-07-31 17:21 UTC (5 hours ago)
        
 (HTM) web link (mjg59.dreamwidth.org)
 (TXT) w3m dump (mjg59.dreamwidth.org)
        
       | M95D wrote:
       | > [...] systems that only trust the new certificate and not the
       | old one would refuse to boot older Linux, wouldn't support old
       | graphics cards, and also wouldn't boot old versions of Windows.
       | Nobody wants that [...]
       | 
       | EVERYBODY wants that! And I mean ABSOLUTELY EVERYBODY! Updates
       | are now mandatory everywhere, in both Windows and Linux, and GPU
       | manufactureres would LOVE to make the old cards obsolete, even if
       | technically the new cards aren't much better.
       | 
       | So expect to see the old certificate invalidated quickly and
       | automatically, in the name of security, of course!
        
         | michaelt wrote:
         | Even if this did happen, there's a trivial workaround
         | available: Just go into your BIOS and switch 'Secure Boot' off.
         | 
         | Secure Boot is a fine thing if you're a huge corporation and
         | want to harden laptops against untrustworthy employees, or
         | you've got such a huge fleet of servers they go missing despite
         | your physical security controls, or you're making a TiVo style
         | product you want to harden against the device owners. But when
         | the user is the device owner? Doesn't do much.
        
           | trelane wrote:
           | > you're making a TiVo style product you want to harden
           | against the device owners.
           | 
           | This sentence just makes me so sad
        
             | observationist wrote:
             | This should be illegal, and anyone caught doing it fined
             | twice the total cost of amortized ownership per each device
             | owner over the total duration of ownership in addition to
             | completely refunding every customer.
             | 
             | Throw in jail time for decision makers. Lets make markets
             | honest with real incentives.
        
               | necovek wrote:
               | For a start, stop buying those products: vote with your
               | wallet.
               | 
               | Do you own a phone that's easily rooted? Who else does?
               | 
               | What about your WiFi routers? Internet modem? AirTags?
               | Smart home appliances?
        
           | M95D wrote:
           | You won't be able to switch it off for long. See how many
           | phones still have that option! [1]
           | 
           | In the end what matters is always money. Always.
           | 
           | What brings more money? TiVo or buyer-owned device? You think
           | 5% of technically competent potential buyers would make a
           | difference when the 95% illiterate users will just replace
           | the product no questions asked?
           | 
           | It started as a fight against piracy and half-competent users
           | that break their own systems (and the company's systems too,
           | like you said). But slowly the industry sees that there's
           | more money to be made if the same technology can provide a
           | belivable argument in right to repair and planned
           | obsolescence court cases.
           | 
           | [1] https://github.com/melontini/bootloader-unlock-wall-of-
           | shame
        
             | II2II wrote:
             | Get back to me when it actually happens, because I've been
             | hearing that line for about 15 years now and it has not
             | happened.
             | 
             | The reality is that PC's address the needs of a
             | fundamentally different market than "TiVo"s or even mobile
             | phones. While most could, and probably should, be using
             | secure boot noone seems to be eager to take away the option
             | to disable it.
        
           | supportengineer wrote:
           | I'm surprised more huge corporations don't move towards a
           | "Chromebook only" by default. Now you don't have to manage
           | _anything_. We 're all doing our work in browsers anyway.
        
             | keyringlight wrote:
             | I think at some point there will gradually be a line that
             | divides consumer type devices and Workstation with a
             | capital W type devices. If nothing else it'll encourage the
             | PC market to really decide for each use-case how much they
             | value having a huge range of laptop or pre-built
             | configurations or being able to assemble from parts.
             | There's a lot of momentum in the PC mindset, but I also
             | think a lot of people would be satisfied with less
             | 'personal' so long as they were able to identify what they
             | need and match it to capabilities of a model. 20 years ago
             | the idea of a phone/table as the personal computer for most
             | people and not a PC/laptop would be silly, yet here we are
        
             | citizenpaul wrote:
             | If you are issued a chromebook to me it signal that they
             | consider you a replaceable cog.
             | 
             | Its one of my interview questions these days. What device
             | will I be issued?
             | 
             | If its a chromebook I know that no matter what they say
             | they don't really care about the postion.
        
             | spydum wrote:
             | There are quite a few who have. Ive worked in a google
             | workspace enabled company on a chromeos device for like
             | that last 6? Years. It works 95% of the things, but that
             | last 5% can be frustrating: especially when it involves
             | interoperability with a customers system. Now multiply that
             | by 40000 employees.. that's a lot of help desk tickets.
        
           | tux3 wrote:
           | Go in the BIOS and switch it off?
           | 
           | Certainly. Just one problem: Modern consumer BIOS interfaces
           | are graphical and your GPU is off.
        
             | ThePowerOfFuet wrote:
             | That's not how it works; Secure Boot kicks in once EFI
             | hands over control.
        
               | mjg59 wrote:
               | The driver that initialises your plug-in GPU is shipped
               | in flash on the card, is signed by Microsoft, and won't
               | run unless that signature validates.
        
           | tpoacher wrote:
           | Bitlocker
        
           | mschuster91 wrote:
           | > But when the user is the device owner? Doesn't do much.
           | 
           | A decent Secure Boot implementation together with a BIOS/EFI
           | password at least makes the life of US CBP or similar thugs
           | wanting to use my devices against me much more difficult.
           | 
           | And no, that's not an imaginary threat, certainly not under
           | this administration which has come under fire multiple times
           | for first detaining and then deporting random tourists.
        
         | jimmaswell wrote:
         | I certainly do not want old graphics cards to become ewaste for
         | no good reason.
        
       | dang wrote:
       | Recent and related:
       | 
       |  _Linux and Secure Boot certificate expiration_ -
       | https://news.ycombinator.com/item?id=44601045 - July 2025 (265
       | comments)
        
       | Arnavion wrote:
       | There is also the option of enrolling your own certs and
       | resigning the bootloader and any Option ROMs you need, if you're
       | really worried / expect to actually be broken by this.
        
         | mjg59 wrote:
         | Re-signing option ROMs is not trivial (or, well, it's easy to
         | do the signing, it's not necessarily easy to flash that driver
         | back into the card)
        
           | Arnavion wrote:
           | I see. I've never had to deal with any Option ROMs myself. In
           | that case the easier option is to add their hash to db?
        
             | mjg59 wrote:
             | That's the easiest, but it's a pain if you want to switch
             | cards
        
       | NelsonMinar wrote:
       | This article notes that "nobody actually enforces these expiry
       | dates". So this is another way that secure boot is proven to be
       | nowhere as secure as it claims to be. Coupled with LogoFAIL and
       | most hardware shipping with insecure debug keys.. has Secure Boot
       | ever provided meaningful security? It sure causes all sorts of
       | practical problems.
       | 
       | https://arstechnica.com/security/2023/12/just-about-every-wi...
       | 
       | https://arstechnica.com/security/2024/07/secure-boot-is-comp...
        
         | OsrsNeedsf2P wrote:
         | Was Secure Boot supposed to increase security? I thought
         | Microsoft was using it to make it near impossible to install
         | Linux
        
           | mjg59 wrote:
           | Linux distributions have been shipping with secure boot
           | support since 2012, so if that was the goal it had already
           | failed over a decade ago.
        
           | michaelt wrote:
           | It increases security in certain circumstances. Mostly for
           | Windows users at big corporations.
           | 
           | For example, you want your users' laptop hard drives to be
           | encrypted - but also you have users who regularly forget
           | their passwords? With bitlocker their hard drive can decrypt
           | itself, so they only need to remember their windows login,
           | which you can reset remotely.
           | 
           | You give laptops to your field workers, who have full
           | physical access and would love to play video games or access
           | netflix when work puts them in a hotel over night with
           | nothing to do? With secure boot you can keep your precious
           | spreadsheets locked down, even if they're willing to boot
           | from USB sticks or swap the hard drive.
           | 
           | And perhaps most importantly, it has "secure" in the name. So
           | the corporation's IT security auditors will like to see it
           | turned on even if they have only a vague understanding of
           | what it does.
        
         | strstr wrote:
         | With the default key hierarchies, the benefit is more limited.
         | It raises the bar. Implementing known vulnerabilities takes
         | work. And not ever configuration is vulnerable to every issue.
         | And, for a lot of the vulns, the OS vendor shoves things in the
         | dbx to mitigate.
         | 
         | With custom hierarchies, it's a bit more compelling. But it's a
         | lot of work to maintain.
        
         | mjg59 wrote:
         | The rollover coincides with stronger security policies for
         | signed objects (enforcing code being read-only, that kind of
         | thing) and people with stronger security requirements can
         | remove trust in the old certificate to enforce that.
         | 
         | Code has bugs. There's any number of critical vulnerabilities
         | in Linux, Windows, MacOS that have allowed bypass of all
         | security features - does that mean all security features remain
         | security theatre?
        
         | armada651 wrote:
         | They clearly didn't want to leave a system unbootable because a
         | certificate expired. In which case you would have no
         | opportunity to update the certificate because you can't boot
         | the system anymore.
         | 
         | They could've used a time stamping service to include a signed
         | timestamp in the binary to compare the expiry date against, but
         | that still leaves the system unbootable after the time stamping
         | certificate expires in the far future.
         | 
         | Besides, a hacking group powerful enough to steal Microsoft's
         | Secure Boot private key will likely be able to steal a
         | timestamping private key from a certificate authority as well.
        
       | TacticalCoder wrote:
       | Can someone knowledgeable on the subject explain if I understand
       | the following right:                   - on a mobo the
       | motherboard provider signs the PK         - there's only one PK
       | - the PK signs one or more KEK, like "Microsoft Corporation UEFI
       | CA 2011"
       | 
       | If that understanding is correct, can I add myself the new
       | "Microsoft Corporation UEFI CA 2023" (the one that expires in
       | 2038: I think that its name) the same way I can enroll new keys
       | in the dbx? (say my own signed keys?)
       | 
       | If I add the new Microsoft key myself, shall it be as a KEK or in
       | the dbx?
       | 
       | Will motherboard manufacturer release new firmware, with the new
       | Microsoft key already signed? In that case, shall be a KEK ?
       | 
       | Basically instead of thinking, as TFA suggests: _" Let's not
       | worry about anything, everything shall be fine and keep working
       | because keys expiration date aren't enforced"_, can I pro-
       | actively enroll the new Microsoft key myself?
       | 
       | P.S: I don't drink the SecureBoot kool-aid but something has to
       | be said about having a Linux unikernel (kernel+initramfs) signed
       | and enforced by SecureBoot. And SecureBoot does at least somehow
       | work. Source: I modified on bit of my kernel and had a SecureBoot
       | error and the kernel refused to boot. You can try it for
       | yourself.
        
         | mjg59 wrote:
         | Vouched for the parent because it's a reasonable question.
         | 
         | As well as the new root certificates in db, which are used to
         | decide whether signed code will execute or not, there will be a
         | new signed Microsoft key for KEK. This isn't involved in the
         | boot process, but is required for Microsoft to be able to sign
         | further revocation updates. The article is discussing the db
         | case, and if you want to ensure things signed only with the new
         | key will boot on your system, you would want to add them to db.
         | 
         | Microsoft can sign a db update themselves (since there's a
         | valid Microsoft key in KEK and db updates need to be signed
         | with a key in KEK), but KEK updates need to be signed with PK.
         | Microsoft doesn't own PK, so adding the new KEK requires the
         | system vendor produce an update signed with their PK.
         | 
         | If you are in a position to enroll the new keys then you should
         | enroll the new db keys if you want new binaries to be
         | guaranteed to boot, and add the new KEK if you want to be able
         | to apply future Microsoft-signed dbx updates.
        
       | fennec-posix wrote:
       | yeah, that sounds about right for UEFI
        
       ___________________________________________________________________
       (page generated 2025-07-31 23:00 UTC)