Privacy-Enhanced AKMA for Multi-Access Edge Computing Mobility ^†

Abstract

Multi-access edge computing (MEC) is an emerging technology of 5G that brings cloud computing benefits closer to the user. The current specifications of MEC describe the connectivity of mobile users and the MEC host, but they have issues with application-level security and privacy. We consider how to provide secure and privacy-preserving communication channels between a mobile user and a MEC application in the non-roaming case. It includes protocols for registration of the user to the main server of the MEC application, renewal of the shared key, and usage of the MEC application in the MEC host when the user is stationary or mobile. For these protocols, we designed a privacy-enhanced version of the 5G authentication and key management for applications (AKMA) service. We formally verified the current specification of AKMA using ProVerif and found a new spoofing attack as well as other security and privacy vulnerabilities. Then we propose a fix against the spoofing attack. The privacy-enhanced AKMA is designed considering these shortcomings. We formally verified the privacy-enhanced AKMA and adapted it to our solution.

1. Introduction

The fifth generation (5G) mobile network is developed to have reliable, energy-efficient, and high-capacity service with low latency [1]. Ultimately, the 5G is expected to have data rates up to 10 Gbps, service level latency below 1 ms, ubiquitous connectivity of 100%, improved battery life, and support for 300,000 devices within a single cell [1,2,3].

The Internet of Things (IoT) is a growing ecosystem with a massive number of interconnections between heterogeneous physical objects. The number of IoT devices is increasing exponentially; hence these devices generate a larger and larger amount of data. However, IoT devices are resource-constrained. They typically have low battery power, low storage capacity, small processing power, and limited communication capacity [1,4]. Therefore, IoT applications require a decentralized local service that provides location awareness, reliability, low latency [1], and access to centralized cloud computing facilities for data processing and storage [4].

Cloud computing-based services support IoT applications in providing computing resources and storage. On the other hand, cloud computing-based services may have latency issues, jitter, service interruptions, and a single point of failure, which is inconvenient, especially for time-sensitive IoT services [1,3]. Multi-access edge computing (MEC) is developed to extend the capabilities of cloud computing to the edge of the mobile network and to provide improved quality of service (QoS) and quality of experience (QoE) [4,5]. In order to achieve this, MEC hosts are deployed to the edge of the mobile network.

MEC, together with 5G technology, provides proximity, low latency, high bandwidth, location awareness, real-time responsiveness, security, and privacy protection, proximate data outsourcing, and mobility support [1,3,4]. Examples of IoT applications that can benefit from MEC, supported by 5G, include ultra-high definition (UHD) video streaming, augmented reality (AR), virtual reality (VR), mixed reality (MR), tactile internet, machine-type communication (MTC), machine-to-machine (M2M), unmanned aerial vehicle (UAV), vehicle-to-everything (V2E), intelligent transportation system(s) (ITS), serious gaming, factory automation, healthcare, smart grid, smart home, smart city, smart retail, and smart agriculture [1,2,3].

User equipment (UE) mobility –where a UE that is initially connected to the source MEC host is relocated to the target MEC host– has varying impacts on MEC applications. Some are not affected by UE mobility, e.g., when the user state does not need to be maintained for the service. On the other hand, some MEC applications are more sensitive to UE mobility. An example is when the service requires continuous connectivity between the device and the MEC application on the network side. This case requires a seamless handover from one MEC host to another [6]. In order to provide seamless relocation, it is necessary to transfer the user context (i.e., user-specific application state) between the source and target MEC hosts [7,8]. The transfer of the user context can happen in three ways: device application-assisted state transfer, MEC-assisted state transfer, and application self-controlled state transfer [7].

The MEC applications often process data related to users, share secret keys, and store private data. Therefore, relocating services between different MEC hosts may introduce security and privacy issues [9], and it is important to study how UE mobility could be handled while maintaining security and privacy. For example, it is necessary to run authentication with the target MEC application, and authorization should be provided before relocation. Otherwise, an unauthorized UE may start using the MEC application, or the UE may share its data with an unauthorized MEC application [10].

The need for secure authentication between the users and the application functions led to the development of generic bootstrapping architecture (GBA) in the third-generation partnership project (3GPP). The main purpose of GBA is to enable authentication and establish shared keys between the UE and network application function (NAF). In order to achieve this, the 3GPP authentication infrastructure is used [11,12]. Subscription of UE implies that the mobile network operator (MNO) and UE share a permanent key K. The UE is known by a unique identifier, which is called the international mobile subscriber identity (IMSI) in earlier networks and subscription permanent identifier (SUPI) in 5G. After the Authentication and Key Agreement (AKA) protocol is run successfully, MNO and UE also share session keys. Another key is derived from these shared session keys to be shared between UE and NAF [11,13]. The GBA was designed originally for 3G networks and later extended to 4G (or LTE) [13]. A new framework, authentication and key management for applications (AKMA), was developed as an alternative to GBA for 5G [14]. The AKMA framework also supports authentication over non-3GPP network access [13].

We consider a user who is a MEC application client and wants to use the MEC application in the MEC host. The problem we are addressing in this paper is how to secure the connection between the user and the MEC application, (i) when the user is registering to the main server of the MEC application, (ii) when the user connects to the MEC application in the MEC host, (iii) when the mobile user changes the MEC hosts while staying in the same mobile network.

In order to resolve the problem, we propose a secure and privacy-friendly mechanism that enables both static and mobile usage of a MEC application. The solution includes the following protocols: (5A) registration of the user to the main server of the application, (5B) updating the user information and shared keys with the main server of the application, (5C) usage of the application in the MEC host when the user is stationary, and (5D) usage of the application in several MEC hosts when the user is moving. The solution utilizes a privacy-enhanced version of the 3GPP AKMA service for authentication and key sharing.

We make the following contributions to this paper.

• We propose a solution for static and mobile usage of a MEC application, as described above.
• We formally verify AKMA using ProVerif [15].
• We found a new spoofing attack, as well as several privacy vulnerabilities, in the current AKMA specification [14]. We also have a fix against the new attack, and we informed a 3GPP delegate about both the attack and its fix.
• We propose a privacy-enhanced version of AKMA that fixes the above shortcomings.
• We formally verify the privacy-enhanced AKMA using ProVerif.
• We adopt the privacy-enhanced AKMA in the AKMA profiles for TLS and implement these profiles in the proposed protocols for the setting mentioned above.

Necessary background information and related work are provided in Section 2. The problem statement is described along with the system model in Section 3. Section 4 includes AKMA, the new attack against AKMA, and privacy-enhanced AKMA with formal verifications of both AKMA and PE-AKMA, done by ProVerif. The solution with four protocols is presented in Section 5. The paper ends with an analysis of the solution in Section 6 and the final remarks in Section 7. In addition, there are six appendices.

2. Review and Related Work

In this section, we provide background information and summarize related work.

2.1. MEC Framework

European Telecommunications Standards Institute (ETSI) initiated MEC standardization in 2014 [16]. The framework of MEC is illustrated in Figure 1 and it consists of three levels [6]: MEC system, MEC host, and network.

The MEC system level includes the MEC orchestrator (MEO) and user application. MEO has an overview of the MEC system, selects a new host for relocation, and initiates the transfer from the source MEC host to the target MEC host [6,16].

The MEC host-level includes MEC host and MEC host-level management. The MEC host is deployed to the edge of the mobile network, consisting of a MEC platform, MEC applications, and virtualization infrastructure.

MEC functionality can be run over a cellular network, some other wide-area network, or, alternatively, over a local network such as Wi-Fi.

2.2. Authentication and Key Management for Applications (AKMA)

Authentication and key management for applications (AKMA) is a key distribution service in the 5G system that supports authentication and security protection between the UE and applications. AKMA uses similar principles to those of generic bootstrapping architecture (GBA) in legacy mobile networks. AKMA adapts to the architectural changes in the 5G system to meet the requirements for various scenarios, e.g., those related to the Internet of Things [17]. The authentication and key agreement rely on the credentials and identities of the mobile subscriber, and are pre-established with the mobile network operator (MNO) for 5G access [18]. A fundamental difference between AKMA and GBA is that AKMA bootstraps application security from the keys derived in the authentication and key agreement (AKA) during the network access authentication, whereas GBA is based on an AKA run that is independent of network access. More information about GBA is given in Appendix A.

It is important to notice that the AKMA alone does not yet provide authentication between UE and the application. Instead, AKMA is used with another protocol, e.g., TLS, which provides authentication between these two entities based on a shared key created by AKMA.

2.3. Formal Verification

The formal verification of security protocols aim to model and check the security and privacy properties of cryptographic protocols and primitives with the proofs constructed in a fully mechanized manner [19]. The formal verification tries to prove or disprove the security properties. Since proving the security of a protocol is an undecidable problem, the termination of the proof process is not guaranteed [20]. Formal verification methods have been used to verify various mobile network protocols [21].

ProVerif and Tamarin are state-of-art tools for formal verification of the symbolic modeling and analysis of security protocols. Both use the Dolev–Yao adversary model [15,22]. Tamarin allows protocols to be modeled using expressive language based on multiset rewriting rules. These rules are then used to construct a labeled transition system with symbolic representations of the protocol state, messages, and knowledge of the attacker. The protocol state is composed of multiset facts that are a predicate applied to terms, and these facts represent the state information [20]. ProVerif uses the applied pi-calculus as a formal language, translates the protocol into a set of Horn clauses, then tries to conclude if some security property is falsified, i.e., finds an attack [21]. More information about ProVerif is provided in Appendix B.

2.4. Security and Authentication Properties

In this section, we explain security properties that are important in our context and how they are implemented in ProVerif.

• Secrecy means that the attacker cannot reach the private information. Therefore, the secrecy queries verify the confidentiality and privacy of data. In ProVerif, the secrecy of the term M can be verified using the command query attacker(M). If ProVerif returns query not attacker (M) is true, then the term M remains secret despite the presence of an attacker in the public channels [15].
• Reachability means that an event occurs in the protocol. In ProVerif, the reachability of event e can be checked with query event(e) [15].
• Strong secrecy means that the attacker cannot notice the differences between different sessions that follow from changing secrets in the protocol. It is similar to the concept of indistinguishability and semantic security in the computational proof-based approach in cryptography [15,19,23]. In ProVerif, strong secrecy for the term M is proved by the query noninterf M [15].
• Weak secrets are the secrets that are vulnerable to off-line guessing attacks, e.g., human-memorable passwords [15,23]. ProVerif tries to find proof that the attacker cannot distinguish a correct guess of the secret M from an incorrect guess with the query weaksecret M [15].
• Forward secrecy protects against an attacker that has a recording of some past (encrypted) sessions. More precisely, forward secrecy ensures that past recorded encrypted messages (session keys) will remain secret, despite the long-term keys being compromised at some point. One can use ProVerif to show that even if some party in the protocol is corrupted (long-term keys are leaked), the secrets that are shared before the corruption are not revealed to the attacker. Assuming that a long-term key K leaked in the first execution (phase 0), forward secrecy for the subsequent protocol execution (phase 1) is checked by adding the process phase 1; out(c,K) to the main process, where c is a public channel [15].

Next, we describe the authentication properties as described in [24] and their implementation in ProVerif.

• The protocol guarantees agent A the aliveness of agent B, if whenever A completes a run of the protocol (apparently with B) then B has previously been running the protocol. Aliveness does not guarantee that B believes that B ran the protocol with A.
• The protocol guarantees agent A a weak agreement with agent B, if whenever A completes a run of the protocol (apparently with B) then B has previously been running the protocol, apparently with A [24].
• The protocol guarantees agent A a non-injective agreement with B, if whenever A completes a run of the protocol, apparently with B, then B has previously been running the protocol, apparently with A, both A and B have an identical value for a data item M [24]. The non-injective agreement does not rule out the case when A runs the protocol twice, and B takes part in only one of the runs. If the non-injective agreement is not satisfied, A can be subject to an impersonation attack [25].
• The protocol guarantees agent A an injective agreement with B if, whenever A completes a run of the protocol, apparently with B, then B has previously been running the protocol, apparently with A, both A and B agree on the message M, and each such run of A corresponds to a unique run of B [24]. If the injective agreement is not satisfied, A can be subject to a replay attack [25].

In ProVerif, for two events, e and e0, the query for event(e(M))==>event(e0(N)) means that if an event e(M) has been executed, then event e0(N) has been previously executed. Thus, to prove authentication properties, the events are placed in the ProVerif script to capture authentication definitions. For example, we place an event at the end of agent A’s process to capture the fact that “A completes the protocol”. On the other hand, the claim “B has previously been running the protocol”, can be modeled as “B has sent its last message or B has responded to a message (not necessarily to/from A)”. ProVerif has built-in functionality to check injectivity according to the definition in [24], namely, inj-event(e(M))==>inj-event(e0(N)) which additionally checks if the number of occurrences of e0(N) is greater than or equal to the number of occurrences of e(M).

It should be noted that the authentication properties are building on each other: the injective agreement implies a non-injective agreement, which implies a weak agreement, and which implies an aliveness.

2.5. Related Work

Security plays an important role in the use cases, e.g., smart buildings, connected cars, healthcare [26], and unmanned aerial vehicle (UAV)-assisted MEC [27]. Examples of security and privacy threats are control takeover attacks that can lead to data manipulation, data loss, data recovery, and data leakage. In addition, malicious third-party MEC applications in the MEC host can cause serious security problems [26,28,29].

Khan et al. [30] propose a new privacy mode for AKMA, in which the Application Function (AF) and the mobile network communicate via the UE rather than directly. This mode implies bigger changes to the AKMA system than our privacy-enhanced AKMA, where the message paths are the same as in the current AKMA standard.

Kim et al. [31] propose a handover authentication protocol for distributed application functions in a 5G MEC environment using AKMA. In the proposed handover protocol, user context transfer is done via the local MEC AFs. They also provide formal verification of their protocol.

Yang et al. [32] conducted formal verification of AKMA with the Tamarin tool [22].

Niewolski et al. [33] propose a token-based authentication framework for the 5G MEC system. However, they do not consider the case where the user is mobile.

Several works address the security of mobile MEC users without putting a special focus on the privacy of the MEC user. Ali et al. [34] designed a token- or cookie-based authentication of mobile MEC users. In [35], the authors propose establishing an infrastructure of proxies to extend token-based authentication to multi-operator scenarios. Sanchez-Gomez et al. [36] use the pre-shared key extensible authentication protocol method (EAP-PSK) to authenticate the user and the MEC application.

Zhang et al. [37] designed a mobility support system (MSS) in the cellular network infrastructure and use that system to protect the privacy of mobile MEC users.

3. Statement of the Problem

The following scenario motivates our system model: Alice travels to another city in her home country. Assume she is in Finland and she travels from Helsinki to Tampere. On the way to Tampere, Alice uses a MEC application APPIFY, e.g., for video streaming, AR, or mobile gaming. Since Alice stays in her home country, it is very likely that MNO will not change during her trip. However, coverage of MEC is only local. Alice would need to change between several MEC hosts during the trip.

Nonetheless, she wants to continuously use APPIFY with the benefits of MEC services, such as low latency and high bandwidth. Additionally, she wants to protect her personal information from outsiders and other parties in the network. This information could include, e.g., the name of APPIFY, the content of her communication with APPIFY, and her identifiers. Alice also wants to protect her true identity and her identity in MNO from APPIFY.

The system model includes the following entities: the user equipment (UE), mobile network operator (MNO), MEC hosts, MEC applications, and the main server of the application. Figure 2 presents the settlement of these entities in the system model.

Alice is the user who possesses the user equipment UE, and she uses the application APPIFY. This application has a main server that can be reached via the internet. In addition to this, instances of APPIFY servers reside in MEC hosts. APPIFY in each MEC host is synchronized with APPIFY main server. Alice connects to the APPIFY in the MEC host and obtains the service from there instead of the main server, hence enjoys the benefits of Multi-Access Edge Computing.

The MEC hosts are deployed in the network of MNO. There are only two MEC hosts in our illustration of the system model, presented in Figure 2, but there could be more. It should also be noted that there typically are several other MEC application servers in MEC hosts besides APPIFY.

As shown in Figure 2, Alice is on the move, and her connection is regularly transferred from one base station to another. The connection also eventually changes between the two MEC hosts.

The specifications of 3GPP and ETSI describe how to secure the connections between the user and the MEC host and between MNO and the MEC host. These descriptions also include the mobility of MEC hosts. However, the specifications do not address the security and privacy issues when the user establishes a connection to the MEC application and changes from one MEC host to another. Therefore, we address the problem of establishing a secure communication path between the MEC application user in the UE and the MEC application in the MEC host, considering both when the user is static and when the user is mobile. This paper covers only the case where the MNO does not change during the connection.

Another problem we tackle is how to protect the privacy of the user against outsiders and also against the MEC host, MNO, and MEC applications. The outsiders can be considered Dolev–Yao adversaries, which can observe, replay, delete, fabricate, and reorder the messages in the communication channel [38,39]. This type of adversary cannot decrypt the encrypted messages unless it has the correct key [40]. The MNO, MEC host, and APPIFY can be considered honest-but-curious adversaries. Such adversaries are legitimate parties in the system and follow the protocol faithfully. Meanwhile, they may try to gather as much information as possible about the user from the traffic they see [41,42]. It is reasonable to assume that these parties are honest because they have a high risk of losing their reputation and business if they act maliciously and are caught.

4. AKMA and Its Privacy Enhancement

Authentication and key management for applications (AKMA) is described in 3GPP TS 33.535 [14]. In this section, we first present the AKMA protocol in detail and provide its formal verification using the ProVerif tool. Second, we present a new attack against AKMA, along with a countermeasure against the newly found attack. Third, we introduce privacy-enhanced AKMA (PE-AKMA), which is later used as a building block in the protocols of Section 5. In addition, we also provide formal verification of the PE-AKMA protocol in ProVerif. Finally, we show how the privacy-enhanced AKMA can be adapted to AKMA profiles for transport layer security (TLS)-based protocols, described in [14,43]. The source codes of the formal verifications of AKMA and PE-AKMA are publicly available in [44].

4.1. Authentication and Key Management for Applications

Several functions in the core of the mobile network take part in AKMA. The first one is unified data management (UDM), which stores information about the subscribers of the MNO. Second, the AKMA anchor function (AAnF) manages temporary information about subscribers and generates temporary session keys. The third function is the authentication server function (AUSF), which provides the connection between UDM and AAnF. The AUSF also generates AKMA key material with the 5G authentication vector. Fourth, the network exposure function (NEF) establishes the connection between AAnF and the application function (AF) in case AF is not located inside the home network of the MNO [45]. In the rest of the paper, we use the term MNO to cover all functions in the core of the mobile network that participates in the AKMA service.

The Application Function (AF) depicts the online services or applications that the user is interested in. The AF is authenticated and authorized by MNO before providing the key that is shared with the UE. If AF is located inside the network of the MNO, then AF communicates directly with AAnF, while external AF requires NEF for this communication [14].

During AKMA, MNO shares the subscription permanent identifier (SUPI) with AF if it is inside the network of the MNO [14]. SUPI is a globally unique identifier of the subscriber, and it is only used inside the 3GPP system [46].

If AF is outside the network of the MNO, then MNO shares the generic public subscription identifier (GPSI) with AF [14]. GPSI addresses the subscriber in different data networks and is either the phone number, i.e., mobile subscriber international subscriber directory number (MSISDN), or some external identifier. The 3GPP system stores the association between the GPSI and the SUPI, but there is no implication of a one-to-one relationship between these two identifiers [46].

The AKMA service key, ${\mathrm{K}}_{\mathrm{AKMA}}$, is derived from the shared key that UE and the 5G mobile network obtain as a result of the network access (primary) authentication between them. In addition, the AKMA key identifier (A-KID) is assigned to the user to identify the key ${\mathrm{K}}_{\mathrm{AKMA}}$. A-KID is composed of the AKMA temporary UE identifier (A-TID) and the identifier of the mobile network operator, ID-MNO. The application-specific key ${\mathrm{K}}_{\mathrm{AF}}$ is derived from ${\mathrm{K}}_{\mathrm{AKMA}}$ and ID-AF by both UE and MNO, where ID-AF is the identifier of AF, and is essentially the fully qualified domain name (FQDN) of the AF [47]. The key ${\mathrm{K}}_{\mathrm{AKMA}}$ and its identifier A-KID are updated with every primary authentication, but the lifetime of ${\mathrm{K}}_{\mathrm{AF}}$ depends on the policy of the MNO. For example, after ${\mathrm{K}}_{\mathrm{AKMA}}$ is renewed, UE and AF can still use ${\mathrm{K}}_{\mathrm{AF}}$ to secure their communications until the lifetime of ${\mathrm{K}}_{\mathrm{AF}}$ expires or the application session ends. Afterward, a new ${\mathrm{K}}_{\mathrm{AF}}$ will be derived from the new ${\mathrm{K}}_{\mathrm{AKMA}}$ [14].

The AKMA also allows the anonymous user access to an AF residing inside the mobile network, which is used when AF does not require UE identification [14]. If the AF sends to the MNO a key request indicating that the user should be anonymous, then, in the reply, the AF receives only the shared key ${\mathrm{K}}_{\mathrm{AF}}$ and the expiration time of that key. Afterwards, the AF uses A-KID as a temporary user identifier of the UE.

Next, we present the steps of AKMA in Protocol 1, and Figure 3 summarizes the communication flow of the AKMA protocol, which is adapted from 3GPP TS 33.535 [14].

Protocol 1 Authentication and key management for applications (AKMA)

Goal. Providing authentication and key sharing between UE and AF based on the subscription of UE with MNO. The protocol: Authentication and key agreement (AKA): UE runs AKA with MNO. (If an existing and valid shared key ${\mathrm{K}}_{\mathrm{AUSF}}$ is stored, this step can be skipped.) UE and MNO derive ${\mathrm{K}}_{\mathrm{AKMA}}$ from the shared key ${\mathrm{K}}_{\mathrm{AUSF}}$ and generate the AKMA Key Identifier (A-KID). Here, A-KID is composed of A-TID and ID-MNO. Derivation of credentials in UE: 3. UE derives ${\mathrm{K}}_{\mathrm{AF}}$ for the AF from the ${\mathrm{K}}_{\mathrm{AKMA}}$ and ID-AF. Session Establishment Request: 4. UE sends a session establishment request with the parameter A-KID to AF. Fetching UE credentials: 5. AF sends a request to MNO for the application key by including A-KID and its own identifier ID-AF. 6. MNO retrieves the ${\mathrm{K}}_{\mathrm{AKMA}}$ related to the A-KID and derives ${\mathrm{K}}_{\mathrm{AF}}$ from the ${\mathrm{K}}_{\mathrm{AKMA}}$ and ID-AF. 7. MNO sends the SUPI or GPSI of UE, ${\mathrm{K}}_{\mathrm{AF}}$, and the expiration time of ${\mathrm{K}}_{\mathrm{AF}}$ to AF. Session Establishment Response: 8. AF sends a session establishment response to UE after obtaining the key.

4.2. Formal Verification of AKMA

In this section, we explain our ProVerif model of the AKMA protocol and give the results of its formal verification, as well as their analysis.

4.2.1. Threat Model

We assume the presence of the Dolev–Yao adversary in the unsecured channel (between UE and AF). The adversary can observe, replay, delete, inject, and reorder the messages in the channel; it cannot decrypt encrypted messages or forge signatures without capturing appropriate keys [20,38,39]. The adversary cannot compromise the secure channels [20].

4.2.2. Constructing the Protocol

Our ProVerif model of AKMA protocol is available online [44]. While constructing the protocol, we took the following into account.

• We assume that AKA is completed successfully between UE and MNO before AKMA starts. UE and MNO share SUPI and K, and as a result of AKA, they also share ${\mathrm{K}}_{\mathrm{AKMA}}$.
• In AKMA specifications, the protocol runs through the middle intermediate nodes (AUSF, AAnF, NEF) of MNO. In our implementation, these intermediate nodes are not explicitly defined. Instead, MNO is modeled as a single entity.
• We do not include in our model the details of the key derivation of ${\mathrm{K}}_{\mathrm{AKMA}}$ from K [14]. We simply define a function that derives ${\mathrm{K}}_{\mathrm{AKMA}}$ from K.
• The channel between UE and MNO is secure since they have completed AKA.
• The channel between MNO and AF is secure [48]. If AF resides inside the mobile network, the channel can be assumed to be secure. If AF resides outside of the mobile network, then MNO and AF must authenticate each other, e.g., based on the client and server certificates, and establish a TLS connection.
• The channel between UE and AF is not secure.

The queries in the ProVerif code are designed to check security and authentication properties which are explained in Section 2.4. We provide details of the queries and how we constructed the AKMA protocol model in ProVerif in Appendix E.

4.2.3. Results

The result of the security properties we get when we run the protocol “AKMA.pv” [44] is summarized in AKMA column

Table 1. Summary of security properties for AKMA and PE-AKMA.

Security Properties		AKMA	PE-AKMA
Secrecy	SUPI	True	True
	K	True	True
	A-KID	False	True
	${\mathrm{K}}_{\mathrm{AKMA}}$	True	True
	${\mathrm{K}}_{\mathrm{AF}}$	True	True
Strong Secrecy	SUPI	True	True
	K	True	True
Weak Secrecy	SUPI	True	True
	K	True	True
Forward Secrecy	in UE	False	True
	in MNO	False	False

.

The secrecy result can be interpreted as (1) A-KID could be captured by the attacker, (2) the long-term key K, long-term identifier SUPI, AKMA key ${\mathrm{K}}_{\mathrm{AKMA}}$, and AF specific session key ${\mathrm{K}}_{\mathrm{AF}}$ are not learned by the attacker during the protocol.

The result of strong secrecy means that the attacker cannot distinguish whether the SUPI and K differ in different sessions. In addition, we can interpret the result of weak secrecy in such a way that AKMA does not enable brute-force attacks, e.g., dictionary attacks.

Keeping in mind that ID_AF is public, we can interpret the result for forward secrecy in the following way. If the attacker obtains K and SUPI either from the UE or MNO, then this attacker can derive the session keys ${\mathrm{K}}_{\mathrm{AF}}$ that are used to secure past communications. This is the assumption that the attacker recorded the past protocol messages exchanged over the public channel (including messages of the AKA protocol). Please note that the leakage of the secret key at the UE is shown to be possible via side-channel attacks [49].

Next, we discuss queries to check the authentication properties of AKMA. The results of running these queries are summarized in

Table 2. Summary of authentication properties for AKMA.

Authentication Properties	UE->AF	AF->UE	AF->MNO	MNO->AF
Aliveness	False	True	True	True
Weak Agreement	False	False	True	True
Non-Injective Agreement (A-KID)	False	False	True	True
Non-Injective Agreement (${\mathrm{K}}_{\mathrm{AF}}$)	False	False	True	False
Injective Agreement (A-KID)	False	False	–	–
Injective Agreement (${\mathrm{K}}_{\mathrm{AF}}$)	False	False	–	–

. As already mentioned in Section 2.2, AKMA, in itself, does not aim to provide authentication between UE and AF. However, for completeness, we have queries for checking authentication properties between those parties in the ProVerif model.

First, we check the aliveness of the parties. The result of the queries of aliveness is false for (1) UE with AF and true for (2) AF with UE, (3) MNO with AF, and (4) AF with MNO. If the attacker captures the messages of UE for AF and impersonates AF, UE completes the protocol without AF realizing it. Therefore, AKMA does not guarantee the aliveness of AF to UE. On the other hand, only the correct UE can send a valid A-KID, and if AF finds out in the dialogue with MNO that the A-KID is valid, AF can be sure that UE has at least started the protocol. Thus, AKMA guarantees the aliveness of UE to AF.

Second, we check queries for weak agreement. The result is that the MNO has a weak agreement with AF, and AF has a weak agreement with MNO, but AF does not have a weak agreement with UE. ProVerif has found the following attack. A-KID is sent in a public channel, and the Dolev–Yao adversary captures it. Afterward, the attacker inserts messages to the communication channel of UE and AF such that (1) AF receives a request even before UE sends the request or (2) UE receives a response from AF even before AF sends the response.

Third, we check non-injective agreement. The non-injective (and consequently injective) agreements do not hold between UE and AF because we have already seen that they do not obtain even weak agreements. Note that this is not a major shortcoming for AKMA because it is assumed to be used together with some follow-up protocol between UE and AF.

Non-injective agreements hold for AF to MNO on ${\mathrm{K}}_{\mathrm{AF}}$ and A-KID, and MNO to AF on A-KID. However, the non-injective (and consequently injective) agreement for MNO to AF on ${\mathrm{K}}_{\mathrm{AF}}$ does not hold. This is because ProVerif found a counter-example based on the fact that the protocol ends before MNO can verify whether AF has received the key ${\mathrm{K}}_{\mathrm{AF}}$.

Finally, ProVerif replies with “cannot be proved” to the queries for the injective agreements between AF to MNO on both A-KID and ${\mathrm{K}}_{\mathrm{AF}}$ and from MNO to AF on A-KID. This result means that ProVerif was not able to find proof that the injective agreement holds but, on the other hand, was not able to find a counter-example that would show it does not hold.

Yang et al. [45] prove the injective (and, therefore, also non-injective) agreement of MNO with AF and AF with MNO for A-KID and ${\mathrm{K}}_{\mathrm{AF}}$ using Tamarin. This partial contradiction between our and their results is because of the following. They have modeled the channel between MNO and AF not just as a secure channel but also as a reliable channel. Hence, the MNO gets confirmation of AF receiving the last message, which includes ${\mathrm{K}}_{\mathrm{AF}}$. In our ProVerif model, there is no such confirmation.

4.3. Analysis of AKMA and Its Formal Verification

The purpose of AKMA is to enable authentication between the user equipment (UE) and the application function (AF) and help them share a secret key using the MNO subscription. Therefore, we focus our formal verification on the authentication properties between UE and AF and between AF and MNO. We do not prove any agreement between UE and MNO with the formal verification. This is because: (1) before the AKMA protocol begins, UE and MNO have already completed primary authentication (5G AKA). Hence they have mutual authentication outside of our modeling; (2) they do not exchange messages during AKMA protocol.

We found the following issues related to A-KID being captured by the attacker.

• Revealing A-KID in public causes linkability issues, as already pointed put in Yang et al. [45]. The same A-KID means the same ${\mathrm{K}}_{\mathrm{AKMA}}$, which leads to the same SUPI, i.e., the same user. Unless the primary authentication is repeated, A-KID remains the same and continues to be used by the same user. Tracking the A-KID makes it easy to link the same user using many other applications.
• The attacker can send the A-KID to several different AFs, which UE does not intend to use, and can cause DoS attacks. In addition, this implies (honest-but-)curious MNO would get the wrong view about the AFs that UE runs AKMA with, and would draw an incorrect profile for UE.
• We found a new attack which is discussed in Section 4.4.

Another privacy issue with AF is that it learns SUPI or GPSI. As explained in Section 2.2, SUPI is sent to AF if AF is in the MNO network, and GPSI is sent otherwise. However, GPSI is MSISDN or an external identifier assigned to UE. Therefore, the same GPSI is sent to all the AFs that UE wants to connect to. If AFs share information, they can observe that the same user is using those other applications.

4.4. New Attack and Its Countermeasure

We will now describe a spoofing attack, where a malicious AF impersonates another AF towards a UE. As already explained in Section 2.2, we use the term MNO to cover all network functions that participate in the AKMA service.

3GPP TS 33.535 [14] Section 6.3 specifies how an external AF obtains the application key ${\mathrm{K}}_{\mathrm{AF}}$ from MNO. AF and MNO establish a TLS connection during this process, and AF sends the request for ${\mathrm{K}}_{\mathrm{AF}}$. The request message includes A-KID and ID-AF. The specification states that the MNO shall check whether it can provide the service to the AF based on the configured local policy or based on the authorization information available in the signaling. But it does not explicitly require the MNO to verify that the AF is authorized to use the ID-AF in the request. This opens the door for the following attack.

Assume that two application functions, AF1 and AF2, can both connect to MNO. Assume also that AF2 listens to the traffic between UE and AF1 and then captures the A-KID of the UE. Now, AF2 sends the A-KID and the identity of AF1 to MNO (Step 5 in Figure 3). If MNO does not verify that the received identity belongs to the correct AF, it will provide ${\mathrm{K}}_{\mathrm{AF}}$ to AF2. Now, AF2 can pretend to be AF1 towards the UE.

A different but related attack, where the attacker impersonates UE towards AF, is presented in [45]. This attack is due to the lack of weak agreement from AF to UE.

To prevent the attack where AF2 impersonates AF1 towards a UE, the MNO needs to verify the received ID-AF before deriving the ${\mathrm{K}}_{\mathrm{AF}}$ in Step 6 in Figure 3. We informed a 3GPP delegate about both the attack and its fix.

The predecessor of AKMA, generic bootstrapping architecture (GBA), does not face a similar problem. The 3GPP TS 33.220 [11] states that “with the key material request, the NAF shall supply a NAF-ID (which includes the NAF’s FQDN that the UE has used to access this NAF and the Ua security protocol identifier) to the BSF. The BSF shall verify that the NAF is authorized to use that FQDN”.

4.5. Description of PE-AKMA

Based on the formal verification results of AKMA in Section 4.2 and the subsequent discussions in Section 4.3, we developed a privacy-enhanced AKMA. The PE-AKMA protocol employs key and data encapsulation mechanisms (KEM and DEM, respectively) to protect the data that UE sends via the Application Function (AF) to MNO. The KEM and DEM concepts are explained in Appendix C.

Recall that the MNO, the UE, and the AF participate in the AKMA procedure. The MNO has identifiers of its subscribers (SUPI) and long-term keys (K). The MNO also has identifiers (ID-AF) of different AFs. In the privacy-enhanced AKMA (PE-AKMA), the MNO also has public and secret key pairs ($\mathrm{P}{\mathrm{K}}_{\mathrm{MNO}}$, $\mathrm{S}{\mathrm{K}}_{\mathrm{MNO}}$), and ${\mathrm{K}}_{\mathrm{MNO}}$.

The owner of the UE, Alice, is a subscriber of MNO, and she has an identifier SUPI for MNO, long-term key, K, and the public key of MNO, $\mathrm{P}{\mathrm{K}}_{\mathrm{MNO}}$. Alice also has a user identifier, user_id, and password, psw, for AF. During the PE-AKMA, Alice uses another key, locally generated ${\mathrm{K}}_{\mathrm{UE}}$, to compute a pseudonym to be used instead of her AF user identifier in the protocol.

The application function may reside in the mobile network or connect to the mobile network from outside. Either way, MNO authenticates and authorizes AF before providing the AKMA session key. The AF has an identifier ID-AF, and it knows the identifier ID-MNO of the MNO.

Figure 4 presents the privacy-enhanced AKMA protocol. The figure is adapted from 3GPP TS 33.535 [14]. The steps with red text are our additions to improve the privacy of the AKMA procedure. The PE-AKMA is explained in Protocol 2.

Protocol 2 Privacy-enhanced authentication and key management for applications (PE-AKMA)

Goal. Improve the privacy of AKMA considering the shortcomings discussed in Section 4.3. The protocol: Authentication and Key Agreement (AKA): UE runs AKA with MNO. (If an existing and valid shared key ${\mathrm{K}}_{\mathrm{AUSF}}$ is stored, this step can be skipped.) UE and MNO derive ${\mathrm{K}}_{\mathrm{AKMA}}$ from the shared key ${\mathrm{K}}_{\mathrm{AUSF}}$ and generate the AKMA key identifier (A-KID). Here, A-KID is composed of A-TID and ID-MNO. Derivation of credentials in UE: 3.  (a)  UE derives ${\mathrm{K}}_{\mathrm{AF}}$ for the AF from the ${\mathrm{K}}_{\mathrm{AKMA}}$ and ID-AF.  (b)  UE computes T=$\mathrm{HMA}{\mathrm{C}}_{{\mathrm{K}}_{\mathrm{UE}}}$(user_id, ID-AF) to conceal the user_id.  (c)  UE prepares the message $\mathrm{M}=\mathrm{A}\text{-}\mathrm{KID}\left|\mathrm{ID}\text{-}\mathrm{AF}\right|\mathrm{T}$.  (d)  UE starts encapsulation as described in Appendix C. UE applies Key-Encaps($\mathrm{P}{\mathrm{K}}_{\mathrm{MNO}}$) to obtain a ciphertext C and a shared key ${\mathrm{K}}_{\mathrm{sh}}$.  (e)  UE saves the key ${\mathrm{K}}_{\mathrm{sh}}$.  (f)  UE applies Data-Encaps(${\mathrm{K}}_{\mathrm{sh}}$, M) to obtain N.  (g)  UE derives ${\mathrm{K}}_{\mathrm{AF}}^{\prime }=\mathrm{KDF}({\mathrm{K}}_{\mathrm{sh}},{\mathrm{K}}_{\mathrm{AF}})$, where KDF is the key derivation function. This key will be the shared AKMA key between AF instead of ${\mathrm{K}}_{\mathrm{AF}}$. Session Establishment Request: 4. UE sends a session establishment request to AF with the parameters N, C, and ID-MNO. Fetching UE credentials: 5. AF sends a request to MNO for the application key by including N, C, and its own identifier ID-AF. 6.  (a)  MNO retrieves the ${\mathrm{K}}_{\mathrm{AKMA}}$ related to the A-KID and derives ${\mathrm{K}}_{\mathrm{AF}}$ from the ${\mathrm{K}}_{\mathrm{AKMA}}$ and ID-AF.  (b)  MNO starts decapsulation as described in Appendix C. MNO applies Key-Decaps($\mathrm{S}{\mathrm{K}}_{\mathrm{MNO}}$, C) and obtains ${\mathrm{K}}_{\mathrm{sh}}$ as an output.  (c)  MNO computes M=Data-Decaps$({\mathrm{K}}_{\mathrm{sh}},\mathrm{N})$, where $\mathrm{M}=\mathrm{A}\text{-}\mathrm{KID}\left|\mathrm{ID}\text{-}\mathrm{AF}\right|\mathrm{T}$.  (d)  MNO verifies that three ID-AFs (one that MNO has, one that UE included in M, and one that AF sent) are the same to ensure that the request of UE is sent from the correct AF.  (e)  MNO acquires the ${\mathrm{K}}_{\mathrm{AKMA}}$ related to A-KID and derives ${\mathrm{K}}_{\mathrm{AF}}$ using ID-AF.  (f)  MNO derives ${\mathrm{K}}_{\mathrm{AF}}^{\prime }=\mathrm{KDF}({\mathrm{K}}_{\mathrm{sh}},{\mathrm{K}}_{\mathrm{AF}})$.  (g)  MNO computes a hashed identifier H-ID=$\mathrm{HMA}{\mathrm{C}}_{{\mathrm{K}}_{\mathrm{MNO}}}\left(\mathrm{T}\right|\mathrm{SUPI}\left|\mathrm{ID}\text{-}\mathrm{AF}\right)$ to replace SUPI and GPSI. 7. MNO sends H-ID, ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$, and the expiration time of ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ to AF. Session Establishment Response: 8. AF sends a session establishment response to UE after obtaining the key.

4.6. Formal Verification of PE-AKMA

This section presents the formal verification of PE-AKMA using ProVerif.

4.6.1. Constructing the Protocol

The construction of the PE-AKMA protocol in ProVerif is similar to what we explained in Section 4.2, except for the new variables and the implementation of the key and data encapsulation mechanisms (KEM/DEM) explained in Appendix C in the PE-AKMA.

The queries in the ProVerif code are designed to check security and authentication properties, explained in Section 2.4. We provide details of the queries and how we constructed the PE-AKMA protocol model in ProVerif in Appendix F.

4.6.2. Results

Table 1 summarizes the security properties in AKMA and in PE-AKMA. The highlighted rows show that PE-AKMA prevents attackers from capturing A-KID and provides forward secrecy in UE.

Now, we explain the security properties of the new variables in PE-AKMA. In addition to the secrecy queries that were verified in the generic AKMA protocol, we have shown that the attacker cannot learn $\mathrm{S}{\mathrm{K}}_{\mathrm{MNO}}$, ${\mathrm{K}}_{\mathrm{sh}}$, and ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$.

The PE-AKMA protocol provides forward secrecy in the case where the secrets, K and SUPI, are leaked. That is because the key ${\mathrm{K}}_{\mathrm{sh}}$ remains secret. Consequently, past ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ remains safe from the attacker. Please note that if SK_MNO leaks, then the forward secrecy is broken. However, we argue that a compromise of the parameters in the UE, i.e., K and SUPI, is more likely than a compromise of the long-term secret keys in the MNO.

We defined queries to check the authentication properties of PE-AKMA. The results are summarized in

Table 3. Summary of authentication properties for PE-AKMA.

Authentication Properties	UE->AF	AF->UE	AF->MNO	MNO->AF
Aliveness	False	True	True	True
Weak Agreement	False	False	True	True
Non-Injective Agreement (N)	False	False	True	True
Non-Injective Agreement (${\mathrm{K}}_{\mathrm{AF}}^{\prime }$)	False	False	True	False
Injective Agreement (N)	False	False	–	–
Injective Agreement (${\mathrm{K}}_{\mathrm{AF}}^{\prime }$)	False	False	–	–

.

Aliveness holds for AF, with UE as the responder, while the weak agreement does not. Neither aliveness nor weak agreement holds for UE with AF as the responder. Please note that aliveness in this context means that AF is assured of the following. AF has a dialogue with MNO about certain UE and that UE has at least started the protocol. In contrast to AKMA, the AF does not obtain the SUPI (or GPSI) that identifies the UE in the mobile network. Instead, the AF obtains H-ID, i.e., a pseudonym of the UE.

ProVerif proves that MNO has a weak agreement with AF and AF has a weak agreement with MNO.

We introduced new keys and identifiers. Therefore, we have new queries for non-injective and injective agreements.

ProVerif shows that AF has a non-injective agreement with MNO on ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ and on N. In addition, MNO has a non-injective agreement with AF on N. However, MNO does not have a non-injective agreement with AF on ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ because the protocol ends before MNO can verify that AF has the key.

On the other hand, ProVerif cannot prove the injective agreements for AF and MNO, with similar reasons explained in Section 4.2.

Finally, the lack of weak agreement between the UE and AF implies that non-injective and injective agreements between UE and AF do not hold as well. We remark that the weak and non-injective agreements between the UE and AF would hold if a key confirmation round is added at the end of the protocol. Similar to AKMA, this is a minor shortcoming of PE-AKMA because it is assumed to be used with some follow-up protocol between UE and AF.

4.7. Remarks on the PE-AKMA

We improved AKMA considering the issues that are discussed in Section 4.3.

We added Step 6(d) in Protocol 2, where ID-AF is verified by the MNO, as a countermeasure against the attack described in Section 4.4. Even if a malicious AF captures N and C and sends those to MNO together with the ID-AF of some other AF, then, because of this countermeasure, the request will not be accepted by MNO.

We introduced KEM/DEM, explained in Appendix C, in the privacy-enhanced AKMA. In our threat model, we assume the presence of an active attacker in the channel between the UE and the AF. Thus, we recommend using KEMs providing resistance against such attackers, i.e., at least has the indistinguishability under chosen-plaintext attack (IND-CPA) property [50].

Usually, IND-CPA KEMs are built using (randomized) probabilistic encryption schemes [51]. Hence, we implemented the randomized KEMs in our ProVerif model. For the DEM, we use symmetric encryption with the key resulting from the KEM. To ensure further security properties [52], we equip the DEM with a message authentication code (MAC) check (Encrypt-then-MAC), which is the case in the standardized elliptic curve integrated encryption scheme (ECIES) [48].

We used the KEM/DEM paradigm to protect the message M in Step 3 in Figure 4 and to provide forward secrecy. Please note that using TLS with the AKMA protocol would provide forward secrecy, but with the introduction of KEM/DEM, we guarantee forward secrecy at the UE, also in those cases when UE and AF do not use TLS. In PE-AKMA, we use ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ instead of ${\mathrm{K}}_{\mathrm{AF}}$ as a session key. ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ is derived using freshly generated public and secret key pairs in UE. Therefore, even if K and SUPI are leaked, attackers cannot decrypt the earlier communication.

Our enhanced protocol can be used when it is not desirable that the MNO is able to learn the user_id in AF. To achieve this, we introduced a new identifier, T, which is derived by computing the keyed hash of user_id and ID-AF. The T is given to the MNO instead of the user_id as a unique identifier for the user. Then, the MNO does not learn the UE identifier related to this specific AF. Moreover, even if the user has the same user_id for different AFs, the MNO would not be able to recognize this since T also depends on the AF identifier.

If the application function does not require a user_id, then UE can compute T with a null value instead of the user_id in Step 3(b) of Figure 4.

We also recall that AKMA specifications (Section 6.6 of TS 33.535 [14]) include a case for anonymous user access. In order to use it, AF should indicate the anonymous user access request while sending the key request to MNO, Step 5 of Figure 3. Anonymous user access can also be adapted to PE-AKMA, such that AF indicates the request in Step 5 of Figure 4. Then, in Step 7, MNO does not send H-ID to AF. In this case, N is used as a temporary user identifier.

In addition, the user might want to stay anonymous towards the AF. To achieve this anonymity, the user prepares M in Step 3(c) of Figure 4 such that T is a null value. When MNO decrypts the message in Step 6(c) of Figure 4, it understands the anonymity request of the user by checking T and does not send H-ID later in Step 7. Similarly to the earlier case, N is used as a temporary user identifier. Note that N is different every time UE sends the session establishment request; therefore, AF does not learn that the two sessions belong to the same user.

Another feature of our protocol is based on the fact that in the standard AKMA, the MNO provides the UE identifiers, i.e., SUPI or GPSI, to AF along with the shared key ${\mathrm{K}}_{\mathrm{AF}}$. Such identifiers can be used to track the user. Therefore, we replaced SUPI/GPSI with H-ID to protect these identifiers from AF. H-ID is derived by computing the keyed hash of SUPI, T, and ID-AF. Therefore, H-ID is a unique identifier depending on UE, MNO, and AF. Note that AF does not even learn whether two user_ids belong to the same user.

4.8. AKMA Profiles for TLS

The specification of AKMA includes two profiles for applying AKMA when the UE connects to AF over TLS: (1) shared key-based UE authentication with certificate-based AF authentication; and (2) shared key-based mutual authentication between UE and AF [14]. They are based on the TLS profiles in the GBA specification [43].

This section shows how to apply the privacy-enhanced AKMA from Section 4.5 in profiles (1) and (2). The numbering of the steps of the profiles conforms with the numbering in the specifications [14,43]. The changes to the original profiles are indicated by red color in Figure 5 and Figure 6.

4.8.1. Profile 1: Shared Key-Based UE Authentication with Certificate-Based AF Authentication

This profile explains how AF is authenticated by UE with its certificate, while UE is authenticated later with the shared key resulting from AKMA. The procedure is described below in Protocol 3 and shown in Figure 5.

Figure 5. Profile 1 with PE-AKMA.

Figure 5. Profile 1 with PE-AKMA.

Protocol 3 AKMA Profile 1 for TLS with PE-AKMA

Goal. Adapting PE-AKMA to the AKMA Profile 1 for TLS-based protocols. The protocol: AF authentication for UE:  - TLS tunnel is established between UE and AF.  - The user authenticates the AF with its public key certificate, while UE is not authenticated by AF yet. UE authentication for AF: 2.  - UE sends an HTTP request to AF inside the TLS tunnel to establish the HTTPS connection.  - UE indicates that AKMA-based authentication is supported in the request.  - UE also includes the hostname of the AF in the HTTP header. 3.  - AF invokes HTTP digest with UE to perform client authentication.  - AF also checks if the product tokens in Step 2 indicate AKMA mode acceptable to AF.  - AF sends the constant string 3gpp-bootstrapping-AKMA and its fully qualified domain name (FQDN) to UE. 4.  - UE verifies the FQDN of AF.  - UE applies Step 3 of the PE-AKMA (Protocol 2). 5.  - UE sends the authorization header field with Digest to AF.  - The digest calculation includes N as the username (instead of A-KID) and ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ as the password (instead of ${\mathrm{K}}_{\mathrm{AF}}$).  - This step corresponds to Step 4 of the PE-AKMA (Protocol 2). 6.  - AF retrieves ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ from AAnF (MNO) using N.  - Steps 5–7 of PE-AKMA are run for the key retrieval.  - AF verifies the password attribute of the response after receiving the ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ from AAnF. Secure communication: 7.   UE and AF communicate over a mutually authenticated secure TLS tunnel.

4.8.2. Profile 2: Shared Key-Based Mutual Authentication between UE and AF

The second profile uses the shared key resulting from AKMA for mutual authentication. This profile does not require any certificate from the parties because it is based on Transport Layer Security Pre-Shared Key (TLS-PSK), about which more information is provided in Appendix D. The protocol is described in Protocol 4 and shown in Figure 6.

Figure 6. Profile 2 with PE-AKMA.

Figure 6. Profile 2 with PE-AKMA.

Protocol 4 AKMA Profile 2 for TLS with PE-AKMA

Goal. Adapting PE-AKMA to the AKMA Profile 2 for TLS-based protocols. The protocol: TLS-PSK request:  (a)  UE starts with preparing AKMA tokens by applying Step 3 of the PE-AKMA (Protocol 2).  (b)  UE also derives the TLS external PSK from ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$.  (c)  UE sends a ClientHello message indicating the TLS-PSK.     - The ClientHello message includes the hostname of AF as the server_name, 3GPP-AKMA as the PSK-identity namespace, and N (instead of A-KID) as the PSK-identity.     - This step corresponds to Step 4 of the PE-AKMA. TLS-PSK response: 2.  (a)  AF retrieves ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ from AAnF (MNO) using N. Steps 5–7 of PE-AKMA are run for the key retrieval.  (b)  AF derives the TLS external PSK from the ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ after receiving ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ from AAnF.  (c)  AF sends the ServerHello message, including the AKMA PSK identity.  (d)  UE replies with the Finish Message. Secure communication: 3.  UE and AF start using the TLS tunnel for application-level communication.

4.9. Feasibility of PE-AKMA and Profiles

Comparing AKMA with PE-AKMA, we first recall that the message flow and the number of exchanged messages between the parties are similar for both protocols. For the communication overhead, the request messages (Steps 4 and 5) in PE-AKMA consist of N, C, and ID-MNO instead of A-KID in AKMA. Please note that C is the ciphertext of KEM, while N is the message resulting from symmetric encryption of M=A-KID|ID-AF|T, where T=$\mathrm{HMA}{\mathrm{C}}_{{\mathrm{K}}_{\mathrm{UE}}}$(user_id, ID-AF).

To illustrate the size of these parameters, we should mention that 3GPP standardized the use of the ECIES KEM/DEM for the SUPI encryption in 5G AKA, see 3GPP TS 33.501 [48] Annex C. The KEM ciphertext in ECIES is 32 bytes. Moreover, the DEM utilizes a 128 bits AES in counter mode. The HMAC algorithm, the mentioned 3GPP standard, uses the HMAC SHA 256. Consequently, in Steps 4 and 5, PE-AKMA creates approximately 1 KB of overhead compared to AKA. In addition, in Step 7, the change is sending H-ID instead of SUPI, which is sending 256 bits instead of 64 bits. In summary, the communication overhead for each message is less than 1 KB.

Considering the computation overhead, we compare AKMA and PE-AKMA with respect to the used cryptographic operations, i.e., hash functions (including key derivation functions, message authentication codes), public key operations (including encryption, decryption, KEM, signing), and symmetric key operations (including encryption, decryption, DEM). Computationally, public key operations are heavier than hash functions or symmetric key operations.

The 5G UE and MNO already have the capacity to execute KEM/DEM for concealing SUPI during AKA; see [48]. In addition, KEM/DEM mechanism is used only once per PE-AKMA. Please note that PE-AKMA is compatible with any KEM, e.g., the recently standardized post-quantum KEMs by the National Institute of Standards and Technology in the USA (NIST).

Considering the computational cost per entity, UE computes only three hash functions in AKMA, whereas in PE-AKMA, it computes two additional hash functions, one public key operation, and one symmetric key operation. AF does not have any computation in AKMA or PE-AKMA. The MNO computes three hash functions in AKMA, whereas PE-AKMA also computes two hash functions, one public key operation, and one symmetric key operation.

In summary, there are a few more symmetric and public key operations in PE-AKMA than in AKMA. However, these operations are standardized and are already used in 5G UE and 5G networks. Therefore, it is feasible to adapt PE-AKMA.

The communication and computational overheads in privacy-enhanced AKMA profiles, described in Section 4.8, compared to generic AKMA profiles, described in [14], are the same as the overheads of PE-AKMA over AKMA.

5. Protocols for Accessing to MEC Application

This section presents a solution to maintain security and privacy for the MEC applications intended for static and mobile users. The solution is based on adapting the privacy-enhanced AKMA and AKMA profiles, shown in Section 4.5 and Section 4.8, respectively.

The setting can be illustrated by the following scenario. Alice is an MNO subscriber and uses an application called APPIFY. The application APPIFY appears both in the form of the main server of APPIFY (S-APPIFY) and as the local APPIFY server instance in the MEC host (M-APPIFY). Alice uses AKMA to authenticate herself to APPIFY.

The S-APPIFY has a key pair consisting of a public encryption key and a secret decryption key (EK, DK). The users of APPIFY utilize the public key EK to encrypt their identifiers. ID-APPIFY and ID-MNO are the identifiers of S-APPIFY and MNO, respectively, and are known by the users and also by S-APPIFY and MNO themselves. Alice has her subscription permanent identifier (SUPI) for the MNO context and identifier–password pair (Alice13, psw) for the APPIFY context.

Our solution consists of four protocols: 5A, 5B, 5C, and 5D. Protocols 5A and 5B are executed between Alice and the S-APPIFY. Protocol 5A is used to register a new user or a new trusted device to the main server of APPIFY. Protocol 5B is run for renewing the public key EK of S-APPIFY and shared keys related to the users. This protocol is also run to establish a secure connection between Alice directly and S-APPIFY for the purpose of providing services to Alice from the main server. Protocol 5C is executed between Alice and M-APPIFY when Alice wants to use services provided by APPIFY in the MEC host. Protocol 5D is used when Alice is moving while using APPIFY in the MEC host, and the serving MEC host and the M-APPIFY server have to be changed. The section ends with an analysis of our solution.

In Protocols 5A and 5B, a transport layer security (TLS) connection is established between Alice and the main server of APPIFY. One good solution is to use enhanced Profile 1, described earlier in Section 4.8.1.

A secure channel between Alice and MEC host [53], e.g., a TLS or datagram transport layer security (DTLS) connection, is established in Protocols 5C and 5D. This secure channel establishment is based either on a certificate of the MEC host or on a pre-shared key PSK method with a key that results from the run of AKMA between Alice and MEC, as with Profile 2, described in Section 4.8.2. We leave out of the scope of this paper further details of the secure channel between Alice and MEC.

Next, we explain the four protocols of our solution.

5.1. Protocol 5A: Signing Up

Protocol 5A is run when a new user wants to sign up, or a registered user wants to add a new trusted device. In this context, a new device implies that the user also has a new SUPI. Protocol 5A runs between Alice and S-APPIFY through MNO. We use Profile 1 (Protocol 3 in Section 4.8.1) with PE-AKMA for key distribution between Alice and S-APPIFY. The protocol is explained below, and the communication flow is shown in Figure 7.

Protocol 5 A: Signing Up

Goal. Key sharing when signing up a new user or adding a new device by a registered user. The protocol: 1. Alice runs AKA with MNO. (If an existing and valid shared key ${\mathrm{K}}_{\mathrm{AUSF}}$ is stored, this step can be skipped.) Establishing secure connection and authentication of S-APPIFY: 2. Alice and S-APPIFY run Steps 1–3 of Profile 1 (Protocol 3 in Section 4.8.1). This step includes the TLS connection establishment and the HTTP request of Alice. Moreover, S-APPIFY starts client authentication via AKMA. Authentication of UE: 3. Alice runs Step 4 of Profile 1, which includes verifying the FQDN of S-APPIFY and computing AKMA parameters, e.g., N and ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$. Note that a key derived from ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ is used as a shared key instead of ${\mathrm{K}}_{\mathrm{AF}}$. 4. Alice runs Step 5 of Profile 1, i.e., sends a session establishment request including the parameter N as username and the key ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ as password. 5. Alice then sends Alice13, psw, and a selected option to S-APPIFY through the secure channel. The options are (1) new user registration and (2) registering a new device. 6. S-APPIFY checks the database for Alice13 and psw.  If Alice13 is not found in the database:   If Option (1) is selected, then S-APPIFY stores Alice13 and psw in the database, and the protocol continues with Step 7.   If Option (2) is selected, then the protocol continues with Step 7* with the message “either wrong username or wrong psw”.  If Alice13 is found in the database:   If Option (1) is selected, then the protocol continues with Step 7* with the message “user identity is already chosen, please choose another user identity”.   If Option (2) is selected, we still have two cases:    If psw is correct: The protocol continues with Step 7.    If psw is not correct: The protocol continues with Step 7* with the message “either wrong username or wrong password”. 7*. S-APPIFY sends the error message, and the protocol is aborted. Key Confirmation of ${\mathrm{K}}_{\mathrm{AF}}$ for S-APPIFY: 7. S-APPIFY runs Step 6 of Profile 1 to obtain ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ from MNO. Then, it verifies that this key matches with the one that UE sent earlier. UE and S-APPIFY are now able to communicate over mutually authenticated TLS channel (Step 7 of Profile 1). 8.  (a)  S-APPIFY stores the pair (H-ID, ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$), sent in Step 7, and associates it with Alice13 and psw.  (b)  S-APPIFY computes the hash H(${\mathrm{K}}_{\mathrm{AF}}^{\prime }$) as an identifier of the (H-ID, ${\mathrm{K}}_{\mathrm{AF}}$) pair to be used later in Protocol 5C in Section 5.3.  (c)  S-APPIFY computes $\mathrm{MA}{\mathrm{C}}_{{\mathrm{K}}_{\mathrm{AF}}^{\prime }}\left(\mathrm{EK}\right)$. Note that S-APPIFY already verified that Alice has the shared key, but Alice did not verify the converse. Key Confirmation of ${\mathrm{K}}_{\mathrm{AF}}$for Alice: 9. S-APPIFY sends Alice13, EK, and $\mathrm{MA}{\mathrm{C}}_{{\mathrm{K}}_{\mathrm{AF}}^{\prime }}\left(\mathrm{EK}\right)$ along with the success message to Alice over the TLS channel. 10. Alice verifies $\mathrm{MA}{\mathrm{C}}_{{\mathrm{K}}_{\mathrm{AF}}^{\prime }}\left(\mathrm{EK}\right)$.  If the verification is successful: The protocol continues with Step 11.  If the verification is a failure: The protocol continues with Step 11*. 11. Alice sends a success message to S-APPIFY. Further communication continues over TLS; for example, the profile settings can be updated. 11*. Alice sends an error message “MAC failure” to S-APPIFY and the protocol is aborted.

5.2. Protocol 5B: Signing In

Protocol 5B is run when the user and their devices are already registered and the user wants to connect to the main server. The user can renew the shared keys or use APPIFY from the main server. Protocol 5B runs between Alice and S-APPIFY and includes MNO. We use Profile 1 (Protocol 3 in Section 4.8.1) with PE-AKMA for key distribution between Alice and S-APPIFY. The protocol is explained below, and the communication flow is shown in Figure 8.

Protocol 5 B: Signing In

Goal. Key sharing, when the user and their devices are already registered and using the main server. The protocol: Alice runs AKA with MNO. (If an existing and valid shared key ${\mathrm{K}}_{\mathrm{AUSF}}$ is stored, this step can be skipped.) Establishing a secure connection and authentication of S-APPIFY: 2. Alice and S-APPIFY run Steps 1–3 of Profile 1 (Protocol 3 in Section 4.8.1). This step includes the TLS connection establishment and the HTTP request of Alice. Moreover, S-APPIFY starts client authentication via AKMA. Authentication of UE: 3. Alice runs Step 4 of Profile 1, which includes verifying the FQDN of S-APPIFY and computing AKMA parameters, e.g., N and ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$. Note that a key derived from ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ is used as a shared key instead of ${\mathrm{K}}_{\mathrm{AF}}$. 4. Alice runs Step 5 of Profile 1, i.e., sends a session establishment request including the parameter N as username and the key ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ as password. 5. Alice sends Alice13 and the selected option to S-APPIFY through the secure channel. The options are (1) Renewing EK and (2) Signing into the main server. In both options, ${\mathrm{K}}_{\mathrm{AF}}$ is updated. 6.  (a)  S-APPIFY checks the database for Alice13.      If Alice13 is found in the database: The protocol continues with Step 6b.      If Alice13 is not found in the database: The protocol goes to Step 9*.  (b)  S-APPIFY fetches the H-ID(s) related to the identity Alice13. Note that Alice may use the application from several different devices, and there would be different H-IDs for each device. Key Confirmation of ${\mathrm{K}}_{\mathrm{AF}}$ for S-APPIFY: 7. S-APPIFY run Step 6 of Profile 1 to obtain ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ from MNO. Then, it verifies that this key agrees with the one that UE sent earlier. UE and S-APPIFY are now able to communicate over mutually authenticated TLS channel (Step 7 of Profile 1). 8.  (a)  S-APPIFY checks if the H-ID sent by MNO matches any existing H-ID(s) found in Step 6b.      If H-ID matches: The protocol continues with Step 8b.       If there is an existing ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$, which is replaced by the new one.       If there is no existing ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$, it is saved.      If H-ID does not match: The protocol goes to Step 9*.  (b)  S-APPIFY computes the hash H(${\mathrm{K}}_{\mathrm{AF}}^{\prime }$) as an identifier of the (H-ID, ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$) pair to be used later in Protocol 5C.  (c)  S-APPIFY computes $\mathrm{MA}{\mathrm{C}}_{{\mathrm{K}}_{\mathrm{AF}}^{\prime }}\left(\mathrm{EK}\right)$. Key Confirmation of ${\mathrm{K}}_{\mathrm{AF}}$for Alice: 9. S-APPIFY sends EK and $\mathrm{MA}{\mathrm{C}}_{{\mathrm{K}}_{\mathrm{AF}}^{\prime }}\left(\mathrm{EK}\right)$ along with the success message to Alice. 9*. Error message “Either wrong username or authentication has failed” is sent by S-APPIFY, and the protocol is aborted. 10. Alice verifies $\mathrm{MA}{\mathrm{C}}_{{\mathrm{K}}_{\mathrm{AF}}^{\prime }}\left(\mathrm{EK}\right)$.  If the verification is successful: UE stores EK and the protocol continues with Step 11.  If the verification is a failure: The protocol goes to Step 11*. 11. Alice sends a success message to S-APPIFY. Further communication continues over TLS; for example, the profile settings can be updated. 11*. Alice sends an error message “MAC failure” to the main server of APPIFY, and the protocol is aborted.

5.3. Protocol 5C: Connecting to Application in MEC Host

Protocol 5C is run when at least Protocol 5A or Protocol 5B is run between Alice and S-APPIFY. Thus, Alice has up-to-date keys for the main server and wants to use M-APPIFY. The entities, MNO, MEC, M-APPIFY, and S-APPIFY, participate in this protocol. Protocol 5C is explained below, and the communication flow is shown in Figure 9.

At the beginning of the protocol, Alice has her identities SUPI for MNO and Alice13 for APPIFY. She also has psw, public key EK of S-APPIFY, and ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$. MNO knows the SUPI of Alice and has saved ${\mathrm{K}}_{\mathrm{AKMA}}$ and A-KID relating to the SUPI. S-APPIFY has the public key EK and saved Alice13, psw, (H-ID, ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$), and H(${\mathrm{K}}_{\mathrm{AF}}^{\prime }$) in the database. MEC and M-APPIFY do not have any information on the user.

Protocol 5 C: Connecting to MEC APPIFY

Goal. Establishing a secure and privacy-preserving connection with MEC APPIFY. The protocol: Secure communication with MEC: Alice and MEC establish a secure connection, e.g., DTLS connection. Derivation of credentials in UE of Alice: 2.  (a)  Alice computes the hash H(${\mathrm{K}}_{\mathrm{AF}}^{\prime }$).  (b)  Alice generates a random X.  (c)  Alice encrypts her identifier Alice13, X, and H(${\mathrm{K}}_{\mathrm{AF}}^{\prime }$) by using the public key of S-APPIFY EK: M=${\mathrm{E}}_{\mathrm{EK}}(\mathrm{Alice}13,\mathrm{X},\mathrm{H}\left({\mathrm{K}}_{\mathrm{AF}}^{\prime }\right))$. Request for the session with M-APPIFY: 3. Alice sends the ID-APPIFY and M to MEC through the secure channel. 4. MEC notices the identifier of S-APPIFY and forwards the message M to M-APPIFY. 5. M-APPIFY forwards M to S-APPIFY. Distribution of session credentials: 6.  (a)  S-APPIFY decrypts M with its secret key DK.  (b)  S-APPIFY then checks the database for Alice13.      If Alice13 is in the database: S-APPIFY obtains the related identifiers and keys, e.g., ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ that matches $\mathrm{H}\left({\mathrm{K}}_{\mathrm{AF}}^{\prime }\right)$.       If there is an existing ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$, the protocol continues with Step 6c.       If there is no existing ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$, the protocol continues with Step 6* with the error message “Run Protocol 5B”.      If Alice13 is not in the database: The protocol continues with Step 6* with the error message “User is not found”.  (c)  S-APPIFY derives a new key ${\mathrm{K}}_{\mathrm{AFD}}$=KDF(${\mathrm{K}}_{\mathrm{AF}}^{\prime }$, ID-M-APPIFY, Alice13, X), where the ID-M-APPIFY is the identifier of M-APPIFY. 6* The error message is sent, and the protocol is aborted. 7. S-APPIFY sends ${\mathrm{K}}_{\mathrm{AFD}}$, Alice13, X, the user profile of Alice13, and the expiration time of ${\mathrm{K}}_{\mathrm{AFD}}$ to M-APPIFY. 8.  (a)  M-APPIFY stores Alice13, ${\mathrm{K}}_{\mathrm{AFD}}$, and the expiration time of ${\mathrm{K}}_{\mathrm{AFD}}$.  (b)  M-APPIFY encrypts ET=${\mathrm{E}}_{{\mathrm{K}}_{\mathrm{AFD}}}\left(\mathrm{expiration}\mathrm{time}\mathrm{of}{\mathrm{K}}_{\mathrm{AFD}}\right)$.  (c)  M-APPIFY computes Y=$\mathrm{MA}{\mathrm{C}}_{{\mathrm{K}}_{\mathrm{AFD}}}$(ID-M-APPIFY, Alice13, X). 9. M-APPIFY sends ID-M-APPIFY, Y, and ET to MEC. 10. MEC forwards ID-M-APPIFY, Y, and ET to Alice. 11.  (a)  Alice derives ${\mathrm{K}}_{\mathrm{AFD}}$=KDF(${\mathrm{K}}_{\mathrm{AF}}^{\prime }$, ID-M-APPIFY, Alice13, X) after receiving ID-M-APPIFY.  (b)  Alice then decrypts ${\mathrm{D}}_{{\mathrm{K}}_{\mathrm{AFD}}}\left(\mathrm{ET}\right)$ and stores the expiration time of ${\mathrm{K}}_{\mathrm{AFD}}$.  (c)  Alice computes $\mathrm{MA}{\mathrm{C}}_{{\mathrm{K}}_{\mathrm{AFD}}}$(ID-M-APPIFY, Alice13, X) and verifies whether it matches Y.      If the verification is successful: The protocol continues with Step 12.      If the verification is a failure: The protocol continues with Step 12*. Secure communication with M-APPIFY: 12. Alice and M-APPIFY establish a TLS connection with a pre-shared key (TLS-PSK), where the key is ${\mathrm{K}}_{\mathrm{AFD}}$. Communication proceeds securely with this key. 12*. Error message “MAC Failure” is sent, and the protocol is aborted.

The application may have a time limit that defines how long a user remains signed in for S-APPIFY and M-APPIFY. After that time, the user is kicked out, which means the TLS connection is dropped.

Alice may want to re-establish a connection with the same M-APPIFY after some time, assuming the time limit is not over. In this case, the following steps are followed.

• Is the TLS connection still on?
  • Yes: Protocol 5C continues with Step 12.
  • No: Is ${\mathrm{K}}_{\mathrm{AFD}}$ is still valid?
    • Yes: TLS session resumption [54] is run with the key ${\mathrm{K}}_{\mathrm{AFD}}$, and Protocol 5C continues with Step 12.
    • No: Alice needs to start Protocol 5C from Step 1. If Alice does not have ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ stored, she first needs to run Protocol 5B to renew the key ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$.

5.4. Protocol 5D: Changing the MEC Host

Protocol 5D is run when Alice, who is actively using M-APPIFY (this means Alice and M-APPIFY are in Step 12 of Protocol 5C), is also moving. Let us recall the case where Alice travels from one city to another in the same country, say from Helsinki to Tampere. While she moves, the MEC host that provides services to Alice changes. During this trip, MNO might or might not change. We focus on the case where MNO does not change and leave the extension to the roaming case for future work.

Protocol 5 D: Changing to MEC APPIFY in another MEC host

Goal. Transferring the connection with MEC APPIFY in one MEC host to MEC APPIFY in another MEC Host through the main server in a secure and privacy-preserving way. The protocol: Ongoing secure communication with M-APPIFY: 0. The protocol starts when there is an existing connection between Alice and source M-APPIFY resulting from Protocol 5C, i.e., Step 12 of Protocol 5C. Request for MEC transfer: 1.  - When MEO determines the target MEC host, MEO provides this information to the source MEC host.  - Source MEC notifies source M-APPIFY that the connection of Alice13 is being transferred to another MEC host and M-APPIFY. 2. Source M-APPIFY sends Alice13, ${\mathrm{K}}_{\mathrm{AFD}}$, and the target MEC host information to S-APPIFY. Source M-APPIFY also sends the service state information of Alice13. This state information was already mentioned in Section 1. Distribution of session credentials: 3.  (a)  S-APPIFY generates a random R.  (b)  S-APPIFY encrypts R with ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$: ${\mathrm{E}}_{{\mathrm{K}}_{\mathrm{AF}}^{\prime }}\left(\mathrm{R}\right)$.  (c)  S-APPIFY derives the key ${\mathrm{K}}_{\mathrm{AFD}}^{\prime }$=KDF(${\mathrm{K}}_{\mathrm{AF}}^{\prime }$, ID-M-APPIFY-T, Alice13, R) where ID-M-APPIFY-T is the identifier of the target M-APPIFY. 4. S-APPIFY sends ${\mathrm{K}}_{\mathrm{AFD}}^{\prime }$, Alice13, R, user profile, service state information of Alice13, and the expiration time of ${\mathrm{K}}_{\mathrm{AFD}}^{\prime }$ to the target M-APPIFY. 5.  (a)  Target M-APPIFY stores Alice13, ${\mathrm{K}}_{\mathrm{AFD}}^{\prime }$, R, user profile, service state information of Alice13, and the expiration time of ${\mathrm{K}}_{\mathrm{AFD}}^{\prime }$.  (b)  Target M-APPIFY encrypts ET’=${\mathrm{E}}_{{\mathrm{K}}_{\mathrm{AFD}}^{\prime }}$(expiration time of ${\mathrm{K}}_{\mathrm{AFD}}^{\prime }$). 6. Target M-APPIFY sends an acknowledgment to S-APPIFY that it received the message. 7. S-APPIFY sends ${\mathrm{E}}_{{\mathrm{K}}_{\mathrm{AF}}^{\prime }}\left(\mathrm{R}\right)$, ID-M-APPIFY-T, and ET’ to the source M-APPIFY. 8. Source M-APPIFY sends ${\mathrm{E}}_{{\mathrm{K}}_{\mathrm{AF}}^{\prime }}\left(\mathrm{R}\right)$, ID-M-APPIFY-T, ET’, and the target MEC host information to Alice. 9.  (a)  Alice decrypts ${\mathrm{E}}_{{\mathrm{K}}_{\mathrm{AF}}^{\prime }}\left(\mathrm{R}\right)$ with ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ to retrieve R.  (b)  Alice derives ${\mathrm{K}}_{\mathrm{AFD}}^{\prime }$=KDF(${\mathrm{K}}_{\mathrm{AF}}^{\prime }$, ID-M-APPIFY-T, Alice13, R).  (c)  Alice then decrypts ${\mathrm{D}}_{{\mathrm{K}}_{\mathrm{AFD}}^{\prime }}\left(\mathrm{E}{\mathrm{T}}^{\prime }\right)$.  (d)  Alice stores the expiration time of ${\mathrm{K}}_{\mathrm{AFD}}^{\prime }$. Secure communication with target MEC: 10. Alice establishes a secure connection with the target MEC host, e.g., a DTLS connection. Secure communication with target M-APPIFY: 11. Alice sends R with ID-APPIFY to the target MEC host. 12. Target MEC host forwards R to the target M-APPIFY. 13. Target M-APPIFY checks the database for R and finds related data as Alice13, ${\mathrm{K}}_{\mathrm{AFD}}^{\prime }$, and the user information. 14. Target M-APPIFY initiates a TLS-PSK connection with Alice with the key ${\mathrm{K}}_{\mathrm{AFD}}^{\prime }$.

There may be no available MEC host with M-APPIFY near where the user is moving to. In this case, Alice continues to be served through S-APPIFY, and Protocol 5B is run. This can be enhanced by an option where the source M-APPIFY informs the main server about losing connection to Alice13. We do not explain this option further and leave it for future  work.

When Alice is moving and she is about to leave the service area of the MEC host, MEC orchestrator (MEO) finds the target MEC host and the target M-APPIFY [6]. Protocol 5D is explained step by step below, and the communication flow is shown in Figure 10.

When the TLS connection between Alice and target M-APPIFY is established successfully, target M-APPIFY continues providing the services to Alice instead of the source M-APPIFY. Note that until this happens, Alice has been receiving services from the source M-APPIFY. The TLS connection with source M-APPIFY is terminated when the TLS connection with target M-APPIFY is established. If the connection with source M-APPIFY is lost before the connection with target M-APPIFY is established, the service continues with the main server.

6. Analysis

In this section, we provide a feasibility, security, and privacy analysis of the solution that is presented in Section 5.

6.1. Feasibility Analysis

Our solution uses the privacy-enhanced version of 3GPP AKMA for the authentication and key sharing between the user Alice and the main server of the application S-APPIFY in Protocol 5A (Section 5.1) and Protocol 5B (Section 5.2). The shared key resulting from AKMA is used later in Protocol 5C (Section 5.3) and Protocol 5D (Section 5.4) when Alice wants to obtain service from the M-APPIFY.

It makes sense to utilize the AKMA service in our setting because AKMA is created in 5G to support applications, and APPIFY is one such application. MNO already verifies the identity of the user during the subscription and already authenticates the user during the network access. Therefore, AKMA is using the capability of MNO to help the user and S-APPIFY authenticate each other. In addition, AKMA is a better option for authentication, and key sharing between Alice and S-APPIFY compared to, e.g., a solution where S-APPIFY creates a random key and sends it back to Alice. If one of the parties loses the shared key, the recovery of the keys between these parties requires less effort with AKMA.

Our solution works well in the situation when the user having a single user_id is using several devices, each with a different SUPI. Then, there would be an (H-ID, ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$) pair corresponding to each device, associated with that user_id in S-APPIFY. When the user runs Protocol 5C, M-APPIFY receives the user profile and continues serving the user with the correct device.

In Section 4.9, we showed that PE-AKMA is a feasible solution and that adapting it to AKMA TLS Profiles 1 and 2, defined in 3GPP TS 33.535 [14], is also feasible.

Protocols 5A and 5B are based on the privacy-enhanced Profile 1, described in Section 4.8.1. The communication overhead of Protocols 5A and 5B, compared to PE-AKMA Profile 1, is one extra message with a length smaller than 0.5 KB. We also included key confirmation for Alice to the protocols. Since this key confirmation is embedded in the success messages, the message length in Step 9 increases, but the increment is less than 1 KB. Computational overhead includes one database search, two hash functions in S-APPIFY, and one hash function for Alice.

Protocol 5C is based on the MEC architecture defined in [6]. For communication cost, the additional messages over those in [6] are for secure channel establishments, e.g., DTLS and TLS, in Steps 1 and 12 in Protocol 5C. In order to implement privacy protection, Protocol 5C includes an additional public key and symmetric key operations and hash functions. The UE computes three hash functions, one public key operation, and one symmetric key operation. The M-APPIFY computes one hash function and one symmetric key operation, whereas S-APPIFY does one database search and computes one hash function and one public key operation. Note that MNO and MEC do not have any additional computational load due to the run of Protocol 5C.

ETSI GR MEC 021 [7] defines three ways to transfer user context between the source and target M-APPIFYs. We chose to move the user context via the main server of the MEC application. Similar to Protocol 5C, the number of messages in Protocol 5D does not change compared to the solution in [7], other than the messages needed to establish DTLS/TLS connections. The following is the computational overhead in Protocol 5D. The UE computes one hash function and two symmetric key operations; the target M-APPIFY computes one symmetric key operation; S-APPIFY computes one hash function and one symmetric key operation.

Overall, the privacy improvements require somewhat more storage and computation. DTLS and TLS connections constitute the communication overheads to obtain privacy. These protocols are based on state-of-the-art systems, and the functions used in the protocols are standardized.

In summary, our design uses well-known techniques to improve the privacy of MEC users in the 5G system. We conclude that it is feasible to implement our solution.

6.2. Security Analysis

It is natural to use usernames and passwords for accessing the applications. However, when Alice uses PE-AKMA in Protocols 5A and 5B, she does not need to enter her password for the application every time she uses the application. This is convenient and also decreases the chance of the password being compromised.

In our solution, secure communication channels are established between the parties, which protects the integrity and confidentiality of the messages sent. The channel between Alice and MNO is secured after the Authentication and Key Agreement (AKA) is run.

In Protocols 5A and 5B, the AKMA profile 1 with PE-AKMA for TLS-based protocols (Section 4.8.1) is used. Consequently, a TLS connection is established between Alice and the main server of APPIFY before she sends her identifiers and password. Therefore, Alice can be sure that she is talking to the correct server, and that these identifiers and passwords are not visible to outsiders or MNO.

Protocols 5C and 5D focus on the usage of APPIFY in MEC hosts. Therefore, there should also be a secure connection between Alice and MEC host, e.g., DTLS is used for this purpose. The handshake can be based on a pre-shared key (resulting from AKMA) or a certificate. Moreover, 3GPP defines the usage of AKMA in the technical documents [10]. We do not discuss how to secure the connection between the user and MEC host further.

Studies in 3GPP focus on the authentication between Alice and MEC host, and between Alice and MEC system. In this paper, we focus on authentication at the application level. We use privacy-enhanced AKMA to provide mutual authentication between the user and the main server of the application. As a product of PE-AKMA, the user and the main server of the application share a key. Another application-specific key, derived from the shared key, is then used to secure the connection between the user and the MEC application, e.g., TLS-PSK in Protocols 5C and 5D. This newly derived key depends on the MEC application. Therefore, whenever the user wants to connect to a MEC application in a different MEC host, a new key can be derived from the shared AKMA key without needing to run AKMA again. In addition, since the same key is not used with different MEC hosts, the key is less likely to be compromised.

6.3. Privacy Analysis

The TLS connection between Alice and M-APPIFY protects the communication from outsiders and honest-but-curious entities of the system model, e.g., MNO and MEC host. These honest-but-curious entities aim to learn as much as possible without interfering with the communication protocol [41]. In order to preserve the privacy of the user, MNO, MEC, and APPIFY should not learn anything related to the user that is not needed for providing services.

The privacy of the user is preserved against MNO with our solution. MNO learns that Alice uses S-APPIFY since PE-AKMA is run between these two entities. However, MNO cannot know whether or when Alice is using M-APPIFY.

MNO cannot learn the identifier of Alice for APPIFY, Alice13, or her password, because these are sent to S-APPIFY in Protocols 5A and 5B after the TLS connection is established. Similarly, in Protocols 5C and 5D, Alice first establishes a secure connection with the MEC host and then sends her identifier, which is encrypted with the public key of the main server. This latter encryption protects the privacy of the identifier against honest-but-curious MEC hosts.

In addition, the communication between Alice and S-APPIFY continues over the TLS channel in Protocols 5A and 5B, so MNO cannot see the data sent between the two parties. In Protocols 5C and 5D, the secure channel between Alice and MEC and the TLS channel between Alice and M-APPIFY prevents MNO from seeing the content sent between Alice and M-APPIFY.

Regarding the TLS channel between Alice and M-APPIFY in Protocols 5C and 5D, we introduced a derived key ${\mathrm{K}}_{\mathrm{AFD}}$ instead of ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ as a pre-shared key. Since MNO knows the key ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ but not the derived one, MNO would not be able to decrypt the communication channel. Therefore, MNO cannot learn the content of communication of Alice with either S-APPIFY or M-APPIFY.

Deriving ${\mathrm{K}}_{\mathrm{AFD}}$ helps to use several M-APPIFYs without the need to repeat AKMA with S-APPIFY for each connection. The derived key is relevant because using the same ${\mathrm{K}}_{\mathrm{AF}}^{\prime }$ itself to secure communications with different M-APPIFYs is not a recommended practice.

The privacy of the user is also preserved against MEC. Alice sends her identifier Alice13 after encrypting it with the public key of the main server. Moreover, the TLS connection between Alice and M-APPIFY prevents MEC from learning the content of the messages between Alice and M-APPIFY. Therefore, MEC cannot learn identifiers of Alice or the details of the services she obtains from M-APPIFY.

Finally, the privacy of the user is preserved against APPIFY (both S-APPIFY and M-APPIFY). The privacy enhancements that we propose to AKMA protect the identity of the user from S-APPIFY in Protocols 5A and 5B. In Protocols 5C and 5D, Alice does not use her identifier for MNO because she shared the key and agreed on her application-specific identifier with S-APPIFY.

7. Final Remarks

We started with creating a secure and privacy-preserving connection between a mobile user and the MEC application in the local MEC host. The scope is restricted to the non-roaming case, where the mobile user may change MEC hosts but stays in the same mobile network.

We propose a solution that is based on the 3GPP authentication and key management for applications (AKMA). First, we conducted a formal verification of AKMA using ProVerif and found a new spoofing attack on AKMA, as well as several privacy vulnerabilities in the current AKMA specification. Second, we designed and formally verified a privacy-enhanced AKMA, where the spoofing attack is prevented and privacy vulnerabilities are mitigated. Finally, we adapted the privacy-enhanced AKMA in our solution.

One limitation of our study is that AKMA still needs to be deployed. Therefore, observing the limits of AKMA in practice and experimenting with our solution are left for future work. Future work could also include the roaming case, where the source and the target MEC hosts belong to different mobile network operators.