Elliptic Curve Cryptography-Based Identity Authentication Scheme Suitable for Metaverse Environment

Abstract

Compared to traditional platform environments in the online realm, the metaverse, as a three-dimensional (3D) virtual world, exposes more identity data to the network. Once these data are compromised, it leads to privacy breaches. Therefore, how to ensure identity security in the metaverse environment has become an urgent problem to be solved. Although research on identity authentication schemes can help improve identity security, traditional identity authentication schemes in network environments are studied based on their own environmental characteristics, which makes it difficult to meet the security needs in the metaverse environment. As a result, in this paper we propose an elliptic curve cryptography (ECC)-based identity authentication scheme to address identity authentication issues in the metaverse environment. This scheme ensures secure communication among users, avatars, and platform servers. The security of this scheme was demonstrated through informal security analysis and the automated validation of internet security protocols and applications (AVISPA) formal security analysis tools, and the results showed that it can resist various known attacks. Compared with existing identity authentication schemes, this scheme has lower computational and communication costs.

1. Introduction

The metaverse, as a virtual world built upon the internet, offers immersive services akin to the real world. Massive amounts of data circulate between the metaverse and the real world through insecure channels, facing a variety of security threats [1,2,3]. On one hand, privacy and security issues prevalent in traditional internet environments also pose risks in the metaverse. Currently, many mature technologies still harbor security vulnerabilities, and the metaverse, being a fusion of multiple technologies, is exposed to an even greater number of security risks. Users, devices, and servers within the metaverse constantly interact, exchanging vast amounts of data, including but not limited to, user identity information, device ownership details, and server keys. The utilization of massive data brings about more forms of attacks by malicious actors. For instance, in Internet of Things (IoT) environments similar to the metaverse, when embedded devices utilize large resource pools in the cloud, the information exchanged between devices and cloud servers is susceptible to man-in-the-middle attacks, device or server impersonations, and deceit. On the other hand, the metaverse is where users manipulate digital avatars with different appearances to interact with other avatars in digital application scenarios by wearing VR and XR devices. A series of security issues related to devices and identities will also come to mind. Therefore, compared to identity authentication in traditional network environments, identity authentication in the metaverse environment needs consideration of more security factors when designing, in order to ensure the identity security of users, avatars, and servers in the metaverse.

Consequently, there is a need to propose an identity authentication scheme suitable for the metaverse environment to protect privacy and security among its diverse participants. Authentication schemes used in similar environments are not directly applicable to the unique requirements of the metaverse. This mismatch arises from the metaverse’s complex and diverse demands for identity verification, aimed at addressing a broader range of interaction scenarios and data-exchange processes. For example, in remote healthcare services, researchers [4] proposed an authentication scheme between users and servers based on the asymmetric encryption algorithm RSA, which can effectively resist various attack forms, including offline password guessing and user or server impersonation. This method enhances authentication strength by incorporating physical security factors, thereby providing enhanced protection for users and servers, ensuring data security and integrity. Although this scheme secures user–server interactions, the metaverse environment requires the incorporation of multi-factor and multi-party authentication in the design of authentication schemes. For instance, the use of user biometrics and bidirectional authentication between users, their digital avatars, servers, and wearable devices are key measures to ensure secure interactions. Researchers [5] proposed a multi-factor and tripartite authentication protocol based on the ECC algorithm, introducing biometric factors during the registration and authentication phases to verify user identities, achieving tripartite session key negotiation among users, fog nodes, and cloud servers in fog computing-based smart healthcare scenarios. However, given the decentralized nature of the metaverse, it is necessary to reduce reliance on trusted third parties and design more suitable decentralized authentication schemes.

Therefore, a redesigned authentication solution for the metaverse is required to meet its unique security, interoperability, and user privacy protection needs. As a result, this paper introduces an elliptic curve-based identity authentication scheme suitable for the metaverse environment. The main contributions are as follows:

• A novel elliptic curve-based identity authentication scheme is proposed, where, during the user registration phase, the server stores the user’s anonymous identity and a number randomly chosen by the server on a private blockchain, ensuring the confidentiality of critical parameters. This scheme secures safe sessions among users, avatars, and servers;
• The security of the scheme was validated through informal and AVISPA formal security analysis tools, and the results showed that it can resist a wide range of known attacks. Moreover, compared to existing identity authentication schemes in internet, IoT, and metaverse environments, this scheme exhibits superior security properties;
• A computational overhead comparison using the MIRACL library shows that our scheme requires less computation time and, in terms of communication overhead, can authenticate user identities with fewer bits.

The remainder of this paper is organized as follows: Section 2 compares and analyzes identity authentication schemes in metaverse and traditional network environments. Section 3 introduces preliminary knowledge related to the authentication scheme. Section 4 introduces the system model of the scheme. Section 5 presents the proposed ECC-based identity authentication scheme suitable for the metaverse environment. Section 6 conducts a security analysis of the scheme. Section 7 compares the computational and communication overhead of the scheme. Finally, Section 8 concludes the paper.

2. Related Work

The core objective of identity authentication mechanisms is to ensure the confidentiality, integrity, and availability of data, as well as to protect the security of user privacy. This process is foundational to information security management, aimed at preventing unauthorized access through user identity verification and thereby safeguarding information resources from harm. Effective identity authentication schemes are crucial for maintaining system security, ensuring that only authorized users can access sensitive data and resources while defending against external threats. Thus, this section reviews and analyzes identity authentication schemes within the metaverse and similar network environments.

In environments similar to the metaverse, researchers [6] introduced an efficient lightweight three-factor authentication protocol using fuzzy extractors on a blockchain platform to ensure the security of device communication during user information transmission in the IoT. The protocol was analyzed for its security using the Random Oracle Model (ROM), Burrows–Abadi–Needham (BAN) logic, and the AVISPA tool. This scheme proposed a three-factor authentication protocol for IoT within a blockchain framework, employing lightweight cryptography and fuzzy extractors and leveraging a private blockchain to enhance the security and transparency of registered information in smart cards, while also restricting the number of individuals allowed to confirm information registration. Researchers [7] proposed a three-factor authentication scheme that integrates lightweight data-hiding techniques with widely used three-factor authentication, achieving bidirectional authentication and completing the authentication of sensors to gateways and users to sensors. Compared to existing typical schemes, this method offers the advantage of low energy consumption and resistance to sensor capture, offline guessing, and insider attacks. Researchers [8] proposed a cloud-based mutual authentication model for wearable medical devices, successfully completing mutual identity verification between users and wearable sensor nodes and establishing a session key for future secure communication. The model utilized the ROM and AVISPA tool for formal security analysis, offering protection against device impersonation in medical monitoring systems, as well as password change and smart card revocation functionalities. However, under the characteristics of immersive interaction in the metaverse, it is necessary to design an identity authentication scheme suitable for the metaverse environment. Therefore, authentication solutions for the metaverse need to be redesigned to meet its unique security, interoperability, and user privacy protection needs.

In the metaverse environment, the risk and form of user privacy data leakage in the metaverse have become unpredictable, and virtual tracking, virtual monitoring, and virtual harassment will greatly reduce the user experience in the metaverse [1,9], because in the metaverse environment, the correspondence, uniqueness, and traceability between user and avatar identities can easily be confused [3]. As a result, researchers [10] introduced a secure mutual authentication scheme using ECC and fuzzy extractors for encrypting and decrypting biometric information, ensuring safer interactions between avatars in the metaverse. This scheme ensures authentication between users and avatars, as well as between avatars and avatars. Random numbers are added to the authentication calculation to prevent attackers from analyzing user identity information from intercepted information. However, the scheme’s security depends on certificate authorities. Researchers [11] employed multi-factor authentication and elliptic curve cryptography algorithms, storing users’ anonymous identities and public keys on a public permissioned blockchain for transparent management. This facilitates secure communication between users and platform servers, as well as the authentication of avatar identities. The scheme offers a secure authentication framework for both user-to-server communication and interactions between avatars, capable of resisting theft of smart devices, offline password guessing, and impersonation attacks. However, as a virtual digital world, the metaverse requires lower communication overhead to meet the user’s immersive experience [12].

In summary, the authentication schemes used in environments similar to the metaverse are not suitable for direct application to the unique needs of the metaverse. This mismatch stems from the metaverse’s more complex and diverse requirements for identity verification, aimed at handling a wider range of interaction scenarios and data-exchange processes. However, in the authentication scheme in the metaverse environment, a lower cost, higher security attributes, and a combination of multi-factor authentication are required, combining traditional cryptographic identity authentication schemes with blockchain secure storage identity authentication schemes. Therefore, this article describes an identity authentication scheme suitable for the metaverse environment based on elliptic curve cryptography. This scheme will use private blockchain to store important parameters related to user identity verification during the authentication process and complete the encryption and decryption of biometric features through a fuzzy extractor, meeting the needs of secure interaction between users, avatars, and servers in the metaverse and reducing computational costs.

3. Preliminary Knowledge

3.1. Elliptic Curve Cryptography

ECC utilizes elliptic curves over finite fields to offer superior security performance with smaller key sizes compared to existing public key cryptography technologies [13,14]. Assuming p is a prime number and F_p represents a finite field with n, m ∈ F_p, this is illustrated by Formula (1).

4n³ + 27m² ≠ 0

(1)

The non-singular elliptic curve E_p (n,m) over F_p is represented by the equation shown in Formula (2).

E_p(n,m): y² = x³ + nx + m (mod p)

(2)

Furthermore, suppose L is a base point on E_p (n, m), and t is a positive integer with t ∈ F_p, then the point multiplication formula is represented as shown in Formula (3), where the count of L is t.

t·L = L + ⋯ + L

(3)

The two computational hard problems of ECC are described as follows:

• The Elliptic Curve Discrete Logarithm Problem (ECDLP) posits that, given two points P and L on E_p (n, m), and x ∈ F_p, calculating the value of x from L = x·L is a difficult problem;
• The Elliptic Curve Diffie–Hellman Problem (ECDHP) posits that, given three points P, x₁·P, and x₂·P on E_p (n, m), computing x₁·x₂·P is a difficult problem.

3.2. Hash Function

In a hash function H: {0,1}* → {0,1}ⁿ, n is a constant, {0,1}* represents a string of arbitrary length, and {0,1}ⁿ represents a string of fixed length n. Therefore, a hash function receives an input D of arbitrary length and computes an output H = h (D) of fixed length. Moreover, two points should be noted when using a hash function:

• A hash function can only compute in one direction without computational reversibility, meaning it is difficult to calculate the input value D ∈ {0,1}* when having both h and the output value H ∈ {0,1}ⁿ;
• Finding two input values D₁ and D₂ that satisfy h (D₁) = h (D₂) in a hash function is difficult.

3.3. Fuzzy Extractors

Fuzzy extractors transform non-uniform data into uniform random strings suitable for cryptographic applications. Biometric information is commonly used with fuzzy extractors, producing repeatable strings considered as parameters for personal authentication [15,16]. A fuzzy pattern extractor consists of two algorithms {Gen (·), Rep (·)}. Using a biometric parameter B_i, the Gen (B_i) = (σ, ρ) algorithm generates two outputs. σ can then be used with ρ to verify input data. If the biometric B_i and B_i′ are identical, the algorithm Rep (B_i′·ρ) = σ will produce an output identical to the previous σ.

• Generation Function (Gen(·)): This function is defined as Gen (ω) = (σ, ρ), with ω as the input. It produces a random string σ ∈ {0,1} and a string ρ.
• Reproduction Function (Rep (·)): This function accepts a biometric parameter ω′, identical to the input ω, and uses the string ρ. Through the algorithm Rep (ω′·ρ) = σ, it outputs σ.

3.4. Adversary Model

To demonstrate the security of the proposed scheme, we introduce the capabilities of an adversary within the Dolev–Yao (DY) model [17,18]. The malicious attacker in the adversary model is capable of:

• Ensuring the information exchanged through secure channels during the registration phase is true and secure;
• Intercepting messages transmitted over public channels, with the ability to replay, insert, eavesdrop, modify, and delete transmitted messages;
• Capturing or tampering with smart devices during the registration phase, thus gaining access to secret credentials stored in the device’s memory and attempting various other security attacks;
• Conducting simultaneous offline identity and password guessing attacks;
• The information stored on the blockchain is secure.

3.5. Blockchain Technology

Blockchain technology [19,20] combines modern cryptography, distributed storage, consensus mechanisms, and smart contracts among other technologies. It offers a technical solution independent of trusted third parties, using its distributed nodes for storing, verifying, transmitting, and communicating network data. Essentially, blockchain refers to a distributed ledger where stored data or transactions are immutable, structured into hash-linked blocks. Blockchains can be categorized into public, private, and consortium chains, as follows:

• Public chain: no permission required for node identity verification, with nodes freely entering or exiting the public chain and chain data fully public;
• Private chain: established within a single organization, with control fully held by a few high-capacity nodes;
• Consortium chain: only allows organizational members to join the blockchain, with nodes preselected and generally having cooperative relationships, belonging to a partially centralized structure.

Blockchain technology has found wide application in supply chain, digital finance, smart agriculture, IoT, etc. Its decentralized nature makes it suitable for large-scale, distributed IoT scenarios, helping to address issues raised by centralized identity management. Thus, researchers [21] highlight blockchain as a crucial component of the metaverse, addressing key management overhead and dependency on trusted third parties inherent in traditional authentication methods. As a three-dimensional virtual world, the metaverse requires a large amount of data storage. If important privacy information in the metaverse relies on central storage systems, once data are leaked, it will affect the identity security of metaverse users [22,23]. Due to the limitation of access to private blockchains by individuals who need them, private blockchains will be faster and more secure than public chains [24]. Therefore, private chains are more suitable for the metaverse environment. The proposed solution in this article will also use private chains to store important user identity parameters, ensuring data security.

4. System Model

The system model for the proposed scheme is illustrated in Figure 1. As shown in the figure, after logging into the server, user 1 generates an avatar corresponding to their identity, which interacts with user 2 in the metaverse service provided by the server. During this period, blockchain will be used to store important data that servers use to verify user and avatar identities. Although the system model only shows the scenario of user 1 and user 2 interacting in the metaverse, this is the basic process for users to obtain metaverse services. With the increase of users, servers, and avatars, the system model can still support it. As depicted, the system comprises users, avatars, servers, and blockchain technology, with each component described as follows:

• Users: During the registration phase, users submit an anonymous identity to the server to verify their real identity, thereby gaining access to services within the metaverse provided by the server. Subsequently, users register an avatar identity on the platform server, corresponding to their own identity. Upon completion of registration, users can enter the metaverse environment space provided by the platform server under the identity of their avatar. During registration, users require a smart device, which stores critical parameters from the registration process and performs certain computations;
• Avatars: Avatars represent users’ identities within the metaverse. A user can have multiple avatars, but each must match the user’s identity. Although an avatar’s identity is unique, the manifestations of a user’s avatars are diverse;
• Servers: In this scheme, the server is considered secure and reliable. The server is responsible for generating symmetric keys and encrypting and decrypting them using the server’s private key. The encrypted symmetric key is stored in a smart card and sent to the user through a secure channel. After completing the authentication of user and avatar identities, the server updates the symmetric key to ensure communication security;
• Blockchain: In our proposed scheme, private blockchain is used. Therefore, only a few allowed servers can read the data stored on the chain. For example, during the user registration phase, the anonymous identity of the user and the random number generated by the server are stored on the blockchain to achieve server authentication of the user’s identity. Moreover, during the avatar registration stage, the anonymous identity generated by the user and the corresponding avatar identity are stored on the chain. During the authentication process, the server accesses the private blockchain to achieve the authentication of the avatar identity. This scheme utilizes the security of blockchain data storage as an auxiliary measure to improve identity authentication. The specific focus of this article is on the design of authentication schemes. The data acquisition, storage, sharing, interoperability, and privacy protection of blockchain in the metaverse can be referred to in the literature [23].

5. Proposed Scheme

This section provides a detailed description of the scheme, including the specific interpretations of the symbols used, as illustrated in

Table 1. Definition of notations in our scheme.

Notation	Definition
Ui	User
Sj	Server
SDi	Smart device of Ui
Avatari	Avatari identity of Ui
IDi	Identity of Ui
PWi	Password of Ui
Bi	Biometric information of Ui
PIDi	Pseudo-identity of Ui
σi	Private parameters generated by fuzzy extractor
ρi	Common parameters generated by fuzzy extractors
k	Private key of Sj
r1, r2, r3, r4, r5	Random numbers
T1, T2	Timestamps
P	Point P on elliptic curve
H (·)	One-way hash function
Enck (·)	Symmetric encryption algorithm using k
Deck (·)	Symmetric decryption algorithm using k
Gen (·)	Generating functions for biometric fuzzy extractor
Rep (·)	Reproduction function of biometric fuzzy extractor
||	Concatenation operation
⊕	Exclusive or operation

.

5.1. Initialization Phase

During the system initialization phase, the server S_j selects a non-singular elliptic curve E_p (n,m) over F_p, then chooses a point P on E_p (n,m) and a private key k, and finally publishes the parameters {E_p (n,m), P, h (·)}.

5.2. User Registration

When each new user device wants to obtain services in the metaverse, it needs to register with the server first. During the registration process, the user device will send encrypted identity information to the server through a secure channel. After the server obtains this information, it generates a symmetric key using its own private key and stores it in a smart card to send to the user device as a credential for future user authentication. The user registration phase consists of three steps, as shown in Figure 2.

Step 1: First, the user U_i inputs their identity ID_i, password PW_i, and biometric information B_i. The user’s smart device SD_i then selects a random number r₁. The biometric fuzzy extractor’s generation function Gen(B_i) calculates Gen(B_i) = (σ_i, ρ_i) using the input B_i, extracting the private parameter σ_i and the public parameter ρ_i belonging to U_i. Subsequently, it computes PWD_i = h(ID_i||PW_i||σ_i) and the pseudo-random identity PID_i = h(ID_i||r₁). Finally, SD_i sends U_i’s information {PWD_i, PID_i} to the server S_j via a secure channel.

Step 2: Upon receiving PWD_i and PID_i, the server S_j selects random numbers r₂ and r₃, calculates Z_j = h(PID_i||r₂||k), N_j = PWD_i⊕Z_j, and EID_p = Enc_k (PID_i||r₃), and then stores {PID_i, r₂} on the blockchain. In these calculations, k is S_j’s private key, and Enc_k represents symmetric encryption using k. S_j finally sends the smart card {EID_p}, {N_j} back to U_i via a secure channel.

Step 3: Upon receiving the smart card, U_i performs the following calculations to create parameters required for authentication: E_i = N_j⊕h(PWD_i||σ_i), G_i = N_j⊕r₁, and F_i = h(PWD_i||PID_i||N_j). Then, it stores the parameters {ρ_i, E_i, G_i, F_i} on the smart card, with the smart card now containing {EID_p, ρ_i, E_i, G_i, F_i, Gen(·), Rep(·)}.

5.3. Avatar Generation Phase

In the avatar generation stage, in order to ensure the correspondence between the user identity and the generated avatar identity, the user needs to verify the user identity information on the login device. After verification is completed, the randomly generated avatar identity is encrypted, and then the encrypted avatar identity, symmetric key, and verification information are transmitted to the server through a secure channel. After receiving it, the server completes the user identity verification and stores the corresponding avatar identity of the user. The avatar generation phase is depicted in Figure 3 and is described as follows.

Step 1: The user U_i inputs their identity ID_i, password PW_i, and biometric information B_i. Using the smart card’s stored biometric fuzzy extractor generation function Rep(·), ρ_i, E_i, G_i, and F_i, the user calculates σ_i* = Rep(B_i, ρ_i), PWD_i* = h(ID_i||PW_i||σ_i*), N_j* = E_i⊕h(PWD_i*||σ_i*), r₁* = G_i⊕N_j*, PID_i* = h(ID_i||r₁*), and F_i* = h(PWD_i*||PID_i*||N_j*). They then verify whether F_i* equals F_i. If not, the session is terminated; otherwise, U_i generates the avatar identity Avatar_i and calculates Z_j = N_j⊕PWD_i, V₁ = Avatar_i⊕Z_j, GID_i = PID_i⊕V₁, and M_i = h(Z_j||V₁||GID_i). Finally, U_i extracts EID_p from the smart card and sends {EID_p, GID_i, M_i} to S_j via a secure channel.

Step 2: Upon receiving the information from U_i, S_j first decrypts (PID_i*||r₃) = Dec_k (EID_p) using the symmetric decryption algorithm Dec_k (·) with the key k, to obtain U_i’s PID_i, then retrieves the stored r₂ from the blockchain using PID_i. Next, S_j calculates Z_j* = h(PID_i*||r₂||k), V₁* = GID_i⊕PID_i*, and M_i* = h(Z_j*||V₁*||GID_i*). After completing these calculations, S_j verifies whether M_i* = M_i; if not, the session is terminated. Otherwise, S_j calculates Avatar_i = V₁⊕Z_j and finally stores {PID_i, Avatar_i} in the server’s database.

5.4. Login and Authentication Phase

At this stage, users need to negotiate session keys with the server to ensure communication security. After verifying user identity information, the user encrypts the generated avatar identity. The user device sends the symmetric key, verification message, and timestamp to the server through a public channel. Once receiving this information, the server will verify the authenticity of the information. After verification is completed, the server negotiates the session key and updates the symmetric key. Then, the verification information and timestamp are sent to the user device. When the user device receives it, the verification calculation is performed to obtain the new symmetric key, which completes the session key negotiation with the server and updates the symmetric key in the smart card. The login and authentication phase of the scheme is depicted in Figure 4.

Step 1: Initially, before negotiating a session key with S_j, SD_i needs to verify U_i’s identity to grant U_i access to the parameters stored on the smart card. U_i enters their identity ID_i, password PW_i, and biometric information B_i. Then, the calculations σ_i* = Rep(B_i, ρ_i), PWD_i* = h(ID_i||PW_i||σ_i*), Nj* = E_i⊕h (PWD_i*||σ_i*), r₁* = G_i⊕N_j*, PIDi* = h(ID_i||r₁*), and F_i* = h(PWD_i*||PID_i*||N_j*) are performed. F_i* is checked against F_i. If they do not match, the session is terminated. Otherwise, Z_j = N_j⊕PWD_i is calculated along with a random number r₄ and timestamp T₁. Following this, X_p = r₄P, N_u = X_p⊕Avatar_i, and V₂ = h(PID_i||Z_j||X_p||N_u||T₁) are computed. Finally, {EID_p, X_p, V₂, T₁} is sent to S_j.

Step 2: Upon receiving {EID_p, X_p, V₂, T₁}, S_j first checks the freshness of T₁. If T₁ exceeds the maximum delay allowed during transmission, the session is ended. Otherwise, S_j decrypts EID_p using the symmetric decryption algorithm Dec_k (·) to obtain PID_i and r₃. Then, S_j retrieves r₂ stored on the blockchain and Avatar_i stored in the server database using PID_i. Subsequently, Z_j* = h(PID_i*||r₂||k), N_u* = X_p⊕Avatar_i, and V₂* = h(PID_i*||Z_j*||X_p||N_u*||T₁) are calculated, and V₂* is verified against V₂. If they do not match, the session is terminated. Otherwise, a random number r₅ and timestamp T₂ are selected. The computations V₃ = r₅P, V₄ = r₅X_p, SK = h(PID_i||V₄||T₂), EID_p^new = Enc_k (PID_i||r₅), V₅ = EID_p^new⊕h (SK), and V₆ = h(Z_j||V₃||SK||EID_p^new||V₅||T₂) are performed, where SK serves as the negotiated session key between S_j and U_i, and V₆ serves as the verification message. Finally, S_j sends {V₃, V₅, V₆, T₂} to U_i.

Step 3: Upon receiving {V₃, V₅, V₆, T₂} from S_j, U_i checks the freshness of T₂. If T₂ exceeds the maximum delay allowed during transmission, the session is terminated. Otherwise, V₄* = V₃r₄, SK* = h(V₄*||T₂), EID_p^new = V₅⊕h(SK*), and V₆* = h(Z_j||V₃||SK*||EID_p^new||T₂) are calculated. V₆* is then verified against V₆. If they do not match, the session is terminated. Otherwise, the session key negotiation is complete, and U_i updates EID_p on the smart card to EID_p^new.

6. Security Analysis

The security analysis of the scheme is crucial for verifying its capability to ensure secure communication. It mainly includes informal security analysis and formal security analysis. In the scheme security analysis sections of references [6,8,10,11], both informal security analysis and formal security analysis using AVISPA tools were used. Therefore, this section first verifies the security of the proposed authentication scheme suitable for the metaverse environment through informal security analysis, then employs the AVISPA tool for formal security analysis, and finally compares the security properties with authentication schemes in similar environments.

6.1. Informal Security Analysis

(1) Anonymity: Throughout the design process of this scheme, no plaintext information regarding user U_i’s identity (ID_i), avatar identity (Avatar_i), or server S_j’s identity was transmitted via any channel. The protection of anonymity for U_i and Avatar_i is as follows: During the registration phase, U_i encrypts ID_i and a randomly generated number r₁ into PID_i = h(ID_i||r₁) using hash operations, and throughout the entire scheme, U_i communicates with S_j using this encrypted identity PID_i. Therefore, attackers cannot obtain U_i’s ID_i through eavesdropping. Assuming an attacker possesses S_j’s private key k and the decryption algorithm Dec_k(·), and intercepts the information U_i sends to S_j during the login and authentication phase, including EID_p, X_p, and T₁, the attacker could only derive PID_i by decrypting EID_p = Dec_k(PID_i*||r₃) with Dec_k(·). Furthermore, with X_p being r₄P, without U_i’s random number r₄, solving X_p = r₄P poses a mathematical challenge for the attacker, thus preventing them from deriving Avatar_i through N_u = X_p⊕Avatar_i. Additionally, with k as the symmetric decryption key, the identity of servers possessing k remains secure, making it challenging for attackers to impersonate or identify S_j without k. Even if attackers can obtain PID_i, calculating Z_j = h (PID_i||r₂||k) without S_j’s random number r₂ remains a mathematical difficulty. Therefore, this scheme ensures the anonymity of U_i, Avatar_i, and S_j identities.

(2) Unlinkability: During the login and authentication phase, the information transmitted between U_i and S_j over public channels cannot be used by attackers to confirm the identities of the communication parties across multiple session rounds, even if they intercept multiple messages {EID_p, X_p, V₂, T₁} and {V₃, V₅, V₆, T₂}. This is because EID_p is updated to EID_p^new = Enc_k (PID_i||r₅) after each login and authentication session, where r₅ is a random number generated by S_j. Additionally, the rest of the transmitted message parameters include operations with timestamps or random numbers, ensuring that messages are refreshed after each session. Therefore, this scheme maintains unlinkability.

(3) Mutual authentication: During the login and authentication phase, U_i sends information {EID_p, X_p, V₂, T₁} to S_j, who then, using the private key k, decrypts (PID_i*||r₃) = Dec_k (EID_p). By extracting PID_i*, S_j retrieves the corresponding r₂ from the blockchain and Avatar_i from the server database. Subsequently, S_j calculates N_u* = X_p⊕Avatar_i and V₂* = h (PID_i*||Z_j*||X_p||N_u*||T₁), and it verifies whether V₂* = V₂ holds true. If it does, the server successfully authenticates U_i and Avatar_i. Then, S_j sends {V₃, V₅, V₆, T₂} to U_i, who completes the authentication of the server by verifying whether V₆* = V₆. Thus, this scheme enables mutual authentication among U_i, S_j, and Avatar_i.

(4) Session key negotiation: S_j, by selecting a random number r₅ and a timestamp T₂, calculates the session key SK = h(PID_i||V₄||T₂) and sends the information {V₃, V₅, V₆, T₂} to U_i. Upon receiving this information, U_i calculates SK* = h(PID_i||V₄*||T₂) and verifies if V₆* = V₆ matches. If both are equal, the session key negotiation process is complete. U_i and S_j can then engage in secure interactions using this session key.

(5) Resistance to offline password guessing attacks: In this scheme, U_i’s PW_i is encrypted through a hash function with the private parameter σ_i generated by the fuzzy extractor and U_i’s ID_i and then transmitted between U_i and S_j via a secure channel. Assuming an attacker gains access to the parameters stored on the smart card {EID_p, ρ_i, E_i, G_i, F_i, Gen (·), Rep (·)} and the equation PWD_i = h(ID_i||PW_i||σ_i), the attacker still cannot guess the password, as they would not have access to U_i’s real identity information ID_i and the private parameter σ_i generated by the fuzzy extractor. Therefore, this scheme is resistant to offline password guessing attacks.

(6) Resistance to smart card theft attacks: Assuming an attacker steals the smart card of U_i through any means and extracts the stored information {EID_p, ρ_i, E_i, G_i, F_i, Gen(·), Rep (·)}, they cannot obtain U_i’s real identity information (ID_i). This is because ID_i, combined with a randomly generated number r₁ by U_i, is encrypted into PID_i = h(ID_i||r₁) using a hash function. Even if the attacker obtains r₁ and PID_i, they cannot calculate ID_i due to the irreversible nature of the hash function. Furthermore, assuming the attacker acquires S_j’s private key k, they could only obtain PID_i by computing (PID_i||r₃) = Dec_k (EID_p). Additionally, the attacker cannot obtain the private parameter σ_i generated by the fuzzy extractor without U_i’s biometric information B_i, as they cannot perform the calculation σ_i = Rep (B_i, ρ_i). Therefore, this scheme possesses security attributes resistant to smart card theft attacks.

(7) Resistance to replay attacks: A replay attack involves an attacker obtaining and using previously intercepted information sent between U_i and S_j to create a new connection in the name of S_j or U_i, making it difficult for the intended S_j or U_i to distinguish whether the received message is a repeat or outdated. In this scheme, the use of random numbers r₄ and r₅ along with timestamps T₁ and T₂ by U_i and S_j, respectively, counters such attacks and maintains the freshness of the messages.

(8) Resistance to man-in-the-middle attacks: In this type of attack, the information transmitted between U_i and S_j is intercepted or eavesdropped on by an attacker. One of the most effective ways to prevent this type of attack is through mutual authentication. As analyzed above, this scheme possesses characteristics of mutual authentication; therefore, attackers cannot impersonate U_i or S_j to interact with the intended S_j or U_i.

(9) Resistance to insider attacks: In such attacks, privileged insiders within the system may exploit their access to information for malicious purposes. Assuming an attacker has access to all information on U_i’s smart card {EID_p, ρ_i, E_i, G_i, F_i, Gen(·), Rep(·)} and the PWD_i and PID_i sent by U_i to S_j, they still cannot log in as a legitimate user because the calculation F_i* = h (PWD_i*||PID_i*||N_j*) and verification of F_i* = F_i is required, where F_i* is derived from N_j* = E_i⊕h(PWD_i*||σ_i*), and without U_i’s biometric information B_i, the attacker cannot calculate N_j*. Even if the attacker possesses the server’s key k, they cannot masquerade as a legitimate entity without also having the random number r₂ stored on the private blockchain. Therefore, this scheme effectively resists insider attacks.

(10) Resistance to known session-specific temporary information attacks: In such attacks, assuming an attacker can find session-specific temporary information, such as the random numbers r₄ and r₅ used during session negotiation, they might forge the session key. However, in this scheme, the session key SK = h(PID_i||V₄||T₂) cannot be calculated by the attacker without PID_i. Since PID_i is securely transmitted to S_j via a secure channel during U_i’s registration phase, and even if the attacker intercepts the message EID_p sent by U_i to S_j during the login and authentication phase, they cannot calculate PID_i without S_j’s key k. Thus, this scheme resists attacks involving known session-specific temporary information.

In conclusion, the proposed scheme meets the security objectives, resisting various attacks, and ensures secure communication among users, avatars, and servers, safeguarding user access to interactive services within the metaverse environment.

6.2. Formal Security Analysis with AVISPA

AVISPA formal security analysis occurs in virtual machine environments with SPAN installed. In the formal security analysis conducted with AVISPA, the authentication scheme is described using the HLPSL (High-Level Protocol Specification Language). The complete description includes definitions for each role involved in the scheme, explanations of roles representing components of the scheme, and the definition of the execution environment. Consequently, this section defines the proposed authentication scheme in HLPSL language as comprising four roles: the basic roles of user and server, the session role, and the environment role. The definition of the session role serves to instantiate basic roles for a complete protocol session, while the environment role includes definitions of security goals, adversary capabilities, and authentication objectives.

The definition of the user role is illustrated in Figure 5. Initially, the execution of the user registration phase begins upon the user role receiving a start signal. The state is then changed from 0 to 1 to execute the hashing of critical parameters and send the information to the server via Snd, where Snd ({PIDi′.PWDi′}_SKus) denotes sending the message encrypted with SKus containing {PID_i′.PWD_i′}, corresponding to the secure channel used in the registration phase of the proposed scheme. The notation secret ({IDi, PWi, Bi, R1′}, s1, {U}) indicates that the information {IDi, PWi, Bi, R1′} is known only to participant U, as identified by s1. Following this, upon the user receiving a message from the server Rcv ({EIDp′.Nj′}_SKus), the state transitions to 2 to continue with the registration of the user and avatar phases. During the login and authentication phase, upon receiving a message from the server Rcv (V3′.V5′.V6′.T2′), the state transitions to 3, concluding the session key negotiation. The notation witness (U, S, user_server_r4, R4′) signifies strong identity verification between participant U and S, facilitated by the keyword R4′ generated by participant U, with user_server_r4 identifying the involved roles in authentication. The notation secret ({SK}, s4, {U, S}) signifies that the session key SK is known only to participants U and S, as identified by s4.

The server role definition is showcased in Figure 6. The server sends EIDp′ = {PIDi′.R3′}_K encrypted with participant S’s private key K to the user during the registration phase, facilitating subsequent identity authentication of participant U and their avatar identity AVATARi′. The use of witness (S, U, server_user_r5, R5′) strengthens the identity authentication between participant S and U, concluding their session negotiation to ensure communication security.

The HLPSL language description of the session and environment roles is presented in Figure 7. In the session part, the roles of user and server are combined for protocol instantiation. The environment part defines the information that the attacker i can capture and specifies six security goals and two authentication objectives, where the security goals define certain important values to be kept confidential among specified participants, and the authentication objectives pertain to the aforementioned strong identity verification.

After completing the definition of each role mentioned above, it was input in SPAN. The SPAN input interface is shown in Figure 8. The security analysis results of the AVISPA tool calling OFMC backend are shown in Figure 9a. As shown in the figure, through OFMC backend verification, the solution is secure. In other words, the specified security objectives are met for a limited number of sessions defined in the environment role. The security analysis results using the CL-AtSe backend of the AVISPA tool, as shown in Figure 9b, indicate that the scheme is SAFE in the SUMMARY section, proving the scheme’s security. In summary, the scheme proposed in this paper is secure under the scrutiny of the AVISPA formal analysis tool, capable of resisting various attacks.

6.3. Security Properties Comparison

The security properties of a scheme determine its susceptibility to security risks during use. Following the above security analysis, this scheme is capable of resisting various attacks, including offline password guessing attacks, insider attacks, and smart card theft. Based on this, a comparison of security properties with similar authentication schemes in internet, IoT, and metaverse environments was conducted, as shown in

Table 2. Comparison of security attributes of different authentication schemes.

Security Features	Literature [10]	Literature [11]	Literature [25]	Literature [26]	Our Scheme
Anonymity	1	1	1	0	1
Unlinkability	1	1	0	0	1
Mutual authentication	1	1	1	1	1
Session key negotiation	1	1	1	1	1
Resistance to offline password guessing attacks	1	1	1	1	1
Resistance to smart card theft attacks	1	1	1	0	1
Resistance to replay attacks	1	1	1	1	1
Resistance to man-in-the-middle attacks	1	1	1	1	1
Resistance to insider attacks	1	1	0	1	1
Resistance to known session-specific temporary information attacks	1	1	1	0	1

0: Indicates that the security attribute is not present; 1: Indicates possessing the security attribute.

. This comparison reveals that, compared to the authentication schemes in internet environments discussed in the literature [25] and IoT environments discussed in the literature [26], our scheme exhibits a higher resistance to attacks. It shares similar security properties with the authentication schemes for the metaverse environment described in the literature [10,11].

7. Performance Analysis

This section compares the computation and communication overheads with the authentication schemes in internet, IoT, and metaverse environments from the literature [10,11,25,26].

7.1. Computation Overhead

In the comparative analysis of computation overhead, the MIRACL library was used to measure the operational costs involved in the computation process, analyzed on a laptop with a 12th Gen Intel (R) Core (TM) i5-12500H processor, 16.0 GB RAM, running Windows 11. The measured approximate times are shown in

Table 3. The execution time corresponding to different arithmetic operations.

Notation	Definition	Execution Time (ms)
Tecm	ECC point multiplication execution time	4.4542
Teca	ECC point addition execution time	0.0332
Th	Hash function execution time	0.0404
TBh	Biological hash function execution time	0.0404
TFe	Fuzzy extractor execution time	4.4542
TEk/TDk	Symmetric encryption/decryption execution time	0.0015

. From Table 3, the meanings of different symbols and the execution time for each operational operator can be discerned. The computational costs for fuzzy extractors and biometric hash functions can be equated to the execution times for point multiplication operations and hash functions [27], while the times for string concatenation and XOR operations are negligible. The metaverse, as a mapping of the physical world, shuttles massive amounts of data through cyberspace. The computational power of processing this information affects the user experience and system responsiveness. Although the computational cost in identity authentication schemes only exists as a small part, the user experience and system responsiveness will not be significantly affected with the participation of a small number of users. However, as the number of users in the metaverse increases, authentication schemes with lower computational costs can help improve the user experience and system responsiveness.

Referring to the form of overhead calculation in the literature [10], that is, comparing the computation overhead of the login and authentication phase in different environments, the user-side computation cost described in the literature [10] is 3T_ecm + 10T_h + 1T_Fe ≈ 18.22 ms, and the server-side computation cost is 3T_ecm + 5T_h ≈ 13.56 ms, totaling 31.78 ms. In the literature [11], the user-side computation cost is 4T_ecm + 1T_eca + 8T_h + 2T_Bh ≈ 18.25 ms, and the server-side cost is 5T_ecm + 1T_eca + 5T_h ≈ 22.51 ms, totaling 40.76 ms. Reference [25] shows a user-side cost of 3T_ecm + 12T_h + 2T_Ek/T_Dk ≈ 13.85 ms and a server-side cost of 2T_ecm + 9T_h + 2T_Ek/T_Dk ≈ 9.28 ms, totaling 23.13 ms. Reference [26] reports a user-side cost of 2T_ecm + 10T_h + 1T_Fe + 2T_Ek/T_Dk ≈ 13.77 ms and server-side cost of 2T_ecm + 9T_h + 2T_Ek/T_Dk ≈ 9.28 ms, totaling 23.05 ms. The proposed scheme’s user-side computation cost is 2T_ecm + 7T_h + 1T_Fe ≈ 13.65 ms, and the server-side cost is 2T_ecm + 5T_h + 2T_Fe ≈ 9.11 ms, totaling 22.76 ms. The computation costs of the schemes are illustrated in

Table 4. The computation costs of different schemes.

Scheme	Computation Costs
	User	Server	Total Costs
Reference [10]	3Tecm + 10Th + 1TFe ≈ 18.22 ms	3Tecm + 5Th ≈ 13.56 ms	31.78 ms
Reference [11]	4Tecm + 1Teca + 8Th + 2TBh ≈ 18.25 ms	5Tecm + 1Teca + 5Th ≈ 22.51 ms	40.76 ms
Reference [25]	3Tecm + 12Th + 2TEk/TDk ≈ 13.85 ms	2Tecm + 9Th + 2TEk/TDk ≈ 9.28 ms	23.13 ms
Reference [26]	2Tecm + 10Th + 1TFe + 2TEk/TDk ≈ 13.77 ms	2Tecm + 9Th + 2TEk/TDk ≈ 9.28 ms	23.05 ms
Our scheme	2Tecm + 7Th + 1TFe ≈ 13.65 ms	2Tecm + 5Th + 2TFe ≈ 9.11 ms	22.76 ms

, and a comparative graph is shown in Figure 10. The calculation of computational costs in Table 4 is based on the number of execution times of different operations in the authentication schemes in the corresponding references. For example, according to the operation mentioned in Table 3, in the authentication scheme in the literature [10], 3 T_ecm, 10 T_h, and 1 T_Fe were performed on the user side, and 3 T_ecm and 5 T_h were performed on the server side. However, T_eca, T_Bh and T_Ek/T_Dk were not performed in this scheme. The order of references cited from left to right in Figure 10 is [10,11,25,26]. The dotted line in Figure 10 represents the trend line, which more intuitively shows that our proposed solution has the lowest computational cost. From Table 4 and Figure 10, it is evident that the proposed authentication scheme exhibits higher computation efficiency in the login and authentication phase, especially when compared to the two metaverse environment schemes, showcasing lower computation overhead.

7.2. Communication Overhead

This section compares the communication overhead during the login and authentication phases of identity authentication schemes mentioned in References [10,11,25,26]. Initially, definitions for the bit sizes of different parameters were established, as shown in

Table 5. The lengths of different parameters.

Parameter	Bits
Points on elliptic curves	160
Hash function	256
Symmetric encryption/decryption	128
Timestamp	32
Other	128

. In this article, based on the definition of the number of bits for different parameters in Table 5, the same computing environment will be created to compare the communication overhead of different authentication schemes. From the table, the bit sizes for different parameters in the authentication schemes are defined as follows: points on the elliptic curve are 160 bits, hash functions are 256 bits, symmetric encryption/decryption keys are 128 bits, timestamps are 32 bits, and other used parameters are 128 bits.

In our scheme, the messages sent over public channels during the login and authentication phases are {EID_p, X_p, V₂, T₁} and {V₃, V₅, V₆, T₂}, consuming 832 and 1088 bits, respectively, totaling 1920 bits. According to Reference [10], messages sent during these phases are {N₁, U₁, T₁} and {N₂, U₃, T₂}, consuming 1248 and 448 bits, respectively, totaling 1696 bits. Reference [11] sends messages {EM₁, S₁, T₁} and {EM₂, S₃, T₂} during these phases, consuming 1504 and 448 bits, respectively, totaling 1952 bits. Reference [25] sends {E₁, P₃} and {E₂, TL_A3} during the login and authentication phases, consuming 2240 and 1216 bits, respectively, totaling 3456 bits. Reference [26] sends {E₁, I₁, T₁} and {E₂, T₃} during the login and authentication phases, consuming 1088 and 1312 bits, respectively, totaling 2400 bits. The comparison of communication overheads among these schemes is presented in

Table 6. Comparison of communication costs between login and authentication stages.

Scheme	Number of Messages	Total Communication Overhead (bits)
Reference [10]	2	1696
Reference [11]	2	1952
Reference [25]	2	3456
Reference [26]	2	2400
Our scheme	2	1920

. A comparative chart of communication overhead is shown in Figure 11. The order of references cited in Figure 11 from top to bottom is [10,11,25,26]. From Table 6 and Figure 11, it is evident that our scheme has a lower communication overhead compared to References [11,25,26] and is slightly more efficient than Reference [10], thus indicating cost-effectiveness in terms of communication overhead.

8. Conclusions

Given the complex network environment of the metaverse, where identity security risks are increasingly unpredictable, this paper introduces an elliptic curve-based identity authentication scheme suitable for the metaverse environment. The security of this scheme is validated using the AVISPA tool, demonstrating its security. Moreover, by comparing security properties with authentication schemes in internet, IoT, and metaverse environments, our scheme shows resilience against known attacks. Additionally, a comparison of computational overheads using the MIRACL library indicates our scheme requires less computation time, and in terms of communication overhead, it utilizes fewer bits to complete user identity login and authentication. Therefore, our scheme demonstrates more efficient and secure characteristics in terms of security properties and computational and communication overheads, making it better suited for identity authentication in the metaverse environment.