TrueCrypt Security: Securing Yourself against Practical TrueCrypt Attacks
The need to defend confidentiality of our sensitive information against persistently rising cyber threats has turned most of us toward using encryption on a daily basis. This is facilitated by easy-to-use GUI tools like TrueCrypt that offer advanced encryption without hassles. TrueCrypt offers ‘on-the-fly’ encryption, which means we do not have to wait for large files to decrypt after entering the correct passphrase; files are immediately accessible. Many of us have come to trust TrueCrypt to defend extremely sensitive personal and business secrets. However, there is no such thing as absolute security. Vulnerabilities always exist, and in this paper we look at some of the ways in which TrueCrypt security can be “beaten”. Please note that these attacks may not target a flaw in TrueCrypt itself, but rely on ‘bypassing’ TrueCrypt security or taking advantage of user negligence.
This paper seeks to address TrueCrypt users who wish to understand known attacks against TrueCrypt, and forensics analysts who are interested in defeating TrueCrypt during the course of criminal investigations.
Known Attacks against TrueCrypt
In this paper, we will progress via attacks that are easily understood, and move toward attacks that require advanced understanding of TrueCrypt functionality and encryption systems.
The concept of a dictionary attack is simple. We sequentially try all entries in a dictionary file as potential passphrases until we succeed. However, there are obvious downsides to this approach. Most users who are using TrueCrypt to protect their sensitive information are smart enough to use complicated passphrases that would not be found in dictionaries. Also, this attack can get very time-consuming, depending on the size of the dictionary selected.
Here, we use a tool called ‘truecrack’ to implement a dictionary attack on a protected TrueCrypt volume. We created a dummy dictionary with 7 phrases, the last of which was the correct passphrase [Figure 1].
Note: Such dictionary attacks on TrueCrypt are incredibly slow, since it uses the Password-Based Key Derivation Function 2 (PBKDF2) that is meant to slow down the password cracking process using key stretching.
Brute Force Attacks
Brute force attacks deploy a similar concept to dictionary attacks, except here every possible combination of characters is tried from a pre-determined set. To simulate a brute force attack on a TrueCrypt volume, we used the tool ‘unprotect.info’. First, we point it to the encrypted volume [Figure 2].
Next, we set the parameters to be used while implementing the attack [Figure 3]. These parameters will determine the total number of possible combinations. Note that we set the password to the encrypted volume as ‘haha’—a simple combination of 4 characters—to save time during experimentation.
For example, in this case we knew the password to be 4 characters long and having all lower case characters. We set the parameters accordingly which gave us a total of (26*26*26*26) =456976 possible passphrases [Figure 4].
The tool sequentially tried all possible combinations until it got to the correct passphrase, which was then displayed to us [Figure 5].
As with dictionary attacks, PBKDF2 used in TrueCrypt would considerably slow down the brute force attacks.
DMA (Direct Memory Access) is used to acquire control of the RAM via the FireWire port. The attacker can then take a full memory dump even if a computer is locked or logged off. If the protected TrueCrypt volume is mounted while the memory dump is taken via a FireWire port, the resulting image would contain the cryptographic keys needed to decrypt and mount the TrueCrypt volume (as explained later in this paper). ‘Inception’ is a free tool that allows one to perform a FireWire attack. The best mitigation against this attack is to simply disable the FireWire drivers in the Operating System and render the port non-functional.
Rootkits are a form of advanced malware that facilitate stealthy deployment and operation of programs on a system. Bootkits are variants of rootkits that infect the Master Boot Record (MBR) or a boot sector Wik1. In case full disk encryption is being used, such bootkits are capable of manipulating the original bootloader and replacing it with an infected copy. Such an attack was implemented by researchers Alex Tereshkin and Joanna Rutkowska Ale2. This “evil maid” attack drew attention to the need for physical security of the device that holds the encrypted TrueCrypt volume. The idea is that even if the user is protecting his sensitive information using full disk encryption, the MBR itself is not encrypted and can be infected. Hence, if an attacker can boot your computer using a USB stick, he can overwrite the original bootloader and insert a type of “sniffer” that would “hook” a TrueCrypt password function and save the passphrase the next time the volume is mounted. This passphrase is then extracted by the attacker at a later time.
Note: If you wish to replicate this experiment, you would need a copy of the Evil Maid infector image (see Downloads above), and a device that is using full disk encryption. Also note that it is best to use TrueCrypt 6.3a during this test since Evil Maid is no longer updated and is known to corrupt the bootloader when used against TrueCrypt 7.1a.
Cached Passphrase Attacks
Cached passphrases allow automatically mounting containers without requiring the user to enter the passphrase every time. This cached passphrase is located in ‘TrueCrypt.sys’. In case the user has explicitly told TrueCrypt to ‘cache’ passphrases [Figure 6], an attacker could locate this passphrase in a memory dump. Volatility framework provides a plugin called ‘TrueCryptpassphrase’ especially for the retrieval of cached passphrases from memory. Note that once the attacker has access to the passphrase, he would not need to know the details of the encryption algorithm used or the cryptographic keys.
Decrypting and Mounting a TrueCrypt Volume using Cryptographic Keys Extracted from Memory
Analyzing the Protected TrueCrypt Volume
The first thing we need to do is make sure that we are, in fact, dealing with an encrypted TrueCrypt volume. TrueCrypt volumes are identified based on certain characteristics such as sizes that are multiple of 512 (block size of cipher mode), missing headers, etc. Volatility framework offers a ‘TrueCryptsummary’ plugin that can be used to locate information germane to TrueCrypt within our memory image [Figure 7].
Looking at the results, we know that TrueCrypt 7.0a was being used on the system and the protected volume was mounted while the memory was dumped. Also, we notice that ‘ppp.challange.vol’ is the TrueCrypt container.
Understanding Cryptographic Keys
TrueCrypt provides ‘on-the-fly‘ encryption, which means that the cryptographic keys have to be loaded in memory at all times while the protected TrueCrypt volume is mounted. By default, TrueCrypt uses AES encryption along with XTS, and the 256 bit primary and secondary keys are concatenated together to form one master key of 512 bits. You may search for these keys on RAM (system memory) or ‘hiberfile.sys’ (a file created during hibernation). Here, it is important to note that hiberfile.sys can only be expected to contain the keys if the protected TrueCrypt volume was mounted while the system went into hibernation. In case the protected volume was dismounted during hibernation, it is futile to look for the cryptographic keys on the RAM dump or hiberfile.sys. The keys are not stored on disk due to obvious security concerns Mic3.
Searching for Cryptographic Keys in Memory
Before we can extract keys from memory, we need to identify them. One approach is to attempt decryption of known plaintext using every possible combination of bytes. However, in the presence of bit errors in memory, this approach gets highly convoluted JAl084. Another approach is to cycle through each byte in memory and to treat the following block of a certain size as a key schedule. Then, a hamming distance is calculated pertaining to this word and the word that should have been generated based on surrounding words. If the number of bits that violate constraints germane to correct key schedule is small, the key is discovered JAl084. ‘Aeskeyfind’ implements this approach, and we use it to search for AES keys in our memory image [Figure 8].
Alternatively, you can use ‘bulk extractor’ to locate keys in memory [Figure 9]. Note that this tool also locates other information in memory such as emails, IP addresses, URLs, etc.
At this point, we know the two 256 bit primary and secondary AES keys and we can use these to mount the protected volume. However, we first need to fake a header.
Faking a TrueCrypt Header
Since we do know the actual passphrase pertaining to the protected volume, we will create a template containing a known passphrase and copy this to the protected volume. Later, we can use this known passphrase and the extracted AES keys to mount or decrypt the protected volume.
./TrueCrypt –text –create –encryption=aes –filesystem=FAT –hash=RIPEMD-160 –password=pranshu –random-source=/dev/random –size=33600000 –volume-type=normal anothvol
Here, we are using TrueCrypt in ‘text’ mode to create a volume with default AES encryption, RIPEMD-160 hash, and a FAT file system. Please note that the size of the encrypted volume is 33.6 MB or 33600000 bytes. We need this TrueCrypt volume (with known password) to be of the same size [Figure 12].
In order to copy header information from this volume to the protected volume, we use ‘dd’ [Figure 13]:
dd bs=512 count=1 conv=notrunc if=/root/TrueCrypt/Main/anothvol of=/root/ppp.challenge.vol
Hard Coding Keys into TrueCrypt Source Code
We now need to “patch” TrueCrypt so that it accepts the discovered AES keys. Here, we have patched TrueCrypt 7.1 (see Downloads above). For this purpose, we modify the ‘VolumeHeader.cpp’ file and hard code the AES keys in there Mic15 [Figure 14].
Now, we compile this modified source code and attempt to mount the protected volume using the known password [Figure 15].
./TrueCrypt –text –mount-options=readonly –password=pranshu /root/ppp.challenge.vol /mnt/pranshu
We have successfully mounted the protected TrueCrypt volume at ‘/mnt/pranshu/’ using the known password and hard coded AES keys. We can now view the sensitive file inside the volume [Figure 16].
The purpose of this paper—like many researchers who studied and implemented attacks on TrueCrypt—is to make a TrueCrypt user aware of what protection is truly being offered. A false sense of security is highly perilous. For instance, it is imprudent to neglect physical security of the device while using TrueCrypt lest you fall prey to a bootkit attack or a DMA attack. On the other hand, keeping the protected volume mounted at all times, or for extended periods, increases the likelihood of getting cryptographic keys stolen from memory. Note that we have intentionally avoided discussing any commercial recovery software in this paper.
As of this writing, there is a vague warning on TrueCrypt website that apprises users of “security issues” in TrueCrypt. There is no detailed information on this warning yet, however, if you wish to pay heed to it, you may use ‘Veracrypt’ as an alternative to TrueCrypt.
 Wikipedia. [Online]. http://en.wikipedia.org/wiki/Rootkit#Bootkits
 Joanna Rutkowska Alex Tereshkin. The Invisible Things Lab’s blog. [Online]. http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-TrueCrypt.html
 Michael Ligh. Volatility Labs. [Online]. http://volatility-labs.blogspot.com/2014/01/TrueCrypt-master-key-extraction-and.html
 Seth D. Schoen, Nadia Heninger, William Clarkson, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, Edward W. Felten. J. Alex Halderman, “Lest We Remember: Cold Boot Attacks on Encryption Keys,” in Proc. 17th USENIX Security Symposium (Sec ’08), San Jose, CA, 2008.
 Michael Weissbacher. Michael Weissbacher. [Online]. http://mweissbacher.com/blog/2011/05/17/plaidctf-writeup-fun-with-firewire/
 Michael Ligh, “Mastering TrueCrypt: Windows 8 and Server 2012 Memory Forensics,” in Open Memory Forensics Workshop, 2013.