A Self-Destruct Option For Linux Disk Encryption

[Ericg]

The article specifically says that the password is "nuke". Has anyone even read it? What a bunch of 1st grade kids.

Pay more attention. The quotes are not used in the means of "this is a literal string, which contents are "nuke"", but as "this is a metaphor of what it does, it doesn't literally nukes your hard drive, it does metaphorically "nukes" the contents". Proof: first time the word "nuke" appears in quotes, it says it's "a" nuke password. Why would Michael say "a" if there aren't SEVERAL possible ones?

Birdie, i'm just taking a shot in the dark here but... I'm gonna guess that english is NOT your first language, correct? Because that contextual mistake is not one that a native speaker should really make..

[rohcQaH]

So you all just read michael's rewording and put undue emphasis on minor grammatical points, instead of clicking through to the original announcement and getting your information from there?
I'd say you all failed reading comprehension then.

There's a direct setup guide in there!

root@kali:~# cryptsetup luksAddNuke /dev/sda5
Enter any existing passphrase: (existing passphrase)
Enter new passphrase for key slot: (nuke passphrase)

Hey look, you're supposed to enter the passphrase you want to use!

[mrugiero]

So you all just read michael's rewording and put undue emphasis on minor grammatical points, instead of clicking through to the original announcement and getting your information from there?
I'd say you all failed reading comprehension then.

Actually, I'd rather say you are wrong. That's what journalism is for, so you don't have to research any deeper to generically know there is something out there. I'm not interested in the inner workings of this, as I do not use any form of encryption. Only thing I found interesting was this particular feature, so I read the article. I'd access the cited source if I'd have any question the article fails to answer, but I haven't any, and the issue the other poster had was perfectly answered by reading a bit more carefully the original article.

[nils_]

This is a good idea. What I'd also like to have is a password that opens another region of the devices (like a subpartition). That way you could enter one password and innocuous data shows up and another for the real thing.

[Luke]

This gives a fast destroy option for non-hacker users

Phoronix: A Self-Destruct Option For Linux Disk Encryption

The security-minded Kali Linux distribution has proposed a feature of adding "emergency self-destruction of LUKS" to their cryptsetup package when doing full-disk encrypted Linux installations...

http://www.phoronix.com/vr.php?view=MTU2MjQ

This sort of thing could save someone from going to jail for 18 months for refusing to give a passphrase to a grand jury, especially if they used it as the raid arrived. Of course, if you are alone and intend to defend your castle, you won't have time to interact with the computer except maybe to pull disks from external hotswap drawers and smash them. Things get very busy very fast in raids, whether you surrender or fight. I've been in enough building stormings by Occupy et all to know that if a first floor computer at the security desk were the target, we would have been able to secure it before anything could be done to it. On the other hand, in a larger building like an office tower a warning from the first floor would give plenty of time to run a destruction passphrase. An opposed stair climb does not go fast, and elevators can be stopped.

For some (most recent) disks a "security erase enhanced" could be initiated from the OS while running, and even a single second of that would kill the LUKS header of a freestanding /home disk. A daytime raid would often find computers running, so a boot destroy passphrase should also be set up to be usable from the running OS, just as hdparm --security-erase-enhanced or LuksKillSlot are by themselves. A dedicated IT guy could easily destroy data while others fight to keep the raid team off him-unless the power is cut first.

Don't rely on being able to destory data, use strong passphrases that your enemy cannot brute force. Five words that do not form a phrase found in any book or your writing is said to require "nation-state" level resources to crack, so use more than that.

[Luke]

Forensic agencies ALREADY use only disk images

What's it to be used for? If someone is telling you to put your password in so they can get at your files, or maybe several nuke passwords for someone to accidentally find when trying to decrypt a drive.
Once people figure out this feature exists, the new standard operating procedure for this kind of thing will be "mirror the drive first."

The pigs would not attempt to boot your machine, they would make many images of the disk, this has been standard operating procedure for YEARS as the original is considered "evidence" too valuble to risk even flipping a single bit. A CHANGED filesystem raises questions with jurors the presecutors don't like. To use a self-destruct, you must be able to use it yourself. I see one place you might be given the opportunity: at the airport.

You should NEVER carry computer equipment over US borders as it is subject to search, data smuggling should be done with LOCALLY encrypted file containers moved over the network. If you must use a laptop, TSA and CBP goons are not forensic computer specialists and will try to order you to boot the machine. A honeypot OS will usually be enough to fool them-but combining this with a destroy password on the real one is a lot of extra protection.

Finally, if CBP gets burned this way a few times, they will be forced to stop stealing laptops when passphrases are refused (as they should always be) and switch to making a disk image they can attempt to crack later. If they simply steal every encrypted laptop they will make too many corporate enemies. As for me, I refuse to use legal US border crossings or any form of transit that searches luggage at all as I refuse to consent to searches.

[nslay]

Depends on the situation, there was one story on /. about a guy being forced to give up the encryption key to his laptop. Give up the nuke password then say that they must've damaged the hard drive in transit, or that the drive must be suffering from corruption. Or have the nuke password be something one letter off from the real password (like a strange letter, z instead of s maybe) then when they enter it and blame you just say they heard you incorrectly.

Really depends on if maybe you're a reporter and the data on your drive could get someone else killed or start a war or something extreme like that

Or plug in a USB key with a boot loader or kernel with the nuke password feature disabled? Feature aside, why would you even trust to boot the user's configuration in the first place?

This feature is especially useless if it's widely known about. It becomes an expected tactic by anyone wishing to break into your system.

[tga.d]

I get the impression that a lot of people don't understand what's going on here. This code doesn't literally go through and wipe a hard drive. Instead, it finds all LUKS keyslots and wipes those.

You see, when you encrypt your drive using LUKS, your passphrase actually isn't used to encrypt the disk at all. Instead, your passphrase is used to encrypt a container that the real key is stored in. This allows you to do things like change your passphrase without reencrypting the entire disk, or rendering a disk unreadable by deleting where the real key is stored. This code combines these two things. This makes it theoretically useful for "wiping" your hard drive without having to write to the whole disk.

However, this DOES NOT WORK if there is wear-leveling used, as is the case for pretty much every SSD. If wear-leveling is enabled, this will simply make it look like the LUKS header was destroyed, when in fact it's just the drive reporting to the OS that it was, while in reality it simply wrote the data intended to overwrite it to someplace else. Any adversary capable of any physical analysis (e.g. any moderately sized government) would be able to examine the whole drive and see the original LUKS header this code thinks it wiped, and then use any cryptanalysis attack that they would have used if the nuke password hadn't been entered.

[mrugiero]

I get the impression that a lot of people don't understand what's going on here. This code doesn't literally go through and wipe a hard drive. Instead, it finds all LUKS keyslots and wipes those.

You see, when you encrypt your drive using LUKS, your passphrase actually isn't used to encrypt the disk at all. Instead, your passphrase is used to encrypt a container that the real key is stored in. This allows you to do things like change your passphrase without reencrypting the entire disk, or rendering a disk unreadable by deleting where the real key is stored. This code combines these two things. This makes it theoretically useful for "wiping" your hard drive without having to write to the whole disk.

However, this DOES NOT WORK if there is wear-leveling used, as is the case for pretty much every SSD. If wear-leveling is enabled, this will simply make it look like the LUKS header was destroyed, when in fact it's just the drive reporting to the OS that it was, while in reality it simply wrote the data intended to overwrite it to someplace else. Any adversary capable of any physical analysis (e.g. any moderately sized government) would be able to examine the whole drive and see the original LUKS header this code thinks it wiped, and then use any cryptanalysis attack that they would have used if the nuke password hadn't been entered.

I think we all understood this, but the practical effect is what most people care about, and the practical effect is the same as wiping out the disk: your data becomes unaccessible. Although I personally thought it worked more like a private-public key pair, with the "public" (not really public, here) key being in the key nodes (was that their name? I don't really want to check), and the data actually being encrypted using both. Now that I think of it, it doesn't make sense, as usually that's not how those pairs work, IIRC. I'm not sure, I skimmed through the generics of how that works once, but anyway.
I didn't know the SSD bit, though.

[Luke]

SSD's not good for encrypted data, OK for OS

I get the impression that a lot of people don't understand what's going on here. This code doesn't literally go through and wipe a hard drive. Instead, it finds all LUKS keyslots and wipes those.

You see, when you encrypt your drive using LUKS, your passphrase actually isn't used to encrypt the disk at all. Instead, your passphrase is used to encrypt a container that the real key is stored in. This allows you to do things like change your passphrase without reencrypting the entire disk, or rendering a disk unreadable by deleting where the real key is stored. This code combines these two things. This makes it theoretically useful for "wiping" your hard drive without having to write to the whole disk.

However, this DOES NOT WORK if there is wear-leveling used, as is the case for pretty much every SSD. If wear-leveling is enabled, this will simply make it look like the LUKS header was destroyed, when in fact it's just the drive reporting to the OS that it was, while in reality it simply wrote the data intended to overwrite it to someplace else. Any adversary capable of any physical analysis (e.g. any moderately sized government) would be able to examine the whole drive and see the original LUKS header this code thinks it wiped, and then use any cryptanalysis attack that they would have used if the nuke password hadn't been entered.

If this happened on the machine I am using right now, the attacker would get only into the boot drive, which contains the OS. The data volume (/home) is on a pair of HDDs and they would be permanently unreadable after a LUKS header wipe. If the header were to be split between the two drives than killing that part of either drive would kill the filesystem for good. That being so, it's also important to backup data on LUKS encrypted volumes to another LUKS or otherwise encrypted volume, as the sector your LUKS header is in can and sometimes does go bad!

The only reason I encrypt SSD OS volumes at all is to narrow the target area for a keylogger attack to /boot and the BIOS, both of which are very small, plus the (obvious) hardware keylogger that pretends to be a USB adapter and gets caught. SSD's should not be used for secure data unless it is acceptable not to be able to erase the data and/or a plain mapping is used with a long interation at password-derived key generation. For the same reason, if a key must be revoked, an SSD drive volume should be remade from scratch so as to kill the usefulness of any recovered key.

For a laptop, a control to feed the full +12V to an SSD's memory cells with a combination of keys would be the best emergency kill switch.