Tails

#1 Updated by micah 2014-01-18 19:34:32

This mechanism is a bit flawed IMHO:

1. it deletes the keys by wiping them with zeros - this is easily detectable by any forensic analysis
2. it is much easier, and safer, to wipe the LUKS header, which can be done with a simple dd
3. it requires a patch to cryptsetup… while I guess that would be nice to have an option to do it, being able to do that with dd is pretty easy
4. if you wipe your headers, and have a backup of your headers, you have the possibility of restoring them! (see backupninja sys handler option ‘luksheaders’)
5. hello!

#2 Updated by micah 2014-01-18 19:47:00

I was mistaken, they do wipe the keys correctly, and not just with zeros (they are using “LUKS_del_key()” which writes some random data in some funky loops)… but i think it is still better to just wipe the header with dd!

#3 Updated by micah 2014-01-18 19:52:33

Might as well provide a little bit more information - I think that if you had a backup of your headers, you would still be able to restore the keys, if they were wiped with this kali linux method. However, I think that wiping the full header is better, because it contains other metadata and identifies the device as an encrypted device. If you just wiped the keys, you still have the header. Wiping the header gives you a partition with data that looks random and is indistinguishable from an uninitialized device… there is no way of knowing that this is a LUKS device. Wiping the keys, but leaving the header leaves you in a state where investigation of the partition will show that it is a LUKS device, but it appears as if it has had its keyslots removed, which looks like a deliberate attempt to hide/obstruct the decryption of the partition.

#9 Updated by cypherpunks 2018-06-08 06:26:57

intrigeri wrote:
> OK, so next step is to ask cryptsetup upstream to implement this feature in a saner way (that is, in a way that actually wipes the entire LUKS header).

It has been asked before, and upstream will not do that. In fact they seem to have a philosophical issue with attempting to hide encryption, calling it wasted effort (they refuse to implement plausible deniability for the same reason). All they will do is what they have already done, i.e. cryptsetup erase which wipes the key material and sets the number of valid keyslots to 0. This is fine from a security point of view since the key material is, in theory, destroyed.

Wiping it, regardless of technique, on a USB device is rather useless anyway. In fact, it will not work, since attempting to overwrite the same logical sector twice on a USB flash drive (or any SSD) will end up writing to two different physical sectors due to dynamic wear leveling (static wear leveling on higher end devices). Overprovisioning additionally makes it impossible to reliably overwrite the entire block device.

I think this ticket should be rejected, as what it is suggesting is impossible to accomplish with any extant flash drive.

#10 Updated by Gaff 2018-06-08 07:04:32

Isn’t the classic answer here to change the encrypted password using /dev/random as the input?

cypherpunks wrote:
> Wiping it, regardless of technique, on a USB device is rather useless anyway. In fact, it will not work, since attempting to overwrite the same logical sector twice on a USB flash drive (or any SSD) will end up writing to two different physical sectors due to dynamic wear leveling (static wear leveling on higher end devices). Overprovisioning additionally makes it impossible to reliably overwrite the entire block device.

I accept your point - but at the same time it increases the cost of recovery by several orders of magnitude. That’s better than nothing.

#11 Updated by intrigeri 2018-06-10 10:20:18

OK, so let’s forget about wiping the full header and say that what kali does is good enough.

So, has there been an attempt to upstream kali’s new feature?

#12 Updated by cypherpunks 2018-06-13 00:58:29

intrigeri wrote:
> OK, so let’s forget about wiping the full header and say that what kali does is good enough.
>
> So, has there been an attempt to upstream kali’s new feature?

It was rejected because the author of cryptsetup does not like the idea of relying on anything other than cryptographic soundness for security. His argument is that no adversary is going to enter the password you give them into the original copy of the encrypted volume using software you gave them. They will image the disk and attempt decryption using their own software, making it both useless and dangerous to give them a dummy passphrase.