Protecting the pre-OS environment with UEFI
Here is a
small blog about some of the things to keep in mind and think about when
implementing secure boot.
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.
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.
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.
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.
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.
Installing Windows to an EFI-Based Computer
If you are installing Windows to an EFI-based computer, you
must enable EFI mode in the computer's firmware. You must enable EFI mode in
both attended and unattended installations. You must boot to 64-bit EFI-mode
preinstallation media (64-bit Windows PE in EFI mode, or 64-bit Windows Setup
in EFI mode). You cannot install Windows to UEFI-based computers in BIOS mode.
(For more information about switching modes, see your EFI firmware
documentation.) The steps described in this topic are for reference only and
may not match the specific commands for your EFI firmware type.
After Windows is installed, you can make additional
configurations to your image. This Windows image becomes your master image that
you use to deploy to other computers.
To Install Windows to an EFI-Based Computer
- Install
Windows by running Windows Setup from an EFI boot entry on the master
computer. Use the EFI shell or the firmware’s “Boot from file” menu to
launch the Windows EFI Boot Loader on the installation disk. Refer to your
firmware documentation for more information.
- From
the EFI shell, select the device with the Windows installation media and
start the EFI boot application. Assuming that the DVD device is fs0, use
the following commands for x64-based computers:
Shell> Fs0:
fs0:> \EFI\BOOT\BOOTX64.EFI
For the
Itanium-based computers, use the following command:
Fs0:\EFI\BOOT\BOOTIA64.EFI
If the EFI
boot manager supports booting from a DVD, the EFI shell command is not
required. You can boot the DVD directly from the EFI boot manager.
- When prompted, press any key to
boot from the Windows DVD. Windows installs to the computer.
If you perform an attended install, follow the user interface prompts to complete Windows Setup.
Optionally, you can perform an unattended installation by using an Autounattend.xml file stored on a USB disk on key or other device. For the answer file requirements for EFI-based computers, see Create an Answer File for UEFI-based Computers.
 Note |
Some EFI
platforms support both UEFI and BIOS firmware. On some of those systems, it
is not always clear if the default DVD boot option is an EFI or BIOS boot
option. On these systems, using the EFI shell command may be required. If you
do not specifically start Windows Setup by using the EFI boot entry, the
default firmware boot entry for BIOS may be used. If Windows Setup starts in
BIOS mode on a combined EFI/BIOS system, the ESP and MSR partitions are not
created. After Windows Setup completes, use the Diskpart command to verify
that the ESP and MSR partitions were created.
|
- After Windows is installed to the
computer, complete all other customization tasks.
- From an elevated command prompt,
run sysprep to prepare the Windows image for imaging and
deployment. For example,
%WINDIR%\system32\sysprep\sysprep.exe
/generalize /oobe /shutdown
When the
Sysprep command completes, the computer shuts down.
Capture
the Windows Image
After the
Windows image is installed, you can capture the Windows image and the EFI
partition image to deploy to other computers.
- Create a network share where you
intend to copy your master Windows image and ESP image to. For example,
net use n: \\MyNetworkShare\Images
- Assign a drive letter to the ESP
by using the diskpart command. For example,
diskpart
select disk
0 //Select
the first disk
select partition
1 //Select
the ESP volume to configure
assign
letter=s //Assign
drive letter s to the ESP
exit
- Capture the ESP by using ImageX.
For example,
imagex /capture s: n:\efisys.wim
"ESP"
- Capture the Windows image by
using ImageX. For example,
imagex /capture c:
n:\OSimage.wim "Windows"
The images are ready to be applied.
Practical UEFI Secure Boot
Enabling & Disabling UEFI Secure Boot. Instructions for
setting up a system with UEFI Secure Boot to dual-boot between Microsoft*
Windows* 8 & Ubuntu* 12.10. Part 1 of 3. For additional information, please
visit the Intel® UEFI Community Resource Center at http://uefidk.com/
PlayList Intel Video
Microsoft UEFI Demo
Explore Secure Boot, also referred to as Trusted Boot, a new
security feature in Windows 8 that leverages the Unified Extensible Firmware
Interface (UEFI) to block the loading and operation of any program or driver
that has not been signed by an OS-provided key, and thus protects the integrity
of the kernel, system files, boot-critical drivers, and even antimalware
software.
UEFI Firmware FAQ's
Drs. Albert Spijkers
DBA Consulting
web: http://www.dbaconsulting.nl
blog: DBA Consulting blog
profile: DBA Consulting profile
Facebook : DBA Consulting on Facebook
Posts
0 reacties:
Post a Comment