On the (In)Security of 4G - Part VIII: 4G Security Architecture Overview and Features

Table of Contents

Where are we at?

On our journey to understand 4G security, we have arrived at the moment where the User Equipment (UE) has engaged in the Initial Attach Procedure with the network. In our previous post, part VII, I covered that in great detail. Now it is time, to look at security components incorporated at each entities and during crucial moments in the LTE protocol.

Literature

As we are going deeper into the field of 4G security, I wold like to point out some great resources.
The LTE security analysis of NIST is a great starting point and there is even a shorter and more concise presentation about the topic here. If we want to go deeper into the question, what service requirements were taken into consideration for the 4G Evolved Packet System (EPS), we can look that up in TS 22.278. However, the most interesting document might be TS 33.821 because in it, we will find the “Rationale and track of security decisions in Long Term Evolution (LTE) RAN / 3GPP System Architecture Evolution (SAE)". Last but not least, and also covering the whole picture of 4G Security, we find the LTE Security Architecture in document TS 33.401.

4G Security Architecture Overview

Before we begin with the details about cryptographic algorithms, keys and confidentiality and integrity protection of user and control data, I would like to point out the security feature groups of 4G’s security architecture:

The Roman numbers point to different security features and problem domains. These are [Source]:

1. Network Access Security (I): A set of security features that provide users with secure access to services, and which in particular protect against attacks on the (radio) access link.
2. Network Domain Security (II): A set of security features that enable nodes to securely exchange signalling data, user data (between Access Network (AN) and Service Network (SN) and within AN), and protect against attacks on the wireline network.
3. User Domain Security (III): A set of security features that secure access to mobile stations.
4. Application Domain Security (IV): A set of security features that enable applications in the user and in the provider domain to securely exchange messages.
5. Visibility and Configurability of Security (V): A 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.

4G Security Architecture Features

What features does the 4G security architecture have? What does it want to protect? Why? To answer these questions, we have a look at several documents:

• The LTE Security Architecture TS 33.401
• 3G Security Architecture TS 33.102
• General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access TS 23.401
• Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS) TS 24.301
• Evolved Universal Terrestrial Radio Access (E-UTRA) Radio Resource Control (RRC) Protocol specification TS 36.331
• Service Principles TS 22.101
• Network Domain Security (NDS) - Authentication Framework (AF) TS 33.310

In the following section we will go through each feature in depth.

4G User-To-Network Security

This part describes all security interactions and features between the user device and the network.

User Identity and Device Confidentiality

User Identity Confidentiality is defined as “the property that the permanent user identity (International Mobile Subscriber Identity (IMSI)) of a user to whom a services is delivered cannot be eavesdropped on the radio access link” TS 33.102. However this is not enough. We also need User Location Confidentiality, which is “the property that the presence or the arrival of a user in a certain area cannot be determined by eavesdropping on the radio access link” and User Untraceability, which is “the property that an intruder cannot deduce whether different services are delivered to the same user by eavesdropping on the radio access link” TS 33.102.

What does that mean?

1. From subscriber’s privacy point of view it means, his or her identifier should not be sent as cleartext over the radio gap. Thus the Mobile Subscription Identification Number (MSIN), the International Mobile Station Equipment Identity (IMEI), and the International Mobile Station Equipment Identity and Software Version number (IMEISV) should be confidentiality protected.
2. The UE shall only reveal its IMEI or IMEISV, , if the network asks for it in an integrity-protected request.
3. The UE shall only send IMEI or IMEISV to the network, if NAS security has been activated (i.e. after integrity and confidentiality protection measures have been activated for the link). BUT: There is an exception to the rule. If the UE has no valid or provides no valid IMSI, Globally Unique Temporary Identity (GUTI) or Packet-Temporary Mobile Subscriber Identity (P-TMSI) during an emergency attach, the IMEI is sent in plaintext from the UE to the network.
4. IMEI and IMEISV are only sent in the NAS protocol. BUT: NAS confidentiality protection is an option for the network operator. If it is not provided… Well, bad luck, then IMEI and IMEISV simply cannot be confidentiality protected.

Entity Authentication

In TS 33.102 we find two security features related to entity authentication:

1. User Authentication: “the property that the serving network corroborates the user identity of the user”
2. Network Authentication: “the property that the user corroborates that he is connected to a serving network that is authorized by the user’s Home Environment (HE) to provide him services; this includes the guarantee that this authorization is recent.”

In other word the 4G security architecture requires mutual entity authentication between the (1a) User or Subscriber to (2) the Network and (1b) Smartphone/Tablet… or Mobile Equipment (ME) to (2) the Network. As UE includes both, we could say the 4G security architecture requires mutual entity authentication between UE and Network.

User Data and Signalling Data Confidentiality

First of all it seems, that all confidentiality protection (i.e. encryption) of either signalling/control or user data is a network operator option and subject to national regulation. Great. That sounds like: “Well, we would really like to encourage you to use it and please, please, please behave, but if you don’t… Well, we won’t judge.”

Ciphering Requirements

Ciphering requirements begin with the input parameters for ciphering having to be synchronized for all protocols involved in the ciphering.

Let’s start with the “we must encrypt this” part [TS 33.401]:

1. All S1 and X2 messages carried between Radio Network (RN) and Donor eNB (DeNB) shall be encrypted.

And now the “it would be great” part [TS 33.401]:

1. Ciphering may be provided to RRC-signalling as an an operator option.
2. The NAS signalling may be confidentiality protected as an an operator option. Ciphering of NAS signalling messages in laid out in chapter 4.4.5 in TS 23.401.
3. User plane confidentiality protection over the access stratum shall be done at Packet Data Convergence Protocol (PDCP) layer and is an operator option.
4. User data sent via Mobility Management Entity (MME) may be confidentiality protected.

And now the “here we really don’t need confidentiality” part:

1. TS 23.401 defines the “Emergency Calling in Limited Service Mode”. If the authentication of credentials fail in that mode, the network chooses no confidentiality protection of NAS, RRC signalling and user plane

User Data and Signalling Data Integrity

Integrity seems much more important to 4G than confidentiality as in this part we find way more “musts”.

Integrity Requirements

Again we begin with the “all input parameters for integrity protection shall be synchronized for the protocols involved in the integrity protection” part.

In general for all NAS and RRC signalling messages replay protection must be in place.

Integrity is a must have for the following messages:

1. All NAS signaling messages except EPS Mobility Management (EMM) messages specifically listed in chapter 4.4.4 in TS 24.301 must be integrity protected.
2. All RRC signaling messages except those explicitly mentioned in A.6 and chapter 6 in TS 36.331 must be integrity protected.
3. All user data packets sent via the MME shall be integrity protected.
4. All user plane packets carrying S1 and X2 messages between RN and DeNB shall be integrity-protected.

There is one optional integrity protection case defined:

1. Integrity protection for all other user plane packets (except S1 and X2 messages) between RN and DeNB may be supported.

There is again one exceptional situation where signalling and all other messages (similar to the exception with ciphering) will not be integrity protected. Also we have two user plane data cases without integrity protection:

1. If no security context has been activated due to TS 23.401 “Emergency Calling in Limited Service Mode”, all messages are accepted without integrity protection.
2. User plane packets between the eNB and the UE shall not be integrity protected on the Uu interface.
3. User plane packets between the RN and the UE shall not be integrity protected.

4G Security Visibility and Configurability

Security visibility shall be provided to the user for the following cases: “indication of access network encryption: the property that the user is informed whether the confidentiality of user data is protected on the radio access link, in particular when non-ciphered calls are set-up;” [TS 33.401] This ciphering indicator is defined in Chapter 14 in TS 22.101. “The ciphering indicator feature allows the UE to detect that the 3GPP radio interface ciphering (user plane) is not switched on and to indicate this to the user.” The default configuration for this feature lies in the SIM/USIM/UICC and the network operator decides whether to switch it on or off, however the user can explicitly overwrite it.
A little side note: I could nt activate the ciphering indicator on my phone within the E-Plus network.
“Configurability is the property that the user can configure whether the use or the provision of a service should depend on whether a security feature is in operation. A service can only be used if all security features, which are relevant to that service and which are required by the configurations of the user, are in operation.” [TS 33.401 - 5.2]

4G Security Requirements on eNodeB

As the eNB is the first point of contact for the UE, it is especially interesting security-wise. Here we describe requirements for its setup, key management, control/user plane data handling and the secure environment for the eNB.

Requirements for eNB Setup and Configuration

When setting up and configuring eNBs it shall only happen when authenticated and authorized to prevent malicious access. The following seven configuration and setup requirements should hold for eNBs [TS 33.401 - 5.3.2]

1. “The support of security associations is required between the Evolved Packet Core (EPC) and the eNB and between adjacent eNBs, connected via X2. These security association establishments shall be mutually authenticated and used for user and control plane communication between the entities.”
2. “Communication between the O&M systems [(Please note: O&M interface is a Management interface between Home eNB (HeNB) and the Home eNodeB Management System (HeMS).)] and the eNB shall be confidentiality, integrity and replay protected from unauthorized parties. The support of security associations is required between the eNB and an entity in the EPC or in an O&M domain trusted by the operator. These security association establishments shall be mutually authenticated.”
3. “The eNB shall be able to ensure that software/data change attempts are authorized.”
4. “The eNB shall use authorized data/software.”
5. “Sensitive parts of the boot-up process shall be executed with the help of the secure environment.”
6. “Confidentiality of software transfer towards the eNB shall be ensured.”
7. “Integrity protection of software transfer towards the eNB shall be ensured.”

Requirements for Key Management inside eNB

Essentially keys stored inside the eNB shall never leave the secure environment of the eNB. (Except for when specified otherwise in other 3GPP specifications.)

Requirements for handling User Plane Data for the eNB

The eNB encrypts and decrypts user plane packets between the Uu and S1/X2 reference points and apply integrity protection for user plane packets for S1/X2 reference points.

1. All encrypting/decrypting/integrity handling is supposed to take place inside the secure environment where the required keys are stored.
2. “The transport of user data over S1-U and X2-U shall be integrity, confidentially and replay-protected from unauthorized parties.” [TS 33.401 - 5.3.2]

Requirements for handling Control Plane Data for the eNB

Control plane packets on the S1/X2 reference point also must be confidentiality and integrity protected by the eNB.

1. Same measure as in the section above.
2. “The transport of control plane data over S1-MME and X2-C shall be integrity-, confidentiality- and replay-protected from unauthorized parties.” - This cryptographic protection is the operator’s decision! [TS 33.401 - 5.3.2]

Requirements for Secure Environment of the eNB

The eNB incorporates a secure environment where keys are stored and encrypting/decrypting/integrity handling is performed. Sensitive data shall never leave that secure environment, it executes sensitive parts of the boot procedure, has its own system integrity protection measures and only authorized parties shall be granted access to it for modifying its data.

Summary

We have discovered the different zones of protection: Network Access Security, Network Domain Security, User Domain Security, Application Domain Security and Visibility and Configurability of Security. Or in our own words: We need to protect the radio link between UE and Network, the communication from the eNB to the Network, within the Network and make sure, user and signalling data are kept secure, no matter where data travels. To ensure all of this, the 4G security architecture offers a list of features, which we discussed at great length here. The most important takeaway is the different security concepts, NAS and RRC security “zones”, and in general, that LTE security is kind of onion layered.

Here you can read Part VII and Part IX.

See you soon. :)

Abbreviations

• Access Network (AN)
• Authentication Framework (AF)
• Donor eNB (DeNB)
• eHome eNodeB Management System (HeMS)
• EPS Mobility Management (EMM)
• Evolved Packet Core (EPC)
• Evolved Packet System (EPS)
• Evolved Universal Terrestrial Radio Access (E-UTRA)
• Evolved Universal Terrestrial Radio Access Network (E-UTRAN)
• General Packet Radio Service (GPRS)
• Globally Unique Temporary Identity (GUTI)
• Home Environment (HE)
• Home eNodeB Management System (HeMS)
• Home eNB (HeNB)
• Long Term Evolution (LTE)
• International Mobile Station Equipment Identity (IMEI)
• International Mobile Station Equipment Identity and Software Version number (IMEISV)
• International Mobile Subscriber Identity (IMSI)
• Mobile Equipment (ME)
• Mobile Subscription Identification Number (MSIN)
• Mobility Management Entity (MME)
• Network Domain Security (NDS)
• Non-Access-Stratum (NAS)
• Packet Data Convergence Protocol (PDCP)
• Packet-Temporary Mobile Subscriber Identity (P-TMSI)
• Radio Network (RN)
• Radio Resource Control (RRC)
• Service Network (SN)
• System Architecture Evolution (SAE)
• User Equipment (UE)