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.