dm-crypt

You are currently browsing articles tagged dm-crypt.

I blogged earlier detailing my experiences in installation of Fedora Core 10, encrypted internal hard disk drives, and external removable hard disk drives. For some, it’s also necessary to be able to access encrypted removable drives in other Operating Systems, such as Microsoft Windows.

Under Microsoft Windows XP, you will need two pieces of software. A filesystem driver, such as Ext2fsd, and an application capable of opening and closing the LUKS container, such as FreeOTFE. Simply install both pieces of software, and ensure that both are executing. Ext2fsd seems to run at start-up by default, but FreeOTFE does not.

Plug in your LUKS/dm-crypt encrypted USB drive, and open up FreeOTFE. It’s quite tempting to jump straight for the big ‘Mount partition’ button, but instead you will need to go to the File menu, Linux volume, and Mount partition…

Mount Linux Partition Option in FreeOTFE

You will then be prompted to select the partition. Once you do, you’ll receive a prompt for the passphrase, and some additional mounting options. Input your LUKS passphrase for this parition, and change the Mount as option to Removable disk.

Input Passphrase in FreeOTFE

Click OK, and that’s it. The partition should mount correctly. When it comes to unplugging the device, remember to unmount first from FreeOTFE, and then go through the normal hardware disconnection procedure.

I recently attempted an upgrade from Fedora Core 9 to Core 10. It wasn’t so successful, reboot to a screen filling up with ‘GRUB’, re-write the MBR, reboot to a FC10 installation which can’t update libpango… So, instead of actually attempting to resolve that issue, I just opted to install Fedora Core 10 from scratch. The other deciding factor was that I wanted to move to an encrypted filesystem, and I’ve yet to find anyway to convert an existing un-encrypted filesystem.

Why an encrypted filesystem? — Primarily, just in case my workstation is ever stolen or the disks ever go walkabouts or just as additional protection for when I do finally dispose of my hard disk drives, as I don’t have access to degaussing and shredding equipment. As with all controls, filesystem encryption is not a panacea, and it’s not an excuse to slip in to poor habits or a false sense of security. It can be circumvented in the right circumstances, particularly if the machine is powered on (via coldboot attacks), or memory has been written to disk (such as swap, or hibernation data)… Although this attack does have potential mitigation techniques, it’s a topic for another day.

Why LUKS?The Linux Unified Key System provides a standard way of storing and retrieving keys in the partition header. The encryption scheme of the partition itself is not important to LUKS, LUKS just provides portability of the keys independently of the partition encryption package, like dm-crypt. The upshot is the user gets more choice.

With a fresh installation of Fedore Core 10, it’s easy to encrypt partitions, just one checkbox away. However, there’s little point in encrypting system partitions if one is performing backups to an external hard disk drive, as I do. So we must prepare any external media to also contain encrypted partitions. For example, my external USB drive (Seagate eSATA 750GB) is designated /dev/sdb, the first partition is — of course — /dev/sdb1. First of all, in to order to hinder cryptoanalytical attacks it’s advisable to fill the disk with random data. There are two key ways of performing this:

The first is to check for bad blocks, and fill with random data at the same time. This utilises libc’s random function, and so is not a cryptographic grade source of random numbers, but it’s faster:

# badblocks -c 10240 -s -w -t random -v /dev/sdb
Checking for bad blocks in read-write mode
From block 0 to 732574583
done
Reading and comparing: done
Pass completed, 0 bad blocks found.

The more secure method, in that the random numbers have better entropy, is: “dd if=/dev/urandom of=/dev/sdb” However, using /dev/urandom is computationally slow as the Secure Hashing Algorithm (SHA-1) is used in the process. So be prepared to wait a long time (hours) if you choose this method, especially on a large drive. Then create a partition on the disk, using fdisk. The process is self-explanatory, and the man page is a huge help.

# fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xf690dcb5.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

The number of cylinders for this disk is set to 91201.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-91201, default 1):
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-91201, default 91201):
Using default value 91201

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Once that is done, then we can establish the keys for the partition, and map a friendly name to the partition:

# cryptsetup --verbose --verify-passphrase luksFormat /dev/sdb1

WARNING!
========
This will overwrite data on /dev/sdb1 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command successful.

Then you’ll need to unlock the container, before you can create a logical filesystem:

# cryptsetup luksOpen /dev/sdb1 disk
Enter LUKS passphrase for /dev/sdb1:
key slot 0 unlocked.
Command successful.

And then create a filesystem on the partition:

# mkfs.ext3 -j /dev/mapper/disk
mke2fs 1.41.3 (12-Oct-2008)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
45793280 inodes, 183143000 blocks
9157150 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
5590 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 21 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

The filesystem is now accessible, but only to root. In order to open it up to other users (or just yourself) then you’ll need to ‘chown’ the root of the partition filespace. Replace username and groupname with your preferred values:

# chown username:groupname /media/disk/

Now unmount the partition, and close the LUKS container:

# umount /media/disk
# cryptsetup luksClose disk

Congratulations! Now when you connect the drive as normal, you will receive a graphic prompt in Gnome to input the passphrase in order to mount the partition. Over the coming week I intend to also investigate connecting my new LUKS enabled USB drive to a Windows XP machine, and determining if Fedora Core 10 encrypts the swap partition or not…