Lack of LTE Data Integrity Allows Attackers to Control Mobile Connections

 July 30, 2018  |  By Joel Odom

Most mobile devices rely on the LTE protocol for high-speed wireless data. A group of security researchers have recently shown that, due to a lack of data integrity protection for user data transmitted over LTE, it is possible for an attacker to alter the data received by an LTE device -- redirecting internet connections from the intended endpoint to one controlled by the attacker. The attack, named "aLTEr," starts by causing the mobile device to connect to an attacker-controlled simulation of the device’s mobile network. The simulated network acts as a "man in the middle" between the mobile device and the legitimate network. Because LTE offers encryption for confidentiality, the attacker cannot directly read the victim’s traffic, but clever tricks allow the attacker to modify DNS replies, thus allowing IP traffic redirection.


IISP Analyst Joel Odom"When people think of encryption, the first thing that usually comes to mind is keeping secrets a secret. While confidentiality is important, data integrity is often more important. For example, I’ve often said that I prefer not to have my personal banking information leaked, but I really care more about the integrity of my bank account than its secrecy.
For the encryption of user data, LTE uses the AES block cipher in a mode called "counter mode" (often abbreviated as AES-CTR). What this means from a practical standpoint is that AES is used to create an unpredictable stream of pseudo-random bits that is mixed with the plaintext (the unencrypted data) using the XOR function. The problem with using AES-CTR is that a bit that is flipped in the ciphertext (the encrypted data) flips the corresponding bit in the plaintext. Computers exchange data in precisely-formatted protocols, so there are realistic cases where it’s easy for an attacker to predict which bits in the ciphertext correspond to protocol bits that the attacker can control for malicious purposes.
Thinking beyond this simple attack on DNS over LTE, consider the cases where distributed infrastructure is controlled using industrial control protocols over LTE. If the control messages rely on LTE’s encryption, an attacker could use this attack to do things like change a message that says “open this valve” to “close this valve.”
I urge protocol engineers to consult with cryptographers when protocols are designed to avoid these kinds of mistakes. Modern cryptography gives us authenticated encryption schemes that protect against attacks on integrity and confidentiality with little added computational overhead. AES-GCM is one example of an encryption scheme that could have been specified instead of AES-CTR to provide integrity protection. I should also mention that protection against replay attacks is important. We can get fancy by requiring more esoteric protections, such as forward secrecy and protection against traffic analysis, but AES-GCM with replay protection is usually good enough.
As the researchers who demonstrated the aLTEr attack point out, mobile applications that properly employ TLS will easily detect the connection problems and will, in the worst case, simply fail to connect. This demonstrates the need for layered protection. The end-to-end principle states that applications should provide their own end-to-end cryptography rather than relying on lower layers to provide link-level protection. Designers of systems that communicate over LTE or any other communication channels that the future may present would be well advised to build standard encryption schemes such as TLS into their applications."


For further reading


Joel Odom leads a team of researchers focused on software security as branch head for the Cybersecurity, Information Protection, and Hardware Evaluation Research (CIPHER) Laboratory at the Georgia Tech Research Institute. He and his team research static and dynamic software analysis, software testing techniques, software reverse engineering, and software vulnerability discovery and mitigation.

More by the author(s)