upvote
Full disk encryption protects from somebody yanking a hard drive from running server (actually happens) or stealing a laptop. Calling it useless because it doesn't match your threat model... I hate todays security people, can't threat model for shit.
reply
I (the commenter you responded to) am a security engineer by trade and I'm arguing that SB is useful. I'm not sure if the parent commenter is or isn't a security person but my interactions with other people in the security field have given me the impression that most of them think it's good, too.

So I'm a little confused about the "can't threat model for shit part," I think these sorts of attacks are definitely within most security folks threat models, haha

reply
> Full disk encryption protects from somebody yanking a hard drive from running server (actually happens) or stealing a laptop.

Both of these are super easy to solve without secure boot: The device uses FDE and the key is provided over the network during boot, in the laptop case after the user provides a password. Doing it this way is significantly more secure than using a TPM because the network can stop providing the key as soon as the device is stolen and then the key was never in non-volatile storage anywhere on the device and can't be extracted from a powered off device even with physical access and specialized equipment.

reply
> the device uses FDE and the key is provided over the network during boot

An example of such an implementation, since well before TPMs were commonplace: https://www.recompile.se/mandos

reply
> The device uses FDE and they key is provided over the network during boot, in the laptop case after the user provides a password.

Sounds nice on paper, has issues in practice:

1. no internet (e.g. something like Iran)? Your device is effectively bricked.

2. heavily monitored internet (e.g. China, USA)? It's probably easy enough for the government to snoop your connection metadata and seize the physical server.

3. no security at all against hardware implants / base firmware modification. Secure Boot can cryptographically prove to the OS that your BIOS, your ACPI tables and your bootloader didn't get manipulated.

reply
> no internet (e.g. something like Iran)? Your device is effectively bricked.

If your threat model is Iran and you want the device to boot with no internet then you memorize the long passphrase.

> heavily monitored internet (e.g. China, USA)? It's probably easy enough for the government to snoop your connection metadata and seize the physical server.

The server doesn't have to be in their jurisdiction. It can also use FDE itself and then the key for that is stored offline in an undisclosed location.

> no security at all against hardware implants / base firmware modification. Secure Boot can cryptographically prove to the OS that your BIOS, your ACPI tables and your bootloader didn't get manipulated.

If your BIOS or bootloader is compromised then so is your OS.

reply
> If your threat model is Iran

Well... they wouldn't be the first ones to black out the Internet either. And I'm not just talking about threats specific to oneself here because that is a much different threat model, but the effects of being collateral damage as well. Say, your country's leader says something that makes the US President cry - who's to say he doesn't order SpaceX to disable Starlink for your country? Or that Russia decides to invade yet another country and disables internet satellites [1]?

And it doesn't have to be politically related either, say that a natural disaster in your area takes out everything smarter than a toaster for days if not weeks [2].

> If your BIOS or bootloader is compromised then so is your OS.

well, that's the point of the TPM design and Secure Boot: that is not true any more. The OS can verify everything being executed prior to its startup back to a trusted root. You'd need 0-day exploits - while these are available including unpatchable hardware issues (iOS checkm8 [3]), they are incredibly rare and expensive.

[1] https://en.wikipedia.org/wiki/Viasat_hack

[2] https://www.telekom.com/de/blog/netz/artikel/lost-place-und-...

[3] https://theapplewiki.com/wiki/Checkm8_Exploit

reply
they said network, not internet :)
reply
Secure Boot provides no useful security for an individual user on the machine they own, and as such should be disabled by default.

If you want to enable it for enterprise/business situations, thats fine, but one should be clear about that. Otherwise you get the exact Microsoft situation you mentioned and also no one knows about it.

reply
So everyday users should be vulnerable to bootkits and kernel-mode malware...why, exactly? That is useful security. The fact that people do not pursue this type of malware very frequently is an effect of SB proliferation. If it were not the default then these attacks would be more popular.
reply
Citation please.

There are so many vectors for malware, can't say I'm just going to accept this one on pure "because it's possible."

reply
You're arguing for not wearing seatbelts because no evidence has been shown that anyone has ever been saved by wearing one has been presented. That's just stupid by refuting ubiquitously understood data and facts.

SecureBoot ensures a valid, signed OS is installed and that the boot process generally hasn't been completely compromised in a difficult-to-mitigate manner. It provides a specific guarantee rather than universal security. Talking about "many vectors" has nothing to do with SecureBoot or boot-time malware.

reply
>It's necessary for FDE to have any sort of practical security

why? do you mean because evil maid attacks exist? anyone that cared enough about that specific vector just put their bootloader on a removable media. FDE wasn't somehow enabled by secure boot.

>bootkits are a security nightmare and would otherwise be much more common in malware

why weren't they more common before?

serious question. Back in the 90s viruses were huge business, BIOS was about as unprotected as it would ever possibly be, and lots of chips came with extra unused memory. We still barely ever saw those kind of malware.

reply
> anyone that cared enough about that specific vector just put their bootloader on a removable media. FDE wasn't somehow enabled by secure boot.

Sure, but an attacker could still overwrite your kernel which your untouched bootloader would then happily run. With SB at least in theory you have a way to validate the entire boot chain.

> why weren't they more common before?

Because security of the rest of the system was not at the point where they made sense. CIH could wipe system firmware and physically brick your PC - why write a bootkit then? Malware then was also less financially motivated.

When malware moved from notoriety-driven to financially-driven in the 2000s, bootkits did become more common with things like Mebroot & TDL/Alureon. More recently, still before Secure Boot was widespread, we had things like the Classic Shell/Audacity trojan which overwrote your MBR: https://www.youtube.com/watch?v=DD9CvHVU7B4 and Petya ransomware. With SB this is an attack vector that has been largely rendered useless.

It's also a lot more difficult to write a malicious bootloader than it is to write a usermode app that runs itself at startup and pings a C2 or whatever.

reply
> Sure, but an attacker could still overwrite your kernel which your untouched bootloader would then happily run.

Except that it's on the encrypted partition and the attacker doesn't have the key to unlock it since that's on the removable media with the boot loader.

They could write garbage to it, but then it's just going to crash, and if all they want is to destroy the data they could just use a hammer.

reply
The attacker does this when the drive is already unlocked & the OS is running.

Backdooring your kernel is much, much more difficult to recover from than a typical user-mode malware infection.

reply
> The attacker does this when the drive is already unlocked & the OS is running.

But then you're screwed regardless. They could extract the FDE key from memory, re-encrypt the unlocked drive with a new one, disable secureboot and replace the kernel with one that doesn't care about it, copy all the data to another machine of the same model with compromised firmware, etc.

reply
> serious question. Back in the 90s viruses were huge business,

No, they were not. They were toys written for fun and/or mischief. The virus authors did not receive any monetary reward from writing them, so they were not even a _business_. So they were the work of individuals, not large teams.

The turning point was Bitcoin. Suddenly it provided all those nice new business models that can be scaled up: mining, stealing cryptowallets, ransomware, etc.

reply
Instead of proprietary SecureBoot controlled by megacorps, you can use TPM with Heads based entirely on FLOSS with a hardware key like Librem Key. Works for me and protects from the Evil Maid attack.
reply
Anything that restricts user freedom is entirely bad, even if it's at the expense of security.
reply
But...it doesn't restrict user freedom. If the user wishes to do so, they can disable SB.
reply
And will then be locked out from an increasing amount of Applications, Media, and eventually even Websites.
reply
I run Linux with Secure Boot and I don't feel locked out of any media, applications, or websites.

My mom uses Secure Boot with Windows and doesn't know or care that it's enabled at all.

reply
They shouldn't _have_ to do anything. The point is that no demands should be placed upon users.

Same problem with age gating. It's fine, as long as zero additional demands are placed upon users.

reply
Are the demands that users become experts in provider their own security against more advanced actors not significantly worse? The control part is unfortunate but the defaults should make it so users can focus on sharing pictures of cats without fear or need for advanced cyber security knowledge.
reply
Freedom from the consequences of malware is more valuable than the low cost of turning SecureBoot off if you don’t want it.

We shouldn’t need the hassle of locks on our home and car doors, but we understand they are probably worthwhile for most people.

reply
Do you lock your house or car and permanently handover the keys to some stranger, who you then have to depend on always to lock or unlock it for you?
reply
No? I have locks on my house and car that I have the keys for. That an argument _for_ secure boot.
reply
It is absolutely not.

It's a decent one for "locks on an apartment building that someone else owns."

But no, purchasing a house ought not include by default "a set of locks that you must work around, permission-wise."

reply
Funnily enough, when you buy a house, the first task is to change all the locks.

Y’know, for security.

reply
Sure. Now, of the people who buy houses -- how many of them would find this a difficult or onerous task?

And then, do computers.

Apples and oranges here, for this point.

reply
Sorry dwattttt, I’m unable to verify your identity and your keys are disabled. If you have an issue, please fax a copy of your DUNS number.
reply
What's the improved security argument for terminating VeraCrypt's account though? SB does have clear benefits but what is unclear is the motivation for the account termination.

What's the likelihood that this account ban provides zero security benefit to users and was instead a requirement from the gov because Veracrypt was too hard to crack/bypass.

reply
Users who care enough to do so can enrol their own keys using the extremely well documented process to do that.

Users who don’t care about the runtime integrity of their machine can just turn it off.

Both options are so easy that you could’ve learned how to do them on your machine in the time that you spent posting misinformation in this thread.

reply
So like banks requiring you to have a PIN on your ATM card, even if you don’t want one… that’s bad? Seatbelt laws are bad?
reply
deleted
reply