The Meaning of all Keys
Introduction
The UEFI specification (2.3.1c) outlines various key stores and their respective formats, including the Platform Key (PK), Key Exchange Key (KEK), key database (db), and forbidden signatures database (dbx). This article explores the interconnections among these elements and delves into their implementation within the Tianocore reference implementation.
UEFI Secure Variables
The storage of all keys is implemented through UEFI secure variables, as detailed in section 7.2 of the UEFI specification. An essential characteristic of secure variables is that they can only be updated if the individual attempting the update can demonstrate, through a digital signature on a specified payload known as the authentication descriptor, possession of the private part of the key used for creating the variable. The UEFI specifications permit only two types of signing keys: X509 and RSA2048. Clearing a secure variable is achieved by writing an empty update, which must still include a valid authentication descriptor.
Authentication Descriptor
The UEFI specifications provide for two types of authentication descriptors:
time-based and
monotonic count-based.
Once a variable is established, it retains both the key responsible for its creation and the initial value for the time or monotonic count. Subsequent updates must be signed with the same key and possess the same update type (either time-based or monotonic count) as the variable's creation. This precautionary measure prevents the replay of earlier updates, requiring a newer update to feature either a later time or a higher monotonic count. Upon acceptance of an update, the time or count is adjusted to match the value in the authentication descriptor.
Setup and User Modes
During Setup Mode, secure variables can be modified without the typical authentication checks. While secure variable writes in this mode must still contain an authentication descriptor for the initial key and update type, the actual authentication information isn't scrutinized. Secure boot is turned off in Setup Mode.
In user mode, the platform verifies that any attempt to write to a secure variable includes a validly signed authentication descriptor. Additionally, the platform exposes a secure boot flag (enabled by default) in user mode. If secure boot is set, the platform will only execute EFI binaries that meet one of the following conditions:
Unsigned binaries with a SHA-256 hash in the db but not in dbx.
Signed binaries with a signature in db but not in dbx.
Binaries signed by a key in KEK or db, with neither the key nor the signature appearing in dbx.
Platform Key (PK)
The platform key establishes a trust relationship between the platform owner and the platform firmware.
The Platform Key serves as the gateway to the platform and is stored in the PK variable. Its primary role is to regulate access to both the PK variable and the KEK variable. In the majority of implementations, only one key can be stored in PK at a time, and the PK itself is restricted to being an X509 key.
If the PK variable undergoes clearance, achieved either through an authenticated variable write or a specific user-present firmware action, the platform must promptly transition into setup mode.
Updates to the PK variable are exclusively permitted through an authentication descriptor signed with the platform key.
Note: The platform key is not authorized for signing binaries for execution.
Key Exchange Key (KEK)
Key exchange keys establish a trust relationship between the operating system and the platform firmware.
The Key Exchange Key is employed for updating the signature database and resides in the KEK variable. It can be utilized to update the existing signature databases or to sign binaries for legitimate execution. In contemporary implementations, the KEK variable can accommodate multiple keys, which may be of type X509 or RSA2048, any of which can function as the key exchange key.
Updates to the KEK variable are restricted to authentication descriptors signed with the platform key.
Signature Database (db)
The signature database (aka whitelist) is employed to validate signed EFI binaries and loadable ROMs during secure mode operation. It is stored in the db variable, which may contain a mix of keys, signatures, or hashes. In secure boot mode, the signature in the EFI binary (or SHA-256 hash if unsigned) is compared with entries in the database. The image is allowed execution if:
The image is unsigned, and its SHA-256 hash is in the database, or
The image is signed, and the signature itself is in the database, or
The image is signed, and the signature verification key is in the database (with a valid signature).
Updates to the db variable are exclusively allowed through an authentication descriptor signed with the key exchange key.
Forbidden Signatures Database (dbx)
The forbidden signatures database (aka blacklist) is instrumental in invalidating EFI binaries and loadable EFIs when the platform operates in secure mode. Stored in the dbx variable, it can contain keys, signatures, or hashes. During secure boot mode, the signature in the EFI binary (or computed SHA-256 hash for unsigned binaries) is cross-referenced with entries in the database. Execution is declined if:
The binary is unsigned, and its SHA-256 hash is in dbx, or
The image is signed, and the signature matches an entry in dbx, or
The image is signed, and the key used for the signature matches an entry in dbx.
Note: Since unsigned binaries are automatically denied execution, adding a hash to dbx prevents the image from being authorized by having an entry for its hash in the signature database (as explained below).
Updates to the dbx variable are only permitted through an authentication descriptor signed with the key exchange key.
How Key Verification Works
While key verification with either X509 or RSA2048 keys may resemble TLS/SSL standards, there is a distinction: the key chain is only verified back to the key in the databases and not beyond. This implies that none of the keys must be self-signed, and the typical TLS/SSL approach of verifying all the way to the root CA is not followed.
The chain of trust is a follows
PK -> KEK -> DB | DBX
Example
Let db.key be a private signing in order to sign .efi binaries and db.crtthe corresponding public key, potentially issued by a certificate authority or self-signed. For secure boot to accept EFI binaries signed with db.key, db.crt must be added to the signature database. This implies the entry is signed with the KEK signing key, which again implies the KEK is signed with the private platform key.
Last updated