> you are now secure against petty criminals stealing your data
Ordinary disk encryption would protect me too here, wouldn't it?
Ordinary disk encryption would protect me too here, wouldn't it?
https://security.stackexchange.com/questions/267222/full-dis...
So, there are two scenarios here.
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.
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.
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.
Coreboot supports secure boot, so why isn't that sufficient?
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.
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.
This is equally true for coreboot.
Here is there list of supported hardware: https://doc.coreboot.org/mainboard/index.html
Also, heads seems to use coreboot also.
> 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
If you want something that will hold your hand a little more, then one of the downstream projects might be a better fit.
I'm satisfied I've backed up my points though.
> That wasn't what you asked for
Here's a quote from my earlier comment:
>> Can I compile coreboot with Secure Boot from source and reflash my UEFI/BIOS with it?
I don't see how I could formulate it better. You seem to evade the actual answer. I'll continue to think this is impossible.
I've shown it's possible to flash hardware and have an entirely open source and auditable secure boot implementation which is better than your current solution in a number of ways. That was all I had a burden to prove, and I've met it.
If you want further help or convincing, I'd suggest interacting with an AI to get answers to your questions.