En­crypt­ing Par­ti­tions Us­ing LUKS

Sen­si­tive data needs to­tal pro­tec­tion. And there’s no bet­ter way of pro­tect­ing your sen­si­tive data than by en­crypt­ing it. This ar­ti­cle is a tu­to­rial on how to en­crypt your laptop or server par­ti­tions us­ing LUKS.

OpenSource For You - - Contents - By: Kshi­tij Upad­hyay The au­thor is RHCSA and RHCE cer­ti­fied, and loves to write about new tech­nolo­gies. He can be reached at upad­hyayk04@gmail.com.

Sen­si­tive data on mo­bile sys­tems such as lap­tops can get com­pro­mised if they get lost, but this risk can be mit­i­gated if the data is en­crypted. Red Hat Linux sup­ports par­ti­tion en­cryp­tion through the Linux Uni­fied Key Setup (LUKS) on-disks-for­mat tech­nol­ogy. En­crypt­ing par­ti­tions is eas­i­est dur­ing in­stal­la­tion but LUKS can also be con­fig­ured post in­stal­la­tion.

En­cryp­tion dur­ing in­stal­la­tion

When car­ry­ing out an in­ter­ac­tive in­stal­la­tion, tick the En­crypt check­box while cre­at­ing the par­ti­tion to en­crypt it. When this op­tion is se­lected, the sys­tem will prompt users for a passphrase to be used for de­crypt­ing the par­ti­tion. The passphrase needs to be man­u­ally en­tered ev­ery time the sys­tem boots.

When per­form­ing au­to­mated in­stal­la­tions, Kick­start can create en­crypted par­ti­tions. Use the --en­crypted and --passphrase op­tion to en­crypt each par­ti­tion. For ex­am­ple, the fol­low­ing line will en­crypt the /home par­ti­tion:

# part /home --fstype=ext4 --size=10000 --on­part=vda2 --en­crypted --passphrase=PASSPHRASE

Note that the passphrase, PASSPHRASE is stored in the Kick­start pro­file in plain text, so this pro­file must be se­cured. Omit­ting the –passphrase = op­tion will cause the in­staller to pause and ask for the passphrase dur­ing in­stal­la­tion.

En­cryp­tion post in­stal­la­tion

Listed be­low are the steps needed to create an en­crypted vol­ume:

1. Create ei­ther a phys­i­cal disk par­ti­tion or a new log­i­cal vol­ume.

2. En­crypt the block de­vice and des­ig­nate a passphrase, by us­ing the fol­low­ing com­mand:

# crypt­setup luk­sFor­mat /dev/vdb1

3. Un­lock the en­crypted vol­ume and as­sign it a log­i­cal vol­ume, as fol­lows:

# crypt­setup luk­sOpen /dev/vdb1 name

4. Create a file sys­tem in the de­crypted vol­ume, us­ing the fol­low­ing com­mand:

# mkfs -t ext4 /dev/map­per/name

As shown in Fig­ure 1, the par­ti­tion has been en­crypted and opened and, fi­nally, a file sys­tem is as­so­ci­ated with the par­ti­tion.

5. Create a mount point for the file sys­tem, mount it, and

then ac­cess its con­tents as fol­lows:

#mkdir /se­cret

#mount /dev/map­per/name /se­cret

We can ver­ify the mounted par­ti­tion us­ing the df -h com­mand, as shown in Fig­ure 2.

6. When fin­ished, un­mount the file sys­tem and then lock the

en­crypted vol­ume, as fol­lows:

#umount /se­cret

Note: The di­rec­tory should be un­mounted be­fore closing the LUKS par­ti­tion. Af­ter the par­ti­tion has been closed, it will be locked. This can be ver­i­fied us­ing the df -h com­mand, as shown in Fig­ure 2.

# crypt­setup luk­sClose name

How to per­sis­tently mount en­crypted par­ti­tions

If a LUKS par­ti­tion is cre­ated dur­ing in­stal­la­tion, nor­mal sys­tem op­er­a­tion 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 re­boot, unattended.

To boot a server with an en­crypted vol­ume unattended, a file must be cre­ated with a LUKS key that will un­lock the en­crypted vol­ume. This file must re­side on an un­en­crypted file sys­tem on the disk. Of course, this presents a se­cu­rity risk if the file sys­tem is on the same disk as the en­crypted vol­ume, be­cause theft of the disk would in­clude the key needed to un­lock the en­crypted vol­ume. Typ­i­cally, the file with the key is stored on re­mov­able me­dia such as a USB drive.

Here are the steps to be taken to con­fig­ure a sys­tem to per­sis­tently mount an en­crypted vol­ume with­out hu­man in­ter­ven­tion.

1. First, lo­cate or gen­er­ate a key file. This is typ­i­cally cre­ated with ran­dom data on the server and kept on a sep­a­rate stor­age de­vice. The key file should take ran­dom in­put from /dev/uran­dom, and gen­er­ate our out­put /root/ key.txt with a block size of 4096 bytes as a sin­gle count of ran­dom num­bers.

# dd if=/dev/uran­dom of=/root/key.txt bs=4096 count=1

Make sure it is owned by the root user and the mode is 600, as fol­lows:

# chmod 600 /root/key.txt Add the key file for LUKS us­ing the fol­low­ing com­mand: # crypt­setup luk­sAd­dKey /dev/vda1 /root/key.txt

Pro­vide the passphrase used to un­lock the en­crypted vol­ume when prompted.

2. Create an /etc/crypt­tab en­try for the vol­ume. /etc/crypt­tab

con­tains a list of de­vices to be un­locked dur­ing sys­tem boot. # echo “name /dev/vdb1 /root/key.txt” >> /etc/crypt­tab

…lists one de­vice per line with the fol­low­ing space­sep­a­rated fields:

The de­vice map­per used for the de­vice

The un­der­ly­ing locked de­vice

The ab­so­lute path­name to the pass­word file used to un­lock the de­vice (if this field is left blank, or set to none, the user will be prompted for the en­cryp­tion pass­word dur­ing sys­tem boot)

3. Create an en­try in /etc/fstab as shown be­low. Af­ter mak­ing the en­try in /etc/fstab, if we open the par­ti­tion us­ing the key file, the com­mand will be:

# crypt­setup luk­sOpen /dev/vdb1 --key-file /root/key.txt name

As shown in the en­try of the fstab file, if the de­vice to be mounted is named, then the file sys­tem on which the en­crypted par­ti­tion should be per­ma­nently mounted is in the other en­tries. Also, no passphrase is asked for separately now, as we have supplied the key file, which has al­ready been added to the par­ti­tion. The par­ti­tion can now be mounted us­ing the mount -a com­mand, af­ter which the mounted par­ti­tion can be ver­i­fied upon re­boot by us­ing the df -h com­mand. All the steps are clearly de­scribed in Fig­ure 5.

Note: The de­vice listed in the first field of /etc/fstab must match the name cho­sen for the lo­cal name to map in /etc/crypt­tab. This is a common con­fig­u­ra­tion er­ror.

At­tach­ing a key file to the de­sired slot

LUKS of­fers a to­tal of eight key slots for en­crypted de­vices (0-7). If other keys or a passphrase ex­ist, they can be used to open the par­ti­tion. We can check all the avail­able slots by us­ing the luk­sDump com­mand as shown be­low:

# crypt­setup luk­sDump /dev/vdb1

As can be seen in Fig­ure 5, Slot0 and Slot1 are en­abled. So the key file we have supplied man­u­ally, by de­fault moves to Slot1, which we can use for de­crypt­ing the par­ti­tion. Slot0 car­ries the master key, which is supplied while cre­at­ing the en­crypted par­ti­tion.

Now we will add a key file to Slot3. For this, we have to gen­er­ate a key file of ran­dom num­bers by us­ing the uran­dom com­mand, af­ter which we will add it to Slot3 as shown be­low. The passphrase of the en­crypted par­ti­tion must be supplied in or­der to add any sec­ondary key to the en­crypted vol­ume.

# dd if=/dev/uran­dom of=/root/key2.txt bs=4096 count=1. #crypt­setup luk­sAd­dKey /dev/vdb1 --key-slot 3 /root/key2. txt.

Af­ter adding the sec­ondary key, again run the luk­sDump com­mand to ver­ify whether the key file has been added to Slot3 or not. As shown in Fig­ure 7, the key file has been added to Slot3, as Slot2 re­mains dis­abled and Slot3 has been

en­abled with the key file supplied. Now Slot3 can also be used to de­crypt the par­ti­tion.

Restoring LUKS head­ers

For some com­monly en­coun­tered LUKS is­sues, LUKS header back­ups can mean the dif­fer­ence be­tween a simple ad­min­is­tra­tive fix and per­ma­nently un­re­cov­er­able data. There­fore, ad­min­is­tra­tors of LUKS en­crypted vol­umes should en­gage in the good prac­tice of rou­tinely back­ing up their head­ers. In addition, they should be fa­mil­iar with the pro­ce­dures for restoring the head­ers from backup, should the need arise.

LUKS header backup

LUKS header back­ups are per­formed us­ing the crypt­setup tool in con­junc­tion with the luk­sHead­erBackup sub­com­mand. The lo­ca­tion of the header is spec­i­fied with the ­­header­backup­file op­tion. So by us­ing the com­mand given be­low we can create the backup of any LUKS header:

# crypt­setup luk­sHead­erBackup /dev/vdb1 --header-backup-file / root/back

As with all sys­tems ad­min­is­tra­tion tasks, LUKS header backup should be done be­fore ev­ery ad­min­is­tra­tive task per­formed on a LUKS-en­crypted vol­ume. Should the LUKS header be cor­rupted, LUKS stores a meta­data header and key slots at the be­gin­ning of each en­crypted de­vice. Thus, cor­rup­tion of the LUKS header can ren­der the en­crypted data in­ac­ces­si­ble. If a backup of the cor­rupted LUKS header ex­ists, the is­sue can be re­solved by restoring the header from this backup.

Test­ing and recovering LUKS head­ers

If an en­crypted vol­ume’s LUKS header has been backed up, the back­ups can be re­stored to the vol­ume to over­come is­sues such as for­got­ten pass­words or cor­rupted head­ers. If mul­ti­ple back­ups ex­ist for an en­crypted vol­ume, an ad­min­is­tra­tor needs to iden­tify the proper one to re­store. The header can be re­stored us­ing the fol­low­ing com­mand:

# crypt­setup luk­sHead­erRe­store /dev/vdb1 --header-backup-file /root/backup

Now, let’s sup­pose some­one has changed the pass­word of the en­crypted par­ti­tion /dev/vdb1 us­ing luk­sChangeKey, but the pass­word is un­known. So the only op­tion is to re­store the par­ti­tion from the backup that we have cre­ated above, so that we can de­crypt the par­ti­tion from the previous passphrase. The backup also helps when ad­min for­gets the passphrase.

In Fig­ure 8, a backup of /dev/vdb1 has been taken ini­tially, and its passphrase has been sub­se­quently changed by some­one, with­out our knowl­edge.

Be­fore closing a par­ti­tion, we have to un­mount the locked par­ti­tion. Af­ter closing the par­ti­tion, try­ing to open the par­ti­tion by us­ing the pre­vi­ously set passphrase will throw the er­ror ‘No key avail­able with this passphrase’, be­cause the passphrase has been changed by some­one (Fig­ure 9).

But as the backup has al­ready been taken by us, we just need to re­store the LUKS header from the backup file which was cre­ated ear­lier. As shown in Fig­ure 10, the header has been re­stored.

Now we can open the header with the passphrase that was set ear­lier. There­fore, it is al­ways ben­e­fi­cial for ad­min­is­tra­tors to create a backup of their header, so that they can re­store it if some­how the ex­ist­ing header gets cor­rupted or a pass­word is changed.

Fig­ure 1: An en­crypted par­ti­tion with an ext4 file sys­tem

Fig­ure 2: The en­crypted par­ti­tion has been locked and ver­i­fied

Fig­ure 3: A key file has been gen­er­ated and added to the LUKS par­ti­tion

Fig­ure 5: Avail­able slots for an en­crypted par­ti­tion are shown

Fig­ure 7: Slot3 en­abled suc­cess­fully

Fig­ure 4: De­cryp­tion of a per­sis­tent en­crypted par­ti­tion us­ing the key file

Fig­ure 6: Sec­ondary key file key2.txt has been added at Slot3

Fig­ure 9: De­crypt­ing a par­ti­tion with the passphrase supplied ini­tially

Fig­ure 10: Header is re­stored from the backup file

Fig­ure 8: Passphrase has been changed

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.