Event details
We are using the AvailableUpdates=x5944 method to make these changes in our environment. Two out of our ~ten active, Win11-supported models of Lenovo desktops/laptops will not take the KEK cert update (the DB certs and bootloader update fine on them, but the KEK piece fails with Event ID 1795). In the last month, Lenovo has released BIOS updates for those models that add the 2023 certs to the default Secure Boot key stores, but not the active store, and the KEK update from within the OS still fails. Lenovo's recommended process is to update the BIOS and then use the "Restore Factory Keys" get the new certs into the active store. We have started doing this and it works but it is obviously a hands-on process (in particular, the "reset to factory keys" part cannot be automated and requires physical presence, as far as I know).
Is there any hope that Microsoft (maybe in partnership with these OEMs) will add "support" for more hardware models to take the KEK cert via AvailableUpdates before June, or, if it doesn't do it now, is that not going to change?
Event ID 1795 should include an error code that might be useful to diagnose this (Not all 1795 are equal).
For the KEK update to work, the OEM needs to submit a signed variable update with the new KEK that is signed with the Platform Key. and upload to Microsoft's secureboot_objects repo on GitHub. A list of all platform keys they have received (even those that did not make it into the January CU) with their thumbprint is available at
https://github.com/microsoft/secureboot_objects/blob/main/PostSignedObjects/KEK/kek_update_map.json
You can check the Subject and Thumbprint of the used platform key on affected machines that did not reload the factory keys, by installing and importing UEFIv2 Powershell module and running:
(Get-UEFISecureBootCerts pk).Signature | Format-List Subject,Thumbprint
If the thumbprint has already been submitted to Microsoft, it will probably be part in one of the subsequent updates and therefore the KEK update may work. If the KEK update causes a firmware error, the OEM might push a firmware update to fix this. So time can fix this.
The most likely case for a vendor like Lenovo to release a firmware update but not submit a signed KEK to Microsoft would be that they simply lost the private key to the PK used in those firmware versions. You can check on a machine that already uses the new factory keys (or by looking at pkdefault instead of pk if the firmware exposes that variable) if it uses a PK with different thumbprint. If yes, that is a telltale sign.
In that case, automated fixing is not possible (if the machine has an active TPM, which it probably has if it is Win11-supported). If Lenovo pushed a firmware update that either updated PK or KEK, it would invalidate PCR7 of the TPM and in case Bitlocker uses that PCR to seal their keys you would end up in Bitlocker recovery (which is a tedious manual step as well). And as long as they cannot sign a new KEK update with the PK as they lost it, Microsoft cannot do anything either.
That's exactly what Secure Boot tries to prevent.
mihi - thanks for clarifying why the BIOS update can't realistically update the active keys.
The two models we have that won't take the KEK update via the OS (as of the January B-Week CU, anyway) are PK thumbprints F2E851A4D6C74F0671DC0DCF392C96F94AE30816 and EF95E29CCE285D87734012EF940FB14EE0A7118B, respectively. Both of these have been on the JSON file you referenced since it was first published last May. The PK thumbprint is still the same after updating the BIOS to the version that adds the new certs to the factory defaults and performing a reset to factory keys.
It sounds like Microsoft still might add support, then? That said, with taking so long to do so, our hand is basically being forced to undertake an extremely intensive manual process, since we can't afford to wait until a month or two before June with no guarantee that Microsoft will actually get around to it and then not have enough time to complete the updates manually ourselves.
Can you give any insight into how much of a "backlog" MS has in adding support for PKs already submitted by vendors? Any specifics into when the two thumbprints I provided might be added?