Secureboot is a technology introduced in 2012 that was meant to solve a plethora of issues: rootkits, evil maid attacks, bootkits, etc. With the introduction of Secureboot, the foundation was officially laid for Windows (and other platforms) to improve security. However, there was a problem, and this problem reared its ugly head when in 2022 a developer accidentally leaked the Microsoft Secureboot key used for many Windows PCs on Github; there is a singular root of trust that, if leaked, would go unpatched for many users (notably those on older or certain current computers). To make matters worse, when the issue was investigated further, it was found that some UEFI manufacturers were using test keys. This means that many computers using "Secureboot" didn't even have a valid root of trust, making Secureboot a completely worthless feature on those devices! Furthermore, due to recent events, even if your computer had a valid root of trust THAT root of trust is now compromised.
Secureboot's actual security is somewhat debatable, Secureboot on its own only checks for two things: that you're running the correct bootloader, and that you are running a valid kernel. On a system with no UEFI protection, this is a very weak root of trust, and it's practically security theater on Linux where other parts of the boot process are left completely unverified. Secureboot is not a comprehensive root of trust, but rather requires a comprehensive strategy with multiple technologies being used to verify hardware security, boot process, kernel and drivers, and the userspace.
This latest hack is a major problem for many computers' root of trust, Windows and Linux users alike now depend on Microsoft for their security. Assuming you had a model that didn't use test keys, you're trusting a singular entity with your root of trust and THAT is a major problem when leaks happen. The fact is that on many computers, this exploit is not going to be patched. If there is no root of trust, the other technologies Microsoft deploys to keep the system safe cannot be trusted either. If compromised at the UEFI/Boot level, it should be assumed that all warnings or checks are easily bypassed. While Windows users were effectively pwned, this is a case where Linux users have an option to take back their security.
Most UEFI vendors allow for one to enroll their own security keys, this is a significant step forwards in user freedom and security. Linux users have the opportunity to create their own keys, sign their own bootloader, and take back their root of trust on their systems with the only downside of having to protect their Secureboot keys alongside data. Another system Linux users can use is Trusted Boot, a boot security system where a trustworthy computer state is measured upon boot using TPM, using the human as a final check. From there, users can verify the state of their system. Two noteworthy Trusted Boot implementations on Linux are Anti Evil Maid and TPM2 TOTP. These systems both work by sealing a secret to the TPM using the current PCRs, and then on boot the human verifies that the secrets are correct. Trusted Boot is a system that can not only verify the boot process, but also that the UEFI was not tampered with, and even part of userspace. It is a very powerful tool, but it means the human has to be aware of changes. This means that the human should not use the computer while inebriated, sleepy, or under duress. Finally, we need to talk about Safeboot. Safeboot is an attempt to implement verified boot on Debian and Ubuntu, using technologies like Secureboot, Unified Kernel Images, Trusted Boot, DM-Verity, and the tamper protection features found in Thinkpad laptops. At the time of writing, Safeboot is the strongest implementation of verified boot seen on Linux, securing UEFI, Kernel, and userspace. The way Safeboot does this is through a creating unique Secureboot keys, creating a Unified Kernel Image containing all of the components needed for boot, signing this image, setting up TPM2-TOTP, and rounding off everything with a DM-Verity filesystem. What this effectively means is that Safeboot is very similar to Android verified boot, capable of even resisting escalations to root. While the Safeboot script has not been updated in some time, the process the script goes through is documented very well. Users should look to Safeboot as the gold standard for secure computing on Linux, and if they can't use Safeboot they should try to replicate the features of Safeboot as best as they can on their distro. If you can't do this, at the very least create your own Secureboot keys, sign your own bootloader, and set up Trusted Boot alongside it. From there, look into technologies such as DM-Verity or FS-Verity for your next step.
You should not just trust Secureboot, and don't just take my word for it, look at Microsoft's boot process and see if they completely trust Secureboot. On its own, the protection Secureboot offers is pretty weak, and at the time of writing Microsoft's Secureboot setup cannot be trusted. Linux users should take back their root of trust from Microsoft, and overall distributions may want to create their own Secureboot keys for the user to optionally enroll (similar to how Graphene OS implements Verified Boot). Combining this with an option to automatically setup Trusted Boot on install would be a massive increase in Linux distribution security, with very little usability impact. With this latest exploit, Windows users unfortunately have no choice other than waiting for Microsoft/vendors to fix the issue (assuming they have a new computer), or buying a new computer entirely. PKFail, as it's being dubbed, has left the Windows security landscape decimated at the time of writing. Things may improve in the future, but at the cost of forcing the user to enroll a new Secureboot key, or at the cost of the user needing to buy new hardware.
return to home return to mobile site