search

veracrypt / VeraCrypt

Disk encryption with strong security based on TrueCrypt
https://www.veracrypt.fr
Other
6.88k stars 946 forks source link

Fix issues of TrueCrypt Phase II NCC OCAP #32

Closed ghost closed 8 years ago

ghost commented 8 years ago

Are these issues fixed in VeraCrypt? https://opencryptoaudit.org/reports/TrueCrypt_Phase_II_NCC_OCAP_final.pdf

ghost commented 8 years ago

Related to #5 (Phase I), ping @idrassi

ghost commented 8 years ago

ping @idrassi

idrassi commented 8 years ago

I have already written on April 3rd 2015 a post detailing my analysis about the NCC Phase 2 report.You can read it here: https://veracrypt.codeplex.com/discussions/616471#post1399210

Basically, the only real issue was with the random generator which has been fixed since then. The other issue that deserves work is the keyfile mixing algorithm but as I explained in the link above it is not critical and it requires finding adequate solution to preserve current mixing properties.

Here is a quote of my post in the above URL. Feel free to comment.

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.