UEFI secure boot: Next generation booting or a controversial debate
One of the first initiatives for secure booting has been the Unified Extensible Firmware Interface (UEFI) Initiative. UEFI is a superior replacement of the Basic Input Output System (BIOS) and a secure interface between the operating system and the hardware firmware.
The UEFI Initiative was a joint effort by many companies to minimize the risks of BIOS attacks from malware that may compromise the system. It was started by Intel and termed as Extensible Firmware Interface (EFI) for its Itanium-based systems since BIOS lacked the inherent capability to secure vulnerable firmware.
One of the aforementioned BIOS attacks was the Mebromi rootkit, a class of malware that focused on planting itself in the BIOS. Similar to the BIOS, the UEFI is the first program in the booting process and is installed during the manufacturing process of the hardware. UEFI has the inbuilt capability for reading and understanding disk partitions and different file systems.
UEFI has several advantages, including the ability to boot from large hard disks of around 2TB with a GUID Partition Table, excellent network booting, CPU-independent architecture and drivers. It uses the GUID partition table with globally unique identifiers to address partitions and has the ability to boot from hard disks with capacity of around 9.4 ZB (1024x1024x1024 GB). Secure boot is a UEFI Protocol to ensure security of the pre-OS environment.
The security policy integrated in the UEFI works on the validation of authenticity of components. UEFI has a modular design that gives system architects and hardware designers greater affability in designing firmware for cutting edge computing and for the demand for higher processing capabilities. The sequence of booting remains the same and a computer boots into the UEFI followed by certain actions and ultimately the loading of the operating system.
Furthermore, the UEFI controls the boot and runtime services and various protocols used for communication between services. The UEFI resembles a lightweight operating system that has access to all the computer’s hardware and various other functions. The transition from EFI to UEFI continues with Itanium 2 systems followed by System x machines and now we have the new Intel and AMD Series with inherent UEFI capabilities.
Once we power on a UEFI-capable computer, the code execution starts, and configures the processor and other hardware and gets ready to boot the operating system. As of this date, UEFI has been used with 32/64 bit ARM, AMD and Intel chips and for each of these platforms, there had to be a specific compilation of the boot code for the target platform. UEFI offers support for older extensions like ACPI, which makes it backward compatible with components that are not dependent on a 16-bit runtime environment. Once a system gets powered on, the firmware checks the signature of the firmware code that exists on hardware components like hard disks, graphic cards and network interface cards.
Next Option ROMs work by preparing and configuring the hardware peripherals for handoff with the operating system. It is during this process that the firmware checks for embedded signatures inside the firmware module against a database of signatures already in the firmware. If a match is found, that particular hardware module is allowed to execute. Hence, it works on a checklist of matching the integrity of signatures from the firmware database and denies further action if a particular component signature is found in the Disallowed list, which means that it may be infected with malware.
The main database is actually segmented into an Allowed and a Disallowed list. The Allowed list contains the trusted firmware modules while the Disallowed list contains hashes of malware-infected firmware and their execution is blocked to maintain the integrity and security of the system.
The original equipment manufacturer installs a unique signature and keys during the manufacturing process for the secure booting process. This trust relationship is built on a digital certificate exchange commonly known as Public Key Infrastructure (PKI). PKI is the core infrastructure of the secure boot feature in UEFI. The Public Key Infrastructure is a set of hardware and software policies used to create, manage and distribute digital certificates with the help of a Certificate Authority (CA).
The Secure Boot feature requires the firmware to have UEFI version 2.3.1 or higher. The secure booting feature mainly addresses rootkits and malware that may target system vulnerabilities even before the operating system loads. This feature even protects systems from bootloader attacks and firmware compromises. A cryptographic key exchange takes place at boot time to keep a check whether the operating system trying to boot is a genuine one and not compromised by malware or rootkits.
A while ago there was a dispute between Microsoft and the Free Software Foundation in which the latter accused the former of trying to use the secure boot feature of UEFI to prevent the installation of other operating systems such as different Linux versions by requiring the computers certified with Windows 8 getting shipped with secure boot enabled through a Microsoft private key. Microsoft controls the key signing authority and anyone who wanted to boot an operating system on the hardware certified for Microsoft Windows would have to buy Microsoft’s private key at a lucrative price. The computer hardware would itself have a copy of Microsoft’s public key and would use it to verify the integrity of the private key and check whether it is originally from Microsoft.
If any modifications are made, the verification would fail and the computer would fail to carry on the boot process any further. Microsoft then denied the fact that this strategy was built to prohibit the installation of other operating systems. It further said that it had the option to either disable the secure boot or allow the Windows 8 boot along with the secure boot feature. The developers of the open source community were concerned, since most Linux vendors did not have the power to get their certificates in the UEFI system. Red Hat, Ubuntu, and Suse would have no doubt implemented their certificates in the UEFI but the problem lies with communities like Slackware, NetBSD, and others.
The main concern was that there are many UEFI motherboard manufacturers and getting the certificates included in each of them would not be an easy task for non-commercial open source communities since it would require a lot of time and money. All the binaries needed to be signed in with certificates from the binaries’ vendor, and this was indeed a tough task. And this certificate which signed those binaries had to be imported to the UEFI, which would enable that particular operating system to function securely. The problem would arise when a hardware vendor would not allow disabling Secure Boot from the setup menu and does not install certificates from other operating systems.
In that case, the users who buy the computers with such capability will not be able to make use of open source Linux operating systems either through dual boot or single boot Linux since the secure boot feature would need the certificate from that particular operating system. The protests have taken form of Facebook pages like “Stop the Windows 8 Secure Boot Implementation” and campaigns like “Will your computers Secure Boot turn out to be Restrictive Boot” being created.
Until and unless the public key of each open source operating system was available to the hardware vendor, GNU/Linux users would fail to enjoy the combination of secure boot with the inherent security of Linux and if the option to disable the secure boot was not incorporated in that particular hardware by the vendor then life would certainly become very difficult for Linux users.
This secure boot initiative would prohibit tech people from implementing their own custom Linux flavors, and restrict them to using only what the manufacturer of the computer wants them to. The Certifying Authority (CA) would be incorporated by the computer manufacturer and he would ultimately decide whether a particular operating system has to be included or not.
A simple solution to this controversy would be making the user be the CA and giving him or her the authority to decide the choice of operating system with secure boot. But on the other hand, this would open non-technical to the danger of being tricked into using a malicious operating system. Everything has its pros and cons and that is how technology goes. Luckily, everything is not settled yet and Microsoft is still trying its best without harming the Free Software Foundation and the Open Source Community.
Red Hat, in collaboration with Canonical (the Ubuntu Community) and The Linux Foundation, published a white paper titled UEFI Secure Boot Impact on Linux. For further information regarding Linux and Red Hat, check out the Linux certification courses offered by the InfoSec Institute. The Red Hat and Canonical team further warned people that the personal computer devices will ship their hardware enabled with Secure Boot, which ultimately would be a problem for the open source distributions.
Although Microsoft clearly denies this fact, the Linux Foundation is full of anger over this initiative. Microsoft is open to the implementation of the option to disable Secure Boot in the UEFI model but at the same time, it does not strongly support it. The issue would become even more troublesome if a user wants to dual boot Linux along with Windows. Red Hat along with the Linux Foundation have worked with hardware vendors and Microsoft to develop a UEFI secure boot mechanism that would allow users to run the Linux of their choice. During its research initiative, Red Hat’s main aim was to not only provide support to Red Hat/Fedora but also to make users able to run any one they choose.
Red Hat geek Matthew Garrett, put forward a customized solution in which Microsoft would provide keys for all Windows OS, and Red Hat would similarly provide keys for Red Hat and Fedora. Ubuntu and others could participate by paying a nominal price of 99$. This would allow them to register their own keys for distribution to firmware vendors.
We have covered the advantages of having the Secure Boot feature of UEFI, but there are cons to be considered as well. Having the Secure Boot feature would require all the components of the system to be signed, which includes not only the bootloader, but any hardware drivers as well. If the component vendors wished to sign their own drivers, they would need to ensure that their key is installed on all hardware they wish to support. For laptops, a single point solution would be to make all the drivers be signed with the OEM’s keys. At the same time, this approach would be problematic for the new hardware vendors and would prevent them from entering the new market until they distributed their keys to major OEMs.
An alternative approach could be to have the drivers signed by a key included in the majority of the platforms. This would help hardware vendors from having per-platform issues. Also, if secure boot is disabled to boot an alternate OS, then this process would be limited to those who are technologically-savvy, i.e. not for the masses. Another disadvantage to the signing process is that if the signing key is disclosed and gets in the wrong hands, it may be used to boot a malicious operating system even with Secure Boot restrictions. To avoid this, the signing key would have to be blacklisted, which would prevent the operating system from booting. If the same happens with hardware vendors then the drivers would not validate and would cease the system process.
Hence, we come to a point that the UEFI Secure Boot technology is a crucial part of a Linux setup and increases the protection at the root level to fight against the use of malicious software. The only limitation is that it should not hinder user freedom by limiting its use of different operating systems. The sad part is that the current version of Secure Boot model deters easy installation of Linux and inhibits users to play with the whole system. So after a long research initiative, the open source community recommended that the Secure Boot implementation is designed around the hardware vendor who would have full control over security restrictions.
It is also recommended that the original equipment manufacturer should agree with allowing the secure boot option to be easily disabled and enabled as per the user’s choice. (This means that secure boot may be disabled through the OS and you may have the option to enable it through the firmware interface something like BIOS has.)
This would help the open source community and also help the cause of the Secure Boot initiative.