LUKS dm-crypt: Unlock multiple volumes

VirtualRider · 2010-05-20 19:49:03

Hi,

is there a comfortable way to unlock multiple luks-encrypted partitions by entering the password only once? Currently i'm using nautilus to to that for some external drives, but i need to enter the password for each. Normally i do that with pam-mount but the password is different to my account-password and i don't wanna change it (because it's less secure/painful to type and i don't need the external drives all the time).

Thanks
VR

Tenken · 2010-05-20 23:33:07

It might not be exactly what you're looking for, but you could store the passwords for the external drive in your /etc/crypttab file and have the whole thing mount without any passwords. The luks wiki page has the instructions on how you can do this.

VirtualRider · 2010-05-21 13:00:53

Thanks but I don't wanna do this because the password would be stored plaintext then

Tenken · 2010-05-21 23:31:53

You could create a key instead of having the password in the file.

Zariel · 2010-05-21 23:54:30

Store the key on an encrypted drive which requires a password

Profjim · 2010-05-22 01:30:12

Zariel wrote:

Store the key on an encrypted drive which requires a password

Yes, that's what you should do.

Overview:

* Your /boot won't be LUKS encrypted.

* Your / might be LUKS encrypted or it might not. If it is, you'll need to arrange for it to be unlocked at boot time, using the "encrypt" hook to mkinitcpio, and some extra arguments in your kernel boot line. You can type in the password manually, or specify a location where it resides on for example a USB key.

* Your swap might be encrypted or it might not. If it is, and you want to resume after suspending to disk, you'll need your swap to be decrypted at boot time as well. Perhaps you have both / and swap on a single LUKS partition, then once you've unlocked it for / it will be unlocked for swap too. Or perhaps you're like me, and have them on separate LUKS partitions. Then arch's standard "encrypt" hook for mkinitcpio won't suffice, and you'll need a custom "multicrypt" hook. I wrote such, and can supply it to anyone interested. (I submitted an earlier version a while back to the mkinitcpio devs, but it hasn't been taken up yet. That older version doesn't work anymore with the changes mkinitcpio has undergone, but I've got an updated version that does.)

Nothing else needs to be unlocked at boot time.

If you have any LUKS partitions that are still locked after the machine has all booted up, you can arrange for them to be unlocked in the /etc/crypttab file. To do that, you'd either have to put the password in plaintext in that file (but if / was itself LUKS-encrypted, and the file is only root-readable, that might not be so bad), or you'd have to specify the location of a keyfile which is then root-readable (that keyfile could reside on a LUKS-encrypted partition that was unlocked at boot time, or it could reside on a removable USB key).

An alternative to using /etc/crypttab would be to write your own script and call it from /etc/rc.local. Your script could prompt for a manually-entered password, and use that to unlock a LUKS partition. If you've got multiple partitions to decrypt, you could make a single small partition containing only keyfiles to all the others, and have your manually-entered password unlock that partition, then use the keyfiles to unlock everything else, then relock the small keyfile partition.

The "encrypt" hook for mkinitcpio (and also my custom "multicrypt" hook) would be good starting points for such a script.

Barghest · 2010-05-24 13:28:18

Profjim wrote:

If you have any LUKS partitions that are still locked after the machine has all booted up, you can arrange for them to be unlocked in the /etc/crypttab file. To do that, you'd either have to put the password in plaintext in that file (but if / was itself LUKS-encrypted, and the file is only root-readable, that might not be so bad)

Thanks, the wiki suggests just this and I was a little bit concerned. Maybe I should add to make the file readable only for root (or is this the case by default)?

So, when my new notebook will arrive the next days I'll go for a full encryption.

Although this is OT: Does encryption causes the battery to last shorter?

akephalos · 2010-05-26 14:10:10

I'm storing the random keys in /etc/keys which is on the root encrypted partitions. I make sure that no user other than root has access to that directory and keys:

# mkdir /etc/keys
# dd bs=1 count=512 if=/dev/random of=/etc/keys/extern1.key
(# dd ... /etc/keys/*.key)
# chown -R root:root /etc/keys/
# chmod -R go-rwx /etc/keys/

Yes, the key is too big because dd measures in bytes, but it doesn't matter anyway. Then I add the keys to the respective partitions with 'cryptsetup luksAddKey' and to /etc/crypttab, then add the loopback interfaces to fstab. So the only partition with a manual key is the root one "/" which asks for a key at startup, the rest are unlocked automatically.
If you have many partitions, consider that it would probably be a good idea to lower the iterations for unlocking (cryptsetup -i) for each added key, and put them on the first slot, otherwise it might take a long time for unlocking all of them.

Most if not all of this is written in the wiki, afaik.
---

I think the computing penalty is not so greats, you might take a look to this benchmark: http://www.saout.de/tikiwiki/tiki-index … eChonhulio - it could tell some things, but I don't know how up-to-date it is or the relationship between speed differences and power consumption. I can not tell whether it slows down my system or not, there's no visible slowdown.
So it depends on the cipher you use for encryption and the key length (not the generated one, but the one you add with the cryptsetup command when you format the patition! The generated keys just should be equal or longer than those). Another performance gain is to use a kernel supported cipher and load its module for your architecture at startup - eg I use AES and load "aes_x86_64" by rc.conf, I'm on Arch 64.

Last edited by akephalos (2010-05-26 14:16:29)

VirtualRider · 2010-05-27 20:16:42

Barghest wrote:

Although this is OT: Does encryption causes the battery to last shorter?

The de/encryption needs to be calculated by cpu when accessing the disk, so there should be slightly more battery consumption - but i can't note any difference on my notebook.

Profjim wrote:

An alternative to using /etc/crypttab would be to write your own script and call it from /etc/rc.local.

A script would solve my problem. Is there a way to pass the password directly to the (multiple) cryptsetup luksopen calls?

Last edited by VirtualRider (2010-05-27 20:17:39)

moljac024 · 2010-05-27 21:15:32

VirtualRider wrote:

Barghest wrote:
Although this is OT: Does encryption causes the battery to last shorter?
The de/encryption needs to be calculated by cpu when accessing the disk, so there should be slightly more battery consumption - but i can't note any difference on my notebook.
Profjim wrote:
An alternative to using /etc/crypttab would be to write your own script and call it from /etc/rc.local.
A script would solve my problem. Is there a way to pass the password directly to the (multiple) cryptsetup luksopen calls?

Yes - it's called a keyfile.

akephalos · 2010-05-27 23:17:27

I tried

echo <pass> | cryptsetup luksOpen /dev/device name

it takes *a password* it seems, but reports that no key like this is found, maybe it has to be filled with spaces until the key length, or is it requires hx00 bytes to fill the space, I don't know how to do that from command-line.
Anyway, writing the password in the command-line may save it in the command history (/root/.bash_history or whatever) so maybe key files are the better option anyway.

bobdob · 2010-05-28 07:17:06

When I was messing around with plymouth I used this to pass the password in from stdin:

echo ${pass} | cryptsetup luksOpen --key-file=- ${cryptdev} ${cryptname}

moljac024 · 2010-05-29 06:57:27

That would be doing it the wrong way. Remember that with LUKS you can have multiple keys for one volume, so one can be a passphrase if you like, and the other can be a keyfile which you would use in such scripts. Passing a passphrase in cleartext in a script just doesn't sound right

Profjim · 2010-05-30 23:19:15

moljac024 wrote:

Passing a passphrase in cleartext in a script just doesn't sound right

Yes, if you did that the passphrase would show up in your ps output. And I think even non-root users would be able to see it.

Arch Linux

#1 2010-05-20 19:49:03

LUKS dm-crypt: Unlock multiple volumes

#2 2010-05-20 23:33:07

Re: LUKS dm-crypt: Unlock multiple volumes

#3 2010-05-21 13:00:53

Re: LUKS dm-crypt: Unlock multiple volumes

#4 2010-05-21 23:31:53

Re: LUKS dm-crypt: Unlock multiple volumes

#5 2010-05-21 23:54:30

Re: LUKS dm-crypt: Unlock multiple volumes

#6 2010-05-22 01:30:12

Re: LUKS dm-crypt: Unlock multiple volumes

#7 2010-05-24 13:28:18

Re: LUKS dm-crypt: Unlock multiple volumes

#8 2010-05-26 14:10:10

Re: LUKS dm-crypt: Unlock multiple volumes

#9 2010-05-27 20:16:42

Re: LUKS dm-crypt: Unlock multiple volumes

#10 2010-05-27 21:15:32

Re: LUKS dm-crypt: Unlock multiple volumes

#11 2010-05-27 23:17:27

Re: LUKS dm-crypt: Unlock multiple volumes

#12 2010-05-28 07:17:06

Re: LUKS dm-crypt: Unlock multiple volumes

#13 2010-05-29 06:57:27

Re: LUKS dm-crypt: Unlock multiple volumes

#14 2010-05-30 23:19:15

Re: LUKS dm-crypt: Unlock multiple volumes

Board footer