You are not logged in.

#1 2020-11-21 19:58:13

VDmvKcW9JamBSir5fNfehqpG
Member
From: Earth
Registered: 2019-12-30
Posts: 39

Better way for encrypted system on two disks than LVM on LUKS on LVM?

My laptop just died, and the laptop I'm thinking about buying to replace it has a 256GB NVMe drive, as well as a space for a 2.5in SATA drive. In the 2.5in bay, I want to add the 240GB SSD from my old laptop so I'll have 496GB of total storage, since 240GB is starting to feel a little limiting and I'll have even less available now that I probably have to keep a Windows partition (in case my college forces me to run crappy Windows-only software), which I didn't have to do on my old laptop because my high school software was browser-based. I want a setup that provides in order of importance:

1. The Windows installation that comes with the laptop and a swap area on the NVMe drive, and a rootfs filling the rest of the NVMe drive and the entire SATA drive, all of which must be encrypted (except for the Windows installation because Windows can't reliably handle full disk encryption and I don't trust Windows to handle anything sensitive anyways).

2. Ability to mount the whole thing by only entering a password once, because entering passwords more than once is annoying

3. Good performance (ability to use TRIM and placing more commonly used files on NVMe while reserving SATA for less regularly used files)

4. Fault tolerence: I want to be able to mount either drive on its own and access whatever data that drive might contain, and continue to be able to boot if the working drive happens to have all the needed files. (I would like a warning when that happens so I know that some of my files might be missing.)

5. Some degree of resistance to tampering with the boot partition by evil maids, roommates, Microsoft through backdoors in Windows, and other adversaries that might obtain physical access to the laptop, preferably provided by having detached headers on a boot partition on external media.

6. Plausible deniability of the existence of an encrypted installation to provide some protection against government thugs. (Though I know that's a weak defense, so I'm putting my desire for it as the lowest priority.)

The best solution I could think of is to give Windows however many partitions it wants, make another partition on the NVMe, combine the last partition of the NVMe and the entire SATA into one volume by using LVM, put a LUKS container on that one volume, and then use LVM again to split the LUKS container into swap and root. This does provide 1, 2, and 5, but doesn't satisfy everything. I don't know if TRIM can go through two layers of LVM, and as far as I can tell the filesystem will have no preference for the NVMe over the SATA (because most filesystems are probably designed with the expectation that the block device is the same regardless of where on the block device you read/write to), so it will just put the files wherever it feels like. Unless I set up the filesystem to not attempt to reduce fragmentation and just write everything in the lowest available address, which I'm not even sure if I can do and feels a little hacky. If one drive fails, I think I lose everything on both drives, which means that using this setup raises the risk of my computer suddenly becoming unusable. And while I can use an external boot partition for some degree of evil maid resistance and a detached header for plausible deniability of the LUKS container, it doesn't hide the first layer of LVM. Plus, I don't know why, but having nested layers of LVM just feels a little wrong to me.

Is there a way to achieve the setup I'm trying to get, or at least have more of the features I'm looking for? If not, is there at least a better way to achieve what the idea I already came up with does? Or is what I'm trying to do just a bad idea and to be avoided?


btw I use Arch

Offline

#2 2020-11-21 21:01:26

loqs
Member
Registered: 2014-03-06
Posts: 12,084

Re: Better way for encrypted system on two disks than LVM on LUKS on LVM?

If you span the NVME and SATA with an LVM four would seem impossible.
Why not have multiple LUKS instead of LUKS on LVM on LUKS?  The passphrase for a keyslot would be common or loaded from a keyfile on the first unlocked LUKS.
How does having an encrypted boot partition for Arch protect against evil maid?  Which to my understanding would be installed in the bootloader or firmware.

Last edited by loqs (2020-11-21 21:01:38)

Offline

#3 2020-11-21 21:23:11

Xyne
Moderator/TU
Registered: 2008-08-03
Posts: 6,544
Website

Re: Better way for encrypted system on two disks than LVM on LUKS on LVM?

I would avoid spreading a single file system over the NVMe and the SATA drives, especially an encrypted one. The performance of the drives are very different and I have no idea how the data will be spread across the devices with the encryption layer, which also means that a single device failure will almost certainly lead to greater loss of data than just the storage capacity of the failed disk, unless LUKS over LVM has some magical way of mapping different files to different devices.

As for LVM over LUKS over LVM, that just seems overly complicated and it means that all of your data is unencrypted and exposed whenever the system is running. If you are only trying to protect your system from tampering, that may make sense, but if you have actually sensitive data then that should probably only be mounted when you actually need to access it (e.g. either manually, or via pam-mount and an isolated user account). For system partitions, you can use keyfiles to avoid multiple passwords. For example, configure your boot loader to mount your encrypted root partition and then use key files on the root partition to unlock other system partitions. Once the system is up and running, all of that data is exposed anyway so the keyfiles themselves don't really make the system more vulnerable. In that case, you can do LUKS over LVM without the additional LVM layer and with better fault tolerance.

In that case, your personal data can be encrypted on a separate independent partition as well so that you don't need to decrypt and expose  your system partitions when accessing that data from windows (assuming that windows can handle LUKS/LVM/whatever).

An external boot device with separate encrypted partitions for your Linux system should satisfy 5 but make sure that you have a backup or that you can easily recreate the boot device in case you lose it.  Also keep in mind that your roommate or maid can still copy the device while you're sleeping or tamper with it so it's really just shifting the target from one device to the other. Ultimately, if you can't limit physical access to your devices I don't really see how you can fully protect yourself. An encrypted boot partition is probably good enough. If you want to go the paranoid route, you can also use a trusted live medium to check the integrity of files on your system before booting, but a) that's a pita, b) you have to trust the live medium, so it's still a chicken & egg problem.

As for plausible deniability, once the government wants your data, you're completely f***ed so there's not much point in worrying about it. They are sophisticated enough to detect hidden data on devices, in block files, embedded in other files, etc. Your encrypted data has to reside somewhere and those bytes will stick out to anyone who's looking for them. Once they see that you're hiding something, good ol' rubber hose cryptanalsysis is all they'll need to get the keys out of you. If you destroy the keys before they get you, well, you'll just get more of the rubber hose. The only way to protect yourself is to keep everything on an external device that you can completely destroy or discard.

So, my recommendation would be:

  1. LUKS over LVM with keyfiles on the NVMe drive for your system partitions (including non-sensitive data in /home)

  2. LUKS over LVM for sensitive personal data on the SATA device, mounted on demand via a script or pam-mount

  3. any data sensitive enough to merit uncomfortable government interest on a dispensible/destructible external device

  4. determine whether or not you really need to bother with an external boot device etc.


My Arch Linux StuffForum EtiquetteCommunity Ethos - Arch is not for everyone

Offline

#4 2020-11-21 22:25:23

VDmvKcW9JamBSir5fNfehqpG
Member
From: Earth
Registered: 2019-12-30
Posts: 39

Re: Better way for encrypted system on two disks than LVM on LUKS on LVM?

loqs wrote:

If you span the NVME and SATA with an LVM four would seem impossible.

Yeah, thought so. I was wondering if there was something better than LVM for what I'm doing.

loqs wrote:

Why not have multiple LUKS instead of LUKS on LVM on LUKS?  The passphrase for a keyslot would be common or loaded from a keyfile on the first unlocked LUKS.

I was under the impression that if I did that, I'd have to enter my password many times. Since I apparently don't have to do that, I no longer have an objection to it, so I guess we can go with that.

loqs wrote:

How does having an encrypted boot partition for Arch protect against evil maid?  Which to my understanding would be installed in the bootloader or firmware.

I said "some degree." It will protect against evil maids who only know how to fuck with my SSD and not how to swap my hardware out or mess with the firmware. Since I have an easy opportunity to make it harder, even if it's not perfect, I might as well.

Xyne wrote:

I would avoid spreading a single file system over the NVMe and the SATA drives, especially an encrypted one. The performance of the drives are very different and I have no idea how the data will be spread across the devices with the encryption layer, which also means that a single device failure will almost certainly lead to greater loss of data than just the storage capacity of the failed disk, unless LUKS over LVM has some magical way of mapping different files to different devices.

Yeah, that's my concern. That's why I wanted an alternative.

Xyne wrote:

An external boot device with separate encrypted partitions for your Linux system should satisfy 5 but make sure that you have a backup or that you can easily recreate the boot device in case you lose it.  Also keep in mind that your roommate or maid can still copy the device while you're sleeping or tamper with it so it's really just shifting the target from one device to the other. Ultimately, if you can't limit physical access to your devices I don't really see how you can fully protect yourself. An encrypted boot partition is probably good enough. If you want to go the paranoid route, you can also use a trusted live medium to check the integrity of files on your system before booting, but a) that's a pita, b) you have to trust the live medium, so it's still a chicken & egg problem.

Yeah, I knew it wasn't going to add much evil maid protection, but it's better than nothing so I figured I might as well. Also, I do not trust Windows itself not to inject malware into my kernels, and I figured that this is the easiest way to prevent Windows from doing that. And yes, I will keep backups.

Xyne wrote:

So, my recommendation would be:

LUKS over LVM with keyfiles on the NVMe drive for your system partitions (including non-sensitive data in /home)

LUKS over LVM for sensitive personal data on the SATA device, mounted on demand via a script or pam-mount

any data sensitive enough to merit uncomfortable government interest on a dispensible/destructible external device

determine whether or not you really need to bother with an external boot device etc.

The problem with that is that I might have more non-sensitive data than can fit on one drive, and not enough sensitive data to warrant a dedicated drive. I can achieve mounting on demand through ecryptfs, so I see no need for a dedicated sensitive drive. I guess I can do it if nobody has a satisfactory way to spread my rootfs without elevated risk of data loss.


btw I use Arch

Offline

#5 2020-11-22 04:53:41

Xyne
Moderator/TU
Registered: 2008-08-03
Posts: 6,544
Website

Re: Better way for encrypted system on two disks than LVM on LUKS on LVM?

VDmvKcW9JamBSir5fNfehqpG wrote:

The problem with that is that I might have more non-sensitive data than can fit on one drive, and not enough sensitive data to warrant a dedicated drive. I can achieve mounting on demand through ecryptfs, so I see no need for a dedicated sensitive drive. I guess I can do it if nobody has a satisfactory way to spread my rootfs without elevated risk of data loss.

Even if you have too much non-sensitive data for a single device, you can still organize it into different partitions on different devices, no? And for the sensitive data, you don't need to dedicate an entire device, just a partition. As for ecryptfs, keep in mind that the underlying files and metadata are still visible even when the directory isn't mounted. Given that you're asking about scenarios with evil maids and government agents, that's something to consider. For one thing, the timestamps will reveal recent access and undermine any argument about not remembering the password. With ecryptfs, it may also be more difficult to access the data from other systems. As for robustness, my own experience with ecryptfs has been bad due to data loss but that was several years ago so it may have improved since then. I've found encfs to be very reliable for filesystem-level encryption so I've never had a reason to try ecryptfs again.


My Arch Linux StuffForum EtiquetteCommunity Ethos - Arch is not for everyone

Offline

#6 2020-11-22 17:49:02

VDmvKcW9JamBSir5fNfehqpG
Member
From: Earth
Registered: 2019-12-30
Posts: 39

Re: Better way for encrypted system on two disks than LVM on LUKS on LVM?

Xyne wrote:

Even if you have too much non-sensitive data for a single device, you can still organize it into different partitions on different devices, no? And for the sensitive data, you don't need to dedicate an entire device, just a partition. As for ecryptfs, keep in mind that the underlying files and metadata are still visible even when the directory isn't mounted. Given that you're asking about scenarios with evil maids and government agents, that's something to consider. For one thing, the timestamps will reveal recent access and undermine any argument about not remembering the password. With ecryptfs, it may also be more difficult to access the data from other systems. As for robustness, my own experience with ecryptfs has been bad due to data loss but that was several years ago so it may have improved since then. I've found encfs to be very reliable for filesystem-level encryption so I've never had a reason to try ecryptfs again.

I guess I could organize my data into partitions, but I'm trying to avoid doing that because I'm lazy and want something that I can set up once and then forget about. However, it seems like I might have to because there doesn''t seem to be a way to do what I want in a sketchy way. LVM has questionable performance when merging different drives as well as questionable safety when merging drives. I found mergerfs and mhddfs don't have safety concerns (because each SSD has an underlying filesystem of its own), but they're all FUSE (so bad performance and can probably kill -9) and as far as I can tell always prefer the drive with the most free space rather than the faster one. Overlayfs looks to be non-FUSE, but appears to only support a read-write overlay on top of a read-only filesystem. Unionfs looks to support read-write everything and have a kernel-space implementation, but I can't find much information on it so I don't know if it's safe or if it has faster drive preference. So is unionfs OK, or will I have to give up on merging the drives?

I trust the software running on bare metal under Linux (untrusted software will be run in a web browser, a VM, or Windows) and will have ecryptfs/encfs on top of an encrypted filesystem, so metadata leaks on the underlying filesystem aren't a huge concern to me. I've had trouble migrating ecryptfs to different installations (no data loss, but a huge hassle), so maybe I'll try encfs instead.


btw I use Arch

Offline

Board footer

Powered by FluxBB