[dm-crypt] nuke password to delete luks header
flyingstar16 at gmail.com
Thu Jan 16 23:49:30 CET 2014
> Ok, here is one proposal:
> Lets split this discussion. I think this simplifies things.
> 1. Have a secure erase that is easy to use. This will
> help anybody that is not a technical person but
> needs to securely get rid of a luks header fast when
> still free to act as thay chose.
> This can just be a key-slot kill for all slots or the like.
> It can also be a full header erase.
> Maybe "cryptsetup luksEraseAll" or something like it
> and requiring a "YES" like luksFormat.
I think having 1. generally is good, as it is a dedicated operation
> that really does only one thing and does it well, namely making
> the LUKS container irrecoverable while the user is still free to
> act as they chose. The journalist from the example would only need
> to memorize this one command ad an emergency "red button".
I agree. Also, the same journalist could create an alias (say alias
EMERGENCY="/sbin/cryptsetup luksEraseAll /dev/sda"), set a NOPASSWD option
ini /etc/sudoers (if he's using sudo) and have a
$ sudo EMERGENCY
that triggers (1).
Even faster, and pretty useful to him
> 2. Have the option of unlocking a keyslot created with a specific
> option to trigger the function implemented in 1.
For 2. all the pros and cons apply though. I would at the very
least make its presence a compile-time option and put very strong
> warnings that this is dangerous in the documentation. It may still
> be desirable to not have 2. at all (I think it is so, as it does more
> harm than good), as it really is only something useful when already
> not free to act or under close superwision of what command one types.
> And that is a situation that is highly problematic and we cannot even
> come close to help the user mastering this situation.
While it's actually not a "command", that a person is typing, but just a
password, a question comes to mind:
Once you get to the password prompt, it's clear you have an encrypted disk.
So, unless you're really, really, really in trouble you'd never use the
Three cases come to mind:
1) you have something really, really illegal on your HD and you get stopped
at a security checkpoint. In this case, (a) you're an idiot who took that
kind of stuff on a laptop instead of having a clean laptop and retrieving
it via a secure connection and (b) even if you wipe your hard drive you're
in big trouble, because they'll know you did it.
2) Your life is in danger and somebody wants something from your laptop:
what do you think will happen then, if you wipe your key?
The only real time you're going to need such functionality is if you have
data on your computer, you know someone's coming and your computer is
turned _off_: you have very little time, so you just boot, type in the wipe
password and unplug.
In this case, though, it's not enough wiping the keyslots: you'd have to
wipe the entire header, because otherwise the only thing that "someone"
will see is you not giving them the correct password.
> As tool-makers we have a responsibility to balance functionality
> and risks as we understand the tool better than most of the users.
> Of course, the user may understand the situation he finds himself
> in better than we do (or not), but that is why it is a balance.
> Neither "deny everything even a bit riksy" nor "allow everything"
> is morally right for a tool that is mainly used by non-experts.
I believe that the best course of action in this case would be to implement
it as "highly experimental not guaranteed" with a (or a couple of)
compile flag, but at least we can give the users a choice. And, with a
compile flag, very few people are going to be able to put that in place.
I must admit I did not read the 60+ emails in the whole discussion, so I
might have repeated something someone had already said.
If so, please disregard it :)
 Not guaranteed because of the issues with SSDs.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt