---
layout: post
title: Secure Boot Experiments
date: 2024-05-13 20:00 +0200
lang: "en"
categories: "tech"
description: "My experience with Secure Boot and Linux"
---

So, since I was bored recently, I somehow wanted to experiment with Secure Boot.
I didn't enable it when I bought my PC 10-ish years ago, not did I ever enable
it for any of the Linux Distributions I tried out. So why now? Dunno, I was
curious how well it works. So, this was mostly a "I have no idea what I'm doing,
let's see what happens" thing.

For most of the stuff, including basics, you wanna look at the references below.
So, I guess this blog article is mostly a "things I stumbled upon / got confused
about" list.

- Assumption:
  Enabling Secure Boot only makes sense if you also set a formerly "BIOS
  password" / protect the firmware setup with a password, otherwise someone with
  physical access to the machine could simply disable secure boot again? And even
  then… Surely there are ways to reset the settings including the password, in
  case you forget it? Wouldn't secure boot be disabled by this, allowing an
  attacker to boot arbitrary stuff? (Well yes, but an attacker with physical
  access to the machine is not what SB was designed for, it's for protecting
  against root kits. -- Correct me if I'm wrong here).
- How do all these keys relate to each other, and what is the MOK? (See
  references below).
- Enabling Secure Boot in UEFI. What the heck is Custom or Standard key
  management? (Custom allows you to add your own keys? Or does it only influence
  the default keys? Your UEFI may vary.)
- What does "Secure Boot disabled / Setup mode" mean? (It means the keys needed
  for SB are not set up yet)
- Following the Arch Wiki article: Why the heck could I update the DB key
  database using `efi-updatevar -a -c MS2.cer -k ../KEK/KEK.key  -g "$(<
  ../myGUID.txt)" db` without entering the keys passphrase? (I was in setup
  mode. EFI variables in regard to SB keys can be written freely).
- Why am I getting "Invalid Signature" by my UEFI, even though the binary is
  signed? (Either my UEFI implementation is broken, or this never works: The EFI
  binary had two signatures, I only added my signature to the Linux signature,
  instead of replacing it. Replacing works!)
- Why does stub complain about "0x1A Security Violation"? I clearly signed the
  binary with the MOK key? (The rEFInd binary didn't have an .sbat section - the
  Debian package is too old).
- Does Debian actually auto-enroll the DKMS signing key into the MOK? If so,
  how? I thought this requires entering a password? (I *would guess* Debian does
  not auto-enroll, because it needs a password).
- Where does shim actually store "accepted" MOK keys? (I *think* in the
  efivars?).
- Why does shim use a light grey font on a light blue background? This is
  unreadable! (No idea).

## References

- [Secure Boot on Debian Wiki](https://wiki.debian.org/SecureBoot)
- ["Switching on Secure Boot in Debian" on blog.lazy-evaluation.net](https://blog.lazy-evaluation.net/posts/linux/switching-to-secureboot.html)
- [Secure Boot on Arch Wiki](https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot)
- ["The meaning of all the UEFI keys" on blog.hansenpartnership.com](https://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/)
- ["Managing Secure Boot" in rEFInd docs](https://www.rodsbooks.com/refind/secureboot.html)
- ["Controlling Secure Boot" in rEFInd docs](https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html)
- ["About UEFI Secure Boot" in Oracle docs](https://docs.oracle.com/en/operating-systems/oracle-linux/secure-boot/sboot-OverviewofSecureBoot.html)