Linux Mint - Free and powerful

Thursday, 7 June 2012

Two form factor encryption


Technical details on the passdev keyscript


The debian package already contains the 'passdev' keyscript which implements a similar approach. See section '10. The "passdev" keyscript' of /usr/share/doc/cryptsetup/README.initramfs.gz:

If you have a keyfile on a removable device (e.g. a USB-key), you can use the passdev keyscript. It will wait for the device to appear, mount it read-only, read the key and then unmount the device.

The "key" part of /etc/crypttab will be interpreted as :, it is strongly recommended that you use one of the persistent device names from /dev/disk/*, e.g. /dev/disk/by-label/myusbkey.

This is an example of a suitable line in cryptsetup: cryptroot /dev/hda2 /dev/disk/by-label/myusbkey:/keys/root.key cipher=aes-cbc-essiv:sha256,size=256,hash=plain,keyscript=/lib/cryptsetup/scripts/passdev

The above line would cause the boot to pause until /dev/disk/by-label/myusbkey appears in the fs, then mount that device and use the file /keys/root.key on the device as the key (without any hashing) as the key for the fs.

Also, you should be able to replace the function type_key() by invoking '/lib/cryptsetup/askpass "Enter password: "'.
Show quoted text

The passdev keyscript supports all common filesystems. Only support for LUKS-encrypted media is missing. Maybe you could use the same syntax as passdev in /etc/crypttab and simplify your keyscript like the following (untested by me):

#!/bin/sh
argv="$1"
IFS=':' echo "$argv" | while read keydev keyfile; do
 if /lib/cryptsetup/scripts/passdev "$argv"; then
  exit 0
 elif /sbin/cryptsetup isLuks "$keydev"; then
  count=0; while [ $count -lt 3 ]; do
   if /lib/cryptsetup/askpass "Enter password: " | /sbin/cryptsetup --readonly --key-file=- luksOpen "$keydev" "keydevscript"; then
    /lib/cryptsetup/scripts/passdev "${keydev2}:${keyfile}"
    break
   fi
   count=$(( $count + 1 ))
   test "$count" -ge 3 && exit 1
  done
 else
  exit 1
 fi
done
unset keydev keydev2 keyfile

example line for /etc/crypttab:
cryptroot /dev/hda2 /dev/disk/by-label/myusbkey:/keys/root.key luks,keyscript=/path/to/your/keyscript


1. Introduction

Kernels more recent than 2.6.12 have dropped support for devfs, which means that initrd-tools can no longer be used to boot into an encrypted root partition. Instead, a similar functionality has been developed for  use with an initramfs-image.

2. A fresh installation


If you plan to perform a completely new installation of Debian onto a machine and to do so using an encrypted root partition, you might want to consider using a version of Debian Installer with partman-crypto (see http://wiki.debian.org/DebianInstaller/PartmanCrypto).

The installation will then take care of all the details and perform the necessary configuration for you, meaning that you should not have to read the rest of this document to get a machine with an encrypted root filesystem up and running.

However, if you are not planning to perform a new installation from scratch,the following information might be useful to you.

3. Requirements


In order to boot from an encrypted root filesystem, you need an initramfs-image which includes the necessary kernel modules and scripts to setup the root device after the kernel has been initialized, but before the rest of the operating system is booted.

To do so, you need two partitions:
- an unencrypted /boot partition
- an encrypted / partition

In addition, you need to have both initramfs-tools and busybox installed.

NOTE: You should make sure that your swap partition is either encrypted, or that you are using a swap file on an encrypted partition, as crypto keys and other sensitive information might otherwise be written out to the swap partition in unencrypted form.

4. Setup (regular dm-crypt)


First of all, you must edit /etc/crypttab and add a line describing your root device, for example:

  cryptroot /dev/hda2 none cipher=aes-cbc-essiv:sha256,size=256,hash=sha256

This will allow cryptsetup to create /dev/mapper/cryptroot from the encrypted partition /dev/hda2 during boot.

In addition, you must also make sure that the root device is listed in /etc/fstab, for example:

  /dev/mapper/cryptroot / ext3 defaults 0 1

This will allow the initramfs support scripts to know which of the devices in the crypttab that is the root device.

After doing these changes, you should regenerate the initramfs by running "initramfs-update -u", then make sure that your boot loader is configured to feed the initramfs to the kernel when booting. The kernel root argument should also be changed to /dev/mapper/cryptroot.

Now, reboot the machine, and if everything is correctly configured, you should be given a prompt to type in the passphrase for the encrypted root partition before the boot can continue.

NOTE: the initramfs scripts default to using the sha256 hash function while the plain cryptsetup binary defaults to using the ripemd160 hash function. In order to ensure that the crypto setup works in a consistent manner, you should make sure that the hash function is specified in the /etc/crypttab file if you are using regular dm-crypt (with LUKS the hash function to use is stored in the LUKS header).

5. Setup (using LUKS)


If you are using the LUKS feature of cryptsetup, the above setup recipe should still apply, but since most options can be derived from the information stored in the LUKS header on-disk, the line to add to /etc/crypttab should look something like this:

  cryptroot /dev/sda2 none luks

6. Exotic key types


The above examples assume that you use a regular passphrase as the key to the encrypted filesystem. However, if you wish to make use of more complex setups (such as root-key-on-usb-memory), you can create a script which does all the steps necessary to retrieve the key and then prints it to stdout.

Then add a keyscript=/path/to/your/script.sh to the options (fourth column) in the above mentioned /etc/crypttab line, so that it looks something like this:

  cryptroot /dev/sda2 none luks,keyscript=/usr/local/sbin/cryptkey

Next, regenerate your initramfs image. This will copy the script into the initramfs image under the /keyscripts/ directory.

NOTE: there is a limited set of tools available when the script is executing as part of the initramfs bootup, you have to make sure that you do not use any tools which are not available or your script, and therefore boot, will fail.

7. "cryptopts" boot argument


In general, you should use the above approach with a line describing your root partition in /etc/crypttab and /etc/fstab. However, if for some reason you wish to override the settings that are derived from these files and stored in the initramfs image, you can use the "cryptopts" boot argument (this *only* works for the root partition).

The format of cryptopts is:
cryptopts==,=...

Beside the "hash", "size", "cipher" and "lvm" options that correspond to the same options in the fourth field of /etc/crypttab, the options "target",  "source" and "key" are also supported. They correspond to the first, second and third field of /etc/crypttab, respectively. See the crypttab man page for further details.

Several "cryptopts" boot arguments can also be specified in case more than one mapping needs to be setup in the initramfs stage of the boot.

Example boot arguments:
root=/dev/mapper/crypt0 cryptopts=target=crypt0,source=/dev/hda1,cipher=twofish

8. Resume device support


The initramfs scripts will also try to automatically determine the devices, if any, that are used for software suspend (swsusp, suspend2 or uswsusp) and to set them up during the initramfs stage in order to allow suspend and resume in combination with encryption to keep the resume image safe from potential attackers.

If your resume device and your root partition use two different cryptsetup mappings, you might want to use the "decrypt_derived" keyscript as described below.

9. The "decrypt_derived" keyscript


Assume that you have two entries in /etc/crypttab:

cryptroot /dev/hda1 none luks
cryptswap /dev/hda2 none luks

If cryptswap is used as your suspend/resume device, you'd normally need to enter two different passphrases during the boot, but the "decrypt_derived"  script can generate the key for the second mapping using a hash of the key for the first mapping.

In short, you'll need to do something like the following to take advantage of the decrypt_derived script:

1) swapoff -a
2) cryptsetup luksClose cryptswap
3) edit /etc/crypttab and change the cryptswap line to e.g.:
cryptswap /dev/hda2 cryptroot cipher=aes-cbc-essiv:sha256,size=256,hash=sha256,keyscript=/lib/cryptsetup/scripts/decrypt_derived,swap
4) /etc/init.d/cryptdisks start
5) Make sure that /dev/mapper/cryptswap has been created
6) swapon -a
7) (optional) update-initramfs -u

After you've followed the above steps, your swap device should be setup automatically after the root device has been setup during the boot stage.

Note: If you don't use suspend device support, it's better to use completely random keys for your encrypted swap device. See the section '2. Encrypted swap partition(s)' in /usr/share/doc/cryptsetup/README.Debian for information on how to setup this.

10. The "passdev" keyscript


If you have a keyfile on a removable device (e.g. a USB-key), you can use the passdev keyscript. It will wait for the device to appear, mount it read-only, read the key and then unmount the device.

The "key" part of /etc/crypttab will be interpreted as :[:], it is strongly recommended that you use one of the persistent device names from /dev/disk/*, e.g. /dev/disk/by-label/myusbkey.

This is an example of a suitable line in cryptsetup:

cryptroot /dev/hda2 /dev/disk/by-label/myusbkey:/keys/root.key cipher=aes-cbc-essiv:sha256,size=256,hash=plain,keyscript=/lib/cryptsetup/scripts/passdev

The above line would cause the boot to pause until /dev/disk/by-label/myusbkey
appears in the fs, then mount that device and use the file /keys/root.key
on the device as the key (without any hashing) as the key for the fs.

The timeout option has to be in seconds.

If any modules are required in order to mount the filesystem on the removable device, then initramfs-tools needs to be configured to add these modules to the initramfs. This can be done by listing the required modules in /etc/initramfs-tools/modules.

0 comments :

Post a Comment

Thank you for taking the time to comment. Your opinion is important and of value and we appreciate the positive feedback! If you are "Negative Nancy" then please do us, and humanity, a favor, and piss off.

Total Pageviews

Google+ Followers

Pages

Blog Archive

Popular Posts

Recent Comments

Rays Twitter feed

Ads

Web sites come and go and information is lost and therefore some pages are archived. @rayd123. Powered by Blogger.