Implementing boot.crypter for USB token/password authentication of encrypted hard drives and swap space
For most system administrators, desktop users, auditors and managers, data is extremely import. Data like financial, business secrets, and medical records, among a few, are extremely sensitive. The risk of having that data leaked, is greater than the minimal performance hit than doing disk based encryption. With modern computers, using software based encryption will not have a noticeable performance hit unless you have a slow hard disk or an older CPU.
SuSE Linux supports LUKS or Linux Unified Key Setup, which supports multiple keys. Using this guide you can setup a LUKS encrypted volume with USB key authentication that will mount the volume using USB key authentication or ask for a password when the system is booted up.
This article assumes the following:
- You are familiar with the basics of encryption
- Your computer supports USB drives
- You are familiar with the devices on your system and how to find USB storage devices
- You understand that there will be a minimal performance hit (more noticeable if on a laptop)
prepare the partitions
Depending on whether or not you belong to the Tinfoil hat conspiracy theorist camp, you might want to put all sorts of random data. For each partition, or logical volume that you are going to use, simply type “dd if=/dev/urandom of=DEVICE”. Time can be a couple of hours for larger drives or slow machines. The end result is that some-one looking at the system will be unable how much of the drive has data, as it will all look random.
create the physical encrypted volume
- Generate a random key for use with the encrypted volume
dd if=/dev/urandom of=key bs=256 count=1
- Create the encrypted device
bhoward10:/mnt # cryptsetup -v -s 256 luksFormat /dev/sdb1 key WARNING! ======== This will overwrite data on /dev/sdb1 irrevocably. Are you sure? (Type uppercase yes): YES Command successful. bhoward10:/mnt #
- Open the encrypted volume so we can place a filesystem on it. The following command will use device mapper to create a block device called /dev/mapper/accounting
cryptsetup -d key luksOpen /dev/sdb1 accounting
- Put a filesystem on it
- List the meta-data about the volume
bhoward10:/mnt # cryptsetup luksDump /dev/sdb1 LUKS header information for /dev/sdb1 Version: 1 Cipher name: aes Cipher mode: cbc-essiv:sha256 Hash spec: sha1 Payload offset: 2056 MK bits: 256 MK digest: 37 21 d7 65 86 75 90 04 6f 6d 3a 27 dc f3 9f 2a 18 5a 4a 9d MK salt: 26 23 30 1b d1 e3 85 b0 36 00 6c 3e 23 31 c8 84 7e a8 49 5d 8a 3a 4c ad 7c d2 40 37 f0 bc 33 21 MK iterations: 10 UUID: 45d9d181-7467-4a86-8eb6-1d57d8511d37 Key Slot 0: ENABLED Iterations: 207715 Salt: 5f f3 11 96 77 d3 1a 9d 3d e3 79 c4 d2 a5 eb 9a 07 06 a6 64 81 46 aa 67 51 7e 24 00 42 21 7d 21 Key material offset: 8 AF stripes: 4000 Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED bhoward10:/mnt #
- Populate the pass-phrase for an empty or disabled key slot. In order to do this you will need to reference the first key.
cryptsetup -d key /dev/sdb1 key slot 0 unlocked. Enter new passphrase for key slot: Verify passphrase: Command successful.
place the key on the usb drive
This step is pretty straight forward. However a decision needs to made. With a USB key there is the risk where the USB key can be copied. Ultimately this is the worst thing that could happen; after all what good is encryption if the key is divulged. Ultimately, this solution does not deal with this very effectively. In fact, I would argue that while there are advantages to USB key authentication for encrypted volumes, it does introduce a major security risk. Depending on how you implement this, there are some things to prevent this from happening. The decision that you need to make is how to reference the USB key.
Use the arbitrary kernel device name: The arbitrary kernel device name is usually /dev/sdbX. This the most flexible, as you can make as many copies of the USB key that you want. Biggest problem is that an unauthorized user that is able to copy the disk may be able to compromise the encrypted volume.
Use uDev identification: The big temptation is to use the file-system identification. The problem is that a fairly adept attacker could simply copy the entire filesystem. On Linux, this is fairly easy. As a result, I would recommend using the device’s own identification information.
To identify the devices device ID, type “ll /dev/disk/by-id”. The output will look something like this:
lrwxrwxrwx 1 root root 10 2008-01-16 13:55 usb-Kingston_DataTravelerMini_5B731863035D-part1 -> ../../sde1
configure the boot script
Part of this guide is a custom script that will look for the keys. If a key is found, then it will use that. Otherwise, the cryptsetup program will prompt for a password.
The location of the file is up to you, and the format is pretty simple. The default name of the file is /etc/sysconfig/cryptVolumes
For each encrypted partition add a line for each volume, with only one volume defined per line. The format is physical_device,volume_name,mount_point,key_file_name,key_location.
/dev/sdb1,accounting,/acct,key,/dev/disk/by-id/usb-Kingston_DataTravelerMini_5B731863035D-part1 /dev/sdb2,ceo_files,/ceo,key1,/dev/sdc1 /dev/sdb3,managers,/mgr
The first example will only use a key named key found on a single, specific device (see section above)
The second example will use a key named key1 found on ANY device that is known to the kernel as /dev/sdc1
The third example will prompt for a password
One of the features is that the script will bring an encrypted swap online. Of course, those who know about encryption will say something like, “swap is already slow, why on earth would I want to make it slower?” The reason that most sane people would encrypt a hard drive is because they are trying to prevent unauthorized people from accessing sensitive data or because you have something to hide. Tinfoil hat theories aside, the main reason is to protect the sensitive data from being swapped from memory to the swap space, including the encryption key. On Linux, there is no way to prevent something from being swapped to disk, short of turning swap off. So unless you have a machine with 8GB and can afford not having swap, it is strongly suggested that you encrypt swap. Besides, even if you don’t need it, you can always brag to the Tinfoil hat conspiracy crowd with the fact that, short of a lot of computing power, nobody will be able to see what was swapped to disk.
If you want to use the encrypted swap feature, simply add “SWAP=…” with the physical point that you want to use to swap, and then comment out the swap partition in your /etc/fstab.
load the script
The script provided in this document will automatically load the encrypted filesystems at boot, or at least prompt for the password. It will also handle the shutting down of the filesystems for you. It has been designed to be as robust as possible, but it may require some customization
- Download the script
- Place the script in /etc/init.d
- Make it executable
chmod 0755 /etc/init.d/boot.usbCrypt
- Insert it as a service
- Turn it on
- Reboot to test it
Double check each command and review the script for completeness and saftey. If the script has undesirable effects, you have been warned.
This document also ONLY dealt with securing the data as written to the disk in an encrypted volume. This can be circumvented if you transfer the data from an encrypted volume off to an unencrypted volume, or if you don’t secure the system when it is running. Less effective methods of securing the system would include not running a firewall, sharing out data on the encrypted volume, etc.