[dm-crypt] nuke password to delete luks header

Jonas Meurer jonas at freesources.org
Mon Jan 27 10:04:28 CET 2014


Am 2014-01-23 22:26, schrieb Milan Broz:
> On 01/21/2014 11:40 PM, Jonas wrote:
>>> But what I really want to avoid is that every distribution will
>>> add some random patches implementing something like this.
>>> 
>>> It is perhaps better to implement and document this upstream.
>> 
>> Milan, have you made your decision yet, whether you add the nuke 
>> feature
>> to libcryptsetup (and cryptsetup util)?
> 
> Hi,
> 
> as Arno said, let's split this to two parts.
> 
>> 1. Have a secure erase that is easy to use. [...]
>> 
>> 2. Have the option of unlocking a keyslot created with a specific
>>   option to trigger the function implemented in 1. [...]
> 
> For 1, I think we can introduce new CLI command "erase" (with alias 
> luksErase)
> which will remove all keyslots (in fact it is equivalent of 
> luksKillSlot called
> for all active slots).
> In libcryptsetup API it can be extension of existing
> crypt_keyslot_destroy() call.
> 
> (It can be easily parameter to luksKillSlot but special command is easy
> to understand and remember. Moreover, for some possible formats the 
> keyslot
> in command name can be confusing - think TrueCrypt)
> 
> (And it should work for future other FDE formats as well. The main use 
> case
> is that it removes master key from device but not ciphertext data 
> itself.)
> 
> This is not controversial and it is easy to use. Also it can be used in 
> distro
> wrappers around cryptsetup. (I can imagine special emergency user login 
> which
> will erase header. IMHO much better solution than 2.)

Great, sounds like a good plan.

> For 2, (aka self destroy passphrase) - I tried to read the discussion 
> again
> and I am really not convinced yet we want it.

Do you intend to protect the erase feature by asking for a password? In 
that
case it will be hard to build a nuke wrapper around 'cryptsetup erase'.
Especially if the nuke password should not reveal access to encrypted 
data
and merely allow to erase LUKS header.

> BTW original patch is INCOMPLETE and DANGEROUS.
> 
> (For example, did anyone think about cryptsetup-reencrypt? Guess what 
> will
> happen if user try to *reencrypt* device with this destroy passphrase?
> Try it... or better not ;-) And there are more missing code which just
> do not convince me that it was properly thought-out work.

Isn't that a good argument for implementing it properly upstream? ;)

> I think there is only negligible set of users who really have use for 
> nuke pwd
> (I do not count "toy" cases.) Note the is already way to do it outside
> of cryptsetup.


> (BTW reencryption (regular key change) is way more better to increase
> security - even
> if anyone have old header backups, it makes these backups unusable.
> And I still have very few reports of cryptsetup-reencrypt success 
> stories.
> I would like remove experimental warning one day.
> ... While the list is full of nuke passwords mails...

While I see your argument, reencryption takes a lot more time than using 
a
nuke feature. Both features serve completely different purposes.

And if you merely want to destroy access to the data, overwriting it is 
still
better than reencrypting, isn't it?

Kind regards,
  jonas



More information about the dm-crypt mailing list