NSA Boot Security
Modes and Recommendations
Legacy (BIOS or CSM) boot
UEFI native boot
Secure boot standard mode
Secure boot custom mode
UEFI or legacy boot with TPM auditing
UEFI secure boot with TPM auditing
Legacy (BIOS or CSM) boot
Many computing devices feature a legacy boot mode called Basic Input / Output System (BIOS) mode or Compatibility Support Module (CSM).
Legacy boot modes are intended to be used with older peripherals, hardware, and software lacking support for Unified Extensible Firmware Interface (UEFI)2 standards.
Compatible with decades of solutions and protocols.
Least restrictive solution in terms of security features.
Processor vendors are discontinuing legacy mode support starting in 2020.
UEFI native boot
Unified Extensible Firmware Interface (UEFI) adheres to standards defined by the UEFI Forum.
Hardware, software, peripherals, system vendors, and solution providers collaborate to define common interfaces, variables, protocols, feature sets, and structures for use on modern computing platforms.
Binaries are arranged in the form of modules. Modules can be patched, replaced, added, removed, or otherwise altered individually as needed.
Some modules can execute in parallel to accelerate boot time.
Some modules can fail or enter error states without affecting a device’s ability to boot.
UEFI relies upon Secure Boot or vendor-specific boot protection solutions – no validation or protection of the boot process is granted simply by choosing UEFI over legacy mode.
Some older hardware and software do not function in UEFI mode.
Secure boot standard mode
Secure Boot is a signature and hash-checking mechanism added to the UEFI boot process.
Each firmware and software executable at boot time must have an associated signature or hash. Secure boot validates signatures using RSA-2048 public key certificates.
System firmware, component firmware, bootloaders, kernels, and other boot-time executables are validated by Secure Boot to provide a boot-time anti-malware solution.
Secure Boot signing authorities may make mistakes in granting signatures or loading hashes.
Bootloaders that ignore Secure Boot and boot-time malware have been mistakenly signed and released to the public in the past.
Secure boot custom mode
Custom mode allows the system owner to exert control over Secure Boot’s data stores.
The system owner assumes full responsibility for signing and hashing trusted content (e.g. bootloaders, kernels) rather than relying upon the ecosystems set up by MSFT and system vendors.
Administrators can trust specific hardware components, boot methods, and boot software. Allows system owners such granular control that they can trust an individual version of an OS kernel.
Administrative overhead is required to sign binaries and identify the hashes of items that cannot be signed.
Systems must be provisioned with a custom Secure Boot. Administrators must create custom Secure Boot update scripts.
UEFI or legacy boot with TPM auditing
UEFI and Legacy modes can record hashes of firmware components to the Trusted Platform Module (TPM). The TPM must be both activated and enabled for hashes to be written.
Hashes normally capture firmware images, firmware configurations, expansion component firmware images, expansion component firmware configurations, and the bootloader.
TPM-aware bootloaders can continue logging hashes to describe the kernel, initial file system, and any modules. Kernels, applications, and drivers can log runtime hashes to the TPM too.
TPM PCR hash extensions are automated at the firmware level from the earliest stages of boot.
Newer versions of Windows and Linux also automatically detect the presence of TPM and begin recording integrity information.
There is no automatic enforcement mechanism (TPM performs passive observation during boot).
Malware is not denied execution privileges at boot time.
Any valid UEFI, Legacy, or binary is allowed to execute without signature, hash, or integrity checks.
UEFI secure boot with TPM auditing
Secure Boot can be used in standard mode or custom mode in conjunction with TPM.
TPM provides the ability to cover the early-boot blind spot that exists in Secure Boot. Secure Boot allows the flexibility to handle multiple trusted system images, devices, and configurations when necessary.
The most restrictive option is covered. Windows 10 and newer automatically leverages Secure Boot and TPM when BitLocker is enabled.
Requires the most developer and administrator overhead.
Last updated