A Lightweight and Privacy-Preserving Authentication Protocol for Mobile Edge Computing

TL;DR

This paper introduces a lightweight, ECC-based mutual authentication protocol tailored for Mobile Edge Computing environments, enhancing security while reducing computational and communication overheads in resource-constrained settings.

Contribution

It proposes a novel, efficient authentication scheme for MEC that addresses security issues and minimizes overhead compared to existing solutions.

Findings

Reduces communication overhead compared to existing schemes

Resists impersonation, replay, and man-in-the-middle attacks

Suitable for resource-constrained MEC environments

Abstract

With the advent of the Internet-of-Things (IoT), vehicular networks and cyber-physical systems, the need for real-time data processing and analysis has emerged as an essential pre-requite for customers' satisfaction. In this direction, Mobile Edge Computing (MEC) provides seamless services with reduced latency, enhanced mobility, and improved location awareness. Since MEC has evolved from Cloud Computing, it inherited numerous security and privacy issues from the latter. Further, decentralized architectures and diversified deployment environments used in MEC platforms also aggravate the problem; causing great concerns for the research fraternity. Thus, in this paper, we propose an efficient and lightweight mutual authentication protocol for MEC environments; based on Elliptic Curve Cryptography (ECC), one-way hash functions and concatenation operations. The designed protocol also leverages the advantages of discrete logarithm problems, computational Diffie-Hellman, random numbers and time-stamps to resist various attacks namely-impersonation attacks, replay attacks, man-in-the-middle attacks, etc. The paper also presents a comparative assessment of the proposed scheme relative to the current state-of-the-art schemes. The obtained results demonstrate that the proposed scheme incurs relatively less communication and computational overheads, and is appropriate to be adopted in resource constraint MEC environments.

Tables

Table 1. TABLE I: Illustrative comparison of security features supported by the proposed and existing authentication protocols.

Protocols	Tsai et al.[9]	Irshad et al.[11]	Jia et al.[8]	Proposed
$𝔖{𝔉}_1$	$\times$	$✓$	$✓$	$✓$
$𝔖{𝔉}_2$	$\times$	$✓$	$✓$	$✓$
$𝔖{𝔉}_3$	$\times$	$✓$	$✓$	$✓$
$𝔖{𝔉}_4$	$\times$	$✓$	$✓$	$✓$
$𝔖{𝔉}_5$	$✓$	$✓$	$✓$	$✓$
$𝔖{𝔉}_6$	$✓$	$\times$	$✓$	$✓$
$𝔖{𝔉}_7$	$\times$	$✓$	$✓$	$✓$
$𝔖{𝔉}_8$	$\times$	$✓$	$✓$	$✓$
$𝔖{𝔉}_9$	$✓$	$✓$	$✓$	$✓$
$𝔖{𝔉}_{10}$	$\times$	$\times$	$\times$	$✓$

Table 2. TABLE II: Execution overhead of different cryptographic functions.

Entity	${𝕋}_{bp}$	${𝕋}_m$	${𝕋}_a$	${𝕋}_h$	${𝕋}_e$
Server	5.275	1.97	0.012	0.009	0.339
Client	48.66	19.919	0.118	0.089	3.328

Table 3. TABLE III: Computational overhead analysis.

Protocols	At User	At Server
Tsai et al.[9]	$5{𝕋}_{bp}+2{𝕋}_a+{𝕋}_e+{𝕋}_{inv}+5{𝕋}_h\approx 93.604$	$2{𝕋}_{bp}+2{𝕋}_m+2{𝕋}_a+2{𝕋}_e+5{𝕋}_h\approx 15.228$
Irshad et al.[11]	${𝕋}_{bp}+5{𝕋}_m+2{𝕋}_a+2{𝕋}_e+{𝕋}_{inv}+6{𝕋}_h\approx 155.681$	$2{𝕋}_{bp}+4{𝕋}_m+3{𝕋}_a+2{𝕋}_e+3{𝕋}_h\approx 19.171$
Jia et al.[8]	$4{𝕋}_m+3{𝕋}_a+{𝕋}_e+5{𝕋}_h\approx 83.807$	${𝕋}_{bp}+5{𝕋}_m+3{𝕋}_a+5{𝕋}_h\approx 15.206$
Proposed	$4{𝕋}_m+4{𝕋}_h\approx 80.032$	$3{𝕋}_m+4{𝕋}_h\approx 5.946$

Table 4. TABLE IV: Comparison of communication overheads.

Scheme	Cost	No. of bits
Tsai et al.[9]	$3\left|G\right|+\left|G_T\right|+\left|H\right|+\left|ID\right|$	4608
Irshad et al.[11]	$4\left|G\right|+\left|G_T\right|+\left|H\right|+\left|ID\right|$	5632
Jia et al.[8]	$4\left|G\right|+2\left|T\right|+2\left|Z_q\right|+\left|ID\right|$	4736
Proposed	$2\left|G\right|+2\left|T\right|+2\left|H\right|$	2624

Full text

I Introduction

Mobile Edge Computing (MEC) has emerged as a promising platform, providing seamless data storage, computational and processing facilities at the edge of the network. In MEC, heterogeneous arrays of devices (such as laptops, access points, computers, tablets, switches, etc.) are involved in providing intended services to the end-users. More formally, MEC extends the notion of cloud computing facility closer to the ground [1]. However, in contrast to the distant cloud computing platform, MEC enables real-time data processing and analysis with reduced latency, enhanced mobility, greater user experience, and improved location awareness [2]. With these inherent advantages, the provisioning of emerging technologies like the Internet of Things (IoT), vehicular networks, cyber-physical systems (CPSs) has become a reality [3, 4].

However, the greatest challenge associated with the wide-scale adoption of MEC is induced due to the underlying security and privacy issues. MEC devices (*a.k.a. *edge devices) are mostly located closer to the users with limited installed security measures and support. Further, the decentralized architectures and diversified deployment environments often used in MEC environments, adversely impact the provisioning of centralized security measures. Hence, MEC devices are often susceptible to various attack vectors such as man-in-the-middle attacks (MITM), impersonation attacks, user traceability attacks, replay attacks, etc. Further, the information relayed over the open channel is prone to sniffing, tampering and replay; leading to severe privacy leakage issues. In order to circumvent the above-mentioned challenges, the installation of mutual authentication protocols in MEC environments can be a viable solution. These protocols enable mutual verification of the communicating parties before the transmission of confidential and sensitive information. They also facilitate the key exchange mechanism for preserving confidentiality and privacy[5, 6].

The following section summarizes the most related schemes proposed in the literature along the lines. Almajali et al.[7] proposed a comprehensive architecture with the aim of instilling security in IoT environments specifically using MEC. Furthermore, the authors also evaluated the existing state-of-the-art authentication protocols under the proposed architecture. Likewise, the primary focus of Jia et al.’s [8] work was on data security and user privacy, particularly in the context of MEC. To attain the same, the authors designed an identity-based anonymous authentication-driven key agreement protocol based on Elliptic Curve Cryptography (ECC). However, the authors employed expensive bilinear pairing operations in their protocol design. Xia et al.  in [2] focused on the caching mechanism used in MEC; wherein the authors were found quoting that MEC is susceptible to numerous attack vectors ranging from denial of service to impersonation attacks. Consequently, the authors investigated three attack models in MEC environments in the context of mobile offloading and caching procedures. Additionally, the authors also propounded an authentication scheme for mobile edge devices.

Tasi and Lo [9] presented a distributed scheme for mobile devices accessing cloud computing services. In the designed scheme, the authors employed computationally expensive bilinear pairing cryptosystem. The authors also claimed that their scheme was resilient against privacy comprising attacks and supported mutual authentication, replay protection, forgery protection, user anonymity, and user intractability. However, Jiang et al.[10] falsified Tasi and Lo’s notion to maintain adequate user privacy, and proved that the scheme was vulnerable to user impersonation attacks and lacked mutual authentication support. The improved variants of Tasi and Lo’s scheme along with its security loopholes were also discussed in [11, 12, 13]. For instance, Irshad et al.[11] used bilinear pairing operations and map-to-point hash functions to meet the claimed security requirements of the Mobile Cloud Computing (MCC) platform. Unfortunately, Xiong et al.[14] claimed that Irshad et al.’s scheme was computationally expensive and was prone to two designs flaws, *i.e., *inability to achieve three-factor security and lack of user revocation and registration facility. Thus, to solve the above-mentioned issues, Xiong et al.[14] designed a provably secure authentication scheme, specifically for mobile computing setups. More recently, Li et al.[15] proposed a preserving-preserving scheme based on ECC for mobile devices. The authors claim that their scheme supports mutual authentication, preserves users’ privacy and provides perfect forward secrecy.

It is evident from the above discussion that different variants of authentication protocols have been proposed in the context of MEC and MCC environments. Nevertheless, the existing protocols are prone to different attack vectors and lead to higher communicational and computational overheads. Thus, this paper presents a lightweight and privacy-preserving mutual authentication protocol, especially for MEC environments.

I-A Contributions

The key contributions of the work are listed below:

• •

We propose an ECC-based privacy-preserving mutual authentication protocol that is resistant to several sophisticated attacks in MEC environments. The designed protocol also helps in the key exchange between the participating entities, *i.e., *mobile users and MEC servers.

• •

We present a detailed security analysis of the proposed protocol and compare its features with the existing state-of-the-art.

• •

Another objective of the paper is to protect mobile edge devices in an open and vulnerable network; while keeping the associated overheads to a minimum.

I-B Organization

The rest of the paper is organized as follows. Section II sketches the schematic overview of the MEC environment. Section III illustrates the proposed protocol. The security and performance evaluations are presented in Sections IV and V, respectively. Finally, the paper is concluded in Section VI.

II System Model

A typical MEC environment consists of the following entities, *i.e., *a trusted Registration Center (RC), mobile users, and MEC servers; as depicted in Fig. 1. Here, the MEC servers are provided with computational and storage functionalities. These servers are geographically dispersed and deployed in close proximity of the mobile users; often at mobile base stations. Their closeness to the users helps reduce the latency and enhance the user experience significantly. The mobile users can access MEC services via their vehicles, smartphones, tablets, etc. On the contrary, the RC is assumed to be a trusted third-party that helps initialize the cryptographic parameters and provides a common platform for the registration of the users and MEC servers. The process of registration is essential for the proposed lightweight and privacy-preserving authentication protocol. In the designed protocol, it is assumed that the users and MEC servers get registered only once during their lifetime. Thus, the RC is deployed at the distant cloud platform and is not involved in the authentication process.

II-A Assumptions Considered

The following list of assumptions have been considered in this work:

It is assumed that the respective clocks of all the participating entities are well synchronized. This assumption enables generation of fresh timestamps for every session which helps the MEC resist to replay attacks. 2. 2.

The threat model is considered to be Dolev-Yao (DY); under which an adversary ($\mathcal{A}$) has full access to the channel. This, in turn, provides the $\mathcal{A}$ with the ability to intercept, alter, replay and delete the transmitted messages. The DY threat model relates precisely with the practical open channels. 3. 3.

The $\mathcal{A}$ can either be an insider or outsider. 4. 4.

The channels i) between the mobile user and the RC and ii) between MEC server and the RC, are assumed to be secure.

III Proposed Authentication Scheme

In this section, the proposed authentication protocol for MEC is presented. The designed protocol operates across the following phases: 1) Setup Phase, 2) User Registration Phase, 3) Server Registration Phase, and 4) Authentication Phase.

III-A Phase I: Setup Phase

This phase forms the crux of the upcoming phases and initializes all the parameters essential for the security of the MEC environment. The related details are summarized below:

Step 1: The RC begins the initialization process by selecting a cyclic additive group $G$, an elliptic curve $E$ with a generator $P$ and order $q$.

Step 2: Next, the RC generates its public ($P_{RC}$) and private ($d_{RC}$) key-pairs as follows: $d_{RC}\in Z^{*}_{q}$ and $P_{RC}=d_{RC}.P$.

Step 3: Next, a pair of collision-resistant one-way hash functions ($H_{1}()$ and $H_{2}()$) are chosen.

Step 4: Lastly, the following parameters $<G,E,P,q,H_{1}(),$ $H_{2}(),P_{RC}>$ are made public.

III-B Phase II: User Registration Phase

During this phase, the $u^{th}$ mobile user registers itself with the RC and in return is allocated a dedicated public-private key pair ($P_{u}~{}\&~{}d_{u}$) and a pseudo-identity ($SID_{u}$). The detailed process is elaborated as under.

Step 1: The $u^{th}$ mobile user selects an identity ($ID_{u}$) and transmits it to the RC over the secure channel.

Step 2: Upon receiving the user’s registration request, the RC generates a secret key $r_{u}$ and computes $R_{u}$. Following this, the RC performs the hash operation over the concatenated values of $ID_{u}$ and $R_{u}$, i.e., $h_{u}=H_{1}(ID_{u}||R_{u})$. Finally, the RC calculates $SID_{u}$ using the values computed above and its private key $d_{RC}$.

Step 3: Then, the RC computes $P_{u}~{}\&~{}d_{u}$ for the $u^{th}$ user. The computed values, i.e., $<SID_{u},~{}d_{u},~{}r_{u}>$ are then transmitted to the user over the secure channel.

Step 4: The received values and keys are stored by the user for the upcoming mutual authentication and key establishment phase. Meanwhile, the values $<SID_{u},~{}P_{u},~{}R_{u}>$ are made public to the MEC servers and stored in their respective repositories.

III-C Phase III: Server Registration Phase

This phase is identical to the previously discussed phase; wherein the only difference lies in the party trying to register with the RC. Here, the $ms^{th}$ MEC server tries to register itself and is associated with the following parameters: public-private key pairs ($P_{ms}~{}\&~{}d_{ms}$), pseudo-identity ($SID_{ms}$), and secret key ($r_{ms}$).

III-D Phase IV: Authentication Phase

During this phase, the mobile user and the MEC sever authenticate each other through a challenge-response mechanism and establish a shared session key for secure data transmission. The detailed processed is discussed as under (Fig. 4).

Step 1: The mutual authentication process is initiated by the mobile user trying to access the services of the MEC server. It initiates the process by recording its time-stamp ($T_{u}$) and generating a random number ($r_{1}$). Following this, the $u^{th}$ mobile user performs two ECC multiplication operations to generate $R_{1}$ and $R_{1-ms}$. Here, the latter is computed over $r_{1}$ and the $ms^{th}$ server’s public key $P_{ms}$.

Step 2: Finally, the user computes a token $\mathbb{TK}_{u}$ for the MEC server to verify and extract its identity. The token is estimated using the XOR operation on $SID_{u},~{}T_{u},$ and $R_{1-ms}$.

Step 3: Next, the parameters $<\mathbb{TK}_{u},~{}T_{u},~{}R_{1}>$ are relayed to the MEC server.

Step 4: Upon receiving these values, the MEC server validates the received time-stamp $T_{u}$. If the time-stamp lies within the permissible time window, then only the server advances the authentication phase. Otherwise, the connection is terminated.

Step 5: Then, the server computes $R_{1-ms}^{*}=d_{ms}.R_{1}$ and extracts $SID_{u}$ using the XOR operations. Upon deriving a valid identity, the server checks its database for its corresponding cryptographic parameters $R_{u}~{}\&~{}P_{u}$.

Step 6: The MEC serve then records its current time-stamp ($T_{ms}$) and computes $R_{u-ms}=d_{ms}.R_{u}$. Using these values, the $ms_{th}$ MEC server generates an intermediate authentication token ($\mathbb{A}uth_{ms}$) for the $u^{th}$ user to verify. Finally, the computed token and time-stamp are relayed to the user for verification.

Step 7: Upon acquiring $<T_{ms},~{}\mathbb{A}uth_{ms}>$, the user first verifies the received $T_{ms}$. Next it computes $R_{u-ms}^{*}=r_{u}.P_{ms}$ using its secret key $r_{u}$; followed by the estimation of the authentication token $\mathbb{A}uth_{ms}^{*}=H_{2}(SID_{u}||T_{u}||T_{ms}))\oplus H_{2}(SID_{u}||R_{u-ms}^{*})$.

Step 8: Finally, the tokens are checked for similarity. If the similarity is established then the user is assured that he is communicating with a valid MEC server; else the connection is terminated.

Step 9: Next, the user computes $R_{ms-u}=d_{u}.R_{ms}$ and a token ($\mathbb{A}uth_{u}$) for the server to verify. Along with this, it also computes its shared session key ($SK_{u-ms}$) with the server; and it is used only if the mutual authentication phase is completed with positive outcomes.

Step 10: Upon receiving $\mathbb{A}uth_{u}$, the $ms^{th}$ initiates the veri- -fication process by computing $\mathbb{A}uth_{u}^{*}$ and comparing it with the received value. If the two values match, then the process of mutual authentication between the two parties is established, and the server computes $SK_{u-ms}$.

IV Security Analysis and Comparisons

In this section, the security features provided by the proposed authentication scheme are discussed in details. In addition to this, the corresponding security evaluation with respect to the current state-of-the-art is also discussed herein.

IV-A Security Analysis

The proposed authentication scheme is found to be resilient against a number of attack vectors and supports the following features:

IV-A1 Mutual authentication

The proposed authentication mechanism supports mutual authentication between the mobile users and the MEC servers. The process of authentication is established by computing the intermediate authentication tokens, i.e., $\mathbb{A}uth_{ms}$ and $\mathbb{A}uth_{u}$. These tokens can only be calculated by the legitimate users as they involve the knowledge of the secret keys $d_{ms},r_{u},d_{u},$ and $r_{ms}$. Further, extracting the secret keys from their corresponding public keys in an intractable process in accordance with the elliptic curve discrete logarithm problem (ECDLP) [16, 8].

IV-A2 Session key agreement

Phase IV of the proposed protocol helps establish shared secret key ($SK_{ms-u},SK_{u-ms}$) between the participating entities. The computation of these keys requires the estimation of $R_{1-ms},R_{1-ms}^{*},R_{u-ms},R_{u-ms}^{*},R_{ms-u},$ and $R_{ms-u}^{*}$. Their computation in turn requires the knowledge of keys which are secret to the users and MEC servers. Further, the hardness of the computed $SK_{ms-u}$ and $SK_{u-ms}$ can be attributed to the elliptic curve diffie–hellman (ECDHP) problem [8]. .

IV-A3 User anonymity

In the designed protocol, the users’ identity is completely masked using pseudo identity, i.e., $SID_{u}$. Furthermore, neither the $ID_{u}$ nor $SID_{u}$ is ever transmitted to the server in clear text format. For instance, during the first authentication pass, $SID_{u}$ is masked using $T_{u}$ and $R_{1-ms}$. Here, the extraction of $R_{1-ms}$ is an infeasible process as it involves the information of secret keys, i.e., $r_{1}$ and $d_{ms}$.

IV-A4 User intractability

The designed protocol guarantees un-traceability of mobile users as it involves the use of random numbers ($r_{1}$) and fresh time-stamps ($T_{u}~{}\&~{}T_{ms}$) in every session. Thus, the transmitted tokens ($\mathbb{TK}_{u},~{}T_{u},~{}R_{1},~{}T_{ms},~{}\mathbb{A}uth_{ms},$ and $\mathbb{A}uth_{u}$) tend to acquire fresh values in each and every session. This limits $\mathcal{A}$’s capability to track a mobile user and monitor its activities.

IV-A5 Single sign-in

In the considered set-up, the mobile user logins with the MEC server post successful mutual phase authentication and establishment of a shared session key. In the overall process, the mobile user needs to register itself with the RC only once.

IV-A6 Perfect forward secrecy

Let us assume that the $\mathcal{A}$ somehow gets hold of the private keys of the user and MEC server. Further, it is also assumed that $\mathcal{A}$ can now intercept all the ongoing information ($\mathbb{TK}_{u},~{}T_{u},~{}R_{1},~{}T_{ms},~{}\mathbb{A}uth_{ms},$ and $\mathbb{A}uth_{u}$). Even under such a scenario, $\mathcal{A}$ would not be able to comprise the previously relayed messages without adequate knowledge of the random numbers ($r_{1},r_{u},r_{ms}$). Further, the computation of the session keys ($SK_{ms-u}$ and $SK_{u-ms}$) is a daunting task due to the nature of ECDHP problem.

IV-A7 Resists impersonation attack

In order to successfully impersonate a user or MEC server, $\mathcal{A}$ needs the following information: $d_{u},d_{ms},r_{1},r_{u}$ and $r_{ms}$. The said information is essential to generate the intermediate authentication tokens. Here, the first two in the list are the private keys and the last three are the random numbers and secret keys; and their extraction from their publicly available keys is an infeasible mechanism in accordance with ECDLP.

IV-A8 Resists man-in-the-middle attack (MITM)

During this attack, $\mathcal{A}$ can intercept and alter the information transmitted over the channel between the two legitimate parties. Further, $\mathcal{A}$ can trick the legitimate users into believing that the modified message is being sent by an authorized source. In the proposed protocol, the intermediate tokens can only be changed with the help of private keys; which in turn can not be accessed by $\mathcal{A}$. Thus, the protocol is resilient against MITM attacks.

IV-A9 Replay protection

The designed protocol also guarantees replay protection by incorporating the time-stamps ($T_{u}$ and $T_{ms}$) during each session. This means that the previously relayed messages cannot be used by the $\mathcal{A}$ to trick the legitimate users and servers into bypassing the mutual authentication process.

IV-B Security Comparison

An illustrative comparison of the proposed protocol against the existing schemes is detailed in Table I. The comparison is based on the following security features ($\mathfrak{SF}$): mutual authentication ($\mathfrak{SF}_{1}$), session key agreement ($\mathfrak{SF}_{2}$), user anonymity ($\mathfrak{SF}_{3}$), user intractability ($\mathfrak{SF}_{4}$), single sign-in ($\mathfrak{SF}_{5}$), perfect forward secrecy ($\mathfrak{SF}_{6}$), resist impersonation attacks ($\mathfrak{SF}_{7}$), resist man-in-the-middle attacks ($\mathfrak{SF}_{8}$), replay protection ($\mathfrak{SF}_{9}$), and lightweight ($\mathfrak{SF}_{10}$). Three existing schemes namely Tsai et al.’s [9], Irshad et al.’s [11], and Jia et al.’s [8] schemes have been considered for the purpose of evaluation.

In accordance with the details highlighted in Table I Tsai et al.’s [9] scheme doesn’t support the majority of the security features except for single sign-in, perfect forward secrecy and replay protection. Nevertheless, the protocols suggested by Irshad et al. fail to support perfect forward secrecy and is not lightweight. Similarly, Jai et al.’s scheme is also not lightweight but is secure against the major attack vectors. Thus, it is evident from the above discussion that the existing schemes/protocols cannot provide an adequate level of security and are not apt for MEC environments due to the use of heavy computations. Mobile devices involved in MEC often are battery constraint and have limited computational and communication capacity. Thus, heavy computations may take a toll on their performances. Meanwhile, the proposed authentication protocol supports all the security features and is lightweight too.

V Performance Evaluation

In this section, a comparative performance assessment of the proposed scheme with the existing schemes [9, 11, 8] is demonstrated. These schemes are essentially identity-based and privacy-driven. The related simulation details are discussed next:

V-A Simulation Details

The simulation setup is adopted from Jia et al.’s [8] work; wherein the authors have adopted different platforms to emulate the computational capabilities of the MEC servers and mobile devices. Alibaba’s cloud was used to simulate the servers with the following configurations: Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30 GHz, 1 GB RAM and Ubuntu 14.04. On the other hand, Google Nexus One smartphone provides the mobile devices platform with 2 GHz ARM CPU armeabi-v7a, 300 MiB RAM, and Android 4.4. For detailed information, readers are encouraged to refer to [8].

V-B Evaluation Parameters

The evaluation has been carried out on the basis of two widely used metrics, *i.e., *computational overhead, and communication overhead.

V-B1 Computational Overhead Analysis

For the computational analysis, different cryptographic functions were executed on the above-mentioned devices and platforms, *i.e., *MEC servers and mobile devices. Table II describes the overhead associated with the execution of different functions (in ms). Here, the variables $\mathbb{T}_{bp},\mathbb{T}_{m},\mathbb{T}_{a},\mathbb{T}_{h},$ and $\mathbb{T}_{e}$ denote the computational time required for executing a single bilinear pairing, scalar multiplication, point addition, hashing, and modular exponentiation operation, respectively.

Based on these values, the computational cost of the proposed protocol was analyzed against the existing protocols. The comparisons were carried out on both the mobile users’ and MEC servers’ sides. The obtained results are depicted in Table III. It is evident from the results that the proposed scheme depicts the best performance for both the MEC servers and the mobile users, and it is the most lightweight protocol amongst all.

V-B2 Communication Overhead Analysis

To analyze the communication overhead associated with the proposed and existing protocols, the number of messages transmitted between the participating parties has been considered as a potential metric. These transmitted messages comprise of different tokens such as cyclic additive group ($G$), field ($Z_{q}$), identity ($ID$), hash ($H$), and time-stamp ($T$). Their lengths were set as follows: $|G|=1024b,|Z_{q}|=160b,|ID|=256b,|H|=256b,$ and $|T|=32b$. In accordance with these values, the communication cost of the protocols was computed and summarized in Table IV. The results depict that the proposed scheme leads to the best performance, *i.e., *2624 b followed by Tsai et al.’s scheme (4608 b), Jia et al.’s scheme (4736 b), and Irshad et al.’s scheme (5632 b), respectively.

VI Conclusion

In this paper, a lightweight and privacy-preserving mutual authentication protocol for MEC environments has been proposed. The proposed protocol relies on ECC, one-way hash functions and concatenation operations for its secure and lightweight functionality. More specifically, the designed protocol acquires its strength from the hardness of ECDLP and ECDHP problems to compute the intermediate authentication tokens. Additionally, the protocol also leverages the advantages of freshly generated random numbers and time-stamps to resist replays of previously communicated messages. Overall, the protocol withstands different security attacks (namely user impersonation, server impersonation, MITM, user traceability, etc.) and provides mutual authentication, session key agreement, and single sign-in facility. The performance assessment of the proposed protocols with the existing state-of-the-art protocol reveals that the proposed protocol achieves the highest level of security with comparatively reduced computational and communication overheads.

Acknowledgment

This work was supported by the Tier 2 Canada Research Chair.