Has the NSA hacked Tresorit encryption by hacking SSL?

Many people have raised their concerns about a potential NSA hack during the past week.

The quick answer is: no.

But we also have a longer answer! It may sound a bit more complicated – but surely worth your time. Tresorit relies on open-source, strong cryptography libraries, and even if SSL gets compromised, it could cause no harm for Tresorit due to our “belts-and-suspenders” principle: everything is double secured, not to mention that our client-side encryption does not rely on the security of SSL. However, there are still some crypto-related problems which keep us awake all day and all night.

Double-secured architecture – first step of keeping Tresorit secure.

When we designed Tresorit, we had two different options: using widespread, well-tested, standardized, industry-standard protocols or creating (or implementing) new, stronger protocols. We decided to combine the best of these approaches: we use the strongest standard one, and extend it with our protocol on a way that if our own protocol fails, it would fall back onto the standard one.

The problem with standard (legacy) protocols: There are several widespread protocols, which turned out to be week later on, like NTLM, the one used in Windows-based systems for authentication. There are several tools available to the public to crack such protocols, and there are still a lot of other legacy protocols deployed and used each day. Did you know that it takes only  8 minutes to crack a password on Windows? What each protocol has in common: they were considered to be strong when they were designed – at least, by the public. Remember WiFi WEP, where WEP stands for Wired Equivalent Privacy. It was first released in 1999, became widespread, and even when it became obvious that WEP contained several serious security flaws, we had to wait 2 years for the first publication about its serious weaknesses. The worst part of the story is that 12 years after the previously mentioned publication, there are still WEP-enabled devices on the market.

On the contrary, there are a lot of examples of failure for non-well analyzed, proprietary protocols. This was the case for GSM A5/1 encryption. It was kept secret from 1987 until 1994, when the general design was leaked. Right after the leakage, several serious weaknesses were found by academic researchers, and today, even with your PC you can crack it within some seconds.
So we decided not to use any protocols which appear to be weak, even if there is no known attack against them. For example, we are using SHA512 instead of SHA1. Obviously, we denied to use any algorithms like MD5, which turned out to be insecure. Note, that despite of its insecurity, MD5 is still widely used by companies who claim they were “secure”.

But what if there is no standard solution? Well, we created our own solutions, designed to be as close to the standards as possible, using only standard primitives, like AES256 and SHA512. After that we double secured it with established solutions. For example, we upload every file using TLS, and strong encryption keys, even if your files are already encrypted with another method to provide client-side end-to-end protection.

How does Tresorit secure content?

If you don’t feel a great motivation to understand all technical details, feel free to skip this section. It describes the relatively complicated process of securing your content. Our vision is building a service which is so easy to use that you won’t have to understand or even worry about the encryption. It will do its job in the background, so that you can do yours.

When you log in, your password is salted and hashed (more info here), using 256-bit random salts, and PBKDFv2-HMAC-SHA1 algorithm to generate strong, 160-bit encryption and authentication keys. This algorithm is iterated 10,000 times, which slows down the code generation, and thus means serious delay for a potential brute-force attack. Note, that most of the protocolsused today do not apply this method which makes the work of NSA easier.

This generated key is now used to log in with a zero-knowledge, challenge-response protocol with the server. If you created a strong password, the server will provide you your encrypted profile, but the server will not be able to access even the generated secret.

Your profile is encrypted with AES256, in CFB mode, the same mode which is used in PGP. The encryption key is generated from your password, like mentioned above, but an absolutely different key is used. This key is your master key, and if you enable auto-login, it will be stored on your local device – obviously, applying a local encryption. Note, that your profile is only opened on your computer or device. Our servers, and Tresorit employees only see encrypted random data.

Your contains your private keys. Currently, we are using RSA 4096 bit. Note, that even banks rarely use such a strong key. Your public key is used to share tresors with others. When you share a tresor, you see that it takes some time for a “Crypto handshake”. During that time, the inviter and the invitee exchange their public keys with each other, but on a paranoid way: there are several steps to ensure there is no third party sitting between the invitee and the inviter. This handshake is secured with digital signatures from each party, digitally signed certificates from Tresorit, HMAC-SHA512. You can even use a pairing-password to securely authenticate the full handshake –as usual, we use PBKDFv2-HMAC-SHA512 and HMAC-SHA512 alone to provide additional integrity. This guarantees, that even your digital signature is flawed, there is a second protection level.

Tresorit members share a 256 bit random secret key using their RSA 4096 bit public key. This secret key is used to open the tresor. Each and every document stored in a tresor has its own, unique, random, 256 bit key, all of them refreshed frequently, and the best: none of these keys leave your or your partners’ computer. File and directories, including the file name, directory structure, are encrypted in a form quite similar used in OpenPGP. We extended the OpenPGP standard to enable effective synchronization, but we kept all security properties of that. Those keys are stored in a special tree, which can be opened with the shared 256 bit random secret key. This architecture guarantees that even if one file, or even one version of a file is compromised, it does not endanger the security of your full tresor.

But encryption alone is not enough. Therefore, each file is protected with HMAC-SHA512, using a different individual key for the encryption. Every person you share the tresor with will check this code, and if it was modified by an unauthorized user, the file will be dropped.

When we upload such encrypted, HMAC-ed bundles, we use TLS (a later version of SSL), using both client and server public keys to secure the transmission. TLS is used for securing the communication between our servers and your client, but TLS protected packets are decrypted on the server side – not just in Tresorit, in every other case. Our encryption inside the TLS channels guarantee that even after TLS decryption servers are unable to decrypt or modify your content. As you can see, even we treat our own cloud as an untrusted party – even though our servers are located in top-notch secured datacenters, which are ISO/IEC 27001:2005 and SSAE 16/ISAE 3402 audited and certified.

Why do we believe that the NSA did not hack Tresorit?

We think we oversecured our system, using the latest and the strongest commercially available cryptography algorithms to provide you the highest confidentiality. None of the lately leaked reports contain anything which could imply our system was or could be hacked by the NSA. To the best of our knowledge, none of the used cryptography algorithms (AES, SHA, RSA) were hacked by the NSA, and even if they have supercomputers, 256 bit random keys cannot be brute-forced.

However, there is a Canadian “startup”, D-Wave which publicly provides 512 qubit quantum computers. If this becomes commercially available, what is already available for the NSA? They may use a quantum computer to run the Shor’s algorithm to crack any prime factorization problem based cryptography, like RSA. So far, there is no known evidence that they succeeded to crack AES or SHA with quantum computers. Here, at Tresorit, we are working hard on using only algorithms which are resistant to a possible quantum computer attack.

Yet, there are other ways to bypass our over-secured system: your operating system might have been hacked by NSA, but according to the leaked information this is quite unlikely since NSA targeted mostly servers. Also, there might be backdoors in your operating system, or even in your hardware, and not just created by the US government, since most chips are constructed outside of USA, for example in China. In this case, all security products can be bypassed. Using limited backdoors like weakened random generators, does not fully compromise your system. The latter is simpler to implement, and the possibility to be caught is way smaller since any of this limited backdoors can be named as a security bug.

So, why we think NSA did not hack Tresorit? If they did so, that would mean they hacked everything in the world – using quantum computers or fully-backdoored systems, not to many digital systems would remain secure at all. To the best of our knowledge, this is not the case.