Could we enable encryption of swap by default, even when full disk
encryption is not used? As far as I undrestand, there is no
performance issue for this for most hardware made in the past
half-decade. Swap encryption also doesn't require the user to enter a
password: it can be generated on the fly for each boot.

This was suggested in the Debian GnuPG BoF at Debconf15.

Hi Lars,

Lars Wirzenius <liw@liw.fi> (2015-08-16):
some reports about signature not being the right one, and bits of
cryptsetup not being fully set correctly. I haven't had time to look
into that yet.

Thanks for forwarding this to us.

Mraw,
KiBi.

This is obviously wrong. The performance cost may be low to the effect
that it is negligible on "recent hardware", but it is not zero; even if
you run it on custom crypto hardware that wouldn't otherwise be used
except for crypto operation, that would make that hardware unavailable
(or at the very least, less available) for other crypto operations.

This also makes it impossible to use suspend-to-disk, as that uses the
swap partition to write the state of the current RAM, which needs to be
reread at boot time; if you encrypt the swap partition with a random
key, you can't read it at the next boot, so you've removed the ability
to use that feature.

This is obviously wrong. The performance cost may be low to the effect
that it is negligible on "recent hardware", but it is not zero; even if
you run it on custom crypto hardware that wouldn't otherwise be used
except for crypto operation, that would make that hardware unavailable
(or at the very least, less available) for other crypto operations.

This also makes it impossible to use suspend-to-disk, as that uses the
swap partition to write the state of the current RAM, which needs to be
reread at boot time; if you encrypt the swap partition with a random
key, you can't read it at the next boot, so you've removed the ability
to use that feature.

It's a shame that encrypted swap by default hasn't happened yet for
debian.

As i see it, the three outstanding concerns are:

 a) source of entropy at boot time

 b) actual hardware performance

 c) suspend-to-disk


boot time entropy
-----------------

The linux kernel's getrandom() situation is much better today than it
was two years ago.  It's actually possible to get blocking bytes when
needed early, without forcing yourself into a blocking situation later
once the kernel's prng is initialized.  See getrandom(2) and random(4)
for more details.

actual hardware performance
---------------------------

I suspect the cost is negligible on most hardware today, particularly
when compared to the disk I/O.  If you're swapping, you're likely to be
waiting for the disk, not waiting for the CPU.  That said, i agree that
users with specialized situations ought to be able to disable this.  But
the default should still be on.

suspend-to-disk
---------------

If the user suspends to disk, then the memory will be written to disk.
this is definitely a leak.  However, we currently write the memory to
disk *without* suspending to disk, so even if we don't handle
suspend-to-disk "safely" it's still a win to encrypt swap, because we
protect the people who do *not* suspend to disk.  So that's the simplest
solution to the suspend-to-disk problem: just punt on it for now, and
leave that case unprotected.

If suspend-to-disk (or rather, resume-from-disk) is the only problem,
then we should look for ways to opportunistically take advantage of
other non-disk hardware on which we could store any ephemeral keys
needed for restoration.

For example, on systems with rewritable nvram, it's conceivable that we
could suspend to the encrypted volume, and then stash the ephemeral
encryption key in nvram.  Upon resume, read the key from nvram into main
memory, clear the nvram, and restore from the encrypted volume.  This
isn't perfectly secure (an attacker with both the disk and the nvram can
recover your memory from the suspend file) but it is a significant win
against an attacker who physically removes the hard disk.



So i think we ought to outline the steps that need to be taken to make
this happen by default.  Which pieces need to be updated, and how?

It's a shame that encrypted swap by default hasn't happened yet for
debian.

As i see it, the three outstanding concerns are:

 a) source of entropy at boot time

 b) actual hardware performance

 c) suspend-to-disk


boot time entropy
-----------------

The linux kernel's getrandom() situation is much better today than it
was two years ago.  It's actually possible to get blocking bytes when
needed early, without forcing yourself into a blocking situation later
once the kernel's prng is initialized.  See getrandom(2) and random(4)
for more details.

actual hardware performance
---------------------------

I suspect the cost is negligible on most hardware today, particularly
when compared to the disk I/O.  If you're swapping, you're likely to be
waiting for the disk, not waiting for the CPU.  That said, i agree that
users with specialized situations ought to be able to disable this.  But
the default should still be on.

suspend-to-disk
---------------

If the user suspends to disk, then the memory will be written to disk.
this is definitely a leak.  However, we currently write the memory to
disk *without* suspending to disk, so even if we don't handle
suspend-to-disk "safely" it's still a win to encrypt swap, because we
protect the people who do *not* suspend to disk.  So that's the simplest
solution to the suspend-to-disk problem: just punt on it for now, and
leave that case unprotected.

If suspend-to-disk (or rather, resume-from-disk) is the only problem,
then we should look for ways to opportunistically take advantage of
other non-disk hardware on which we could store any ephemeral keys
needed for restoration.

For example, on systems with rewritable nvram, it's conceivable that we
could suspend to the encrypted volume, and then stash the ephemeral
encryption key in nvram.  Upon resume, read the key from nvram into main
memory, clear the nvram, and restore from the encrypted volume.  This
isn't perfectly secure (an attacker with both the disk and the nvram can
recover your memory from the suspend file) but it is a significant win
against an attacker who physically removes the hard disk.



So i think we ought to outline the steps that need to be taken to make
this happen by default.  Which pieces need to be updated, and how?

[...]

For clarity, when I stated that, I wasn't using it as an argument
against enabling encryption of the swap partition by default; it's just
that saying "there is no performance impact when doing something extra"
is objectively wrong. The performance impact may be negligable; but when
you need to do more work, you need to actually do it and there will be
an impact. It will not matter in the common case, but there will be
exceptions where it will matter, and therefore we need to continue
supporting that.

Pet peeves, I suppose.

The initramfs code that does the actual resume should be updated to read
the key from wherever it was written.

On systems that don't have writable nvram, we could still support both
encrypted swap and suspend-to-disk provided the system has an
alternative location to write that session's encryption key to (which
I'll inaccurately call "the session key" for now -- it's not really a
session key, but it's close enough).

If the kernel needs to read the session key, then it can't be on a
partition that needs to be live. The initramfs would need to mount that
partition to be able to see whether there is a session key that needs to
be used to do the resume-from-disk, which would cause a journal replay;
that would invalidate the suspended image. What we could do, however, is
if the user has a separate /boot partition, to make the "suspend" script
write the session key to a well-known file in that partition, and then,
just before actually doing the suspend, *unmounting* the /boot
partition. The resume code in the initramfs could then mount the /boot
partition and figure out if there is a session key; if there is, it
would read the key, unmount the partition again, and then proceed to
decrypt the swap partition and resume the system.

If a user installs a system with encrypted swap but no separate /boot
partition, the suspend-to-disk code could/should then produce an error
message to the effect that the user needs to either disable encrypted
swap, or create a separate /boot partition. If partman is then also
updated to default to having a separate /boot partition, we would be
able to support encrypted swap as well as suspend-to-disk virtually
anywhere.

On a side node, if the system has a TPM that is not disabled, we should
also attempt to encrypt the session key (regardless of where it is
stored) using the TPM. That way, an attacker who gains access of the
hard disk and the (encrypted) session key but not the system itself
cannot decrypt the swap partition, since a TPM is supposed to not allow
keys to be removed from it.

[...]

For clarity, when I stated that, I wasn't using it as an argument
against enabling encryption of the swap partition by default; it's just
that saying "there is no performance impact when doing something extra"
is objectively wrong. The performance impact may be negligable; but when
you need to do more work, you need to actually do it and there will be
an impact. It will not matter in the common case, but there will be
exceptions where it will matter, and therefore we need to continue
supporting that.

Pet peeves, I suppose.

The initramfs code that does the actual resume should be updated to read
the key from wherever it was written.

On systems that don't have writable nvram, we could still support both
encrypted swap and suspend-to-disk provided the system has an
alternative location to write that session's encryption key to (which
I'll inaccurately call "the session key" for now -- it's not really a
session key, but it's close enough).

If the kernel needs to read the session key, then it can't be on a
partition that needs to be live. The initramfs would need to mount that
partition to be able to see whether there is a session key that needs to
be used to do the resume-from-disk, which would cause a journal replay;
that would invalidate the suspended image. What we could do, however, is
if the user has a separate /boot partition, to make the "suspend" script
write the session key to a well-known file in that partition, and then,
just before actually doing the suspend, *unmounting* the /boot
partition. The resume code in the initramfs could then mount the /boot
partition and figure out if there is a session key; if there is, it
would read the key, unmount the partition again, and then proceed to
decrypt the swap partition and resume the system.

If a user installs a system with encrypted swap but no separate /boot
partition, the suspend-to-disk code could/should then produce an error
message to the effect that the user needs to either disable encrypted
swap, or create a separate /boot partition. If partman is then also
updated to default to having a separate /boot partition, we would be
able to support encrypted swap as well as suspend-to-disk virtually
anywhere.

On a side node, if the system has a TPM that is not disabled, we should
also attempt to encrypt the session key (regardless of where it is
stored) using the TPM. That way, an attacker who gains access of the
hard disk and the (encrypted) session key but not the system itself
cannot decrypt the swap partition, since a TPM is supposed to not allow
keys to be removed from it.

even if the user suspends to RAM, the key will stay in memory, which is
can be pretty bad (as it can be taken from there via hardware tools).
so the idea came up to create a small chroot in memory, unmount the disk
on suspend, throw away they key and chroot in there. Then upon resume they
ey needs to be entered again, to unlock the disk. See these URLs for more
information on this:

https://github.com/QubesOS/qubes-issues/issues/2890
https://askubuntu.com/questions/95625/suspend-to-ram-and-encrypted-partitions
https://github.com/jonasmalacofilho/ubuntu-luks-suspend

I'd love to see this for Debian!