From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYBdWKMsBWhM for ; Thu, 16 Jan 2014 14:10:00 +0100 (CET) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Thu, 16 Jan 2014 14:10:00 +0100 (CET) Received: by mail-ea0-f175.google.com with SMTP id z10so1116321ead.6 for ; Thu, 16 Jan 2014 05:09:56 -0800 (PST) Received: from [134.34.218.248] (wl-2808.wlan.uni-konstanz.de. [134.34.218.248]) by mx.google.com with ESMTPSA id h3sm17976495eem.15.2014.01.16.05.09.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Jan 2014 05:09:55 -0800 (PST) Message-ID: <52D7DA1D.2070309@gmail.com> Date: Thu, 16 Jan 2014 14:09:49 +0100 From: Florian Junghanns MIME-Version: 1.0 References: <638F1A81-8F17-4E18-8993-7F848EA84F08@offensive-security.com> <20140114043042.GA15870@tansi.org> <52D6EF1B.4020206@gmail.com> <52D7AB5E.8020302@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] nuke password to delete luks header List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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 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