The frontend communications between tags and readers A potential threat caused by anonymous accessing is the are on public radio channels.Attackers are able to difficulty to prevent malicious clients from anonymous storing eavesdrop,manipulate,delete,replay frontend massive junk data to the cloud,occupying storage space of messages. other clients to perform a DOS attack.However,it is accountable afterwards.The victimized tag owner and verifier The backend communications between readers and the cloud are through VPN connections.Attackers are able can file a suit at the cloud,submitting their attacked storage to intercept,block,and resend TCP/IP packets in space address.Then,the cloud provider can find out the attacker's VPN IP address from which the attack starts. network layer,however,infeasible to validly parse, according to the accessing logs.Finally,the malicious client modify,or replay the RFID authentication protocol can be identified by the VPN agency according to the VPN messages in the application layer. login logs.The process of revealing malice is a multiparty The cloud provider,i.e.the database keeper,is not cooperation based on other research fields not covered in this trusted.It may be malicious or vulnerable paper. B.VPN Agency The use of VPN routing protects readers'anonymity only in network layer.The corresponding anonymity in application There are four kinds of participants in the proposed layer(ie.in the RFID authentication protocol)is provided by scheme:i.e.tag owner,verifier,VPN agency,and cloud provider.The order of connections is illustrated in Figure 5. the proposed scheme in subsection D. The tag owner and the verifier are frontend participants of C.Encrypted Hash Table the proposed scheme.Tag owners are those own tagged items. An EHT is utilized in the proposed scheme to prevent Verifiers are reader owners or holders.A tag owner and a client's data confidentiality and access anonymity from verifier can be identical sometimes.For instance,the tag owner revealing to the untrustworthy cloud provider.Its structure is is also the verifier in a scenario that a person uses a PDA to illustrated in Figure 4.The index which is a hash digest identify his/her tagged personal belongings.On the other hand, H(RIDTIDSID)uniquely denotes the session with SID from in a scenario that a club identifies its members by the reader with RID to the tag with TID.According to the one- authenticating their smart ID cards,the tag owner is the way characteristic of hash function,attackers as well as the member to be identified,and the verifier is the club.The cloud provider are infeasible to parse an index to crack the security and privacy requirement of a tag-owner/verifier is the anonymity of the session.The record indexed by infeasibility either to sniff out the TID/RID or to forge the tag's H(RIDTIDSID)is E(RIDTIDISIDData).It is a cipher text /reader's messages. according to a reader-defined encryption algorithm with a reader-managed key.The RID field is used to check the The VPN agency and the cloud provider are backend integrity of the cipher text after decryption by the reader.The participants of the proposed scheme.The VPN agency provides TID field is used for mutual authentication as a shared secret readers and the cloud with VPN routing.The cloud provider between the reader and the tag.The SID field is an identifier offers a cloud service of RFID authentication to the verifier which is a term in a reader-defined sequence.It can be and the tag owner. enumerated to generate all indexes of previous sessions from VPN routing makes the communication between the reader the reader to the tag.The Data field is customized to store any and the cloud as secure as in a private intranet.It means that application data such as location of a tag,access time,account on one hand,the confidentiality and freshness of the backend balance in a smartcard,etc.All these data are encrypted by the communications are ensured.Attackers are able to intercept, reader-self to prevent privacy from revealing to the cloud. block,and resend TCP/IP packets in the network layer, Need of special note is,the encryption used in the EHT is however,infeasible to effectively parse,modify,or replay not to protect transmitted messages but to protect stored data. RFID authentication protocol messages in the application There is no key distribution process,because both encryption layer.On the other hand,network-layer-anonymity of readers and decryption algorithm are designed and implemented by a accessing the cloud is achieved.The VPN agency provides a reader-self.The key management can be provided by using any reader with a random virtual IP address each login.A mature approach needless to be detailed in this paper. malicious cloud can not links the protocol messages form the same reader based on the packets'source address. D.The Proposed Protocol Tag Owner Verifier VPN Agency Cloud (Reader Holder) (VPN Router) Privider Fig.5.The participants in the proposed schemeFig. 5. The participants in the proposed scheme • The frontend communications between tags and readers are on public radio channels. Attackers are able to eavesdrop, manipulate, delete, replay frontend messages. • The backend communications between readers and the cloud are through VPN connections. Attackers are able to intercept, block, and resend TCP/IP packets in network layer, however, infeasible to validly parse, modify, or replay the RFID authentication protocol messages in the application layer. • The cloud provider, i.e. the database keeper, is not trusted. It may be malicious or vulnerable. B. VPN Agency There are four kinds of participants in the proposed scheme: i.e. tag owner, verifier, VPN agency, and cloud provider. The order of connections is illustrated in Figure 5. The tag owner and the verifier are frontend participants of the proposed scheme. Tag owners are those own tagged items. Verifiers are reader owners or holders. A tag owner and a verifier can be identical sometimes. For instance, the tag owner is also the verifier in a scenario that a person uses a PDA to identify his/her tagged personal belongings. On the other hand, in a scenario that a club identifies its members by authenticating their smart ID cards, the tag owner is the member to be identified, and the verifier is the club. The security and privacy requirement of a tag-owner/verifier is the infeasibility either to sniff out the TID/RID or to forge the tag's /reader's messages. The VPN agency and the cloud provider are backend participants of the proposed scheme. The VPN agency provides readers and the cloud with VPN routing. The cloud provider offers a cloud service of RFID authentication to the verifier and the tag owner. VPN routing makes the communication between the reader and the cloud as secure as in a private intranet. It means that, on one hand, the confidentiality and freshness of the backend communications are ensured. Attackers are able to intercept, block, and resend TCP/IP packets in the network layer, however, infeasible to effectively parse, modify, or replay RFID authentication protocol messages in the application layer. On the other hand, network-layer-anonymity of readers accessing the cloud is achieved. The VPN agency provides a reader with a random virtual IP address each login. A malicious cloud can not links the protocol messages form the same reader based on the packets’ source address. A potential threat caused by anonymous accessing is the difficulty to prevent malicious clients from anonymous storing massive junk data to the cloud, occupying storage space of other clients to perform a DOS attack. However, it is accountable afterwards. The victimized tag owner and verifier can file a suit at the cloud, submitting their attacked storage space address. Then, the cloud provider can find out the attacker's VPN IP address from which the attack starts, according to the accessing logs. Finally, the malicious client can be identified by the VPN agency according to the VPN login logs. The process of revealing malice is a multiparty cooperation based on other research fields not covered in this paper. The use of VPN routing protects readers’ anonymity only in network layer. The corresponding anonymity in application layer (i.e. in the RFID authentication protocol) is provided by the proposed scheme in subsection D. C. Encrypted Hash Table An EHT is utilized in the proposed scheme to prevent client's data confidentiality and access anonymity from revealing to the untrustworthy cloud provider. Its structure is illustrated in Figure 4. The index which is a hash digest H(RID||TID||SID) uniquely denotes the session with SID from the reader with RID to the tag with TID. According to the one￾way characteristic of hash function, attackers as well as the cloud provider are infeasible to parse an index to crack the anonymity of the session. The record indexed by H(RID||TID||SID) is E(RID||TID||SID||Data). It is a cipher text according to a reader-defined encryption algorithm with a reader-managed key. The RID field is used to check the integrity of the cipher text after decryption by the reader. The TID field is used for mutual authentication as a shared secret between the reader and the tag. The SID field is an identifier which is a term in a reader-defined sequence. It can be enumerated to generate all indexes of previous sessions from the reader to the tag. The Data field is customized to store any application data such as location of a tag, access time, account balance in a smartcard, etc. All these data are encrypted by the reader-self to prevent privacy from revealing to the cloud. Need of special note is, the encryption used in the EHT is not to protect transmitted messages but to protect stored data. There is no key distribution process, because both encryption and decryption algorithm are designed and implemented by a reader-self. The key management can be provided by using any mature approach needless to be detailed in this paper. D. The Proposed Protocol