Fortunately, there's an easy alternative if you want to protect against evil maid attacks: use full disc encryption and keep the bootloader (and key) on a usb drive on your person.
Fortunately, there's an easy alternative if you want to protect against evil maid attacks: use full disc encryption and keep the bootloader (and key) on a usb drive on your person.
Secure Boot is trustable, if you remove the vendor keys and reprogram the platform key with one under your own control. Likewise, the TPM is useful for protecting your secrets, not just enforcing DRM, if you take ownership of it and make use of the sealed key policies. See the safeboot.dev threat model[2] for how these protections are applied and how they detect or prevent many sorts of attacks.
1: https://mjg59.dreamwidth.org/35742.html 2: https://safeboot.dev/threats/
...you have verified the silicon of your TPM chip, motherboard, etc.
The purpose of Secure Boot is to validate that the bootloader is trusted so that you can have some assurance that you're not giving your disk encryption password to a fake bootloader which phishes you.
Secure Boot doesn't give any agency more control over your machine than if you were not running Secure Boot. Using Secure Boot is strictly more secure than not using it, even if you don't trust the parties who made the implementation.
The only argument against it is that it provides a false sense of security, which is only a problem if you decrease security in other areas as a result of using Secure Boot.
And additionally trusting them even with the possibility for a NSL that very likely was sent to them in the past already and means they probably have an automated pipeline for handing over the keys to federal institutions.
I'd never trust any OEM BIOS with anything. Just as I won't trust Intel ME.
Or are you literally replacing all OEM firmware, using purely open hardware. Using purely open source firmware. Verifying the firmware you have corresponds to the sources you have. Verifying that there is no additional secret firmware you don't know about, verifying that the hardware you have actually corresponds to the open hardware specs you have, etc. i.e. Doing an insane amount of steps that are so impractical, you might as well make your own computer starting from first principles.
What you can do though is trying your best that you can influence with your own skillset. I would never claim that any device is secure (heck, eversince BadUSB not even my power transformator is) but I'd have a better feeling when using coreboot that I configured, built and flashed via my CH341a adapter instead of an OEM SeaBIOS, for example. I mean, software is my skillset. Software I can influence. Hardware: not so much.
I don't know whether there are government-level exploits available for coreboot or libreboot, but I think that's the level of security where we can just dump our hardware into the trash anyways.
Additionally I don't have the skillset of verifying that a RISC-V chipset is really open, verified or secure. Therefore I would have to trust somebody else to do it, which might become the centralized point where the red tape fails for all of us.
When it comes to open hardware, mntmn [1] got pretty far already. Even though I personally think that the touchpad is still unusable in terms of modern UX. But I really admire them for what they do, and that they do not compromise on their core principles.
the only acceptable phrasing of "I don't trust anything" is to finish that sentence with "... therefore I don't use computers" ... the very idea of using computers means that data is processed. and so eliminating all attack surface is not to play.
You can "not trust" computers, and use them.
If you spend $1000 (or equivalent in time/whatever you care about) mitigating a risk that at worst would cause you $10 worth of damage, that is a poor use of resources.
Of course some people like locking things down as a hobby. Nothing wrong with that, but at that point you're doing it for fun, not to protect yourself.
I wouldn't want to do that on x86 platform though. A64 SoC is simple enough that getting close to this ideal is possible.
> With a Librem Key linked to your encrypted drive, you can boot your system, insert your key, and enter your PIN when prompted. You can always fall back to your passphrase if your Librem Key isn’t at hand.
Emphasis mine. Since the bootloader is not protected, it's susceptible to evil maid attacks.
https://puri.sm/posts/the-librem-key-makes-tamper-detection-...
or here https://docs.puri.sm/Librem_Key/Getting_Started/User_Manual....
So the bios that boots your USB in a hypervisor can't read what you type?
Thats what TPM can sort of help with.