This article explains about secure boot and how it is extended to Linux; RHEL7. It also provides some insights in to Linux 'trusted kernel Boot' and its 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 or corruption and theft. Malware can come in the middle of the BIOS and OS loader. It can also come in between OS Loader and OS.
Unified Extensible Firmware Interface (UEFI) is the new standard of hardware and 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 together in a 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 running binaries that are unmodified and known to the platform. This mechanism is called Secure Booting - see Microsoft 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 the secure boot mechanism here.
UEFI Secure boot:
The UEFI specification defines the infrastructure required for secure booting. Provided is a brief introduction of the terminology used in secure boot to be useful to those 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 prevents systems from running hidden malware.
These keywords are the base of a secure boot. UEFI Specifications tell more about these keywords. These specs tell in detail how to sign the binaries; see section 28
for more information.
Authenticated Variables:
UEFI provides a service called authenticated variables which means only a certified module or authentic code module can write, that is only a code module that has a key certificate can write. But any party can read these variables.
Platform key (PK):
Platform Key establishes a trust relationship between platform owner and firmware which is installed in the NVM by the platform manufacturer.
Key Exchange Key (KEK):
Key Exchange Key establishes trust between Operating Systems and the platform firmware. KEKs are installed in the platform by the OS and or third party components which want to communicate with platform firmware.
Database (DB):
Authorized Database holding the public keys and certificates of the code module that is authorized to interact with platform firmware.
DBX:
Black listed database. Any code module that matches to these certificates is not allowed to start loading.
Signature:
The private key and hash generate the Signature of the binary that is to be signed.
Certificate:
Authenticode certificate containing a public key that corresponds to the private key used to sign the image.
UEFI platform firmware loads 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 the UEFI platform. OEMs install the public part of the key in the platform DB, and the UEFI loader protocol service validates the 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 OS loaders that are signed and whose key is present in the DB to run. This key mechanism ensures that the OS loader or option ROMs are allowed to run only if they are authorized and not modified by any party.
Figure 1: UEFI platform firmware