Sensitive data needs total protection. And there’s no better way of protecting your sensitive data than by encrypting it. This article is a tutorial on how to encrypt your laptop or server partitions using LUKS.
Sensitive data on mobile systems such as laptops can get compromised if they get lost, but this risk can be mitigated if the data is encrypted. Red Hat Linux supports partition encryption through the Linux Unified Key Setup (LUKS) on-disks-format technology. Encrypting partitions is easiest during installation but LUKS can also be configured post installation.
Encryption during installation
When carrying out an interactive installation, tick the Encrypt checkbox while creating the partition to encrypt it. When this option is selected, the system will prompt users for a passphrase to be used for decrypting the partition. The passphrase needs to be manually entered every time the system boots.
When performing automated installations, Kickstart can create encrypted partitions. Use the —encrypted and —passphrase option to encrypt each partition. For example, the following line will encrypt the /home partition:
# part /home --fstype=ext4 --size=10000 --onpart=vda2 --encrypted --passphrase=PASSPHRASE
Note that the passphrase, PASSPHRASE is stored in the Kickstart profile in plain text, so this profile must be secured. Omitting the –passphrase = option will cause the installer to pause and ask for the passphrase during installation.
Encryption post installation
Listed below are the steps needed to create an encrypted volume:
1. Create either a physical disk partition or a new logical volume.
2. Encrypt the block device and designate a passphrase, by using the following command:
# cryptsetup luksFormat /dev/vdb1
3. Unlock the encrypted volume and assign it a logical volume, as follows:
# cryptsetup luksOpen /dev/vdb1 name
4. Create a file system in the decrypted volume, using the following command:
# mkfs -t ext4 /dev/mapper/name
As shown in Figure 1, the partition has been encrypted and opened and, finally, a file system is associated with the partition.
5. Create a mount point for the file system, mount it, and then access its contents as follows:
#mkdir /secret #mount /dev/mapper/name /secret
We can verify the mounted partition using the df -h command, as shown in Figure 2.
6. When finished, unmount the file system and then lock the encrypted volume, as follows:
#umount /secret
Note: The directory should be unmounted before closing the LUKS partition. After the partition has been closed, it will be locked. This can be verified using the df -h command, as shown in Figure 2.
# cryptsetup luksClose name
How to persistently mount encrypted partitions
If a LUKS partition is created during installation, normal system operation prompts the user for the LUKS passphrase at boot time. This is fine for a laptop, but not for servers that may need to be able to reboot, unattended.
To boot a server with an encrypted volume unattended, a file must be created with a LUKS key that will unlock the encrypted volume. This file must reside on an unencrypted file system on the disk. Of course, this presents a security risk if the file system is on the same disk as the encrypted volume, because theft of the disk would include the key needed to unlock the encrypted volume. Typically, the file with the key is stored on removable media such as a USB drive.
Here are the steps to be taken to configure a system to persistently mount an encrypted volume without human intervention.
1. First, locate or generate a key file. This is typically created with random data on the server and kept on a separate storage device. The key file should take random input from /dev/urandom, and generate our output /root/key.txt with a block size of 4096 bytes as a single count of random numbers.
# dd if=/dev/urandom of=/root/key.txt bs=4096 count=1
Make sure it is owned by the root user and the mode is 600, as follows:
# chmod 600 /root/key.txt
Add the key file for LUKS using the following command:
# cryptsetup luksAddKey /dev/vda1 /root/key.txt
Provide the passphrase used to unlock the encrypted volume when prompted.
2. Create an /etc/crypttab entry for the volume. /etc/crypttab contains a list of devices to be unlocked during system boot.
# echo “name /dev/vdb1 /root/key.txt” >> /etc/crypttab
…lists one device per line with the following space-separated fields:
- The device mapper used for the device
- The underlying locked device
- The absolute pathname to the password file used to unlock the device (if this field is left blank, or set to none, the user will be prompted for the encryption password during system boot)
3. Create an entry in /etc/fstab as shown below. After making the entry in /etc/fstab, if we open the partition using the key file, the command will be:
# cryptsetup luksOpen /dev/vdb1 --key-file /root/key.txt name
As shown in the entry of the fstab file, if the device to be mounted is named, then the file system on which the encrypted partition should be permanently mounted is in the other entries. Also, no passphrase is asked for separately now, as we have supplied the key file, which has already been added to the partition. The partition can now be mounted using the mount -a command, after which the mounted partition can be verified upon reboot by using the df -h command. All the steps are clearly described in Figure 5.
Note: The device listed in the first field of /etc/fstab must match the name chosen for the local name to map in /etc/crypttab. This is a common configuration error.
Attaching a key file to the desired slot
LUKS offers a total of eight key slots for encrypted devices (0-7). If other keys or a passphrase exist, they can be used to open the partition. We can check all the available slots by using the luksDump command as shown below:
# cryptsetup luksDump /dev/vdb1
As can be seen in Figure 5, Slot0 and Slot1 are enabled. So the key file we have supplied manually, by default moves to Slot1, which we can use for decrypting the partition. Slot0 carries the master key, which is supplied while creating the encrypted partition.
Now we will add a key file to Slot3. For this, we have to generate a key file of random numbers by using the urandom command, after which we will add it to Slot3 as shown below. The passphrase of the encrypted partition must be supplied in order to add any secondary key to the encrypted volume.
# dd if=/dev/urandom of=/root/key2.txt bs=4096 count=1. #cryptsetup luksAddKey /dev/vdb1 --key-slot 3 /root/key2.txt.
After adding the secondary key, again run the luksDump command to verify whether the key file has been added to Slot3 or not. As shown in Figure 7, the key file has been added to Slot3, as Slot2 remains disabled and Slot3 has been enabled with the key file supplied. Now Slot3 can also be used to decrypt the partition.
Restoring LUKS headers
For some commonly encountered LUKS issues, LUKS header backups can mean the difference between a simple administrative fix and permanently unrecoverable data. Therefore, administrators of LUKS encrypted volumes should engage in the good practice of routinely backing up their headers. In addition, they should be familiar with the procedures for restoring the headers from backup, should the need arise.
LUKS header backup
LUKS header backups are performed using the cryptsetup tool in conjunction with the luksHeaderBackup sub-command. The location of the header is specified with the –header-backup-file option. So by using the command given below we can create the backup of any LUKS header:
# cryptsetup luksHeaderBackup /dev/vdb1 --header-backup-file /root/back
As with all systems administration tasks, LUKS header backup should be done before every administrative task performed on a LUKS-encrypted volume. Should the LUKS header be corrupted, LUKS stores a metadata header and key slots at the beginning of each encrypted device. Thus, corruption of the LUKS header can render the encrypted data inaccessible. If a backup of the corrupted LUKS header exists, the issue can be resolved by restoring the header from this backup.
Testing and recovering LUKS headers
If an encrypted volume’s LUKS header has been backed up, the backups can be restored to the volume to overcome issues such as forgotten passwords or corrupted headers. If multiple backups exist for an encrypted volume, an administrator needs to identify the proper one to restore. The header can be restored using the following command:
# cryptsetup luksHeaderRestore /dev/vdb1 --header-backup-file /root/backup
Now, let’s suppose someone has changed the password of the encrypted partition /dev/vdb1 using luksChangeKey, but the password is unknown. So the only option is to restore the partition from the backup that we have created above, so that we can decrypt the partition from the previous passphrase. The backup also helps when admin forgets the passphrase.
In Figure 8, a backup of /dev/vdb1 has been taken initially, and its passphrase has been subsequently changed by someone, without our knowledge.
Before closing a partition, we have to unmount the locked partition. After closing the partition, trying to open the partition by using the previously set passphrase will throw the error ‘No key available with this passphrase’, because the passphrase has been changed by someone (Figure 9).
But as the backup has already been taken by us, we just need to restore the LUKS header from the backup file which was created earlier. As shown in Figure 10, the header has been restored.
Now we can open the header with the passphrase that was set earlier. Therefore, it is always beneficial for administrators to create a backup of their header, so that they can restore it if somehow the existing header gets corrupted or a password is changed.
