Windows Store for developers blog
Windows 8 app developer blog
The Windows Blog
Inside SkyDrive blog
Download Windows 8 Release Preview
Windows Dev Center
Follow us @BuildWindows8
The //build/ conference
Windows 8 Release Preview forums
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Figure 5 - Samsung PC secure boot setting
Tony Mangefeste Ecosystem