Developers mull adding data nuke to Kali Linux

Developers mull adding data nuke to Kali Linux

Summary: Security experts using Kali Linux may soon have a last resort to destroy their encrypted data by typing in a special passphrase that will wipe the keys.


The developers behind penetration testing and security auditing suite Kali Linux are considering creating a "nuke" password that would allow information security professionals to render data unreadable if needed.

Kali Linux is an open-source operating system based on the popular BackTrack Linux suite, but backed and funded by Offensive Security. It can be set up to use full-disk encryption using a combination of Logical Volume Management (LVM) and Linux Unified Key Setup (LUKS).

When creating an encrypted LUKS container, a master key is generated at random. A passphrase is then used to encrypt the master key in turn.

This process means that the passphrase is not directly coupled to the data. That is, if two sets of identical data are encrypted and the same passphrase used, the master keys remain unique to each set and cannot be swapped out.

What this also means, however, is that regardless of the passphrase used, if the master key is lost, recovering data is impossible. This process conveniently lends itself to being used as a nuke by deliberately wiping the keys.

Offensive Security founder and Kali Linux lead developer Mati Aharoni is currently testing a modification to the operating system that will effectively nuke the master keys if a specific passphrase is used. It is based on a patch developed by Juergen Pabel in 2008.

"On any subsequent reboots, you will be asked for the LUKS decryption password each time as usual. If, for whatever reason, you were to enter the nuke password, the saved keys would be purged, rendering the data inaccessible," Aharoni wrote on the blog for the operating system.

Although confirmed as working, the base images for Kali do not yet include the new feature, as the community is still being polled for whether the nuke feature should be added.

While this would provide an easy method of destroying keys in an emergency, such a feature would not defend against an attacker that had the foresight to create a disk image before attempting to enter the password. It could also leave victims in rather precarious circumstances should an attacker decide to use rubber hose cryptanalysis.

Topics: Security, Linux, Open Source

Michael Lee

About Michael Lee

A Sydney, Australia-based journalist, Michael Lee covers a gamut of news in the technology space including information security, state Government initiatives, and local startups.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • What's really needed is an alternate key/password system.

    Yes, someone hacking into a system without physical access may have problems. But, for instance, the first thing forensic software does is lock write-lock the disk. Then the entire disk is imaged. At that point, nothing the system does to prevent decryption of the original disk is useful.

    What is needed is a *real* password/key and a *fake* key. The difference is that if the fake key is entered it *will* produce *real* decoy data. So it *looks* like the encryption has been broken. But simultaneously, entering the fake key will permanently prevent access to the real data.
    • TrueCrypt does this, for a whole decoy OS install
  • This is a great time to mention . . .

    . . . cloud computing.

    We with the FSF call cloud computing "careless" computing. At the minimum careless computing needs to be able to have encrypted data. In other words, the keys (real and fake) need to be tied to the local machine and the data in the cloud need to be encrypted. If the user does not have the "real" machine with real keys the cloud data is useless.