On Fri, Jan 17, 2014 at 8:17 AM, Thomas Bastiani <thom@xxxxxxxxxxxx> wrote:
On 16 January 2014 22:49, Claudio Moretti <flyingstar16@xxxxxxxxx> 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
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 partition.
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
# 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 backup...
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...
Claudio
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
