LTE-Advanced, recently standardized as 4G, brings about a paradigm shift in the way real-time data-driven wireless applications are conducted since it enables speeds up to 1 Gbit/s for data transfers. Its frequency-division multiple access (FDMA) radio access, along with a packet-switched radio interface optimized for packet data, enables such higher data rates and lower latency.

These new real-time data-driven wireless applications bring about a greater need to ensure certain security features that cover various vulnerabilities including network access security, network domain security, user domain security, application domain security, and visibility of configurability of security features. Fortunately, designers can take advantage of the security features, mechanisms used to implement these features, and the security procedures performed within the LTE-Advanced mobile communication standard, as specified by the relevant 3GPP specifications.

Overview of LTE-Advanced Security Features

Security features need to cover the following areas of vulnerability to meet related threats and accomplish certain objectives:

  • Network access security features provide users with secure access to mobile services and protect against attacks on the radio access link.
  • Network domain security features enable nodes in the provider domain to securely exchange signaling data and protect against attacks on the wireline network.
  • User domain security features facilitate access to mobile stations.
  • Application domain security features enable applications in both the user and provider domains to securely exchange messages.
  • Visibility and configurability enable the user to determine whether or not a security feature is (or should be) in operation.

Security Procedures for User Identity Confidentiality on Network Access Link

Three features protect data from eavesdropping on the radio access link. First, user identity confidentiality protects the permanent user identity (IMSI). Second, user location confidentiality masks the presence or arrival of a user in a certain area. Finally, user untraceability prevents an intruder from detecting whether different services are delivered to a user.

To avoid user traceability, which may lead to the compromise of user identity confidentiality, the user is identified by a temporary identity (GUTI) provided by the serving network. This mechanism can be used to identify a user on the radio path in location update requests, service requests, detach requests, connection re-establishment requests, and other requests. Any signaling or user data that can reveal the user’s identity is ciphered on the radio access link.

Security Procedures for Entity Authentication on Network Access Link

Entity authentication comprises two steps and should occur at each connection setup between the user and the network. First, user authentication ensures that the serving network corroborates the user identity of the user. Next, network authentication ensures that the user’s connection is to a serving network with an up-to-date authorization from the user’s home environment (HE) to provide services.

The mechanism of entity authentication is based on the authentication vector delivered by the user’s HE to the serving network. This authentication-and-key mechanism establishes a secret cipher key and integrity key between the user and the serving network. The serving network should invoke this mechanism after a first registration of a user in a serving network and after a service request, location update request, attach request, detach request, or connection reestablishment request when the maximum number of local authentications using the derived integrity key have been conducted.

The local authentication mechanism uses the integrity key established between the user and serving network during the previous execution of the authentication and key establishment procedure. This mechanism should be invoked by the serving network after a service request, location update request, attach request, detach request, or connection re-establishment request, provided that the maximum number of local authentications using the same derived integrity key has not been reached yet.

Security Procedures for Data Confidentiality on Network Access Link

The confidentiality of user data and signaling data ensures that neither type can be overheard on the radio access interface. The cipher algorithm agreement ensures that the mobile station (MS) and the serving network (SN) can securely negotiate the algorithm that they should use subsequently.

The cipher algorithm agreement is achieved via a mechanism for security mode negotiation between the user and the network. The cipher key agreement, which is established in the course of the execution of the mechanism for authentication and key agreement, ensures that the MS and the SN agree on a cipher key that they may use subsequently.

Security Procedures for Data Integrity on Network Access Link

Data integrity and origin authentication of signaling data allow the receiving entity to verify two key facts; first, that the signaling data was not modified in an unauthorized way after it was transmitted by the sending entity (SN or MS); second, that the origin of the signaling data received is indeed the one claimed.

The integrity algorithm agreement ensures that the MS and the SN securely negotiate the integrity algorithm that they will use subsequently. The integrity algorithm agreement is realized via a mechanism for security mode negotiation between the user and the network. The integrity key agreement, which is also established in the course of the execution of the mechanism for authentication and key agreement, ensures that the MS and the SN agree on an integrity key that will be used subsequently.

Security Procedures for USIM Authentications in the User Domain

User-to-USIM authentication ensures that access to the universal subscriber identity module (USIM) is restricted until the USIM has authenticated the user. The user and the USIM must share a secret PIN that is stored securely in the USIM. Users get access to the USIM only if they prove knowledge of the secret PIN. This prevents unauthorized access to the user’s account and the resulting fraudulent charges.

USIM-terminal link authentication ensures that access to terminal or other user equipment (UE) is restricted to an authorized USIM. The USIM and the terminal must share a secret that is stored securely in the USIM and the terminal. If a USIM fails to prove its knowledge of the secret, it will be denied access to the terminal.

Security Procedures for Secure Messaging between the USIM Applications and the Network

The USIM application toolkit allows operators or third-party providers to create applications that reside on the USIM. Both the network operator and application provider can specify a required level of security for any data transferred over the network to applications on the USIM. Security measures that ensure those requirements are met must be in place.

Security Procedures for Visibility of Security Events

This feature ensures that the user is informed of security-related events. This would include indication of access network encryption. The user would receive a visible notice of whether the confidentiality of user data is protected on the radio access link, particularly when non-ciphered calls are set up. It would also indicate a change in the level of security provided by the visited network, particularly when a user is handed over to or roams into a network with less security.

Security Procedures for Configurability of Security Events

This feature allows the user to specify security requirements to be met prior to the use or the provision of a given service. For example, the user can enable (or disable) user-USIM authentication for particular events, services, or uses. The user can also indicate whether incoming non-ciphered calls should be accepted or rejected.

User-to-Network Security with User Identity and Device Confidentiality

To ensure the subscriber's privacy, the MSIN, IMEI, and IMEISV should be confidentiality protected. Therefore, the UE should provide its equipment identifier (IMEI or IMEISV) to the network only in response to an integrity-protected request. The IMEI and IMEISV should be securely stored in the terminal. The UE should not send IMEI or IMEISV to the network on a network request before the NAS security has been activated. The IMEI or IMEISV should be sent in the NAS protocol.

User-to-Network Security with User Data and Signaling Data Confidentiality

Ciphering may be provided to RRC-signaling (radio resource control) to prevent UE tracking based on cell level measurement reports, handover message mapping, or cell level identity chaining. The network attached storage (NAS) signaling may be confidentiality protected. User plane confidentiality protection should be enacted at the Packet Data Convergence Protocol (PDCP) layer.

User-to-Network Security with User Data and Signaling Data Integrity

Synchronization of the input parameters for integrity protection should be ensured for the protocols involved in the integrity protection. Integrity protection, as well as replay protection, should be provided to NAS and RRC-signaling. All NAS and RRC signaling messages (with few exceptions) should be integrity-protected.

Security Procedures for eNodeB Setup, Configuration, and Secure Environment

An evolved Node B (eNB) is the radio access part of the UMTS LTE system. A single eNB may contain several radio transmitters, receivers, control sections, and power supplies. The purpose of the eNB is to ensure that software/data change attempts are authorized. The eNB should use authorized data and software. Sensitive parts of the boot-up process should be executed within the secure environment.

Authentication and authorization before setting up and configuring the eNBs prevents attackers from modifying the eNB settings and software configurations via local or remote access. Security associations are required between the EPS core and the eNB, as well as between adjacent eNBs. These security associations should be mutually authenticated and used for communication between the entities.

Once up and running, the eNB should have a secure environment so it can support various sensitive operations:

  • The storage of sensitive data, e.g., long-term cryptographic secrets and vital configuration data;
  • The execution of sensitive functions, e.g., encryption and decryption of user data and the basic steps within protocols that use long-term secrets (such as authentication protocols); and
  • The execution of sensitive parts of the boot process.

Security Procedures for Key and Data Handling within eNB

The EPS core network provides subscriber-specific session keying materials for the eNBs, which also hold long-term keys used for authentication and security association setup purposes. Protecting all these keys is important. Keys stored inside eNBs should never leave a secure environment within the eNB except in accordance with this or other 3GPP specifications.

The eNB has to cipher and decipher both user plane and control plane packets. Data ciphering and deciphering should take place inside the secure environment where the related keys are stored. The transport of user and control plane data should be integrity-, confidentiality-, and replay-protected from unauthorized parties.

Security Procedures Between UE and EPC Network Elements for Authentication and Key Agreement

The EPS authentication and key agreement (AKA) procedure should be used over E-UTRAN. EPS AKA produces keying material to form a basis for user plane, RRC, and NAS ciphering keys, as well as RRC and NAS integrity protection keys.

The mobility management entity (MME) sends the random challenge (RAND) and an authentication token (AUTN) to the USIM (via the mobile equipment [ME]) for network authentication from the selected authentication vector. Upon receiving this message, the USIM should verify the freshness of the authentication vector by checking whether AUTN can be accepted.

If so, the USIM computes a response RES. The UE should respond with a user authentication response message that includes RES in case of successful AUTN verification. If the verification fails, the USIM indicates the reason for failure to the ME. The UE should send an authentication failure message with a CAUSE value indicating the reason for failure.

Security Procedures Between UE and EPC Network Elements for Distribution of Authentication Data from HSS to Serving Network

This procedure provides the MME with one or more EPS authentication vectors from the user’s HE (HSS) to perform user authentication. The MME invokes the procedures by requesting authentication vectors from the HE. The authentication data request should include the IMSI, the SN identity (i.e., MCC + MNC), and the network type (i.e., E-UTRAN).

The HE may have pre-computed the required number of EPS authentication vectors, in which case it would retrieve them from the HSS database. Alternatively, the HE may compute them on demand. Upon the receipt of the authentication data request from the MME, the HE sends an authentication response that contains the requested information. If multiple EPS authentication vectors had been requested, they would be remitted in sequential order. The MME should use the EPS authentication vectors in the correct order.

Security Procedures Between UE and EPC Network Elements for User Identification by a Permanent Identity

This feature allows the identification of a user on the radio path by means of the permanent subscriber identity (IMSI). The serving network should involve the user identification mechanism whenever the user cannot be identified by means of a temporary identity (GUTI). In particular, it should be used when the serving network cannot retrieve the IMSI based on the GUTI by which the user identifies itself on the radio path.

Security Procedures for IMS Emergency Session Handling

IMS emergency sessions can be initiated by normally attached UEs or by UEs attached for EPS emergency bearer services. IMS emergency services can be authenticated or unauthenticated, as defined below. Whether or not unauthenticated IMS emergency sessions are allowed depends on the serving network policy. Any behavior not explicitly specified as being special to IMS emergency sessions is handled in accordance to normal procedures.

IMS emergency sessions may be established in limited service state without the network having to authenticate the UE or apply ciphering or integrity protection for either AS or NAS. Such a “security procedure not applied” option may be used if authentication is impossible due to the absence of the USIM or due to a network failure that prevents authentication vectors from being obtained.


As data traffic increases and becomes more diverse, security must also become more robust. Areas of vulnerability in the LTE-Advanced mobile communications standard include network access security, network domain security, user domain security, application domain security, and the visibility and configurability of security features.

While not exhaustive in scope, this article outlined the salient security aspects of the Universal Mobile Telecommunication System (UMTS), the Evolved UTRAN (E-UTRAN), the Evolved Packet System (EPS), and the Evolved Packet Core (EPC) as provided by the 3GPP. More details can be found in the relevant 3GPP specifications.