How to create a randomly keyed, encrypted swap partition, referring to it "by-uuid", on Debian?

Question

It is sensible that if you have any sort of block device encryption implemented on your GNU/Linux system, to encrypt your swap partition too, as any decrypted data may be written in cleartext at any time to the swap.

Looking at the debian man page for "crypttab" I see an example of creating a randomly keyed swap partition on boot-up, so the key is set randomly as the boot proceeds and known only to the system itself:

# Encrypted swap device
cswap /dev/sda6 /dev/urandom cipher=aes-cbc-essiv:sha256,hash=ripemd160,size=256,swap

In this example the swap device is referred to by a conventional dev path i.e. /dev/sda6

Absolute device paths are subject to change and be re-assigned at boot-up if, say a usb drive is plugged in, for example. A user would be very unhappy if /dev/sda6 happened to be a different partition than expected and it was subsequently overwritten with random swap data!!

So the solution would seem to be: use a UUID instead of a device path (as a UUID shouldn't change), replacing /dev/sda6 with /dev/disk/by-uuid/<whatever the uuid of dev/sda6 is>

BUT ... here's the problem: Every time cryptsetup recreates the encrypted swap partition at boot time it generates a new UUID for it! Doh!

So we need to preserve the UUID of this encrypted filesystem somehow. I think cryptsetup can do this with its --offset switch, allowing for preservation of the LUKS header and thus the UUID.

I have found this URL: https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Using_UUIDs_with_encrypted_swap_partitions

Does anyone know how to implement the solution described for Arch Linux on the Debian OS? The init scripts referred to in the document seem not to exist on the Debian OS

Thanks!

EDIT One could use ecryptfs to achieve the same ends (encrypted swap space) using the command: ecryptfs-setup-swap Without the problems that beset block device encryption. Have a look at this AskUbuntu query

Solution 1

Every time cryptsetup recreates the encrypted swap partition at boot time it generates a new UUID for it! Doh!

In /etc/crypttab, use /dev/disk/by-id instead of /dev/disk/by-UUID to refer to your swap partition. For example, your /etc/fstab entry for swap might be

#<file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/cswap none swap sw 0 0

Then the correct corresponding entry in /etc/crypttab would be something like

# <name> <device> <password> <options>
cswap /dev/disk/by-id/ata-SAMSUNG_SSD_830_Series_S0XYNEAC762041-part5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256,size=256

Notice that the device above is referred to by /dev/disk/by-id which you can find out for your drive by typing the following at the CLI:

ls -lF /dev/disk/by-id

Solution 2

In my /etc/crypttab, I have

# <target name>  <source device>        <key file>   <options>
swap             /dev/mapper/cswap      /dev/random  swap

Here /dev/mapper/cswap is a logical volume created by LVM, which takes care of correctly assigning logical volume names regardless of the drive letter names. It also allows me to easily resize my swap partition.

Solution 3

To do a swap on encrypted file over LVM partition while using by-uuid option is not possible ... during initramfs boot stage or during most of systemd boot stages.

Here's why...

Or skip to "Steps" section to get started for an equally safe encrypted LVM swap space that gets created during normal bootup stage (for systemd, Debian 10).

Assumptions

You created an LVM partition named lv_swap_encrypted using 100% of vg_swap VG space as followed:

lvcreate -l 1000%VG -n lv_swap_encrypted vg_swap

such that our goal is to have the following logical diagram:

/dev/sda3
                            LVM Physical Volume (PV)
/dev/mapper/dm-7
                            LVM Volume Group (VG)
/dev/vg_swap
                            LVM Logical Volume (LV)
/dev/vg_swap/lv_swap_encrypted
                            cryptsetup plain
/dev/mapper/swap_unencrypted           
                            swap space

Problem

Take a look at the newly created LVM partition named vg_swap-lv_swap_encrypted just for use with swap (or encrypted swap):

# ./lsblk-uuid 
NAME                          UUID                                   MOUNTPOINT
sda                                                                  
├─sda1                                                               
├─sda2                        XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX   /boot
├─sda3                        XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX 
│ └─vg_swap-lv_swap_encrypted                                        
└─sda4                        XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX 
  ├─arca_v1-root              XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX   /
  └─arca_v1-spare  
...

Notice that there is no UUID for that vg_swap-lv_swap_encrypted partition?

You COULD execute mkswap vg_swap-lv_swap_encrypted on that LVM and obtain that UUID but then we would be skipping the much needed encryption part that we wanted.

WARNING: Oh, you executed mkswap? Then wipe it clean by executing:

dd if=/dev/urandom of=/dev/mapper/vg_swap-lv_swap_encrypted 

Executing dmsetup info /dev/dm-7 reveals a different UUID format:

   LVM-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY

I already tried the UUID= option with that funky LVM value above won't work in the 2nd field of /etc/crypttab either. Costed me a reboot here.

Note: X represent VG UUID and Y is LV UUID in LVM parlance.

Availability of Device Links

During initramfs boot stage, not many symbolic links are available for use with boot-up stage. We investigate which device paths are available for encrypted swap.

No need to do update-initramfs or any rebuilding of initfs here.

LVM Linked Device Names

In the /dev directory, LVM creates several symbolic links for each LV (logical volume) partition that lvcreate (or systemd-lvm2 during bootup) activates.

During initramfs boot stage, LVM activation creates the following block and symbolic files links:

• /dev/dm-X
• /dev/mapper/vg_swap-lv_swap_encrypted
• /dev/vg_swap/lv_swap_encrypted

During normal kernel boot stage, OS takes care of the rest of the following links. No need to investigate by whom or where, as our focus is on link availability for encrypted swap partition DURING initramfs boot stage.

• /dev/block/254:X
• /dev/254:X
• /dev/vg_swap-lv_swap_encrypted
• /dev/lv_swap_encrypted
• /dev/dm-name-vg_swap-lv_swap_encrypted
• /dev/disk/by-id/dm-uuid-LVM-XXXXXXXXXXXXXXXXXXXXXXXXXYYYYYYYYYYYYYYYYYYYYYYYY YYYYYYYYYYYYYYY
• /dev/dm-uuid-LVM-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY YYYY

Twenty reboots into runlevel 2 later, I've learned that it will never be possible (during initramfs boot stage) to use mount by-uuid because as each time the swapper writes unencrypted data into the first couple of blocks into the encrypted partition, whatever UUID it had before its encrypted data wrote over it is now long, long gone.

For normal post-bootup stage, UUID can be used in cryptsetup/cryptdisks_*.

Let's step back away from physical and extended partition UUID to take a look at LVM UUID here: LVM management pretty much ensures that each LVM partition is highly unique.

DANGER: In short, only danger to you is by reusing this same LVM parition for something else other than swap. If so, by the next reboot, that partition gets converted back to a swap space again and any newly installed data is gone (just be glad it's not the old and precious data).

SETUP

This arrangement of going by LVM VG/LV name would be impervious to data loss caused by addition, removal, and repartitioning of a hard drive, whether it's a swap or a filesystem.

In this /etc/crypttab example:

swap_unencrypted /dev/mapper/vg_swap-lv_swap_encrypted /dev/random none

swap space using memory-based randomized-key AND using VG/LV pathname, this approach will take your existing swap partition and convert it to an encryp ted swap space.

Basically, the following steps will

• disable hibernate,
• create an LVM partition for encrypted part of swap space,
• make a new entry in /etc/crypttab
• get dm-crypt/LUKS to create yet another partition, swap_unencrypted.
• modify swap entry in /etc/fstab
• Create swap space (mkswap)
• Enable swap space ('swapon`)

all to re-encrypt the swap space now and after every reboots.

Disable Hibernate

To use randomized key, you should understand that hibernate feature gets no longer supported.

You should disable hibernate as well before going on further. Hibernate makes use of swap space and randomized keys effectively makes prior hibernation quite unusable.

Note: we WANT to set the physical or extend partition to SWAP to fool the systemd initramfs generator into NOT disabling the SUSPEND/SLEEP part.

On Debian, you can execute:

systemctl mask hibernate.target hybrid-sleep.target
systemctl restart systemd-logind.service  # or reboot if using Gnome/gdm3 display manager

Good news is that hardware suspend or sleep mode will still work.

Create LVM

These steps assumes that you have a physical or extended (and not a LVM) partiti on for a swap partition already.

Re-type the Swap Partition

Assume that /dev/sda is the drive name. Assume that 3 is the partition number of /dev/sda drive that swap is located on.

Execute fdisk and use t option to relabel the Linux swap into Linux LVM by entering in 31 (or you can use L to list all options after that t comma nd.

# fdisk /dev/sda

Welcome to fdisk (util-linux 2.33.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): t
Partition number (1-4, default 4): 3
Partition type (type L to list all types): 31

Changed type of partition 'Linux swap' to 'Linux LVM'.

Command (m for help): w
The partition table has been altered.
Syncing disks.

Create LVM Physical Volume

Create a physical volume for LVM, by executing:

pvcreate /dev/sda3

Create LVM Volume Group

Create a volume group for LVM, by executing:

vgcreate vg_swap /dev/sda3

Nice thing about a volume group is that you can expand your swap space later on with another physical hard drive.

Create LVM Logical Volume

Create a logical volume for LVM, by executing:

lvcreate -l 100%vg -n lv_swap_encrypted vg_swap

# Make the LVM create a special file under /dev/vg_swap/lv_swap_encrypted
lvchange -a y vg_swap

Now we have a /dev/dm-7 block file available.

You will find that:

• /etc/mapper/vg_swap-lv_swap_encrypted
• /etc/vg_swap/lv_swap_encrypted

all points to the same /dev/dm-7.

I will advocate using /etc/mapper/vg_swap-lv_swap_encrypted because it is the consistent location that most of us can expect.
Not many know to look for this custom LVM Volume Group name here like /dev/vg_swap. Some other (like most BOFH) who create hard-to-find /etc/mapper_other (VG name of mapper ) to make it harder to look for.

We will not be using /dev/dm-7 because it could be dm-19 or other, depending on your partition layout.

Now we have a pathway to a drive, a logical drive, but not yet an encrypted driv e with random key pointing to /dev/mapper/vg_swap-lv_swap_encrypted.

Encrypted Swap Partition

Add or modify the following entry into /etc/crypttab:

swap_unencrypted /dev/mapper/vg_swap-lv_swap_encrypted /dev/urandom swap,cipher=
aes-cbc-essiv:sha256,size=256

Then activate the encryption and create yet another dm device under /dev/mapper block device: Choose one of two commands below:

# cryptsetup open /dev/mapper/vg_swap-lv_swap_encrypted  \
                swap_unencrypted

or

# cryptdisks_start swap_unencrypted
[ ok ] Starting crypto disk...swap_unencrypted (running)...done.

A new symbolic link has been made, execute lsblk

# lsblk
NAME                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                             8:0    0   3.7T  0 disk  
├─sda1                          8:1    0     1M  0 part  
├─sda2                          8:2    0   381M  0 part  /boot
├─sda3                          8:3    0  15.3G  0 part  
│ └─vg_swap-lv_swap_encrypted 254:7    0  15.3G  0 lvm   
│   └─swap_unencrypted        254:8    0  15.3G  0 crypt [SWAP]
└─sda4                          8:4    0   3.6T  0 part  
  ├─arca_v1-root              254:0    0 186.3G  0 lvm   /
...                            11:0    1  1024M  0 rom   

You could look at the UUID for that LVM partition, but that's useless at this point.

Execute lsblk -o name,uuid,mountpoint

# ~/bin/lsblk -o name,uuid,mountpoint
NAME                          UUID                                   MOUNTPOINT
sda                                                                  
├─sda1                                                               
├─sda2                        XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX   /boot
├─sda3                        XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX 
│ └─vg_swap-lv_swap_encrypted                                        
│   └─swap_unencrypted
└─sda4                        XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX 
  ├─arca_v1-root              XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX   /
...

Newly created block device to /dev/mapper/swap_unencrypted now exists.

Details on /dev/mapper/swap_unencrypted:

# cryptsetup status swap_unencrypted
/dev/mapper/swap_unencrypted is active.
  type:    PLAIN
  cipher:  aes-cbc-essiv:sha256
  keysize: 256 bits
  key location: dm-crypt
  device:  /dev/mapper/vg_swap-lv_swap_encrypted
  sector size:  512
  offset:  0 sectors
  size:    31997952 sectors
  mode:    read/write

Create Swap Space

Create the swap space:

# mkswap /dev/mapper/swap_unencrypted 
Setting up swapspace version 1, size = 15.3 GiB (16382947328 bytes)
no label, UUID=8cd89984-9892-4d62-a9ba-ecfb6476379c

Now notice the UUID created for swap_unencrypted? This will always be different for each reboot.

# ~/bin/lsblk-uuid 
NAME                          UUID                                   MOUNTPOINT
sda                                                                  
├─sda1                                                               
├─sda2                        XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX   /boot
├─sda3                        XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX 
│ └─vg_swap-lv_swap_encrypted                                        
│   └─swap_unencrypted        8cd89984-9892-4d62-a9ba-ecfb6476379c   [SWAP]
└─sda4                        XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX 
  ├─arca_v1-root              XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX   /
...

Activate Swap Space

In /etc/fstab, modify or add the line of the swap entry:

/etc/mapper/swap_unencrypted none swap sw 0 0

Then execute:

# swapon /dev/mapper/swap_unencrypted

Swap space is now being encrypted using a random key.
Since dm-crypt is using UUID provided by LVM LV block device, this should be a sufficient answer to a functionally secured encrypted swap space.

Conclusion

UUID cannot be used for encrypted swap partition due to schotastic nature of encrypted data that prevents identification of such partition (swap, ext4, btfs).

UUID cannot be used for unencrypted swap partition provided by cryptsetup because our goal is to refresh the swap space at each reboot.

You could use /dev/disk/by-id.

But LVM offers more than enough sufficient protection by the virtue of YOUR unique naming convention of each the VG and LV partitions.

Above setup provides an uniquely encrypted swap space locator which will be scrambled yet unrecoverable after each reboot (or in event of rare case, LVM remount.)

Comments

[underscore_d]

"One could use ecryptfs to achieve the same ends [...] Without the problems that beset block device encryption." No, because ecryptfs-setup-swap is just a helper that configures dm-crypt/crypttab for you. As ecryptfs is a file-level driver, it doesn't handle entire partitions, so it farms that off to dm-crypt. You might find this method more user-friendly, but you are ultimately not achieving anything different. If anything, the quirks of this method (including the UUID) probably made me more confused than if I had just done it myself from first principles... though I learned more.

[Marcel Waldvogel]

On newer versions of cryptsetup, e.g. in Ubuntu 21.04, the following crypttab line is required cswap /dev/sda6 /dev/urandom plain,swap,discard,cipher=aes-cbc-essiv:sha256,size=256,keyf‌​ile-size=256.

[Geeb]

Thanks for your response. Yes I would agree the the Arch script is a sanity check to make sure the partition appears to be a swap partition. But I'm imagining having left a USB drive plugged in and rebooting to find a non-swap partition being used. I think I would cry real tears... I'm grateful for all the sanity checks I can get!

[idupree]

That shouldn't happen because you're using its UUID to find it in the first place. So all it'll find is the swap partition, or nothing.

[cscracker]

Note that the by-id name refers to both the model and serial number, which is extremely unlikely to overlap with any other device you might plug in.

[John Greene]

This use of by-id does not answer the question. The question is asking for by UUID as a safety precaution.

[John Greene]

Your answer uses by-id which does not answer the question. The question is asking for by-uuid.

[Marcel Waldvogel]

In newer versions of cryptsetup (e.g., Ubuntu 21.04), I needed to add the keyfile-size=256 option (and also added plain, to be sure, and discard), resulting in swap_unencrypted /dev/mapper/vg_swap-lv_swap_encrypted /dev/urandom swap,plain,discard,cipher= aes-cbc-essiv:sha256,size=256,keyfile-size=256

[John Greene]

as explained, the UUID for ENCRYPTED swap partition can be changed if going from mobo to mobo.

[Brian Minton]

The partition uuid is stored in the GPT. It's not going to change. That's the difference between UUID=xxx and PARTUUID=xxx. It's stored in the disk, not the motherboard.