9.1 Security in 3GPP Mobile Networks

The objectives for security, as documented in 2001 by 3GPP [1] are that:

• user information is protected against misuse;
• network resources and services provided by serving networks and home environments, are adequately protected against misuse;
• security features are standardized, have worldwide availability (considering e.g. export restrictions) and are interoperable so that roaming can be supported between different serving networks;
• level of protection for both user, and for providers of service, is better than that provided by contemporary fixed or mobile networks;
• security features and mechanisms are extendable as required, to address potential new threats and services.

The experiences from 2G security were the basis for creating the objectives for 3G, especially the identified shortcomings, real and perceived, of 2G security were addressed. Otherwise the security elements and components from 2G that were perceived to be robust were kept as a basis.

The documented 2G weaknesses include:

• Possibility for a ‘false BTS’ attack (since terminal is authenticated, but not the network). This is addressed with mutual authentication.
• Transmitting keys as clear-text. Between networks (and network domains), network domain security functionality has been included in 3G.
• Weaknesses in authentication, related to IMEI (International Mobile Equipment Identity).
• Lacking data integrity protection. Integrity of air interface signaling is protected in 3G.
• Lawful interception and fraud information gathering, was not initially considered in 2G.
• Encryption over the air interface was not extending deep enough into the network.
• Lacking flexibility for subsequent release new functionality (e.g. encryption algorithms and key lengths not sufficiently strong, and not easily extendable).

Security threats in the 3G system are according to TS33.120:

• Unauthorized access to sensitive data: e.g. by eavesdropping.
• Manipulation of sensitive data: e.g by modifying the content of communication.
• Disturbing network service: e.g. by triggering traffic flows leading to denial of service.
• Repudiation: e.g. claiming that actions of a user or a network have not taken place.
• Unauthorized access to services: e.g. by misusing access rights.

As an exception to the confidentiality of the communication between users, in some cases law enforcement may be entitled to interfere with the communication between users. This happens technically through lawful interception (LI) functions. The rules of when and to what extent law enforcement has the right for lawful interception, are subject to legislation.

Many of the threats above are related to handling user information such as authentication of the mobile user, billing and accounting of the user, etc. These are all transparent to the radio network and to the mobile backhaul. Thus they are addressed by the mobile system standards. Clearly there are threats originating from the mobile backhaul; user data can technically be accessed and potentially manipulated, and also network service disturbed. These threats can be addressed by network security functionality, using cryptography (IPsec) and other features.

3GPP security architecture is based on features grouped into five areas, shown in Figure 9.1.

Network access security protects the wireless access to 3G services. Network domain security makes the mobile nodes' exchange of sensitive information secure, over the wireline network. User domain security concerns of access to the mobile stations. Application domain security secures communication between user and network domains. Finally, visibility and configurability of security inform users of whether security features are in use, and, whether the service should depend on the availability of a security feature.

Features for the network access security exist in areas of user identity confidentiality, entity authentication, confidentiality on the access link, data integrity on the access link and mobile equipment authentication. User domain security features are in providing user to USIM authentication and ensuring an access to the terminal only via an authorized USIM. Application domain security includes e.g. securing applications that reside on the USIM.

Network domain security was addressed starting from 3GPP Rel-4, with the focus on core network signaling and securing the Mobile Application Part (MAP) protocol of the SS7 signalling system. IP layer security was included with 3GPP Rel-5. The resulting specification in Rel-5 is TS 33.210, defining the use of IPsec protocols. Security within the mobile backhaul falls into the network domain security area. The services needed are confidentiality, integrity and authentication.

9.1.1 Network Domain Security

IP networking is increasingly used in all radio technologies, 2G, 3G, HSPA, HSPA+ and LTE. This means that open and well-known protocols (TCP/IP protocol suite) are used to backhaul the mobile network traffic. Having an access to the mobile backhaul network, means thus that there is IP connectivity to the mobile network elements, unless this access is restricted.

This opens the mobile network up to threats and risks that did not exist with TDM or ATM networks. IP is also used for all of the traffic types: User plane traffic, signaling/control plane, management plane and synchronization plane traffic. All of the traffic types have their own vulnerabilities.

3GPP defines in TS33.210 a security domain. This means a network that is managed by a single administration. So, typically, a network that is operated by a single operator, is also a security domain. Within a security domain typically the same level of security is maintained.

TS33.210 is written with the mindset of protecting the control plane. Radio access network internal interfaces (such as Iub), are not covered. Principles can be reused for interfaces that are not explicitly mentioned in the specification. In LTE, S1 and X2 interfaces are covered in LTE security architecture explicitly (TS33.401), so a standards-based view is clear.

With the network domain security, the interface to other security domains is designated as interface Za. A security gateway (SEG) is an element that is used at the interface to another security domain. A peer entity over the Za interface is SEG of the other security domain. An interface within a security domain is interface Zb. This is between a network element (NE) and another NE, or between NE and SEG.

Additionally, a transit security domain is defined as a domain which is transmitting NDS IP traffic between other security domains. The interface used between a transit security domain and other security domains, is Za.

Figure 9.2 matches directly e.g. a roaming case where two different operators interconnect and need to protect the common control plane (e.g. GTP-C) with a commonly agreed set of features.

A mobile network element (NE) may include an integrated SEG. In this case the SEG logically interfaces Za. Multiple SEGs may be operated in parallel, for load sharing or for resiliency. ESP tunnels may be available constantly, or established dynamically when needed.

For the interface between security domains (Za), authentication and integrity protection is mandatory, and encryption is recommended, all these functions using IPsec Encapsulating and Security Payload (ESP) protocol. The ESP tunnel between SEGs is negotiated, established and maintained using IKEv2 (according to 3GPP Rel-11 specification). Previously, IKEv1 may have been implemented. Rel-11 mandates SEGs to support both versions (IKEv1 and IKEv2), to ensure interoperation over the Za.

Zb interface is optional. If implemented, it supports ESP tunnel mode, and IKEv2 (according to 3GPP Rel-11). IKEv1 may be supported, as well as ESP transport mode. Authentication and integrity protection is mandatory and encryption is optional. In particular, control plane protection needs to be considered over the Zb.

The concept presented assumes that inter-domain communication always occurs through the use of SEGs, so that there is no direct NE-NE inter-domain communication. In the actual implementation, SEG functionality may be integrated with an NE, which is also discussed in 3GPP TS33.210. Secure inter-domain NE-NE communication is supported, if the combined NE/SEG node interfaces another combined NE/SEG node in the other security domain. The features supported in this case depend on the security policy. The combined NE/SEG node can interface either a combined NE/SEG node, or a SEG-only node in the other security domain.

For protecting the traffic in the mobile backhaul, both dedicated SEGs, and combined NE/SEG nodes are potentially relevant. In cases where the access tier of the backhaul network requires cryptographic protection, mobile system interfaces like Iub and S1/X2 have to be considered. Deciding whether the backhaul lacks adequate protection, has to be assessed case by case. If cryptographic protection is needed, then SEG is deployed for the traffic leaving the security domain.

At the BTS site, IPsec protection can be deployed either as a cell-site gateway with IPsec functionality (acting as a dedicated SEG, shown as Alternative 1 in Figure 9.3), or as implementing the needed IPsec functions into the eNodeb (LTE) (shown as Alternative 2 in Figure 9.3). The BTS site interfaces the unsecure network via Za. At the other end (core site), similarly a Za interface is used.

Both alternatives protect the S1 over the originally not-adequately-secured transit network. In Alternative 1), BTS site consists of two physical nodes, eNodeB and SEG. In this case, protection of the intra-site connection between eNodeB and SEG needs to be considered in addition.

In Alternative 2), SEG is integrated with eNodeB into a combined node. In this case, the connection from the eNodeB to SEG is node-internal. In the combined node case, the S1 interface is only available in an encapsulated mode (ESP tunnel). (As a side effect, troubleshooting S1 e.g. with protocol analyzers, is not possible. If an unprotected port is offered by the combined node, protection is compromised.)

In the case of combined NE/SEG node, a further limitation is imposed, in that the combined NE/SEG node should not be used by other NEs towards other security domains. In Figure 9.3 as it is presented, in Alternative 2 this has the consequence that according to 3GPP, IPsec transport service is not allowed to be used for a possible co-located 2G or 3G BTS (or a chained BTS).

9.1.2 2G

At the mobile system level, three key security features of 2G are: subscriber authentication, encryption of the air interface, and the use of temporary identities. Subscriber authentication means that the subscriber has no access to the network unless successfully authenticated. (Note the exception of emergency calls). Temporary identities protect the identity of the user. International Mobile Subscriber Identity (IMSI) is the permanent identity of the subscriber. In addition to IMSI, temporary identities are defined.

Encryption is discussed further as it is relevant for considering the protection needs of the 2G backhaul.

The mobile voice service over GSM is designed to be no more vulnerable to eavesdropping than a fixed voice service. Air interface is considered a weakness compared to the voice service over fixed lines, and thus encryption is specified over the air interface between the mobile station and the BSS.

In the 2G system, ciphering is supported in the user plane in BTS for voice, and in LLC layer for the packet switched data (GPRS). This means that user plane traffic is ciphered over the air interface, from the mobile station to the BTS (for voice) and from the mobile station to the SGSN (for packet switched data). For the encryption function in the BTS, BSC is responsible for downloading the encryption key to the TRX. The key is downloaded using control messages between the BTS/TRX and the BSC.

The cryptographic algorithms used in 2G are variants of A5. A5/0 means no encryption. A5/1 is considered medium level encryption, A5/2 weak, and A5/3 as strong encryption. A5/3 is based on the algorithm used in 3G. For 2G/GPRS services, algorithms GEA1, GEA2 and GEA3 are used. Selection of the algorithm depends on the terminal and network capabilities. The algorithms are used for encryption only.

9.1.3 Abis, A and Gb

Abis interface itself (as a PCM-interface), is not providing any specific security feature. This is also comparable to voice on the fixed access systems. PCM-based Abis has not been viewed as a security vulnerability. The control traffic on Abis (LAPD links) is similarly in clear-mode over the TDM, unless protected separately.

Microwave radio transmission, commonly used for Abis (as well it is also used for Iub and S1), was perceived as a 2G system vulnerability, since wireless transmission is used. Point-to-point microwave radio links have a vendor-specific air-interface and they are typically not encrypted. Abis traffic is in clear-mode so it is open to eavesdropping and other security vulnerabilities.

Microwave point-to-point links, however, differ from the air interface transmission. Air interface of the BTS consists of omnidirectional, or sectorized cells. With point-to-point microwave radio, line-of-sight is required, and the signal attenuates rapidly outside of the line-of-sight. Eavesdropping is naturally still technically possible. In 3G, the RLC/MAC layers are responsible for encryption, and they are located in the 3G RNC, and thus the radio bearers over the Iub, whether using microwave radios or some other backhaul, is encrypted.

When Abis is circuit emulated over the packet mobile backhaul, it is similarly based on the IP protocol stack, and exposed to the same vulnerability as native IP based Iub of 3G (Rel-5 onwards) or LTE S1 and X2. Specific concerns related to the access transport in general (Abis, Iub, S1, X2) are the high amount of BTSs, and the physical location of BTSs. Many BTS sites are not physically as secure as controller or core network sites.

The case of carrying Abis over packet mobile backhaul is implementation specific, as circuit emulation is out of the scope of 3GPP. IPsec protocol suite can be deployed and the guidance from other 3GPP specified IP interfaces for NDS can be adopted for the emulated Abis interface.

A interface connects the BSS to the circuit switched core. The user plane interface is either PCM as initially defined, or it may be A over IP. Gb interface connects the BSS to the GPRS core network. Initially frame relay was defined, and Gb over IP was added as an option.

3GPP specifications support both A and Gb with IP transport option for both user and control traffic. Although not identical, the A and Gb interfaces are comparable to the Iu-interfaces of 3G: The A interface is functionally comparable to the Iu-cs interface, and the Gb to the Iu-ps interface.

The protection of UTRAN/GERAN IP based protocols is discussed in Annex of TS33.210, stating that traffic shall be protected properly and that the NDS/IP protection principles are to be followed. Za interface is to be implemented between security domains. The document explicitly mentions Iu-mode interfaces, however it can be assumed that the same principles apply to GERAN A and Gb interfaces, as the protection needs of A and Gb are comparable to those of Iu-cs and Iu-ps.

9.1.4 3G

For 3G, the 2G security features that were assessed as robust and needed were taken as a basis. So, for example, subscriber authentication, air interface encryption and the use of temporary identities continued to be supported, with enhancements. At the same time, the weaknesses identified in the 2G system were addressed. 3G security features are an evolution of the corresponding 2G functionality, with enhancements where needed. For further information refer to [9].

For the traffic types, user plane traffic from the UE is encrypted for both CS and PS domain by the radio network layers. Now the encryption is extended, as the RLC/MAC layers support the encryption, and these are located in the RNC. This addresses one of the documented 2G weaknesses (Encryption not extending deep enough in the network). Similarly, control plane traffic from the UE is encrypted between the user equipment and the RNC. Additionally, UE control plane traffic is also integrity protected, which is again an enhancement compared to 2G (and again a documented 2G weakness). User traffic is not integrity protected.

A separate encryption key (as in 2G) is used for the CS and PS domains for the user traffic over the air interface. These keys are derived by the core network (SGSN and MSC/VLR) using information in the user equipment (UE, USIM) and in the core network subscriber registers. The keys are delivered to the RNC by RANAP signaling. Appropriate security mode is selected based on terminal and network capabilities, and possible further information about the needs of the application.

UMTS AKA (Authentication and Key agreement) procedure is used to authenticate the user. Now also the network is authenticated, which is an improvement compared to 2G.

9.1.5 Iub

Similarly to the PCM-based Abis interface of 2G, with initial 3G RAN, the ATM based interface of Iub was not viewed as a real vulnerability from a security standpoint. With IP defined in 3GPP Rel-5 for the 3G Iub, the situation changed.

3GPP Rel-5 IP Iub can be used for all traffic from a NodeB, for user traffic on DCH and HSPA channels, and for signaling and management traffic. Also, packet based timing may be carried over IP. With Rel-5, the assumption is that of a closed IP network, in which case the network can be considered secure and trusted, and IPsec solution is not mandated by 3GPP. With this assumption, there is no need to specify IP Iub within network domain security. Whether the backhaul network deployed for the Rel-5 compliant IP is secure and can be trusted, has to be assessed case by case. In LTE, physical security for the eNodeB is the exception given in 3GPP, so as not to mandate cryptographic protection.

In addition to user and control plane traffic from the UEs, NBAP signaling traffic between nodeB and the RNC exist in the Iub interface. NBAP/SCTP/IP carries control messages necessary for the NodeB operation. There is no specific security functionality specified related to NBAP itself.

Similarly, other possible traffic types extending over the Iub to the NodeB but not over the air interface, are by default not protected by any specific security features. Network management and packet timing are examples of this kind of traffic. Network management traffic is critical and is typically protected even with ATM based interface, as over the ATM IP is used, and because of the risk level associated with O&M procedures.

Even though the mobile network is authenticated to the user equipment, UMTS authentication procedure is not authenticating any network elements (nodeB and RNC). This has to be arranged for separately, at the IP layer e.g. by using IPsec.

User plane traffic is encrypted up to the RNC due to the RLC/MAC layers, as well as the control plane to the UE (RRC messages). As mentioned, integrity protection is also added to the radio layer signaling (RRC).

Threats related to IP transport on Iub in general are similar to the other IP interfaces. Specific concerns related to the Iub are the high amount of NodeBs, and the physical location of NodeBs. Many NodeBs sites are not physically as secure as controller or core network sites. If the Iub backhaul is not closed (physically secured), IPsec can be applied. Following 3GPP NDS/IP specification for eNodeB access (LTE case), IPsec is mandated, unless the site is physically protected.

9.1.6 Iu-cs, Iu-ps and Iur Interfaces

Iu-cs, Iu-ps and Iur interfaces support both user and control plane traffic. Iu-cs user plane connects to the CS core, with RTP/UDP/IP stack (RTCP optional). Iu-cs control plane stack consists of RANAP/SCTP/IP. Iu-ps user plane is based on GTP-U/UDP/IP, and the Iu-ps control plane is RANAP/SCTP/IP. Iur connects to another RNC, with FP/UDP/IP in the user plane and RNSAP/SCTP/IP in the control plane. Iu-cs or Iu-ps user and control planes do not include any specific protecting functionality on RANAP or Iu user plane layers. (Note that since the serving RNC terminates the radio Layer 3 (RRC) and Layer 2 (RLC/MAC) protocols, Iur is comparable to Iub in this aspect). RNSAP on the Iur does not include any specific protecting functionality.

The protection of these interfaces is based on NDS/IP (IPsec), when needed. As mentioned, NDS formally covers only control plane (RANAP and RNSAP).

Iu interface control plane (both Iu-cs and Iu-ps) carries sensitive information, e.g. the encryption keys, which is why 3GPP specifies the use of encryption along with integrity protection with IPsec ESP, when traversing inter-security domain boundaries. 3GPP documents the reason for requiring this so as not to limit the applicability of IP protocol to a closed network case. Logically this is the Za interface with a SEG. If the Iu interface does not cross a security domain boundary (Zb interface), protection with IPsec is optional.

9.1.7 LTE

LTE security architecture is defined in TS33.401, and it is further built on the 2G and 3G security features, with enhancements. Compared to 2G and 3G specifications of 3GPP, security functionality has been covered in further detail, also related to the eNodeB interfaces, S1 and X2.

For the authentication, with LTE it is possible for the UE to authenticate the network (serving network identity).

In the user plane, air interface is ciphered between UE and eNodeB. Integrity protection is not defined for the user plane. For the S1 and X2 interfaces, user plane protection relies on the use of IPsec (unless physical protection can be assured). In the control plane, protection of signaling includes both ciphering and integrity protection with replay protection.

The algorithms specified are SNOW 3G (128-EEA1 and 128-EIA1) or AES (128-EEA2 and 128-EIA2). These algorithms are used for both AS (access stratum) and NAS (non-access stratum) signaling, and for user plane, and the algorithm is selected based on UE and network capabilities and allowed security algorithms.

For the EPS AKA, LTE introduces new functionalities compared to the UMTS AKA. 3G USIMs are allowed, but 2G SIMs are not supported, so LTE maintains a backwards-compatibility only to the previous generation (3G) but not to 2G. MME is in the role of VLR/SGSN when compared to 3G. With LTE, key derivation includes more steps and intermediate keys than 3G.

Temporary identities are supported in a way comparable to 2G and 3G. Additionally, terminal identity confidentiality is introduced by conveying the terminal identity only after security mode for NAS is enabled.

9.1.8 S1 and X2 Interfaces

LTE differs from both 2G and 3G since in the LTE architecture, eNodeBs connect directly to the core network. This also means that there is IP connectivity from each eNodeB site to the core network, unless this connectivity is limited. The eNodeB is the only element in the radio network, so that the S1 interface is logically comparable to the Iu interface, as it is the interface between the radio network and the mobile core network. In the user plane, the protocol stack is GTP-U/UDP/IP for S1 and X2, in the user plane. In both S1 and X2 control plane, the protocol stack is SCTP/IP.

From the mobile backhaul technology viewpoint, LTE is an IP network from the start, so network domain security is a key concern.

For the user plane (S1-U and X2-U), TS33.401 mandates integrity, confidentiality and replay-protection using IPsec (clause 12), unless the eNodeB is in a physically protected environment. In the latter case S1-U and X2-U links are considered to belong to an extended secure environment. Similar requirements are set for the control plane (S1-MME and X2-C): integrity, confidentiality and replay-protection (clause 11) is mandated, with the same exception allowed for a physically protected environment.

The user plane (S1-U and X2-U) protection in practice is implemented with IPsec ESP (RFC4303) with a profile defined in TS33.210. Tunnel mode is mandatory, transport mode is optional. At the core network side, a SEG may terminate the tunnel. IKEv2 certificate based authentication is specified, with a certificate profile and IKEv2 profiles defined in TS33.310.

The control plane (S1-MME and X2-C) requires IPsec ESP (RFC4303) as specified in TS33.210. IKEv2 certificates based authentication is required (TS33.310). Tunnel mode is mandatory and transport mode is optional.

eNodeB is responsible for ciphering the air interface, and the S1 and X2 interfaces (S1 and X2 via IPsec). Ciphering has to be implemented in a secure environment.

A secure environment is defined in LTE security specifications as a group of sensitive functions within the eNodeB, and a secure storage for sensitive data. Functions are e.g. encryption and those phases of authentication that use long-term cryptographic secrets. Sensitive functions in the boot process also belong to the secure environment. Integrity of the environment itself must be ensured, and the access to the environment must be limited to authorized personnel.

9.1.9 Management Traffic

For LTE, TS33.401 requires that attackers:

• Are not able to modify eNodeB settings or configurations via local or remote access.
• Security associations between the eNodeB and the EPS core are required, and they have to be mutually authenticated.
• Communication between O&M systems and the eNodeB have to be mutually authenticated.
• ENodeB software and data change attempts have to be authorized.
• Confidentiality and integrity protection of software transfer have to be ensured.

Often, management plane traffic is carried together with the S1 traffic, over the same physical links. The same protection mechanisms as defined for the S1 interface, can be reused for the management plane traffic (denoted S1-M).

Tunnel mode IPsec is mandated for the S1-M on the eNodeB. At the other end of the management plane, a SEG can be used, or the functionality may be implemented in an element manager. IPsec ESP, with the profile as specified in TS33.210, including confidentiality, integrity, and replay protection. IKEv2 with certificate based authentication is specified for the eNodeB for the S1-M. Profile is defined in TS33.310.

If the management plane is carried on separate links than S1, essentially an equal level of protection is required. Typically management plane shares the physical links to the eNodeB with other traffic, as arranging separate links is costly. If the management plane interfaces can be trusted (they are physically secured), protection with IPsec can be omitted.

Often there is an additional level of protection at a higher layer by the network management system, since it is essential that communication to the management system is protected. The O&M is vendor specific. As an example, TLS (Transport Layer Security) can be deployed end-to-end between the NMS and the Network Element (NE). TLS can also use IPsec as the IP layer service.