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.
- Browser and website vulnerabilities
- Danger of phishing
- Bad random generators
- 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:
- 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.
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!
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.