UEFI Binary Digital Signature Verification Explained

Unified Extensible Firmware Interface (UEFI) verifies digital signatures on arbitrary binary files through its Secure Boot subsystem, relying on Authenticode specifications, cryptographic hashing, and non-volatile signature databases. Before any executable image is permitted to run, the firmware calculates an Authenticode-compliant hash and evaluates the binary's embedded Public-Key Cryptography Standards (PKCS) #7 signature against trusted and revoked certificates stored in the platform's non-volatile random-access memory (NVRAM). This process ensures that boot loaders, drivers, and operating system kernels maintain cryptographic integrity and originate from trusted vendors.

The PE/COFF and Authenticode Structure

UEFI relies on the Microsoft Portable Executable/Common Object File Format (PE/COFF) standard for all executable binaries, including EFI drivers, applications, and OS boot loaders.

To sign an arbitrary PE/COFF binary, a digital signature is embedded into the file's Attribute Certificate Table located in the IMAGE_DIRECTORY_ENTRY_SECURITY directory. UEFI implements Microsoft Authenticode specifications to generate and verify these signatures. Because certain fields within a PE/COFF image change depending on the runtime context (such as the file checksum and the security directory entry itself), the verification mechanism excludes these volatile fields when computing the cryptographic digest. This deterministic hashing process ensures the file hash remains identical before signing and during firmware evaluation.

Cryptographic Algorithms and Formats

UEFI firmware utilizes standard public-key cryptography to validate authenticity:

  • Digest Algorithms: The UEFI specification mandates support for SHA-256, though platforms may also support SHA-384 and SHA-512. Older, deprecated algorithms such as SHA-1 are phased out or explicitly forbidden.
  • Signature Containers: Signatures are wrapped within PKCS #7 / Cryptographic Message Syntax (CMS) SignedData structures. The package includes the signer's X.509 certificate, the encrypted digest of the binary, and optionally a trusted timestamp countersignature.
  • Public Key Algorithms: Firmware commonly evaluates RSA keys (typically 2048-bit or 4096-bit) and Elliptic Curve Cryptography (ECC) keys using curves like NIST P-256 or P-384.

UEFI Key Databases

The verification logic depends on a hierarchical key architecture stored in authenticated UEFI variables:

  1. Platform Key (PK): Establishes the trust relationship between the platform owner and the firmware, controlling access to the Key Exchange Key database.
  2. Key Exchange Key (KEK): Authorizes updates to the signature databases.
  3. Authorized Signature Database (db): Contains the public keys, X.509 certificates, and cryptographic hashes of approved binary images.
  4. Forbidden Signature Database (dbx): Serves as a revocation list containing certificates, public keys, and SHA-256 hashes of compromised or vulnerable binaries.

The Verification Workflow

When an image is invoked via the UEFI Boot Service function gBS->LoadImage(), the firmware routes the execution request through the EFI_SECURITY2_ARCH_PROTOCOL or EFI_SECURITY_ARCH_PROTOCOL. The verification mechanism executes the following sequential steps:

  1. Hash Calculation: The firmware calculates the Authenticode digest of the PE/COFF binary according to the specification, bypassing excluded regions (e.g., file checksum and certificate entry pointers).
  2. Revocation Check (dbx Evaluation):
    • The binary's computed hash is compared against all entries in the dbx database. If a match is found, execution is immediately aborted with an access-denied error.
    • If the binary contains an embedded signature, the firmware inspects the signer's certificate chain. If any certificate or key in the chain matches an entry in dbx, the image is rejected.
  3. Authorization Check (db Evaluation):
    • Direct Hash Matching: The computed hash is compared to standalone hashes in db. If a match exists, the binary is considered authentic and allowed to execute, even without an embedded PKCS #7 signature.
    • Certificate Chain Validation: If no direct hash match occurs, the firmware parses the embedded PKCS #7 structure in the Attribute Certificate Table. The firmware validates that the certificate resolves to a trusted root or intermediate certificate present in db.
    • Signature Mathematical Validation: The firmware decrypts the encrypted digest inside the PKCS #7 structure using the public key extracted from the valid certificate and verifies that it mathematically matches the freshly computed Authenticode hash of the image.

If all cryptographic checks pass and no revocation entries are encountered, the image is loaded into memory, marked as executable, and execution control is transferred to the binary’s entry point. If any step fails, the firmware halts the operation, preventing unauthorized or altered code from executing.