5G-AKA-FS: A 5G Authentication and Key Agreement Protocol for Forward Secrecy

5G acts as a highway enabling innovative digital transformation and the Fourth Industrial Revolution in our lives. It is undeniable that the success of such a paradigm shift hinges on robust security measures. Foremost among these is primary authentication, the initial step in securing access to 5G network environments. For the 5G primary authentication, two protocols, namely 5G Authentication and Key Agreement (5G-AKA) and Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA′), were proposed and standardized, where the former is for 3GPP devices, and the latter is for non-3GPP devices. Recent scrutiny has unveiled vulnerabilities in the 5G-AKA protocol, exposing it to security breaches, including linkability attacks. Moreover, mobile communication technologies are dramatically evolving while 3GPP has standardized Authentication and Key Management for Applications (AKMA) to reuse the credentials, generated during primary authentication, for 5G network applications. That makes it so significant for 5G-AKA to be improved to support forward secrecy as well as address security attacks. In response, several protocols have been proposed to mitigate these security challenges. In particular, they tried to strengthen security by reusing secret keys negotiated through the Elliptic Curve Integrated Encryption Scheme (ECIES) and countering linkability attacks. However, they still have encountered limitations in completing forward secrecy. Motivated by this, we propose an augmentation to 5G-AKA to achieve forward security and thwart linkability attacks (called 5G-AKA-FS). In 5G-AKA-FS, the home network (HN), instead of using its static ECIES key pair, generates a new ephemeral key pair to facilitate robust session key negotiation, truly realizing forward security. In order to thoroughly and precisely prove that 5G-AKA-FS is secure, formal security verification is performed by applying both BAN Logic and ProVerif. As a result, it is demonstrated that 5G-AKA-FS is valid. Besides, our performance comparison highlights that the communication and computation overheads are intrinsic to 5G-AKA-FS. This comprehensive analysis showcases how the protocol effectively balances between security and efficiency.


Introduction
Since the first deployment of the fifth generation (5G) mobile networks in 2019, 5G has rapidly become a mainstream mobile network worldwide.According to the Global System for Mobile Communications Association (GSMA), the 5G adoption rate reached 43.1% in the United States in Q4 2022 [1].5G mobile networks and telecommunication standards have been developed to meet the various demands of modern telecommunication.In particular, it is designed to support enhanced features such as Enhanced Mobile BroadBand (EMBB), showed that there still exist attack scenarios against 5G-AKA.In addition, refs.[10,16] pointed out that privacy problems of users may occur since 5G-AKA is susceptible to linkability attacks.Furthermore, ref. [17] presented shortcomings of 5G-AKA, including the lack of support for forward secrecy, also known as perfect forward secrecy.
Meanwhile, the 5G network environments face the following new challenges: • As the advancement of 5G technology and the proliferation of 5G network applications continue at a rapid pace, the emergence of new security threats and attacks becomes more pronounced, thereby necessitating the establishment of elevated security prerequisites.• Thanks to the Authentication and Key Management for Applications (AKMA) [18], the credentials generated through 5G primary authentication can be reused for application authentication in the 5G network environments; that is, the master session key negotiated during the 5G primary authentication is applied to derive an application key that allows a UE to authenticate itself to AKMA-based applications smoothly and efficiently.
Evidently, the security robustness of the existing 5G primary authentications falls short of addressing the aforementioned concerns.As a result, it becomes imperative to bolster the security framework with robust public key-based measures and ensure the implementation of forward secrecy.
Regarding EAP-AKA ′ , there has been a standardization effort aimed at enhancing the protocol to incorporate support for forward secrecy (known as EAP-AKA ′ -FS) [19].On the 5G-AKA side, there are existing works proposed to support unlinkability and forward secrecy, such as [3,16,17,20,21].In particular, those 5G-AKA enhancements attempted to reuse the ECIES shared key, which is used to protect the UE's identifier in the initiation phase.However, in such an approach, if an adversarial security event happens in HN, forward secrecy is not guaranteed for the session key.
In this paper, we propose a 5G-AKA-Forward Secrecy (5G-AKA-FS) protocol that supports forward secrecy and unlinkability together to solve the limitations of the existing studies and maximize the efficiency of authentication in 5G networks.The proposed protocol accomplishes forward secrecy and unlinkability by introducing an additional ECIES-based ephemeral key pair generation within HN.The main contributions of this paper are summarized as follows: • The 5G-AKA-FS protocol is designed to concurrently support forward secrecy and unlinkability.

•
We analyze the latest studies proposed to improve the vulnerabilities of 5G-AKA and provide a solid comparison of security attributes between our 5G-AKA-FS and the latest studies.

•
We conduct a rigorous security verification of the proposed protocol using formal verification (BAN Logic [22] and ProVerif [23]).

•
Performance evaluation is thoroughly carried out by measuring overhead in terms of computation and communication.
The rest of the paper is organized as follows.Section 2 explores the existing enhancements of 5G-AKA, while Section 3 describes the preliminaries used in this paper.Moving on to Section 4, we present a detailed description of the proposed protocol, followed by the formal security analysis using BAN Logic and ProVerif in Section 5. Assessing performance, Section 6 carries out a comparative evaluation of security properties between the proposed and existing protocols, along with measured overhead.Finally, Section 7 provides the conclusion.

Related Works
3GPP has defined two AKA protocols, namely 5G-AKA and Extensible Authentication Protocol (EAP)-AKA ′ , for primary authentication in 5G networks.The purpose of the AKA protocols is to establish mutual authentication between the UE and the HN.In 2G to 4G networks, UE's identifier IMSI is publicly exposed, thus resulting in privacy issues.
However, in 5G-AKA, the subscriber identity information, known as SUPI, is encrypted into SUCI, which is then used for authentication while solving the privacy problem.
5G-AKA enhances authentication and key exchange in addition to introducing subscriber identity protection (e.g., SUCI) for privacy.However, as it is developed based on EPS-AKA, it inherits existing security vulnerabilities.Ref. [15] conducted a formal verification and analysis of the 5G-AKA protocol using the Mixed Strand Space model, revealing vulnerabilities within the protocol.Their study also presented 21 attack scenarios specific to 5G-AKA and highlighted security features not supported by 5G-AKA.Furthermore, ref. [17] identified shortcomings, such as the lack of support for forward secrecy through an analysis of 5G-AKA.In this regard, improved protocols, including [3,16,17,20,21], have been proposed to address such vulnerabilities in 5G-AKA.
SUCI-AKA, proposed by [20], aims to achieve forward secrecy for the anchor key K SEAF .For this goal, when generating the master session key K AUSF , the protocol reuses the shared key k HN , which is exchanged through ECIES to encrypt SUPI.In more details, the sequence number SQN is replaced with k HN during the generation of K AUSF .Such an approach enhances the security of the anchor and sub-session keys derived from K AUSF while still allowing the UE to verify if the received messages and their message authentication code (MAC) are fresh.However, SUCI-AKA can not support forward secrecy because the anchor key K SEAF is compromised when the long-term key k, shared between the UE and the HN, and the HN's private key sk HN are leaked.
5G-IPAKA, proposed by [17], aims to provide mutual authentication between the UE and the SN, enhanced security for the anchor key and authentication vector (AV), and key confirmation.This protocol tries to provide forward secrecy by applying the ECIES secret k HN to generate the anchor key K SEAF , from which sub-sessions keys are then derived.Moreover, it lets the HN send K SEAF to the SN before the UE authentication.In this way, 5G-IPAKA enables the UE to authenticate the SN by verifying the SN's message authentication code computed with K SEAF in addition to the HN.Similar to this, the UE is authenticated to the SN through its message authentication code.As a result, 5G-IPAKA achieves mutual authentication between the SN and the UE and between the HN and the UE while supporting key confirmation.However, if k and sk HN are leaked, an attacker can reconstruct the anchor key K SEAF for malicious purposes while breaking forward secrecy.Furthermore, active attacks by malicious SNs are also possible since the HN delivers K SEAF to the SN without authenticating the UE.Finally, this protocol leads to compatibility issues with Subscriber Identity Modules (SIMs) by proposing a structure that deviates from the existing standard specification.
5GAKA-LCCO, proposed by [21], aims to improve high communication and computation overheads as well as address SUCI replay attacks present in 5G-IPAKA.In this protocol, the SN first creates the random number and timestamp RAND SN and T SN , and sends to the UE these values, which are then applied to generate the key block with the long-term shared key k and the ECIES secret k HN .Note that the generated key block is not only used to compute the UE's SUCI but also to authenticate the UE to the HN.Upon a receipt of the new SUCI, the HN decrypts it into the corresponding SUPI, counts on its timestamp T HN to validate the received T SN , and authenticates the UE.In such a way, the authentication process is optimized to have one round trip, reducing the computation and communication overhead.Also, the HN utilizes timestamps to prevent the SUCI replay and Denial-of-Service (DoS) attacks on itself while enhancing the security of the session keys by deriving K AUSF from sk HN , k, RAND SN , and T SN .However, it should be noted that when generating K AUSF , both k and sk HN are utilized.Therefore, if k and sk HN are leaked, an attacker can recover K AUSF and conduct subsequent malicious attacks.Furthermore, to address SUCI replay attacks, 5GAKA-LCCO introduces freshness to SUCI by utilizing T SN .However, this approach requires time synchronization, which may pose challenges in situations such as roaming.Consequently, the use of T SN is not desirable for mobile telecommunication scenarios.Furthermore, 5GAKA-LCCO exhibits an unconventional protocol flow compared to the 5G-AKA standard, and the differences in the Authenticate SIM command can lead to compatibility issues, particularly with Legacy Universal Subscriber Identity Modules (USIMs), potentially resulting in backward compatibility problems.
5G-AKA ′ , introduced by [16], focuses on addressing linkability attacks by reusing the ECIES secret k HN , which is used to protect SUPI in the initial step.In this protocol, the HN encrypts its randomly generated number RAND into RAND ′ with k HN , then sending to the UE the encrypted result instead of RAND along with the authentication token AUTN.At this point, it is worth noting that since the UE trusts the freshness of k HN , it also trusts the freshness of RAND ′ .Therefore, if successfully decrypting RAND ′ with k HN , the UE can trust the freshness of its received AUTN, thereby detecting the message replay attack prior to arriving at the Sync_Failure while defending against the linkability attack.In spite of such a successful defense against the linkability attack, this protocol is vulnerable to active attacks by malicious SNs because it allows the HN to send K SEAF to the SN without authentication to the UE.More importantly, 5G-AKA ′ fails to achieve forward secrecy because the old anchor keys can be recovered if the long-term key k shared between the UE and the HN is leaked.

Notations
Table 1 shows abbreviations and notations to be used throughout this paper.

Elliptic Curve Integrated Encryption Scheme
The Elliptic Curve Integrated Encryption Scheme (ECIES) [24,25] is a well-known hybrid encryption scheme consisting of a Key Encapsulation Mechanism (KEM) and a Data Encapsulation Mechanism (DEM) where messages of arbitrary length can be encrypted.This scheme is a key component of 5G-AKA.
The ECIES-KEM has the following three algorithms: • KeyGen(pp): On input of a public parameter pp, the algorithm outputs a publicprivate key pair (PK, sk) such that PK = sk • G, where pp is an elliptic curve parameter standardized in secp256r1 [26], and G ∈ pp is a base point.• Encap(PK): On input of a public key PK, the algorithm generates an ephemeral publicprivate key pair (R, r) such that R = r • G, and then outputs a ciphertext C 0 = R and a shared key k s = KDF(r • PK), where KDF is a key derivation function.

•
Decap(sk, C 0 ): On input of a ciphertext C 0 and a private key sk, the algorithm outputs the shared key k s = KDF(sk • C 0 ).
The ECIES-DEM has the following two algorithms: • SEnc(k s , M): On input of a key k s and a message M, the algorithm first parses k s as where ENC is an encryption part of a symmetric encryption scheme and MAC is a message authentication code.
, where DEC is a decryption part of a symmetric encryption scheme.

A 5G-AKA Protocol for Forward Secrecy
In this section, we propose a 5G-AKA protocol for forward secrecy (for short, 5G-AKA-FS) that is compatible with the current 3GPP standards [3], and the proposed protocol is shown in Figure 2. Before executing the 5G-AKA-FS protocol, UE holds (k, PK HN , SUPI, SQN UE ) secretly and HN stores (k, sk HN , ID HN , SQN HN ) secretly.Also, SN stores ID SN .We denote by H SHA-256 the SHA-256 cryptographic hash function.

The Initiation Phase: Step 1
In this phase, UE sends its SUPI as an encrypted form using ECIES [24,25] with HN's public key PK HN .Correspondingly, HN decrypts SUCI with its private key sk HN .Upon successful completion of Step 1, we proceed to Step 2 by selecting the 5G-AKA-FS among various methods.Before choosing the authentication method, the Step 1 process unfolds as follows: Step 1.1 (UE) Inputs.With HN's public key PK HN , UE executes the followings: The Protocol: Generate an ephemeral private-public key pair (r, R) With PK HN , compute a ciphertext C 0 = R and a key k UE = KDF(r • PK HN ) 3.
Parse the shared key k UE as k 1 ||k 2 4. Compute Outputs.UE sends (SUCI) to SN.The Protocol: Parse the shared key k HN as k 1 ||k 2 3.
Retrieve the corresponding k and SQN HN from its database

The Challenge-Response Phase: Step 2
In this phase, UE and HN authenticate each other via a challenge-response method and establish anchor keys (i.e., K SEAF ) together with SN.A key idea is that we set a Diffie-Hellman public key Y as a random challenge RAND, and a Diffie-Hellman key DHK is used as a key material for forward secrecy.This phase uses a series of HMAC-SHA-256 cryptographic key derivation functions f 1 , f 2 , f 3 , f 4 , f 5 , f * 1 , and f * 5 , as specified by TS 33.501 [3] (see also Figure 3).The Protocol: Generate an ephemeral private-public key pair (y, Y) Compute a Diffie-Hellman key DHK = y • C 0 3.
Set RAND ← Y as a challenge (The 128-bit randomness of RAND is guaranteed since y is randomly chosen from the 128-bit key space.) 4.
In the UE, the ME forwards the received RAND and AUTN to the SIM 2.
Check  [3], UE and SN should confirm the keys agreed and the identities of each other implicitly through the successful use of keys in subsequent procedures, which can be expressed by a key-confirmation round trip with K SEAF .

Formal Verification
To verify the security of the protocol, various formal verification methods are used as shown in Figure 4.Among several formal verification methods, the proposed protocol is verified through two methods: BAN Logic and ProVerif.BAN Logic is a representative method of Modal Logic and one of the widely used formal verification methods.With its decisiveness on the result, it can be fully trusted once the verification process is correct.However, each verification method has its pros and cons.BAN Logic does not consider dishonest reasoning.In other words, it cannot detect the attack of malicious participants.Thus, for precise verification results, we have included ProVerif as the second verification tool.ISO29129-1, a document for protocol verification framework, guides to formally verify the protocol using the automated prover [28].ProVerif is one of the state-of-theart verification tools that meets the guidelines.It can formally verify the protocol in an unbounded session environment and detect malicious attacks on the protocol.By using two complementary verification methods, BAN Logic and ProVerif, we have come up with reliable verification results.

Formal Verification via BAN Logic
The results of BAN Logic are driven by the idealization, assumption, goals, and derivation phase.The notations and rules of BAN Logic used in the above process are shown in Table 2 and 3. Excluding messages that are not encrypted, only messages protected by secret keys or secret information between communication participants, such as encryption, digital signature, and message authentication code are expressed.Second, in the Assumption step, preconditions for communication, such as network environment and home, are defined in a form that can be applied in BAN Logic.Third, in the goal step, the security goal to be required in the proposed protocol is defined.Finally, in the derivation step, it shows a series of processes to derive the security attributes defined in the goals through the BAN Logic rule.The results verified through BAN Logic in this paper are as follows.

Notation Meaning
P |≡ X P believes the message X P ◁ X P receives the message X P |∼ X P previously sent the message X P ⇒ X P has authority over X #(X) The message X is fresh ⟨X⟩ K X is combined with a secret K {X} K X is encrypted with a key

Rule Formula
Message Meaning Rule (MM)

The Initiation Phase: Step 1
The idealization form of the Initiation Phase of the protocol is shown below: We added Assumptions (2) to (5) to verify through BAN Logic.
HN |≡ #(UE HN |≡ #(UE Technically, all the aforementioned assumptions could be invalidated as the HN inherently lacks trust in the UE's public key PK UE .However, in the case of 5G AKA, since it was designed to tolerate a replay attack or Man-in-the-Middle (MITM) attack on the public key, we followed the standard and added the above assumption to continue this analysis.
Therefore, we set a security goal that HN believes that UE believes in SUPI, and derived this goal through the derivation step.

The Challenge-Response Phase: Step 2
The idealization form of the Challenge-Response Phase of the protocol is shown below: Unlike HN in (14), in (13), due to no knowledge on k, SN treats RES * as an unrecognized simple value.We added assumptions from ( 15)-( 26) to derive the security goal.
K SEAF is derived based on the ECIES ephemeral key pair performed once again in HN, and the UE can also derive K SEAF through the ECIES process.Therefore, since the UE can trust that K SEAF is fresh, ( 18) is added.Also, (19) and ( 20 from (11), we derive UE◁ Y − → HN by (11) (36) Here, given the ephemeral ECIES public key of HN, UE derives Note that after recovery, SQN HN is checked for its freshness.For this procedure, we add the assumption (17).Now, UE possesses the valid SQN HN .Even if RAND and AUTN are replayed, a linkability attack does not occur in the UE.Because freshness is verified based on the key derived through ECIES rather than SQN HN during MAC check, when a replay attack occurs, the Sync_Failure step is not performed, and MAC_Failure is executed to stop authentication, so unlinkability is supported.
Although our settings are similar to Damir et al. [29], the actual internal processes are different as the internal processes of UE, SN, and HN are fairly different from those of Damir et al.'s protocol.We implement those differences in our implementation.
Under Dolev-Yao's attacker model, we simplify some cryptographic primitives as symbolic functions.Particularly, the Diffie-Hellman key exchange protocol can be implemented as a symbolic function as follows: DH Key Exchange protocol type pubKey.type secKey.
For the symmetric key encryption/decryption, we utilized a symbolic function defined in [29] to implement the protocols in our 5G-AKA-FS.Symmetric key encryption/decryption means that a message m is encrypted by senc using a secret key n.Then, the encrypted message senc(m,n) only can be decrypted using sdec with the same key.It is defined as follows: Encryption/Decryption fun senc(bitstring,bitstring):bitstring.reduc forall m:bitstring,n:bitstring; sdec(senc(m,n),n)=m.

Protocol Process
We processed our protocol for the verification.We define the public key of HN using its corresponding private key, skHN, and the public key is broadcasted to all public channels as it is a public parameter.We composited infinite replication of UE, SN and HN processes in parallel for protocol processes.

Assertions
Using ProVerif, we can verify if the adversary can access the security parameters by reaching the state where those parameters are available.In our protocol, the private key of HN (skHN), a Long-term key at UE/HN (uk), and the Long-term identity (SUPI) were queried to verify their secrecy.

Verification Results
We execute our ProVerif code on the ProVerif online demo website.As a result of the verification, we can conclude that the attacker cannot access the security keys in any state of the process.Moreover, all the sequences of executions of UE, SN, and HN are verified as defined in the protocol.
The summary of the verification results is as follows:

Verification Summary
Query

Comparative Analysis
In this section, we conduct a comparative assessment aimed at evaluating the effectiveness of the proposed protocol by considering security requirements as well as the computational and communication overheads.For a starter, six protocols are compared against six security requirements to assess the degree of security they each offer.This analysis showcases that the proposed protocol delivers robust security measures in comparison to the others.
Next, we proceed to determine the computational overhead linked to each protocol.This involves scrutinizing the amount of cryptographic operations required within each security protocol and quantifying the computational overhead through Python.We also evaluate the communication overhead by closely examining the message dimensions described in the 3GPP standard document [3].For that, the transmitted messages are not only inspected, but also their bit sizes are calculated to measure the communication overhead caused by each protocol.

Security Analysis
The proposed security protocol is compared to the existing protocols based on six security requirements: 5G Network and UE's Mutual Authentication (AUTH), Secure Key Exchange (SKE), Legacy USIM Compatibility Support (LUCS), LinkaBility Attack (LBA), Active attack by Malicious SN (AMS), and Forward Secrecy for K SEAF (FS).The security requirements that each protocol satisfies are shown in Table 4.
According to the table, all protocols satisfy the requirements for AUTH as well as SKE.However, LUCS is not supported by 5G-IPAKA and 5GAKA-LCCO.5G-IPAKA introduces a different structure, which may result in compatibility issues.Similarly, 5GAKA-LCCO deviates from the standard by utilizing T SN and follows an unconventional protocol flow, potentially leading to compatibility problems with previous versions, i.e., reverse compatibility problems.
LBA is an attack related to compromising a UE's location privacy.5GAKA-LCCO eliminates the process of synchronization failure by reducing round-trip, thus preventing LBA.In the case of 5G-AKA ′ , k HN is reused instead of SQN, which enables it to confirm the freshness of MAC and address LBA.On the other hand, 5G-AKA-FS can defend against LBA because it computes DHK in HN and reflects this key when generating values required for authentication.
In 5G-IPAKA and 5G-AKA ′ , active attacks by malicious SN are possible because the HN delivers K SEAF to the SN without authentication of the UE.5G-AKA, SUCI-AKA, and 5G-AKA ′ derive the anchor key K SEAF through the long-term key k, so FS is not supported when k is leaked.5G-IPAKA and 5GAKA-LCCO used not only k but also HN's private key sk HN to support FS.However, if sk HN is compromised, FS for K SEAF in the past is not achieved.

Overhead Analysis
To compare the trade-off between security and resource consumption, we have compared the proposed protocol computation and communication overhead.SUCI-AKA, 5G-IPAKA, 5GAKA-LCCO, and 5G-AKA ′ are other protocols improvised based on 5G-AKA.However, they do not provide complete FS.EAP-TLS1.3and EAP-AKA ′ -FS are both representative protocols on the mobile network field and provide complete FS.The test results provide respectful data for a trade-off between security and resource consumption.

Computation Overhead
Table 5 summarizes the environment used in the experiment.The computation overhead for each protocol was measured by conducting 5000 test runs using the cryptography library in Python 3.10.11.As can be seen in a test result shown in Figure 5, 5G-AKA-related protocols have minor differences with 5G-AKA computation overhead.However, these protocols do not completely provide FS.The proposed protocol, with a computation overhead of 6.75 ms, provides FS and has resistance against LBA and AMS.Moreover, as can be seen in comparison with EAP-TLS1.3and EAP-AKA ′ -FS, the increase in computation overhead for providing FS in the proposed protocol is low.
The majority of the computation overhead is incurred by ECDH (Elliptic Curve Diffie-Hellman) and digital signature.To provide FS, the protocol must generate a fresh key every session, which 5G-AKA does not do on the HN side, so an increase in overhead to provide FS on protocols is mostly caused by adding fresh ECDH in the key generation phase.In EAP-AKA'-FS, HN and UE generate fresh ECDH keys in the challenge-response phase.However, the proposed protocol, with the reuse of the fresh ECDH key generated in the initiation phase.In Step 1.1, the proposed protocol computation overhead is optimized.Moreover, unlike EAP-TLS1.3,by a succession of 5G-AKA architecture, the proposed protocol does not require a digital signature.These are the reasons the proposed protocol has lower computation overhead than EAP-TLS1.3and EAP-AKA ′ -FS.Considering that our proposed protocol provides strong security, this level of computational overhead is deemed acceptable.It represents a trade-off that we are willing to accept to prioritize robust security.

Communication Overhead
Communication overhead refers to the total message size that needs to be transferred in the network for a specific purpose.Based on the 3GPP 33.501 specification, we have analyzed the total size of the messages that are exchanged through the primary authentication phase.Table 6 refers to the size of the messages that consist of the 5G primary authentication phase.The combination of upper messages concludes the total communication overhead of the 5G-AKA.Table 7 gives the total communication overhead of 5G-AKA, improved protocols, and for practical comparison EAP-TLS1.3and EAP-AKA ′ -FS.For one protocol to offer additional security properties and inherit the structure of 5G-AKA, it is most likely to use additional messages to fulfill that purpose.As a result, 5G-AKA-FS leads to a higher communication overhead than 5G-AKA.However, as compensation for this sacrifice, i.e., additional overhead, the proposed protocol offers forward secrecy by newly generating the HN's ephemeral ECDH public key and using it as RAND in the initialization phase.Note that in 5G-AKA RAND is a 128-bit random challenge, but in 5G-AKA-FS the RAND challenge is replaced with the HN's ephemeral ECDH public key, which is 256-bit.This results in 5G-AKA-FS having 384-bit higher communication overhead than 5G-AKA.With only 384-bit extra messages traveling through the network, 5G-AKA-FS achieves resistance against LBA and AMS and provides FS.Among 5G-AKArelated protocols, 5G-AKA-FS is the only improvised protocol that offers all three security properties.Furthermore, despite its increase, the overhead of 5G-AKA-FS remains lower than that of the EAP-TLS-1.3protocol and EAP-AKA ′ -FS.The analysis results indicate that the addition of 384 extra bits for three crucial security properties are reasonably justifiable trade-offs.

Further Discussions
The proposed protocol has both advantages on security properties and overheads.However, implementing 5G-AKA-FS presents another challenge.While it is USIM compatible and does not require hardware exchange, software updates are required on both the UE and the 5G Core.Given that the 5G network serves as the infrastructure for connecting a massive number of devices, testing, and simulation are essential before the updates.
As for security properties, the proposed 5G-AKA-FS protocol has several limitations.For example, our protocol does not provide resistance to key compromise impersonation attacks since an attacker who obtains a permanent key k from HN can easily impersonate UE.Also, the proposed protocol does not guarantee security against ephemeral key leakage (e.g., due to side-channel attacks) because the exposure of r breaks UE anonymity.Additionally, the security of the proposed protocol relies on the safety of the cryptographic key exchange function ECDH.However, the emergence of quantum computing poses a threat to the security of legacy cryptographic algorithms including ECDH.Therefore, future research on quantum-resistant AKA using Post-Quantum Cryptography is required.

Conclusions
In this paper, we proposed an improved 5G-AKA (5G-AKA-FS) protocol that provides UE unlinkability and forward secrecy, and is compatible with the 3GPP standard.Implementing the proposed protocol will require the update on UE and 5G Core.However, since it is compatible with the original 5G-AKA it only needs minor software updates.Also, we proved that the 5G-AKA-FS protocol is valid by using formal verification tools BAN Logic and ProVerif.Moreover, we compared the security properties and computation/communication overheads of our 5G-AKA-FS to those of the other existing protocols, including 5G-AKA, SUCI-AKA, 5G-AKA ′ , 5G-IPAKA , 5GAKA-LCCO, EAP-TLS 1.3, and EAP-AKA ′ -FS.This comparative analysis demonstrates that the proposed protocol effectively maintains a balance between security and efficiency.

Case iii) Case i (The SIM card returns ⊥
[27] check does not pass, the SIM card returns ⊥ and then UE sends a failure message SQN HN < SQN UE + ∆ (The first condition SQN UE < SQN HN ensures the freshness of (RAND, AUTN).Also, the second condition SQN HN < SQN UE + ∆, which is optional in the non-normative Annex C of TS 33.102[27], prevents a wrap-around of SQN UE .For example, if ∆ is too small (i.e., ∆ = 2), an attacker can make a synchronization failure by sending SUCI computed by the attacker with a fake SUPI.After this attack, the honest UE and HN can no longer authenticate each other.In TS 33.102[27], a recommended value of ∆ is 228so as to decrease the synchronization failure rate.)• If this check does not pass, the SIM card computes MAC * ← f * 1 (k, SQN UE , AMF, RAND ⊕ DHK) and returns AUTS ← (AK * ⊕ SQN UE , AMF, MAC * ) where AK * ← f * 5 (k, RAND ⊕ DHK).Then, UE re-synchronizes with HN by sending a failure message Sync_Failure and AUTS to SN (see Case ii) • Otherwise, proceed to the next step 9. Set SQN UE ← SQN HN 10.Compute CK ← f 3 (k, RAND ⊕ DHK) and IK ← f 4 (k, RAND ⊕ DHK) 11.Compute RES ← f 2 (k, RAND ⊕ DHK) and SIM returns RES, CK, and IK to ME 12.The ME calculates RES * ← KDF(CK||IK, ID SN ||RAND||RES) and derives K AUSF ← KDF(CK||IK, ID SN ||CONC|| DHK) and K SEAF ← KDF(K AUSF , ID SN ) 13.The UE returns (K SEAF , RES * ) Outputs.The UE stores K SEAF and sends RES * to SN (see ): The UE sends a failure message Mac_Failure to SN.

Table 2 .
Notations of BAN Logic.
this point, despite no trust in Y, UE can be sure that AK is a good key shared between HN and itself.This is because AK is derived by inputting k and x where k is only known to both UE and HN and x is its own fresh ephemeral ECIES private key.As a result, UE gains the belief (37) as follows.

Table 4 .
Comparison in terms of security requirements with existing protocols.