Live data from Hacker News

Authenticated Boot and Disk Encryption on Linux (2021)

0pointer.net

51–60 of 75 posts

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#51
post #20

Earlier quoted context omitted.

In a data loss situation you image the drive and decrypt it with your recovery key. That has nothing to do with secure boot. You won't lose access to the drive, the issue is that you want to mostly not use that recovery key all the time.

With normal full disk encryption, every user has memorised the secret needed to recover the disk, because you get reminded of it every time you boot. The TPM is intentionally designed to make sure this is no longer the case. Seems like a downgrade to me, from a disk recovery perspective.

Storing infrequently used private documents safely is something everyone in the modern world has familiarity with.

Very few people have any familiarity with the risk model of encryption, even if they need or should have encryption (with should have including: providing cover for people who need encryption by making encryption common). And even more people write down passwords rather then remember them.

For example: disk encryption keys basically never change, even if you change the password. So intercepting an image of the encrypted disk at time point A, and then intercepting the user typing the same password in at time point A+N gives you the password to decrypt the disk. You can also reverse the order of this.

If you boot your laptop up from a cold boot in any public area and enter your encryption password, then it's high probability a local security camera has just taken the password. So the attack model can be "get a shot of someone typing on the keyboard in public" and then later "image the drive and crack at your leisure".

If someone gets a copy of your drive image at an earlier point in time, then you change the password, then you mention what your old password was (because it's now "safe" right?), then you've just given them the ability to decrypt the old disk image, and probably the current one too (since they still have a copy of the encryption headers and thus the master keys, which didn't change).

With TPM based factors, these attacks become worthless: the drive separated from the computer, even if you know the user's password, can't be decrypted. The user changing their day-to-day password on the drive is a secure event because the password only works with the computer it's attached too, not independently.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#52

Earlier quoted context omitted.

> no more bootloader: please use the kernel instead This had a post on HN before and I didn't find the arguments terrible compelling. I'm curious what security advantages they might be able to say exist though.

IIRC from a presentation the main point behind NMBL is to not reimplement an entire OS in the bootloader like GRUB. Instead you should use the kernel with an Initrd instead and should kexec if you wanna boot into a different kernel. That way you only really need to take care of the existing kernel and userspace security. The problem with that is that it starts to muddy the TPM PCRs (read: makes the PCRs that should b…

The last two paragraphs are my thoughts exactly. NMBL acts like it's solving a problem but I just see it creating more.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#53
post #4

I'm surprised that the author doesn't mention Pureboot [0] or even Heads [1], the most user-friendly [2] way to use TPM on Linux and authenticate the boot process along with /root, /boot directories. 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…

Why is this downvoted?

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#54
post #49

Earlier quoted context omitted.

This mechanism makes perfect sense from the POV of every user ( especially developers, who are often high-value targets) who isn't currently working on/actively contributing to low-level OS development. This is not a concern, unless your personal definition of computing freedom is equivalent with running Gentoo. If you want to tinker, there's always an escape hatch. Even macOS freely allows you to disable FileVault o…

I have no idea why having freedom would not include running Gentoo. Gentoo, as a matter of fact, offers lots of freedom. Its package manager has built-in capability to distinguish licenses. You can choose between systemd or openrc. Musl or glibc. You can disable all sorts of configure options you don't want or need. You can use it stand-alone or inside another distro. You can specify cpu flags for the compiler global…

I think the persons point was that for the average user freedom requires a lot of technical knowledge and fiddling. Gentoo is an example of a free system that needs a lot of technical knowledge and fiddling.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#55

Earlier quoted context omitted.

I have no idea why having freedom would not include running Gentoo. Gentoo, as a matter of fact, offers lots of freedom. Its package manager has built-in capability to distinguish licenses. You can choose between systemd or openrc. Musl or glibc. You can disable all sorts of configure options you don't want or need. You can use it stand-alone or inside another distro. You can specify cpu flags for the compiler global…

I think the persons point was that for the average user freedom requires a lot of technical knowledge and fiddling. Gentoo is an example of a free system that needs a lot of technical knowledge and fiddling.

I picked on Gentoo because there's a vocal group of people who believe that unless you can trivially swap PID 1, your operating system is holding your freedom back. (And yes, I am saying this as someone who surgically swapped PID 1 to runit when Debian switched to systemd. I had more free time and less perspective.)

Let's put things differently. ssh-keygen(1) gives you the complete freedom to NOT have a passphrase on your private key, but asks you to provide one BY DEFAULT, which is the more secure choice. What you do with that choice is entirely up to you, but defaults matter, especially in security.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#56
post #55

Earlier quoted context omitted.

I think the persons point was that for the average user freedom requires a lot of technical knowledge and fiddling. Gentoo is an example of a free system that needs a lot of technical knowledge and fiddling.

I picked on Gentoo because there's a vocal group of people who believe that unless you can trivially swap PID 1, your operating system is holding your freedom back. (And yes, I am saying this as someone who surgically swapped PID 1 to runit when Debian switched to systemd. I had more free time and less perspective.) Let's put things differently. ssh-keygen(1) gives you the complete freedom to NOT have a passphrase on…

I don't quite get the arguments against the topic at all: if you don't want the added security, you can continue as you do now; and if you do want it, then you can compile and sign the entire software chain yourself; or get the precompiled one. Don't seem like there are any downsides here, or are there?

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#57
post #56
post #55

Earlier quoted context omitted.

I picked on Gentoo because there's a vocal group of people who believe that unless you can trivially swap PID 1, your operating system is holding your freedom back. (And yes, I am saying this as someone who surgically swapped PID 1 to runit when Debian switched to systemd. I had more free time and less perspective.) Let's put things differently. ssh-keygen(1) gives you the complete freedom to NOT have a passphrase on…

I don't quite get the arguments against the topic at all: if you don't want the added security, you can continue as you do now; and if you do want it, then you can compile and sign the entire software chain yourself; or get the precompiled one. Don't seem like there are any downsides here, or are there?

The downside is that one company holds the keys to the castle for this particular security scheme.

Also, saying freedom requires technical knowledge and fiddling is a non sequitur. Technical knowledge and fiddling is possible with freedoms 1 and 3. Without technical knowledge and fiddling you still benefit from freedoms 0 and 2. Thus, software freedom applies to everyone irrespective of skill level.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#58
post #5

> the attacker takes the harddisk from your laptop while you aren't watching > 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.

No. Anyone trying to tamper with your laptop that had that would do the same as you and take a photo to restore.

It's practically impossible to repeat a pattern with tiny colorful particles.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#59

Earlier quoted context omitted.

No. Anyone trying to tamper with your laptop that had that would do the same as you and take a photo to restore.

It's practically impossible to repeat a pattern with tiny colorful particles.

I realize now you are talking about using the nail polish to detect if a screw has been removed as opposed to checking if the screws had been taken out and put back in a different order.

In that case, I would say 1) Nowadays with high res photos and various types of printers, I do think a pattern could be printed back onto a screw head, 2) there is no way you would be checking this every time the laptop was out of your site, let alone reapplying the polish, 3) there are numerous significantly simpler methods that achieve a better result.

Re: Authenticated Boot and Disk Encryption on Linux (2021)

#60

Earlier quoted context omitted.

It's practically impossible to repeat a pattern with tiny colorful particles.

I realize now you are talking about using the nail polish to detect if a screw has been removed as opposed to checking if the screws had been taken out and put back in a different order. In that case, I would say 1) Nowadays with high res photos and various types of printers, I do think a pattern could be printed back onto a screw head, 2) there is no way you would be checking this every time the laptop was out of yo…

> I do think a pattern could be printed back onto a screw head

I've never seen anything like that and don't believe it's practical. 3D-printed patterns will not look the same.

> there is no way you would be checking this every time

This entirely depends on your threat model and how much you suspect a tampering at specific conditions. In principle, you could even (automatically?) take a picture of all screws regularly and compare it with the original using some other, trusted device. In the worst case, you will find out about the tampering later, but it's a very different case than not knowing at all, forever.

> there are numerous significantly simpler methods that achieve a better result

What is simpler depends on the threat model and a person. But I don't disagree. For me, Secureboot is not a better method anyway.

Post reply on HN