By Ron Grattopp ronaldg-001_thumb2_thumb_thumb1_thum….I mentioned in my last post that I would follow up on the Trusted Boot process in Windows 8, and give you more details on it as well as Unified Extensible Firmware Interface (UEFI).  First, let’s start with a quick UEFI primer.

Historically, most Windows-based computers begin their boot process using some firmware known as the BIOS (basic input/output system).  Typically, after the “POST (power-on self-test)” stage the firmware transfers control of the boot process to the Boot Manager, which then loads an OS loader, device drivers, and the OS kernel and then continues on with the loading of the full OS including a user logon which then culminates in a “desktop” UI customized for the user.   Of course, the BIOS is rooted in the x86 processor 16-bit “real mode” era, and its limitations are due to that as well as its reliance on the MBR (master boot record) disk partitioning scheme.  However, going forward, most Windows-based computers, regardless of the processor architecture, will rely on firmware known as the Unified Extensible Firmware Interface (UEFI), which was created to overcome those BIOS limitations and better support the new generations of 64-bit processors.  UEFI itself is not new, it began back in the 1990’s with the EFI spec and then in 2005 the UEFI forum was formed, which now includes over 140 technology companies such as AMD, Apple, Dell, HP, IBM, Intel, Lenovo, and yes Microsoft to name just a few.  One of the significance aspects of UEFI, as I alluded above is that it’s processor agnostic – it can work with 64-bit versions of any processor or chipset architecture.  Because it’s 64-bit, it can also address virtually unlimited memory throughout the boot process, and it uses a GUID Partition Table (GPT) disk partitioning scheme, which supports 100 partitions and up to 16TB disk sizes.  Moreover, the UEFI drivers (known as EBC, EFI Byte Code, drivers) and applications execute in the boot environment and thus support loading of network stacks and use of hi-res graphics even if no functional OS is running yet.  And as the whitepaper states: “UEFI defines a set of boot and runtime services that have standard syntax and semantics for interfaces and data structures...This greatly improves interoperability, reduces the complexity of supporting new hardware, and helps computer manufacturers update and maintain firmware more rapidly.”  Here’s a link to that downloadable whitepaper, UEFI and Windows, if you care to know more of the gory details or the many additional features and benefits of UEFI.  Speaking of UEFI benefits, two listed as “future UEFI capabilities” in the whitepaper are: rootkit prevention and network authentication -- the ability of UEFI to support Authenticode digital signatures in the pre-OS environment means that “the firmware can verify software before it runs and make sure that no untrusted code runs before the operating system is loaded. This enables the operating system to establish a security foundation for all the other software on the computer” which is my lead in to the discussion of the Secured and measured boot features in Windows 8.

As you have probably ascertained from above the “Secured boot” process starts with the foundation of UEFI as described above.  Rootkits (and bootkits) are an increasingly popular attack vector and have been successful because they are able to insert themselves into the old BIOS boot process before the full OS and anti-malware software was loaded.  The changes to the Windows 8 boot process incorporate three elements that protect the Windows boot process from attack:
     1) as we saw above UEFI firmware allows for the checking of “digital signatures” on all software that executes
     2) Anti-malware software can now be launched much earlier in the boot process
     3) PCs with TPM chips take unique “measurements” of the software components loaded during the boot process, and can use that info to “attest” to the health (or trustworthiness) of the computer.

So the first piece of Secure booting is the implementation of the UEFI Secured Boot specification.  This spec defines a policy enforcement mechanism which ensures that only “trusted” (signed) software is executed in the boot process.  Thus if a rootkit, which is unlikely to be signed, attempts to load it will be recognized as untrusted and not allowed to execute.  UEFI doesn’t really change the boot sequence, as described above, but at every step of the process, each driver and/or executable will be validated before it is allowed to run.  And, btw, if an executable doesn’t pass the check, UEFI would be able to load an alternative executable to replace the bad one and (usually) enable the boot to complete.

Early-launch Anti-Malware (or ELAM) is the second pillar of the secure boot process.  This is pretty straightforward, as the name implies, and ensures that valid AM software is loaded and active before other components or drivers.  Currently, AM software does not load until reasonably late in the boot process and a rootkit can already be instantiated and thus “hide” from or even disable the AM software.   As you may know ALL 64-bit device drivers must be signed to work with Windows, but ELAM drivers, in particular, have to be signed by Microsoft, not 3rd-parties, and they are also identified specifically as an early load component.  There is more to the ELAM but suffice it for this post to know what it is and basically how it provides additional security to the boot process.  Also, this should be a really good story for the Security software vendors out there to know that their offerings can’t be compromised before they even get loaded.  Here’s the link to a whitepaper on ELAM if you’d like to know more about it: Early Launch Anti-Malware 

And the last aspect of our secure booting functionality is the TPM chip and a feature called measured boot which Windows can use to further validate the boot process beyond Secured Boot.  For TPM-based systems, Windows 8 will perform a comprehensive chain of measurements during the boot process, called measured boot, which can be used to validate the boot process to prevent rootkits and other malware. These measurements are stored in the TPM chip and then used later, in a process called attestation, where the measured boot feature provides the AM software with essentially a trusted log of all the loaded boot components to confirm that they are trusted thus ensuring a Windows OS load safe from malware.  Here’s a link to a TechNet article on TPM and measured boot: Trusted Platform Module Technology Overview

And here’s a link to an additional Microsoft Whitepaper on this: Trusted Boot: Hardening Early Boot Components Against Malware

OF course there were a LOT of details and additional information around Secured Boot that I didn’t include in this post, but hopefully the whitepaper links will help if you need that.  What I wanted to do here was let you know, in a somewhat specific way, why security is even better in Windows 8 than it was in Windows 7.  As I’ve said many times in my blogs, Microsoft gets security, and betting on us to provide a safe computing environment for your business (or home) is a good bet these days.

Cheers, as always,