I still genuinely struggle to understand the advantage of UEFI/Secureboot whatever over BIOS.
I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.
Theoretically you hook up your whole disk encryption to your secureboot and it protects you against "evil maid" attacks. But yeah I'm pretty sure in practice it's about making it harder to install Linux or watch imported Blurays.
I suspect the actual reason is a lot more banal, it's enterprises asking for it.
People who own fleets of devices and need to keep them secure don't care about homegrown Linux distributions, they want to minimize the fallout from that one employee installing the "FlashPlayer update" again. Those are the people driving the concerns of Microsoft and computer vendors.
> People who own fleets of devices and need to keep them secure don't care about homegrown Linux distributions, they want to minimize the fallout from that one employee installing the "FlashPlayer update" again.
How does secure boot help with that? Those kind of users aren't going to be pulling the CMOS battery to reset the BIOS password.
Presumably drive encryption is necessary anyway to protect lost/stolen devices, and at that point modifying the bootloader won't be useful.
I see the value when the attacker manages to modify the device without the user knowing, and causes them to unknowingly use an attacker-controlled OS, but that's a vastly different threat model.
I'd argue that it's neither necessary nor sufficient for securing your data. (Convenience is another worthwhile consideration, of course.)
Cryptography should be enough to protect you from brute force, if you care about such things. I don't think it would be controversial to say that it's much more likely your particular secure enclave is broken than your encryption scheme (assuming you choose something appropriate and you're not on the NSA's radar).
> Some kind of secure enclave is necessary to prevent brute force attacks.
Eh maybe, what's the realistic threat model here? 99.9% of the time someone stealing a laptop isn't going to know or care what's on it, they'll just wipe it and sell the hardware. And in the rare case where you're seriously concerned about a competitor or spy making a targeted attack, you'll have a password policy where you're not using something bruteforceable.
The supposed attack scenario is that the laptop is returned in a trojaned form with a kernel-based keylogger. The usual counterargument is that the laptop might be as well returned with a hardware-based keylogger.
You should be able to do what you want to it. You should also be able to configure it such that only you can do what you want to it, and nobody else can.
Secure Boot protects against boot kits, malware that replaces the bootloader and backdoors the OS as it boots and before any other security protections kick in. Real world bootkits have been found in the wild, and we've even seen them use vulnerabilities in signed (now revoked) bootloaders, so we know secure boot has forced their developers to work harder. You may not be worried about that as a risk (well, until you are) but there are real people who this has genuinely protected.
Is it worth it by default? Completely reasonable separate discussion to have. But is there a reason it exists? Absolutely.
Stick a BIOS password on your machine and turn on Secure Boot.
Unless there's an exploit in your firmware, you are now secure against petty criminals stealing your data to even somewhat sophisticated attacks from non-state actors via data exfiltration, software keyloggers, etc.
You can go another step further and use Secure Boot in a chain of trust up to the kernel with Linux, ensuring everything up to the kernel from boot isn't tampered.
Secure Boot isn't about protecting yourself from the OS or software, it's about establishing a chain of trust from the boot process up so you are running the system you intend to run.
This comment assumes you're using disk encryption on top of Secure Boot. When doing FDE, unless your firmware supports it, part of the boot process must be unencrypted to spin up encrypted disk access, and to protect that process, you can sign the unencrypted software to ensure its authenticity despite lack of encryption.
First, PC with FDE + normal boot gets stolen. The attacker cannot get the data without the password, so it's safe.
Second, unattended FDE + normal boot PC gets tampered with. Attacker manipulates the bootloader. Unsuspecting user later boots the tampered PC, unlocks the FDE, gets owned.
The second case requires a professional, dedicated attacker. I use TPM with Heads and a hardware key to protect myself against it. It will notify me if the boot partition or BIOS are tampered with.
As an advantage, all relevant code running on my computer is FLOSS and auditable, unlike the Secure Boot and UEFI.
And yes, getting back to the original topic, I believe that against petty criminals, even a full disk encryption is plenty defense. They won't go about installing anything to the EFI partition just to get to the data.
This Coreboot + Heads setup I'd trust to protect against even the more involved.
Unless your BIOS/UEFI supports full disk encryption unlocking of hardware-encrypted Opal drives, you will always have an unencrypted bootstrap process at early boot from the disk.
That unencrypted bootstrap process can be modified by anyone with access to the disk, physical or remote. Theoretically, someone can inject a keylogger into the process and exfiltrate your encryption key's password, or a process that waits until you're decrypted and exfiltrates your data. It's also a potential vector for ransomware, root/boot kits, etc.
What you've described in that comment is just kind of reinventing the wheel. You're solving the same problem a different way, in a way that has slightly more complexity than just using UEFI and secureboot.
The main difference is that the user owns the root of trust and doesn't have to blindly trust a (buggy) proprietary software from a commercial company. Also, the community review.
The reference implementation is not the same as knowing which code runs on "your" hardware and having all keys from "your" hardware. If you are protected by a steel door but you don't have the keys, you are not safe, you are imprisoned.
This seems like a ridiculous argument. There is a fully source open source secure boot implementation, that if you have concerns about it you can fully audit, just as you can fully audit your current setup if you wanted to - but almost certainly have not.
So you are suggesting me to audit an implementation which I do not necessarily run and there's no way to know if I do. What's the point? How will it help?
The code running on my hardware is open, so anybody from the community can audit it and I have a possibility to verify that this is what I run at least by reflashing it. And I did reflash it. This approach is getting more reliable with more software becoming reproducible.
> So you are suggesting me to audit an implementation which I do not necessarily run and there's no way to know if I do. What's the point? How will it help?
No, I'm pointing out your, what seems to fundamentally be contrarian, alternative method that you are preferring because it is 'open', is no more secure than the coreboot secureboot implementation. Your concern seems to be based on the idea that the coreboot secureboot implemetnation could have sus code in their, but that is equally true for your heads setup. Unless you audit both, or pay to have both audited, either could have problem code.
Your position is an irrational inconsistency.
> The code running on my hardware is open, so anybody from the community can audit it and I have a possibility to verify that this is what I run at least by reflashing it. And I did reflash it. This approach is getting more reliable with more software becoming reproducible.
Can I compile coreboot with Secure Boot from source and reflash my UEFI/BIOS with it? If yes, then you have a point. I would appreciate the corresponding link to the source and supported devices.
Thanks, I already know where the coreboot source is (and I'm already using it with Heads). Concerning Secure Boot, I only found this (emphasis mine):
> soc/amd/common/block/psp: Add platform secure boot support
>
> Add Platform Secure Boot (PSB) enablement via the PSP if it is not already enabled. Upon receiving psb command, PSP will program PSB fuses as long as BIOS signing key token is valid. Refer to the AMD PSB user guide doc# 56654, Revision# 1.00. Unfortunately this document is only available with NDA customers
It's mostly about your UEFI firmware coming with a set of trusted CAs to verify bootloader is built by one of the trusted parties like Microsoft or Canonical or Redhat or...
You can turn it off, or make it into trust-once and sign your own bootloader, and avoid the risk of bootkit getting installed ever, except with exploits like these.
Unless the software vendor requires it to be locked down hard. Microsofts certification requirements for ARM devices back in 2012 explicitly required secure boot and prohibited custom certificates.
It would be fine it were only that. The actual problem is that software vendors can and do use Secure Boot to also check if you, the machine's owner, "decided" to "trust" this set of special CAs - and if you did not (and limited your freedom to execute any code you want in any way you want it on your machine in doing so), make the software you bought/licensed from them - or any other software you would like to run on top of these vendors' platforms - refuse to work on your machine.
As example, FaceIT Anti Cheat only works if Secure Boot is enabled. I guess their argument is that they can ensure you only boot genuine Windows and thus they can better check if you've tampered with anything.
well then thats on me and i misunderstood. I thought that with secure boot enabled a tampered operating would not boot and therefore the anti cheat can expect that if secure boot is enabled the os is legit. but yea if secure boot enrollment can be faked then my point doesn't stand anymore.
"BIOS vs UEFI" and Secure Boot are two different things.
UEFI supports the latter if you want and configure it, but it's not a requirement of UEFI, and technically a BIOS could also implement signature verification of the boot sector.
>I own a piece of hardware, so I can do what I want to it.
It's not a feature for you, it's for enterprise/corporations. You might be the user of the PC, but your employer owns it, and they want it as locked down as possible both from you and from other potential bad actors.
TPM has to be there. If you have a machine that doesn't support a high enough version your OS vendor will refuse to give you any support and if you have secure boot disabled the software you try to run might refuse to work. Today, you can disable secure boot and have a degraded experience, tomorrow, who knows?
Then buy a machine without TPM. Or buy games that don't require TPM.
Of course online multiplayer games are gonna have more stringent device security requirements to try to deter cheaters on the PC platforms. Companies aren't gonna mass produce new HW and SW customized to your own individual desires just because you want something else than the masses of consumers don't care about.
Vote with your wallet if TPM bothers you. Otherwise I don't see what your argument stands on.
If an attacker gains root privileges on your system, an attacker can modify the bootloader on your boot device to load a different kernel than the one you have installed, possibly one that the attacker uploaded that may have backdoors, etc.
Secure boot requires that the bootloader match a hash derived from a TPM-stored key.
Of course, you get the same protection (and update hassle) by storing the bootloader in something that can't be written except when you specifically enable it.
A better scheme than the UEFI secure boot/TPM junk is simply a 2GB SD card (enough to hold a bootloader, kernel, and initrd) in an SD card reader with a physical read/write switch. When it's time to update your bootloader or kernel, flip the switch to write mode, then flip it back - heck the system could even refuse to boot if write mode was enabled on boot.
Honestly I don't know why the whole PC firmware shouldn't be on that SD card. Corrupt unbootable BIOSes can be fixed with a new SD card.
For remote updates, the physical switch could be replaced with a GPIO pin and a Raspberry Pi that you connect to and log into separately. It's less secure than the physical switch but oodles more secure than what's there now - maybe not oodles but at least the software on a Pi is much higher quality than UEFI vendors.
So I guess if you provide a key for the bootloader, the firmware will sign it when it's in setup mode? I guess that private key is embedded directly in the firmware then? I presume that's made invisible once control is handed to the bootloader somehow ...
No, the firmware never has any private keys. You sign offline with a private key and provide the public key to the firmware. All further bootloader updates are signed with the same key and require no additional firmware configuration.
If an attacker has root privileges to my Linux system, what's stopping them from overwriting my Linux kernel image in my boot partition with one that has backdoors?
How is secure boot stopping them from overwriting my kernel image on the first place? Won't it just report that the kernel image was tampered and thus you cannot boot to the system?
It does nothing to prevent overwriting the kernel image.
If secure boot is operating as designed, the boot loader will refuse to boot the replacement kernel (because its hash is not on a list).
Now if you ask, how is secure boot stopping an attacker from overwriting libc or some other important system library? the answer is nothing is stopping it on Linux, but on ChromeOS, MacOS, Windows and the two mobile OSes, the secure-boot machinery has been guarding against that for years.
I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.