I like talk about the attack on LTE and that this protocol is not as secure as previously thought. Since then, the researchers behind the LTE vulnerabilities have published a PoC code and a video demonstrating the attack.
But the story doesn't end there.
A few days ago, the same specialists from the Ruhr University spoke about a new vulnerability in LTE, which they called revoLTE.
To begin with, a brief historical excursion.
LTE and VoLTE
The foundation for modern cellular telephony standards was laid in the 1980s with the advent of the Global System for Mobile. GSM was the first major digital cellular telephony standard to introduce a number of advanced features at the time, such as the use of encryption to secure phone calls. GSM was developed primarily for voice communications, although it also allowed other data to be transmitted.
With the increasing importance of data transmission, Long Term Evolution (LTE) standards have been developed to rationalize this type of communication. LTE is based on a group of older standards such as GSM, EDGE and HSPA and is designed to improve data transfer rates. There is a lot of branding and misrepresentation in this area, but the point is that LTE is a data transmission system that serves as a bridge between old packet data protocols and future 5G cellular data technologies.
History tells us that once there is enough (IP) bandwidth, concepts like “voice” and “data” will start to blur. The same is true for modern cellular protocols. To make this transition smoother, LTE standards define Voice-over-LTE (VoLTE), which is an IP standard for transferring voice calls directly over the LTE data plane, bypassing the switched portion of the cellular network entirely. As with standard VoIP calls, VoLTE calls can be terminated by your mobile operator and connected to the regular telephone network. Or they can be routed directly from one cellular 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 actually called RTP) for processing voice data. VoLTE also adds some additional bandwidth optimizations such as header compression.
What does encryption have to do with it?
LTE, like GSM, has a standard set of cryptographic protocols for encrypting packets as they travel over the air. They are primarily designed to protect your data as it travels between your phone (called user equipment, or UE) and your cellular antenna. This is because cellular providers view external eavesdropping devices as enemies.
GSM encryption had many weaknesses: bad ciphers, protocols in which only the phone was authenticated at the tower (which means that an attacker could impersonate the tower, for example, as in the Stingray attack), and so on. LTE has fixed many of the obvious bugs while retaining much of the old structure.
Let's start with the encryption itself. Assuming that the key generation has already taken place - and we'll talk about that in a minute - then each packet of data is encrypted using streaming encryption using some kind of cipher called "EEA" (which in practice can be implemented using things like AES). Essentially, the encryption mechanism here is CTR , as shown below:
Basic VoLTE packet encryption algorithm (source: ReVoLTE). EEA is a cipher, "COUNT" is a 32-bit counter, "BEARER" is a unique session identifier that separates VoLTE connections from regular Internet traffic. "DIRECTION" indicates in which direction the traffic is going - from the UE to the tower or vice versa.
Since the encryption algorithm itself (EEA) can be implemented using a strong cipher like AES, it is unlikely that there will be any direct attack on the cipher itself, as was the case in the days of GSM . However, it is clear that even with a strong cipher, this encryption scheme is a great way to shoot yourself in the foot.
LTE uses a (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, the term for this is "nonce reuse attack," but the potential risks here are not modern. They are famous and ancient, dating back to the days of glam metal and even disco.
To be fair, the LTE standards say: "Do not reuse these meters, please." But LTE standards are about 7,000 pages long, and anyway, it's like begging toddlers not to play with a gun. They will inevitably do it, and terrible things will happen. In this case, the unloading pistol is a keystream reuse attack in which two different confidential messages are XORed with the same keystream bytes. This is known to be extremely damaging to the confidentiality of messages.
What is ReVoLTE?
The ReVoLTE attack demonstrates that in practice this highly vulnerable encryption design is misused by real hardware. In particular, the authors analyze real VoLTE calls made using commercial equipment and show that they can use something called a "key reset attack". (Much of the credit for finding this problem belongs to raise and Lou (Raza & Lu), who first pointed out the potential vulnerability. But research ReVoLTE turn it into a practical attack).
Let me give you a quick look at the attack, although you should also look at the original document.
It can be assumed that once LTE establishes a packet data connection, the task of transmitting voice over LTE becomes just a matter of routing the voice packets over that connection along with all your other traffic. In other words, VoLTE will be a concept that only exists above Level 2. This is not entirely true.
In fact, the LTE data link layer introduces the concept of "bearer". Bearers are separate session IDs that separate different types of packet traffic. Normal internet traffic (your Twitter and Snapchat) goes through one bearer. SIP signaling for VoIP goes through the other, and the voice traffic packets are processed on the third. I am not very familiar with LTE radio and network routing mechanisms, but I believe that it is done this way, because LTE networks want to provide QoS (quality of service) mechanisms so that different packet streams are processed with different priority levels: i.e. your second-rate TCP connections to Facebook may have a lower priority than your real-time voice calls.
This is generally not a problem, but the consequences are as follows. LTE encryption keys are generated separately each time a new "bearer" is installed. Basically, this should happen again every time you make a new phone call. This will result in a different encryption key being used for each call, eliminating the possibility of reusing the same key to encrypt two different sets of voice call packets. Indeed, the LTE standard says something like "you have to use different keys every time you install a new bearer to handle a new phone call." But this does not mean that this is actually the case.
In fact, in real implementations, two different calls occurring in close temporal proximity will use the same key - despite the fact that new (of the same name) bearer is configured between them. The only practical change that happens between these calls is that the encryption counter is reset to zero. In the literature, this is sometimes called a key reinstallation attack . It can be argued that this is essentially an implementation error, although in this case the risks seem to largely stem from the standard itself.
In practice, this attack leads to reuse of the key stream, where an attacker can receive encrypted packets C1 = M1⊕KS and C2 = M2⊕KS, which allows calculating C1⊕C2 = M1⊕M2. Even better, if an attacker knows one of M1 or M2, then he can immediately recover the other. This gives him a strong incentive to learn 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 a target phone and a cell tower, and is somehow “lucky” to record two different calls, with the second occurring immediately after the first. Now imagine that he can somehow guess the unencrypted content of one of the calls. With such a fluke, our attacker can completely decrypt the first call using a simple XOR between the two sets of packets.
Of course, luck has nothing to do with it. Since telephones are designed to receive calls, an attacker who can eavesdrop on the first call will be able to initiate the second call at the very moment when the first one ends. This second call, if the same encryption key is reused with the counter reset to zero, will allow unencrypted data to be recovered. Moreover, since our attacker actually controls the data during the second call, he can recover the contents of the first call - thanks to a lot of specifically implemented little things playing on his side.
Here is an image of the general attack plan, taken from the original document:
An overview of the attack from the ReVoLTE document. This scheme assumes that there are two different calls occurring using the same key. The attacker controls a passive sniffer (top left), as well as a second phone, with which he can make a second call to the victim's phone.
So does the attack really work?
On the one hand, this is really the main question for the article on ReVoLTE. In theory, all of the above ideas are great, but they leave a lot of questions. Such as:
- Is it possible (for academic researchers) to actually intercept a VoLTE connection?
- Do real LTE systems really re-key?
- Can you actually initiate a second call quickly and reliably enough for the phone and tower to reuse the key?
- Even if the systems reinstall the keys, can you actually find out the unencrypted content of the second call - given that things like codecs and transcoding can completely change the (bitwise) content of that second call, even if you have access to the "bits" coming from your attacking phone?
The researchers found that for key reuse to be triggered, the second call had to happen quickly enough after the first was complete, but not too fast about ten seconds for the operators they experimented with. Fortunately, it doesn't matter if the user answers the call during this time - “ringing”, ie. the SIP connection itself forces the operator to reuse the same key.
So many of the crappy problems revolve around problem (4) - getting bits of the unencrypted content of an attacker-initiated call. This is because a lot of things can happen to your content as it travels from the attacker's phone to the victim's phone over the cellular network. For example, transcoding an encoded audio stream, which leaves the sound the same but completely changes its binary representation. LTE also uses RTP header compression, which can significantly alter a large portion of the RTP packet.
Finally, the packets sent by the attacker should line up roughly with the packets that went on the first phone call. This can be problematic, as modifying the silence during a phone call results in shorter messages (aka comfort noise) that may not fit well with the original call.
The "real world attack" section is worth reading in full detail. It addresses many of the above issues - in particular, the authors found that some codecs were not recoded and that approximately 89% of the target call's binary representation could be recovered. This is true for at least two European operators that have been tested.
This is a surprisingly high level of success, and, frankly, much higher than I expected when I started working on this document.
The authors also posted a video with a demonstration:
Demo video of the revoLTE attack.
So what can we do to fix it?
The immediate answer to this question is extremely simple: since the essence of the vulnerability is an attack on reuse (reinstallation) of a key, just fix this problem. Make sure you get a new key for every phone call, and never let the packet counter reset the counter back to zero with the same key. Problem solved!
Or maybe not. This will require the modernization of a large number of equipment, and, frankly, such a fix in itself is not super reliable. It would be nice if the standards could find a more secure way to implement their encryption modes that is not catastrophically vulnerable by default to such key reuse issues.
One of the possible options is to use encryption modes in which the misuse of the nonce does not lead to catastrophic consequences . It might be too expensive for some modern hardware, but it is definitely a direction that designers should think about in the future, especially given that 5G standards are about to take over the world.
This new study also raises the general question of why the same damn attacks keep popping up in one standard after another, many of which use very similar constructs and protocols. When you are faced with the problem of reinstalling the same key in several widely used protocols such as WPA2, don't you feel like it's time to make your specifications and testing procedures more reliable? Stop treating standards implementers as thoughtful partners, attentive to your warnings. Treat them like (unintentional) adversaries who are inevitably going to do it wrong.
Or alternatively, we can do what companies like Facebook and Apple are increasingly doing: make encryption of voice calls occur at a higher level of the OSI network stack, without relying on cellular equipment manufacturers. We can even promote end-to-end encryption of voice calls, as WhatsApp does with Signal and FaceTime, assuming the US government will just stop tripping us . Then (with the exception of some metadata) many of these problems would simply disappear. This decision is especially relevant in a world where even governments are unsure if they trust their equipment suppliers.
Or we can just do what the ne