Event details
The option was there, and I tried both the .der file in your link, as well as the .crt found here:
https://go.microsoft.com/fwlink/?linkid=2239775
Both resulted in this error (see below). I tried saving the original KEK to see if it would at least identify the correct extension, but it didn't specify an extension on export.
Any other suggestions?
This page: https://www.dell.com/community/en/conversations/optiplex-desktops/how-to-manage-secure-boot-key-files-on-bios-type-2-machines/691c874fca58a9338d7717a9 says Dell needs .auth files.
This defense dept PDF (https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-Secure-Boot-Customization-UOO168873-20.PDF) (believe it or not) says you can turn a CRT into a .auth as follows - but I don't know where to get the KEK.key file or the PK.crt
PowerShell can also be used to convert ESL files into AUTH files. Only AUTH files can be used to update Secure Boot values while enforcing signature checks. The PK can sign itself and KEK(s).
openssl pkcs12 –export –in KEK.crt –inkey KEK.key –out KEK.pfx –name "KEK"
Does the options in your UEFI setup match the screenshots in that document? [EDIT: Now your screenshot shows up, I did not see it before. guess that's a Yes.] I was hoping that there is an option (as I have seen it on a few machines) to upload a KEK certificate form the setup that is not authenticated by the current platform key, keeping the rest of the keys intact. Probably only available after enabling Custom Mode.
And it seems you copied the wrong line from that PDF. To create KEK.auth, you need PK.key. Which matches the options that Windows itself is using to update the KEK, they have received a signature of Microsoft's KEK signed with the vendor's PK.
If there is no way to shortcut this process in the UEFI setup, and Dell won't provide any support, the only way forward would be to do what that document describes:
- Create your own PK (DJ8014A-PK) and sign it with itself
- create your own KEK (DJ8014A-KEK)
- sign DJ8014A-KEK and MS2011-KEK and MS-2023-KEK with DJ8014A-PK.
- Take inventory what is currently in DB and sign all of that with DJ8014A-KEK. Alternatively take the signed objects for MS2023 certificates that are signed by MS-2011-KEK
- I would not care about DBX, just delete everything in there and let Windows repopulate it on next DBX update.
- in UEFI setup, Erase secure boot keys
- Load the keys again (either via keytool or from UEFI setup), start with DB, then KEK, last PK.
Make sure to store your PK securely that no attacker can steal it, or else you could just keep Secure Boot off...
If you are feeling unsure, follow your feelings and don't follow this description, you don't want to brick your precious workstations...
Thank you for the detailed response.
Sadly, I do think this is beyond my meager abilities.
This is especially true considering some of the tools in that DOD PDF have been deprecated, and I can't even get the Dell UEFI to import keys that it exported - they throw the same error (you'd think ones it exported itself should be just fine).
Instead, I'm going to try to get some sort of idea as to what kind of security hole I'd be leaving on these machines... That is, if I can get Boot Manager updates, but not bootloader/dbx updates (without a KEK), does that mean that, on average, I'll get 1 out of every 4 Secure Boot updates going forward? 1 out of every 50? 1 out of every 1000?Not sure about deprecated tools. Signtool.exe is still part of the Windows SDK, and OpenSSL for Windows is available precompiled from different vendors. If you prefer the Linux route, all of openssl, pesign, sbsigntool, and efitools are part of Debian 13 (the latest version).
And for importing, I would suggest using keytool.efi (or trying the import from a booted OS) after all secure boot keys have been removed via the UEFI setup, that way you are using the documented ways (that also Microsoft uses to update the KEK if they had the signature for it) and avoid any firmware setup quirks.
Still I can understand you don't want to take that endeavor.
As I said in the other post, I don't believe there have been any Secure Boot relevant updates to the bootloader (with a CVE) that did not go with also blacklisting some older versions via DBX (either by hash or by SVN).
