A Personal Privacy-Ensured User Authentication Scheme

Abstract

User authentication verifies the legitimacy of users and prevents service providers from offering services to unauthorized parties. The concept is widely applied in various scenarios, including everyday access control systems and IoT applications. With growing concerns about personal privacy, ensuring user anonymity has become increasingly important. In addition to privacy, user convenience is also a key factor influencing the willingness to adopt a system. To address these concerns, we propose a user authentication scheme that ensures personal privacy. The system consists of a backend server, multiple users, and multiple control units. Each user is issued or equipped with an authentication unit. An authorized user can be authenticated by a control unit, with assistance from the backend server, without revealing their identity to the control unit. The scheme is suitable for applications requiring privacy-preserving authentication. Furthermore, to enhance generality, the proposed design ensures computational efficiency and allows the authentication unit to adapt to specific application requirements.

1. Introduction

User authentication verifies the legitimacy of users, ensuring that only authorized individuals can access resources or services. This concept is widely applied across various domains. For example, in community security, residents can be authenticated using dedicated RFID tags. In online banking, customers must provide their registered credentials, such as a username and password, for precise identity verification by the bank’s server. Due to the rapid progress of technologies, we are now surrounded by various portable, sensing, wearable, and smart devices. A variety of applications are proposed and realized. Among them, the concept of IoT (the Internet of things) is the most popular. IoT devices can be sensors, RFID tags, RFID readers, smartphones, wireless sensors, and so on. These IoT devices can communicate with each other via the networks, and various IoT applications are proposed, such as IoV (the Internet of vehicles), smart grid, smart home, and eHealth. In some IoT applications, sensors or devices will collect the user’s private information and then transmit it to the server via the internet. For example, an OBU (on-board unit) in IoV records and collects the vehicle’s location and route, and wearable sensors sense and collect the user’s physiological data for eHealth. Since the data are transmitted over a public channel, Lamport [1] proposed the first password authentication scheme to ensure security.

Wang and Ma [2] analyzed the ECC-based ID authentication scheme for mobile applications, revealing vulnerabilities like reflection and parallel session attacks. Their analysis helps prevent similar design flaws in future cryptographic protocol development. Turkanović et al. [3] proposed a lightweight authentication and key agreement scheme for heterogeneous WSNs, enabling secure remote access without contacting the gateway. Using only hash and XOR operations, it achieves mutual authentication among users, sensor nodes, and gateways. Amin et al. [4] proposed a robust smartcard-based authentication and key agreement protocol for IoT-enabled WSNs. It overcomes vulnerabilities in prior schemes, supports identity change and card revocation, preserves user anonymity, and resists various attacks. Their simulation confirms its security, with improved performance compared to related protocols. A double-blockchain assisted scheme [5] for fog-enabled smart grids was proposed to ensure secure, anonymous, and efficient data aggregation using Paillier encryption, batch signatures, and anonymous authentication. The three-tier architecture supports fine-grained aggregation, power dispatching, and low computational overhead, enhancing both privacy and performance. Wu et al. [6] proposed a multi-server authentication and key agreement protocol that incorporates multi-factor authentication and hierarchical key management using hashes, Merkle trees, and graph-based derivation, ensuring privacy-aware access control with low resource consumption, making it ideal for IIoT systems with diverse users and limited computational capacity. For V2G networks, a PUF-based lightweight authentication and key agreement framework is proposed [7] to provide bidirectional authentication, session key secrecy, user anonymity, and strong resistance against physical and common cyber attacks—all with low computational overhead. Another novel six-step authentication protocol [8] was proposed to ensure privacy-preserving mutual authentication and session key establishment between vehicles, achieving 39% reduction in communication cost and 91% reduction in computation cost while maintaining strong security and efficiency.

From then on, many authentication schemes have been proposed [9,10,11,12,13,14,15,16,17,18,19,20,21,22] to defend against various attacks in various environments to protect the transmitted data. Lo and Tsai [13] proposed a novel ECC-based identity-based signature scheme that enables conditional privacy-preserving authentication and batch verification in vehicular sensor networks, eliminating pairing and MapToPoint operations to enhance efficiency and outperform existing pseudo-ID-based methods in message processing speed. Zeng et al. [14] prevented an efficient two-user ring signature-based deniable authentication protocol to prevent IoT location leakage in edge computing. It enhances location privacy and reduces computational costs by up to 14.696% over existing solutions. An ECC-based authentication scheme [15] was proposed to enhance security while maintaining efficiency through lightweight operations, making it well-suited for resource-constrained IoT environments and resistant to various known attacks. Chang et al. [16] presented an anonymous, non-repudiation user authentication system enabling executives to be verified by departments without revealing their identities. The scheme ensures secure, privacy-preserving authentication with fixed device data despite personnel changes, meeting special organizational requirements. Shamshad et al. [17] proposed an anonymous identity-based authentication scheme for MEC, ensuring lightweight, real-time security for resource-constrained devices. The scheme enhances user anonymity, reduces computational cost, and outperforms previous methods in both efficiency and communication overhead under a formal security model.

In 2024, Chang et al. [18] proposed a biometrics-based mutual authentication scheme for eHealth systems, enhancing security and privacy in patient monitoring and telecare medical information systems. It improves existing protocols by ensuring user convenience while protecting sensitive data, enabling secure remote healthcare services through sensor networks. In 2025, Huang et al. [19] proposed a lightweight, anonymous authentication scheme for federated learning. Using ECC and CRT, it supports batch verification, dynamic updates, and identity traceability, ensuring privacy, integrity, and efficiency while resisting poisoning and free-rider attacks with low computational overhead. A lightweight authentication and privacy-preserving aggregation scheme for blockchain-enabled federated learning in VANETs is proposed by Liu et al. [20]. It ensures secure model transmission, continuous authentication, and reliable aggregation, enhancing privacy, integrity, and model accuracy in dynamic vehicular environments. Seifelnasr et al. [21] proposed a cross-domain, privacy-preserving authentication protocol for VANET emergency messages. It ensures message integrity, anonymity, and traceability, resists attacks, supports secure cross-domain communication, and achieves low overhead and delay, proven via formal analysis and implementation. Yu et al. [22] proposed a cross-layer PUF-based authentication and key agreement protocol for IIoT. It ensures strong security, device anonymity, and low overhead by integrating CRPs into cryptographic and physical-layer features, achieving excellent performance in 3GPP-compliant factory scenarios.

In modern society, there exist various enterprises in our daily lives. An enterprise may hold promotional activities for competition or a cross-industry alliance. For example, company A and company B may cooperate to hold one promotion activity such that a member of company A can utilize company B’s resources or access company B’s services when the activity is held. The member of company A can present his/her membership card to prove his/her legitimacy and get the special offers given by company B. However, this allows company B to obtain the member’s information through these activities. Furthermore, company B can analyze the collected data to realize the member’s habits or preferences. Thereupon, company B can utilize these data and analyses for business competition, which can result in customer attrition or revenue loss for company A. On the other hand, the user may be reluctant to disclose personal information or receive unsolicited marketing messages. With the growing emphasis on personal privacy, ensuring user anonymity has become a critical concern. In the above example, concealing the member’s identity not only ensures user anonymity but also protects company A’s rights.

Taking the above into consideration, we will propose a user authentication scheme ensuring personal privacy in the above special scenario. That is, the proposed scheme should help the user be authenticated by the registered server without revealing who he/she is to others, even the legal cooperators. Unlike prior authentication schemes [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22], which use fixed types of authentication factors, our proposed scheme supports three flexible categories: (1) something you know, such as a password; (2) something you have, such as a token, smart card, or portable device; and (3) something you are, such as a fingerprint or iris pattern. As to the password, an additional password input device is needed, and this may result in other problems. Firstly, the additional input device may malfunction or be damaged by someone on purpose. Secondly, entering the password is inconvenient to users and it exposes them to peeping. As to something you are, various additional input devices are also needed. Such input devices vary to get the desired features, and they are expensive. Firstly, these input devices may malfunction or be damaged by someone on purpose as well. Secondly, feature retrieving is more complex and may be error-prone. To make the proposed scheme general and take convenience into consideration, each user in the proposed scheme will be issued an authentication unit or utilize something held to be the authentication unit, and the proposed authentication scheme needs to provide computational efficiency.

In the proposed authentication scheme, there exist one backend server, multiple users, and multiple control units. The proposed authentication scheme makes an authorized user use his/her authentication unit to be authenticated by the control unit with the backend server’s help while who he/she is will not be known by the control unit. After the user is authenticated successfully, the control unit will provide the user with the requested service. The proposed scheme will ensure personal privacy, security, efficiency, and convenience, and it can be applied to applications possessing such special properties.

To sum up, the proposed authentication scheme should possess the following properties:

• Anonymity: The control unit/the third party cannot retrieve who the user is, even after the user is authenticated by it successfully.
• Untraceability: No control unit or attacker can trace specific user by the transmitted authentication data.
• Mutual authentication: Any two communication parties can authenticate each other to ensure that the involved communication parties are legal.
• Security: In order to provide essential security, the proposed scheme must resist common attacks.

The rest of this paper is organized as follows. Application scenarios of the proposed personal privacy-ensured user authentication scheme are illustrated in Section 2. The proposed authentication scheme is shown in Section 3, followed by the corresponding property analysis in Section 4. Further discussions are made in Section 5. At last, some conclusions are drawn in Section 6.

2. Application Scenarios of the Proposed Personal Privacy-Ensured User Authentication Scheme

To illustrate the broad applicability of the proposed user authentication scheme that ensures personal privacy, two application scenarios are presented below. In these examples, smart cards, RFID tags, and mobile devices with varying computational capabilities are employed as authentication units. These examples demonstrate that the proposed scheme maintains both security and user convenience. The details are described as follows.

2.1. Scenario 1—Applications for Franchising

In the first scenario, we discuss franchising, a marketing concept for an enterprise that can be considered a market expansion strategy. With franchising, franchisees can quickly acquire proprietary technology, procedures, intellectual property, and other business knowledge. The franchisor will also license the franchisees to use the business model, brand, and rights. Franchisees only need to pay the corresponding fee and comply with the contract’s requirements and obligations. By this strategy, enterprises can quickly expand the target market with low investment costs. However, while franchising provides numerous advantages, it may lack privacy protection for its members. For example, in Figure 1, there are restaurant A, franchisee Eve, competitor restaurant C, and member Bob of restaurant A. In the example, A and Eve have signed a franchise agreement, and Bob is a customer of the franchise store owned by Eve. At the same time, Bob can enjoy the same membership benefits and use the mobile membership application to track his records. The franchisee’s store is not affiliated with A. When the contract is going to expire, it may come to Eve to open a new restaurant or to be licensed by a new franchisor. If A fails to protect users’ privacy such that Eve gets member information or customers’ related records, this may result in serious problems. Firstly, Eve may provide member information to restaurant C, the competitor of restaurant A. Secondly, member Bob’s consumption behavior can be analyzed by the obtained data, and this may further result in the disclosure of Bob’s personal information. To protect the rights and interests of A and Bob, the proposed authentication scheme can be implemented to help member Bob be authenticated by Eve’s franchise store when Bob’s personal information is protected from being revealed to unauthorized parties. Moreover, the proposed authentication scheme can make the member enjoy the membership benefits and protect him/her from being tracked at the same time.

2.2. Scenario 2—Applications for Co-Branding

In the second scenario, we discuss co-branding, a strategy of business marketing. Co-branding is an arrangement that associates a product or service with two or more brands. Co-branding may increase brand awareness and help brands attract new customers or retain customer loyalty. In today’s world, such a marketing strategy can be found in various products and services. However, some of them may encounter the problem of protecting personal privacy. We now take the co-branded card as an example. As shown in Figure 2, there exist bank A, department store B, and customer Tim. A and B make an agreement to issue a co-branded card that bears the name of both the department store and the bank and provides special benefits. Tim is attracted by these benefits. After applying for this co-branded card, Tim can get benefits such as discounts or reward points by using this credit card in B. Consequently, all entities can obtain the desired benefits. However, if A fails to protect the privacy of its customers, the confidential information will be disclosed. Furthermore, a malicious user can harm A’s reputation and Tim’s interests with the disclosed confidential information. To protect the interests of both A and Tim, A can implement the proposed scheme to protect the customer’s privacy. As mentioned before, the proposed authentication scheme can ensure user privacy and security at the same time. Thus, it allows only authorized customers to enjoy the benefits provided by co-branding while personal information is still kept secret.

3. The Proposed User Authentication Scheme Ensuring Personal Privacy

As discussed, user authentication restricts system access to legitimate users. While various schemes address different system needs, security and efficiency remain critical. In addition, growing concerns over personal privacy make user anonymity a key factor in user adoption. To address these needs, we propose a user authentication scheme ensuring personal privacy. In the proposed authentication scheme, there exist one backend server, multiple users, and multiple control units. Each user will be issued an authentication unit or utilize something held to be the authentication unit. The proposed user scheme makes an authorized user use his/her authentication unit to be authenticated by the control unit with the backend server’s help while who he/she is will not be known by the control unit. Notations used in the proposed scheme are listed in

Table 1. Notations used in the proposed user authentication scheme.

Notations	Definitions
S	backend server
Ui	i-th user
Ai	Ui’s authentication unit
Rj	j-th control unit
AIDi	permanent identification number of Ai
${TID}_i^{old}$	temporary identification number of the last successful authentication iteration of Ai
${TID}_i^{new}$	temporary identification number for the next authentication iteration of Ai
TIDi	${TID}_i^{old}/{TID}_i^{new}$ transmitted in synchronous/asynchronous authentication subphase
RIDj	identification number of Rj
$K_{{SR}_j}$	secret key shared between S and Rj
$K_{{SA}_i}$	secret key shared between S and Ai
P	large prime number
g	primitive root modulo p
NA	random number generated by Ai in the authentication phase
NR	random number generated by Rj in the authentication phase
NS	random number generated by S in the authentication phase
H(.)	one-way hash function
||	connection operator

. The proposed user scheme is composed of two phases, the initialization phase and the authentication phase, and the details are as follows:

3.1. Initialization Phase

When the backend server S is configured for initialization, system parameters p and g are first generated, and a one-way hash function H(.) is selected. For different requirements, such as security levels, there exist two modes to generate random numbers, N_A, N_R, and N_S, for authentication in the proposed authentication scheme. In Mode 1, N_A, N_R, and N_S are randomly generated in each authentication iteration. In Mode 2, A_i, R_j, and S randomly choose r_A, r_R, and r_S in Z_p and compute $N_R=g^{r_R}\mathrm{m}\mathrm{o}\mathrm{d} p$, and $N_S=g^{r_S}\mathrm{m}\mathrm{o}\mathrm{d} p,$ respectively. Whenever a new user U_i wants to access services, U_i needs to register with S to obtain his/her authentication unit A_i. Before issuing A_i to U_i, A_i needs to be initialized by S. In addition, before a control unit R_j is deployed, R_j needs to be initialized by S as well. The details of how to initialize A_i and R_j are as follows:

3.1.1. Initialization of the Authentication Unit

When a new user U_i wants to access services, U_i needs to register with the server S to obtain his/her authentication unit A_i, and S will perform the following steps to initialize the authentication unit A_i.

Step 1.

S first chooses and assigns a unique identification number AID_i to A_i. Then S randomly generates a temporary identification number ${TID}_i^{old}$ and sets ${TID}_i^{new}$ = ${TID}_i^{old}$.

Step 2.

S randomly generates a secret key $K_{{SA}_i}$ shared between S and A_i.

Step 3.

S stores (AID_i, ${TID}_i^{new}$, ${TID}_i^{old}$, $K_{{SA}_i}$) in its database for A_i and stores (AID_i, ${TID}_i^{new}$, ${TID}_i^{old}$, $K_{{SA}_i}$) in A_i’s memory. If Mode 2 is applied to generating N_A, S will also store p and g in A_i’s memory; otherwise, if Mode 1 is adopted to generate N_A, only (AID_i, ${TID}_i^{new}$, ${TID}_i^{old}$, $K_{{SA}_i}$) are stored in A_i’s memory.

Step 4.

S issues the initialized A_i to U_i securely.

3.1.2. Initialization of the Control Unit

Before a control unit R_j is deployed, S performs the following steps to initialize the control unit R_j.

Step 1.

S first chooses and assigns a unique identification number RID_j to R_j. Then S randomly generates the secret key $K_{{SR}_j}$ shared between S and R_j.

Step 2.

S stores (RID_j, $K_{{SR}_j}$) in its database for R_j and stores (RID_j, $K_{{SR}_j}$) in R_j’s memory. If Mode 2 is applied to generating N_R, S will also store p and g in R_j’s memory; otherwise, if Mode 1 is adopted to generate N_R, only (RID_j, $K_{{SR}_j}$) are stored in R_j’s memory.

3.2. Authentication Phase

When U_i wants to access services via R_j, U_i will use his/her authentication unit A_i to execute a specific process. Because the authentication unit is not determined, the specific process will differ. If the authentication unit is an RFID tag, the control unit will be an RFID reader, and U_i will hold his/her RFID tag against the RFID reader. If the authentication unit is a smart card, the control unit will be a card reader, and U_i will insert his/her smart card into the card reader. After this specific process, this phase will be executed immediately. In the proposed user authentication scheme, the authentication unit’s temporary identification number will be updated in each successful authentication iteration. Data are transmitted over a public channel in this phase. That is, an attacker can interrupt or modify the transmitted data such that the authentication unit’s temporary identification numbers stored in its memory and the backend server’s database are different. The authentication phase in the proposed user authentication scheme is depicted in Figure 3. For clarity, two subphases are used to demonstrate how this phase works. Note that the synchronous authentication subphase will be first executed.

3.2.1. Synchronous Authentication Subphase

The synchronous authentication subphase will be first executed when U_i wants to be authenticated. In the synchronous authentication subphase, ${TID}_i^{new}$ will be used to identify A_i. The details are as follows:

Step 1.

The authentication unit A_i generates the authentication parameter N_A and sends {request, RID_j, ${TID}_i^{new}$, N_A} to R_j.

Step 2.

When R_j receives {request, RID_j, ${TID}_i^{new}$, N_A}, R_j generates the authentication parameter N_R and sends {request, RID_j, N_R, ${TID}_i^{new}$, N_A} to S.

Step 3.

When S receives {request, RID_j, N_R, ${TID}_i^{new}$, N_A}, it generates the authentication parameter N_S and sends N_S back to R_j

Step 4.

When N_S is received, R_j computes M₁ = H(N_A||N_R||N_S||$K_{{SR}_j}$) and sends M₁ to S.

Step 5.

After S receives M₁, S uses RID_j as the index to get $K_{{SR}_j}$ stored in its database to compute H(N_A||N_R||N_S||$K_{{SR}_j}$) and checks whether the computation result is equal to the received M₁. If they are not equal, S will determine that R_j is not a legal control unit, and the authentication phase will be terminated immediately; otherwise, S will determine that R_j is legal, and this subphase will proceed. S uses ${TID}_i^{new}$ as the index to find the corresponding data in its database. If no matched item is found, synchronous authentication subphase will be terminated immediately, and asynchronous authentication subphase will be performed instead. Otherwise, it denotes that ${TID}_i^{new}$ stored in the database of S and that stored in A_i’s memory are consistent, and the last authentication iteration is completely successful. Then S gets (AID_i, ${TID}_i^{new}$, ${TID}_i^{old}$, $K_{{SA}_i}$) from its database, computes M₂ = H(RID_j||AID_i||N_A||N_R||N_S||$K_{{SA}_i}$) and M₃ = H(RID_j||M₁||$K_{{SR}_j}$) and sends {M₂, M₃} to R_j.

Step 6.

When R_j receives {M₂, M₃}, R_j computes H(RID_j||M₁||$K_{{SR}_j}$) and checks whether the computation result is equal to M₃ or not. If they are not equal, R_j determines that S is not legal and terminates the authentication phase; otherwise, R_j sends {N_R, N_S, M₂} to A_i.

Step 7.

When A_i receives {N_R, N_S, M₂}, A_i uses its identification number AID_i and secret key $K_{{SA}_i}$ to compute H(RID_j||AID_i||N_A||N_R||N_S||$K_{{SA}_i}$) and checks whether the computation result is equal to the received M₂. If they are not equal, A_i determines other parties are illegal and terminates the authentication phase immediately; otherwise, A_i determines that S and R_j are legal and computes M₄ =H(AID_i ||M₂||$K_{{SA}_i}$). ${TID}_i^{new}$ and ${TID}_i^{old}$ stored in its memory are updated to H(N_A||N_S||$K_{{SA}_i}$||AID_i) and ${TID}_i^{new}$, respectively. At last, A_i sends {M₄} to R_j.

Step 8.

R_j forwards {M₄} to S.

Step 9.

When S receives {M₄}, it computes H(AID_i ||M₂||$K_{{SA}_i}$) and checks whether the computation result is equal to the received M₄. If they are not equal, it denotes that A_i is not authenticated successfully, and S computes M₅ = H(“No”||N_R||N_S||$K_{{SR}_j}$) and sends {No, M₅} to R_j; otherwise, it denotes that A_i is authenticated successfully by S, and S computes M₅ = H(“Yes”||N_R||N_S||$K_{{SR}_j}$), sends {Yes, M₅} to R_j, and updates ${TID}_i^{new}$ and ${TID}_i^{old}$ stored in its database to H(N_A||N_S||$K_{{SA}_i}$||AID_i) and ${TID}_i^{new}$, respectively.

Step 10.

When R_j receives the reply, R_j computes H(“No”||N_R||N_S||$K_{{SR}_j}$) or H(“Yes”||N_R||N_S||$K_{{SR}_j}$) and compares the computation result with the received M₅. If they are equal, it denotes that the response is indeed sent by S, and R_j will provide A_i with the desired service or deny the request.

3.2.2. Asynchronous Authentication Subphase

When ${TID}_i^{new}$ stored in the database of S and that stored in A_i’s memory are inconsistent, the asynchronous authentication subphase will be executed. At this moment, ${TID}_i^{new}$ stored in the database of S is the same as ${TID}_i^{old}$ stored in A_i’s memory. The details are as follows:

Step 1.

The authentication unit A_i generates the authentication parameter N_A and sends {request, RID_j, ${TID}_i^{old}$, N_A} to R_j.

Step 2.

When R_j receives {request, RID_j, ${TID}_i^{old}$, N_A}, R_j generates the authentication parameter N_R and sends {request, RID_j, N_R, ${TID}_i^{old}$, N_A}to S.

Step 3.

When S receives {request, RID_j, N_R, ${TID}_i^{old}$, N_A}, it generates the authentication parameter N_S and sends N_S back to R_j.

Step 4.

When N_S is received, R_j computes M₁ = H(N_A||N_R||N_S||$K_{{SR}_j}$) and sends M₁ to S.

Step 5.

After S receives M₁, S uses RID_j as the index to get $K_{{SR}_j}$ stored in its database to compute H(N_A||N_R||N_S||$K_{{SR}_j}$) and checks whether the computation result is equal to the received M₁. If they are not equal, S will determine that R_j is not a legal control unit, and the authentication phase will be terminated immediately; otherwise, S will determine that R_j is legal, and this subphase will proceed. S uses ${TID}_i^{old}$ as the index to find the corresponding data in its database. If no matched item is found, S sends a reply to ask R_j to inform A_i that no information related to ${TID}_i^{old}$ exists and asks A_i to execute the asynchronous authentication subphase. Otherwise, matched (AID_i, ${TID}_i^{new}$, ${TID}_i^{old}$, $K_{{SA}_i}$) are found in its database, S computes M₂ = H(RID_j||AID_i||N_A||N_R||N_S||$K_{{SA}_i}$) and M₃ = H(RID_j||M₁||$K_{{SR}_j}$) and sends {M₂, M₃} to R_j.

Step 6.

When R_j receives {M₂, M₃}, R_j computes H(RID_j||M₁||$K_{{SR}_j}$) and checks whether the computation result is equal to M₃. If they are not equal, R_j determines that S is not legal and terminates the authentication phase; otherwise, R_j sends {N_R, N_S, M₂} to A_i.

Step 7.

When A_i receives {N_R, N_S, M₂}, A_i uses its identification number AID_i and secret key $K_{{SA}_i}$ to compute H(RID_j||AID_i||N_A||N_R||N_S||$K_{{SA}_i}$) and checks whether the computation result is equal to the received M₂. If they are not equal, A_i determines that other parties are illegal and terminates the authentication phase immediately; otherwise, A_i determines that S and R_j are legal and computes M₄ = H(AID_i||M₂||$K_{{SA}_i}$). ${TID}_i^{new}$ stored in its memory is updated to H(N_A||N_S||$K_{{SA}_i}$||AID_i). At last, A_i sends {M₄} to R_j. Note that ${TID}_i^{old}$ stored in A_i’s memory does not need to be updated in the asynchronous authentication subphase.

Step 8.

R_j forwards {M₄} to S.

Step 9.

When S receives {M₄}, it computes H(AID_i||M₂||$K_{{SA}_i}$) and checks whether the computation result is equal to the received M₄. If they are not equal, it denotes that A_i is not authenticated successfully, and S computes M₅ = H(“No”||N_R||N_S||$K_{{SR}_j}$) and sends {No, M₅} to R_j; otherwise, it denotes that A_i is authenticated successfully by S, and S computes M₅ = H(“Yes”||N_R||N_S||$K_{{SR}_j}$), sends {Yes, M₅} to R_j, and updates ${TID}_i^{new}$ and ${TID}_i^{old}$ stored in its database to H(N_A||N_S||$K_{{SA}_i}$||AID_i) and ${TID}_i^{new}$, respectively. Note that ${TID}_i^{old}$ stored in A_i’s memory after updating, ${TID}_i^{new}$ stored in the database of S before updating, and ${TID}_i^{old}$ sent with the authentication request are the same.

Step 10.

When R_j receives the reply, R_j computes H(“No”||N_R||N_S||$K_{{SR}_j}$) or H(“Yes”||N_R||N_S||$K_{{SR}_j}$) and compares the computation result with the received M₅. If they are equal, it denotes that the response is indeed sent by S, and R_j will provide A_i with the desired service or deny the request.

4. Property Analysis

In the following, we will make an analysis to show that the proposed personal privacy-ensured user authentication scheme possesses the claimed properties of anonymity, untraceability, mutual authentication, and security such that it can achieve the desired requirements. The corresponding analysis is as follows.

4.1. Anonymity

In the initialization phase, the backend server S assigns a unique identification number AID_i to U_i’s authentication unit A_i, and two temporary identification numbers ${TID}_i^{new}$ and ${TID}_i^{old}$ are also set and stored in the backend server’s database and in A_i’s memory. In the authentication phase, U_i uses the temporary identification numbers ${TID}_i^{new}$ and ${TID}_i^{old}$ stored in A_i’s memory to help S identify himself/herself for synchronous authentication and asynchronous authentication, respectively. And new random numbers N_A, N_R, and N_S are generated in each session. If the user U_i is authenticated successfully, ${TID}_i^{new}$ and ${TID}_i^{old}$ stored in the backend server’s database are updated to H(N_A||N_S||$K_{{SA}_i}$||AID_i) and ${TID}_i^{new}$, respectively, for both synchronous authentication and asynchronous authentication. On the other hand, if U_i is authenticated successfully, ${TID}_i^{new}$ and ${TID}_i^{old}$ stored in A_i’s memory are updated to H(N_A||N_S||$K_{{SA}_i}$||AID_i) and ${TID}_i^{new}$ for synchronous authentication while ${TID}_i^{new}$ and ${TID}_i^{old}$ stored in A_i’s memory are updated to H(N_A||N_S||$K_{{SA}_i}$||AID_i) and ${TID}_i^{old}$ for asynchronous authentication. When a user wants to be authenticated, the synchronous authentication subphase will be first executed. That is, A_i will send ${TID}_i^{new}$ at first, for authentication. Because random numbers N_A, N_R, and N_S generated in one session differ from those in other sessions, ${TID}_i^{new}$ computed by both S and A_i in one session must differ from that in other sessions. Thus, ${TID}_i^{new}$ transmitted in one session must be different from that in other sessions. Moreover, the unique identification number AID_i is never transmitted, such that who the user is will never be revealed. Thus, the proposed user authentication scheme ensures anonymity.

4.2. Untraceability

In the authentication phase, U_i uses ${TID}_i^{new}$ and ${TID}_i^{old}$ stored in A_i’s memory to help S identify himself/herself for synchronous authentication and asynchronous authentication, respectively. If U_i is authenticated successfully, ${TID}_i^{new}$ and ${TID}_i^{old}$ stored in the backend server’s database are updated to H(N_A||N_S||$K_{{SA}_i}$||AID_i) and ${TID}_i^{new}$, respectively, for both synchronous authentication and asynchronous authentication. On the other hand, if U_i is authenticated successfully, ${TID}_i^{new}$ and ${TID}_i^{old}$ stored in A_i’s memory are updated to H(N_A||N_S||$K_{{SA}_i}$||AID_i) and ${TID}_i^{new}$ for synchronous authentication while ${TID}_i^{new}$ and ${TID}_i^{old}$ stored in A_i’s memory are updated to H(N_A||N_S||$K_{{SA}_i}$||AID_i) and ${TID}_i^{old}$ for asynchronous authentication. When a user wants to be authenticated, the synchronous authentication subphase will be first executed such that ${TID}_i^{new}$ will be sent at first for authentication. Because new random numbers N_A, N_R, and N_S are generated for each session, ${TID}_i^{new}$’s computed by both S and A_i in all sessions must differ from each other. Thus, ${TID}_i^{new}$ transmitted in one session must be different from that in other sessions. On the other hand, the parameters, such as M₁, M₂, M₃, M₄ and M₅, transmitted in the authentication phase are computed with these random numbers N_A, N_R, and N_S that are new and generated for the present session, where M₁ = H(N_A||N_R||N_S||$K_{{SR}_j}$), M₂ = H(RID_j||AID_i||N_A ||N_R||N_S||$K_{{SA}_i}$), M₃ = H(RID_j||M₁||$K_{{SR}_j}$), M₄ =H(AID_i ||M₂||$K_{{SA}_i}$), and M₅ = H(“Yes”||N_R||N_S||$K_{{SR}_j}$). As a result, parameters transmitted in one session of the authentication phase will differ from those in other sessions. Because no constant parameter will be transmitted in different sessions of the authentication phase, no one can trace a specific user; this way, untraceability can be ensured in the proposed user authentication phase.

4.3. Mutual Authentication

In the proposed scheme, any two of the authentication unit A_i, the control unit R_j, and the server S can authenticate each other. In the authentication phase, A_i generates N_A and sends it to R_j. After getting A_i’s authentication request, R_j generates N_R and sends N_R and N_A to S. After getting A_i’s authentication request forwarded by R_j, S generates N_S and sends N_S back to R_j. When N_S is received, R_j computes M₁ = H(N_A||N_R||N_S||$K_{{SR}_j}$) and sends M₁ to S. After S receives M₁, S uses RID_j as the index to get $K_{{SR}_j}$, the secret key shared between S and R_j, to compute H(N_A||N_R||N_S||$K_{{SR}_j}$). Then S checks whether the computation result is equal to the received M₁. If they are equal, R_j is authenticated by S successfully. Then S uses ${TID}_i^{new}$ and ${TID}_i^{old}$ as the index to find (AID_i, ${TID}_i^{new}$, ${TID}_i^{old}$,$K_{{SA}_i}$) in its database for the synchronous authentication and asynchronous authentication, respectively, where $K_{{SA}_i}$ is the secret key shared between S and A_i. S computes M₂ = H(RID_j||AID_i||N_A||N_R||N_S||$K_{{SA}_i}$) and M₃ = H(RID_j||M₁||$K_{{SR}_j}$) and sends {M₂, M₃} to R_j. When R_j receives {M₂, M₃}, R_j computes H(RID_j||M₁||$K_{{SR}_j}$) and checks whether the computation result is equal to the received M₃. If they are equal, S is authenticated by R_j successfully, and R_j sends {N_R, N_S, M₂} to A_i. When A_i receives {N_R, N_S, M₂}, A_i uses AID_i and $K_{{SA}_i}$ to compute H(RID_j||AID_i||N_A||N_R||N_S||$K_{{SA}_i}$) and checks whether the computation result is equal to the received M₂. If they are equal, S is successfully authenticated by A_i directly, and R_j is also authenticated by A_i successfully with the backend server’s help. A_i computes M₄ = H(AID_i||M₂||$K_{{SA}_i}$) and updates ${TID}_i^{new}$ and ${TID}_i^{old}$ stored in its memory. Then, A_i sends {M₄} to R_j, and R_j forwards {M₄} to S. When S receives {M₄}, it computes H(AID_i||M₂||$K_{{SA}_i}$) and checks whether the computation result is equal to the received M₄. If they are equal, A_i is authenticated by S successfully, and S computes M₅ = H(“Yes”||N_R||N_S||$K_{{SR}_j}$), sends {Yes, M₅} to R_j, and updates ${TID}_i^{new}$ and ${TID}_i^{old}$ stored in its database. When R_j receives the reply, R_j computes H(“Yes”||N_R||N_S||$K_{{SR}_j}$) and compares the computation result with the received M₅. If they are equal, it denotes that the response is indeed sent by S, and A_i is authenticated by R_j with the backend server’s help. Due to the above derivation, mutual authentication is ensured in the proposed user authentication scheme such that any two involved parties can authenticate each other.

4.4. Security

In order to provide essential security, the proposed scheme must resist common attacks. In the following, how the proposed scheme can defend against desynchronization attack, replay attack, impersonation attack, and offline secret key guessing attack will be shown in detail.

4.4.1. Resistance to Desynchronization Attack

When an attacker wants to mount the desynchronization attack in the proposed scheme, he/she modifies the transmitted parameters such that only ${TID}_i^{new}$ and ${TID}_i^{old}$ stored in the authentication unit A_i’s memory are updated while the backend sever S does not update ${TID}_i^{new}$ and ${TID}_i^{old}$ stored in its database. In such a case, ${TID}_i^{new}$ stored in the database of S and that stored in A_i’s memory are inconsistent, and ${TID}_i^{new}$ stored in the database of S is the same as ${TID}_i^{old}$ stored in A_i’s memory.

There are two authentication subphases to verify the legitimacy of the user in the proposed scheme. In synchronous authentication subphase, the authentication unit A_i sends {request, RID_j, ${TID}_i^{new}$, N_A} as the authentication request to the backend sever S via the control unit R_j, and ${TID}_i^{new}$ is generated in the last successful authentication iteration and is used in the present iteration to help the backend server identify A_i. In asynchronous authentication subphase, A_i sends {request, RID_j, ${TID}_i^{old}$, N_A} as the authentication request to S via R_j, and ${TID}_i^{old}$ is the temporary identification number of the last successful authentication iteration for identifying A_i and is also used in the present iteration to help S identify A_i. As a result, S can still identify A_i with ${TID}_i^{old}$ sent by A_i, even after the attacker mounts the desynchronization attack. It is ensured that the proposed user authentication scheme can defend against the desynchronization attack.

4.4.2. Resistance to Replay Attack

In the authentication phase, parameters N_A, N_R, and N_S are generated by A_i, R_j, and S, respectively. N_A, N_R, and N_S in one session are different from those in other sessions. Parameters M₁, M₂, M₃, M_4, and M₅ are transmitted and used to verify the legitimacy of other parties in the authentication phase. M₁, M₂, M₃, M_4, and M₅ are computed with these random numbers N_A, N_R, and N_S that are new and generated for the present session, where M₁ = H(N_A||N_R||N_S||$K_{{SR}_j}$), M₂ = H(RID_j||AID_i||N_A ||N_R||N_S||$K_{{SA}_i}$), M₃ = H(RID_j||M₁||$K_{{SR}_j}$), M₄ = H(AID_i||M₂||$K_{{SA}_i}$), and M₅ = H(“Yes”||N_R||N_S||$K_{{SR}_j}$). As a result, the correct M₁, M₂, M₃, M_4, and M₅ in the present session must differ from those in previous sessions. As a result, even if an attacker eavesdrops and resends the intercepted data, a replay attack cannot damage the proposed user authentication scheme.

4.4.3. Resistance to Impersonation Attack

As mentioned above, the proposed authentication ensures mutual authentication such that any two involved parties can authenticate each other. That is, if an attacker attempts to impersonate R_j, S, or A_i to cheat the other parties in the authentication phase, the other two parties will detect that. The details are as follows.

First, after S receives M₁, S computes H(N_A||N_R||N_S||$K_{{SR}_j}$) and checks whether the computation result is equal to the received M₁, where M₁ = H(N_A||N_R||N_S||$K_{{SR}_j}$) and $K_{{SR}_j}$ is the secret key shared between S and R_j. If they are equal, R_j is authenticated by S successfully. Because N_S is generated by S and only S and R_j know $K_{{SR}_j}$, only R_j can compute M₁ correctly to be authenticated by S successfully. That is, if an attacker wants to impersonate R_j, S will detect that.

Second, when R_j receives {M₂, M₃} sent from S, R_j computes H(RID_j||M₁||$K_{{SR}_j}$) and checks whether the computation result is equal to the received M₃, where M₃ = H(RID_j||M₁||$K_{{SR}_j}$) and $K_{{SR}_j}$ is the secret key shared between S and R_j. If they are equal, S is authenticated by R_j successfully. Because N_R is generated by R_j and only S and R_j know $K_{{SR}_j}$, only S can compute M₃ correctly to be authenticated by R_j successfully. That is, if an attacker wants to impersonate S, R_j will detect that.

Third, when A_i receives {N_R, N_S, M₂}, A_i uses AID_i and $K_{{SA}_i}$ to compute H(RID_j||AID_i||N_A||N_R||N_S||$K_{{SA}_i}$) and checks whether the computation result is equal to the received M₂, where M₂ = H(RID_j||AID_i||N_A||N_R||N_S||$K_{{SA}_i}$) and $K_{{SA}_i}$ is the secret key shared between S and A_i. If they are equal, S is successfully authenticated by A_i directly, and R_j is also authenticated by A_i successfully with the backend server’s help. Because N_A is generated by A_i, and only S and A_i know $K_{{SA}_i}$, only S can compute M₂ correctly to have both S and R_j authenticated by A_i successfully. That is, if an attacker wants to impersonate S or R_j to cheat A_i, A_i will detect that.

Fourth, when S receives {M₄}, it computes H(AID_i||M₂||$K_{{SA}_i}$) and checks whether the computation result is equal to the received M₄, where M₂ = H(RID_j||AID_i||N_A||N_R||N_S||$K_{{SA}_i}$) and M₄ = H(AID_i||M₂||$K_{{SA}_i}$). If they are equal, A_i is authenticated by S successfully. Because only S and A_i know $K_{{SA}_i}$ and M₂ is computed by S for authenticating A_i previously, only A_i can compute M₄ correctly to be authenticated by S successfully. That is, if an attacker wants to impersonate A_i to cheat S, S will detect that.

Fifth, when R_j receives the reply {Yes, M₅}, R_j computes H(“Yes”||N_R||N_S||$K_{{SR}_j}$) and compares the computation result with the received M₅, where M₅ = H(“Yes”||N_R||N_S||$K_{{SR}_j}$). Because N_R is generated by R_j, and only S and R_j know $K_{{SR}_j}$, only S can compute M₅ correctly to have both S and A_i authenticated by R_j successfully. That is, if an attacker wants to impersonate S or A_i to cheat R_j, R_j will detect that.

4.4.4. Resistance to Offline Secret Key Guessing Attack

In the authentication phase, parameters RID_j, N_A, N_R, N_S, M₁, M₂, M₃, M₄, and M₅ are transmitted via the public channel, where M₁ = H(N_A||N_R||N_S||$K_{{SR}_j}$), M₂ = H(RID_j||AID_i||N_A ||N_R||N_S||$K_{{SA}_i}$), M₃ = H(RID_j||M₁||$K_{{SR}_j}$), M₄ =H(AID_i ||M₂||$K_{{SA}_i}$), and M₅ = H(“Yes”||N_R||N_S||$K_{{SR}_j}$). When an attacker tries to retrieve $K_{{SA}_i}$ or $K_{{SR}_j}$, he/she can eavesdrop and analyze these intercepted data offline. Unfortunately, because of the properties of one-way hash functions, it is hard for the attacker to retrieve the unknown parameters, $K_{{SA}_i}$, $K_{{SR}_j}$, and AID_i. As a result, the proposed user authentication scheme can defend against an offline secret key guessing attack.

5. Further Discussions

In the proposed user authentication scheme, a variety of tools or devices, such as smart cards, RFID tags, and mobile devices, can be utilized for the authentication unit. These tools or devices possess different computational capabilities. For different requirements, there exist two modes to generate random numbers N_A, N_R, and N_S for authentication in the proposed authentication scheme. In Mode 1, N_A, N_R, and N_S are randomly generated in each authentication iteration. In Mode 2, A_i, R_j, and S randomly choose r_A, r_R, and r_S in Z_p and compute N_A = $g^{r_A}$ mod p, N_R = $g^{r_R}$ mod p, and N_S = $g^{r_S}$ mod p, respectively. When a session key needs to be negotiated to protect the following communication, Mode 2 can be adopted to realize Diffie–Hellman key exchange. That is, the proposed scheme can be implemented elastically even when different security levels need to be achieved or different requirements need to be satisfied. As a result, the proposed scheme ensures convenience.

Furthermore, the one-way hash functions provide fast computation with low time complexity, typically O(n). This makes them ideal for efficient data verification, authentication, and integrity checks, especially in resource-constrained or real-time systems requiring quick and secure processing.

Table 2. The average computation times for various hash functions.

Input (bits)	SHA-256 (μs)	SHA-512 (μs)	SHA3-256 (μs)	SHA3-512 (μs)
1024	1.33	1.61	1.35	1.38
2048	1.51	1.62	1.37	1.96
4096	1.86	1.98	2.24	3.54
5120	2.10	1.90	2.67	4.23

lists the average computation times (in microseconds) for SHA-256, SHA-512, SHA3-256, and SHA3-512 using Python 3.10, with input data lengths of 1024, 2048, 4096, and 5120 bits. Each hash was computed 1000 times per input size using random data. Experimental data may vary slightly depending on the hardware, but overall, these hash algorithms can complete computation within a few microseconds for small amounts of data, demonstrating their computational efficiency. On the other hand, only the one-way hash function is executed in the authentication phase, so computational efficiency can be ensured in the proposed user authentication scheme as well.

6. Conclusions

In this paper, we propose a user authentication scheme that ensures personal privacy. The scheme involves a backend server, multiple authentication units, and multiple control units. Each user is issued or equipped with an authentication unit. An authorized user can be authenticated by a control unit with assistance from the backend server without revealing their identity to the control unit. We demonstrate that the proposed scheme achieves anonymity, untraceability, mutual authentication, usability, and computational efficiency through detailed analysis. Additionally, we show its resilience against common attacks, thereby ensuring both security and privacy. This makes the scheme suitable for real-world applications requiring these properties.