[dm-crypt] nuke password to delete luks header
thom at codehawks.eu
Fri Jan 17 09:17:15 CET 2014
On 16 January 2014 22:49, Claudio Moretti <flyingstar16 at gmail.com> wrote:
> While it's actually not a "command", that a person is typing, but just a
> password, a question comes to mind:
> Once you get to the password prompt, it's clear you have an encrypted
> disk. So, unless you're really, really, really in trouble you'd never use
> the "wipe" password.
> Three cases come to mind:
> 1) you have something really, really illegal on your HD and you get
> stopped at a security checkpoint. In this case, (a) you're an idiot who
> took that kind of stuff on a laptop instead of having a clean laptop and
> retrieving it via a secure connection and (b) even if you wipe your hard
> drive you're in big trouble, because they'll know you did it.
> 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.
> 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.
> 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.
> 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" 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dm-crypt