Using MOK for Custom Kernels in Debian Secure Boot

UEFI Secure Boot ensures that an operating system loads only cryptographically validated binaries, which natively prevents user-compiled or modified kernels from booting. In Debian, the Machine Owner Key (MOK) bridges this gap by acting as an administrator-controlled trust anchor within the shim bootloader infrastructure. This article explains how MOK enables the execution of custom Linux kernels on Debian systems, the cryptographic mechanism behind its validation process, and how it preserves platform security without disabling Secure Boot.

The Secure Boot Challenge with Custom Kernels

Under standard UEFI Secure Boot, the system firmware relies on authorized keys stored in non-volatile RAM (NVRAM), typically restricted to Microsoft and hardware OEM certificates. Debian achieves compatibility with Secure Boot by using a first-stage bootloader (shimx64.efi) signed by Microsoft's Third Party UEFI CA, which subsequently validates Debian's official bootloader (GRUB) and stock kernels signed by Debian's official key.

When an administrator compiles a custom kernel, builds out-of-tree kernel modules (such as proprietary drivers or custom patches), or modifies an existing kernel image, Debian's official signature is absent. The firmware and standard boot chain reject the binary, halting the boot process to prevent unauthorized code execution.

The Role and Architecture of the Machine Owner Key

The Machine Owner Key is an X.509 certificate managed directly by the system owner rather than hardware vendors or Debian maintainers. It operates within the shim bootloader layer rather than the UEFI platform key hierarchy (PK, KEK, db), avoiding the risk of bricking firmware or modifying complex UEFI NVRAM databases directly.

The primary functions of MOK in custom kernel validation include:

  • Local Trust Anchor: MOK serves as a secondary signature verification database specifically for shim. When shim checks the validity of GRUB and subsequent kernel images, it references both the embedded distribution keys and the keys enrolled in the MOK database.
  • Preserving Firmware Integrity: Because MOK operations are managed by shim and its companion utility MokManager (mmx64.efi), users do not need to replace firmware-level platform keys or disable Secure Boot globally.
  • Kernel and Module Validation: In addition to validating the custom vmlinuz binary during the initial boot phase, Debian uses the MOK database at runtime. If the kernel is built with module signature verification enabled (CONFIG_MODULE_SIG), the kernel imports keys from the MOK list into its system keyring, allowing custom or DKMS-compiled kernel modules to load seamlessly.

How Debian Validates a Custom Kernel via MOK

Validating a custom kernel requires establishing a trusted signing pipeline between the administrator and the MOK database:

  1. Key Generation: The administrator generates an asymmetric RSA or ECDSA key pair (a private signing key and an X.509 public certificate) on the Debian system.
  2. Signing the Kernel: The custom kernel image is signed using the private key and tools such as sbsign. This embeds a digital signature directly into the PE/COFF header of the kernel binary.
  3. Enrollment Request: The public certificate is submitted to the MOK infrastructure using the user-space utility mokutil --import. This stages the key in a temporary, protected UEFI variable.
  4. Physical Presence Verification: Upon reboot, control is handed to MokManager. To prevent malware from silently registering its own signing keys from user space, MokManager requires a physically present user to confirm the key enrollment and input a one-time password set during the mokutil command.
  5. Boot-Time Verification: Once enrolled, the key is permanently stored in the MOK list (held in NVRAM). On every subsequent boot, shim evaluates the custom kernel's embedded signature against this enrolled certificate. If the signature matches, the kernel executes with the full protection of Secure Boot active.