Project

General

Profile

Feature #6582

Emergency password for self destruction of LUKS keys

Added by intrigeri over 5 years ago. Updated about 1 year ago.

Status:
Rejected
Priority:
Low
Assignee:
-
Category:
Persistence
Target version:
-
Start date:
01/08/2014
Due date:
% Done:

0%

Feature Branch:
Type of work:
Communicate
Blueprint:
Starter:
No
Affected tool:

Description

There's a cryptsetup patch floating around, and tested by the kali folks, that allows adding a "nuke" passphrase to a LUKS volume. When this passphrase is entered, cryptsetup deletes all keyslots.

Marking as upstream for now, as I doubt we want to patch cryptsetup ourselves.


Related issues

Duplicated by Tails - Feature #15135: Emergency password for self destruction of LUKS keys Duplicate 12/30/2017
Duplicated by Tails - Feature #16638: Nuke keys Duplicate

History

#1 Updated by micah over 5 years ago

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 over 5 years ago

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 over 5 years ago

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.

#4 Updated by intrigeri almost 5 years ago

  • Type of work changed from Upstream to Communicate

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).

#5 Updated by u over 1 year ago

  • Related to Feature #15135: Emergency password for self destruction of LUKS keys added

#6 Updated by u over 1 year ago

  • Subject changed from Emergency self-destruction of LUKS keys to Emergency password for self destruction of LUKS keys

#7 Updated by sajolida over 1 year ago

  • Related to deleted (Feature #15135: Emergency password for self destruction of LUKS keys)

#8 Updated by sajolida over 1 year ago

  • Duplicated by Feature #15135: Emergency password for self destruction of LUKS keys added

#9 Updated by cypherpunks about 1 year ago

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 about 1 year ago

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 about 1 year ago

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 about 1 year ago

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.

#13 Updated by intrigeri about 1 year ago

  • Status changed from Confirmed to Rejected

OK, so:

  • This has low benefits ("better than nothing" is not always worth the effort)
    • Limitations on flash media.
    • AFAICT this feature can only be set up on the command line and it's unlikely that common GUIs ever support it as long as it's not in cryptsetup upstream => very few users can benefit from it.
  • Benefits are hard to explain to the user (it kinda works but not so well on flash media) => some users will be mislead and put too much trust into this feature.
  • It requires maintaining a cryptsetup patch basically forever (we don't want to drop this feature ever because users may be relying on it and some will miss the announcement about its deprecation). We're weak on C developers at Tails so we cannot guarantee we'll be able to maintain this patch.

So to me the cost/benefit is pretty much clear cut => rejecting this ticket for now.

#14 Updated by mercedes508 3 months ago

Also available in: Atom PDF