From the translator and TL;DR
TL;DR:
It seems that VoLTE is even more poorly secured than the first Wi-Fi clients with WEP. This is an architectural miscalculation that allows for some XORing of traffic and recovery of the key. The attack is possible if you are near the caller and they make frequent calls.
Thanks for the tip and TL;DR
Researchers have developed an app to determine if your carrier is vulnerable, more details . Please share your results in the comments; in my area, VoLTE is disabled on MegaFon.
About the Author
Matthew Green.
I am a cryptographer and a professor at Johns Hopkins University. I have developed and analyzed cryptographic systems used in wireless networks, payment systems, and digital content protection platforms. In my research, I explore various ways to use cryptography to enhance user privacy.
I haven't written a post in the format of , and that has been frustrating for me. Not because there haven't been attacks, but mainly because there hasn’t been an attack on something sufficiently widely used to pull me out of my creative slump.
But today I came across an called ReVoLTE on the protocols, the hacking of which particularly delights me, namely, the protocols of cellular networks (voice over) LTE. I am excited about these protocols—and this new attack—because it is very rare to witness the hacking of actual cellular network protocols and implementations. This is mainly because these standards are developed in smoke-filled rooms and documented in 12,000-page documents that not every researcher can tackle. Moreover, executing these attacks forces researchers to use complex radio protocols.
Thus, serious cryptographic vulnerabilities can spread worldwide and may only be used by governments before any researcher pays attention to them. But every now and then, there are exceptions, and today’s attack is one of them.
Authors : David Rupprecht, Katharina Kohls, Thorsten Holz, and Christina Pöpper from the Ruhr University Bochum and New York University Abu Dhabi. This is a wonderful attack on key reinstatement in the voice protocol that you are probably already using (assuming you are from the older generation that still makes phone calls with a mobile phone).
To begin with – a brief historical overview.
What are LTE and VoLTE?
The foundation of our modern mobile communication standards was laid in Europe back in the 1980s with the standard (GSM). GSM was the first major standard of digital cellular communication that introduced several revolutionary features, such as the use of to protect phone calls. Early GSM was primarily designed for voice communication, although it was possible to .
As the importance of data transmission in mobile communications grew, Long Term Evolution (LTE) standards were developed to streamline this type of communication. LTE is based on a set of older standards, such as GSM, and and is intended to increase data transfer speeds. There is a lot of branding and but TL;DR is that LTE is a data transmission system that serves as a bridge between older packet-switched protocols and future mobile data transmission technologies. .
Of course, history tells us that once sufficient (IP) bandwidth is available, concepts like ‘voice’ and ‘data’ will begin to blur. The same applies to modern mobile protocols. To make this transition smoother, LTE standards define (VoLTE), which is an IP standard for transmitting voice calls directly over the data transmission plane of the LTE system, completely bypassing the switched portion of the mobile network. Like standard VoLTE calls can be terminated by the mobile operator and connected to the regular telephone network. Or (which is becoming increasingly common) they directly from one mobile client to another, and even between different providers.
Like standard VoIP, VoLTE is based on two popular IP-based protocols: Session Initiation Protocol – SIP) for call setup, and Real Time Transport Protocol, which should be called RTTP, but is actually called RTP) for handling voice data. VoLTE also adds some additional bandwidth optimization, such as header compression.
So, what does this have to do with encryption?
LTE, like , has a standard set of cryptographic protocols for encrypting packets during their transmission over the air. They are primarily intended to protect your data while it is moving between the phone (referred to as the 'User Equipment' or UE) and the cell tower (or wherever your provider chooses to terminate the connection). This is because mobile providers consider external eavesdropping devices as enemies. Naturally.
(However, the fact that VoLTE connections can occur directly between clients in different provider networks means that the VoLTE protocol itself has some additional, optional encryption protocols that may take place at higher network layers. This is not relevant to the current article, except for the fact that they can mess everything up. We will briefly discuss them later).
Historically, encryption in GSM had : poor , protocols where only the phone authenticated with the tower (meaning that an attacker could impersonate the tower, creating a ), and so on. LTE fixed many of the obvious errors while retaining much of the previous structure.
Let's start with the encryption itself. Assuming that key generation has already occurred — and we will talk about that in a minute — each data packet is encrypted using a stream cipher with something called ‘EEA’ (which can practically be implemented using items like AES). Essentially, the encryption mechanism here is , as shown below:
The main algorithm for encrypting VoLTE packets (source: ). EEA – the cipher, “COUNT” – a 32-bit counter, “BEARER” – a unique session identifier that separates VoLTE connections from regular internet traffic. “DIRECTION” indicates the traffic flow direction – from UE to the tower or vice versa.
Since the encryption algorithm itself (EEA) can be implemented with a strong cipher like AES, it is unlikely that there will be any direct attacks on the cipher itself, as has been However, it is evident that even with a strong cipher, this encryption scheme represents a great way to shoot oneself in the foot.
Specifically: the LTE standard uses an (unauthenticated) stream cipher with a mode that will be extremely vulnerable if the counter – and other inputs such as “bearer” and “direction” – are ever reused. In modern parlance, this concept is termed a “nonce reuse attack,” but the potential risks are not something new. They are known and ancient, dating back to the glam metal and even disco eras.
Nonce reuse attacks in CTR mode existed back when Poison became well-known.
To be fair, the LTE standards state: “Do not reuse these counters, please.” But the LTE standards span about 7000 pages, and in any case, it's like begging toddlers not to play with a gun. They will inevitably do so, and terrible things will happen. In this case, the discharging gun is a key stream reuse attack, where two different confidential messages are XOR’d with the same key stream bytes. It is known that this .
So what is ReVoLTE?
The ReVoLTE attack demonstrates that in practice, this very vulnerable encryption scheme is incorrectly used by real equipment. Specifically, the authors analyze actual VoLTE calls made using commercial equipment and show that they can exploit something called a “key reset attack.” (Much credit for identifying this issue goes to (Raza & Lu), who were the first to point out a potential vulnerability. However, ReVoLTE research turns it into a practical attack.
Let me briefly show you the essence of the attack, although you should also take a look at .
It can be assumed that once LTE establishes a data packet transmission connection, the task of transmitting voice over LTE becomes just a matter of routing voice packets through that connection along with all your other traffic. In other words, VoLTE will be a concept that exists only above [OSI model – example]]. This is not entirely accurate.
In fact, the LTE channel layer introduces the concept of a "bearer." A bearer is a separate session identifier that differentiates various types of packet traffic. Regular internet traffic (your Twitter and Snapchat) goes through one bearer. SIP signaling for VoIP goes through another, and voice traffic packets are handled on a third. I'm not very familiar with the mechanisms of radio channels and LTE network routing, but I assume this is done precisely because LTE networks want to ensure the operation of QoS (Quality of Service) mechanisms, so that different packet streams are processed with different priority levels: i.e., your lower priority TCP connections to Facebook may have a lower priority than your real-time voice calls.
This is generally not a problem, but the implications are as follows. Keys for LTE encryption are generated separately each time a new bearer is established. In principle, this should happen anew every time you make a new phone call. This will result in different encryption keys being used for each call, eliminating the possibility of reusing the same key for encrypting two different sets of voice call packets. In fact, the LTE standard states something like, "you must use different keys every time you set up a new bearer to handle a new phone call." But that doesn't mean it actually happens that way.
In fact, in real implementations, two different calls occurring in close temporal proximity will use the same key — even though new (similarly named) bearers are set up between them. The only practical change that occurs between these calls is that the encryption counter is reset to zero. In the literature, this is sometimes referred to as . One could argue that this is essentially an implementation flaw, although in this case, the risks appear to largely stem from the standard itself.
In practice, this attack leads to key stream reuse, where an attacker can obtain encrypted packets $inline$C_1 = M_1 oplus KS$inline$ and $inline$C_2 = M_2 oplus KS$inline$, allowing the computation of $inline$C_1 oplus C_2 = M_1 oplus M_2$inline$. Better yet, if the attacker knows one of $inline$M_1$inline$ or $inline$M_2$inline$, they can immediately recover the other. This gives them a strong incentive to discover one of the two unencrypted components.
This leads us to the complete and most effective attack scenario. Consider an attacker who can intercept radio traffic between the target phone and the cell tower and who somehow "gets lucky" recording two different calls, where the second occurs immediately after the first. Now imagine that they can somehow guess the unencrypted content of one of the calls. In such a lucky circumstance our attacker can completely decrypt the first call using a simple XOR between two sets of packets.
Of course, luck has nothing to do with it. Since phones are designed to receive calls, an attacker who can listen in on the first call will be able to initiate a second call exactly when the first ends. This second call, if reusing the same encryption key with the counter reset to zero, will allow the recovery of unencrypted data. Furthermore, since our attacker effectively controls the data during the second call, they can recover the contents of the first call — thanks to numerous specifically implemented details, working in their favor.
Here is an illustration of the overall attack plan, taken from :
Attack Overview from . This scheme assumes that two different calls occur using the same key. The attacker controls a passive sniffer (top left) and a second phone, which they can use to make a second call to the victim's phone.
So, does the attack really work?
On one hand, this is indeed the main question for an article about ReVoLTE. Theoretically, all the ideas outlined above are brilliant but raise many questions. Such as:
- Is it possible for (academic researchers) to truly intercept a VoLTE connection?
- Do real LTE systems indeed re-establish keys?
- Can you actually initiate a second call quickly and reliably enough for the phone and tower to reuse the key?
- Even if systems re-establish keys, can you actually discern the unencrypted content of the second call—considering that factors like codecs and transcoding could completely alter (bitwise) the content of that second call, even if you have access to the 'bits' coming from your attacking phone?
Some of these questions are answered affirmatively in the ReVoLTE work. The authors use a commercial software-defined radio sniffer called to intercept the VoLTE call from the downlink side. (I think that simply mastering the software and having a basic understanding of how it works took months off the lives of poor grad students — which is typical for such academic research).
The researchers found that for key reuse to occur, the second call must happen quickly after the first one concludes, but not too quickly—around ten seconds for the operators they experimented with. Fortunately, it does not matter if the user answers the call within that time—the 'call,' i.e., the SIP connection itself, prompts the operator to reuse the same key.
Thus, many of the most troublesome issues revolve around problem (4) – obtaining bits of unencrypted content from a call initiated by an attacker. This happens because your content can undergo various changes as it moves from the attacker’s phone to the victim’s phone via the cellular network. For example, there can be mischief such as re-encoding the encoded audio stream, which keeps the sound the same but completely alters its binary representation. Header compression for RTP is also used in LTE networks, which can significantly alter a large part of the RTP packet.
Finally, packets sent by the attacker must line up roughly with the packets sent during the initial phone call. This can be problematic since modifying silence during a phone call leads to shorter messages (known as comfort noise), which can poorly align with the original call.
is worth reading in detail. It discusses many of the aforementioned issues – in particular, the authors discovered that some codecs are not re-encoded, and that about 89% of the binary representation of the target call can be reconstructed. This is relevant for at least two European operators that were tested.
This is an astonishingly high success rate, and frankly, much higher than I expected when I started working on this document.
So what can we do to fix this?
The immediate answer to this question is quite simple: since the essence of the vulnerability lies in the reuse (reinstallation) of the key, just fix that issue. Ensure that a new key is obtained for each phone call, and never allow the packet counter to reset back to zero with the same key. Problem solved!
Or maybe not. This will require upgrading a large amount of equipment and, frankly, such a fix alone isn't very reliable. It would be nice if standards could find a safer way to implement their encryption modes that isn't by default catastrophically vulnerable to problems like key reuse.
One possible option is to use . This may be too costly for some modern hardware, but it is certainly a direction that designers need to think about in the future, especially considering that 5G standards are about to take over the world.
This new research also raises the broader question of why , many of which use very similar constructs and protocols. When you encounter the issue of reinstalling the same key across several widely used protocols like WPA2, doesn't it seem like it's time to make your specifications and testing procedures more rigorous? Stop treating standard implementers as thoughtful partners who are attentive to your warnings. Treat them like (unintentional) adversaries who are inevitably going to implement everything wrong.
Or alternatively, we could do what companies like Facebook and Apple are increasingly doing: ensure that encryption of voice calls happens at a higher level of the OSI network stack, without relying on cellular equipment manufacturers. We could even promote end-to-end encryption of voice calls, as WhatsApp does with Signal and FaceTime, assuming the U.S. government would simply stop . Then, (except for some metadata) many of these problems would simply disappear. This solution is particularly relevant in a world where .
Or we can simply do what our kids already did: just stop answering those annoying voice calls.
Source: habr.com
