It would be really great if Framework could publish the KEK and DB certificates used for secure boot on the Framework laptop.
Why
A user who chooses to enroll their own Platform Key (PK) will lose system trust for anything that they, or a certificate they have signed, have signed.
Publishing the Key Exchange Key (KEK) and Allowed Signature Database (DB) certificates shipped with Framework laptops would allow such a user to re-enable that trust by cross-signing those certificates with their new platform key.
NOTE: This is not a request that you release the private keys! Just the public certificates, which already ship by default on every laptop and could be extracted.
Prior Art
Microsoft does this for their KEK and DB as well, for the express purpose of enabling an OEM or PK holder to trust the Windows bootloader and allow Microsoft to perform their own key exchanges.
In the interim, I’ve published the certificates as extracted from the dbDefault and KEKDefault secure boot variables in this repository.
Two notes:
Since you have no reason to trust me, I’ve documented steps (which should work on Linux) that you can use to verify that these certificates are, in fact, signed by the root of trust on your own laptop.
I am not affiliated with Framework or the Framework team. Further, I will happily take these certificates down if I’m asked to.
@DHowett Thanks for your work. I’ll probably try to enroll my own key to enable Secureboot on my archlinux install in the coming months and as I have never had to do this it helps a lot
NOTE (since I can’t edit the original post): I’ve updated the repository with certificates from the 12th gen Intel Framework Laptop based on data provided by ngxson and Morpheus636.
I’m really struggling to find information on fixing secure boot issues… I’ve recently wiped and re-installed my Framework laptop (I had Omarchy on there, which required Secure Boot to be disabled, but have now gone to Fedora and wish to re-enable Secure Boot) and find that the Enable Secure Boot option in the firmware is greyed out and cannot be enabled.
I believe I’ve tried both of the Secure Boot reset options in the firmware (and have a suspicion that one of these options has caused my current predicament) and can see that the various options within the Secure Boot sections are empty, except for the DBX which has a SHA256 value consisting of all zeros… which doesn’t seem right.
If I boot using a Ventoy USB stick, I am sometimes asked to add the key using the MOK manager process, and this works… then I can install an OS and I seem to get some keys listed in the DB … but mokutil --sb-state shows that secure boot is not available and installing the sbctl tool and running sbctl status suggests that the system is not booted with UEFI, despite the output of [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS being UEFI.
Whilst framework support are currently enquiring about whether I followed the guide for Fedora and what make and model my RAM sticks are, this is about the closest conversation I’ve seen on the forums here discussing secure boot… are you guys aware of how I can restore the original DBX content? I’m on an 11th Gen Intel motherboard, so I have tried re-applying the 3.24 firmware files (by skipping the startup.nsh commands and running the update manually via the shell) but that hasn’t helped.
Alright, I don’t know if you will be able to use this method. However, Framework published a firmware update that repairs the secure boot state. If you can downgrade from 3.24 to 3.22 and use the ClearVar firmware image in this thread it may just work. Follow the instructions in Note 1 (near the top.)
Thanks for the suggestion but I can’t seem to downgrade the BIOS. Using the clearvars version, I’ve amended -allowsv to the end of the command and it seems to run through the process but rebooting into the UEFI settings still shows that I’m on 03.24 and the settings are still greyed out.
I’ve also tried running that command and immediately running CapsuleApp.efi winux.bin firmware.cap… which seems to throw some text on the screen but immediately reboots the laptop.
EDIT: On a side note, slightly concerned that despite having a supervisor password set and chassis intrusion detection enabled, the “clear mainboard” process that is often suggested by support for these devices seems to completely wipe any trace of those settings… meaning they’re effectively useless. This then renders the disabling of booting from USB / network null and void, meaning you can’t really trust your laptop once it’s out of your possession. You’d effectively be relying on noticing that the UEFI options are no longer protected by your particular password … but then if you work on this as a business device, you might not know the password your IT team have set.
So, I had a follow up from support … like another poster on here it seems they’re opting to replace the mainboard. Seems sad that we can’t recover it… the thing boots, it just needs it’s firmware fixing.
Don’t erroll the microsoft keys unless you need microsoft losedows. Use sudo sbctl enroll-keys -f --yes-this-might-brick-my-machine (It did not brick my framework) instead.
