Hi,
Does anyone know how to remove the platform keys and put secureboot into setup mode?
I’m asking because I would like to enroll my own keys using sbctl:
https://man.archlinux.org/man/community/sbctl/sbctl.8.en
Thank you for your advice.
3 Likes
In the UEFI setup page for Security, sub-page Secure Boot, choose “Erase all Secure Boot Settings.”
That will put the platform into Setup mode.
After you enroll your own keys, if you want to retain the ability to upgrade the firmware and run other boot applications provided by Framework Computer you will need to re-enroll their DB and KEK¹.
¹ I have a thread requesting an official source for those certificates here: Request: Publish the Secure Boot DB and KEK certificates
8 Likes
Thanks, this is much appreciated!
Would it be possible to add some documentation to your repo on how to re-enroll their DB and KEK?
1 Like
Sure, I can take a crack at that. It looks like sbctl doesn’t support enrolling keys it didn’t itself create¹, but in the meantime while your platform is in setup mode you should be able to use KeyTool or sbkeysync (which will sync a directory of keys into NVRAM; migrating from sbctl is still unfortunately an exercise for the reader!)
¹ Except for the Microsoft keys, for use with option ROMs.
2 Likes
@DHowett So just to clarify: Just signing fwupd with my own keys would not be enough to update the laptop firmware later?
$ sbctl sign -s -o /usr/lib/fwupd/efi/fwupdx64.efi.signed /usr/lib/fwupd/efi/fwupdx64.efi
1 Like
I don’t believe so. I’m not certain how fwupd works, but it might rely on the vendor’s updater (for Framework, that’s H2OFFT.efi, the H2O Firmware Flash Tool), which may be distributed as part of the update bundle and which you may not have a chance to re-sign. If not that, there is also a signature on the firmware capsule itself that might be validated via secure boot.
2 Likes
Thanks for your input. Do you think enrolling my own key in setup mode and then later adding back framework’s KEK and DB in the bios menu would work?
1 Like
Definitely. I wasn’t able to figure out what certificate format the setup menu was looking for, but it does seem to have the ability to enroll keys in User mode.
2 Likes
So, I had a quick look at sbctl. It looks like you can enroll the Framework upstream keys in a roundabout (though totally correct) fashion.
This assumes that you’ve already created and enrolled keys using sbctl!
- Download the Framework DB in EFI Signature List format (
.esl) from the cert repository - Make sure
efitoolsis installed (pacman -Syu efitools) - Produce a version of the Framework DB signed with your KEK (which will allow secure boot to authenticate that you are the person adding the Framework signature)
- We’re going to use the key and owner GUID that
sbctlproduced! sign-efi-sig-list -a -g $(cat /usr/share/secureboot/GUID) -c /usr/share/secureboot/keys/KEK/KEK.pem -k /usr/share/secureboot/keys/KEK/KEK.key db frame.work-LaptopDB.esl frame.work-LaptopDB.esl.auth
- We’re going to use the key and owner GUID that
Once you have frame.work-LaptopDB.esl.auth, you can enroll it using KeyTool.
There is a copy of KeyTool at /usr/share/efitools/efi/KeyTool.efi. You will probably need to sign that as well, using cp /usr/share/efitools/efi/KeyTool.efi; sbctl sign KeyTool.efi.
Grab a FAT32-formatted flash drive and copy your newly-signed KeyTool.efi to it as EFI/boot/bootx64.efi. Place the auth file at the root of that drive.
Boot from it – with Secure Boot enabled – and go enroll/append the new db key from the .auth file you just produced. 
4 Likes
Sorry for the double bump! It also looks like if you fetch the *.der files from my repository and rename them to *.cer, the Enroll Signature option under the KEK and DB sections will pick them up.
- Copy them to your ESP
- db/KEK
- Enroll Signature
- PKCS7
- Navigate to the right one (DB or KEK)
- Choose it.
- Enter the owner GUID (this is really annoying, as it doesn’t tell you what it’s for and it doesn’t let you correct what you already typed)
- That’s
55555555-5555-5555-5555-555555555555(8-4-4-4-12) (and yes, Framework’s owner GUID is all fives.)
- That’s
4 Likes
Thanks @DHowett
Here’s what worked for me on Arch using dracut and systemd-boot (haven’t tried updating the BIOS yet because I’m on the most current version):
- Go to BIOS/Secureboot. Enable Secureboot and select the “Erase all Secureboot settings” option
- Boot into Linux and verify that with “sbctl status” that “Setup Mode” shows “Enabled”. Secureboot will still show “Disabled”
- “sbctl create-keys”
- Point dracut to the keys by adding this in the dracut.conf(.d/whatever.conf)
uefi_secureboot_cert="/usr/share/secureboot/keys/db/db.pem"
uefi_secureboot_key="/usr/share/secureboot/keys/db/db.key" - Regenerate and sign EFI images:
dracut -f --uefi --regenerate-a - Sign and install bootloader
sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi
bootctl install - (Optionally) sign fwupd:
sbctl sign -s -o /usr/lib/fwupd/efi/fwupdx64.efi.signed /usr/lib/fwupd/efi/fwupdx64.efi - Enroll the keys with “sbctl enroll-keys”
- Reboot to BIOS and follow @DHowett instructions of adding db/KEK cer files manually (post above)
3 Likes
I have intentions of properly supporting the proper OEM keys for laptops. The issue is that they are hard to fetch.
I have had a few emails with Richard Hughes (Red Hat and LVFS) to see if we can have OEMs upload their secure boot certificates to LVFS so they are easier to gather and properly apply depending on the OEM. But it has partially died on my end because this is still only a hobby
I do have some intentions of providing ways to import keys into db/KEK/PK in the future so this should be easier hopefully.
3 Likes
Absolutely! Sometimes they live locked away in a firmware volume somewhere, and other times they’re part of NVRAM (??). Getting them up on the web behind an API (LVFS sounds great!) would be ideal.
Since I’ve been floating around the area recently . . . would you accept a contribution that adds support for optionally loading keys from KEKdefault and dbdefault? I know that some vendors offer those.
1 Like
Sure that would be great! Personally I have never seen those files populated on Thinkpads nor the Framework either (IIRC?) but probably neat to have the ability to enroll if present.
1 Like
@DHowett As of recently, my encrypted Arch install won’t boot if “setup mode” is enabled. Regular secure boot on or of poses no problem. Have you encountered this?
Huh! I’ve never seen that before. If you boot without quiet or splash in your kernel command line, does it print anything interesting about signing keys or module signatures or something on startup?
Alright! Based on this, I’ll make an educated guess
I am guessing that you have LUKS set up with automatic decryption via a key stored in the TPM, and no backup password option. The TPM key is probably bound to the secure boot configuration (one of the PCRs; which one, I cannot remember), so the TPM won’t cough it up when you switch modes.
@DHowett Thanks for your input. That was my first guess as well, but wiping the TPM slot with systemd-cryptenroll (which results in having to manually enter the decryption key on boot) produces the same strange outcome: Working fine with secureboot on or off, but halting in secureboot setup mode.
Am I missing something?
just a heads up, sbctl enroll-keys -m -f does put the framework keys back so no need for extra hops i think!
2 Likes