[dm-crypt] LUKS self-destruct key

[dm-crypt] LUKS self-destruct key

[Andrew]

Greetings dm-crypt folks,

Is it feasable to add a self-destruct password to cryptsetup for LUKS, such that when this password is entered, the decryption code silently and deliberately overwrites all or part of the master key?  

If you are facing an unjust order to produce a working key, having the option to produce a self-destruct key would be helpful in some circumstances.  There are a number of ham-fisted regimes and illegal groups that do not know the difference between decrypting data and running untrusted code.  Destroying the master key would look to these like a simple failed attempt at decryption, and ensure the permanenty destruction of the data that they are seeking.

 + Give us your key
 - I don't remember it
 + Give Us Your Key
 - I really don't remember it
 + GIVE US YOUR KEY
 - I think it's "INITIATE-SELF-DESTRUCT-SEQUENCE" but I'm not sure
 + That didn't work
 - I told you I don't remember


In pseudocode, the decryption would become something like this (based on my probably faulty understanding of LUKS):

    evaluate_password_for_slot(slot) {
	slot_plaintext=decrypt(slot_ciphertext, password);
	/* initiate self_destruct */
	if memcmp(slot_plaintext,SELF_DESTRUCT_PLAINTEXT,sizeof(SELF_DESTRUCT_PLAINTEXT))==0)
		wipe_master_key();
		wipe_key_slots();
	}
	/* self_destruct complete */
	master_key = decrypt(master_ciphertext, slot_key);
	if this_is_a_valid_master_key(master_key) { return E_SUCCESS; }
	return E_FAIL;
    }

Code changes would include:
	Not considering a self-destruct key as a valid remaining key in luksKillSlot
	Front-end code to create a slot as a self-destruct key
	Back-end code to destroy the master key
	s/SELF_DESTRUCT/ESCROW/g  /* :) */

Re: [dm-crypt] LUKS self-destruct key

[Chris Drake]

Hi Andrew,

Codewise - easy.

Point-wise - I cannot see.

From your adversary's point of view, all they see is you giving them
bogus passwords that don't work.  You may as well just keep giving
them bogus passwords.

The only difference is that when they point a gun at your head, with
your idea, you're 100% certain you're going to die.

Kind Regards,
Chris Drake


Monday, March 31, 2014, 3:17:30 PM, you wrote:

A> Greetings dm-crypt folks,

A> Is it feasable to add a self-destruct password to cryptsetup for
A> LUKS, such that when this password is entered, the decryption code
A> silently and deliberately overwrites all or part of the master key?

A> If you are facing an unjust order to produce a working key, having
A> the option to produce a self-destruct key would be helpful in some
A> circumstances.  There are a number of ham-fisted regimes and
A> illegal groups that do not know the difference between decrypting
A> data and running untrusted code.  Destroying the master key would
A> look to these like a simple failed attempt at decryption, and
A> ensure the permanenty destruction of the data that they are seeking.

A>  + Give us your key
A>  - I don't remember it
A>  + Give Us Your Key
A>  - I really don't remember it
A>  + GIVE US YOUR KEY
A>  - I think it's "INITIATE-SELF-DESTRUCT-SEQUENCE" but I'm not sure
A>  + That didn't work
A>  - I told you I don't remember


A> In pseudocode, the decryption would become something like this
A> (based on my probably faulty understanding of LUKS):

A>     evaluate_password_for_slot(slot) {
A>         slot_plaintext=decrypt(slot_ciphertext, password);
A>         /* initiate self_destruct */
A>         if
A> memcmp(slot_plaintext,SELF_DESTRUCT_PLAINTEXT,sizeof(SELF_DESTRUCT_PLAINTEXT))==0)
A>                 wipe_master_key();
A>                 wipe_key_slots();
A>         }
A>         /* self_destruct complete */
A>         master_key = decrypt(master_ciphertext, slot_key);
A>         if this_is_a_valid_master_key(master_key) { return E_SUCCESS; }
A>         return E_FAIL;
A>     }

A> Code changes would include:
A>         Not considering a self-destruct key as a valid remaining key in luksKillSlot
A>         Front-end code to create a slot as a self-destruct key
A>         Back-end code to destroy the master key
A>         s/SELF_DESTRUCT/ESCROW/g  /* :) */

A> _______________________________________________
A> dm-crypt mailing list
A> dm-crypt@saout.de
A> http://www.saout.de/mailman/listinfo/dm-crypt

Re: [dm-crypt] LUKS self-destruct key

[Arno Wagner]

This has been discussed here several times, please search 
the mailing-list archives and read FAQ Item 5.21. 

The current take is that it makes no sense security-wise.
In fact, the possibility does more harm than good. This
is not "Mission: Impossible", this is the real world.

The only thing found to make some sense is to have an
explicite "erase/luksErase" command that does not take a 
password. cryptsetup has this since version 1.6.4.

Arno

On Mon, Mar 31, 2014 at 07:17:30 CEST, Andrew wrote:
> Greetings dm-crypt folks,
> 
> Is it feasable to add a self-destruct password to cryptsetup for LUKS,
> such that when this password is entered, the decryption code silently and
> deliberately overwrites all or part of the master key?
> 
> If you are facing an unjust order to produce a working key, having the
> option to produce a self-destruct key would be helpful in some
> circumstances.  There are a number of ham-fisted regimes and illegal
> groups that do not know the difference between decrypting data and running
> untrusted code.  Destroying the master key would look to these like a
> simple failed attempt at decryption, and ensure the permanenty destruction
> of the data that they are seeking.
> 
>  + Give us your key
>  - I don't remember it
>  + Give Us Your Key
>  - I really don't remember it
>  + GIVE US YOUR KEY
>  - I think it's "INITIATE-SELF-DESTRUCT-SEQUENCE" but I'm not sure
>  + That didn't work
>  - I told you I don't remember
> 
> 
> In pseudocode, the decryption would become something like this (based on
> my probably faulty understanding of LUKS):
> 
>     evaluate_password_for_slot(slot) {
> 	slot_plaintext=decrypt(slot_ciphertext, password);
> 	/* initiate self_destruct */
> 	if memcmp(slot_plaintext,SELF_DESTRUCT_PLAINTEXT,sizeof(SELF_DESTRUCT_PLAINTEXT))==0)
> 		wipe_master_key();
> 		wipe_key_slots();
> 	}
> 	/* self_destruct complete */
> 	master_key = decrypt(master_ciphertext, slot_key);
> 	if this_is_a_valid_master_key(master_key) { return E_SUCCESS; }
> 	return E_FAIL;
>     }
> 
> Code changes would include:
> 	Not considering a self-destruct key as a valid remaining key in luksKillSlot
> 	Front-end code to create a slot as a self-destruct key
> 	Back-end code to destroy the master key
> 	s/SELF_DESTRUCT/ESCROW/g  /* :) */
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] LUKS self-destruct key

[Jonas Meurer]

Am 2014-03-31 07:17, schrieb Andrew:
> Greetings dm-crypt folks,
> 
> Is it feasable to add a self-destruct password to cryptsetup for LUKS,
> such that when this password is entered, the decryption code silently
> and deliberately overwrites all or part of the master key?

Hello Andrew,

As others already pointed out, the topic has been discussed on the
list recently. The discussion was quite controversal. And while it is
true, that the majority of expressed opinions was against implementing
the requested nuke feature, there've been quite some statements that
opposed to this majority. In my eyes, quite some valid realworld
examples have been mentioned.

You can read the full discussion thread here:
http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/7104

Please also note that Kali Linux already implemented the nuke feature
into their distribution:
http://www.kali.org/how-to/emergency-self-destruction-luks-kali/
http://www.kali.org/how-to/nuke-kali-linux-luks/

Kind Regards,
  jonas

Re: [dm-crypt] LUKS self-destruct key

[Andrew]

On Mon, 31 Mar 2014 11:52:34 +0200
Jonas Meurer <jonas@freesources.org> wrote:

> Am 2014-03-31 07:17, schrieb Andrew:
> > Greetings dm-crypt folks,
> > 
> > Is it feasable to add a self-destruct password to cryptsetup for
> > LUKS, such that when this password is entered, the decryption code
> > silently and deliberately overwrites all or part of the master key?
> 
> Hello Andrew,
> 
> As others already pointed out, the topic has been discussed on the
> list recently. The discussion was quite controversal. And while it is
> true, that the majority of expressed opinions was against implementing
> the requested nuke feature, there've been quite some statements that
> opposed to this majority. In my eyes, quite some valid realworld
> examples have been mentioned.
> 
> You can read the full discussion thread here:
> http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/7104
Thanks Jonas,

I read the thread -- interesting reading (Gmane seems a little off for me at the moment though.)

A few points that were not raised directly by anyone are:

 * Some of the worst attackers *do* lack technical skills.  While various interest groups do have technical experts, less skilled persons may try their hand first, and succeed in destroying the evidence.  Terrorism has lately tended towards a cell structure.  A particular cell may not have access to adequate technical resources, while not lacking "skills" like kidnapping, robbery and torture of those they target.  

 * An attacker may guess the wipe/kill/nuke/erase password without any intervention by the user (at last - a use for post-it notes!)  Users' passwords may well be inadequate, despite all advice to the contrary.  Having an even-more-inadequate nuke/self-destruct/erase password may frustrate an attacker.

 * If it is possible for the key to be destroyed without the user's intervention, then it becomes plausible that there is nothing to be gained by asking for a password.  (e.g. LEO removes device from user, and upon return, the user's provided key does not work, because LEO has tested some password; user complains that LEO has destroyed the data.)  

 * A self-destruct feature is not unique, and exists in other modern devices: e.g. the iPhone's self-destruct on failed lock

 * Users have a free choice whether to create a self-destruct/nuke/erase key or not.  Choice is important.

 * Law enforcement may demand all passwords.  It would be an omission to fail to provide them with passwords for the good and the bad key slots ;) (rather cheeky, but it's a choice)


> Please also note that Kali Linux already implemented the nuke feature
> into their distribution:
> http://www.kali.org/how-to/emergency-self-destruction-luks-kali/
> http://www.kali.org/how-to/nuke-kali-linux-luks/
I like!  I'll look out for the patch for my favourite distribution.

> 
> Kind Regards,
>   jonas

Re: [dm-crypt] LUKS self-destruct key

[Arno Wagner]

Ok, I will repeat some of the same old things that apparently 
have to be said time and again when somebody has this 
not-so-bright idea.

On Mon, Mar 31, 2014 at 14:19:29 CEST, Andrew wrote:
[...]
> I read the thread -- interesting reading (Gmane seems a little off for me
> at the moment though.)
> 
> A few points that were not raised directly by anyone are:
> 
>  * Some of the worst attackers *do* lack technical skills.  While various
>    interest groups do have technical experts, less skilled persons may try
>    their hand first, and succeed in destroying the evidence.  Terrorism
>    has lately tended towards a cell structure.  A particular cell may not
>    have access to adequate technical resources, while not lacking "skills"
>    like kidnapping, robbery and torture of those they target.

Even the dumbest attackers have seen the movies where the magic
computer destroys all data when the wrong password is entered.

And when you come to any writing about compouter forensics,
the first rule is always to never work on originals. 
 
>  * An attacker may guess the wipe/kill/nuke/erase password without any
>    intervention by the user (at last - a use for post-it notes!) Users'
>    passwords may well be inadequate, despite all advice to the contrary. 
>    Having an even-more-inadequate nuke/self-destruct/erase password may
>    frustrate an attacker.

See above.

>  * If it is possible for the key to be destroyed without the user's
>    intervention, then it becomes plausible that there is nothing to be
>    gained by asking for a password.  (e.g.  LEO removes device from user,
>    and upon return, the user's provided key does not work, because LEO has
>    tested some password; user complains that LEO has destroyed the data.)

See above and add to it that you may have trouble for "destroying 
evidence" by an "elecronic booby-trap". 
 
>  * A self-destruct feature is not unique, and exists in other modern
>    devices: e.g.  the iPhone's self-destruct on failed lock

These are not reliable and well-known to law-enforcement.

>  * Users have a free choice whether to create a self-destruct/nuke/erase
>    key or not.  Choice is important.

Experts have a duty not to give dangerous tools to amateurs. 
Amateurs are likely to shoot themselves in the foot. Often
repeatedly. This is not a technological problem, hence a 
responsible expert will not implement technological "snake oil"
that may look like a "solution" to an ordinary user but is not.
 
>  * Law enforcement may demand all passwords.  It would be an omission to
>    fail to provide them with passwords for the good and the bad key slots
>    ;) (rather cheeky, but it's a choice)

See above. 

> 
> > Please also note that Kali Linux already implemented the nuke feature
> > into their distribution:
> > http://www.kali.org/how-to/emergency-self-destruction-luks-kali/
> > http://www.kali.org/how-to/nuke-kali-linux-luks/
> I like!  I'll look out for the patch for my favourite distribution.

Have fun. But be aware that you do not get what you think you get.
And please complain to them when you get out of prison, not to us.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] LUKS self-destruct key

[Andrew]

On Mon, 31 Mar 2014 15:06:12 +0200
Arno Wagner <arno@wagner.name> wrote:

> Ok, I will repeat some of the same old things that apparently 
> have to be said time and again when somebody has this 
> not-so-bright idea.
Not really ok.  You were already very vocal in the thread which someone else had the courtesy to point out.  As you state, you have said these same old things already, generally without actually engaging the actual argument.  Although your point is interesting, it is the answer to a different question.  While you are apparently at liberty to repeat yourself time and again, this does not lend force to your statements.  

In the absence of bright ideas, no-so-bright simple stupid and practical hacks really do carry the day.  

> On Mon, Mar 31, 2014 at 14:19:29 CEST, Andrew wrote:
> [...]
> > I read the thread -- interesting reading (Gmane seems a little off
> > for me at the moment though.)
> > 
> > A few points that were not raised directly by anyone are:
> > 
> >  * Some of the worst attackers *do* lack technical skills.  While
> > various interest groups do have technical experts, less skilled
> > persons may try their hand first, and succeed in destroying the
> > evidence.  Terrorism has lately tended towards a cell structure.  A
> > particular cell may not have access to adequate technical
> > resources, while not lacking "skills" like kidnapping, robbery and
> > torture of those they target.
> 
> Even the dumbest attackers have seen the movies where the magic
> computer destroys all data when the wrong password is entered.
This is not true.
> 
> And when you come to any writing about compouter forensics,
> the first rule is always to never work on originals. 
This is not relevant.
>  
> >  * An attacker may guess the wipe/kill/nuke/erase password without
> > any intervention by the user (at last - a use for post-it notes!)
> > Users' passwords may well be inadequate, despite all advice to the
> > contrary. Having an even-more-inadequate nuke/self-destruct/erase
> > password may frustrate an attacker.
> 
> See above.
Don't see.
> 
> >  * If it is possible for the key to be destroyed without the user's
> >    intervention, then it becomes plausible that there is nothing to
> > be gained by asking for a password.  (e.g.  LEO removes device from
> > user, and upon return, the user's provided key does not work,
> > because LEO has tested some password; user complains that LEO has
> > destroyed the data.)
> 
> See above and add to it that you may have trouble for "destroying 
> evidence" by an "elecronic booby-trap". 
Still don't see, and what if this trouble is 
>  
> >  * A self-destruct feature is not unique, and exists in other modern
> >    devices: e.g.  the iPhone's self-destruct on failed lock
> 
> These are not reliable and well-known to law-enforcement.
> 
> >  * Users have a free choice whether to create a
> > self-destruct/nuke/erase key or not.  Choice is important.
> 
> Experts have a duty not to give dangerous tools to amateurs. 
> Amateurs are likely to shoot themselves in the foot. Often
> repeatedly. This is not a technological problem, hence a 
> responsible expert will not implement technological "snake oil"
> that may look like a "solution" to an ordinary user but is not.
>  
> >  * Law enforcement may demand all passwords.  It would be an
> > omission to fail to provide them with passwords for the good and
> > the bad key slots ;) (rather cheeky, but it's a choice)
> 
> See above. 
Still don't see.
> 
> > 
> > > Please also note that Kali Linux already implemented the nuke
> > > feature into their distribution:
> > > http://www.kali.org/how-to/emergency-self-destruction-luks-kali/
> > > http://www.kali.org/how-to/nuke-kali-linux-luks/
> > I like!  I'll look out for the patch for my favourite distribution.
> 
> Have fun. But be aware that you do not get what you think you get.
> And please complain to them when you get out of prison, not to us.
I'll be dead, not complaining, so don't worry.
> 
> Arno
> -- 
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email:
> arno@wagner.name GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF
> B774 E35C 5FA1 CB5D 9718 ----
> A good decision is based on knowledge and not on numbers. -  Plato
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Click here to receive this message as an unsolicited e-mail

Re: [dm-crypt] LUKS self-destruct key

[Heiko Rosemann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/31/2014 10:17 PM, Andrew wrote:
> On Mon, 31 Mar 2014 15:06:12 +0200 Arno Wagner <arno@wagner.name>
> wrote:
>> On Mon, Mar 31, 2014 at 14:19:29 CEST, Andrew wrote: [...]
>>> I read the thread -- interesting reading (Gmane seems a little
>>> off for me at the moment though.)
>>> 
>>> A few points that were not raised directly by anyone are:
>>> 
>>> * Some of the worst attackers *do* lack technical skills.
>>> While various interest groups do have technical experts, less
>>> skilled persons may try their hand first, and succeed in
>>> destroying the evidence.  Terrorism has lately tended towards a
>>> cell structure.  A particular cell may not have access to
>>> adequate technical resources, while not lacking "skills" like
>>> kidnapping, robbery and torture of those they target.
>> 
>> Even the dumbest attackers have seen the movies where the magic 
>> computer destroys all data when the wrong password is entered.
> This is not true.

Well, the number of attackers which is knowledgeable enough to detect
a luks device and figure out that they need a password to open it (or
stupid enough to just type a password at an unknown prompt), but not
knowledgeable enough to make a backup before trying is probably
insignificant, I'm even leaning towards zero.

>> And when you come to any writing about compouter forensics, the
>> first rule is always to never work on originals.
> This is not relevant.

Yes it is. Because it's not only in any writing but also common sense.

If the attacker works on a backup and still has the original,
destroying the backup does not help anybody. This is what renders all
your further points moot.

I can see exactly one use case for a "destroy password" and that has
been discussed in the thread mentioned above and all the neccessary
tools have been implemented in the form of the luksErase command. In
short: The data is more valuable than your life _and_ you have a few
seconds of time on your computer _before_ the attacker takes control
over it. You could implement it in such a way as the machine looks for
a key on a USB stick and if none is found, runs luksErase instead of
luksOpen, or by booting from a USB stick with a working system but
when booting from the HDD (when the USB stick is missing) it runs
luksErase.

Best Regards,
Heiko

- -- 
eMails verschlüsseln mit PGP - privacy is your right!
Mein PGP-Key zur Verifizierung: http://pgp.mit.edu

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlM51UAACgkQ/Vb5NagElAVcvACbByshRHJm5r1GqO1zen0vx9t3
8HkAnRJAhxXrLru6JuKbuVkjDK8RrgD6
=jspl
-----END PGP SIGNATURE-----