Protecting the pre-OS environment with UEFI

There have been some comments about how Microsoft implemented secure boot and unfortunately these seemed to synthesize scenarios that are not the case so we are going to use this post as a chance to further describe how UEFI enables secure boot and the options available to PC manufacturers. The most important thing to understand is that we are introducing capabilities that provide a no-compromise approach to security to customers that seek this out while at the same time full and complete control over the PC continues to be available. Tony Mangefeste on our Ecosystem team authored this post. --Steven

Quick summary

  • UEFI allows firmware to implement a security policy
  • Secure boot is a UEFI protocol not a Windows 8 feature
  • UEFI secure boot is part of Windows 8 secured boot architecture
  • Windows 8 utilizes secure boot to ensure that the pre-OS environment is secure
  • Secure boot doesn’t “lock out” operating system loaders, but is a policy that allows firmware to validate authenticity of components
  • OEMs have the ability to customize their firmware to meet the needs of their customers by customizing the level of certificate and policy management on their platform
  • Microsoft does not mandate or control the settings on PC firmware that control or enable secured boot from any operating system other than Windows

The big picture – no compromises on security

The UEFI secure boot protocol is the foundation of an architecturally neutral approach to platform and firmware security. Based on the Public Key Infrastructure (PKI) process to validate firmware images before they are allowed to execute, secure boot helps reduce the risk of boot loader attacks. Microsoft relies on this protocol in Windows 8 to improve platform security for our customers.

 Diagram of Windows 8 platform integrity architecture: 1. Secure boot prevents running an unknown OS loader. 2. The kernel launches Early Launch Anti-Malware (ELAM) drivers first, and they enforce policy for 3rd-party drivers and apps. 3. Measurements of the system start state were recorded in the TPM during boot. 4. To prove a client is healthy, the antimalware software can quote TPM measurements to a remote verifier.
Figure 1 – Platform integrity architecture

Microsoft is working with our partners to ensure that secured boot delivers a great security experience for our customers. Microsoft supports OEMs having the flexibility to decide who manages security certificates and how to allow customers to import and manage those certificates, and manage secure boot. We believe it is important to support this flexibility to the OEMs and to allow our customers to decide how they want to manage their systems.

For Windows customers, Microsoft is using the Windows Certification program to ensure that systems shipping with Windows 8 have secure boot enabled by default, that firmware not allow programmatic control of secure boot (to prevent malware from disabling security policies in firmware), and that OEMs prevent unauthorized attempts at updating firmware that could compromise system integrity.

Most of these policies are not new to UEFI firmware, and most PCs today carry some form of firmware validation. Even the existing legacy support, such as BIOS password, is a form of secure boot that has been under OEM and end-user control for years. However, with secure boot & UEFI, the industry and Microsoft are raising the bar to create greater system integrity and health, and to provide customers with a strong level of protection against a growing class of threat.

What is UEFI?

UEFI (Unified Extensible Firmware Interface) is managed through the UEFI forum, a collection of chipset, hardware, system, firmware, and operating system vendors. The forum maintains specifications, test tools, and reference implementations that are used across many UEFI PCs. Microsoft is a board member of this forum, and the forum is open to any individual or company to join free of cost.

UEFI defines the next generation firmware interface for your personal computer. The Basic Input and Output System (BIOS) firmware, originally written in assembly and using software interrupts for I/O, has defined the PC ecosystem since its inception – but changes in the computing landscape have paved the way for a “modern firmware” definition to usher in the next generation of tablets and devices.

The intent of UEFI is to define a standard way for the operating system to communicate with the platform firmware during the boot process. Before UEFI, the primary mechanism to communicate with hardware during the boot process was software interrupts. Modern PCs are capable of performing faster, more efficient block I/O between hardware and software, and UEFI allows designs to utilize the full potential of their hardware.

UEFI allows for modular firmware design that enables hardware and system designers a greater flexibility in designing firmware for the more demanding modern computing environments. Whereas I/O was limited by software interrupts, UEFI promotes the concept of event-based, architecture-neutral coding standards.

What is secure boot?

UEFI has a firmware validation process, called secure boot, which is defined in Chapter 27 of the UEFI 2.3.1 specification. Secure boot defines how platform firmware manages security certificates, validation of firmware, and a definition of the interface (protocol) between firmware and the operating system.

Microsoft’s platform integrity architecture creates a root of trust with platform firmware using UEFI secure boot and certificates stored in firmware. A growing trend in the evolution of malware exploits is targeting the boot path as a preferred attack vector. This class of attack has been difficult to guard against, since antimalware products can be disabled by malicious software that prevents them from loading entirely. With Windows 8’s secured boot architecture and its establishment of a root of trust, the customer is protected from malicious code executing in the boot path by ensuring that only signed, certified “known good” code and boot loaders can execute before the operating system itself loads.

In most PCs today, the pre-operating system environment is vulnerable to attacks by redirecting the boot loader handoff to possible malicious loaders. These loaders would remain undetected to operating system security measures and antimalware software.

Existing boot processes: BIOS > Any OS loader code > OS Start
Figure 2 - Legacy BIOS boot path

Windows 8 addresses this vulnerability with UEFI secure boot, and using policy present in firmware along with certificates to ensure that only properly signed and authenticated components are allowed to execute.

Secured boot win Windows 8: Native UEFI 2.3.1 > Verified OS loader only > OS Start
Figure 3 - Secure boot path with UEFI

Secure boot is only a part of the Windows 8 Platform Integrity story. Along with UEFI, Microsoft’s strategy is a holistic approach to other available hardware to further enhance the security of the platform.

Background: how does it work?

Powering on a PC starts the process of executing code that configures the processor, memory, and hardware peripherals in preparation for the operating system to execute. This process is consistent across all platforms, regardless of underlying silicon architectures (x86, ARM, etc.).

Shortly after the system is powered on, and before handoff to the OS loader occurs, the firmware will check the signature of firmware code that exists on hardware peripherals such as network cards, storage devices, or video cards. This device code, called Option ROMs, will continue the process of configuration by ensuring that the peripheral is prepared for handoff to the operating system.

During this part of the boot process firmware will check for an embedded signature inside of the firmware module, much like an application, and if that signature matches against a database of signatures in firmware, then that module is allowed to execute. These signatures are stored in databases in firmware. These databases are the “Allowed” and “Disallowed” lists that determine if the booting process can continue.

Diagram showing Allowed list and Disallowed (Malware Hashes) lists controlled by KEK and platform key certificates
Figure 4 - Security databases for certificates

This figure represents the hierarchy of signatures and keys in a system with secure boot. The platform is secured through a platform key that the OEM installs in firmware during manufacturing. This is the process used today on most shipping systems, regardless of whether they are based on UEFI, or legacy BIOS. (Applications like firmware update utilities will use the platform key to protect the firmware image.) Other keys are used by secure boot to protect access to databases that store keys to allow or disallow execution of firmware.

The Allowed database contains keys that represent trusted firmware components and, more importantly, operating system loaders. Another database contains hashes of malware and firmware, and blocks execution of those malware components. The strength of these policies is based on signing firmware using Authenticode and Public Key Infrastructure (PKI). PKI is a well-established process for creating, managing, and revoking certificates that establish trust during information exchange. PKI is at the core of the security model for secure boot.

What is required for secure boot?

Secure boot requires firmware that meets or exceeds UEFI revision 2.3.1. The UEFI forum ratified the latest revision which updated the policies of Chapter 27 to improve upon the existing secure boot protocol to include time-authenticated variables, stronger keys for encryption, and clarification on how those certificates are stored.

The feature would be transparent to the consumer purchasing a PC. The benefit is that their system has an added measure of reliability from bootkit and rootkit attacks that target system vulnerabilities before the operating system itself even loads, as described above.

Who is in control?

At the end of the day, the customer is in control of their PC. Microsoft’s philosophy is to provide customers with the best experience first, and allow them to make decisions themselves. We work with our OEM ecosystem to provide customers with this flexibility. The security that UEFI has to offer with secure boot means that most customers will have their systems protected against boot loader attacks. For the enthusiast who wants to run older operating systems, the option is there to allow you to make that decision.

A demonstration of this control is found in the Samsung tablet with Windows 8 Developer Preview that was offered to //BUILD/ participants. In the screenshot below you will notice that we designed the firmware to allow the customer to disable secure boot. However, doing so comes at your own risk. OEMs are free to choose how to enable this support and can further customize the parameters as described above in an effort to deliver unique value propositions to their customers. Windows merely did work to provide great OS support for a scenario we believe many will find valuable across consumers and enterprise customers.

Image of a console with options for TPM Configuration: Enable virtualization [enabled], CSM Support [Disabled], Attempt Secure Boot [Enabled], Display Rev. Info - Intel UEFI...
Figure 5 - Samsung PC secure boot setting

Tony Mangefeste
Ecosystem