Lion Cipher Lab

Take ownership of the UEFI trust chain: enroll your own Secure Boot keys and sign your own kernel

• Cyber / Security Engineer
• Advanced
• ~90 min
• Free · no account required

Why it matters

Secure Boot is the one security control on your machine whose trust anchor you almost certainly did not choose. Out of the box your firmware's allowed-signature database contains Microsoft's certificates, and Microsoft's third-party UEFI CA has signed 'shim' — the small first-stage loader used by essentially every Linux distribution. The practical consequence is that your machine will happily boot a signed bootloader from a distribution you have never heard of, because the trust anchor is Microsoft, not you. That design has been stress-tested in public: BootHole (CVE-2020-10713) was a buffer…

What you'll learn

• explaining the UEFI Secure Boot key hierarchy from zero: PK -> KEK -> db / dbx, and what Setup Mode actually is
• naming who holds each key in a factory machine (Microsoft's KEK CA, the Windows Production PCA, the third-party UEFI CA) and proving it from the firmware image
• generating a PK, KEK and db keypair with openssl and converting them to EFI signature lists and signed .auth updates
• enrolling your own keys into edk2/OVMF firmware in the correct order — db, then KEK, then PK LAST
• signing an EFI binary (your kernel) with sbsign and verifying it with sbverify
• proving enforcement BOTH ways: a signed image boots, a one-byte-tampered image is refused with Access Denied
• running the whole thing safely in a QEMU VM with its own writable OVMF_VARS file instead of on real hardware
• naming the real failure modes: PK-first lockout, dual-boot and BitLocker fallout, Option ROMs, out-of-tree modules and MOK, kernel updates that unsign you
• judging when owning the keys is worth it (appliances, fleet images) and when it is not (a dual-boot daily driver) — and why Secure Boot is a gate, not a record

Steps in this lab

1. Read this first: everything here happens in a virtual machine, never on your laptop
2. The key hierarchy, from zero: PK -> KEK -> db and dbx
3. Whose keys are in your machine right now — the factory state
4. Why you would ever take the keys: BootHole, and the price of a shared anchor
5. Install the toolchain and find your OVMF firmware files
6. Generate your own PK, KEK and db keypairs
7. Convert to EFI signature lists and build the signed .auth updates — and learn the ordering rule
8. Sign your own kernel with sbsign, and verify it with sbverify
9. Build an EFI System Partition image and boot the VM into firmware setup
10. Enroll your keys in the firmware: db, then KEK, then PK LAST
11. Proof one: your own signed kernel boots
12. Proof two: flip one byte, and watch the firmware refuse it
13. The dual-boot reality check: what your keys just cost you, seen live
14. The five ways this goes wrong in real life — name them so you can spot them
15. How a professional does this now: sbctl, and why you did it by hand anyway
16. The judgment: when to own the keys, and what Secure Boot still cannot tell you

Open the full interactive lab →