UEFI Secure Boot: Hundreds of computers have insecure crypto keys

Security experts found more than 900 computers with UEFI firmwares, each containing an insecure platform key (PK). This undermines Secure Boot.

Save to Pocket listen Print view
Screenshot of the BIOS setup of a Mini-PC with an untrusted UEFI Platform Key (PK)

Screenshot of the BIOS setup of a Mini-PC with an untrusted UEFI Platform Key (PK).

(Image: c’t Magazin)

4 min. read
Contents
This article was originally published in German and has been automatically translated.

Many PC and mainboard manufacturers are sloppy when it comes to implementing UEFI Secure Boot. This finding is not new, but now the company Binarly is reporting another variation: The UEFI BIOS of many computers contains a so-called platform key (PK) that is untrustworthy or insecure.

Numerous desktop PCs, notebooks and mainboards are delivered with a UEFI BIOS that contains a PK from BIOS supplier American Megatrends (AMI) that is expressly classified as untrustworthy.

The computer magazine c't had already documented individual cases months ago in test reports of mini PCs from the Chinese companies Mele and Zotac. However, the error has been known for some time.

What is new, however, is Binarly's discovery that devices from well-known companies such as Acer, Dell, Gigabyte, Intel and Supermicro are also affected. Security researchers have discovered them on more than 900 different systems that are potentially used by millions of people.

Binarly provides a website where BIOS images can be uploaded for testing- for example, the files from BIOS updates. Those who assemble desktop PCs themselves can find these files on the product pages of the mainboards.

Binarly calls the vulnerability "PKfail", but does not provide a risk assessment according to the standards for Common Vulnerabilities and Exposures (CVE). According to Binarly, an insecure PK can be exploited to bypass UEFI Secure Boot. However, this also requires administrator rights on securely configured computers.

On a PC where the BIOS setup can be called up without entering a password, any attacker with physical access to the device can disable UEFI Secure Boot anyway.

An insecure PK in the UEFI BIOS therefore does not pose a particularly serious risk for most computers. However, this can change if attacks emerge that specifically exploit insecure PKs.

Companies that deliver a UEFI BIOS with an insecure or explicitly marked as untrusted PK have either not understood the concept of UEFI Secure Boot or their quality control is not working properly. Both indicate that the manufacturer does not take firmware security very seriously.

Some of the insecure UEFI PKs are clearly marked as untrusted.

(Image: c’t Magazin)

Firmware should be digitally signed and a PC should also check this signature before loading its UEFI BIOS. Otherwise, a manipulated BIOS can be loaded onto the system undetected.

The PK has nothing to do with this firmware code signature. The PK is only important for UEFI Secure Boot. It protects the so-called Key Exchange Key (KEK). This in turn is necessary so that the operating system can use functions such as Windows Update or the Linux Vendor Firmware Service (LVFS/Fwupdate) to change the databases for secure and insecure boot loaders located in the BIOS flash memory. This is used to subsequently lock boot loaders that are recognized as insecure or faulty.

Microsoft (for Windows 10/11 and Server) and several Linux distributions (with SBAT) are currently making far-reaching changes to the concept of UEFI Secure Boot. Security vulnerabilities such as BootHole and BlackLotus have proven in recent years that the original concept of Secure Boot has numerous shortcomings.

Under Linux, the command

sudo efi-readvar

command from the previously installed efitools package to find out immediately whether the PK is marked as untrusted. On Windows, this can be done with tools that can be installed for PowerShell.

Binarly has published a list of affected computers on GitHub. Further information can be found in Binarly advisory BRLY-2024-005.

(ciw)