LinuxQuestions.org - [SOLVED] Unlock LUKS encrypted partition with USB drive

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Unlock LUKS encrypted partition with USB drive (https://www.linuxquestions.org/questions/slackware-14/unlock-luks-encrypted-partition-with-usb-drive-4175451682/)

Unlock LUKS encrypted partition with USB drive

Hi,

I recently installed Slackware64 14.0 on NAS server with full disk encryption (except /boot) and since I want to run it headless, it won't have monitor attached all the time. I'd like to use USB drive with key file so I won't have to type password on every start.

I tried initrd with -K luks_keyfile option but it won't unlock disk and still asks about password.

USB drive is FAT32 formated with label 'NASKEY'

Code:

$ cfdisk /dev/sdb

Name          Flags        Part Type    FS Type              [Label]            Size (MB)

------------------------------------------------------------------------------------------------

                              Pri/Log      Free Space                                  1.05    *

sdb1                          Primary      vfat                [NASKEY]            2011.17    *

My initrd was created with following command (sda1 /boot, sda2 encrypted partition)

Code:

mkinitrd -c -k 3.2.29 -f ext4 -m ext4:<other modules for usb keyboard> -r /dev/linuxvg/slackware-root -C /dev/sda2 -K LABEL=NASKEY:/boot/key.luks

-L -o /boot/initrd.gz

mkinitrd_helper_script.sh suggests adding -u (Include udev in the initrd) option, but it acts the same with or without this options.

Am I missing something?

You first have to create that file on the USB stick, called "/boot/key.luks" and add it to your computer's LUKS key store. The initrd command will not do either of these steps. All it does is cause Slackware to check if there is a USB stick with the configured FAT label, and then locate that file you mentioned on the mkinitrd commandline, and present that file to cryptsetup for unlocking the encrypted volume. But if you did not first add the contents of that file into a LUKS key slot, then cryptsetup will not accept that file as a valid key.
For example, create a file with random content (512 characters), then add the file to the LUKS volume on partition /dev/sdX1 as a new unlock key. The new key will be accepted after you type a valid LUKS unlock passphrase:

Code:

# dd if=/dev/urandom of=/media/NASKEY/boot/key.luks bs=512 count=1

# cryptsetup --key-file /media/NASKEY/boot/key.luks luksAddKey /dev/sdX1

# umount /media/NASKEY

Those commands implied that you inserted that boot stick in the computer and Slackware mounted it automatically at /media/NASKEY .

When you do this, your LUKS volume will have two unlock keys: the original passphrase, and the new key-file. It will not matter which one you use.

Eric

Sorry, I didn't mention it in original post, but I have already created key, added it to LUKS keyslot and save it on boot stick. I know key works because I can unlock encrypted partition with it.

Only difference I see is key size. I created 4096 bytes key and you suggested 512 bytes. Does size make a difference?

I can see at boot that kernel recognize my boot stick, therefore It should unlock encrypted partition.

Size or content of the key file does not make a difference.

Also note the support for FAT filesystems which gets added to the initrd:

Code:

  # Several extra modules are needed to support a vfat formatted USB stick...

  # assuming here we are using a western codepage.

  # This possibly adds doublures, but we clean up the MODULE_LIST further down!

  MODULE_LIST="${MODULE_LIST}:ehci-hcd:uhci-hcd:usb-storage:hid:usbhid:fat:nls_cp437:nls_iso8859-1:msdos:vfat"

Since you are czech, perhaps your FAT filesystem needs another codepage module added, but I doubt that since you are using "normal" western directory- and file names.

What also happens in the initrd is to pause for 5 seconds in order to give the OS time to query the USB stick. Maybe your computer needs more time? Change the "5" to something higher in /boot/initrd-tree/wait-for-root and re-run "mkinitrd", followed by "lilo".

Eric

Well, I finally found out what was wrong. All initrd modules, keys, etc. was correct except one thing. I looked through .bash_history and find this command:

Code:

$ pwd

/root

$ mkinitrd [...] -o boot/initrd.gz

Which created initrd in /root/boot/ and I was using wrong initrd all the time. Correct parameter is

Code:

$ mkinitrd [...] -o /boot/initrd.gz

Now it works as intended. Anyway, thanks for suggestions!