Use random encryption key for swap partition

[rustybird]

Normally, the disk password entered during the boot process is used to decrypt both the root partition and the swap partition.

But if a wrong password is entered initially, subsequent tries prompt separately for the root partition and the swap partion password, i.e. you have to enter the same password twice now. This can be observed by looking at the LUKS UUIDs in the console (after pressing <ESC> to leave the plymouth splash screen) or the journal.

(Tested on Qubes 3.0 RC1)

[marmarek]

By default there is only one encrypted partition, with LVM on it. Did
you chosen some other layout?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[rustybird]

Yes, btrfs.

[nrgaway]

This was also the same behaviour in Release2. In Ubuntu I set the swap to use random password on boot.

[cfcs]

Having a swap partition with a static key can be a privacy problem for any software that deals with ephemeral keys or if you have encrypted contents (such as gpg keys or dmcrypt volumes) inside your primary partition. Would it be a huge overtaking to add an option to the bootloader for having random passphrases? (I'm aware this disables suspend-to-disk)

[marmarek]

I think, instead of solving original issue, we should just change swap partition setup to use random key (if it is installed as separate partition, not on the same encrypted LVM as root filesystem). This way it will additionally ease #904.

[rustybird]

@marmarek Ephemeral swap also works around #978.

I used this script to convert my swap: https://gist.github.com/rustybird/917ac2560fe4e9541d1f

[andrewdavidwong]

@cfcs:

Having a swap partition with a static key can be a privacy problem for any software that deals with ephemeral keys or if you have encrypted contents (such as gpg keys or dmcrypt volumes) inside your primary partition.

Is the concern that if a single passphrase is used to encrypt both root and swap, and an attacker learns this passphrase, then the attacker can also access old data remnants in swap which have survived across reboots? If so, then I understand the concern, but I don't think using a random key for swap is as important in Qubes as it is in other OSes, since (1) dom0 isn't used for any user activities, and (2) being able to decrypt root = access to dom0 = game over anyway.

(Note: I'm not saying we shouldn't do it or that it's not important; I'm just saying it doesn't seem as important in Qubes compared to other OSes. It still strikes me as worthwhile.)

Would it be a huge overtaking to add an option to the bootloader for having random passphrases? (I'm aware this disables suspend-to-disk)

Xen (and, therefore, Qubes) doesn't support suspend-to-disk, so no loss there.

[cfcs]

@axon-qubes

Is the concern that if a single passphrase is used to encrypt both root and swap, and an attacker learns this passphrase, then the attacker can also access old data remnants in swap which have survived across reboots?

Yes, exactly that. If a user is recorded in, say, a foreign airport, while typing their password, presumed volatile data (such as decrypted gpg keys or ephemeral OTR keys held in memory) should not be compromised as well. If Qubes/Xen doesn't suspend-to-disk I see no benefit of not doing this.

Another problem pertains to appvms swapping to disk in /var/lib/qubes/appvms/*/volatile.img.
My concern described above is relevant to AppVM swap data too, any ideas how to accomodate that?
We could loopmount a swap file encrypted using a random key for each domain on startup, but that would (usually) mean encrypting that data twice, which is not desirable for swap. Looking for a slightly more elegant solution than doing that.

[starius]

Any update on this?

[andrewdavidwong]

@starius: Not that I'm aware of.

[v6ak]

This one seems to be easy to implement in existing installation by hand (I actually have it done.), but I am not sure how hard is it to add it to the installer.

The encrypted swap should be outside of encrypted main LVM-on-LUKS, because doing so would mean double encryption, which would mean some extra overhead.

The /etc/crypttab supports swap flag which automatically formats the device to swap. The drawback is it implies plain mode (i.e., no LUKS header), which means it has no persistent UUID. In such case, you have to address is directly by /dev/sdaX (or /dev/sdbX), which is not a good practice. Fortunately, there is a workaround: Put the swapfile into a LVM, effectively getting swap-on-dm-crypt-on-LVM setup. The main drawback of dm-crypt-on-LVM (instead of LVM-on-LUKS) is it might add some attack surface for those who try to bypass AEM.

With GPT, we could get rid of LVM for swap: We can use /dev/disk/by-partuuid or /dev/disk/by-partlabel. But I am not sure if it is a good idea to require GPT: My old laptop was unable to boot with GPT, requiring MBR. (I don't care much about my old laptop that will not work with Qubes 4 anyway, but there might be other people facing similar issues.) Well, Qubes 4 will reduce support for old hardware anyway, but I am still not sure if requiring GPT would be a good idea. On the other hand, requiring GPT for this specific feature (let's call it "ephemeral swap") would be probably OK. It is better to have this feature on modern hardware only than not to have it at all. Moreover, modern hardware is likely to use GPT.

Some notes:

• I use the same ephemeral approach for /largetmp, which stores volatile.img, see Store volatile.img in separate location #1527. Without this, you don't resolve this issue for domUs. This is slightly more tricky -- while crypttab has "tmp" option that formats it to ext, you will have issues with permissions. I format it by a script started by systemd servivce.
• With ephemeral swap, you forgo hibernation (i.e., suspend-to-disk) by design. AFAIK Qubes does not support this anyway at the moment. To make it clear, this does not interfere with suspend-to-RAM.
• I use /dev/random, because /dev/urandom might have low entropy on boot. The drawback with /dev/random is that it might take longer time when low on entropy. It does not look like a large issue for me. Maybe haveged in dom0 could help, but it would require to start it before cryptsetup for swap/largetmp.

EDIT: Fixed dm-crypt vs. LUKS.

[starius]

@v6ak Thank you for your answer!

Can we enable swap not at boot but later (after dom0 is running). If there was free partition for that on /dev/sda I could do it easily with a script. But there are only two partitions: for LUKS and for /boot (btw /boot also worth encrypting to avoid possible leaks about system setup; it is possible with recent grub).

[v6ak]

Can we enable swap not at boot but later (after dom0 is running).

I used to have this setup with Ubuntu (intentional delay in order to reduce HDD operations on boot), but I am not sure if there are huge advantages. Maybe it could help on low-entropy setups with startup time.

If there was free partition for that on /dev/sda I could do it easily with a script.

As I have written, the hardest problem is how to identify the partition: * Traditional /dev/sdaX – not generally recommended. AFAIR, when having two drives, you might get nondeterministically swapped them etc. You might also intentionally swap the two devices, which could lead to erasure of random partition on one of the drives. The solution might be OK for some specific setup, but I would not recommend it as a general solution. * Labels and UUIDs – they are either FS-specific (and plain dm-crypt does not have them) or partition-table-specific (supported by GPT, unsupported by MBR) * LVM – adds attack surface for AEM.

But there are only two partitions: for LUKS and for /boot

Do you mean the default layout?

(btw /boot also worth encrypting to avoid possible leaks about system setup; it is possible with recent grub).

I don't think this will work with UEFI. Moreover, I don't see much benefit of it.

[brendanhoar]

In R4.1, this was partially implemented for domU VMs (using a pool level flag that currently defaults to disabled here): #6958

IIRC, full implementation for domU VMs is slated for R4.2.

B

[rustybird]

QubesOS/qubes-core-admin-linux#79