Security for 5G Service-Based Architecture: key updates since Release 16

Catching up: 3GPP Release 16 onwards

In 2020 we blogged about the security of the 5G Service Based Architecture (SBA). The blog covered direct communication scenarios, briefly introduced indirect communication using the Service Communication Proxy (SCP) and described the challenge of automated certificate management for certificate enrolment for all the Network Functions (NFs). Since Release 16 and 17 are finalized, and Release 18 recently completed, it is time to follow up. Here we detail the most important functionality that has been introduced since Release 16, driven by the motivation to make 5G work securely for large scale deployments. We also explain how 3GPP SA3 (SA Working Group 3 – Security and Privacy) took on challenges mentioned in our previous blog regarding automated certificate management.

Security professionals interested in understanding how to exploit all the bells and whistles of SCP for achieving security goals will find valuable insights as we detail the role SCP plays in achieving segmentation of trust domains, while at the same time being ‘trusted enough’ to represent Network Function Service Consumer (NFc) from one trust domain to Network Function Service Producer (NFp) in another trust domain.

Did we just say ‘trusted enough’? Aren’t we striving to adhere to Zero Trust Architecture? To imply such trust, it is necessary to harden the SCP at infrastructure and service layers. That means a security policy as well as architecture patterns are needed to guide your organization – otherwise it’s only a matter of time before the very node that could help with security enforcement is turned into a root cause of a security incident.

We mentioned in our earlier blog the indirect communication via the SCP that was introduced in 3GPP Release 16. Instead of an NFc invoking a service directly from an NFp, the NFc sends its service request to the SCP.

Figure 1A: NFc service request process

Depending on the deployment option, the NFc may even task the SCP to discover the NFp on its behalf. In any case, the SCP has several important operational functions, such as rate limiting, failover, load balancing, rerouting of traffic, connecting different trust domains in an SBA deployment and re-selection of NFs. An SCP can also act as mediator between NF consumers and NF producers from different vendors. The indirect communication with incremental responsibilities delegated by Network Function Repository Function (NRF) to the SCP results in a hub and spoke model as depicted in figure 2, with some NFs depicted as the spokes and the SCP depicted as the hub.

Figure 1B: SCP and NF – ‘hub and spoke’ model

While there are different deployment options for an SBA using indirect communication, which results in different deployment options for SBA security as well, there are some more general aspects of SBA security using the SCP.

One security feature for indirect communication that was introduced already in Release 16 was the Client Credentials Assertion (CCA). In our previous blog post, we mentioned a "self-signed assertion" that was discussed during Release 16. This assertion was introduced to the 5G security specification 3GPP TS 33.501 at the end of Rel-16 as CCA. When the SCP requests an access token on behalf of an NFc, it can use the CCA signed by the NFc to indicate to the NRF acting as an authorization server that the SCP is implicitly authorized to request access tokens on behalf of the NFc. Essentially, the CCA is a short-lived token signed by the NFc that provides authorization of SCP by NFc to represent NFc towards the NRF or NFp in situations where there is only hop-by-hop TLS security due to the presence of the SCP.

SCP security defines overall 5G core network security

Since the introduction of the SCP segments the original end-to-end security between Network Functions, the overall security of a 5G Core network becomes dependent on the security of the SCP itself. This is the key outcome of SA3's study (3GPP TR 33.875) on enhanced security of the 5G Service-Based Architecture in Release 17 and Release 18. Here, SA3 studied topics such as end-to-end protection of signaling messages via the SCP and authentication of the NFp towards the NFc. However, security measures would interfere with the expected advantages of the introduction of indirect communication, like message mediation. Therefore, indirect communication via the SCP should be used in situations where the SCP can be trusted to correctly handle messages passing through it.

In Communication Service Provider (CSP) multivendor, multi service deployments, SCP could serve to be an enabler for step change transition of Release 15 SBA core to Release 16 architecture. It could also provide security separation serving multiple trust domains where 3GPP slices and NFs belong to different trust domains.

During the Release 17 and 18 timeframes, SA3 has also worked on several enhancements that make SBA more secure and easier to deploy. For example, the certificate profiles for NFs, SCP and Security Edge Protection Proxy (SEPP) have been improved. This led to a collaboration with IETF, resulting in the introduction of an X.509 Certificate Extension for 5G Network Function Types (IETF RFC 9310). The latest development is about how the NRF validates the NFc before issuing an access token.

SBA security shows strong adaptability to new use cases

Additionally, we see in Release 16 and onwards that new use cases in 3GPP can successfully rely on SBA security with none or minimal updates. For example, the security of data access via the Data Collection Coordination Function (DCCF) described in Annex X of TS 33.501 largely relies on using token-based authorization with some adaptions. For most new use cases, even those involving the introduction of new Network Functions, SBA security just applies without impacting security architecture. This can be seen as a success of SBA security, since robust secure by design architecture adapts to serving new use cases that it was designed to be.

Certificate Management for the 5G Core

Operational mishaps have shown that manually handling large quantity of cryptographic material is prone to errors and paves the way for an adversarial compromise. 5G Core is cloud native and it has cryptographic footprint in every tier of its technology stack, so the stakes are high if a security risk manifest. It can also lead to unintentional service outages due to expired certificates. So, what do we do to reduce risk in the 5G Core environment? We introduce automation and orchestration of cryptographic material management.

Automation of certificate management enables dynamic scaling of the cloud native SBA for NFs to request and enroll an X.509v3 certificate in a secure manner. A lack of standardized procedure for serving certificate demands of the 5G SBA posed an operational challenge, and a security risk, because of manual handling and provisioning of the cryptographic material for CSP carrier grade environment. These challenges were acknowledged in the industry and led to the start of the Release 18 study and normative work of Automated Certificate Management (ACM), respectively, captured in 3GPP TR 33.876 and 3GPP TS 33.310. Other standardization forums such as the European Telecommunications Standards Institute (ETSI) and GSMA also carried out parallel efforts for automated certificate management for serving use cases of ETSI NFV infrastructure and 5G roaming.

Considering the interoperability requirement in CSP multivendor environments where network functions are sourced from different suppliers, standardized procedures for certificate management life cycle, such as enrolment of a new certificate and ensuring whether a certificate has been revoked, are needed. The ACM study identified nine key issues during the study phase that include:

• Initial trust establishment
• A common certificate management protocol for enrolment and renewal
• Validate identity of the requester before issuing certificate
• Certificate revocation

The normative work for the standardized solutions for identified key issues is completed.

The most important aspect is the establishment of initial trust for the certificate enrolment. Since the 3GPP 5G NF can be a Virtual Network Function (VNF) or Containerized Network Function (CNF) deployed on Commercial Off the Shelf (COTS) hardware, it is not possible for the 3GPP NF vendor to benefit from hardware provided security of data at rest by “burning in” cryptographic material in hardware. Alternatives that rely on confidential computing should be considered to provide initial trust. This revolves around the principle that initial trust relies on either some form of cryptographic authentication or a level of assurance in trustworthiness of the infrastructure. One important discussion on this point was the utilization of remote attestation methods, which is also discussed in another study on the security impacts of virtualization (3GPP TR 33.848) in SA3. Other methods for providing initial trust for certificate management must assume the existence of some level of trust, but the problem then moves to proving initial trust for the mechanism of the initial trust, thus it becomes a classic chicken-egg problem.

Another important aspect in the study is the relation between certificate life cycle management and the NF life cycle management. For example, if the certificate of a NFp has been revoked and the NRF does not have any information about the status of the certificate, the NRF may return that NFp in the service discovery result, which makes the NFc try TLS establishment with the NFp, but it will fail because the NFp certificate had been revoked. This may have a detrimental impact on service availability and network performance, i.e., degraded customer experience in terms of service reliability and sustainability. Consideration of certificate status of the NFs by the NRF could be seen as an NF health check by the NRF. Such health checks provide optimization.

Another aspect is that the operator Certificate Authority (CA) is usually general purpose built and are not adapted to cater for serving all use cases of a 5G network where network functions simultaneously use several certificates for signaling, O&M, and lawful intercept. Hence, introducing a certificate management broker between the SBA domain and operator CA would facilitate better reuse of existing CA capabilities. Such a broker is integral in architecture and is defined as CMF (Certificate Management Function) in the ETSI IFA026 work.

Evolving SBA security further

Each 3GPP release since Release 15 introduced new functionalities for the SBA, new use cases for industry verticals, and addressed gaps in the specifications by resolving potential ambiguities in interpretation. Academia and industry threat intelligence also help review and revise SBA security where necessary. SBA security has also been reviewed from the lenses of Zero Trust Architecture tenets from NIST.

SBA is designed to be cloud native, meaning that the SBA NFs are deployed in a virtualized or containerized environment – on premise in CSP or off premise. Therefore, the security of the SBA is not complete without securing the virtualized and containerized environment. It is an all-software environment that itself is modular in its technology stack comprising several technology building blocks inherited from Cloud Native Computing Foundation (CNCF), for example Kubernetes for container orchestration, Docker container runtime, and CI/CD DevSecOps for security patches and upgrades of microservices and containerized architecture. This is a paradigm shift from the legacy mobile network infrastructure. The threat landscape is expanded so risk reduction requires applying corresponding security controls at each tier in a multilayered architecture to secure the infrastructure entities, O&M, and communication.

Figure 2: Layered realization of a 3GPP NF and some of its external interfaces that require certificates for HTTPS/TLS.

It is imperative to recognize that industry standardization only provides the baseline that is consensus based. However, securing the SBA requires securing the entire lifecycle of an operational carrier grade telecommunications network. Security assurance, security testing, and audit through GSMA NESAS accreditation can truly benefit from 3GPP Security Assurance Specifications (SCAS) and Security Assurance Methodology (SECAM) to provide a level of assurance that vendor products comply with agreed baseline capabilities and additionally product development practices.

As with anything new, the more of it we do and the more we share knowledge, the better we get. With lessons learnt from more commercial deployments of 5GC around the world, and in parallel security researchers identifying vulnerabilities in 3GPP technologies, disclosed in a responsible way through  GSMA CVD and 3GPP CVD programs, improving security is a journey. The next time you find vulnerability in 3GPP stack, raise it through CVD programs. There is no bug bounty, but helping the community is rewarding.

Above we covered built-in preventative security controls within 5GC and accreditation schemes to provide you with higher levels of security assurances. And while perfect security is a utopian dream, we aim to manage risks while on a journey to stay one step ahead of the bad guys. Evolving SBA security has been an exciting ongoing collaborative effort among number of standardization forums (called Standards Development Organizations, SDOs) and Market Representation Partners (such as GSMA and 5G-ACIA). This work will continue building on the sound foundation laid by Release 15 SBA security, as well as from the lessons learnt by more and more commercial deployments of 5G SBA by CSPs and the industry verticals.

Key takeaways:

• The overall security of a 5G Core network is dependent on the security of the SCP itself, as the introduction of SCP segments the original end-to-end security between Network Functions.
• Since Release 16, SBA security has proven to be reliable for new use cases in 3GPP with none or minimal updates.
• The lack of standardized procedure for serving certificate demands of the 5G SBA poses an operational and security challenge. This has been acknowledged by the industry and led to efforts in multiple SDOs around automated certificate management.
• Evolving SBA security is an ongoing journey, boosted by collaboration between standardization forums, Market Representation Partners, and security researchers, who can identify vulnerabilities and raise them through CVD programs.