The long journey of creating secure web access - Part II.

From our previous post you may remember the four key issues that as a secure cloud storage provider, we consider essential, and we believe that these have to be resolved before a truly secure web interface can be created.

1. Browser and website vulnerabilities
2. Danger of phishing
3. Bad random generators
4. Lack of code integrity protection

In this post we pick up the thread and introduce and as a ‘part II.’ we discuss the latter ones: bad random generators and lack of code integrity protection.

The key of strong cryptography: true random generators

Strong cryptography is based on good random numbers. Even the best cipher suites are worthless without random keys. The best way to collecting random numbers is using special hardware. If this is not present, using a combination of system wide information can be an alternative (for more information, see RFC 4086), but implementing such random generators is quite dangerous without profound knowledge of cryptography. The security of any cryptographic protocol can be significantly weakened by reducing the entropy of random number generators. A good example for the consequences of a weak random generator is the random number bug in Debian Linux.

On May 13th 2008, the fact that the Debian version of OpenSSL (a library used for cryptographic operations) used only the process ID as the input of the random generator (CVE 2008-016) was revealed. This story may sound insignificant, but this actually meant that since the bug was introduced in 2006, for nearly 2 years millions of computers’ OpenSSL generated encryption keys could be decrypted by trying less than 32,768 variations. This may seem like a high number, but a regular desktop computer can try all of these variations in a relatively short time and decrypt any secured content.

Imagine that you are using an encryption tool and you think everything is secured properly; and after 2 years it turns out that all the data which was assumed to be encrypted was actually basically stored in completely accessible clear text. Even if you update your system, your data would still be in danger if your encryption keys remain the same, which take lots of effort to change.

A web application usually does not have access to good random sources. There is a huge endeavour on the developer side of web technologies to solve this problem. However, there is not a fully supported technology on the market:

• JavaScript: Web Cryptograpy API is a promising initiative, which contains good random generators and crypto implementations. However, the API is still in draft version, and only some browsers support it (according to Mozilla, currently only Chrome, Firefox and Safari support it, IE and Opera do not).
• Flash:  Flash Crypto in Actionscript 3 supports strong random key generation, but does not support other cryptographic operations natively. Furthermore, the creator of Flash, Adobe does not support Flash on mobile devices.
• Java Applet: Java Security package has supported secure random generators for a long time; however Java Applets are otherwise quite insecure, this is why more and more organizations forbid their usage. In addition, mobile devices usually do not support Java Applets.

Building trusted environment with code integrity protection

Code integrity protection guarantees that an application has not been modified by an adversary (someone with no permission to access and modify data streams, like a hacker). The most widespread technique for code integrity protection is code signing: the published application is hashed and digitally signed by the application publisher.

Trusted signatures include the data of the application publisher, which was checked by an authority. Strictly speaking trusted signature does not guarantee that an application is free from viruses, or any malicious code (e.g. Stuxnet drivers were signed by JMicron and Realtek), but it is a good indicator. The signature is only a legal record that can be traced and connected to an organization or an individual and says that the application is trusted. If authorities can trace the creator of a malicious code, they will receive strict punishment (e.g. the creator of Gozi is spending his 95 years sentence in prison).

Did you know that iOS, Android or Windows Phone apps must be signed? If the app does not have a signed code, these mobile operating systems will ban it. This is why there are very few mobile viruses. On desktop systems, mostly for compatibility reasons, singed code is not a must (however, strongly encouraged). Operating systems usually warn the user that a downloaded application is not signed or its signature is not valid, but the explicit banning of unsigned applications is quite rare.

Furthermore, JavaScript and HTML5 applications are not signed at all, even if you see a green bar (SSL/TLS certificate) in the browser – that only shows that the connection between your browser and the server is secured with SSL/TLS connection, and any code downloaded from the server has not been modified during the transition. However, this does not guarantee that JavaScript has not been modified on the server. So if you use a service applying JavaScript crypto which encrypts everything in your browser, your data is still in danger. If the servers are hacked, an adversary can easily modify the code to send the encryption key, or even the fully decrypted file back to the hacker.

Many argues that it can be assumed that servers are well protected. Yes, it can be. Question is whether we should. By accepting that, we would also assume that there’s no point in using JavaScript crypto at all, since you’re uploading data to a trusted environment.

So what is JavaScript crypto good for, why is it in widespread use? The truth is that it’s main function is to protect the service provider, because this way they can claim they have no knowledge of uploaded content, so if any illegal material is uploaded to their servers, they can’t be held legally responsible.

How will Tresorit provide secure web access?

At Tresorit, we sign every part of our code, and the signing procedure is quite complicated: we download the source code to a dedicated physical computer – this platform is protected with a TPM chip and strong passwords only used on this device. We automatically and manually check the code, and if everything is alright, we take our safely stored, tamper evident hardware token, connect it to the computer, and we manually type in 2 passwords for signing each binary. During signature signing the private encryption key never leaves the hardware tokens. After binaries and installers are created and published, we switch off the machine, take out the hardware token from the USB, and take it back to its secured place.

So what if somebody hacks our servers which publish the installer or the update? No big deal – your operating system will warn you that something is wrong with the downloaded executables. So never-ever install a Tresorit client that is not signed correctly!

We are looking for ways to guarantee code integrity for web access. Currently, among wide spread web technologies, only Java Applets support code signing, Flash and JavaScript does not (Mozilla is the only one who supports signed JavaScript). The problem with Java Applets is that it is not supported on mobile devices, and those are quite vulnerable.

Covering security in the cloud

I hope I could give you an overview of the vulnerabilities present in every service that offers a web access, and provide insights that help to explain why it is not self-explanatory that a secure cloud service should have a web interface. I also hope that this post made a point, how a badly constructed browser access can exploit common web access vulnerabilities.

We are working hard to ward off all those risks, or at least minimize the possibility of losing control over your data. We would like to provide a web interface because we are committed to easy usability. But we are also committed to maximum security without compromise, so until we are 100% sure that your data will be safe, we won’t offer you fake secure solution for web access, unlike others.