A Novel Authentication Protocol for 5G gNodeBs in Service Migration Scenarios of MEC

Edge computing paradigms were an expedient innovation for elevating the contemporary standards of mobile and Internet networks. As specified in Multi-Access Edge Computing (MEC) standardization, edge computing serviceable infrastructures are running on virtualization technologies to provide dynamic and flexible service instances. Since the inception and operation of the services are executing at the edge level gNodeBs (<inline-formula><tex-math notation="LaTeX">$gNB$</tex-math><alternatives><mml:math><mml:mrow><mml:mi>g</mml:mi><mml:mi>N</mml:mi><mml:mi>B</mml:mi></mml:mrow></mml:math><inline-graphic xlink:href="ranaweera-ieq1-3320647.gif"/></alternatives></inline-formula>s), migration of services between <inline-formula><tex-math notation="LaTeX">$gNB$</tex-math><alternatives><mml:math><mml:mrow><mml:mi>g</mml:mi><mml:mi>N</mml:mi><mml:mi>B</mml:mi></mml:mrow></mml:math><inline-graphic xlink:href="ranaweera-ieq2-3320647.gif"/></alternatives></inline-formula>s is an imminent occurrence in edge computing that is contriving challenges to its feasible deployment. Security and service level latency requirements are vital parameters for such service migration operations conducted through <inline-formula><tex-math notation="LaTeX">$gNB$</tex-math><alternatives><mml:math><mml:mrow><mml:mi>g</mml:mi><mml:mi>N</mml:mi><mml:mi>B</mml:mi></mml:mrow></mml:math><inline-graphic xlink:href="ranaweera-ieq3-3320647.gif"/></alternatives></inline-formula> to <inline-formula><tex-math notation="LaTeX">$gNB$</tex-math><alternatives><mml:math><mml:mrow><mml:mi>g</mml:mi><mml:mi>N</mml:mi><mml:mi>B</mml:mi></mml:mrow></mml:math><inline-graphic xlink:href="ranaweera-ieq4-3320647.gif"/></alternatives></inline-formula> (g2g) connecting channels. In this paper, our focus is to ensure identity verification among the parties involved in a service migration through authentication and to secure the migrating content through a robust g2g channel establishment. Our proposed authentication protocol was designed in accordance with the MEC architectural standardization. We have verified the proposed protocol employing four different formal verification techniques: Scyther and AVISPA verification tools, GNY and ROR logical approaches. Further, we have developed the proposed protocol in a test-bed environment emulating the MEC system with an integrated 5G Core network.

Abstract-Edge computing paradigms were an expedient innovation for elevating the contemporary standards of mobile and Internet networks.As specified in Multi-Access Edge Computing (MEC) standardization, edge computing serviceable infrastructures are running on virtualization technologies to provide dynamic and flexible service instances.Since the inception and operation of the services are executing at the edge level gNodeBs (gN Bs), migration of services between gN Bs is an imminent occurrence in edge computing that is contriving challenges to its feasible deployment.Security and service level latency requirements are vital parameters for such service migration operations conducted through gN B to gN B (g2g) connecting channels.In this paper, our focus is to ensure identity verification among the parties involved in a service migration through authentication and to secure the migrating content through a robust g2g channel establishment.Our proposed authentication protocol was designed in accordance with the MEC architectural standardization.We have verified the proposed protocol employing four different formal verification techniques: Scyther and AVISPA verification tools, GNY and ROR logical approaches.Further, we have developed the proposed protocol in a test-bed environment emulating the MEC system with an integrated 5G Core network.Index Terms-Authentication, edge computing, federated identity verification, MEC, security framework, service migration.

I. INTRODUCTION
M ULTI-ACCESS Edge Computing (MEC) is a nascent edge computing paradigm proposed to overcome the limitations of the existing cloud-centric networks.The lack of locational and context awareness attributed to the cloud computing platforms and the untrusted data outsourcing feature is contriving security and privacy issues for the service subscribers.Moreover, managing the trust domain is arduous with its globally dispersed deployment.Thus, edge computing offers the unique opportunity for launching a computing-enabled serviceable platform at the edge of the mobile network within a gNodeB (gN B), where Mobile Network Operators (MNOs) can guarantee the trust-domain intrinsic with General Data Protection Regulation (GDPR) resembled standards.
The emergence of edge computing paradigms has introduced the concept of service migration to cater to the heterogeneous IoT device's ubiquitous connectivity over the mobile network.The MEC-based services are offered from the nearest MECenabled gN B to the subscriber.Since the service instance or the program executing at the edge platform originates there, such a service instance is not available in other MEC gN Bs.In a situation where the subscriber is traversing beyond the range of the currently serving MEC gN B, the service instance should be migrated to a gN B with MEC capabilities in the proximity of the subscriber-roamed location.Once migrated and configured to the roamed MEC infrastructure, offered service to the consumer continues through the communication channels of the roamed gN B. The Quality of Service (QoS) and Quality of Experience (QoE) aspects of the offered MEC-based service depend entirely on the seamless operation of the migration process.The latency or a delay caused in the migration process will disrupt the service to the consumer device, thereby impacting both QoS and QoE factors negatively.Thus, service migration within edge computing platforms is a weaker aspect of MEC that forecasts inevitable issues.
In a typical gN B-to-gN B (g2g) communication, specialized authentication is not required as all gN Bs are registered under an MNO.Though with the advent of 5G, local operators are granted the ability to launch services in the mobile network, and such operators are not quite trustable due to the scalability of 5G.There is always a possibility of a fake gN B being launched by an adversary with replicated communication protocols.Since service migrations are becoming frequent in 5G, g2g communication is becoming a regular function for emerging networks.In addition to the impact it causes on the User Equipment (UE) communication, implications to the service migration process would be severe.This severity is due to service migration conveying mostly executable content or sensitive credentials between the gN Bs.Thus, validating the identity of the gN B is critical for 5G and its envisioned use cases.An authentication mechanism can validate the identity of the 5G gN B, and establish a secure migration channel afterwards.A Trusted Third Party (T T P ) should be engaged as both entities' identity verification (mutual authentication) cannot be pursued in an ad-hoc or peer-to-peer manner.
One might think that a typical authentication mechanism, as presented in [1] or [2], could be sufficient for this authentication mechanism.Service migration is a unique process requiring a specialized security protocol targeting the Service Migration Channel (SMC).This intended protocol should determine the eligibility of the roaming gN B considering resource availability and SMC network capacity while validating the legitimacy of the migrating virtual instances.Further, different security profiles ought to be applied to the SMC, depending on the application specifications.Thus, the SMC security profile selection should also be communicated via this protocol establishment.

A. Related Work
Zhang et al. in [1] propose a handover authentication protocol for 5G-based Heterogeneous Networks (HetNets) called RUSH.RUSH employed chameleon hash functions considering their trapdoor collision property and blockchain for its tamper resistance, and formal logic and model-based methods were used to verify it.Though the proposed RUSH scheme is not directly related to service migrations, the context in which it forms a secure channel between 5G HetNet gN Bs or access points is quite relevant to this study.Yan et al. in [3] developed a group handover authentication mechanism for 5G vehicle-to-everything scenarios.The mutual authentication protocol proposed between the gN Bs and the vehicles employs certificateless aggregated signatures free from key escrow issues and substantially reduces the signaling overhead.Although this paper accurately involves 5G core network entities in establishing the group handover scheme, edge computing or service migration aspects are not within its scope.Zhang et al. in [4] propose a blockchain-based secure edge service migration framework called Falcon, which enables Virtual Machines (VMs) or containers to be migrated as mobile agent-based carriers to make the migration process more flexible.This framework employs an immutable alliance chain decentralized to edge clouds for improving performance.The identity verification and management engaged in migration is a lacking aspect of this protocol, where a comprehensive security solution is required apart from the blockchain.Cui et al. in [5] introduce a fountain codes-based jamming strategy for service migration scenarios of edge computing environments.This solution contrives a set of Relay nodes to conduct cooperative jamming, which would eventually mislead and deteriorate the illegal eavesdropping quality of the migration channel.This strategy, however, does not provide a solution for authenticity verification among migration entities.
An authentication protocol for service migration scenarios in cloud computing was proposed by Karthick et al. in [2].This protocol targeted vehicular applications that require migrations between two clouds, and a registration entity is performing the communication of resource allocation securely.Though this protocol has been validated with AVISPA, there are evident issues, such as needless signature exposure that opt for reuse threats, ill consideration of perfect forward secrecy, and Denial of Service (DoS) threats.In addition, the lack of a development environment or any simulated performance metrics indeterminate the feasibility of this protocol.

B. Our Contribution
To the best of our knowledge, no literature is available addressing the security issues of edge-to-edge service migration scenarios.Our work can be considered as the pioneer attempt to solve the security concerns of service migrations.This paper proposes a holistic security protocol for authenticating and establishing a secure channel for pursuing service migrations.The main contributions of this research are stated below.
r Proposing a communication protocol for service migration instigation from an MEC architectural standpoint.
r Ensuring the authenticity and integrity of parties engaged in the service migration process through a federated identity verification approach.
r Securely conveying the credentials or parameters that en- able the formation of a security profile.
r Establishing a secure g2g channel for service migrations.r Validating our claims through formal analysis employing Scyther tool, AVISPA tool, Gong, Needham, and Yahalom (GNY) logic, and Real-Or-Random (ROR) logic.
r Conducting an informal analysis to verify compliance with the proposed security goals.
r Developing a prototype MEC environment to deploy the proposed protocol.

C. Paper Organization
The rest of the paper is organized into seven sections.Section II introduces the proposed MEC service migration security framework along with the novel authentication model proposed for it, while the considered threat model and the security goals of the proposed protocol are specified afterwards.In Section III, the design aspects of the security protocol are discussed and aligned to the considered service-migrating MEC system model.The informal analysis of the proposed protocol is presented in Section IV, while the formal analysis results employing Scyther, AVISPA tools, and GNY, ROR logics are presented in Section V. Section VI presents the computational and communication cost of the proposed protocol, while the details of the developed prototype MEC environment are presented in Section VII.Finally, Section VIII concludes the paper.

II. PROPOSED MEC SERVICE MIGRATION SECURITY FRAMEWORK AND THE THREAT MODEL
In this paper, we assume that service migration is occurring as VMs or lightweight containers as specified in [4], [6].In the MEC architecture specified in [7], Mobile Edge Services (MESs) are launched in Mobile Edge Hosts (MEHs).If we assume the MEHs are launched as VMs, and corresponding MESs are contained in light-weight containers as Mobile Edge Apps (ME Apps), migration of a particular MES is represented by transferring the contents of a container or a hibernated image of the said container.In such an instance, the hibernated image of the MES should be re-configured and launched at the roamed gN B MEC environment after the migration.The framework illustrated in Fig. 1 is proposed to perform the task of service migration within the g2g channel, embedded with optimal security strategies that guarantee maximal service level efficiency.

A. Proposed Service Migration Security Framework for MEC
The proposed Service Migration Security Framework (SMSF) for MEC-based gN Bs is formed for two primary purposes.The first purpose is the mutual authentication of entities engaged in a service migration scenario.In the authentication phase, the main functions are 1) validation of the gN B identities, 2) determining the legitimacy/ integrity of the migrating MES, and 3) launching capability of the migrating MES at the roaming gN B MEC environment.This phase is concluded by securely transferring the credentials and parameters corresponding to the security profile.
Security Profile (SP): SP embeds the layers of key size, padding scheme, and size, integrity checking mechanism, tunneling scheme, and other additional security schemes (i.e., for DoS mitigation, jamming as in [5]).SP s are identified from their Security Profile Index (SPI), which makes the operations of selection and application more convenient.Each SP (K M ) i corresponds to a different set of layers l 0 , l 1 , l 2 , . ... ..l j , where l 0 represents whether the SP is in the tunneling mode or not.If not, the rest of the layers are subjected to various security encryption algorithms denoted by A. The depth of layers (i.e., j) and its applied mechanism will determine the security level (L) and the incurred costs in terms of computation (C) and communication (T ) perspectives.T results in the resulting BW utilization each SP (K M ) i is deploying, while C accounts for the average processor utilization for each SP (K M ) i processing.
The second purpose is to optimize the application of security level in accordance with the current service level requirements, considering the available Bandwidth (BW) of the g2g channel.In addition to the two primary purposes, the functions of content transfer, session handling, and security are handled by this framework.However, the determination of the optimized security level and modeling of the SP exceed the scope of this paper.Thus, this paper only focuses on the first purpose.
To improve the efficiency in service migration scenarios, UE path prediction models can be considered as specified in [8], [9].Thus, simultaneous 1-to-N authentication can be conducted among the gN Bs that are positioned on the predicted path of the UE.As illustrated in Fig. 2, possible migration points are notified as g Ri , where each authentication session is specified as Auth(i), in which i ∈ 0, 1, 2, . .., I. Though this process is simultaneous, priority is given to the proximate g Ri points, and I is determined based on the UE predicted path and the reach of gN B S .This paper focuses on establishing a single Auth(i) session to maximize security.

B. Threat Model
To examine the robustness of the proposed protocol, we employ the Delev-Yao (DY) [10] threat model.The adversary's capabilities are as follows 1) The adversary (A) has total control over a wireless channel where an attacker may remove, modify, or inject legitimate messages.2) A can only guess one credential in polynomial time because it is impossible for the attacker to guess several values at once, such as identification or password, at the same time.3) A can intercept messages from many sessions and launch a traceability attack.4) A can act as a middleman and launch a man-in-the-middle attack.Adversary stealthily relays/possibly modifies communications between two parties that believe they are conversing directly with each other.5) A may also reveal some session secrets.6) A can also obtain the private keys of communicating parties.7) Adversay can get the data stored on gN B Source and gN B Roaming .8) Under this model, we also assume that T T P and MVA servers are secure and inaccessible to the adversary.9) It is possible that any of gN B Source or gN B Roaming might be compromised.

C. Security Goals of the Proposed Protocol
The following are the security goals [1], [11], [12] that the designed authentication technique must meet.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.r Protection from Key-Escrow attack: it state that, in any asymmetric-based encryption scheme, if the key generation authority is fully trusted and all the private keys of the users are generated by this authority, then the authority can decrypt all the ciphertexts with the help of these generated keys, but he/she can not get the previous session keys [13].

III. SECURITY PROTOCOL DESIGN
Due to the distributed nature of the MEC edge computing deployments, and its system level existing at a distance (i.e., in the core network), a federated identity verification mechanism was followed in designing this protocol.In other terms, the identity of an individual entity was verified through multiple parties via multiple means.Moreover, the MEC systems' reliance on the 5G core network components (i.e., especially Access and Mobility Management Function-AMF, Session Management Function-SMF, and User Plane Function-UPF) makes the designing of the protocol flow complicated [7], [14].The 3GPP 5G architecture specified in TS 23.501 [15] published under the 3GPP Release 15 was followed in the designs of this protocol.As one of the goals of this protocol is to unburden the main MEC entities of the security and authentication concerns, a T T P can be employed as a provisioning service.The proposed protocol attribute functional and architectural goals in addition to the security goals defined under the Section II-C.Therefore, a complete set of goals targeted by this protocol is stated in Section III-B.
A holistic perspective of the proposed security protocol and its connections to the MEC architectural components, operational sequence, and functional parameters are illustrated in Fig. 3.The entity Mobile Edge Platform Manager (MEPM) is the orchestrator of the edge level, and the Virtualization Infrastructure Manager (VIM) performs the hypervisor function on virtualized resource management.MEHs are the main operational elements of the MEC system, where their ME APPs or MESs launched in the Virtualization Infrastructure (VI) are governed by the Mobile Edge Platform (MEP) entity.The Local Area Data Network (LADN) within the MEH steers the traffic with the assistance of the UPF.Further information on these entities can be found in [6].The noteworthy entities in the same figure are described or defined below.
Operations Support System (OSS): This is one of the main entities at the MEC system level.In fact, the MEC system level is interfacing with the 5G core network through the Naf interface [16].According to the ETSI documentation, OSS is responsible for handling the user access authorization and subscriptions with proper distinguishing of the various service types forwarded from UE App Life-cycle Management Proxy (UALCMP) and Customer Facing Service (CFS) portal [17].As the main authority for authorization in the MEC domain, it is our main assumption that OSS is capable of handling the migration authorizations.Specifically, we are assuming that OSS is catering the functions of 1) serving as the main registry for storing the available T T P servers tasked with performing Authentication, Authorization, and Accounting (AAA) functions; 2) registry/ database for storing live MES information within the MEC system.There could be many T T P servers as MEC is a distributed architecture.But the gNodeB is considered as the edge level of the MEC.There are several gN Bs controlled under a system level.
Purpose of the T T P Server: Due to the allowance in 5G and B5G technologies to launch micro or macro-cell level gN Bs from local 5G operators, registering and monitoring all such gN Bs under the MEC system registries (i.e.OSS) is not viable, as certain services might be placed locally by their service providers and are launched only for application-specific instances within a limited domain.Due to this reason, there could be fake base stations or fake gN B attacks perpetrated by resourceful adversaries capable of intercepting the 5G radio bands.T T P contrives the required trust domain for the assigned geographical area, specific for migration processes.T T P offers a Migration Authentication as a Service (MAaaS) which alleviates the burden on the MEC system regarding handling secure service migrations.If a migration is required by a specific gN B, it should first register under the T T P for the migration.But this registration is only applicable to a single MES migration.However, a single T T P migration registration creates credentials required for I number of Auth(i) sessions for the considered gN B S as indicated in Fig. 2.

Mobile Edge Service Verification Registry (MVR):
This is an entity we are proposing to act as the global registry for all the MESs operating under the MEC service provider.The MVR is monitoring the service instances of each registered MES across the MEC domain, and updates its registries regarding the status, launched gN B location, and migration status.In the MEC service provisioning environment, physical infrastructure is decoupled from the virtualization domain, and software operations are preferred and dominating.Such a priority given to the softwarized entities can be exploited by perpetrators to induce autonomous constructs within and obscured instilled to the code and presents the opportunity to propagate through the virtualized MEC environment with ease.Therefore, security engineers should treat physical and softwarized entities in this era separately.Hence, a malicious MES could penetrate its MEC environment even if a gN B is a legitimate entity.Such an MES could prompt a migration request just to propagate its malicious content to other gN Bs.Therefore, it is important to verify the legitimacy of each MES that is prompting a migration.Among other tasks related to MESs, MVR is primarily tasked with handling the validation process of the MESs that are requesting a migration.
As specified earlier, MVR can be launched as a functional construct of the OSS in the MEC environment.When migration is prompted by an MES in the gN B S towards gN B R , an MES verification request (MES_VER_REQ) is sent from the gN B R to the MVR that embeds the corresponding identities of MES (ID MES ), gN B R (ID R ), and gN B S (ID S ).The MVR would check its entries for the provided ID MES , and whether that particular MES is registered under the ID S .If yes, a verification code CODE MES is sent to the gN B R while the same CODE MES is forwarded to the gN B S .Thus, both gN B R and gN B S can attain the verification code and validate the MES legitimacy.
Table I specifies the Notions and acronyms used in the presented description regarding our proposed protocol.
A. Assumptions r A1 -Assuming that authentication takes place prior to initiating migration in the pre-migration stage.r A2 -Assuming that possible gN B R s are already selected and known in terms of their network addresses.r A3 -Assuming that the most suited (e.g., through predic- tion based on distance) gN B is selected as the 1st gN B R in the sequence of 1-to-N authentication sessions.r A4 -Assuming that all the MESs should be pre-registered under the OSS, MVR, UALCMP, or CFSP.r A5 -All the 1-to-N authentication sessions occur inde- pendently and in parallel to each other, where gN B S is equipped with a sufficient number of 5G NR interfaces.r A6 -Assume that all the links directed from gN B S have sufficient and a dedicated BW to convey the messages relating to the authentication protocol so that maximum security measures can be applied.

r A10 -SOCK T T P and SOCK T T P M (please refer to
Table I for the definitions) have different port numbers; hence the corresponding services can operate independently and simultaneously.r A11 -Assume that all the public certificates related to the entities gN B S , gN B R , OSS, MV R, and T T P are handled by the certificate authority operating within the MEC trust domain and act as the trust anchor.r A12 -For every protocol session/ segment, all the nonces, timestamps, and HMACs are newly generated, and the notions are only bound to the specified protocol session.

B. Goals of the Proposed Security Protocol
The main goals of the proposed protocol are mentioned below.G1 -Mutually authenticate each gN B R selected to initiate the migration with gN B S in pre-migration stage.G1.

C. Proposed Security Protocol
In the protocol segments described below, several methods are followed to ensure the mutual-authentication among the entities involved in communication.Though this is a singular connection, mutual authentication is vital to extend the trust domain to the MEC system level.Though it is not indicated in Fig. 5, the OSS function notifies the T T P server of the gN B S request anchored through ID S as in Fig. 4. We assume this communication is secure as this is extended within the MEC system-level trust domain. 2

) Part B: T T P and the gN B S Communication for Obtaining the T T P Link for Migration Registration at the T T P :
The gN B S should first register under the migration T T P server so that it will issue the relevant credentials to initiate the migration authentication.This registration phase B is depicted in Fig. 6

5) Part G: Migration Session Establishment:
As specified in Subsection II-A, and the security goals G5 and G6, the proposed authentication protocol concludes in a situation where the most suited SP can be applicable to the transferring of the migrating content.Thus, this stage can be considered as the migration session establishment phase of the protocol as illustrated in Fig. 9. Since K M is already determined, an AES-512-based symmetric key is generated utilizing K M (i.e.K M is used as the secret key spec), which forms the SyK M .This SyK M is intended to be employed in signaling message transfers during the migration session.At the initiation, M G 1 is sent from gN B S to gN B R composing all the available SP s that can be bared by gN B S .The M G 1 is encrypted by SyK M while a HM AC is appended, as the integrity of this message is vital for the migration session establishment.Upon receiving, gN B R will select the most suited SP to initiate the migration considering its computational and bandwidth capability.Hence, the SPI of the selected SP is conveyed to the gN B S encrypted with SyK M in M G 2. Since the migration g2g tunnel between gN B S and gN B R is established, the containerized MES is hibernated into an image that includes its running configuration.Then the fragmented image content is subjected to the relevant cryptographic operations specified under the selected SP .The encrypted content is then migrated to the gN B R MEC environment to be decrypted, assembled, and configured to launch the MES in the new environment.

IV. INFORMAL ANALYSIS
This section provides the informal or descriptive analysis of the proposed protocol that establishes proofs for the 7 specified propositions.
Proposition 1: The proposed protocols provide Mutual authentication.
Proof: This preposition explains how the proposed protocols (parts A and part C& D) deliver mutual authentication.Therefore, we can clearly see that even if an attacker eavesdrops or captures the exchanged messages, he will be unable to get the identity of gN B S , gN B R , OSS, T T P because they are exchanged in encrypted from using the public key encryption instead of plaintext.Thus, our proposed protocols provide Confidentiality.
Proposition 3: The proposed protocol provides Perfect Forwards Secrecy.
Proof: The proof of this proposition elaborates that the attacker can not acquire the session key even though he has the private key of communicating entities.
r Part A: If an attacker obtains the private key of gN B S and OSS (i.e., P rK S , P rK OSS ) then he can not determine the SOCK T T P and Cert T T P because they are encrypted Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
with SyK A .It is impossible for the attacker to compute the SyK A = a1.b1.M due to the intractability of ECDL and ECCDH problem [20].
r Part C & D: If an attacker obtain the private key of gN B S , gN B R and T T P (i.e., P rK S , P rK R , P rK T T P ) then he can can not determine the CODE M , r 1 , r 2 , N, CODE M , r 2 and CODE M , n R 2 because they are encrypted with SyK C1 , SyK C2 , SyK D .It is impossible for the attacker to compute the SyK C1 = (a3.b3.M ), SyK C2 = (a3.C), SyK D = (a4.d4)due to intractability of ECDL and ECCDH problem [20].Proposition 4: The proposed protocol is resilient against the Replay attack.
Proof: To assure the replay attack protection, we employ the timestamp and nonce in each message exchange through which communicating parties gN B S , gN B R , OSS, and T T P could verify the freshness of the exchanged message.For, e.g., in Part A, when OSS receives the ((ID S , P A 1, T S1) P uKOSS, Sig[H(J1)] P rK s , HMAC1) then first it verifies the freshness of the exchanged message by checking the freshness condition (T S c − T S r < ΔT ) (i.e., T S2 − T S1 ≤ Δ).If it holds, then it accepts the message and decrypts the message.Otherwise, abort the process.The same approach is applied for the rest of the message exchanges for part A, and part C& D to verify their freshness by the receiving end.Hence, the proposed protocols are resilient against Replay attacks.
Proposition 5: The proposed protocols are resilient against the Denial-of-service (DoS) attack.
Proof: In the proposed protocols, we use the timestamp and nonce to examine the freshness of the message (i.e., the message was not sent previously).All the communication entities such as gN B S , gN B R , OSS, and T T P of Part A, B, C& D verify the freshness of the message by checking the freshness conditions.If the freshness condition meets, then they again verify the timestamps after verifying the signature of the message.If the timestamp is found correct in both checks, then only the message is accepted.Otherwise, they reject the message and abort.The analysis shows that the attacker can not replay the captured message due to the proper use of timestamps and nonce.Therefore, it is hard for an attacker to launch a denial of service attack.Hence, the proposed protocol is resilient against the DoS attack.
Proposition 6: The proposed protocols are resilient against traceability attacks.
Proof: This attack is impossible due to the usage of random numbers, timestamps, and nonces which are changed after each successful authentication request.The random numbers, timestamps, and nonce utilized in two separate sessions are completely unrelated to one another.Assume the attacker obtains a copy of the messages exchanged between the several sessions.In such a situation, he will not be able to connect communications from one session to messages from another since each session's signature and authentication replies are generated using fresh random numbers, nonce, and timestamps.Consequently, an attacker is unable to link the messages of one session to those of another.As a result, the proposed protocols are resistant to traceability attacks.

Proposition 7:
The proposed protocols provide protection from malicious gN B S and gN B R .
Proof: Malicious gN B S or gN B R is meant by the physical compromise of the entity during its operation.The nature of service delivery in the MEC system, as explicated in [21], is dependent on the virtualization platform that extends from the edge to the core of the network towards its system level.In fact, operations of the MEC system decouple the physical and virtual domains.The governing entity of the MEC edge level, Mobile Edge Platform Manager is constantly communicating with the Mobile Edge Orchestrator and the rest of the system-level entities to decide on the inception, operation, and termination of services; while Virtualization Infrastructure Manager controls the resource allocations and manipulations depending on the service requests.Thus, this autonomous environment is operating without any network administrator at the edge level, while all the governing decisions are conveyed from the system level to the edge through the virtual channels.Hence, access to the MEC edge-level servers or entities cannot be gained by an intruder who has physical access to the system.In fact, an interface is not required for administrative access at the edge, other than a monitoring terminal.Thus, MEC-enabled gN Bs are secured against physical threats to the system by design.The reliance on the system level for maintaining the operations, however, induces a possibility for attackers to block the communication channels between the system and edge level, which would isolate the gN B. Therefore, the security of this edge-core channel is a prime requirement for MEC deployments.
Proposition 8: The proposed protocols are resilient against key escrow attacks.
Proof: If the attacker got the public keys then he/she can not determine the session keys due to the use of ECC.For example in Part A, if the attacker has private keys of gN B S and OSS, then he can only get the P A 1, and P A 2. From P A 1, and P A 2, he can not get the SyK A due to the hardness of logarithm discrete problem [20] We do the informal analysis of part A and part C& D since part A is identical to part B and part C&D is identical to part E&F.Therefore, for B and parts C & D, we can follow the same informal analysis approach as part A and part C& D respectively.

V. FORMAL ANALYSIS
This section presents the formal analysis of the proposed protocol using the GNY logic, ROR logic, Scyther tool [22], and the AVISPA tool.

A. Model Based Verification With Scyther
The Scyther tool was employed to verify the proposed protocol for its resiliency, as it is a well-known automated tool for validating security protocols following a model-based approach.The Security Protocol Description Language (SPDL) is used to specify the protocols in Scyther, where testing protocol segments are specified under spdl files.Since the proposed protocol is described under the segments A, B, C, D, E, and F, the specifications were conducted under 4 SPDL files.A and B segments Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.In the tool, verification, advanced, and graph output parameters are controlling how the validation output is conveyed.Under verification, the maximum number of runs was set to 100 for every parameter sequence in the protocol that was tested.In the first sequence, the matching type was set to find basic type flaws while search pruning in advanced parameters was set to find all attacks.In the second sequence, find all type flaws, and find all attacks as the search pruning parameter.For both sequences, the specified claims were verified, and no possible attacks were detected by the tool.The corresponding partial SPDL specification scripts and the verification results of parts A, B, C & D, and E & are depicted in Fig. 10.This overall verification guarantees that the proposed protocol satisfies all timing requirements and nonce's being Alive/ Fresh, weak-agree, Nisynch, and sensitive parameters being secret.

B. Formal Verification Using the AVISPA
In order to confirm that proposed protocols (i.e., Part A, Part B, and Part C&D) are resilient against the attack, the AVISPA tool [23] is used.AVISPA stands for Automated Validation of Internet Security Protocols and Applications.This tool offers modular and expressive formal language to specify the security features of the authentication protocols.Apart from that, it uses different types of backend server that helps carry out different types of implementation using various automatic analysis techniques ranging from protocol falsification to abstraction-based verification methods for both finite and infinite numbers of sessions.This tool uses the role-based language HLPSL (High-Level Protocols Specification Language) to model the authentication protocol in order to examine its security properties.There are four types of backend servers specified by the tool:1) On-thefly Model-Checker (OFMC), 2) Constraint Logic-based Attack Searcher (CL-AtSe), 3) SAT-based Model-Checker (SATMC),

4) Tree Automata based on Automatic Approximations for the Analysis of Security Protocols (TA4SP).
We use the OFMC and CL-Atse backend servers to verify the proposed protocols similar to [1], [24].language.In Part, C&D, the protocol is modeled into the three roles gN BSource, gN Broamig, and OSS, sessions, and environment in order to carry out the simulation.Fig. 13(a) and (b) show that the protocol is safe and secure.

C. Formal Security Analysis Using GNY Logic
This section discusses the formal verification of the proposed protocol using the GNY logic [25] (i.e., extended version of BAN logic) to prove the robustness of the proposed protocol and securely mutually authenticate each other.
1) GNY Notations: Let A and B be the two entities communicating, and m be the message.We have used the general symbolism described in [25] to specify the GNY logic, while the logical postulates of Being told rules, Possession rules, and Freshness rules were utilized in the proving process.

2) Security Verification of Part
We apply the P R 3 rule on S 10

D. Formal Security Analysis Using ROR Logic
We use Real-or-Random (ROR) logic proposed by Abdalla et al. [26] in order to verify the session key security.ROR is considered a more suitable case than the original model proposed by Bellare et al. [27] to formally simulate real attacks on the authentication scheme for 5G gNodeBs in Service Migration Scenarios of MEC.Some of the basic concepts following their work are omitted in this paper, such as participants, long-term keys, freshness, etc.In the ROR model, the security model is defined by a game between two probabilistic polynomial-time Turing machines, namely a challenger (CH) and an adversary (A d ).It is assumed that CH owes a real system that has already applied our proposed scheme P MEC to it.In order to evaluate P MEC security, CH intended to invite A d to launch a real attack on P MEC , but CH worried about A d would learn enormous useful information about the real system.So CH developed an oracle system and designed a game to play with A d .After initialization, the oracle flips an unbiased coin c (c=0, 1), and the goal of A d is to guess the value of CH.To increase the chance of winning this game, A d is provided a series of queries to ask the oracle.There are three communicating parties, such as ( r Send ((Π l , mess): A d executes this query to forge the cap- tured message (i.e., it modified the captured message and then replay this message to the gN B f S , gN B g R , T T P h .)so that he receives the response of the forged message.
r Test (E h ): This query is used to examine the session key security of the communicating entities D f , and AS g ).To examine the session key security, a coin is tossed before starting the game.Based on the tossed outcome, A takes a decision (i.e., c=0, the communicating party returns the random number or c=1, then communicating party returns the session key.Otherwise, a null value is returned.) Where H Q , A ECDDH , U stands for a number of Hash queries, hardness of the discrete logarithm problem, and hash function output value, respectively.
Proof: Since Part A, Part B, Part C&D, and Part E&F use the combination of ECC and RSA to protect the exchange message confidentiality and integrity.Here, we do the proof for Part C&D since all the parts employ the same mechanism.The proof of the protocol is shown using the three games known as G 1 , G 2 , G 3 .An event S A d G 1 is defined as the success probability of the A d to guess the session key or to win the game.
Game (G 1 ): By executing this game, A d tries to get the actual value of c at the start of the game before Oracle initializes the procedure of the game.So, we get Game(G 3 ): Since during the G 2 execution attacker was unable to get the right session key, but he has the intercepted message.In this game, A d tries different ways to get the session key by modeling this game as an active attack by executing the Send query.We use the ECC and RSA that protects the exchange message and will not let the A d derive any secrets of the protocol, especially to determine the random number from these computed parameters {P c 1, P C 2, P C 3P D 1, P D 2} due to the hardness of the discrete logarithm problem [20].This shows that A d will not be able to determine any insight to derive the session key and will not be any collision while the Hash will run.So, the winning probability of G 3 will be similar to the previous game.Hence, This can be obtained by adopting the birthday paradox Now, all the game has been executed by the A d in order to predict the correct value of C, So we can We obtain the following outcome from ( 3) and ( 5).
The outcome after executing the game indicates that A d can not obtain the session key in a polynomial amount of time.

VI. VALIDATION AND PERFORMANCE COMPARISON
This section addresses the proposed protocols' performance measurements in terms of security verification, computational, communication, and energy consumption and compares them to their equivalent counterparts in the literature.

A. Security Features Verification
This section presents the security features verification as mentioned in Section II-C.We conduct the informal as well as the formal (Syther and GNY logic) security verification to show the proposed protocol's robustness against the identified attacks.The research carried out in [28], [29] shows that [1] is vulnerable to various attacks such as confidentiality and MiTM.[1], [30] shows that [31] does not offer the perfect forward secrecy, no formal verification, and confidentiality.The security analysis depicted in [1], [32], [33] confirms that [24] does not offer confidentiality and is also vulnerable to traceability attacks.Further, [34] does not offer confidentiality, and is vulnerable to DoS threats according to [1], [35], [36].
The comparison outcome shown in Table II demonstrates that the proposed protocol has the capability to offer all the identified security features while [1], [24], [31], [34] fails in some sort of security features verification.The protocol in [37] however, meets all the security features covered in our protocol.The fact that we employ a random number, timestamp, and nonce that changes after each successful authentication is the major rationale for providing all of the security features.
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

B. Computational Cost
This section evaluates the number of cryptographic operations used in the proposed protocol and its counterparts.We consider the cost of cryptographic operation as mentioned in [1], using two cores on Intel i7-6600 U CPU @ 2.60 GHz as gN Bs and the OpenSSL with two cores on Intel i4-2500 @3.30GHz as OSS shown in Table III.The notation T RSA , T H , T P , T E , T SM and T MSM stands for RSA signature, Secure Hash Algorithm (SHA2) function, pairing operation, modular exponential, elliptic curve scalar multiplication and multi elliptic curve scalar multiplication, respectively.Table IV contains the computational cost for all the proposed protocols.We also compare the proposed protocol (Part A) with [1][31] [24][37] [34] in terms of computational cost, which is displayed in Table VI, demonstrating that the proposed protocol is the least expensive.The proposed protocol is the least costly since it is based on the combination of T RSA and T SM which is less costly compared to [1][31] [24][37] [34] that uses the T E , T SM and T MSM as shown in Table III obtained through experimental analysis as [1].As stated earlier, current literature lacks any authentication mechanisms to contrast against phase C& D and phase E& F .

C. Communication Cost
This section evaluates the number of bits transmitted in the channel for the proposed protocol and its counterparts.To compute the number of bits transmitted, we use the same bit size as used in [1].The notation M RSA , M ID , M T S , M SM and M H stands for the packet is encrypted with RSA size of 2048 b, the identity of 32 bits, timestamp of 32 b, elliptic curve multiplication of 224 bits and hashed by 256 b, respectively.Table V shows the communication cost for the proposed protocols.We also compare the proposed protocol (Part A) with [1][31] [24][37] [34] in terms of communication cost, which is illustrated in Table VI, indicating that the proposed protocol takes the high-cost [1][31] [24][37] and is the less compared to [34].Although our proposed protocol takes communication cost high cost compared to [1][31] [24] [37], but offers the better security, less computational cost, and additional parts such as part C&D and part E& F .

D. Storage Cost
This section determines the memory required for the gN B S and gN B R .We take the size of cryptographic operations as stated in [1], with RSA being 2048 bits, identity being 32 bits, and hashed output being 256 bits.Table V shows the storage cost required for the proposed protocols.

E. Energy Consumption
This section determines the energy consumption for the cryptographic operations utilized in the various part of the proposed protocol.We have used the same energy consumption as [38] to measure energy consumption.To compute the energy consumption, experiments are performed using a "Strong ARM" CPU running at 133 MHz doing various tasks is described as the energy required for transmitting a bit, AES symmetric enc/dec, Hashed output, enc/dec RSA are 0.00066 mj, 0.00217 mj, 0.000108 mj, 15.3 mj, respectively.Table IV shows the energy consumption required for the proposed protocols.

VII. IMPLEMENTATION
This section explicates the pragmatic feasibility of the protocol while justifying the necessity for the embedded security measures.The specifications of the implemented prototype MEC environment are further elucidated while the conducted experiments are described within the valuation context.

A. Developed Experimental MEC Environment
This research attempt was initiated having a large focus on the SMSF specified in section II-A.Thus, a prototype testbed of the MEC service migration environment was developed and emulated for evaluating the feasibility of the proposed protocol in a practical deployment scenario.Fig. 14 represents the formation of the entities, gN B S , gN B R , T T P , and the OSS.A high-performance server (i.e.Processor: Intel Xeon 2.2 GHz 24 CPU, RAM: 98 GB, OS: Ubuntu 16.04 LTS) was launched as the MEC system level, that embeds both the OSS and 5G Core entities operating as VMs.The 5G Core was launched leveraging the free5GC (i.e.https://www.free5gc.org/)tool.In addition, the T T P or AAA server function was launched at a separate server bearing moderate specifications of Processor: Intel Xeon 2.4 GHz 4 CPU, RAM: 8 GB, OS: Windows Server 2016 64 b.The MEC virtualization platforms of the two emulating gN Bs were maintained in two laptops, due to the requirement for them to be mobile and dynamic to conduct the current and future emulations.The connections between the entities or interfacing were established via the socket-based Inter-Process Communication (IPC) approach.The protocol steps were specified using a Java base.For the cryptographic operations, RSA-4096 b, AES-256, SHA-512, clock-skew 50 ms, and K DoS as 4 parameters were used.The complexity K DoS exceeding 4 would consume more than 500 ms for solving, which is not ideal for the context of the protocol.The P-256 ECDH construct described in RFC5903 was deployed for relevant ECC-based PFS mechanisms.The developed prototype MEC setup converged the protocol to an average completion time of 2047 ms, which covered the phases from A to G. A comparatively higher value is exhibited due to the involvement of many identity and legitimacy verification entities, in addition to the adoption of DoS mitigation and PFS ensuring methods, that incur formidable delays to the protocol.

B. Conducted Emulation-Based Experiments
In order to implicate a scenario where the proposed security measures were not applicable, we have removed the main security measures from the developed protocol and denoted it as the Legacy Protocol (LP).The LP, therefore, withdrew 2 messages from each A and B phases, lingering only the request and reply messages with their inherent Asymmetric security measures.All the timing, hashing, nonce, and DoS measures were detached from the message flows.Since we have already conducted a costwise comparison with existing protocols in Table VI, the impact of integrating the proposed security measures into the protocol was evaluated to justify their security-heavy nature.15-(c) further elaborates on the impact of a DDoS threat, where DDoS bots were emulated towards the server interfaces of the protocol and assumed that each request was handled sequentially while running the setup.Since there are two server interfaces, C1 represents the case where only the OSS is subjected to the DDoS threat, while C2 represents the scenario where both OSS and T T P entities are under the influence of the stated threat.The emulation deduced that DoS measures are essential to mitigate the wasted timing on the system in addition to the exposed idling server interfaces.Fig. 15-(d) depicts a cost-wise perspective of the proposed SP and the LP in case of either tampering or Replay attempts were directed toward the different phases of the protocols.The lack of integrity or freshness measures of LP proves costly.

C. Simulation to Evaluate the Impact of Tampering
Further, we have simulated the behavior of the protocol in case of a tampering threat, and that is depicted in Fig. 16.In this simulation, the protocol completion time was computed considering the delays that ensued for re-transmissions with the perpetrated tampering attempts.This simulation compares the behavior of the two protocols SP and LP, in the context of Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.the probability that a tampering threat is occurring.It is clearly observable that both SP and LP are converging to their maximum re-transmission delays approximately at 0.2 and 0.3 probabilistic instances.LP protocol is undoubtedly exceeding the delays as it lacks the means to detect the ensued tampering attempts.Thus, security mechanisms integrated into the proposed protocol are vital for safeguarding the entities and content involved with service migration processes of MEC environments.

VIII. CONCLUSION
In this work, our focus was to address the security issues associated with the edge-to-edge service migration processes of MEC deployments, that take place between two gN Bs.As the MEC is deployed in a dynamic environment that feeds the 5G-related services, managing the security in long-lasting migration processes is an apparent conundrum.Our primary focus was to maximize the security measures along with mitigating DoS attempts and address the legitimacy issues inherent in novel virtual MEC-based deployments.The proposed protocol ensures mutual authentication among engaged entities through signature and nonce-based verification methods.In addition, a method for verifying the legitimacy of the operating MESs was proposed.The proposed protocol ensures the formation of the migration master key at the conclusion, while it can be utilized to safely configure the respective security profiles.The conducted formal analysis with Scyther and AVISPA tools along with GNY and ROR logics and the informal analysis specifications proved the correctness of our protocol.The comparable values of the efficiency measurements and the timing measurements from the testbed implementation prove the feasibility of the protocol in a server environment suited for a MEC deployment.The future focus of this research tends to the development of the service migration security framework introduced in Subsection II-A.

Fig. 3 .
Fig. 3. Holistic Service Migration Authentication Process from a MEC Architectural Viewpoint.

r
A7 -Assume that re-transmission protocols of the L2 and L4 of the TCP/IP stack are performing independently to detect packet losses or errors during transmission.r A8 -Assume the entire MEC system is synchronized and Timestamp (TS) errors are negligible.r A9 -All T T P s are trusted, and OSS contains the list of all the T T P s registered under the MNO.
Such methods are: r Public Key Encryption -The common RSA encryption based on X509 certificates.r Elliptic Curve Cryptography (ECC) -for PFS assurance.r Timestamp Utilization and Freshness Verification.r Hashing Functions -SHA-512.r Nonces and Nonce Verifying Hashes.r Signatures -Employed to validate the authenticity of the communicating party.

Fig. 4
Fig. 4 indicates the high-level view of the g2g authentication protocol for migration.The steps of the overall process are listed below.r Step A : gN B S reaches out to OSS for requesting contact details of the assigned T T P entity.r Step B : gN B S is contacting the migrating AAA ser- vice at the T T P .T T P registers the respective migration request and create a unique API link/socket specific to this migration while session IDs are created.r Step C : With the received migration credentials, gN B S reaches out to gN B R .

Fig. 5 .
Fig. 5. Part A of the Proposed Security Protocol that takes place between gN B S and the OSS.

Fig. 6 .
Fig. 6.Part B of the Proposed Security Protocol that takes place between gN B S and the T T P .
. The request M B 1 is sent by gN B S to the T T P using the SOCK T T P provided by the OSS, and utilizing the T T P certificate.The initial request M B 1 includes the ID S , T S1, and P B 1 (i.e.P B 1 = a2.M , a2 ∈ Z n ) within the encrypted envelop, while the signature formed with the hash H[J1] = H[ID T T P ||T S1] and the HM AC1 = H[ID S ||ID T T P ||P B 1||T S1] have been embedded to it.Upon receiving this message, T T P will ensure the freshness of the message from the decrypted T S1 and verifies the signature to guarantee it was sent by gN B S .The integrity is validated Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

Fig. 7 .
Fig. 7. Part C and D of the Proposed Security Protocol that takes place between gN B S , gN B R and the T T P .

Fig. 8 .
Fig. 8. Part E and F of the Proposed Security Protocol that takes place between gN B S , gN B R and the MVR.

Fig. 9 .
Fig. 9. Migration Session Establishment Phase of the Proposed Protocol.

r 2 :
Proof for Part C&D: When gN B S receives the message ((ID T T P , ID MP , P C 2, (CODE M , r 2 ) SyK C1 , T S4 ) P uK S ) from the T T P and ((ID R , ID MP , P C 3, (CODE M , n s 2)SyK C2 , H[n s 2,T S5], T S5) P uK S ) from the gN B R .gN B S decrypts this message and compute the H[n s 3, T S5] * in order to compare (H[n s 3, T S5] * == H[n s 2, T S4], CODE M gN B R == CODE * M T T P ).If it matches then believe that gN B R is authentic because n s 3 was sent using the public key of gN B R and gN B R can only know.On the other hand, when gN B R receives the message((ID MP , P D2 , (CODE M , r 1 , r 2 , N 1 ) SyK D , H[n R 1, T S 3], T S3) P uK R ) from the T T P .After decrypting the message, gN B R computes H[n R 1, T S3] * with the stored n R 1 in order to compares H(n R 1, T S3) == H(n R 1 * , T S3), ID MP == ID MP ) than gN B R believes that gN B S isauthentic because gN B S only knows the ID MP .Thus this shows that all three proposed protocols provide Mutual Authentication.Proposition The proposed protocols provide Confidentiality.Proof: In the proposed protocols (i.e., part A and part C& D), the identities of the gN B S , gN B R , OSS, and T T P are exchanged in the encrypted form instead of plaintext over the insecure channel.For the part A, identities of entities involve in communication gN B S and OSS are transmitted in encrypted and hashed form (ID S , P A 1, T S1) P uK OSS and HM AC1 = H(ID S , ID OSS , T S1).For the part C&amp; D, identities of entities involve in communication gN B S , gN B R and T T P are transmitted in encrypted and hashed form (ID S , ID T T P , ID MP , P C1 , SOCK T T P , n s 3, T S1) P uK R .

1 )
Simulation of Part A& Part B Using AVISPA Tool: We do the simulation of Part A and Part B by modeling the protocol into HLPSL language.Part A protocol is modeled into the two roles gN BSource and OSS, sessions, and environment in order to carry out the simulation.The same was used for Part B, two roles gN BSource and T T P , session, and environment() to carry out the simulation.Figs.11(a), (b), 12(a) and (b) show that the protocol is safe and secure.2) Simulation of Part C&D Using AVISPA Tool: We do the simulation of Part C&D by modeling the protocol into HLPSL

S 11 :
gN B S (SOCK T T P , Cert T T P ) SyK A We apply the BT R 4 rule on S 11 based on H3 S 12 : gN B S (SOCK T T P , Cert T T P ) We apply the BT R 2 , P R 3 rule on M 41 based on S 10 , H 12 S 13 : gN B S H(n s 1, n OSS , X) Applying the F R rule based on on S 10 and H 3 , we get S 14 : gN B S |≡ #(SOCK T T P , Cert T T P , H[n s 1, T S 4 ])) Since Part B of the protocol is identical to Part A, we can prove that Part B follows the same approach.3) Security Verification of Part C and D of the Proposed Protocol That Takes Place Between the gN B S , gN B R and the T T P Using the GNY Logic: Initial assumptions for the protocol H 1 : gN B S P rK s , H 2 : gN B S ID S , ID T T P , ID MP H 3 : gN B S #(T S4, T S4),H 4 : gN B S (SyK C1 ,SyK C2 ) H 5 : gN B R #(T S1, T S3), H 6 : gN B R P rK R H 7 : gN B R n R 1, H 8 : gN B R (ID R , ID T T P , ID MP ) H 9 : T T P (ID R , ID T T P , ID MP ), H 10 : T T P #(T S2) H 11 : T T P P rK T T P , H 12 : gN B S (SyK D ) The protocol's security goals are as follows: gN B R T T P ID , MP ID(R0) , SOCK T T P M , Cert T T P , n s 3, T S1, gNB R gN B R (H((n R 1, T S 3 )) gN B S |≡ OSS (SOCK T T P , Cert T T P ) gN B S |≡ OSS |≡ U E ↔ SKH N The following steps demonstrate the idealized form of the proposed protocol: M 10 : gN B R : * ( * ID S , * ID T T P , * ID MP , * SOCK T T P , * Cert T T P , * n s 3, P C 1, * T S1) P uK R , M 11 : gN B R : H( * ID S , * ID T T P , ID MP , * SOCK T T P , Cert T T P * n s 3, ID R , * T S 1 ), M 20 : T T P : * ( * ID R , * ID T T P , ID MP , n R 1, P C 1, P C 2, T S2) P uK T T P M 21 :T T P : * H( * ID R , * ID T T P , * ID MP

Theorem 1 :
If A d tries to crack the session key (SK) in polynomial time.Then Adv

Fig. 15 -
(a) presents a comparison between the protocol Completion Times (CTs) of the Standard Protocol (SP) and the LP.With the reduced security overhead, LP converges to an average CT of 814 ms.On the contrary, Fig. 15-(b) divulge the impact of a DoS attack on the LP from attempt 21 to 40, where the CTs are clearly accumulated beyond 6000 ms.Fig.

Fig. 15 .
Fig. 15.Results of the Emulations Conducted in the Developed Testbed Environment.

Fig. 16 .
Fig. 16.Impact of Tampering to the Protocol Completion Time, based on a Probabilistic Approach .

by sending reused messages. r Protection from Traceability attack: It is hard for an at- tacker to determine whether the same device is sending two distinct authentication requests. r Protection from malicious gN B S or gN B R : It assures that the
attacker is unable to retrieve the previous credentials even if the physical access of either gN B S or gN B R is seized.

TABLE I MAIN
NOTIONS AND ACRONYMS WITH THEIR DEFINITION/ DESCRIPTION G3.1 -Propose a governing and monitoring entity forMESs under the MEC system G3.2 -Propose a method to authenticate and validate the MESs to the governing entity G4 -Evaluate the Eligibility of gN B R to host the MES G5 -Propose a secure SP selection process G5.1 -Create a secure migration master key K M , for migration session establishment G5.2 -Propose a secure method to share available SP s and to conduct the selection process G6 -Migration session establishment G6.1 -Integrate the SP to the migration session G6.2 -Propose a method to migrate the executing MES with the received.If it matches then believe that OSS is authentic because n s 1 was sent using the public key of OSS and OSS only knows.On the other hand, when OSS receives ((S T D−REQ , n s 1, X, H[n OSS , T S3]) P uK OSS ) from the gN B S then it decrypts the message to obtain the credentials.After decrypting the message, OSS computes H[n OSS , T S3] * and compares with the received H[n OSS , T S3] (i.e., H(n OSS , T S3) == H(n * OSS , T S3)).If it matches then OSS believes that gN B S is authentic because gN B S only knows the n OSS .
r Proof for Part A: When gN B S receives message ((OSS − T D − RP , (SOCK T T P , Cert T T P ) SyK A , H[n s 1, T S4], T S4) P uK s ) from the OSS.gN B S decrypts this message and compute the H[n s 1, T S4] * in order to compare H[n s 1, T S4] * == H[n s 1, T S4] A of the Proposed Protocol That Takes Place Between the gN B S and the OSS Using the GNY Logic: Initial assumptions for the protocol H OSS , ID S , T S2, ID OSS ) gN B S (SOCK T T P , Cert T T P ) The idealized form of the proposed protocol: M 10 : OSS : * ( * ID S , * T S 1 , P A 1) P uK OSS , M 11 : OSS : * H( * ID S , * ID oSS , * T S 1 ), M 20 :gN B S : * ( * k dos , * n OSS , P A 2, * T S 2 , R2) P uK S M 21 :gN B S : * H( * k dos , * n OSS , * ID S , * T S2 * ) M 30 :OSS : * ( * n s 1, * X, H[n OSS , T S 3 ], * T S 3 ]) P uK OSS , M 31 :OSS : H( * ( * n OSS , * T S 3 ), M 40 :gN B S : * ( * (SOCK T T P , * Cert T T P ) SyK A , * H[n s 1, T S 4 ], * T S 4 ) P uK s M 41 :gN B Applying the F R rule on S 1 and S 2 based on S 1 and H 8 we get S 3 : OSS |≡ #(ID S , ID OSS , P A 1) By applying the BT R 1 , BT R 3 and P r 1 rule based on H 1 , we get S 4 : gN B S (K dos , n OSS , T S2, P A 2) We apply the BT R 2 and P R 2 rule based on H 5 , S 4 S 5 : gN B S H(K dos , n OSS , ID S , T S2, ID OSS ) Applying the F R rule based on S 4 and H 4 , we get S 6 : OSS |≡ #(K dos , n OSS , ID S , P A 2, ID OSS ) By applying the BT R 1 , BT R 3 and P R 1 rule on M 30 based on H 7 , we get S 7 : OSS (n s 1, X, H[n OSS , T S3], T S3]) We apply the BT R 2 and P R 2 rule on M 31 based on, H 9 and S 7 S 8 : OSS H(n OSS , T S3) Applying the F R rule based on S 8 and H 8 , we get S 1 : gN B S P rK s , H 2 : gN B S n s 1, H 3 : gN B S SyK A H 4 : gN B S #(T S2, T S4), H 5 : gN B S (ID S , ID OSS ) H 6 : OSS P rK OSS , H 7 : OSS ID OSS , ID S H 8 : OSS#(T S1, T S3), H 9 : OSS n OSS The protocol's security goals are as follows: OSS H(ID S , ID OSS , T S 1 ) gN B S H(K dos , n S : * H( * n s 1, * n OSS , * X).Proof and derivation of security goals: By applying the BT R 1 , BT R 3 and P r 1 rule on M 10 based on H 7 , we get S 1 : S 1 : OSS (ID S , T S 1 , P A 1) We apply the BT R 2 and P R 2 rule based on S 1 and H 7 , we get S 2 : OSS H(ID S , ID OSS , T S 1 ) 9 : OSS |≡ #(n s 1, X, H[n OSS ]) By applying the BT R 1 , BT R 3 and P r 1 rule on M 40 based on H 1 , we get S 10 : gN B S ((SOCK T T P , Cert T T P M 40 : gN B S : * ( * ID T T P , * ID MP , P C 2, (CODE M , r 2 ) SyK C1 , * T S4) P uK s , M 50 : gN B S : * ( * ID R , * P C 3, * (CODE M , n R 2) SyK C2 , * n R 2,H[n R 3, T S5], T S5) P uK S , M 51 : gN B S : * H( * n S 3, T S5), Proof and derivation of security goals: By applying the BT R 1 , BT R 3 and P R 1 rule on M 10 based on H 6 , we get S 1 : gN B R (ID S , ID T T P , ID MP , SOCK T T P , Cert T T P , n s 3, P C 1, T S1) BT R 2 and P R 2 rules on M 10 based on S 1 and H 8 was applied.S 2 : gN B R H(ID S , ID T T P , ID MP , SOCK T T P , Cert T T P , n s 3, ID R , T S 1 ) Applying the F R rule on S 1 , S 2 based on H 5 , we get S 3 : gN B R |≡ #(ID S , ID T T P , ID MP , SOCK T T P ,) Cert T T P , n s 3, P C 1 By applying the BT R 1 , BT R 3 and P R 1 rule on M 20 based on H 11 , we get S 4 : T T P (ID R , ID T T P , ID MP , n R 1, P C 1, P D 1, T S2) We apply the BT R 2 and P R 2 rule on M 21 based on S 4 and H 9 S 5 : T T P H(ID R , ID T T P , ID MP , n R 1, T S2) Applying the F R rule on S 4 based on H 10 , we get S 6 : T T P |≡ #(H(ID R , ID T T P , ID MP , n R 1, P C 1, P D 1, )) By applying the BT R 1 and BT R 3 and P R 1 rule on M 30 based on H 6 , we get S 7 : gN B R (ID MP , P D 2, (CODE M , r 1 , r 2 , N) SyK D , H[n R 1, T S3], T S3) We apply the BT R 2 and P R 2 rule on M 31 based on, H 8 and S 6 S 8 : gN B R (H(n R 1, T S 3 )) We apply the P R 3 rule on S 7 S 9 : gN B R (CODE M , r 1 , r 2 , N) SyK D We apply the BT R 4 rule on S 9 based on H 12 S 10 : gN B R (CODE M , r 1 , r 2 , N) Applying the F R rule based on S 5 and H 5 we get S 11 : gN B R |≡ #(ID MP , P D 2, (CODE M , r 1 , r 2 , N), ) H[n R 1, T S3], T S3 By applying the BT R 1 , BT R 3 and P R 1 rule on M 40 based on H 1 , we get S 12 : gN B S ID T T P , ID MP , P c 2, (CODE M , r 2 ) SyK C1 , T S 4 We apply the P R 3 rule on S 12 S 13 : gN B S (CODE M , r 2 ) SyK C1 We apply the BT R 4 rule on S 13 based on H 4 S 14 : gN B S (CODE M , r 2 ) Applying the F R rule based on S 10 and H 3 , we get S 15 : OSS |≡ #(ID T T P , * ID MP , P C 2, (CODE M , r 2 )), * T S 4 By applying the BT R 1 , BT R 3 and P R 1 rule on M 50 based on H 1 , we get S 16 : gN B S ID R , P C 3, (CODE M , n R 2) SyK C2 , n R 2, H[n R 3, T S5], T S5 We apply the BT R 2 and P R 3 rule on M 51 based on S 16 S We apply the P R 3 rule on S 15 S 18 : gN B S (CODE M , n R 2) SyK C2 We apply the BT R 4 rule on S 13 based on H 4 S 19 : gN B S (CODE M , n R 2) Applying the F R rule based on S 16 and H 3 , we get S 20 : OSS |≡ #(ID R , M2, (CODE M , n R 2), n R 2, ) H[n R 3, T S5] Since Parts E & F of the protocol is identical to Parts C & D, we can prove Parts E & F in the same manner.
17: gN B S H(n S 3, T S5) gN B S , gN B R , T T P ) involved in the authentication of 5G gNodeBs in Service Migration Scenarios of MEC.Let instances of f , g and h of gN B S , gN B R and T T P are denoted by gN B f S and gN B g R and T T P h respectively.In the ROR model, it is assumed that A d can perform several activities such as deleting, inserting, and editing the captured exchanged message.A d can perform these activities by executing the queries defined in the ROR model.The description of these queries is as follows.

)
Game (G 2 ): A d executes the Execute query to win the game by intercepting the exchange message{M C 1, M C 2, M C 3, M D 1, M D 2}between the gN B SOURCE , gNB Roaming , and T T P .When A d obtains the exchange message, then it tries to get the correct secret value by guessing the value of c based on the execution of Test query.Since we use the random numbers {a 3 , b 3 , c, a 4 , a 5 } derived from the elliptic curve.They are random (i.e., used only once in the protocol) and exchanged in encrypted form between the communicating entities.So, finding any clue for the random numbers is tough so that A d will get the session key.Therefore, A d will lose the game, and the winning possibility of G 1 will be similar to the G 2 .Hence we can get

TABLE IV COMPUTATIONAL
COST AND ENERGY CONSUMPTION OF THE PROPOSED PROTOCOLS TABLE V COMMUNICATION AND STORAGE COSTS OF THE PROPOSED PROTOCOLS TABLE VI COMPARISON OF COMPUTATIONAL AND COMMUNICATION COSTS OF PART A SEGMENT WITH ITS COUNTERPARTS