UEFI Secure Boot in Windows 8.1

Question

INTRODUCTION

Just as you need a battery to start a car from which the fuel power takes over, similarly you need a firmware to start the computer and bring it to a minimal functional state from which the operating system takes over.

The firmware called BIOS is a first generation computer program in the processor's assembly language which is executed by the processor to directly control the hardware. This provides the foundation for building an advanced software platform by adding logical layers incorporating increasing functionality at each layer. The core layer is an abstraction of the hardware components into software objects which are further developed through the layers into Hardware Drivers, and finally coupled to a well-defined User interface at the peripheral layer. Once this platform called Operating System gets built, the complexity of the hardware and its I/O functions are controlled by simple software commands from the User interface. The Operating System internally translate these commands into a string of low level instructions for communicating with the processor which in effect directs the hardware devices to send or receive data.

Windows 8 has re-engineered its boot method by adopting UEFI (Unified Extensible Firmware Interface) as the new firmware standard while continuing to support the legacy BIOS (Basic Input Output System) firmware standard for machines with old hardware which are not UEFI compatible. UEFI brings in newer features in the platform firmware alongwith a newer set of policies and specifications to comply with.

Platform Firmware provides the first set of instructions that run when the computer is switched on. After the platform firmware finishes detecting hardware and initializes the system, it passes control to the Bootloader program of the Operating System (OS).  Platform Firmware is embedded in non-volatile storage like programmable read-only memory (PROM) or flash memory that's directly attached to a motherboard. Firmware also resides in hardware devices like video cards and storage controllers as a driver program contained in dedicated memory chips.

The BIOS firmware program in 16-bit assembly language are a sequence of hardware specific instructions directly executed by the processor from its 1MB addressable memory space in what is termed as Real Mode . The function of the BIOS is transient during the boot process, after which the processor's Real Mode 16-bit environment gets disintegrated and the OS establishes an advanced platform structure called Protected Mode utilising the 32/64-bit capabilities of a modern processor to access the entire system memory. In protected mode, programs run on an OS rather than directly on the platform as in Real Mode. The OS interfaces with programs as a virtual platform and undertakes the task of centrally managing the allocation of memory and other hardware resources to programs, instead of each program having to manage the memory on its own as in Real mode. The OS in effect emulates as a high performance platform for programs, by efficiently managing the entire hardware through a set of high level device drivers. Protected Mode was phrased to imply that memory is protected from erroneous over-write as is possible in Real Mode, where each program is free to write to all memory locations irrespective of its use by another program.

In the UEFI firmware, only the platform initialisation tasks are performed in Real Mode, after which the UEFI builds a rudimentary operating system on the platform to enable 64-bit Protected Mode for launching the subsequent boot / firmware program in a high level language.

UEFI originally called EFI, was developed by Intel as a modern alternative to the PC BIOS. Now it's supported by an industry consortium. UEFI in essence, is a light-weight operating system, written primarily in C language, that the computer loads at boot time. Being an operating system, UEFI interfaces the computer hardware as a virtual platform for running firmware programs. The primary function of the UEFI is to boot an operating system, but it can also be used to run pre-OS utility programs such as networking, disk management, back-up/restore hard drives, edit boot configuration parameters and execute driver programs for hardware test diagnostics.

BIOS FIRMWARE

BIOS firmware was developed using assembly language for the earliest PCs in the 1970s. Although BIOS is still the most prevalent firmware type, it is limited to a 16-bit processor level program with low level instructions directly executed by the CPU; AND one megabyte (1 MB) of addressable memory space. A modern 32/64-bit processor has to emulate in 16-bit (Real Mode) in the BIOS platform as BIOS standards were developed for 16-bit platform.

A BIOS is the very first program that is executed once the system is switched on. The function of the BIOS program is to control the hardware platform till it identifies and executes the Bootloader program. The BIOS program has three phases – Hardware Initialisation, attend to BIOS configuration change request (if any) by user, boot the Bootloader program from a Hard Drive Or boot into a maintenance environment from an Optical / USB drive.

The BIOS program is stored in a ROM which can be changed only by a BIOS Flash Update utility. The BIOS stores its hardware initialisation parameters, boot data and system date-time in a CMOS chip which permits quick change to the BIOS configuration data. The CMOS chip is an ultra-low current static RAM (NVRAM) powered by a coin cell (CR2032).

The ROM acts as a storage device for firmware programs to reside in a passive state and gets activated when they are loaded (copied) into memory for execution by the processor. In the system initialisation state, when memory is not ready for use, the processor executes the first codes directly from the ROM and this ends with an instruction to copy the ROM codes into memory (RAM). The BIOS program in RAM, Data in NVRAM, and all embedded memory locations in devices containing its driver program as a BIOS subroutine, are consolidated by mapping them to a single memory-address-map to serve as an uniform logical memory structure for the entire system. The BIOS program use the logical memory address and the memory map serves translate the logical memory address into the physical address of a memory location within a Device ROM or RAM. Normally the processor executes instructions sequentially from the logical memory. A memory reference in an instruction is used to access a subroutine on a device ROM Or transfer program control to another location in the RAM.

The BIOS program had gone through numerous revisions with almost every new version of PC until it evolved into the UEFI. The following table tries to depict the typical memory utilisation of BIOS as it reached towards its end-of-life phase.

When a system is switched on, the system memory (RAM) is empty and therefore the processor doesn't really have anything to execute. The processor is thus hard coded with the first instruction (JMP FFFF0h), which is to Jump (JMP) to the memory location (FFFF0h) mapped to the BIOS ROM to begin execution of the BIOS program.

The first routine within the BIOS ROM performs the Power-On-Self-Test (POST) and Hardware initialisation tasks. The system memory (RAM) is then initialised and loaded with the BIOS ROM program. This is followed by a second Jump instruction to shift the program execution to a location in the RAM. This process is called Shadowing and is done because execution from RAM is much faster than from a ROM resulting in reduced boot time.

The second jump instruction takes the processor to a part of the BIOS program (now in RAM) which identifies those devices which must be available for user I/O and system R/W operations - keyboards, video adapters, SATA storage controllers and Optical Disc Drives. Devices are accessed either by the memory address bus or by a dedicated I/O bus consisting of device I/O ports. These devices has a self-contained driver program in a ROM (called OptionROM) directly attached to the device. The BIOS calls those OptionROM driver programs (subroutines) to invoke the device functions.

At this stage, the processor checks for an user control signal (interrupt) sent via the keyboard which sets a flag indicating a request for change of the BIOS Configuration. If the interrupt flag is found positive, the BIOS executes the BIOS GUI program which allow an user to modify the BIOS configuration data from list-options, and save it into the CMOS RAM. The PC restarts to load the latest changes in the BIOS configuration.

The final phase of the BIOS program is to identify the Boot device from a list of boot devices, defined in descending order of priority in the boot configuration. The BIOS searches for the master boot record (MBR) in the first sector of each boot device (Cylinder 0, Head 0, Sector 1), starting from the device at highest priority, and loads the first available MBR into memory location 0000:7C00h. MBR contains three pieces of information:  the master partition table, the disk signature, and the master boot code. BIOS transfers program control to the memory location 0000:7C00h and the master boot code executes, which locates the active boot partition from data in the master partition table, and loads into memory the Bootloader program (NTLDR) of the OS. At the point, when the MBR boot code loads the NTLDR Bootloader, the BIOS relinquishes control and the OS assumes control of the computer system. The NTLDR Bootloader executes to chainload or bootstrap the OS loader (winload.exe), kernel, drivers and finally complete OS program.

BIOS Vs UEFI

UEFI require hard discs in GPT partition structure, instead of the master boot record (MBR) partition structure that is used in BIOS. MBR is limited to addressing 2TB of Hard Disc Space and 4 primary partitions whereas GPT addressing space is practically unlimited and a GPT disc can have up to 128 partitions.

If Windows 8 is already installed using Legacy BIOS, it can't be converted to UEFI. A new OS installation will be required.

The BIOS is essentially a set of platform instructions (routine) in 16-bit assembly language of the processor, whereas UEFI is an Operating System that accomplishes the platform tasks through 64-bit programs in the C-language which is far more efficient than the BIOS routine.

While the startup program in both BIOS and UEFI must reside in a ROM/Flash storage, BIOS extensions are limited to device support through OptionROM, whereas UEFI extensions can be an application or device driver program which can reside on any type of storage - Hard Drive / Flash Drive / OptionROM or even a Network location.

The UEFI firmware is platform independent, and so device drivers are required to have standard commands to communicate with the device controller. The device controller electronics is responsible for translating these commands into input signals in the native format of the device. This makes it possible to test and develop standard drivers and applications irrespective of the implementation. This enables a driver to be universal type for a specific hardware, reduces the complexity of supporting new hardware, and helps computer manufacturers update and maintain firmware more rapidly.

Boot Up Time = Hardware initialisation time + Kernel initialisation time + User session initialisation time.

The processor speed is the determining factor for the Hardware and Kernel initialisation time which is nearly the same for both BIOS and UEFI. Fast boot is actually due to partial hibernation of the User session when Fast start-up is enabled in Windows (8, 10) under Power Options in Control Panel.

The BIOS starts the OS boot process at the first sector of a Hard Disc containing the MBR boot code. The MBR boot code and also the Bootloader program of the OS in the System partition are vulnerable to malware attacks during OS runtime.

The UEFI eliminates the need of a MBR boot code by triggering the OS boot process directly from the EFI SYSTEM PARTITION (ESP) of a Hard Disc. The Bootloader in the ESP is fully concealed and isolated from access by programs running during OS runtime, thus securing the Bootloader against malware attacks.

The UEFI Core firmware that comes on the motherboard ROM is open-source licensed, which allow Device and OS vendors to incorporate their own proprietary UEFI firmware as extension to the UEFI Core Firmware. This makes it possible to include at the firmware level, almost any other service that is possible by the main OS.

Another new feature that comes in UEFI is the Secure Boot process, which prevents malware from busting the firmware. Unlike an elaborate anti-malware application, Secure Boot is a simple safety measure designed for the UEFI firmware environment. Although functionally simple, it mandates some stringent compliance from all third party hardware devices and programs that must hook to the Platform Firmware. To remain flexible, Secure Boot is provided as an optional feature that can be enabled in UEFI and this is the topic of discussion in the next section.

Conclusion ! In the days of 16-bit Windows 3.1 of the early 1990's, a PC used to boot to 16-bit Disk OS (DOS). DOS used the BIOS services for all I/O operations. Windows had to be started by typing the command "WINDOWS" at the DOS prompt.

That BIOS-DOS platform concept is revived in UEFI, with UEFI performing the dual role of BIOS as a boot agent and emulates DOS by providing a pre-OS command line interface called EFI Shell, for running firmware commands and scripts. Moreover it allows 64-bit Windows to be launched from 64-bit UEFI platform rather than 16-bit BIOS.

BIOS has 3 modes of operation – Boot Mode, Setup Mode and Update Mode. The Boot Mode is used to boot an OS; the Setup Mode is used to configure the boot and other firmware settings and the Update Mode is used to update the firmware version.

In addition to the 3 modes of operation, UEFI has a fourth User Mode. In the User Mode, the EFI shell is called by an user to run firmware commands and other utility programs.

The absence of firmware utility programs in BIOS, led to the emergence of many popular third party tools distributed as "bootable CD" like the BartPE and Acronis True Image. The primary objective of these bootable CDs was to provide a repair environment in case of a System breakdown. Starting Windows Vista, Microsoft provided their own Recovery and Repair firmware shell based on Windows PE (Preinstallation Environment) on a System Reserved Partition, which could also be used to create a bootable CD through Windows Control Panel.

In UEFI based systems, firmware utility programs comes pre-installed as part of system maintenance tools built upon UEFI as extension programs, located in the EFI System Partition of the Hard Disc. In Windows 8 UEFI systems, the Recovery Shell on Windows PE continues to remain as the default repair environment. However the EFI shell can be additionally used to install and run customised diagnostic and firmware programs.

UEFI SECURE BOOT

The UEFI has implemented a Security System during boot, called "Secure Boot" which essentially comes to securing the firmware components in the boot process with a digital signature that the platform validates with a trusted key.

In most PCs today, the firmware environment is vulnerable to malware function during boot, when the original MBR bootloader has been replaced with a malicious loader called Bootkit. Bootkits own higher privileges than the OS since it has to load the OS, and thus gains the ability to manipulate the operating system and its security measures from controlling them. Bootkits gets installed through a vulnerability in the OS or in disguise through an apparently genuine software program. Once installed they are very difficult to detect, unless they engage in disruptive activities. They mostly work as spywares collecting user information.

In Windows XP, the function of the BIOS is to transfer control of the platform firmware to the Bootloader of the OS by executing the Master Boot Record (MBR), which is a small program located in the first sector of the computer hard disc that tells the computer how the hard drive is partitioned, and how to load the operating system. The MBR is susceptible to boot sector viruses that can corrupt or remove the MBR, which can leave the hard drive unusable and prevent the computer from booting up.

Windows 7 confines the Bootloader program files in the first partition of the of the Hard Disc called "System Reserved" - a 100 MB primary active partition automatically created by system at the time of Windows 7 installation. The Bootloader files in this system partition are fully concealed and isolated, thus eliminating the chances of corruption by malware.

Windows 8 further extends the secure boot implementation of Windows 7, using trusted keys in Boot Manager to ensure that only properly signed and authenticated components are allowed to execute. In addition, firmware access is limited to user control without any programmatic interface.

The Secure Boot process is owned by vendors who are certified by UEFI to digitally sign their firmware files (images) which forms part of the firmware system. These trusted vendors share their trust key with the principal trust owner of the platform, generally represented by the OEM, who has to authenticate the digital signature on every image with its trust key, before allowing them to execute.

The Windows 8 boot process is secured in three phases – Secure Boot, Trusted Boot and Early Launch Anti Malware (ELAM).

Secure Boot is localised in the UEFI firmware environment, from the ROM which being write protected acts as a safety device for the resident firmware to execute freely without authentication, to locations outside the ROM where the signature of all firmware images are authenticated before allowing them to activate. Secure Boot ends with the loading of a certified Bootloader of the OS into memory.

Trusted Boot takes over from where Secure Boot leaves off, to manage the booting of Windows components using trusted certificates. The Bootloader loads a trusted Windows 8 OS loader, the OS loader loads a trusted Kernel, and the Kernel in turn loads authenticated Windows components as part of the OS boot process. At the point when Windows needs to load third party device drivers, Trusted Boot launches the Anti-Malware driver and hands over the task of malware identification to the Anti-Malware system.

Windows 8 has prioritised the loading sequence of its Anti-Malware program so that it loads before any device drivers where rootkits are located. This process is called Early Launch Anti-Malware (ELAM). Regardless of whether you are using Windows Defender or a different anti-malware product, Windows 8 has tweaked its load process so that security software runs first. By being launched first before any third-party driver, ELAM is able to detect malware in the boot process and prevent it from initializing.

UEFI is a community effort by many companies in the personal-computer industry to upgrade the pre-OS environment. The UEFI Forum is a collection of chipset, hardware, system, firmware, and operating system vendors. The forum is responsible for developing, managing and promoting UEFI specifications. Microsoft is a board member of this forum, and the forum is open to any individual or company to join free of cost.

**Microsoft has further extended the UEFI security policy in Windows 8 certified systems built by OEMs,**to ship systems with secure boot enabled by default, which can only be switched On/Off by direct user access, and have no programmatic interface to prevent malware from disabling secure boot. Also Firmware update in ROM is allowed only through OEM's signature validation.

Key / db name	Owner	Description
Platform Key (PK)	OEM/ Platform Owner	PK enables the root trust anchor in the Platform from which the trust chain is built for Secure Boot.
Key Exchange Key (KEK)	OS Vendor	PK authorises KEK Vendors to provide the second stage trust anchors.
Authorised Database (db)	OS Vendor	db is the list of all UEFI image files anchored to the KEK.
Forbidden Database (dbx)	OS Vendor	A blacklist of keys, signatures, and/or hashes of binaries whose trust has been revoked.

The UEFI Secure Boot Keys are Trust Keys consisting of a key pair – private and public. The private key is secret to the owner of the keys, and the Public Key is distributed openly. These keys have 2 separate implementation as Public Key Encryption (PKE) and Digital Signature. The purpose of PKE is to render confidentiality to a message by encrypting it with the public key and then sending it to a recipient via an open channel, who can only decrypt the message using the secret private key. The purpose of a Digital Signature is to authenticate a software object by encrypting it with the owner's private key and enclosing the public key for ready decryption of the object, and openly distributed where confidentiality is not the requirement. In actual practice, the unencrypted object is accompanied by its digital signature which is decoded at the receiving end and compared with the unencrypted object for a veracity check. However encrypting an entire object produces an unduly large Digital Signature which is therefore reduced by a hash function.

A hash is a complex algorithm which produces a unique ID from the binary of a software object. The purpose of the hash is to prove the integrity to a software object. A hash of an object's binary is further encrypted and used as a digital signature to accompany the original unencrypted object. The receiver receives the unencrypted object and the digital signature enclosed by its public key and the hash function. The receiver uses the public key to unencrypt the signature and retrieve the hash; it then uses the hash function to derive the hash of the received unencrypted object. These two hashes if found identical, confirms the identity and the integrity of the received object.

In the UEFI platform, the secure boot process is owned by an entity which could either be a Platform Vendor or an OEM or even an Enterprise. This entity is the owner of a Trust Key pair that enables the root of trust on the platform and acts as the primal trust anchor from which the secure boot trust chain in built. The owner is responsible to digitally sign the firmware files (images) in the first stage boot process located in UEFI motherboard OptionROMs with its private key. The platform is supplied with the public key and the hash function, together called the Platform Key (PK) stored in the NVRAM. Platform security is enforced by PK which validates the digital signature of each image, before allowing them to execute. The PK thus provides the foundation from which the authenticated boot process is built.

The UEFI specification mandates two additional trust databases:

•   The Key Exchange Key (KEK) database

•   The Allowed Signature (db) database

KEK database is comprised of vendors who provide the second stage trust anchors in the secure boot chain. The KEK database contains the Digital Certificate, issued by UEFI Org. to vendors who are approved as a Certification Authority (CA) to sign their respective firmware images. These UEFI certified OS Vendors, Hardware Driver Vendors and UEFI application vendors are trusted to sign their own firmware images located in UEFI System Partition of Hard Drive, as part of the second stage Secure Boot process.

Only PK is authorised to write the vendor's digital certificate into KEK, which acts as a reference for validating the vendor credential presented during the boot process. Vendors who are defined in the KEK are allowed to write to the Allowed Signature (db) database and Forbidden database (dbx). Like the platform security owner, these vendors maintain a pair of trust keys called Vendor's Production CA, of which the private key is used to sign its firmware images and the public key is provided in the Authorised Database (db) to authenticate the firmware images at run time. The Forbidden (dbx) database is also known as the Revoked Signature or Black List database. This database identifies the revoked keys of UEFI drivers/programs that are no longer trusted and may not be loaded.

A trust chain is established where the root trust holder PK loads trusted vendors in KEK, and the KEK vendors loads trusted firmware images authenticated by the Allowed Signature (db) database. Thus PK in effect have a trust relationship with the images in db, and alongwith the images that is directly signed by it, PK reposes its trust on the entire set of firmware images that is part of the Secure Boot process.

The Allowed Signature database contains the public keys of all images located outside the OptionROMs that are part of the UEFI Secure Boot or the Windows Trusted Boot process.

During Secure Boot, the Platform Key (PK) validates the signature of firmware images executing from Option-ROMs in the first stage, and subsequently uses the trust keys in db to validate the signature of device drivers and bootloaders which are to be loaded from UEFI System Partition in Hard Drive.

As per the UEFI Specification, the chain of trust terminates when the UEFI hands over control to an operating system. During Trusted Boot, Windows continues to use the db to validate the signature of its OS loader, Kernel and Device Drivers.

Beginning Windows 8, Microsoft provides their own proprietary UEFI in Laptops manufactured under Windows 8 logo program. In assembled PCs, Windows UEFI can be installed from the Windows 8 installation media which has to be combined with Windows OS installation.

There lies a catch however. In a PC with dual OS requirement, of which one is to be Windows 8 and another non-Windows, there can exist only a single UEFI as the platform firmware. If Windows UEFI assumes the role of platform firmware, the extent to which Windows UEFI will support the booting of other operating systems from within its own UEFI, is a policy matter that is ongoing evolution amongst OS vendors as part of the UEFI committee. One thing is clear though; PCs manufactured by OEMs under the Windows 8 logo program, will not permit dual OS.

If Dual OS is a pre-requisite for a PC, then the safest choice as of now, is to install the operating systems in Legacy BIOS mode. With some time to invest, it can be a worthwhile effort to study and investigate the compatibility of the other operating system in Windows UEFI environment, at least after disabling Secure Boot.

THE  UEFI  ELEMENTS

UEFI firmware was introduced by Intel as an upgrade to the age-old BIOS which has to be customised for every other firmware type and maintained for its life time. Besides the BIOS was increasingly becoming the target of bootkits which remained generally undetectable by the Anti-malware system. The UEFI Firmware controls the computer before the OS loads and is a miniature OS itself. The UEFI Core Firmware comes embedded in the motherboard on a Flash Storage - used as a Read-Only-Memory , which is backward compatible as a BIOS firmware, the reason it is called UEFI BIOS.

The UEFI BIOS has two basic functions - launch the Bootloader to hand over platform control to the OS AND provide the Shell to manage the computer hardware. The Shell is the user environment which has a command line interface termed EFI Shell and also a graphical user interface abbreviated as GUI. The EFI Shell is used for executing platform commands, scripting, and running UEFI utility programs. The GUI is used to achieve the fundamental task of UEFI firmware settings and these parameters are stored separately in a CMOS NVRAM. To simplify the BIOS to UEFI transition, the UEFI BIOS has the same look and feel as that of a BIOS GUI.

**Thus UEFI BIOS has 4 modes of operation – Boot Mode, User Mode, Setup Mode and Update Mode.**The function of the Boot Mode is to boot the OS. In the User Mode, the EFI Shell is called by an user to run utility programs. The Setup Mode is used to configure the UEFI firmware parameters. The Update Mode is employed to update the version of UEFI BIOS from a USB stick while the platform is in firmware state. UEFI BIOS can also be updated from within the OS.

The UEFI Flash is structured into distinct regions for its boot module, runtime module and data module for initialising the platform hardware. These modules are stored in 5 separate Volumes of the Flash namely – UEFI Boot, Management Engine, Platform Data, Gigabit Ethernet and Flash Descriptor.

Each Firmware Volume can have multiple logical partitions for dividing the main module into smaller functional components. The UEFI Boot specification segments the Boot process into 6 phases with definitive guidelines for developing the firmware script for each phase. The UEFI Boot Manager controls the program flow across the 6 phases as described below.

Security (SEC) phase: When the system starts up, the CPU Cache is flushed and the processor executes the platform reset and initialisation routine directly from the Flash. Since the processor is in Real Mode, it operates through an Assembly Language Program specific to the firmware. Here the Power State determines whether to apply a Hard boot (Power-up from Shutdown) or a Soft boot (Resume from Sleep). On a Hard boot, the CPU Cache is initialised with codes from the Flash to enable a memory model that permits Stack based C-code to be executed with only a few limitations. The processor switches from 16-bit Real Mode to 64-bit Protected Mode and prepares hand-off to the PEI phase. The Security terminology is actually a misnomer as there is no security verification of codes executing in this phase. It is assumed that malware cannot target the Flash as the Flash update can happen only through signature verification.

Pre-EFI Initialisation (PEI) phase: The PEI tasks are performed through the Stack Program in the CPU cache. PEI determines the Hard/Soft boot carried-out by SEC. On a Hard Boot, the PEI initialises the RAM with the UEFI Program contained in the Flash ROM. RAM initialisation does not happen on a Soft boot as the OS environment is retained in the memory during Sleep State. PEI also loads certain modules to ensure that the platform has sufficient resources for the following DXE phase to operate the high level UEFI program in C-code.

Driver Execution Environment (DXE) phase: This phase is designed to be platform independent, where the Device Drivers are loaded into memory and executed. Secure Boot is enforced as the UEFI opens interface with devices to load their driver programs from locations external to the BIOS ROM. Most of the UEFI system initialisation takes place in the DXE phase.

Boot Device Selection (BDS) phase: BDS interprets the boot configuration data and decides on the Boot Policy to be employed. It further works with DXE to determine if the device drivers required signature verification. Accordingly the MBR boot code is loaded into memory for Legacy BIOS Boot Or the Bootloader program is loaded from the EFI partition for UEFI Boot. It also allows an user to enter Setup and choose the EFI Shell or an UEFI application as the Boot Device.

Transient System Load (TSL) phase: Depending on the Boot Device selected in the BDS phase, the firmware boots an OS loader or the EFI Shell or an UEFI application.

**Run Time

Answer 1

You. Are. Amazing.

Thank you. This was brilliantly written, and I appreciate the time it must have taken to put this together. :)

Answer 2

Very helpful article, but I am looking for something quite practical.  Where do I get the KEK and DB certificates for Win 8.1?  I'm building my own PC using a Gigabyte board with UEFI and Win 8.1.  I'm following the instructions from Intel that point to keys that don't exist on the MS site:

http://uefidk.intel.com/content/tutorial-practical-uefi-secure-boot-part-1-3

Seems I need these if I'm starting from scratch.  Where can I get them?  Thanks.

Answer 3

Thanks Sushovan!  I checked my UEFI bios and don't see the secure boot option.  It's a Gigabyte GA-Q87m-d2h so I'll contact their support.  Windows 8.1 is complaining that SecureBoot is not enabled so I must not have got it.  Thanks.

Answer 4

Hello John,

I think the UEFI BIOS is that of Gigabyte and not of Microsoft. The Secure Boot option is a Win 8 proprietary security feature applicable only on Microsoft Windows UEFI OS.

Windows UEFI OS can only be installed at the time of Windows 8 installation.

The other meaning of proprietary is "My way or the highway" when it comes to taking control of the Platform :)

Regards,

Sushovon Sinha