Unlocking LUKS with USB key - method - seeking help to improve

[gaztronics]

After scouring the web and reading tonnes on un-connected posts, I managed, with a lot of trial and error, to work-up a method of unlocking a LUKS partition with a USB Key on boot. I outline the method below and welcome any suggestions on how to improve it. The method is tested on Fedora 12 and 13 on a Dell PowerEdge T105 server with 2x 2TB discs in RAID 1 and a cheap laptop with a single 250GB S-ATA hard drive. USB sticks used are a Lacie iamaKey and a Crucial Gizmo Jr.


Here is my method to date:

Part 1 - Create key file.

1.1 Fill a USB memory stick with random data:

dd if=/dev/urandom of=/dev/sdb bs=1

This assumes your memory stick is /dev/sdb.

Tip: A laptop with lots of devices will have a greater entropy pool than a server.

CAUTION: The 'dd' command will happily wipe your hard drive if you set the wrong /dev/sd?.

1.2 Extract a "key" from the random data on the USB stick:

dd if=/dev/sdb of=luks-secret.key bs=1 count=4096

The above line will extract 4096 bytes of random data from the USB stick.
(Updated: 16th June 2010)

1.3 Add the key to your LUKS partition:

cryptsetup luksAddKey /dev/sda2 luks-secret.key --key-slot 1

The command above adds the newly generated key to slot 1 (assuming slot 0 contains your LUKS passphrase) of your LUKS partition.
It is assumed your encrypted partition is on /dev/sda2.

You will be prompted for your usual LUKS passphrase before the key is added.

You can check the key has been added to slot 1 with the following command:

cryptsetup luksDump /dev/sda2

1.4 Delete the key from your file system:

shred --remove --zero luks-secret.key


Part 2 - Create a udev rule.

Create a udev rule that will detect the USB stick and make it available as /dev/usbkey. The rule can be created "device specific" so inserting another USB stick will not create /dev/usbkey.

2.1 udev rule:

To create the rule, we need to gather some information on the USB stick. Do this with the following command:

udevadm info -a -p $(udevadm info -q path -n /dev/sdb)

I recommend looking for SUBSYSTEMS=="usb" and ATTR{manufacturer}, ATTR{product} and ATTR{serial}. With this information, you can create a rule as follows:

In /etc/udev.d/rules.d create a file called 10-usbkey.rules
(Updated: 16th June 2010)

An example rule is (this is all on one line):

SUBSYSTEMS=="usb", DRIVERS=="usb", ATTRS{manufacturer}=="LaCie", ATTRS{product}=="LaCie iamaKey", ATTRS{serial}=="60f2f4441dc104", SYMLINK+="usbkey%n"

Reload udev rules with: udevadm control --reload-rules

The entry SYMLINK+="usbkey%n" ensures the key is available in /dev/usbkey, which is needed by the next part.


Part 3 - Create a shell script to unlock partition:

Create a file in /sbin called 'dd-luks-unlock' with the following contents:

#!/bin/sh
#
# Script to unlock LUKS volume with USB key

# Read in luks and UUID information
#
LUKS="`grep \"${HAL_PROP_VOLUME_UUID#*_uuid_}\" /etc/crypttab`"
DEVICE="`echo $LUKS | awk '{print $2}' | awk -F= '{print $2}'`"
MAPPER="`echo $LUKS | awk '{print $1}'`"

DEV="/dev/disk/by-uuid/$DEVICE"

# Open LUKS volume
#
dd if=/dev/usbkey bs=1 count=4096 | \
cryptsetup luksOpen $DEV $MAPPER --key-file=- --key-slot 1

# Clean up
#
unset DEV DEVICE MAPPER LUKS

# We are done!
#
exit 0

Notes:
--key-file=- means the key-file will be read from stdin (piped from the dd command)
--key-slot 1 opens the slot with our key (slot 0 is passphrase).

Ensure the file has root:root and 700 permissions.
(Updated: 16th June 2010)

Part 4 - modify dracut.

Fedora (12 onwards) uses a system called 'dracut' to create the 'initramfs' that 'plymouth' uses to boot the kernel. Dracut builds the 'initramfs' from modules which can be modified to carry your own customisations.

4.1 Add the dd-luks-unlock script and awk to plymouth:

Modify the 'install' script found in /usr/share/dracut/modules.d/50plymouth and add the following line to the end of the file:

inst /sbin/dd-luks-unlock
inst /bin/awk
inst /bin/gawk

Notes: Without awk, our dynamic read of /etc/crypttab does not work.

4.2 Modify the cryptroot-ask.sh script to check for a USB key:

Modify the 'cryptroot-ask.sh' script found in /usr/share/dracut/modules.d/50plymouth. Add the following after "#!/bin/sh".

if [ -e /dev/usbkey ]; then
ask=0
echo "USB Key detected - unlocking partition..."
/sbin/dd-luks-unlock
fi

If you have a laptop and the USB key is not detected in time, you may need to sleep the script (until a better solution is found):

echo "Sleeping for 10 seconds to wait for devices..."
sleep 10
if [ -e /dev/usbkey ]; then
ask=0
echo "USB Key detected - unlocking partition..."
/sbin/dd-luks-unlock
fi

This causes the script to sleep for 10 seconds to allow the USB key scripts time to unlock the partition. If you are still prompted for the passphrase, the USB subsystem is not detecting the key.
(Updated: 16th June 2010)

4.3 Add udev rule.

Modify the 'install' script found in /usr/share/dracut/modules.d/95udev-rules and add the following line (with the other inst_rules):

inst_rules 10-usbkey.rules

I have placed this before the other inst_rules in the file so I can see my modification. Future versions of dracut may automagically detect udev rules.
(Updated: 16th June 2010)

4.4 Create new initramfs

Use the following command to create a new initramfs:

/usr/libexec/plymouth/plymouth-update-initrd

4.5 Check the new files have been added to initramfs

lsinitrd /boot/initramfs-{kernel version} | grep dd-luks-unlock

and

lsinitrd /boot/initramfs-{kernel version} | grep 10-usbkey
(Updated: 16th June 2010)

and

lsinitrd /boot/initramfs-{kernel version} | grep cryptroot-ask.sh

and

lsinitrd /boot/initramfs-{kernel version} | grep awk

will show if the files have been correctly added to the initramfs.

{kernel-version} should be the running kernel version number.


Part 5 - Reboot

With the key in place, the LUKS volume should automatically unlock. Without the key, the system will still prompt for the passphrase.

[jpollard]

Your steps 1.1 and 1.2 are not that good.

You will exhaust the entropy pool within the first 50-100 bytes, after that
the data is not that random (no entropy, even distribution..) you have a strictly
psudo-random number generator...

Just extract the number of bits you want at the beginning from /dev/random
which will wait for entropy to build up to give you a better random stream.

Oh, and 1.2 doesn't extract 4096 bits, it extracts 4096 bytes at the beginning
of the USB device. (dd ... bs=1 means 1 byte buffer) If you want 4096 bits then
use "count=512".

I have no opinion on the rest...

[gaztronics]

Thanks for the feedback. I had my bits and bytes mixed again! Original post updated.

The idea is the key will be useless to all but the end user (to the non-technical, it's a blank USB stick) and Gnome will not mount it if you leave it plugged in. The secondary idea is to provide un-attended reboots on remote servers where LUKS has been used. The USB stick could be glued to something, like the floor, such that if the server was stolen, the thief would have to crack the normal LUKS passphrase - assuming you did not remove it and just rely on keys.

[jpollard]

1, put an undefined partition format on the device (all nulls should work)
2. put your key in the second block (you don't want a key to randomly look like a
partition...)

You could put a partition and filesystem on there, but make sure the partition is
short (1 block), then put the key in the block.

The only advantage this has is the ability to use it on a laptop as an external
storage as well as key fob.

[BugRocks1]

99-unlock-luks.rules

I think udev overrides anything that have a number bigger then the default one that is 50 something no?

It should be 10-unlock-luks.rules

The current command to query things in udev is:

udevadm info --query=all --name=sdd1

All old documentation says to use udevinfo but that doesn't work.

[gaztronics]

I have changed the udev rule 99-unlock-luks.rules to 10-usbkey.rules to better reflect its role. This is reflected in the updated method on the original post.

I still need to sleep the cryptroot script to allow the USB key method to work on my laptop. The USB key is not ready in time.

[forkbomb]

Any suggestions from anyone reading this on a better method of filling a USB key with random data?

Nobody addressed this, but you'd do it the same way you fill any other device with random data.

dd if=/dev/urandom of=/dev/whatever

Go make a sandwich while the stuff cooks. It'll stop once it's full.

As already mentioned, your command about reading "random" data (1.2) from the USB stick is just reading the first blocks.

Edit: /dev/random is an option, too.
http://linux.die.net/man/4/urandom

[gaztronics]

I did have to leave the 4GB key for quite some time before it was full with urandom bits.

I believe for 1.2, based on other posts I read about using 'dd' on random data, there is scope in reading various chunks of random data from the USB key and using them as keys for other applications, or LUKS containers on other devices. They would only be known to the person who set it up and should be quite difficult for a hacker to guess. At least that's the theory!

[forkbomb]

Personally, I'm just trying to get my head around what you really want here. You want to decrypt "a LUKS partition with a USB Key on boot," but then you speak of gluing a USB stick to the floor (!!!).

Let's just set aside the technical hows for the moment. I'll say it plain: If you're keeping a physical token in close proximity to the server - or, god forbid, actually in the USB port 24/7 - there is no point in implementing a token system, unless it's still a two-factor system (passphrase + key); even if it is a two-factor system, it knocks out one of the factors. If somebody has physical access to your server, and wants to steal it, he's probably game for stealing that USB key that's randomly laying on the ground near the server. When he goes to pick it up, he'll see it's glued to the floor, and probably think it's important.

Any security system that requires tokens requires a token management system. Not only does physical access to the server need to be regulated, but physical token possession does, as well. Keys should not be kept in proximity to the doors they unlock. We can talk about whether or not /dev/urandom generates enough entropy as much as we want, but security by obscurity isn't security. If this encrypted server is for your use only, the key management system may be as easy as putting your USB key in your pocket (and keeping a copy under lock and key somewhere).

As for the technical bits, offloading /boot on a flash drive would work as long as you are aware of the location of your flash drive and any copies at all times. It's easy to duplicate your /boot partition.

As for encrypting and being able to do a remote reboot? Good luck. That would require leaving the flash drive with the keyfile in the server and defeat the purpose.

Ensure the file has root:root and 755 permissions.

Am I missing something? Why would a normal user have any reason at all to read the file? Octal mode 400 is generally appropriate for private keyfiles.

[bodhi.zazen]

You may find this interesting :

http://www.debian-administration.org/articles/579

[gaztronics]

What I want here is to offer a slightly better level of protection to my clients. All Systems Administrators, myself included, work with security by obscurity. We are well aware that the server is only as protected as its passwords (once the building is physically breached), so we don't tell the users the root password! And if the hardware is stolen and someone knows what they are doing, they will currently have access to your data via a rescue disk.

Encrypting the partitions with LUKS will help in protecting the data, but I also need the ability to remotely reboot the servers and have them recover from power failure without intervention; hence the idea of using a USB key.

When I say "glued to the floor", this could easily be a USB key on a 2 metre USB extension cable that disappears up into the wall void. I am working on the theory that the average thief is thick, will simply pull all the cables and make off with the hardware. In this instance, the LUKS security falls back on the passphrase - unless you removed it in favour of just the key (or keys). This is never going to be a 100% bullet-proof system; but it's better than now't!

The permissions on the shell script could be tightened if needed. As it primarily runs from initrd, I am not that fussed. If fact, it probably doesn't need to be in /sbin; I just put it there whilst I was setting up the install scripts in dracut. Most of these files could be referenced (for dracut) from a scripts directory as they are loaded into initrd and are not needed for normal operation, just boot.

[forkbomb]

All Systems Administrators, myself included, work with security by obscurity.

Whatever you mean by "work with." "Security" by obscurity is neither security nor a paradigm upon which to rely. And I might quip that if it's not reliable, it's worse than useless.

Encrypting the partitions with LUKS will help in protecting the data...

Uhh...not if you employ single-factor token authentication with the token in the same room as the encrypted system.

I understand the dilemma, but there's no point in decrypting if the decryption key is right there.

When I say "glued to the floor", this could easily be a USB key on a 2 metre USB extension cable that disappears up into the wall void.

"Disappears?" So you'll still need some intervention from somebody on their end to make it "reappear" to plug the stick back in?

Put it this way. If you need both 1) the ability to reboot at will, and 2) to encrypt customer data, assuming 3) that your customers can't be trusted to manage passwords or physical tokens, you need to have a data farm (or whatever service it is you're providing) in your facility.

Trying to come up with some contraption to automatically plug or unplug a USB stick from afar is not security.

[stevea]

There are a number of aspects here that I really don't think are well thought out.

/Randomness is all about entropy, it's nonsense to use /dev/urandom vs /dev/random for any serious app.

/WhyTF are you overwriting the entire stick when you are just using the first 4kbits ? What is the point ?

/The "sleep 10" stuff implies you need to revise your design to wait on events, not clocks. I haven't looked into the detail but that's not right.

/If your mojo stick is ... "glued to the floor" then why can't anyone stick the usb flash into their laptop/nettop and dd a copy, and also, given physical access, dd off a copy of your encrypted system disk ?

Your solution makes all security dependent on keeping the "key" ((your "key" is just an ugly password)) away from the encrypted fs, but you don't go very far to prevent this.

Int's not very hard to

I disagree with TJ' security by obscurity comments. SbO is not absolute security certainly, but it can reduce your target profile enough to make a major impact on non-persistent attacks. If you move your ssh port to 443 you'll likely never see another script kiddie attack. If you use single packet authentication you reduce the time when network attacks are viable to a few seconds per connect. SoB is a bit like sticking your Rolex in you pocket while walking past the muggers convention. It doesn't in any way prevent an effective attack but it reduces the probability of attack enough to be very effective.

[forkbomb]

I'm not saying that security by obscurity doesn't reduce attack profile. On the contrary, it most certainly does by virtue of the fact that botnets and skiddies rarely know how to adapt to obscurity. A skiddie who doesn't know how to port scan is out of luck if SSH is moved off of port 22. I've seen it myself. My informal observation of taking SSH off of port 22 on my home server was at least a 90% decline in attempted brute forces.

Thing is, beyond that, there has to come a time where we have to admit that security by obscurity is not something to bet the farm on. And once you get to that point, what is security by obscurity? Just a footnote or parenthetic mention? At best, it could be part of defense in depth, but obscurity is not something to stake a reputation on.

As for the "glue the stick to the floor" method, I wouldn't bet on most miscreants being "dense." If somebody's even gained unfettered and unapproved access to the server racks, something's already gone awry in terms of physical access security procedure, and the home team has already lost an important battle. Makes no sense further assuming that the burglar won't look for the key under the mat.


Anywho, it's probably not necessarily worth breaking open the old "SbO" chestnut here. Suffice it to say I'm on board with Kerckhoffs. Assume the attackers know security principals as well as (or better than) you do. (I mean, heck - everybody knows how SSH works from an algorithmic standpoint, and the OpenSSH daemon's code is out there for all eyes to see. Yet, it's tough if not impossible to pop if it's implemented with, say, two-factor authentication, long keys, and proper key management, even sitting on standard ports - assuming the keys aren't compromised.)

[dosboss]

Ahh, how I hate to dig up old threads, but this seems to be the only recorded attempt I can find on the web to make a USB key that is read on boot to decrypt a LUKS root partition. And it happens to be a Fedora user, so double good for me. I do have an issue with it though - or I wouldn't be posting, now would I?

Under a new install of F13 from the 'everything' DVD, I have encrypted the root partition during install with the standard password method. Using the instructions from the OP here, I tried the procedure on my machine. Now I am no slouch in this area, having used various Linux distributions since kernel 1.2/1.3 (oooh! bleeding edge!), and before there was a need for a thing such as a 'firewall', and shadow password support was something you compiled and installed the bits manually yourself.

What I cannot get my system to do is read the key from the USB drive. For some reason it does not see the USB drive on boot. I have tested this by putting an 'ls -l /dev/usb*' at the top of the cryptroot-ask.sh script and it shows no 'usbkey' device node. I have tried inserting/replugging the USB drive after the LUKS password prompt comes up, and get a whole bunch of kernel USB bus errors continuously spit out to the console about not being able to attach the drive, until I unplug it and the messages stop. I can of course re-start the cryptroot-ask.sh script by hitting escape, which clears the screen. The USB device works perfectly when booted into the OS, creating the /dev/usbkey udev node without issue, and removing it when the device is pulled out. It seems to me that the USB module in the initrd is not loading some critical component to read USB drives correctly. I thought I had read through the procedure pretty thoroughly, following it and the other recommendations, including the other links referenced... Did I miss something in the comments about a piece that needs to be in the initrd to make USB drives work in the RAM disk environment?