[dm-crypt] nuke password to delete luks header

Claudio Moretti flyingstar16 at gmail.com
Sat Jan 18 00:18:27 CET 2014

On Fri, Jan 17, 2014 at 8:17 AM, Thomas Bastiani <thom at codehawks.eu> wrote:

> On 16 January 2014 22:49, Claudio Moretti <flyingstar16 at gmail.com> wrote:
>>  2) Your life is in danger and somebody wants something from your
>> laptop: what do you think will happen then, if you wipe your key?
> I believe Iggy made a point earlier:
> " [...] not everyone values their physical well-being over the compromise
> of their data."
> Which is a surprisingly (to me) valid point. There might be cases where
> someone might actually want to protect something at the cost of their life.

I hadn't thought about that, but now that you mention it I've given it a
little thought and I agree. Suppose you're a police officer, you're
carrying an encrypted laptop with thousands of names of people in a witness
protection program, and you're captured by the mob.

Without diving into further examples concerning the safety of the people
someone holds most dear, I believe this is the perfect example.

>> The only real time you're going to need such functionality is if you have
>> data on your computer, you know someone's coming and your computer is
>> turned _off_: you have very little time, so you just boot, type in the wipe
>> password and unplug.
> The way I use LUKS is that I've got a passworded rsa certificate that I
> use to encrypt my key. Both files (encrypted LUKS key and passworded
> certificate) are then stored on my boot partition on a USB dongle in my
> pocket. If I wanted to prevent someone from accessing my LUKS partition(s),
> I'd simply wipe those files. Or, worst case, repeatedly smash the dongle
> with a hammer. The point is that I can't give access to my LUKS protected
> data anymore, which is the point of  the "nuke" feature. My point here is
> that if you use a key instead of a password, and thus can't give access to
> the required data from memory, it's easy enough to delete the key. Also,
> erasing a file from a FAT formatted USB dongle should be more secure than
> erasing the header from an SSD. I might be wrong but I believe that current
> USB keys don't have fancy wear-leveling and storage overprovision that
> modern SSDs do.

That's not how I do it, but only because I'm lazy and tend to forget
everything, everywhere.
Also, I have a friend who does that, and I clearly remember about the time
he forgot his USB key home :P

But, anyway, that's the best way to do it: there's no header, no nothing on
the drive that might give away the fact that you have an encrypted

Even though "You can't prove that you don't have a separate header backup."

>> In this case, though, it's not enough wiping the keyslots: you'd have to
>> wipe the entire header, because otherwise the only thing that "someone"
>> will see is you not giving them the correct password.
> You can't prove that you don't have a separate header backup.

You're right, but remember that when someone tries to turn on your wiped
computer, the computer will give a "disk error/no boot partition
available/root partition not found/etc." error. You can claim ignorance ;)
Also, forensic analysis will be useless, because there's nothing to be
found, whereas if they're able to "dd" your disk, they can try as many
times as they want, and if a judge orders you to surrender the password (I
don't know if it's legal in some countries, I'm just saying) if you just
wiped the keyslots you can't actually prove it: the only thing anyone will
see will be "there is no key available with this passphrase"; and if you
actually tell them "I have wiped my LUKS slots before you showed up", they
can say "we don't believe you", and you have no way of proving you're not
lying :/

>> As tool-makers we have a responsibility to balance functionality
>>> and risks as we understand the tool better than most of the users.
>>> Of course, the user may understand the situation he finds himself
>>> in better than we do (or not), but that is why it is a balance.
>>> Neither "deny everything even a bit riksy" nor "allow everything"
>>> is morally right for a tool that is mainly used by non-experts.
>> I believe that the best course of action in this case would be to
>> implement it as "highly experimental not guaranteed[1]" with a (or a couple
>> of) compile flag, but at least we can give the users a choice. And, with a
>> compile flag, very few people are going to be able to put that in place.
> What if the <insert popular user-friendly distro name> package maintainer
> decides it's a cool feature?

I actually thought about this, before adding that paragraph, but IMHO it's
not our concern. If the functionality ever gets added, how long will it
take to be able to find DEBs and RPMs in various personal repos, that have
the functionality enabled? IMHO a really short time. It's not only a
maintainer issue.

Nevertheless, I believe it should be the user's choice. Anyone can achieve
similar results with a
# dd if=/dev/urandom of=/dev/sda
so maybe yeah, my "sudo EMERGENCY" idea could do that instead, but with the
header wipe we won't touch the actual data so if you do have a hedaer

It's a really tricky topic, and everyone's opinion is slightly different;
that's one of the reasons I believe it should be the user who decides.
There is no way of warning users about the possible legal/real implications
of this (aside from data loss) and I expect somebody someday to come in
here and say "hey, my cat was on my keyboard and typed 'sudo cryptsetup
luksWipe /dev/sda'! How do I get my data back?", but I also believe that
people who have to really protect themselves already have a custom made
patched version of cryptsetup that does that...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20140117/5221a65f/attachment.html>

More information about the dm-crypt mailing list