OEM's and their Secure Boot Keys (2023) BIOS Update Policy

suatcini54 said:

For HP notebook PC owners, whose notebook PCs fall outside of manufacturer's service life, you can follow the procedure outlined in this website to install Secure Boot certificates CA 2023:

https://h30434.www3.hp.com/t5/Busin...3-CA-certificates-in-pre-2018-HP/td-p/9628370

Click to expand...

suatcini54 said:

The same procedure may also work for other notebook PCs outside of manufacturers' service life.

Hope this helps.

Click to expand...

Those are the exact steps my script follows when installing certs on unsupported PC's. Except it does it safely for you.

But I can't do the hard part, sitting in front of the BIOS menu and tell you what your screen looks like to delete all Secure Boot keys to enter Setup Mode. Every BIOS can have a different menu. HP owners have to check for Sure Start, which prevents unauthorized changes to the UEFI.

My script tries all of the supported methods, from the least difficult to most difficult in order.

1. When your PC has KEK CA 2023 installed in the BIOS, it applies any missing CA 2023 cert (like the Option ROM) and copies the new boot manager.

2. When your PC doesn't have KEK CA 2023, but your OEM submitted one to Microsoft, it downloads the matching KEK file from MS's GitHub and installs it from Windows. This is identical to receiving the "Secure Boot Allowed Key Exchange Key (KEK) Update" message from Windows Update.

3. If your PC doesn't have a submitted KEK in GitHub, it copies the KEK CA 2023 cert file to your EFI partition. You can check and see if your BIOS supports manual KEK key enrollment. Manually install the key from the BIOS menu. If successful, run the script to finish the work.

4. If your PC doesn't support loading a cert file (older Dells are known to have this problem), then use Setup Mode to wipe the Secure Boot keys. Run the update script to download the EDK2 binaries and install them.

Setup Mode will generally work for most PC's, unless your vendor has locked BIOS features or your PC is very old.

The difference between Mosby and my script (and the posted procedure) is Mosby uses self-signed certs instead of the Windows OEM Devices certs from the MS GitHub repository. Using the Windows OEM Devices certs means you're more supported, because those are written by MS for the OEM's use.

All the Secure Boot cert files used in my script are directly from Microsoft sources, in the Windows SecureBootUpdates folder or from their official GitHub site. I don't provide any of the secure files myself, so you don't have to stop and confirm the files are authentic and untouched. All of the file locations and GitHub URL's are visible in the update script for inspection.

garlin said:

Those are the exact steps my script follows when installing certs on unsupported PC's. Except it does it safely for you.

But I can't do the hard part, sitting in front of the BIOS menu and tell you what your screen looks like to delete all Secure Boot keys to enter Setup Mode. Every BIOS can have a different menu. HP owners have to check for Sure Start, which prevents unauthorized changes to the UEFI.

My script tries all of the supported methods, from the least difficult to most difficult in order.1

Click to expand...

Thanks for this explanation. You are basically saying that after getting into UEFI Setup Mode, I could run your update scripts to install CA 2023 certificates easily. I took the hard route to update. That's a load off. Next time.

suatcini54 said:

Thanks for this explanation. You are basically saying that after getting into UEFI Setup Mode, I could run your update scripts to install CA 2023 certificates easily. I took the hard route to update. That's a load off. Next time.

Click to expand...

In your case it looks like HP submitted the 2023 KEK to MS and it was added to the GitHub repository.

@garlin in all fairness to Mosby, if it wasn't for that method I wouldn't have been able to update my Lenovo T460 which had a PK issue. I would agree though that your processes are preferred and Mosby might be said to be method of last resort. There no sense not suggesting folks try it before going out and spending money to replace their device.

There's a somewhat related question I have. Since I have used the Mosby method on the T460, if I were to attempt to run your update method over top of the Mosby keys in Setup Mode ( not resetting or wiping ), would it leave the Mosby PK in place and update the KEK, DB and DBX? I'm only asking out of curiosity.

Dirtyflash said:

@garlin in all fairness to Mosby, if it wasn't for that method I wouldn't have been able to update my Lenovo T460 which had a PK issue. I would agree though that your processes are preferred and Mosby might be said to be method of last resort. There no sense not suggesting folks try it before going out and spending money to replace their device.

There's a somewhat related question I have. Since I have used the Mosby method on the T460, if I were to attempt to run your update method over top of the Mosby keys in Setup Mode ( not resetting or wiping ), would it leave the Mosby PK in place and update the KEK, DB and DBX? I'm only asking out of curiosity.

Click to expand...

Mosby will create a custom PK, and then transform the X509 certs for the MS KEK's so they're authenticated.

At this point, my script or the Secure Boot task can append changes on top of the DB and DBX variables. But you don't need to do that with Mosby, since it applies the DB and DBX certs at the same time. I don't believe it keeps up with the latest DBXUpdate.bin and SVN changes, leaving that to Windows.

garlin said:

Using the Windows OEM Devices certs means you're more supported, because those are written by MS for the OEM's use.

Click to expand...

No, that is incorrect.

Using the Windows OEM signed certs only means that you can install the KEK without enabling Setup Mode, since, outside of Setup Mode, you must use signed packages to update the Secure Boot databases. But the end result will be EXACTLY THE SAME, as the signed "wrapper" is discarded once the cert is installed.

Look, I understand that your script competes with Mosby and that you would therefore like to give it an edge, but I would appreciate, again, if this wasn't accomplished through misinformation. Each method has its pros and cons. But that statement of yours is complete bullshit ("more supported", How, when the end result, with the 2023 certs in the DB are exactly the same?!? "because they are written by MS" No, they are created by the OEMs, since it's only the OEMs that have access to their PK signing keys), and you should know that.

I will also quote (from OEM's and their Secure Boot Keys (2023) BIOS Update Policy):

Mosby will create a custom PK, and then transform the X509 certs for the MS KEK's so they're authenticated.

Click to expand...

1. Not necessarily. You can use option -r with Mosby to reuse the OEM PK and reinstall the OEM KEKs if you want.
2. Stating that Mosby "transforms" the X590 certs is misleading. The X509 certs are added to the Secure Boot databases completely unmodified. All Mosby does is add the necessary wrappers to make that happen for reluctant platforms in Setup Mode.

I don't believe it keeps up with the latest DBXUpdate.bin and SVN changes, leaving that to Windows.

Click to expand...

You are wrong. Mosby does install them by default. And we update it as required.

Again, I have no trouble with you trying to promote your script over Mosby usage (because I too would recommend that folks who only care about getting the 2023 certs install and are running Windows try that first), but I would prefer if it wasn't done through misinformation about what Mosby does or doesn't do.