Mitigating Security Vulnerabilities in 6G Networks: A Comprehensive Analysis of the DMRN Protocol Using SVO Logic and ProVerif

Abstract

The rapid evolution of mobile and optical communication technologies is driving the transition from 5G to 6G networks. This transition inevitably brings about changes in authentication scenarios, as new security demands emerge that go beyond the capabilities of existing frameworks. Therefore, it is necessary to address these evolving requirements and the associated key challenges: ensuring Perfect Forward Secrecy (PFS) to protect communications even if long-term keys are compromised and integrating Post-Quantum Cryptography (PQC) techniques to defend against the threats posed by quantum computing. These are essential for both radio and optical communications, which are foundational elements of future 6G infrastructures. The DMRN Protocol, introduced in 2022, represents a major advancement by offering both PFS and PQC while maintaining compatibility with existing 3rd Generation Partnership Project (3GPP) standards. Given the looming quantum-era challenges, it is imperative to analyze the protocol’s security architecture through formal verification. Accordingly, we formally analyze the DMRN Protocol using SVO logic and ProVerif to assess its effectiveness in mitigating attack vectors, such as malicious or compromised serving networks (SNs) and home network (HN) masquerading. Our research found that the DMRN Protocol has vulnerabilities in key areas such as mutual authentication and key exchange. In light of these findings, our study provides critical insights into the design of secure and quantum-safe authentication protocols for the transition to 6G networks. Furthermore, by identifying the vulnerabilities in and discussing countermeasures to address the DMRN Protocol, this study lays the groundwork for the future standardization of secure 6G Authentication and Key Agreement protocols.

1. Introduction

1.1. Motivation

The rapid evolution of mobile network technologies has led to the widespread deployment of 5G Non-Standalone (NSA) architecture, with the industry progressing towards 5G Standalone (SA) and 6G networks. These next-generation mobile communications are expected to play a pivotal role in driving the Fourth Industrial Revolution and facilitating digital transformation across various sectors. As we advance toward more sophisticated network architectures, there is a growing demand to enhance the security protocols that underpin these systems. The 5G Authentication and Key Agreement (AKA) protocol [1], which is based on symmetric key cryptography and the standard for the 5G SA primary authentication, is facing increasing pressure for improvement. This pressure arises from two main factors:

• The advancement of network computing environments.
• The desire to extend authentication credentials to 5G convergence applications (5G cAPPs) beyond the initial authentication phase.

As a result, two critical security features have emerged in the context of 5G AKA. First, perfect forward secrecy (PFS) has been proposed to ensure that current communication sessions remain secure, even if long-term secret keys are compromised in the future. Second, quantum-safe cryptographic techniques, i.e., Post-Quantum Cryptography (PQC) techniques, are suggested to protect current cryptographic systems against potential threats posed by the advent of large-scale quantum computers. These features are essential for safeguarding against future security threats and providing long-term data protection. The importance of these features is evident in the ongoing standardization efforts for non-3GPP primary authentication protocols. For instance, extensions to the Extensible Authentication Protocol for Authentication and Key Agreement (EAP-AKA’) [2] are being developed, specifically EAP-AKA’-FS [3] for perfect forward secrecy and EAP-AKA’-PQC [4] for post-quantum cryptography support.

In this context, the DMRN Protocol [5] proposed by Damir et al. in 2022 represents a significant advancement. It is the first protocol to simultaneously offer both perfect forward secrecy and post-quantum cryptography support while maintaining compatibility with the 3GPP primary authentication protocol, 5G AKA. The innovative features of the DMRN Protocol are expected to have a substantial impact on future research, particularly in the development of 6G AKA protocol standards.

Given the potential influence of the DMRN Protocol on future mobile network security standards, a comprehensive security analysis is crucial. Therefore, this paper aims to provide an in-depth and thorough examination of the DMRN Protocol’s security properties using two rigorous formal verification techniques. By conducting a rigorous, multi-faceted, and systematic formal security analysis, we evaluate the protocol’s resistance to known attacks, identify potential vulnerabilities, and consider possible attack scenarios. Through this analysis, we aim to contribute valuable insights that will guide future research directions in mobile network security protocols. Our work not only serves to validate the security claims of the DMRN Protocol but also provides a foundation for further improvements and adaptations as we progress toward 6G and beyond.

Furthermore, as 6G networks are expected to integrate optical communication technologies for ultra-high-speed and low-latency data transmission, the security of optical networks becomes a critical concern [6]. Optical fiber communication systems, which form the backbone of modern telecommunications, offer immense bandwidth, energy efficiency, and immunity to electromagnetic interference. However, they are susceptible to unique security threats such as optical tapping, signal jamming, and side-channel attacks [7]. Given that quantum computing is expected to operate within such fiber-optic communication infrastructures, preparing for attacks leveraging quantum computing is of utmost importance. In this context, the integration of quantum-safe cryptographic techniques in security protocols is particularly relevant for securing optical networks, as quantum computers pose a significant threat to traditional encryption methods used in optical communications [4]. Consequently, the development of robust authentication and key agreement protocols that can protect both radio frequency and optical segments of 6G networks is crucial for ensuring end-to-end security in next-generation mobile communications, especially considering the increasing reliance on fiber-optic infrastructure for backhaul and fronthaul connections in 6G architectures [8].

1.2. Related Works

The 5G primary authentication standards include two key protocols: the 5G Authentication and Key Agreement (5G-AKA)—which supports 3GPP devices—and the Extensible Authentication Protocol (EAP)-AKA’—which is used for non-3GPP devices. A significant improvement over previous generations is the encryption of the SUPI (Subscription Permanent Identifier), addressing the issue of unencrypted IMSI (International Mobile Subscriber Identity) transmission by using an ECIES (Elliptic Curve Integrated Encryption Scheme) to compute and transmit the SUCI (Subscription Concealed Identifier). However, despite these advancements, both protocols remain vulnerable to various attacks, prompting the ongoing development of enhanced protocols to address these security challenges, as shown in Figure 1 [9,10,11].

Figure 1. The 5G authentication protocols.

The 5G-AKA’ [12] aimed to counteract linkability attacks by reusing the $K_{HN}$ key, which is negotiated between a User Equipment (UE) device and its corresponding Home Network (HN) through an ECIES, to encrypt the SUPI in the initial phase. In more detail, this protocol lets the HN replace its random number within the authentication token (AUTN) with the value encrypted from that random number with the $K_{HN}$. Based on the trust in the freshness of the $K_{HN}$, the UE can use the encrypted result to mitigate replay attacks, as well as linkability attacks. Nevertheless, the protocol remains vulnerable to active attacks from a malicious Serving Network (SN), as it allows the transmission of the anchor key $K_{SEAF}$ to the SN without authenticating the UE with the HN. Additionally, the protocol does not fully support security for PFS.

The SUCI-AKA protocol [13] was proposed to achieve PFS for the anchor key $K_{SEAF}$ and to prevent linkability attacks. It reuses the $K_{HN}$ key, which was originally generated through an ECIES to encrypt the SUPI for the calculation of the master session key $K_{AUSF}$. To explain further, because the $K_{HN}$ is trusted to be fresh by both the UE and the HN, it substitutes the sequence number, thereby defending against the linkability attacks. However, if the long-term key K and the HN’s private key $s{k}_{HN}$ are compromised, an attacker can recover the anchor key $K_{SEAF}$, thereby undermining the protocol’s PFS.

The 5G-IPAKA [14] was proposed to support mutual authentication between the UE and SN, secure key exchange, and PFS. It tried to provide PFS by computing the anchor key using the ECIES secret $K_{HN}$. This protocol allows the HN to send the anchor key $K_{SEAF}$ to the SN before finally authenticating the UE. In this way, both the UE and the SN are able to authenticate each other using the Message Authentication Code (MAC) generated and transmitted by the corresponding party with $K_{SEAF}$, thereby achieving mutual authentication between the two parties. However, if the long-term key K and the HN’s private key $s{k}_{HN}$ were to be compromised, the protocol would face issues with PFS. Additionally, since the HN can transmit the anchor key $K_{SEAF}$ to the SN without authenticating the UE, there is a threat of active attacks from malicious SNs. Furthermore, compatibility issues arise due to the protocol’s deviation from the standard procedure.

The 5GAKA-LCCO [15] focused on addressing the high communication and computation overhead and SUCI replay attacks. In this protocol, the SN first begins by sending the UE the current timestamp and randomly generated nonce values. Then, the UE applies the values to calculate the key block with the long-term key K and the ECIES secret key $k_{HN}$. Based on the generated key block, the protocol optimizes the communication and computation overhead. In addition, the timestamp can prevent the resource exhaustion attacks and SUCI replay attacks. However, during the computation of the master session key $K_{AUSF}$, the use of the long-term key K and the secret key $s{k}_{HN}$ introduces vulnerabilities concerning PFS in the event of key leakage. Additionally, the reliance on timestamps imposes a time synchronization burden, making it unsuitable for mobile communication environments such as roaming. Lastly, there may be compatibility issues arising from differences with the existing standards.

The 5G-AKA-FS [16] improved the key exchange process by generating ephemeral ECIES keys during communication, aiming to achieve PFS while maintaining compatibility with existing standards. Specially, it reuses the UE’s ECIES key pair generated to encrypt the SUPI so that the overall communication and computation overhead are reduced. Consequently, the proposed protocol not only provides strong security compared to the previously mentioned protocols but also excels in terms of compatibility and efficiency. However, it does not address the threat posed by quantum computing due to the lack of PQC application.

The WirelessPQCSim [17] addresses potential PQC real-world implementation issues by applying a hybrid PQC during the SUCI calculation process. Nonetheless, it faces compatibility challenges and does not achieve PFS, as it only focuses on the SUCI computation phase rather than the entire 5G authentication protocol.

The EAP-AKA’-FS was introduced to address the lack of PFS in the original EAP-AKA’. Although this protocol provides some improvements, it still does not account for PQC, leaving it vulnerable to quantum threats.

The EAP-AKA’-PQC is currently under standardization as a response to these quantum threats. This protocol adopts the X-wing algorithm [18], which is considered to be one of the most promising candidates for hybrid PQC. By doing so, it aims to mitigate potential real-world implementation challenges while addressing the quantum threat.

Table 1 explains a summarized comparison of the protocols discussed:

Table 1. Comparison in terms of security requirements with related works.

Protocol	MA	KE	SUPI	PFS	DmS	QS
5G-AKA’	◯	◯	◯	×	×	×
SUCI-AKA	◯	◯	◯	×	◯	×
5G-IPAKA	◯	◯	◯	×	×	×
5GAKA-LCCO	◯	◯	◯	×	◯	×
5G-AKA-FS	◯	◯	◯	◯	◯	×
WirelessPQCSim	-	-	◯	-	-	◯
DMRN	×	×	◯	◯	×	◯
EAP-AKA’-FS	◯	◯	◯	◯	◯	◯
EAP-AKA’-PQC	◯	◯	◯	◯	◯	◯

MA: Mutual Authentication; KE: Key Exchange; SUPI: SUPI Concealment; PFS: Perfect Forward Secrecy; DmS: Defense against malicious SNs; QS: Quantum-Safe; ◯: Satisfied; ×: Not satisfied; -: Unable to check.

1.3. Contributions

This paper presents a comprehensive and multi-faceted security analysis of the DMRN Protocol, which has been engineered to achieve both perfect forward secrecy and support for PQC in 6G Authentication and Key Agreement. Our primary contributions are outlined below:

• We conducted a comprehensive survey of nine existing protocols, including the DMRN Protocol, performing a comparative analysis based on six key criteria: mutual authentication, secure key exchange, SUPI protection, and other relevant factors.
• A rigorous security analysis of the DMRN Protocol was performed using two distinct formal verification tools: SVO logic and ProVerif. This multi-tool approach provides a more comprehensive and robust evaluation of the protocol’s security properties.
• In the ProVerif verification, we defined four scenarios, each of which was thoroughly and precisely explored to assess potential attack vectors.
• For the DMRN Protocol, we compared and analyzed the results from both SVO logic and ProVerif under four scenarios, using six criteria. Our findings revealed that, contrary to the authors’ claims, the DMRN Protocol is vulnerable to attacks by compromised or malicious SNs. Additionally, the protocol was found to be susceptible to HN masquerade attacks. Lastly, it was demonstrated that the DMRN Protocol does not completely support mutual authentication and secure key exchange.

Our multi-faceted approach to formal verification allows for a more comprehensive assessment of the DMRN Protocol’s security properties. By employing two representative tools in the areas of modal logic and model checking, each with its unique strengths and capabilities, we can examine the protocol from various perspectives, thereby increasing the likelihood of detecting subtle vulnerabilities that might be overlooked in a single-tool analysis. The vulnerabilities we have identified through this process have significant implications for the security of future 6G networks. They highlight potential weaknesses in key management, authentication processes, and resistance to specific attack vectors. These findings are crucial for researchers and standardization bodies working on the development of robust security protocols for next-generation mobile networks. Furthermore, our work emphasizes the importance of thorough and diverse verification methodologies in the development of security protocols. The multi-tool approach we have employed proves to be highly effective in providing a more complete picture of a protocol’s security landscape. This methodology can serve as a model for future security analyses of complex protocols, especially those intended for critical infrastructure such as 6G networks. By presenting these findings and demonstrating the effectiveness of our multi-faceted approach, we contribute valuable insights to the ongoing development and standardization efforts for 6G security protocols. Our work not only aids in enhancing the DMRN Protocol but also sets a precedent for rigorous security analysis in the field of next-generation mobile network security.

1.4. Paper Organization

The remainder of this paper is organized as follows:

• Section 3 provides a comprehensive review of the DMRN Protocol, including its notation, assumptions, and a detailed description of the protocol’s phases.
• Section 4 presents our multi-faceted analytical approach, detailing the two formal verification tools used in our analysis: SVO logic and ProVerif. This section also includes the security analysis conducted using each tool, presenting the results and findings from our rigorous examination of the DMRN Protocol.
• Section 5 discusses the implications of our findings from Section 4, including a comparative analysis of the results obtained from different verification tools. It also explores the potential vulnerabilities identified, followed by giving the countermeasures.
• Finally, the paper is concluded in Section 6, which summarizes the main contributions.

This paper provides a logical flow from the introduction of the protocol through our analytical methods and findings, to a comprehensive discussion of the results and their implications, concluding with a summary and discussion.

2. Materials and Methods

This paper was developed and refined with the assistance of OpenAI’s ChatGPT (version: GPT-4) [19]. ChatGPT is a large language model developed by OpenAI, having been designed to understand and generate human-like text using natural language processing technology. In this paper, ChatGPT was employed to draft the initial version, improve sentence structure, and enhance the overall clarity of the manuscript. All final decisions regarding the content were made by the authors.

3. Review of the DMRN Protocol

3.1. Notation

The explanation of symbols and terms used in the DMRN Protocol is shown in Table 2.

Table 2. Notations.

Notation	Meaning
AK	Anonymity Key
AKA	Authentication and Key Agreement
AUSF	Authentication Server Function
AUTN	AUthentication TokeN
CK	Cipher Key
HN	Home Network
HMAC	Hash-Based Message Authentication Code
HRES	Hash RESponse
HXRES	Hash eXpected RESponse
$I{D}_{SN}$	Identifier of Serving Network
IK	Integrity Key
K	A permanent key shared between UE and HN
$K_{AUSF}$	A master session key
$K_{SEAF}$	An anchor key
KDF	Key Derivation Function
MAC	Message Authentication Code
ME	Mobile Equipment
PFS	Perfect Forward Secrecy
$(p{k}_{HN},s{k}_{HN})$	HN’s KEM public–private key pair
PQC	Post-quantum cryptography
RES	RESponse
$R_{SN}$	256-bit Random Number
SEAF	SEcurity Anchor Function
SN	Serving Network
SUCI	SUbscriber Concealed Identifier
SUPI	SUbscription Permanent Identifier
UE	User Equipment
USIM	Universal Subscriber Identity Module
XRES	eXpected RESponse

3.2. Assumptions

3.2.1. Assumptions on Channels

The communication channel between the SN and the HN, as a component of the end-to-end core network, is expected to ensure confidentiality, integrity, and authenticity, as stated in [1].

In contrast, the communication channel between subscribers, i.e., UEs and SNs, is vulnerable to interception, injection, and manipulation by active attackers and eavesdropping by passive attackers. An active attacker can impersonate legitimate SNs to manipulate or compromise the system. A passive attacker focuses solely on gathering information from the communication channel by listening in on the data transmitted.

3.2.2. Assumptions on Cryptography Primitives

To ensure consistency with 3GPP standards, we followed the same notation used in [1]. In the DMRN Protocol, we used seven symmetric key algorithms labeled by $f_1$, $f_2$, $f_3$, $f_4$, $f_5$, $f_1^{*}$, and $f_5^{*}$. The functions $f_1$, $f_1^{*}$, and $f_2$ are responsible for message authentication, while $f_3$, $f_4$, $f_5$, and $f_5^{*}$ are employed for key derivation purposes.

3.2.3. Assumptions on Parties

This paper fundamentally adheres to the Dolev–Yao attacker model [20], where the adversary has full control over the network, allowing for interception, blocking, and modification of any transmitted message. However, without the necessary cryptographic keys or secrets, the adversary cannot decrypt ciphertext, forge digital signatures, or compromise message authentication codes.

3.3. Key Encapsulation Mechanisms (KEM)

A Key Encapsulation Mechanism (KEM) is a cryptographic protocol designed to securely establish a shared secret key between two communicating parties. This key can then be used for symmetric encryption, where both parties can encrypt and decrypt messages using the same key. A KEM consists of three algorithm parts (KeyGen(), Encaps(), Decaps()), where

• KeyGen(): Generates a (public) encapsulation key and a (private) decapsulation key ($p_k$, $s_k$) through a non-deterministic process.
• Encaps($p_k$): Utilizes the public encapsulation key (pk) to create a secret key k and corresponding ciphertext $c=Enc(p_k,k)$ via a non-deterministic algorithm.
• Decaps($s_k$, c): A deterministic key decapsulation algorithm that, given the private decapsulation key ($s_k$) and a ciphertext c, either returns a secret key k or fails, being denoted by returning ⊥.

3.4. Protocol Description

The DMRN Protocol, composed of three phases, is outlined in Figure 2, and the descriptions for each phase are as follows.

Figure 2. DMRN Protocol.

3.4.1. Phase A: The Identification Phase from UE to HN

(1)–(2) The Mobile Equipment (ME) begins the procedure by generating a KEM key pair, consisting of a public key $p{k}_U$ and a private key $s{k}_U$. Next, it generates a secret key $K_{S1}$ and a corresponding ciphertext $c_1$ by applying the encapsulation algorithm Encaps() to the input public key $p{k}_{HN}$. Then, the ME conceals the SUPI, $p{k}_U$, and $I{D}_{SN}$ through symmetric encryption utilizing the generated secret key $K_{S1}$. These encrypted data are denoted as $c_2$. The ME computes $c_3$ using the HMAC algorithm with the secret key $K_{S1}$ and ciphertext $c_2$. Finally, the UE transmits {SUCI, $I{D}_{HN}$} to the SN, where SUCI = $(c_1,c_2,c_3)$

3.4.2. Phase B: The Identification Phase from UE at HN

(3)–(5) Upon receiving {SUCI, $I{D}_{HN}$} from the UE, the SN generates a 256-bit random number $R_{SN}$ and subsequently forwards {SUCI, $R_{SN}$} to the HN. Once the HN receives the SUCI, the HN parses it into its constituent components: $c_1$, $c_2$, and $c_3$. Next, the HN proceeds to decapsulate $c_1$ with $s{k}_{HN}$ to derive the secret key $K_{S1}$. Using the derived secret key $K_{S1}$, the second component $c_2$ is decrypted to retrieve the SUPI, the public key $p{k}_U$, and the identifier $I{D}_{SN}$. In turn, the $MA{C}_U^{\prime }$ is computed using the HMAC algorithm with the derived secret key $K_{S1}$ and the ciphertext $c_2$. The result is then compared with the received $c_3$ while the $I{D}_{SN}$ is verified; the process is aborted if either this comparison fails or if the $I{D}_{SN}$ is invalid.

3.4.3. Phase C: The Authentication Phase

(6) Once the HMAC value $c_3$ is verified, the HN proceeds to retrieve the UE’s long-term key K associated with the received SUPI. Using the public key $p{k}_U$, the HN then employs the Encaps() algorithm to derive the secret key $K_{S2}$ and generate the ciphertext $c_4$. After obtaining the secret key $K_{S2}$, the HN computes AK ← $f_5(K,K_{S2})$, CONC ← $R_{SN}\oplus AK$, CK ← $f_3(K,K_{S2})$, and IK ← $f_4(K,K_{S2})$. In turn, it forms the AUTN by concatenating CONC and MAC. Furthermore, it computes the expected response XRES using a cryptographic function $f_2$, with K and $K_{S2}$ as inputs. Additionally, an enhanced expected response XRES* is calculated using a KDF that combines CK, IK, $K_{S2}$, XRES, and $I{D}_{SN}$. The HN also computes HXRES* by applying the SHA-256 hash function to $R_{SN}$ concatenated with XRES*. Afterwards, the key $K_{AUSF}$ is calculated using a KDF with CK, IK, $K_{S2}$, CONC, and $I{D}_{SN}$ as inputs. Subsequently, the key $K_{SEAF}$ is derived from $K_{AUSF}$ and $I{D}_{SN}$, followed by computing the key $K_3$ by XORing XRES* and the AK. Finally, the HN generates encrypted message M, which contains the concatenation of $K_{SEAF}$ and SUPI using the key $K_3$.

(7)–(8) The HN transmits {AUTN, HXRES*, M, $c_4$} to the SN in the secure channel. Then, the SN relays {AUTN, $c_4$} to the UE in the open channel.

(9)–(10) When obtaining the message from the SN, the ME derives the secret key $K_{S2}$ using the Decaps() algorithm with the stored secret key $s{k}_U$ and ciphertext $c_4$ as input, namely, $K_{S2}$ ← Decaps($s{k}_U,c_4$). Then, the ME parses the AUTN into the two values CONC and MAC, where CONC is derived from XORing $R_{SN}$ with AK, followed by computing AK ← $f_5(K,K_{S2})$ and recovering $R_{SN}$ through XORing AK with CONC. Next, UE verifies the MAC within the AUTN by checking if it matches the output cryptographic function $f_1$ applied to K, $K_{S2}$, and $R_{SN}$. If the check fails, the process is aborted. Otherwise, the UE continues to compute RES, CK, IK, and RES*. Finally, two session keys, $K_{AUSF}$ and $K_{SEAF}$, are derived for secure communication. Then, the UE forwards the RES* to the SN.

(11)–(12) Upon obtaining the RES* value from the UE, the SN proceeds to verify its integrity and authenticity. For that, it computes the hash using the SHA-256 algorithm on the concatenation of $R_{SN}$ and RES*. This generated hash is then compared against the HXRES* value provided by the HN to ensure consistency and validity. If the check fails, the process is aborted, indicating a failure in the authentication. Otherwise, the SN proceeds to the next step. In more detail, the SN parses the AUTN received earlier into its components: CONC and MAC. Using $R_{SN}$, the SN extracts the AK by XORing $R_{SN}$ with CONC. This step allows the SN to reverse the operation performed earlier by the HN to conceal $R_{SN}$. Next, the SN computes the key $K_3$ by XORing the extracted AK with the received RES*. After computing the key $K_3$, the SN uses it to decrypt the message M into the SUPI and the key anchor key $K_{SEAF}$, which will be used for securing further communication between the UE and the SN. Then, the SN forwards the RES* to the HN.

(13)–(14) Upon receiving the RES* (the UE’s response relayed through the SN), the HN verifies its authenticity by comparing it to the expected response XRES* that the HN had previously computed based on its knowledge of the cryptographic keys and the authentication parameters. If the check passes, confirming that XRES* equals RES*, the HN sends a confirmation message to the SN. This message informs the SN that the UE has been successfully authenticated and that the session keys and other security parameters are valid.

4. Formal Verification

In this section, we perform a systematic and comprehensive security analysis of the DMRN Protocol using formal verification. The verification process adheres to the ISO/IEC 29128-1:2023 standard [21], which facilitates the mathematical proof of correct operations in cryptographic protocols and the identification of potential vulnerabilities. The formal verification categoriztion is as shown in Figure 3, and we have adopted the most state-of-the-art techniques, ProVerif and SVO Logic, which use model checking techniques for verification. The reasons for this adoption, including the pros and cons of SVO Logic and ProVerif, are outlined in Table 3.

Figure 3. Formal verification categorization.

Table 3. Formal Verification technique comparison.

Formal Verification	Pros	Cons
SVO Logic	· Explicitness	· Ambiguity
	· Customizability	· Lack of Automation
	· Simplicity	· Limited Scalability
	· Formalized Expression	· User Expertise
	· Strong Theoretical Foundation	· Limited Real-World Support
ProVerif	· Automation	· False Positives
	· Scalability	· Complexity in Modeling
	· Expressiveness	· No Support for Explicit Time and Probability
	· Comprehensive Security Properties	· Undecidability in Certain Cases
	· Support for Various Attacker Models	· Lack of Exhaustive Checking
	· Rubust Verification support (Unbounded)	· User Expertise

4.1. Formal Verification Using SVO Logic

In this section, we verify the DMRN Protocol using SVO logic [22], which is one of the widely used methods in the formal verification field. SVO logic is a powerful tool for the verification of authentication protocols, and it was developed by Syverson and van Oorschot in 1994. It integrates the strengths of several existing logics, such as BAN logic [23], GNY logic [24], AT logic [25], and VO logic [26], to overcome their limitations and address the complex logical challenges posed by various authentication protocols. SVO logic offers enhanced expressiveness by integrating the strengths of various authentication logic. This allows it to formalize the diverse properties of authentication protocols and logically express complex concepts such as the verification of secret ownership. SVO logic aims to build a more consistent model by leveraging the extensibility and expressiveness provided by the existing BAN-like logic. SVO logic is designed in a traditional axiomatic style, enabling rigorous evaluation of the assumptions underlying authentication protocols. SVO logic maintains consistency with its model while offering the expressiveness needed to handle various protocols. This capability facilitates the logical verification of diverse properties of authentication protocols and eases integration with automated verification tools. Furthermore, SVO logic provides the flexibility to be applied to a wide range of protocols, assisting researchers in designing and verifying new protocols. The notations and axioms of SVO logic used in this paper are shown in Table 4 and Table 5.

Table 4. Notation of SVO Logic.

Notation	Meaning
$P|\equiv X$	P believes the message X
$P◂X$	P has the information X
$P⊲X$	P receives the message X
$P|\sim X$	P previously sent the message X
$P|\approx X$	P sent the message X in the present
$P|\Rightarrow X$	P has authority over X
$\#\left(X\right)$	The message X is fresh
${⟨X⟩}_K$	X is combined with a secret K
${\left\{X\right\}}_K$	X is encrypted with a key K
$\stackrel{K}{\mapsto }P$	X is the public key of P
$P\stackrel{K}{\leftrightarrow }Q$	X is a secret key shared between P and Q
$P\stackrel{K}{\iff }Q$	X is a shared secret between P and Q

Table 5. Axiom of SVO logic.

Axiom	Formula
Belief Axioms (BAs)	$P|\equiv \varphi \wedge P|\equiv (\varphi \supset \psi )\to P|\equiv \psi$
	$P|\equiv \varphi \to \varphi$
Source Association Axioms (SAAs)	$(P\stackrel{K}{\leftrightarrow }Q\wedge P⊲{\left\{X\right\}}_K)\to Q|\sim X$
	$(P◂\stackrel{S{K}_Q}{\mapsto }Q\wedge P⊲{\left\{X\right\}}_{S{K}_Q})\to$
	$P|\equiv Q|\sim X$
Receiving Axioms (RAs)	$P⊲(X_1,\dots ,X_n)\to P⊲X_i$
	$(P⊲{\left\{X\right\}}_K\wedge P◂K)\to P⊲X$
Saying Axioms (SAs)	$\#\left(X_i\right)\to \#(X_1,\dots ,X_n)$
	$\#(X_1,\dots ,X_n)\to \#\left(F(X_1,\dots ,X_n)\right)$
Jurisdiction Axiom (JR)	$\left(P\right|\Rightarrow \varphi \wedge P|\approx \varphi )\to \varphi$
Nonce Verification Axiom (NV)	$(\#(X)\wedge P|\sim X)\to P|\approx X$

The verification process in SVO logic begins with the initial state assumption, where the initial conditions of the protocol are established. Then, the protocol messages are processed through annotation, comprehension, and interpretation, allowing for the logical representation of the protocol’s actions. Following this, the protocol’s goals are defined, and derivation is performed according to the SVO rules. If the derivation is successful, the protocol is considered Secure; otherwise, it is marked as Insecure. In cases of insecurity, hypotheses are added iteratively until the protocol reaches a secure state. Figure 4 illustrates the inference step of SVO logic.

Figure 4. Inference step of SVO logic.

Here, we verify the DMRN Protocol as follows:

Initial state assumptions:

(A1) $HN◂\stackrel{P{K}_{HN}}{\mapsto }HN$

(A2) $HN|\equiv UE|\Rightarrow UE\stackrel{K_{S1}}{\leftrightarrow }HN$

(A3) $UE◂\stackrel{P{K}_U}{\mapsto }UE$

(A4) $UE|\equiv HN|\Rightarrow UE\stackrel{K_{S2}}{\leftrightarrow }HN$

(A5) $UE◂UE\stackrel{K}{\leftrightarrow }HN$

(A6) $SN◂UE\stackrel{R_{S\mathrm{N}}}{\iff }SN$

(A7) $SN|\equiv \#(UE\stackrel{R_{S\mathrm{N}}}{\iff }SN)$

(A8) $SN◂UE\stackrel{A\mathrm{K}}{\leftrightarrow }HN$

(A9) $SN|\equiv \#(UE\stackrel{K_{SEAF}}{\leftrightarrow }HN)$

(A10) $HN◂UE\stackrel{\mathrm{K}}{\leftrightarrow }HN$

(A11) $HN|\equiv \#(UE\stackrel{K_{S2}}{\leftrightarrow }HN)$

Goals:

(G1) $HN|\equiv UE\stackrel{K_{S1}}{\leftrightarrow }HN$

(G2) $HN|\equiv UE|\approx SUPI$

(G3) $HN|\equiv UE|\approx UE\stackrel{K_{S1}}{\leftrightarrow }HN$

(G4) $UE|\equiv HN|\approx UE\stackrel{K_{S2}}{\leftrightarrow }HN$

(G5) $UE|\equiv UE\stackrel{K_{S2}}{\leftrightarrow }HN$

(G7) $SN|\equiv UE|\approx RES*$

(G8) $HN|\equiv UE|\approx UE\stackrel{K_{S2}}{\leftrightarrow }HN$

Hypothesis:

(H1) $HN|\equiv \#(UE\stackrel{K_{S1}}{\leftrightarrow }HN)$

(H2) $UE|\equiv \#(UE\stackrel{K_{S2}}{\leftrightarrow }HN)$

Annotation:

(N1) $HN⊲{\left\{K_{S1}\right\}}_{P{K}_{HN}},{⟨SUPI,P{K}_U,I{D}_{SN},K_{S1}⟩}_{K_{S1}}$

(N2) $UE⊲{\left\{K_{S2}\right\}}_{P{K}_U},{⟨K_{S2},R_{SN}⟩}_K$

(N3) $SN⊲{⟨RES*,R_{SN}⟩}_{R_{SN}}$

(N4) $HN⊲{⟨K_{S2}⟩}_K$

Comprehension:

(C1) $HN|\equiv HN⊲{\left\{K_{S1}\right\}}_{P{K}_{HN}},{⟨SUPI,P{K}_U,I{D}_{SN},K_{S1}⟩}_{K_{S1}}$

(C2) $UE|\equiv UE⊲{\left\{K_{S2}\right\}}_{P{K}_U},{⟨K_{S2},R_{SN}⟩}_K$

(C3) $SN|\equiv SN⊲{⟨RES*,R_{SN}⟩}_{R_{SN}},{\{K_{SEAF},SUPI\}}_{K3}$

(C4) $HN|\equiv HN⊲{⟨K_{S2}⟩}_K$

Interpretation:

(P1) $HN|\equiv HN⊲{\left\{K_{S1}\right\}}_{P{K}_{HN}},{⟨SUPI,P{K}_{UE},I{D}_{SN},K_{S1}⟩}_{K_{S1}}\to$

$\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}HN|\equiv HN⊲{\left\{UE\stackrel{K_{S1}}{\leftrightarrow }HN\right\}}_{P{K}_{HN}},{⟨SUPI,\stackrel{P{K}_{UE}}{\mapsto }UE,I{D}_{SN},UE\stackrel{K_{S1}}{\leftrightarrow }HN⟩}_{K_{S1}}$

(P2) $UE|\equiv UE⊲{\left\{K_{S2}\right\}}_{P{K}_U},{⟨K_{S2},R_{SN}⟩}_K\to$

$\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}UE|\equiv UE⊲{\left\{UE\stackrel{K_{S2}}{\leftrightarrow }HN\right\}}_{P{K}_U},{⟨UE\stackrel{K_{S2}}{\leftrightarrow }HN,UE\stackrel{R_{SN}}{\iff }SN⟩}_K$

(P3) $SN|\equiv SN⊲{⟨RES*,R_{SN}⟩}_{R_{SN}},{\{K_{SEAF},SUPI\}}_{K3}\to$

$\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}\hspace{1em}SN|\equiv SN⊲{⟨RES*fromUE,UE\stackrel{R_{SN}}{\iff }SN⟩}_{R_{SN}},{\{UE\stackrel{K_{SEAF}}{\leftrightarrow }HN,SUPI\}}_{K3}$

(P4) $HN|\equiv HN⊲{⟨K_{S2}⟩}_K\to$ $HN|\equiv HN⊲{⟨UE\stackrel{K_{S2}}{\leftrightarrow }HN⟩}_K$

Derivation:

(D1) $HN|\equiv HN⊲{\left\{UE\stackrel{K_{S2}}{\leftrightarrow }HNfromUE\right\}}_{P{K}_{HN}}$,

$\hspace{1em}\hspace{1em}\hspace{1em}{⟨SUPI,\stackrel{P{K}_{UE}}{\mapsto }UE,I{D}_{SN},UE\stackrel{K_{S1}}{\leftrightarrow }HN⟩}_{K_{S1}}$ by Modus Ponens using (C1), (P1)

(D2) $HN|\equiv HN⊲{\left\{UE\stackrel{K_{S1}}{\leftrightarrow }HNfromUE\right\}}_{P{K}_{HN}}$

                            by (D1), RA, BA

(D3) $HN|\equiv UE|\sim UE\stackrel{K_{S1}}{\leftrightarrow }HN$

                          by (D2), (A1), RA, BA

(D4) $HN|\equiv UE|\approx UE\stackrel{K_{S1}}{\leftrightarrow }HN$

                          by (D3), (H1), NV, BA

(D5) $HN|\equiv UE\stackrel{K_{S1}}{\leftrightarrow }HN$

                           by (D4), (A2), JR, BA

(D6) $HN|\equiv HN⊲{⟨SUPI,\stackrel{P{K}_{UE}}{\mapsto }UE,I{D}_{SN},UE\stackrel{K_{S1}}{\leftrightarrow }HN⟩}_{K_{S1}}$

                            by (D1), RA, BA

(D7) $HN|\equiv UE|\sim (SUPI,\stackrel{P{K}_{UE}}{\mapsto }UE,I{D}_{SN},UE\stackrel{K_{S1}}{\leftrightarrow }HN)$

                         by (D6), (D5), SAA, BA

(D8) $HN|\equiv UE|\approx (SUPI,\stackrel{P{K}_{UE}}{\mapsto }UE,I{D}_{SN},UE\stackrel{K_{S1}}{\leftrightarrow }HN)$

                        by (D7), (H1), FR, NV, BA

(D9) $HN|\equiv UE|\approx SUPI$

                            by (D8), SA, BA

Strictly speaking, both of the $HN$’s beliefs (D3) and (D7) cannot be further developed due to the lack of freshness in the received message P. Thus, to proceed with the derivation, hypothesis (H1) is required to enable the HN to trust that the message was sent by the $UE$. The (H1) is defined as $HN|\equiv \#(K_{S1})$, which cannot be considered an assumption because the $HN$ is unable to assess the freshness of $K_{S1}$ in typical scenarios. Consequently, the $HN$ cannot fully trust the message received in (P1).

(D10) $UE|\equiv UE⊲{\left\{UE\stackrel{K_{S2}}{\leftrightarrow }HNfromHN\right\}}_{P{K}_U},{⟨UE\stackrel{K_{S2}}{\leftrightarrow }HN,UE\stackrel{R_{SN}}{\iff }SN⟩}_K$

                      by Modus Ponens using (C2), (P2)

(D11) $UE|\equiv UE⊲{\left\{UE\stackrel{K_{S2}}{\leftrightarrow }HNfromHN\right\}}_{P{K}_U}$

                             by (D10), RA, BA

(D12) $UE|\equiv HN|\sim UE\stackrel{K_{S2}}{\leftrightarrow }HN$

                          by (D11), (A3), RA, BA

(D13) $UE|\equiv HN|\approx UE\stackrel{K_{S2}}{\leftrightarrow }HN$

                          by (D12), (H2), NV, BA

(D14) $UE|\equiv UE\stackrel{K_{S2}}{\leftrightarrow }HN$

                           by (D13), (A4), JR, BA

(D15) $UE|\equiv UE⊲{⟨UE\stackrel{K_{S2}}{\leftrightarrow }HN,UE\stackrel{R_{SN}}{\iff }SN⟩}_K$

                            by (D10), RA, BA

(D16) $UE|\equiv HN|\sim (UE\stackrel{K_{S2}}{\leftrightarrow }HN,UE\stackrel{R_{SN}}{\iff }SN)$

                         by (D15), (A5), SAA, BA

(D17) $UE|\equiv HN|\approx (UE\stackrel{K_{S2}}{\leftrightarrow }HN,UE\stackrel{R_{SN}}{\iff }SN)$

                        by (D16), (H2), FR, NV, BA

In the above derivation, (D12) and (D16) cannot be further evolved because the received $c_2$ and MAC values cannot assure freshness to the $UE$. This clearly demonstrates a security threat, as leakage of these values could result in severe attacks through their reuse. To address this, we incorporated (H2) and proceeded with the derivation.

(D18) $SN|\equiv SN⊲{⟨RES*fromUE,UE\stackrel{R_{SN}}{\iff }SN⟩}_{R_{SN}},{\{K_{SEAF},SUPI\}}_{K3}$

                     by Modus Ponens using (C3), (P3)

(D19) $SN|\equiv UE|\sim (RES*,UE\stackrel{R_{SN}}{\iff }SN)$

                          by (D18), (A6), RA, BA

(D20) $SN|\equiv UE|\approx (RES*,UE\stackrel{R_{SN}}{\iff }SN)$

                        by (D19), (A7), FR, NV, BA

(D21) $SN|\equiv UE|\approx RES*$

                            by (D20), SA, BA

(D22) $SN◂K3$

                           by (D21), (A8), BA

(D23) $SN|\equiv SN⊲{\{K_{SEAF},SUPI\}}_{K3}$

                            by (D18), RA, BA

(D24) $SN|\equiv HN|\sim (K_{SEAF},SUPI)$

                        by (D23), (D22), SAA, BA

(D25) $SN|\equiv HN|\approx (K_{SEAF},SUPI)$

                       by (D24), (A9), FR, NV, BA

Upon reaching (D21), the $SN$ successfully obtains the belief that the $UE$ is valid based on the $RES*$. With this belief, it uses the received $RES*$ to recover the $UE$’s anchor key and identifier, $K_{SEAF}$ and $SUPI$, respectively, allowing it to proceed with subsequent security setup procedures with the $UE$. Simultaneously, the $SN$ forwards the $RES*$ to the $HN$.

(D26) $HN|\equiv HN⊲{⟨UE\stackrel{K_{S2}}{\leftrightarrow }HN⟩}_K$

                     by Modus Ponens using (C4), (P4)

(D27) $HN|\equiv UE|\sim UE\stackrel{K_{S2}}{\leftrightarrow }HN$

                           by (D26), (A10), SAA

(D28) $HN|\equiv UE|\approx UE\stackrel{K_{S2}}{\leftrightarrow }HN$

                         by (D27), (A11), FR, NV

Finally, based on belief (D28), the $HN$ not only authenticates the UE through the K, but it also ensures that the $UE$ holds a belief in the $K_{S2}$.

Based on the SVO logic verification results presented above, the DMRN Protocol has revealed several critical security vulnerabilities, which can be explained via hypotheses (H1) and (H2) as follows:

• The (H1) shows that the DMRN Protocol is vulnerable to security threats such as replay attacks due to the lack of timeliness in the $SUCI$ value. Consequently, it is desirable to provide timeliness to the $K_{S1}$ so that the $HN$ can verify the timeliness of $C1$ and $C2$.
• In the case of (H2), the $UE$ faces the following issues due to its inability to ensure the timeliness of the $K_{S2}$. First, the $UE$ is unable to authenticate the $HN$ based on the MAC value within the AUTN sent by the $HN$. Second, the $UE$ cannot place sufficient trust in the master session key, anchor key, or any subsequent session keys derived from the two keys K and $K_{S2}$. Although the DMRN Protocol attempts to address these security threats by encrypting the $K_{S2}$ with the $UE$’s ephemeral public key $p_U$, this is necessary to fundamentally resolve this issue.

4.2. Formal Verification by Model Checking

In this subsection, we conduct protocol verification using the model checking tool ProVerif [27]. ProVerif supports robust verification at the ‘unbounded’ level. The structure of ProVerif is as shown in Figure 5. ProVerif stands out as a state-of-the-art tool, offering advanced verification capabilities and scalability. Consequently, this section provides a detailed account of the verification process using ProVerif. Detailed models for ProVerif are publicly available on GitHub (The full ProVerif models can be accessed at https://github.com/yonghoko/ProVerif/tree/main/ (accessed on 16 August 2024) Mitigating Security Vulnerabilities in 6G Networks: A Comprehensive Analysis of the DMRN Protocol Using SVO Logic and ProVerif for further review and replication.

Figure 5. ProVerif structure.

4.3. Verification Scenarios Based on Adversary’s Capabilities

For the formal security verification, we consider the following different scenarios to establish robust and granular security assurances:

(S1) 

We performed a vulnerability assessment of the general protocol operation, considering the lowest level of the adversary’s capabilities. Through this assessment, we verified the fundamental security requirements of mutual authentication and key exchange.

(S2) 

We considered, at some point, that the adversary successfully managed to inject his or her public key into the UE as the HN’s public key and acquired the UE’s AUTN and its corresponding keys $K_{S2}$ and $K_{SEAF}$. Afterwards, the adversary tried to repeatedly launch HN masquerade attacks.

(S3) 

We considered the attack by the compromised or malicious SN. This means the adversary can inject malicious code into the SN and execute it at some point, allowing it to eavesdrop while monitoring the UE’s authentication process and messages. This is a plausible assumption in 5G/6G networks, where authentication mechanisms are expected to offer security assurances—even in the presence of legitimate yet potentially malicious SNs.

(S4) 

For the PFS test, we simulated a scenario where the adversary obtains the long-term secrets K and $s{k}_{HN}$ from a compromised HN or UE. PFS then verified whether confidentiality could be satisfied in message encryption using the final anchor key.

All of the above scenarios will be applied in the formal security verification in the remainder of this section. Note that the (S2)–(S4) scenarios can occur in non-public or private 5G networks, where the core network is managed by a small number of individuals, and many Internet of Things (IoT) devices function as UEs.

4.4. ProVerif

The modeling in ProVerif is structured into three stages—declaration, process macro, and main process—as shown in Figure 6. As illustrated in Algorithm A1, we begin by declaring the types, constants, variables, channels, and security verification queries essential for protocol analysis. Next, we modularly model the UE, SN, and HN as process macros in Algorithms A2–A4, respectively, enabling systematic and reusable representations of these entities.

Figure 6. DMRN ProVerif architecture.

The main process, detailed in Algorithms A5 and A6, handles crucial operations such as cryptographic key generation and the invocation of subprocesses. The Algorithm A5 addresses the scenario where long-term keys remain uncompromised, while the Algorithm A6 evaluates the preservation of PFS by allowing the compromise of long-term keys (i.e., in the case of S4). The DRMN flowchart diagram is shown in Figure 7. Our verification focuses on essential security requirements, including mutual authentication, key exchange, SUPI concealment, defense against compromised or malicious SN, and PFS. For each of these requirements, we define specific queries, as outlined in Table 6, to target and effectively analyze the protocol’s security requirements.

Figure 7. DMRN flowchart diagram.

Table 6. Security requirements verification query.

Security Requirment	Verification Query
Mutual Authentication	Q5: Inj-event(UERecResSN)) ==>
	(inj-event(SNRecResHN) ==>
	inj-event(HNSendResSN)
	&&
	Q6: Inj-event(HNRecConSN) ==>
	(inj-event(SNRecConUE) ==>
	inj-event(UESendConSN))
Secure Key Exchange	Q1: query attacker (kseafUE)
	&&
	Q2: query attacker (kseafSN)
	&&
	Q3: query attacker (kseafHN)
SUPI Concealment	Q0: query attacker (SUPI)
	&&
	Q4: Inj-event(HNRecReqSN) ==>
	(inj-event(SNSendReqHN) ==>
	inj-event(UESendReqSN))
Defense against	Q7: inj-event(SNKeyObtn) ==>
Compromised or Malicious	(inj-event(HNRecConSN) ==>
Serving Network (SN)	inj-event(UESendConSN))
Perfect Forward Secrecy	“phase 1; out(usch, (skHN, k)” in process
Quantum-Safe	Not Available

4.4.1. Queries

Note that the ‘inj-event’ function was applied to ensure strong verification at each communication step, thus confirming authentication and freshness. For mutual authentication, the queries Q5 and Q6 were modeled and tested, evaluating the message freshness and authentication. The security of the key exchange was confirmed through the queries Q1, Q2, and Q3, ensuring that the key exchange process would be completed securely without unauthorized access by an attacker. Additionally, the queries Q0 and Q4 were employed to verify if an attacker could access the SUPI and if the HN correctly authenticated the SUCI value, thereby successfully validating the concealment of the SUPI. Furthermore, the query Q7 was used to assess issues related to defense against potential vulnerabilities caused by compromised or malicious SNs. Finally, the ‘phase’ function in the main process was employed to determine whether PFS held. In this context, Proverif intentionally exposes the secrets, $s{k}_{HN}$ and K, to the public in phase 1 following phase 0 (i.e., S4).

4.4.2. Verification Results

Figure A1–Figure A4 show the verification results of the DMRN Protocol, and the results are summarized in Table 7.

Table 7. Attacker scenario result summary.

Attacker Scenario	Result
S1: General attacker capability	True
S2: MAC freshness issue	False
S3: Attacks by compromised or malicious SN	False
S4: PFS unsupported issue	True

(S1) 

General attacker capability:

Figure A1 and Figure A5 present the results based on scenario (S1), which assumes the lowest level of adversarial capability. Specifically, the verification focused on the confidentiality of the SUPI and anchor key, as well as the authentication and freshness of the two values MAC and RES*. Consequently, it has been confirmed that SUPI concealment, confidentiality of the anchor key, mutual authentication, and secure key exchange have been successfully achieved.

(S2) 

MAC freshness issue:

In (S2), we tested if there was any attack caused by the lack of freshness of the MAC values included in the AUTN. As depicted in Figure A2 and Figure A6, an adversary can reuse the captured MAC value to spoof the core network and launch subsequent attacks. Note that such attacks are possible only if the adversary’s public key is injected as the HN’s public key or if the HN’s private key is stolen.

(S3) 

Attacks by compromised or malicious SN:

Although the authors of the DMRN Protocol claim to guarantee defense against compromised or malicious SNs, verification through Q7 demonstrates that it is still vulnerable to such threats, as shown in Figure A3 and Figure A7. In more detail, by eavesdropping the RES*, an adversary (e.g., a malware installed in the compromised SN) who somehow managed to obtain the two values CONC and $R_{SN}$ can recover earlier the victim UE’s SUPI and $K_{SEAF}$ prior to the HN’s final verification of that RES*.

(S4) 

PFS unsupported issue:

To ensure PFS, ProVerif reveals the long-term secrets $s{k}_{HN}$ and K at phase 1 following phase 0. As a result, shown in Figure A4, it has been confirmed that the anchor key $K_{SEAF}$ remained uncompromised despite the leakage of long-term secrets (i.e., PFS holds). Moreover, mutual authentication and secure key exchange through the queries Q1, Q2, Q3, Q5, and Q6 were verified to be satisfactory. On the other hand, in such a situation, secrecy cannot be fully satisfied for the SUPI, leading to privacy issues. Since the SUPI is not a session key and does not derive subsession keys, this vulnerability cannot be reflected in terms of PFS. Therefore, we can conclude that the DMRN Protocol holds PFS.

5. Discussion and Countermeasures

5.1. Discussion

This section mainly evaluates the security requirements for the DMRN protocol, i.e., mutual authentication, secure key exchange, SUPI concealment, PFS, defense against attack by compromised or malicious SN, and quantum-safe.

5.1.1. Mutual Authentication

The DMRN Protocol is not significantly different from the 5G AKA in terms of mutual authentication. Specifically, in the mutual authentication between the UE and the HN, the UE authenticates the HN through the MAC value within the AUTN provided by the HN, and the HN authenticates the UE through the RES* value presented by the UE. More importantly, the two values, MAC and RES*, used for authentication are enhanced by the PQC-powered and PFS-enabled key $K_{S2}$, and the sequential number SEQ is not used. In this way, the protocol aims to strengthen security compared to the 5G AKA. However, since the SEQ is not used, the UE cannot verify the freshness of the MAC value, as described based on (H2) during the SVO logic verification. To address this issue, the DMRN Protocol has the HN encrypt for the $K_{S2}$ with the UE’s ephemeral PQC public key $p{k}_U$, thereby imparting the timeliness of $p{k}_U$ to the encrypted result. According to the results of the scenarios (S1) and (S4) in the ProVerif verification, it has been shown that such an enhancement allows the DMRN Protocol to achieve authentication between the UE and the HN in both the general and PFS test cases. Nevertheless, the MAC value lacking timeliness still poses a security threat and can be exploited for the HN masquerade attacks. This threat was demonstrated in Figure A2 and Figure A6 through the ProVerif verification. Meanwhile, in the authentication between the UE and the SN, the SN was not authenticated by the UE, but the SN could authenticate the UE through the HXRES* value derived from the RES*.

5.1.2. Secure Key Exchange

The $K_{S1}$ is negotiated through the PQC KEM algorithm with the HN’s ECIES public key $p{k}_{HN}$. From the HN’s perspective, it cannot confirm whether $K_{S1}$ is fresh, because the key’s materials do not include any elements of freshness, as indicated by (H1) in the SVO logic verification. Consequently, the protocol is vulnerable to SUCI replay attacks. On the other hand, the master session key $K_{AUSF}$ and the anchor key $K_{SEAF}$ are derived from two keys, K and $K_{S2}$. Notably, since the freshness issue of $K_{S2}$ is addressed through $p{k}_U$, and it is negotiated using the PQC KEM algorithm in a way that preserves PFS, wherein a strong key exchange is achieved to protect session keys, ensuring the security of signaling messages and user traffic. In more detail, the ProVerif verification for the scenarios (S1) and (S4) shows that the $K_{S2}$ was securely exchanged and sound in both the general and PFS test cases. However, the verification for (S2) shows that the $K_{S2}$’s timeliness issue led to attacks, which has also been pointed out by (H2) in the SVO logic analysis. As a result, considering both the SVO logic and ProVerif results, we can conclude that while it provides feasible security in general scenarios such as (S1) and (S4), it remains vulnerable to sophisticated attacks due to unresolved vulnerabilities that have been theoretically pointed out.

5.1.3. SUPI Concealment

SUPI concealment refers to protecting the privacy of the user’s permanent identifier during the authentication process in a 5G network. The SUCI is a concealed version of the SUPI that is transmitted over the air to prevent the user’s identity from being exposed. Given the operations $(c_1,K_{S1})$ ← Encaps($p{k}_{HN}$), $c_2$ ← Enc($K_{S1}$, SUPI||$p{k}_U$||$I{D}_{SN}$), and $c_3$ ← HMAC($K_{S1}$, $c_2$), the SUCI is formed by concatenating $c_1$, $c_2$, and $c_3$. This process effectively conceals the SUPI, as demonstrated in the ProVerif verification for the general case (S1).

5.1.4. Perfect Forward Secrecy

PFS refers to a security property that ensures the confidentiality of past communication sessions, even if the long-term keys used in those sessions are compromised in the future. Note that in the DMRN protocol, there are two long-term keys, K and $s{k}_{HN}$. Thus, for PFS, we should check whether the past session keys, which were derived from the two long-term keys, remain secure in the event that those long-term keys are leaked in the future. With regard to these long-term keys, there is an important key exchange for the key $K_{S2}$, which is negotiated to derive the master session and anchor keys. The $K_{S2}$ is agreed through the UE’s ephemeral PQC public key $p{k}_U$, and since the corresponding private key $s{k}_U$ is immediately deleted after the protocol execution, there is no way to recover it in the future. In other words, PFS is preserved for the key $K_{S2}$ and the session keys derived from it. The above is shown from Figure A4 in the ProVerif verification for the PFS scenario (S4).

5.1.5. Defense Against Attack by Compromised or Malicious SNs

In addressing attacks by compromised or malicious SN, we assume that malicious code may be injected into the SN, allowing it to monitor and intercept the UE’s authentication messages. In the standard 5G AKA process, such malware could only access critical information like $K_{SEAF}$ and the SUPI after the HN completes the authentication and shares these values with the SN. However, in this protocol, the malware within the SN can obtain the $K_{SEAF}$ and SUPI immediately upon receiving the response $RES*$, giving the attacker earlier access to key information, thereby exposing the system to potential compromise sooner than in the standard 5G AKA.

5.1.6. Quantum-Safe

Quantum-safe security requirements are essential to protect cryptographic systems against the potential threats of quantum computers, which can break traditional algorithms like RSA and ECIES. KEM addresses these requirements by enabling secure key exchanges based on PQC techniques, which rely on hard mathematical problems believed to be resistant to quantum attacks.

5.2. Countermeasures

Table 1 summarizes the analysis of the DMRN Protocol and compares it with the existing protocols. Based on the comprehensive analysis and discussion of the DMRN Protocol, we propose the following countermeasures for designing a future PQC-enabled 6G AKA protocol:

• Implementation of anti-replay techniques: future PQC-enabled 6G AKA protocols should incorporate robust anti-replay mechanisms to counter SUCI replay attacks. This is crucial to prevent attackers from reusing previously captured SUCI values for unauthorized authentication attempts. Potential solutions include integrating timestamps or one-time nonce values into the SUCI generation process. As an alternative, the HN can manage the database for previously used SUCI values for a specified period (e.g., 1 years) from which a given SUCI value’s freshness can be quickly checked.
• Ensuring MAC freshness: The MAC generation process in the DMRN protocol should be improved to make the MAC value fresh. This can be achieved by integrating the UE’s ephemeral public key $p{k}_U$ into the MAC calculations. Such improvements would not only reduce the risk of replay attacks but also strengthen resistance against man-in-the-middle attacks.
• Addressing compromised or malicious SNs: To mitigate situations involving compromised or malicious SNs, the two values SUPI and $K_{SEAF}$ transmission process should be modified. Specifically, the protocol should be adjusted to ensure that the $K_{SEAF}$ is transmitted to the SN after the RES* is finally checked by the HN. This modification prevents malicious or compromised SNs from obtaining the anchor key without proper UE authentication.
• Adoption of hybrid PQC approach: While PQC approaches are essential for mitigating the threats posed by quantum computing, the current implementation status of PQC products raises reliability concerns. Therefore, we recommend adopting a hybrid PQC approach that integrates traditional cryptographic techniques with PQC methods. This balanced approach maintains current security levels while preparing for potential future threats from quantum computing.

By implementing these countermeasures, future 6G AKA protocols can overcome the vulnerabilities identified in the DMRN protocol and provide enhanced security. These improvements will contribute to elevating the overall security posture of 6G networks, ensuring robust protection against both current and emerging threats, including those posed by advancements in quantum computing.

6. Conclusions

In this paper, we conducted a comprehensive security analysis of the DMRN Protocol using two representative formal verification tools SVO logic and ProVerif. The analysis evaluated key security requirements, including mutual authentication, secure key exchange, SUPI concealment, PFS, defense against attacks by compromised or malicious SNs, and quantum-safe properties. The verification research demonstrated that the protocol remains vulnerable to the following attack vectors depending on the attacker’s capabilities. First, while the protocol enhances mutual authentication through PQC-powered and PFS-enabled keys, it faces challenges due to the lack of timeliness in the MAC value, making it vulnerable to HN masquerade attacks. Second, the key exchange mechanism leads to replay attacks on the SUPI and sophisticated attacks due to the non-freshness of the two keys, $K_{S1}$ and $K_{S2}$. Third, attacks by compromised SNs can expose critical information, such as $K_{SEAF}$, earlier than in the standard 5G AKA process. To address these issues, we proposed the following countermeasures: (i) implementing anti-replay mechanisms to prevent SUCI replay attacks; (ii) including the UE’s ephemeral public key in the generation process of $K_{S2}$ to ensure the freshness of $K_{S2}$, which is used for deriving the MAC value and important session keys; (iii) modifying the transmission of $K_{SEAF}$ to occur after UE authentication to mitigate risks from compromised SNs; and (iv) adopting a hybrid PQC approach that combines traditional cryptography with PQC methods to maintain reliability while preparing for quantum threats. By evaluating the security properties of the DMRN protocol from various perspectives, this research provides crucial insights into the design of authentication and key exchange protocols for next-generation 6G networks. The findings of this study will significantly contribute to the standardization process of secure protocols, guiding future protocol design and verification efforts. Additionally, since mobile communication networks and IoT devices are closely related, future research will focus on evaluating the performance of the improved DMRN protocol, particularly in scenarios where PQC algorithms are applied. This will include performance metrics such as overhead and latency.

Appendix A.1. Verification Algorithm of ProVerif

Algorithm A1 Declaration and Queries

(* Channel specification *)    free ch: channel.    free sch: channel [private].

(* Key Encapsulation Mechanism *)    fun Encaps(pubKey, bitstring): bitstring.    fun KEMkey(bitstring): bitstring.    fun KEMCipher(bitstring): bitstring.    fun DecapsKey(secKey, bitstring): bitstring.

(* Secrecy verification *)    Q0: query attacker (SUPI).    Q1: query attacker (kseafUE).    Q2: query attacker (kseafSN).    Q3: query attacker (kseafHN).

(* Security requirements verification *)    Q4: query mac: bitstring;          Inj-event(HNRecReqSN(mac)) ==> (inj-event(SNSendReqHN(mac))          ==> inj-event(UESendReqSN(mac))).    Q5: query mac: bitstring;          Inj-event(UERecResSN(mac)) ==> (inj-event(SNRecResHN(mac))          ==> inj-event(HNSendResSN(mac))).    Q6: query rstar: bitstring;          Inj-event(HNRecConSN(rstar)) ==> (inj-event(SNRecConUE(rstar))          ==> inj-event(UESendConSN(rstar))).    Q7: query rstar: bitstring, key: bitstring;          inj-event(SNKeyObtn(key)) ==> (inj-event(HNRecConSN(rstar))          ==> inj-event(UESendConSN(rstar))).

Algorithm A2 proc_UE

Played by: UE Input: SUPI, $i{d}_{H}N$, $p{k}_{HN}$, k, SNname

[Step 1.1]    new $rUE$;    let $Ks1$ = KEMkey(Encaps($p{k}_{HN}$, rUE)) in    let $c1$ = KEMCipher(Encaps($p{k}_{HN}$, rUE)) in    new $s{k}_{UE}$;    let $p{k}_{UE}$ = $pk\left(s{k}_{UE}\right)$ in    let USUCI = senc((SUPI, $p{k}_{UE}$, SNname), $Ks1$)in    let MAC1 = f1((USUCI, $Ks1$)) in    event UESendReqSN(MAC1);    out(usch,($c1$, USUCI, MAC1, idHN)); [Step 2.3]    in(usch, ($c4$, CONC, MAC2));    let Ks2 = DecapsKey($s{k}_{UE}$, $c4$) in    let rSN = xor(CONC, f5((k, $ks2$))) in    if MAC2 <> f1((k, $ks2$, rSN)) true then exit;    event UERecResSN(MAC2);    let RES = f2((k, $ks2$)) in    let CK = f3((k, $ks2$)) in    let IK = f4((k, $ks2$)) in    let RESstar = keyseed((CK, IK, $ks2$, RES, SNname)) in    let XRES = SHA((RESstar, rSN)) in    let $k_{AUSF}$ = keyseed((CK, IK, $ks2$, CONC, SNname)) in    let $k_{SEAF}$ = keyseed(($k_{AUSF}$, SNname)) in    event UESendConSN(RESstar);    out(usch, RESstar);    out(usch, senc(kseafUE, $k_{SEAF}$));

Algorithm A3 proc_SN

Played by: SN Input: SNname

[Step 1.2]    in(usch,($c1$, USUCI, MAC1, idHN));    new rSN;    new ssID;    event SNSendReqHN(MAC1);    out(sch,(ssID, c1, USUCI, MAC1, SNname, rSN)); [Step 2.2]    in(sch,(=ssID, $c4$, HXRES, M, CONC, MAC2));    event SNRecResHN(MAC2);    out(usch,($c4$, CONC, MAC2)); [Step 2.4]    in(usch, RESstar);    if sHXRES <> SHA((RESstar, rSN)) true then exit;    event SNRecConUE(RESstar);    let AK = xor(CONC, rSN) in    let $K3$ = xor(RESstar, sAK) in    let ($k_{SEAF}$, SUPI) = sdec(M, $K3$) in    event SNKeyObtn((kSEAF, SUPI));    out(sch,(sID, RESstar));    out(usch, senc(kseafSN, $k_{SEAF}$));

Algorithm A4 proc_HN

Played by: HN Input:k, $s{k}_{HN}$, idHN

[Step 1.3]    in(sch,(sID, c1, USUCI, MAC1, SNname, rSN));    let $ks1$ = DecapsKey($s{k}_{HN}$, c1) in    let (hSUPI, $hp{k}_{UE}$, hSNname) = sdec(USUCI, $ks1$) in    if hSNname <> hSNname’ true then exit;    if MAC1 <> f1((USUCI, $ks1$)) true then exit;    event HNRecReqSN(MAC1); [Step 2.1]    new rHN;    let $ks2$ = KEMkey(Encaps($hp{k}_{UE}$, rHN)) in    let $c4$ = KEMCipher(Encaps($hp{k}_{UE}$, rHN)) in    let MAC2 = f1((k, $ks2$, rSN)) in    let XRES = f2((k, $ks2$)) in    let CONC = xor(rSN, f5((k, $ks2$))) in    let CK = f3((k, $ks2$)) in    let IK = f4((k, $ks2$)) in    let XRESstar = keyseed((CK, IK, $ks2$, XRES, SNname)) in    let HXRES = SHA((XRESstar, rSN)) in    let $k_{AUSF}$ = keyseed((CK, IK, $ks2$, CONC, SNname)) in    let $k_{SEAF}$ = keyseed(($k_{AUSF}$, SNname)) in    let $K3$ = xor(XRESstar, f5((k, $ks2$))) in    let M = senc(($k_{SEAF}$, hSUPI), $K3$) in    event HNSendResSN(MAC2);    out(sch,(sID, $c4$, HXRES, M, CONC, MAC2));

[Step 2.5]    in(sch, (=sID, RESstar));    if XRESstar <> RESstar true then exit;    event HNRecConSN(RESstar);    out(usch, senc(kseafHN, $k_{SEAF}$));

Algorithm A5 Main Process without FS—(S1)

process    new idHN;    let $p{k}_{HN}$ = $pk\left(s{k}_{HN}\right)$ in

(!UE(SUPI, idHN, $p{k}_{HN}$, k, SNname) | !SN(SNname) | !HN(k, $s{k}_{HN}$, idHN)

Algorithm A6 Main Process with FS—(S2)

process    new idHN;    let $p{k}_{HN}$ = $pk\left(s{k}_{HN}\right)$ in

(!UE(SUPI, idHN, $p{k}_{HN}$, k, SNname) | !SN(SNname) | !HN(k, $s{k}_{HN}$, idHN)    | phase 1; out(usch, ($s{k}_{HN}$, k)))

Appendix A.2. Verification Results for Each Scenario

Figure A1. (S1) Verification result of ProVerif of DMRN Protocol.

Figure A2. (S2) Verification result of ProVerif.

Figure A3. (S3) Verification result of ProVerif.

Figure A4. (S4) Verification result of ProVerif of DMRN Protocol.

Appendix A.3. Attack Process for Each Scenario

Figure A5. (S1) attack process.

Figure A6. (S2) attack process.

Figure A7. (S3) attack process.