Encrypted swap is at least as important as encrypted data. This is because the contents of nearly anything in memory can be swapped to disk, at any time, and for any length of time. That includes passwords and like, en claire. Encrypting the system swap volume cannot be overlooked.<\/p>\n
During our migration process we have cloned drives in part one<\/a>, switched to an encrypted root in part two<\/a>, and moved partitions around to make room for home data encryption in part three<\/a>. Now we will encrypt the swap partition.<\/p>\n Goals<\/strong><\/p>\n We are free of many of the concerns with which we dealt when dealing with the encrypted root in part two<\/a>, but we have two key goals:<\/p>\n The first is a property unique to swap, that being the place were the contents of RAM are copied when a machine is put into hibernation. Our encryption setup should support that. The second is an artifact of our disk layout, this being a second encrypted volume to be encountered during boot. There are more than a few ways to meet both of these goals, and some shortcuts that can be taken should one or the other not be desired.<\/p>\n Suspend vs Hibernate<\/strong><\/p>\n Imprecision characterizes the names and labels for “hardware sleep” as it does many areas of technology, even after the ideas and processes have been codified. It is worth stating a couple of definitions:<\/p>\n We pursue the latter, as that is all that is relevant for a swap change.<\/p>\n Possibilities<\/strong><\/p>\n There are a number approaches for volume encryption, most of which we did not explore in parts two<\/a> and three<\/a>. All boot-time decryption is handled by systemd-cryptsetup-generator, which understands \/etc\/crypttab entries as well as the rd.luks kernel command-line arguments we used previously.<\/p>\n Option #1 is not available without redoing this particular storage layout from scratch, but would offer the advantage that all logical volumes atop a crypto-pv are implicitly encrypted: root, swap, whatever. This route was not chosen simply because it did not seem to align with install-time Fedora defaults.<\/p>\n Options #2, #3, #4 make use of \/etc\/crypttab, something we did not explore when setting up encrypted root and home, and entries here are generally set up by systemd later in the boot process after initrd. In the entries below, the first is the simplest means of encrypting swap, and a facility unique to crypttab: recreating it with random key at each boot, leaving a plain-crypt (not LUKS) device mapper entry named crypt-swap. The latter two point to a LUKS volume that would need to be cryptsetup manually ahead of time, with masochistically named device-mapper entries in the form luks-UUID:<\/p>\n Out of this bunch, the first does not support hibernate by nature of its use of random key. But #2 and #3 are viable<\/u>, with concerns about key storage for the latter assuaged by its location within the encrypted root.<\/p>\n Options #5 and #6 are the way we handled root in part two<\/a>, for decryption by the initial ram disk. This would add another rd.luks.uuid kernel argument in grub.conf pointing to the device in question:<\/p>\n\n
\n
\n
\r\ncrypt-swap\t\/dev\/mapper\/Volume00-swap\t\/dev\/urandom\tswap\r\nluks-XXX-YYY-ZZZ-AAA-BBB-CCC\t\/dev\/mapper\/Volume00-swap\r\nluks-XXX-YYY-ZZZ-AAA-BBB-CCC\t\/dev\/mapper\/Volume00-swap\t\/etc\/luks\/swap.key\r\n<\/pre>\n
\r\nrd.luks.uuid=XXX-YYY-ZZZ-AAA-BBB-CCC\r\nrd.luks.uuid=XXX-YYY-ZZZ-AAA-BBB-CCC rd.luks.key=\/path\/to\/swap.key\r\n<\/pre>\n