Debakl PKfail with Secure Boot-neutering is more common than anyone could have guessed

The supply chain failure that compromised Secure Boot protections in computing devices from all manufacturers affected many more models than previously thought, including devices used in ATMs, POS terminals and voting machines.

Debakl was the result of non-production platform test keys used in hundreds of device models for more than a decade. These cryptographic keys are the anchor of trust between a hardware device and the firmware that runs on it. Production test keys — marked in certificates with phrases like “DO NOT TRUST” — were never intended for use in production systems. A list of device manufacturers, including Acer, Dell, Gigabyte, Intel, Supermicro, Aopen, Foremelife, Fujitsu, HP, and Lenovo — used them anyway.

Medical devices, gaming consoles, ATMs, POS terminals

Platform keys provide a root-of-trust anchor in the form of a cryptographic key embedded in the system firmware. They establish trust between the platform hardware and the firmware that runs on it. This, in turn, forms the basis of Secure Boot, an industry standard for cryptographic security enforcement in the pre-boot environment of a device. Built into UEFI (Unified Extensible Firmware Interface), Secure Boot uses public-key cryptography to block the loading of any code that is not signed with a pre-approved digital signature.

Using the testbed keys compromises the entire security chain established by Secure Boot, because the private part that underpins their security is an open secret, known to hundreds, maybe thousands, of different people. Worse, the private part of one of the test keys was published in a 2022 GitHub post. This secret information is a necessary element in a highly sophisticated class of attacks that plant so-called rootkits that infect the UEFI of Secure Boot-protected devices.

Since the findings were disclosed in July, researchers at security firm Binarly have learned that the number of device models using test keys is much higher than previously thought. While they previously knew about about 513 models using the test key, they now know about 972. Additionally, they previously knew about 215 of the affected models using the compromised key on GitHub; they now know about about 490. Finally, they discovered four new test keys that they had not previously identified, bringing the total number to about 20. The researchers have dubbed the industry failure a PKfail because it involves PK (platform) keys.

“The complexity of the supply chain is outpacing our ability to effectively manage the risks associated with third-party suppliers,” Binarly researcher Fabio Pagani wrote Monday. “PKfail is a prime example of a supply chain security failure that impacts an entire industry. However, these risks can be mitigated and avoided altogether if we focus more on delivering a security-by-design philosophy.”

Previously, all the keys we discovered came from AMI, one of the three main providers of software development kits that device manufacturers use to customize UEFI firmware to work on their specific hardware configurations. Since July, Binarly has found keys that came from AMI competitors Insyde and Phoenix.

Binarly also discovered that the following three companies also sell devices affected by the PKfail issue:

The Monday post said: “Based on our data, we found PKfail keys and non-production keys on medical devices, desktops, laptops, gaming consoles, corporate servers, ATMs, POS terminals, and a few oddball places like voting machines.”

Binarly declined to provide specific models, citing non-disclosure agreements, since there are no patches available yet. Updated data will be discussed at next week’s LABScon security conference.

The discovery of additional device models and platform keys was made by submitting them to a free detection tool provided by Binarly. In the months since the PKfail study was published, the tool has received 10,095 unique firmware images. Of these, 791, or 8 percent, contained non-production keys.

PKfail undermines the assurances provided by Secure Boot, a protection that is mandatory for some government contractors and is required in many corporate environments. Secure Boot is also considered a best practice for those facing high-risk threats. For people or devices that do not use Secure Boot, PKfail does not pose an additional threat. Last month, PKfail was assigned CVE-2024-8105 and VU#455367.