Thursday, June 21, 2018
Introduction to 4G Security: LTE Security Architecture

Introduction to 4G Security: LTE Security Architecture





The very first mobile telephony system (AMPS) was based on analog technology and offered no security features at all. With the introduction of the second generation 2G GSM system security became a part of mobile telecommunication. Since then, attempts have continually been made to improve security features in mobile telephony systems. In this second article, we will take a look at the security features in the 4th Generation Long Term Evolution (4G LTE) standards defined by 3GPP™.


LTE networks are divided in two parts in a similar fashion as the legacy 3G and 2G networks are. These parts are the access network called EUTRAN (Evolved UMTS Terrestrial Radio Access Network) and the EPC (Enhanced Packet Core). The communication layer between a mobile device and the EUTRAN is called the ‘Access Stratum’ (AS) and the communication or transfer of information between a mobile device and the nodes in the EPC happen in the logical ‘Non-Access Stratum’ (NAS). For a mobile device point of view, LTE standard offers security mechanisms to protect transfer of information on both AS and NAS layers. The 3GPP standard (TS 33.401) for LTE defines five aspects of security in LTE:

  • Network access security (I): the set of security features that provide users with secure access to services, and which in particular protect against attacks on the (radio) access link.
  • Network domain security (II): the set of security features that enable nodes to securely exchange signaling data, user data (between AN and SN and within AN), and protect against attacks on the wire line network.
  • User domain security (III): the set of security features that secure access to mobile stations.
  • Application domain security (IV): the set of security features that enable applications in the user and in the provider domain to securely exchange messages.
  • Visibility and configurability of security (V): the set of features that enables the user to inform himself whether a security feature is in operation or not and whether the use and provision of services should depend on the security feature.

 In this article, we will primarily focus on network access security. LTE provides two different security protection options for both user data and signalling data:

  1. Data Confidentiality – Provides protection against unauthorized eavesdropping.
  2. Data Integrity – Provides authentication mechanisms for both users and networks to protect against threats such as Man-in-the-middle or Replay attacks.

In addition, LTE also provides an ‘Authentication’ procedure to authenticate both mobile subscribers’ as well as the network’s legitimacy.


The master key for each mobile subscription (called ‘K’ –Figure 1) is stored in the USIM module as well as in the EPC in the AuC (Authentication Centre) network node. The mobile device (UE) itself or any other network nodes in the EPC/EUTRAN have no direct access or knowledge of this ‘Master key’ K. All the keys used in the mobile device/EUTRAN/EPC are derived from this master key ‘K’. The following Keys are derived in the USIM/EUTRAN/EPC and used by the mobile device and the EUTRAN7EPC nodes:

  • CK/IK (Cipher Key/Integrity Key): The CK/IK pair is derived directly from ‘K’. This derivation is performed in the AuC node and also in the USIM. The mobile device receives the derived CK/IK pair from the USIM and the HSS node in the EPC receives the CK/IK pair from the AuC. The CK/IK pair generation is performed during an ‘EPS Authentication and Key Agreement’ (EPS-AKA) procedure.
  • KASME: This is an intermediate key (Key-Access Security Management Entity) derived by the mobile device (UE) during the EPS AKA procedure and fetched by the MME from the HSS as part of a data triplet known as ‘Authentication Vector’ (AV). The key KASME is never exchanged over the air. Instead, the KASME to be used is identified by the key set identifier eKSI, which is sent to the UE by the MME in the ‘EMM:Authentication Request’ message during the EPS-AKA procedure. eKSI may be either of type KSI or of type KSISGSN. eKSI shall be stored in the UE and the MME.
  • KeNB: This Key is derived by the UE and MME is a key derived by ME and MME from KASME. 
  • KNASenc: This key is used to cipher NAS signalling messages with a particular encryption algorithm as selected by the network. This key is derived by the mobile device and MME from ‘K’ as well as an identifier for the encryption algorithm using the specific ‘Key Derivation Function’ (KDF).
  • KNASint: This key is used for the protection of NAS signalling messages with a particular integrity algorithm as selected by the network. This key is derived by the mobile device and MME from ‘K’ as well as an identifier for the integrity algorithm using the specific ‘Key Derivation Function’ (KDF).  
  • KRRCenc: This key is used to cipher RRC messages exchanged between a mobile device (UE) and eNB with a particular integrity algorithm. KRRCenc is derived by the mobile device and eNB from KeNB, as well as an identifier for the integrity algorithm using the specific ‘Key Derivation Function’ (KDF).
  • KRRCint: This key is used to protect of RRC messages exchanged between a mobile device (UE) and eNB with a particular integrity algorithm. KRRCint is derived by the mobile device and eNB from KeNB, as well as an identifier for the integrity algorithm using the specific ‘Key Derivation Function’ (KDF).  
  • KUPenc: This key is used to cipher the user data PDUs using a particular encryption algorithm selected by the network operator. This key is derived by UE and eNB from KeNB. 
  • NH: NH (Next Hop) is a key derived by the UE ME and MME to provide forward security, used during handover scenarios. NH is a 256 bit key.
  • KeNB*: This key is derived by the UE and eNB when performing a horizontal or vertical key derivation. This key is used by during a handover procedure when a UE in CONNECTED state moves from one eNB to another. Horizontal and vertical key generation is described later in this article.

There is also another key KUPint, which is used to protect user data PDUs between two particular node types: The ‘Relay Node’ (RN) and DeNB. We will not take any further look at this particular key type in this article. Figure 1 depicts the ciphering and integrity key hierarchy in LTE. Further parameters used in EPS-AKA:

  • AUTN (Authentication Token): AUTN is a 128 bit string, which is calculated by the HSS/AuC and is used during the EPS-AKA procedure. AUTN is sent by MME to UE in the AKA messaging.
  • RAND: A 128 bit random number generated by the HSS/AuC and subsequently sent to the UE as a challenge by the MME during EPS-AKA.



3GPP LTE Key Hierarchy
3GPP LTE Key Hierarchy

Figure 1: Encryption and Integrity Key derivation hierarchy in LTE (3GPP™ TS 33.401)


Here is a simplified description and steps taken at HSS/AuC for Key generation:

  1. MME sends an ‘Authentication Data Request’ message to the HSS/AuC with an IMSI and SN ID, the HSS/AuC validates the IMSI and SN ID.
  2. HSS/AuC generates a 128 bit random number RAND and increases the 48 bit sequence number SQN for this ‘Authentication Vector’.
  3. HSS/AuC calculates the following keys and parameters using the algorithms/functions as described below: (3GPP TS 33.102)

Message Authentication Code: MAC = f1 (K, SQN║RAND║AMF) – Length: 64 bits

Expected Response:  XRES = f2 (K, RAND) – Length: Variable, 4-16 Octets

Cipher Key:    CK = f3 (K, RAND) – Length: 128 bits

Integrity Key:   IK = f4 (K, RAND) – Length: 128 bits

Anonymity Key:  AK = f5 (K, RAND) – Length: 48 bits

KASME = KDF (SQN⊕AK, SN ID, CK, IK) – Length: 265 bits

AUTN = SQN ⊕ (AK║AMF║MAC) – Length: 128 bits


Where f1, f2 are cryptographic algorithms and f3, f4 and f5 are key derivation functions algorithms; all of which stored in AuC (as well as on the USIM). AMF is a 16 bit number stored in the HSS/AuC. In case of EPS-AKA procedure, the ‘Separation bit’ (bit-0, HSB) is set to ‘1’ by the network. If this bit is set to ‘0’, the UE shall reject the AKA request from MME and shall send ‘EMM:Authentication Failure’ message back. Further usage of the AMF field is beyond the scope of this article and is described in 3GPP TS 33.102. The symbol ’’ here denotes a straightforward concatenation of the bit-strings.

LTE Authentication Vector Generation
LTE Authentication Vector Generation

Figure 2: EPS Authentication Vector generation (3GPP TS 33.102)


The ‘EPS Authentication and Key Agreement’ procedure establishes the legitimacy of the subscription of mobile device (implemented in the USIM) as well as that of the eNB. The EPS AKA procedure also triggers creation of the keys required for user data (U-Plane), RRC and NAS ciphering as well as RRC and NAS integrity protection. Figure 3 below provides a simplified messaging involved in EPS-AKA procedure.

The LTE standard (TS 33.401) stipulates the use of a Rel-99 (3G) or later USIM application on a SIM card (UICC) in a LTE network. Access to a LTE network using a 2G SIM card is not allowed. The USIM application on the SIM card contains the cryptographic algorithms and the Key derivation functions required to generate the Keys for both ciphering and integrity protection calculations.

The EPS-AKA procedure involves the MME fetching one or more ‘Authentication Vector’ (AV) from the HSS/AuC by sending the IMSI the Serving Network ID (SN ID: containing the MCC-‘Mobile Country Code’ and the MNC-‘Mobile Network Code’ of the network) and the Network type (EUTRAN in case of LTE) to the HSS. The HSS verifies the IMSI and SN ID and subsequently sends back one or more AV. An ‘Authentication Vector’ includes an AUTN (Authentication Token, 128 bit), a RAND (Random Number, 128 bit) and XRES (Expected Response, 4-16 Octets) and the KASME. Each AV in the list of AVs sent by the HSS to the MME is identified by a sequence number SQN.

MME then selects the an AV from the list and sends an ‘EMM:Authentication Request’ message to the UE with the following parameters: AUTN, RAND and the NAS KSI (Identifying the Key Set and the type of Security context). The UE then checks the AUTN for validity (by checking the ‘Separation bit’ in AMF as well as computing the MAC field exactly as was done by the HSS/AuC). If the MAC value computed by the UE (called XMAC) doesn’t match the received MAC in the AUTN field, the UE shall send back an ‘EMM:Authentication Failure (Cause: MAC Failure)’ message back to the MME and shall consider the network to be unauthenticated. If the Separation is indeed set to ‘1’ (Network type: EUTRAN) and the XMAC is equal to MAC, then the UE sends back an ‘EMM:Authentication Response’ message to the MME with the computed ‘RES’ value (which is computed by the UE exactly the same ways as the XRES value is computed by HSS/AuC). The UE now considers EPS-AKA to be successful.

The MME checks the received RES against the XRES it received from HSS/AuC and if they match the EPS-AKA is considered successful by the MME and both the UE and the MME has now successfully authenticated each other and now have an (indirectly) agreed upon KASME for ciphering and integrity key generation.


Figure 3: EPS Authentication and Key Agreement (EPS-AKA) procedure (3GPP™ TS 33.401)




User data and signalling data confidentiality involves encrypting the data between the sender and receiver. In LTE, shared/symmetric key encryption method is used with 128 bit keys to cipher user and signalling messages with a view to have 256 bit key usage in future versions of the standard.

LTE provides encryption mechanism for both signalling and user data. Signalling data is encrypted in two layers: the Access Stratum (AS) provides its own data confidentiality by using the security mechanism in the RRC (Radio Resource Control) protocol layer.

The RRC protocol layer in both the UE as well as in the eNB node in the EUTRAN maintain their own copy of the RRC encryption key (called KRRCenc) to cipher the contents of signalling message exchanged between an UE and the eNB. This RRC encryption key KRRCenc is a 128 bit key and as of Release-10 version of LTE specification, there are three possible ciphering algorithms available: EEA0 (NULL or no ciphering), 128-EEA1 (SNOW 3G based) and 128-EEA2 (AES based). The same three algorithms are also used to cipher ‘User’ data packets but using a different encryption key, known as KUPenc, which is maintained both at the UE as well at the eNB.

The NAS layer has its own security mechanism to cipher NAS messages exchanged between an UE and the MME in the EPC. The NAS protocol software component in the mobile device as well as in the MME maintain NAS specific encryption key KNASenc to cipher the NAS signalling messages exchanged between the device and the MME. The same three encryption algorithms are as above (EEA0, 128-EEA1, 128-EEA-2) are also used to cipher NAS signalling messages.

LTE Ciphering
LTE Ciphering

Figure 4: Ciphering / De-ciphering in LTE (3GPP™ TS 33.401)



Integrity protection of signalling messages provide protection against ‘Man-in-the-middle’, ‘Bidding-down’ or ‘Replay’ attacks. Integrity protection of signalling messages are also provided in two layers: For messages exchanged between UE and eNB (RRC messages), the PDCP layer provides Integrity Protection by maintaining. An RRC Integrity Key called KRRCint is maintained at the UE as well as the eNB. Protection from ‘Replay’ attack is achieved by ensuring that either UE or eNB accepts a particular PDCP COUNT value only once using the same AS security context. In other words, the PDCP COUNT parameter is incremented at each RRC message transmission and the integrity header (MAC-I) is calculated using the incremented PDCP count.

NAS layer uses a similar Integrity protection mechanism for NAS signalling messages where a NAS MAC (Message Authentication Code)


LTE Authentication

Figure 5: Integrity header generation in LTE (3GPP™ TS 33.401)



An UE and its serving network need to agree upon algorithms to be used for: (3GPP TS 33.401)

  • RRC ciphering and RRC integrity protection for signalling messages between UE and eNB
  • Ciphering of U-Plane PDUs transferred between UE and eNB
  • NAS ciphering and NAS integrity protection for NAS PÜDUs exchanged between UE and MME

The serving network selects the algorithms to use dependent on the security capabilities supported by the UE and the security capabilities configured at the serving network. The MME activates the algorithm selection for NAS ciphering and integrity protection by sending NAS ‘EMM:Security Mode Command’ (NAS SMC) message to the UE. This message contains algorithms to be used for ‘EPS Ciphering’ and ‘EPS Integrity’ along with the eKSI (Key Set Identifier) which points to the KASME to be used. MME also includes a list of UE security capabilities in this message so that the UE can double check it with what it had sent to the MME. This reduces the possibility of any ‘bidding-down’ attack and any manipulation of UE security capabilities in a message by a third party can be detected by the UE. ). This NAS SMC message is integrity protected but not ciphered with KNAS-int integrity key based on the KASME indicated by the eKSI in the message.

If the security mode procedure is successful, the UE then starts NAS integrity protection and encryption/decryption of NAS messages and sends a ciphered and integrity protected NAS ‘EMM:Security Mode Complete’ message back to the MME.

When the MME receives the NAS ‘EMM:Security Mode Complete’ message from the UE; it decrypts the message and checks the integrity protection (the MAC header) attached to the message using the same keys and algorithms it had sent to the UE. Ciphering of NAS messages to the UE starts after receiving the NAS ‘EMM:Security Mode Complete’ message whereas MME starts decrypting NAS messages from the UE immediately after sending the NAS security mode command message.

If the UE fails to verify any NAS ‘EMM:Security Mode Command’ message from a MME, the UE then sends an ‘EMM:Security Mode Reject’ message. UE sends this reject message and all subsequent NAS messages with integrity protection and ciphering using the previously active available NAS security context, if available.

A separate AS level security mode command procedures is used by the RRC protocol layer to activate and configure AS security for both signalling and user plane messages. ‘RRC Security Mode Command’ message contains only the algorithm Ids to be used.





Figure 4: Key derivation scheme in LTE EUTRAN and EPC (3GPP™ TS 33.401)



KASME is identified using the ‘Key set identifier’ parameter eKSI. And subsequently, the keys derived from KASME such as KeNB, KNAS-enc, KNASint, KRRCint, KRRCenc, KUPenc, KUPint are also identified by eKSI.

During an Intra-eNB handover (both the source cell and the target cell belong to the same eNB) a new key KeNB* is derived by the eNB using the Physical Cell Id (PCI) of the target cell, the downlink frequency ID (EARFCN-DL) of the target cell, and either NH or the current KeNB depending on the availability of a unused (NH, NCC) pair at the eNB. If NH (Next Hop) parameter is used to derive the KeNB*, then this is known as ‘Vertical Key Derivation’ and if the current KeNB is used to derive the KeNB*, then that is known as ‘Horizontal key derivation’. The eNB then uses the KeNB* as new KeNB after handover and sends the NCC used for KeNB* derivation to UE in RRC ‘Handover Command’. The UE uses this NCC parameter to derive the KeNB* for use after the handover is complete. Figure 4 below describes the Horizontal and Vertical key generation processes.

EPS Horizontal & Vertical Key Derivation
EPS Horizontal & Vertical Key Derivation

Figure 4: Handover key chaining: Horizontal and Vertical key generation in LTE (3GPP™ TS 33.401)

In case of an X2 handover (where the source eNB and the target eNB are connected via an X2 interface), the source eNB first computes KeNB* using PCI of the target cell, its DL-EARFCN and using either the currently active KeNB in case of horizontal key derivation or from the NH in case of vertical key derivation. The source eNB forwards the KeNB* and NCC values to the target eNB. The target eNB uses the KeNB* as new KeNB and associates the received NCC value with this KeNB. On completion of the handover with the UE, the MME increases its stored NCC value by one and computes a new NH parameter value by using the KeNB and its local NH value and sends the new NH, NCC pair to the target eNB for further handovers.

During a S1-handover (when the source and target cells are not connected via an X2-interface), the source MME increases its local NCC value by one and then computes a new 256-bit NH value and sends this new NCC, NH pair along with the currently used eKSI and KASME to the MME to which the target eNB belongs. The target MME uses this new (NH, NCC) pair and sends it to the target eNB and the target eNB then calculates a new KeNB using this new (NH, NCC) pair as well as the target cell’s PCI and its DL-EARFCN values. The target eNB stores the new NCC value and deletes any unused local (NH, NCC) pair and uses the received NCC value in the RRC ‘Handover Command’ message to the UE via the source eNB. The UE uses this NCC value to calculate a new KeNB.

In all handover scenarios, a UE uses the current KeNB to calculate the KeNB* if the received NCC value in the RRC ‘handover Command’ message is the same as the one associated with the currently active KeNB. Otherwise, it computes a new NH value first by using the appropriate key derivation function (KDF) using the new NCC value and then computes a new KeNB* using the newly computes NH value and the PCI and DL-EARFCN values of the target cell.



There are several security and availability threats to any mobile communications networks and since LTE/SAE is an all-IP based mobile technology, threat vectors which have been used in the Internet might also be used to attack LTE nodes and mobile devices. Here is a short description of some of the security threats facing LTE:


Jamming of any radio communication can be achieved by transmitting a strong enough radio signal in the same frequency band. Since LTE FDD systems use two different centre frequencies (one for Uplink direction and the other for downlink direction) and bandwidth of a cell can be vary between 1.4 MHz to a rather large 20 MHz, a rudimentary jamming method might require powerful (and expensive) jamming transmitters. On the other hand, design of the LTE common channels is such that (such as the PSS, SSS for cell search and the System Information Broadcasts) which are centrally located in the frequency band (taking up the six central ‘Resouce Blocks’ or RBs of 180 KHz each, a total of 1.08 MHz) irrespective of the bandwidth of the cell. This is done in order to help the mobile devices search for a cell without a priori knowledge of the bandwidth used in that cell. But this also means that a jamming transmitter only need to transmit a 1.08 MHz jamming signal centred on the downlink EARFCN of any LTE cell and the particular LTE cell targeted this way would become unusable by any mobile devices. This also makes the jamming LTE cells easier and less easily detectable.

Another way LTE mobile user could be targeted is to jam uplink and downlink control channels used by mobile devices and eNBs to facilitate network access and signalling. Jover, R. P(2013) points to these techniques (referred to as ‘Smart Jamming’), which require lower power jammers and much more difficult to detect since the both the jamming bandwidth and power required are much lower than in the basic jamming method. Jamming of this nature is also more effective in the uplink direction since the mobile devices are typically low power devices.

  1. DoS / DDoS

DoS (Denial of Service) and DDoS (‘Distributed Denial of Service’) are attacks are probably the most well-known attack vectors in the Internet world. But they can also be used to target mobile networks including LTE networks. A DDoS attack targeting a LTE network can take place when an ‘App’ which is purposely designed / or simply poorly designed creates a large number of messaging (such as attempting to connect to a server very frequently). If such an App of this nature is used by a large enough number of mobile devices; this may cause Control-Plane overload in the EPC. C-Plane overloads causing network crashes have already happened in Japan in January 2012 when NTT DoCoMo network became unavailable (on one occasion for about five hours) to about 2.5 Million users due to a Control-Plane traffic overload created by smartphones. The same network had faced downtime during a few months prior also due overload conditions. Jover, R. P (2013) also refers to similar network outage in T-Mobile USA LTE network due to signaling traffic overload caused by Instant Messaging applications. Although these instances were not caused my malicious software but it’s not hard to imagine that a purposely designed and distributed ‘Malware App’ in a ‘Mobile botnet’ scenario could also be effective DDoS tool against a LTE network.

Additionally, as already mentioned that LTE is an all-IP based network, traditional DDoS attacks using external botnet can also be used to target the LTE EPC nodes.



3GPP               3rd Generation Partnership Project

APN                 Access Point Name

AS                     Access Stratum

AuC                   Authentication Centre

DNS                 Domain Naming Service

ECM                 Evolved Connection Management

EMM                Evolved Mobility Management

EPC                  Evolved Packet Core

ESM                 Evolved Session Management

EUTRAN            Evolved UTRAN

GUTI                Globally Unique Temporary Identifier

HSS                 Home Subscriber Server

IMSI               International Mobile Subscriber Identity

LTE                 Long Term Evolution

RNC                Radio Network Controller

MAC                Medium Access Control

MME                Mobility Management Entity

PDCP               Packet Data Convergence Protocol

PDN                 Packet Data Network

PDU                 Protocol Data Unit

PGW                PDN Gateway

PSS                 Primary Synchronisation Signal

PHY                 PHYsical layer

RAN                 Radio Access Network

RAND               RANDom number

RLC                   Radio Link Control

RRC                 Radio Resource Control

NAS                 Non-Access Stratum

NCC                 Next hop Chaining Counter

NH                  Next Hop

S1-AP             S1-Application Part

S1-U               S1 protocol on the U-plane

SCTP               Stream Control Transmission Protocol

SGW               Serving Gateway

SQN               Sequence Number

SN-ID             Serving Network ID

SSS                Secondary Synchronisation Signal

UE                   User Equipment

UMTS              Universal Mobile Telephony System

USIM               Universal Subscriber Identity Module (the ‘SIM’)

UTRAN            UMTS Terrestrial Radio Access Network

X2-AP              X2 Application Part

XRES              X-RESponse



3GPP (2013), ‘3GPP System Architecture Evolution (SAE); Security architecture (Release-10)’
3GPP TS 33.401 V10.5.0 (2013-06) [Online]
Available: [25/01/2014]

3GPP (2010), ‘3G Security: Security architecture (Release-10)’
3GPP TS 33.102 V10.0.0 (2010-012) [Online]
Available: [01/02/2014]

Jover, R P (2013), ‘Security Attacks Against the Availability of LTE Mobility Networks: Overview and Research Directions’, AT&T Security Research Center, New York.
[Online] Available:‎ [05/02/2014]

Asahi (2012), ‘Red-faced NTT DoCoMo takes action to keep lines up’ [Online]

Basil, R (2013), ‘Effects of Signaling Attacks on LTE Networks’ [Online]
Available: [Accessed: 05/02/2014]


This website uses cookies so that we can provide you with the best user experience and to deliver advertising messages and offers on the website that are relevant to you. To read more about the cookies we use and to change your settings see our policy, please click on the link next:

Our Cookie Policy.

This website uses cookies so that we can provide you with the best user experience and to deliver advertising messages and offers on the website that are relevant to you. By continuing to use the site, you agree to the use of cookies.

What are 'COOKIES' ?

Web Browser Cookies

A cookie is a small text file that is sent by a website to your computer or mobile/tablet where it is stored by your web browser. A cookie contains limited non-personal data, usually a unique identifier and the name of the site. This enables a website to recognise you as you move around the site and/or each time you revisit. Cookies are used for a wide variety of purposes such as to keep you logged in or to remember what's in your basket if you're shopping online, to remember your preferences and settings, to analyse how the site is used by you, and to serve advertising to you.

Cookies which are served by the website you are visiting are called "first party cookie". If they are served by another web-site providing services to that website, such as an analytics company or advertising network then they are called "Third party cookies". They will either be stored for the duration of your visit called a "session cookie" or they might remain for a fixed period, which could be months or even years, to remember you across multiple browsing sessions (known as a "persistent cookie").

Google Analytics

We use 'Google Analytics' to collect statistical information about how our websites are used. They use information such as your IP address, browser type and unique identifiers stored in (first party) cookies on your device to record how you interact with our website. We also use 'Google Demographics' data to help us tknow how many users we have, which parts of our sites are most popular, what browsers are used (so we can maximise compatibility), the country or region where our users are located, and the demographics and interests of our users. This enables us to better understand who is using our site and to ensure we are reaching our target demographic, and to improve and tailor our services accordingly.


For more information on cookies and privacy, please visit the UK Information Commissioner's Offce web-site at:

ICO Cookie and Privacy Information