UNCLASSIFIED
National Security Agency | Cybersecurity Technical Report
UEFI Secure Boot Customization
U/OO/168873-20 | PP-20-0652 | Sep 2020 Ver. 1.1
2
UNCLASSIFIED
resources as compared to older BIOS implementations. Native mode implements pure
UEFI and requires devices, components, and software to be UEFI-ready. UEFI Native
Mode is a requirement for utilizing UEFI Secure Boot.
Legacy BIOS Mode or Compatibility Support Module (CSM)
are accommodations for
devices and components that are not designed for use with UEFI. BIOS behavior is
emulated to allow devices incompatible with UEFI's architectural and access control
paradigms to be used on modern systems. Leveraging legacy mode or CSM reintroduces
security, access control, and memory vulnerabilities addressed by the UEFI standard and
prohibits the use of UEFI Secure Boot.
2 UEFI Secure Boot
Secure Boot is a feature added to UEFI specification 2.3.1. Each binary (module, driver, kernel,
etc.) used during boot must be validated before execution. Validation involves checking for the
presence of a signature that can be validated by a certificate or by computing a SHA-256 hash
that matches a trusted hash. Several value stores are used to identify content that is trusted or
untrusted. Figure 2 shows the sequence of checks. The value stores are:
Platform Key (PK)
is the master hierarchy key certificate. Only one PK may exist on the
system as a RSA-2048 public key certificate. In the most secure usage, PKs are unique
per endpoint and maintained by the endpoint owner or infrastructure operators. The PK
private key can sign UEFI environment variable changes or KEK, DB, and DBX changes
that can be validated by the PK certificate. The PK cannot be used for signing executable
binaries that are checked at boot time. Keep the PK private key secure and store it on a
different device.
o
Note:
A PK certificate must be in place for Secure Boot to begin enforcement.
Some vendors ship devices with random PKs or a common/shared PK. Endpoint
owners may also install their own PK as part of the customization process.
Carefully consider the balance between administrative overhead and security.
A
unique PK per endpoint provides greater security against UEFI compromise
across an infrastructure, but may reduce the speed at which administrators
can deploy changes compared to a common/shared PK.
Key Exchange Keys (KEKs)
are normally used by vendors, such as the system vendor
and the OS vendor, who have a need to update the DB or DBX. One or more KEKs are
typically present on a system as RSA-2048 public key certificates. Different endpoints may
have the same KEK(s) – they are not unique to an endpoint. KEKs may sign changes to
the DB and DBX. KEKs can also be used to sign bootable content. However, replacing a
KEK is difficult because involvement from the PK is required. Therefore, KEKs should only
be used to make changes to the DB and DBX. Remember to keep the KEK private key
secure.
Allow list Database (DB)
can contain SHA-256 hashes or RSA 2048 public key
certificates. Binaries that have signatures that can be validated by a certificate will be
allowed to execute at boot time. Likewise, binaries with computed SHA-256 hashes that
match a trusted hash will also be allowed to boot even in the absence of a signature.
Deny list Database (DBX)
can contain SHA-256 hashes or RSA 2048 public key
certificates.
The DBX has ultimate veto power at boot time.
Any binary hash that
matches a DBX hash or has a signature verified by a DBX certificate will be prevented
from executing at boot time. DBX is normally leveraged to target errantly signed binaries