Passphrase protected keyfile usbs
 

Hi all,

I've always wanted to unlock my pc with a usb stick AND a passphrase. Currently slackware only allows one or the other. I've made a modification to the initrd.gz init script which allows me to use a keyfile on a luks-encrypted usb stick to unlock filesystems... basically instead of just mounting the usb stick, it tries to unlock it first if it's a luks volume.

It works the same as before, but now you can also specify a filesystem to the mkinitrd -K option too:

mkinitrd ... -K /dev/sdb3:/keyfile ...
mkinitrd ... -K /dev/sdb3:ext2:/keyfile ...

If you don't specify a filesystem it uses the existing auto-detection. But that never worked for me, it tried to mount my ext2 as a vfat (which is why I made the fs mod).

It would still need a mod to mkinitrd to not include vfat if the user specified an fs, though. I thought with the beta out I'd better make it public if I wanted any chance of it being in the release :P

Hello,

Apart for the thrill of it, is there any practical reason why someone would want to use this method?

Just curious.

Additional security :) "They" talk about something you know, something you are, and something you have as the three types of auth tokens. The more of them you use to auth, the more secure it is (theoretically). In practice "something you are" tends to be hard to do securely+cheaply, like fingerprints are easily forged, even retina scans are hard to do well. In this case, the something you know is the passphrase and the something you have is the usb stick.

Practically, it helps because if you only have the encrypted disk, it is hard to break because the passphrase is long and strong- i.e. a keyfile. But that's the same as using JUST a usb stick. If someone then manages to get both the usb and the disk, say if you're away, then your pc is still safe (unlike using just the usb stick) because they need the passphrase too. Or, say, if I accidentally leave it in my computer. That may or may not be a thing that happens ;)

Thank you for explanation.

Good to know that ;)

hutyerah,
Thank you for pushing the envelope. I have yet even to read your patch, but this
sort of mechanism should have been trivial to implement for the end user long ago (IMHO).

I thought this was what pam_usb was for? Though I can't say I've tried it myself since I don't have a use for it at present.

Thanks STDOUBT. I agree, that's why I posted this, so hopefully it IS trivial in the next Slackware ;)

273, I guess it's like pam_usb. But you can work around pam_usb (or any non-encryption authentication) when you have physical access to the machine, by booting off another disk and messing with the hard drive. This is encryption so you can't do that. Also, Slackware does not use PAM :)

Am I wrong to bump?

Per the LQ Rules, please do not bump your own thread. Because the LQ membership is global, people in other time zones may not have seen this post yet, and thus it may take some time before a response is received.
http://www.linuxquestions.org/rules.php

good idea, need to implement more security features, Slackware are named for focusing on robust, simplicity, and security. I wish the standard installation with LUKS option.

This is an interesting idea, from a security standpoint. But if you are ready to insert a USB key at each boot, why not go one step further?

Why not include the kernel and the initrd on the USB stick and boot from it? The keyfile used to unlock the main slackware partition on the hard disk could then be stored _within_ the initrd.

Benefits:

. your setup is more secure: no more risk that viruses compromise your kernel or initrd when you dual-boot with Windows, or when you try a nice (but untrusted) distro on a live CD...

. you protect your trusted slackware partition against so-called "evil maid" attacks (anyone tampering with your PC when you are away)

. you can remove the USB stick and store it safely as soon as the kernel and initrd are loaded (as soon as you start seeing all those kernel messages on the screen). No need to wait for USB drivers to initialize (it may take several seconds). This makes a noticeable difference in usability.

I have been using this approach for a while, and I'd also be interested in having feed-back, comments and suggestions

Phil

philanc,

I tried for quite some time to figure out how to do what you're doing.
I was approaching the problem by trying to have the entirety of /boot
on a USB stick. Couldn't get it to work.

Do you have a written tutorial or at least a series of commands with
explanations that you could share?

I don't have any written tutorial or detailed list of commands, but I can roughly explain the steps.

1. I assume that you already have a Slackware installation with the root filesystem in an encrypted partition (using cryptsetup/LUKS). If you don't, this is certainly the most delicate part. Fortunately we have a great guide written by AlienBOB on how to implement this. Look for:
<your-slackware-mirror>/slackware-current/README_CRYPT.TXT
and start with this

2. So now we have a bootable system, with all the root filesystem in an encrypted partition and a boot manager (maybe lilo) in a (usually small) boot partition. For the sake of this dicussion, assume the encrypted root filesystem is in sda8, and the boot partition is sda1.

In sda1, we have the kernel and the initrd used to boot. Let's call them generic-smp and initrd.gz respectively. If I remember correctly, there should be no need to change or rebuild initrd.gz.

3. We can now prepare a USB stick to boot from. Make sure there is nothing valuable on the stick (or make sure you have a backup!) Insert the stick in your PC. To keep it simple, let's assume there is only one partition with a FAT filesystem on it and that the USB device is /dev/sdb and the partition is /dev/sdb1. Mount it somewhere and copy generic-smp and initrd.gz to the USB stick root. create a 'syslinux.cfg' text file with the following:
(more details with 'man syslinux', and many tutorials and examples on the web to get a more user-friendly boot menu!)

Now setup the USB stick master boot record. Unmount the stick. (Before performing the steps below, make _sure_ that the USB stick is '/dev/sdb'!!). As root, do:
Looking at lilo.conf, there may be additional parameters for the kernel cmdline. If yes, add them to 'append' line in syslinux.cfg. I don't use lilo and don't have it handy so I cannot check it.

4. Now, if your BIOS is setup correctly to allow booting from a USB disk, you should be able to boot from the USB stick into your encrypted partition.

5. Let's add a keyfile for the encrypted partition. The easiest solution is to store it as another file in the USB stick. Please refer to the README_CRYPT.TXT document, section 'Additional passphrases, keyfiles' which explain how to do this.

To embed the keyfile within the initrd is a bit more complex. You must expand the initrd (this is a compressed cpio archive), add the keyfile, modify the cryptsetup invocation to use the keyfile, and recompress the initrd tree. I may add more details on this in a further post if there is some interest.

HTH

Phil

Many thanks, philanc.
I hope I get some time soon to try this out!

philanc, I like your style and would like to subscribe to your newsletter.

But I'm confused... if I put the keyfile in the initrd, then I can't use a passphrase as well, right? I guess if I did this I'd effectively have my regular slackware boot partition just on the usb stick as well as my encrypted keyfile partition.

A) An option is to store in the initrd an encrypted keyfile. At boot time, the encrypted keyfile should be decrypted before being used with cryptsetup.

Of course it implies that you have also added a (hopefully small!) file encryption utility program to the initrd, with its dependencies if any.

An reasonably sane and well-kown example could be bcrypt (you will find it at SourceForge). The only dependency that may not be in the regular initrd is zlib which you should also add.


B) Another, simpler option is to use for the keyfile the concatenation of a password and a file stored within the initrd (let's call it 'key.part')

The complete content of the keyfile would be:
The keyfile can be built on the fly, just before calling cryptsetup:
This is obviously a rough skeleton. To make it more practical, you would put all this in a loop to make sure that if you make a typo entering the password, you can try again!
HTH

Phil

To me that defeats the purpose of having the password though- i.e. if the usb key falls into the wrong hands, the password can still be read from it. Better to use an encrypted keyfile. Thanks though :)

No, because the password is _never_ stored in the USB key.

When the PC boot, the kernel and the initrd are loaded in memory by the boot loader. The initrd, which is a compressed cpio archive, is expanded in RAM into a small file system (tmpfs). So all the operations I described above such as reading the password and building the keyfile, take place in RAM. The initrd.gz file is not modified during the boot. Nothing is written into the USB stick.

So if your USB stick is lost or stolen at any moment, it still contains only a part of the keyfile (the 'key.part' file), and the complete keyfile cannot be reconstructed without the password.

Hope it clarifies things!

Phil

Gotcha. Not bad :D

Interesting discussion here. One note about key files. Make sure you have copies elsewhere. If something was to happen to your stick, you would be locked out forever if you don't have a copy of the key file tucked away. In fact it best to keep more that one copy of your key file tucked away. I speak from experience on this.

You are definitely right here, and I should have mentioned it earlier.

What I would do is to first create (cryptsetup luksFormat) the encrypted partition with a long, robust password.

Then I add with luksAddKey a keyfile built as described above, by concatenating a file to be stored in the initrd and a "day-to-day" password.

At this stage, I could unlock the encrypted partition either with the long password, or with my specially crafted initrd and the day-to-day password.

Then I can decide if I prefer to remove the long password (luksRemoveKey) and carefully backup the initrd, or just keep it. As I don't use it, the long password is not exposed, and it leaves an option to easily unlock the encrypted partition, should my precious initrd fail :)

Yeah, I just dd the first usb onto a few extra ones and put them in secure places. Like, a safe. Haha.