Tranding Now!

Emergency Self Destruction of LUKS in Kali Linux

Emergency Self Destruction of LUKS in Kali

Emergency Self Destruction of LUKS in Kali

Kali Linux Full Disk Encryption 

As penetration testers, we often need to travel with sensitive data stored on our laptops. Of course, we use full disk encryption wherever possible, including our Kali Linux machines, which tend to contain the most sensitive materials.
Setting up full disk encryption with Kali linux is a simple process. The Kali linux installer includes a straightforward process for setting up encrypted partitions with LVM and LUKS. Once encrypted, the Kali linux operating system requires a password at boot time to allow the OS to boot and decrypt your drive, thus protecting this data in case your laptop is stolen. Managing decryption keys and partitions is done using the cryptsetup utility.

Nuking our Kali Linux FDE Installation

A couple of days ago, one of us had the idea of adding a “nuke” option to our Kali linux install. In other words, having a boot password that would destroy, rather than decrypt, the data on our drive. A few Google searches later, we found an old cryptsetup patch by Juergen Pabel which does just that, adding a “nuke” password to cryptsetup, which when used, deletes all keyslots and makes the data on the drive inaccessible. We ported this patch for a recent version of cryptsetup and posted it on Github.

Testing the LUKS Nuke Patch

This feature isn’t implemented yet in Kali linux as we wanted to gather some user feedback before applying this patch to base images. If you’d like to try it our yourself, these are the build instructions. Start by running an LVM encrypted installation in Kali linux and set a decryption password. Once done, download the cryptsetup package source and apply our patch to it. Proceed to build the patched package as follows:
root@kali:~# apt-get source cryptsetup
root@kali:~# git clone
root@kali:~# cd cryptsetup-1.6.1/
root@kali:~/cryptsetup-1.6.1# patch -p1 < ../cryptsetup-nuke-keys/cryptsetup_1.6.1+nuke_keys.diff
patching file lib/libcryptsetup.h
patching file lib/luks1/keymanage.c
patching file lib/setup.c
patching file src/cryptsetup.c
root@kali:~/cryptsetup-1.6.1# dpkg-buildpackage -b -uc
Once the package has built, install the cryptsetup packages to get our nuke option implemented:
root@kali:~/cryptsetup-1.6.1# ls -l ../*crypt*.deb
-rw-r--r-- 1 root root 149430 Jan 4 21:34 ../cryptsetup_1.6.1-1kali0_amd64.deb
-rw-r--r-- 1 root root 250616 Jan 4 21:34 ../cryptsetup-bin_1.6.1-1kali0_amd64.deb
-rw-r--r-- 1 root root 105226 Jan 4 21:34 ../libcryptsetup4_1.6.1-1kali0_amd64.deb
-rw-r--r-- 1 root root 49580 Jan 4 21:34 ../libcryptsetup-dev_1.6.1-1kali0_amd64.deb
root@kali:~/cryptsetup-1.6.1# dpkg -i ../libcryptsetup*.deb
root@kali:~/cryptsetup-1.6.1# dpkg -i ../cryptsetup*.deb
Now that our patched cryptsetup package has been installed, we can go ahead and add a “nuke” key to our setup:
root@kali:~# cryptsetup luksAddNuke /dev/sda5
Enter any existing passphrase: (existing passphrase)
Enter new passphrase for key slot: (nuke passphrase)

Hey Dude, Where’s my Drive?

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. Should we implement this patch in the cryptsetup package? Let us know what you think via this quick poll. We’ll keep this poll open for a couple of weeks and keep you posted with any further developments of this feature.

No comments

'; (function() { var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true; dsq.src = '//' + disqus_shortname + ''; (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq); })();