Cloud-based rFID Authentication Wei Xie'Lei Xie2,Chen Zhang Quan Zhang',Chaojing Tang School of Electronic Science and Engineering,National University of Defense Technology,Changsha,China State Key Laboratory for Novel Software Technology,Nanjing University,Nanjing,China xiewei@nudt.edu.cn,Ixie@nju.edu.cn,zhan9chen@hotmail.com,(quanzhang,cjtang)@nudt.edu.cn Abstract-Along with the development of cloud computing, privacy-revealing of reader holders.To the best of our cloud-based RFID is receiving more and more attentions of knowledge,there is only one work,which is a server-less researchers and engineers.However,there is no research in searching protocol,specially designed to preserve privacy of which cloud computing is applied to RFID authentication mobile reader holders [5].There are,however,three shortages schemes.Most current works lay emphasis on functionalities, of the work.(1)Symmetric encryption,which is expensive to a lacking considerations about security and privacy.Classical passive tag's limited resource,is required.(2)No server-less RFID authentication schemes fail to meet the special security and privacy requirements of cloud-based RFID.The basic postulates authentication protocol is proposed besides the searching protocol.(3)A specially-structured AL is used,making the of traditional backend-sever-based RFID authentication,i.e. secure backend channel and entirely trustworthy database,are method inapplicable to enhance other server-less protocols. no longer natively tenable in cloud-based RFID scenarios.In this Along with the development of cloud computing,cloud- paper,a virtual private network agency is suggested to build based RFID becomes a new promising architecture [7-14]. secure backend channels and to provide readers with anonymous Data storage and processing is moved from the backend server access to the cloud.The cloud database is structured as an to a cloud offering pervasive RFID services.It is accessible encrypted hash table.The first cloud-based RFID authentication using fixed or mobile readers over the internet whenever and protocol preserving tag/reader privacy to database keepers is wherever needed.There are three advantages of the cloud- proposed.Comparing with classical schemes,the proposed based architecture.(1)A verifier with a cloud account is scheme has advantages in deployment cost saving,pervasiveness enabled to authenticate its tagged objects using any reader of authentication,scalability of O(1)complexity to verify a tag, mobile reader holders'privacy preserving,and database security. device whenever and wherever the pervasive and customized RFID service is accessible.(2)The pay-on-demand resource Keywords-RFID;cloud computing;authentication deployment greatly fits the needs of medium and small size enterprises.(3)The cloud is more robust than the backend I.INTRODUCTION server to serve large-scale applications due to resource RFID (Radio Frequency Identification)is a wireless sufficiency. technology using radio signals to identify tagged objects Present works addressed on cloud-based RFID are automatically and remotely.It has been widely used in supply insufficient in three aspects.(1)Most current works are chain management,inventory control,contactless credit card, focused on functionalities,lacking of considerations about and so on. security and privacy.(2)There is no research in which cloud RFID authentication is a primary approach to secure an computing is applied to RFID authentication.(3)There is no RFID system and make it privacy-friendly.Identifying a tag research in which classical RFID schemes are enhanced to without authenticating it causes serious security issues. meet the special security and privacy requirements of cloud- Attackers may intercept,manipulate,replay messages from the based systems [15].For instance,the backend server is truly tag to pretend to hold the tagged object (like an ID smartcard). trusted by readers in traditional RFID schemes.Secrets of tags are stored on the backend server without any encryption;and There is an extensive literature addressed RFID the backend server is knowledgeable about from which reader authentication schemes (see e.g.[1],[2]).Most of them are and to which tag a session is started.This is unacceptable in a backend-server-based,in which architecture a reader relays cloud-based application,because the cloud provider is rarely signals from tags to a backend server;and the backend server completely-trusted by its clients who use the cloud service.In helps the reader to verify tags according to the backend other words,reader holders and tag owners need to utilize the database.A basic assumption of the architecture is a reliable cloud robustness without losing access anonymity or data and always accessible connection between the reader and the privacy.None of current RFID authentication protocols meets backend server,which limits the reader's mobility. the requirements of cloud-based RFID applications. Server-less is another RFID architecture,which is designed The main contributions of this paper include:(1)Cloud to identify and verify tags using offline mobile readers [3-6]. computing is first applied to RFID authentication scenarios,the The simple idea of offline authentication is to download an AL first cloud-based RFID authentication scheme is proposed.It (Access List)from a CA(Certification Agency)into an mobile inherits pay-on-demand resource deployment,great scalability reader.So the reader is enabled to offline authenticate tags and pervasively-accessibility from cloud computing,without anywhere according to the AL without helps of a backend lacking considerations to protect security and to preserve server.A common weakness in server-less protocols is
Cloud-based RFID Authentication Wei Xie1 , Lei Xie2 , Chen Zhang1 , Quan Zhang1 , Chaojing Tang1 1 School of Electronic Science and Engineering, National University of Defense Technology, Changsha, China 2 State Key Laboratory for Novel Software Technology, Nanjing University, Nanjing, China xiewei@nudt.edu.cn, lxie@nju.edu.cn, zhan9chen@hotmail.com, {quanzhang, cjtang}@nudt.edu.cn Abstract—Along with the development of cloud computing, cloud-based RFID is receiving more and more attentions of researchers and engineers. However, there is no research in which cloud computing is applied to RFID authentication schemes. Most current works lay emphasis on functionalities, lacking considerations about security and privacy. Classical RFID authentication schemes fail to meet the special security and privacy requirements of cloud-based RFID. The basic postulates of traditional backend-sever-based RFID authentication, i.e. secure backend channel and entirely trustworthy database, are no longer natively tenable in cloud-based RFID scenarios. In this paper, a virtual private network agency is suggested to build secure backend channels and to provide readers with anonymous access to the cloud. The cloud database is structured as an encrypted hash table. The first cloud-based RFID authentication protocol preserving tag/reader privacy to database keepers is proposed. Comparing with classical schemes, the proposed scheme has advantages in deployment cost saving, pervasiveness of authentication, scalability of O(1) complexity to verify a tag, mobile reader holders’ privacy preserving, and database security. Keywords—RFID; cloud computing; authentication I. INTRODUCTION RFID (Radio Frequency Identification) is a wireless technology using radio signals to identify tagged objects automatically and remotely. It has been widely used in supply chain management, inventory control, contactless credit card, and so on. RFID authentication is a primary approach to secure an RFID system and make it privacy-friendly. Identifying a tag without authenticating it causes serious security issues. Attackers may intercept, manipulate, replay messages from the tag to pretend to hold the tagged object (like an ID smartcard). There is an extensive literature addressed RFID authentication schemes (see e.g. [1], [2]). Most of them are backend-server-based, in which architecture a reader relays signals from tags to a backend server; and the backend server helps the reader to verify tags according to the backend database. A basic assumption of the architecture is a reliable and always accessible connection between the reader and the backend server, which limits the reader’s mobility. Server-less is another RFID architecture, which is designed to identify and verify tags using offline mobile readers [3-6]. The simple idea of offline authentication is to download an AL (Access List) from a CA (Certification Agency) into an mobile reader. So the reader is enabled to offline authenticate tags anywhere according to the AL without helps of a backend server. A common weakness in server-less protocols is privacy-revealing of reader holders. To the best of our knowledge, there is only one work, which is a server-less searching protocol, specially designed to preserve privacy of mobile reader holders [5]. There are, however, three shortages of the work. (1) Symmetric encryption, which is expensive to a passive tag's limited resource, is required. (2) No server-less authentication protocol is proposed besides the searching protocol. (3) A specially-structured AL is used, making the method inapplicable to enhance other server-less protocols. Along with the development of cloud computing, cloudbased RFID becomes a new promising architecture [7-14]. Data storage and processing is moved from the backend server to a cloud offering pervasive RFID services. It is accessible using fixed or mobile readers over the internet whenever and wherever needed. There are three advantages of the cloudbased architecture. (1) A verifier with a cloud account is enabled to authenticate its tagged objects using any reader device whenever and wherever the pervasive and customized RFID service is accessible. (2) The pay-on-demand resource deployment greatly fits the needs of medium and small size enterprises. (3) The cloud is more robust than the backend server to serve large-scale applications due to resource sufficiency. Present works addressed on cloud-based RFID are insufficient in three aspects. (1) Most current works are focused on functionalities, lacking of considerations about security and privacy. (2) There is no research in which cloud computing is applied to RFID authentication. (3) There is no research in which classical RFID schemes are enhanced to meet the special security and privacy requirements of cloudbased systems [15]. For instance, the backend server is truly trusted by readers in traditional RFID schemes. Secrets of tags are stored on the backend server without any encryption; and the backend server is knowledgeable about from which reader and to which tag a session is started. This is unacceptable in a cloud-based application, because the cloud provider is rarely completely-trusted by its clients who use the cloud service. In other words, reader holders and tag owners need to utilize the cloud robustness without losing access anonymity or data privacy. None of current RFID authentication protocols meets the requirements of cloud-based RFID applications. The main contributions of this paper include: (1) Cloud computing is first applied to RFID authentication scenarios, the first cloud-based RFID authentication scheme is proposed. It inherits pay-on-demand resource deployment, great scalability and pervasively-accessibility from cloud computing, without lacking considerations to protect security and to preserve
privacy.(2)The most important part of the scheme is the first RFID authentication protocol,in which privacy of tags and Certification Agency readers are covered to backend database keepers.The protocol achieves mutual authentication between tags and readers, scalable with O(1)computational complexity of verifying a tag.It is resistant to eavesdropping,manipulating,replaying, Mobile Reader Mobile Reader and desynchronization attacks. Temporary Connection The remain of the paper is structured as follows:In section to Download Access List 2.we detail the reasons that current RFID authenticatior Index Certification schemes are incapable to work in cloud-based scenarios,and provides primary requirements to design a cloud-based RFID TID H(RID,Kt) authentication scheme.In section 3,the scheme is proposed.It applies a VPN(Virtual Private Network)agency,a global EHT (Encrypted Hash Table),and the first RFID authentication protocol against database keepers.In section 4,the complexity Fig.2.The server-less RFID architecture and security of the proposed scheme are analyzed and evaluated by comparing with two representative classical RFID portable device such as a notebook computer,a smart phone. authentication schemes.In section 5,we give our conclusions. etc.It might be stolen.Then,the AL stored in it might be II.REVIEW AND REOUIREMENT maliciously utilized to forge tags.The notion of RID (Reader Traditional RFID authentication schemes are reviewed to IDentifier)is defined to prevent the forging.Each tag's authentication credential is a hash digest derived from the tag's show their inapplicability to cloud-based applications in this key and the reader's RID.listed in the AL and indexed by TID section.There are mainly two architectures of current schemes: (Tag's IDentifier).It makes the AL exclusively useable for the the backend-server-based.and the server-less. reader.Attackers are infeasible to forge a tag by extracting the A.Reviews of Traditional RFID tag's key from the reader-specific AL.But as a result,the tag is The backend-server-based RFID is illustrated in Figure 1.It also infeasible to generate a valid request without the reader's RID.So,the RID is require to be transmitted from the reader to is composed of tags,readers,and a backend server.The readers the tag.In the authentication phase,the reader challenges a tag are generally fixed.They identify and verify tags by querying the backend server.Communications between readers and tags with the RID,waiting the tag response with H(RID,Kt).The reader then searches its AL,trying to find a matched credential are on frontend channels using public radio signals,thus, to verify the Kt and then identify the TID considered to be insecure.Communications between readers and the backend server are on backend channels which is The server-less architecture provides readers with generally on private intranet,thus,considered to be secure. capabilities of large-scale moving and offline authentication. Backend-server-based protocol designers only need to pay There are,however,three drawbacks in current server-less attention to protect frontend communications without worrying authentication protocols.(1)All of them transmit RIDs in about the backend security.However,A major disadvantage of plaintext,revealing the privacy of mobile reader holders. the backend-server-based architecture is the limited mobility of Attacks can identify and locate the holders by sniffing the readers because of using private intranet connection to build a uncovered RIDs.(2)Exhaustive searching through the AL are secure and always accessible backend channel.It makes the with a computational complexity of O(N),where N denotes the backend-server-based architecture inapplicable to the scenarios number of tags.It means unsatisfactory scalability to serve a in which readers are required to move across cities or even huge number of tags.(3)Computational processes of searching countries. and verifying is executed all by a single personal portable The server-less RFID is illustrated in Figure 2.It is device without any help of a backend server,significantly composed of tags,readers,and a CA.There are two phases: reducing the performance. initialization and authentication.The mobile reader accesses B.Requirements of Cloud-based RFID the CA and downloads an AL through a secure connection in The rising cloud-based RFID is illustrated in Figure 3.It is the initialization phase.Unlike the stationary and well offered as a service of cloud computing to individuals and protected backend server,the mobile reader is generally a organizations.It is composed of tags,readers,and a serving cloud.The readers can be fixed or mobile,accessing the cloud Private Intranet Public Channel by wired or wireless connections.Backend servers are replaced with a pervasive cloud which provides readers with data storing and querying.Comparing with the traditional,the cloud-based RFID has many advantages,meanwhile,is Wired Connection Radio Signal Tag challenged by special concerns over security and privacy. Backend Server Fixed Reader Existing RFID authentication protocols are inapplicable to cloud-based applications because of lacking two primary Fig.1.The backend-server-based RFID architecture capabilities
Fig. 1. The backend-server-based RFID architecture Index Certification TID H(RID,Kt) 。。。 。。。 Fig. 2. The server-less RFID architecture privacy. (2) The most important part of the scheme is the first RFID authentication protocol, in which privacy of tags and readers are covered to backend database keepers. The protocol achieves mutual authentication between tags and readers, scalable with O(1) computational complexity of verifying a tag. It is resistant to eavesdropping, manipulating, replaying, and desynchronization attacks. The remain of the paper is structured as follows: In section 2, we detail the reasons that current RFID authentication schemes are incapable to work in cloud-based scenarios, and provides primary requirements to design a cloud-based RFID authentication scheme. In section 3, the scheme is proposed. It applies a VPN (Virtual Private Network) agency, a global EHT (Encrypted Hash Table), and the first RFID authentication protocol against database keepers. In section 4, the complexity and security of the proposed scheme are analyzed and evaluated by comparing with two representative classical RFID authentication schemes. In section 5, we give our conclusions. II. REVIEW AND REQUIREMENT Traditional RFID authentication schemes are reviewed to show their inapplicability to cloud-based applications in this section. There are mainly two architectures of current schemes: the backend-server-based, and the server-less. A. Reviews of Traditional RFID The backend-server-based RFID is illustrated in Figure 1. It is composed of tags, readers, and a backend server. The readers are generally fixed. They identify and verify tags by querying the backend server. Communications between readers and tags are on frontend channels using public radio signals, thus, considered to be insecure. Communications between readers and the backend server are on backend channels which is generally on private intranet, thus, considered to be secure. Backend-server-based protocol designers only need to pay attention to protect frontend communications without worrying about the backend security. However, A major disadvantage of the backend-server-based architecture is the limited mobility of readers because of using private intranet connection to build a secure and always accessible backend channel. It makes the backend-server-based architecture inapplicable to the scenarios in which readers are required to move across cities or even countries. The server-less RFID is illustrated in Figure 2. It is composed of tags, readers, and a CA. There are two phases: initialization and authentication. The mobile reader accesses the CA and downloads an AL through a secure connection in the initialization phase. Unlike the stationary and well protected backend server, the mobile reader is generally a portable device such as a notebook computer, a smart phone, etc. It might be stolen. Then, the AL stored in it might be maliciously utilized to forge tags. The notion of RID (Reader IDentifier) is defined to prevent the forging. Each tag's authentication credential is a hash digest derived from the tag's key and the reader's RID, listed in the AL and indexed by TID (Tag's IDentifier). It makes the AL exclusively useable for the reader. Attackers are infeasible to forge a tag by extracting the tag's key from the reader-specific AL. But as a result, the tag is also infeasible to generate a valid request without the reader's RID. So, the RID is require to be transmitted from the reader to the tag. In the authentication phase, the reader challenges a tag with the RID, waiting the tag response with H(RID, Kt). The reader then searches its AL, trying to find a matched credential to verify the Kt and then identify the TID. The server-less architecture provides readers with capabilities of large-scale moving and offline authentication. There are, however, three drawbacks in current server-less authentication protocols. (1) All of them transmit RIDs in plaintext, revealing the privacy of mobile reader holders. Attacks can identify and locate the holders by sniffing the uncovered RIDs. (2) Exhaustive searching through the AL are with a computational complexity of O(N), where N denotes the number of tags. It means unsatisfactory scalability to serve a huge number of tags. (3) Computational processes of searching and verifying is executed all by a single personal portable device without any help of a backend server, significantly reducing the performance. B. Requirements of Cloud-based RFID The rising cloud-based RFID is illustrated in Figure 3. It is offered as a service of cloud computing to individuals and organizations. It is composed of tags, readers, and a serving cloud. The readers can be fixed or mobile, accessing the cloud by wired or wireless connections. Backend servers are replaced with a pervasive cloud which provides readers with data storing and querying. Comparing with the traditional, the cloud-based RFID has many advantages, meanwhile, is challenged by special concerns over security and privacy. Existing RFID authentication protocols are inapplicable to cloud-based applications because of lacking two primary capabilities
Pervasive Cloud Encrypted Hash Table Pervasive Cloud Index Content H(RIDITIDSID)E(RIDITIDSIDData) 444 Wireless VPN Wired VPN Public Internet Mobile Reader Fixed Reader Mobile Reader Fixed Reader Tag Tag Fig.3.The cloud-based RFID architecture Fig.4.The proposed cloud-based RFID authentication scheme Firstly,cloud-based RFID authentication schemes are required to offer data storage service without spying upon required to secure backend communications besides reader's/tag's secrets.(2)The database keeper is required to protections of the frontend security.In traditional backend- offer data inquiry service without knowing reader's/tag's server-based schemes.readers access the backend server identities.None of current RFID authentication protocols meet through wired private intranet connections,which is considered any of the requirements. to be secure.But in the cloud-based schemes,mobile readers often access the public cloud through wireless open internet III.THE PROPOSED SCHEME connections,which cannot be asserted as secure.There are two The proposed cloud-based RFID authentication scheme is solutions of this issue.The first solution is to establish VPN illustrated in Figure 4.Readers anonymously access the cloud connections between readers and the cloud in the network through wired or wireless VPN connections.An encrypted layer.Keeping a constant VPN username,however,harms the hash table is utilized to prevent clients'(readers and tags) anonymity of readers accessing the cloud.The second solution secrets from revealing to the cloud.The first RFID is in the application layer to design an RFID authentication authentication protocol preserving readers and tags privacy protocol protecting the backend security. against an untrusted database keeper is proposed. Secondly,cloud-based RFID authentication schemes are A.Notations and Assumptions required to prevent tags/readers from privacy-revealing to the untrustworthy cloud.A traditional backend server (or the CA) Notations in this paper are listed in Table 1.Reasonable is totally trusted to store secrets of readers/tags without any assumptions are listed as followed: encryption,and able to trace readers and tags.But in a cloud- Tags are with middleweight computing capacity of based RFID,the cloud provider is not truly trusted by the XOR,PRNG,and hashing. reader holders and tag owners,therefore,it is required to provide readers/tags with confidentiality of data storage and ● A mobile reader is embedded in a portable digital anonymity of access,which is against the cloud.The detailed device like a PDA with computing capacity of XOR, requirements are as follows:(1)The database keeper is PRNG,hashing,and symmetric encryption. TABLE I. NOTATIONS Notation Description RID,R denotes the identity of an RFID reader TID.T denotes the identity of an RFID tag SID,S numbers authentication sessions between a reader and a tag,starts from zero,with bit length L denotes the last number of sessions(i.e.the maximum SID)between a reader and a a tag. Data denotes any data relevant to a session about the user,the reader,and/or the tag. Nr denotes a random number generated by an RFID reader Nt denotes a random number generated by an RFID tag PRNGO) denotes the PRNG(Pseudo Random Noise Generation)function of Nr and Nt HO denotes a secure one-way hash function with output length L.That is,HO):(0,1)*(0,1L EO denotes an encryption function by using a symmetric algorithm with a reader private key. DO denotes a decryption function by using a symmetric algorithm with a reader private key. denotes the bitwise XOR (Exclusive OR)operation denotes the concatenation operation
Fig. 3. The cloud-based RFID architecture Encrypted Hash Table Index Content H(RID||TID||SID) E(RID||TID||SID||Data) … … Fig. 4. The proposed cloud-based RFID authentication scheme TABLE I. NOTATIONS Notation Description RID, R denotes the identity of an RFID reader TID, T denotes the identity of an RFID tag SID, S numbers authentication sessions between a reader and a tag, starts from zero, with bit length L M denotes the last number of sessions (i.e. the maximum SID) between a reader and a a tag. Data denotes any data relevant to a session about the user, the reader, and/or the tag. Nr denotes a random number generated by an RFID reader Nt denotes a random number generated by an RFID tag PRNG() denotes the PRNG (Pseudo Random Noise Generation) function of Nr and Nt H() denotes a secure one-way hash function with output length L. That is, H(): {0,1}*→{0,1}L E() denotes an encryption function by using a symmetric algorithm with a reader private key. D() denotes a decryption function by using a symmetric algorithm with a reader private key. ⊕ denotes the bitwise XOR (Exclusive OR) operation || denotes the concatenation operation Firstly, cloud-based RFID authentication schemes are required to secure backend communications besides protections of the frontend security. In traditional backendserver-based schemes, readers access the backend server through wired private intranet connections, which is considered to be secure. But in the cloud-based schemes, mobile readers often access the public cloud through wireless open internet connections, which cannot be asserted as secure. There are two solutions of this issue. The first solution is to establish VPN connections between readers and the cloud in the network layer. Keeping a constant VPN username, however, harms the anonymity of readers accessing the cloud. The second solution is in the application layer to design an RFID authentication protocol protecting the backend security. Secondly, cloud-based RFID authentication schemes are required to prevent tags/readers from privacy-revealing to the untrustworthy cloud. A traditional backend server (or the CA) is totally trusted to store secrets of readers/tags without any encryption, and able to trace readers and tags. But in a cloudbased RFID, the cloud provider is not truly trusted by the reader holders and tag owners, therefore, it is required to provide readers/tags with confidentiality of data storage and anonymity of access, which is against the cloud. The detailed requirements are as follows: (1) The database keeper is required to offer data storage service without spying upon reader’s/tag’s secrets. (2) The database keeper is required to offer data inquiry service without knowing reader’s/tag’s identities. None of current RFID authentication protocols meet any of the requirements. III. THE PROPOSED SCHEME The proposed cloud-based RFID authentication scheme is illustrated in Figure 4. Readers anonymously access the cloud through wired or wireless VPN connections. An encrypted hash table is utilized to prevent clients’ (readers and tags) secrets from revealing to the cloud. The first RFID authentication protocol preserving readers and tags privacy against an untrusted database keeper is proposed. A. Notations and Assumptions Notations in this paper are listed in Table 1. Reasonable assumptions are listed as followed: • Tags are with middleweight computing capacity of XOR, PRNG, and hashing. • A mobile reader is embedded in a portable digital device like a PDA with computing capacity of XOR, PRNG, hashing, and symmetric encryption
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 scheme
Fig. 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 oneway 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
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 lightweight
Fig. 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 readerspecific 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