LUKS: Add a Backup Key, Backup, Restore and Delete LUKS Volume Header

Following up our LUKS installation, we will go further and explore how to add a backup passphrase as well as how to backup and restore LUKS volume header in case of disaster.

LUKS format uses a metadata header and 8 key-slot areas that are being placed at the beginning of the disk. The passphrases are used to decrypt a single master key that is stored in the anti-forensic stripes.

Multiple key-slots are particularly handy for applications which require several users to have distinct access keys to the same device. Multiple key-slots also allow us to add backup passphrases.

Dump a LUKS Header

We can dump the LUKS header of our existing volume to get information about the key-slots that are in use:

# cryptsetup luksDump /dev/sdb2
LUKS header information for /dev/sdb2

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      e5 88 07 f2 4b ce 79 21 85 34 f7 a6 e3 0b 6b b2 a7 b8 d5 a1
MK salt:        0c dd 95 3d 1e 30 1f 66 d4 5e 31 03 12 a0 61 29
                e5 ef 34 8e 13 5d 80 76 8b 4a 0a c3 55 02 22 d3
MK iterations:  5750
UUID:           e4971160-047b-49ce-8246-b63f1fb67db9

Key Slot 0: ENABLED
        Iterations:             23233
        Salt:                   ff bc fc 78 98 5d 35 50 97 76 37 b4 70 99 38 44
                                9f bd a1 b9 02 2d 4d 1d 18 b5 dc f6 4c a0 37 fc
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

As we may see above, only the “0” key-slot is in use as we have only added a single passphrase when creating the volume.

Add a Backup Key

We would like to add a backup passphrase to the slot “1”. This can be achieved by using the luksAddKey parameter:

# cryptsetup luksAddKey --key-slot 1 /dev/sdb2
Enter any passphrase:
Enter new passphrase for key slot:
Verify passphrase:

Note that the passphrase of an existing key-slot must be supplied first in order to add a new one. Let’s dump the header again to ensure that the “1” key-slot is enabled:

# cryptsetup luksDump /dev/sdb2
LUKS header information for /dev/sdb2

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
Payload offset: 4096
MK bits:        256
MK digest:      e5 88 07 f2 4b ce 79 21 85 34 f7 a6 e3 0b 6b b2 a7 b8 d5 a1
MK salt:        0c dd 95 3d 1e 30 1f 66 d4 5e 31 03 12 a0 61 29
                e5 ef 34 8e 13 5d 80 76 8b 4a 0a c3 55 02 22 d3
MK iterations:  5750
UUID:           e4971160-047b-49ce-8246-b63f1fb67db9

Key Slot 0: ENABLED
        Iterations:             23233
        Salt:                   ff bc fc 78 98 5d 35 50 97 76 37 b4 70 99 38 44
                                9f bd a1 b9 02 2d 4d 1d 18 b5 dc f6 4c a0 37 fc
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: ENABLED
        Iterations:             23956
        Salt:                   3a a0 06 83 d3 e0 ba da b0 5c e2 56 cb ed 72 69
                                76 9a 8a b8 e1 eb e6 90 44 b3 71 7a 2f 96 80 39
        Key material offset:    264
        AF stripes:             4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Perfect, we have now got two passphrases set up on our encrypted volume. In case we forget the initial one, we can use a backup one.

Change or Remove a Key

We can remove the supplied passphrase from the LUKS device by issuing:

# cryptsetup luksRemoveKey /dev/sdb2

WARNING: removing the last passphrase makes the LUKS container permanently inaccessible!

If we want to change one of our existing passphrases, we can simply remove the unneeded one and add a new one to its place instead.

Backup and Restore a LUKS Header

From the cryptsetup man page:

LUKS header: If the header of a LUKS volume gets damaged, all data is permanently lost unless you have a header-backup. If a key-slot is damaged, it can only be restored from a header-backup or if another active key-slot with known passphrase is undamaged. Damaging the LUKS header is something people manage to do with surprising frequency. This risk is the result of a trade-off between security and safety, as LUKS is designed for fast and secure wiping by just overwriting header and key-slot area.”

Referencing LUKS FAQ, there are two critical components for decryption: the salt values in the header itself and the key-slots. If the salt values are overwritten or changed, nothing (in the cryptographically strong sense) can be done to access the data, unless there is a backup of the LUKS header. If a key-slot is damaged, the data can still be read with a different key-slot, if there is a remaining undamaged and used key-slot.

Making the long story short, if our LUKS header gets damaged, all data is gone. To prevent this from happening, we need to create a header backup. This can be done by issuing the following command:

# cryptsetup luksHeaderBackup <device> --header-backup-file <file>

Where <device> is a LUKS volume disk and <file> is a name of a header backup file to be created. In our case:

# cryptsetup luksHeaderBackup /dev/sdb2 --header-backup-file /root/sdb2-header-backup

Important note: a LUKS header backup can grant access to most or all data, therefore we need to make sure that nobody has access to it or at least reduce the possibility for that to happen. Storing a LUKS header backup file on an encrypted cloud storage (such as Spideroak) wouldn’t be a bad idea.

In case of disaster where our LUKS header gets broken, we can restore it by issuing the following command:

# cryptsetup luksHeaderRestore <device> --header-backup-file <file>

WARNING: LUKS header restoration procedure will replace all key-slots, therefore only the passphrases from the backup will work afterwards!

Securely Erase a LUKS Header

In case you’re wondering why would we want to do this, here is the reason: one of LUKS disadvantages is that it is readily obvious there is encrypted data on our disk. Although in practice it doesn’t really matter, in some countries men in black can easily identify we’re using LUKS and force us to hand over the keys. LUKS filesystem can be identified by checking its volume header:

# cryptsetup -v isLuks /dev/sdb2
Command successful.

Issuing the same command for another disk (/dev/sdb1) would gives us a non-valid LUKS device message:

# cryptsetup -v isLuks /dev/sdb1
Device /dev/sdb1 is not a valid LUKS device.
Command failed with code 22: Device /dev/sdb1 is not a valid LUKS device.

The presence of the LUKS header identifies the existence of the LUKS filesystem on our disk, though it’s not enough to prove that we have any keys. However, the suspicion is enough, men in black don’t have to prove anything. Therefore erasing the LUKS header makes it impossible to recover any data from the LUKS volume having no header backup available (although I bet NSA would disagree with me).

The default LUKS header (with only one key-slot enabled) takes 1052672 bytes, what is slightly more than 1 MiB. Having 2 key-slots enabled this would extend the header almost twice (key-slots * stripes * keysize + offset bytes). Therefore overwriting the first 3 MiB would do the job for us:

# head -c 3145728 /dev/zero > /dev/sdb2; sync

This would still leave the disk with encrypted data on it, but that might have been an experiment with /dev/random, for example. Anyhow, it’s as impossible to prove we have encrypted data of the disk as the other way round. The outcome: if they want to lock us up, they will do.

14 thoughts on “LUKS: Add a Backup Key, Backup, Restore and Delete LUKS Volume Header

  1. I’m sorry, but your statement Important note: a LUKS header backup can grant access to most or all data doesn’t make any sense to me.

    The header is just a backup of a certain number of bytes at the beginning of the partition/device. If your statement were true, everyone who had access to the physical encrypted disk would be able to access the data thus rendering encryption useless.

    Can you please clarify your statement?

    • Look a bit deeper. If you have a LUKS header backup or a full backup, then you can grant access to most or all data by brute-forcing the passphrase. It’s just a matter of time NSA cracks your passphrase. It might be hours, it might be years. The amount of time is not important in this case. It’s all about the theoretical possibility. Whether it’s worth spending money and resources on this or not is completely out of the picture.

      The point is to ensure nobody has access to a LUKS header backup. If you have no LUKS header backup and the LUKS header on a disk is damaged, nothing can be done to get access to encrypted data. Data is permanently lost.

    • If you are talking about theoretical possibilities, then it doesn’t matter whether you have the header or not. You could theoretically still brute-force decryption of your data w/o the header.
      It would certainly take a lot more time (really huge numbers here) then just brute-forcing the passphrase, but it is still possible – in theory that is.

      In cryptoanalysis the terms practicality and complexity of attacks are used. Even with the header the attack would be impractical, although there are people who state that even computationally impractical attacks can be considered breaks…

    • Interesting, I was under impression that a LUKS header contains a 256 bit salt per key-slot and without that no decryption is possible. Thus erasing the LUKS header would make access to encrypted data infeasible. I am by no means a cryptography expert, so my understanding in this particular case may be slightly wrong. Thanks for your valuable input Tessarek.

  2. You are right, attacking it without the header would be immensly time consuming. I’m talking about a order of magnitude of several billion years, but it is *theoretical* possible.
    But since you stated in your first reply that you mentiond it because cracking it with the header is a theoretical possibility, I just wanted to explain that it would also be possible without the header.

    Practically both attack vectors are not feasible unless you don’t use a passphrase, but cryptology never has and never will make good for the stupidity of the user.

    • I was looking from a little bit more practical perspective when talked about theoretical possibilities. If your LUKS encryption passphrase is say “123456789” (Adobe password leak, huh?), then having a LUKS header makes it fairly easy to brute-force the whole thing and you data is accessed in pretty much no time.

      On the other hand, if the LUKS header is damaged and no header backup is available, it makes (as you mentioned) the whole decryption process immensely time consuming having no salt values.

      I think you get my point now. And again, thanks for your input. Much appreciated.

  3. Thank you. It took me a long time to find this. Then had to read through the arguments instead of just a clean how to.
    The arguments are certainly valid but I think it just muddies the water here.

    This is a good tutorial but can’t we just stick to the process instead of the argument of what if?
    We just want to get to the meat of locking out the attacker who is just t a thief etc. My larger danger here is theft by a Crack head. I’m not worried about NSA except for the fact I think they are out of control and need to be reigned in along with the other crooked Three letter agencies run by our now criminal element.
    Using this information I now have a script that runs if I just close the lid on my laptop, which will wipe my header with “/dev/urandom.” NOTE: Please do not scream at me about what if I or someone near me just decide to shut the lid. I’m painfully aware of the possibilities. So you can breath easy I keep a monthly image of my laptop drive using DD on another portable disk. The last back up ended today after twenty two hours of running. It’s a pain in the butt but I can rebuild my system to only one month old at the worst case. I also keep hourly, daily, weekly and monthly RSYNC backups of everything important. Yes crontab.
    What I need now is a way to have it auto destruct if the luks password is entered wrong in X number of times. Also would be nice to have a way to enter a fake?? password that would run the wipe keys script. Any good ideas on that? Barring a fake password a timer would be good. Either get the password right within X or runs wipe script automatically.

    Thanks again,
    A pissed off Veteran

  4. Thank you for the guide.

    After erasing the header as indicated with your sample command:

    # head -c 3145728 /dev/zero > /dev/sdb2; sync

    is it possible to restore the backup header and continue to access the data?

    • It is possible to restore the header if you backed it up before erasing, that’s what I always do when creating new LUKS volumes – dump LUKS volume header, erase it and attempt to restore from the backup file. If it works, then I know that I have a valid header backup and can start putting files into the new volume.

  5. I very much appreciate this blog post – a true service to those of us learning how these things work! Thank you no end. – M

Leave a Reply

Your email address will not be published. Required fields are marked *