The attached DRAFT document (provided here for historical purposes) has been superseded by the following publication: #### Publication Number: NIST Special Publication (SP) 800-187 Title: Guide to LTE Security Publication Date: 12/21/2017 • Final Publication: https://doi.org/10.6028/NIST.SP.800-187 (direct link: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-187.pdf). • Related Information on CSRC: https://csrc.nist.gov/publications/detail/sp/800-187/final ----- #### The following information was posted with the attached DRAFT document: Nov 21, 2016 **_SP 800-187_** **_DRAFT Guide to LTE Security_** NIST invites comments on Draft NIST SP 800-187, Guide to LTE Security. Cellular technology plays an increasingly large role in society as it has become the primary portal to the Internet for a large segment of the population. One of the main drivers making this change possible is the deployment of 4th generation (4G) Long Term Evolution (LTE) cellular technologies. This document serves as a guide to the fundamentals of how LTE networks operate and explores the LTE security architecture. This is followed by an analysis of the threats posed to LTE networks and supporting mitigations. This document introduces high-level LTE concepts and discusses technical LTE security mechanisms in detail. Technical readers are expected to understand fundamental networking concepts and general network security. It is intended to assist those evaluating, adopting, and operating LTE networks, specifically telecommunications engineers, system administrators, cybersecurity practitioners, and security researchers. Email comments to: LTEsecurity@nist.gov (Subject: "Comments on Draft SP 800-187") Comments due by: December 22, 2016 ----- 1 **DRAFT NIST Special Publication 800-187** 2 **Guide to LTE Security** 3 4 5 Jeffrey Cichonski 6 Joshua M Franklin 7 Michael Bartock 8 9 10 11 12 13 14 15 16 17 C O M P U T E R S E C U R I T Y 18 19 ----- 20 **DRAFT NIST Special Publication 800-187** 21 **Guide to LTE Security** 22 23 24 Jeffrey Cichonski 25 Joshua M. Franklin 26 _Applied Cybersecurity Division_ 27 _Information Technology Laboratory_ 28 29 Michael Bartock 30 _Computer Security Division_ 31 _Information Technology Laboratory_ 32 33 34 35 36 37 38 39 40 41 November 2016 42 43 44 45 46 47 U.S. Department of Commerce 48 _Penny Pritzker, Secretary_ 49 50 National Institute of Standards and Technology 51 _Willie May, Under Secretary of Commerce for Standards and Technology and Director_ ----- 52 **Authority** 53 This publication has been developed by NIST in accordance with its statutory responsibilities under the 54 Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law 55 (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including 56 minimum requirements for federal information systems, but such standards and guidelines shall not apply 57 to national security systems without the express approval of appropriate federal officials exercising policy 58 authority over such systems. This guideline is consistent with the requirements of the Office of Management 59 and Budget (OMB) Circular A-130. 60 Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and 61 binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these 62 guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, 63 Director of the OMB, or any other federal official. This publication may be used by nongovernmental 64 organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, 65 however, be appreciated by NIST. 66 National Institute of Standards and Technology Special Publication 800-187 67 Natl. Inst. Stand. Technol. Spec. Publ. 800-187, 48 pages (November 2016) 68 CODEN: NSPUE2 69 70 71 Certain commercial entities, equipment, or materials may be identified in this document in order to describe an 72 experimental procedure or concept adequately. Such identification is not intended to imply recommendation or 73 endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best 74 available for the purpose. 75 There may be references in this publication to other publications currently under development by NIST in accordance 76 with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, 77 may be used by federal agencies even before the completion of such companion publications. Thus, until each 78 publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For 79 planning and transition purposes, federal agencies may wish to closely follow the development of these new 80 publications by NIST. 81 Organizations are encouraged to review all draft publications during public comment periods and provide feedback to 82 NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at 83 http://csrc.nist.gov/publications. 84 85 **Public comment period: November 21, 2016 through December 22, 2016** 86 National Institute of Standards and Technology 87 Attn: Applied Cybersecurity Division, Information Technology Laboratory 88 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930 89 Email: LTEsecurity@nist.gov 90 All comments are subject to release under the Freedom of Information Act (FOIA). ----- 91 **Reports on Computer Systems Technology** 92 The Information Technology Laboratory (ITL) at the National Institute of Standards and 93 Technology (NIST) promotes the U.S. economy and public welfare by providing technical 94 leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test 95 methods, reference data, proof of concept implementations, and technical analyses to advance the 96 development and productive use of information technology. ITL’s responsibilities include the 97 development of management, administrative, technical, and physical standards and guidelines for 98 the cost-effective security and privacy of other than national security-related information in federal 99 information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and 100 outreach efforts in information system security, and its collaborative activities with industry, 101 government, and academic organizations. 102 **Abstract** 103 Cellular technology plays an increasingly large role in society as it has become the primary 104 portal to the internet for a large segment of the population. One of the main drivers making this 105 change possible is the deployment of 4[th] generation (4G) Long Term Evolution (LTE) cellular 106 technologies. This document serves as a guide to the fundamentals of how LTE networks operate 107 and explores the LTE security architecture. This is followed by an analysis of the threats posed 108 to LTE networks and supporting mitigations. 109 **Keywords** 110 cellular security; networking; Long Term Evolution; 3[rd] Generation Partnership Project (3GPP); 111 LTE; telecommunications; wireless. 112 **Acknowledgments** 113 The authors wish to thank all of the individuals who provided public comments, and their 114 colleagues who reviewed drafts of this report and contributed to its technical content. This 115 includes Tim Grance, Sheila Frankel, Sanjeev Sharma, Gema Howell, Michael Ogata, Nelson 116 Hastings, Tracy McElvaney, and Murugiah Souppaya of NIST. Additionally, the authors would 117 like to extend a special thanks to Alf Zugenmaier of the Munich University of Applied Sciences. 118 **Audience** 119 This document introduces high-level LTE concepts and discusses technical LTE security 120 mechanisms in detail. Technical readers are expected to understand fundamental networking 121 concepts and general network security. It is intended to assist those evaluating, adopting, and 122 operating LTE networks, specifically telecommunications engineers, system administrators, 123 cybersecurity practitioners, and security researchers. 124 **Trademark Information** 125 All product names are registered trademarks or trademarks of their respective companies ii ----- 126 127 **Table of Contents** 128 **1** **Introduction ............................................................................................................ 1** 129 1.1 Purpose and Scope ........................................................................................ 1 130 1.2 Document Structure ........................................................................................ 1 131 1.3 Document Conventions ................................................................................... 2 132 **2** **Overview of LTE Technology ................................................................................ 3** 133 2.1 Evolution of 3GPP Standards ......................................................................... 3 134 2.2 LTE Concepts ................................................................................................. 4 135 2.2.1 Mobile Devices ..................................................................................... 5 136 2.2.2 E-UTRAN ............................................................................................. 5 137 2.2.3 Evolved Packet Core ............................................................................ 7 138 2.2.4 LTE Network Topologies ...................................................................... 8 139 2.3 LTE Network Protocols ................................................................................... 9 140 2.4 LTE Bearers .................................................................................................. 11 141 2.5 UE Attach ...................................................................................................... 12 142 **3** **LTE Security Architecture ................................................................................... 14** 143 3.1 Cryptographic Overview ................................................................................ 14 144 3.2 Hardware Security ........................................................................................ 16 145 3.3 UE Authentication ......................................................................................... 16 146 3.4 Air Interface Security ..................................................................................... 17 147 3.5 E-UTRAN Security ........................................................................................ 20 148 3.6 Backhaul Security ......................................................................................... 20 149 3.7 Core Network Security .................................................................................. 23 150 **4** **Threats to LTE Networks ..................................................................................... 24** 151 4.1 General Cybersecurity Threats ..................................................................... 24 152 4.1.1 Malware Attacks on UE’s .................................................................... 24 153 4.1.2 Malware Attacks on Base Station Infrastructure ................................. 24 154 4.1.3 Malware Attacks on Core Infrastructure ............................................. 25 155 4.1.4 Unauthorized OAM Network Access .................................................. 25 156 4.2 Rogue Base Stations .................................................................................... 25 157 4.2.1 Device and Identity Tracking .............................................................. 26 158 4.2.2 Downgrade Attacks ............................................................................ 26 iii ----- 159 4.2.3 Preventing Emergency Phone Calls ................................................... 26 160 4.2.4 Unauthenticated REJECT Messages ................................................. 27 161 4.3 Air Interface Eavesdropping .......................................................................... 27 162 4.4 Attacks Via Compromised Femtocell ............................................................ 27 163 4.5 Radio Jamming Attacks ................................................................................ 28 164 4.5.1 Jamming UE Radio Interface .............................................................. 28 165 4.5.2 Jamming eNodeB Radio Interface ...................................................... 28 166 4.6 Backhaul and Core Eavesdropping............................................................... 28 167 4.7 Physical Attacks on Network Infrastructure ................................................... 28 168 4.8 Attacks Against K .......................................................................................... 29 169 4.9 Stealing Service ............................................................................................ 29 170 **5** **Mitigations ............................................................................................................ 30** 171 5.1 Cybersecurity Industry Recommended Practices ......................................... 30 172 5.2 Enabling Confidentiality on the Air Interface ................................................. 30 173 5.3 Use of the Ciphering Indicator ...................................................................... 31 174 5.4 User-Defined Option for Connecting to LTE Networks .................................. 31 175 5.5 Ensure Confidentiality Protection of S1 Interface .......................................... 32 176 5.6 Encrypt Exposed Interfaces Between Core Network Components ............... 32 177 5.7 Use of SIM/USIM PIN Code .......................................................................... 32 178 5.8 Use of Temporary Identities .......................................................................... 32 179 5.9 3[rd] Party Over-the-Top Solutions .................................................................. 33 180 5.10 Unauthenticated Reject Message Behavior .................................................. 33 181 **6** **Conclusions.......................................................................................................... 34** 182 183 **List of Appendices** 184 **Appendix A— Acronyms and Acronyms ................................................................. 36** 185 **Appendix B— References .......................................................................................... 39** 186 187 **List of Figures** 188 Figure 1 - High-level Cellular Network ............................................................................. 4 189 Figure 2 - E-UTRAN ........................................................................................................ 6 190 [Figure 3 - LTE Network Architecture ............................................................................... 8](https://nistgov.sharepoint.com/sites/staff/Guide%20to%20Security%20of%20LTE%20Networks/Shared%20Documents/LTE%20SP%20-%20DRAFT.docx#_Toc464563203) 191 Figure 4 - LTE Protocol Stack ....................................................................................... 10 iv ----- 192 Figure 5 - Initial Attach .................................................................................................. 13 193 Figure 6 - Keys Protecting the Network Stack ............................................................... 15 194 Figure 7 - Authentication and Key Agreement Protocol ................................................. 17 195 Figure 8 - Highlighting the Air Interface ......................................................................... 18 196 Figure 9 - Integrity Protection Requirements ................................................................. 19 197 Figure 10 - Confidentiality Protection Requirements ..................................................... 19 198 Figure 11 - Protecting the S1 Interface .......................................................................... 21 199 Figure 12 - Sample Illustration of Security Gateways .................................................... 22 200 Figure 13 - Example Rogue Base Station ..................................................................... 25 201 Figure 14 – Simplified Downgrade Attack ..................................................................... 26 202 203 **List of Tables** 204 Table 1 - Cryptographic Key Information Summary ...................................................... 15 205 v ----- 206 **1** **Introduction** 207 Cellular technology has caused large changes throughout society in recent decades. Besides 208 providing telephony services, cellular devices store and process personal information, provide 209 enterprise connectivity, and act as the primary portal to the internet for many individuals. 210 Phones, tablets, laptops, wearables, cellular modems in vehicles, and other industry specific 211 equipment all have the ability to access cellular networks. The cellular infrastructure of the 212 United States is transitioning from older 2[nd] Generation (2G) and 3[rd] Generation (3G) cellular 213 technologies to newer 4[th] Generation (4G) technologies such as Long Term Evolution (LTE). 214 LTE is now the dominant air interface technology across the United States and is seeing rapid 215 adoption in countries across the globe. 216 **1.1** **Purpose and Scope** 217 The purpose of this document is to provide information to organizations regarding the security 218 capabilities of cellular networks based on LTE technology. LTE networks are rarely deployed in 219 a standalone fashion and instead are integrated alongside the previous generations of cellular 220 systems - however they are out of scope for the technology overview of this document. Because 221 2G and 3G networks are deployed alongside LTE networks, these older cellular systems are 222 discussed within the threats and mitigations section of this document. 223 The document is primarily scoped to analyzing the security of the systems traditionally owned 224 and/or operated by a wireless provider, but also includes organizations writing firmware to 225 operate the System on a Chip (SoC) inside of a mobile device that communicates with cellular 226 infrastructure. The wireless providers, also known as mobile network operators (MNOs), operate 227 the cellular LTE air interface, backhaul, core network, and portions of a user’s mobile device, 228 including the Universal Integrated Circuit Card (UICC) hardware token and the Universal 229 Subscriber Identity Module (USIM) software application. All of these entities will be fully 230 described within this document. 231 232 The mobile device hardware, mobile operating system security (e.g., Android, Blackberry, iOS, 233 Windows Phone), and 3rd party mobile applications are generally out of the scope of this 234 document unless otherwise noted. This document does not analyze non-3GPP networks (e.g., 235 WiFi, WiMAX, 3GPP2), forthcoming 3GPP features such as device to device cellular 236 communications and cellular internet of things (IoT), and the over-the-air (OTA) management 237 updates to cellular platforms. Finally, the IP Multimedia Subsystem (IMS), a modern platform 238 for delivering services such as Voice over LTE (VoLTE), is not included within this document. 239 **1.2** **Document Structure** 240 The remainder of this document is organized into the following major sections: 241 - Section 2 provides an overview of LTE standards and technology, 242 - Section 3 details the security architecture of LTE, 243 - Section 4 identifies threats to LTE networks, 244 - Section 5 recommends mitigations and other methods of enhancing LTE security, and 1 ----- 245 - Section 6 contains conclusions and future research. 246 The document also contains appendices with supporting material: 247 - Appendix A defines selected acronyms and abbreviations used in this publication, and 248 - Appendix B contains a list of references used in the development of this document. 249 **1.3** **Document Conventions** 250 This document primarily uses LTE/Evolved Packet System (EPS) terminology. Therefore, those 251 already familiar with cellular concepts from non-LTE systems and terminology may need to 252 consult the appendix containing Acronyms and Acronyms for clarification. 253 - The terms "cell" and "cellular" are used interchangeably. 254 - The term "base station" is used as a standards agnostic term of referring to a cellular 255 tower communicating with a mobile device, and is often used when discussing the 256 interaction between 2G, 3G, and 4G systems. Each set of standards uses a specific term 257 for base station, and LTE employs the term evolved Node B, which is shortened to 258 eNodeB or eNB. eNodeB is generally used in this document, but when standards are 259 quoted or specific cryptographic keys referenced, the term eNB may be used. 260 - The term "mobile device" is used as a standards agnostic term of referring to the User 261 Equipment (UE) (e.g., cellphone, tablet, cellular dongle). 262 - The LTE standards heavily use the term Evolved Packet System (EPS) which is used 263 interchangeably with "LTE" within this document. 264 - The LTE standards heavily use the term Evolved Packet Core (EPC), which is used 265 interchangeably with the term “core”. 2 ----- 266 **2** **Overview of LTE Technology** 267 A cellular network is a wireless network with a distributed coverage area made up of cellular 268 sites housing radio equipment. A cellular site is often owned and operated by a wireless 269 telecommunications company, internet service provider, or possibly government entity. The 270 wireless telecommunications company, or mobile network operator (MNO), providing service to 271 end users may own the cellular site, or pay for access to the cellular infrastructure - as is the case 272 with mobile virtual network operators (MVNO). MNOs distribute cellular radio equipment 273 throughout a large geographic region, and connect them back to a core network they typically 274 own and operate. In areas receiving poor cellular service, such as inside a building, MNOs may 275 provide a signal booster or small-scale base station directly to the end user to operate. 276 Before LTE, cellular systems were modeled after the traditional wireline telephony system in 277 that a dedicated circuit was provided to a user making a telephone call, ensuring a minimal 278 guarantee of service. In comparison to circuit switched cellular networks of the past, LTE 279 networks utilize packet switching. An LTE network provides consistent Internet Protocol (IP) 280 connectivity between an end user's mobile device and IP services on the data network, while 281 maintaining connectivity when moving from tower to tower (e.g., mobility). 282 LTE is a mobile broadband communication standard defined by the 3rd Generation Partnership 283 Project (3GPP), a worldwide standards development organization. Implementations of LTE 284 networks are being deployed across the globe and installations continue to increase as the 285 demand for high-speed mobile networks is constantly rising. Within TS 22.278 [9], 3GPP 286 defines number of high-level goals for LTE systems to meet, including: 287 - Provide increased data speeds with decreased latency, 288 - Build upon the security foundations of previous cellular systems, 289 - Support interoperability between current and next generation cellular systems and other 290 data networks, 291 - Improve system performance while maintaining current quality of service, and 292 - Maintain interoperability with legacy systems. 293 The following sections explain the fundamental concepts of LTE technology and architecture, 294 network protocols, and the evolution of the 3GPP security. 295 **2.1** **Evolution of 3GPP Standards** 296 Global System for Mobile Communications (GSM) is a 2G circuit switched cellular technology. 297 Although GSM was not initially defined by 3GPP, 3GPP took control of the standard to 298 maintain, enhance, and use it as a foundation to make future developments. 3GPP's first 299 extension of GSM was the General Packet Radio Service (GPRS), referred to as a 2.5G 300 technology. GPRS was the first method of sending non-voice data over a cellular network, and 301 was quickly followed by the Enhanced Data Rates for GSM Evolution (EDGE), sometimes 302 referred to as a 2.75G technology. 303 The first voice standard defined by 3GPP was the Universal Mobile Telecommunications System 304 (UMTS), which is a 3G circuit switched technology. Soon after the development of UMTS, 3 ----- 305 3GPP packet switched technologies were evolved into multiple variants collectively referred to 306 as High Speed Packet Access (HSPA), which is arguably considered 3.5G, although certain 307 mobile devices will display an HSPA connection as 4G. HSPA was created to increase data 308 throughput on both the downlink and uplink connections. 309 LTE needs to support a growing demand for higher data rates and quality of service. It also needs 310 to be able to quickly support new advances in technology, and LTE’s packet switched foundation 311 will make it easier to upgrade/update the technology as well as lower the complexity of the 312 overall network. To meet these goals, LTE was introduced via 3GPP Release 8, which was 313 frozen on December 11, 2008. All subsequent releases of LTE have built upon this baseline. 314 3GPP defines a series of specifications dedicated to the technological requirements for LTE, 315 known as the 36 series. 3GPP also defines a series of specifications for security, known as the 33 316 series. Each 3GPP series is comprised of Technical Report (TR) and Technical Specification 317 (TS) documents. For a new feature there are typically multiple approaches and possible solutions 318 investigated within a TR. Once a single solution for the feature is agreed upon, it is standardized 319 within a TS. This document is based on 3GPP Release 12, which was frozen on March 13, 2015 320 [1]. 321 **2.2** **LTE Concepts** 322 The following section describes important high level concepts and components of LTE networks 323 that are used and discussed throughout the course of this document. One of the fundamental 324 concepts to understand is the overall network architecture: mobile devices (UEs) connect to base 325 stations (eNodeBs) via radio signals, and the base stations transmit and receive IP packets to and 326 from the core network. The core ntework has a large number of entry and exit points, including 327 the internet and connections to other cellular networks. Figure 1 illustrates these high-level 328 concepts. 329 330 **Figure 1 - High-level Cellular Network** 331 In contrast to earlier cellular network technologies that use a hybrid of circuit-switched 332 technology for voice and packet-switched technology for data, LTE solely uses packet switched, 333 IP-based technology. In the LTE architecture, voice traffic traverses the network over the data 334 connection using protocols, such as VoLTE, which is similar to Voice Over IP (VoIP). VoLTE is 335 being deployed with widespread adoption by MNOs in the US. MNOs may revert back to legacy 336 circuit switched cellular networks to handle voice calls and short message service (SMS) 337 messages by using a mechanism known as circuit switched fallback (CSFB). 4 ----- 338 **2.2.1 Mobile Devices** 339 Mobile devices are the primary endpoint in cellular networks, interacting with base stations via 340 radio signals to send and receive information. A mobile device is composed of two distinct 341 systems: the general purpose mobile OS (e.g., Android, iOS, Windows Phone) that users interact 342 with and the telephony subsystem used to access the cellular network. The telephony subsystem 343 contains a distinct application processor referred to as the baseband processor, which has its own 344 operating system used to interact with the cellular network, often developed by the cellular SoC 345 manufacturer. 346 LTE standards refer to a mobile device as the User Equipment (UE), which refers to both the 347 terminal with the mobile operating system, baseband processor, and LTE radio, and the 348 removable hardware token housing security-critical information used to obtain network access. 349 This removable hardware token is colloquially referred to as the SIM card, but LTE standards 350 use the term Universal Integrated Circuit Card (UICC). The UICC, which is essentially a 351 smartcard, runs a Java application known as the Universal Subscriber Identity Module (USIM). 352 The USIM interfaces with the cellular radio and subsequently the mobile network. The UICC 353 contains secret cryptographic keys that are shared with the MNO before it is provisioned to a 354 user. 355 There are two distinct identifiers used in cellular networks: The International Mobile Subscriber 356 Identity (IMSI) and the International Mobile Equipment Identifier (IMEI). The IMSI is the long357 term identity that the carrier uses to identify a subscriber. The IMEI is used to identify a specific 358 mobile device to the network and is stored on a mobile device’s internal flash memory, although 359 the IMEI may also be stored on the UICC. 360 - **User equipment (UE): Cellular device (cell phone, tablet, LTE modem, etc) includes the** 361 following: 362 `o` **Mobile Equipment (ME): The mobile terminal without the hardware token.** 363 `o` **UICC: A smart card that stores personal information, cryptographic keys, and is** 364 responsible for running java applications that enable network access. This smart 365 card is inserted into the ME. 366 `o` **International Mobile Equipment Identifier (IMEI): Terminal identity used to** 367 identify the mobile device to the cellular network. 368 `o` **International Mobile Subscriber Identity (IMSI): User identity used to identify** 369 a subscriber to the cellular network. 370 In addition to the IMEI and IMSI, other identities exist in LTE, including the Globally Unique 371 Temporary Identity (GUTI) and the Temporary Mobile Subscriber Identity (TMSI). The GUTI 372 can identify a UE to a network without having to send the long-term identity (i.e., IMSI). The 373 security implications of clear-text transmission of the IMSI will be discussed in later sections. 374 Different identities are used for various reasons, including limiting the exposure of a permanent 375 identity, to minimize tracking of a device as it accesses multiple services on the network. 376 **2.2.2 E-UTRAN** 377 The Radio Access Network (RAN) has evolved over time into the Evolved Universal Terrestrial 5 ----- 378 Radio Access Network (E-UTRAN). UEs connect to the E-UTRAN to send data to the core 379 network. The E-UTRAN is a mesh network composed of base stations. A base station, or 380 Evolved Node B, modulates and demodulates radio signals to communicate with UEs. eNodeBs 381 then act as a relay point to create and send IP packets to and from the core network. Cellular 382 networks are designed to pass connectivity from one radio access device in the E-UTRAN to the 383 next as the connected UE changes location. This seamless handoff ability allows devices to have 384 a constant connection with minimal interruptions providing the mobility benefit of cellular 385 networks. eNodeBs use the X2 interface to communicate with each other, primarily transmiting 386 control signaling to allow for LTE network communication enabling UE mobility. During this 387 handover the serving eNodeB must transfer all UE context, cellular paramaters and other 388 information about the UE, to the receiving eNodeB. 389 LTE uses a concept of named interfaces to easily identify the communication link between two 390 endpoints. A named interface in LTE terminology, such as the X2 interface, refers to the logical 391 link between two endpoints, and in this example two eNodeBs. Named interfaces in LTE are 392 responsible for sending and receiving specified messages and data. These can be physically 393 implemented in a variety of ways and multiple named interfaces can share the same physical 394 connection. This physical connection can be a variety of network technologies such as fiber, 395 Ethernet, microwave, satellite link etc. 396 397 **Figure 2 - E-UTRAN** 398 Base stations come in a variety of form factors, different than a typical base station comprised of 399 a physical cell tower and radio equipment. Small cells have a smaller form factor, transmit at 400 lower power levels, capable of extending network coverage, and ultimately increase the capacity 401 of the network. 402 - **Evolved Universal Terrestrial Radio Access Network (E-UTRAN): All of the** 403 components providing wireless mobility. 404 `o` **Evolved Node B (eNodeB or eNB): An evolved Node B, colloquially referred to** 405 as a base station. 6 ----- 406 `o` **Small Cell: Low powered base station with less range and less capacity than a** 407 typical eNodeB, for instance Home eNodeBs (HeNB), Donor eNodeBs (DeNB), 408 and Relay Nodes (RN). 409 **2.2.3 Evolved Packet Core** 410 The evolved packet core (EPC), illustrated in Figure 3, is the routing and computing brain of the 411 LTE network. UEs receive control signals through base stations originating from the Mobility 412 Management Entity (MME). The MME performs a large number of functions including 413 managing and storing UE contexts, creating temporary identifiers, paging, controlling 414 authentication functions, and selecting the Serving Gateway (S-GW) and Packet Data Network 415 Gateway (P-GW), respectively. No user traffic is sent through the MME. The S-GW anchors the 416 UEs for intra-eNodeB handoffs and routes information between the P-GW and the E-UTRAN. 417 The P-GW is the default router for the UE, making transfers between 3GPP and non-3GPP 418 services, allocating IP addresses to UEs, and providing access to the PDN. 419 - **Evolved Packet Core (EPC): Routing and computing brain of the LTE network.** 420 `o` **Mobility Management Entity (MME): Primary network signaling node that** 421 does not interact with user traffic. Large variation in functionality including 422 managing/storing UE contexts, creating temporary IDs, sending pages, controlling 423 authentication functions, and selecting the S-GW and P-GWs. 424 `o` **Serving Gateway (S-GW): Carries user plane data, anchors UEs for intra-** 425 eNodeB handoffs, and routes information between the P-GW and the E-UTRAN. 426 `o` **Packet Data Network Gateway (P-GW): Allocates IP addresses, routes packets,** 427 and interconnects with non-3GPP networks. 428 `o` **Home Subscriber Server (HSS): Master database with subscriber data and stores** 429 the secret key K. 430 `o` **Authentication Center (AuC): Resides within the HSS, maps long term** 431 identities to pre-shared cryptographic keys, performs cryptographic calculations 432 during authentication. 433 `o` **Policy and Charging Rules Function (PCRF): Rules and policies related to** 434 quality of service (QoS), charging, and access to network resources are distributed 435 to the P-GW and enforced by the PCRF. 436 `o` **IP Multimedia Subsystem (IMS): Gateways to the public switched telephone** 437 network (PSTN), multimedia services (e.g., VoLTE, instant messaging, video), 438 and paging for multimedia services. 439 `o` **Backhaul: Connection between radio network and the core network. This** 440 connection can be fiber, satellite link, Ethernet cable, Microwave, etc. 441 `o` **Packet Data Network (PDN): Any external IP network (e.g., internet). UEs can** 442 be connected to one or many PDNs at any point in time. 443 `o` **Access Point Name (APN): Serves as the identifier for a PDN, and is the** 444 gateway between the EPC and PDN. The APN must be specified by the UE for 445 each PDN it connects to. 7 ----- 446 Figure 3 depicts the components introduced above and shows the data flows between these 447 network components. This graphic can serve as reference to visualize the interconnected 448 fundamental LTE network components and may depict concepts not yet discussed. The solid 449 lines in the diagram depict user plane traffic, while the dashed lines depict control plane traffic. 450 **Figure 3 - LTE Network Architecture** 451 **2.2.4 LTE Network Topologies** 452 An LTE network minimally consists of a UE, a group of cellular towers and nodes (E-UTRAN), 453 and the core network (EPC) controlled by the MNO. The E-UTRAN is connected to the EPC via 454 a network link known as the backhaul, from a security perspective it is important to note the E455 UTRAN and EPC are most likely in completely different geographic locations. Thus, the 456 interfaces that link them may or may not be contained totally within the MNO’s private domain. 457 This section will explore various operational network topologies such as fixed and deployable 458 LTE networks. 459 A fixed LTE network is a typical implementation of a cellular network utilizing multiple cell 460 sites to provide a wide spread coverage area to a large geographic area. In this type of 461 architecture, the core network components are generally in separate locations. The cell sites that 462 house the eNodeBs connect to the EPC through the backhaul. The backhaul connection can be 463 provided by a multitude of technologies (e.g., microwave, satellite, fiber, etc). An MNO would 464 typically deploy this type of network architecture. Although LTE networks require the same 465 functional components in order to operate effectively, the quantity and placement of these 466 components is completely dependent on the MNO’s network design. It is possible the network 467 operator incorporates multiple EPC components that serve critical functions as well as load 468 balances these components to provide increased availability. 469 An example of a fixed LTE network is a large region being provided network coverage with the 470 use of many spread out cell sites housing eNodeBs all connecting back into one or multiple 471 EPCs. Multiple eNodeBs are interconnected through the X2 interface, which is responsible for 472 session handover from one eNodeB to next as the UE travels. Ultimately the components of the 8 ----- 473 E-UTRAN are interconnected and communicate to the EPCs through the backhaul or S1 474 interface. There may be many to many relationships between the E-UTRANs and the EPCs to 475 provide high availability and reliability. 476 A deployable LTE network is a compact network able to be deployed in areas where no LTE 477 coverage exists, or where coverage has been interrupted. The deployable network can be mobile 478 and packaged in different form factors (e.g., mounted on a vehicle, trailer, backpack). These 479 types of LTE architectures can be used to create a self-contained network or be connected to an 480 existing LTE, or other, network. The hardware used in a deployable network is generally more 481 compact and capable of handling only a fraction of the throughput and capacity of a fixed LTE 482 network. 483 A Cell on Wheels, or COW, is an example of a commercially available deployable LTE network. 484 These COWs are environments that include all elements of an LTE network and are mounted on 485 trailers or in some cases packaged onto vehicles. COWs often still need to be connected back to 486 the core network. These types of deployable can be used to provide additional capacity to an 487 existing network where there is an increased demand, for example a large sporting event. These 488 can also be used where network coverage is not available, such as a natural disaster site, in order 489 to provide first responders a means of communication. These LTE networks are commercially 490 available and can be purchased from network equipment providers. 491 **2.3** **LTE Network Protocols** 492 The following protocols are used for communication over the air interface (the radio link 493 between the UE and the eNodeB). This protocol suite is referred to as the air interface protocol 494 stack, which is generally divided into three layers. Logically, these protocols set the foundation 495 for all TCP/IP traffic operating above it. These protocols are: 496 - Radio Resource Control (RRC) operating at layer 3; 497 - Packet Data Convergence Protocol (PDCP) operating at layer 2; 498 - Radio Link Control (RLC) operating at layer 2; 499 - Medium Access Control (MAC) operating at layer 2; and 500 - Physical Access (PHY) operating at layer 1. 9 ----- 501 502 **Figure 4 - LTE Protocol Stack** 503 Each protocol within the air interface cellular stack performs a series of functions and operates 504 on one of two logical planes: the user plane or the control plane. The user plane is the logical 505 plane responsible for carrying user data being sent over the network (e.g., voice communication, 506 SMS, application traffic) while the control plane is responsible for carrying all of the signaling 507 communication needed for the UE to be connected. To make the technology evolution paths 508 somewhat independent, the 3GPP specifications partition the cellular protocols into two strata; 509 the Non-Access Stratum (NAS) and the Access Stratum (AS). The AS is all communication 510 between the UE and eNodeB occurring via the RF channel. The NAS consists of all non-radio 511 signaling traffic between UE and MME. All of a user's TCP/IP and other application traffic are 512 transmitted via the user plane. The control plane, which is required to setup, maintain, and 513 terminate the air interface connection between the UE and the MME, hosts the RRC protocol. 514 The PDCP, RLC, MAC, and PHY layers form the foundation of the air interface and are part of 515 both user and control planes. The aforementioned control and user planes operate on top of these 516 protocols. 517 518 The RRC performs a variety of control tasks such as broadcasting system information, 519 establishing a connection with the eNodeB, paging, performing authentication, bearer 520 establishment, and transferring Non-Access Stratum (NAS) messages. The PDCP performs 521 header compression, packet reordering, retransmission, and access stratum security (including 522 integrity and confidentiality protections). As stated in TS 33.401, all cryptographic protection, 523 both confidentiality and integrity, is mandated to occur at the PDCP layer [5]. The RLC readies 524 packets to be transferred over the air interface and transfers data to the MAC layer. It also 525 performs packet reordering and retransmission operations. The MAC performs multiplexing, 526 channel scheduling, Quality of Service (QoS) activities, and creates a logical mapping of data to 527 the PHY layer. The PHY layer provides error management, signal processing, and modulates 10 ----- 528 data onto and off of the air interface. 529 The interfaces between the components within the E-UTRAN and the EPC have their own 530 communication protocols, not listed here. 531 **2.4** **LTE Bearers** 532 In LTE networks, connections must be established between endpoints before user traffic can be 533 communicated, and these connections are called bearers. A bearer is a connection between two 534 endpoints that contains specific information about the traffic class, bit rate, delivery order, 535 reliability, priority, and quality of service for its connection. A bearer may span multiple 536 interfaces. It is important to note that there are two main types of bearers: signaling radio bearers 537 and transport bearers. Signaling radio bearers are established on the control plane in order to 538 allow signaling communication between the UE and eNodeB, and the eNodeB and MME. 539 Transport bearers are established along the path of the user plane in order to allow transmission 540 of user data to its desired endpoint. 541 There are three signaling radio bearers that must be established which are solely used for the 542 purpose of transmitting RRC and NAS messages [30]: 543 - **Signaling Radio Bearer 0 (SRB0): SRB0 is responsible for establishing the RRC** 544 connection between the UE and eNodeB. 545 - **Signaling Radio Bearer 1 (SRB1): SRB1 is responsible for the exchange of security** 546 information, measurement reports, fallback parameters, and handover information. 547 - **Signaling Radio Bearer 2 (SRB2): SRB2 is responsible for the transferring of** 548 measurement information as well as NAS messages. SRB2 is always configured after the 549 establishment of SRB1 and security activation. 550 Once the SRBs are set up, the UE is connected to the core network through a specific eNodeB, 551 and is ready to transmit and receive user data. Throughout the LTE network there are multiple 552 connection points (UE to eNodeB, eNodeB to S-GW, etc.) that user traffic must traverse. In 553 order for user traffic to be allowed to traverse the LTE network multiple bearers must be 554 established. For a UE to have full network connectivity the following bearers must be established 555 in this order [29]: 556 - **Data Radio Bearer (DRB): Established between the UE and eNodeB on the Uu** 557 interface. It allows direct user data communication between the UE and eNodeB. 558 - **S1 Bearer: Established between the eNodeB and the appropriate S-GW on the S1-U** 559 interface. 560 - **E-UTRAN Radio Access Bearer (E-RAB): This is a combination of the DRB and S1** 561 Bearer and creates a connection between the UE and S-GW. 562 - **S5/S8 Bearer: Established between S-GW and the appropriate P-GW for the user data** 563 plane. 564 - **EPS Bearer: This is a combination of the E-RAB and the S5/S8 Bearer and provides** 565 user plane connectivity from the UE to the appropriate P-GW. 566 - **External Bearer: Established between the P-GW and a resource external to the EPC that** 567 the UE needs to access, such as connectivity to the internet. 11 ----- 568 - **End-to-End Service: This is a combination of the EPS Bearer and the External Bearer** 569 and allows user plane access from a UE to the appropriate resource that is external to the 570 EPC. 571 Throughout the UE attach process, bearers are established on an as needed basis. 572 **2.5** **UE Attach** 573 Before a UE can join an LTE network and access voice and data services, it must go through a 574 procedure to identify itself to the LTE network. This process is known as the Initial Attach 575 _Procedure and_ handles the communication of identifiable information from the UE to the LTE 576 EPC to ensure that the UE can access the network. If the process is successful, then the UE is 577 provided default connectivity, with any charging rules that are applicable and enforced by the 578 LTE network. The attach process is defined by TS 23.401 and is illustrated in Figure 5 below 579 _General Packet Radio Service (GPRS) enhancements for E-UTRAN access [2]._ 580 The Initial Attach procedure begins with an attach request from the UE to the MME via the 581 eNodeB. This request includes the IMSI, tracking information, cryptographic parameters, NAS 582 sequencing number, and other information about the UE. The ATTACH REQUEST is sent as a 583 NAS message. The eNodeB then forwards the ATTACH REQUEST along with information 584 about the cell to which the UE is connected on to the MME. For each PDN that the UE connects 585 to, a default EPS bearer is established to enable the always-on IP connectivity for the users and 586 the UE during Network Attachment. 587 If there are specific Policy and Charging Control rules in the PCRF for a subscriber or device for 588 the default EPS bearer, they can be predefined in the P-GW and turned on in the attachment by 589 the P-GW itself. During attachment, one or more Dedicated Bearer Establishment procedures 590 may be launched to establish dedicated EPS bearer(s) for the specific UE. Also during the attach 591 procedure, IP address allocation may be requested by the UE. The MME obtains the IMEI from 592 the UE and checks it with an EIR (Equipment Identity Register), which may verify that this UE’s 593 IMEI is not blacklisted. The MME then passes the IMEI software version to the HSS and P-GW. 594 Once a UE has gone through the initial attach procedure it is assigned a GUTI by the MME. The 595 GUTI is stored in both the UE and the MME and should be used when possible instead of the 596 IMSI for future attach procedures for the specific UE. 12 ----- 597 598 **Figure 5 - Initial Attach** 599 600 Once the attach procedure is successfully completed, the UE authenticates via the Authentication 601 and Key Agreement (AKA) protocol defined in section 3.3. 602 13 ----- 603 **3** **LTE Security Architecture** 604 This section describes the authentication, cryptographic protection mechanisms, hardware 605 protection mechanisms, and network protections LTE provides in further detail. A high level 606 discussion of LTE security goals is provided within [9] and an understanding of 3GPP’s rationale 607 for making certain security decisions and assumptions is recorded within [7]. The majority of 608 technical security requirements are available within the primary LTE security specification – 609 3GPP TS 33.401 – EPS Security Architecture [5]. 610 **3.1** **Cryptographic Overview** 611 In older 2G cellular systems, the cryptographic algorithms used to secure the air interface and 612 perform subscriber authentication functions were not publicly disclosed. The GSM algorithm 613 families pertinent to our discussion are A3, A5, and A8. A3 provides subscriber authentication, 614 A5 provides air interface confidentiality, and A8 is related to A3, in that it provides subscriber 615 authentication functions, but within the SIM card. UMTS introduced the first publicly disclosed 616 cryptographic algorithms used in commercial cellular systems. The terms UEA (UMTS 617 Encryption Algorithm) and UIA (UMTS Integrity Algorithm) are used within UMTS as broad 618 categories. UEA1 is a 128-bit block cipher called KASUMI, which is related to the Japanese 619 cipher MISTY. UIA1 is a message authentication code (MAC), also based on KASUMI. UEA2 620 is a stream cipher related to SNOW 3G, and UIA2 computes a MAC based on the same 621 algorithm [27]. LTE builds upon the lessons learned from deploying the 2G and 3G 622 cryptographic algorithms. 623 LTE introduced a new set of cryptographic algorithms and a significantly different key structure 624 than that of GSM and UMTS. There are 3 sets of cryptographic algorithms for both 625 confidentiality and integrity termed EPS Encryption Algorithms (EEA) and EPS Integrity 626 Algorithms (EIA). EEA1 and EIA1 are based on SNOW 3G, very similar to algorithms used in 627 UMTS. EEA2 and EIA2 are based on the Advanced Encryption Standard (AES) with EEA2 628 defined by AES in CTR mode (e.g., stream cipher) and EIA2 defined by AES-CMAC (Cipher629 based MAC). EEA3 and EIA3 are both based on a Chinese cipher ZUC [5]. 630 Many keys in LTE are 256-bits long, but in some current implementations only the 128 least 631 significant bits are used. The specification has allowed for a system-wide upgrade from 128-bit 632 to 256-bit keys.[1] In LTE, the control and user planes may use different algorithms and key sizes. 633 This diagram depicts the various keys alongside their use for an appropriate protocol. 1 3GPP 33.401 Section 6.1 a [7] 14 ----- 634 635 **Figure 6 - Keys Protecting the Network Stack** 636 The following table depicts various LTE key sizes and the other keys in the key hierarchy from 637 which they are derived [5].[ 2] 638 **Table 1 - Cryptographic Key Information Summary** **Key** **Name** **Length** **Derived in Part From** K Master Key 128 N/A: Pre-shared root key IK Integrity Key 128 K CK Cipher Key 128 K KASME MME Base Key 256 CK, IK NH Next Hop 256 KASME KeNB* eNB Handover Key 256 KASME, KeNB KeNB eNB Base Key 256 KASME, NH KNASint NAS Integrity Key 128 KASME KNASenc NAS Confidentiality Key 128 KASME 2 3GGP TS 33.401 Figure 6.2-2 15 |Key|Name|Length|Derived in Part From| |---|---|---|---| |K|Master Key|128|N/A: Pre-shared root key| |IK|Integrity Key|128|K| |CK|Cipher Key|128|K| |K ASME|MME Base Key|256|CK, IK| |NH|Next Hop|256|K ASME| |K eNB*|eNB Handover Key|256|K , K ASME eNB| |K eNB|eNB Base Key|256|K NH ASME,| |K NASint|NAS Integrity Key|128|K ASME| |K NASenc|NAS Confidentiality Key|128|K ASME| ----- |RRC enc|RRC Confidentiality Key|128|K NH eNB,| |---|---|---|---| |RRC int|RRC Integrity Key|128|K NH eNB,| |UPenc|UP Confidentiality Key|128|K NH eNB,| 639 640 **3.2** **Hardware Security** 641 The UICC is the next-generation Subscriber Identity Module (SIM) card used in modern mobile 642 devices and is the foundation of the LTE security architecture. The UICC hosts the Universal 643 Subscriber Identity Module (USIM) application that performs the full range of security critical 644 operations required of LTE cellular networks, such as authentication and other cryptographic 645 functions. The UICC is a tamper resistant removable storage device that users can leverage to 646 move their cellular service from one cellular device to another, while also providing the 647 capability of storing contacts and other user data. The UICC houses a processor, ROM, RAM, is 648 network aware, and is capable of running small Java applications used for a variety of functions 649 ranging from maintenance, updates, and even video games. The UICC can also potentially be 650 used for identity services and Near Field Communication (NFC). 651 From a security perspective, one of the most important functions of the UICC is cryptographic 652 key and credential storage. In LTE, UICCs are provisioned with a long-term, pre-shared 653 cryptographic key referred to as K. This key is stored within the tamper resistant UICC and also 654 within the core network (in the HSS) and is never to leave either of those locations [15]. All 655 other keys in LTE’s cryptographic structure are derived from K, with the session master key 656 referred to as KASME. Security functions such as cryptographic operations and subscriber 657 authentication are performed by the UICC in conjunction with the HSS and MME, the UICC 658 also plays a role in storing LTE security contexts. Security contexts contain cryptographic keys, 659 UE security capabilities, and other security parameters generated during an attach that can be 660 reused during future system accesses. The UICC also stores the IMSI and IMEI, which are both 661 used to support the use of identities. Some modern mobile equipment operating systems 662 implement the USIM PIN specified by 3GPP TS 121.111 [31]. This allows a PIN to be 663 configured on a UICC. Since UICCs can be removed from one mobile device and inserted into 664 another to provide service, the UICC PIN can prevent someone from stealing another user’s 665 UICC and obtaining unauthorized network access that they are not paying for. 666 **3.3** **UE Authentication** 667 The primary LTE authentication mechanism mobile handsets used to authenticate to an LTE 668 network is known as the Authentication and Key Agreement (AKA) protocol. The use of AKA 669 in LTE is required by 3GPP TS 33.401 [5]. The AKA protocol cryptographically proves that the 670 UICC and MNO have knowledge of the secret key K. From a security perspective, this 671 effectively authenticates the UICC to the network, but not the user or mobile device. An AKA 672 protocol run is depicted and further described below: 673 16 ----- 674 675 **Figure 7 - Authentication and Key Agreement Protocol** 676 677 The AKA procedure occurs as part of the UE attach process, described in Section 0, and provides 678 mutual authentication between the UICC and the LTE network. 679 AKA is begun by a UE providing its identifier to the appropriate MME (item 1 above). This 680 identifier may be permanent, as is the case with the IMSI, or may be temporary. Examples of 681 temporary identifiers include the Temporary Mobile Subscriber Identity (TMSI) and Globally 682 Unique Temporary UE Identity (GUTI). After the identifier is provided to the core network, the 683 MME provides the identifier, alongside additional cryptographic parameters and the serving 684 network ID, to the HSS/AuC (item 2 above) these values then are used to generate an 685 authentication vector (AUTN). To compute an AUTN, the HSS/AuC needs to use a random 686 nonce (RAND), the secret key K, and a Sequence Number (SQN) as inputs to a cryptographic 687 function. This function produces two cryptographic parameters used in the derivation of future 688 cryptographic keys, alongside the expected result (XRES) and authentication token (AUTN) 689 (item 3 above). This authentication vector is passed back to the MME for storage (item 4 above). 690 In addition, the MME provides the AUTN and RAND to the UE, which is then passed to the 691 USIM application (item 5 above). The USIM sends AUTN, RAND, the secret key K, and its 692 SQN through the same cryptographic function used by the HSS/AuC (item 6 above). The result 693 is labeled as RES, which is sent back to the MME (item 7 above). If the XRES value is equal to 694 the RES value, authentication is successful and the UE is granted access to the network (item 8 695 above). 696 **3.4** **Air Interface Security** 697 The UE and the eNodeB communicate using a Radio Frequency (RF) connection commonly 17 ----- 698 referred to as the air interface, which is referred to as the Uu interface. Both endpoints modulate 699 IP packets into an RF signal that is communicated over the air interface; these devices then 700 demodulate the RF signal into IP packets understandable by both the UE and EPC. The eNodeB 701 routes these packets through the EPC while the UE uses the IP packets to perform some function. 702 These radio waves are sent from a UE’s antenna over the air until they reach the antenna of the 703 eNodeB, this over the air communication is not necessarily private, meaning anything within the 704 wave path can intercept these radio raves. The figure below illustrates where in the network this 705 is occurring. 706 707 **Figure 8 - Highlighting the Air Interface** 708 3GPP’s technical specification 33.401 directs that both the NAS and RRC control plane 709 messages must be integrity protected. 3GPP TS 33.401 5.1.4.1 requires that “Integrity protection, 710 and replay protection, shall be provided to NAS and RRC-signalling.” It is specified that user 711 plane packets traveling on the Uu interface are not integrity protected. Specifically, 3GPP TS 712 33.401 5.1.4.1 states “User plane packets between the eNodeB and the UE shall not be integrity 713 protected on the Uu interface.” 714 715 Both control plane and user plane packets communicating between the UE and eNodeB on the 716 Uu can be confidentiality protected but this is left as optional. This statement is based on a 717 requirement located in 3GPP TS 33.401 5.1.4.1: “User plane confidentiality protection shall be 718 done at PDCP layer and is an operator option”. Air interface confidentiality provides a higher 719 level of assurance that messages being sent over the air cannot be deciphered by an external 720 entity. LTE specifies a ciphering indicator feature in 3GPP TS 22.101 [6]; this feature is 721 designed to give the user visibility into the status of the access network encryption. 722 Unfortunately, this feature is not widely implemented in modern mobile phone operating 723 systems. Figure 9 and Figure 10 help to illustrate where on the network integrity and encryption 724 are provided by LTE. 18 ----- 725 726 **Figure 9 - Integrity Protection Requirements** 727 728 729 **Figure 10 - Confidentiality Protection Requirements** 730 731 An exact order is not specified for when the LTE network must negotiate security parameters for 732 a given connection. The TS 24.301 [10] permits the following 7 messages to be sent without 733 security protection: 734 - IDENTITY REQUEST (if requested identification parameter is IMSI); 735 - AUTHENTICATION REQUEST; 736 - AUTHENTICATION REJECT; 737 - ATTACH REJECT; 738 - DETACH ACCEPT (For non switch off); 739 - TRACKING AREA UPDATE REJECT; 740 - SERVICE REJECT. 741 742 Depending on network implementation these messages may be sent in a varying order. When a 743 message that requires protection needs to be sent the network must establish security parameters 744 and agree on algorithms. This establishment is initiated by the sending of the Security Mode 745 Command (SMC). The SMC dictates that the UE and serving network must initiate a 746 cryptographic algorithm negotiation in order to select appropriate algorithms for: RRC ciphering 19 ----- 747 and integrity protection on the Uu interface, user plane cyphering on the Uu interface, and NAS 748 cyphering and NAS integrity protection between UE and MME. It is important to note that the 749 network selects the algorithm based upon security capabilities of the UE and a configured list of 750 available security capabilities on the serving network. 751 752 Separate Access Stratum (AS) and Non Access Stratum (NAS) level SMC procedures are 753 required to configure security on each applicable portion of the protocol stack. The AS SMC is 754 used for configuring RRC and user plane level protections, while the NAS SMC is used for 755 configuring NAS level protections. 756 757 Once an AKA run has occurred, and the NAS and optionally the AS SMCs are sent, a security 758 context is generated. A security context is a collection of session keys and parameters used to 759 protect either the NAS or AS. Long term information such as K, or other identifiers like the 760 IMEI and IMSI are not stored within a security context. Typically, only the keys from KASME and 761 downward within the key hierarchy are stored. When a UE deregisters from an eNodeB, the 762 previous security context can be reused, avoiding a superfluous AKA run, which may add 763 network congestion and require additional computing power on behalf of the core network. 764 765 **3.5** **E-UTRAN Security** 766 The radio access network and associated interfaces make up the E-UTRAN portion of the LTE 767 network, and which is the midway between a handset and an MNO’s core network. Handover is 768 one of the most important functions of a cellular network, allowing the user the ability to be 769 moving, such as traveling on a highway, and maintain call connection. Base stations will often 770 need to communicate between themselves to enable this “mobility”, and they do so via the X2 771 interface. 3GPP specifies multiple security mechanisms to ensure a secure handoff of call related 772 information. 773 Two types of handovers exist: X2 handover and S1 handover. During an S1 handover the MME 774 is aware that a handover is going to occur before it happens. Within an X2 handover, the MME is 775 unaware and the transition occurs purely between eNodeBs via the X2 interface. There are 776 unique security considerations for both methods of handover. With an S1 handover, the MME 777 can refresh the cryptographic parameters used to protect the air interface before the connection is 778 severed. With an X2 handover, fresh keying material can only be provided after the handover for 779 use in the next handover. 780 When handover occurs, new keys are generated, partly separating the new session from the 781 previous one, although a new master session key (i.e., KASME) is not generated. The KeNB is used, 782 alongside other cryptographic parameters and the cell ID of the new eNodeB, to generate KeNB*, 783 which is used to protect the new session after handover occurs. It is of note that the source base 784 station and MME control key derivation and the new eNodeB is not meant have knowledge of 785 the keys used in the original eNodeB session. 786 **3.6** **Backhaul Security** 787 3GPP has specified optional capabilities to provide confidentiality protection to various LTE 20 ----- 788 network interfaces. Section 3.4 discuses optional confidentiality protection provided between 789 UEs and eNodeBs on the Uu interface as well as communication between eNodeBs on the X2 790 interface. According to the LTE technical specifications 33.401, confidentiality protection is also 791 optional between eNodeBs and the Evolved Packet Core S1 interface. 3GPP specifies that the 792 use of IPsec in accordance with 3GPP TS 33.2103 NDS/IP should be implemented to provide 793 confidentiality on the S1 interface but the specification goes on to note that if the S1 interface is 794 trusted or physically protected, confidentiality protection is an operator option. Trusted or 795 physically protected is not further defined within the 3GPP specification. 796 The endpoints the S1 interface connects are very often many miles apart, meaning all data being 797 sent over the LTE network is traveling any number of miles from a cell tower location to the 798 facility where the EPC is located. The physical means to provide this backhaul connection can 799 vary, some technologies include; Microwave, Satellite, Ethernet, Underground Fiber, etc. 800 Physically protecting the S1 interface requires the MNO to have security controls in place at 801 every location through which this connection is routed. It is very likely the cellular MNO does 802 not own or operate the physical connection used to backhaul LTE network traffic, making it 803 difficult for the MNO to ensure the S1 interface is physically protected. The network operator 804 may depend on other network security measures (e.g., MPLS VPN, layer 2 VPN) to protect the 805 traffic traversing the S1 interface and ensure this interface is trusted. 806 807 **Figure 11 - Protecting the S1 Interface** 808 An all IP-based system introduces certain security concerns that are not applicable to older 809 cellular networks. Prior to LTE if an adversary wanted to intercept traffic on a cellular network, 810 specialized hardware was required. With LTE the transport mechanism between the eNodeB and 811 the EPC is all IP, all that is required to intercept traffic is basic networking experience, computer, 3 3GPP TS 33.210 V12.2.0 (2012-12) 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G security; Network Domain Security (NDS); IP network layer security (Release 12) [3] 21 ----- 812 network cable, and access to a switch port. If confidentiality is not provided on the S1 interface 813 all traffic being intercepted is sent in clear text. 814 3GPP TS 33.210 specifies, “For native IP-based protocols security shall be provided at the 815 network layer. The security protocols to be used at these network layer are the IETF defined 816 IPsec security protocols as specified in RFC-4301 and in RFC-2401”.[4] This 3GPP document 817 introduces the notion of Security Domains and using Security Gateways (SEG) or firewalls at the 818 edge of these domains in order to provide security. Security domains are “networks that are 819 managed by a single administrative authority” [3]. These are an important delineation of LTE 820 networks, however, they are ambiguously defined which can lead to different interpretations and 821 documentation for security domains. An example of this could be that all of the EPC components 822 and communication hosted in the same datacenter, with physical security controls provided by 823 the MNO. It could also mean that an MNO defines all components of the core as a single 824 security domain because the same administrative group manages them, even though they are 825 spread geographically throughout the country. Confidentiality is provided by initiating an IPsec 826 tunnel at the eNodeBs for traffic traveling over the (potentially not physically secure) S1 827 interface and terminating the tunnel at the security gateway placed at the edge of the Security 828 Domain where the EPC is hosted. 829 830 **Figure 12 - Sample Illustration of Security Gateways** 831 The use of IPsec on the S1 interface will require endpoints terminating the IPsec tunnel to be 832 provisioned with pre-shared keys or digital certificates. The use of a scalable system such as 833 Public Key Infrastructure (PKI) is likely to be utilized for a commercial LTE network. The 834 security parameters used to establish the encrypted connection can be dynamically negotiated 835 using Internet Key Exchange (IKE) based on policies configured at the endpoints. Both 836 endpoints of the IPsec tunnel (eNodeB & SEG) contain digital certificates or pre-shared keys, 837 provisioned either manually or dynamically from the PKI system. If digital certificates are not 838 pre-provisioned a Certificate Authority (CA) can be used to issue digital certificates and will 4 Citations from this quote were omitted to avoid citation collisions from the source document and this document 22 ----- 839 need to be accessible to endpoints on the LTE network. For more information regarding Public 840 Key Technology reference NIST SP 800-32 [26]. 841 **3.7** **Core Network Security** 842 As previously mentioned, 3GPP has specified optional security capabilities for various 843 connections within LTE networks. However, even though 3GPP has noted in its standards that 844 since LTE has introduced an all IP-based network, there needs to be more focus on security of 845 the EPC than there was in 2G/3G there is no specific security guidance tailored for the EPC [3]. 846 Although, traditional IP network security guidelines and operational procedures may be 847 beneficial. Since the core network handles the majority of control plane signaling, security needs 848 to be a primary consideration. 849 As specified in TS 33.210, the LTE network must be logically and physically divided into 850 different security domains. If any components of the core are in different security domains then 851 traffic between them is required to be routed through an SEG using IPsec for encryption and 852 integrity protection [3]. Due to the ambiguities associated with defining a security domain, an 853 operator’s core network may be considered one security domain. This implies a lack of security 854 on standard communication between core LTE network components. If this is the case, then all 855 of the signaling and user traffic being transmitted in the core would be transmitted in the clear, 856 without confidentiality protection. However, if different pieces of the core are defined to exist in 857 distinct security domains, then traffic must be encrypted using IPsec between them. To ensure 858 that user and control data is protected in the appropriate places in the core network, careful 859 consideration should be given to how security domains are defined for a network. Confidentiality 860 protection may be implemented between different components of the core to ensure that the user 861 and signalling traffic is protected. 862 Currently, 3GPP is working on standards for Security Assurance Methodology (SECAM) for 863 3GPP nodes. The main document, TR 33.805, "studies methodologies for specifying network 864 product security assurance and hardening requirements, with associated test cases when feasible, 865 of 3GPP network products" [8]. There are plans to have accompanying documents to TR 33.805 866 that will have specific security considerations for each component of the core. 3GPP will first 867 create the Security Assurance Specifications (SCAS) for the MME as a trial. Once the initial 868 SCAS is completed for the MME, the 3GPP SA3 working group will continue work on SCAS 869 for the other network product classes. The MME SCAS, TR 33.806, is currently still in draft and 870 addresses the security assurance specification for the MME. 3GPP is partnering with GSMA 871 Network Equipment Security Assurance Group (NESAG) to establish an accreditation process 872 and resolution process to evaluate products against the requirements defined in the SCAS. 873 Core network security does not have any rigorous security specifications or requirements in the 874 3GPP standards. Future development of SCAS may require specific security controls to be 875 implemented within the individual core components. 23 ----- 876 **4** **Threats to LTE Networks** 877 This section explores general classes of threats to LTE networks grouped by related threat 878 categories. It is of note that the 3GPP SA3 Working Group explored threats to LTE networks and 879 authored a document listing many of threats addressed in this section [7]. Threat analyses 880 external to 3GPP have been performed, such as [16], [17], and [18], and were used as input to 881 this analysis. Many of the threats listed below have been identified via academic research, while 882 others may be documented and reported real-world attacks that have occurred in deployed 883 cellular systems. 884 While some of these threats may have an impact on network availability and resiliency, others 885 are limited user data integrity and confidentiality. Additionally, most of the threats mentioned 886 here would only affect a limited portion of the network. With increased availability of low cost 887 LTE hardware and software [21] many threats listed below can be implemented with a low level 888 of complexity [19] [25]. 889 **4.1** **General Cybersecurity Threats** 890 LTE infrastructure components (e.g., eNodeB, MME, S-GW) may run atop of commodity 891 hardware, firmware, and software, making it susceptible to publically known software flaws 892 pervasive in general purpose operating systems (e.g., FreeBSD and other *nix variants) or other 893 software applications. This implies that these systems need to be properly configured and 894 regularly patched to remediate known vulnerabilities, such as those listed in the National 895 Vulnerability Database [28]. The following subsections will address malware threats to specific 896 network components and the management of an LTE network. 897 **4.1.1 Malware Attacks on UE’s** 898 Malicious code infecting a mobile device's operating system, other firmware, and installed 899 applications could prevent a UE from accessing a cellular network. Malware could directly 900 attack the baseband OS and its associated firmware. Attacking the baseband OS could change 901 important configuration files for accessing the network or prevent important routines from 902 running, such as those interpreting the signaling from a base station. Either of these would cause 903 a denial of service. 904 **4.1.2 Malware Attacks on Base Station Infrastructure** 905 Malware installed on a mobile device, or infecting a mobile device's operating system and other 906 firmware, could be part of a botnet launching an attack against a carrier’s radio network 907 infrastructure. A Distributed Denial of Service (DDoS) attack could be launched via a continuous 908 stream of attach requests, or requests for high bandwidth information and services, is one manner 909 of causing this attack. An unintentional DDoS attack on a carrier’s radio infrastructure has been 910 seen to occur via a mobile application making a large number of update requests [11]. Malware 911 can also compromise base station operating systems causing unexpected and undesirable 912 equipment behavior. 24 ----- 913 **4.1.3 Malware Attacks on Core Infrastructure** 914 Malware infecting components a carrier’s core network infrastructure would have the potential to 915 log network activity, modify the configuration of critical communications gateways, and sniff 916 user traffic (e.g., call traffic, SMS/MMS) depending on which components are infected. These 917 types of attacks have been previously observed in GSM networks [22], but as of this time there is 918 no known example of this attack within backend LTE infrastructure. 919 **4.1.4 Unauthorized OAM Network Access** 920 Operational and Access Management (OAM) networks are a vital part of an operational cellular 921 network, providing remote access into geographically spread out components of the network. 922 These OAM network interfaces provide quick access to network components, allowing MNOs to 923 manage and tune networks from one central location. Poor design and lack of hardening of these 924 management networks and interfaces create a serious security risk to the networks operational 925 stability. Unauthorized access to management interfaces can potentially allow malicious and 926 unintentional misconfigurations of critical network systems. 927 **4.2** **Rogue Base Stations** 928 Rogue base stations are unlicensed base stations that are not owned and operated by an authentic 929 MNO. They broadcast a cellular network masquerading as a legitimate carrier network. The 930 necessary hardware to construct these devices can be inexpensively obtained using commercial 931 off-the-shelf (COTS) hardware. The software required to operate a 2G (GSM) base station is 932 open source and freely available [20], and can be configured to operate as a rogue base station. 933 934 **Figure 13 - Example Rogue Base Station** 935 Rogue base stations exploit the fact that mobile handsets will attach to whichever base station is 936 broadcasting as its preferred carrier network and is transmitting at the highest power level. 937 Therefore, when a rogue base station is physically proximate to a mobile handset while 938 transmitting at very high power levels, the handset may attempt to connect to the malicious 939 network [23]. At the time of this writing, a large majority of rogue base stations broadcast a 2G 940 GSM cellular network. Unfortunately, the security protections offered by GSM lack mutual 941 authentication between the handset and cellular network, and strong cryptographic algorithms 942 with keys of sufficient length. Additionally, there is no requirement mandating that the 2G GSM 943 air interface is encrypted. 25 ----- 944 **4.2.1 Device and Identity Tracking** 945 As previously stated, both the IMSI (UICC) and IMEI (handset) act as unique identifiers. Both of 946 these identifiers can be indicators of who owns a mobile handset and where a device is 947 physically located. It is commonplace today for individuals to constantly keep their mobile 948 devices physically near them, and if a rogue base station is used to intercept traffic in an area, 949 such as where you reside, the operator of the rogue network may be able to identify whether a 950 specific individual is, or is not, residing within a specific location. This poses a threat to privacy 951 because an eavesdropper can determine if the subscriber is in a given location. Data needed for 952 geolocation is available via signaling channels, and is sent over the air interface during handset 953 attach and authentication. 954 **4.2.2 Downgrade Attacks** 955 Using a rogue base station broadcasting at a high power level, an attacker can force a user to 956 downgrade to either GSM or UMTS. As of the time of this writing, there are no significant, 957 publically known weaknesses in the cryptographic algorithms used to protect the confidentiality 958 and integrity of the UMTS air interface. Unfortunately, significant weaknesses exist for the 2G 959 GSM cryptographic algorithms used to protect the confidentiality and integrity of the air 960 interface. Examples of broken 2G cryptographic algorithms are A5/1 and A5/2 [15]. Depending 961 on the algorithm negotiated while attaching to the rogue base station, the air interface 962 cryptographic algorithms chosen to protect the air interface may be cryptographically broken, 963 leading to a loss of call and data confidentiality. 964 965 **Figure 14 – Simplified Downgrade Attack** 966 While GSM is out of scope for this document, real world deployments utilize GSM networks to 967 connect with LTE networks, which bring this into scope. 968 **4.2.3 Preventing Emergency Phone Calls** 969 Attackers using a rogue base station could prevent mobile devices physically close to the rogue 970 base station from accessing emergency services. This occurs when the rogue station fails to 971 forward user traffic onward to the MNO. If this attack occurs during an emergency situation, it 972 could prevent victims from receiving assistance from public safety services and first responders. 973 This attack may be detectable, since the UE believes it has cellular service but is unable to make 974 calls or send/receive data. This attack takes advantage of another vector that comes into play 26 ----- 975 while making emergency phone calls when the preferred network is not available. When making 976 an emergency phone call the UE might attach and attempt to send the call through a rouge base 977 station, even if the base station is not masquerading as a legitimate network. There is a risk that 978 the rogue base station will not forward the emergency call appropriately. 979 **4.2.4 Unauthenticated REJECT Messages** 980 As stated in section 3.4, during the UE attach procedure certain messages can be sent before 981 security parameters are negotiated. One of these unauthenticated messages is the ATTACH 982 REJECT message, which prevents a UE from completing the attach procedure. A rogue base 983 station coercing a UE to participate in a UE attach procedure can send this unauthenticated 984 ATTACH REJECT message. In response to receiving this message, a UE will no longer attempt 985 to attach to this, or other LTE networks. Since the ATTACH REJECT message is sent even 986 before the UE can authenticate the network, it is unable to distinguish the rogue base station 987 from a real one. This can cause a DOS that may persist until a hard reboot of the UE is 988 performed. Certain baseband implementations will not automatically try to reconnect if this 989 ATTACH REJECT message is received [25]. 990 Similarly, the TRACKING AREA UPDATE REJECT message can be sent by a rogue base 991 station in the same manner, and may have the same effect as the ATTACH REJECT message. 992 **4.3** **Air Interface Eavesdropping** 993 A complex eavesdropping attack is possible if the operator does not encrypt user plane LTE 994 traffic on the Uu interface. Attackers would need to have the proper equipment to capture and 995 store the radio communication between UE and eNodeB. In addition, the attackers would need 996 software to identify the specific LTE frequencies and timeslots a UE is using to communicate so 997 they can demodulate the captured traffic into IP packets. 998 **4.4** **Attacks Via Compromised Femtocell** 999 Femtocells offer a user the ability to have a small base station located within their house or other 1000 area. These small base stations can assist with poor reception to an eNodeB, which may cause 1001 slow, intermittent, or no access back to the core network. UEs attach to these devices like a 1002 typical eNodeB, but these devices often connect back to the MNO’s core via a user’s home 1003 internet connection through their Internet Service Provider (ISP). Femtocells have been 1004 standardized in LTE since release 8, and are referred to as H(e)NodeBs, HeNodeBs, or HeNBs. 1005 HeNBs are mandated to have an IPsec connection back to an HeNB gateway (HeNB-GW) to 1006 protect traffic flowing into and out of a MNO’s core network [4]. 1007 If the HeNBs is within the physical possession of an attacker, this provides unlimited time to 1008 identify a flaw on the HeNB. A compromised HeNBs can be used in a manner similar to a rogue 1009 base station, but it also has access to the cryptographic keys used to protect the cellular 1010 connection. They will provide attackers access to clear text traffic before it is sent back to the 1011 core network. Common methods of attack exploit implementation flaws in the host OS and 1012 drivers [14]. 27 ----- 1013 **4.5** **Radio Jamming Attacks** 1014 Jamming attacks are a method of interrupting access to cellular networks by exploiting the radio 1015 frequency channel being used to transmit and receive information. Specifically, this attack occurs 1016 by decreasing the signal to noise ratio by transmitting static and/or noise at high power levels 1017 across a given frequency band. This classification of attack can be accomplished in a variety of 1018 ways requiring a varying level of skill and access to specialized equipment. Jamming that targets 1019 specific channels in the LTE spectrum and is timed specifically to avoid detection is often 1020 referred to as smart jamming. Broadcasting noise on a large swath of RF frequencies is referred 1021 to as dumb jamming. 1022 **4.5.1 Jamming UE Radio Interface** 1023 A low cost, high complexity attack has been proposed to prevent the transmission of UE 1024 signaling to an eNodeB. Research from Virginia Tech [12] and other institutions [13] suggests 1025 that, due to the relatively small amount of LTE control signaling used by the LTE air interface 1026 protocols, this attack is possible. Further research is required to ascertain the level of complexity, 1027 severity, and probability of this attack succeeding. 1028 **4.5.2 Jamming eNodeB Radio Interface** 1029 Base stations may have physical (e.g., fiber optic) or wireless (e.g., microwave) links to other 1030 base stations. These links are often used to perform call handoff operations. As mentioned in 1031 section 4.5.1, it may be possible to jam the wireless connections eNodeBs use to communicate 1032 with each other. Although theoretical, the same type of smart jamming attacks that are used 1033 against the UE could be modified to target communicating eNodeBs, which would prevent the 1034 transmission of eNodeB to eNodeB RF communication. 1035 The 3GPP SA3 Working Group, the group that defines LTE security standards, states that this 1036 attack “…can be made with special hardware and countermeasures for these are not feasible to 1037 implement. However, jamming attacks may be detected and reported” [7]. This indicates that 1038 these types of jamming attacks are outside of the LTE threat model. 1039 **4.6** **Backhaul and Core Eavesdropping** 1040 The backhaul connection handles data communication between the LTE core and eNodeBs (cell 1041 sites). In section 3.6 this document explores backhaul security and optional standards based 1042 features to provide confidentiality on this critical interface. If the LTE network is not utilizing 1043 confidentiality protection on the backhaul interface the communication being sent to and 1044 received from cell sites is vulnerable to eavesdropping. It would be trivial to intercept 1045 communication if a malicious actor had access to network equipment terminating the S1 1046 interface. 1047 **4.7** **Physical Attacks on Network Infrastructure** 1048 The cell site is the physical location containing all of the equipment necessary to run and operate 1049 an eNodeB. Although these sites sometimes are enclosed by a fence and protected by a physical 1050 security system, it is possible for these defenses to be circumvented. A denial of service attack is 28 ----- 1051 possible if the equipment used to run the eNodeB is taken offline or somehow destroyed. For 1052 instance, copper theft is very common, which would result in a denial of serice. More subtle 1053 attacks that are much more difficult to detect are also possible if an attacker can obtain gain 1054 control of the systems running the eNodeB. 1055 **4.8** **Attacks Against K** 1056 Cryptographic keys enable LTE to provide many of the strong security features built into the 1057 system. As discussed in section 3.1, there are many different keys used to protect different layers 1058 of LTE communication. All of these keys are derived from a secret pre shared key referred to as 1059 ‘K’. This key resides in two places: one is the USIM running on the UICC and the other is within 1060 the carrier’s HSS/AuC. Depending on how K is provisioned to the UICC it may be possible for a 1061 malicious actor to gain access to this secret key responsible for all of LTE’s cryptographic 1062 functions. If an actor gains access to K they have the potential to both impersonate a subscriber 1063 on the network and the ability to decrypt communication from the subscriber for whom K was 1064 provisioned. 1065 **4.9** **Stealing Service** 1066 UICC cards are small cards that are removable from mobile devices by design. Service from an 1067 MNO is tied to a user’s UICC. This means it is possible for a UICC to be stolen from one mobile 1068 device, and placed into another with the goal of stealing service, including voice and data. 1069 Another means of stealing service is if an insider with access to the HSS or PCRF grants 1070 unapproved access to the network. For example, this could be an employee who activates UICCs 1071 unbeknownst to the MNO and sells them for personal profit. 29 ----- 1072 **5** **Mitigations** 1073 This section identifies mitigations to the threats identified in the previous section. It is of note 1074 that there is not a one to one mapping for the threats listed in Section 4 and the mitigations listed 1075 within Section 5, as there are unaddressed threats within this analysis. Each mitigation addresses 1076 at least one threat listed in Section 4. It is of note that the 3GPP SA3 working group has explored 1077 and authored a document detailing mitigations to many LTE threats listed in the previous section 1078 [7]. 1079 Ensuring that many of the following mitigations are implemented in cellular networks is out of 1080 the realm of possibility for everyday users, with the ability to enable change to be in the hands of 1081 MNOs, mobile operating system developers, and hardware manufacturers. MNOs can work to 1082 implement many of the mitigation techniques described in this section, however challenges may 1083 exist where hardware, firmware, and software do not support these countermeasures. It is 1084 important to work with the ecosystem in order to research, develop, and implement these security 1085 features in commercial cellular equipment. 1086 If these mitigations are important to a user, they may need to request these security protections 1087 from the appropriate party. Many of the listed mitigations may simply be modifying certain 1088 configurations of already implemented features, something that would be feasible in the near 1089 term. Others would require software updates to mobile operating systems, and/or baseband 1090 processors, or modifications to 3GPP standards, which will take much more time to implement. 1091 **5.1** **Cybersecurity Industry Recommended Practices** 1092 LTE infrastructure components (e.g., eNodeB, MME, S-GW) rely on purpose built systems to 1093 perform their network functions. The core software these systems run on is often a general 1094 purpose operating system. It is important that computer security recommended practices, 1095 including network, physical, and personnel security, be applied to these components in the same 1096 way they are applied to general information technology systems throughout industry today. 1097 Protection mechanisms such as patch management, configuration management, identity and 1098 access management, malware detection, and intrusion detection and prevention systems can be 1099 carefully planned and implemented throughout the MNO’s LTE infrastructure. These processes 1100 and protection mechanisms can be tailored to best support and protect the specialized LTE 1101 system. 1102 _Addresses the following threats: 4.1, 4.1.2, 4.1.3, 4.1.4_ 1103 **5.2** **Enabling Confidentiality on the Air Interface** 1104 Although integrity protection of NAS and RRC is mandatory, air interface encryption is left as 1105 an operator option in LTE systems [5]. Enabling cryptographic protection of the user plane over 1106 the Uu interface via the UPenc key can prevent passive eavesdropping attacks. It is possible that 1107 implementing confidentiality protection on the air interface can introduce significant latency into 1108 cellular networks, and it may also significantly impact a UE’s battery. Further testing, pilot 1109 programs, capable hardware in conjunction with a phase approach can be followed to provide 1110 confidentiality protection. 1111 _Addresses the following threats: 4.3_ 30 ----- 1112 **5.3** **Use of the Ciphering Indicator** 1113 As discussed in 4.2, the authentication procedure for the 2G GSM system does not perform 1114 mutual authentication between the mobile device and the base station. This allows for the 1115 possibility of a non-LTE rogue base station to perform a downgrade attack on a UE with an 1116 active LTE connection. This GSM connection may not be confidentiality protected. Current 1117 mobile devices do not provide the option for a user to know if their UE’s connection is encrypted 1118 to the eNodeB. 3GPP provides a mechanism to alert a user to an unencrypted connection, 1119 referred to as the ciphering indicator. 1120 The ciphering indicator is defined in 3GPP TS 22.101, which defines this indicator as a feature to 1121 inform the user as to the status of the user plane confidentiality protection. This feature could be 1122 implemented as a user interface notification appearing on the user’s mobile device and dose not 1123 provide functionality to prevent a call from being made. It is possible for the MNO to disable this 1124 feature with a setting in the USIM. 3GPP specifies the default behavior of the UE shall be to 1125 obey the setting configured in the USIM. However, it is possible for the UE to provide a user 1126 interface option to ignore the USIM setting and provide the user an indication of the status of the 1127 user plane confidentiality protection. “Ciphering itself is unaffected by this feature, and the user 1128 can choose how to proceed” [6]. 1129 This indicator would be beneficial to informed users wishing to know if their over the air cellular 1130 connection is encrypted or not. This may require new software from either the mobile 1131 operating system vendor (e.g., Apple, Google, Microsoft) or the baseband manufacturer (e.g., 1132 Qualcomm, Intel, Samsung). 1133 _Addresses the following threats: 4.3_ 1134 **5.4** **User-Defined Option for Connecting to LTE Networks** 1135 Rogue base stations often exploit the lack of mutual authentication that exists in GSM. Current 1136 mobile devices do not provide average users the option to ensure that a user's mobile device only 1137 connects to a 4G LTE network, a specific MNO’s (or MVNO’s) network, or a specific physical 1138 cellular site. If users could ensure that their mobile device is connected only to a 4G LTE 1139 network, mutual authentication is achieved between their UE and eNodeB via the LTE AKA 1140 protocol, and an active rogue base station attack downgrading the connection to GSM should not 1141 be possible. 1142 It is of note that a preferred network technology listing exists on many UEs, and depending on 1143 the platform, similar options may exist in testing modes, it is unclear if this option would prevent 1144 a UE that is under attack from connecting to a rogue base station. The current functionality is not 1145 intended to be a security feature but could provide vital defense against rogue base stations. The 1146 user-defined option is not widely deployed in UEs, and would likely require software updates 1147 from the mobile operating system vendor (e.g., Apple, Google, Microsoft) and/or the baseband 1148 manufacturer (e.g., Qualcomm, Intel, Samsung). This option would be beneficial to informed 1149 users wishing to only connect to LTE networks. 1150 _Addresses the following threats: 4.2.1, 4.2.2. 4.2.3_ 31 ----- 1151 **5.5** **Ensure Confidentiality Protection of S1 Interface** 1152 Both physical and logical security can be used to secure the backhaul connection of an LTE 1153 network. Placing devices in physically secure location is an important step in securing the 1154 backhaul connection and protecting it from malicious actors. Cryptographically securing the IP 1155 traffic traversing the backhaul connection is seen as equally important and provides a higher 1156 level of assurance and is possible via NDS/IP. Implementing confidentiality protection on the S1 1157 interface may introduce latency into cellular backhaul connections, and further research is 1158 required to understand if this latency would noticeably degrade service and traffic throughput. 1159 _Addresses the following threats: 4.6_ 1160 **5.6** **Encrypt Exposed Interfaces Between Core Network Components** 1161 To the extent that it does not significantly affect availability of network resources, the interfaces 1162 between core network nodes can be confidentiality protected in some way, possibly via the 1163 mechanisms defined in 3GPP TS 33.210. For instance, traffic between an S-GW and P-GW 1164 should be encrypted. In the near future, many of the network components may be either 1165 collocated on the same server as distinct applications or virtualized via Network Functions 1166 Virtualization (NFV).[5] NFV will enable workloads running on the same physical hardware to be 1167 logically separated, allowing communication between components to happen in software. This 1168 would continue to separate each function’s processes but could possibly eliminate an exposed 1169 physical interface. 3GPP and ETSI will provide forthcoming guidance for protecting these 1170 interfaces. 1171 _Addresses the following threats: 4.6_ 1172 **5.7** **Use of SIM/USIM PIN Code** 1173 As previously noted, some modern mobile equipment operating systems implement the USIM 1174 PIN specified by 3GPP TS 121.111 [31]. This enables local user authentication to the USIM via 1175 PIN configured on a UICC. Enabling the UICC PIN can prevent someone from stealing another 1176 subscriber’s UICC and obtaining unauthorized network access. An individual stealing the UICC 1177 and placing it into another device would be required to enter a PIN before they could continue 1178 any further. Many UICCs lock after 10 incorrect attempts and the user’s MNO would be required 1179 to provide an unlocking code to make the USIM usable again. The SIM/USIM PIN may degrade 1180 the user experience by adding additional authentication and slowing down the UE boot process. 1181 _Addresses the following threats: 4.9_ 1182 **5.8** **Use of Temporary Identities** 1183 A subscriber’s permanent identity, the IMSI, is one of the first parameters sent to an eNodeB 1184 when a UE attaches to the LTE network. IMSIs are sometimes sent in clear text over the air 1185 interface, and this may be unavoidable in certain scenarios. 3GPP defines multiple temporary 1186 identities that MNOs can leverage to avoid sending these sensitive identifiers over the air 1187 interface, such as the GUTI in LTE. When the GUTI is in use, user tracking should become more 5 http://www.etsi.org/technologies-clusters/technologies/nfv 32 ----- 1188 difficult. GUTIs need to be implemented in a manner so they are periodically refreshed via the 1189 _NAS GUTI Reallocation Command to ensure that it is a truly temporary identifier [19]._ 1190 _Addresses the following threats: 4.2.1_ 1191 **5.9** **3[rd] Party Over-the-Top Solutions** 1192 If an MNO is not encrypting a user’s traffic, or if a passive eavesdropping attack occurs, using a 1193 3[rd] party over the top service can provide strong authentication, integrity and confidentiality 1194 protection for user data. This mitigation would effectively use an MNO’s network as a “dumb 1195 pipe”, and a user would use an application running on the general-purpose mobile operating 1196 system to provide video, audio, or some other communication service. Additionally, 3[rd] party 1197 over-the-top solutions can act as a defense in depth measure, choosing not to rely soley on their 1198 MNO to provide confidentiality protection. 1199 _Addresses the following threats: 4.2.2, 4.3, 4.4, 4.6, 4.8_ 1200 **5.10 Unauthenticated Reject Message Behavior** 1201 In the presence of illegitimate messages with the ability to deny network access, a possible 1202 mitigation is for the UE to continue to search for other available networks while ignoring the 1203 network denying service. The baseband firmware could be tested to understand the behavior 1204 these systems exhibit when in the presence of unauthenticated reject messages. Additional 1205 research and development is needed to ensure that baseband processors are exhibiting behavior 1206 that does not cause unintentional DoS when receiving an illegitimate reject message. 1207 _Addresses the following threats: 4.2.4_ 33 ----- 1208 **6** **Conclusions** 1209 When compared to previous cellular networks, the security capabilities provided by LTE are 1210 markedly more robust. The additions of mutual authentication between the cellular network and 1211 the UE, alongside the use of publically reviewed cryptographic algorithms with sufficiently large 1212 key sizes are positive steps forward in improving the security of cellular networks. The enhanced 1213 key separation introduced into the LTE cryptographic key hierarchy and the mandatory integrity 1214 protection also help to raise the bar. 1215 Yet LTE systems are rarely deployed in a standalone fashion - they coexist with previous cellular 1216 infrastructure already in place. Older cellular systems continue to be utilized throughout many 1217 different industries today, satisfying a variety of use cases. With this in mind, it’s easy to see 1218 why LTE networks are often deployed in tandem with GSM and UMTS networks. This multi1219 generational deployment of cellular networks may lead to an overall decrease in cellular security. 1220 A primary example of this is the requirement for the baseband firmware to remain backward 1221 compatible, supporting legacy security configurations. 1222 The interconnection of these technologies introduces additional complexity into an already 1223 complicated system that is distributed over an immense geographic area, that is continental in 1224 scale. Cellular networks traditionally use separate networks to communicate call signaling 1225 information. Specifically, the SS7 network has been in use for decades and has its own unique 1226 set of security challenges that is separate from the cellular network technology. An LTE-specific 1227 version of Diameter was specified by 3GPP to, in part, resolve the challenges associated with the 1228 use of SS7, although it is not widely deployed. It’s important for MNOs and all interested parties 1229 to perform their own security analysis of this technology in order to understand how to 1230 appropriately mitigate the risks introduced by these signaling technologies. This security analysis 1231 should include how any partnering MNO also mitigates these risks in their own network, since a 1232 weakness in one MNO’s network adversely affects the security of those its connected to. 1233 LTE’s sole use of IP technology is a major differentiator from previous cellular networks. LTE 1234 does not use circuit switching, instead opting to move to a purely packet switched system. IP is a 1235 commoditized technology that is already understood by Information Technology practitioners, 1236 which presents both challenges and opportunities. Attackers may be able to leverage existing 1237 tools for exploiting IP-based networks to attack the LTE core and other associated cellular 1238 infrastructure within an MNO’s network. Conversely, this may allow already existing IP-based 1239 defensive technology to be immediately applied to LTE networks. Hopefully, the application of 1240 these technologies will offer novel ways to increase system security. 1241 The following list highlights areas of the LTE security architecture that either lack the 1242 appropriate controls or have unaddressed threats: 1243 - **Default Confidentiality Protection for User Traffic: The LTE standards do not provide** 1244 confidentiality protection for user traffic as the default system configuration. Enabling 1245 user traffic encryption by default, except for certain scenarios such as emergency calls, 1246 would provide out of the box security to end users. 34 ----- 1247 - **Prohibiting user traffic integrity: Although the LTE standards require integrity** 1248 protection for critical signaling traffic, integrity protection for user traffic is explicitly 1249 prohibited, as stated in section 3.4. 1250 - **Lack of protection against jamming attacks: This is an active area of research, and** 1251 mitigations have been proposed, although it is unclear if these mitigations have been 1252 appropriately vetted and considered for inclusion into the LTE standard. 1253 - **OAM Networks: Vulnerabilities potentially exist on the OAM network depending on** 1254 how it is architected and managed. 1255 1256 While this document is focused on the fundamentals of LTE and its security architecture, many 1257 concepts were considered out of the scope of our analysis. Some of these concepts are services 1258 that build on top of the LTE architecture, while others come from specific implementations and 1259 uses of an LTE network. It is important that the security implications introduced by these 1260 concepts listed below are well understood, and require further research: 1261 - Security analysis of IMS, 1262 - Security analysis of VoLTE, 1263 - Protection against jamming attacks, 1264 - Enabling UE network interrogation, 1265 - LTE for public safety use, and 1266 - Security implications of Over the Air (OTA) updates. 1267 This document identified threats to LTE networks, and described potential mitigations to these 1268 issues. Exploring and enabling the mitigations included within this document will be a 1269 coordinated effort between mobile OS vendors, baseband firmware developers, standards 1270 organizations, mobile network operators, and end users. Developing solutions to the problems 1271 identified here, and continuing to perform relevant research is an important task since LTE is the 1272 nation’s dominant cellular communications technology. 35 ----- 1273 **Appendix A—Acronyms and Acronyms** 1274 Selected acronyms and abbreviations used in this paper are defined below. 1275 **2G** 2[nd] Generation 1276 **3G** 3[rd] Generation 1277 **4G** 4[th] Generation 1278 **AES** Advanced Encryption Algorithm 1279 **AKA** Authentication and Key Agreement 1280 **APN** Access Point Name 1281 **AS** Access Strum 1282 **AuC** Authentication Center 1283 **AUTN** Authentication Token 1284 **CA** Certificate Authority 1285 **CK** Confidentiality Key 1286 **COTS** Commercial off-the-Shelf 1287 **COW** Cell on Wheels 1288 **CSFB** Circuit Switch Fallback 1289 **DDoS** Distributed Denial of Service 1290 **DeNB** Donor eNodeB 1291 **DMZ** Demilitarized Zone 1292 **DoS** Denial of Service 1293 **DRB** Data Radio Bearer 1294 **EDGE** Enhanced Data rates for GSM Evolution 1295 **EEA** EPS Encryption Algorithm 1296 **EIA** EPS Integrity Algorithm 1297 **EIR** Equipment Identity Register 1298 **E-RAB** E-UTRAN Radio Access Bearer 1299 **eNB** eNodeB, Evolved Node B 1300 **eNodeB** Evolved Node B 1301 **EPC** Evolved Packet Core 1302 **EPS** Evolved Packet System 1303 **E-UTRAN** Evolved Universal Terrestrial Radio Access Network 1304 **GPRS** General Packet Radio Service 1305 **GSM** Global System for Mobile Communications 1306 **GSMA** GSM Association 1307 **GUTI** Globally Unique Temporary Identity 1308 **HeNB** Home eNodeB 1309 **HeNB-GW** HeNB Gateway 1310 **HSPA** High Speed Packet Access 1311 **HSS** Home Subscriber Server 1312 **IK** Integrity Key 1313 **IKE** Internet Key Exchange 1314 **IMEI** International Mobile Equipment Identifier 1315 **IMS** IP Multimedia Subsystem 1316 **IMSI** International Mobile Subscriber Identity 1317 **IoT** Internet of Things 36 ----- 1318 **IP** Internet Protocol 1319 **ISP** Internet Service Provider 1320 **LTE** Long Term Evolution 1321 **MAC** Medium Access Control 1322 **ME** Mobile Equipment 1323 **MitM** Man in the middle 1324 **MME** Mobility Management Entity 1325 **MMS** Multimedia Messaging Service 1326 **MNO** Mobile Network Operator 1327 **MPLS** Multiprotocol Label Switching 1328 **MVNO** Mobile Virtual Network Operator 1329 **NAS** Non-Access Stratum 1330 **NDS/IP** Network Domain Security / Internet Protocol 1331 **NESAG** Network Equipment Security Assurance Group 1332 **NFC** Near Field Communications 1333 **NFV** Network Function Virtualization 1334 **NH** Next Hop 1335 **OAM** Operational and Access Management 1336 **OS** Operating System 1337 **OTA** Over the Air 1338 **PCRF** Policy and Charging Rules Function 1339 **PDCP** Packet Data Convergence Protocol 1340 **PDN** Packet Data Network 1341 **P-GW** Packet Gateway 1342 **PHY** Physical Access 1343 **PKI** Public Key Infrastructure 1344 **PSTN** Public Switched Telephone Network 1345 **QoS** Quality of Service 1346 **RAND** Random Parameter 1347 **RAN** Radio Access Network 1348 **RF** Radio Frequency 1349 **RES** Response 1350 **RN** Relay Node 1351 **RRC** Radio Resource Control 1352 **SCAS** Security Assurance Specifications 1353 **SECAM** Security Assurance Methodology 1354 **SEG** Security Gateway 1355 **S-GW** Serving Gateway 1356 **SIM** Subscriber Identity Module 1357 **SMC** Security Mode Command 1358 **SMS** Short Message Service 1359 **SQN** Sequence Number 1360 **SRB** Signaling Radio Bearer 1361 **SoC** System on a Chip 1362 **SQN** Sequence Number 1363 **TCP** Transmission Control Protocol 37 ----- 1364 **TMSI** Temporary Mobile Subscriber Identity 1365 **TR** Technical Report 1366 **TS** Technical Specification 1367 **UE** User Equipment 1368 **UEA** UMTS Encryption Algorithm 1369 **UIA** UMTS Integrity Algorithm 1370 **UICC** Universal Integrated Circuit Card 1371 **UMTS** Universal Mobile Telecommunications System 1372 **USIM** Universal Subscriber Identity Module 1373 **VoLTE** Voice over LTE 1374 **VoIP** Voice over IP 1375 **VPN** Virtual Private Network 1376 **WiMAX** Worldwide Interoperability for Microwave Access 1377 **XRES** Expected result 38 ----- 1378 **Appendix B—References** [1] 3[rd] Generation Partnership Project, Releases, [http://www.3gpp.org/specifications/67-releases](http://www.3gpp.org/specifications/67-releases) [accessed 11/24/15] [2] 3[rd] Generation Partnership Project, General Packet Radio Service (GPRS) _enhancements for Evolved Universal Terrestrial Radio Access Network (E-_ _UTRAN) access, 3GPP TS 23.401 V13.4, 2015._ [http://www.3gpp.org/DynaReport/23401.htm](http://www.3gpp.org/DynaReport/23401.htm) [accessed 11/24/15] [3] 3[rd] Generation Partnership Project, Network Domain Security (NDS); IP _network layer security, 3GPP TS 33.210 V12.2.0, 2012._ [http://www.3gpp.org/DynaReport/33210.htm](http://www.3gpp.org/DynaReport/33210.htm) [accessed 11/24/15] [4] 3[rd] Generation Partnership Project, Security of Home Node B (HNB), 3GPP TS 33.320 V12.1, 2014. [http://www.3gpp.org/DynaReport/33320.htm](http://www.3gpp.org/DynaReport/33320.htm) [accessed 11/24/15] [5] 3[rd] Generation Partnership Project, System Architecture Evolution (SAE): _Security Architecture, 3GPP TS 33.401 V12.12, 2014._ [http://www.3gpp.org/DynaReport/33401.htm [accessed 11/24/15]](http://www.3gpp.org/DynaReport/33401.htm) [6] 3[rd] Generation Partnership Project, Service aspects; Service Principles, 3GPP TS 22.101 V14.1, 2015. [http://www.3gpp.org/DynaReport/22101.htm [accessed 11/24/15]](http://www.3gpp.org/DynaReport/22101.htm) [7] 3[rd] Generation Partnership Project, Rationale and track of security decisions _in Long Term Evolution (LTE) RAN / 3GPP System Architecture Evolution_ _(SAE), 3GPP TR 33.821 V9, 2009._ [http://www.3gpp.org/DynaReport/33821.htm [accessed 11/24/15]](http://www.3gpp.org/DynaReport/33821.htm) [8] 3[rd] Generation Partnership Project, Study on security assurance methodology _for 3GPP network products, 3GPP TR 33.805 V12, 2013._ [http://www.3gpp.org/DynaReport/33805.htm [accessed 11/24/15]](http://www.3gpp.org/DynaReport/33805.htm) [9] 3[rd] Generation Partnership Project, Service requirements for the Evolved _Packet System (EPS), 3GPP TS 22.278 V13.2, 2014._ [http://www.3gpp.org/DynaReport/22278.htm](http://www.3gpp.org/DynaReport/22278.htm) [accessed 11/24/15] [10] 3[rd] Generation Partnership Project, Non-Access-Stratum (NAS) protocol for _Evolved Packet System (EPS), 3GPP TS 24.301 V13.4, 2015._ http://www.3gpp.org/dynareport/24301.htm [accessed 02/10/16] [11] Dano, Mike. The Android IM App That Brought T-Mobile's Network to Its _Knees. Fierce Wireless, 2010._ [http://4g.hivefire.com/articles/share/351057/ [accessed 11/24/15]](http://4g.hivefire.com/articles/share/351057/) 39 ----- [12] Reed, Jeffrey, Comments of Wireless @ Virginia Tech, Virginia Tech College of Engineering, November 8, 2012. [http://www.ntia.doc.gov/files/ntia/va_tech_response.pdf [accessed 11/24/15]](http://www.ntia.doc.gov/files/ntia/va_tech_response.pdf) [13] R. Bassil, A. Chehab, I. Elhajj, and A. Kayssi, Signaling oriented denial of _service on lte networks, in Proceedings of the 10th ACM international_ symposium on Mobility management and wireless access. ACM, 2012, pp. 153–158. [14] DePerry, Doug, Ritter, Tom, and Rahimis, Andrew, Traffic Interception & _Remote Mobile Phone Cloning with a Compromised CDMA Femtocell, Las_ Vegas, Defcon 2013. http://securelist.com/files/2014/11/Kaspersky_Lab_whitepaper_Regin_platfo rm_eng.pdf [accessed 11/24/15]. [15] Dan Forsberg, G.H., Wolf-Dietrich Moeller, Valtteri Niemi, LTE Security. 2nd ed. 2012: Wiley. [16] Prasad, Anand and Aissi, Selim, Mobile Devices Security: Evolving Threat _Profile of Mobile Networks, RSA 2014._ [http://www.rsaconference.com/writable/presentations/file_upload/mbs-t07-](http://www.rsaconference.com/writable/presentations/file_upload/mbs-t07-mobile-devices-security-evolving-threat-profile.pdf) [mobile-devices-security-evolving-threat-profile.pdf [accessed 11/24/15]](http://www.rsaconference.com/writable/presentations/file_upload/mbs-t07-mobile-devices-security-evolving-threat-profile.pdf) [17] Bhasker, Daksha, 4G LTE Security for Mobile Network Operators, Published in Journal of Cyber Security and Information Systems 1-4 October 2013: Understanding Cyber Risks and Security Management. [18] Bikos, Sklavos. LTE/SAE Security Issues on 4G Wireless Networks, Published in IEEE Security & Privacy, March/April 2013. [19] Shaik, Borgaonkar, Asokan, et al, Practical attacks against privacy and _availability in 4G/LTE mobile communication systems, Computing Research_ Repository, October 2015. [20] Range Networks, OpenBTS Project, 2015. [http://openbts.org [accessed 11/24/15].](http://openbts.org/) [21] Wojtowicz, Ben, openLTE - An open source 3GPP LTE implementation, 2015. http://openlte.sourceforge.net/ [accessed 11/24/15]. [22] Kaspersky Labs, The Regin platform: Nation-State Ownage of GSM _Networks, Version 1.0, 2014._ [http://securelist.com/files/2014/11/Kaspersky_Lab_whitepaper_Regin_platfo](http://securelist.com/files/2014/11/Kaspersky_Lab_whitepaper_Regin_platform_eng.pdf) [rm_eng.pdf](http://securelist.com/files/2014/11/Kaspersky_Lab_whitepaper_Regin_platform_eng.pdf) [accessed 11/24/15] [23] Paget, Chris, Practical Cellphone Spying, Presented at Defcon 18, July 10 2010. 40 ----- [http://www.tombom.co.uk/blog/?p=262](http://www.tombom.co.uk/blog/?p=262) [accessed 12/1/15] [24] Hulton, David, Intercepting GSM traffic, Blackhat DC 2008, March 2008. [https://www.blackhat.com/presentations/bh-dc-08/Steve-](https://www.blackhat.com/presentations/bh-dc-08/Steve-DHulton/Presentation/bh-dc-08-steve-dhulton.pdf) [DHulton/Presentation/bh-dc-08-steve-dhulton.pdf [accessed 12/1/15]](https://www.blackhat.com/presentations/bh-dc-08/Steve-DHulton/Presentation/bh-dc-08-steve-dhulton.pdf) [25] Jover, Roger Piqueras, LTE security and protocol exploits, Shmoocon 2016. [http://www.ee.columbia.edu/~roger/ShmooCon_talk_final_01162016.pdf](http://www.ee.columbia.edu/%7Eroger/ShmooCon_talk_final_01162016.pdf) [accessed 2/1/16] [26] NIST Special Publication (SP) 800-32, Introduction to Public Key _Technology and Federal PKI Infrastructure, National Institute of Standards_ and Technology, Gaithersburg, Maryland, February 2001. http://csrc.nist.gov/publications/nistpubs/800-32/sp800-32.pdf. [27] ETSI/SAGE, Specification of the 3GPP Confidentiality and Integrity _Algorithms UEA2 & UIA2. Document 1: UEA2 and UIA2 Specification,_ Version 2.1, March 16, 2009 [accessed 2/15/16] [28] [NIST, National Vulnerability Database. [Web page] http://nvd.nist.gov/](http://nvd.nist.gov/) [accessed. [29] 3rd Generation Partnership Project, Evolved Universal Terrestrial Radio _Access Network (E-UTRAN); S1 data transport, 3GPP TS 36.414 V12.1,_ 2014. http://www.3gpp.org/dynareport/36414.htm [accessed 2/10/16] [30] 3[rd] Generation Partnership Project, Evolved Universal Terrestrial Radio _Access (E-UTRA); Radio Resource Control (RRC); Protocol specification,_ 3GPP TS 36.331 V12.8, 2016. http://www.3gpp.org/dynareport/36331.htm [accessed 2/10/16] [31] 3[rd] Generation Partnership Project, USIM and IC card requirements, 3GPP TS 21.111 V13, 2016. http://www.3gpp.org/DynaReport/21111.htm [accessed 2/25/16] 1379 41 -----