Managing UEFI Key Databases in Setup Mode

UEFI Setup Mode is a specialized administrative state within the Secure Boot architecture that grants administrators unrestricted access to the system's cryptographic key databases. This article explains how entering Setup Mode disables standard signature verification requirements, allowing users to safely clear, replace, or customize the Platform Key (PK), Key Exchange Key (KEK), and authorized or forbidden signature databases (db and dbx), before locking the system back into User Mode.

The Role of Setup Mode in UEFI Architecture

Secure Boot operates in one of two primary states: User Mode and Setup Mode. This status is defined by the presence or absence of a Platform Key (PK), tracked internally by the UEFI variable SetupMode.

  • User Mode (SetupMode = 0): The system has an active Platform Key installed. In this state, any update to the signature databases (db, dbx, or KEK) must be cryptographically signed by an existing, authorized key higher up in the hierarchy.
  • Setup Mode (SetupMode = 1): The system has no Platform Key installed. In this state, the platform is considered "unowned" from a cryptographic standpoint.

Bypassing Cryptographic Verification

Under normal conditions in User Mode, the UEFI firmware enforces a strict hierarchy to prevent unauthorized modification of boot policies:

  1. The Platform Key (PK) authorizes updates to the PK and the Key Exchange Key (KEK).
  2. The Key Exchange Key (KEK) authorizes updates to the allowed signature database (db) and the forbidden signature database (dbx).
  3. The Signature Databases (db and dbx) authorize or block UEFI binaries, operating system bootloaders, and drivers.

When a device is placed into Setup Mode, the firmware suspends the requirement for updates to be cryptographically signed by an existing key. Because no Platform Key exists to validate incoming changes, the firmware accepts unsigned payload structures directly into non-volatile memory (NVRAM). This mechanism allows users to alter the entire security hierarchy without possessing original OEM private keys.

How Users Clear Key Databases

Clearing keys is typically the first step in taking control of the Secure Boot environment:

  1. Firmware Interface Action: Users access the UEFI/BIOS settings menu and locate the Secure Boot administration section. Selecting options such as "Clear Secure Boot Keys," "Delete PK," or "Erase All Security Keys" triggers the reset.
  2. Deletion of the Platform Key: Deleting the PK immediately causes the firmware to set the SetupMode variable to 1.
  3. Database Purge: Once the PK is cleared, the system permits the deletion of the KEK, db, and dbx without prompting for cryptographic authorization. Many UEFI menus offer a one-step action that deletes all databases simultaneously.

Modifying and Enrolling Custom Keys

Once in Setup Mode, the user can populate the empty databases with custom certificates to build a custom trust chain:

  • Firmware Enrollment: Many modern UEFI implementations allow users to browse local filesystems (such as a FAT32-formatted USB drive) to import .cer, .der, or .auth files directly into db, dbx, and KEK.
  • Programmatic Enrollment: Because signature checks are bypassed, users can run custom OS-level utilities (such as sbctl or efi-updatevar on Linux) to push new certificates directly into the UEFI NVRAM variables.
  • Granular Updates: Administrators can append specific hash values or certificates to dbx to block known vulnerable bootloaders, or append custom signing certificates to db to allow self-compiled kernels and drivers to execute.

Closing Setup Mode

Setup Mode is strictly a temporary administrative state. While in Setup Mode, the system cannot enforce Secure Boot protections, as any executable can run without validation.

To exit Setup Mode and re-establish security enforcement, a new Platform Key must be enrolled. The moment a valid public key is written to the PK variable, the UEFI firmware automatically sets SetupMode to 0, transitioning the machine back into User Mode. From that point forward, all further changes to any key database require signatures validated by the newly installed key hierarchy.