Re: [dm-crypt] Re2: nuke password to delete luks header

[Matthias Schniedermeyer <ms@citd.de>]

On 15.01.2014 11:00, Jonas Meurer wrote:
> Am 2014-01-15 07:01, schrieb Arno Wagner:
> >Huh? I think you do not understand my arguments at all.
> >
> >A) It puts people in danger
> >
> >[...]
> >
> >I do not think I need to repeat how dangerous, disconnected from
> >reality and stupid this approach is, do I? Your "analysis" shows
> >perfectly why having a "nuke" option is not a good idea. People
> >will start taking risks (carrying sensitive data, trying to nuke
> >in a dangersous situation) they would otherwise not take because
> >they will wrongly think this method protects them.
> >
> >Here is a real-world scenario: You do not nuke, but you pretend
> >to give a password, yet it is invalid. Guess what, before
> >a forensic examination, this behaves exactly the same as "nuke"!
> >After a forensic examination, they _will_ suspect you of having
> >nuked the password in the nukle case. Not good at all.
> 
> I fail to see the point of your "dangerous" argument. A lot of
> things/tools/techniques are able to put people in danger. Still
> they're useful. With the same logic, you could argument against
> cryptography in general. People could actually forget the password
> and see themselves confronted with a bad evil person/institution/
> state who tries to force them to tell the password.
> 
> There's quite some situation where being accused of having nuked
> the password is not a problem at all. In german law for example,
> you're not required to help investigative authorities with their
> investigations. Actually, it's not a criminal action to destroy
> your data. Indeed it is, if the data itself is criminal. But that
> has to be proved first, which might be much harder in case that
> it's not recoverable anymore.
> 
> As I tried to explain above, I still see legitimate scenarios
> for using a nuke password function.
> 
> In cases where using the feature makes things worse, people
> should not use it. But this decision has to be made by the
> individuals themselves. Not implementing a feature because
> people could use it in a stupid way is not an argument, is it?
> 
> I agree with you, that controversal features need some extra
> protection and documentation. But this can be fixed easily:
> the process of setting a nuke password could include a big
> fat warning and point to further documentation.
> 
> The argument against false sense of security again could be
> used for every security technique. People do need to understand
> the limitations of security and cryptography. That's what
> documentation is for (and by the way: your FAQ is a great
> example of doing documentation right. Thanks for your work on
> it!)

Assuming Law Enforcement:

Before the point in time you get into the vicinity of a LEO you can nuke 
to your hearts content. After it's tampering with evidence, which is a 
punishable crime of itself (As far as i know or assume. AND IANAL). That 
the data couldn't be decrypted beforehand is insubstantial (IANAL too).
The important thing is: You can't "react" to getting into the vicinity 
of a LEO other that powering down your device.

Problem is: If a volume is nuked, you can't prove if that was before or 
after that point in time. The LEO can construct a crime right there and 
then.

The documented existence of such an option is a risk by itself, because 
the mere existence of "something" that looks like something nuked can be 
a problem. Especially if a LEO asked you to enter a password, which you 
did but it didn't work. If something that looks nuked is found after 
that, the LEO just assumes you committed the crime of tampering with 
evidence.
Altough if you nuke a LUKS header completely you can't prove that the 
data is encrypted by LUKS.
So LEO can assume the data is encrypted with any product that you can't 
exclude by analysing the remaining data.

For e.g. "Intact" you can determine that my encrpyted data is NOT LUKS 
(At least not the normaly used "inline Header"-version). If i zero-out 
the range a LUKS header normaly occupies, i can't prove anymore that the 
data is not encrypted by (inline-)LUKS or any other product that doesn't 
leave any distinguishing markers (after a possible header).

Or for the Truecypt example:
Try to prove that you don't have a hidden volume. It's a documented 
feature of Truecypt, so a LEO just assumes that you use it, regardless 
of you actually using one or not.




-- 

Matthias