Secure UEFI boot

Secure UEFI boot

According to UEFI Wikipedia - Unified Extensible Firmware Interface (EFI) - the interface between the operating system and the firmware that controls the low-level functions of the equipment, its main purpose is to correctly initialize the equipment when the system is turned on and transfer control to the bootloader of the operating system. EFI is designed to replace the BIOS - an interface that is traditionally used by all IBM PC-compatible personal computers.

It is likely that many will soon have questions on this topic:

The UEFI Secure Boot Protocol is part of the specification for the latest UEFI release. It allows you to install one or more signed keys in the system firmware. Once enabled, UEFI “safe boot” prevents the download of executable files or drivers if they are not signed with one of the pre-installed keys. Another set of keys (Pkek) allows you to maintain communication between the OS and the firmware. The OS, together with a set of Pkek matching keys, which organizes communication with the keys installed in the firmware, can add additional keys to the so-called “white list” in the firmware. Naturally, in addition to this, she can add keys to the “black list”. Binaries that are marked in the blacklist of keys will naturally not work on boot.

There is currently no centralized UEFI key signing mechanism. If the manufacturer’s system contains a key, then the only way to get the code signed by this key is to contact the manufacturer to complete the signing. Several keys can be embedded in the system, but if you cannot use any of them to sign your binaries, they will not be installable.

This certainly has an impact on both software and hardware manufacturers. OS manufacturers will not be able to download their software in the system until it is signed with a key that is included in the firmware system. The equipment manufacturer will not be able to run its hardware inside the EFI environment until its drivers are signed with the same keys found in the system firmware. For example, when you install a new video card that has unsigned drivers that naturally were not found in your system firmware, you cannot make it work in this environment.

Microsoft's requirement is that Windows-compatible systems and systems with a client version of Windows 8 be shipped with “safe boot” enabled. Two alternative methods are proposed. The first - each copy of Windows must be signed with a Microsoft key, and its public part is embedded in all systems, or, as an alternative, the second method offers for each OEM-manufacturer to put their own key in the system and sign them with a pre-installed copy of Windows. The second way will make it impossible to run a boxed copy of Windows on Windows-compatible systems, it will also be impossible to install new versions of Windows until your OEM has signed a new version. The first option seems more likely.

A system that ships only with OEM keys and Microsoft will not be able to download copies of Linux.

Now, most likely, we can provide signed versions of Linux. But it is not so simple and several problems will appear. First, you need a non-GPL bootloader. Grub 2 is released under GPLv3, which clearly states that we provide signature keys. Grub, which is released under GPLv2, which lacks an explicit key requirement, but may contain a request for scripts used to control compilation, which may contain this requirement. This is a “gray area”, and the use of exploits will show well the dishonesty of the parties. Secondly, in the near future by design, the kernel will become part of the bootloader. This means that the kernel will also have to be signed. Which will make it almost impossible for users or developers to create (assemble) their own kernels. Finally, if we provide a signature for ourselves, it is still necessary

In principle, there are no signs that Microsoft will not allow hardware vendors to provide the “ON / OFF” function for this kind of firmware so that the user can still run unsigned code. However, experience has shown that many software manufacturers and OEMs are interested in providing the minimum firmware functionality needed for their market. It is almost certain that some systems will come with the ability to disable this feature, but on the other hand, as a result of certain agreements, it may turn out that most manufacturers will not leave the right of choice to users.

This article should not make you panic, it’s just worth considering ...

PS I want to add on my own that in the future, most likely two lines from the manufacturer may appear, more expensive with support for disabling signature verification, and cheaper, i.e. with limited functionality, especially it seems to me that this will be reflected on mobile computers (laptops, netbooks, etc.)
The original article can be found at the following link: ORIGINAL

PPS Translated in tandem with a friend, KoPBuH thanks, unfortunately it’s not yet a hub, but I hope to appear soon.