News Microsoft signing key required for Secure Boot UEFI bootloader expires in September, which could be problematic for Linux users

Toggle sidebar Toggle sidebar
Where is this September expiration date coming from? The Microsoft UEFI CA 2011 certificate doesn't expire until June 2026.

This really should be an easy transition. All Microsoft needs to do is use their KEK to sign a command to update Secure Boot with the new 2023 DB certificate. Yes, their 2011 KEK will expire in 2026 too, but we won't have to worry about this again until 2037. A firmware update is not needed to install the 2023 DB certificate -- only the 2023 KEK certificate.
 
  • Like
Reactions: iLoveThe80s_90s
jackt said:
when win10 ends ? maybe ms hopes to prevent the migration to Linux, with some confusion ? making it harder to install linux ? they will release a new key with a little delay ? lol they are pathetic 😆
Click to expand...
To be honest that was my first thought too. I do think these signing keys were done up like 10 or 15 years ago though.

I will point out, the root certificate authorities for secure boot are Microsoft (for booting Windows again) and Microsoft again (a seperate root authority for signing 'other' things than Windows.) This isn't some industry spec, it's spec'ed by Microsoft and was implemented by vendors because they made it mandatory for 'designed for Windows 8' computers.

I'll note (besides the stated security reasons for Secure Boot), it was also originally a ploy by Microsoft to prevent installing other OSes on the PC you own. They originally did not have that second certificate authority, no plans to sign bootloaders etc. as they do now, and being able to go into setup and add keys was optional (and in reality the expectation was that systems would probably just 'neglect' to implement this). See the original Surface RT (from around 2012)... you could run Windows RT and only Windows RT on it because of SecureBoot being implemented to Microsoft's original specifications. Someone actually just sorted out a way to get a better OS on these within the last couple years -- the Nintendo Switch and the Surface both use Nvidia Tegra ARM CPUs and some Switch exploit turned out to work on the Surface.
 
  • Like
Reactions: lemongrassgarlic, phenomiix6, jackt and 1 other person
remixedcat said:
Will disabling secure boot prevent any OSes already installed from booting?? Would i have to reinstall?? I got music production software that would not play nicely with reinstall due to licenses.
Click to expand...
FUD, fear, uncertainty and doubt, one of the most powerful weapons in the M$ arsenal...

But that's also the reason M$ insists on TPMs, and using BitLocker on normal Windows 11 installs, to complete the dependence, which doesn't need to exist.

Disabling secure boot on a Windows system that doesn't use BitLocker doesn't prevent Windows being able to boot, unless it doesn't want to. In any case you should be able to disable secure boot in the BIOS, and simply test it... unless disabling secure boot were to involve deleting a stored master key to access your data, you can always just re-enable it.

Of course there is no telling if there are programmed nasties and I suggest you don't try that on a managed corporate laptop.

I avoid using media encryption, especially TPM based, because all my Windows machines are dual or triple boot, I often move or copy my media including operating systems between machines (including VMs) and because I like the ability to operate on file systems and media across operating systems, e.g. NTFS on Linux.

Secure boot in my understanding mostly prevents UEFI booting off files or media that's not cryptographically signed and that's why enabling secure boot may make Linux or older Windows installations inaccessible. Disabling it shouldn't be destructive, just cause a dependency when a media encryption key won't be made available without it.

But since I've worked hard to avoid it for many years, I can't give you certainty. I only know that in my installations, there is no functional difference between enabling and disabling it at any moment (just did a BIOS update yesterday, which always tends to reset it to 'secure').

But my Windows 11 IoT LTSC also runs with all TPMs disabled in the BIOS before installation as well as a setting to disable BitLocker installation from the start.

Before I had my IoT LTSC variant all figured out, I was able to remove BitLocker from a system, where Microsoft had managed to sneak in this new default: you just need to do that before you disable the TPU, swap the CPU or do other 'harm' to the security of your PC.
 
  • Like
Reactions: phenomiix6
abufrejoval said:
FUD, fear, uncertainty and doubt, one of the most powerful weapons in the M$ arsenal...

But that's also the reason M$ insists on TPMs, and using BitLocker on normal Windows 11 installs, to complete the dependence, which doesn't need to exist.

Disabling secure boot on a Windows system that doesn't use BitLocker doesn't prevent Windows being able to boot, unless it doesn't want to. In any case you should be able to disable secure boot in the BIOS, and simply test it... unless disabling secure boot were to involve deleting a stored master key to access your data, you can always just re-enable it.

Of course there is no telling if there are programmed nasties and I suggest you don't try that on a managed corporate laptop.

I avoid using media encryption, especially TPM based, because all my Windows machines are dual or triple boot, I often move or copy my media including operating systems between machines (including VMs) and because I like the ability to operate on file systems and media across operating systems, e.g. NTFS on Linux.

Secure boot in my understanding mostly prevents UEFI booting off files or media that's not cryptographically signed and that's why enabling secure boot may make Linux or older Windows installations inaccessible. Disabling it shouldn't be destructive, just cause a dependency when a media encryption key won't be made available without it.

But since I've worked hard to avoid it for many years, I can't give you certainty. I only know that in my installations, there is no functional difference between enabling and disabling it at any moment (just did a BIOS update yesterday, which always tends to reset it to 'secure').

But my Windows 11 IoT LTSC also runs with all TPMs disabled in the BIOS before installation as well as a setting to disable BitLocker installation from the start.

Before I had my IoT LTSC variant all figured out, I was able to remove BitLocker from a system, where Microsoft had managed to sneak in this new default: you just need to do that before you disable the TPU, swap the CPU or do other 'harm' to the security of your PC.
Click to expand...
I have dual boot windows 11 and mint Linux on most of my laptops.. and i installed Linux while secure boot was enabled.

But really I need an answer that's not fluff or fud...

Will any systems that are actively on secure boot have any issues with me turning it off and would doing so prevent windows or Linux from booting?
 
  • Like
Reactions: phenomiix6
remixedcat said:
I have dual boot windows 11 and mint Linux on most of my laptops.. and i installed Linux while secure boot was enabled.

But really I need an answer that's not fluff or fud...

Will any systems that are actively on secure boot have any issues with me turning it off and would doing so prevent windows or Linux from booting?
Click to expand...
Give it a try then.

Need to have prepared for a catastrophic failure via backup and restore anyway, right?

Hope that doesn't sound too fluffy 😉

P.S. I get paid for reliable answers based on careful experimentation.
 
  • Like
Reactions: phenomiix6
remixedcat said:
I have dual boot windows 11 and mint Linux on most of my laptops.. and i installed Linux while secure boot was enabled.

But really I need an answer that's not fluff or fud...

Will any systems that are actively on secure boot have any issues with me turning it off and would doing so prevent windows or Linux from booting?
Click to expand...
Are you using BitLocker or LUKS +TPM?

If Yes, then changing the state of Secure Boot will change TPM PCR 1. This will cause BitLocker to go into recovery mode. LUKS will throw some sort of error at you and refuse to unlock (my experience with LUKS is limited). You should disable BitLocker or LUKS+TPM prior to toggling Secure Boot. You can also do a suspend in BitLocker that should cause Windows to update the TPM PCR 1 value on next boot.

If No, then go ahead and toggle Secure Boot on and off all you want. Some security software and EDRs might notice the change, but they shouldn't do more than warn you that Secure Boot has changed state and TPM PCR 1 is different -- they shouldn't try to stop booting or using the device.

If you're running an OS that is still in active support, then you may have already received a copy of the Microsoft 2023 cert to add to the Secure Boot DB. There's a check script for Windows PowerShell located at https://github.com/cjee21/Check-UEFISecureBootVariables?tab=readme-ov-file that can help list what certificates are installed. If you have a modern device that gets firmware updates, then it's also possible you have the 2023 KEK certificate too. The DB cert is more important since the DB and DBX values are what do all the allowing and denying at boot time.
 
  • Like
Reactions: Grobe, phenomiix6 and abufrejoval
In a quick search it would seem the issue for Linux is that firmware updates for some OEMs is not available.
As Secure Boot checks hardware as well as drivers.

The driver signing key is not the issue but the hardware signing key.
Most distributions have sorted out driver signing. However, if your firmware of the PC is not up-to-date they may have outdated keys and thus fail the security check.
Solution update your firmware in Windows. (Most likely because you manufacturer does not have a method or to update directly in Windows.
So if you're having problems with secure boot then it will be even worse with windows as you won't be even to disable secure boot to update your drivers.

So make sure that all your computers firmware is up to date.

This will help to eliminate any problems in September.

But this is not just a Linux issue this will affect Windows users as well if they haven't updated the firmware.
 
  • Like
Reactions: phenomiix6
I'm pretty skeptical of this article's claim that you need a firmware update (UEFI/BIOS update) to address this. You should be able to just enroll the new certs/keys yourself through the UEFI interface. You could, presumably, instead create a (temporary) Windows install and run the steps here: https://techcommunity.microsoft.com...g/updating-microsoft-secure-boot-keys/4055324

I admit I have not tried this myself, but I did do something similar back when I ran a more esoteric version of Linux. It didn't work out of the box with secure boot (the way Ubuntu, etc., do), but all I had to do is enroll the bootloader via the UEFI and I was good to go.

Edit: Ended up enrolling the new MS 2023 KEK just to try it out. Was pretty quick and easy; admittedly I don't really know how to test it, but it seemed to have work just fine. Used the cert listed in section 1.5 here https://learn.microsoft.com/en-us/w...ation-and-management-guidance?view=windows-11
 
Last edited:
Yes be careful just disabling Secure Boot -- if you have Bitlocker, disabling the Secure Boot DOES erase the security keys and Bitlocker will be toast next time you try to boot into Windows. (Want a recovery key etc.) If you experiment with Secure Boot I would turn off Bitlocker first.

I disabled Secure Boot in preparation for getting Windows off a Surface (Surface 5 Pro, like the 2017 model) and putting Ubuntu on it -- the Windows install was thoroughly trashed anyway (screen rotation was locked upside down, and it took forever to boot and shut down because it kept trying to install the same set of updates and failing, and ran incredibly slowly -- this was my sisters machine so I have no idea what she did to it.) But indeed, I found it then wouldn't boot, re-enabled Secure Boot and still no boot due to Bitlocker keys being wiped. So the Windows install went from thoroughly trashed to totally non-functional. I could have installed Ubuntu with Secure Boot on but I decided not to.
 
  • Like
Reactions: abufrejoval and phenomiix6
hwertz said:
Yes be careful just disabling Secure Boot -- if you have Bitlocker, disabling the Secure Boot DOES erase the security keys and Bitlocker will be toast next time you try to boot into Windows. (Want a recovery key etc.) If you experiment with Secure Boot I would turn off Bitlocker first.

I disabled Secure Boot in preparation for getting Windows off a Surface (Surface 5 Pro, like the 2017 model) and putting Ubuntu on it -- the Windows install was thoroughly trashed anyway (screen rotation was locked upside down, and it took forever to boot and shut down because it kept trying to install the same set of updates and failing, and ran incredibly slowly -- this was my sisters machine so I have no idea what she did to it.) But indeed, I found it then wouldn't boot, re-enabled Secure Boot and still no boot due to Bitlocker keys being wiped. So the Windows install went from thoroughly trashed to totally non-functional. I could have installed Ubuntu with Secure Boot on but I decided not to.
Click to expand...
This highlights, why the M$ trash talk about enhancing your system's security with TPM and Bitlocker is just that: trash increasing the probability of loosing your data to hardware and software failures, but also your own mistakes.

If you own or operate a computer with secret data that isn't always under your physical control, you may have little choice, if only because M$ also sits in committees that design security standards and compliance criteria. That's why most corporate laptops enforce this.

But most users or those who help them with their PCs are probably still better off not using BitLocker but a container like VeraCrypt for sensitve data. More inconvenient during daily use, but a lot more convenient when you can recover storage from a broken or damaged computer.

TPM vulnerabilities which compromise the keys are being discovered all the time, and then Pluton based TPMs are practically guaranteed to contain backdoors, enforced by the US government.

And once those backdoors are discovered or leaked, that security is toast. There is a reason greater nation states like China even invent their own cryptography algorithms.

So if you have a choice, I'd recommend disabling what you cannot control and you practice and test on your backup and recovery procedures when you can't avoid TPM and Bitlocker: you can use a VM for that, no need to play with the real thing until you've gained practice: snapshots are your friend!
 
  • Like
Reactions: Grobe
hwertz said:
To be honest that was my first thought too. I do think these signing keys were done up like 10 or 15 years ago though.

I will point out, the root certificate authorities for secure boot are Microsoft (for booting Windows again) and Microsoft again (a seperate root authority for signing 'other' things than Windows.) This isn't some industry spec, it's spec'ed by Microsoft and was implemented by vendors because they made it mandatory for 'designed for Windows 8' computers.

I'll note (besides the stated security reasons for Secure Boot), it was also originally a ploy by Microsoft to prevent installing other OSes on the PC you own. They originally did not have that second certificate authority, no plans to sign bootloaders etc. as they do now, and being able to go into setup and add keys was optional (and in reality the expectation was that systems would probably just 'neglect' to implement this). See the original Surface RT (from around 2012)... you could run Windows RT and only Windows RT on it because of SecureBoot being implemented to Microsoft's original specifications. Someone actually just sorted out a way to get a better OS on these within the last couple years -- the Nintendo Switch and the Surface both use Nvidia Tegra ARM CPUs and some Switch exploit turned out to work on the Surface.
Click to expand...
Surface RT is a tablet, having a super locked down FW that makes it difficult/impossible to install non-stock OS seems to be the norm for mobile devices in my experience. But my run of the mill x86 motherboard from 2015 has all the key management options, what makes you think it was super rare? Or maybe you're taking about pre-built PCs/laptops, in which case I have no idea but it seems plausible.

Some of your statements on Secure Boot seem a little off-base. It is part of the UEFI spec, which originated with Intel before being passed off to the UEFI Forum (comprised of a number of industry partners, including MS). It's not a pure-MS (or MS-first) thing. Also, secure boot doesn't really require a CA, as far as I know. It just makes it more convenient, because then 3rd party vendors can all get the CA to sign for them and end users only need to enroll one key (the CA's). And I don't see why there's any real requirement for support from MS to establish a new CA. You or I could start acting as a CA tomorrow, if we find anyone willing to enroll our self-signed certs as a KEK (and/or start selling hardware with our keys pre-loaded, or working with OEMs to do so, etc.).
 
Last edited:
TJ Hooker said:
Some of your statements on Secure Boot seem a little off-base. It is part of the UEFI spec, which originated with Intel before being passed off to the UEFI Forum (comprised of a number of industry partners, including MS). It's not a pure-MS (MS-first) thing. Also, secure boot doesn't really require a CA, as far as I know.
Click to expand...
I can't see how it could work without it. Secure boot relies on the ability to validate integrity of files or media via checksums signed with digital signatures: that's basic PKI crypography and requires at least one initial CA present upon boot.

Of course managing that initial CA and delegating some stuff to others can and is being done, but the fact that those initial CAs are being managed by Microsoft, doesn't just irk other nations: even the hyperscalers prefer to manage all that on their own and inject their own firmware and/or TPU designs.
TJ Hooker said:
It just makes it more convenient, because then 3rd party vendors can all get the CA to sign for them and end users only need to enroll one key (the CA's). And I don't see why there's any real requirement for support from MS to establish a new CA. You or I could start acting as a CA tomorrow, if we find anyone willing to enroll our self-signed certs as a KEK.
Click to expand...
That's my understanding, too, but without an initial root CA the firmware trusts implicitly, there is no way to validate those checksums and distinguish between secure and insecure data or code, rendering secure boot unable to do its job and at best disabled. In a worst case scenario the hardware is trash if things with key management go wrong.

And that is typically the reason vendors find it hard to resist some backdoor of their own for these edge cases 😎
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom