Are there any risks from cloning a LUKS encrypted partition?

Question

I'm using an installation of Ubuntu server on disk, with some extra packages installed and configuration carried out, on disk as a kind of base image for repeatedly creating other systems. I clone this to a new disk, alter a bit of configuration and have a new working system in very little time. I understand that some sort of automated provisioning system such as Ansible may be a better way to go, but this is my current workflow.

However, I have one partition that's a LUKS container, managed with cryptsetup. This only has a single keyslot in use in the LUKS header. My approach is to alter the passphrase interactively with cryptsetup luksChangeKey.

I've considered also changing the UUID of the LUKS device. Although I'm not sure if that's adding anything, it will at least differentiate the partitions on different systems.

Am I creating an opportunity for attack by doing this?

Answer 1

Per the cryptsetup wiki,

Note: this section pertains to backups specifically, but I feel like it applies to your situation.

6.7 Does a backup compromise security?

Depends on how you do it...There are risks introduced by backups. For example if you change/disable a key-slot in LUKS, a binary backup of the partition will still have the old key-slot. To deal with this, you have to be able to change the key-slot on the backup as well, securely erase the backup or do a filesystem-level backup instead of a binary one.

To clarify, one should ensure that the old key-slot is removed in the cloned partition.

In both cases, there is an additional (usually small) risk with binary backups: An attacker can see how many sectors and which ones have been changed since the backup. To prevent this, use a filesystem level backup method that encrypts the whole backup in one go, e.g. as described above with tar and GnuPG.

To reiterate, one could simply back up the partition by creating an archive and encrypting it, and then moving it to a newly encrypted partition on the new machine and extracting it.

I've considered also changing the UUID of the LUKS device. Although I'm not sure if that's adding anything, it will at least differentiate the partitions on different systems.

I would recommend this.

6.15 Can I clone a LUKS container?

You can, but IT BREAKS SECURITY, because the cloned container has the same header and hence the same master key. You cannot change the master key on a LUKS container, even if you change the passphrase(s), the master key stays the same. That means whoever has access to one of the clones can decrypt them all, completely bypassing the passphrases.

The right way to do this is to first luksFormat the target container, then to clone the contents of the source container, with both containers mapped, i.e. decrypted. You can clone the decrypted contents of a LUKS container in binary mode, although you may run into secondary issues with GUIDs in filesystems, partition tables, RAID-components and the like. These are just the normal problems binary cloning causes.

Note that if you need to ship (e.g.) cloned LUKS containers with a default passphrase, that is fine as long as each container was individually created (and hence has its own master key). In this case, changing the default passphrase will make it secure again.