Modern UEFI firmware relies on numerous cryptographic algorithms to ensure platform security and resilience against firmware-level threats. For example, Intel Boot Guard verifies the integrity of firmware stored in SPI flash using multiple keys and hashes, some of which are even fused into the platform hardware. Another well-known example of cryptographic verification done in UEFI firmware is UEFI Secure Boot. This technology checks the signatures of third-party modules, such as OS bootloaders, before execution to prevent OS-level malware from easily gaining pre-OS code execution.
This REsearch report follows our recent talk at RSAC 2025, where we presented new research and revisited past research sitting at the intersection of UEFI firmware and cryptography. In this research we highlight multiple failures in key management, for instance, we cover the data breaches that affected UEFI-related vendors that led to the exposure of private keys, discussing their past and ongoing consequences on the ecosystem. Using the latest available data on the UEFI ecosystem we’ll also be able to provide new up-to-date insights on these old but current issues affecting the ecosystem.
At Black Hat 2022, Binarly researchers presented a summary of weaknesses found in Pre-EFI (PEI) boot drivers. Part of the presentation focused on Intel Platform Properties Assessment Module (PPAM), a technology that allows the verifying of the integrity of the SMM code. In a nutshell, this integrity check is done by comparing a measurement of PPAM code with a reference measurement stored in a certificate found in the PPAM manifest. One of the findings from this REsearch was that many devices were shipping with an expired certificate.
To check whether this is still the case, we used our latest snapshot of UEFI firmware and scanned 21,610 firmware images which include the PPAM manifest, and found that over 67% of them still contain an expired certificate. While reviewing the results, something else also caught our attention: certain devices ship with a PPAM certificate with issuer “PPAM Root Debug Issuer Key”, contrary to the more common “PPAM Root Production Issuer Key”.
The debug certificate is present on devices released by different manufacturers from 2019 until December 2024.
Debug certificates are a known issue–our PKfail research is a great example of this–we decided to take a closer look and collected all the different versions of the PPAM binaries present in our dataset. This resulted in the identification of 1 debug build and 21 release builds. We then used the similarity and confidence scores computed by BinDiff to compare the debug build with the most similar release build, to check whether the debug build could provide any unwanted functionality that could be used to attack PPAM. Functionality-wise these two binaries seem to be equivalent, with one difference being that the release binary reads the content of a MSR (0x35), which contains the thread and core count of the CPU.
Overall, the debug PPAM and the expired certificate discussed in this section don't pose a security issue, but they highlight the complexity of UEFI firmware and how challenging is managing the related cryptographic material.
In October 2022, a GitHub repository named ICE_TEA_BIOS was created by the user LCFCASD. The true motive behind this action remains unclear to this day—whether it was an honest mistake or a malicious attack. The repository contained 6GB of data related to the Intel Alder Lake platform firmware, including the UEFI reference implementation from Intel, the IBV solution from Insyde, and the OEM implementation from Lenovo.
This repository also included multiple private keys, including 5 private Boot Guard keys and 1 Integrated Sensors Hub (ISH) keys, affecting 47 products from Lenovo, Supermicro and Intel in total.
In April 2023, MSI was the victim of a cyberattack orchestrated by the Money Message ransomware group. The 1.5TB archive released by the ransomware gang included UEFI source code and production database.
This leak also included multiple private keys used to sign and interact with different firmware components:
Earlier this year, Binarly was notified about a possible leak of Boot Guard keys included in a firmware update package for Clevo devices. After downloading the offending archive, we quickly discovered two private keys embedded in an executable binary and stored unencrypted in some files (as shown in Figure 3). We confirmed the impact of this leak by finding 15 firmware images for Gigabyte devices using the leaked keys.
Given all the described security incidents involving the leakage of Boot Guard private keys, we decided to run a retrospective scan on our dataset, to measure the incidence of leaked keys on real-world devices.
The previous histogram shows the percentage of firmware using leaked Boot Guard keys, based on the firmware’s release date. This histogram shows two interesting things. First, the spike of affected devices around 2023, which is related to the MSI and LCFC leaks. Second, in 2025 we still have a number of devices affected–even when not considering the recent Clevo leak. This is because the Boot Guard Key Manifest hash is fused into the platform hardware and, once set, it cannot be easily updated.
Last year, while developing a new feature related to Secure Boot for our Binarly Transparency Platform, we noticed that the Platform Key on some devices contained the string “DO NOT TRUST - AMI Test PK”. Since the Platform Key is the de-facto “master key” of Secure Boot, any weakness in this key could be used to bypass this protection. It didn’t take long to discover that the private part of one of these “DO NOT TRUST” keys was included in the “AAeon leak” that happened in 2023, putting millions of devices at risk.
Based on this initial finding, we started a REsearch that resulted in a massive public disclosure—considering that around 10% of firmware was affected by this issue—and advisories from many of the affected vendors. On the disclosure date, we released a free detection website for the community, which is still available at https://pk.fail. The firmware submitted to this service gave us an even clearer overview of the ecosystem’s state regarding untrusted PKs, including evidence that the issue affected more than just AMI-based devices.
Now that nearly eight months after our initial disclosure passed, with even more ecosystem-wide data available, we revisited this research and conducted another scan of our internal dataset of firmware images.
The previous figure shows the trend of affected devices over time. It’s interesting to note how the number of affected devices was steadily increasing just before our disclosure on July 28th (marked by the red purple line), after which it experienced a sharp downturn. Another positive outcome of Binarly’s disclosure and the awareness it generated is that we have not detected any affected devices released so far in 2025, suggesting that the problem may have been eradicated from the ecosystem once and for all.
While scanning our dataset, we extracted every platform key found in each firmware image. The previous table summarizes our results: for each vendor, we report the number of unique PKs found per year, as well as the total number of unique PKs. From this table, we observe that some vendors, such as Lenovo, use many different keys, whereas others, like Acer, use only a few (Acer uses 6 unique PKs in all its firmware). Each approach has its own advantages and disadvantages. Fewer keys are easier to manage, store, and secure; however, if one key is compromised, every device must be updated. On the other hand, a larger number of keys are more challenging to track and secure but the compromise of a single key would affect fewer devices.
After discovering PKfail, we turned our attention to BMC firmware. Since it has been at the center of various security-relevant findings, we checked if it was affected by an issue similar to PKfail. On some Supermicro servers, we discovered a certificate with the issuer “RD1 BMC Test Key - DO NOT TRUST”. After dissecting the boot process on Supermicro servers, we discovered that the U-Boot SPL bootloader was signed with the test key, potentially indicating that the public part of the test key is stored in the BMC OTP memory. Back then, Supermicro rejected this issue, mentioning that the NIST-compliant key hasn’t been leaked (which we agree) and that test key has similar access control and security level as production key (which we disagree, given that production certificates have smaller validity period and that the certificate’s issuer hints to have been generated and stored in a Hardware Security Module).
Given that a few months have passed since our initial disclosure, we decided to check if Supermicro firmware was updated. However, we didn’t see any updates from Supermicro. For the affected devices listed in our first report, we found that the public test key modulus is still present in the latest firmware images and that parts of the image are still signed with the test key.
Earlier this year, we discovered a vulnerable UEFI module on VirusTotal, signed by Microsoft's third-party key ('Microsoft Corporation UEFI CA 2011'). This key is often included by default in Secure Boot’s allowed database (db) since it is also used to sign shim, the UEFI application that enables Linux-based systems to boot with Secure Boot enabled. Because of this reason, the vulnerability effectively allows Secure Boot to be bypassed on any device where this key is trusted.
This is a developing story—the disclosure process with CERT/CC is still ongoing—so we can’t share the full context behind this finding yet. However, there are a few important points to note.
First, this discovery, along with the recent Secure Boot bypass from ESET (CVE-2024-7344), once again demonstrates that the Secure Boot ecosystem is vulnerable to Bring Your Own Vulnerable Driver (BYOVD) attacks. In the UEFI context, attackers can execute legitimately signed UEFI modules to gain code execution and break the Secure Boot chain of trust.
Second, this is one of the first memory corruption bugs discovered in signed UEFI modules and it was found automatically by our Binarly Transparency Platform. The core issue behind this vulnerability is that an NVRAM variable is blindly trusted and used for multiple memory writes, which allows an attacker to store any memory address in the affected variable and have multiple arbitrary memory writes. While the written value is not directly controlled by the attacker, it’s still more than sufficient to easily bypass Secure Boot, as shown in the following PoC video. Stay tuned for more details!
While monitoring how the ecosystem responded to CVE-2024-7344 (a Secure Boot bypass reported by ESET) we noticed several discrepancies between the dbx distributed by Microsoft and the version available on the UEFI Forum website. The most significant difference was that the UEFI Forum dbx was missing some hashes that were present in Microsoft’s version—particularly those hashes blocking CVE-2024-28924 and CVE-2024-23593 from execution. This discrepancy meant that any vendor using the UEFI Forum’s dbx in their firmware devices was left vulnerable to a publicly-known Secure Boot bypass for more than six months.
In the previous sections, we highlighted several weaknesses affecting Secure Boot, such as leaked keys, memory corruption in signed modules, and missing hashes. While these examples can all be used to bypass Secure Boot, they represent only a subset of a broader attack surface. In fact, any vulnerability during the early boot stages—such as in the PEI (Pre-EFI Initialization) or DXE (Driver Execution Environment) phases—can often be exploited for a Secure Boot bypass. For instance, the recent Bootkitty proof-of-concept demonstrates how LogoFAIL can be leveraged to achieve early code execution and circumvent Secure Boot.
In this section, we want to highlight why these firmware-level issues are security-critical and why Secure Boot serves as the final line of defense against attackers attempting to install a bootkit on a machine.
To demonstrate this, we recorded a demo using the latest available version of Windows 11 (Build 26100) with Secure Boot enabled. In the video, a potential attacker performs a Secure Boot bypass from a privileged terminal, adding their own unsigned module to the UEFI Boot Manager (labeled “BRLY-POC” in the demo).
Upon reboot, thanks to the Secure Boot bypass, the unsigned module is allowed execution, and after printing some ASCII art, it loads a bootkit. For this demonstration, we used redlotus-rs, an open-source bootkit written entirely in Rust, which draws inspiration from many existing bootkits including BlackLotus. The redlotus-rs bootkit hooks into the Windows Boot Manager and the Windows kernel—a behavior commonly observed among bootkits, as discussed in our recent blog post. This is a very privileged vantage point which allows bypassing any OS-level security defense and protection. In particular, as shown in the video, this bootkit patches the kernel so that any unprivileged user is allowed to load any arbitrary Windows kernel drivers.
The Google security team released an advisory documenting CVE-2024-56161, a vulnerability affecting the verification of signatures attached to AMD microcode. A privileged attacker exploiting this vulnerability can load malicious microcode and rewrite how instructions behave—effectively taking over the CPU. When we tracked the ecosystem’s response, we observed that while the original AMD advisory only mentioned AMD EPYC CPUs, microcode updates were also being released for the Ryzen family. This turned out to be an accurate finding, as AMD eventually issued the AMD-SB-7033 advisory, which includes Ryzen CPUs.
Although the technical details of this vulnerability are beyond the scope of this report, we have included it because its root cause is closely related to bad cryptography practices. In particular, Google’s research found that AMD CPUs were using the example key from the NIST SP 800-38B publication, which allowed them to compromise the cryptographic implementation and to forge valid microcode updates.
In this blog, we summarized how the UEFI firmware ecosystem has been impacted by the leak of numerous private keys and in general by failures in cryptographic key management, posing serious security threats to a wide range of devices.
The complexity of the UEFI supply chain further exacerbates this issue, as keys compromised from one vendor can easily be deployed across devices from another. In many cases, test keys intended for development purposes find their way into real-world devices, leaving them exposed to potential exploitation.
