The canonical implementation of the TrueCrypt encrypted container format is developed in a secretive way by anonymous hackers. This upsets some people who are not comfortable with their encryption software being developed by unknown people. Fortunately, there are alternative implementations of the TrueCrypt format, particularly on Linux and BSD platforms. (NOTE: there are Windows implementations as well, but I don’t use Windows, so I don’t know anything about them).

dm-crypt: Linux Kernel Encrypted Data Storage

The Device Mapper is the Linux kernel infrastructure which enable arbitrary data stores to appear as block devices. The dm-crypt module provides transparent encryption as a Device Mapper layer. Any block device (including loopback devices) can be mapped by dm-crypt as a transparently encrypted virtual block device under /dev/mapper.

This is a powerful kernel module for working with encrypted data stores. It abstracts the entire encryption handling into the kernel and allows the userland programs to treat the encrypted data container as a simple block device, just like any other. UNIX philosophy for the win!

tc-play: TrueCrypt for dm-crypt

A DragonflyBSD developer did a complete reimplementation of the TrueCrypt container format using the dm-crypt module to handle the crypto. In the process of developing his reimplementation, he discovered some inconsistencies between the TrueCrypt documentation and the actual container format.

tc-play GitHub

cryptsetup: Swiss Army Knife of Disk Encryption

The cryptsetup tool is vital to the functioning of encrypted disks on Linux. Originally only supporting some lame on-disk format, cryptsetup was later updated to implement LUKS.

LUKS is a hardened on-disk encrypted key storage designed to withstand bruteforce and forensic attack. It uses multiple key slots to allow multiple passphrases to decrypt, uses a strong master key to decrypt the drive contents, and is generally pretty awesome as an encrypted container format.

If you read nothing else, read the cryptsetup FAQ which is full of information about securing an encrypted drive.

For a while now cryptsetup has supported the TrueCrypt container format along side the native, and far superior, LUKS format. The TrueCrypt support is available as tcrypt and I’ll have to look into that more. See how to mount a TC container using cryptsetup.

stlth: stealth, the stego crypto container thats a cryptsetup shellscript

In 2009 or 2010 someone decided to wrap some of the awesome features of cryptsetup in a simple shell script, enabling humans to actually take advantage of these features. It was such a complicated process he lost all the vowels.

The one particularly cool thing about stlth is that it enables hidden storage, similar to TrueCrypt’s hidden container. You have to manually enter the offset for the hidden container, which is a bit brittle and error prone.

stlth source code is on sourceforge, although both stlth and sourceforge are basically dead.

Tomb: cryptsetup wrapper shellscript, part deaux

The Tomb project is actually really cool. They have done a lot of work to make the power of cryptsetup accessible to mere mortals. In the process, they have incorporated some very sound best practices, what I would call a robust SOP for handling encrypted data stores.

The major innovation with the Tomb software is the separation of the data store (the tomb) from the key. Tomb, like TrueCrypt, allows multiple files to be aggregated and used as the unlocking passphrase. Tomb goes further by forcing the user to keep the decryption key in a separate PGP encrypted file (the .key). The user can now store the key in an arbitrary location, separate from the encrypted container. `Tomb` supports using `steghide` to keep the key inside a JPEG. You can even pull the key file over Bluetooth when you unlock the tomb! If that doesn’t give you devious thoughts, get out of the hacking business, this is no place for you.

Tomb home. There is a github, but the src is old. The github wiki has interesting stuff though. The most relevant guide to using Tomb is probably the crunchbang paranoid computer user guide, which you should read anyway. It is quite comprehensive.

Conclusion

The Grugq, a well-known anti-forensics researcher, outlines the key issues related to counter-forensics for the OS X platform during HITBSecConf event.

At the end of September at Virus Bulletin 2012 my colleague Eugene Rodionov and I presented the results of our research “Defeating anti-forensics in contemporary complex threats”, dealing with hidden file systems and modern complex threats. Hidden file systems are used by modern complex threats for evading detection by security and forensic software. We have already discussed forensic problems with hidden file systems more than once in our previous blog posts (Bootkit Threat Evolution in 2011) and in this research we have been concentrating on in-depth analysis of the most widely used anti-forensic technique – the implementation of hidden encrypted storage – as used by complex threats currently in-the-wild. Here is a self-explanatory diagram depicting the evolution over time of bootkit threats with hidden file systems:

Adrian Crenshaw discusses "anti-forensics" at Notacon 7, focusing on the assembly of a small device called a Programmable HID USB Keystroke Dongle, or PHUKD for short--some cyberpunk James Bond type shit which can be programmed to execute commands upon being plugged into a target computer. So you can, say, open a new text file in Notepad on your boss's machine and have it type "We do not forgive. We do not forget. Expect us." and then get fired. Or any number of other, more subtle and nefarious things your imagination can come up with.

You might need to crank the volume, as the camera/audio work isn't exactly top notch.