keyfile doesn't work in initramfs

Asked by Nikolaus Rath on 2008-06-07

Binary package hint: cryptsetup

I am using an encrypted root and swap partition. As long as I enter the keys manually ("none" in /etc/crypttab), everything works fine.

Now I wanted to save the key for the swap fs on the root fs as I did for other encrypted filesystems. However, for the swap partition, this results in update-initramfs complaining that:

> cryptsetup: WARNING: target sda7_crypt uses a key file, skipped

Probably as a result of this, I can no longer resume the system, it always performs an ordinary boot.

I see no real reason why this should be a problem. If I enter both keys over the keyboard, I am first asked for the key of the root fs, so it seems to me that there should be no problem in retrieving the key for the swap fs from the just mounted root fs.

Question information

Language:
English Edit question
Status:
Expired
For:
Ubuntu cryptsetup Edit question
Assignee:
No assignee Edit question
Last query:
2008-06-07
Last reply:
2008-07-09

This question was originally filed as bug #238163.

Nikolaus Rath (nikratio) said : #1

[0] nokile:~$ dpkg -s cryptsetup | grep Version
Version: 2:1.0.5-2ubuntu12

Reinhard Tartler (siretart) said : #2

Can you please clarify on your setup?
 - do you use LVM?
 - please attach your /etc/crypttab file

Nikolaus Rath (nikratio) said : #3

I am not using LVM. crypttab is attached.

Nikolaus Rath (nikratio) said : #4
Nikolaus Rath (nikratio) said : #5

Note: sda5_crypt is root, sda6_crypt is /home and sda7_crypt is swap.

Reinhard Tartler (siretart) said : #6

well, wait a minute. After rereading the bug description, I come to the following conclusion:

- you have an encrypted root and want to use a keyfile instead of a password.
- In your /etc/crypttab you put the keyfile in /etc/luks_passwd.
- the initramfs has no possibility to decrypt the key in /etc/luks_passwd because it would need to have that key in advance
- the message is warning exactly because of this issue.

If you want to get the keyfile from a removable device, please about the passdev script from the cryptsetup package in intrepid in /usr/share/doc/cryptsetup/README.initramfs.gz

Nikolaus Rath (nikratio) said : #7

No, you confused the root and swap fs. I want to use a keyfile for the *swap* partition.

Reinhard Tartler (siretart) said : #8

Ah, okay, my bad.

I just tried to reproduce this issue with the cryptsetup package in intrepid but failed to do so. The volume does come up pretty well.

Could you perhaps fetch the source from intrepid, compile the source on your hardy package and retry? there has been a few changes to cryptdisks, which is used by /etc/init.d/cryptdisks.

Oh yes, please attach the output of that init script to this bug. Does it contain useful information what's going wrong?

Nikolaus Rath (nikratio) said : #9

I compiled and installed cryptsetup from intrepid in Hardy. Unfortunately it only leaves my system onbootable, the boot hangs after the "Waiting for root filesystem" message from the initramdisk.

Reinhard Tartler (siretart) said : #10

Hm. in my tests with kvm the system came up as expected. Can you try to
boot without usplash and watch if there are more 'interesting' boot
messages? If you use a serial console you can save the boot messages to
a file and attach that to this bug.

Nikolaus Rath (nikratio) said : #11

Ok, after I recovered my system, the intrepid cryptsetup works partially. Unfortunately I can't really tell what the important change was. I booted from a rescue system, reinstalled the hardy cryptsetup, used the opportunity to change some of my device labels and cleaned up /etc/fstab, /etc/cryptsetup and /etc/initramfs-tools/conf.d/resume.

What happens now is that I can boot my system normally with intrepid cryptsetup using a keyfile for all partitions except /. However, I am unable to resume. If I hibernate the system, then afterwards it starts up normally and only brings up the swap device together with the other partitions later in the boot process instead of right after the root fs in the initramdisk. The hibernation works fine though, when the swap is activated I get a warning that it contains a valid resume signature.

Nikolaus Rath (nikratio) said : #12

I also still get the same warning:

[1] nokile:~$ sudo update-initramfs -k all -c
[sudo] password for nikratio:
update-initramfs: Generating /boot/initrd.img-2.6.24-19-386
cryptsetup: WARNING: target luks_swap uses a key file, skipped
[0] nokile:~$ sudo cryptsetup --version
cryptsetup 1.0.6

so essentially I am now having the same problems with intrepid cryptsetup as I had with hardy cryptsetup.

Reinhard Tartler (siretart) said : #13

Okay, now things become clearer.

As explained before, you cannot expect to use a keyfile for the root file system, because the keyfile would have to be in either at some unencrypted place (/boot or initramfs) which defeats the purpose of using a keyfile. The very same reasons apply to using a keyfile for encrypting swap space from which you want to resume from. Where should the key for unencrypting the device come from?

the only "solution" to this issue is to use the "passdev" mechanism introduced with the cryptsetup in intrepid to fetch the key from some removable media.

Btw, the warning 'cryptsetup: WARNING: target luks_swap uses a key file, skipped' is perfectly valid and intended to make you aware of this issue.

For this reason, I'm converting your bug report to a support ticket, because that's what you're actually requesting. There is nothing wrong in the cryptsetup package in this point and the package is behaving exactly as I would expect it to do.

Launchpad Janitor (janitor) said : #14

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

n0PxN0p (n0pxn0p) said : #15

1. So how comes that "use a keyfile for the root file system" feature used to work fine for me in 12.04 for example?
2. What is that so bad about keeping key files on /boot physically detachable media taking in view the fact that bootloader NEVER gets encrypted and vulnerable for "evil maid" attack (considering this the idea of keeping bootloader and keys altogether is not that bad)?
3. Why /boot can't be removable media?

I didn't like an idea of reviving such things, but i've spent two days on freenode and oftc dealing with similar (as i see it) thing described here on 13.04, that's why i took all my courage and revived the bug report and linked it to this discussion.

P.S. Sorry if i'm doing wrong stuff due to my inability to see things i could probably miss (in advance) and for my english if it sounds frustratung at some point.

Eero Aaltonen (ejn) said : #16

n0PxN0p:
2. Would make sense in my opinion
3. This is potentially difficult. What happens when you try to install updates and /boot is not mounted ?