keyfile doesn't work in initramfs

[Nikolaus Rath]

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.

[Nikolaus Rath (nikratio)]

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

[Reinhard Tartler (siretart)]

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

[Nikolaus Rath (nikratio)]

I am not using LVM. crypttab is attached.

[Nikolaus Rath (nikratio)]

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

[Reinhard Tartler (siretart)]

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)]

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

[Reinhard Tartler (siretart)]

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)]

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)]

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)]

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)]

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)]

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.

[Nikolaus Rath (nikratio)]

Reinhard Tartler <email address hidden> writes:
> Okay, now things become clearer.
>
> As explained before, you cannot expect to use a keyfile for the root
> file system,
[...]

But that is not what I want to do. I want to use a keyfile for the
*swap* filesystem.

> Where should the key for unencrypting the device come from?

Well, from the root file system I'd expect.

> 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.

I'm afraid I still don't see why the warning is appropriate. I'd be
glad if you could try to explain again why the swap filesystem cannot
be decrypted using the key from the root filesystem (this can't be
more difficult than using removable media, can it?).

Thanks for your efforts,

   -Nikolaus

--
 <email address hidden> | College Ring 6, 28759 Bremen, Germany
 Class of 2008 - Physics | Jacobs University Bremen

 »My opinions may have changed, but not the fact that I am right.«

[Reinhard Tartler (siretart)]

Nikolaus Rath <email address hidden> writes:

> Reinhard Tartler <email address hidden> writes:
>> Okay, now things become clearer.
>>
>> As explained before, you cannot expect to use a keyfile for the root
>> file system,
> [...]
>
> But that is not what I want to do. I want to use a keyfile for the
> *swap* filesystem.

Yes, I understand that.

>> Where should the key for unencrypting the device come from?
>
> Well, from the root file system I'd expect.

From the 'unencrypted' root filesystem, to be more correct.

> I'm afraid I still don't see why the warning is appropriate. I'd be
> glad if you could try to explain again why the swap filesystem cannot
> be decrypted using the key from the root filesystem (this can't be
> more difficult than using removable media, can it?).

It is not more difficult, but pointless. The key would need to be
unencrypted on the physical hard drive, so an attacker would be able to
directly grab and use it.

If you really want to do that anyway, it should be possible to use the
passdev script that is intended to be used with removable drives with
your root filesystem by entering the UUID of the root filesystem. I
didn't try this myself (because I still think this is rather pointless
security wise), but it should work.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Nikolaus Rath (nikratio)]

Reinhard Tartler <email address hidden> writes:
>>> Where should the key for unencrypting the device come from?
>>
>> Well, from the root file system I'd expect.
>
> From the 'unencrypted' root filesystem, to be more correct.

Why unencrypted? The root fs is encrypted as well, and for the root fs
I am entering the key manually.

Best,

   -Nikolaus

--
 <email address hidden> | College Ring 6, 28759 Bremen, Germany
 Class of 2008 - Physics | Jacobs University Bremen

 »My opinions may have changed, but not the fact that I am right.«

[Reinhard Tartler (siretart)]

Nikolaus Rath <email address hidden> writes:

> Why unencrypted? The root fs is encrypted as well, and for the root fs
> I am entering the key manually.

Ah, I see. Well, this particular use case is not implemented then (and
nowhere documented AFAIS) and tricky to implement. You would need to

 1. first mount the root filesystem
 2. get the key
 3. unlock the swap device,
 4. check if the system could resume.
 4a. if yes, unmount root again and resume.
 4b. if not, continue with regular boot.

I'm not sure if step 4 is possible at all with currently available
means. Feel free to submit a patch for that, though.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[n0PxN0p (n0pxn0p)]

I have a similar issue with the same cryptsetup warning during update-initramfs stage in attempt to achieve key file authorization for root partition during boot process on 13.04.
cryptsetup Version: 2:1.4.3-4ubuntu2
Linux blackrouter 3.8.0-28-generic #41-Ubuntu SMP Fri Jul 26 16:26:01 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

root@blackrouter:~# cat /etc/crypttab
sda1_crypt /dev/sda1 /dev/urandom cipher=aes-xts-plain64,size=256,swap
sda2_crypt UUID=bc4ff5ca-d27a-423b-9ab1-806b64556ace /boot/key luks
sdb1_crypt UUID=85baac75-dae4-4807-98dd-65d17d0c66f4 /boot/key luks

sda2_crypt has mount point at /
sdb1_crypt has mount point at /media/storage

Both have only slot 0 with key file, sdb1_crypt mounts automatically during boot as expected, while at the step of updating initramfs image in order to achieve the same procedure for sda2_crypt i get the following warning:

update-initramfs: Generating /boot/initrd.img-3.8.0-28-generic
cryptsetup: WARNING: target sda2_crypt uses a key file, skipped

Which i suspect means that initiating reboot after this is a bad idea and will lead to "unusable" system. This conclusion comes due to another issue, according to which sdb1_crypt fails to mount with 2 active slots: slot #0 with passphrase and slot #1 with a key file (same crypttab), while cryptsetup should have even 10 (if i remember well) active slots that could be used to mount encrypted device on boot.
The described schemes worked perfect at 12.04 for example.

Should i expect it to work if it was working for me and for another drives in system? I assume yes, why not.

[Christoph Anton Mitterer (calestyo)]

Please have a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774647#76

There I describe why from my understanding, the whole feature - if implemented - would be dangerous per se.