Yet despite the technological approach applied to every stage of telecommunications, there have always been specific designs regarding the information exchanging protocols used to set up a standardized language that allows devices to speak to each other.

As history has repeatedly taught us, this is where most security issues occur. We’ve seen it throughout history, from Caesar’s ciphers through World War II’s Enigma machine all the way to today’s methods of high-speed communication, including virtual private networks, secure shells, voice over IP, and video calls.

Today’s topic covers a specific, recently discovered flaw by David Rupprecht, Katharina Kohls, Thorsten Holz, and Christina Pöpper (Ruhr University Bochum & New York University Abu Dhabi) which involves one of these communications protocols, Voice over LTE (VoLTE for short). LTE stands for Long Term Evolution and is a modern communications standard used by many companies to provide different services (using additional technologies) to customers.

What is Voice over LTE (VoLTE)?

Voice over LTE networks (also known as HD voice) are basically an additional feature to the whole LTE/4G stack that brings high-quality voice communications to LTE networks by using the actual LTE frequency bands. You may have noticed that when communicating by phone and your device or provider doesn’t have VoLTE enabled, there is a signal downgrade to a lower technology (such as 3G) to establish your voice connection.

Usually, these voice channels aren’t great, and call quality has been lagging behind Internet speed improvements for years. VoLTE has improved this by taking advantage of the LTE reserved spectrum and by sending voice in a voice over IP fashion.

Unveiling the ReVoLTE attack

The “Re” part of ReVoLTE indicates the attack technique used to deceive this technology’s protection measures, as in “Key Reuse”. This type of attack takes advantage of the kind of cipher implementation most popularly used for network transfers called stream cipher. Stream ciphers are commonly implemented by utilizing a shared secret key to encrypt information, by using a secret key that’s at least the same size as the actual ciphertext.

As shown in the example below, this method usually involves the fragmentation of every piece of information into frames that are encoded separately, then decoded in the same fashion. Here you can see the fragmentation of a certain two-letter plaintext into two different to-be-encoded pieces of information. Once every byte is encoded, the ciphertext is built.

Notice that the flow of an XOR stream cipher works in a simplified way, which is very efficient for network transmissions. And that’s what we all want when transmitting information between remote parties.

Once the transmission arrives its destination, it needs to be decoded. For that, it uses the exact same shared key to perform a XOR operation again, this time between the ciphertext’s frames and the key.

Modern communications are more complex, but these are the main components and functionality that involve this kind of stream cipher encryption.

Keystream reuse problems

The main issue with XOR keystream operations is that you can recover the actual key by operating the plaintext against the ciphertext. This means that an attacker who manages to sniff the encrypted message and obtains portions of the sent information could potentially discover the key that’s making the stream encryption possible.

In this next image, we follow the previous example and operate our plaintext separated frames against the resulting ciphertext, as if it was obtained by sniffing into network traffic.

This XOR permutation allows us to recover our secret key. With that, we’ll be able to decrypt the whole communication.

For this reason, security recommendations regarding stream ciphers involve the randomization of the keystream, at least per every transaction or transmission session.

To name a popular example, the now-infamous Wireless Enhanced Privacy (WEP) protection used by WiFi networks to protect themselves used this concept, and added an additional security measure by introducing an initialization vector (IV) in conjunction with the key at every stream. This IV was incremented sequentially to provide further randomization.

But as we’ve learned before, the weakest link in the chain is the one that weakens the whole chain.

The WEP implementation had predictability issues with its IV due to its small size (24 bits) and the fact that it was incremented by one every time a frame was sent.

These design decisions made the whole system vulnerable once an attacker managed to gather enough packets (by unauthenticated sniffing of the network) with the same keystream information, as IV’s tend to repeat themselves once the IV number reaches its maximum value.

ReVoLTE inner workings

As explained, keys in this context should never be used more than once, as it is computationally relatively easy to recover important pieces of information, if not all of it.

The research states that for decrypting the original call, there should be two calls involved where the attacker must conduct an xor of the known plaintext (which will be recorded through the attacker’s phone, explained below) against the ciphertext of the first call (also known as the target call, obtained by sniffing the network connected to the same mobile cell).

When the attacker finds a vulnerable base station, this means that the cell giving the phone line service is reusing the keystreams in different phone calls. And as we’ve said earlier, this weakens the communication’s encryption.

The following is a live demonstration of the attack showing all parties involved. The victim in this scenario is the device that receives both calls (the first from a partner, and the second from an attacker).

The first call involves a valid communication between the victim and the partner. For this communication to be eavesdropped it must be established using the same mobile cell as the attacker.

Also, the attacker needs to be prepared, having already configured all elements to obtain packets from mobile communications. To accomplish this, the attack’s researchers have configured a downlink analyzer called Airscope to sniff traffic and a set of three Android phones with SCAT installed that allows them to capture the signals.

Once the call is established between the victim and the partner, the attacker sniffs packets from the vulnerable base station and stores them locally while getting ready to dial the victim—right after the previous call has ended.

As shown in the video, the attacker calls the victim and establishes a brand new call that should last about the same time as the call previously placed with the partner. This will allow the attacker to recover enough unencrypted communications with its associated keystreams to enable full conversation recovery.

Once the second call has ended, the recovered information is processed locally by the attacker. As our demonstration shows, this technique has managed to gather all the voice traffic of the first call.

Analyze your own network

How vulnerable is your provider? This is a valid question, and in terms of attacks against these types of infrastructures it’s one that’s difficult to answer. Fortunately, ReVoLTE researchers have developed a mobile application that performs this assessment for us to check and for companies to conduct an attack surface analysis .

This application, Sentinel, is available only for Android devices with Qualcomm chips. You can download the .apk package from their Github repository.

And while it may seem obvious, you need to ensure the mobile provider has VoLTE capabilities—otherwise you’ll get a message like this:

When running correctly, you’ll see the label isVolteEnabled set to “True” as shown here:

By using this you can determine if your target network is VoLTE capable as well as if it’s vulnerable. As the researchers stated when conducting random testing throughout different countries, they found around 12 radio cells vulnerable out of 15 total base stations tested.

Summary

We’ve covered this novel attack against telecommunications by sharing the researchers’ approach of using a well known vulnerability against vulnerable LTE cells that are either misconfigured or badly implemented.

Cryptographic implementations don’t come without challenges, however, and especially in this area the devil is in the actual details. With software architectural designs it’s highly important to consider data at every step. That may be easier said than done, but when it comes to working with customers’ personal information (such as personal records or voice), we can always try to improve.