Without a doubt, telecommunications have evolved beyond the imagination. We can now do things on our smartphones and personal computers that we once saw only in the realm of science fiction.

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 ...