Skip to content

Secure Boot Objects

Jump to bottom
Doug Flick edited this page Mar 5, 2025 · 2 revisions

Understanding Secure Boot Objects

Secure Boot Objects are essential files that either contain the initial defaults for a platform or the update files that can apply the most recent DB (Database) or DBX (Revoked Signatures Database) during Secure Boot Maintenance in the lifecycle of a device.

Background

Typically, an Original Equipment Manufacturer (OEM) selects the defaults for a device when the firmware is built. These defaults are what the firmware will revert to if Secure Boot is ever reset (disabled and re-enabled).

During Secure Boot Enablement, which may occur during manufacturing, these defaults are used. The OEM might offer multiple 'templates' for a user to choose from, although many implementations only have a single template. In practice, this process can vary depending on the implementation.

For more details on globally defined variables and their properties, you can refer to the Globally Defined Variables.

Secure Boot Variables

Types of Secure Boot Objects

There are two forms of Secure Boot Objects.

  1. Signed Objects (A.K.A. Authenticated Variable)
    1. These contain the EFI_SIGNATURE_LIST
    2. Historically these were available on uefi.org/revocationlistfile
    3. Authenticated variables are used when a platform has Secure Boot enabled and a running operating system.
    4. The Public Key of the signer of the authenticated variable must be trusted. For DB and DBX, the signer must be in the KEK (Key Exchange Key). For KEK, the signer must be in the PK (Platform Key).
  2. Unsigned (A.K.A. EFI_SIGNATURE_LIST)
    1. Historically, these are the result of using SplitDbx.ps1 on a Signed Object.
    2. These may be used by firmware or by the OS if Secure Boot is disabled.

Understanding these Secure Boot Objects and their types is crucial for maintaining the integrity and security of a platform's boot process.

Clone this wiki locally