Tag: Reader: Cloud: T,RS,HO,PRNGO) R HO,EO DO PRNGO Encrypted Hash Table H(RITIS) H(RI[TIS) Nr Search in the EHT E(RITIS) Find: Obtain T.S by D(E(R[]S))&Check R H(RITIS),E(RTIS) H(R[TINr),Nt Verify H(RTNr),if success: First Query::HWIS+1)】 Absence of H(RTM) Enumerate Queries means the last record of Check Answers Last Answer:E(R[T]M)) R &T is H(R[TM)) where M=M+1 Generate H(RIT]Nt H(RITIM)E(RITIM) Obtain M Notify the Cloud to update Verify HORM) The new record is If success: H(RTIN)⊕MP,HTR) Notify the tag to update,after checking H(RI円⊕H(E(RI[TM円)added into the EHT Update S=M Fig.6.The proposed cloud-based RFID authentication protocol The proposed cloud-based RFID authentication protocol is back to the reader from the cloud to confirm the updating is illustrated in Figure 6.E(RIDTIDSIDData)in the EHT is successful. simplified to E(RTS),where R denotes RID,T denotes TID, S denotes SID.The Data field is omitted without any influence The 5th step is to send a comprehensive response to be on the authentication process.S+1 denotes the next term after verified by the tag.The reader calculate H(RTNt)as the the S th term in the reader-defined sequence. response to the tag's random challenge Nt.The response is also used as an encryption key which is XORed with M'as a simple In particular,the RID has been shared by the reader with encryption.The encrypted M,i.e.H(RITIINt)M',is send to the tag in a registration phase,in which the reader write its RID the tag with H(TIR]M')which is also to be verified by the tag. and an initialized SID into the tag.The reader also adds an initialized record,i.e.(H(RIITIIS),E(RIITIIS)),into the backend The 6th step is for the tag to authenticate the reader and EHT in the registration phase.It is tenable to assume the repair the desynchronization.The tag calculates H(RTNt) registration is secure due to two reasons.(1)The frontend XORed with the received H(RIITIINt)M'to obtain M,then communication,i.e.the reader initializes the tag,is just once, calculates and verifies H(TRM').If success,it means the M' and thus can be implemented in a closed environment.(2)The is not modified by attackers,then synchronization is achieved backend communication,i.e.the reader initializes the EHT,is again by updating S=M'on the tag.Moreover,the validity of actually through the VPN protected networks. M'also means the validity of the reader's response H(RTINt) which is XORed together with M,that is,the reader is The 1st step of the proposed authentication scheme is for authenticated by the tag. the reader to obtain T and S.The tag generates H(RIITIS)as an authentication request,sends it to the reader.The reader reads IV.COMPARISON.ANALYSIS,AND EVALUATION the cipher text E(RTS)indexed by H(RIT]S)from the cloud EHT,decrypts,and checks the integrity by verifying R,and The proposed scheme is analyzed and evaluated in this section,comparing with two classical RFID authentication then obtains T,S schemes.One is Chien et al.'s backend-server-based protocol The 2nd step is to authenticate the tag.The reader generates using tags of EPC C1G2(Class 1 Generation 2)standard [16]. a random number Nr as a challenge to the tag.The tag The other is the first RFID server-less authentication protocol calculates H(RTNr)as a response and a random nonce Nt as proposed by Tan et al.[3].These two protocols are very its challenge to the reader.The reader verifies the response,if representative,attracting lasting attention till today. valid,the 3rd step is started;otherwise,the protocol is terminated. A.Applicability and Complexity Tags capability requirement.The protocol [16]is The 3rd step is to check the synchronization of S between lightweight that Gen2 tags only support PRNG,CRC,and the tag and the EHT.The reader tries to read the next record bitwise XOR operations,not support hash functions.The indexed by H(RT(S+1))from the EHT,and check the protocol [3],which replaces backend database with reader- integrity.If there is a valid record,it means that the tag has specific AL,requires tags to support hashing to generate a been desynchronized.The reader continues to try to read the valid response to the specific reader.So,it is middleweight as S+2 th record indexed by H(RIT(S+2))and so on,until well as all later server-less protocols.The proposed scheme finding the last valid record,assuming its SID is M. using an EHT also requires tags to support hashing,and The 4th step is to update the cloud EHT.The reader writes therefore middleweight.However,using a hash function does E(RTM)with the index H(RT]M)into the EHT,where not necessarily mean the order of magnitude increasing for a M'=M+1.A message of H(RIITIIM)H(E(RITM))is send tag.For instance,the research [17]presented a lightweightFig. 6. The proposed cloud-based RFID authentication protocol The proposed cloud-based RFID authentication protocol is illustrated in Figure 6. E(RID||TID||SID||Data) in the EHT is simplified to E(R||T||S), where R denotes RID, T denotes TID, S denotes SID. The Data field is omitted without any influence on the authentication process. S+1 denotes the next term after the S th term in the reader-defined sequence. In particular, the RID has been shared by the reader with the tag in a registration phase, in which the reader write its RID and an initialized SID into the tag. The reader also adds an initialized record, i.e.{H(R||T||S), E(R||T||S)}, into the backend EHT in the registration phase. It is tenable to assume the registration is secure due to two reasons. (1) The frontend communication, i.e. the reader initializes the tag, is just once, and thus can be implemented in a closed environment. (2) The backend communication, i.e. the reader initializes the EHT, is actually through the VPN protected networks. The 1st step of the proposed authentication scheme is for the reader to obtain T and S. The tag generates H(R||T||S) as an authentication request, sends it to the reader. The reader reads the cipher text E(R||T||S) indexed by H(R||T||S) from the cloud EHT, decrypts, and checks the integrity by verifying R, and then obtains T, S. The 2nd step is to authenticate the tag. The reader generates a random number Nr as a challenge to the tag. The tag calculates H(R||T||Nr) as a response and a random nonce Nt as its challenge to the reader. The reader verifies the response, if valid, the 3rd step is started; otherwise, the protocol is terminated. The 3rd step is to check the synchronization of S between the tag and the EHT. The reader tries to read the next record indexed by H(R||T||(S+1)) from the EHT, and check the integrity. If there is a valid record , it means that the tag has been desynchronized. The reader continues to try to read the S+2 th record indexed by H(R||T||(S+2)) and so on, until finding the last valid record, assuming its SID is M. The 4th step is to update the cloud EHT. The reader writes E(R||T||M') with the index H(R||T||M') into the EHT, where M'=M+1. A message of H(R||T||M')⊕H(E(R||T||M')) is send back to the reader from the cloud to confirm the updating is successful. The 5th step is to send a comprehensive response to be verified by the tag. The reader calculate H(R||T||Nt) as the response to the tag's random challenge Nt. The response is also used as an encryption key which is XORed with M' as a simple encryption. The encrypted M', i.e. H(R||T||Nt)⊕M', is send to the tag with H(T||R||M') which is also to be verified by the tag. The 6th step is for the tag to authenticate the reader and repair the desynchronization. The tag calculates H(R||T||Nt) XORed with the received H(R||T||Nt)⊕M' to obtain M', then calculates and verifies H(T||R||M'). If success, it means the M' is not modified by attackers, then synchronization is achieved again by updating S=M' on the tag. Moreover, the validity of M' also means the validity of the reader's response H(R||T||Nt) which is XORed together with M', that is, the reader is authenticated by the tag. IV. COMPARISON, ANALYSIS, AND EVALUATION The proposed scheme is analyzed and evaluated in this section, comparing with two classical RFID authentication schemes. One is Chien et al.'s backend-server-based protocol using tags of EPC C1G2 (Class 1 Generation 2) standard [16]. The other is the first RFID server-less authentication protocol proposed by Tan et al. [3]. These two protocols are very representative, attracting lasting attention till today. A. Applicability and Complexity Tags capability requirement. The protocol [16] is lightweight that Gen2 tags only support PRNG, CRC, and bitwise XOR operations, not support hash functions. The protocol [3], which replaces backend database with reader￾specific AL, requires tags to support hashing to generate a valid response to the specific reader. So, it is middleweight as well as all later server-less protocols. The proposed scheme using an EHT also requires tags to support hashing, and therefore middleweight. However, using a hash function does not necessarily mean the order of magnitude increasing for a tag. For instance, the research [17] presented a lightweight