3GPP Rel-18 security - the overview

The security posture of the 5G mobile network is very good today. Over the different generations, security qualities and improvements have been added in order to protect the confidentiality and privacy of the users and applications.

As new use cases and features are added, new and enhanced security solutions for the system need to be standardized. In 3GPP standardization, security is the responsibility of the group SA3. In this blog post, we will look at some of the new security features of the newly finished Release-18 (Rel-18).

We start with the horizontal security enhancements which can be grouped into three categories:

After which we will briefly look into the Rel-18 security work required for some of the vertical areas:

General enhancement of 5G security

Security of the 5G Service-Based Architecture

Security of the 5G Service-Based Architecture (SBA) in Rel-15/16 was a milestone in improving core network security. One important addition in Rel-18 was the specification of automated certificate management. The SBA security relies on certificates provisioned to all network functions (NFs) and the logistics of handling these certificates can become very complex as NFs are deployed dynamically and in scalable instances in the cloud. This requires a high level of automation. A profile for the Internet Engineering Task Force (IETF)  certificate management protocol (CMP) was specified, so that CMP can be used in an interoperable way for certificate enrolment and lifecycle in the 5G SBA. SA3 also clarified how initial trust for the enrolment of an operator certificate is established and provided guidance for certificate and key management procedures in implementations. For more details, please see our blog Security for 5G SBA: updates since Release 16.

Authentication enhancements

One improvement introduced in basic 5G Security in Rel-15 was enhanced home network control of the primary authentication mechanism, that is the home network is involved in each authentication procedure and does not just send authentication vectors to the visited network without checking that the subscriber is present in the visited network.

Rel-18 now also introduced the option of home network triggered primary authentication. The motivation was to refresh the key KAUSF , which is shared between a device connected to the 3GPP network, called user equipment (UE) in 3GPP lingo, and the home network, for example when the UE moves from 4G to 5G for the first time. The key KAUSF is used to secure communication between home network and UE, for example for the update of UE parameters by the home network.

Cryptographic algorithms

The cryptographic algorithms that 3GPP specifications use to authenticate UEs and protect the radio interface communication are not specified by SA3 but by the ETSI Security Algorithms Group of Experts (SAGE). During Rel-18, ETSI SAGE specified 256-bit algorithms for encryption and integrity protection of the radio interface, as well as a 256-bit version of the authentication algorithm MILENAGE. The current versions in use are based on 128-bit keys. Specifying new algorithms is important not only to increase the security level, but the new algorithms are much faster in software implementations, which is needed to support the increased speed of 5G and future systems. SA3 discussed how and when these will be introduced in the 3GPP specifications. The discussion is continued in Rel-19.

Roaming security

Roaming security was an important topic for SA3 in Rel-18. Earlier, in Rel-15, SA3 specified the Protocol for N32 Interconnect Security (PRINS) for the control plane interface between the home and the visited network, for a scenario with roaming intermediaries on the path that are allowed to read and modify signaling messages when providing roaming value-added services. In the Rel-18 timeframe, SA3 by request from GSMA 5G Mobile Roaming Revisited (5GMRR) also considered additional intermediaries such as roaming hubs allowed to send signaling messages on behalf of public land mobile networks (PLMNs).

Address regulatory requirements

The work on security assurance tests, called security assurance specification (SCAS), is one major part of SA3's work to address regulatory requirements. GSMA network equipment security assurance scheme (NESAS) works together with SCASes to provide a security assurance scheme and related test cases for network products. Since the fundamental work in Rel-13 and 14, SA3 has added tests and new test specifications in every release to cater to the additions in functional security requirements and procedures in the new releases.

In Rel-18, SA3 has added a variety of SCAS tests and/or test specifications for virtualized network products, management function, and split gNodeB deployments with central and distributed unit, to name a few.

Another important regulatory requirement is compliance with Zero Trust Architecture. In Rel-18, SA3 analyzed how the seven tenets of the Zero Trust Architecture apply to the 5G core network. Several of the tenets are already covered by existing 5G security functionality, like mutual TLS between network functions and token-based authorization for dynamic access control. The work on Zero Trust Architecture continues in Rel-19.

Bootstrapping application layer security

In Rel-17, SA3 specified  authentication and key management for applications (AKMA), which can be used to authenticate a UE and a third-party application function (AF) as well as establish keys between these two entities. AKMA can be seen as a lightweight, control plane, 5G version of generic bootstrapping architecture (GBA). In Rel-18, SA3 specified the roaming aspects of AKMA. Furthermore, SA3 specified OSCORE and DTLS protocol profiles for AKMA and GBA, meaning how AKMA can be used to establish a secure channel between UE and AF using OSCORE or DTLS, respectively.

Security for vertical areas

Area: Network automation

Generally, the security of network automation features for the 5G core network is based on the security of the SBA, with TLS and OAuth 2.0 as the major building blocks. For the security of the third phase of network automation features, 3GPP SA3 extended SBA security to also cover procedures for machine learning (ML) model storage and sharing, federated learning and data/analytics sharing in roaming. The interesting difference to vanilla SBA security is that the models shared both in model storage and sharing and in federated learning are property of the vendor that trained the model. This led SA3 to develop new features of the existing OAuth 2.0 based authorization mechanism which in addition can provide higher granularity, specifically the option to authorize per analytics use case.

Area: Non-public networks

In the second phase of enhanced non-public networks (NPN), a major part of SA3's work was on the security for non-3GPP access to non-public networks, for example for WLAN access to non-public 5G networks. The interesting part was that standalone NPNs allow the usage of any extensible authentication protocol (EAP) method (for example, EAP-TLS based on certificates) for authentication between UE and network. This means that already deployed authentication solutions can be reused for non-3GPP access to non-public networks. Certificate-based EAP methods like EAP-TLS in turn allow the usage of anonymous subscription concealed identifier (SUCI). One main technical challenge addressed in this work was to specify how the usage of the anonymous SUCI affects the non-3GPP access specific security procedures.

Ranging and positioning is one of the promising new use cases of 5G NPN in factories and logistic facilities. Ranging is the determination of the distance between UEs, or the determination of the direction of one UE from another UE. For the security of ranging and positioning, fortunately, many security procedures from previous features such as proximity services (see below) and vehicle to everything (V2X) could be re-used. However, new security procedures had to be specified for broadcast/groupcast communication, and the authorization procedures required some new work, since users and subscribers may not be willing to share their location with others to assist them with positioning.

Area: Connectivity

Edge Computing brings processing and storage resources for applications closer to where data is generated or consumed. In Rel-17, SA3 had specified the basic security features for edge computing use cases, including the authentication between edge client and edge servers. In Rel-18, one important piece was the security procedures for addressing the roaming case, i.e. when the UE consumes edge services not in its home network but in a visited network. Fortunately, many existing security procedures could be re-used, building on DNS over (D)TLS for discovery and TLS to protect the roaming interfaces between edge configuration servers. Additionally, SA3 made some important clarifications to UE and edge enabler client (EEC) authentication and authorization. In addition to listing AKMA and GBA as optional mechanisms for authentication of UE and EEC, SA3 also gives the option to use application layer based solutions available in the ecosystem. Since there are multiple options for authentication, the TLS 1.3 handshake protocol is used for negotiation of authentication mechanisms. SA3 also specified a solution to prevent possible generic public subscription identifier(GPSI) spoofing attacks and related privacy attacks, by avoiding usage of unverified GPSI received from the client side.

The introduction of IP Multimedia Subsystem (IMS) data channels in the architecture specifications required extensive work in SA3 to specify the security procedures. IMS data channels are a new concept that adds a synchronized data channel to the already established Voice over LTE (VoLTE) and Video over LTE (ViLTE). This data channel can be used to interactively add features to the link, such as real time collaborative editing, and remote real-time control. Rel-18 specifies the security for both the end to Data Channel edge(e2DCe) case and the end to end (e2e) case. Both sets of procedures are based on using stream control transmission protocol (SCTP) over DTLS. One interesting problem to solve was how the DTLS endpoints ensure that the DTLS is really established between the nodes that exchanged the SIP signaling. The solution relies on the secure transport of certificate fingerprints via SIP signaling.

Proximity services use relay UEs when no direct network connection is available. These services are important for public safety use cases. In Rel-17, SA3 had specified the security for UE-to-network relays. The main additions in Rel-18 were the security for the UE-to-UE relay procedures and for emergency services for remote UEs via UE-to-Network Relays. The PC5 link between UE and UE-to-UE relay either uses the User Plane or Control Plane based solution for UE-to-network relays specified in Rel-17 (with network assistance) or the V2X solution using long-term credentials (without network assistance). If required by regulations, and if the remote UE does not have a USIM, emergency services over UE-to-network relay can be supported without PC5 link security.

For Wireless wireline convergence, the main part of the security work was on so-called authenticable non-3GPP (AUN3) devices behind 5G capable residential gateways (5G-RGs). This could be for example a laptop in a residential home that accesses the internet via a 5G capable router. Those AUN3 devices could either support or not support the 5G key hierarchy. SA3 specified the authentication procedures based on the EAP framework for both types of AUN3 devices behind 5G-RGs.

Area: Exposure

Network exposure makes network capabilities, such as data and network services, easily available for communication service providers and third parties. From a security point of view, it is one of the most important attack surfaces, and securing APIs in 5G networks is crucial. In earlier releases, SA3 specified the security features for network exposure to application functions (AFs), for example using the Common API Framework (CAPIF). In Rel-18, CAPIF was enhanced to also consider permission of the resource owner, who could be the user of the UE or the owner of the subscription, before allowing API invocations which result in accessing resources of the resource owner. Authorization of the access to the resource owner's resources uses existing OAuth 2.0 based flows that can be used depending on the specific use case.

Thanks:
Many thanks for the very helpful input from Ferhat Karakoç, Helena Vahidi Mazinani, Michael Li, Mohsin Khan, Niraj Rathod, Patrik Ekdahl, Tiffany Xu, Vesa Lehtovirta, and Vlasios Tsiatsis.

More reading

Learn more about our research on future network security

Learn more about network security standardization