Securing IoT-Based RFID Systems: A Robust Authentication Protocol Using Symmetric Cryptography

Despite the many conveniences of Radio Frequency Identification (RFID) systems, the underlying open architecture for communication between the RFID devices may lead to various security threats. Recently, many solutions were proposed to secure RFID systems and many such systems are based on only lightweight primitives, including symmetric encryption, hash functions, and exclusive OR operation. Many solutions based on only lightweight primitives were proved insecure, whereas, due to resource-constrained nature of RFID devices, the public key-based cryptographic solutions are unenviable for RFID systems. Very recently, Gope and Hwang proposed an authentication protocol for RFID systems based on only lightweight primitives and claimed their protocol can withstand all known attacks. However, as per the analysis in this article, their protocol is infeasible and is vulnerable to collision, denial-of-service (DoS), and stolen verifier attacks. This article then presents an improved realistic and lightweight authentication protocol to ensure protection against known attacks. The security of the proposed protocol is formally analyzed using Burrows Abadi-Needham (BAN) logic and under the attack model of automated security verification tool ProVerif. Moreover, the security features are also well analyzed, although informally. The proposed protocol outperforms the competing protocols in terms of security.


Introduction
Since its inception, the Internet of Things (IoT) is an emerging idea and is defined as, "A system of interrelated computing devices, mechanical and digital machines, objects, animals, or people that are provided with unique identifiers (UIDs) and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction" [1]. The devices are equipped with RFID is simplest form of pervasive sensor networks and is commonly used for identification of physical objects [4,5]. Systems based on RFID consist of a tag, which is equipped with a transceiver to send and receive radio signals from connected devices [6,7]. The RFID Reader is the other device which acts as an access point and can receive and send messages to transceivers. The Reader is also responsible for the availability of tag information at application level [8][9][10]. RFID tags can be passive, as well as active. Table 1 summarizes the features of passive and active tags. RFID systems are typically used for object tracking and identification purposes. The system application accessed through Reader can perform data processing for onward usage in a range of applications like: Asset Tracking, Race Timing, E-Passport, Transportation, Payments, Human Implants, Supply-Chain-Management, Fleet and Asset-Management, Security Access-Control, E-Commerce, and Traffic Analysis and Management [9,[11][12][13][14]. The IoT-enabled RFID system facilitates all such systems without any physical exposure and in bulk. However, such facilities come with security threats because of the underlying wireless media used for the communication between the tag and the Reader [15][16][17].
To make an RFID system acceptable and meet industrial standards, the following security features should be considered during the design phase of RFID security schemes: 3. The scheme should prevent insider attacks and replay attacks. 4. The system should have capabilities to withstand impersonation and forgery attacks. 5. The system should provide mutual authentication and thwart man in middle attack. 6. The system should be user-friendly and should have the provision of updation and alteration of tag data at any time.
In 2005, Yang et al. proposed an RFID authentication protocol based on only exclusive-OR (XOR) and hash functions [23]. Some other protocols were also proposed in [21,26,30], using only lightweight hash, XOR and/or symmetric encryption. Despite their [21,23,26,30] claims to provide flawless security, Piramuthu [28] proved that the protocols in [23,30] are vulnerable to replay attack, the protocol in [26] is vulnerable to impersonation of the tag and the Reader, and protocol proposed by Cai et al. [30] is vulnerable to denial-of-service (DoS) and impersonation of tag. Cho et al. [31] then proposed another hash-based protocol for securing RFID. However, Safkhani et al. [29], through cryptanalysis, proved that Cho et al.'s protocol is insecure against DoS, as well as impersonation attacks. Another authentication protocol for securing RFID systems using only symmetric key operations was proposed by Ayaz et al. [17]. However, in their protocol [17], the authentication is performed on the basis of biometrics verification. Such biometric verification may not be desirable in many scenarios, like anti-counterfeiting of life saving drugs, recording and counting number of specific goods moving in and out of a store, etc.

Motivations and Contributions
Quite recently, Gope and Hwang [3] argued that the existing protocols [21,23,26,[29][30][31] based on hash functions are impractical. Then Gope and Hwang presented a new lightweight authentication protocol using only hash functions. They claimed to avoid all known attacks while maintaining efficiency. However, in this paper, we show that the protocol of Gope and Hwang is vulnerable to collision, DoS, and stolen verifier attacks. Moreover, this article presents an improved and robust protocol using only lightweight symmetric cryptography primitives for IoT-based RFID systems to resist all known attacks. The general contributions of this article include: • Cryptanalysis of the baseline [3] protocol. • Proposed an improved authentication protocol using only lightweight symmetric key primitives to overcome the security issues of the baseline protocol. • Performed formal and informally security analysis of the proposed protocol. • Solicited the comparison of the proposed protocol with related existing protocols with respect to security features. • Accomplished the comparison of the proposed protocol with related existing protocols with respect to performance, including communication, as well as computation complexity.

Adversarial Model
The proposed protocol is designed keeping in mind the following adversarial model where common assumptions as pointed out in [34] are made. The following assumptions are considered as the capabilities of the adversary A.
1. The public channel is under full control of A, so that the A can intercept, revert, modify, replay, or even send a fresh fabricated message. 2. A has the capability to extract some of the information of the tag by power analysis. However, shared key of the tag and Server is secret and is inaccessible to any adversary.

3.
A can be any deceitful tag or an outsider of the system. 4. The database attached to the Server is inaccessible, and no adversary A can access the private key of the Server.

Road Map
The rest of the article is organized in various sections. In Section 1.4, a brief overview of the protocol of Gope and Hwang [3] is presented. Section 2 presents the proposed protocol, whereas Section 3 presents the detail security analysis of the proposed protocol. Section 4 presents the comparative analysis of the proposed protocol with existing protocols, and, finally, Section 5 concludes the article.

Review of Baseline Protocol
This section first reviews the baseline protocol of Gope and Hwang's [3] and then performs its cryptanalysis. Table 2 presents some of the notations used in the baseline protocol. The proposed protocol designed for RFID consists three main entities: (1) Database Server, (2) Reader Device, and, (3) RFID tags. The network layout of the RFID System divided into several RFID clusters. Every cluster consists of a Reader and many tags. Tags can shift from one cluster to another. Every Reader of the cluster authenticates the registered tags through the Database Server. Each Reader and Database Server share a symmetric key K rs [3]. Gope and Hwang's [3] authentication scheme consists of two main phases: (1) tag Registration Phase and (2) tag Authentication Phase.

Baseline Protocol Tag Registration Phase
The following steps, as shown in Figure 2, are performed for tag registration: Step BLR 1: tag i ID T i −→ S Each tag (tag i ) submits ID T i to the Server S.
Step BLR 2: S M −→ tag i : M = {K ts , (SID, K emg ), Tr seq , h(.)} S generates random number n s and computes K ts = h(ID T i n s ⊕ ID s ). S then generates a set of unlikeable shadow identities ID s , and SID = {sid 1 , sid 2 · · · }, where the sid j ∈ SID. S computes sid j = h(ID T i r j K ts ). Further, S generates a set of emergency keys K emg = {k emg 1 , k emg 2 · · · }, each of the keys corresponding to specific sid j ∈ SID, where each k emg i ∈ K emg . S then computes k emg i = h(ID T i sid j r j ). Then S generates a 32-bit random sequence number Tr seq and random number m and matches it with Tr seq , Tr seq = m. S then sends the Tr seq to the tag i through Reader R i by maintaining the copy of Tr seq in its database for speeding up the authentication process. S authenticates the validity of RFID tag ID T i based on TR seq . If TR seq does not have a match within the record of S, it terminates the process. In this case, the RFID tag ID T i will use one of its fresh pair of the emergency key k emg j ∈ K emg and shadow ID sid j ∈ SID. The used pair of shadow ID and emergency ID (SID, K emg ) must be deleted from both, the Database Server S and the RFID tag ID t i . Database Server S again updates and send {K ts , (SID, K emg ), Tr seq , h(.)} through a secure channel for further communication.
Step BLR 3: tag i , upon receiving message from S, stores {ID T i , K ts , (SID, K emg ), Tr seq , h(.)} in its memory.

Baseline Protocol Tag Authentication Phase
The registered tag initiates the authentication process, as shown in Figure 3, and is detailed as follows: Step BLA 1: tag i M A 1 −→ R i : M A 1 = {AID T , N x , Tr seq , V 1 } tag i with identifier ID T i generates random number N t , and derives AID T = h(ID T i K ts N t Tr seq ), N x = K ts ⊕ N t . The tag then computes V 1 = h(AID ti K ts N x R i ) and sends message request as M A 1 to the Reader device R i . R i also receives a recently used sequence number from S for mutual authentication. In the case of synchronization loss, the tag uses one of its fresh pair (sid j , K emg j ). Subsequently, it is assigned to the sid j as AID T and then k emg j as K ts . tag i sends M A 1 to the Reader R i .
Step BLA 2: R i Upon receiving request from tag i , Reader R i of the i th cluster (in which tag i is located) generates random number N r and computes N y = K rs ⊕ N r , V 2 = h(M A 1 N r K rs ). R i then sends M A 2 to S for verification.
Step BLA 3: S When S receives a request from R i , first it validates the track sequence number Tr seq by computing V 1 = h(AID T K ts N x R i ). S then derives N t = K ts ⊕ N x and verifies AID T . Upon successful verification of AID T , S generates a random number m and assigns it to T r seq = m. S also computes T r = h(K ts ID T i N t ) ⊕ T r seq , V 4 = h(T r K ts ID T i N t ), V 3 = h(R i N r K rs ) to create a message M A 3 and the S sends M A 3 to R i . Finally, S computes K Ts new = h(K ts ID T i Tr seq new ) and updates K Ts new and Tr seq new . In case the message M A 1 does not contain T r seq , then S randomly generates a new shared key K TS new using the emergency key K emg j and real identity of the tag ID T i . Then x = K ts new ⊕ h(ID T i K emg j ) is computed and x is sent with the message M A 3 , where V 4 is calculated as V 4 = h(N t T r x K emg j ).
Step BLA 4: R i 3 and computes h(R i N r K rs ), and validates if it is equal to V 3 . Upon successful validation, R i sends M A 4 to tag i . Contrarily, the Reader R i terminates the session.
Step BLA 5: tag i , on receiving M A 4 , computes h(Tr K ts ID T i N t ) and verifies its equality with V 4 .
Upon success, tag i derives K ts new = h(K ts ID T i Tr seq new ) and stores K ts = K ts new , Tr seq = Tr seq new for future communication.
= h(T r K ts ID Ti N t ) Compute and update: Tr seqnew = h(K ts ID Ti N t ) ⊕ T r K tsnew = h(K ts ID Ti Tr seqnew Tr seq = Tr seqnew , K ts = K tsnew Or

Cryptanalysis of Baseline Protocol
The following subsections show that the baseline protocol is vulnerable to: (1) Collision, (2) Stolen Verifier, and (3) DoS Attacks.

Vulnerable to Collision Attack
The correctness of the baseline protocol [3] depends on Track sequence number Tr seq , generated randomly during registration and saved in the database, as well as in the tag's memory. This number Tr seq is sent in authentication request M A 1 = {AID T , N x , Tr seq , V 1 } by the tag and then, upon reception of M A 1 , the Reader R i sends M A 2 = {M A 1 , N y , R i , V 2 } to the Database Server. S verifies the legitimacy of Tr seq by comparing it with the one stored in its database. The randomness can cause two or more track sequence numbers to have the same value (collision), and there is no mechanism to handle such collisions. Then the process will terminate abnormally, and the legitimate tag will be deprived of its right to authentication and access.

Vulnerable to Stolen Verifier Attack
Considering the common adversarial modal, as mentioned in Section 1.2, an adversary can steal the verifier table stored unencrypted on server. A based on the track sequence number Tr seq and the public request from any of the previous session M A 1 can then generate login request using the previous session's N x , N y and the stolen new Tr seq . The request will pass the authentication test as all values are valid. Hence baseline protocol is also vulnerable to stolen verifier attack.

Vulnerable to DoS Attack
In the baseline proposal [3], an adversary can launch a DoS attack by continuously generating 32 bits random Tr seq numbers and send it to the Database Server. It will keep S busy in verifying dummy random numbers, thus restricting S to serve a legitimate request.

Proposed Scheme
Like the baseline protocol, the proposed protocol for RFID consists of three main entities: (1) Database Server, (2) Reader Device, and (3) RFID tags. The network layout of the RFID System is divided into several RFID clusters. Every cluster consists of a Reader and many tags. Tags can shift from one cluster to another. Every Reader of the cluster authenticates the registered tags through the Database Server. Each Reader and Database Server share a symmetric key K rs . Proposed improved authentication scheme consists of two main phases; (1) tag Registration Phase, (2) tags Authentication Phase.

Tags Registration Phase
The following steps, as shown in Figure 4, are performed for tag registration: Step PTR 1: tag i ID T i −→ S Each tag submits ID T i to the Server S.
Step PTR 2: S M −→ tag i : M = {ID T i , K ts , AID} S generates a random number n s and computes K ts = h(ID T i n s ⊕ ID s ). S generates r i randomly and computes one-time alias tag i 's identity AID = E s x (ID T i r T i ) by encrypting it with the Secret Key s x of S. S authenticates tag i based on AID T in authentication phase by checking if a request is valid or not. S stores and sends M to the RFID tag through a secure channel.
Step PTR 3: Upon receiving the message from S, tag i stores the information M = {ID T i , K ts , AID} in its memory.

Tags Authentication Phase
The registered tag initiates the authentication process, as shown in Figure 5, and is detailed as follows: Step PTA 1: tag i The tag then initiates an authentication request request by sending M A 1 to R i .
Step PTA 2: R i Upon receiving the request from the tag, Reader R i of the i th cluster (in which tag is located) first verifies the timestamp freshness as (T 2 − T 1 ) ≤ ∆T. R i generates a random number N r and computes Step PTA 3: S Step PTA 4: R i and verifies its equality with the received V 3 . Upon success, R i sends M A 4 to tag i . Otherwise, R i terminates the session.
Step PTA 5: Upon receiving M A 4 , tag i first checks freshness of the timestamp and upon success verifies the message V4 * ?
= h(K ts ID T i N t ). Then tag i computes and updates AID T i (new) = (Z T ⊕ K Ts ), AID T i = AID T i (new) and saves the information for the next authentication process.

Security Analysis
In this section, the security analysis of the proposed protocol under the adversarial model briefed in Section 1.2 is performed. The task is accomplished by formal analysis under Burrows Abadi-Needham (BAN) logic, and informal security features are explained. Moreover, the robustness of the proposed protocol is also analyzed through the automated tool, ProVerif-a widely accepted simulation tool for verification of the security of authentication protocols [35][36][37][38][39][40][41][42][43].

BAN Logic-Based Formal Security Analysis
BAN logic consists of a set of rules that can be used to analyzed information exchange protocols. It specifically determines if the information exchanged in a protocol is resistant against eavesdropping and is trustworthy and secured. The mutual authentication of the proposed protocol has been checked using the BAN logic [44]. Different rules of BAN logic, including idealized form, assumptions, and proofs, are shown in Table 3. Table 3. BAN logic Notations.

Notations Description
P| ≡ X P believes that X P X P sees that X P| ∼ X P once said X P ⇒ X P have total jurisdiction on X #(X) X is updated and fresh Hash of message X using a key K To analyze the security of a protocol using BAN logic, different goals have to be determined. In the case of the proposed protocol, eight different goals have been determined based on BAN logic. These goals are shown in the following list.
To achieve the goals listed above, the security analysis using BAN logic has been divided into three parts. Part1 shows the idealized form of the protocol and is proved in Part3, whereas Part2 uses assumptions to analyzed the proposed protocol.

Part2:
The assumptions used for analyzing the proposed protocol using BAN logic are shown below: Part 3: Analysis of Idealized form of the proposed protocol that has been derived on the basis of BAN logic assumptions and rules is described as follows: M1: tag →Ri: AIDT i ,N x :< N t > K ts , T1 is time-stamp of tag. Using the seeing rule, the following can be achieved: • S1: R i AIDT i , SID, N x :< N t > K ts , T1.
According to the message-meaning rule and S1, the following can be obtained: Using the freshness-conjuncatenation rule and S2 will achieve the following: Using the jurisdiction rule and S3, the following can be achieved: Using S4 and the session key rule, the following can be achieved: Using the nonce-verification rule, the following is obtained: M2: R i → S j : M1, N y :< N r > K rs , T2, V2, whereas T2 is time-stamp of R i . By using the seeing rule, we achieve: • S7: S j M1, N y :< N r > K rs , T2, V2.
By the message-meaning rule and S7, the following can be achieved: By the freshness-conjuncatenation rule and S8, the following can be computed: By applying the jurisdiction rule and S9, the following can be obtained: • S10: S j | ≡ N r .
Using the S10 and the SK rule, the following can achieved: Using the nonce-verification rule and S11, the following can be achieved: M3: S j →Ri: V3, V4, Zt < AIDT i new > * K ts , T3,T3 is time-stamp of S j . By the seeing-rule, the following can be achieved: By the message-meaning rule and S13, the following can be obtained: By S14 and the freshness-conjuncatenation rule, the following can achieved: • S15: By the assumption S15 and jurisdiction rule, the following can be achieved: • S16: R i | ≡ AIDT i new .
Using S16 and the session-key rule, the following can be achieved:
Using the message-meaning rule and S19, the following is achieved: Using S20 and the freshness-conjuncatenation rule, the following can be obtained: Using the jurisdiction rule and S21, the following can be achieved: Using the session-key rule, the following can be obtained: Finally, using the nonce-verification rule, the following can be achieved, which is also the final goal of the proposed protocol: Consequently, using the BAN logic, it has been shown that tag, R i , and S j achieve mutual authentication successfully and securely attain the session key agreement.

Security Analysis with ProVerif
Based on applied π calculus, ProVerif uses automated reasoning to test the security features of authentication protocols. Specifically, ProVerif can verify the reachability, correspondence, and observational equivalence, as well as secrecy properties. ProVerif supports primitive cryptographic operations [45], including MAC, digital signatures, encryption/decryption, elliptic curve operations, hash, and other functions [46]. The steps of the proposed scheme, as illustrated in Section 2 and shown in Figures 4 and 5, are simulated in ProVerif. The formal security validation model of ProVerif consists of three phases: (1) Declaration, as coded in Figure 6A, declares the constants, names, variablesm, and cryptographic function, (2) Process part, as shown in Figure 6B, defines the three processes, each for tag, Reader, and Server, and (3) Main, as implemented in Figure 6C, simulates the actual protocol.
( * s e c u r e c h a n n e l * ) f r e e ChPub : c h a n n e l .
( * p u b l i c c h a n n e l * ) ( * ======= C o n s t a n t s and V a r i a b l e s ======= * ) f r e e IDTi : b i t s t r i n g . ( * * * * * * * * * * * * * * * * * * * P r o c e s s e s * * * * * * * * * * * * * * * * * * * ) ( * ================RFID Tag=============== * ) ( * ======= R e g i s t r a t i o n ======= * ) l e t pTag= o u t ( ChSec , ( IDTi ) ) ; i n ( ChSec , ( IDTi : b i t s t r i n g , Kts : b i t s t r i n g , AIDTi : b i t s t r i n g ) ) ; ( * ==========Tag l o g i n========= * ) e v e n t s t a r t T a g ( IDTi ) ; new Nt : b i t s t r i n g ; new T1 : b i t s t r i n g ; l e t Nx=XOR( Kts , Nt ) i n l e t V1=h ( Concat ( AIDTi , ( Kts , Nx , Ri ) ) ) i n o u t ( ChPub , ( AIDTi , Nx , V1 , T1 ) ) ; i n ( ChPub , ( V4 : b i t s t r i n g , T4 : b i t s t r i n g , Zt : b i t s t r i n g ) ) ; l e t V4=h ( Concat ( Kts , ( IDTi , Nt ) ) ) i n i f V4=h ( Concat ( Kts , ( IDTi , Nt )  ( * * * * * * * * * * * * * * * * * * * * E v e n t s * * * * * * * * * * * * * * * * * * * * ) e v e n t s t a r t T a g ( b i t s t r i n g ) . e v e n t e nd Ta g ( b i t s t r i n g ) . e v e n t s t a r t R ( b i t s t r i n g ) . e v e n t end R ( b i t s t r i n g ) . e v e n t s t a r t S ( b i t s t r i n g ) . e v e n t e n d S ( b i t s t r i n g ) . ( * * * * * * * * * * * P r o c e s s R e p l i c a t i o n * * * * * * * * * * * * * * * * ) p r o c e s s ( ( ! pS ) | ( ! pR ) | ( ! pTag ) ) ( * * * * * * * * * * * * * * * * * * * Q u e r i e s * * * * * * * * * * * * * * * * * * * * ) f r e e AIDTinew : b i t s t r i n g [ p r i v a t e ] . q u e r y a t t a c k e r ( AIDTinew ) . q u e r y i d : b i t s t r i n g ; i n j e v e n t ( end T ag ( IDTi ) ) ==> i n j e v e n t ( s t a r t T a g ( IDTi ) ) . q u e r y i d : b i t s t r i n g ; i n j e v e n t ( end R ( Ri ) ) ==> i n j e v e n t ( s t a r t R ( Ri ) ) . q u e r y i d : b i t s t r i n g ; i n j e v e n t ( e n d S ( I D s ) ) ==> i n j e v e n t ( s t a r t S ( I D s ) ) . Simulation of three processes executed in parallel is performed, along with six events to validate the reachability properties of three processes. Finally, four queries are implemented. The results are shown in Figure 6D. Based on the above description of results 1, 2, and 3, all three original processes of the proposed protocol successfully started and terminated. Result 4 shows that the session tag identity AID T i is safe from any adversary attack. Therefore, the proposed protocol possesses correctness and provides tag secrecy.

Informal Security Analysis
The proposed protocol for RFID System is analyzed for security loopholes against the known attacks in the following subsections.

Mutual Authentication Between Tag And Server
The RFID Server authenticates RFID tag by verifying a one time alias AID T i and V 1 = h(ID T ||K ts ||N||R i ) in the message M 1 . Only a legitimate RFID tag can form a valid request message M 1 , including both these parameters, as valid AID T i is only known to legal tag; moreover, ID T , K ts are known to the legal tag only. On other side, the RFID tag can authenticate the legitimacy of the Server using parameters V 4 and message M 3 in M 4 . This way, the proposed protocol achieves mutual authentication property.

Anonymity
One of the basic principles of security is that an authentication protocol must not reveal the identity information of any participant (user or device) to an adversary. Anonymity is an essential factor of a secure protocol. A secure scheme guards the personal information of a user so that an adversary or intruder cannot access any information that may lead to a security breach of the system. In the proposed protocol, strong anonymity has been achieved. In the registration phase, the RFID tag registered itself with the Server S through RFID-Reader using a secure channel, M = {ID T i , K ts , AID}.
In the login and authentication phase of the proposed protocol, message M A 1 = {AID T i , N x , V 1 , T 1 } has been sent to the Server S using public channel. Here, if an adversary gets the message M 1 , the adversary still cannot know the identity of the RFID tag because AID T i is a one-time alias identity of the tag. The original identity is kept encrypted in AID T i and can only be decrypted by the Server using a shared secret Key K ts . Thus, an adversary cannot reveal the RFID tag's actual identity, hence achieving anonymity for the proposed protocol.

Traceability
A genuinely secure protocol must not reveal any identifying information of the participants to an illegitimate user. The identifying information may lead to the traceability of the RFID tag. The proposed protocol does not reveal any login information of the current of or any previous sessions that lead to a security attack on the RFID system. It is achieved through the use of different random numbers at different levels, like N t , N r , r i . Furthermore, a new one-time-alias identity for the RFID tag AID Ti has been use, making it impossible for an adversary to guess any random number and launch an attack on the RFID system. Consequently, it can be been claimed that the proposed protocol makes the RFID tag untraceable.

Backward/Forward Secrecy
It is essential for security protocols that the information transmitted in a session is not compromised, as well as traced or used by an adversary to create vulnerabilities in the current, previous, or future authentication session between the RFID tag and RFID Server S. In the proposed protocol, even if the identity ID T or alias identity are lost, it does not affect previous or next sessions. It is ensured through the use of encrypted AID Ti , which is updated in every new session. In this way, the proposed protocol for the RFID System guarantees backward and forward secrecy.

Scalability
In the proposed protocol for the RFID System, the RFID Server S does not perform an exhaustive process to authenticate any RFID-tag. Instead, the RFID-Server S processes AID Ti to validate the RFID tag and responds quickly to the RFID tag. This makes the proposed protocol more scalable.

Collision Attack
If RFID-tags share the same credentials for authentication to access the RFID Server, the protocol may be left vulnerable to a collision attack. In the proposed protocol, every RFID tag uses different parameters, i.e., {N y , R i , V 2 , M A 1 }, for authentication that makes it impossible for collision attack to take place.

DoS Attack
The protocol is not based on any random key that is responsible for authentication or verification of the RFID tag; rather, it is based on AID Ti that is well encrypted and updated for every transaction. Therefore, the proposed scheme resists any DoS attack.

Replay Attacks
In a replay attack, the attacker may delay or repeat the transmitted information for authentication with the Server S. The proposed protocol for RFID systems has three participants: tag, Reader, and Server. For authentication, four messages are exchanged, i.e, {M 1 , M 2 , M 3 , M 4 }, using a public channel. Having access to the messages, an adversary A may attempt to launch a replay attack. However, this attempt will fail as every message is sent with a fresh time-stamp T. In case the time-stamp is invalid, the adversary A request will be rejected each time. Furthermore, if an adversary A cannot compute other parameters of the message, the adversary still cannot launch the attack as all message parameters are updated for every new session by the participants of RFID System. Therefore, the proposed protocol for RFID systems is resistant to replay attack.

Location Tracking Attack
As the real identity of the RFID tag is not sent directly in the message for authentication between the RFID-tag and Server S, it has been sent in an encrypted form that only the Server can decrypt using its secret key. Moreover, the messages exchanged among the participants are constantly updated in every new session that provides unpredictability. Hence, an adversary cannot find the location and any attempt of finding the location will ultimately fail.

Impersonation Attacks (Forgery Attacks)
An adversary A may intercept the messages of the previous legitimate RFID tag and modify that for authentication with the RFID Server S. In this case, the adversary A needs to make a valid message request that includes different parameters, like N y , R i , V 2 , M A 1 , AID Ti . To do so, the adversary A must compute AID Ti that is well encrypted and impossible to be computed or forged. Moreover, the adversary A also needs different other parameters and timestamps to put a valid request for authentication as a legitimate RFID tag. It is impossible for the adversary A without knowing the actual parameters of the Message used for authentication, hence leaving the adversary A unable to prove its legitimacy as an RFID tag to the RFID Server S. Reluctantly, the proposed protocol for RFID System resists any forgery attack.

Stolen-Verifier Attacks
The proposed protocol resists stolen-verifier-attack. All the verification and validation keys are stored encrypted in the RFID Database Server S. If the data and keys are stolen from the RFID Database Server S, still the adversary A cannot decrypt and extract them. Also, the adversary A cannot alter or modify the original data saved in the RFID Database Server S. Hence, the proposed protocol resists any stolen-verifier attack.

Comparative Analysis
This section presents a comprehensive comparative analysis of the proposed protocol with the existing protocols [3,21,23,30,31], as these schemes are based on lightweight symmetric key primitives. Hence, they are eligible for a fair comparison with the proposed scheme. Firstly, the proposed protocol is compared with the existing protocols in terms of security requirements. Secondly, a comparison of the proposed protocol with existing protocols based on computation cost (running time or execution time) is given, and thirdly, a comparison based on communication cost is presented. Furthermore, the proposed protocol is analyzed for storage complexity. Please note that we have selected the schemes based on lightweight symmetric key primitives and also that have been published recently. Each of these comparisons has been elaborated in the following subsections, one-by-one.

Security Requirements
Security requirements are the features expected from an authentication protocol. Every authentication protocol must be able to ensure these features or requirements. By these requirements, the proposed protocol is compared with the existing protocols. Following is the list of features/requirements considered for comparative analysis.  Table 4 shows the security requirements comparison of the proposed protocol with existing symmetric key-based protocols [3,21,23,30,31].
The insecurities of the existing schemes [3,21,23,30,31] are well defined in Section 1 and are replicated in Table 4. The security requirements in Table 4 show that only the proposed protocol provides all security features.

Computation Cost Analysis
This section describes the computation cost analysis of the proposed protocol with existing related protocols [3,21,23,30,31]. For analysis purposes, the following notations are introduced: • CC: Computation cost; • T h : CC of single hash function; • T se : CC of symmetric encryption/decryption.  [23] Tan et al. [30] Cai et al. [21] Cho et al. [31] Gope and Hwang [3] Proposed Scheme  Table 5 shows the computation cost analysis. The protocol presented in [23] incurs 2T h ,3T h , and 5T h , for each tag, Reader and Server, respectively, making its total computation cost 10T h . Similarly, the computation cost of protocol presented in [30] is 2T h , 2T h , and 3T h , respectively, for each participant, totaling it to 7T h . The protocol presented in [21] requires 4T h , 2T h , and 6T h for each tag, Reader, and Server, respectively, totaling it to 12T h . The computation cost of the protocol of Gope and Hwang [3] is 5T h , 2T h , and 7T h , respectively, for each participant totaling it to 14T h . In comparison, the tag in proposed protocol uses 2T h , the Reader uses 2T h , and the Server requires 4T h + 2T se , so in total the computation cost of the proposed protocol is equal to 8T h + 2T se . Considering the experiment of Kilinc and Yanik [47], the computation time of T h is 0.0023 ms, whereas the computation time to calculate T se is 0.0046 ms. The experiment was performed on a Ubuntu system with an Intel dual-core Pentium processor with specifications, including 2.20 GHz, 2048 MB processor and Ram, respectively. The total computation time of the proposed protocol is 0.0276 ms, whereas the total cost of the protocol presented in [23] is 0.0230 ms, the cost of protocol in [30] is approximately 0.0161 ms, the cost of the proposal in [3] is 0.0322 ms, and the proposal in [21] takes a total of 0.0276 ms. Although the proposed protocols incur a slightly higher computation cost as compared with [23,30], it provides less computation cost when compared with the baseline [3] and provides the same computation cost as compared to the protocol presented in [21]. Moreover, the proposed protocol is the only protocol that provides resistance against all known attacks. The results presented in Table 5 are visualized in Figure 7. Tan et al. [30] Cai et al. [21] Cho et al. [31] Gope and Hwang [3] Proposed Scheme

Communication and Storage Cost Analysis
Communication cost is presented in terms of the total number of messages exchanged and total number of bits exchanged during one transaction of the protocol. In the proposed protocol, tag i transmits four parameters in M 1 to R i carrying 416 bits and receives 384 bits from R i . Similarly, R i transmits 736 bits and receives 416 bits from S, while S transmits 416 bits and receives 736 bits. The communication cost comparison of the proposed protocol with other existing protocols is presented in Table 6. The storage cost is represented by length Value L, the proposed protocol uses SH A − 1 hash function to implement h(.); for simplicity, each of the length values is considered as 160-bit long.
In the proposed scheme, each tag stores ID T i , K ts , AID parameters. Therefore, the cost of storage in the tag is 3L, whereas on the Server side, ID T i , K ts , AID new , AID old are being stored; hence, the storage cost on the Server side is 4L per tag. The proposed protocol incurs less communication cost as compared with the protocols of [3,30], whereas it has more communication cost when compared with others [21,23,31]. However, only the proposed protocol provides required security. The results presented in Table 6 are visualized in Figure 8.

Communication Cost
Yang et al. [23] Tan et al. [30] Cai et al. [21] Cho et al. [31] Gope and Hwang [3] Proposed Scheme  Table 6 indicates that the proposed protocol is more efficient than the baseline protocol in terms of communication cost. Specifically, the proposed protocol not only overcomes the security flaws of the baseline protocol but also achieves 16.94% efficiency in terms of the number of bits exchanged during one transaction of the protocol.

Conclusions
In this article, cryptanalysis of a recent authentication protocol by Gope and Hwang has been presented, and it has been proved that their protocol has some weaknesses against collision, stolen verifier, and DoS attacks. An improved scheme using only lightweight primitives is proposed to resist all known attacks. The security of the proposed scheme has been thoroughly analyzed informally, as well as formally, using BAN logic. Moreover, the scheme is simulated in automated applied π calculus-based tool ProVerif. The simulation also backs the formal and informal security analysis. Although the proposed scheme incurs some extra computation and communication cost as compared with some existing related protocols, only the proposed protocol resists all known attacks and is more suitable for practical IoT-based scenarios.