5G Release 17: Overview of new RAN security features

Because the radio access network (RAN) is the entry point to the telecom network, its security is especially important. 3GPP – where 5G is standardized – gives due importance to RAN security in every release, and deservedly so.

In our earlier blog post, we gave an overview of RAN security in 3GPP Release 16. Fast forward to today where 3GPP Release 17 work is now complete.

Below, we will first give a high-level overview of the latest and greatest, followed by a technical deep-dive. Let’s begin.

Overview of the new features

There are four topics in Release 17 that are largely related to RAN security. Some of these topics were inherited or enhanced from 4G security, e.g., security of 5G Proximity Services. Also very interesting is the reverse - that 4G backported a security feature from 5G, the user plane integrity protection.

Figure 1: Key RAN security standardization topics in Release 17

1. User plane integrity protection. User plane refers to the type of messages that carry data traffic like Internet browsing and video streaming. Integrity protection is a security feature that allows a base station and a mobile phone to determine that the received messages were not tampered with by an attacker. User plane integrity protection was already introduced to 5G as part of Release 15, for so-called Option 2, or Stand-alone). The new addition in Release 17 is the backporting of this feature to the deployment options with 4G core over LTE and NR radios (so-called Options 1 and 3). If the base stations support this feature, CSPs can decide whether to activate it.
2. Security of 5G Proximity based services. Generally, the traffic from/to mobile phones are routed via the network. On the other hand, Proximity based services is a feature that enables mobile phones to directly communicate with each other when in close vicinity. You can consider it as a form of device-to-device communication. In addition, it also allows a mobile phone to act as a relay between the network and another mobile phone which is out of coverage. In Release 17, this feature was standardized for 5G New Radio (NR). Simultaneously, the necessary security mechanisms were also standardized, including securing the mechanism by which a mobile phone discovers another mobile phone, and protecting the actual communication between the mobile phones after the discovery.
3. Security for Industrial IoT. The 5G system is suitable not only for mobile broadband, but also for new use cases including Industry 4.0. For the latter, deterministic communication – the right packet at right time – is especially important and since Release 16, the 5G system supports the enabling technology called time sensitive networking (TSN). In Release 17, the 5G System expands this support for time synchronization and time sensitive communications (TSC) for applications, along with the corresponding security mechanisms including secure interfaces, authentication and authorization.   
4. Security against false base stations. One of the main attack vectors in a radio access network is a false base station, which are radio devices impersonating genuine base stations and very often engaging in some wrongdoing. Several topics were studied in Release 17 to mitigate privacy and security problems caused by these false base stations. The topics included, among others, protection of broadcast and unicast messages. While no proposed solutions from the study were concluded, a new protection mechanism for mobile phone’s capabilities was directly expedited into standards outside of the study.

Let's get a little more technical

Now, take a deep breath and hold tight. We are diving into the technical details.

1. User plane integrity protection (UPIP) with 4G core

UPIP was already introduced in Release 15 for 5G NR with 5G core (so-called Option 2), with a flexibility of reduced data rate. Later in Release 16, the reduced data rate was removed and the support for full data rate UPIP was mandated.

So, what was left to do in Release 17?

Well, it was one of those rare cases where enhancements in 5G were backported to 4G. Among other conclusions from the UPIP study (3GPP TR 33.853), we will only discuss the aspects pertaining to the introduction of UPIP with 4G core over LTE radio (so-called Option 1), and over NR radio in dual connectivity with LTE radio (so-called EN-DC or Option 3).

Figure 2: UPIP in Option 1, 2, and 3

It is the network that ultimately decides whether UPIP is activated. To make this decision, the network takes two points into consideration: (a) the UE’s capability and (b) the network’s policy. Let’s further discuss these two points.

1.1 UE's UPIP capability

The network needs to know the UE’s capabilities in order to determine if the UE supports activation of UPIP. For this, the UE includes a new indication called EPS-UPIP supported in Attach Request and Tracking Area Update messages to the Mobility Management Entity (MME), as shown in Figure 3. The MME then provides the indication to the LTE eNB.

Figure 3: Indication of UE’s UPIP capability

Under the hood, the new indication is signaled as the first bit of the fourth octet (octet 4, bit 1) in the information element called UE network capability. This octet 4, bit 1 was originally called EPS integrity algorithm #7 (EIA7) and was intended to indicate UE’s support for a new integrity algorithm in future. 3GPP’s decision to repurpose the EIA7 bit to indicate EPS-UPIP is motivated by the fact that this bit is transparently forwarded between network nodes without requiring any upgrade of the involved network nodes and interfaces.

1.2 Network’s UPIP policy

The preference or requirement of the network pertaining to the activation of UPIP is contained in the UPIP policy. The policy can take one of the following values:

• Required. It is mandatory for the RAN (eNB in Option 1 and gNB in Option 3) to activate UPIP. If the RAN cannot activate UPIP, it must not establish DRBs.
• Preferred. It is recommended (but optional) for the RAN to activate UPIP. If the RAN cannot activate UPIP, it is still allowed to establish DRBs.
• Not needed. It is forbidden for the RAN to activate UPIP.

This UPIP policy traverses in the network as shown in Figure 4. It can be configured in a function that supports 4G-5G interworking called SMF+PGW-C (Session Management Function + PDN Gateway Control plane function). The SMF+PGW-C can also retrieve the UPIP policy from the combined HSS+UDM (Home Subscriber Server/Unified Data Management), in which case the policy from HSS+UDM takes precedence over locally configured policy at the SMF+PGW-C.

Figure 4: User plane integrity policy traversal with 4G core

Further, the SMF+PGW-C sends the policy to an upgraded MME via an upgraded Serving Gateway (SGW). The policy is then communicated to the LTE eNB at the establishment of a Packet Data Network (PDN) connection, the policy being applicable to all Data Radio Bearers (DRBs) established for that PDN connection. The LTE eNB can also be pre-configured with a local UPIP policy that the LTE eNB uses if it does not receive any UPIP policy from the MME.

Note that the local UPIP policy at the LTE eNB was specified so that the network operators can choose to utilize the UPIP feature in the areas where only the RAN has been upgraded, but not the 4G core network.

In case of Option 3, if the UE supports activating the UPIP, the LTE eNB (which acts the main node) provides the UPIP policy to the NR gNB (which acts as the secondary node). If the UE lacks the UPIP support, the LTE eNB skips providing the policy to the NR gNB in which case the NR gNB does not activate UPIP with the UE.

2. Security of 5G Proximity based Services (ProSe)

Security and privacy aspects of ProSe in 5G were specified in Release-17 in 3GPP TS 33.503, which is largely adopted from security of ProSe in earlier generations. In the below, we discuss some main points.

Figure 5: Some components and interfaces for security of 5G ProSe

As shown in Figure 5, UE A, B, and C are 5G ProSe-enabled UEs that support 5G ProSe requirements and associated procedures. The direct sidelink radio interface between UEs is named PC5. UE A and B connect to 5G Core (5GC) via gNB using the 3GPP air interface called Uu. UE C which is out of the network coverage takes the role of a remote UE and can still get connection via another UE in its vicinity (say UE B) which takes the role of a relay UE.

The policy control function (PCF) supports unified policy framework to govern communication behavior and in the context of ProSe, it provisions the UEs (e.g., UE A, B and C in Figure 5 above) with necessary policies and parameters to use 5G ProSe services. 5G direct discovery name management function (DDNMF) handles network actions required for direct discovery (see below) and interacts with UEs via the interface called PC3a. 5G ProSe key management function (PKMF) interacts with UEs using the PC8 interface and handles network actions required for the key management and the security material for enabling remote/relay UE discovery and communication. The PC8 and PC3a rely on the 5GC user plane for transport, i.e., over IP.

On a high-level, there are three main security features in 5G ProSe, each of which is discussed in further detail below:

• direct discovery security,
• direct communication security, and
• relay communication security.

2.1 Direct discovery security

5G ProSe direct discovery is a procedure used by a 5G ProSe-enabled UE for discovering other 5G ProSe-enabled UEs in its vicinity based on direct radio transmissions over the PC5 interface. It could be of type open or restricted, security aspects, including:

• Open discovery: The ProSe codes in the discovery messages over PC5 are integrity protected. However, they are not encrypted since open discovery is not restricted for certain UEs. Validation of the integrity protection is performed by 5G

• Restricted discovery: This type of discovery only takes place with explicit permission from a 5G ProSe-enabled UE being discovered. To preserve the UE's privacy, the discovery messages support confidentiality protection so that ProSe codes are not seen in the clear by unauthorized parties. Further, integrity checking may be performed either by the 5G DDNMF or the receiving UE. The discovery of relay UE is also based on restricted discovery with some variations.

2.2 Direct communication security

5G ProSe direct communication occurs between two or more 5G ProSe-enabled UEs that are in direct communication range using PC5.

The PC5 communication supports confidentiality protection, integrity protection and anti-replay protection.

The PCF or the 5GDNNMF may provision PC5 security policies to the UEs. If a UE receives PC5 security policies from 5G DDNMF, the UE will use them instead of those provisioned by PCF or pre-configured in UE.

Security keys for direct communication are derived based on long-term keys, similar to the security of eV2X (advanced Vehicle-to-Everything) as specified in 3GPP TS 33.536.

2.3 Relay communication security

5G ProSe relay communication enables indirect communication between the 5G network and remote UEs (that are out of coverage of the network) via a relay UE. The relay UE is officially called UE-to-network relay.

The remote and the relay UE communicate using the PC5 interface and, as for direct communication, confidentiality protection, integrity protection and anti-replay protection are supported. The 5G PKMF may provision PC5 security policies to remote and relay UEs.

For establishing security keys, the remote UE first provides its encrypted long-term identifier (called the subscription concealed identifier, SUCI) or a PRUK ID (if one is available) to the relay UE. Thereafter, two solutions are specified (partially illustrated in Figure 6):

• User plane solution. In this solution, the 5G PKMF of the remote UE is responsible for providing a UE specific security key called Prose remote user key (PRUK) and the key identifier called PRUK ID to the remote UE. If the remote UE indicates PRUK ID, the relay UE (via its 5G PKMF) gets a new fresh key named K_NRP which is generated from the PRUK (identified by the PRUK ID) from the 5G PKMF of the remote UE. Alternatively, if the remote UE indicate SUCI, the security mechanism called generic bootstrapping architecture (GBA) Push is triggered (for this blogpost, we won’t go into the details of this).
• Control plane solution. In this solution, if the remote UE provides PRUK ID, its authentication server function / Prose anchor function is responsible for providing a new fresh key named K_NRP which is generated from the PRUK (identified by the PRUK ID) (for simplicity, we won’t go into detail on this topic). In case the remote UE provides SUCI, an EAP-AKA’ based mutual authentication is triggered between the remote UE and its home network. The PRUK is then generated, and a security key derived from the PRUK is provided to the relay UE. Note that this mutual authentication (which is called “5G ProSe remote UE specific authentication”) is decoupled from, and does not affect, the primary authentication framework in 5G.

Figure 6: User plane and control plane solution for security key establishment in case of relay (for simplicity, only PRUK ID for user plane and SUCI for control plane are illustrated).

3. Security for Industrial IoT

Industrial IoT is a larger topic. The scope of our current discussion is the security aspects of TSC studied in 3GPP TR 33.851. The TSC feature was first introduced in 5G in Release 16, with further enhancements in Release 17.

The 5G system can support TSC by integrating transparently as a logical bridge in an IEEE 802.1 TSN network as shown in Figure 7.

Figure 7: 5G system supporting time sensitive communication

Being a logical bridge means that the 5G system specific procedures (including RAN and CN) are transparent to the TSN system. This transparency is achieved thanks to the TSN translator (TT) functionality that consists of device-side TT (DS-TT) and network-side TT (NW-TT).

Time synchronization messages sent between the DS-TT/UE and the NW-TT/UPF are protected (re-)using the secure interfaces Uu between the UE and the RAN, and N3 between the RAN and the user plane function (UPF). Note that in this case, it is mandatory for the user plane traffic on the Uu radio interface to be both encrypted and integrity protected. In Release 16, only the downlink time synchronization was addressed, with the grand master (GM) clock always being on the NW-TT/UPF side. In Release 17, the uplink time synchronization was also addressed.

Another aspect addressed in Release 17 is the secure interaction between the 5G system and TSN application function (AF). The TSN AF is a network function that knows deterministic application requirements and requests TSC services from the 5G system via network exposure function (NEF). Security of the interface between NEF and TSN AF (re-)uses TLS-based mutual authentication and OAuth-based authorization.

4. Further security enhancements against false base stations

In one of our previous blogs, we checked if the battle against false base stations was over. We reviewed that 5G phase 1 (Release 15) already came with various inherited security features (like mutual authentication between UEs and the network, and integrity protected signaling) and many new privacy and security features (like concealment of permanent identifier (SUPI/SUCI) and integrity protection of user plane traffic). We further discussed that 3GPP, like a good warrior, did not put its guard down and continued to investigate what could still be enhanced over Release 15. For 5G phase 2 (Release 16), 3GPP had initiated a new study (3GPP TR 33.809) to proactively investigate the topic of false base stations even further.

In the below, we will summarize the state-of-affairs in the study by the end of Release 17.

Figure 8: State-of-affairs in 3GPP TR 33.809 by the end of Release 17

Let’s begin.

a) Broadcast protection. This is the hottest and most heavily debated topic in the study. It concerns the downlink broadcast messages, called system information (SI). By design, SI messages are meant for all UEs (including those which have just powered on for the first time ever) and therefore lack any security context for protection. This means that an attacker can create its own SI messages or tamper with the genuine ones. There are numerous proposals on how to fix the problem. Most of them are about using asymmetric crypto and differ from each other mainly on the aspects of key management. Few are using symmetric crypto and rely on shared key between UE and the network. The analysis is still ongoing (e.g., the cost-benefit and robustness of the proposed solutions) and no conclusion has been made.

b) Unauthenticated-unicast protection. Unicast messages are uplink or downlink messages concerning one particular UE. The unicast messages that are transferred after security activation are indeed protected. But there are some unicast messages that occur before security activation (called unauthenticated-unicast) which lack security, and therefore can be read or tampered with by an attacker. One of the proposals to this problem uses asymmetric crypto and is generic to all radio resource control (RRC) messages. Other proposals focus on protection of RRC Resume Request message and RRC UE capability transfer procedure.

We want to note that the study concludes there is no additional work affecting standards for the protection of RRC UE capability transfer procedure. There is, however, a new protection mechanism which was expedited – outside of the study – directly into 3GPP TS 33.501 (clause 6.5.3) and TS 33.401 (clause 7.4.5). As shown in Figure 9, the gist of the solution follows. If the RAN fetches the UE capabilities before security activation, it neither stores them locally for later use, nor sends them to other network entities; and fetches them again after security is activated. If an attacker had tampered with the UE capabilities over-the-air before security activation, the effect is not perpetual, thanks to the new mechanism.

Figure 9: Mitigating the perpetual effect of potentially tampered UE capabilities

c) False base station detection enhancement. This topic is about enabling/enhancing the detection of false base stations. Some proposals use positioning measurement reports, some enrich normal measurement reports, and others focus on handover procedures. The proposals are still under study with no conclusion to date.

d) Man-in-the-middle mitigation. This topic concerns generic threat of false base stations sitting in between UE and the network and performing attacks. Some proposals use global navigation satellite system (GNSS) information of UE and base stations; others propose using indications of abnormal event sequences; and still others use cryptographic cyclic redundancy checksum (CRC). No conclusion has been made.

e) Miscellaneous. For the sake of completeness, the study also mentions topics like self-organizing network (SON) poisoning and radio jamming. No further action is taken in this study, mainly because these topics fall in the scope of other working groups responsible for radio and network management.

Thus, the study has not finished and is continuing in Release 18. There are early indications of further progress, and we could give you a teaser, but let’s keep the surprise until the work is done.

Final words

We discussed the four key RAN security topics from 3GPP Release 17:

• User Plane Integrity Protection with 4G core,
• Security of 5G Proximity based Services (ProSe),
• Security for Industrial IoT, and
• Security enhancements against false base stations.

Because of the pandemic, this was yet another release where the 3GPP meetings were held electronically. While we write this blogpost, the Release 18 work has started and hybrid meetings are being planned.

So, what will Release 18 add to RAN security? Well, we will keep you posted in due time.

We thank our wonderful colleagues who worked on the topic of RAN security.

Further reading

A summary of 3GPP Release 16, 5G phase 2: Security and RAN

3GPP Release 15: An end to the battle against false base stations?

5G security - enabling a trustworthy 5G system

An overview of the 3GPP 5G security standard

Explore IoT

Explore 5G

Explore Industry 4.0