Did you manually update your Secure Boot Keys ?

Akeo said:

@starchase, just follow the steps detailled in this specific entry of the Rufus FAQ.

Someone (sorry can't recall who) also posted all these steps, with screenshots, earlier in this thread. The information is there, if you look hard enough...

EDIT: It was @Almighty1 (nice job there!) in this post. But frankly, this thread if becoming way too long, and its information so diluted that we're circling answering stuff that's already been answered or documented. This makes me a bit reluctant to want to participate in it any longer, because, IMO, once a thread becomes this large, it completely defeats its whole purpose...

Click to expand...

I think perhaps a tutorial about using Mosby is the way to go here.

I know, I'm asking you to do more work: "Nothing is so easy as the job you imagine someone else doing!" If I can be of any help, I'd be glad to.

@gunrunnerjohn, I already did that. It's the part of the Rufus FAQ I pointed to.

As evidenced by the fact that I had to spend 5 minutes looking for the screenshot guide that @Almighty1 had done because I knew it existed in the first place, it is clear to me that trying to publish a tutorial here, if that's what you have in mind, is not the way to go. And the thing is, I am pretty much already replicating the same thing in the Mosby README. So I guess what you are asking is "Can you please write a dumbed down guide to help tech illiterate people", which is not really something that I want to do, especially as I'd personally rather avoid tech illiterate people try to use Mosby in the first place if they can't really comprehend what it's all about. These folks are much better off waiting and letting Microsoft (hopefully) handle this whole thing for them... eventually.

In short, I very much assume that people who want to use Mosby:
1. Do understand what they are trying to accomplish with it and have some idea of what DB, DBX, KEK, PK, Secure Boot and Setup Mode are (because otherwise, they will have a lot of trouble just getting into Setup Mode).
2. Are tech literate enough to figure out stuff on their own in case of issues.

Which is why I consider the tech-level of the TWO EXISTING SHORT TUTORIALS I ALREADY WROTE FOR IT is more than enough, and I have not plans to write yet another tutorial (even more so as the one from @Almighty1 is quite good for people who need a bit more).

This is from VMware Workstation With Windows 11 24H2



I didn't do anything on the guest system, but it seems to be using the latest certificate! It also has the “Microsoft Corporation KEK 2K CA 2023” certificate and the “Microsoft UEFI CA 2023” certificate, which are not on my computer



Is there any explanation?

I also updated the Gigabyte BIOS, which includes an update for the secure boot keys.

Margarita said:

TI also updated the Gigabyte BIOS, which includes an update for the secure boot keys.

View attachment 146807

Click to expand...

Which does bring up an interesting question. If the BIOS update overwrites the keys, does that affect the Secure Boot that has already been configured by another means, say updated with Mosby?

gunrunnerjohn said:

If the BIOS update overwrites the keys, does that affect the Secure Boot that has already been configured by another means, say updated with Mosby?

Click to expand...

Considering that the keys reside in a dedicated area used by UEFI to store variables, and that is separate from the "BIOS" itself, if the BIOS update is properly designed, it should just add new UEFI variables and leave the existing ones alone.

This kind of stuff is quite important for corporate customers, who might have installed their own certs in the DB and would rather not see them being deleted on BIOS updates, so, because manufacturers care a lot more about corporate than regular joes like you and I, they (usually) tend to get the stuff that could irate corporate customers right.

Which means that I am pretty confident BIOS updates to add the 2023 keys should not delete other keys. But of course, I can not 100% vouch for it.

ADDON: I'll add that my guess is that the Secure Boot Database Key update is probably only about the keys that are included in the UEFI firmware itself and that are used when you pick the "restore Secure Boot keys to default" option. That option does remove everything before reinstalling the keys defined by the manufacturer, so, most likely, the manufacturer realized that they only have the 2011 certs in the source for the restoration copy, and they added the 2023 certs. They're probably not updating the Secure Boot variables at all as part of the firmware update.

Margarita said:

Is there any explanation?

Click to expand...

Easy. Because it is an integral part of the VMWare application, the VMWare UEFI firmware is updated with the application, so, of course, whatever latest features you find on current physical machines (such as UEFI firmares that do include the 2023 certs) also get pushed to your virtual machine.

In short, using current VMWare virtual machine should put you in a similar situation as if you had purchased physical PC that was released a few weeks ago: They will have the 2023 certs installed alongside the 2011 certs by default.

Akeo said:

ADDON: I'll add that my guess is that the Secure Boot Database Key update is probably only about the keys that are included in the UEFI firmware itself and that are used when you pick the "restore Secure Boot keys to default" option. That option does remove everything before reinstalling the keys defined by the manufacturer, so, most likely, the manufacturer realized that they only have the 2011 certs in the source for the restoration copy, and they added the 2023 certs. They're probably not updating the Secure Boot variables at all as part of the firmware update.

Click to expand...

Considering you know way more about this than most here, I suspect that's true. Their update notes aren't exactly clear, but what you say certainly makes sense to me. I know when I started all this I did that update before I looked at secure boot. The 2023 certs were already there.

Meanwhile I don't intend to do anything since whatever changes are required should be implemented via Windows Update.

Well i had done all of the key updates yada yada got everything into the bios was only missing the dbx one. Went out with the wife to the mall came up on a good deal for a 1 tb ssd . got home installed the ssd and tried to load a windows 10 iso file made with rufs. nothing, so i made one with out rufus and nothing. long story short i had to delete all them custom keys and go back to the org bios settings to install windows 10 . i really hope since this is a unsupported machine and the keys when installed would boot and run secure boot . That ms will just push them out via windows update .

Steve C said:

Meanwhile I don't intend to do anything since whatever changes are required should be implemented via Windows Update.

Click to expand...

I've been reading as much as I can about the secure boot keys from resources linked from these posts, and also the rather wide variance of update experiences by people here including my own. I'm wondering whether or not these Windows Updates will go so smoothly, possibly leaving huge numbers of computers that didn't get one or more of the keys added to the secure boot variables. But nobody will really know just how badly until well after the expirations since binaries already signed will still function perfectly well.

Right up until Microsoft posts a security update that needs boot files signed but can't find a valid certificate. That's when updates will be failing en-masse and the response will be simply to disable secure boot and get on with things since we aren't going to be able to figure this crap out. That's already being spoken... a lot... and by the sort of folk who used to insist it's a necessity to run SB, even for a home user, in this modern threat environment.

Steve C said:

Meanwhile I don't intend to do anything since whatever changes are required should be implemented via Windows Update.

Click to expand...

I agree, especially since HP advised not to manually update the keys but to wait for the update.

Steve C said:

Meanwhile I don't intend to do anything since whatever changes are required should be implemented via Windows Update.

Click to expand...

This is not a manual update. By running "\Microsoft\Windows\PI\Secure-Boot-Update" scheduled task, you only remind windows to check for secure boot updates. It's like clicking on "check update now" button.

Sheikh said:

This is not a manual update. By running "\Microsoft\Windows\PI\Secure-Boot-Update" scheduled task, you only remind windows to check for secure boot updates. It's like clicking on "check update now" button.

Click to expand...

Sure there is, the "manual update" is by using Mosby to update the keys.

All my systems are updated and using secure boot.

Sheikh said:

This is not a manual update. By running "\Microsoft\Windows\PI\Secure-Boot-Update" scheduled task, you only remind windows to check for secure boot updates. It's like clicking on "check update now" button.

Click to expand...

No it doesn't work that way. When you call the task, it checks the reg value for AvailableUpdates for which actions to do (push the DB or DBX certs to UEFI, overwrite the boot file). The expected reg values are pre-defined, and listed in the MS instructions.

If you have installed any Monthly Update since April 2024, all the files and functions to perform the UEFI procedure were already added. But they have remained dormant, because the current rollout plan says we're in the optional stage. Advanced users can go ahead and run the steps.

Other users can wait for MS to force Windows to update UEFI in 2026.

I suspect MS split the UEFI procedure into at least 4 steps, because they are very paranoid. Just as Mosby can do it in one pass, I've determined you can repeat the equivalent steps on a live system in one or two passes (depending on the status of KEK CA 2023). If you look up one of the now deprecated KB's for UEFI mitigations, they used to have you run a more complicated PS command to directly insert the files (pushed by February and April 2024 updates) onto the UEFI.

But that was probably unsafe to trust users not to screw up. So now we're into this lame "repeat the same process 4 times with a different AvailableUpdates setting" method.

If correctly scripted, you can arrive at one of MS's recommended vendor outcomes for the UEFI which includes 2 KEK certs, 2 DB CA 2011 certs, 3 DB CA 2023 certs, and 1 DBX CA 2011 cert. And update the boot manager on the system drive's EFI, and update your bootable USB drives.

garlin said:

If correctly scripted, you can arrive at one of MS's recommended vendor outcomes for the UEFI which includes 2 KEK certs, 2 DB CA 2011 certs, 3 DB CA 2023 certs, and 1 DBX CA 2011 cert. And update the boot manager on the system drive's EFI, and update your bootable USB drives.

Click to expand...

I'm not quite there yet, but I'll keep watching this space for updates. I am booting with secure boot with the 2023 certificate and have the Windows 2011 certificate revoked, so I'm good with Windows. I'm missing the Option 2023 CA cert.

I am at a loss as to how your script would update the BIOS tables.

UEFI has a set of different variables. The PK, KEK, DB and DBX variables are arrays of byte values.
You're allowed to erase them (zero out the array), or append new bytes (or cert contents) from outside UEFI.

You take the post-signed objects from the MS GitHub (which is the official reference site according to the UEFI org), and apply them. There's even an example PS script provided by MS, but it's half-ass. I would NOT recommend running their script, it's a bare bones programming example.

The wrinkle is when your PC's PK isn't listed on the GitHub, which means your vendor isn't cooperating with MS to get their **** done. But you can manually enroll the KEK CA 2023 from the BIOS setup menu. So that's just an extra step outside of a script.

garlin said:

The wrinkle is when your PC's PK isn't listed on the GitHub, which means your vendor isn't cooperating with MS to get their **** done. But you can manually enroll the KEK CA 2023 from the BIOS setup menu. So that's just an extra step outside of a script.

Click to expand...

That's where I find myself for two of the four systems I was updating, hence my interest in figuring out Mosby and some of the in's-n-out's of the secure boot environment. I figured I'm about 30% of the way to understanding all of it, a long ways to go.

garlin said:

....

Other users can wait for MS to force Windows to update UEFI in 2026.

..

Click to expand...

Excellent - I'll wait and hope MS don't screw up the updates

Topics like this really crap me up. :) Updating secure boot keys - was never intended or recommended by anyone from Microsoft for the average user. This move was intended mainly for IT teams - securing their system against a known exploit. And here we are... even below average Windows users - try or struggle to manually update the secure boot keys on a Personal Computer - using CMD/PS, PS1 scripts, editing the registry and meddling with the UEFI storage - even using 3rd party tools like Mosby.

And yet, same users - whenever they see a topic about a Linux distribution - which was heavily dumbed down for a Windows like audience - act like we're still in the '80s - '90s and Linux distributions can only be managed and used on a daily basis using a CLI - while Windows is a point and click experience. The irony of it all and the double standards - are quite perplexing to say the least.

We have members here who are computer savvy (I'm not including myself in that group) and there are problems for some of them with this.
I think MS is going to have quite a task to roll this out the wider computer users.