Cryptanalysis of two mutual authentication protocols for low-cost RFID
Radio Frequency Identification (RFID) is appearing as a favorite technology for automated identification, which can be widely applied to many applications such as e-passport, supply chain management and ticketing. However, researchers have found many security and privacy problems along RFID technology. In recent years, many researchers are interested in RFID authentication protocols and their security flaws. In this paper, we analyze two of the newest RFID authentication protocols which proposed by Fu et al. and Li et al. from several security viewpoints. We present different attacks such as desynchronization attack and privacy analysis over these protocols.
💡 Research Summary
This paper conducts a thorough cryptographic analysis of two recent low‑cost RFID mutual authentication protocols: the FWCFP protocol proposed by Fu et al. and the LWJX protocol proposed by Li et al. After a brief overview of RFID architecture, the authors describe the standard threat model for RFID (tag/reader impersonation, man‑in‑the‑middle, tracing, and desynchronization) and adopt a formal privacy framework that defines Execute, Send, Corrupt, and Test queries for an adversary.
The FWCFP protocol works as follows: the reader sends a random number rand1, the tag replies with its current alias IDTA, a hash H(K‖rand1) and a new random rand2. The reader decrypts IDTA to obtain the permanent identifier IDT, retrieves the shared secret key K, and verifies the hash. If verification succeeds, the reader generates a fresh random rand3, computes two values A = IDTA ⊕ H(K‖rand1‖rand2) and B = IDTA ⊕ H(K‖rand2‖rand1), and sends H(K‖rand2), A, and B to the tag. The tag authenticates the reader by checking H(K‖rand2), then recomputes IDTA1 = A ⊕ H(K‖rand1‖rand2) and IDTA2 = B ⊕ H(K‖rand2‖rand1). If the two results match, the tag updates its stored alias to IDTA1 and acknowledges the reader.
The authors identify three critical weaknesses in FWCFP. First, a desynchronization attack: an active adversary can intercept the third message, replace A and B with arbitrary values A′ and B′, and forward them to the tag. Because the hash H(K‖rand2) still verifies, the tag accepts the forged values, computes a new alias IDTA′ = IDTA ⊕ Δ (where Δ is the attacker‑chosen difference), and stores it. The reader, however, still expects the original alias and therefore fails to locate the tag in its database, leading to a permanent loss of synchronization with no recovery mechanism. Second, a traceability attack: the hash H(K‖rand2) appears in both the second and third flows of the protocol. By eavesdropping a legitimate session (Execute query) and later sending the same rand2 to a target tag (Send query), the adversary can compare the returned hash with the previously recorded one. Equality reveals that the same tag is involved, breaking untraceability. Third, a backward‑untraceability attack: after corrupting a tag at time t1 (Corrupt query) and obtaining its secret K, the adversary can recompute H(K‖rand1) for a prior session at time t0 < t1 (Execute query). Matching hashes allow the adversary to link past communications to the compromised tag, violating the backward‑untraceability property.
For the LWJX protocol, the analysis is simpler but equally damning. The protocol also relies on a single hash H(K‖rand) transmitted by the tag. Because the same random value can be replayed, an adversary can again use Execute and Send queries to obtain identical hash outputs from the same tag, thereby achieving traceability. The authors argue that the protocol’s claim of privacy is therefore unfounded.
Based on these findings, the paper proposes concrete countermeasures. To prevent desynchronization, the authors suggest using a cryptographically strong combination (e.g., HMAC) of the alias and a fresh nonce rather than a simple XOR, and to include a recovery phase that allows the reader and tag to renegotiate a common state after a failure. To mitigate traceability, they recommend ensuring that each round uses a distinct hash input (e.g., incorporating both nonces and a session counter) so that the same hash value cannot be reproduced. For backward‑untraceability, they advise that long‑term keys should be refreshed periodically and that the protocol should be formally verified against the privacy model before deployment.
In conclusion, the paper demonstrates that lightweight RFID authentication schemes that rely solely on XOR, hash, and symmetric encryption are vulnerable to practical attacks when state synchronization and hash reuse are not carefully handled. The authors emphasize the necessity of rigorous formal analysis and the inclusion of robust state‑management mechanisms to achieve true mutual authentication and privacy in low‑cost RFID environments.
Comments & Academic Discussion
Loading comments...
Leave a Comment