October 21, 2011

Update: Booten vom verschlüsselten USB-Stick

Filed under: Paranoia — Tags: , , — martin @ 9:02 pm

Also, die Sache mit den USB-Sticks von Lok-IT war sicher eine tolle Idee, das Problem ist aber, daß man de-facto nicht von ihnen booten kann funktioniert.

Grub, Kernel und initrd werden zwar geladen. Leider erfolgt innerhalb der initrd aber scheinbar ein Reset des USB-Systems. Ein normaler USB-Stick holpert da irgendwie drüber (das funktioniert mit /boot auf dem Stick problemlos), aber der Lok-IT sperrt sich sicherheitshalber automatisch.

Das ist schade, aber kein Beinbruch. Das letzte Wort wird da auch hoffentlich noch nicht gesprochen sein.

Es trifft zu, daß der USB-Bus beim Hochfahren zurückgesetzt wird und sich der Stick in diesem Moment aus Selbstschutz sperrt. Das ist aber überhaupt kein Problem. Man muß lediglich in /etc/fstab dafür sorgen, daß das System beim Hochfahren nicht versucht /boot zu mounten oder zu checken. Beide Daumen nach oben für meinen unknackbaren Terrorlaptop! 🙂

Und, nein, es wird kein HOWTO dazu geben. Wer dafür ein Kochrezept braucht, sollte besser die Finger davon lassen.

February 14, 2009

Re-Layering LVM encryption

Filed under: Security, UNIX & Linux — Tags: , , — martin @ 11:48 pm

In an earlier article, I had promised live migration of LVM data to encrypted storage. I was able to acquire an external SATA disk for my backup server today, so here we go. 🙂


The backup server is running headless, so I opted to store the key locally for now. Yes, I’m a moron. But hey, at least it’s not on the same medium.

# dd if=/dev/urandom of=/etc/luks.key count=256 ; chmod 600 /etc/luks.key

As long as the disk isn’t the only one, I can’t predict the device name it will come up as. Thus, it is referenced by its udev ID when formatting it with LUKS:

# cryptsetup luksFormat /dev/disk/by-id/scsi-SATA_WD_My_Book_WD-WCAU123-part1 /etc/luks.key

Open the new LUKS device:

# cryptsetup luksOpen -d /etc/luks.key /dev/disk/by-id/scsi-SATA_WD_My_Book_WD-WCAU123-part1 pv_crypt_1

The entry in /etc/crypttab makes the encrypted device come up on boot:


pv_crypt_1 /dev/disk/by-id/scsi-SATA_WD_My_Book_WD-WCAU123-part1 /etc/luks.key luks

Create a new Physical Volume on the crypted device:

# pvcreate /dev/mapper/pv_crypt_1

Now the Volume Group can be extended with the new PV:

# vgextend datavg /dev/mapper/pv_crypt_1

I rebooted at this point, in order to see if everything would come up as expected.

The new PV is now visible:

# pvs
  PV         VG     Fmt  Attr PSize   PFree
  /dev/dm-0  datavg lvm2 a-   931.51G 931.51G
  /dev/sdb1  datavg lvm2 a-   465.76G      0

The next step is to migrate the VG content to the new PV. Migration will take a very long time if the disk is full, so you may want to use a screen session for this.

# pvmove -v  /dev/sdb1

This is a classical LVM operation that may be cancelled at any time and picked up later. In fact, my Promise SATA driver crashed hard in the middle of the operation, and everything went along fine after a kernel upgrade.

When pvmove is done, throw out the original PV from the volume group:

# vgreduce datavg /dev/sdb1

The Volume Group is now on encrypted storage.

January 18, 2009

Managing encrypted logical volumes

Filed under: Security, UNIX & Linux — Tags: , , — martin @ 1:32 pm

Worked on this with G. the other day.

Create the underlying logical volume:
lvcreate -n datalv_crypted -L 1G vg00

Initialize a LUKS crypto device on the logical volume:
cryptsetup luksFormat /dev/vg00/datalv_crypted

If you have lost your mind and want to keep the passphrase in a file (which is what G.’s weirdo client had asked for):
dd if=/dev/urandom of=/etc/i_am_dumb count=256
cryptsetup luksFormat /dev/vg00/datalv_crypted /etc/i_am_dumb

Bring up the crypto device from the encrypted logical volume:
cryptsetup luksOpen /dev/vg00/datalv_crypted data # optionally -d /etc/i_am_dumb

Create a file system on the crypto device, /dev/mapper/data, which has now sprung to life:
mkfs.ext3 /dev/mapper/data

Enter the crypto device in /etc/fstab:
/dev/mapper/data /data ext3 defaults 0 0

Don’t forget to create the mount point:
mkdir /data

Enter the encrypted logical volume in /etc/crypttab. Substitute “none” with /etc/i_am_dumb if you are keeping the passphrase on the system.
data /dev/vg00/datalv_crypted none luks

Reboot. You will be prompted for the passphrase on bootup, unless you’re keeping it in a file. The new file system will be mounted on /data.

The usual process for resizing file systems now has to be extended by an additional step:

lvresize -L +1G /dev/vg00/datalv_crypted
cryptsetup resize /dev/mapper/data
resize2fs /dev/mapper/data

That’s all there is to it. In another installment, I will hopefully write about encrypted physical volumes, allowing live migration of an entire volume group to encrypted storage during full operation. 🙂

With the technical details out of the way, some additional words about keeping the passphrase on-disk:

If you work for someone who wants this, he’s not neccessarily an idiot, but maybe just a bit naive. It is your duty as the expert to explain why keeping the passphrase in-band with the encrypted data is nothing more than just a waste of CPU cycles. Seriously. This, G., means you. 😉

December 4, 2008

Using a USB key for the LUKS passphrase

Filed under: Paranoia, UNIX & Linux — Tags: , , — martin @ 10:43 pm

When I had installed my notebook with Ubuntu 8.04 “Horny Hard-on”, I had opted to put the /home filesystem onto an encrypted partition on /dev/sda4. However, after a few months, entering the passphrase after turning on the computer doesn’t seem to be that attractive anymore. I have therefore decided to try to store the passphrase on a spare USB key.

This is how I migrated my LUKS container to a passphrase stored on USB media.

First, I filled the USB key with random data:
# dd if=/dev/urandom of=/dev/sdc

Then, I siphoned off 256 bytes from the USB key, to be used as the passphrase:
# dd if=/dev/sdc of=/home/martin/foo.key bs=1 count=256

foo.key is required temporarily. You may keep a copy of it stored in a safe place, or you may leave the interactive password in place as a fall-back measure. Which is what I’m doing.

The new passphrase can be added to the LUKS container like this:
# cryptsetup luksAddKey /dev/sda4 /home/martin/foo.key

Cryptsetup asks for “any passphrase”. That is one of the numerous possible passphrases that may be assigned to a LUKS device at once. Such as the interactive passphrase that is already in place.

When the new passphrase has been added, foo.key can be deleted.

Next, I determined the USB id of my USB key:
# ls -l /dev/disk/by-id/ | grep sdc
lrwxrwxrwx 1 root root 9 2008-12-04 21:31 usb-LG_XTICK_AAAAAAAAAAAAAAAAA-0:0 -> ../../sdc

I found that I needed a little helper script that extracts 256 bytes from the USB key and pipes them to stdout:

# Script: /usr/local/sbin/dd-luks-key.sh
if [ -e $1 ]
dd if=$1 bs=1 count=256

And now the change to /etc/crypttab:

# Old entry; ask for password:
#sda4_crypt /dev/disk/by-uuid/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee none luks
# New entry; execute the keyscript with the USB id as the argument:
sda4_crypt /dev/disk/by-uuid/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /dev/disk/by-id/usb-LG_XTICK_AAAAAAAAAAAAAAAAA-0\:0 luks,keyscript=/usr/local/sbin/dd-luks-key.sh

That’s it. I can now reboot with the USB key plugged in and observe how the system automatically mounts the LUKS container. The USB key is not partitioned, so Gnome will not automatically mount it. It can just be pulled anytime after bootup.

If I had chosen to delete the interactive passphrase, which is stored in key slot 0:
# cryptsetup luksDelKey /dev/sda4 0

Be advised that this is no real-deal tough-minded security, but something that will protect the machine only against the type of attackers (e.g. thieves) who are out for your hardware but not for your data. Don’t leave the USB key close to the laptop. Use this responsibly. Thanks!

I’m not conviced that I will stick with this, as it’s far below my usual standard of paranoia. Nevertheless, I have gained a few nice insights into the LUKS system.

Blog at WordPress.com.