An Applied Analysis of Securing 5G/6G Core Networks with Post-Quantum Key Encapsulation Methods

1. Introduction

5G has revolutionized cellular communications by providing higher connection throughputs, higher User Equipment (UE) density, lower latencies, improved network configurability, the software virtualization of network services, and a resulting shift towards more affordable commodity hardware platforms for 5G operations and deployments [1]. These improvements have also brought with them a rapidly expanding ecosystem of open-source 5G implementations and tools and even allow them to run or experiment with personal or private 5G networks. Currently, available free and open-source 5G tools also include full-stack implementations that provide all the functionality needed for implementing UE, gNodeB (gNB) software implementations using Universal Software Radio Peripherals, and all the required Core Network (CN) software. Some solutions also provide support for Open Radio Access Network (O-RAN), allowing researchers and customers to mix and match various components to meet their needs, with all of these solutions complying with 3rd Generation Partnership Program (3GPP) standards [2].

Within this realm of commercial and open-source solutions around 5G, security is an ever-evolving topic with many focus areas and areas of research interest. This paper, with its focus on security aspects of open-source CNs, is part of this domain. Reviewing the available 5G open-source CN software packages, three notable solutions are at the forefront: OpenAirInterface, Open5GS, and free5GC. All of these powerful tools leverage the standards set in place by 3GPP but have significant differences when looking at the security capabilities they provide to their users. In an escalating climate of cyber hacks and data leaks, security is ever more important [3]. Users on a public or private 5G network rely on the systems in place to safeguard their data. As our review has shown, free5GC has the most robust security measures in place among these three prevalent open-source 5G projects, incorporating TLS-enabled HTTPS requests between its 5G Core’s Virtualized Network Functions (VNF).

While this is a great capability considering current security standards, the feasibility, availability, and capability of quantum computers are rising. Quantum computing represents a revolutionary leap in computational power, leveraging the principles of quantum mechanics to perform complex calculations at speeds unattainable by traditional non-quantum computers. However, this advancement poses a significant threat to current cryptographic systems, as quantum computers could potentially break widely used encryption methods by recovering cryptographic keys currently infeasible to be recovered by classical machines.

In cryptography, we consider two primary types of encryption: symmetric and asymmetric encryption. A common example of symmetric encryption, where the same cryptographic key is used for both encryption and decryption, is the Advanced Encryption Standard (AES). Asymmetric encryption utilizes key pairs comprised of a public and a private key that are related to each other. It is primarily used for digital signatures but can also be used for data exchanges. For example, it can be found in key exchange algorithms used with symmetric encryption to ensure the same key is available to both parties. These challenges have been explored by European Telecommunications Standards Institute (ETSI) [4] and others [5,6]. One common example of that role is found in TLS, which, in turn, is the key security mechanism behind HTTPS and other secure communications approaches. In TLS, symmetric encryption using AES is used for the actual data exchange, but asymmetric methods are used for TLS session establishment and the key exchange. Here, it is important to know that while AES-256 is generally considered quantum-safe, there is an increased risk specifically for asymmetric cryptographic methods, which in turn could pose the risk of quantum computing attacks revealing the symmetric keys being exchanged during TLS handshaking and thus allowing an attacker to decrypt all data being exchanged by both parties.

To counter this threat, post-quantum cryptography (PQC) is being developed as a suite of cryptographic algorithms designed to be secure against the capabilities of quantum computers. PQC algorithms are based on mathematical problems that are believed to be resistant to quantum attacks, such as lattice-based, hash-based, and code-based cryptographic methods. Implementing PQC is crucial for future-proofing secure communications and ensuring that sensitive data remains protected as quantum technology evolves. The National Institute of Standards and Technology (NIST)’s efforts in this domain focus on standardizing algorithms to address threats to key encapsulation and digital signature algorithms from quantum computing [6].

PQC is also crucial for securing 5G core networks due to the introduction of VNFs in the 3GPP 5G standards. While 3GPP security standards do not explicitly list support for PQC in their supported TLS guideline [7], expansion of security profiles Subscription Permanent Identifier (SUPI) protection allows the introduction of quantum-resistant protection [8]. VNFs decentralize and abstract network functions into virtualized software services running on standard hardware, increasing flexibility and efficiency but also expanding the attack surface if the communication between all of these software services, which predominantly use HTTP-based REpresentational State Transfer (REST) API calls between themselves, is not properly secured. In a typical perimeter-based cyber defense posture, where we focus on keeping attackers out of the 5G Core Network, any successful intruder that can establish a foothold inside of the 5G core poses a grave threat to any and all 5G core activities and its users. With current security measures, all 5G CNs are at risk of Store Now Decrypt Later (SNDL) attacks. This is the idea of collecting encrypted data and decrypting it later using, for example, a quantum computer. In the event an attack like this succeeds, sensitive customer connection data will be leaked. In order to protect against these possible attacks, CNs must be equipped with strong Key Encapsulation Methods (KEM).Current 5G CNs that have TLS capabilities, like free5GC, are still vulnerable to SNDL attacks. Specifically, connections between the VNFs within the CN are at risk if this data is ever leaked and must adopt PQC features to mitigate this vulnerability.

The remainder of this paper is organized as follows. Section 2 outlines an overview of our approach, Section 3 provides an overview of related research efforts, Section 4 outlines current open-source 5G cores and compares their implemented security features, and Section 5 gives an overview of our integration of PQC algorithms into the open-source free5GC package. Section 6 will outline the results of our 5G core efforts, including our obtained bandwidth and latency results for connecting UEs to 5G services when different PQC KEM algorithms are being employed, and Section 7 will conclude our work and provide future research directions.

2. PQC Protections for 5G Core Networks

Open Quantum Safe (OQS) [9] has assembled open-source packages to address this specific issue, integrating quantum-resistant KEMs into OpenSSL. With the current 5G CNs being susceptible to SNDL attacks, our research, and development of a quantum-safe CN shows that it is absolutely feasible for production systems, with only a small amount of associated overhead. Figure 1 showcases the main systematic components of a 5G network, including the focus of this paper – a quantum-safe 5G CN. Our research is already continuing to expand these security provisions to the communications between the Radio Access Network (RAN) gNodeB base stations and the 5G Core, as well as for end-to-end protections for the user plane traffic, especially when it involves Multi-Access Edge Computing integrated with the 5G infrastructure. These efforts are also shown in Figure 1.

In Figure 2 below, we are providing a more in-depth look into the 5G core architecture and its set of VNFs, all of which communicate with each other using HTTP REST API calls, which for security would utilize TLS to secure the transport layer. TLS, as mentioned earlier, uses asymmetric cryptography for the session establishment, and it is here that we focused our research in order to provide PQC protections for the TLS key exchange process.

This paper introduces an integration of PQC algorithms within an open source 5G core network, free5GC. A detailed analysis of these algorithms and their effect on latency and bandwidth for UE connections to a CN. From the results presented in this paper, there are existing PQC implementations that achieve similar latency to traditional security methods, while having limited effect on a network’s utilized bandwidth.

3. Related Works

As Quantum Computing (QC) continues to evolve, finds practical applicability, and is more widely available, the threat of current encryption methods becoming vulnerable to quantum algorithms able to determine the encryption key and thus enabling the unauthorized decryption of the protected information grows as well. The discovery of various Quantum Algorithms (QA) has also shown that current TLS is at risk given a sufficiently powerful quantum computer infrastructure. Current cryptography techniques leverage math problems that would be too resource and time-intensive to solve with a typical computer [10]. With a traditional Turing-based computer, the difficulty of factorization of a number grows exponentially with the size of the number. In 1999, Peter Shor developed Shor’s Factorization Algorithm – a quantum computing algorithm that can factorize any given number in logarithmic time, potentially reducing a factorization that would take thousands of years down to a few minutes [11]. Similarly, in 1996, Grover’s algorithm was discovered, which leverages quantum computing in order to take the problem of finding a random record in N records from O(N) difficulty down to O(log(N)) [12]. Due to their ease of solving the mathematical problems behind current encryption methods, Quantum computers have shown to be relatively effective at circumventing different types of currently employed encryption methods such as Rivest–Shamir–Adleman (RSA), Diffie-Hellman (DH), and Elliptic Curve Cryptography (ECC) [13]. Therefore, an urgent need to create and implement algorithms that cannot be easily solved by either a traditional or quantum computer has emerged.

Much of the current internet infrastructure relies on one or more of these encryption algorithms, and due to the widespread nature of the problem, a need was identified to find quantum-safe cryptographic algorithms. In 2016, the United States NIST called for proposals of alternative Public Key Encryption Schemes, Key Encapsulation Methods, and Digital Signature Schemes, which would be resistant to a quantum attack [14]. The goal of this process is to identify a PQC algorithm best suited for widespread adoption and standardization. In the first round of submissions, 69 total algorithms were submitted. These were then evaluated based on three major characteristics: security, cost and performance, and algorithm implementation characteristics. NIST completed three rounds of evaluation, and encryption methods were improved and resubmitted as the evaluation progressed [15]. As of August 13, 2024, NIST has released its first three finalized encryption standards, which will significantly reduce the threat posed by quantum attacks on systems that implement PQC approaches. NIST has also stated that it will continue to evaluate alternative encryption methods, but these should be considered backups to the finalized selections [16].

While these algorithms can be applied to regular internet traffic, they are far more advisable for consideration in addressing specific complexities and needs in areas such as 5G security. 5G UEs must first communicate with a base station, referred to as a gNB by 3GPP, which then communicates with a 5G CN. This 5G CN subsequently performs authentication and provides the UE with access to the internet. One of the main features of 5G is that many of the prior generations’ hardware-based network operations are now represented by software services and are able to be virtualized [17]. These network functions use HTTP REST API calls to communicate with each other [18]. HTTP communications do not provide any secure encrypted communications. For that, HTTPS was created, facilitating security through Transport Layer Security (TLS) capabilities. Whenever one of the VNFs requires the services of another VNF, it will first need to establish an HTTP/HTTPS connection to that VNF service before exchanging data securely. The capabilities of software virtualization in 5G mean that there are no restrictions about where each VNF could be running. A 5G Core’s entire set of VNFs could be deployed on the same physical host or be distributed across a number of physical hosts. But regardless of where they are deployed, they do require network communications to function properly, and for those communications to be secure. One of the goals of the research presented in this paper is thus to strengthen the secure communication between these network functions, ensuring that any information exchanged is quantum-safe.

There is existing research on applying PQC algorithms to the 5G domain. In [19], Figlarz and Hessel apply a PQC signature method to enhance the security of the 5G-AKA key exchange. Hoque, Abdullah, and Zeydan present a PQC key distribution framework for Internet of Things (IoT) networks that utilize 5G networks in [20]. In [21], the authors Minhas and Mansoor propose securing communication between edge-computing devices for e-Health applications in IoT, which often rely on a cellular connection through 5G. One of the key performance indicators of 5G networks is to be able to support multi-access edge computing (MEC), or a form of computing where applications and data are stored at the network edge, greatly reducing latency and improving scalability, compared to a cloud-based service, and allowing for low latency computation to be performed off of constrained devices [22]. Previous works have created an implementation of this service, such as a 2016 report that presents an architecture for MEC and, through their tests, has shown that MEC is capable of applications with a network delay of as little as 17ms [23]. Other works have shown that it is practical and has shown a minimum latency of as little as 10ms in the network [24]. However, there is also existing concern about the speed at which PQC can be utilizes, especially in TLS. In [25], Zheng et al. evaluated PQ-KEM algorithms and found hardware advancements speed up PQC key generation by 3.5 to 4.9 times. In this paper, we expand on the current 5G security research by implementing PQC key exchange for communication between each of the VNFs within the 5G Core network and present the resulting performance impact to latency and bandwidth compared to traditional cryptographic algorithms.

In [26], Zeydan et al. introduce a novel architecture that integrates Quantum Key Distribution (QKD) with Blockchain-based Self-Sovereign Identity (SSI) within the Open RAN (O-RAN) framework for 6G networks, aiming to enhance security and identity management. It explores the practical applications, challenges, and future directions of this integration, emphasizing its potential to transform telecommunication networks into more secure and decentralized systems. The authors of [27] explore the integration of quantum computing, federated learning, and 6G networks to enhance security and privacy in the Internet of Things (IoT) ecosystem, addressing the unique challenges posed by the proliferation of IoT devices. They also provide an overview of recent developments, a conceptual framework for implementing these technologies, and insights into future advancements that could significantly improve IoT security. Nakka et al. [28] address the threat of quantum computing in distributed energy resources (DER) and explore the adoption of PQC within the IEEE 2030.5 standard for DER networks and presents a real-time hardware-in-the-loop co-simulation testbed to validate the feasibility of implementing PQC in DER systems. Additional work as been conducted evaluating PQC for IP Security (IPSec), which achieved 100 Gbps throughput in a high-speed data center and 0.486 Gbps in a local-to-cloud architecture [29].

4. Current Open-Source 5G Core Security

While the focus of this paper is on implementing Post Quantum Cryptography for a custom implementation of free5GC and the resulting performance considerations, we first present our comparative analysis of prominent, currently available open-source implementations of 5G cores in order to compare and contrast what security measures are currently in place for each of them. There are currently five implementations of open-source 5G networks available. Of these five, there are three that have complete core network implementations: Open5GS, free5GC, and Open Air Interface (OAI) [30]. Current published research analyzing the security of their network functions on these three. The study of these three Core Networks (CN) identified and briefly described any existing vulnerabilities. In our own review, outlined in Table 1, it was found that the OAI CN didn’t implement TLS at all. Every REST API call between 5G Core VNFs is performed using unencrypted HTTP. Furthermore, it is critical to analyze the projects utilizing TLS to determine vulnerabilities in the TLS communication used throughout the network. The OAI CN was excluded from this review because it did not implement TLS [31].

TLS is recommended by 3GPP to be used for any 5G Core communications to improve security. Hence, we can see that OAI doesn’t fully meet 3GPP recommendations, at least in the state it was in during the research [2]. The free5GC project currently implements TLS versions 1.0-1.3, while Open5gs implements versions 1.2 and 1.3. Having these outdated versions of TLS opens free5GC up to a downgrade attack where, if a TLS version cannot be agreed upon, then the version will be downgraded to a less secure one until the two communicating parties both agree on a version. Limiting this to only recent TLS versions decreases the risks of downgrading attacks in Open5gs, giving it an advantage in this regard. In terms of TLS vulnerabilities and weaknesses, the tools used in this research, TLS-Scanner [32], SSLyze [33], and PySSLScan [34], were unable to find any vulnerabilities in Open5GS, while free5GC is vulnerable to the "sweet32" attack and has the "version intolerance" bug.

Additionally, we observed that in both implementations that have TLS, a default key and certificate were used. As stated in the research [31], this could have catastrophic consequences if these cores were ever commercially deployed unmodified, as anyone could retrieve the public key from GitHub and then would be able to decrypt messages being sent between network functions. It was found that free5GC makes use of 14 different ciphers, all of which are ordered by strength. The application then uses the most complex first, going down the list if the strongest cannot be used. In research, it has been found that 8 of these 14 cipher suites are weak, with some being broken as far back as 2017 [31]. Open5GS also uses weak cipher suites, with 10 of the 16 ciphers used being considered weak. Additionally, Open5GS does not have cipher ordering, meaning there are no guarantees that the strongest available cipher will be used in communication. Open5GS and OAI can also benefit from the addition of PQC. OAI would first need to implement TLS capabilities, and since OAI is written in the C language, direct access to OpenSSL at the system level can be integrated. Like OAI, Open5GS could also benefit from the integration of PQC, utilizing a similar migration process as suggested for OAI.

However, there are some challenges and risks associated with integrating PQC algorithms into projects such as these, as PQC implementations are inherently unproven and can have potentially negative security ramifications if implemented incorrectly. While this is a concern in general, several projects already use the OQS implemented we selected successfully, specifically to mitigate this risk. Additionally, there is no straightforward approach for empirically evaluating the security improvements provided by such PQC implementations, which we consider out of the scope of this paper. It is also possible for malicious parties to subvert open-source third-party packages in what is referred to as a software supply chain attack, in order to introduce vulnerabilities then propagating to dependent packages. While not detailed in this paper, we performed due diligence and reviewed all utilized packages for any reported vulnerabilities.

There are also computational trade-offs for utilizing PQC in a system. Additional processing for encryption and decryption, higher bandwidth utilization, and increased latency are all potential concerns when utilizing PQC instead of more traditional cryptographic approaches. During our testing, no noticeable increase of CPU usage was observed within the system. Thus, the primary focus of our study is on the implication of our PQC integration on the utilized bandwidth and latency, our study of which is presented in Section 6 of this paper.

While the aim of this research is on current implementations of 5G CNs, research towards 6G networks identifies additional capabilities. Current research suggests 6G implementations will include Holographic MIMO, which leverages large intelligent surfaces (LIS) [35], the implementation of AI/ML for radio access [36], AI/ML for more efficient receivers [37], and Reconfigurable Intelligent Surfaces (RIS) for improved energy efficiency and adaptive beam-forming [38]. Core network improvements will focus on Quality of Service improvements and may have lower latency and bandwidth tolerances than presented in this paper [36]. MEC is also predicted to experience increased adoption with the introduction of 6G standards, which often have different requirements for latency and processing time. However, there are concerns with adding PQC methods to Fog and Cloud Computing applications, as key size, encryption processing time, and data overhead may increase latency [39].

5. Methodology

As NIST continues to standardize PQC, the expectation is that this technology will experience a rapid acceleration of its integration into a wide variety of existing and future software and infrastructure projects in an effort to maintain a high level of security and privacy protections. To aid in this effort, the open-source community started a new project called "Open Quantum Safe" (OQS). OQS’ efforts focus on creating and maintaining a free implementation of PQC algorithms in the form of "liboqs", as well as integrations of this capability into common providers and architectures, such as OpenSSL [40], BoringSSL [41], and more. Specifically, enabling the OQS extension for OpenSSL allows for a more straightforward approach to testing and research of these algorithms in lab and production systems before, during, and after their standardization by NIST. The specific repository used in this research, oqs-provider, lists its included PQC KEM and Signature algorithms. A list of these KEM and Signature Algorithm groups is shown in Table 2.

Specifically, the main focus of testing is put on CRYSTALS-Kyber, as it is the main KEM that is being considered for standardization by NIST. The full list of KYBER PQC and Hybrid (a combination of traditional methods with PQC) KEMs included in oqs-provider is detailed in Table 3.

The full incorporation of PQC into a 5G CN does require careful consideration of understanding the components and interfaces that require changes. If there are any missed in the process, essential CN functions will no longer work, causing fatal system errors.

The process outlined in Figure 3 details the high-level steps taken to add PQC into a 5G CN. This methodology can also be used as a roadmap to incorporate PQC into other 5G systems, as the underlying structure of different CNs is comparable in accordance with 3GPP standards.

In order to utilize oqs-provider, it needs to be compiled from source, which ultimately generates the necessary shared library file that OpenSSL utilizes to incorporate the PQC KEMs and Signature algorithms. In Listing 1 in Appendix A, we are demonstrating the instructions for this procedure that we have incorporated inside each of the Dockerfiles associated with all the NFs included in free5GC.

To fully enable the features provided by this extension in a variety of environments, OQS provides detailed instructions in their documentation as well. For the purpose of this research, the CRYSTALS-Kyber KEMs were activated at the system level by adding their values to the ’openssl.cnf’ configuration file. Figure 4 shows the lines that were added or updated in order to enable OQS.

The free5GC project is a free and open-source 5G CN that is currently compliant with 3GPP Release 15, with ongoing development aiming at compliance with 3GPP Release 17 [42]. In our research, we cloned the original free5GC repositories and subsequently modified them to incorporate PQC capabilities using oqs-provider. Free5GC has a "docker-compose" deployment method that allows for seamless integration and use with systems that support Docker. Figure 5 illustrates the Docker images that are running after updating the free5GC codebase to allow PQC.

In our custom implementation of free5GC, each VNF container is running a lightweight version of Ubuntu 22.04 Jammy with OpenSSL v3.0.2 installed. After compiling oqs-provider from source for the respective platform, the resulting shared library file is installed in each VNF Docker container, enabling PQC integration at a system level.

Additionally, some modifications to the source of free5GC are necessary in order to utilize OpenSSL. Virtually all aspects of free5GC are written in GoLang [43], which lacks direct native support for using OpenSSL. A Go program traditionally uses Go’s own TLS and Crypto libraries to handle TLS communications [44]. To address this challenge, we selected the open-source Go-Openssl wrapper from ’pexip’ [45] and incorporated it within each VNF to enable the use of OpenSSL for cryptography within free5GC rather than Go’s crypto library. At the time of publication of this paper, the custom CN implementation is built using free5GC v3.4.2. The integration of Go-Openssl focuses on two main areas within each VNF in free5GC’s source code: server.go and the OpenAPI system. Within server.go, the network function is typically utilized to create a TCP listener, which subsequently utilizes the Go TLS to secure the HTTP connection on the server side. Listing 2 in Appendix A shows a code snippet of the two functions that are amended within the code base, in this specific case for 5G’s the "Access and Mobility Management Function" (AMF) VNF. In our PQC-enabled implementation, if encryption (https) is enabled in free5GC’s YAML configuration file, then an OpenSSL-enabled listener is created within the ’NewServer’ function. The newly created server uses the OpenSSL context that is stored in the server struct from the logic in the NewServer function. The built-in functions are used to obtain the path to the certificates used for context creation, and certificate verification is set to "none" for testing purposes.

Next, our focus was on enabling each of the HTTPS clients used throughout free5GC for API calls to similarly be enabled for OpenSSL usage. This process was not as straightforward as the corresponding server-side effort. Free5GC utilizes an OpenAPI-driven approach to API implementation and handling of client HTTP requests. Analyzing the call flow across multiple different files that include client attributes revealed that, ultimately, they all utilize a call to the CallAPI() function within the free5GC OpenAPI repository, which is located in the client.go file. In this function, an OpenSSL context is created using two specific functions: CreateOpenSSLClientCtx() and GetCurrentNetworkFunctionUsingAPI(). The OpenSSL context is managed in the same manner as the server. However, in the case of a client, there are no built-in functions to obtain the path to the client certificates. Client certificates are not strictly required for TLS connectivity. However, they are needed when mutual TLS authentication (mTLS) is desired, which can provide a significant improvement in security between both client and server. Thus, GetCurrentNetworkFunctionUsingAPI() obtains the specific network function that is making a request by parsing the stack trace. Returned from this function is effectively the name of the VNF making the HTTP request, which is appended to the path where the certificates are stored inside the Docker containers. In either scenario, if the configuration includes a custom HTTPClient setup requirement, a custom client transport method that includes OpenSSL support is added. The logic sequence for this process is shown in CreateOpenSSLInnerClientTransport(). The dialTLS function that handles the transport protocols for an HTTP client in Go is overridden to use the OpenSSL dial wrapper. The request is then made using the OpenSSL-enabled dialTLS() function during the invocation of the Do() method. This process is shown in the code Listing 3 contained in Appendix A.

One major goal of this customization was to make it as seamless as possible for a free5GC administrator to install and operate it with support for PQC. With the extensible nature of Docker, this goal was met while maintaining the same basic structure for downloading and installing our PQC-enabled free5GC build. The user only needs to run one additional command to install MongoDB from source, which, for convenience, has been incorporated into a single shell script. The steps to clone, build, install, and run PQC-enabled free5GC that are used by this script are also shown in Appendix A in Listing 4.

Once we established a full integration of PQC into all HTTPS REST API endpoints (server code) and all corresponding client calls to these APIs, we could proceed to collect results that demonstrate the feasibility of this integration of PQC into free5GC operations and also quantify the impact on latency and bandwidth usage, which are shown and discussed in the next section.

6. Results

The results from this study aim to evaluate the impact of using standard Elliptic Curve Cryptography (ECC), PQC, and Hybrid PQC KEMs within the communications of the VNFs in a 5G CN using free5GC. All of the CRYSTALS-Kyber KEMs displayed in Table 3 are included in this evaluation, along with the classical ECC KEM x25519. Furthermore, these different methods are compared to a CN that does not use TLS to secure the 5G CN API calls and instead uses unencrypted HTTP calls. This acts as the baseline for our tests. All of them were conducted on a Dell Server equipped with an AMD Epyc 7313p 16-Core, 32-Thread CPU, running the aforementioned custom implementation of free5GC. Included in this test environment is another computer, which is responsible for running UERANSIM, a tool provided by the free5GC package to simulate a gNB as well as multiple UE connections in accordance with 3GPP standards. Any performance metrics of the UERANSIM host machine are inconsequential to this evaluation since all the signaling requests and communications activities are measured relative to the TLS activity within the CN machine. Both machines are running Ubuntu 22.04 LTS.

6.1. Testing Scenarios

Each test is conducted with 100 total UE connections in order to maintain statistically relevant, consistent, and comparable results. Each UE is scheduled with a seven-second cadence between connections, allowing the CN sufficient time to complete each client attachment and to be able to adequately capture and measure each TLS handshake. The data gathered from these studies represents the varying total UE connection times between the different KEMs available in this system. Prior hypotheses were that the PQC KEMs would result in a significant additional latency during a UE connection, but as our results clearly show, this is not the case. In our testing, all connections use a consistent cipher, AES_256_GCM_SHA384, to maintain high security and uniform data communication latency results. Due to OpenSSL typically only accepting signed certificates from a trusted Certificate Authority (CA), all tests are conducted with OpenSSL set to skip certificate verification. This is due to the fact that free5GC includes self-signed certificates. However, it is highly recommended for production systems to use certificates that are signed by a trusted CA. The use of certificates from a CA could increase the latency of the UE connections, due to the small additional time required for verification, but this additional time would be true for any KEM that is used – traditional or PQC.

Wireshark is utilized to capture packets within the CN, displaying the communications between the VNFs. Data from these packets can be extrapolated to further understand connection times, bytes sent, etc. Prior to each test, one KEM is enabled in each of the VNFs openssl.cnf file, ensuring proper control over the test environment. The KEM that is under test is also validated in the final Wireshark capture, which can be seen during the Client or Server Hello message under the ’key_share’ extension field. Then, the CN is brought up, and the gNB connection is established. Once all of these processes are complete, Wireshark begins capturing packets on the free5GC-br network interface. Once Wireshark begins capturing, the UERANSIM program is executed, with inputs configured for 100 total UE connections and a seven-second cadence between each subsequent connection. Each UE connects in its own time interval in order to gain a large data set to understand the average UE connection time with each respective KEM active in the CN, and other information which is analyzed in the next section.

6.2. Data Analysis

One important test we conducted focuses on the measurement and evaluation of the total client connection setup duration, which represents the time from the UE initially requesting a connection via the gNodeB until the UE can send user data through the 5G connection. Figure 6 shows a box plot of the different KEMs and their respective UE connection times we obtained. We observe that the baseline connection time when using no encryption (plain-text HTTP requests) is slightly less than 0.5 seconds. This is expected due to the fact that there are significantly fewer computations required when we are not encrypting and decrypting each communication request.

It is important to stress, however, that we conducted this analysis solely for baseline purposes. In no way do we recommend implementing or operating a 5G Core Network using unencrypted communications, as this would pose a significant and unnecessary risk to user data and control data. As a secondary baseline, therefore, we are utilizing the ×25519 KEM. This method is a commonly used ECC KEM known for its high performance and adequate security, utilizing a key size of 256 bits. It can be seen that the hybrid x25519 algorithms are nearly identical in total connection time compared to the regular Kyber KEMs, in terms of additional latency. The P256, P384, and P521 hybrid variants, however, do add significantly more latency to the handshake and total connection process times.

Figure 7 outlines box plots that represent the amount of data, in Megabytes, transmitted in the CN during an attachment of a UE. Showing a similar outcome to the results in Figure 6, the tests conducted and shown here for unencrypted communications and the x25519 KEM once again show the lowest amount of bytes exchanged. With the understanding that encryption by nature adds more data to a packet, along with more packets overall being required due to the addition of the TLS handshakes, it is no surprise that there is significantly less data transferred during the unencrypted baseline. Likewise, x25519 uses a 32-byte key, which is the smallest key size compared to other PQC and Hybrid PQC KEMs. It is obvious from these results that with this increase in key sizes we observe an increase in required data being exchanged. For example, kyber512 has a median data volume of 1.12 MB, and kyber1024, with double the public key and cipher text size as seen in Table 4, is responsible for an increase by nearly 200 KB of data that is sent during the UE connection process.

Further correlation between larger key sizes and bytes exchanged can also be observed throughout the dataset collected for the Hybrid PQC KEM results. We hypothesize that the observed variance in the data is due to ongoing internal CN communication that can vary from time to time, thus creating some tests that record a differing amount of bytes during a UE connection operation. Hybrid PQC KEMs are specifically important in the role of quantum-resistant algorithms. In a blog post from Google engineers, the authors state the two main rationale points for using Hybrid KEMs is ’Mitigating risks associated with new algorithms’ and ’A safe transition’ to PQC [47]. Hybrid KEMs provide the security of PQC combined with the trust afforded to ECC. Thus, many systems are expected to adopt the hybrid approach, and the data presented on the network performance of Hybrid PQC KEMs in 5G is promising.

Figure 8 and Figure 9 illustrate the relative differences in time between the different KEM algorithms used during UE connection operations in relation to the unencrypted operation and to the ECC x25519 KEM, respectively. For example, Figure 9 takes the average UE connection time of each tested PQC and Hybrid PQC KEM and subtracts the average UE connection time of the standard ECC x25519 KEM. A similar approach is used in Figure 8, subtracting the connection time we observed for unencrypted 5G core operations from the obtained PQC and Hybrid PQC results. The previously mentioned trends are extrapolated here to give a clearer view of the relative time differences. We would also like to specifically point out the performance shown for p384_kyber768, as it is nearly 50% slower than its counterparts. Our hypothesis is that the cause of this outcome is the lack of optimization capability for the specific P-384 algorithm in software, combined with additional computational complexities when working with that specific KEM. Figure 9 notes the time differences compared to the classical ECC x25519 KEM. Interestingly, all of the standalone Kyber KEMs performed better than the baseline ECC x25519 KEM. This could be due to heightened optimizations within the OQS OpenSSL library, along with using an AVX2-enabled machine.

In order to better understand the complexity of a UE connection operation, we wanted to show the entire process and all API calls required to complete this process. Thus, in Figure A1, shown in Appendix A, we are showing a detailed call sequence for one entire UE connection sequence, observing a total of 129 TLSv1.3 handshakes. Contained in this capture is each control signal sent or received by the gNB, along with a condensed version of the TLS client hello messages. Column ’Qty’ details how many duplicate consecutive packets were sent. For example, during the first TLS handshakes of the UE connection, the AMF sends 3 separate requests to the NRF. This figure is helpful in that it quantifies how many TLS handshakes occur during an attachment and also provides more insight into the duration of each handshake.

Further information on the time it takes to complete a transaction is illustrated in Figure 10. The differences in handshake time between p521_kyber1024 and plain kyber1024 demonstrate that the additional latency shown in Figure 9 is indeed attributable solely to the TLSv1.3 handshake process, which includes the KEM.

Burst connections of multiple UEs simultaneously are part of our future work, where the focus is on the scalability of both the 5G Core provided by free5Gc and also of the 5G Core VNFs’ communications using PQC KEMs. With the understanding that Massive Machine-Type Communications (mMTC) could potentially need to support 1 million devices per km², situations in which devices are connecting and disconnecting quickly could have a real impact on performance in the CN with PQC enabled [48]. Kyber1024 has nearly 400KB or 3.2Mb more data transferred during a single UE connection, and in the extreme case of 1 million devices connecting, 400GB or 3.2Tb of data would be transferred in this scenario. Therefore, the systems employed for CN operations would need to withstand these connection bursts, with adequate load balancing and compute resources. Scalability is of particular focus also in commercial deployments, where the concern is not about adequate resource availability but about the cost for those resources, thereby driving the need for efficiency.

7. Conclusions

5G continues its worldwide rollout, allowing millions of people worldwide access to high-speed cellular service. At the same time, the need for customer data privacy protections and strong operational cybersecurity is rapidly increasing due to the growing sophistication and reach of cyberattacks in recent years. As such, we need to protect all aspects of today’s technology systems, especially 5G cellular services and their importance to our modern information society. We also need to be looking ahead at the cybersecurity requirements for the upcoming 6G and beyond. Future work in this area can expand upon the tests presented in this paper, with further testing using physical UEs, different channel bandwidths, testing with commercial grade equipment, and expanding PQC to end-to-end communication channels. Utilizing physical UEs with differing channel bandwidths may provide interesting insight into the device implementation differences between different devices, which may be resource-constrained.

With the rising possibility of usable quantum computers in the near future and the threats of SNDL attacks, 5G and 6G must adapt PQC in order to keep customer data quantum-safe. The research we present in this paper demonstrates that the modifications we conducted to integrate PQC into free5GC resulted in only a negligible latency impact and a minimal increase in data transfer volume during the UE connection phase to the 5G network from the inclusion of certain PQC or Hybrid PQC KEMs. These positive test outcomes were collected from capturing and analyzing a large number of 5G Core Network communications utilizing TLS v1.3 with PQC KEMs during numerous UE attachments using a variety of different KEMs. The results indicate that standalone Kyber KEMs can actually outperform the traditional ECC x25519 KEM in terms of the UE client connection duration tests. Thus, we can conclude that without any UE latency impact, we can achieve a significantly strengthened cybersecurity posture for the entire 5G Core Network. With these modifications, every API call between VNFs is not only AES-256 protected, which is currently considered quantum-safe, but we also achieved strong protections for the key exchange during the TLS handshaking for quantum safety. Thus, based on our tests, we anticipate similarly encouraging results regarding the latency and bandwidth impact of introducing PQC into TLS connections for all control plane and user plane operations in 5G and beyond. Our future work encompasses significant steps in that direction, with efforts already underway to secure RAN communications, Multi-Access Edge Communications in 5G, and end-to-end user data protections for 5G UEs.