Event details
MicrosoftTwo of the certificates are used to sign security updates in Windows:
- KEK - signed DBX (and DB) updates to block vulnerable and malicious boot loaders (and other firmware utilities)
- PCA2023(Windows UEFI CA 2023) - signs Windows boot loader updates - mainly security fixes.
Not having the updated KEK prevents security updates that block boot loaders. Not having the PCA2023, means not getting boot manager updates.
The third-party certificates (Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023) means that updates to third party software will be blocked - this could be things like 3rd party disk encryption, firmware utilities, and firmware drivers for things like plug in video cards.
The certificates establish what should be trusted by the firmware. The certificates in turn sign firmware/software that the firmware needs to validate.
Thank you.
So, to be clear, I think we on these systems we do have PCA2023 - can you confirm that is correct if I provide the list of Event ID's that I believe verifies that statement? Here they are (this is from the Dell T5610):
ID 1036: Secure Boot Db update applied successfully
ID 1044: Secure Boot DB update to install Microsoft Option ROM UEFI CA 2023 certificate applied successfully
ID 1045: Secure Boot DB update to install Microsoft UEFI CA 2023 certificate applied successfully
ID 1799: Boot Manager signed with Windows UEFI CA 2023 was installed successfully
If that is correct, and we have PCA2023, but not KEK, can you provide a rough estimation of how often fixes/updates are made to Secure Boot and a rough idea of how many of those fixes we would and would not get?
For example, you could say "In the last 5 years, we have pushed 25 updates to Secure Boot to address security issues. 5 of those 25 updates have been to block (non-Windows?) bootloaders, requiring the KEK. The other 20 updates have been Windows boot loader updates, which do not require the KEK."
I clearly have no idea about the correct numbers there, or even if my statements about how they apply are correct, I'm just trying to get a gauge of how big a hole we're leaving in our security measures by only getting Secure Boot partially updated.
Looking through
https://github.com/microsoft/secureboot_objects/blob/main/PostSignedObjects/KEK/kek_update_map.json , there have been 431 DBX updates for x64 (alongside to 93 on ia32, 26 on aarch24 and 110 on arm).
Of these 431, they roughly split by vendor of the "vulnerable" boot loader:
- 173 Microsoft
- 39 SecureStar
- 33 SUSE Linux
- 33 Unknown
- 18 Intel Corporation
- 14 DT Research Inc 14
- 13 Canonical Ltd
- 22 Red Hat
- 9 Oracle Corporation
- 77 (Other)
Of the 141 ones that have a description mentioning a CVE, they mention a total of 21 different CVEs. But 240 don't have a CVE in the description at all.
Also, the current SVN is at 7, so there have been at least 6 "classes" of Microsoft bootloaders that had vulnerabilities and therefore were locked via SVN without requiring to add them as hash to DBX. Note that the SVNs also live in DBX, so they cannot be updated without a KEK either.
Note that when there has been a CVE on a Microsoft bootloader affecting either Secure Boot or TPM, that often resulted in a whole "generation" of Microsoft bootloaders being blacklisted via DBX. (Issuing a fixed version signed by DB is only half of the problem, assuming an attacker got Admin privileges, they might "roll back" the boot loader to a previous version otherwise). On the other hand, there are multiple bootloaders in use at the same time across different products, SKUs, and beta/insider versions. Since all of them need to be blacklisted, one CVE resulted in blacklisting more of them.
In the time since 2011, I recall at least three events of a CVE in a non-Microsoft bootloader that got publicly exploited (and included into "exploit kits" for script kiddies) where the mentioned bootloader could be tricked into loading any other bootloader with Secure Boot signature check disabled (which is in my opinion the worst case of a Secure Boot vulnerability) in 100% of the attempts, just by dropping that bootloader, a config file, and the unsigned other bootloader on the EFI system partition.
Most severe known vulnerabilities in Microsoft bootloaders were TPM or memory clearing bugs that could be used to leak the Bitlocker recovery key from a volume encrypted solely with TPM PCRs 7 and 11. Those vulnerabilities were often race conditions, meaning that you needed multiple attempts (of cold boot) to get them reliably exploited.
Other fixes in the bootloader that were not security relevant were only rarely known. For most cases, taking the bootloader from Windows 8 RTM will still successfully boot a Windows 11 machine today. I recall being fixes for booting from devices with native 4K sectors (which were common at a time when some Windows versions could not read devices larger than 4 billion sectors which is about 2 terabytes when you use 512b sectors and 8 terabytes when you use 4K sectors), and a fix for some scenarios when booting natively from a VHD snapshot (via Boot2VHD). Apart from that, there might have been other non-security fixes, but they went mostly below the radar I would say.
After 2 weeks of work and 2 full days specifically fighting with Copilot/ChatGPT/Claude (Claude was finally able to get the final issue sorted), I was able to generate DB/KEK/PK .auth files that successfully loaded in BIOS/UEFI (and after some more work, allowed Windows to boot) on a Dell T5810. And it now reports event ID 1808 (This device has updated Secure Boot CA/keys. UpdateType: Windows UEFI CA 2023 (DB), Option ROM CA 2023 (DB), 3P UEFI CA 2023 (DB), KEK 2023, Boot Manager (2023)).
My next question - why does it have to be this hard? According to both Claude and Copilot, these .auth files should work on pretty much any system, so why did I have to spend all this time generating them? Couldn't MS take 10 minutes (what took me 2 weeks would probably take MS 10 min) and post them somewhere for easy download, so any admin could easily apply them thru UEFI? Without the KEK private key (which presumably would not be posted for the public) would what I suggested somehow be less secure than allowing older systems to go completely without Secure Boot updates?
First of all, congratulations. Not for fighting of course, but for succeeding in your endeavor.
The main obstacle of providing a bundle of auth files is that most firmware requires vendor specific certificates in their .DB database. In some cases, when those are missing, you can never get into your UEFI firmware setup again to fix it or turn off Secure Boot, so you have effectively "soft-bricked" your system. Or your on-board GPU no longer initializes so you only get a display when you add a dedicated GPU, which is also kind of "bricked". Those certificates can obviously not be provided by Microsoft, since they do not have them for all vendors.
So, Did you need to add any certificates besides from the Microsoft ones to your DB? If no, and you can still enter the firmware setup, consider yourself lucky (or thank Dell for thinking about this scenario). If yes, that is why Microsoft cannot provide those .auth files for everybody.
Second reason why Microsoft is not attempting to do that (probably) is that it makes them more liable to mistakes users do while trying to apply them - especially since every vendor's settings look somewhat different. And they would have to suppor that. I guess it is likely some hobbyist (thinking about Pete Batard who is the author of Rufus and some UEFI drivers and definitely has more experience with UEFI and Secure Boot than me) might provide tooling for that once the deadline approaches or has passed, but probably they don't want to take that kind of liability either.
Third, there have been cases where applying a firmware update on a system with custom certificates installed also soft-bricked the machine. Not a problem for you, since there are no firmware updates for your machines any more, and if there were, you would probably think about resetting the certificates before you try them. But this might be a liability that would also deter Microsoft or others from providing a semi-automated solution for this.
- Arden_White
Sorry, there's no predicting the number of security issues that will be addressed. There's also no way to predict the severity of the security issues that are fixed.
I was able to add the same AUTH files (containing the 2023 certs) to the z840 without much issue (had to use KeyTool.efi though).
Unfortunately, I receive 1802 errors ("The Secure Boot update Option ROM CA 2023 (DB) was blocked due to a known firmware issue on the device."). I assume that is just related to the z840 and other machines of that era no longer receiving BIOS updates (stuck with old DB/KEK/PK) and therefore being blacklisted, as noted here:
https://support.microsoft.com/en-us/topic/understanding-secure-boot-events-1802-and-1803-29a045f3-54bd-464b-bd16-d5989f82885d
"KI_7, KI_8, KI_9: HP Firmware
This HP device has a known compatibility problem during Secure Boot updates."
Arden_White - will it be possible to force-bypass this blacklisting on these devices through a registry edit, or similar?
Regardless, I did get event 1034 (Secure Boot Dbx update applied successfully), so I'm wondering if even if MS does not allow me to force the update process to go any further, will I at least continue to get DBX updates (even after the 2011 certs expire) on this machine, or am I only receiving them now because the 2011 certs are still valid?
I would assume that if the error talks about a compatibility problem, there is actually one, and not just the fact that it went out of support. A likely cause could be a size limit of the individual UEFI variables (PK, KEK, DB), and all the new certificates combined are too large to fit.
You can always take "C:\windows\system32\SecureBootUpdates\DBUpdateOROM2023.bin", copy it to ESP or a USB key and apply it using keytool.efi (rename it .auth, then Edit Variable, DB, Append, Select the file, Done). I would assume you would receive an error message. In theory, it should also be possible to take the file as SignedFilePath to Update-SecureBootUEFI powershell cmdlet (the EFI_TIME value is at the very beginning of the file and is 2010-03-06 19:17:21), but I could not get this to work on a test machine while keytool.efi works fine.
Or redo your DB auth bundle and include that certificate. (You might remove the old certificates once the bootloader has been updated to make space if needed).
In any case, not having the Option ROM is not a problem at all (unless you want to upgrade your hardware with new peripherals that would need it), so you can just remove that bit from AvailableUpdates flag and consider it donw.
I certainly understand that you cannot predict anything regarding severity or total number of issues that will occur in the future. I'm asking about the past though - are you able to answer my question as regards recent history?
"past performance is not indicative of future results"; of course. I'm just trying to get a gauge. At this point I have no idea what kind of fixes have been applied specifically to Secure Boot in the past, and while I suppose I could spend a few months searching thru CVE's to try to figure it out, hopefully you could provide a rough idea of recent history without any digging.- Arden_White
If you have the latest updates on a device with Secure Boot enabled, you can see the history by running the following PowerShell command as an Administrator:
Get-SecureBootUEFI -Name dbx -Decoded
There are dates included.
