UEFI Secure Boot
UEFI Secure Boot is a feature defined in the UEFI Specification. It guarantees that only valid 3rd party firmware code can run in the Original Equipment Manufacturer (OEM) firmware environment. UEFI Secure Boot assumes the system firmware is a trusted entity. Any 3rd party firmware code is not trusted, including the bootloader installed by the Operating System Vendor (OSV) and peripherals provided by an Independent Hardware Vendor (IHV). The end user may choose to enroll and revoke entries in the UEFI Secure Boot image security database as part of managing verification policy.
UEFI Secure Boot includes two parts - verification of the boot image and verification of updates to the image security database. Figure 2-1 shows the UEFI Secure Boot verification flow. Table 2-1 shows the key/image security database used in UEFI Secure Boot.

Figure 2-1: UEFI Secure Boot

Table 2-1: Key Usage in UEFI Secure Boot
Key
Verifies
Update is verified by
NOTES
PK
New PK New KEK New db/dbx/dbt/dbr New OsRecoveryOrder New OsRecovery####
PK
Platform Key
KEK
New db/dbx/dbt/dbr New OsRecoveryOrder New OsRecovery####
PK
Key Exchange Key
db
UEFI Image
PK/KEK
Authorized Image Database
dbx
UEFI Image
PK/KEK
Forbidden Image Database
dbt
UEFI Image + dbx
PK/KEK
Timestamp Database
dbr
New OsRecoveryOrder New OsRecovery####
PK/KEK
Recovery Database

UEFI Secure Boot Image Verification

Table 2-2: UEFI Secure Boot Image Verification
Item
Entity
Provider
Location
TP
UEFI Secure Boot Image Verification
OEM
Originally on flash, loaded into DRAM
CDI
Manufacture Firmware Code
OEM
Originally on flash, loaded into DRAM
UEFI Secure Boot Image Security Database (Policy)
End user (or OEM default)
Originally on flash, authenticated variable region, loaded into DRAM
UDI
3rd party Firmware Code, (OS boot loader)
OSV
Originally on external storage (e.g. Hard drive, USB), loaded into DRAM
3rd party Firmware Code, (PCI Option ROM)
IHV
Originally on PCI card, loaded into DRAM
3rd party Firmware Code, (UEFI Shell Tool)
Any
External Storage (e.g. hard drive, USB), loaded into DRAM
Table 2-2 shows the component involved in the UEFI Secure Boot Image Verification.

Signing

In UEFI Secure Boot, the UDI is any 3rd part firmware code, including the OS boot loader, PCI option ROMs, or a UEFI shell tool. The component provider needs to sign these components with a private key and publish the public key.

Public Key Storage

The OEM or end user may enroll the public key as a CDI (UEFI Secure Boot Image Security Database). The database is in a UEFI Authenticated Variable region. The database can also be
updated during runtime. It can be read by anyone but only be written after data authentication. See Table 2 below.

Verification

During boot, the TP (Image Verification Procedure) verifies the UDI (3rd party firmware code), according to the CDI (UEFI Secure Boot Image Security Database) as policy. If the verification passes, the UDI is transformed into a CDI and the 3rd party firmware code is executed. If the verification fails, the 3rd party firmware code is discarded.
Figure 2-2 shows a verification flow using db/dbx.

Figure 2-2: Image Verification flow

Figure 2-3 shows a verification flow introducing dbt. An additional check is required based dbx signature.

Figure 2-3: Image Verification with timestamp signature database

UEFI Authenticated Variable Verification (Policy Update)

Table 2-3: UEFI Authenticated Variable Verification
Item
Entity
Provider
Location
TP
UEFI Authenticated Variable Verification
OEM
Originally on flash, loaded into SMRAM
CDI
Manufacture Firmware Code in SMM.
OEM
Originally on flash, loaded into SMRAM
UEFI Secure Boot Image Security Database (Policy)
End user (or OEM default)
Originally on flash, loaded into SMRAM
UDI
New UEFI Secure Boot Image Security Database
End user
Originally in normal DRAM, loaded into SMRAM
In Table 2-2, the CDI (UEFI Secure Boot Image Security Database) is updatable. The database itself is in the UEFI Authenticated Variable region. Table 2-3 shows the component involved in the UEFI Authenticated Variable Verification.

Signing

To update the existing Image Security Database (CDI), the new Image Security Database (UDI) needs to be signed if UEFI Secure Boot is enabled.

Public Key Storage

The signer’s public key must be enrolled in system firmware. It is the same as the public key used for UEFI Secure Boot Image Verification. The database is stored in a UEFI Authenticated Variable region.

Verification

During runtime update, the TP (Authenticated Variable Verification Procedure) verifies the UDI (new Image Security Database), according to the CDI (UEFI Secure Boot Image Security Database) as policy. If verification passes, then the UDI is transformed into a CDI, and the new Image Security Database takes effect on the next boot. If verification fails, the new Image Security Data is discarded.
For details on the authenticated variable flow, please refer to the “Implementing
UEFI Authenticated Variables in SMM with EDK II” whitepaper.
Last modified 1yr ago