A Lightweight and Secure Authentication Protocol for Mobile Radio Frequency Identification Systems Using Quadratic Residue Theory

Abstract

Radio frequency identification (RFID) systems are increasingly used in applications such as supply-chain tracking, mobile commerce, pervasive computing, and smart healthcare. However, the highly constrained nature of RFID systems in dynamic and insecure environments creates significant challenges for designing authentication mechanisms that are both secure and efficient. In addition, Mobile RFID environments face strict constraints on energy, computation, and storage, making traditional security mechanisms unsuitable. To address these limitations, this work introduces a lightweight and secure authentication protocol tailored specifically for mobile RFID systems. The protocol leverages minimal cryptographic primitives, optimized message flows, and dynamic session parameters to reduce computational load, communication overhead, and energy consumption. At the same time, it ensures strong server-mediated authentication between mobile readers and RFID tags—with the back-end server acting as a trusted third party—and supports key-updating mechanisms that protect long-term privacy. The design mitigates a wide range of threats, including desynchronization attacks, replay attacks, and tag impersonation, while maintaining compatibility with the low-power hardware commonly found in RFID tags. The security validation of the proposed RFID authentication protocol was performed through both informal and formal analysis to provide comprehensive assurance of its resilience against potential attacks. Informal security analysis demonstrates that the proposed protocol achieves robust resistance to known attacks, preserves tag anonymity, and provides forward security—all without relying on heavy cryptographic operations. In order to validate these security properties, formal verification was conducted using Scyther and ProVerif, two widely recognized automated security verification tools. Performance evaluation further shows that the protocol outperforms existing schemes in terms of execution time, memory usage, and communication cost, making it a practical solution for real-world mobile RFID deployments.

1. Introduction

Radio frequency identification (RFID) has quietly become one of the most influential technologies shaping how the physical world is tracked, managed, and understood. RFID systems [1] represent a mature yet continuously evolving class of electromagnetic identification technologies designed to automatically extract digital information from remotely interrogated tags. At the system level, RFID integrates radio-frequency transceivers, tag-integrated circuits, and data management middle-ware to establish a bidirectional communication link. Modern RFID deployments increasingly benefit from improvements in tag antenna efficiency, ultra-low-power chip architectures, and robust medium access control protocols, allowing large-scale, high-throughput identification in dynamic environments.

The operational characteristics of RFID systems include spectral allocation, modulation techniques, anti-collision protocols, and interference resilience. These allow them to be adapted to highly heterogeneous environments and application domains such as supply chain/logistics [2], healthcare/medical asset tracking [3], industrial automation/manufacturing, security and access control, smart agriculture, IoT and wireless sensor networks, transportation systems, device tracking [4], and libraries and information management. For example, in supply chain and logistics systems, RFID supports continuous and high-throughput traceability by enabling real time identification throughout warehousing, transportation, and distribution processes, which enhances inventory synchronization and mitigates the inaccuracies inherent in manual data entry. Within healthcare environments, RFID offers dependable tracking of medical equipment, pharmaceuticals, and patient-related materials. Through integration with clinical information platforms, RFID-generated events improve asset availability, regulatory compliance, and patient safety. In security and access control systems, RFID tags operate as cryptographically protected credentials that facilitate controlled entry, tamper resistance, and detailed auditability when coupled with identity management frameworks. Within the realm of the Internet of Things (IoT) and wireless sensor networks, RFID functions as a lightweight, energy-efficient mechanism for identification and event sensing, enabling dense, distributed environments to maintain context awareness without imposing significant communication overhead. Transportation systems employ RFID for electronic tolling and vehicle identification, where long-range interrogation and high-speed performance are essential for maintaining throughput and operational safety. Meanwhile, libraries and information management systems use RFID for rapid inventory scanning, automated circulation, and enhanced loss prevention. A typical RFID system architecture is depicted in Figure 1.

Figure 1. General RFID System Architecture.

Across these diverse domains, RFID serves not only as an identification mechanism but also as a foundational layer in broader cyber-physical and data-driven infrastructures. However, RFID systems introduce a range of security and privacy challenges that stem from their wireless, broadcast-based communication model and the computational capabilities of tags. Because RFID transmissions can be intercepted or spoofed by unauthorized readers, threats such as eavesdropping, cloning, and replay attacks undermine the authenticity and integrity of tag data [5]. In general, tags are vulnerable due to limited resources that restrict their ability to support strong cryptographic operations and mutual authentication protocols. Privacy concerns also arise from the possibility of covert tracking, where adversaries exploit persistent tag identifiers to infer user behavior and location patterns. Addressing these issues requires a combination of lightweight cryptographic schemes, secure reader–tag protocols, and privacy-preserving tag designs that balance security requirements with the economic and operational constraints of large-scale RFID deployments.

Authentication mechanisms in mobile RFID systems are generally divided into three classes [6]: heavy-weight, light-weight, and ultra-lightweight protocols. Heavy-weight schemes employ computationally intensive cryptographic algorithms that require considerable processing capability and substantial memory on the participating devices. Light-weight protocols, by contrast, make use of more modest cryptographic primitives—such as hash functions, cyclic redundancy checks (CRC), pseudo-random number generators (PRNG), and simple XOR operations—to reduce computational load. Ultra-lightweight protocols further minimize complexity by restricting tag-side operations to basic bitwise manipulations, including logical functions like AND and XOR, as well as simple bit substitutions, shifts, and related operations.

In this paper, we propose a lightweight and secure authentication scheme for RFIDs to secure the communication between their entities. The proposed scheme uses quadratic residue theory [7] to authenticate entities and update shared secrets between the tag, reader, and server. Using hash-indexed lookup tables on the server and lightweight primitives (PRNG, Eac, hash) on the tag, the proposed scheme achieves strong mutual authentication with minimal tag-side resource consumption. It effectively resists a variety of well-known attacks, including replay, impersonation, desynchronization, tag tracking, and eavesdropping attacks. Compared to other mechanisms, the proposed scheme offers improved performance in terms of tag-side storage, tag-side communication, and overall computational distribution between entities.

The main contributions of this work are summarized as follows:

• We design a server-mediated authentication protocol in which a trusted server (a trusted third party, TTP) authenticates the reader and the tag, so that mutual trust between reader and tag is established transitively; the quadratic residue construction is confined to the reader–server link, so that the tag’s secret is never subjected to modular operations and can be as short as 96 bits. The target platform is stated explicitly—passive, crypto-enabled EPC Gen2v2 class tags—and a dedicated hardware feasibility analysis (Section 7.4) justifies every tag-side primitive on this platform, including the energy-delivery timing of the air interface.
• We introduce a dual-entry, hash-indexed server table design that yields constant-time expected lookup together with a provable one-update-behind desynchronization recovery guarantee (Lemma 1). The design is paired with an explicit adversary model covering physical capture of mobile readers (Section 2.1) and a constant-time reader revocation procedure (Section 5.4).
• We validate security through reduction-based arguments in the random-oracle/PRF model (Section 6.2) and through automated verification with Scyther and ProVerif; we additionally provide a Tamarin model that treats the exclusive-OR operation natively (Section 6.5), which is accepted with no well-formedness violations, with a fully terminating mechanized XOR proof left as future work. Tag unlinkability is additionally proven in the Juels–Weis privacy model, together with an explicit characterization of the bounded residual tracking window that arises under sustained active blocking of key updates (Section 6.6).
• We evaluate performance under a uniform channel-traffic convention, extended in this work with cycle-normalized computational costs, air-interface framing overheads, and firmware footprint accounting. The proposed scheme achieves the lowest tag-side storage (192 bits) and reader-side storage (352 bits) among representative recent schemes and tag-side communication matching the best prior result (288 bits).

We emphasize that the novelty of this work is architectural rather than a new primitive. Prior quadratic residue RFID schemes achieve their security by placing the heavy modular structure on the tag: Fan et al. [8], Zhou et al. [9], and SecMAP [10] each require the tag to store a 1024-bit modulus and/or perform local modular squaring, and Xu et al. [11] require a 1024-bit tag-side key. The contribution here is to show that the quadratic residue mechanism can be relocated entirely to the reader–server link while preserving its security role, so that the tag is reduced to XOR, a keyed PRNG, a single hash, and a fixed bit-permutation. This relocation is what simultaneously yields 96-bit tag secrets, 192-bit tag storage (a $5\times$–$10\times$ reduction over the compared schemes), constant-time server lookup, and provable one-update-behind desynchronization recovery (Lemma 1)—a combination that, to our knowledge, no prior scheme attains. The quantitative separation is not incremental: the compared quadratic residue schemes sit roughly two orders of magnitude above ours in normalized tag-side cost.

The remainder of this article is organized as follows. Security and privacy for RFID are discussed in Section 2. Section 3 provides an overview of the state of the art on the security and privacy in RFID systems. Section 4 summarizes needed mathematical preliminaries. In Section 5, the proposed authentication model is presented. The security analysis of the proposed scheme is addressed in Section 6. The performance analysis of the proposed scheme is addressed in Section 7. Finally, conclusions are drawn in Section 8.

2. RFID Security and Privacy

Establishing secure authentication between communicating parties in RFID systems is essential, since authentication protocols ensure that only legitimate tags are granted access and that both the tag and the reader can verify each other’s identity [12]. The design of these protocols is complicated by the constrained processing capabilities and minimal memory available on most RFID tags, which limit the use of traditional cryptographic techniques. Therefore, the wireless and openly accessible communication medium, combined with the limited processing and memory capabilities of RFID tags, exposes these systems to a wide range of security and privacy threats. Adversaries can perform eavesdropping attacks to capture transmitted data and extract sensitive information or launch replay attacks by reusing previously intercepted messages to gain unauthorized access. Impersonation attacks allow malicious entities to masquerade as legitimate tags or readers, while man-in-the-middle attacks enable attackers to alter or inject messages during communication. In addition, tag tracking and location tracing attacks threaten user privacy by correlating tag responses across multiple sessions, revealing movement patterns or personal information. Desynchronization attacks can disrupt shared secrets between tags and back-end servers, causing authentication failures, whereas denial-of-service attacks aim to exhaust system resources or block legitimate interactions. Furthermore, cloning attacks replicate tag identifiers to create counterfeit tags, undermining system trust. These diverse threats highlight the necessity of robust yet lightweight security solutions that provide mutual authentication, confidentiality, integrity, and privacy protection.

2.1. Adversary Model

We now make the adversary model underlying the remainder of this paper explicit. The adversary $\mathcal{A}$ is granted the following capabilities:

• Full channel control (Dolev–Yao): $\mathcal{A}$ can eavesdrop on, intercept, modify, inject, reorder, delay, and block any message on both the tag–reader air interface and the reader–server link. All cryptographic primitives are assumed ideal: $\mathcal{A}$ can apply any public function to known values but cannot invert one-way functions or predict PRNG outputs without the corresponding key.
• Physical capture of mobile readers: Because the readers in our system model are mobile handheld devices, $\mathcal{A}$ may steal or otherwise physically capture a reader and extract its full stored state, namely, the tuple $\{SRID,r,h(s\left)\right\}$. Note that the reader stores only the hash of the server master secret s; the secret itself never leaves the server.
• Physical capture of tags: $\mathcal{A}$ may attempt to physically capture tags; however, consistent with the deployment assumption stated in Section 5, tags are tamper-resistant, and any attempt at physical extraction renders the tag unreadable and unusable.

The security goals evaluated against this adversary are (i) mutual authentication among tag, reader, and server; (ii) secrecy of all long-term secrets $(t,r,s,STID,SRID)$; (iii) tag unlinkability; (iv) forward secrecy; and (v) graceful recovery from desynchronization induced by $\mathcal{A}$’s blocking of update messages. The consequences of reader capture, and the corresponding revocation procedure, are analyzed in Section 6.1.12 and Section 5.4, respectively.

3. Related Work

In the following, a literature review for the most appropriate existing studies being carried out is presented.

In 2015, Li et al. [13] identified a critical security weakness in the protocol developed by Srivastava et al. [14]. They showed that an attacker can gain unauthorized access to a back-end server by exploiting a stolen or lost reader, which can lead to disclosure of sensitive medical data. To overcome these limitations, Li et al. designed a secure and efficient RFID authentication protocol that is designed to address the vulnerabilities and to improve the performance of the system.

In 2017, Ma et al. [15] presented an ultra-lightweight authentication protocol that used word synthesis operations for data protection. The scheme achieves notable reductions in both communication overhead and computational effort. Moreover, in 2017, Tan et al. [16] introduced an elliptic curve cryptography processor that is engineered for passive ultra-high-frequency RFID tags. This new proposed processor targets anti-counterfeiting and banknote verification applications in order to offer optimized area, performance, and energy efficiency.

In 2018, Fan et al. [17] designed a lightweight RFID protocol for medical applications that focuses on preserving privacy and data confidentiality by employing an effective authentication mechanism. In 2018, Liu et al. [18] developed a bidirectional authentication scheme for RFID systems. Their model is designed to minimize storage and computational overhead. In addition, the proposed scheme divides the output of the hash function generated by the tag into two segments. One segment is assigned to reader validation and the other to tag verification. Finally, they used BAN logic to verify the security correctness and validation of the proposed model. In 2018, Zhu et al. [19] proposed a new improved RFID model by employing Chebyshev chaotic maps $\left(CCM\right)$. They used Chebyshev chaotic maps to address many limitations discovered in Akgun’s scheme [20]. Therefore, Zhu et al. proved that Akgun’s protocol is vulnerable to impersonation, desynchronization, and to secret leakage attacks.

In 2019, Fan et al. [8] developed a lightweight RFID authentication scheme for healthcare systems by using both quadratic residue methods and pseudo-random number generators in order to improve the overall security of the entities. Authors claimed that the proposed solution maintains data confidentiality and resists against different main threats available in wireless mobile environments. Moreover, in 2019, Zhou et al. [9] designed an authentication framework for TMIS platforms that provides both security and efficiency. The proposed method is developed by using quadratic residue principles. Furthermore, data confidentiality is ensured by combining both quadratic residue computations and cryptographic hash operations. By using reader-generated timestamps, authors claimed that the proposed protocol is secure against replay attacks. In addition, in 2019, Huang et al. [21] proposed an ultra-lightweight authentication scheme for wireless mobile systems. Authors proved that the scheme minimizes computational overhead by using bit-permutation technique.

In 2020, Zhu [10] studied the scheme presented by Safkhani et al. and found out two weaknesses that are related to system scalability and to forward secrecy. To resolve these shortcomings, Zhu developed a secure and efficient mutual authentication scheme, referred to as SecMAP. In 2020, Zhu et al. [22] provided a study over the scheme developed by Fan et al. [8] and uncovered many security limitations. Therefore, authors presented a new secure and efficient lightweight authentication mechanism to mitigate the risks that were found.

In 2021, Xu et al. [23] presented a protocol called Au-Hota. According to Xu et al., this framework prevents impersonating and replay attacks—two limitations commonly found in physical-layer solutions. The authors also declared that this framework performs with current ultra-high-frequency $\left(UHF\right)$ RFID infrastructures without the need for any system alterations. In 2021, Yang et al. [24] proposed an efficient group-based authentication mechanism where many tags are authenticated all at once by using a single challenge–response exchange. Moreover, the protocol incorporates privacy protection features to prevent illicit tracking of tagged objects. In 2021, Sharma et al. [25] presented an efficient and secure mutual authentication protocol for RFID systems that can be applied for Internet of Vehicles $\left(IoV\right)$ environments. The proposed model uses elliptic curve cryptography. In addition, they introduced a blockchain-driven framework to better improve the security requirements of $IoV$ networks.

In 2023, Wang et al. [26] presented a comprehensive study of the RFID authentication protocols that were proposed by Li [13] and Fan [17]. This study revealed that Li’s scheme is susceptible to desynchronization attack, impersonation attack, and replay attack. Moreover, they proved that Fan’s scheme suffers from impersonation vulnerabilities and poses a threat to location privacy. To resolve these limitations, Wang et al. presented a new authentication protocol that is designed for mobile RFID environments. The correctness of the security of their scheme was conducted by using BAN logic and the Scyther verification tools. It shows that the protocol meets the required security threshold. In 2023, Xu et al. [11] revised the scheme developed in [15] and proved that the RFID tag cannot be verified by the RFID reader, and so, mutual authentication is not achieved. In addition, authors [11] revised the mechanism in [21]. They showed that during the identification phase, the information of the tag is transmitted in plaintext, which enables a clear tag-tracking attack. To resolve these limitations, Xu et al. [11] introduced an efficient and secure mobile RFID authentication protocol that provides secure verification between participating entities. The proposed design minimizes computational overhead on tags and enhances mobile data security by using hash-based operations for the communications between the reader and the cloud and exchange–cross bitwise operations between the cloud server and the tag. In addition, authors used an index data table at the server to improve data protection and to prevent exposure of data.

In 2024, Shimizu et al. [27] presented a light and resilient authentication approach for RFID environments based on the SAS-L2 framework. The method is specifically designed to impose minimal computational demands, making it well suited for low-cost passive tags. Furthermore, in 2024, Xiao et al. [28] introduced a novel authentication protocol that incorporates pseudo-random number generation together with vector dot product operations. This strategy is applied to strengthen the overall security of the scheme. In 2025, Alhasan et al. [29] proposed an ultra-lightweight mutual authentication scheme that combines rotation operations, T-functions, and timestamp mechanisms. The authors conducted formal security validation using the Scyther and AVISPA tools, and the results demonstrate that the protocol is resilient against a wide range of attacks, including replay-based attacks.

Despite this substantial body of work, a clear gap remains. To the best of our knowledge, no existing scheme simultaneously achieves (i) constant-time server-side lookup, (ii) tag-side persistent storage below 200 bits, (iii) graceful recovery from desynchronization, and (iv) the complete absence of modular arithmetic on the tag. The schemes closest to ours in cryptographic foundation violate at least one of these properties: Fan et al. [8] require the tag secret to be at least 1024 bits because its modular square is stored on the server; Zhou et al. [9] and SecMAP [10] require the tag to hold the 1024-bit modulus n and to perform modular squaring locally; and Xu et al. [11] employ a 1024-bit tag-side secret key. These four properties are not arbitrary: each addresses a concrete deployment constraint. Constant-time server-side lookup is required for the back-end to scale to millions of tags and to resist lookup-amplification denial of service; tag-side storage below 200 bits matters because non-volatile memory is the dominant silicon-area and unit-cost driver for passive tags produced at scale; graceful desynchronization recovery is a functional necessity because over-the-air update messages are routinely lost, and without recovery, a single lost message permanently disables the tag; and the complete absence of modular arithmetic on the tag is what keeps the tag within the gate and energy budget of passive hardware, since modular squaring is the single most expensive operation on tag-class silicon. A scheme missing any one of these fails in practice on cost, scalability, reliability, or feasibility grounds. The protocol proposed in this paper is designed to close this gap by confining all modular arithmetic to the reader–server link, which allows the tag to operate with 96-bit secrets, 192 bits of persistent storage, and no modular operations, while the dual-entry, hash-indexed server tables retain constant-time expected lookup and provable desynchronization recovery.

4. Mathematical Preliminaries

In this section, we summarize the necessary mathematical preliminaries including quadratic residues, pseudo-random number generator, and exchange-cross operation.

4.1. Quadratic Residue Theorem

Quadratic residues [7] play a key role in public key cryptosystems, such as the $Goldwasser-Micali$ encryption scheme, and in $zero-knowledge$ proofs. Given two large prime numbers p and q, and their product $n=pq$, an element $y\in {\mathbb{Z}}_n$ is considered a quadratic residue if there exists an integer x such that $y\equiv x^2\left(\mathrm{mod}n\right)$. In other words, y has a square root modulo n. If no such x exists, then y is called a quadratic non-residue modulo n. Due to the computational difficulty of factoring n, it is infeasible to determine such an x without knowing the factors p and q.

The steps to solve the congruence $y\equiv x^2\left(\mathrm{mod}n\right)$ are as follows:

• Factorize n as p.q
• Solve the congruence $y\equiv x^2\left(\mathrm{mod}p\right)$.
• Solve the congruence $y\equiv x^2\left(\mathrm{mod}q\right)$.
• Combine solutions using Chinese remainder theorem.
• Obtain all $x_i$.

4.2. PRNG()

The proposed protocol uses a pseudo-random number generator $\left(PRNG\right)$, which is a mathematical model used to generate random numbers by applying mathematical formulas. These generators are widely utilized in various fields, including simulations, video games, and cryptography. Two distinct notions must not be conflated. The 16-bit random number generator mandated by the EPC Gen2 air-interface specification [30] is a source of statistical randomness for anti-collision and air-interface purposes; it is not a keyed cryptographic primitive. In contrast, the function $PRNG(·)$ used in the proposed protocol is a cryptographic pseudo-random function: whenever it is evaluated at a point containing a long-term secret k, the security analysis models $PRNG(k\oplus x)$ as a pseudo-random function $F_k\left(x\right)$ (Section 6.2). On constrained tags, $PRNG(·)$ is instantiated on the same lightweight cryptographic engine as the hash function $h(·)$—for example, the hash in feedback mode, or an AES-based construction on the AES engine of Gen2v2 crypto tags (Section 7.4)—so it requires no additional hardware core, while the mandated 16-bit generator serves only nonce generation on the reader side and air-interface randomness. Its per-invocation cost is accordingly accounted at hash-class cost in the normalized performance analysis.

4.3. Eac(X, Y)

$Eac(X,Y)$ is an exchange-cross operation described for reducing computation on RFID tags while maintaining privacy and security. It leverages per-bit operations, offering a more efficient approach than traditional hash functions or modulo-square operations, particularly for tasks like authentication and data security in mobile RFID systems. A sequence Z is constructed by combining the latter half of X and the first half of Y, where X, Y are two binary sequences with the same number of bits. Finally, $Eac(X,Y)$ is calculated by performing a cross-exchange operation on the sequence Z.

5. Proposed Authentication Scheme

The proposed system model consists of three main entities: Server $\left(RS\right)$, RFID Reader $\left(RR\right)$, and RFID Tag $\left(RT\right)$. The system architecture for our RFID scheme is shown in Figure 2. Figure 2 represents an RFID network with many tags, $\{R{T}^1,\dots ,R{T}^i\}$, and few readers, $\{R{R}^1,\dots ,R{R}^j\}$, connected to an RFID server. This network is designed to efficiently track and manage large numbers of items or assets. A smaller number of strategically placed RFID readers scan these tags within their range, capturing data such as the tag ID, timestamp, and other information. These readers are connected to an RFID server, which acts as the central processing and management hub. The server collects and stores data from all readers, processes it, and authenticates the readers and the tags accordingly. The proposed mutual authentication scheme is cost-effective as it aims to minimize the computation, communications, and storage overhead. Moreover, it is scalable, leveraging a limited number of readers to monitor a large volume of tags across a facility or supply chain. The notation used by our proposed scheme is summarized in Table 1. The proposed scheme assumes the following:

Figure 2. Multi-Reader RFID System Design.

Table 1. List of Notation.

Symbols	Definition
$SSID$	Identity of the server
$SRI{D}^j$	Identity of the jth RFID reader
$STI{D}^i$	Identity of the ith RFID tag
⊕	Bitwise XOR operation
$p,q$	Two large prime numbers with $n=pq$
$PRNG\left(\right)$	Pseudo-random number generator
$Eac\left(\right)$	Exchange-cross operation
$h(.)$	One-way hash function
$\left|\right|$	Concatenation operation
$R_N$	Random number generated by RFID reader
T	Time stamp
$\Delta T$	Expected time interval for transmission delay

• It can be used for many-to-many tag-to-reader models where a single tag can be associated with multiple readers, and a single reader can interact with multiple tags. Because the reader and the tag deliberately share no pairwise secret, authentication between them is server-mediated: the server authenticates the reader and the tag, and each of them authenticates the server, so that mutual trust between tag and reader is established transitively through the mutually authenticated server. This is the standard notion of mutual authentication in three-party mobile RFID models [8,10,11]; pre-distributing pairwise reader–tag secrets would defeat scalability in a many-to-many deployment and would multiply the exposure created by the loss of a single mobile reader (Section 2.1).
• The RFID server $\left(RS\right)$ is secure and has no limitations in terms of storage and computation.
• The RFID Tags $\left(RT\right)$ have limited resources (i.e., energy, computation, memory).
• The RFID Tags are passive, crypto-enabled EPC Gen2v2 class devices: in addition to the bitwise operations and the 16-bit PRNG mandated by the EPC Gen2 air-interface specification [30], they provide a lightweight cryptographic engine on which the one-way hash function can be instantiated. The hardware feasibility of every tag-side primitive on this platform, including the energy-delivery timing of the air interface, is analyzed in Section 7.4.
• The RFID readers $\left(RR\right)$ have higher resources (i.e., energy, computation, memory) compared to RFID tags but fewer resources compared to $RS$.
• The RFID tags are designed to be tamper-resistant. Any damage, altering, or tampering prevents them from being read or used again.

This scheme consists of two main phases, namely, the system requirements and entities deployment phase (also known as the initial phase), and the mutual authentication phase. During the initial phase, the system administrator sets required values for each party. Mutual authentication is achieved once the second phase is executed. These two phases are described in the following subsections. Figure 3 shows the steps of the proposed scheme.

Figure 3. Proposed Model.

5.1. Phase 1: System Requirements and Entities Deployment

Setting up a server involves several key steps. Therefore, the system administrator executes the following:

Setting Up The Server:

• The system administrator selects a pseudo identifier $SSID$ and a secret key s. Next, $SSID$ and s are stored on the server.
• The system administrator generates two large prime numbers p and q and calculates $n=pq$.
• The system administrator sets the pseudo-random number generator function, the exchange-cross operation, and the one-way hash function.
• To prevent desynchronization attacks, the server stores all related data secrets in two index data tables, Table 2 and Table 3.

Table 2. Server Index Data Table For Tags.

	Old Data Fields			Current Data Fields
	Old ID	Old Key1	Hash of Old ID	New ID	New Key1	Hash of New ID
$R{T}^1$	$STI{D}_{Old}^1$	$t_{Old}^1$	$h(STI{D}_{Old}^1\oplus t_{Old}^1)$	$STI{D}^1$	$t^1$	$h(STI{D}^1\oplus t^1)$
$R{T}^2$	$STI{D}_{Old}^2$	$t_{Old}^2$	$h(STI{D}_{Old}^2\oplus t_{Old}^2)$	$STI{D}^2$	$t^2$	$h(STI{D}^2\oplus t^2)$
⋮	⋮	⋮	⋮	⋮	⋮	⋮
$R{T}^i$	$STI{D}_{Old}^i$	$t_{Old}^i$	$h(STI{D}_{Old}^i\oplus t_{Old}^i)$	$STI{D}^i$	$t^i$	$h(STI{D}^i\oplus t^i)$

Table 3. Server’s Index Data Table For Readers.

	Old Data Fields				Current Data Fields
	Old ID	Old Key1	Old Key2	Hash of Old ID	New ID	New Key1	New Key2	Hash of New ID
$R{R}^1$	$SRI{D}_{Old}^1$	$r_{Old}^1$	$h\left(s_{Old}^1\right)$	$h(SRI{D}_{Old}^1\oplus r_{Old}^1)$	$SRI{D}^1$	$r^1$	$h\left(s^1\right)$	$h(SRI{D}^1\oplus r^1)$
$R{R}^2$	$SRI{D}_{Old}^2$	$r_{Old}^2$	$h\left(s_{Old}^2\right)$	$h(SRI{D}_{Old}^2\oplus r_{Old}^2)$	$SRI{D}^2$	$r^2$	$h\left(s^2\right)$	$h(SRI{D}^2\oplus r^2)$
⋮	⋮	⋮	⋮	⋮	⋮	⋮	⋮	⋮
$R{R}^j$	$SRI{D}_{Old}^j$	$r_{Old}^j$	$h\left(s_{Old}^j\right)$	$h(SRI{D}_{Old}^j\oplus r_{Old}^j)$	$SRI{D}^j$	$r^j$	$h\left(s^j\right)$	$h(SRI{D}^j\oplus r^j)$

Deployment of RFID Reader:

• For each legitimate RFID reader, the system administrator selects a pseudo identifier $SRID$ and a secret key r.
• The pseudo identifier $SRID$ and secret key r of each RFID reader are stored in the server in the corresponding index table for RFID readers.
• To prevent desynchronization attacks, the server stores the previous index $SRI{D}_{old}$ and the previous secret key $r_{old}$ of the tag in the corresponding index table. Initially, $SRI{D}_{old}$ and secret key $r_{old}$ are set to 0. The index table for RFID readers on server is shown in Table 3.
• The system administrator computes $h\left(s\right)$.
• The RFID reader is deployed by storing $<SRID,r,h\left(s\right)>$ in its storage. The data memory table for an RFID reader is shown in Table 4.
• Finally, the deployment of the RFID reader is presented in Figure 4.

Table 4. Reader’s Memory Table.

	ID	Key1	Key2
$R{R}^m$	$SRID$	$r^m$	$h\left(s^m\right)$

Figure 4. Deployment of RFID Reader.

Deployment of The RFID Tag:

• For each RFID tag, the system administrator selects a pseudo identifier $STID$ and a secret key t.
• The pseudo identifier $STID$ and secret key t of each RFID tag are stored in the server in the corresponding index data table for RFID tags.
• To prevent desynchronization attacks, the server stores the previous index $STI{D}_{old}$ and the previous secret key $t_{old}$ of the RFID tag in the corresponding index table. Initially, $STI{D}_{old}$ and secret key $t_{old}$ are set to 0. The index table for RFID tags on server is depicted in Table 2.
• The RFID Tag is deployed by storing $<STID,t>$ in its storage. The data memory table for an RFID tag is shown in Table 5.
• Finally, Figure 5 illustrates the deployment of the RFID tag.

Table 5. Tag Memory Table.

	ID	Key1
$R{T}^n$	$STI{D}^n$	$t^n$

Figure 5. Deployment of RFID Tag.

5.2. Phase 2: Mutual Authentication Process

The authentication process using an RFID tag begins when the tag is within the range of an RFID reader. The reader emits a radio frequency signal, which activates the tag, causing it to start replying. The proposed authentication protocol flow is shown in Figure 6. The steps are as follows:

Figure 6. Authentication Phase of Proposed Model.

• Step 1: The RFID reader generates $R_{N_1}$ and extracts the current time $T_1^R$
• Step 2: The RFID reader sends $R_{N_1}$ and $T_1^R$ to the RFID tag.
• Step 3: The RFID tag computes $M_1^T=Eac(T_1^R\oplus R_{N_1},R_{N_1})$, computes $M_2^T=PRNG(M_1^T\oplus R_{N_1})$, and computes $M_3^T=PRNG(t\oplus R_{N_1})$. Finally, the RFID tag computes $M_4^T=h(STID\oplus t)\oplus R_{N_1}\oplus M_2^T$. Note that since $M_1^T$ and $M_2^T$ depend only on the public values received in Step 2, the tag can compute them during its power-up interval, before its response slot, which removes them from the timing-critical path (see Section 7.4).
• Step 4: The RFID tag sends $M_3^T$ and $M_4^T$ to the RFID reader.
• Step 5: The RFID reader extracts the current time $T_2^R$ and verifies whether $|T_2^R-T_1^R|\stackrel{?}{<}\Delta T$. If it is not true, the reader aborts the protocol. Otherwise, it computes $h\left(r\right)$ and computes $x_R=h(SRID\oplus r)\oplus R_{N_1}$. Next, the reader computes $M_1^R=h\left(\right(x_R\left|\right|R_{N_1})\oplus h\left(x_R\right))$ and computes $M_2^R=PRNG(r\oplus T_1^R\oplus h\left(s\right))$. Finally, the RFID reader computes $X_R=x_R^{2}modn$.
• Step 6: The RFID reader sends $M_1^R$, $M_2^R$, $M_3^T$, $T_1^R$, $T_2^R$, $X_R$, $R_{N_1}$, and $M_4^T$ to the server.
• Step 7: The server extracts the current time $T_1^S$ and verifies whether $|T_1^S-T_2^R|\stackrel{?}{<}\Delta T$. If it is not true, the server aborts the protocol. Otherwise, the server solves $X_R$ to find $\{x_{R_1},x_{R_2},x_{R_3},x_{R_4}\}$. Next, and for each $x_{R_i}$, the server computes $M_1^{R^{\prime }}=h\left(\right(x_{R_i}\left|\right|R_{N_1})\oplus h\left(x_{R_i}\right))$ and checks if $M_1^{R^{\prime }}\stackrel{?}{=}{M}_1^R$. If there are no matches, the server aborts the protocol. Otherwise, the server selects the corresponding $x_{Ri}$ and computes $h(SRID\oplus r)=x_{R_i}\oplus R_{N_1}$. Next, the server searches its index table, Table 3, for $h(SRID\oplus r)$ using the current data fields section. If it fails, it attempts the search with the old data fields section. If $h(SRID\oplus r)$ is not found, the server aborts the protocol. Otherwise, the server extracts the corresponding r and $h\left(s\right)$ and computes $M_2^{R^{\prime }}=PRNG(r\oplus T_1^R\oplus h\left(s\right))$. Next, the server verifies whether $M_2^{R^{\prime }}\stackrel{?}{=}{M}_2^R$. If it is not true, the server aborts the protocol. Otherwise, the server authenticates the RFID reader. Note that with knowledge of the factorization $n=p·q$, solving $X_R$ reduces via the Chinese remainder theorem to two modular exponentiations (one modulo p and one modulo q), and the root disambiguation above costs at most four pairs of hash evaluations; the total cost of this stage is therefore bounded by $1T_{qr}+8T_h$ per request (see Section 7.1).
  Next, the server computes $M_1^T=Eac(T_1^R\oplus R_{N_1},R_{N_1})$, and $M_2^T=PRNG(M_1^T\oplus R_{N_1})$. Next, the server computes $h(STID\oplus t)=M_4^T\oplus R_{N_1}\oplus M_2^T$. Next, the server searches its index table, Table 2, for $h(STID\oplus t)$ using the current data fields section. If it fails, it attempts the search with the old data fields section. If $h(STID\oplus t)$ is not found, the server aborts the protocol. Otherwise, the server extracts t and computes $M_3^{T^{\prime }}=PRNG(t\oplus R_{N_1})$. The server verifies whether $M_3^{T^{\prime }}\stackrel{?}{=}{M}_3^T$. If it is not true, the server aborts the protocol. Otherwise, the tag is authenticated.
  In addition, the server computes $h\left(r\right)$, $t_{new}=PRNG(t\oplus R_{N_1}\oplus T_1^R)$ and computes $r_{new}=PRNG(h\left(r\right)\oplus R_{N_1})$. The server computes $STI{D}_{new}=PRNG(STID\oplus R_{N_1}\oplus T_1^R)$, computes $SRI{D}_{new}=PRNG(SRID\oplus R_{N_1}\oplus T_1^R)$, and computes $s_{new}=PRNG(h\left(s\right)\oplus R_{N_1}\oplus T_1^R)$. Next, the server computes $PRNG\left(r\right)$, computes $M_1^S=PRNG(r_{new}\oplus T_1^R\oplus PRNG\left(r\right))$, computes $PRNG\left(t\right)$, and then computes $M_2^S=PRNG(t_{new}\oplus T_1^R\oplus PRNG\left(t\right))$. Finally, the server updates its index tables for tags and readers as follows:
  For Reader Index Table: If $SRID$, r and $h\left(s\right)$ were extracted from the old data field section, the server sets $SRID=SRI{D}_{new}$, $r=r_{new}$, $h\left(s\right)=h\left(s_{new}\right)$, and $h(SRID\oplus r)=h(SRI{D}_{new}\oplus r_{new})$, whereas $SRI{D}_{old}$, $r_{old}$, $h\left(s_{old}\right)$, and $h(SRI{D}_{old}\oplus r_{old})$ remain the same. If $SRID$, r, and $h\left(s\right)$ were extracted from the current data field section, the server sets $SRI{D}_{old}=SRID$, $r_{old}=r$, $h\left(s_{old}\right)=h\left(s\right)$, $h(SRI{D}_{old}\oplus r_{old})=h(SRID\oplus r)$, $SRID=SRI{D}_{new}$, $r=r_{new}$, $h\left(s\right)=h\left(s_{new}\right)$, and $h(SRID\oplus r)=h(SRI{D}_{new}\oplus r_{new})$.
  For Tag Index Table: If $STID$ and t were extracted from the old data field section, the server sets $STID=STI{D}_{new}$, $t=t_{new}$, and $h(STID\oplus t)=h(STI{D}_{new}\oplus t_{new})$, whereas $STI{D}_{old}$, $t_{old}$, and $h(STI{D}_{old}\oplus t_{old})$ remain the same. If $STID$ and t were extracted from the current data field section, the server sets $STI{D}_{old}=STID$, $t_{old}=t$, $h(STI{D}_{old}\oplus t_{old})=h(STID\oplus t)$, $STID=STI{D}_{new}$, $t=t_{new}$, and $h(STID\oplus t)=h(STI{D}_{new}\oplus t_{new})$. Finally, the server erases $s_{new}$.
• Step 8: The server sends $T_1^S$, $M_1^S$, and $M_2^S$ to the RFID reader.
• Step 9: The RFID reader extracts the current time $T_3^R$ and checks whether $|T_3^R-T_1^S|\stackrel{?}{<}\Delta T$. If it is not true, the RFID reader aborts the protocol. Otherwise, the RFID reader computes $SRI{D}_{new}=PRNG(SRID\oplus R_{N_1}\oplus T_1^R)$, $r_{new}=PRNG(h\left(r\right)\oplus R_{N_1})$, $s_{new}=PRNG(h\left(s\right)\oplus R_{N_1}\oplus T_1^R)$, $PRNG\left(r\right)$, and $M_1^{S^{\prime }}=PRNG(r_{new}\oplus T_1^R\oplus PRNG\left(r\right))$. Next, the RFID reader checks if $M_1^{S^{\prime }}\stackrel{?}{=}{M}_1^S$. If it is not true, the RFID reader will not update its memory table. Otherwise, the RFID reader authenticates the server and approves the new updates. Therefore, the RFID reader computes $h\left(s_{new}\right)$ and updates its memory table by replacing $\{SRID,r,h(s\left)\right\}$ with $\{SRI{D}_{new},r_{new},h\left(s_{new}\right)\}$. Finally, the RFID reader erases $s_{new}$ and $PRNG\left(r\right)$.
• Step 10: Next, the RFID reader sends $M_2^S$ to the tag.
• Step 11: After receiving the message from the RFID reader, the RFID tag computes $PRNG\left(t\right)$, $STI{D}_{new}=PRNG(STID\oplus R_{N_1}\oplus T_1^R)$, and $t_{new}=PRNG(t\oplus R_{N_1}\oplus T_1^R)$. Next, the tag computes $M_2^{S^{\prime }}=PRNG(t_{new}\oplus T_1^R\oplus PRNG\left(t\right))$. Next, it checks whether $M_2^{S^{\prime }}\stackrel{?}{=}{M}_2^S$. If it is not true, the RFID tag will not update its memory table. Otherwise, the RFID tag updates its memory table by replacing $\{STID,t\}$ with $\{STI{D}_{new},t_{new}\}$. Finally, the RFID tag erases $PRNG\left(t\right)$.

5.3. Key Update Summary

For clarity, Table 6 consolidates the key-update rules that are distributed across Steps 7, 9, and 11 of the mutual authentication phase. Every update is bound to the fresh session values $R_{N_1}$ and $T_1^R$ through a one-way PRNG evaluation, which is the basis of the forward-secrecy argument in Section 6.1. An entity commits its update only after verifying the corresponding server confirmation message ($M_1^S$ for the reader, $M_2^S$ for the tag), and the transient value $s_{new}$ is erased by both the server and the reader immediately after use.

Table 6. Key Update Summary.

Secret	Update Formula	Computed By	Committed In	Gated By
t	$t_{new}=PRNG(t\oplus R_{N_1}\oplus T_1^R)$	Server (Step 7), Tag (Step 11)	Steps 7, 11	$M_2^S$
$STID$	$STI{D}_{new}=PRNG(STID\oplus R_{N_1}\oplus T_1^R)$	Server (Step 7), Tag (Step 11)	Steps 7, 11	$M_2^S$
r	$r_{new}=PRNG(h\left(r\right)\oplus R_{N_1})$	Server (Step 7), Reader (Step 9)	Steps 7, 9	$M_1^S$
$SRID$	$SRI{D}_{new}=PRNG(SRID\oplus R_{N_1}\oplus T_1^R)$	Server (Step 7), Reader (Step 9)	Steps 7, 9	$M_1^S$
s	$s_{new}=PRNG(h\left(s\right)\oplus R_{N_1}\oplus T_1^R)$; stored as $h\left(s_{new}\right)$; $s_{new}$ erased after use	Server (Step 7), Reader (Step 9)	Steps 7, 9	$M_1^S$

5.4. Reader Revocation

Because the readers in the system model are mobile, loss or theft of a reader is a realistic operational event (Section 2.1). The dual-entry index table architecture makes revocation a constant-time administrative operation: upon a reported loss, the system administrator deletes (or flags as revoked) the row corresponding to the compromised reader in the server’s reader index table (Table 3). From that point on, any authentication request produced with the captured credentials fails the lookup for $h(SRID\oplus r)$ in Step 7—in both the current and old data field sections—and the server aborts the protocol. No other reader, tag, or server parameter is affected, since every reader holds an independent pseudo-identifier and key pair, and the server master secret s is present on the reader only through the one-way image $h\left(s\right)$. We state the operational limitation plainly: revocation is effective from the moment the loss is reported, and in the interval between capture and report, the captured reader authenticates legitimately by construction—a limitation shared by every credential-revocation mechanism. This exposure window is bounded operationally rather than cryptographically: server-side per-reader rate limiting (Section 6.1), the freshness windows $\Delta T$, and standard usage-anomaly monitoring on the per-reader session log limit what a captured reader can do before revocation, and the per-reader independence of secrets caps the damage to that single reader’s authorizations. The security implications of reader capture are analyzed in Section 6.1.12.

6. Security Analysis of the Proposed Scheme

In this section, both informal and formal analyses are presented in order to show that the proposed scheme can withstand relevant attacks under the adversary model of Section 2.1. In the informal security analysis, we discuss the security and resilience of the proposed protocol against well known attacks including node capture attacks, and we complement it with reduction-based arguments in the random-oracle/PRF model (Section 6.2). As for the formal analysis, there are a number of tools such as BAN-Logic, Scyther, AVISPA, ProVerif, and Tamarin. In this paper, we use three complementary tools—Scyther, ProVerif, and Tamarin—to prove the security correctness of the proposed scheme; Tamarin is included specifically because its equational theory models the algebraic properties of the exclusive-or operation natively. Finally, tag privacy is treated formally in the Juels–Weis model in Section 6.6.

6.1. Informal Security Analysis of the Proposed Scheme

In this subsection, we analyze the resistance of the proposed protocol against the main classes of attacks relevant to RFID authentication systems.

6.1.1. Mutual Authentication (Server-Mediated)

The protocol achieves mutual authentication among the three parties in the server-mediated sense: the server (a trusted third party) authenticates the reader and the tag, and each authenticates the server, so trust between the tag and reader is transitive. The server authenticates the reader via $M_2^R=PRNG(r\oplus T_1^R\oplus h\left(s\right))$ (Step 7) and the tag via $M_3^T=PRNG(t\oplus R_{N_1})$. In contrast, the reader and the tag authenticate the server through $M_1^S$ (Step 9) and $M_2^S$ (Step 11), respectively. Each authenticator binds a fresh nonce and/or timestamp with a long-term secret, so only legitimate entities can produce valid values. As stated in the system-model assumptions of Section 5, mutual trust between the tag and the reader is established transitively through the mutually authenticated server, since the two share no pairwise secret by design.

6.1.2. Replay Attack

Every authentication message is bound to a fresh nonce $R_{N_1}$ and timestamps ($T_1^R$, $T_2^R$, $T_1^S$, $T_3^R$). A replayed $\{M_3^T,M_4^T\}$ fails the server’s freshness check $|T_1^S-T_2^R|<\Delta T$ in Step 7 or produces a mismatch $M_3^{T^{\prime }}\ne M_3^T$ under a new nonce. The same argument applies to $\{M_1^R,M_2^R\}$, and $\{M_1^S,M_2^S\}$. A quantitative bound is given in Theorem 3.

6.1.3. Impersonation Attack

The impersonation of the tag requires the secret t and the identifier $STID$, which reside only in the memory of the tag resistant to tampering. The impersonation of the reader requires r and $h\left(s\right)$, stored only in the reader. The server impersonation requires r, t, and $h\left(s\right)$, stored only on the server. Since none of these secrets ever appear in cleartext on the channel, impersonation is infeasible. Quantitative bounds are given in Theorems 1 and 2.

6.1.4. Man-in-the-Middle Attack

Any modification of $\{R_{N_1},T_1^R\}$ in Step 2 propagates into the tag’s $M_3^T$ and $M_4^T$. Since the server recomputes these values in Step 7 using the authentic $R_{N_1}$ and $T_1^R$ reported by the reader in Step 6, the mismatch is immediately detected and the protocol aborts.

6.1.5. Desynchronization Attack

We analyze desynchronization robustness systematically rather than by example. Consider an entity E (a reader or a tag) and its corresponding server table entry, and define two states: in state ${\mathcal{S}}_0$ (synchronized), the credentials stored by E equal the current data fields of its entry; in state ${\mathcal{S}}_1$ (one behind), they equal the old data fields. The resulting state machine is shown in Figure 7. We enumerate every message-loss scenario after the server commits its update in Step 7:

Figure 7. Synchronization state machine of an entity (reader or tag) relative to its server table entry. ${\mathcal{S}}_0$: entity holds the current data fields; ${\mathcal{S}}_1$: entity holds the old data fields. By Lemma 1, no further state is reachable.

(a)

Loss of Step 8 (reader does not update). The server has shifted its current fields to the old fields and installed the new values as current, while the reader retains its previous credentials; the reader is now in ${\mathcal{S}}_1$. In the next session, the server’s lookup for $h(SRID\oplus r)$ fails on the current fields and succeeds on the old fields, authentication proceeds, and—critically—because the match occurred in the old data field section, the server’s update rule refreshes only the current fields and leaves the old fields unchanged. The reader verifies $M_1^S$ (computed from the matched old-field values and the fresh session parameters), commits the update, and returns to ${\mathcal{S}}_0$.

(b)

Loss of Step 10 (tag does not update). Symmetric to case (a) via Table 2 and $M_2^S$: the tag moves to ${\mathcal{S}}_1$ and returns to ${\mathcal{S}}_0$ at the next completed session.

(c)

Loss of both Steps 8 and 10. The reader and the tag each move to ${\mathcal{S}}_1$ independently; since their entries reside in separate tables and their recoveries use disjoint messages ($M_1^S$ and $M_2^S$), each recovers via cases (a) and (b) independently.

(d)

Repeated blocking. If the adversary blocks the update message again while E is in ${\mathcal{S}}_1$, the server again matches the old fields, again refreshes only the current fields, and again preserves the old fields; E remains in ${\mathcal{S}}_1$ and never falls further behind.

Lemma 1

(One-update-behind invariant). At the beginning of every authentication session, the credentials stored by each reader and each tag are equal either to the current data fields or to the old data fields of the corresponding server table entry.

Proof sketch.

By induction on the number of sessions. The invariant holds after deployment (Section 5.1). For the inductive step, consider one session involving entity E. If E is in ${\mathcal{S}}_0$, and the update message is delivered, the server shifts current to old and installs new values, and E commits the same new values: E ends in ${\mathcal{S}}_0$. If E is in ${\mathcal{S}}_0$, and the update message is blocked, E’s unchanged credentials equal the server’s old fields after the shift: E ends in ${\mathcal{S}}_1$ (case (a)/(b)). If E is in ${\mathcal{S}}_1$, the server matches the old fields and, by the old-field branch of the update rule in Step 7, leaves the old fields unchanged while refreshing only the current fields; if the update message is delivered, E commits the new current values and ends in ${\mathcal{S}}_0$, and if it is blocked, E remains equal to the (preserved) old fields and stays in ${\mathcal{S}}_1$ (case (d)). In all branches, the invariant is maintained.    □

The dual-entry design therefore implements rollback semantics by construction: no additional recovery protocol is required, and an entity re-converges with the server within one completed session, regardless of the adversary’s blocking strategy.

6.1.6. Eavesdropping Attack

The long-term secret (r, t, s, $SRID$, $STID$) is not transmitted in cleartext. The tag’s identifier appears only inside $h(STID\oplus t)$, which is further masked by $R_{N_1}\oplus M_2^T$ in $M_4^T$. Modular squaring $X_R=x_R^2\mathrm{mod}n$ is infeasible to invert without factorization $n=p·q$, held only by the server.

6.1.7. Tag Tracking and Location Privacy

Randomization is carried out within $M_3^T$ and $M_4^T$ by the variables $R_{N_1}$ and $T_1^R$, and both $STID$ and t are refreshed after each successful session, so two responses of the same tag separated by a completed key update are unlinkable: all values emitted in the later session are one-way PRNG outputs under refreshed secrets. We note, however, an important subtlety of the index-based lookup mechanism: because $M_2^T$ is computable from the public values $R_{N_1}$ and $T_1^R$ alone, a passive eavesdropper can recover the index value $h(STID\oplus t)=M_4^T\oplus R_{N_1}\oplus M_2^T$, and this value remains constant between successful updates. Unlinkability therefore holds across completed sessions, but an active adversary who blocks the Step 10 update message can observe the same index value across the blocked sessions, obtaining a tracking window that lasts until the next completed session. Section 6.6 formalizes both the unlinkability guarantee and this bounded residual window in the Juels–Weis model, explains why the window is inherent to constant-time index-based lookup, and notes a possible mitigation direction.

6.1.8. Tag Cloning Attack

An adversary who wants to clone the tag’s stored secrets will fail, as these secrets are held in tamper-resistant memory and never appear in cleartext. In addition, refreshing them in each session is a key feature that will prevent any leaked outdated data from being authenticated in later sessions.

6.1.9. Forward Secrecy

The one-way property of the $PRNG$ used in $t_{new}=PRNG(t\oplus R_{N_1}\oplus T_1^R)$ and $STI{D}_{new}=PRNG(STID\oplus R_{N_1}\oplus T_1^R)$ prevents the recovery of any previous secret even if an adversary compromises the current secret $(\mathit{STID},t)$ and the public transcript $(R_{N_1},T_1^R)$. In addition, after each update is performed in Step 7, the server erases $s_{new}$ immediately, which prevents transient values from leaking into previous sessions. We state the converse limitation explicitly: forward secrecy does not imply post-compromise security. Because every update is a deterministic function of the current secret and public transcript values (Table 6), an adversary who obtains a tag’s current $(\mathit{STID},t)$ could compute all subsequent secrets by observing the public transcripts. The protocol therefore relies on the tamper-resistance assumption of Section 5 to exclude tag-state extraction in the first place, rather than on healing after compromise; introducing tag-side entropy into the update chain to obtain post-compromise recovery—at the cost of the $O\left(1\right)$ lookup property—is noted as future work in Section 8.

6.1.10. Denial-of-Service (DoS) Attack

Multiple early-rejection checkpoints limit the cost of invalid requests to a small fixed amount per rejected session. This happens because timestamp checks in Steps 5 and 7 verify that the time elapsed since the previous hop does not exceed the threshold $\Delta T$, and the verification of $M_1^R$, $M_2^R$, and $M_3^T$ in Step 7 confirms the reader’s and tag’s knowledge of their respective long-term secrets, all before any key update is performed. In addition, hash-indexed server tables (Table 2 and Table 3) use precomputed values $h(\mathit{SRID}\oplus r)$ and $h(\mathit{STID}\oplus t)$ as direct lookup keys. This ensures a constant-time expected lookup that is independent of the number of registered tags and readers, preserving server availability under load. Two further mitigations bound the cost of the quadratic residue stage itself: the freshness test in Step 7 precedes the root extraction, so stale or replayed requests are rejected before the server performs any modular arithmetic, and a per-reader rate-limiting rule at the server throttles floods of well-formed but invalid requests from a single origin before they reach the extraction stage. The residual per-request cost of the extraction stage is bounded by $1T_{qr}+8T_h$ (Section 5.2), a small constant.

6.1.11. Secret Disclosure

The tag secret only shows up in two places: $\mathit{PRNG}(t\oplus R_{N_1})$ and a hash function that combines the tag secret with a unique $\mathit{ID}$. Similarly, the reader’s secret key is only found inside a hash function that combines the reader’s $\mathit{ID}$ with the key and a random number generator that uses the key along with some other values $\mathit{PRNG}(r\oplus T_1^R\oplus h\left(s\right))$. The server’s secret, on the other hand, is never used directly—only a hashed version of it is used for authentication. This means that even if someone sees the hashed values, they will not be able to figure out the original secrets because the hash function only works one way.

6.1.12. Reader Compromise Resistance and Revocation

Under the physical-capture capability of Section 2.1, an adversary who captures a mobile reader obtains exactly the tuple $\{SRID,r,h(s\left)\right\}$. Three properties bound the resulting damage. First, the server master secret s cannot be recovered, since the reader holds only its one-way image $h\left(s\right)$; consequently, no other reader’s credentials can be derived, because each reader is provisioned with an independent $(SRID,r)$ pair. Second, no tag is endangered: tag secrets $(STID,t)$ never reside on any reader, and the reader merely relays the tag-related messages $M_3^T$, $M_4^T$, and $M_2^S$ without being able to open them. Third, the exposure window of the captured credentials themselves is closed administratively by the revocation procedure of Section 5.4: once the corresponding row of Table 3 is deleted or flagged, the captured tuple fails the Step 7 lookup and can no longer authenticate. This directly addresses the stolen-reader attack surface that Li et al. [13] identified against the protocol of Srivastava et al. [14].

6.2. Reduction-Based Security Arguments

To complement the attack-by-attack discussion above with bounding arguments, we model $h(·)$ as a random oracle with ℓ-bit output and, for a long-term secret k, model $PRNG(k\oplus ·)$ as a pseudo-random function $F_k(·)$ drawn from a PRF family; ${\mathbf{Adv}}^{\mathrm{PRF}}\left(\mathcal{B}\right)$ denotes the distinguishing advantage of an adversary $\mathcal{B}$ against this family. This modeling choice deserves a caveat: keying a function by XOR-ing the key into its input is sound only if the underlying construction behaves as a PRF under related inputs, which a bare statistical generator does not provide. It is justified here because, per Section 4.2, $PRNG(·)$ is instantiated as a keyed cryptographic construction on the same engine as $h(·)$ (e.g., a hash- or AES-based PRF), for which this is the standard assumption; the Gen2-mandated 16-bit generator is never used in this role. The adversary $\mathcal{A}$ is active in the sense of Section 2.1 and makes at most q queries in total (protocol sessions plus random-oracle queries). We write $\lambda =|R_{N_1}|$ for the nonce length.

Theorem 1

(Tag impersonation). For any adversary $\mathcal{A}$ that causes the server to authenticate a tag in a session whose nonce $R_{N_1}$ is fresh, without $\mathcal{A}$ holding the tag secret t, there exists a PRF adversary $\mathcal{B}$ such that ${\mathbf{Adv}}^{\mathrm{tag}\text{-}\mathrm{imp}}\left(\mathcal{A}\right)\le {\mathbf{Adv}}^{\mathrm{PRF}}\left(\mathcal{B}\right)+{\displaystyle \frac{q^2}{2^{\ell }}}+{\displaystyle \frac{q}{2^{\lambda }}}.$

Proof sketch.

To be accepted in Step 7, $\mathcal{A}$ must produce $M_3^T=PRNG(t\oplus R_{N_1})=F_t\left(R_{N_1}\right)$ on the fresh nonce $R_{N_1}$, together with an $M_4^T$ consistent with the registered index value $h(STID\oplus t)$. Since the index value is recoverable from any prior transcript (Section 6.1.7), $M_4^T$ poses no barrier, and the security rests entirely on $M_3^T$. In a first game hop, replace $F_t$ by a truly random function; $\mathcal{A}$’s success probability changes by at most ${\mathbf{Adv}}^{\mathrm{PRF}}\left(\mathcal{B}\right)$, where $\mathcal{B}$ simulates the protocol using its PRF oracle. In the modified game, a fresh nonce has never been queried to the random function unless a nonce collision with an earlier session occurred (probability at most $q/2^{\lambda }$), so $\mathcal{A}$ must guess a uniformly random ℓ-bit value, succeeding with probability at most $q/2^{\ell }$; random-oracle collisions contribute at most $q^2/2^{\ell }$ in total. Collecting terms yields the bound.    □

Theorem 2

(Reader impersonation). For any adversary $\mathcal{A}$ that causes the server to authenticate a reader in a session with fresh $R_{N_1}$ and $T_1^R$, without $\mathcal{A}$ holding both r and $h\left(s\right)$, there exist adversaries $\mathcal{B}$ (against the PRF) and $\mathcal{C}$ (against the one-wayness of h) such that ${\mathbf{Adv}}^{\mathrm{rdr}\text{-}\mathrm{imp}}\left(\mathcal{A}\right)\le {\mathbf{Adv}}^{\mathrm{PRF}}\left(\mathcal{B}\right)+{\mathbf{Adv}}_h^{\mathrm{OW}}\left(\mathcal{C}\right)+{\displaystyle \frac{q^2}{2^{\ell }}}+{\displaystyle \frac{q}{2^{\lambda }}}.$

Proof sketch.

Acceptance in Step 7 requires (i) a value $X_R$ whose extracted root $x_{R_i}$ satisfies the $M_1^R$ check and maps under $\oplus R_{N_1}$ to a registered index $h(SRID\oplus r)$ and (ii) the confirmation $M_2^R=PRNG(r\oplus T_1^R\oplus h\left(s\right))$, i.e., a PRF evaluation keyed jointly by r and $h\left(s\right)$ at the fresh point $T_1^R$. Requirement (i) is satisfiable from transcripts, since the index value is recoverable as $x_R\oplus R_{N_1}$ from an eavesdropped session; the reduction therefore concentrates on (ii). If $\mathcal{A}$ succeeds without $h\left(s\right)$, extracting a preimage-related value contradicts one-wayness ($\mathcal{C}$); if $\mathcal{A}$ succeeds without evaluating the PRF on the fresh point, the game-hop argument of Theorem 1 applies verbatim, yielding the PRF, collision, and nonce-reuse terms.    □

Theorem 3

(Replay resistance). The probability that the server accepts a transcript containing any message replayed from an earlier session is at most ${\displaystyle \frac{q}{2^{\lambda }}}+{\mathbf{Adv}}^{\mathrm{PRF}}\left(\mathcal{B}\right),$ in addition to the requirement that the replay arrive within the freshness window $\Delta T$.

Proof sketch.

Every verification equation in Steps 7, 9, and 11 evaluates a PRF at a point that includes the current session’s $R_{N_1}$ (and, for $M_2^R$, $M_1^S$, $M_2^S$, the timestamp $T_1^R$). A message replayed under a new nonce therefore fails its check unless the PRF outputs collide across distinct points, which are bounded by ${\mathbf{Adv}}^{\mathrm{PRF}}\left(\mathcal{B}\right)$ after the standard game hop, or the nonce itself repeats, which occurs with probability at most $q/2^{\lambda }$ over q sessions. Replays of an entire session additionally face the timestamp checks of Steps 5, 7, and 9.    □

We emphasize that these are asymptotic-style bounds intended to make the informal arguments of Section 6.1 objective and quantitative; the automated analyses in the following subsections verify the corresponding trace properties mechanically.

6.3. Formal Security Analysis Using Scyther

In this section, we present the formal analysis using the Scyther tool [31] to evaluate the security of the proposed protocol. Scyther is a well-known automated verification tool for security protocols. It was selected because of its open-source Python-based development and its effectiveness in analyzing security protocols. The verification process involved a detailed examination of each of the protocol-related security claims.

The complete Scyther SPDL specification of the proposed protocol is presented in Listing 1. The model declares four hash-style functions (h, $PRNG$, $Eac$, $MS$ (modular squaring)) and three roles (reader, tag, server), faithfully reflecting the eleven steps of the mutual authentication phase described in Section 5.2. Each role declares its long-term secrets, its fresh nonces and timestamps, and its send/receive events. Standard Scyther security claims are issued at the end of each role to evaluate the secrecy of long-term secrets and to verify mutual authentication through the Alive, Weakagree, Niagree, and Nisynch claims.

The results of running Scyther on the SPDL specification of Listing 1 are summarized in Figure 8. All twenty security claims distributed across the three roles—six for the reader (R1–R6), six for the tag (T1–T6), and eight for the server (S1–S8)—returned an “Ok” status with the comment “No attacks within bounds,” confirming that the proposed protocol satisfies secrecy of long-term secrets and provides mutual authentication between all communicating entities under the Dolev–Yao threat model.

Figure 8. Scyther verification results for the proposed RFID authentication protocol.

6.4. Formal Security Analysis Using ProVerif

To further strengthen the formal security guarantees of the proposed protocol, we complement the Scyther verification with an independent analysis using ProVerif [32]. ProVerif is a widely used automated verification tool based on the applied pi-calculus. It supports an unbounded number of protocol sessions, making it suitable for verifying secrecy and authentication properties under the Dolev–Yao threat model.

Listing 1. Scyther SPDL specification of the proposed RFID authentication protocol.

The ProVerif model declares five cryptographic primitives matching those defined in Section 4: a one-way hash function (hash), a pseudo-random number generator (prng), an exchange-cross operation (eac), a bitwise XOR operation (xor), and a modular squaring function (modsq). The quadratic residue root extraction, which is exclusive to the server (Section 4.1), is modeled as a destructor (qrsolve) that can only invert modsq—reflecting the server’s sole knowledge of the factorization $n=p·q$. Three processes (reader, tag, server) faithfully encode the eleven steps of the mutual authentication phase described in Section 5.2, with each entity’s stored secrets matching Table 4 and Table 5.

Since ProVerif’s equational engine cannot natively handle the full algebraic theory of XOR (self-inverse, associativity, commutativity), which produces non-confluent rewriting systems, we adopt the standard approach used in the ProVerif-based RFID verification literature: XOR is modeled as a plain constructor without equational properties, and the server’s verification logic uses recomputation instead of XOR recovery. That is, instead of unmasking a received value via XOR cancellation, the server recomputes the expected masked value from its stored secrets and compares it against the received value. This transformation is semantically equivalent—both approaches verify the same mathematical relationship—and constitutes a sound abstraction that does not introduce false positives. Nevertheless, a constructor-based model cannot, by construction, explore attacks that exploit the algebraic properties of XOR; the Tamarin analysis of Section 6.5 closes exactly this gap.

The complete ProVerif specification of the proposed protocol is presented in Listing 2. Nine security queries are evaluated: five secrecy queries (for the long-term secrets r, s, t, $SRID$, and $STID$) and four correspondence assertions (for mutual authentication between all three entities). Table 7 summarizes the verification results.

Listing 2. ProVerif specification of the proposed RFID authentication protocol.

Table 7. ProVerif Verification Results.

#	Query/Property	Result
Secrecy Queries
Q1	attacker(rkey): Secrecy of r	True
Q2	attacker(skey): Secrecy of s	True
Q3	attacker(tkey): Secrecy of t	True
Q4	attacker(SRID): Secrecy of $SRID$	True
Q5	attacker(STID): Secrecy of $STID$	True
Authentication Queries
Q6	Server authenticates Reader	True
Q7	Server authenticates Tag	True
Q8	Reader authenticates Server	True
Q9	Tag authenticates Server	True

All nine queries returned true, confirming that no attack exists within the Dolev–Yao model. The five secrecy queries (Q1–Q5) establish that no attacker strategy can extract any long-term secret, corresponding to eavesdropping resistance (Section 6.1.6) and secret disclosure resistance (Section 6.1.11). The four correspondence assertions (Q6–Q9) establish mutual authentication (Section 6.1.1): Q6 and Q7 confirm that the server cannot be deceived into accepting a forged reader or tag, while Q8 and Q9 confirm that neither the reader nor the tag can be deceived into accepting a forged server response.

6.5. XOR-Aware Formal Analysis Using Tamarin

The Scyther and ProVerif models above abstract the exclusive-or operation, and XOR-based protocols have historically been broken by algebraic attacks—message recombination through XOR cancellation—that such abstractions cannot express. To close this gap, we additionally verify the protocol with the Tamarin prover [33], whose built-in equational theory (builtins: xor) supports the full algebraic theory of XOR, including self-inverse, associativity, commutativity, and the neutral element.

The Tamarin theory, presented in Listing 3, encodes the same three roles and the eleven steps of Section 5.2. The functions h, $PRNG$, and $Eac$ are modeled as free function symbols; modular squaring is modeled as $\mathsf{msq}/1$ together with a root-extraction function $\mathsf{qrsolve}/2$ satisfying the equation $\mathsf{qrsolve}\left(\mathsf{msq}\right(x),\mathit{fk})=x$, where the factorization witness $\mathit{fk}$ is generated fresh in the setup rule and given only to the server—capturing the fact that only the holder of p and q can extract roots. Two modeling choices deserve mention. First, the server rule encodes the combination of root extraction, $M_1^R$ disambiguation, and table lookup by pattern-matching the received $X_R$ against $\mathsf{msq}(h(SRID\oplus r)\oplus R_{N_1})$: a rule instance exists exactly when extraction succeeds and the recovered index matches the registered $h(SRID\oplus r)$, which is the Step 7 acceptance condition. Second, $M_1^R$ is modeled as $h\left(⟨x_R,R_{N_1}⟩\right)$: its role is a random-oracle binding of $x_R$ and $R_{N_1}$, and its internal concatenation/XOR layout is irrelevant once inside the oracle, whereas keeping it literal multiplies XOR unification variants without adding attack surface. All XOR occurrences that carry algebraic weight—the masking of the index value in $M_4^T$, the construction of $x_R$, and every XOR under $PRNG$—are modeled literally. Ten lemmas are stated: five secrecy lemmas for the long-term secrets (secrecy_r, secrecy_s, secrecy_t, secrecy_SRID, secrecy_STID), four non-injective agreement lemmas covering all four authentication directions (agree_server_reader, agree_server_tag, agree_reader_server, agree_tag_server), and one exists-trace sanity lemma (executable) whose witness event $\mathsf{TagAuthServer}$ can only occur after a complete honest protocol chain. The theory is accepted by Tamarin with no well-formedness violations, confirming that the model is syntactically and structurally sound and that the exclusive-or operator is handled by the native equational theory rather than abstracted away. However, automated proof of the secrecy and agreement lemmas does not terminate within practical time bounds: the self-inverse, associative, and commutative properties of exclusive-or make its unification non-finitary, so the constraint-solving search over message recombinations does not converge for a protocol that uses ⊕ as heavily as ours. This is a well-documented limitation of automated reasoning about XOR-based protocols rather than an indication of an attack, and it affects Tamarin’s proof search, not the soundness of the model. We therefore rely on the Scyther and ProVerif analyses of Section 6.3 and Section 6.4 for the mechanized secrecy and authentication guarantees, on the reduction-based arguments of Section 6.2 for the XOR-sensitive properties (where the PRF reduction covers exactly the message-recombination adversary that motivated the Tamarin model), and we leave a fully terminating mechanized XOR proof—for instance via a bounded-session model or manually guided interactive proof—as future work.

Listing 3. Tamarin theory of the proposed RFID authentication protocol with native XOR modeling.

We state a scope limitation shared by all three tool-based analyses: each models the protocol within a single key epoch, i.e., the roles hold fixed long-term secrets, and the dual-entry update state machine is not mechanized. Cross-epoch properties—desynchronization recovery and unlinkability across updates—are established by the pen-and-paper arguments of Lemma 1 and Theorem 4, which is the customary division of labor in this literature; mechanizing the stateful update logic (e.g., in Tamarin’s mutable-state fragment) is left as future work.

6.6. Formal Privacy Analysis and Bounded Tracking Window

We now formalize the location-privacy discussion of Section 6.1.7 in the indistinguishability based privacy model of Juels and Weis [34].

Definition 1

(Tag unlinkability game). The challenger initializes the system with N tags, the readers, and the server. The adversary $\mathcal{A}$ may, in a learning phase, interact arbitrarily with all entities under the capabilities of Section 2.1. $\mathcal{A}$ then designates two uncorrupted challenge tags $R{T}^a$ and $R{T}^b$; the challenger draws a uniform bit β and gives $\mathcal{A}$ oracle access to $R{T}^{c_{\beta }}$ (with $c_0=a$, $c_1=b$) through complete protocol sessions. Finally $\mathcal{A}$ outputs a guess ${\beta }^{\prime }$. The advantage of $\mathcal{A}$ is ${\mathbf{Adv}}^{\mathrm{priv}}\left(\mathcal{A}\right)=\left|Pr[{\beta }^{\prime }=\beta ]-\frac{1}{2}\right|$.

Theorem 4

(Unlinkability across completed sessions). If every challenge-phase session completes successfully (i.e., the Step 10 update message is delivered and verified), then for any adversary $\mathcal{A}$ making at most q queries, there exists a PRF adversary $\mathcal{B}$ such that ${\mathbf{Adv}}^{\mathrm{priv}}\left(\mathcal{A}\right)\le 2q·{\mathbf{Adv}}^{\mathrm{PRF}}\left(\mathcal{B}\right)+{\displaystyle \frac{q^2}{2^{\ell }}}.$

Proof sketch.

After a completed session, both $STID$ and t are refreshed through one-way PRNG evaluations at points containing the fresh $R_{N_1}$ and $T_1^R$ (Table 6). Every value the challenge tag emits in the following session—$M_3^T=F_{t^{\prime }}\left(R_{N_1}\right)$ and the index value $h(STI{D}^{\prime }\oplus t^{\prime })$ inside $M_4^T$—is therefore an evaluation of a PRF under a refreshed key or a random-oracle output at a point never queried before except with collision probability $q^2/2^{\ell }$. A hybrid argument over the at most q challenge sessions replaces each such evaluation with an independent uniform value at a cost of ${\mathbf{Adv}}^{\mathrm{PRF}}\left(\mathcal{B}\right)$ per key per session; in the final hybrid, the transcript distribution is identical for $\beta =0$ and $\beta =1$, so the advantage collapses to the collected hybrid losses. □

Remark 1

(Bounded tracking window). The completed-session condition in Theorem 4 is necessary, and the resulting limitation should be stated plainly. If an active adversary blocks the Step 10 message in k consecutive sessions of the same tag, the recoverable index value $h(STID\oplus t)$ (Section 6.1.7) remains constant throughout those k sessions, which links them; the window closes at the first completed session, when Theorem 4 again applies. This bounded window is inherent to any scheme with constant-time index-based lookup: the server must locate the correct table entry before it knows which tag-specific secret to apply, so the lookup key cannot itself be masked by a per-session tag-side secret without forfeiting $O\left(1\right)$ lookup. The same structural trade-off is present in the hash-indexed designs of [8,11]. We further observe that the window is not passively exploitable: sustaining it requires the adversary to actively block the update message in every targeted session, which is a continuous, energy-expensive, and readily detectable jamming attack that simultaneously denies the tag its normal service; a single unblocked session—whether because the adversary pauses, the tag moves out of the jammer’s range, or the channel recovers—immediately refreshes the index value and terminates the window. The exposure is therefore bounded not only in principle but in practice by the adversary’s ability to maintain uninterrupted jamming of one specific tag.

We note that this residual window can, in principle, be capped by design—for instance, by having a tag that has observed several consecutive unconfirmed updates switch to a randomized-response mode in which the server resolves its entry by bounded search rather than $O\left(1\right)$ index lookup. A full specification and analysis of such a mechanism, including its own denial-of-service containment, is beyond the scope of this paper and is left to future work; the guarantee established here is the unlinkability of Theorem 4 across completed sessions, together with the explicit statement of the residual window under sustained blocking.

7. Performance Analysis of the Proposed Scheme

7.1. Computational Overhead

To enable a systematic analysis of the computational cost of the proposed protocol, we first introduce the notation used throughout this section. Table 8 summarizes the symbols that represent the cost of each cryptographic and logical operation used in the proposed scheme.

Table 8. Notation of Computational Cost Operations.

Symbol	Operation
$T_{\oplus }$	Cost of one bitwise XOR operation
$T_{\left|\right|}$	Cost of one concatenation operation
$T_h$	Cost of one one-way hash operation
$T_{PRNG}$	Cost of one pseudo-random number generation
$T_{Eac}$	Cost of one exchange-cross operation
$T_{ms}$	Cost of one modular squaring operation $\left(x^2\mathrm{mod}n\right)$
$T_{qr}$	Cost of one quadratic residue root extraction $(y\equiv x^2\mathrm{mod}n)$
$T_{srch}$	Cost of one index-table search $\left(O\right(1)$ with hash indexing)
$T_{cmp}$	Cost of one equality comparison (negligible)
$T_{ts}$	Cost of one timestamp extraction or comparison (negligible)
$T_{nonce}$	Cost of one nonce generation (negligible)

Based on the notation in Table 8, we now quantify the total computational cost incurred by each entity during one execution of the mutual authentication phase.

Tag: The RFID tag performs a total of $12T_{\oplus }+1T_{Eac}+6T_{PRNG}+1T_h$ operations in Steps 3 and 11 of the mutual authentication phase.

Reader: The RFID reader performs a total of $12T_{\oplus }+1T_{\left|\right|}+5T_h+6T_{PRNG}+1T_{ms}$ operations in Steps 1, 5, and 9 of the mutual authentication phase.

Server: The RFID server performs a total of $27T_{\oplus }+4T_{\left|\right|}+12T_h+12T_{PRNG}+1T_{Eac}+1T_{qr}+2T_{srch}$ operations in Step 7 of the mutual authentication phase (worst-case $QR$ (quadratic residue) matching).

Note: Negligible operations ($T_{cmp}$, $T_{ts}$, $T_{nonce}$) are omitted from these totals to align with the convention used in comparable RFID performance analyses [8,11,29].

Reader-side modular squaring cost: We argue that the single $T_{ms}$ charged to the reader is negligible on the target device class, independently of the exact processor. Mobile RFID readers are battery-powered handheld or smartphone-class devices built around ARM application processors (typically Cortex-A class), not energy-harvesting devices. On such processors, a 1024-bit modular squaring is a single big-integer multiplication followed by one modular reduction; with a standard multiple-precision library, this completes in the microsecond range (for reference, a GMP-backed implementation on a 64-bit processor completes one such operation in 3.5μs over $2\times {10}^5$ iterations), and it is executed exactly once per authentication session. The decisive point is not the absolute timing but the comparison against the reader’s own dominant energy cost: the same device performs RF transmission and reception on the order of milliseconds per session, whose energy exceeds that of a single microsecond-scale arithmetic operation by several orders of magnitude. The modular squaring is therefore a negligible fraction of the reader’s per-session power budget—it is dwarfed by the radio activity the device must perform regardless of the authentication scheme. We further note why offloading the squaring to the server (as one might consider to relieve the reader) would be counterproductive: the squaring is precisely the mechanism that conceals $x_R$ on the reader-to-server link. Transmitting $x_R$ in the clear so that the server could square it would expose $h(SRID\oplus r)\oplus R_{N_1}$ to the channel adversary and defeat the purpose of the construction. Direct measurement on representative ARM reader hardware is noted as future work, but the order-of-magnitude margin above makes the conclusion robust to the specific platform.

Index lookup at scale: The constant-time lookup claim deserves scrutiny under realistic deployment sizes, including collision handling and index maintenance. The lookup key is a full $\ell =160$-bit hash output; by the birthday bound, the probability that any two of even ${10}^7$ registered entries collide is approximately $\left({\displaystyle \genfrac{}{}{0pt}{}{{10}^7}{2}}\right)/2^{160}\approx 2^{-114}$, and the probability that a given lookup encounters a colliding bucket is smaller still—negligible, but not assumed away: the server structure is an in-memory hash map with separate chaining, whose expected lookup cost is $O\left(1\right)$ and whose worst case degrades gracefully to $O\left(k\right)$ for k colliding entries. Index maintenance per successful session consists of two constant-time row updates (old and current fields), independent of deployment size. Table 9 reports measured lookup latency for table populations spanning four orders of magnitude (${10}^3$ to ${10}^7$ entries, 160-bit keys, in-memory hash map, mean over $2\times {10}^4$ random probes). Latency remains within one microsecond throughout; the mild growth with population is attributable to processor cache-hierarchy effects (larger tables exceed successive cache levels), not to algorithmic complexity, which remains $O\left(1\right)$ expected.

Table 9. Measured Server Lookup Latency vs. Table Population.

Entries	${10}^3$	${10}^4$	${10}^5$	${10}^6$	${10}^7$
Mean lookup (μs)	0.07	0.15	0.48	0.67	1.01

Reference implementation: interpreted-language (CPython) hash map with separate chaining, 160-bit keys, commodity 64-bit server; mean over $2\times {10}^4$ uniformly random successful probes per population. The figures are conservative upper bounds—a compiled production implementation would be faster still—and the trend, not the absolute values, is the object of the measurement.

7.2. Communication and Storage Overhead

In this subsection, we evaluate the communication and storage overhead of the proposed authentication protocol. The bit-lengths of the protocol parameters follow the conventions commonly adopted in the RFID authentication literature [8,9,11]. Specifically, we assume that pseudo-identifiers ($SRID$, $STID$) and secret keys (r, t, s) are 96 bits each, random nonces ($R_{N_1}$) are 128 bits, timestamps are 32 bits, hash outputs are 160 bits, PRNG and Eac outputs are 128 bits each, and the modular squaring output ($X_R=x_R^2\mathrm{mod}n$) is 1024 bits.

7.2.1. Communication Overhead

The proposed protocol involves five transmission steps during the mutual authentication phase. Table 10 summarizes the communication payload of each step, derived directly from the description of the protocol in Section 5.2.

Table 10. Communication Overhead of the Proposed Protocol.

Step	From → To	Transmitted Values	Size (Bits)
2	Reader → Tag	$\{R_{N_1},T_1^R\}$	160
4	Tag → Reader	$\{M_3^T,M_4^T\}$	288
6	Reader → Server	$\{M_1^R,M_2^R,M_3^T,T_1^R,$$T_2^R,X_R,R_{N_1},M_4^T\}$	1792
8	Server → Reader	$\{T_1^S,M_1^S,M_2^S\}$	288
10	Reader → Tag	$\left\{M_2^S\right\}$	128
Total Channel Traffic			2656

Total represents the channel traffic: the sum of bits transmitted across every network hop, with each transmission counted once at the sender. Forwarded values are counted at each hop they traverse.

Counting each network hop once at the sender (with forwarded values counted at each hop they traverse), the per-entity breakdown is as follows. The tag transmits 288 bits in Step 4 ($M_3^T+M_4^T$). The reader transmits 2080 bits across Steps 2, 6, and 10: 160 bits in Step 2, 1792 bits in Step 6 (which includes the relay of $M_3^T$ and $M_4^T$ from tag to server), and 128 bits in Step 10 (relay of $M_2^S$ from server to tag). The server transmits 288 bits in Step 8 ($T_1^S+M_1^S+M_2^S$). These per-entity contributions sum to the 2656-bit channel-traffic total in Table 10. The tag-side profile is compatible with the memory and energy budget of passive EPC Gen2v2 class tags, while the heavier 1792-bit payload in Step 6 is dominated by the 1024-bit quadratic residue value $X_R$ and is handled by the higher-bandwidth reader-to-server link.

Framed channel traffic: The payload figures above exclude link-layer framing. To present realistic wireless-channel traffic, Table 11 adds the air-interface and network-layer overheads per message: each of the three over-the-air messages (Steps 2, 4, and 10) carries the CRC-16 mandated by the EPC Gen2 air interface [30], and each of the two backhaul messages (Steps 6 and 8) is charged a representative 40-byte IPv4/TCP header. Preamble and frame-sync are time-domain signaling rather than payload bits and depend on the selected link rate; they are therefore excluded from the bit accounting. Since every scheme compared in Section 7.3 traverses the same link types with comparable message counts, identical per-message framing applies across schemes, and the relative rankings are preserved under framed accounting; the framed totals simply give the realistic absolute figures.

Table 11. Framed Channel Traffic of the Proposed Protocol.

Step	Link	Payload (Bits)	Framing (Bits)	Framed (Bits)
2	Gen2 air interface	160	16 (CRC-16)	176
4	Gen2 air interface	288	16 (CRC-16)	304
6	Backhaul (TCP/IPv4)	1792	320	2112
8	Backhaul (TCP/IPv4)	288	320	608
10	Gen2 air interface	128	16 (CRC-16)	144
Framed Total				3344

7.2.2. Storage Overhead

The persistent storage requirement of each entity is derived directly from Table 2, Table 3, Table 4 and Table 5 presented in Section 5.1. Table 12 summarizes the storage overhead per entity.

Table 12. Storage Overhead of the Proposed Protocol.

Entity	Stored Values	Size (Bits)
RFID Tag	$\{STID,t\}$	192
RFID Reader	$\{SRID,r,h(s\left)\right\}$	352
Server (per tag entry)	Old ∪ New: $\{STID,t,$ $h(STID\oplus t)\}$	704
Server (per reader entry)	Old ∪ New: $\{SRID,r,h(s),$ $h(SRID\oplus r)\}$	1024

For a deployment with $N_T$ registered tags and $N_R$ registered readers, the total server-side storage is given by

$$\left|\mathrm{Server}\mathrm{Storage}\right|=704N_T+1024N_R\mathrm{bits}$$

(1)

The highest storage penalty is chargeable to the server as it needs to maintain two (old and new) data fields within its index tables for graceful desynchronization recovery, this trade-off is acceptable in practice because server-side storage is abundant.

Implementation footprint: The figures above cover mutable credential storage. Feasibility on severely constrained tags additionally requires accounting for the fixed, non-volatile footprint of the primitive implementations themselves. Table 13 summarizes this footprint for the tag. The $Eac$ operation is a fixed exchange-and-cross bit-permutation; in an ASIC realization, it is routing rather than logic, and its cost is negligible. The cryptographic engine is the only element with a substantive footprint, and it serves both keyed primitives: the hash $h(·)$ and the keyed $PRNG(·)$, which per Section 4.2 is instantiated on the same engine (hash in feedback mode, or an AES-based PRF) rather than on the specification-mandated 16-bit generator, whose role is confined to air-interface randomness. This engine can be realized in two commercially grounded ways: as a dedicated lightweight hash core such as PHOTON [35] or SPONGENT [36], each realizable in approximately 1000–2000 gate equivalents (GE) at the 160-bit security level, or—on Gen2v2 crypto tags that already ship an AES-128 engine—via standard AES-based constructions [37], reusing the existing engine at essentially zero additional area. For microcontroller-class implementations, the corresponding code footprint is on the order of 1–4 KB of ROM. The total incremental digital footprint of the proposed scheme on the tag is therefore approximately 1–2 kGE beyond the baseline tag logic, which is well within the digital gate budget of commercial Gen2v2 crypto-enabled tags (Section 7.4). For a like-for-like comparison, note that the schemes of Zhou et al. [9] and SecMAP [10] additionally require a 1024-bit modular multiplier on the tag, whose area dwarfs a lightweight hash core, while Fan et al. [8] and Xu et al. [11] require PRNG/rotation/Eac-class primitives of footprint comparable to or below ours.

Table 13. Tag-Side Implementation Footprint of the Proposed Protocol. Costs are stated as the additional gate equivalents (GE) required beyond the digital logic of a baseline passive EPC Gen2v2 crypto-enabled tag; gate counts assume the 8- or 16-bit serial datapath typical of passive-tag logic.

Primitive	Tag-Side Realization	Approximate Cost
XOR	Native bitwise logic, folded into the existing tag datapath	≈2 GE/bit; <50 GE on an 8/16-bit serial datapath (<3% of the crypto engine)
$Eac$	Data-independent exchange-cross bit-permutation; fixed routing, no logic gates	Negligible (wiring only)
$h(·)$ and keyed $PRNG(·)$	One shared engine: PHOTON [35]/SPONGENT [36] core, or AES-based constructions [37] on the Gen2v2 AES engine (Section 4.2)	≈1.1–2 kGE total; ≈1–4 KB ROM (MCU-class)
16-bit RNG	Mandated by EPC Gen2 [30]; air-interface randomness only, not used as the keyed $PRNG(·)$	No marginal cost

7.3. Comparison with Existing Protocols

We compare our protocol with four RFID authentication protocols from the recent literature: Fan et al. [8] (2019, IEEE Network), SecMAP by Zhu [10] (2020, IEEE Access), Zhou et al. [9] (2019, JAIHC), and Xu et al. [11] (2023, IEEE Access). Similarities in cryptography and structure among these schemes led us to select them specifically; they have also been widely cited in the field. The quadratic residue theory employed by Fan et al. [8] and Zhou et al. [9] aligns with our cryptographic foundation. SecMAP [10] further uses quadratic residues combined with hash functions and was specifically designed to overcome the limitations of earlier healthcare RFID protocols, making it a directly relevant comparator for our scheme. In addition, Xu et al. [11] used the $E_{ac}$ (exchange-cross) operation and hash-indexed server tables. This setup is similar to our own. Assumptions about the bit-lengths of variables are preserved as given by the respective authors, which allows for a correct comparison with each protocol’s stated security parameters.

7.3.1. Computational Overhead Comparison

Table 14 summarizes the computational workload per entity across the five schemes.

Table 14. Computational Overhead Comparison Across Schemes.

Scheme	Tag	Reader	Server
Fan et al. [8]	$4T_{\oplus }+1T_{+}+2T_{Rot}+3T_{PRNG}$	$13T_{\oplus }+1T_{+}+5T_{Rot}+5T_{PRNG}+3T_{ms}+1T_{qr}$	Not reported
SecMAP [10]	$2T_h+1T_{ms}+1T_{PRNG}$	$2T_h+1T_{ms}+1T_{PRNG}$	$4T_h+1T_{PRNG}+2T_{qr}$
Zhou et al. [9]	$3T_{ms}+1T_{nonce}+2T_h$	$3T_{ms}+1T_{nonce}+5T_h$	$6T_{qr}+6T_h$
Xu et al. [11]	$2T_{Eac}+2T_{Rot}$ (bitwise ops ignored)	$1T_{nonce}+5T_h$	$1T_{nonce}+5T_h$
Proposed	$12T_{\oplus }+1T_{Eac}+6T_{PRNG}+1T_h$	$12T_{\oplus }+1T_{\left|\right|}+5T_h+6T_{PRNG}+1T_{ms}$	$27T_{\oplus }+4T_{\left|\right|}+12T_h+12T_{PRNG}+1T_{Eac}+1T_{qr}+2T_{srch}$

Among the five schemes, our proposed protocol requires no modular squaring or quadratic residue extraction on the tag, whereas Zhou et al. [9] requires the tag to perform three modular squaring operations ($3T_{ms}$). This represents a significant structural advantage for the proposed scheme, since modular squaring is one of the most resource-intensive operations available on RFID tag hardware. SecMAP [10] also requires the tag to perform modular squaring ($1T_{ms}$) and two hash operations, imposing a heavier computational burden on the tag than the proposed scheme, which avoids modular arithmetic entirely on the tag side. Fan et al. [8] and Xu et al. [11] keep the tag lightweight with simpler primitives, but both still require the tag to hold large-size secret parameters for their respective security guarantees, as detailed in the storage comparison below.

Cycle-normalized comparison: Symbolic operation counts conflate primitives whose real costs differ by orders of magnitude; a fair efficiency conclusion requires normalization. Table 15 states the per-primitive cycle costs we assume, drawn from published lightweight-cryptography implementation results: bitwise operations and additions at unit cost, rotation and $Eac$ permutations at ≤${10}^2$ cycles, keyed cryptographic $PRNG$ and hash invocations at ≈$1.2\times {10}^3$ cycles each—both execute on the same serialized lightweight engine (PHOTON/SPONGENT class [35,36]; Section 4.2), and we apply the same PRF-grade weighting to every compared scheme that uses $PRNG$ cryptographically—and a 1024-bit modular squaring on tag-class serial hardware at ≈$5\times {10}^5$ cycles. Applying these weights to the tag column of Table 14 yields the normalized tag-side estimates of Table 16. Three conclusions follow. First, the schemes that place modular squaring on the tag (SecMAP [10] and Zhou et al. [9]) are dominated by that single primitive and land roughly two orders of magnitude above the proposed scheme; the structural claim of the paper—keeping modular arithmetic off the tag is what matters—is thus strengthened by normalization. Second, the proposed scheme (≈$8.5\times {10}^3$ cycles) sits in the same order of magnitude as Fan et al. [8] (≈$4\times {10}^3$), the difference reflecting our larger number of keyed evaluations, in exchange for which the proposed scheme provides hash-protected constant-time lookup, 96-bit secrets, and the recovery guarantee of Lemma 1. Third, Xu et al. [11] remain the cheapest in tag cycles (≈$2\times {10}^2$) because their tag performs only unkeyed bit manipulations; the corresponding trade-off appears in the storage comparison in Section 7.3.3. We present these estimates transparently rather than claiming uniform superiority: the proposed scheme’s position is that of the cheapest design that avoids tag-side modular arithmetic while retaining keyed cryptographic protection of the lookup index.

Table 15. Assumed Per-Primitive Cycle Costs (Tag-Class Hardware).

Primitive	Assumed Cycles
$T_{\oplus }$, $T_{+}$	≈1
$T_{Rot}$, $T_{Eac}$	≤${10}^2$
$T_{PRNG}$ (keyed PRF on the shared engine, Section 4.2)	≈$1.2\times {10}^3$
$T_h$ (lightweight, serialized [35,36])	≈$1.2\times {10}^3$
$T_{ms}$ (1024-bit, tag-class)	≈$5\times {10}^5$

Table 16. Normalized Tag-Side Computational Cost (Estimated Cycles, Order of Magnitude).

Scheme	Estimated Tag Cycles
Fan et al. [8]	≈$4\times {10}^3$
SecMAP [10]	≈$5\times {10}^5$
Zhou et al. [9]	≈$1.5\times {10}^6$
Xu et al. [11]	≈$2\times {10}^2$
Proposed	≈$8.5\times {10}^3$

Estimates obtained by applying the weights of Table 15 to the tag columns of Table 14; intended as order-of-magnitude normalization, not as measured figures.

7.3.2. Communication Overhead Comparison

Table 17 presents the total communication overhead per entity, derived from each protocol’s transmitted message sequence. For each scheme, the bit-length assumptions stated by the scheme’s own authors are applied.

Table 17. Communication Overhead Comparison (bits).

Scheme	Tag	Reader	Server	Total
Fan et al. [8] †	288	960	1248	2496
SecMAP [10] †	1120	2528	288	3936
Zhou et al. [9] *	3072	6784	480	10336
Xu et al. [11] †	1152	2856	1344	5352
Proposed	288	2080	288	2656

All values follow a uniform channel-traffic convention: each network hop is counted once at the sender, with forwarded values counted at every hop they traverse. Link-layer framing is excluded here; every scheme incurs identical per-message framing on the same link types (see Table 11), so rankings are unchanged under framed accounting. * Zhou et al. [9] does not report communication overhead; the values above are derived from their protocol description using their modular squaring output size ($n=1024$ bits). ^† Fan et al. [8], SecMAP [10], and Xu et al. [11] originally tabulate per-entity overhead excluding some or all forwarded values; their reported totals are 2272, 3648, and 3240 bits respectively. The values above re-derive their communication overhead under the channel-traffic convention used uniformly across this table.

On tag-side communication—the most critical metric for energy-constrained tags—the proposed scheme transmits only 288 bits, matching Fan et al. [8] (288 bits) while reducing tag-side overhead by 74.3% versus SecMAP [10] (1120 bits), 75% versus Xu et al. [11] (1152 bits), and 90.6% versus Zhou et al. [9] (3072 bits). On server-side communication, the proposed scheme ties with SecMAP [10] at 288 bits—the lowest of all five schemes—and reduces the server-side load by 77% versus Fan et al. [8] (1248 bits), 40% versus Zhou et al. [9] (480 bits), and 78.6% versus Xu et al. [11] (1344 bits). In aggregate, the proposed scheme’s channel traffic of 2656 bits is the second lowest after Fan et al. [8] (2496 bits) and is 32.5% below SecMAP [10] (3936 bits), 50% below Xu et al. [11] (5352 bits), and 74% below Zhou et al. [9] (10336 bits).

7.3.3. Storage Overhead Comparison

Table 18 compares the persistent storage required by each entity across the five schemes.

Table 18. Storage Overhead Comparison (bits).

Scheme	Tag	Reader
Fan et al. [8]	1120	3168
SecMAP [10]	2048	2048
Zhou et al. [9]	1216	1536
Xu et al. [11]	1152	1152
Proposed	192	352

The proposed scheme achieves the lowest tag storage (192 bits) and reader storage (352 bits) among all five schemes. The reason is structural: Fan et al. [8] explicitly require the tag’s secret x to be at least 1024 bits because $x^2\mathrm{mod}n$ is stored on the server; SecMAP [10] requires the tag to store both a 1024-bit identifier and the 1024-bit public key n for local modular squaring; Zhou et al. [9] require the tag to hold the modulus n (1024 bits) to perform modular squaring locally; and Xu et al. [11] use a 1024-bit secret key $ke{y}_t$ on the tag. In contrast, the proposed scheme never subjects the tag’s secret t to modular operations, allowing the use of much shorter secrets (96 bits) while maintaining strong security through PRNG, Eac, and hash operations. Beyond these mutable credentials, the fixed firmware/logic footprint of each scheme’s tag-side primitive set is discussed in Section 7.2 (Table 13); the proposed scheme’s incremental footprint (≈1–2 kGE) is at or below that of the compared hash-based schemes and far below the modular-multiplier requirement of [9,10].

7.4. Hardware Feasibility on EPC Gen2v2 Tags

Academic RFID security literature has often been criticized for assuming tag capabilities that commercial hardware does not provide, and we address this gap between academic security literature and real-world hardware production explicitly. Off-the-shelf baseline passive EPC Gen2 tags provide only bitwise operations and the mandated 16-bit PRNG; they cannot execute a hash function, and the proposed protocol is accordingly not targeted at them. The target platform of this work, stated in the assumptions of Section 5, is the crypto-enabled EPC Gen2v2 tag class [30]: commercially available passive tags that extend the baseline command set with cryptographic-suite support and on-die cryptographic engines (typically AES-128), introduced precisely to host authentication protocols on passive tags.

Primitive-by-primitive feasibility: On this platform, each tag-side primitive of the proposed protocol is implementable as summarized in Table 13: XOR is native logic—at roughly 2 GE per bit, and under 50 GE in total on the 8- or 16-bit serial datapath of passive-tag logic, it is under 3% of the cryptographic engine and in practice folds into the existing datapath at no marginal area; $Eac$ is a data-independent bit-permutation—its operand selection is positional (the latter half of X with the first half of Y, Section 4), and the subsequent cross-exchange is fixed, so no multiplexer network is required, and its ASIC cost is routing rather than logic; and both keyed primitives—the hash $h(·)$ and the keyed $PRNG(·)$ (Section 4.2)—execute on a single shared cryptographic engine, realized either as a dedicated lightweight hash core (PHOTON [35] or SPONGENT [36], approximately 1000–2000 GE—a small fraction of the digital gate budget of crypto-enabled tags) or, at essentially zero additional area, by AES-based constructions [37] reusing the AES-128 engine that Gen2v2 crypto tags already ship. The specification-mandated 16-bit generator remains present for air-interface randomness but is deliberately not used as the protocol’s keyed $PRNG(·)$, avoiding any conflation of statistical and cryptographic randomness.

Timing and energy: The normalized workload of Table 16 places the complete tag-side computation at approximately $8.5\times {10}^3$ cycles per session (seven keyed evaluations on the shared engine, plus permutations and bitwise logic). At the 1–2 MHz clock rates typical of passive-tag digital logic, this corresponds to roughly 4–9 ms of computation per session; moreover, the pipelining remark of Step 3 moves the two pre-computable evaluations ($M_1^T$, $M_2^T$, $\approx 2.4\times {10}^3$ cycles) into the power-up interval, leaving approximately $6\times {10}^3$ cycles (≈3–6 ms) on the interactive path. Published energy figures for lightweight hash and AES cores on passive-tag processes place per-invocation energy in the nanojoule-to-sub-microjoule range, so the full per-session tag energy budget is on the order of 0.1–1 μJ—within the harvested-energy envelope reported for crypto-enabled passive tags. We state explicitly that these are literature-based estimates rather than measurements on physical tags; measurement on commercial Gen2v2 hardware is declared as future work in Section 8.

Energy delivery and air-interface timing: A passive tag harvests all of its energy from the reader’s field, which raises the question of whether the reader can power a multi-millisecond computation and whether the air-interface timing tolerates it. Two properties of the Gen2 air interface resolve both concerns for the target class. First, during an interrogation, the reader does not fall silent in the RF sense: after issuing a command, it continues emitting an unmodulated continuous wave from which the tag harvests power while computing, so energy delivery is not confined to the command transmission itself. Second, the Gen2v2 revision introduced mechanisms designed precisely for cryptographic computations that exceed the standard reply window: in-process/delayed reply handling and extended temporary memory allow a tag to signal that a cryptographic result is pending and deliver it within the protocol’s timing rules [30]. Commercial crypto tags additionally integrate on-die storage capacitance that buffers harvested energy across the computation. Finally, the protocol itself shortens the timing-critical path: as noted in Step 3 of Section 5.2, $M_1^T$ and $M_2^T$ depend only on the values received in Step 2 and can be computed during the tag’s power-up interval, before its response slot, leaving only $M_3^T$, $M_4^T$ (Step 3) and the update chain (Step 11) on the interactive path.

8. Conclusions

In this paper, we proposed a fast and secure mutual authentication protocol for lightweight mobile RFID systems based on quadratic residue theory, where the server is designed to do most heavy operations including quadratic residue root extraction and index-table maintenance. The tag performs only lightweight primitives (XOR, PRNG, Eac and single hash) avoiding heavy modular arithmetic, and the target platform—passive, crypto-enabled EPC Gen2v2 class tags—is justified primitive-by-primitive in a dedicated hardware feasibility analysis covering gate counts, cycle counts, per-session energy, and the energy-delivery timing of the air interface. The protocol also enables graceful recovery from desynchronization through a dual-entry index-table design at the server, with a provable one-update-behind guarantee, and protects session freshness via nonces and timestamps.

The informal analysis showed that the protocol resists replay, impersonation, MITM, desynchronization, eavesdropping, tracking, cloning, DoS, and secret-disclosure attacks, while also providing mutual authentication, forward secrecy, and resistance to mobile reader capture with constant-time revocation; these arguments are made quantitative through reduction-based theorems in the random-oracle/PRF model and are further validated using the Scyther and ProVerif verification tools; a Tamarin model that treats the exclusive-or operation natively is additionally provided and is accepted with no well-formedness violations, with a fully terminating mechanized XOR proof left as future work. Tag unlinkability across completed sessions is proven in the Juels–Weis privacy model, and the bounded tracking window that arises under sustained active blocking of key updates is stated explicitly. The performance analysis showed that under a uniform channel-traffic convention (each network hop counted once at the sender), the proposed scheme reduces tag-side storage by approximately 83–91% compared to representative recent schemes [8,9,10,11], matches Fan et al. [8] on tag-side communication (288 bits), and reduces tag-side communication by 74–91% versus SecMAP [10], Xu et al. [11], and Zhou et al. [9]. Compared to the same representative schemes, the proposed scheme also achieves the lowest server-side overhead (288 bits, tied with SecMAP [10]). Its aggregate channel traffic (2656 bits) is 32.5% below SecMAP [10] (3936 bits), 50% below Xu et al. [11] (5352 bits), and 74% below Zhou et al. [9] (10336 bits), sitting only marginally above Fan et al. [8] (2496 bits). Under the cycle-normalized accounting introduced in this revision, the structural claim is sharpened: the compared quadratic-residue schemes are dominated by tag-side modular squaring and land roughly two orders of magnitude above the proposed scheme in tag cycles, while the proposed scheme remains in the same order of magnitude as the lightest hash-free designs, positioning it as the cheapest design that avoids tag-side modular arithmetic while retaining keyed cryptographic protection of the lookup index. These gains stem from a structural advantage: the tag’s secret is never subjected to modular operations, allowing the use of much shorter secret parameters (96 bits) without compromising security, and the protocol concentrates communication overhead on the high-bandwidth reader-to-server link rather than the energy-constrained tag-to-reader link.

For future work, we plan to implement the protocol on actual crypto-enabled EPC Gen2v2 tag hardware to measure execution time and per-session energy consumption, validating the literature-based estimates of Section 7.4. Three further directions follow from the limitations we have stated explicitly in this paper: introducing tag-side entropy into the key-update chain to obtain post-compromise security and quantifying the resulting cost to the constant-time lookup property (Section 6.1); mechanizing the dual-entry update state machine in a stateful verification framework, so that the cross-epoch properties currently established by Lemma 1 and Theorem 4 are also tool-checked (Section 6.5); and specifying and analyzing a randomized-response fallback that caps the residual tracking window of Section 6.6. Finally, we want to make the scheme stronger against quantum computers by looking into lattice-based alternatives to the quadratic residue construction.