cryptsetup and the yubikey…

i recently set up my laptop with a new install of gentoo linux. i’ve been using gentoo for years, but not on my laptop recently.

since encryption was no issue back then i had to get myself up to speed with cryptsetup and initramfs, which you can build yourself in gentoo. there is an option via genkernel to do this automatically, but where is the fun in that?

my basic setup includes two partitions. sda1 is boot, sda2 contains a crypt device, which contains the root partition and the user’s home partition in a lvm container.

this post is about cryptsetup and the method i use to swap the password for the container on every bootup with a cycling challenge response provided by the yubikey. let’s get to it!

the yubikey is a hardware token that looks like a usb stick. it has no moving parts and is very robust. it has a user button which triggers one time passwords. having inserted the yubikey into a usb slot it emulates a keyboard and enters the password. i’ve been keeping it on my bunch of keys for some time now and it has not been damaged. it provides different methods to authenticate a user to a system. i’m not going to discuss every possibility, i’ll just mention two. you can read about the others on their website.

the one time password (OTP) can be used with yubico’s authentication servers. this requires an active internet connection. the yubikey will generate a one time password based on a cycling number, it’s unique id and a secret that is only known by yubico and the key itself. normally this OTP is used in combination with a remembered user password and both credentials have to be valid to login. e.g: there is a yubikey wordpress plugin.

the challenge response is a feature that is available since yubikey version 2.2. those were available since september 2010. it supports HMAC-SHA1 and the yubikey OTP algorithm. for my cryptsetup i used the synchronous (no user interation) HMAC-SHA1 variant.

as the yubikey supports 2 slots where any configuration can be put (challenge response, yubikey OTP, static password, OATH), i used slot 2 for the challenge response option and left slot 1 as is. this left me the option to use the factory preset yubico setup with yubico’s servers if i needed it.

as the yubikey alone is not a safe option (just imagine someone stealing it together with the laptop), i wanted to implement two factor authentication. meaning, a user password has to be provided together with the yubikey in the usb slot to unlock the device. this provides enough security: 256 bit encryption on the device itself, 160 bit on the yubikey and a decently strong user password that is combined with the challenge response of the yubikey. and of course the challenge changes at every boot up.

to change the challenge in a secure way, the new password is written after the crypt device is mounted. the new password is written in a file on the just mounted and encrypted file system. it is set in the luks header and deleted just after.

the init script i came up with can be found on github, feel free to mess with it, fork it and improve it! if you are planning on using the script i highly recommend to backup your luks header with a known password in case something goes wrong.

all in all it seems like a quite secure solution. post to the comments if you want to share what you think.