«
»

How to change encryption type on your encrypted LVM

If you are like a lot of users who were “early adopters” of Linux disk encryption, you probably installed with the aes-cbc-essiv encryption scheme, which is decent, but not as secure as the new aes-xts-plain encryption method.

There is a helpful post on the Ubuntu bugtracker explaining how to install Ubuntu with i.e. XTS support. Unfortunately, this does not help a user who wishes i.e. to change encryption methods while upgrading his hard disk.

A simpler method is here. I list the following step by step method for a complex LVM scenario where the simple method may not work.

The basic steps are as follows:

  • If you are upgrading your hard disk, connect the new disk through SATA or USB, and use dd, dd_rescue or g4l to clone your disk to the new disk, which must be of equal or greater capacity.
  • From now on, Disk A is the disk which is to remain in the system when finished, while Disk B is the standby backup disk that will be retained temporarily.
  • Boot into single user / recovery mode on Disk A.
  • Unmount all filesystems, and remount the root filesystem read-only (important!)
  • Mount Disk B somewhere (i.e. /mnt)
  • Use dd to make an image of each volume in /dev/mapper that you wish to keep and put the output file on Disk B. Use ‘1M’ as the dd blocksize.
  • If you run out of room on Disk B, you will have to pipe the dd output through gzip. Don’t forget which images you have gzipped!
  • IMPORTANT: Save copies of the output of vgdisplay, pvdisplay, and lvdisplay onto Disk B. This is what you will recreate your LVM volume structure from. Also copy /etc/fstab to Disk B.
  • Reboot with an Ubuntu “Alternate Installer” disk.
  • Find out what kernel is on the installer disk. Download the full .deb for this kernel from the Ubuntu archives. You will need to extract the modules for the encryption methods you are using. (For example, the ‘aes-xts-plain’ method requires the ‘xts’ and ‘gf128mul’ modules.) Then put these on a USB media, or on Disk B.
  • Follow the prompts until you reach the partitioner. It will not recognize your encrypted LVM partition. You need to select it and tell the installer that you want to use it as a physical volume for encryption. When you make this selection, the installer will also load the required kernel modules for encrypted LVM. Then you need to pick “Configure encrypted volumes”. This will force the changes to be saved.
  • After this point, you need to go to another console (Ctrl-F2) to load your encryption modules by hand using insmod, either off Disk B or the USB media you used in the previous step.
  • You can then follow the instructions in the Ubuntu bug referenced above. The important steps are to: 1) Delete the dm-crypt entry that exists. 2) Create a new encrypted LVM. 3) Open the new encrypted LVM.
  • Then, go back into the partitioner. Hit enter on the encrypted volume and choose “Physical volume for LVM”. Then select Configure Logical Volumes.
  • Now is the part where having a copy of your lvdisplay output is a lifesaver. Recreate the logical volumes with the same names and sizes as they were, referring to the lvdisplay output. (Unfortunately, you cannot set the UUID because the busybox and udeb versions of mke2fs and mkswap do not support setting the UUID. If you could, referring to the filesystem UUIDs in your copy of fstab would allow you to recreate any filesystems you chose not to clone without requiring any reconfiguration. By the way, the LVM UUID is separate from the filesystem UUID. The filesystem UUID is what interests us.)
  • Now, you MUST, while still in the installer, use dd to clone the backed-up root filesystem back onto the root filesystem volume that now exists in /dev/mapper.
  • Then, mount /dev/mapper/root or whatever your root volume is onto /mnt.
  • Mount /dev/sda5, or whatever your boot partition is, onto /mnt/boot.
  • chroot into /mnt/boot. Then mount /proc inside the chroot. You will probably want to run bash as well.
  • There are several files you will need to fix. I will identify them, but fixing them is context dependent. These are the configuration files that will prevent your system from booting if they are not correct: /boot/grub/menu.lst; /etc/initramfs-tools/modules; /etc/crypttab; /etc/initramfs-tools/conf.d/resume; /etc/fstab.
  • In /boot/grub/menu.lst, you will probably need to fix the root= option as well as the groot= option. The groot expects the device or UUID of the filesystem where the GRUB files can be found, i.e., /boot. After modifying this file, always run update-grub.
  • In /etc/fstab, you will need to update the UUIDs with the UUIDs that were created for any filesystems that you chose to recreate instead of to backup and restore. To find the UUID for a filesystem, use debugfs and issue the command stats inside its shell.
  • In /etc/crypttab, you must give the physical volume name (i.e. sda6_crypt) as well as the UUID of the partition that contains the encrypted LVM. For example, your physical partition might be /dev/sda6. To find the UUID, ls -l /dev/disk/by-uuid and look for the UUID that points to /dev/sda6. This is the UUID you need to use. After changing this, you must run update-initramfs -k all -u.
  • In /etc/initramfs-tools/modules, you must list any modules that may not be detected as necessary in order to access the root filesystem. For the aes-xts-plain encryption method, both gf128mul and xts are required. These modules will be copied into the initrd and loaded unconditionally. After changing this, you must run update-initramfs -k all -u.
  • In /etc/initramfs-tools/conf.d/resume, you must list the swap device that suspend/resume is to function upon. This is actually critical to have correct, even if you don’t use suspend/resume, because if it is not found, the startup scripts will die. After changing this, you must run update-initramfs -k all -u.
  • Now, you should be ready to reboot. Be sure to choose the single user/recovery option.
  • Unfortunately, since GRUB did not have any way to determine the partition where the kernel images reside while in the chroot, you will need to edit the GRUB command line and remove the /boot prefix from both the kernel and initrd lines. Then hit ‘b’ to boot.
  • If you end up with a long delay and get dropped into an initramfs shell, you screwed up something with the above five configuration files. Go back into the installer, and try again. But this time, instead of deleting the encrypted partition and recreating it, simply tell it to use it as physical partition for encryption, so that it loads the modules, load your required modules by hand again, and then use cryptsetup luksOpen ... to open the encrypted partition. Then what? To get the device-mapper volumes to show up again, you must do vgscan --mknodes and then vgchange -a y. Then you can mount your root volume and try again in the chroot.
  • If you get a password prompt, you are almost good to go. You will probably have to type in your password three times. Then you will get some errors about missing filesystems and such. But you will get a root shell prompt inside your proper root filesystem. This is the only important part. This means that the encrypted partition is being found and properly unlocked, and that the kernel is finding your root filesystem. From here, you can then use mke2fs and mkswap to recreate any non-backed-up filesystems with the UUID that is expected, or else modify the /etc/fstab to reflect the new UUIDs. You can also now clone back any filesystems that you backed-up, remembering to use zcat when dealing with any filesystem image that you had to compress. Then you need to update-grub to fix up GRUB with the correct paths to the kernel and initrd images.

Leave a Reply