Independent Audit: Insights into the Source Code of Boxcryptor

Boxcryptor was subjected to a comprehensive external audit by the security company Kudelski in May 2020. The results are positive throughout. Kudelski could not find any critical weaknesses and the few suggestions for improvement have already been implemented. In the following article, we provide an insight into the audit process and the results.

Boxcryptor ensures that no one has access to data without authorization. Cloud providers and their staff, as well as potential hackers, are excluded reliably. For private users, Boxcryptor is a means of digital self-defense against curious third parties, for companies and organizations it is a path to genuine GDPR compliance and complete control over business data. With software as security-relevant as Boxcryptor, it is understandable that users want to be sure that the software works properly and does exactly what it is supposed to do.

For the audit we gave Kudelski access to the source code of Boxcryptor for Windows (our most widely used platform) and to our internal documentation.

All these components were logically correct and did not show any significant weakness under scrutiny. It is important to note that the codebase we audited was not showing any signs of malicious intent. (Boxcryptor Code Audit – Final Report)

The goal of the audit was to give all interested parties an indirect insight into the software. This way they can be sure that no backdoors or security flaws are found in the code.

Kudelski – The Company that Looked into Boxcryptor

We have chosen to have our audit conducted by Kudelski Security. The world-renowned Swiss security company develops its own security software and has advised and audited many large companies. Kudelski’s technology and vulnerability assessment enjoy a very good reputation in the industry. In their audits, Kudelski’s independent security experts first obtain an overview of the software architecture of the technology under test. In a second step, they identify potential vulnerabilities that need to be addressed.

What Are the Benefits of an Audit?

We were thinking about having Boxcryptor audited for quite some time now, but we have always decided against it for a variety of reasons. Our biggest problem with an audit has always been that audits are just a snapshot of the software. We are constantly working on the software, and – we thought – with the next update, the audit would be out of date again. Additionally, an audit is never a guarantee that a software is safe, because nothing in the field of security can ever be a 100% secure. Kudelski also records this in its report.

It is important to notice that, although we did our best in our analysis, no code audit assessment is per se guarantee of absence of vulnerabilities. (Boxcryptor Code Audit – Final Report)

In our opinion, this applies to the open source model as well. Just because software is openly available does not mean that you can rely on every change being critically reviewed by security experts. A real security analysis of open source software is also rather the exception, so in principle the same problem remains. Since an audit also has a significant financial impact, we have always wondered whether the potential benefits do justice to the financial outlay – especially in the first years as a start-up.

Advantages of an Audit for the Users

Since Boxcryptor has been on the market for over nine years and is used by hundreds of thousands of users, we have decided to conduct an audit. For example, it may not be that important to audit every single version of a software. It is rather a matter of being able to assess three essential things:

1. the company behind the software
2. the quality of the software in general
3. the security-relevant source code (which is not constantly being changed)
   A positive audit report helps users to assure themselves of this quality. It also shows, in our opinion, the following.

Experts Work Here

The team behind Boxcryptor knows what it is doing. Cryptography is complex and to write secure software requires a lot of expertise and talent. Since verified experts examined Boxcryptor and found it to be secure, the user can assume that serious bugs and security problems are unlikely to occur in future versions of the software.

Security Is a Priority for the Boxcryptor Team

The greatest expertise is of no use if the security aspect is not sufficiently taken into account in the development process. For example, if the company’s security expert does not even see new code, even companies with encryption legends may develop insecure products as a team.

What You See Is What You Get

We have always communicated our encryption protocol very openly. Based on our technical overview and a release of our source code for our encryption on GitHub, Boxcryptor can almost be replicated conceptually. Nevertheless, most users do not have the time to check this information themselves by decrypting their own files “manually”. With Kudelski, a well-known, competent and independent partner has taken on this task and can now confirm that we actually do what we promise.

The Concept of Boxcryptor is Secure

The audit shows that our cryptographic concept is secure. Users can be even more reassured after the independent audit by Kudelski, as the experts did not find any security-critical vulnerabilities in Boxcryptor.

Overall the cryptographic primitives used and the architecture of the system are adequate to achieve the security goals we were presented. (Boxcryptor Code Audit – Final Report)

You Can Trust Boxcryptor

Of course, it is possible that a weak point is overlooked during an audit. But it is very unlikely that major problems go unnoticed. We believe that this statement will remain true for future versions. We have always been convinced that we have done good and reliable work with Boxcryptor in the past. The result of the audit confirms this assumption and you can expect the same from us in the future.

What We Hoped to Gain from the Audit

A View from The Outside

As already mentioned, security has always been a top priority in our software and we always pay great attention to security issues. Nevertheless, we only see Boxcryptor from our perspective and risk a certain amount of operational blindness. For this reason alone, it made sense to provide an external company with insight into the code. This way, external experts could point out problem areas to us if necessary.

Verification of the Secure Software Development Lifecycle

One point that was important to us was the verification of our Secure Software Development Lifecycle (SSDL). We have a defined process to test our software for security before, during and after development. One of the goals of this SSDL is to identify as many problem areas, security-relevant scenarios and attack possibilities as possible. Kudelski’s external audit has now enabled us to match this process with the problems found. The questions we can ask ourselves when problems arise are as follows: What type of problem is it? In principle, could we have found the problem using our SSDL process? Does the report cover a whole area that we have not considered? Why were the problems that were found not discovered by us before? The audit could have given us input that would have allowed us to adapt and improve our SSDL.

Fortunately, our SSDL has proven itself, so no changes to the process were necessary. Nevertheless, we have been able to take away a new line of thinking here and there for our own search for weaknesses.

A Pleasant Side Effect: Improvement of the Internal Documentation

In the course of the audit, we revised the complete internal documentation so that Kudelski can find its way around easily. This gave our internal documents a final polish once again. As a result, we now have documentation that is easy to understand, well-structured and clearly arranged in one place available for new employees of the company.

How the Audit was Conducted

First Step: Objective Setting and Threat Model

At the beginning of the audit, we discussed and defined the goals of the audit, the threat model against which Boxcryptor has to protect its users, and the relevant code sections. First of all, we had to be clear what was to be audited at all and which attacker we were expecting.

For example, should Boxcryptor employees also be considered as potential attackers? Do we also want to protect ourselves against theoretical attacks from cloud providers? In both cases, the answer during our audit was yes. In this first step of the objective, the audit company was given access to our external and internal documentation, the source code and an intro to it.

Second Step: The Audit

Kudelski launched the audit process at the beginning of May, with short communication channels at all times to the developers and managers in the Boxcryptor team. We quickly noticed how routinely Kudelski worked, as they were able to get to grips with our – for them, foreign – code without any lengthy training. This was pleasant for us, as the effort required by the developers supervising the audit was surprisingly low. This is very relevant for us, because when considering the cost of an audit, one must always bear in mind the cost of the time lost by the staff if they were to be occupied by the audit company 24 hours a day.

Important: if Kudelski had found a serious security breach, they would not have held it back until the final report but would have reported the problem immediately. This made it clear to us that Kudelski’s priority was the same as Boxcryptor’s and our users’: the security of customer data has top priority at all times.

In our case, the audit comprised two parts. We did not just want to have our software and its code verified, we also wanted to audit our Boxcryptor protocol (which you can have a look at at any time in our technical overview. Since a building can only be as stable as it was designed, we wanted to make sure that our protocol, the foundation of Boxcryptor, is stable.

Third Step: A Two-part Discussion of the Results

Once Kudelski had completed the audit, a preliminary report was drawn up. On the basis of this, the problems found were discussed and we had the chance to fix them. Kudelski then re-examined the measures taken and drew up a final report.

The Results of the Boxcryptor Audit

In the following, we briefly summarize the results and their interpretation and assessment for you. You can view the entire audit report here.

Overall, there were few surprises. There was no critical and only one weakness rated “medium”. This concerned the software and not the underlying encryption technology. The problems could therefore be fixed quickly and we are thoroughly satisfied with the result.

The following issues were found in the audit:
• A issue rated as “medium”
• 2 issues classified as “low”
• 6 “observations” to be taken as an indication

1. WebDAV Connection to Cloud Providers

Classification: “medium”

Description: The problem rated as medium is a part of the code that affects the connection to cloud providers that use the WebDAV protocol. Theoretically, the operators of such cloud storage providers could have tried to inject code into Boxcryptor for Windows. In practice, however, this part of the code was never used by Boxcryptor, so there was no danger for Boxcryptor users at any time.

Solution: In response to the audit, we have now completely removed this redundant part of the code.

2. The User Password

Classification: “low”

Description: The most interesting problem for us, rated as “low”, concerned Boxcryptor’s handling of the user password. Boxcryptor uses multiple password hashing to provide users with the highest possible security, even when they use a password that is actually insecure. In this process, the password is linked to bytes which are unique for each user, and then hashed several times. A hash is a kind of “fingerprint” of the password, which cannot be calculated back into the password. The random data serves the purpose of ensuring that two users with the same password still generate different fingerprints. This process has two goals: By hashing the password before the transfer, the user password is never sent to the server (of course we also hash this fingerprint a second time after the transfer). Multiple hashing also reduces the number of passwords that an attacker can test in a given time: Because generating so many fingerprints takes time, and that slows down the attacker. After all, he or she has to perform this calculation anew for each attempt.

The number of hash passes was 5,000, while in other places we use a number of 10,000 hashes. Kudelski criticized both the fact that we remained “below our standard” here and that they would generally recommend 100,000 passes. In addition, Kudelski recommended taking a more critical look at users’ passwords when choosing them and, for example, not accepting passwords that were too short.

Solution: If you are a Boxcryptor user and have chosen a secure password, this problem does not concern you. For those who have chosen an insecure password, we have increased the iteration number of the hash to 10,000. Increasing the number to 100,000 would have slowed down old browsers or slow devices too much, so we decided to leave the number at 10,000. From now on, there is also a minimum password length for newly created passwords.

3. Reading the Boxcryptor Configuration

Classification: “low”

Description: The second problem rated as low was the reading of the Boxcryptor configuration. An attacker who had writing access to the configuration files could have attempted to inject code there. However, this problem was purely theoretical. In order to exploit this vulnerability, additional constraints had to be met that were not present in the current version or any Boxcryptor versions in the past. An actual security hole could have been created in future versions, so this observation was noted.

Solution: We have adapted the corresponding code location so that no security gap can occur in the future either.

4. Changes of Files are Known to the Cloud Provider

Classification: “Observation”

Description: The most interesting observation for us was that Boxcryptor does not hide from the cloud provider which files have just been modified by the user. If a file is changed by the user, Boxcryptor encrypts it and updates it in the cloud provider’s folder. Based on the access patterns, the cloud provider could now draw conclusions about the file, e.g. what type of file it is.

Solution: A practical solution to avoid this is currently not available. Academic solutions to this problem do exist, but they are not so easy to implement in practice without side effects for the user. For this reason, we are following Kudelski’s recommendation in this case: keep an eye on the progress of research in this area and adapt Boxcryptor accordingly as soon as possible.

The remaining observations can be summarized in two categories: Code that was not used and which we subsequently removed, and misleading naming of code constructs. The latter are not a problem in themselves, but could be misinterpreted by developers in the future and then used in an unsafe way. We have reduced this risk by renaming or documenting the code locations.

Conclusion

We are very happy with the verification of the quality of the software and have gratefully accepted Kudelski’s small suggestions for improvement. The audit was a great opportunity for us to get an outside view of Boxcryptor. We hope that the audit and its results also confirm for our users that Boxcryptor is the right choice for protecting your data.