Introduction

The UEFI specification (2.3.1c) defines several key stores and their formats:  The Platform Key (PK), The Key Exchange Key (KEK) The key database (db) and the forbidden signatures database (dbx).  This post describes the relationships between them all and how they’re implemented in the Tianocore reference implementation.  This means that not everything possible is implemented because Tianocore follows the Windows 8 hardware certification requirements closely.

UEFI Secure Variables

All of the keys are stored in UEFI secure variables (see section 7.2 of the UEFI specification).  A secure variable cannot be updated unless the person attempting the update can prove (with a digital signature on a specified payload, called the authentication descriptor) that they possess the private part of the key used to create the variable.  The UEFI specifications only allow two types of signing keys: X509 and RSA2048.  A secure variable may be cleared by writing an empty update (which must still contain a valid authentication descriptor).

Authentication Descriptor

The specifications allow two types of authentication descriptors: time based and monotonic count based.  Once a variable is created, it stores both the key that created it and the initial value for the time or monotonic count and will only accept subsequent updates signed with that key and which have the same update type (time based or monotonic count) that it was created with.  The reason for this is to prevent replay of previous updates, so a newer update must have either a later time or a higher monotonic count.  Once the update is accepted, the time or count is updated as well to the value in the authentication descriptor.

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

1. are unsigned but have a sha-256 hash that is in db and not in dbx or
2. are signed and have a signature in db but not in dbx or
3. are signed by either a key in KEK or a key in db and neither the key nor the signature appears in dbx.

Platform Key (PK)

The Platform Key is the key to the platform and is stored in the PK variable.  Its job is to control access to the PK variable and the KEK variable.  In most implementations, only one key at once may be stored in PK and the PK may only be an X509 key.

If the PK variable is cleared (either by an authenticated variable write or by a special user present firmware action), the platform must immediately enter setup mode.

The PK variable may only be updated by an authentication descriptor signed with the platform key.

Note: The platform key may not be used to sign binaries for execution.

Key Exchange Key (KEK)

The Key Exchange Key is used to update the signature database and is stored in the KEK variable.  It may be used either to update the current signature databases or to sign binaries for valid execution.  In most current implementations, the KEK variable may contain multiple keys which may be of type X509 or RSA2048 any of which may perform the function of the key exchange key.

The KEK variable may only be updated by an authentication descriptor signed with the platform key.

The Forbidden Signatures Database (dbx)

The forbidden signatures database is used to invalidate efi binaries and loadable roms when the platform is operating in secure mode.  It is stored in the dbx variable.  The dbx variable may contain either keys, signatures or hashes. In secure boot mode, the signature stored in the efi binary (or computed using SHA-256 if the binary is unsigned) is compared against the entries in the database.  Execution is refused if either

1. The binary is unsigned and the SHA-256 hash of the binary is in dbx or
2. The image is signed and the signature matches an entry in dbx or
3. The image is signed and the key used to create the signature matches an entry in dbx.

Note: since unsigned binaries are automatically refused execution, the addition of a hash to dbx serves only to prevent that image being authorised by having an entry for its hash in the signature database (see below).

The dbx variable may only be updated by an authentication descriptor signed with the key exchange key.

The Signature Database (db)

The signature database is used to validate signed efi binaries and loadable roms when the platform is operating in secure mode. It is stored in the db variable.  The db variable may contain a mixed set of keys, signatures or hashes.  In secure boot mode, the signature stored in the efi binary (or the SHA-256 hash if there is no signature) is compared against the entries in the database.  The image will be executed if either

1. the image is unsigned and a SHA-256 hash of the image is in the database or
2. the image is signed and the signature itself is in the database or
3. the image is signed and the signing key is in the database (and the signature is valid).

The db variable may only be updated by an authentication descriptor signed with the key exchange key.

How Key Verification Works

Although key verification with either X509 or RSA2048 keys looks to be SSL standard, it isn’t quite: the key chain is only verified back to the key in the databases and no further.  This means that none of the keys has to be self signed, and that the usual ssl approach to verify all the way to the root CA isn’t followed.

Some consequences of all of this

As you can see from the above, the holder of the platform key is essentially the owner of the platform.  However, simply knowing the platform key (the private part) isn’t enough because in order to change the platform you have to be able to execute binaries and the platform will only execute binaries signed by a key either in KEK or db.  If you take control of your platform by installing a platform key, you need to ensure that this key (or another you control) is also added to either KEK or db so you can sign binaries with it and have them execute.

This page is a rolling brain dump of what I’ve discovered trying to get a tianocore UEFI secure boot platform up and running in KVM