FS#5374 - cryptsetup: External key file for encrypted root
Attached to Project:
Arch Linux
Opened by Alex Merry (pippin) - Saturday, 09 September 2006, 00:43 GMT
Last edited by Tobias Powalowski (tpowa) - Saturday, 09 September 2006, 13:44 GMT
Opened by Alex Merry (pippin) - Saturday, 09 September 2006, 00:43 GMT
Last edited by Tobias Powalowski (tpowa) - Saturday, 09 September 2006, 13:44 GMT
|
Details
Wasn't sure where this should go, so it's here:
I wanted the initcpio encrypted root hook to allow for a key to be stored on an external device. This, for example, means you can have the key on an external usb drive and the computer will boot (without prompting for a password) providing the drive is in the machine. So I hacked the hook included with cryptsetup to allow this (using two command line options: cryptokeydev and cryptokeyfile). If you want to add this (or something similar), that would be great. |
This task depends upon
Closed by Thomas Bächler (brain0)
Sunday, 17 December 2006, 13:29 GMT
Reason for closing: Implemented
Sunday, 17 December 2006, 13:29 GMT
Reason for closing: Implemented
Some documentation would still need updating: I had to include vfat and nls_cp473 in the MODULES parameter of mkinitcpio.conf and USB in HOOKS to get my pen drive to work. But I'm using the script without any problems at the moment.
It now uses crypto, rather than cryptokeydev and cryptokeyfile, because of the issues with cleaning the kernel command line (replacing . and - with _ - see /lib/initcpio/init). The format is crypto=keydev:keydevfstype:keyfile, where keyfile is relative to the root of the keydev filesystem.
So for me, this is: crypto=/dev/sda1:vfat:keys/root.key
encrypt_install (1 KiB)
Don't use crypto=, we need that for legacy cryptsetup, it would be better to introduce another option, like cryptkey=dev:fstye:file. I see another problem here: if you are using scsi or sata disks, there is a risk that the usb stick ends up being sda, while the disk will be sdb, which you really don't want (I don't know how to work around that yet, but we'll see).
Otherwise the idea is good and I will look into it, so that we can integrate it without breaking existing systems. Another idea would be saving the key in the area between the partition table and the first partition on the stick (which is unused), specifying an offset. Or storing the key on a floppy or a CD.
Finding the usb stick is the smallest problem here, it can be uniquely identified and symlinked easily. Making sure that sda is what the user assumes to be sda will prove more difficult.
Anyway, I am definitely going to add this feature when I have time again to work on early-userspace (which will be 2 days from now). I will look at your input of course. I'll report back here once I have done some testing and the feature is ready for inclusion.
Update to newest cryptsetup package from testing (if you don't want to add testing to the repo list, just use this link: ftp://ftp.archlinux.org/testing/os/i686/cryptsetup-1.0.4-1.pkg.tar.gz). Keep a copy of your old initramfs image (e.g. kernel26.img). Generate a new one with the new cryptsetup package.
It works like this (for both LUKS and non-LUKS): you add a cryptkey kernel command line parameter, here are some examples:
cryptkey=/dev/cruzer1:vfat:/keyfile
You also need the vfat and nls_437 modules in MODULES and the usb (or the right host controller and usb-storage module) hook, as well as a FILES="/etc/udev/rules.d/01-usbstick.rules". The latter has a rule to create a /dev/cruzer and /dev/cruzer1 symlink for my usb drive. You may as well use the sda/sdb name, but I like this better, as it identifies the usb drive by its serial number (KERNEL=="sd*", ATTRS{serial}=="someserial", SYMLINK+="cruzer%n"). The generic format is cryptkey=BLOCKDEVICE:FILESYSTEM:FILENAME, which mounts BLOCKDEVICE as FILESYSTEM and looks for FILENAME.
You could also try this: add "floppy" to the modules and write a line like cryptkey=/dev/fd0:vfat:/keyfile
cryptkey=/dev/cruzer:7680:512
cryptkey=/dev/fd0:0:1024
This is more tricky, but I think it's awesome. Again, you need usb respectively floppy drivers, but no filesystem modules. The format cryptkey=BLOCKDEVICE:OFFSET:SIZE uses dd to get the keyfile from BLOCKDEVICE, reading SIZE bytes starting from OFFSET bytes. In the first example, I wrote a keyfile in the space between the partition table and the first partition on my usb drive (again, the name is generated by a udev rule). In the second example, I wrote my keyfile on a floppy disk in the first 1024 bytes.
Please test what you like and tell me with which parameter you successfully used it.