Security for 5G Service-Based Architecture: What you need to know

5G Service-Based Architecture (SBA) marked a paradigm shift for the core network architecture of mobile networks. But what role does security play in its development? We explore why SBA security is the appropriate security for new use cases, how SBA security is specified in the 3GPP specifications, and discuss the use of certificates in actual deployments.

Security for 5G Service-Based Architecture

Senior Researcher security

Senior Expert, security

Senior Researcher security

Contributor (+1)

Senior Expert, security

Category & Hashtags

The 5G Service-Based Architecture (SBA) is built on web technology and web protocols to enable flexible and scalable deployments using virtualization and container technologies and cloud-based processing platforms. The use of 5G systems for a wider range of use cases and the use of virtualized implementation and cloud processing, however, also put higher and different requirements on security.

Acknowledging these changes in requirements, the security for the 5G Service Based Architecture (SBA) is designed to bring the appropriate security for new use cases and the virtualized deployments.

SBA security for direct communication

SBA security for direct communication

Figure 1: Service-Based Architecture (SBA) as specified in 3GPP TS 23.501

 

SBA security, like 5G security in general, is specified in 3GPP TS 33.501. An important consequence of the SBA is that the Network Functions (NFs) can all communicate with each other. The interactions are request/response or subscribe/notify interactions between so-called NF service consumers and NF service producers. This requires a careful specification of how communication between the NFs can be realized and how the service APIs of each NF have to be protected and how the use of these APIs is properly authorized. Furthermore, the underlying protocol stack is based on web protocols like HTTP and JSON. This has consequences also on the choice of security protocols that are used to secure the interactions.

Generally, the following security mechanisms need to be in place to secure communication between different entities:

  • Authentication between the communication endpoints, to mitigate spoofing of messages.
  • Transport protection of the communication (confidentiality, integrity, replay protection), to mitigate tampering, repudiation and information disclosure of messages.
  • Authorization of the request, to mitigate elevation of privilege.

(See also the STRIDE threat model = Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. The observant reader will notice that Mitigation of Denial of Service threats is not mentioned in the list above. This is mostly performed by proprietary means.)

The first version of the SBA security specification, Rel-15, details security for direct communication between Network Functions (NFs), i.e. without proxies between the NFs. It is based on two important components:

  • Mutual authentication and transport security between network functions, based on TLS 1.2 and 1.3, and
  • Token-based authorization for access of NF service consumers to the services offered by NF service producers, based on OAuth 2.0.


TLS 1.2 and 1.3 are state-of-the-art protocols used abundantly for securing communication both in the internet and other networks. Earlier generations of mobile networks and also 5G networks outside the SBA rely traditionally on IPsec. Nothing against IPsec from a security point of view, however, using TLS makes it easier to terminate security directly in the network function instead of a security gateway used to secure a whole network domain. This approach is well-suited to virtualized deployments with multi-tenancy.

Token-based authorization using OAuth 2.0 is a well-established way to perform authorization in a dynamic, virtualized deployment. It is based on a central authorization server that issues access tokens to clients (= NF service consumers in the SBA) after previous authentication of the client. The client (= NF service consumer) then presents the access token to the NF service producer when invoking a service. The NF service producer first validates the access token before granting the NF service consumer access to its services.

In the SBA, the NRF (Network Repository Function) takes the role of the authorization server. The authorization rules can be provided by the NF service producers itself during registration at the NRF. Token-based authorization needs to be coupled with authentication to be effective: NRF and NF service consumer authenticate mutually (using TLS) before the NRF issues the access token. Also transport protection (likewise achieved by TLS) is essential to protect the tokens from being intercepted and misused.

SBA security for indirect communication

SBA security for indirect communication

Figure 2: Model of Rel-16 Service-Based Architecture using indirect communication via the Service Communication Proxy (SCP)

 

The second version (Rel-16) of SBA security specifies security for indirect communication. Instead of an NF consumer interacting directly with an NF producer, indirect communication introduces a Service Communication Proxy (SCP) in the path between NF consumer and producer. From a security point of view, the important aspect is that consumers and producers need to rely on the SCP to send service requests on behalf of the NF service consumer and to forward the responses from the NF service producer to the consumer. This has consequences on the underlying trust model.

The SCP does not simply forward the service requests from the consumer. Both for standardized and proprietary features of the SCP, it is necessary that the SCP can become active and modify the service requests. Hence, although mutual authentication and transport security for each of the hops are still based on TLS, end-to-end transport security between consumer and producer as achieved with TLS in direct communication is no longer possible with indirect communication.

However, token-based authorization as already specified for direct communication comes to rescue, as it provides means for the SCP to prove towards the producer that it is authorized by the consumer to represent it. The SCP simply presents to the producer a valid access token that was issued to the NF service consumer. However, as the SCP in some deployment models can request access tokens on behalf of the NF service consumer, this only works if the NRF ensures that only SCPs that are allowed by the consumer to request access tokens on behalf of them can do so. (For more details, see the Slide set used during discussion in 3GPP SA3 with examples for different deployment models.) For this, the consumer sends a self-signed assertion to the SCP that the SCP uses towards the NRF to prove that it is authorized by the consumer. This mechanism bootstraps token-based authorization. As mentioned above, for communication between NF service consumer and producer, the access token can then be used by the SCP to prove that it is authorized by the consumer to represent it.

Realizing SBA security in deployments

The usage of both TLS and OAuth 2.0 in the SBA relies on the use of a Public-Key Infrastructure (PKI) in place in the network. In a PKI, a Certificate Authority (CA) issues certificates to each of the communication endpoints guided by proper (identity) management functions and policies. The public/private key pairs associated with the certificate can then be used for the asymmetric cryptography used in mutual authentication and signing/verifying of tokens that is required for using TLS and OAuth 2.0 as specified in the SBA.

Realizing SBA will be mainly done using a microservice architecture supporting continuous deployment and updates at a fast pace. Combined with the overall use of TLS for connections between the NFs, there is a need for a highly automated process to issue and manage certificates that the NFs must hold securely. There will be little room for manual procedures for certificate issuing that have been used in the past for physically nodes.

Beside the consideration of how to securely issue certificates in a dynamic 5G system, there is also the question of how to secure the storage of the secrets for the TLS endpoints in a cloud native deployment. Additional challenges are caused by the observation that the NFs are in fact not singletons but a collection of interacting microservices for which the intra NF communication must be protected. This intra NF communication is not specified in the 3GPP specifications, however, TLS is commonly used to protect communication, authorization of API use, and to maintain the topology of the NF as a set of microservices. The manner by which certificates for this intra NF are provisioned is not in scope for 3GPP specification either, yet it is closely related to it, as a certificate provisioning solution for intra NF communication has to be realized in a manner that allows integration with a tenants PKI when required by the tenant.

Since SBA is intended for mobile network use, where there are strong regulatory requirements, the issue of tenant control of certificates goes even deeper. For example, is it acceptable that the PKI for the certificates used by Kubernetes is a CA root autogenerated by Kubernetes itself, or should this PKI have its root in an officially managed external CA? An additional aspect that must be addressed is how to support multi-vendor NFs. The current 3GPP specification leaves several details on how to provision certificates and how to setup an appropriate PKI unspecified. All in all, when realizing SBA, certificate management and the storage of the related keys take a leading position for security.  

Take-home message

The introduction of SBA and microservice technology allows for the realization of efficient mobile networks. However, it also brings new specific security demands that have been taken into consideration by 3GPP in the 5G security specification. SBA security relies on the usage of TLS and other web-based security protocols that are well-suited for virtualized deployments.

The SBA security specifications cover direct and indirect communication, and the aspects of mutual authentication, transport security, and authorization. While the 3GPP SA3 specifications cover essential parts of SBA security, there are also aspects to be considered in deployment. The number of certificates, the use of slicing, as well as the variety of NFs imply that automated certificate management is an important part of deploying SBA security.  An efficient PKI that is able to support all needs is important for the deployment and management of the network functions. An additional aspect is that a well-designed PKI makes it easier to support multi-vendor realizations.  

As for 5G security in general, SBA security is a combination of carefully defined standards, implementation, deployment and operational management. The SBA security specifications were designed to be the appropriate security for new use cases and virtualized deployments. Specification is only one component of security, though, so implementation aspects are essential as well.

Discover more

Read our blog post: An overview of the 3GPP 5G security standard.

Learn more about security standards and their role in 5G.

The Ericsson Blog

Like what you’re reading? Please sign up for email updates on your favorite topics.

Subscribe now

At the Ericsson Blog, we provide insight to make complex ideas on technology, innovation and business simple.