UEFI (Unified Extensible Firmware Interface)
Last updated
Secure Execution Environments
Last updated
Current firmware interface for PCs
Replacing Basic Input and Output System (BIOS)
Its goal was to define a standard way for the operating system to communicate with the platform firmware during the boot process
Instead of the former primary mechanism, software interrupts
UEFI allows for modular firmware design
Enables hardware and system designers a greater flexibility in designing firmware for modern computing environments
Firmware validation process.
Defines how platform firmware manages security certificates, validation of firmware, and a definition of the interface (protocol) between firmware and the operating system.
Goal: validate an OS bootloader
Platform Key (PK)
(Usually only one) asymmetric key pair
Should be under the control of the platform owner
Key Exchange Key (KEK)
Set of Asymmetric key pairs
Controlled by the OEM and OS vendors
KEKs can only be changed by the PK owner.
Forbidden signatures database (blacklist, dbx).
Hashes of blacklisted firmware code.
Signature database (whitelist, db).
Key or certificates of keys that validate signatures over authorized firmware code.
Hashes of allowed firmware.
KEK owners can update both databases.
Firmware code is not allowed to execute if its hash is in DBX.
Firmware code is allowed to execute if:
It is signed by a key in DB; or
Has its hash in the DB; or
Is signed by a KEK key.
They are stored in UEFI secure variables.
Each variable is bound to a public key.
Set upon its creation.
Variables can only be changed if an authentication descriptor is provided.
With a signature made with the corresponding private key.
Authentication descriptors cannot be reused.
To avoid replay attacks.
PK, KEK, db and dbx can be changed without checks.
The secure boot is off.
PK, KEK, db and dbx cannot be changed without verification.
PK, KEK -> requires PK signature
db, dbz -> requires a KEK signature
