Sunday, June 13, 2010

Recovering an encrypted hard disk and creating encrypted partitions

I recently wrote about how to make a secure connection to a remote machine. Now I'll make a few comments on how to create and use an encrypted partition, including DVDs. I apologize for skipping comments and technical details, these are just personal notes in case I must repeat the procedure in the future. I started to think about this when my not-so-old laptop broke, and I had to recover my file system, which was automagically set up by the Debian installation using the LVM+LUKS encryption. That is, what I was using as partitions were in fact "logical volumes" whose physical volume was an encrypted partition of the hard disk.

Creating an encrypted partition

First, a simpler version of the problem, which is to create an encrypted partition from a removable disk using cryptsetup with LUKS extensions. There is nothing special about being a removable disk, the procedure is exactly the same for a local disk. If we assume that the disk /dev/sdc has a partition /dev/sdc1, we can encrypt it by:
[thisPC:~] cryptsetup luksFormat /dev/sdc1
WARNING!
========
This will overwrite data on /dev/sdc1 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
You can change the cipher algorithm with e.g. the parameters "-c aes -s 256 -h sha256". I haven't mentioned but the partition should be initialized with garbage data using the command dd. If the system complains, try loading some modules:
[thisPC:~] apt-get install loop-aes-utils cryptsetup
[thisPC:~]
modprobe loop
[thisPC:~]
modprobe aes
[thisPC:~]
modprobe cryptoloop
[thisPC:~]
modprobe dm-crypt
(those with "loop" in the name are actually for creating a loopback partition, see below). This partition is still unusable, we must map it to a accessible device by decrypting it:
[thisPC:~] cryptsetup luksOpen /dev/sdc1 backup
Enter passphrase for /dev/sdc1:
Key slot 0 unlocked.
[thisPC:~]
dmsetup ls
backup  (254, 5)
thisPC-swap_1  (254, 2)
thisPC-usr     (254, 3)
sda2_crypt     (254, 0)
thisPC-home    (254, 4)
thisPC-root    (254, 1)
The first command "opens" a device called "backup", accessible through /dev/mapper/backup. The name "backup" is arbitrary, and could be any name distinct from the existing mapped devices. The second command shows us the list of these devices - we can see that besides the newly-created "backup" I have other "logical" partitions set up by LVM. The device "backup" can now be formatted as an ext3 partition:
[thisPC:~] mkfs.ext3 /dev/mapper/backup -L CryptBackupDisk
mke2fs 1.41.12 (17-May-2010)
Filesystem label=CryptBackupDisk
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
19537920 inodes, 78141903 blocks
3907095 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
2385 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

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

This filesystem will be automatically checked every 37 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
The partition is now ready to be used:
[thisPC:~] mount /dev/mapper/backup /mnt
...
[thisPC:~]
umount /mnt
[thisPC:~]
cryptsetup luksClose /dev/mapper/backup
Since the action "luksClose" will remove the device "backup", you must call the cryptsetup command "luksOpen" (and type the passphrase) again if you want to mount the partition once more. You must repeat the procedure every time you reconnect the removable disk or reboot the machine. One advantage of the LUKS extensions (as compared with the traditional "cryptsetup -c aes -y create backup /dev/sdc1") is that most environments can recognize that /dev/hdc1 is a LUKS encrypted partition and prompt the user for the passphrase when automatically mounting the removable devices.

Super-user privileges

So far I assumed root privileges, and for completeness I'll write below the configurations that should allow me to mount the partition as a regular user:
[thisPC:~] md /media/CryptBackupDisk
[thisPC:~]
sudo chmod g+s /media/CryptBackupDisk
[thisPC:~]
chown leo:leo /media/CryptBackupDisk
[thisPC:~]
cat /etc/crypttab
 sda2_crypt /dev/sda2 none luks
 backup     /dev/sdc1 none luks
[thisPC:~]
cat /etc/fstab
# /etc/fstab: static file system information
#              
proc                    /proc   proc  defaults          0    0
/dev/mapper/thisPC-root /       ext3  errors=remount-ro 0    1
# ... (other entries)
/dev/mapper/backup /media/CryptBackupDisk/ ext3 user,noauto 0 0

By creating a directory with the same name as the partition label ("CryptBackupDisk"), I should control the mounting process, but it is simply not working - it creates another directory called /media/CryptBackupDisk_ (notice the underscore), and with root permissions only. For now I removed the directory (since it will be dynamically created) and created a directory inside the encrypted partition (after being properly mounted) to which I have access as a regular user. There is another option using cryptomount but I haven't tried it with LUKS. It seems an easy alternative to the whole process described above, since you can create the encrypted partition from scratch using it. For setting up an already created encrypted partition it was not so easy (but again, I haven't tried with a LUKS partition).

Files and DVDs

The procedure above works not only with partitions, but with files as well. The trick is to transform the file (like an ISO image) into a filesystem, using the loopback device (more information here). So a 1Gb partition can be created through the file /home/leo/fake.img:

[thisPC:/home/leo] dd if=/dev/zero of=/home/leo/fake.img \
      bs=1M count=1024
A safer but slower alternative to /dev/zero is /dev/random. This file can thus be mounted as a partition, like /dev/sdc1 of the previous example:

[thisPC:/home/leo] losetup /dev/loop0 /home/leo/fake.img
...
[thisPC:/home/leo]
losetup -d /dev/loop0
That is, you can encrypt the device with "cryptsetup luksFormat /dev/loop0", etc. Don't forget that "losetup" should be the first and last recipes ("-d" for deleting the device), before "luksOpen" and after "luksClose", respectively. As a last digression, here is how to create an encrypted data DVD (with my precious "articles" directory as an example):

[thisPC:/home/leo] sudo apt-get install aespipe mkisofs \
      loop-aes-utils
; sudo modprobe aes; sudo modprobe cryptoloop
[thisPC:/home/leo] mkisofs -U -R -J -r /home/leo/articles | \
      aespipe -e aes256 > backup.iso
#encrypted backup.iso image

[thisPC:/home/leo] sudo mount -t iso9660 backup.iso /mnt/iso \
      -o loop=/dev/loop0,encryption=aes256
#confirm that image is OK
After burning the backup.iso image to a DVD, you can mount and access it with

[thisPC:/home/leo] sudo mount -t iso9660 /dev/cdrom /mnt/iso \
      -o loop=/dev/loop0,encryption=aes256
Recover an encrypted root partition

Now, my original problem. Assuming that I have a hard disk where even the root directory was part of an LVM which was encrypted inside partition /dev/sdc2, we decrypt it as before (obviously, you should know the passphrase!):

[thisPC:/home/leo] cryptsetup luksOpen /dev/sdc2 BrokenPCPartition
[thisPC:/home/leo] dmsetup ls
thisPC-swap_1     (254, 2)
thisPC-usr        (254, 3)
sda2_crypt        (254, 0)
thisPC-home       (254, 4)
BrokenPCPartition (254, 5)
thisPC-root       (254, 1)

But now BrokenPCPartition is not a regular device, it is the part of an LVM. We can scan all possible volume groups (LVM lingo...) with the command:

[thisPC:/home/leo] vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "brokenPC" using metadata type lvm2
  Found volume group "thisPC" using metadata type lvm2

The group "thisPC" is from my working machine, and the newly-recognized "brokenPC" is the one found through /dev/mapper/BrokenPCPartition (of course the real name was not "brokenPC" :). Now we make this volume group available, and scan all possible logical volumes. IOW, we will activate the logical volumes from this group and list them:

[thisPC:/home/leo] vgchange -a y brokenPC
   3 logical volume(s) in volume group "brokenPC" now active
[thisPC:/home/leo] lvscan
  ACTIVE            '/dev/brokenPC/swap_1' [2.50 GiB] inherit
  ACTIVE            '/dev/brokenPC/root' [59.60 GiB] inherit
  ACTIVE            '/dev/brokenPC/home' [235.74 GiB] inherit
  ACTIVE            '/dev/thisPC/root' [6.52 GiB] inherit
  ACTIVE            '/dev/thisPC/swap_1' [7.92 GiB] inherit
  ACTIVE            '/dev/thisPC/usr' [111.76 GiB] inherit
  ACTIVE            '/dev/thisPC/home' [469.73 GiB] inherit

Now we have, besides the volumes from thisPC, the "recovered" volumes from brokenPC that can be regularly mounted and played with:

[thisPC:/home/leo] mount /dev/brokenPC/home /mnt/
[thisPC:/home/leo] ls /mnt/
leo/  lost+found/
[thisPC:/home/leo] umount /mnt/
[thisPC:/home/leo] vgchange -a n brokenPC
  0 logical volume(s) in volume group "brokenPC" now active
[thisPC:/home/leo]
cryptsetup luksClose /dev/mapper/BrokenPCPartition
 Notice that the volumes names (like /dev/brokenPC/home) are just links to the device mapper (like /dev/mapper/brokenPC-home).



1 comment:

  1. I haven't checked if everything works, but I've found that to define a specific mount point, we must specify the disks on /etc/fstab and /etc/crypttab (the disk is the same but the UUIDs are distinct). To find the disk UUID, we run the command "blkid": the device with TYPE="crypto_LUKS" is the one that we should define on /etc/crypttab, and (after decrytping with Luks) "blkid" will give us another UUID for the TYPE="ext3", which should be added to /etc/fstab.

    I'm still confused since the point of defining /etc/crypttab is exactly to create a /dev/mapper/backup (in which case the correspondent UUID line on /etc/fstab would not be needed). But /etc/crypttab is not working (maybe it needs a reboot?)...

    ReplyDelete

Before writing, please read carefully my policy for comments. Some comments may be deleted.

Please do not include links to commercial or unrelated sites in your comment or signature, or I'll flag it as SPAM.

LinkWithin

Related Posts with Thumbnails