On 16 January 2014 22:49, Claudio Moretti <flyingstar16@xxxxxxxxx> 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.
Agreed.
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[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?
--
Thomas Bastiani
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
