How to view and edit your UEFI BIOS secure boot keys

The bootable UEFI tool KeyTool.efi can save your UEFI Secure Boot keys or allow you to edit them.

You can save all keys to a disk using this menu.

From the Edit Keys menu you can examine and edit the various databases held in the UEFI BIOS NVRAM.

The Allowed Signatures menu will allow you to add authentication keys by loading one from a .auth file which should also be present on an accessible volume.

The Machine Owner Key List (MokList) menu entry will allow you to view and delete any existing keys which have been added. Ventoy requires you to add a key to the MokList so that you can secure boot the unsigned Ventoy BOOTX64.EFI boot file. You can use KeyTool to remove the Ventoy key from MokList after you have finished using the computer with Ventoy.

Microsoft/Linux may add entries into the dbx blacklist database to block the loading of some signed .efi file executables.

In brief, while UEFI Secure Boot is enabled, the hardware restricts the execution of code at boot time only to binary code signed by trusted keys. Trusted keys belong to a chain of trust with a root key stored on firmware and referred to as the Platform Key. The UEFI firmware verifies that the boot loader image has a cryptographically valid signature before running it.

Note: KeyTool.efi will not load under VirtualBox - use a real system for testing!

See Rod Smith's page for more details of KeyTool.

UEFI databases

The UEFI specification defines four secure, non-volatile variables, which are used to control the secure boot subsystem. They are:

1. The Platform Key (PK). The PK variable contains a UEFI (small 's', small 'd') 'signature database' which has at most one entry in it. When PK is emptied (which the user can perform via a BIOS GUI action), the system enters setup mode (and secure boot is turned off).
   In setup mode, any of the four special variables can be updated without authentication checks. However, immediately a valid platform key is written into PK (in practice, this would be an X.509 public key, using a 2048-bit RSA scheme), the system (aka, 'platform') enters user mode.
   Once in user mode, updates to any of the four variables must be digitally signed with an acceptable key.
   The private key counterpart to the public key stored in PK may be used to sign user-mode updates to PK or KEK, but not db or dbx (nor can it be used to sign executables).
2. The Key Exchange Key (KEK). This variable holds a signature database containing one (or more) X.509/2048-bit RSA public keys (other formats are possible). In user mode, any db/dbx (see below) updates must be signed by the private key counterpart of one of these keys (the PK cannot be used for this). While KEK keys (or, more accurately, their private-key counterparts) may also be used to sign executables, it is uncommon to do so, since that's really what db is for.
3. The Signature Database (db). As the name suggests, this variable holds a UEFI signature database which may contain (any mixture of) public keys, signatures and plain hashes. In practice, X.509/RSA-2048 public keys are most common. It functions essentially as a boot executable whitelist.
4. The Forbidden Signatures Database (dbx). This variable holds a signature database of similar format to db. It functions essentially as a boot executable blacklist.

Setup and User Modes

When a platform is in Setup Mode, the secure variables may be altered without the usual authentication checks (although the secure variable writes must still contain an authentication descriptor for the initial key and update type but the actual authentication information isn’t checked). In this mode, secure boot is turned off.

In user mode, the platform will check that any attempt to write to a secure variable has a validly signed authentication descriptor. In user mode, the platform will also expose a secure boot flag (which is on by default).

•  If secure boot is set, it will only execute efi binaries which are unsigned but have a sha-256 hash that is in db and not in dbx or
• are signed and have a signature in db but not in dbx or
• are signed by either a key in KEK or a key in db and neither the key nor the signature appears in dbx.

Note: PK is not consulted when attempting to verify executables.

EFI boot shims can also be loaded if their key is in the MokList.

DBT - Timestamp Signatures Database Maintains signatures of codes in the timestamp signatures database. These new certificate types also have a timestamp field, which allows the UEFI firmware to determine whether the UEFI driver or application was signed before the revocation date of the certificate. The revocation date is the time at which the certificate was identified as having been compromised. By checking the time stamps of the certificates in the UEFI drivers or applications against the time stamp of the certificate's revocation. If a UEFI driver or application was signed before that date and time, then it can still be loaded by the UEFI firmware since the certificate had not yet been compromised. If the UEFI driver or application was signed after that date and time, it might be malware and should be rejected. This generates less thrash for the IT department or OEM in having to update every single executable image ever signed by that certificate. The timestamps used in these certificates are created and compared by procedures described in RFC3161. With this information, the time stamps can be compared with an integer compare. There are time stamp authorities, similar to certificate authorities, that issue signed time stamp certificates. When checking the time stamps, their authority must have its signature registered with the UEFI firmware, in a new authenticated EFI variable called "dbt".

Note: If KeyTool is run in User Mode (secure mode) only .auth files will be listed.

MokList

The easiest way to bypass secure boot is to use a preloader. The preloader binary is signed with a (Microsoft) key and it is therefore suitable for being loaded by every UEFI Secure Boot firmware (if not blacklisted). The preloader uses a whitelist mechanism called Machine Owner Key list. If the hash of the launching binary is in the MokList, the preloader will execute it.

The MokList cannot be read or written by the OS (just the UEFI firmware only) so it must be altered manually by the 'owner' via the UEFI BIOS Setup menu or by booting from a local/USB disk.

New OEM Windows systems should always be shipped with Secure Boot enabled

When you buy a new Windows (11, 10 or 8) machine, it will usually be set up as follows:

• The PK variable will be loaded with a public key issued by the hardware vendor (for example, Lenovo).
• The KEK variable will be loaded with a public key issued by Microsoft.
• The db variable will be loaded with a set of public keys issued by various vendors authorized by Microsoft.
• The dbx variable will generally contain some revoked signatures or hashes (although it may also be empty, it depends on the revision of Windows on your machine). Windows Updates will often update this list to prevent signed efi files (which are later identified as a security risk) from being loaded.

How to run KeyTool.efi

If you have an E2B USB drive, you can place the unsigned KeyTool.efi file in a folder on the 2nd FAT32 partition (I use the \EFI\refind folder so that refind will list KeyTool in the refind tools menu). If you can Secure Boot to agFM then you will be able to run KeyTool.efi (by launching rEFInd first and using it's tools menu).

If Ventoy can be booted successfully, then it should also allow you to directly select and run this unsigned KeyTool.efi file.

The new version of agFM (v. 1.A1) includes the unsigned KeyTool.efi - if agFM can be booted then KeyTool.efi should run OK in both Secure and in-Secure modes (there is also a new entry for KeyTool in the startup_default.cfg menu in v.1.A1).

Download KeyTool.efi  (UEFI64 only - unsigned).

This file can be booted to directly by a UEFI64 BIOS. For instance, you could replace the \EFI\BOOT\BOOTX64.EFI file which is the default 64-bit Intel x86 architecture UEFI boot file with KeyTool.efi by simply copying it to a FAT volume and renaming it to that name. The UEFI should not be in Secure Boot mode as the efi file is not signed, however you can sign it for secure booting by following the process here.

You can also try adding it to your Windows boot menu (untested - the UEFI BIOS Secure Boot setting may need to be in Setup Mode not User Mode?):

bcdedit /copy {bootmgr} /d "KeyTool"
bcdedit /set {GUID from previous command} path \EFI\utils\keytool.efi

Note: If you want this to load when Secure Boot is enabled and in User Mode, you may need to use a KeyTools-signed.efi version (???).

Super-UEFIinSecureBootDisk

You may also find the Super-UEFIinSecureBootDisk .img file by ValdikSS useful to write to a FAT32 USB stick as an image. On first boot you may need to use MokManager to add the key which is in the root, to the UEFI MokList before it will load the boot shim however.

The .img file can also be booted directly from agFM or Ventoy on a real system (if you can boot to the agFM\Ventoy menu successfully).