Sunday, April 21, 2013

TLS is the standard which defines how web traffic is encrypted. It is what keeps your credit card secure when you buy something on the internet, and it is what should be used (but sometimes isn't) to make sure a password is not snooped when you log into a web site. You know when a web site uses TLS, because the location uses the https prefix and not the http prefix.

In recent months we have seen a lot of "attacks" on TLS. Many with cool names such as BEAST, CRIME, Lucky 13 and TIME. There has also been a recent one involving an attack on using RC4 within TLS, which alas does not have a cool name. Many of these attacks make use of timing information leakge (aka side channels) and some (Lucky 13 and the RC4 attack) attack the underlying cryptography.

Before proceeding we should perhaps recap on a bit of history. Firstly TLS comes in three flavours, TLS 1.0, TLS 1.1 and TLS 1.2. Now TLS 1.2 has been around since 2008, and is the latest version, it fixes a number of problems with earlier versions and should be used by default. So now guess how many systems use TLS 1.2? It turns out virtually none. Most browsers and web sites use the old versions of TLS, and the main reason for not upgrading is said to be because people do not see the benefit of moving to the newer standard. Indeed at a recent meeting, one person said to me that all the recent attacks on TLS are not real attacks as they will not affect anyone in the real world.

Let us now look at the problems these attacks show up.

The timing based attacks are basically a form of side-channel attack, and side-channels have been known in the cryptographic community since the late 1990s. Indeed there is a whole conference, CHES, which devotes much of its discussion to looking at side-channel attacks in their various forms and how to protect against them. It seems rather hard to believe that after so many years, one of the key pieces of security infrastructure we rely on still falls to side-channel attacks. After all they have been known about for years, so why would one not want to defend against them?

The Lucky 13 attack is an attack on the method used to encrypt data. It uses a method known as "MAC-then-Encode-then-Encrypt". It has been known, again since the turn of the century, that methodologies such as "MAC-then-Encrypt" (of which MAC-then-Encode-then-Encrypt is a variant) are not a good design practice. Modern cryptographers have for nearly 15 years been requiring the use of a method known as "Encrypt-then-MAC", which is known to be much more secure. Indeed it comes with a mathematical proof of security, and TLS 1.2 comes with an even better solution, namely a fully integrated Authenticated Encryption algorithm called GCM. For those readers doing undergraduate courses, this basically means that TLS 1.0 and TLS 1.1 do not use an IND-CCA encryption algorithm; whereas TLS 1.2 does. So again we have that the basic internet security infrastructure is using a method which has known to be suspect for a long time, and for which simple fixes have also been known for years.

If you want to avoid some of the problems with "MAC-then-Encode-then-Encrypt" then a simple solution would be to use a stream cipher to do the encryption. And TLS 1.0 and TLS 1.1 allow one to use such a stream cipher; indeed they allow the use of the RC4 stream cipher. But RC4 has been known to have structural weaknesses, which means that the key stream it produces is not random enough for modern cryptographic use. How long have these weaknesses been known? Well about the same length of time.

So we have in all cases that the current attacks show that the deployed software has weaknesses, and these weaknesses have been known for a very long time. All the new attacks do is show how to exploit these weaknesses within TLS. Yet still people are claiming TLS 1.0 and 1.1 is secure. After all the attacks are rather contrived and do not apply to most real world instantiations of TLS!

Does this remind one of another recent case of security engineers ignoring the advice of cryptographers for many years? Well it should. In the mid 1990's various structural weaknesses were found in the MD family of hash functions, including MD5 which was used all over the internet. But since no real world attacks were found the security engineers did not see the point of replacing MD5 in their software. When real attacks on MD5 came along, which compromised security for real world users, cryptographer could claim a great big "We told you so", and engineers then had to spend (and are still spending) a great deal of effort removing uses of MD5 in software.

In some sense the recent attacks are basically an early warning sign, that the security concerns of the cryptographic community re TLS 1.0 and TLS 1.1 are getting closer to real world attacks. It is still probably safe to send your credit card details over the internet, but for how long? When will a total break occur? No one knows. The simplest quick solution is to move to TLS 1.2, and hopefully that is what browser vendors, web sites and software producers will now do. But this is hard, there is no point in your browser using TLS 1.2, unless the web site also uses TLS 1.2.

Lets hope the change is made, before the cryptographic community has another round of "We told you so".

Friday, April 5, 2013

Modern cryptography is about so much more than encryption; as follows of this blog will know. Last month I discussed how the technique of secure multi-party computation (MPC) can be used to provide defence mitigation techniques for servers. By splitting up a secret held on one server into two secrets held on two servers one can mitigate against a single server being compromised by an attacker. The functionality provided by the secret is then still accessed, but via a secure multi-party computation protocol. What is surprising is that such a protocol is now really practical; whereas a few years ago it would have been inconceivable to think about implementing it.

But there are all sorts of other cool things one can do with MPC. A recent video by our Estonian friends on YouTube shows an application of MPC to the world of space. The problem statement is quite simple; there are so many man made satellites orbiting the earth that it is likely that two will collide. Given how expensive this is, in terms of replacing the satellite, people want to avoid this. However, the location of each satellite can be a closely gaurded secret; it can even be a national secret. So what we want is a way for two parties to compute whether two satellites are about to hit each other, without either party learning the location of the other satellite in the case where they are not about to hit each other (if they are going to hit each other then the location of the collision is in some sense going to leak by definition). As expected this is another practical, real world application, for multi-party computation.

So with MPC being used to stop satellites hitting each other cryptographers really are becoming rocket scientists.