Secure Boot key compromised in 2022 is still in use in over 200 models — an additional 300 more use keys are marked ‘DO NOT TRUST’

Software security firm Binarly discovered in 2023 that devices from Acer, Dell, Gigabyte, Intel, and Supermicro had compromised Secure Boot. The cryptographic key protecting those models leaked in late 2022 in a public GitHub repository. Anyone who downloaded it could bypass the protection offered by Secure Boot.

Aside from the 2022 leak, Ars Technica also reported that over 300 more models used 21 platform keys marked ‘DO NOT SHIP’ or ‘DO NOT TRUST.’ These 21 keys were provided by American Megatrends, Inc. (AMI) as test keys to motherboard manufacturers for customizing their UEFI firmware. That means nearly all manufacturers that worked with AMI had a copy of these keys, and they’re an open industry secret known to hundreds, if not thousands, of personnel.

Binarly founder and CEO Alex Matrosov said, “Imagine all the people in an apartment building have the same front door lock and key. If anyone loses the key, it could be a problem for the entire building. But what if things are even worse and other buildings have the same lock and the keys?” He adds, “If the key will be leaked, it’s impacting the ecosystem. It’s not impacting a single device.”

Aside from the five companies impacted by the leaked key on GitHub, the following manufacturers were also affected by the testing keys: Aopen, Foremelife, Fujitsu, HP, and Lenovo. The widespread impact of this Secure Boot leak, Binarly called it PKfail (Platform Key fail), in recognition of the failure of the entire industry to practice proper management of cryptographic keys.

According to the Binarly team, PKfail highlights several issues concerning supply chain security:

• Poor cryptographic materials management and appearance of the private keys directly in the code repositories with the hardcoded path from the build scripts.
• Usage of the non-production cryptographic keys responsible for the platform security of production firmware and devices.
• No rotation of the platform security cryptographic keys per product line. For example, the same cryptographic keys were confirmed on client and server-related products. Similar behavior was detected with Intel Boot Guard reference code key leakage.The same OEM used the same platform security-related cryptographic keys for firmware produced for different device manufactures. Similar behavior was detected with Intel Boot Guard reference code key leakage.

Unfortunately, individual users cannot rectify this if they are affected. Unless the board manufacturer releases a BIOS update, you cannot fix a device with this vulnerability.

“My takeaway is ‘yup, [manufacturers] still screw up Secure Boot, this time due to lazy key management,’ but it wasn’t obviously a change in how I see the world (Secure Boot being a fig leaf security measure in many cases),” says H.D., a firmware security expert and CEO of runZero. “The story is that the whole UEFI supply chain is a hot mess and hasn’t improved much since 2016.”