LUKS Frequently Asked Questions

You are seeing
Failed to setup dm-crypt mapping.
Failed to read from key storage
Command failed: No key available with this passphrase.

dm-crypt does not work properly.
1. Check if you have a /dev/ tree, including /dev/mapper/control.
ghanima:~$ ls -l /dev/mapper/control
crw-r----- 1 root root 10, 63 Jan 1 1970 /dev/mapper/control
(char device, major 10, minor 63)^
If it's missing, you probably lack a complete /dev tree, so copy it somewhere or use devfs.
2. Check if you have device mapper and dm-crypt included in the kernel. Run
dmsetup targets
If don't, see a line like "crypt v1.1.0" or the command fails, compile device mapper and the crypt target into your kernel.
3. Check if you have the cipher you want to use included in the kernel. Run
cat /proc/crypto
4. If you are using <2.6.10, supply -c "aes-plain" on partition creation.


In fact, you probably don't want to make copies of the phdr or the master keys. The reason is that LUKS was designed to manage its metadata securely. If you copy the master keys then LUKS has lost control of them, leaving you with the responsibility of managing the keys securely.


INSERTION BEGIN
question from user:
I don't get the point. When I backup the luks-header via dd, I mainly backup a master key that is encrypted by some passwords. Why should it be dangerous to store this header let's say on my home-page where everyone can get it. I even could publish the image of my encrypted device (which includes phdr, encrypted keys and the encrypted bulk data) via torrent, and it should not be risky. I thought it is supposed to be safe till someone gets my passwords. When the police come and take my hdd's they also get my luks-header. So backupping the phdr with all its (encrypted) keys should not be a risk, but be a benefit because of the higher safety against loosing all my data. This is what would happen, if my luks-header gets screwed up. Please tell me about mistakes I made. (sorry for my english)

answer by clemens:
The FAQ states: "If you copy the master keys then LUKS has lost
control of them, leaving you with the responsibility of managing the
keys securely."
"managing keys securely" needs a bit of clarification: LUKS was
designed with key revocation in mind — that is you are able to delete
passphrases. Obviously this is not possible if you post copies of the
header on your homepage. Assuming you have a good reason to change
your passphrase (maybe someone was standing behind your computer, or
you found a key logger built into your keyboard), then data
destruction is vitable, more precisely all copies of the master key
must be destroyed that are encrypted by the old-passphrase that is
assumed to be compromised.

final comment by user:
OK, now i've got the point. Besides I'm using LUKS in combination with gpg.
(like: gpg --decrypt ./root-key.gpg 2>/dev/null | cryptsetup luksOpen /dev/sdx7 root)
So LUKS never gets my (weak) password directly, but just a weird random key that is stored inside the root-key.gpg file. So I think in my case, it makes sense to backup the LUKS-Header, because I'm not planing to change the LUKS keys at all.
INSERTION END



The problem here is that it is extremely difficult to do this. You expose yourself to risk the moment that you write the master keys to a permanent, unencrypted, storage media. As soon as this happens, the file system is free to do whatever it wants with the data. The file system can move the metadata during defragmentation, put the data in its journal and rewrite it later, dump the unencrypted data to a backup file once or multiple times during an incremental backup. Once there are many copies of the master keys floating around, it is difficult, or impossible,to revoke them without leaving traces. This is a large compromise of security.

What are the risks of not backing up your metadata? The LUKS phdr is certainly a single point of failure. There are two reasons why a LUKS phdr can become unusable: human error, mechanical wear. The first class is hard to come by — too many variants exists. For the second class, there is a standard solution: RAID. It covers all single point of failures in your storage system neatly. Another option is to do regular backups to another LUKS partition.

Hence because there are problems than benefits, cryptsetup-luks will never include a command to export metadata.

If you really think you know what you are doing, do it:

cryptsetup luksDump <your luks dev>

search for a line
Payload offset: <payloadnumber>

Now to backup your metadata — that is everything before the payload — run
dd if=<your luks dev> of=<destination, see below> count=<payloadnumber>

To restore the metadata, reverse "of=" and "if=" in the command above.

In case you really consider doing this, put the metadata

• on a ram disk,
• or when you need to store it more permanently, burn it on CD directly of that ram disk (without your burning programming writting an intermediate image to some tmp dir).

It's already there. If you want the USB stick to be sufficient to access your data,

1. mkfs/mount your USB stick
2. generate a key file directly onto the USB stick (for example, a 2048bit key): dd if=/dev/random of=/mnt/usbstick/keyfile bs=1 count=256
3. and add it into a key slot: cryptsetup luksAddKey /dev/luksPartition /mnt/usbstick/keyfile

Make a script to reset the password (to a randomly generated one?) after each use.

Yes. (need to complete)