The results are in from the cryptanalysis phase of the TrueCrypt audit, and they show—nothing.
Well, maybe not “nothing,” but certainly no signs of a deliberate backdoor from the NSA or any government entity, fears of which date back to the autumn of 2013, post-Snowden, and ignited talk to have the open source encryption software audited.
“We approached the audit looking for any vulnerabilities we could identify, such as the misuse of a function or a memory corruption issue,” said one of the auditors, Tom Ritter, a security engineer with NCC Group Cryptography Services. “We did not go into the audit looking expressly for backdoors nor did we go in assuming there would be none and ignore them.
“It’s difficult to identify a deliberately placed backdoor, but we feel we did a good audit over the code. Ultimately, we like TrueCrypt as a project and hope the community continues to develop it.”
Auditors from NCC Group’s Cryptography Services arm finalized their report on March 13 and publicly released it today. Four vulnerabilities were identified in the code, two of them meriting a high-severity rating from the auditors. None of the issues, however, lead to a bypass of confidentiality, the report said.
“TrueCrypt appears to be a relatively well-designed piece of crypto software,” wrote Matthew Green, a cryptography professor at Johns Hopkins University and one of the organizers of the Open Crypto Audit Project. “The NCC audit found no evidence of deliberate backdoors, or any severe design flaws that will make the software insecure in most instances.”
This was the second phase of the audit; the first was completed almost a year ago and turned up fewer than a dozen vulnerabilities in the TrueCrypt bootloader and Windows kernel driver. The just-completed cryptanalysis was narrow in scope, and looked at the assorted AES implementations, the random number generator implementation, the SHA-512 hash function, key derivation functions, keyfiles, header volume format and cipher cascades. The auditors were looking for a number of problems that would lead to the leakage of plaintext or key data, predictable outputs from the RNG, and other design and implementation flaws.
The biggest issue that turned up during the audit was related to the random number generator, which generates keys that encrypt TrueCrypt volumes. The vulnerability calls into question whether the RNG is indeed predictable. Green said the TrueCrypt developers (their identity has still not been publicly revealed) based the RNG on a 17-year-old design that uses an entropy pool of unpredictable values from a number of different sources in the system, including the Windows Crypto API.
– Matthew Green
“A problem in Truecrypt is that in some extremely rare circumstances, the Crypto API can fail to properly initialize. When this happens, Truecrypt should barf and catch fire. Instead it silently accepts this failure and continues to generate keys,” Green said. “This is not the end of the world, since the likelihood of such a failure is extremely low. Moreover, even if the Windows Crypto API does fail on your system, Truecrypt still collects entropy from sources such as system pointers and mouse movements. These alternatives are probably good enough to protect you. But it’s a bad design and should certainly be fixed in any Truecrypt forks.”
Ritter, who conducted the audit along with colleagues Alex Balducci and Sean Devlin, said TrueCrypt’s RNG gathers input from a number of sources, some of which are more predictable than others, but still not cryptographically sound. The main source is from a call to the Windows API, yet if the call somehow fails, TrueCrypt will continue to create volumes or encrypt a disk using a key that’s partially predictable.
Cryptography Services also said that volume header decryption uses integrity checks that don’t properly detect tampering. It also said that TrueCrypt’s AES implementations are vulnerable to cache-timing attacks.
“This is probably not a concern unless you’re performing encryption and decryption on a shared machine, or in an environment where the attacker can run code on your system (e.g., in a sandbox, or potentially in the browser),” Green said. “Still, this points the way to future hardening of any projects that use Truecrypt as a base.”
Ritter said no one has ever demonstrated the ability to conduct a cache-timing attack against AES in a realistic scenario.
“A realistic scenario would be where you visit a website and it does normal JavaScript that runs in your browser, and that JavaScript runs a cache timing against your AES implementation in TrueCrypt,” Ritter said. “That would be a powerful attack that would allow any website to learn your key and decrypt your laptop.”
Ritter said some JavaScript cache-timing attacks have been pulled off, but not against AES, which would require a significant investment to pull off.
The auditors recommend that code reviews continue on TrueCrypt, in particular in three areas: XTS pointer arithmetic; header volume parameters; and program flow.
“Truecrypt is a really unique piece of software. The loss of Truecrypt’s developers is keenly felt by a number of people who rely on full disk encryption to protect their data,” Green said. “With luck, the code will be carried on by others. We’re hopeful that this review will provide some additional confidence in the code they’re starting with.”
