Authenticated Boot and Disk Encryption on Linux (2021)

This makes sense from the perspective of making a kitchen appliance for the home consumer market. It makes no sense at all from the perspective of making a Unix-like operating system with four freedoms from scratch and ensure it stays that way.

  Developing trustworthy Linux-based systems in an open-source way
  Common git repo for hosting Boot-firmware
  Accelerating Linux Kernel Boot-Up for Large Multi-Core Systems
  Leveraging and managing SBAT revocation mechanism on distribution level
  Using U-boot as a UEFI payload
  Measured Boot, Secure Attestation & co, with systemd
  Secure Launch - DRTM solution on Arm platforms
  no more bootloader: please use the kernel instead
  OF != UEFI

( https://www.tomshardware.com/news/crucial-samsung-ssd-encryp... https://community.wd.com/t/what-do-you-think-of-the-security... https://www.zdnet.com/article/flaws-in-self-encrypting-ssds-... https://techreport.com/news/256-bit-aes-encryption-broken-in... https://security.stackexchange.com/questions/134564/how-secu... and some Defcon(?) files I can't find now - no success with Intel ? )

I've never understood why people keep making this incredibly weak argument for secure boot.

Secure boot makes sense for a college computer lab, where any disk encryption is better than nothing, and you can't give everyone the password or it'd defeat the point.

Secure boot makes sense if you're a Microsoft-only company, as it's a closed-source OS anyway and Microsoft have the code-signing keys. It means your users only have one password to type in - and helpdesk can reset it remotely if a user forgets.

Secure boot makes sense if you're making something like an xbox or tivo where you want disk encryption but you can't give the owner the password, as they're the adversary you're trying to protect against.

And yet people instead ignore these benefits, and go for this spy thriller nonsense as if people are going to be crawling through the air vents and abseiling from the ceiling to interfere with my computer? If you're going to pretend to be James Bond you'd better also be learning ballroom dancing, kung fu, skiing and foreign languages.

Also, there is no Microsoft involved in my laptop, i.e., the author's statement

> Microsoft's certificates are basically built into all of today's PCs

is wrong. I enjoy the coreboot with Heads on my Librem 14 with my own keys.

[0] https://docs.puri.sm/PureBoot.html

[1] https://github.com/osresearch/heads

[2] https://puri.sm/posts/pureboot-101-first-boot-first-update-a...

Have the bootloader boot automatically into an encrypted guest OS, and have it obtain the key transparently from the TPM. This way the hard drive can not be read outside of the machine. The guest OS allows easy login, can be used to let people borrow your pc in a trusted way, and can also serve as plausible deniability when asked to log in in front of authorities or otherwise being intimidated or forced.

Then configure the bootloader to boot an alt OS or show a boot menu for a specific key combo, and enter a passphrase to boot into the real, 'hidden' OS.

He also misses the point with the attack scenarios. If you luks encrypt your data and choose a good passphrase, the brunt is done against theft. Protecting against bad passwords is futile in the long run. (Will elaborate if requested.) That someone images your drive for offline bruteforce or manipulates your boot binaries is rare. The true benefit of signed boot chain is to have security patches work reteoactively, "compromise recovery". Automated attacks and malware from the internet side are way more common.

Imagine one of your daemons is compromised. As long as it does not escalate privileges, it can only gain persistence via corruptable data files or config accessible to itself. Now a patch comes along that closes the hole that reinfects the daemon. The malware will not start on daemon restart.

With signed booting you can bring that to the kernel and root.

Signed booting with rollback protection into a known good state. As long as the malware is not part of that system it won't run on launch.

But who signs my stuff, especially my own scripts and automation? Me of course, if I had good tooling.

If that became normal malware would just steal the key.

A TPM or other keybearer device lets you conditionally unlock a signing key.

So to sign, you can boot your system into a runlevel / target / ... that does not run auxiliary scripts from writable locations. If that state is measured by the TPM, you can sign.

With good enough tooling this is workable.

If implemented well, this even helps maintenance of the system.

In the state of things now, its a horrible convoluted mess that doesnt give extra security but 10 more points at which you can break your boot.

+ UEFI itself is again a complexity monster full of holes on very many machines. The whole x86 preboot stack amd or intel is a horrible complexity monster.

> You'll never notice they did that.

Won't you be safe if you put a colorful nail polish to your laptop screws and take picture of its pattern? Then you regularly compare the actual pattern with your picture.