.
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.
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
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.
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.
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.
Reference : - http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the-pre-os-environment-with-uefi.aspx
A blog posted by Microsoft Engineering Team.
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.
Figure 2 - Legacy BIOS boot path
Figure 3 - Secure boot path with UEFI
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
Background: how does Secure Boot 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.
Figure 4 - Security databases for certificates
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.
Reference : - http://blogs.msdn.com/b/b8/archive/2011/09/22/protecting-the-pre-os-environment-with-uefi.aspx
A blog posted by Microsoft Engineering Team.
No comments:
Post a Comment