Secure Boot overview

This article will explain about secure boot and how it is extended to Linux; specifically RHEL7. It will also provide some insights in to Linux ‘trusted kernel Boot’ and implications on user space applications.  

Secure boot is designed to prevent root kits being installed at boot time in memory using mechanisms like option ROM and MBRs to get loaded in to the OS, hijacking the system control and remaining hidden from anti-malware programs.  This problem has grown over time to play a significant role in data loss/corruption and theft. Malware can come in middle of BIOS and OS loader. It can also come in between OS Loader and OS.

UEFI is the new standard of hardware/software interface for modern server platforms with a rich set of UI, modularity and standard interfaces for IHVs to develop device drivers in UEFI that work seamlessly in pre-boot environment that is more flexible than a legacy bios environment. UEFI adoption across operating systems and platforms continues to grow, with many of the major client and server OS versions supporting it. 

Led by Microsoft, the UEFI standards body identified a way to prohibit boot time malware rootkits from being installed using a mechanism of loading and executing binaries that are un-modified and known to the platform. This mechanism is called Secure Booting - please see Microsoft way of Secure boot for the Microsoft information and in similar ways different OS vendors incorporated different ways to achieve secure boot. 

Secured UEFI platforms load only software binaries, such as option ROM drivers, boot loaders, OS loaders, that are unmodified and trusted by the platform.  UEFI specification describes in detail about secure boot mechanism here.  

UEFI secure boot:

The UEFI specification defines the infrastructure required for secure booting. We will provide a brief introduction of the terminology used in secure boot to be useful to thos who want to understand in greater detail.

Secure Boot does not protect the system while running and its data. Secure Boot stops booting to the OS if any component is not authenticated in the boot process which will prevent systems from running hidden malware.

These key words are the base of secure boot. UEFI Specification tells more about these key words. These specs tell in detail how to sign the binaries; specifically see section 28.

Authenticated Variables: UEFI provides a service called authenticated variables which means only a certified module or authentic code module can write i.e. only a code module that has a key certificate can write. But any party can read these variables.

Platform key (PK): Platform Key establishes trust relationship between platform owner and firmware which is installed in the NVM by the platform manufacturer.

KEK: Key Exchange Key establishes trust between Operating Systems and the platform firmware. KEK’s are installed in the platform by the OS and/or third party components which want to communicate with platform firmware.

DB:  Authorized Database holding the public keys and certificates of the code module that is authorized to interact with platform firmware.

DBX: Black listed DB. Any code module that matches to these certificates will not be allowed to start loading.

Signature: Signature is generated by the private key and hash of the binary that will be signed.

Certificate: Authenticode certificate containing public key that corresponds to the private key used to sign the image    

UEFI platform firmware will load the third party drivers, optionROMS, and OS loaders that are signed by the Certification Authority (CA), in this case Microsoft. Any hardware vendor can write their drivers in UEFI BIOS and get it signed by Microsoft to run on UEFI platform.  OEMs install the public part of the key in the platform DB and the UEFI loader protocol service validates signature of the binary against the authorized DB before it is allowed to run on the platform. This chain of authentication continues from the UEFI to the OS loader and OS.

In summary, UEFI allows to run OS loaders that are signed and whose key is present in the DB. This key mechanism ensures that the OS loader or option ROMs are allowed to execute only if they are authorized and not modified by any party.


Figure 1: UEFI platform firmware