SECURITY IN 4G LTE:
LTE (LONG TERM EVOLUTION), SECURING DATA AND SIGNALLING
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:
- Data Confidentiality – Provides protection against unauthorized eavesdropping.
- 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.
KEYS USED IN LTE
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.
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:
- 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.
- HSS/AuC generates a 128 bit random number RAND and increases the 48 bit sequence number SQN for this ‘Authentication Vector’.
- 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
AV = RAND ║ XRES ║KASME ║AUTN
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.
Figure 2: EPS Authentication Vector generation (3GPP TS 33.102)
EPS AUTHENTICATION & KEY AGREEMENT (EPS-AKA)
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)
DATA CONFIDENTAILITY IN LTE
USER AND SIGNALLING DATA ENCRYPTION
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.
Figure 4: Ciphering / De-ciphering in LTE (3GPP™ TS 33.401)
DATA INTEGRITY IN LTE
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)
Figure 5: Integrity header generation in LTE (3GPP™ TS 33.401)
SECURITY MODE & ALGORITHM NEGOTIATION
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.
KEY DERIVATION IN LTE
Figure 4: Key derivation scheme in LTE EUTRAN and EPC (3GPP™ TS 33.401)
KEY DERIVATION DURING HANDOVERS
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.
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.
SECURITY THREATS IN LTE
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.
- 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
3GPP (2013), ‘3GPP System Architecture Evolution (SAE); Security architecture (Release-10)’
3GPP TS 33.401 V10.5.0 (2013-06) [Online]
Available: http://www.3gpp.org/ftp/specs/2013-06/Rel-10/33_series/33401-a50.zip [25/01/2014]
3GPP (2010), ‘3G Security: Security architecture (Release-10)’
3GPP TS 33.102 V10.0.0 (2010-012) [Online]
Available: http://www.3gpp.org/ftp/specs/2013-06/Rel-10/33_series/33102-a00.zip [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: http://www.research.att.com/techdocs/TD_101153.pdf [05/02/2014]
Asahi (2012), ‘Red-faced NTT DoCoMo takes action to keep lines up’ [Online]
Basil, R et.al. (2013), ‘Effects of Signaling Attacks on LTE Networks’ [Online]
Available: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6550445 [Accessed: 05/02/2014]