This project has moved. For the latest updates, please go here.

TrueCrypt Phase II Audit

Topics: Feature Requests, Technical Issues
Apr 2, 2015 at 6:30 PM
Hi,

I just found out that https://opencryptoaudit.org/

any idea when you can address the issues mentioned there.
I have not read it but on a site that posted the summary the issues should be minor.

Or have those issues already been addressed?
Apr 2, 2015 at 7:02 PM
Ars Technica article on the "Open Cryptographic Review" here:
http://arstechnica.com/security/2015/04/truecrypt-security-audit-is-good-news-so-why-all-the-glum-faces/

PDF of the just-released report here: https://opencryptoaudit.org/reports/TrueCrypt_Phase_II_NCC_OCAP_final.pdf

Results:
2 High Severity Issues
0 Medium Security Issues
1 Low Security Issue
1 Undetermined Security Issue

Vulnerability Class Severity
  1. CryptAcquireContext may silently fail in unusual scenarios - Cryptography - High
  2. AES implementation susceptible to cache-timing attacks - Cryptography - High
  3. Keyfile mixing is not cryptographically sound - Cryptography - Low
  4. Unauthenticated ciphertext in volume headers - Cryptography - Undetermined
Coordinator
Apr 2, 2015 at 10:34 PM
Hi,

I already started working on the CryptAcquireContext issue: the modification will not tackle only this function but will also add more specific error handling for random generator initialization. In practice, this will almost never manifest itself (the only case I can think of is a user with no profile on disk) but the code should be made more robust anyway.

Concerning the cache-timing attack, this is a deep issue found in several implementations not only TrueCrypt/VeraCrypt and implementing a counter-measure is not obvious nor simple. From the attack point of view, this is very a very complex attack to mount. Moreover, it requires the attacker to run code the victim's machine...

Cache-timing attacks are realistic on multi-user server environment where a malicious user can recover sensitive keys from the CPU. This type of shared environment is clearly not recommended for TrueCrypt/VeraCrypt because of other security risks so this is not a realistic scenario in our context.
On the other hand, remote cache-timing attacks (for example using JavaScript) that target cryptographic keys are still on the early stages (more difficult than attacking mouse/network activity as demonstrated by the paper referenced by the audit report) and the best know attack requires between 2x10^9 and 4x10^9 samples...this requires a lot of time (between one week and one month) and it will most certainly be detected or interrupted before it gets any results.
Nevertheless, it should be taken into account since attacks get only better. The problem is, as expressed by Daniel Bernstein in his famous paper about cache timing attacks, it is extremely difficult to write constant-time high-speed AEs software for common general-purpose computers. The other problem is that there patented way to modify AES implementation in order to protect against these attacks which make them impossible to use without written consent.
Anyway, since this applies to all cryptographic libraries, we should seek external help/advice from other open source projects to look for available general purpose implementations that brings some level of protection without loosing too much performance.

As noted by the audit report itself, the keyfile mixing issue has been know of years. Moreover, a user has already opened an ticket for this on VeraCrypt issue tracker two weeks ago: https://veracrypt.codeplex.com/workitem/115
This is no a critical issue but it definitely needs to be enhanced. This will take some time to define the best implementation that is secure but also practical (for example, keyfile processing should remain quick and preferably the order of the key files should not matter).

The last point concerning unauthenticated plain text in the decrypted header is not a realistic attack at all. Since the attacker doesn't know the encryption key, he will have to find a way to force VeraCrypt on the target machine to mount specially crafted volumes 2^32 times, hoping to be able to forge the "VERA" ASCII string. Moreover, because of the checks done by TrueCrypt/VeraCrypt on the validity of various fields (sector size, header version, Required program version), the attack needs also to uncover valid values for these fields at the same time. Thus the real number of crafted volumes needed is at roughly around 2^32 x 2^16 x 2^16 x 2^16 if we take into account the ASCII field and the three numeric fields. This is 2^80 attempts, which is completely unrealistic...

These are my first thoughts about the report. Overall, no real vulnerability despite the high rating given by the report and the keyfile mixing issue is the more realistic issue among them all but it has been known for years.
Apr 3, 2015 at 10:25 AM
As said most are minor. The cache-timing attack is a bit higher but only on multi-user systems

Regarding the header that is why they said undetermined security issue, I guess.
However, I think that one should be a relatively fast fix?

Anyway, so you intend to fix those things, even if they are minor?

One last thing: If I understand this correctly, changes regarding these points would not make old encrypted volumes unusable because they have nothing to do with creating the volume?
Apr 3, 2015 at 3:09 PM
Edited Apr 3, 2015 at 3:55 PM
AndreasAll wrote:
As said most are minor. The cache-timing attack is a bit higher but only on multi-user systems

Regarding the header that is why they said undetermined security issue, I guess.
However, I think that one should be a relatively fast fix?

Anyway, so you intend to fix those things, even if they are minor?

One last thing: If I understand this correctly, changes regarding these points would not make old encrypted
volumes unusable because they have nothing to do with creating the volume?
The time Cache-timing attacks are not a threat if the computer is completely powered off and unplugged, and not
being used to encrypt data on a server over OpenSSL AES.

CPU's are now powerful enough to to run constant-time high-speed AES which have multiple threads and an AES instruction set. The only problem is what Mounir says, which are patented issues.

Changes should not effect your data, and I wouldn't worry about changes as you can always keep an old copy of VeraCrypt for decryption, but I seriously doubt Mounir would release a copy that would render your data useless.

Here is Berstein's research, he talks of CPU's from the pentium era, so you can understand why he says
CPU's wouldn't have have the power to run constant-time high-speed AES, and also CPU's back then did
not have an AES instruction set, so it is very possible now.

http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

I would also like to mention Serpent and twofish, these are other choices, but the reason why there was a big deal made out of AES in the audit is because it is used for symmetric encryption with asymmetric encryption (emails) and sessions and with OpenSSL as it is quicker.

http://en.wikipedia.org/wiki/OpenSSL

But the main part here is VeraCrypt and Truecrypt are not internet facing apps.
Apr 10, 2015 at 8:24 PM
Edited Apr 10, 2015 at 8:25 PM
When these issues are addressed, do headers need to be updated and re-created on data volumes? I just converted all my drive headers over from TrueCrypt. I would think the headers would need to be replaced again after reading the changelog. If the random generator had issues then how would one know if their keys and volume headers were created correctly.

By the way, thank you idrassi for all your efforts and contributions to this prodject this far and forward. Keep up the great work!
Sep 21, 2015 at 11:41 PM
Since the CryptoAcquireContext issue was fixed in 1.0f-2, I would focus on:
  1. Keyfile mixing -- even HMAC-RIPEMD160 would be an improvement
  2. If they're available, use AES-NI to provide fast, cache-timing-safe AES. Otherwise, fall back to a constant-time implementation. Libsodium has an implementation of bitsliced AES-128-CTR http://doc.libsodium.org/advanced/aes-128-ctr.html
As far as the unauthenticated volume header, what would it take to authenticate this too?