I am looking to configure the secure boot platform to allow Windows Update to alter my DB and DBX, without using Microsoft's KEK. I have once again encountered being unable to update Windows on my PKI test rig because of lacking automatic variable updates. An LLM told me what I should do is enroll my KEK key pair into the trusted root, and the public key as normal into the secure boot storage. I am about to start to test the possibility, but I wanted more information. Do I need to sign the KEK with a certificate that is also in the trusted root, or will it be fine? Does it need specific usage constraints to be detected for this purpose? Is this even the right way to do this? Is this even possible? Alternatively I will just enroll their certificates or make a reminder to check for variable updates when I can't install another CU. Probably safer that way, without my KEK private key available to processes, but curiosity has me wondering. Much appreciation if you have any tips or leads!
Not really possible, and it doesn't even have anything to do with Windows or its trust store. DB/DBX updates work by doing authenticated UEFI variable writes, i.e. the firmware verifies that the data to be written is signed by a trusted key (KEK or PK). If the key used to sign the data is not enrolled, the firmware (not Windows) will reject the write. In the case of Windows updates the DB and DBX updates come signed with Microsoft's KEK of course, so without that KEK enrolled the UEFI writes will fail. You'd have to sign the DB/DBX lists [0] with your own KEK and do the variable update yourself if you wanted to do this without MS's KEK present, but that's not going to work as part of the regular Windows update process. If you're going to trust Microsoft's DB/DBX lists anyway you may just as well enroll their KEKs, that's what they're for. [0]: github.com/microsoft/secureboot_objects