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.