Search the Community

The Security audit of TrueCrypt disk-encryption software has been completed, with no evidence of any critical design vulnerabilities or deliberate backdoors in its code. TrueCrypt -- one of the world's most-used open source file encryption software used by Millions of privacy and security enthusiasts -- is being audited from past two years by a team of security researchers to assess if it could be easily exploited and cracked. Hopefully, it has cleared the second phase of the audit. TrueCrypt is a free, open-source and cross-platform encryption program available for Windows, OSX and Linux that can be used to encrypt individual folders or encrypt entire hard drive partitions including the system partition. NO NSA BACKDOORS Security Auditors and Cryptography Experts at NCC took an initiative to perform a public information security audit of TrueCrypt in response to the concerns that National Security Agency (NSA) may have tampered with it, according to a leaked classified document by Edward Snowden. TrueCrypt cleared the first phase of the audit that reviewed the blueprints of the software and given a relatively clean bill of health almost a year ago. At the first phase, auditors discovered 11 issues of medium and low severity in the software. Now, the auditors from NCC Group’s Cryptography and security audit Services have finalized and published the 21-page Open Cryptographic report related to the second phase of audit that examined TrueCrypt's implementation of random number generators and critical key algorithms, and various encryption cipher suites. FOUR VULNERABILITIES DISCOVERED The report uncovered four vulnerabilities in the latest original version of the software, but none of them could lead to a bypass of confidentiality or let hackers use deformed inputs to subvert TrueCrypt. The vulnerabilities are given below: Keyfile mixing is not cryptographically sound -- Low severity Unauthenticated ciphertext in volume headers -- Undetermined CryptAcquireContext may silently fail in unusual scenarios -- High severity AES implementation susceptible to cache timing attacks -- High severity The most critical of the four vulnerabilities involved the use of Windows API to generate random numbers used by master cryptographic key. A separate vulnerability with undetermined severity checks for the volume header decryption was susceptible to tampering. Also, a low severity flaw for a method used to mix the entropy of keyfiles was not cryptographically sound. Another high severity flaw identified refers to "several included AES implementations that may be vulnerable to cache-timing attacks." Source: thehackernews.com

There's a story on Hacker News asking what the hell is going on with the Truecrypt audit. I think that's a fair question, since we have been awfully quiet lately. To everyone who donated to the project, first accept my apologies for the slow pace. I want to promise you that we're not spending your money on tropical vacations (as appealing as that would be). In this post I'd like to offer you some news, including an explanation of why this has moved slowly. For those of you who don't know what the Truecrypt audit is: in late 2013 Kenn White, myself, and a group of advisors started a project to undertake a crowdfunded audit of the Truecrypt disk encryption program. To the best of my knowledge, this is the first time anyone's tried this. The motivation for the audit is that lots of people use Truecrypt and depend on it for their security and safety -- yet the authors of the program are anonymous and somewhat mysterious to boot. Being anonymous and mysterious is not a crime, but it still seemed like a nice idea to take a look at their code. We had an amazing response, collecting upwards of $70,000 in donations from a huge and diverse group of donors. We then went ahead and retained iSEC Partners to evaluate the bootloader and other vulnerability-prone areas of Truecrypt. The initial report was published here. That initial effort was Part 1 of a two-part project. The second -- and much more challenging part -- involves a detailed look at the cryptography of Truecrypt, ranging from the symmetric encryption to the random number generator. We had some nice plans for this, and were well on our way to implementing them. (More on those in a second.) Then in late Spring of 2014, something bizarre happened. The Truecrypt developers pulled the plug on the entire product -- in their typical, mysterious way. This threw our plans for a loop. We had been planning a crowdsourced audit to be run by Thomas Ptacek and some others. However in the wake of TC pulling the plug, there were questions. Was this a good use of folks' time and resources? What about applying those resources to the new 'Truecrypt forks' that have sprung up (or are being developed?) There were a few other wrinkles as well, which Thomas talks about here -- although he takes on too much of the blame. It took us a while to recover from this and come up with a plan B that works within our budget and makes sense. We're now implementing this. A few weeks ago we signed a contract with the newly formed NCC Group's Cryptography Services practice (which grew out of iSEC, Matasano and Intrepidus Group). The project will evaluate the original Truecrypt 7.1a which serves as a baseline for the newer forks, and it will begin shortly. However to minimize price -- and make your donations stretch farther -- we allowed the start date to be a bit flexible, which is why we don't have results yet. In our copious spare time we've also been looking manually at some portions of the code, including the Truecrypt RNG and other parts of the cryptographic implementation. This will hopefully complement the NCC/iSEC work and offer a bit more confidence in the implementation. I don't really have much more to say -- except to thank all of the donors for their contributions and their patience. This project has been a bit slower than any of us would like, but results are coming. Personally, my hope is that they'll be completely boring. Sursa: A Few Thoughts on Cryptographic Engineering: Another update on the Truecrypt audit

Inainte stiam ca era TureCrypt puteai sa faci encriptare la orice fisier care cica era sigura. Puteai sa faci encriptare si la intreg hardiskul si sa iti ceara o parola atunci cand boot-eaza. Auzisem eu ceva de TrueCrypt cum ca daca e opensource s-ar putea sa nu fie chiar atat de sigur fiindca oricand cineva ar poate face programul care sa inverseze algoritmul si sa decripteze ce ai criptat tu. Intru pe situl celor de la TrueCrypt si ia uitati ce gasesc: TrueCrypt WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues Si ne sfatuiesc sa folosim acel Bitlocker de la Windows. Pe bune, voi credeti ca asta o fi sigur ? Multi zic ca insusi windows-ul are programe de spionaj bagate in el, sa ne incredem in Bitlocker ? La un moment dat aparuse PGP, daduse la televizor, acum cativa ani, ca niste hackeri ar fi pus la punct un program de encriptie avansat si foarte performant numit PGP. Nu a durat mult si acest PGP se pare ca a fost cumparat de cei de la Symantec. Se stie ca in orice moment din zi si din noapte daca unei firme publice, cum e si Symantec, i se cere accesul de la ceva anume de catre CIA sau FBI, acestia sunt obligati sa il dea. Il dau adica si de la Norton numai ca sa nu faca 150 de ani de puscarie de caciula cum se da pe la USA. In concluzie, daca vrei sa encriptezi bine datele si acestea sa fie 100% sigur encriptate si imposibil de decriptat, ce program folosesti ?

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. Downloads: Evil Maid USB image Memory image and encrypted TrueCrypt volume Tools Used: TrueCrypt 7.1 (source code) Truecrack Unprotect Inception Volatility Aeskeyfinder Bulk Extractor\ 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. Dictionary Attacks 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]. 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]. 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. Figure 3 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]. Figure 4 The tool sequentially tried all possible combinations until it got to the correct passphrase, which was then displayed to us [Figure 5]. Figure 5 As with dictionary attacks, PBKDF2 used in TrueCrypt would considerably slow down the brute force attacks. DMA 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. Bootkit Attacks 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. Figure 6 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]. 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]. 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.\ Figure 9\ Figure 10 Figure 11 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 Figure 12 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 Figure 13 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]. 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 Figure 15 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]. Figure 16 Conclusion 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. References [1] Wikipedia. [Online]. http://en.wikipedia.org/wiki/Rootkit#Bootkits [2] Joanna Rutkowska Alex Tereshkin. The Invisible Things Lab’s blog. [Online]. http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-TrueCrypt.html [3] Michael Ligh. Volatility Labs. [Online]. http://volatility-labs.blogspot.com/2014/01/TrueCrypt-master-key-extraction-and.html [4] 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. [5] Michael Weissbacher. Michael Weissbacher. [Online]. http://mweissbacher.com/blog/2011/05/17/plaidctf-writeup-fun-with-firewire/ [6] Michael Ligh, “Mastering TrueCrypt: Windows 8 and Server 2012 Memory Forensics,” in Open Memory Forensics Workshop, 2013. Source

nterview A TrueCrypt audit project has uncovered a well of technical support with its plans to publicly audit the widely used disk and file encryption utility for the first time. TrueCrypt is a widely used utility that encrypts and decrypts entire drives, partitions or files within a virtual disk. The tool can also hide volumes of data on discs. The TrueCrypt audit project raised enough money to pay for a professional review of the software within days of its launch. The Register recently caught up with one of the two founders of the project – Kenneth White, principal scientist at biotechnology firm Social & Scientific – to find out more about where the project goes from here. The Reg: You've achieved your early funding goals but will carry on accepting donations because there's much more you'd like to do, such as the bug bounty? Kenneth White: On IndieGoGo, you have to set a funding time range, so the 60 days was arbitrary, and, at the time we thought $25,000 was a pretty ambitious stretch goal. It turns out we hit that target in the first four days of the campaign. But yes, we've set our sights high in terms of what we would like to accomplish. We have formed a technical advisory panel and are discussing different strategies to make best use of our funding, perhaps a combination of professional security engineering analysis, academic review and public research. We are also in talks with a couple of non-profits who have offered to co-sponsor the work, but several details [need] to be worked out. The Reg: Are there any historic precedents for your project? Do you think the same idea could be applied to evaluating other security packages? I understand that you want to do TrueCrypt first but am wondering if this type of kick-starter idea might be applied to other security projects, by yourself or others, in future? White: The closest with TrueCrypt was by the 2008 review by engineers working with privacy-cd.org. But more broadly, the best model we have seen - and [one which we] hold as our standard - is the recent public review (PDF) of SecureDrop by the University of Washington CS Engineering Department, along with Bruce Schneier and Jacob Applebaum. The Reg: A security researcher has compiled TrueCrypt 7.1a for Win32 and matched the official binaries. Xavier de Carné de Carnavalet, a master's student in information systems security at Concordia University, Canada, claims he achieved what few others have managed so far. I know confirming the Win executable matches the source code was one of your goals. So does Xavier's work satisfy this or is further confirmation needed? Is Xavier affiliated with yourselves? White: It's a necessary first step, and we were impressed by Xavier's work. He's not affiliated, but has offered to help. He's a very talented engineer, and very humble. The Reg: What does the future hold? White: With the recent NIST recall and subsequent third party review of their entire "body of existing cryptographic work", I suspect there will be many more stories to come. Source: TrueCrypt audit project founder: 'We've set our sights high' • The Register

TCHunt is a small portable application that can be used to find encrypted TrueCrypt volumes on the system. It has been specifically designed to demonstrate the possibility of finding TrueCrypt volumes even if they are not mounted and well disguised by the user. http://16s.us/TCHunt/downloads/TCHunt.exe [v.1.6] http://dl.dropbox.com/u/55144650/t00lz/TCHunt-1.5-en.exe [v.1.5; GUI]