Is deleting LUKS keys during operation a good way to protect my data?

Question

Let's say Alice owns a server that stores highly sensitive data. Let's further assume the data is worth a lot, but losing all data is way less of a problem than having it read by attacker Mallet.

To have the data safe in normal operation, all the harddisks have LVM and LUKS with full volume encryption enabled. There is one keyslot enabled. The server is protected against power loss via UPS.

Alice could see Mallet, physically trying to steal the harddisks, coming, ssh into the server and issue cryptsetup luksErase to permanently destroy the header and thus make the data unrecoverable.

If, however, Mallet sneaked into the server room, unplugged the server from the UPS without shutting it down, and then took out the drives, the LUKS headers with the keys would still be on there. Assuming Mallet had the computation power at his hands to break the password, he could unlock the volumes.

Now I came up with this: What if the server, once the volumes are unlocked, overwrote the headers? In a case of sudden power loss, all data would be gone forever. When Alice needs to reboot, she could copy the data off the unlocked volume to another disk, reboot, reinitialize the LUKS volume and restore the data, then destroy the external disk.

Would that be safer or is it sufficient to choose a long enough password for LUKS? (Not to mention the solution is surely paranoid, but just in theory)

I suppose if confidentiality is much much much much more important than availability, yes, that is a way to do it, provided you understand that no hosting provider ever manages 100% uptime, so you will completely lose your data at some point. — crovers, Oct 25 '16 at 18:12
Note that if your attacker has physical access she can also do a cold-boot or DMA attack and recover the keys from RAM which are always kept there as the server needs them to be able to use the encrypted volume. — André Borie, Nov 04 '16 at 19:34
I think you could get rid of the dma risks by disabling firewire and other vulnerable i/o in the bios settings? — Out of Band, Nov 04 '16 at 21:13
@PascalSchuppli what about accessing the PCI slots in the machine which can't be disabled, or tapping into the PCB traces that link the RAM modules to the CPU? If the attacker has physical access it's game over no matter how hard you try. — André Borie, Nov 06 '16 at 03:25
@André - likely, but the harder you try, the more difficult it becomes for an attacker. The idea would be to make it so difficult that another venue of attack becomes cheaper/more likely. And there's a few simple ways to lock down a physical machine to provide some resistance. — Out of Band, Nov 06 '16 at 09:37

score 2 · Accepted Answer · answered Nov 04 '16 at 19:26

Would your solution be more secure than choosing a really long password?

That depends on the size of the passphrase.

The luks header contains a certain-sized key and iv.II don't know the sizes in bits of those two without looking them up, but lets assume that together they are 512 bits long.

If you overwrite the luks header, in order to decrypt the partition, you need to correctly guess these 512 bits. This is currently impossible to do in a useful amount of time (think anytime before the sun explodes...)

If you assume luks doesn't do any key stretching (which it does), you need a random passphrase of 64 characters to match this. You can easily produce such a key:

$ dd if=/dev/random of=my-key bs=64 count=1

You can even pass in such a key directly while creating a luks partition. This is how encrypted swap works on linux. The swap partition gets reinitialized with a new random key every time the system boots, so the old swap contents are securely destroyed.

For your system, you could make it easier to handle by storing the luks key in memory (or /dev/shm). When the system unexpectedly shuts down, the partition is lost. when you want to reboot, you store the key to disk (or export it over the network) and open the luks container using the stored key after reboot. Then you replace the key with a new key, which you again only keep in memory.

This way, you won't lose the data on scheduled shutdowns.

score 0 · Answer 2 · answered Nov 04 '16 at 21:37

This seems rather convoluted given that a much simpler solution exists. Instead of having the encryption key generated by a password that can be found by brute force, have it generated by a password that can't be found by brute force.

A password isn't guessable by virtue of being a password, it's guessable because it's too short, or more precisely because it has too little entropy. If a password has 128 bits of entropy, it isn't any more guessable than any other 128-bit key. (Replace “128” by “256” if you believe in ~~magic~~ quantum cryptanalysis.)

Such a long password can't realistically be remembered by a human, but it can be written down and typed by the operator, or, better, stored on a smartcard which is inserted by the operator. The operator is needed to boot your system anyway since somebody has to provide the credentials.

You can, and should, keep using multiple slots so that you can revoke one of the keys without invalidating the others (e.g. if one operator's smartcard or piece of paper gets stolen).

Since you're worried about an attacker with physical access, you'll probably want to apply the TRESOR patch to protect against the attacker coming with a can of compressed air, yanking the RAM modules out and reading the key back from the RAM.

Is deleting LUKS keys during operation a good way to protect my data?

2 Answers2