wiki:Linux/Ubuntu/HardyEncryptedLVM

Version 2 (modified by tj, 9 years ago) (diff)

--

Hardy Encrypted Logical Volume Management

This article shows how to use the Ubuntu Hardy Desktop Live CD to build and install to a secure encrypted Logical system that requires a key-file on an external USB memory stick in order to start. It is designed to secure portable PCs (netbooks, notebooks, laptops, etc.).

The existing organisation and usage of the laptop was preventing an upgrade from Gutsy to Hardy: sda6 (12.8GiB - the Gutsy / partition) was too full, and I had too many customisations I didn't want to lose. Most of the partitions were at or near capacity. I decided to backup all the data to other disks and do a clean install that allowed me to create an optimum configuration that included encryption and LVM.

Existing Layout

In my case the laptop PC was fully utilising the 200GB (186GiB) hard disk:

fdisk -ul /dev/sda

Disk /dev/sda: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders, total 390721968 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0xf7fc3a6e

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048    19531775     9764864   27  Unknown
/dev/sda2   *    19531776    77008895    28738560    7  HPFS/NTFS
/dev/sda3        77008896    81008896     2000000+  82  Linux swap / Solaris
/dev/sda4        81015795   390716864   154850535    5  Extended
/dev/sda5        81015858    81497744      240943+  83  Linux
/dev/sda6        81497808   108406619    13454406   83  Linux
/dev/sda7       108406683   120551759     6072538+  83  Linux
/dev/sda8       120551823   390716864   135082521   83  Linux
  • sda1 9.3GiB Sony Recovery
  • sda2 27.4GiB Windows Vista
  • sda3 1.9GiB Linux Swap
  • sda5 235.3MiB /boot
  • sda6 12.8GiB / (Gutsy - primary OS)
  • sda7 5.8GiB / (Ubuntu+1 testing)
  • sda8 128.8GiB /home

Data Back-Up

I copied a large amount of non-core data directories (Source-code repositories, audio-book libraries, camcorder library, etc.) to an external USB2 160GB drive. It already had a lot of data on it so I then used rsync to copy all of /, /boot, /home, and the Vista partition image to a RAID-5 server over a 100Mbps ethernet link.

Total data moved over ethernet was 30GiB + 10GiB + 27.4GiB and it took about 3.5 hours.

I started the laptop with the Hardy Desktop Live CD, installed the sshfs package from the universe repository, and mounted the network server in the Live CD environment:

sudo su
sed -i 's/^# \(deb .*universe\)/\1/' /etc/apt/sources.list
apt-get update
apt-get install sshfs
mkdir /mnt/remote
sshfs tj@10.254.251.72: /mnt/remote

I mounted the local hard drive partitions into the Live CD environment:

mkdir /mnt/rootfs
mkdir /mnt/home
mount /dev/sda6 /mnt/rootfs
mount /dev/sda5 /mnt/rootfs/boot
mount /dev/sda8 /mnt/home

I kept /home on a separate mount-point so I could rsync the root file-system and home separately. These operations took several hours:

rsync -ae ssh --delete /mnt/home/ tj@10.254.251.72:Backups/home/
rsync -ae ssh --delete /mnt/rootfs/ tj@10.254.251.72:Backups/rootfs/

I copied an image of the Windows Vista partition (27.4GiB) to the network server:

dd if=/dev/sda2 bs=512000 of=/mnt/remote/Backups/sda2-Vista.img

I copied an image of the Sony Recovery partition (10GB) to the external USB2 hard disk:

dd if=/dev/sda1 bs=512000 of=/media/disk/Backups/sda1-SonyRecovery.img

Finally, I made a backup of the master boot record (MBR) sector and a textual log from fdisk:

dd if=/dev/sda bs=512 count=1 of=/mnt/remote/Backups/mbr-sector.bin
fdisk -ul /dev/sda > /mnt/remote/Backups/sda-fdisk.txt

Optimised Layout

I wanted to simplify the Linux organisation, drop the almost 10GB taken up by the Sony Recovery partition, and shuffle the Windows Vista partition closer to the start of the disk. I also needed the LVM flexibility to shrink, grow, remove and create volumes to help with advanced testing.

  • sda1 251.0MiB /boot
  • sda2 27.4GiB Windows Vista
  • sda3 4.0GiB Linux Swap
  • sda4 154.8GiB Linux (encrypted) + LVM VG + / (Hardy), /var, /home, / (Ubuntu+1) and spare

I used cfdisk to create the revised layout (I initially used fdisk to ensure the Windows partition was exactly the same size as previously but cfdisk reported "FATAL ERROR: Bad primary partition 3: Partition ends in the final partial cylinder" so, since cfdisk's reputation is so good, I let it do the work. The result is that the Windows Vista partition is slightly bigger than the NTFS file-system image that was backed up, but Vista's Disk Management tool can expand the NTFS live file-system to ensure the slack space will be used.

fdisk -ul /dev/sda

Disk /dev/sda: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders, total 390721968 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x4abc0f4b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63      498014      248976   83  Linux
/dev/sda2   *      498015    57994649    28748317+   7  HPFS/NTFS
/dev/sda3        57994650    65995019     4000185   82  Linux swap / Solaris
/dev/sda4        65995020   390716864   162360922+  83  Linux

Encryption

First, install the cryptography package:

apt-get install cryptsetup

Load the kernel module:

modprobe dm-crypt

Randomise the disk surface

By ensuring every sector of the disk partition is written with random data, a potential attacker will have great difficulty locating encrypted data that they might want to try to decrypt. If the surface of the disk was written with zeros (using if=/dev/zero) or some other predictable values encrypted data would be easy to identify if the disk were to fall into hostile hands.

This is likely to take a long time - possibly 24 hours or more - even with running one background process for each disk:

dd if=/dev/urandom of=/dev/sda4

Check the progress by sending the USR1 signal to the dd processes:

ps -ef | sed -n 's/[a-z ]*\([0-9]*\).* dd.*/\1/p' | while read PID; do kill -USR1 $PID; done

Choosing a Key-File

The key-file is kept on an external USB memory stick. There are various ways to create and store the key-file. Many guides recommend generating a random key from /dev/random but in my opinion anyone that managed to get access to the memory stick could easily locate the key-file because of its totally random contents, unless many 'fake' keys were also on the memory stick.

My preferred method now is to use a real file. Install the  Hardy Desktop Live image on the USB memory stick so it is bootable on any system. Because the installation has a persistent /home/ I can copy some music and image files onto it and use one of those as the key-file. The reason I choose music and images is that most MP3 and PNG or JPG files are highly compressed and their data can have a high degree of variability, and is hard to predict. An attacker would need to know the name of the key-file to determine which of the thousands of files was the key-file. To do that, they'd need access to the encrypted system itself.

For the purposes of this guide let us assume we're using a self-created music file called theme-song.mp3 (Being self-created no-one else will have the same file - in other words, don't use a commonly shared file).

Put the file on the USB memory stick and then plug it into the new system. Ensure it is mounted. In this example the USB key has two volumes on it (ubuntu & casper-rw) and the persistent files are in the casper-rw volume which usually is auto-mounted at /media/casper-rw (see  Installing Ubuntu on USB pendrive using Linux.

Encrypting the Disk

Now encrypt the large sda4 partition that will eventually use LVM:

cryptsetup --hash sha512 --key-size 256 --cipher aes-cbc-essiv:sha256 \
 luksFormat /dev/sda4 /media/casper-rw/home/tj/Media/theme-song.mp3

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

Are you sure (Type uppercase yes): YES
Command successful

Open the encrypted device, giving it the name sda4encrypted:

cryptsetup --key-file /media/casper-rw/home/tj/Media/theme-song.mp3 luksOpen /dev/sda4 sda4encrypted
key slot 0 unlocked.
Command successful.

There will now be a new device:

ls -1 /dev/mapper
control
sda4encrypted

Attachments