Removing system encryption - ArchWiki

Jump to content
From ArchWiki

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Reason: written in first person, other style issues. (Discuss in Talk:Removing system encryption)

Removing system encryption with dm-crypt and LUKS.

## Removing LUKS Encryption in-place

This article or section is out of date.

Reason: `cryptsetup-reencrypt` tool has been removed as of cryptsetup 2.5.0. See cryptsetup-reencrypt(8) (Discuss in Talk:Removing system encryption)

### Overview

Although not as safe as backing up your data and restoring it on to a reformatted device, cryptsetup does allow the user to permanently remove the LUKS encryption from a device in-place. For example, if you have an ext4 filesystem living inside a LUKS-encrypted partition, performing in-place decryption will remove the LUKS signature, and place the ext4 filesystem directly on the partition, so that you can mount it directly. Unless something goes wrong, the files in the filesystem will remain intact. The terms used by cryptsetup's documentation for this is "decryption."

Support for non-destructive offline decryption of LUKS1 devices has been available starting with `cryptsetup` version 1.5.0, which was released in 2012. LUKS1 decryption only supported offline mode decryption.

For LUKS2 devices, both offline and online (i.e. unmount not required) decryption are supported.

Warning: The procedures which follow are inherently risky and may cause catastrophic data loss. You should always backup your drive and LUKS headers before proceeding, to protect your data from accidents during decryption.

### Decrypting LUKS1 devices in-place

Decryption is done in offline mode, using the (noq legacy) `cryptsetup-reencrypt` command. The steps are:

1. Verify that your block device has a LUKS1 header (and not LUKS2) using `cryptsetup luksDump <dev>`
2. reboot into a live environment using a USB stick.
3. Identify your block device using `blkid`, `lsblk`, etc'
4. Make sure that the block device to be decrypted has not been opened by cryptsetup (there is no entry under `/dev/mapper/`, let alone mounted. If it has been, unmount and use `cryptsetup luksClose` to close it.
5. Use the legacy command `cryptsetup-reencrypt`:

    # cryptsetup-reencrypt --decrypt <device_path>

The process might take a while. If no problems occur, the contents of the encrypted block device should not be accessible directly from the block device. i.e., you should be able to mount it directly.

### Decrypting LUKS2 devices in-place

Decryption can be done in either offline or online mode, using the `cryptsetup` command.

Warning: As of 2020, and version 2.3.3, when using cryptsetup to decrypt a LUKS2 block device the program requires you to provide a LUKS `--header` file. If you do not use the "detached header" feature of LUKS, and naively try to pass the block device itself (which contains a LUKS2 header) as the subject of the `--header`, cryptsetup will accept this and go ahead with alleged decryption. Afterwards the block device will show up as a LUKS2 device with no key-slots, and your data will be lost. If you try to use `cryptsetup luksHeaderBackup` as the header file used with `--header`, your data will be lost. If you try to restore a backed-up header after this faulty decryption, your data will still be lost.

If you still went ahead with the decryption, the data might be recoverable by shifting the partition start after the now defunct LUKS header: [1], still, do not rely on this.

Given the data loss risk just noted, you should avoid in-place decryption of LUKS2 devices unless you use detached header. I have tested offline LUKS2 decryption for a device with a detached header file and the procedure went smoothly. This functionality is also part of the tests included in the cryptsetup source.

If you do not use a detached header, your safest course is to use the safer backup-format-restore procedure described below. Alternatively, you can choose to convert your LUKS2 device to a LUKS1 device, and then proceed with the LUKS1 decryption procedure.

The conversion with take a significant amount of time, the system should be connected to mains power and extreme care should be taken to avoid any event that may lead to a system crash or loss of power. Data loss may occur if interrupted.

Steps:

1. Verify that your block device has a LUKS2 header (and not LUKS1) using `cryptsetup luksDump dev`
2. Note what key slots are in use using `cryptsetup luksDump dev`
3. Reboot into a live environment using a USB stick.
4. Identify your block device using `blkid` or `lsblk`.
5. Make sure that the block device to be decrypted has not been opened by `cryptsetup` (there is no entry under `/dev/mapper/`, let alone mounted). If it has been, unmount and use `cryptsetup luksClose` to close it.
6. Before converting the device, you must convert the Password-Based Key Derivation Function (PBKDF) for all key-slots to be LUKS1 compatible. Use the following command for each key slot: `sudo cryptsetup luksConvertKey --key-slot key_slot_number --pbkdf pbkdf2 device_path`
7. Verify that all key slots PBKDFs are convert to pbkdf2: `cryptsetup luksDump dev`
8. Convert the device from LUKS2 to LUKS1: `sudo cryptsetup convert --type luks1 device_path`
9. Decrypt the (now) LUKS1 device: `sudo cryptsetup-reencrypt --decrypt device_path`

If successful, you should now be able to mount whatever filesystem was previously inside the LUKS device, by mounting the block device directly.

Hopefully, the `cryptsetup` project will address these usability and data loss issues in a future release (written August 2020).

### Cleaning up system files

Device names and UUIDs may change due to decryption, and you will likely need to update relevant configuration files. The files most likely to need updating are `/etc/crypttab`, `/etc/fstab` and, if your recently decrypted device appeared on the kernel command line, your bootloader's configuration (e.g, `/etc/default/grub`). If you edit the latter, remember to regenerate the grub configuration as described in GRUB.

## Removing LUKS via Backup-Format-Restore

### Prerequisites

- An encrypted root filesystem you wish to decrypt.
- Enough drive space to store a backup.
- An Arch Linux (or other) live CD/USB.
- A few hours.

### Boot into a live environment

Download and burn the latest Arch ISO to a CD or USB, reboot the system, and boot to cd.

### Activate partitions

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

Reason: Hard to read, written like a blog post, misses some prompts. (Discuss in Talk:Removing system encryption)

#### Note about different setups

An example setup is shown here:

Disk
NTFS | myvg(lvm) | NTFS
Other OS | cryptswap(lv) | cryptroot(lv) | Shared
luks | luks
swap | root(xfs)

The grey partition is a frame of reference and can be ignored. The yellow partition will be used as storage space and may be changed at will. The green partitions will be modified. Bold text must match your system's setup.

In the example system: myvg contains lvs called cryptroot and cryptswap. They are located at `/dev/myvg/cryptroot` and `/dev/myvg/cryptswap`. Upon boot, LUKS is used along with a few crypttab entries to create `/dev/mapper/root` and `/dev/mapper/swap`.

Swap will not be unencrypted as part of this guide, as undoing the swap encryption does not require any complex backup or restoration.

The example system is not indicative of all systems. Different filesystems require different tools to effectively backup and restore their data. LVM can be ignored if not used.

Note: XFS requires xfs_copy to ensure an effective backup and restore, dd is insufficient. dd may be used with ext2, 3 and 4.

This article or section needs expansion.

Reason: What of jfs, reiserfs and reiser4fs? (Discuss in Talk:Removing system encryption)

#### Once partitions are located

Load necessary modules. For device mapper/LVM:

    # modprobe dm-mod

For LUKS:

    # modprobe dm-crypt

Scan for physical, volume and logical volumes:

    # pvscan; vgscan; lvscan

Activate the LVM volume group:

    # lvchange -ay myvg/cryptroot

Open the encrypted filesystem with LUKS so that it can be read:

    # cryptsetup luksOpen /dev/myvg/cryptroot root

Enter password.

Note: The only partition that will be operated on that should be mounted at this point is the backup partition. If a partition other than the backup partition is already mounted, it can be safely umounted it now.

##### Mounting backup space

Only if using NTFS to store the backup, install ntfs-3g.

The next step is important for backup storage.

    # mount -t ntfs-3g -o rw /dev/sdXY /mount/point/

or use netcat to store the backup on a remote system.

This article or section needs expansion.

Reason: Add netcat instructions. (Discuss in Talk:Removing system encryption)

### Backup data

Using xfs_copy:

    # xfs_copy -db /dev/mapper/root /mount/point/backup_root.img

Note: The `-d` flag preserves UUIDs and `-b` ensures direct IO is not attempted to any of the target files.

Using dd:

    # dd if=/dev/mapper/root of=/mount/point/backup_root.img

### Undo encryption

This is the point of no return. Make sure that you are ready for this step. If you plan to undo this later, you will have to start almost from scratch.

    # cryptsetup luksClose root
    # lvm lvremove myvg/cryptroot

### Restore data

We have to create a new logical volume to house our root filesystem, then we restore our filesystem.

    # lvm lvcreate -l 100%FREE -n root myvg
    # xfs_copy -db /mount/point/backup_root.img /dev/myvg/root

The second drive name is changed now.

### Adjust configurations

You need to boot into your system and edit `/etc/crypttab`, `/etc/mkinitcpio.conf`, `/etc/fstab`, and possibly `/boot/grub/menu.lst`.

Category:

- Data-at-rest encryption

Hidden categories:

- Pages or sections flagged with Template:Style
- Pages or sections flagged with Template:Out of date
- Pages or sections flagged with Template:Expansion