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

[Florian Junghanns <florian.junghanns@gmail.com>]

On 01/16/2014 11:30 AM, Thomas Bastiani wrote:
> Hi guys,
>
> I've been following this discussion for a few days. And I feel like giving
> my opinion... :-)

Hello everyone,

I'm feeling the same way as Thomas does. Please see below for my 
explanation and proposal.

>
> On 16 January 2014 09:50, Ondrej Kozina <okozina@redhat.com> wrote:
>
>> On 01/15/2014 09:27 PM, Milan Broz 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.
>>>
>>
> I would argue that it's really independent from any actual crypto logic.
> The only thing that need's to be done is wrap the password/key prompt and
> check the password against a known salted hash or PBKDF (same as all Linux
> distros do). Then "nuking" the container is actually quite simple. Just
> erase the LUKS header by zeroing it. This is not any more complex than what
> distros already have to do to support root-on-LUKS.
>
> Actually this functionality is simple enough that anyone actually wanting
> it can just write their own password prompt wrapper script.
>
> I would point out that this doesn't require any more information from LUKS
> internals than mouting a block device from /etc/crypttab would. And so it's
> entirely possible to keep the code layered and simple. KISS applies.
>
> Moreover, I think it's wrong to assume that distros don't share any of
> their code. Proof is, they fork each other. It wouldn't have to be
> implemented a dozen times.
>

It is my opinion as well that this should be solved by external wrappers 
of the Linux distribution used. Also, I do not see how this is a 
different area than e.g. caching the passphrase for mounting multiple 
encrypted volumes on boot, a functionality that is provided e.g. by the 
Debian distribution (not by dm-crypt). The functionality to make the 
LUKS header unusable is provided by the 'dd' command with correct 
parameters. IFF you want to provide the functionality of making the LUKS 
header unusable via dm-crypt, I believe the *addition of a 'force' flag 
to luksHeaderRestore* in order to enable a file that is not a LUKS 
header backup file to be used as source is more sensible, e.g. 
*'cryptsetup luksHeaderRestore /dev/sda1 -f 
--header-backup-file=/dev/zero'*. This is a clear maintenance operation 
which is - in my opinion - a saner solution than adding this very 
unusual 'nuke' functionality. If you're still going to implement it, I 
strongly feel it should be called something like 'destroy' instead of 
'nuke'. Even better would be 'overwrite' or 'disable', since - as 
discussed before - on e.g. SSD drives this does not necessarily 'nuke' 
the header rather than 'displace'/'unlink' it from the former position 
in the block register.

As already indicated above, I feel that this is a maintenance operation. 
Without putting yourself in danger, there are two use cases when you 
will want to 'nuke' your header. The one is before you depart from your 
original location. Then you have your device booted and can use the 
normal system tools ('dd', or - if the -f flag is implemented - 
luksHeaderRestore) to disable the LUKS header. The other situation is 
that you are short on time and cannot manage to boot your device without 
e.g. missing your flight. In that case, you need the option to disable 
the header without actually booting the device. This however is not the 
core functionality and responsibility of dm-crypt but rather of the 
distribution in use which can do this with a wrapper script just like 
Debian does already for caching passphrases.
Any other use case I can think of is - as discussed to some extent in 
the last few days - either stupid or heavily endangering yourself or 
both. It is not the task of dm-crypt to enable people to do such things.

Best regards,
   Florian