A supply chain failure that compromises Secure Boot protections on computing devices from across the device-making industry extends to a much larger number of models than previously known, including those used in ATMs, point-of-sale terminals, and voting machines.
The debacle was the result of non-production test platform keys used in hundreds of device models for more than a decade. These cryptographic keys form the root-of-trust anchor between the hardware device and the firmware that runs on it. The test production keys—stamped with phrases such as “DO NOT TRUST” in the certificates—were never intended to be used in production systems. A who’s-who list of device makers—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 the root-of-trust anchor in the form of a cryptographic key embedded into the system firmware. They establish the trust between the platform hardware and the firmware that runs on it. This, in turn, provides the foundation for Secure Boot, an industry standard for cryptographically enforcing security in the pre-boot environment of a device. Built into the UEFI (Unified Extensible Firmware Interface), Secure Boot uses public-key cryptography to block the loading of any code that isn’t signed with a pre-approved digital signature.
Use of the test platform keys compromises the entire security chain established by Secure Boot because the private portion underpinning their security is an open secret that’s known to hundreds or possibly thousands of different people. Making matters worse, the private portion of one of the test keys was published in a 2022 post on GitHub. This secret information is a necessary element in a highly sophisticated class of attacks that plant so-called rootkits that infect the UEFI of devices protected by Secure Boot.
Since disclosing the findings in July, researchers at security firm Binarly have learned that the number of device models using the test keys is much larger than previously known. Whereas previously they knew of roughly 513 models using a test key, they are now aware of 972. Additionally, they previously knew that roughly 215 of the affected models used the key compromised on GitHub; they now know of about 490. Finally, they discovered four new test keys they hadn’t identified before, bringing the total number to about 20. The researchers have dubbed the industry-wide failure PKfail, because it involves PKs (platform keys).
“The complexity of the supply chain is overgrowing our ability to effectively manage the risks associated with third-party suppliers,” Binarly researcher Fabio Pagani wrote Monday. “PKfail is a great example of a supply chain security failure impacting the entire industry. However, these risks could be mitigated and totally avoidable if we focus more on delivering a secure-by-design philosophy.”
Previously, all discovered keys originated from AMI, one of the three main providers of software developer kits that device makers use to customize their UEFI firmware so it will run on their specific hardware configurations. Since July, Binarly has found keys that originated with AMI competitors Insyde and Phoenix.
Binarly has also discovered the following three vendors also sell devices affected by PKfail:
Monday’s post went on to say: “Based on our data, we found PKfail and non-production keys on medical devices, desktops, laptops, gaming consoles, enterprise servers, ATMs, POS terminals, and some weird places like voting machines.”
Binarly officials declined to identify specific models, citing non-disclosure agreements because no fixes are yet available. The updated figures will be discussed at the LABScon security conference scheduled for next week.
The discovery of additional device models and platform keys came through submissions to a free detection tool provided by Binarly. In the months since the PKfail research was published, the tool received submissions of 10,095 unique firmware images. Of those, 791, or 8 percent, contained the non-production keys.
PKfail undermines the assurances provided by Secure Boot, a protection that is mandated for some government contractors and is required in many corporate settings. Secure Boot is also considered a best practice for those who face high-risk threats. For people or devices that don’t use Secure Boot PKfail poses no added threat. Last month, PKfail was assigned the designations CVE-2024-8105 and VU#455367.