IT Security Vulnerabilities in Internet encryption protocol
Every time we use online banking or log into a web application, we are transmitting sensitive data such as passwords and account information via the Internet. Currently, they are not one hundred per cent secure.
People who check their emails, log in to the university Wi-Fi network Eduroam, or use an online shop rely on encrypted data transfer. After all, password and account data should be safe from interception by strangers. In all those applications, the same encryption protocol is deployed: TLS, short for Transport Layer Security. Until a few years ago, it was considered one hundred per cent secure.
A number of attacks on the protocol were performed around the world.
Jörg Schwenk
“Then, a number of attacks on the protocol were performed around the world, and people realised that it requires considerable optimisation,” explains Prof Dr Jörg Schwenk from the Chair for Network and Data Security. Together with his team, he was involved in several such attacks. The results gathered in the process are going to be incorporated into the latest TLS version, which is currently being standardised by the Internet Engineering Task Force.
Transport Layer Security was originally developed by the company Netscape, which released the first Internet browser to the market. “The developers bore in mind at a relatively early stage that a certain degree of protection is necessary in order to browse the Internet, for example online shops,” says Schwenk.
To this end, they released the encryption protocol Secure Socket Layer (SSL) in 1994, the later versions of which were renamed TLS. The current version is labelled 1.2. The follow-up version TLS 1.3 is expected to be available in 2016 or 2017. Virtually everything is going to be new in it, in more ways than one: on the actual encryption level as well as on the key negotiation level.
Two things are necessary in order to encode a message: an encryption protocol that describes which algorithm has to be used to alter the message, and a key that must be known to both parties in order to code and decode the message. The encryption protocol can be publicly known, the key must not. This is because it is crucial for decoding the message. As long as the key remains secret, the content of the message is protected.
In order for two parties to communicate in a secure manner – for example if a customer wishes to transfer credit card details to an online shop –, they have to agree on a key, i.e. negotiate a shared secret. During this process, security gaps may occur, in the same way as during the actual encryption.
Stealing the secret key
Jörg Schwenk’s team has, for example, successfully stolen the key that two parties negotiate with TLS 1.2. Generally speaking, key negotiation can be performed in three different ways; most problems are caused by the so-called RSA handshake protocol, named after its developers Rivest, Shamir and Adleman.
To put it in simple terms: the webshop server sends a letter box to the customer. The customer places a secret message into the letter box and sends it back to the server. The server, in turn, opens the letter box, thus accessing the secret message. That message then serves as the key which the customer uses to encrypt his credit card data.
Performing a so-called Bleichenbacher attack, Schwenk’s team gained access to the key: for this purpose, the IT security experts fed errors into the secret message, before putting it in the letter box and sending it to the server. They repeated the action more than once, slightly modifying the secret message each time.
The server expects that the incoming message has a specific form; it has to start with the numbers zero and two. Should that not be the case, the server’s error manager is launched. The messages sent by the RUB researchers contained deliberate errors, which means they did not always start with zero and two. Error management is more time-consuming than the server proceeding with key exchange as usual. This time lag gave clues regarding the contents of the message, i.e. the key that should remain secret.
More security with new TLS version
Such an attack on Transport Layer Security will no longer be possible to conduct in version 1.3. The RSA handshake protocol will be replaced by the Diffie-Hellman key exchange. Schwenk remembers: “My doctorate supervisor Albrecht Beutelsbacher has explained the protocol as follows: two secret ingredients are put in a recipe. Once the whole is stirred, it is no longer possible to identify those two ingredients.” Consequently, nobody can replicate the recipe.
In order to generate the key, each of the two parties who communicate with each other comes up with a sub-secret, and the individual parts are then blended to create the key. Subsequently, both parties delete the secret ingredients which they had used to generate the sub-secrets. Without those ingredients, the key cannot be recalculated.
Intelligence agencies in the United States can force companies to hand over keys used to encode their customers’ data.
Jörg Schwenk
This is also relevant for approaches practised by intelligence agencies. Schwenk explains: “Intelligence agencies in the United States can force companies to hand over keys used to encode their customers’ data.” Thus, intelligence agencies are able to record encrypted information in huge volumes and to backlog them; if they need to take a look inside, they procure the key from the respective enterprise and decipher the stored data. “But large corporations such as Google or Amazon don’t want to accept that,” says Schwenk.
The Diffie-Hellmann protocol will make it impossible to decipher data gathered in the past, because the secret ingredients used for generating the key will be deleted the moment they are no longer required. “As a result, intelligence agencies will be able to intercept only current and future information,” says the researcher from Bochum, “but no longer past ones.”
Security gaps in earlier protocol versions
The attack described above is one of many examples of the research conducted by the RUB team into TLS security. Dr Juraj Somorovsky, researcher at the Chair for Network and Data Security, was involved in the “Drown attack” that generated a buzz in March 2016. He and his colleagues bypassed the security mechanisms of the current TLS version 1.2 by using a previous version to gain access.
Old SSL and TLS versions are often installed on servers in order to support as many different browsers are possible; this is because older browsers are often incompatible with new security protocols. Exploiting vulnerabilities in the dated protocols, the researchers successfully disabled the current TLS security mechanisms during the Drown attack. In a similar fashion, another team at the Chair for Network and Data Security succeeded in creating fake digital signatures in the current TLS version 1.2.
TLS encryptions cracked every year
This is how the RUB researchers contributed to re-engineering Transport Layer Security. “However, the reason why this had to be done were the numerous attacks on encryptions, not on key negotiations,” points out Jörg Schwenk. Every year, TLS encryptions were cracked in one way or another. Schwenk: “It became obvious that the entire design is fairly poor.”
Security issues are not the only reason for the new TLS standard. Google, for example, advocated a new protocol for key negotiations, because the current handshake is too slow.
Jörg Schwenk’s motivation for contributing to the process is quite different. It’s certainly not about the money. “I want to conduct relevant research that makes an impact,” he says. Like his research into Transport Layer Security, which is deployed in practical applications.
