Article

(View Disclaimer)

the idea

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.

assumptions

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

1. Generate a random key for use with the encrypted volume
   

   dd if=/dev/urandom of=key bs=256 count=1

2. 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 #
   
   

3. 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
   
   

4. Put a filesystem on it
   

   mkfs.ext3 /dev/mapper/accounting

5. 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 #
   
   

6. 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

1. Download the script
2. Place the script in /etc/init.d
3. Make it executable
   

   chmod 0755 /etc/init.d/boot.usbCrypt
   
   

4. Insert it as a service
   

   insserv /etc/init.d/boot.usbCrypt
   
   

5. Turn it on
   

   chkconfig boot.usbCrypt
   
   

6. Reboot to test it

safety notice

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.

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.