TrueCrypt Audit Phase II completed: 4 vulnerabilities identified
The recent history of the TrueCrypt encryption software is a strange one. First, there was a crowdfunding campaign to get the software audited for security issues in 2013 after Edward Snowden leaked classified information from the National Security Agency (NSA) starting June 2013.
Then in May 2014, an announcement was published on the TrueCrypt website claiming that TrueCrypt was not secure anymore and that users should find another program to use for that purpose.
The developers released a final version of TrueCrypt that was broken (by design) in many regards. The final source code of the full version of the program was published by Gibson Research Corporation and alternatives such as VeraCrypt or CipherShed appeared shortly thereafter.
At that time, TrueCrypt's audit was not complete as only phase one of the audit had been completed by the researchers.
The research term made the decision to continue with the audit of TrueCrypt 7.1a despite the fact that the project developers abandoned the project in the meantime.
Today, phase 2 of the TrueCrypt analysis has completed. The researches have uploaded the final report as a PDF document to the official website from where it can be downloaded.
A total of four vulnerabilities were discovered:
- Keyfile mixing is not cryptographically sound (low).
- Unauthenticated ciphertext in volume headers (undetermined).
- CryptAcquireContext may silently fail in unusual scenarios (high).
- AES implementation susceptible to cache timing attacks (high).
The most severe finding relates to the use of the Windows API to generate random numbers for master encryption key material among other things. While CS believes these calls will succeed in all normal scenarios,at least one unusual scenario would cause the calls to fail and rely on poor sources of entropy; it is unclear in what additional situations they may fail.
Additionally, CS identified that volume header decryption relies on improper integrity checks to detect tampering, and that the method of mixing the entropy of keyfiles was not cryptographically sound.
Finally, CS identified several included AES implementations that may be vulnerable to cache-timing attacks. The most straightforward way to exploit this would be using native code, potentially delivered through NaCl in Chrome; however, the simplest method of exploitation through that attack vector was recently closed off. #
The report highlights each vulnerability in detail which should help projects that use the TrueCrypt source as their base to address the issues in future updates.
It needs to be noted that the audit was narrow in scope and not a full code review. The team concentrated on important parts of TrueCrypt and here especially its cryptographic implementations and use.
“CryptAcquireContext may silently fail in unusual scenarios” is the most troubling of the four bugs, but this is due to the improper use of the so-called CryptAcquireContext function in Windows. Since Linux (my current system) has a different method of entropy polling in /dev/random, I doubt this is present in that OS. Even on Windows, if you did your due diligence and helped produce entropy by moving your mouse cursor when the program asked you to, which is then combined with PC variables like CPU time and process counters, then it is sufficient for security purposes.
“AES implementation susceptible to cache timing attacks” is oversimplifying the vulnerability. According to the paper, it only affects AES implemented through software that uses “AesSmall.c, AesSmall_x86.asm, Aes_x86.asm, and Aes_x64.asm”. It does not affect AES using AES-NI, which is available in TC 6.3 (maybe earlier?) and above. Also, I don’t see how it can be fruitfully exploited. For this cache-timing attack to work, the computer must be on and the volume decrypted (“A successful exploit may rely on the attacker’s ability to execute native code on the victim’s machine”). If an attacker can run native code on a victim’s machine, then it’s already pwned and the attacker can just dump/scan the memory for the key. On a powered-down computer or an unmounted encrypted external hdd, this vulnerability will not work.
“Keyfile mixing is not cryptographically sound” affects me because I always use one or more keyfile for all of my TC volumes. The vulnerability can negate the security provided by the keyfile. If one relied on a weak passphrase and hoped that the keyfile can add protection, this bug will bite them. With a sufficiently secure passphrase, the vulnerability can be mitigated. This is the one bug I would hope will get fixed. And as the team has labeled this as “high difficulty”, then it is probably not that easy to exploit in any case.
“Unauthenticated ciphertext in volume headers” is undetermined because it is not known if it can be exploited to weaken the security of the volume. Surreptitious tampering of the volume header may be possible but may do nothing. Until we find a way to exploit it, this bug is low security.
None of the four vulnerabilities are deal-breakers and I will still use Truecrypt with confidence. On my Linux machine I only use TC for external drive encryption for compatibility/interoperability with Windows machines. For Linux drive encryption I use LUKS.
What means those risks ? How much of the encrypted data can be unencrypted using these weakness ? Just some files, some part of the files or the whole data . ???
Does these vulnerabilities pose a real threat?
For me, it sounds like only people with a high skills in programming and good knowledge around the TC code could, **possibly**, access a TC volume.
RC4 SSL/TLS ‪Encryption‬ has been hacked Exposing Sensitive Data in Plain text.
Not to be used anymore.
The most popular and widely used encryption scheme has been found to be weaker with the disclosure of a new attack that could allow attackers to steal credit card numbers, passwords and other sensitive data from transmissions protected by SSL (secure sockets layer) and TLS (transport layer security) protocols.
The attack leverages a 13-year-old weakness in the less secure Rivest Cipher 4 (RC4) encryption algorithm, which is the most commonly used stream cipher for protecting 30 percent of TLS traffic on the Internet today.
The attack, dubbed “Bar-Mitzvah”, can be carried out even without conducting man-in-the-middle attack (MITM) between the client and the server, as in the case of most of the previous SSL hacks.
http://proethicalhacker.blogspot.co.il/2015/03/13-year-old-weakness-in-rc4-ssltls.html
Veracrypt is an open source fork that supports Truecrypt containers. Easy to migrate Truecrypt files. Just open it in Veracrypt.
I’m using Veracrypt for a while. It’s almost identical to Truecrypt in regard of GUI and use but it’s quite slower opening / decrypting volumes (using the same algorithm). Can’t understand if this is due to a higher level of security or simply it’s less efficient than Truecrypt.
And who is going to fix them ?
The NSA, of course.
No one is going to fix the TrueCrypt source but the spin-offs are likely to fix them.
I’m currently using VeraCrypt (https://veracrypt.codeplex.com/) and it works quite well (on Debian Jessie).
Martin, do you use any of the forks? I’m still using the original TrueCrypt and was wondering if there’s anything (that is based on TrueCrypt) worth switching to.
I’m using DiskCryptor for that now: https://www.ghacks.net/2012/08/08/how-to-encrypt-partitions-with-diskcryptor/