Authenticated Boot and Disk Encryption on Linux • Hacker News Board

Re: Authenticated Boot and Disk Encryption on Linux

#151

Post by yyyk » Thu, Sep 23, 2021, 4:36 PM UTC

Iolaum wrote: post #145

yyyk wrote: post #132

Earlier quoted context omitted.

I think btrfs subvolumes can do this? However btrfs doesn't (yet?) support encryption.

I am using BTRFS and FDE encryption right now on Fedora Silverblue for a year if not more. And like the post says, I am typing two passwords.

I'm talking about filesystem level support, not block level support. FDE is block level and of course will work on any supported filesystem including btrfs.

What btrfs doesn't do is support encryption inside the filesystem a la fscrypt - where we can encrypt specific directories - or ZFS encryption, where we can encrypt specific filesystems inside a pool.

If I understand btrfs right, supporting encryption/verification on subvolume or directory levels would allow splitting the system so only part of it is encrypted/verified (so we get Poettering's performance gains), while avoiding space issues between the subvolumes.

Also, using only one password is easy on fscrypt style systems, though this may not suit everyone's threat model.

Re: Authenticated Boot and Disk Encryption on Linux

#152

Post by thayne » Thu, Sep 23, 2021, 4:37 PM UTC

On most linux distros the initrd is dynamically generated, and depends on the specific hardware. So it isn't possible for the initrd to be signed by the vendor. Is it possible for the TPM to verify such a dynamically created file during boot?

Also, requiring a TPM for decrypting the hard drive has a security/usability tradeof. If the TPM dies, or possibly other components of the computer (like the motherboard), then you lose the ability to access the data on the drive altogether. While if it isn't you can still recover the data from the drive.

Re: Authenticated Boot and Disk Encryption on Linux

#153

Post by curt15 » Thu, Sep 23, 2021, 4:49 PM UTC

yyyk wrote: post #151

Iolaum wrote: post #145

Earlier quoted context omitted.

I am using BTRFS and FDE encryption right now on Fedora Silverblue for a year if not more. And like the post says, I am typing two passwords.

I'm talking about filesystem level support, not block level support. FDE is block level and of course will work on any supported filesystem including btrfs. What btrfs doesn't do is support encryption inside the filesystem a la fscrypt - where we can encrypt specific directories - or ZFS encryption, where we can encrypt specific filesystems inside a pool. If I understand btrfs right, supporting encryption/verificatio…

fscrypt support for btrfs is apparently under development; see the most recent comments at https://github.com/btrfs/btrfs-todo/issues/25

Re: Authenticated Boot and Disk Encryption on Linux

#154

Post by jvanderbot » Thu, Sep 23, 2021, 4:51 PM UTC

nsajko wrote: post #22

An option that wasn't at all considered in the article is to have the initrd and (optionally) the secret key used for decrypting the disk on a separate device (or devices), for example on an 1 GB USB drive. This way the big disk can have full, real FDE (not LUKS). To an attacker not in possesion of the USB drive the big disk just looks like random data. And the USB drive can be kept on one's own person and easily des…

In the case you are mugged, that USB key is going with the mugger. (see also police raids or airport "inspections" e.g., entering or leaving bad states) I prefer memorized keys, with, ideally, a duress passphrase for this reason.

But, hypothetical scenarios without reasonable threat modelling is a losing man's game. You can never one-up a mythical adversary. Protecting against the easy 80% of threats takes only 20% effort.

Re: Authenticated Boot and Disk Encryption on Linux

#155

Post by cmurf » Thu, Sep 23, 2021, 4:56 PM UTC

zokier wrote: post #116

vbezhenar wrote: post #63

So basically an issue is that initramfs is not validated. Is it even possible to resolve that issue? If new grub version adds forced initramfs validation when run under secure boot mode, attacker can just install old grub which is still signed, but allows for unsigned initramfs. Of course everything but /boot must just be encrypted, there's no reason not to.

You don't need separate initramfs file these days, you can bake it into the kernel executable which you can then sign

True but this is complicated for users to do themselves.. And also complicated for distributions to create, sign, and distribute a "universal" or no-host-only initramfs that will boot any supported configuration. Plus that universal initramfs is quite a lot larger than the more compact host-only initramfs.

It should be possible to automate writing out a new fs-verity "boot" directory containing the locally-signed files we care about, and having the signing regime enforced by a distro signed bootloader. Like dm-verity Android images, the Merkel tree is signed by asymmetric key pair, with the private key tossed immediately after successfully creating and signing the tree, with the public key being exposed wherever convenient.

Re: Authenticated Boot and Disk Encryption on Linux

#156

Post by psanford » Thu, Sep 23, 2021, 4:57 PM UTC

thayne wrote: post #152

On most linux distros the initrd is dynamically generated, and depends on the specific hardware. So it isn't possible for the initrd to be signed by the vendor. Is it possible for the TPM to verify such a dynamically created file during boot? Also, requiring a TPM for decrypting the hard drive has a security/usability tradeof. If the TPM dies, or possibly other components of the computer (like the motherboard), then…

The TPM 2.0 spec has the ability to duplicate keys from one TPM to another for this type of use case. It of course requires the key policy to allow for duplication, so you have to plan ahead of time, but it is possible.

Re: Authenticated Boot and Disk Encryption on Linux

#157

Post by predakanga » Thu, Sep 23, 2021, 5:12 PM UTC

michaelt wrote: post #96

cesarb wrote: post #12

On a quick skim, I could see three issues with this proposal: 1. While each home directory is individually encrypted, since /home itself is not encrypted (unlike with current uses of full disk encryption), the user login names can be found unencrypted on the disk. 2. Since each home directory is individually encrypted, backup systems like borgbackup running as root can no longer easily backup everything. 3. As far as…

Also, once you've got per-user encryption on ~/.ssh/authorized_keys you'll need some other mechanism for users to log in. And don't think of having the users do their own backups - locking users' home directories mean they won't be able to run their own cron jobs.

> Also, once you've got per-user encryption on ~/.ssh/authorized_keys you'll need some other mechanism for users to log in.

OpenSSH supports this through the AuthorizedKeysFile directive - it'd be quite simple for the homedir mounting tool to sync that file from the user's authorized_keys file on unmount.

You could also use SSH certificates, but that requires a CA - not ideal for the home user.

Re: Authenticated Boot and Disk Encryption on Linux

#158

Post by adgjlsfhk1 » Thu, Sep 23, 2021, 5:19 PM UTC

teddyh wrote: post #109

nsajko wrote: post #70

Earlier quoted context omitted.

LUKS leaves encryption metadata unencrypted. For real FDE, use "plain dm-crypt" with cryptsetup: https://security.stackexchange.com/questions/109223/what-doe... > Possible with UEFI, not BIOS/MBR. Why do you think that? I have this setup on a modern (UEFI) computer, but I use the old BIOS/MBR interface.

> LUKS leaves encryption metadata unencrypted. Except for ruling out plausible deniability, what problem does this pose?

Metadata includes file names. If you have a file on your computer called proof_nsa_is_doing_illegal_stuff.pdf, that would significantly help a prosecutor trying to convict a wistleblower even if they can't get the file.

Re: Authenticated Boot and Disk Encryption on Linux

#159

Post by cmurf » Thu, Sep 23, 2021, 5:23 PM UTC

Can a TPM be shared by two operating systems? As in, dual boot configurations? Is any sort of deconfliction required and does the relevant spec account for this?

Re: Authenticated Boot and Disk Encryption on Linux

#160

Post by SV_BubbleTime » Thu, Sep 23, 2021, 5:24 PM UTC

teddyh wrote: post #109

nsajko wrote: post #70

Earlier quoted context omitted.

LUKS leaves encryption metadata unencrypted. For real FDE, use "plain dm-crypt" with cryptsetup: https://security.stackexchange.com/questions/109223/what-doe... > Possible with UEFI, not BIOS/MBR. Why do you think that? I have this setup on a modern (UEFI) computer, but I use the old BIOS/MBR interface.

> LUKS leaves encryption metadata unencrypted. Except for ruling out plausible deniability, what problem does this pose?

Which is kinda funny on a laptop. If some authority told you to unlock a device and it did have a plausible deniability encryption system - no one is going to believe that anyway.

For a USB drive or a file, sure, feature. For a laptop, “duh, it’s encrypted” is going to be the first thing anyone considers. Not “well, I guess the laptop has no data on it at all!”