CSAI: Open-Source Cellular Radio Access Network Security Analysis Instrument

CSAI: Open-Source Cellular Radio Access Network Security Analysis Instrument

Thomas Byrd and Vuk Marojevic Dept. of Electrical and Computer Engineering
Mississippi State University
Mississippi State, MS
{tkb140, vuk.marojevic}@msstate.edu
   Roger Piqueras Jover1 1Author did not contribute to source code. Code published to accompany this paper was written by Mr. Thomas Byrd and Dr. Vuk Marojevic. Bloomberg LP
New York, NY

This paper presents our methodology and toolbox that allows analyzing the radio access network security of laboratory and commercial 4G and future 5G cellular networks. We leverage a free open-source software suite that implements the LTE UE and eNB enabling real-time signaling using software radio peripherals. We modify the UE software processing stack to act as an LTE packet collection and examination tool. This is possible because of the openness of the 3GPP specifications. Hence, we are able to receive and decode LTE downlink messages for the purpose of analyzing potential security problems of the standard. This paper shows how to rapidly prototype LTE tools and build a software-defined radio access network (RAN) analysis instrument for research and education. Using CSAI, the Cellular RAN Security Analysis Instrument, a researcher can analyze broadcast and paging messages of cellular networks. CSAI is also able to test networks to aid in the identification of vulnerabilities and verify functionality post-remediation. Additionally, we found that it can crash an eNB which motivates equivalent analyses of commercial network equipment and its robustness against denial of service attacks.

open-source LTE, SDR, paging, radio access network signaling, analysis, wireless security

I Introduction

The Long Term Evolution (LTE) is a cellular communications standard developed by the 3rd Generation Partnership Project (3GPP). LTE was finalized in 3GPP Release 8 in December 2008, and LTE-Advanced followed in 3GPP Release 10. Only recently has there been significant enough open source software development efforts for producing stable implementations of the LTE and LTE-A specifications to allow for rapid prototyping and testing of 4G networks by the broader research community.

Next generation 5G networks promise a huge leap from 4G. The reality however is that the initial 5G releases leverage LTE networks in many regards: New Radio (NR) initially implements a similar radio access network (RAN) and hooks to the LTE evolved packet core (EPC). 5G generally allows more flexible waveform and protocol configurations, transmission in sub 6 GHz and millimeter wave bands, and higher bandwidths than LTE. The signaling will initially be OFDM, for example, where the 5G signaling frame will carry data and control information. Starting in 3GPP Release 15, 5G frames, channels, and signals are specified in the standards specifications.

There is a huge need for research and development tools that enable cellular signaling analysis for a multitude of purposes. It can help understand the limitations of current implementations and guide the evolution of the standard. They can also be effectively used for education and training. Security is another important aspect where RAN signaling analysis is needed. It has been shown that the LTE control signaling suffers from targeted interference that an adversary can exploit, easily and cheaply [1]. We therefore propose a flexible signal analysis tool for analyzing commercial and experimental cellular communication systems, assisting in the detection of potential vulnerabilities, and evaluating corrective measures which will pave the path to secure wireless networks.

This paper leverages open-source software implementations of LTE and develops a free open-source cellular RAN security analysis instrument, CSAI. CSAI is lightweight and can process data in real time. It interfaces with common software radio front ends, such as Ettus Research USRPs, and can capture LTE control messages and be easily extended to capture 5G NR signals. It can emulate an eNodeB (eNB) or user equipment (UE) and implement specific processes to test the behavior of the UE or eNB. It also allows testing larger RANs which involve multiple UEs or multiple eNBs. For example, in commercial networks that have dozens of UEs, or more, that rotate between serving cells, this tool will be able to monitor paging traffic in a particular cell and identify new UEs as they are paged for the purpose of signaling analysis.

It is very important to be able to analyze protocol edge cases and understand their implications in terms of RAN security. Not only can it be used for analyzing the standard specifications of a modern cellular standard, but this tool can also test vendor specific implementations. Additionally, it is a benchmarking tool for stress testing 4G and 5G networks and can be adapted to fit different use cases. For instance, if a vendor needs an automated tool to determine the limits of their Radio Resource Control (RRC) buffers, this instrument will be able to facilitate that.

The remainder of this paper is organized as follows. Section II briefly outlines other work in the area of capturing LTE messages and performing LTE security analyses. Section III describes the important LTE signaling over the RAN. This allows for better comprehension of Section IV, which introduces our software instrument for analyzing broadcast and paging messages. Section V discusses experiments and data collected from commercial networks. Section VI focuses on the security implications of our initial results, and Section VII concludes the paper.

Ii Related Work

Security research of cellular communications standards has a long history and helped evolve systems to the current 4G and emerging 5G networks [2]. The insecure 2G systems are still used today and whenever 4G or 3G coverage is not available, handsets look for 2G networks. 4G systems introduce network and user authentication, where a user can authenticate the network it connects to. However, certain 4G security vulnerabilities were identified that 5G networks intend to fix.

With the emergence of software radios, increasing processing power of general-purpose computers, and software implementations of cellular standards, experimental LTE security research took off [3]. Researchers dissected the entire LTE signaling frame looking for vulnerabilities of the system when specific subsystems are interfered with. Two types of attacks were examined, physical control channel jamming and spoofing, and mitigation mechanisms were proposed in [4] and [5]. Other research groups have more recently tested LTE’s higher layer signaling protocols and published their findings in open literature [6].

While there exist many commercial tools that perform LTE traffic capture and decoding, to our knowledge, there is no open source software that will accomplish this. Papers that have been published regarding LTE security require the use of commercial LTE capture tools or the development of custom tools as observed in [7] and [8]. The relevance of this subject is apparent from the availability of professional test instruments, offered by various hardware and software companies. But their high cost limits their widespread use in research and education. Our goal is to provide a framework for making cellular RAN signaling analysis accessible to all, enable wireless security research, increase the transparency and visibility of RAN operations, and allow easy adoption by industry and standardization bodies.

Iii Background

This section provides the necessary background on how LTE UEs register to the network and get notified by the network of incoming messages or calls. When a UE powers on, it first needs to receive and decode the Primary and Secondary Synchronization Signals (PSS/SSS) [9]. Together, these two signals allow the UE to synchronize on a slot and frame level basis, respectively, as well as correct for frequency and phase offsets between the eNB and UE oscillators Now that the UE is synchronized with the eNB, it needs to know more information before it can initiate an attach request. It needs to decode the the Master and System Information Blocks (MIB/SIBs). These blocks are transmitted in the clear by the eNB on a regular basis to ensure that UEs have the necessary information needed to attach. This is the initial cell search that each UE performs when turned on or when returning out of coverage and is part of the information that our tool can capture and analyze.

Fig. 1: Life cycle of an LTE UE.

Once a UE knows the network configuration details that are provided in the MIB/SIBs, it can then use its Random Access Radio Network Temporary Identity (RA-RNTI) to initiate a RRC connection with an eNB. After a UE has established an RRC connection, the UE will communicate to the EPC through the eNB over the Non-Access Stratum (NAS) protocol layer. Fig. 1 illustrates this attachment process.

In order to identify itself with the network, UEs utilize the International Mobile Subscriber Identity (IMSI). This secret identifier can be leveraged in a number of privacy-invading attacks [10] and, as such, should always be kept private. However, the UE will authenticate with the EPC’s Home Subscriber Server (HSS) transmitting its IMSI in the clear if the UE has no history with the network.

Once all of the NAS and RRC connections are established, the UE will enter an Idle state and deactivate the radio link between itself and the eNB. If the EPC needs to deliver a message to an idle UE, it is the job of the eNB to ‘wake-up’ the idle device and re-establish a physical connection [11]. This is done by sending out a paging message to all UEs in the operational area of the eNB. These paging messages use a specific Paging RNTI (P-RNTI) [12] to indicate the broadcast nature of paging and UEs are required to respond if their IMSI or SAE Temporary Mobile Subscriber Identity (S-TMSI) is being paged. The S-TMSI is a combination of MME Code and the Mobile TMSI (m-TMSI), herein both are simply referred to as the TMSI. Our tool is able to capture and decode the SIBs and Paging messages for specified eNBs which enables RAN Security analysis.

Iv CSAI: Cellular RAN Security Analysis Instrument

There are various open source software applications that implement different parts of the LTE specifications. We chose srsLTE [13] for its simplicity and applicability toward capturing and decoding broadcast and paging messages.

srsLTE specifically implements 3GPP Release 8 with certain components of Release 9 integrated into its software. It is a licensed under the GNU Affero General Public License for free use for non-commercial purposes, such as research and education. The srsLTE software suite is compatible with software defined radio (SDR) hardware to build LTE radio access networks. As the names suggest, srsUE implements the LTE UE and srsENB the LTE eNB. To accompany these, Software Radio Systems (SRS) has also published srsEPC which provides an Evolved Packet Core (EPC) that is needed for a fully working LTE network with one or several eNBs serving one or several UEs. At the time of writing, we are using the most current version of srsLTE, version 18.12.0 based on commit 3cc4ca85 from the master branch [14].

There are two primary ways that a message capture program can be implemented using the srsLTE software suite. The first method has been used in many different research papers and uses one of srsLTE’s example binaries which requires little modification but significant external processing to generate useful data. The second method requires more modification to srsUE, but automatically decodes data and presents it in an easily readable format.

Iv-a Method 1

Method 1 involves using one of the example binaries. The one we are focusing on is pdsch_ue which is one of many example programs provided for LTE network testing. Its companion program is pdsch_enodeb which can generate PSS/SSS and MIB/SIBs. These blocks can be transmitted over a physical radio frequency (RF) interface or written to a file. The UE application is able to decode the synchronization signals as well as the information blocks. It also has the capability to listen for a specific RNTI and only decode blocks addressed to that RNTI. As defined in the Medium Access Control (MAC) protocol specifications [12], P-RNTIs have the fixed value 0xFFFE, and we can instruct pdsch_ue to only listen for this specific paging channel RNTI. The only modification we need to make to pdsch_ue is one to get the raw information blocks and paging messages from the program.

In order to achieve this, an additional line of code is needed after the application decodes the PDSCH to print the frame received from an RF interface or input file. For the data to be written to a file, the necessary configuration code must be added before the program enters the main loop that continually receives and decodes PDSCH frames.

The main problem with this approach is that additional work is required to decode the output data using an ASN.1 message decoder. An example output is shown in Figure 2. While there exist online tutorials and LTE message decoders, they either add unnecessary complication to the workflow or are inadequate for the amount of processing required for real time operations. While this is a valid method to capture paging traffic, we did not want to hinder large-scale analysis and choose Method 2 for our tool.

Fig. 2: Output from ASN.1 Decoding

Iv-B Method 2

The second method involves directly modifying the srsUE source to achieve the desired capabilities. Specifically, we modify the code that implements the RRC protocol. The RRC protocol is primarily responsible for connection establishment and release as well as handling paging messages. In the connection_request function, send_con_request is called which is responsible for sending the RRC connection request message to the lower layers that is transmitted to the eNB. If we comment this function and replace it with a call to rrc_conection_release, we instruct the UE to remain disconnected and not communicate with an eNB. This alone allows capturing the SIBs transmitted by the eNB, but is not enough to capture paging messages as well.

In order to capture paging messages, we add an additional line after the connection release call to update the RRC state to reflect a successful connection. The other layers of srsUE will now look for paging messages and they are automatically captured and logged if configured to.

Finally, the capture flag must be enabled. This is achieved by editing the ue.conf file to enable PCAP logging and set debug level logging for the MAC and RRC layers. The log file will display all decoded SIBs and paging messages, but they are also available in the generated pcap file. We can view the capture in Wireshark by making an entry in the DLT_USER encapsulation table. The required DLT settings are listed in configuration files. After making all necessary modifications and rebuilding the software, outputs as shown in Figures 3 and 4 can be obtained for analysis. The next section describes some of the statistics we derived from using CSAI.

Fig. 3: Wireshark analysis of paging messages.

Fig. 4: Log output of paging message.

V Experimentation

In order to benchmark CSAI, we capture commercial network traffic and provide masked statistics to show the effectiveness of the tool. Two USRP B210s with the modifications detailed in Section IV were used to capture SIBs and paging traffic on an Ubuntu 18.04.02 machine. Similarly to [15] and [16], only SIB and paging messages were acquired; careful consideration was taken to ensure that no user data was captured or retained despite being encrypted.

V-a Short-Term Persistence

Table I shows the data that we obtained from three networks. We measured the amount of total paging traffic over a six-hour time frame of two network operators the first day, and repeated the same capture for the third operator on the following day. By inspecting the paging information to see whether IMSIs were used to page users, we found that all pages used S-TMSIs to identify a UE as opposed to revealing the IMSI, which is an encouraging result.

The last row in Table I shows the longest observed TMSI in minutes which matches the length of the experiment. In all three cases, TMSIs were observed throughout the capture, but the majority of TMSIs were either a single occurrence, or were used for a short time.

Network Operators
Metrics Operator 1 Operator 2 Operator 3
Total Pages 586701 280795 156311
Unique TMSIs 31654 36544 49076
Longest active TMSI in minutes 361.25 361.04 288.15
TABLE I: Network Statistics

Figure 5 shows the histograms of the lifespans of the observed TMSIs. Most TMSIs are very short lived, whereas some are observed for the entire duration of 6 hours. Our measurements were taken at a single location and we had no control of the UEs in the area. Due to the mobility of users, it is likely that the average TMSI lifespan is longer than shown here.

Operator 1 has a significant number of long-lasting TMSIs. This implies that many UEs attached to this cell did not hand-off connectivity during our experiements. This is displayed in Fig. 5 which shows a higher number of TMSIs at the maximum observed time for operator 1 when compared to the other two operators.

(a) Operator 1
(b) Operator 2
(c) Operator 3
Fig. 5: Time distribution of observed Paging messages.

V-B Long-Term Persistence

Next, we examine the persistence of TMSIs across different days. To test this, we use two commercial UEs and CSAI to monitor its operating band. We initiated communication to the UE in attempts to capture the paging messages. This was accomplished by sending numerous messages from one UE to the other with ample time between messages so that the RRC connection is released due to UE inactivity between messages. The next day we repeated a similar communication pattern to generate more paging messages to our UE.

We review the log files to see if our TMSI from day one persisted on the following day. While the test was limited in scope, we did not observe any of the TMSIs from day one in the day two capture. This is a particularly encouraging result, as it implies that this network operator rotates TMSIs at least every twenty-two hours, which was the time window between our test captures.

Vi Security Implications

Vi-a Potential Attacks

CSAI takes advantage of the inherent nature of pre-authentication and broadcast signaling in LTE. While paging messages do not inherently contain sensitive information, it is possible to map a TMSI to a RNTI if you monitor subsequent RRC connection setup requests. Once a mapping is obtained, an attack as described in [17] could allow for statistical traffic analysis even though the contents of the NAS messages are encrypted and reflects a privacy concern.

Lichtman et al. outline attacks in [1] that discuss jamming of the LTE signals. Once the MIB/SIBs are decoded, it is possible to target jamming efforts towards a specific eNB. Combined with the aforementioned TMSI to RNTI mapping, it would be possible to extend the attack and jam one or several UE’s data and control plane traffic.

Most network operators will page a UE using a TMSI; however, 3GPP standards allow eNBs to page a UE using its IMSI in cases where a UE does not respond to three subsequent paging attempts using a TMSI. This presents a significant security issue as many follow-on attacks are capable once a UE’s IMSI is known and include down bidding attacks or man in the middle style interceptions as demonstrated in [7] and [8]. Our instrument enables research on security analysis and system hardening. Researchers will benefit from CSAI as they test modifications to 4G and 5G protocols to prevent the exploitation of preauthentication messages as surveyed in [18].

Vi-B Crashing a Software eNB

Another interesting behavior that we observed in the course of developing CSAI was the potential for a straightforward Denial of Service attack against an SDR eNB through active RF attacks that mimic older Transmission Control Protocol (TCP) SYN Flood attacks. A SYN Flood attack exploits the inherit trust in TCP where a client floods a server with TCP SYN messages in the first stage of the TCP three way handshake. The server will allocate resources for the connection and reply to the client with a TCP SYN ACK message. Instead of completing the handshake with an ACK message, the client will disregard the server’s SYN ACK and continue opening connections with the server. This will eventually consume all resources on the server leading to a system crash or denying connectivity to legitimate clients.

In modifying the rrc.cc file, if one sends an RRC Connection Request to an eNB and immediately calls the RRC Connection Release process, the UE will not respond to the eNBs request for RRC Connection Setup. The eNB will allocate resources for the UE in expectance that the UE will reply with an RRC Connection Setup Complete; however, the UE has already begun the process of releasing the connection. This leaves the base station in a half open state waiting for the UE to finish the RRC handshake. Since the UE was instructed to release, after a short delay it will attempt to reconnect to the eNB further exhausting its resources. An even faster way to perform this attack would be to have a fake UE enter a while loop that constantly requests and immediately releases RRC Connections.

In performing this attack against a SDR eNB, we were able to crash it with high success. In our investigation, the eNB crashed due to automated buffer overflow protections enabled by default when using the GNU C Compiler. An example of this crash is shown in Fig. 6.

While more testing is required to determine the scope of this active attack, one potential mitigation may be similar to SYN cookies as detailed in [19] where the eNB would only allocate resources for RRC Connections after the UE responds with the full Setup Complete message. In the case of performing this attack without the while loop, the eNB occasionally took minutes before it crashed. It is possible to modify CSAI be modified to include a delay that ensures the eNB does not crash, but rather denies service to legitimate UEs that are connected or are trying to connect. This finding exemplifies the potential of fuzzing analysis against the cellular network infrastructure. In the case of the analysis presented in this manuscript, a software radio-based UE successfully crashed an open-source LTE network. However, the same could occur against a commercial eNB. We are currently investigating this further and impact on commercial femtocells and their protection against the attacks demonstrated in [20].

Fig. 6: Crash of a software eNB

Vii Conclusion

This paper describes how a SDR LTE implementation of a cellular RAN can be repurposed for analyzing the security of the wireless network. Our example is for 4G LTE, but similar principles can be applied to other cellular communications protocols. Using method two described in Section IV, SIBs and paging messages are able to be passively recorded from test or commercial LTE networks; we also discovered another modification to allow for DoS attacks against eNBs. When 5G specifications are frozen and NR begins to deploy, this tool will be extended to capture those messages as well because the signaling in NR is similar to that of LTE/LTE-A.

We will release our code so that the community can utilize this instrument for ongoing investigations on RAN security. In continuing research, we are using CSAI as we investigate practical attacks and remediations for UE and eNB implementations. These include base station/small-cell fuzzing, location leakage, and UE denial of service attacks and their countermeasures.


  • [1] M. Lichtman, R. P. Jover, M. Labib, R. Rao, V. Marojevic, and J. H. Reed, “Lte/lte-a jamming, spoofing, and sniffing: threat assessment and mitigation,” IEEE Communications Magazine, vol. 54, no. 4, pp. 54–61, 2016.
  • [2] R. P. Jover and V. Marojevic, “Security and protocol exploit analysis of the 5g specifications,” IEEE Access, vol. 7, pp. 24 956–24 963, 2019.
  • [3] R. M. Rao, S. Ha, V. Marojevic, and J. H. Reed, “Lte phy layer vulnerability analysis and testing using open-source sdr tools,” in MILCOM 2017-2017 IEEE Military Communications Conference (MILCOM).   IEEE, 2017, pp. 744–749.
  • [4] V. Marojevic, R. M. Rao, S. Ha, and J. H. Reed, “Performance analysis of a mission-critical portable lte system in targeted rf interference,” in 2017 IEEE 86th Vehicular Technology Conference (VTC-Fall).   IEEE, 2017, pp. 1–6.
  • [5] M. Labib, V. Marojevic, J. H. Reed, and A. I. Zaghloul, “Enhancing the robustness of lte systems: analysis and evolution of the cell selection process,” IEEE Communications Magazine, vol. 55, no. 2, pp. 208–215, 2017.
  • [6] S. Hussain, O. Chowdhury, S. Mehnaz, and E. Bertino, “Lteinspector: A systematic approach for adversarial testing of 4g lte,” in Network and Distributed Systems Security (NDSS) Symposium 2018, 2018.
  • [7] A. Shaik, R. Borgaonkar, N. Asokan, V. Niemi, and J.-P. Seifert, “Practical attacks against privacy and availability in 4g/lte mobile communication systems,” arXiv preprint arXiv:1510.07563, 2015.
  • [8] R. P. Jover, “Lte security, protocol exploits and location tracking experimentation with low-cost software radio,” arXiv preprint arXiv:1607.05171, 2016.
  • [9] 3GPP, “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation,” 3rd Generation Partnership Project (3GPP), Technical Specification (TS) 36.211, 03 2013, version 10.7.0. [Online]. Available: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetai
  • [10] T. Engel, “Locating mobile phones using signalling system 7,” in 25th Chaos communication congress, 2008.
  • [11] A. Shrut, “Lte for layman (part 3) - the complete picture!” 2016, [Online; posted 15-June-2016].
  • [12] 3GPP, “Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC); Protocol specification,” 3rd Generation Partnership Project (3GPP), Technical Specification (TS) 36.321, 04 2019, version 15.5.0. [Online]. Available: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetai
  • [13] I. Gomez-Miguelez, A. Garcia-Saavedra, P. D. Sutton, P. Serrano, C. Cano, and D. J. Leith, “srslte: an open-source platform for lte evolution and experimentation,” in Proceedings of the Tenth ACM International Workshop on Wireless Network Testbeds, Experimental Evaluation, and Characterization.   ACM, 2016, pp. 25–32.
  • [14] S. R. Systems, “srslte,” https://github.com/srsLTE/srsLTE/tree/3cc4ca85
    , 2019.
  • [15] S. R. Hussain, M. Echeverria, O. Chowdhury, N. Li, and E. Bertino, “Privacy attacks to the 4g and 5g cellular paging protocols using side channel information,” 2019.
  • [16] M. Chlosta, D. Rupprecht, T. Holz, and C. Pöpper, “Lte security disabled — misconfiguration in commercial networks,” in Proceedings of the 12th ACM Conference on Security & Privacy in Wireless and Mobile Networks, ser. WiSec ’19, 2019.
  • [17] D. Rupprecht, K. Kohls, T. Holz, and C. Pöpper, “Breaking lte on layer two,” in IEEE Symposium on Security & Privacy (SP), 2019.
  • [18] M. A. Ferrag, L. Maglaras, A. Argyriou, D. Kosmanos, and H. Janicke, “Security for 4g and 5g cellular networks: A survey of existing authentication and privacy-preserving schemes,” Journal of Network and Computer Applications, vol. 101, pp. 55–82, 2018.
  • [19] J. F. Kurose and K. W. Ross, Computer Networking: A Top-Down Approach (7th Edition), 7th ed.   Pearson, 2016.
  • [20] H. Kim, J. Lee, L. Eunkyu, and Y. Kim, “Touching the Untouchables: Dynamic Security Analysis of the LTE Control Plane,” in Proceedings of the IEEE Symposium on Security & Privacy (SP).   IEEE, May 2019.
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
Add comment
Loading ...
This is a comment super asjknd jkasnjk adsnkj
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test description