cryptomnesia

Linux deniable cryptographic storage eraser based on hardware USB trigger for self-destruction in a case of emergency

(hard to find an acronym for that one huh?)

Quick demo:

Dependencies:

• LUKS - Linux Unified Key Setup, widely used nowadays for disk encryption
  • cryptsetup - its main CLI, works both for version 1 and 2
• DigiSpark - a cheap piece of hardware for USB simulation, used as a trigger
  • Arduino IDE and AVRDUDE - used to upload the code
  • AVR ISP programmer with SOIC8 clips and micronucleus, plus some jumper wires - optional, allows firmware reprogramming to achieve significantly faster USB detection
• root shell - the whole script with some basic commands (dd, fdisk, df, sync, lsusb, update-grub)

Intro and Insights

OK, I think that everyone felt a little pressure from government in the beginning of 2020 for obvious reasons. Now, I'm not saying that cyberpunk dystopia is right here (even if I think so), but that we have to be ready for it. You might say "no worries dude, I'm a 1337 h4x0r, I use full disk crypto and staff, my data is 144% safe" and you will be right... almost. You see, although, disk encryption protects your data from theft and the password may be difficult to crack, you're still human that can gently give the key if asked "nicely". And I'm not just speaking about rubber-hose cryptanalysis, but there are actual laws that force you to give the key (or any decryption meaning) if needed in almost any "civilized" country (unless they are busy stealing toilet paper or face masks from each other).

Self-destruction as a last resort

So, what can you do in a scenario where SWAT or Russian mafia breaks into your door? Well, you will probably will not have enough time to run "rm" or "dd" command (considering the fact that some deleted data can still be recovered) and just powering off the PC will still leave you as a key/password holder. You can always destroy the PC or the disk itself (or even a dedicated device to encrypt or/and hold keys), but you can't be sure that the damage will be sufficient (unless you use EMP or something). Of course, if you're using deniable encryption or steganographic storage already, then you just swaped one problem for another, but I won't talk about those solutions since they are quite separate topics. Thus, the poor-man's solution is just to soft self-destruct, to erase the keys, to make the encrypted storage undecryptable and unreadable even by your-self, once and for all, irreversibly. Sounds pretty scary and challenging, I know, but let's look at technical details right now.

(yeah, that was kind of a rant blog, but anyway)

Full Disk Encryption?

Basically, when a PC is powered up, the BIOS will check if everything is OK and if there is a disk to boot. If it's the case it will search for a bootable code that contains partitions (like MBR or GPT) and passes the control to it. If there is a partition containing a bootloader (like GRUB) it will pass the control to it next. The bootloader will search for a kernel (vmlinuz) and a file system (initrd) to boot, then it will load the rest of your files and data, hence the whole system is booted and you have your shell (or KDE environment). The whole process is a bit more complicated (like shadow memory, inithooks, etc), but it will be enough to understand the rest. Now, if your disk is encrypted (using LUKS for instance), it's actually isn't encrypted completely, the MBR/GPT and bootloader are still stored in clear (which is a HUGE security issue, but that's another problem), otherwise the PC won't boot. Moreover, the disk even isn't encrypted with your password, it's encrypted with a randomly generated key that is stored encrypted with your password in a pretty descent way. So, when you enter your password, it decrypts the key which goes to memory and stays there to encrypt and decrypt the data from and to your disk on the fly. Such system isn't perfect and has its own flaws, but again, we're dealing with a different issue here. Another important thing to mention is that all this metadata (ciphers, hashes, etc) and additional passphrases are stored in a specific location on the encrypted partition, called header.

(I actually considered making a blog about it, but since there are plenty of info already on this topic, I just decided to make an overview)

Delete all the things!

Now, the question is, how we can erase our data quickly and certainly? Well, first of all, why to erase all of it if we can just erase the key since it's needed for decryption? That could be done with just one command, but that will still leave the whole header, proving that your disk was indeed encrypted (and prompting for password at boot), which could cause you some (even more) troubles. Thus, it is better to erase (or even write random data to) the whole header, in order for the partition to look like empty or corrupted. But even so, you still have your bootloader and everything else showing that you at least have an operational disk (or had sda2_crypt partition in /boot/grub/menu.lst, that also has to be replaced if not using LVM), so why not to delete (or randomly overwrite) it all, making it look like a complete rubbish? Well, it's a good idea at first sight, but your boot partition could be pretty big (especially if using LVM/RAID) and you may not have SSD but HDD, which will perform write operation much slower. At the same time, if you can just trigger the event and launch it in the background with fewer possibilities to cancel it (assuming the attacker will not instantly perform cold-boot), that would work. However, even if we delete the key from the storage, it is still in the live memory, so we have to instantly power off the PC just after erasing the key, which will empty our memory and make the key unrecoverable (or at least difficult to recover, especially with DDR3L or DDR4 RAMs nowadays). If you have a laptop, don't worry, there is a Linux command to do it (yes, it's basically like cutting power cord, even quicker than pressing the power button), but I mean, it's pretty much like a rule 34 for Linux, if it's possible there is a shell command for it, if not start coding.

The Red Button (or USB)

Alright, jokes aside, we still have to resolve one more issue, and that's how you're going to trigger such event. You can simply assign a keyboard shortcut for it, but you may forget it or accidentally type it. Another solution is to make an alias or just double click the script, but still, you will have to remember what they are and where they are, as well as be careful not to launch them by error. That's why, a hardware USB solution is preferable InMyHackishOpition, unless you don't insert a specific device, nothing bad will (should) happen and in case of an emergency you don't have to think, but to act directly and simply.

Happy end?

Finally, what if you still want your data afterwards? Well, if you just erased the header, you can make a backup of it somewhere to restore it and the same goes to full wipe (booloader and all), as well as having a full backup of your disk is not a bad idea either. You can say that if the attacker know that the backup exist, they will go after it and you will be right, but even if there is no backup, it's unlikely that the attacker will believe it, so you still will have to say that there is no backup regardless of it being true or not and accept all the consequences, but if the data is deleted and you can't recover it, you become useless for the attacker whatsoever and if he/she/it wants the backup, he/she/it can't harm you (or at least won't end).

Anyway, let's conclude this pretty long talk before it gets too geo-political/phylosophical and do some practice, but just before that, few demonstrations:

Quick erase the header with customized hardware:

Full erase the disk with customized hardware or quick erase the header with stock hardware:

HowTo

!!! WARNING !!! be very attentive and cautious with this guide and code, one error could cost you all data, so please be careful

First things first, make sure that cryptsetup, dd, fdisk, df, sync, lsusb and update-grub commands are available to you and installed as well as your disk in encrypted with LUKS.

As I mentioned, the solution can be used without any additional hardware, but is intended to, so you will also need a DigiSpark USB, those are pretty cheap in any online shop.

Now, there are 2 solutions: easy, but slow, and hard, but fast.

EASY

1 - Plug your GigiSpark

2 - Configure it using default proposed settings (requires to install Arduino IDE)

3 - Modify (by commenting) lines 256 and 265 in ~/.arduino*/packages/digistump/hardware/avr/*/libraries/DigisparkCDC/usbconfig.h (requires IDE restart):

Replace "0xd0,