On December 10th 2020, Germany's Federal Office for Information Security (BSI) published the English report of a security evaluation of VeraCrypt that they ordered from the Fraunhofer Institute for Secure Information Technology (SIT).
The report can be found at the following URL: https://www.bsi.bund.de/DE/Publikationen/Studien/VeraCrypt/veracrypt.html
I have also attached the PDF of the report to this post in case URL changes in the future.
Before the publication of this report, the SIT team responsible of the security evaluation reached out to us and we had exchanges about their findings. I shared my feedback and I also implemented changes in 1.24-Update7 based on their findings.
In my opinion, this evaluation is the most comprehensive one that have been published so far about VeraCrypt, spanning over a year and analyzing all aspects of the project and the source code. Their findings are helpful and VeraCrypt development will benefit from them.
Great news, and kudos to all your good work, its the second major validation after the Quarkslab audit of 2016 for v1.18. This is overall a good review and their most severe criticism is about process of code maintenance and not the security of the product itself. This news should update the validation entry section in Wikipedia.
For readers unfamiliar with the reviewing agency :
It appears the URL has changed to the published report. Using the search feature on the BSI site resulted in the following two links to download the report that is written in English.
Don't get me wrong, I love Veracrypt and highly appreciate this marvelous piece of software. However, I find the audit to not be all that positive if you read the summery.
I have highlighted the points which seem concerning to me.
VeraCrypt is a popular open-source tool for disk encryption available for Windows, Linux and macOS.
VeraCrypt is a successor of TrueCrypt, an encryption software whose development stopped in 2014 and
which is no longer maintained by its developers. VeraCrypt adopted most of TrueCrypt’s source code and to
this day shows considerable similarities to TrueCrypt.
This report summarizes the results of a year-long project of Fraunhofer Institute for Secure Information
Technology, Darmstadt, Germany on behalf of the Federal Office for Information Security (BSI), Bonn,
Germany. After starting off with an extensive research into the project evolution and related work, we
executed a security analysis of VeraCrypt with a focus on its cryptographic mechanisms and the security of
the application as a whole. During the research process we followed a security model that includes pertinent
usage scenarios including the use of VeraCrypt for secure online sharing of data and the use on public
systems and servers. Our research efforts included both automated and manual testing techniques, manual
code and documentation review, as well as the creation and use of dedicated test tools.
We found that although VeraCrypt is a well-acknowledged software project, it appears that the project is
still mostly driven by a single developer rather than a development team. The data we collected for
VeraCrypt’s development history indicate that the project did not follow an elaborated software-
development cycle with acknowledged best practices for software engineering, for instance, quality gates,
peer reviews, and documentation of code changes. The code base still mainly consists of code from the
TrueCrypt project that has been repeatedly criticized for its poor coding style as the case of differing
implementations of the random number generator for different operating systems still tellingly shows. The
inherited code base has not been cleaned up, moreover, the development still follows questionable coding
practices.
The basic functionality such as the parsing of container files and the interface to the kernel driver did not
show security issues in any of our tests. We also did not find vulnerabilities in the cryptographic algorithms
of VeraCrypt. However, VeraCrypt still uses the outdated and deprecated RIPEMD-160 hash algorithm and
we found peculiarities with respect to the implementation of the random number generators and the GOST
block encryption cipher. The recently integrated memory encryption has a weak rationale from a security
perspective and increases the cost of related attacks by a relevant margin in very limited scenarios only. We recommend the VeraCrypt project to switch to well-acknowledged and reliable open-source libraries
for the implementation of cryptographic functions instead of proceeding to provide and use own outdated
cryptographic code in the VeraCrypt code base. We also recommend to switch to a state-of-the-art key
derivation function. As a final remark, we want to stress that VeraCrypt can only protect data effectively in
case of theft or loss of encrypted devices but not against any form of online attacks on a running system.
Also, VeraCrypt cannot provide any protection in scenarios where an attacker can visit a target system
multiple times.
In conclusion, we did not find substantial security issues in VeraCrypt. VeraCrypt in its current version does
seem to protect the confidentiality of data in an encrypted volume as long as the volume is not mounted.
Authenticity and integrity, however, are not protected. A mounted VeraCrypt volume is exposed to a
multitude of attack vectors including vulnerabilities of the host system. Hence, any volume-access scenario
exceeds the protection envelope of VeraCrypt. The development practices and the resulting code quality of
VeraCrypt are a cause for concern. Therefore, we cannot recommend VeraCrypt for sensitive data and
persons or applications with high security requirements. We recommend to execute similar security
assessments also for future versions of the software.
Or is it just me being too critical?
Last edit: Anonyx 2021-12-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for raising these points. I will try to give my answer and clarify some points.
Concerning the inherited code base from TrueCrypt, there have been several improvements done in VeraCrypt to cleanup several parts and use more secure implementations and API calls but indeed the much of the code remains the same and I have been following coding approach similar to TrueCrypt guys one in order to keep the overall architecture coherent.
A more complete rewrite is needed to ease maintenance but the amount of time and resources needed for that is beyond what I can do for now. That being said, the coding styles and architecture don't affect the security of VeraCrypt.
Concerning GOST and random generator, the auditors comments have been addressed in version 1.24-Update7. For RIPEMD-160, it offered only for system encryption on legacy MBR boot mode and it is not offered by default (SHA-256 is the default one is this case), in all other cases it is not offered at all.
Concerning memory encryption, I disagree with the auditors: although it is not perfect in its current implementation, it does enhance security and it makes key extraction more costly. Enhancements to RAM encryption are ongoing and there is no reason to remove this feature.
Concerning the cryptographic functions implementations used in VeraCrypt, the language used by the auditors makes it look as if VeraCrypt (and TrueCrypt before it) is using home-made code. The reality is that VeraCrypt uses implementations from various libraries that are well tested and from authors No issues have been found in any cryptographic code in VeraCrypt but the auditors prefer that VeraCrypt uses implementations from less number of sources, preferably from a single library like Botan or OpenSSL.
I have nothing against using a single source for cryptographic implementation. It is just not an urgent task and there are always risks of regression when changing such critical code that has been battle tested for years by a new one even if it comes from other well know libraries.
Concerning the key derivation, VeraCrypt uses PBKDF2 which is old but it is still secure especially thanks to high number of iterations used (for example, PBKDF2 is part of NIST recommendation for password key derivation alongside Balloon). Auditors recommend using memory-hard functions like Argon2. I agree with this recommendation although Balloon function recommended by NIST seems also interesting (Dan Boneh is one of its authors). Anyway, there is no security risk associated with PBKDF2 in VeraCrypt.
The comments about development practice and code quality are understandable. The same applies to various projects and even TrueCrypt before. Does this mean that VeraCrypt is not secure? They didn't say that. They certainly don't feel comfortable with the limited resources available to the project development compared to other commercial solutions that come with liability.
As far as I'm concerned, the outcome of this exhaustive audit is positive since no security issue was found, various comments have been addressed and other enhancements inline with the audit recommendations are planned. Certainly 2021 was not the most active year for VeraCrypt development because of various circumstances but hopefully 2022 will be a better year with this respect.
👍
1
Last edit: Mounir IDRASSI 2022-01-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It looks like VeraCrypt could use some improvements but it currently doesn't seem to affect its security which is the main goal.
I understand this project uses a lot of your time to develop and maintain it. We can only hope you'll have enough free time to keep maintaining it and I just want to thank you once again for this great piece of software!
I do wonder: do you have plans to expand on the developer side? I mean, wouldn't it be easier for you and also beneficial to VeraCrypt to let others help you in coding and further development?
Or are there not enough candidates (if any?) to help you out?
Or is it too risky in terms of trusting others to write code?
Happy New Year and best wishes for 2022!
Last edit: Anonyx 2022-01-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The project is always open to developers who want to contribute and collaborate. The issue is that there is not many developers who contribute code and usually contributions are limited. The only major contribution to VeraCrypt in terms of code was the implementation of UEFI bootloader by Alex Kolotnikov and with whom I exchanged a lot for a year in order to integrate UEFI support in VeraCrypt.
There are many skilled developers out there who can help on various topics but doing open source work is not always something they are willing to do and for those who are into open source they are often committed to other projects.
As for trust, of course one must always be careful when receiving code from unknown parties but the risks are mitigated through careful reviews and a lot of testing and validation. So I don't see this as a blocking point.
My best wishes also to you and the entire community for a happy new year 2022.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Quote Mounir "There are many skilled developers out there who can help on various topics but doing open source work is not always something they are willing to do and for those who are into open source they are often committed to other projects."
I think you are being far too modest Mounir. I believe code contributions from other developers are limited because few have your abilities.
I doubt many users of VeraCrypt fully appreciate just how lucky we are to have you and I wish more would donate financially.
Given the calculation, (1x Mounir >= 3x average developers), do we really need anyone else? :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have come to the conclusion that veracrypt is secure for data at rest, however I have elected to use another encryption vendor to create encrypted vaults within the OS to provide additional security incase of an online attack. I highly recommend you do the same. I won't name my vendor here because I don't want to come off as and advertiser..... However there are plenty of good packages out there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On December 10th 2020, Germany's Federal Office for Information Security (BSI) published the English report of a security evaluation of VeraCrypt that they ordered from the Fraunhofer Institute for Secure Information Technology (SIT).
The report can be found at the following URL: https://www.bsi.bund.de/DE/Publikationen/Studien/VeraCrypt/veracrypt.html
I have also attached the PDF of the report to this post in case URL changes in the future.
Before the publication of this report, the SIT team responsible of the security evaluation reached out to us and we had exchanges about their findings. I shared my feedback and I also implemented changes in 1.24-Update7 based on their findings.
In my opinion, this evaluation is the most comprehensive one that have been published so far about VeraCrypt, spanning over a year and analyzing all aspects of the project and the source code. Their findings are helpful and VeraCrypt development will benefit from them.
Great news, and kudos to all your good work, its the second major validation after the Quarkslab audit of 2016 for v1.18. This is overall a good review and their most severe criticism is about process of code maintenance and not the security of the product itself. This news should update the validation entry section in Wikipedia.
For readers unfamiliar with the reviewing agency :
https://www.sit.fraunhofer.de/en/the-institute/fraunhofer-sit/profile/
the prior audit is here:
https://blog.quarkslab.com/security-assessment-of-veracrypt-fixes-and-evolutions-from-truecrypt.html
Last edit: Robert iXj Smith 2021-07-30
It appears the URL has changed to the published report. Using the search feature on the BSI site resulted in the following two links to download the report that is written in English.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Veracrypt/Veracrypt.html
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/Veracrypt/Veracrypt.html
Don't get me wrong, I love Veracrypt and highly appreciate this marvelous piece of software. However, I find the audit to not be all that positive if you read the summery.
I have highlighted the points which seem concerning to me.
Or is it just me being too critical?
Last edit: Anonyx 2021-12-30
Thank you for raising these points. I will try to give my answer and clarify some points.
Concerning the inherited code base from TrueCrypt, there have been several improvements done in VeraCrypt to cleanup several parts and use more secure implementations and API calls but indeed the much of the code remains the same and I have been following coding approach similar to TrueCrypt guys one in order to keep the overall architecture coherent.
A more complete rewrite is needed to ease maintenance but the amount of time and resources needed for that is beyond what I can do for now. That being said, the coding styles and architecture don't affect the security of VeraCrypt.
Concerning GOST and random generator, the auditors comments have been addressed in version 1.24-Update7. For RIPEMD-160, it offered only for system encryption on legacy MBR boot mode and it is not offered by default (SHA-256 is the default one is this case), in all other cases it is not offered at all.
Concerning memory encryption, I disagree with the auditors: although it is not perfect in its current implementation, it does enhance security and it makes key extraction more costly. Enhancements to RAM encryption are ongoing and there is no reason to remove this feature.
Concerning the cryptographic functions implementations used in VeraCrypt, the language used by the auditors makes it look as if VeraCrypt (and TrueCrypt before it) is using home-made code. The reality is that VeraCrypt uses implementations from various libraries that are well tested and from authors No issues have been found in any cryptographic code in VeraCrypt but the auditors prefer that VeraCrypt uses implementations from less number of sources, preferably from a single library like Botan or OpenSSL.
I have nothing against using a single source for cryptographic implementation. It is just not an urgent task and there are always risks of regression when changing such critical code that has been battle tested for years by a new one even if it comes from other well know libraries.
Concerning the key derivation, VeraCrypt uses PBKDF2 which is old but it is still secure especially thanks to high number of iterations used (for example, PBKDF2 is part of NIST recommendation for password key derivation alongside Balloon). Auditors recommend using memory-hard functions like Argon2. I agree with this recommendation although Balloon function recommended by NIST seems also interesting (Dan Boneh is one of its authors). Anyway, there is no security risk associated with PBKDF2 in VeraCrypt.
The comments about development practice and code quality are understandable. The same applies to various projects and even TrueCrypt before. Does this mean that VeraCrypt is not secure? They didn't say that. They certainly don't feel comfortable with the limited resources available to the project development compared to other commercial solutions that come with liability.
As far as I'm concerned, the outcome of this exhaustive audit is positive since no security issue was found, various comments have been addressed and other enhancements inline with the audit recommendations are planned. Certainly 2021 was not the most active year for VeraCrypt development because of various circumstances but hopefully 2022 will be a better year with this respect.
Last edit: Mounir IDRASSI 2022-01-02
Thank you for that clarification!
It looks like VeraCrypt could use some improvements but it currently doesn't seem to affect its security which is the main goal.
I understand this project uses a lot of your time to develop and maintain it. We can only hope you'll have enough free time to keep maintaining it and I just want to thank you once again for this great piece of software!
I do wonder: do you have plans to expand on the developer side? I mean, wouldn't it be easier for you and also beneficial to VeraCrypt to let others help you in coding and further development?
Or are there not enough candidates (if any?) to help you out?
Or is it too risky in terms of trusting others to write code?
Happy New Year and best wishes for 2022!
Last edit: Anonyx 2022-01-01
The project is always open to developers who want to contribute and collaborate. The issue is that there is not many developers who contribute code and usually contributions are limited. The only major contribution to VeraCrypt in terms of code was the implementation of UEFI bootloader by Alex Kolotnikov and with whom I exchanged a lot for a year in order to integrate UEFI support in VeraCrypt.
There are many skilled developers out there who can help on various topics but doing open source work is not always something they are willing to do and for those who are into open source they are often committed to other projects.
As for trust, of course one must always be careful when receiving code from unknown parties but the risks are mitigated through careful reviews and a lot of testing and validation. So I don't see this as a blocking point.
My best wishes also to you and the entire community for a happy new year 2022.
Quote Mounir "There are many skilled developers out there who can help on various topics but doing open source work is not always something they are willing to do and for those who are into open source they are often committed to other projects."
I think you are being far too modest Mounir. I believe code contributions from other developers are limited because few have your abilities.
I doubt many users of VeraCrypt fully appreciate just how lucky we are to have you and I wish more would donate financially.
Given the calculation, (1x Mounir >= 3x average developers), do we really need anyone else? :)
I have come to the conclusion that veracrypt is secure for data at rest, however I have elected to use another encryption vendor to create encrypted vaults within the OS to provide additional security incase of an online attack. I highly recommend you do the same. I won't name my vendor here because I don't want to come off as and advertiser..... However there are plenty of good packages out there.
@czx30
Were you referring to Microsoft Windows operating system?