Paper Title (Use Style: Paper Title)

1114 JOURNAL OF NETWORKS, VOL. 9, NO. 5, MAY 2014

An Efficient Offline Delegation Protocol in Mobile RFID Environment

Jia-Ning Luo Ming Chuan University, Information & Telecommunications Engineering, Taoyuan County, Taiwan 333 Email: [email protected]

Ming-Hour Yang* Chung Yuan Christian University, Information & Computer Engineering, Taoyuan County, Taiwan 320 *Corresponding Author, Email: [email protected]

Abstract—In this paper, we propose a new protocol to allow reader, and the delegated reader is allowed to access a delegation transfer between offline mobile readers in the specific tag in the future even in an offline environment mobile RFID (Radio Frequency Identification) environment. [10] [14] [16]. A mobile reader can grant the access rights of a specific tag Fouladgar et al. [5] propose an online delegation and to another reader. Besides, our protocol is efficient and ownership transfer protocol. Lee et al.’s scheme [9] uses secure against most current network threats, such as replay attacks, Man-in-the-Middle (MITM) attacks, denial of timestamps to manage authorization, but in Lee’s protocol, service (DoS) attacks caused by asynchronous update, if one user updates a tag’s timestamp, others will have to guessing attacks, and counterfeit tags. It also guarantees use the new timestamp to access the tag. When a tag forward/backward secrecy, data privacy, and location reaches its maximum timestamp update times, all the privacy. delegated readers have to connect to their back-end server for new delegation. Yang [15] also proposes an offline Index Terms—Mobile RFID; Offline Delegation; Delegation delegation protocol that stores an access control list (ACL) Transfer on a tag to limit a reader’s access right. He also deploys timestamps in his offline delegation scheme. His back-end I. INTRODUCTION server can delegate the access right to a tag, but the access right cannot be transferred from one reader to another. Radio frequency identification (RFID) has been widely For these reasons, we propose a new scheme to perform applied in logistics management, entrance control, smart offline delegation transfer. In our protocol, the delegation appliances, medical control, and e-wallet services. An of a specific tag is within control. A mobile RFID reader is RFID framework consists of back-end servers, database, allowed limited access times of a specific tag by its RFID readers, and tags. RFID tags include active tags and back-end server. The tag can verify and decrease the passive tags. An active RFID tag contains a battery, and a access counter in each access. After the counter expires, passive tag is powered by radio wave energy from an the reader has to request a new delegation from the RFID reader. Most RFID tags used in supply chains are back-end server. The other reader can request delegation passive ones. Because of the limitation of power from the reader that owns the tag. A delegation transfer is consuming and gate counts, a passive RFID tag can only operated offline without the involvement of the back-end do simple computation and have limited storage capacity. server. After the delegation transfer, the access times of Most of its data is stored on the back-end database servers. the tag are transferred to the new reader, and the access In recent years RFID technology has seen the counter of the previous reader decreases by the same integration of RFID and mobile devices [2] [7] [8]. An amount. The rest of the paper is organized as follows: RFID-embedded cellphone can access a tag and retrieve section 2 details our proposed protocol; section 3 analyzes its data from the back-end server through wireless or 3G the security issues; section 4 deals with performance networks [14]. evaluation and comparison; section 5 concludes our In a mobile RFID environment, even though a mobile scheme. reader can communicate with its back-end server through telecommunications, weak reception or poor network II. OFFLINE DELEGATION PROTOCOL quality can usually affect its performance [3] [4] [5] [9] Our offline delegation transfer protocol includes an [11] [15]. Among RFID’s research, offline delegation initial stage and three protocols: (1) offline reader-tag transfer allows users who have been authorized to access a mutual authentication protocol; (2) readers’ delegation specific tag to transfer a part of their authorization to protocol and (3) offline delegation transfer protocol, as others without Internet connections [1] [10] [12] [16]. To shown in Figure 1. At the initial stage, mobile readers have perform offline delegation, a back-end server has to been delegated authority to a specific tag and authenticate delegate authority of a specific RFID tag to an RFID each other. In the second part, the readers identify and

access the tag offline. In the third part a reader delegate his performed offline. Figure 3 details the steps of our access rights to another reader. reader-tag mutual authentication.

Reader RIDi Back-end server Reader i 1.offline authentication R,T, Delegation RIDi , Tlisti

1. RequestDelegation , RIDi

m m 2.offline reading Generate RK i , ri m m SKi  H(Secrectm || RIDi || ri ) DM m  LE (SK m , RID || TID || RS || RK m || RC m ) 3.offline delegation i i i m m i i m m m m transfer 2.offline reading Tlisti  Tlisti {TIDm , RK i , RCi , DM i ,ri } Tag TID1 2.Tlisti

Tlisti  Tlisti

1.offline authentication Figure 2. Initial stage

Reader RIDj Reader i Tag m Figure 1. Offline coupon delegation transfer scheme RIDi , Tlisti  {{TIDm , TIDm , Secretm , TSm , RK m , RC m , DM m ,r m}} i i i i Rlistm

Notations uses in this paper are listed in Table 1. m m 1. Request Authentica tion , RIDi , ri , DM i

TABLE I. NOTATIONS flag  false m m SKi  H(Secrcet m  RIDi  ri ) Tag ’s identifier. m m m Derive RIDi ', TIDm ', RSm , RKi , RCi from DM i

Reader ’s identifier. (target reader in delegation transfer) If (RIDi  RIDi ') and (TIDm  TIDm ') and (RSm  TSm )

Secret key shared between and its back-end server. If (RSm  TSm )

Tag ’s timestamp. TSm  RSm , Clear Rlistm m m Reader’s current timestamp. / Tag ’s current timestamp If (Rlistm {RIDi , RKi , RCi }) m m that a reader holds. Rlistm  Rlistm {{RIDi , RKi , RCi }} Counters that indicate reader ’s and reader ’s maximum flag  true

query times to tag . (on tag’s part) Generate r1 Counters that indicate reader ’s and reader ’s maximum If ( flag  true) m m query times to tag . (on reader’s part) M1  LE(RKi ,TIDm || ri || r1) Else Tag ’s access control list. M  r Reader ’s authorization table. 1 1 2. M Reader ’s and reader ’s shared keys with tag , Derive TID ',r m ' from M 1 m i 1 m m respectively. If (ri  ri ')and(TIDm  TIDm ') Delegation message, generated by back-end server for Confirm

reader i to access tag m.

Requested query times in delegation transfer. Figure 3. Mutual authentication protocol Delegation transfer flag.

Session key, used to en/decrypt a delegation message. Step 1: Reader i sends a request message Nonce generated by back-end server, used in reader-tag to tag m, along with its own communications, between reader and tag . Random numbers. identifier , a nonce , and a delegation message

Hash function. .

Lightweight symmetric key encryption algorithm. Step 2: Tag m generates a session key and Concatenation of messages. decrypts to derive reader’s identifier , tag’s A. Initial Stage identifier , reader i’s current timestamp , the key , and reader i’s delegated query times . Tag In the initial stage, when an RFID reader i wants to access a tag, it should send a delegation request to the m compares and with and , respectively. It also checks if . If , back-end server, and the server will return a tag-list that contains all the tags owned by the reader, see Figure 2. the reader’s delegated authority expires. If , tag m has to update its timestamp, i.e. , and to The server randomly generates a session key and a clear its access control list . Then tag m stores , nonce . After concatenating , and , and on its . If reader i is valid, tag m and generate the session key , a delegation message sends a message to the reader, as shown in figure3. If contains reader’s and tag’s identifiers, system’s reader i fails to pass the authentication, tag m returns a timestamp , session key , and reader’s maximum random number. query times . Then the server sends to the Step 3: When receiving , reader i derives and reader. and compare them to and . B. Offline Reader-Tag Mutual Authentication Protocol C. Reader’s Delegation Protocol After a reader gets the access right of a specific tag from In our protocol, the delegation of a specific tag is the back-end server, the reader and the tag should do limited. Each time when a reader accesses a tag, a counter mutual authentication to identify each other, which is decrease. After the counter expires, the reader has to

request a new delegation from the back-end server. We use Our offline delegation transfer requires a tag and two two counters and to restrict delegated readers’ mobile readers (one to request delegation transfer, the access to a tag, as shown in Figure 4. Detailed steps are as other to transfer authorized query times). Both reader i and follows: reader j have to be delegated authority in advance to access Reader i Tag m tag m. We assume that reader i has run out of its delegated RIDi , Tlist i  {{TIDm , TIDm , Secretm , TSm , m m m m query times. It needs to request delegation transfer from m m RK i , RC i , DM i , ri }} Rlist  {{RID , RK ,TC }} m i i i reader j, so that it can acquire some extra query times to Generate r2 m 1. Request , RID , M access the tag. One particular requirement in our M2  LE(RKi ,TIDm || r2 ) Read i 2 flag  false delegation transfer is that the transfer must be performed If RID in Rlist i 1 under the same timestamp. Only in doing so can tag m Derive TIDm ', r2 from M2

If (TIDm  TIDm ') have full record of all delegated readers’ information. This m If (TCi  0) requirement also empowers our back-end server to use flag  true timestamps to restrict readers’ delegated authority. Generate r3 If ( flag  true) m m M3  LE(RKi ,TIDm || TCi || r2 || r3 ) Else m 2. M3 Derive TIDm ', TCi , r2 ', r3 from M3 M3  r3

If (r2 ' r2 ) and (TIDm ' TIDm ) m m RCi  TCi 1 m m M4  LE(RKi , RCi || r3 ) Else 3. M4 Derive RC m , r ' from M M4  r2 i 3 4 m m If (r3  r3 ') and (RCi  TCi 1) m m TCi  RCi

Figure 4. Steps of reader’s access to tag

Step 1: Reader i constructs by using to encrypt and a random number . Then it sends , its own identifier , and M2 to the tag m.

Step 2: Tag m checks if is stored on , and Figure 5. Message flow of offline delegation transfer look ups the to decrypt to obtains and . If matches , tag m checks if reader i has run Reader j provides tag m with the information required out of its query times. If , tag m allows reader i’s for delegation transfer. Once the tag approves the request, access. It generates a random number , and uses to it will update its own access control list and then the encrypt , , and . Then tag m returns the transfer of delegation is done. The transfer includes 6 steps, encrypted message to reader i. If a reader fails to pass as shown in Figure 6 and Figure 7. Reader i Reader j Tag m any of the verification, tag m returns as to reader i. RID , Tlist  {{TID , RIDi , Tlisti  {{TIDm , j j m TIDm , Secretm , TSm , m m m m m m m RK , RC , DM }} m m RKi , RCi , DM i }}, DCi j j j Rlist  {{RID , RK ,TC }} Step 3: Reader i uses to decrypt and then m i i i verifies whether the received and match its own m 1. Request Reader DT , RIDi , TIDm , DCi and . If they match, reader i can confirm is not Generate r4 M  LE(RK m ,TID || RID || DC m || r ) replayed and the sender of is tag m. Next, reader i 5 j m i i 4 2. Request , RID , M updates its counter, i.e. . Last, reader i Tag DT j 5 flag  false If RID in Rlist uses to encrypt the updated and . The j m m Derive TIDm ', RIDi , DCi , r4 from M5 If (TID  TID ') and (TC m  DC m ) encrypted message is returned to tag m as . If m m j i cannot be verified, reader i returns as to tag m. flag  true If RIDi not in Rlistm DC m  0 Step 4: Tag m decrypts with . Then tag m i Generate r5 verifies whether the received matches its , and If ( flag  true) M  LE (RK m ,TID || TC m || RID || DC m || r || r ) 6 j m j i i 4 5 whether the received has been updated, i.e. Else M6  r5 . If they are verified, tag m approves reader i’s 3. M 6 access and then updates its own counter , i.e. . Figure 6. Offline delegation transfer (1) D. Offline Delegation Transfer Protocol In our offline delegation transfer protocol, the access Step 1: Reader i sends to reader j a transfer request , its own identifier , tag m’s right of a reader can be transferred to another reader through tag m’s authorization. For example, the initial identifier , and requested query times . Step 2: Reader j generates a delegation transfer request query times of readers i and j are 3 and 18 respectively, i.e. and . Reader j uses the offline , and uses to encrypt , , delegation transfer protocol to transfer 10 query times to and . Next it sends the encrypted message , the reader i; at last the query time of reader i and j are 13 and 8 request , and its own identifier to tag m. respectively, i.e. and , see Figure 5.

Step 3: If is on tag m’s , the tag uses III. SECURITY ANALYSIS to decrypt and obtains , , and . Our protocol is designed to perform delegation transfer

Then the tag checks if and if . between offline readers. Without the involvement of It has to make sure that tag m is the tag that the two readers back-end servers, we use timestamps and access control try to access, and that reader j still has enough query times lists, e.g. and , to control readers’ delegated for delegation transfer. If is not on , will authority. Apart from these, we deploy hash functions to be set zero. At last, tag m approved the delegation transfer generate keys, add random numbers into our messages, by constructs by using to encrypt , , and use lightweight symmetric key encryption [6] [13] in our communications. All of these are intended to enhance , , and . our security and to lower the chance of attacks. Therefore, Step 4: Reader j decrypts with , and obtains our security analysis will particularly focus on mutual , , , , and . If they are valid, authentication, replay attacks, MITM attacks, forward reader j updates its maximum query times, i.e. secrecy, backward secrecy, guessing attacks, location . Then it constructs M7 by using to privacy, data privacy, and DoS attacks in asynchronous encrypt and and it sets the flag to . update. Then is returned to tag m and is sent to reader i. If A. Mutual Authentication the received data in is not valid, reader j returns as Our reader-tag communications are all encrypted with to tag m and checks . If , it means is not on and delegation transfer cannot be symmetric keys. Only with reader-tag shared keys, e.g.

and , can the two decrypt each other’s performed and will be set as to indicate messages and hence authenticate each other. Even though the illegitimacy of . If is not zero, reader j will adversaries intercept our delegation messages, their set as to signal the failure of delegation transfer, which may result from message loss or false readers cannot pass our authentication because the messages. messages contain delegated readers information. If they Step 5: If reader i receives or , try to use an intercepted message to perform authentication, they do it simply for a legitimate reader delegation transfer stops. If reader i receives whose identifier is in the message. Besides, without the from reader j, it will wait for tag m’s approval message keys they cannot even decrypt the intercepted messages. so that it can update its query times . B. Replay Attacks Step 6: Tag m decrypts with and obtains the updated and . If and match and Since we use nonce in our reader-tag communications, the messages will change in every session. Thus, attackers , tag m updates ’s and . That is, ; . Then the tag are unable to replay any legitimate messages to pass our authentication. However, during our offline mutual constructs by using to encrypt the updated , authentication, there is only one from a back-end , and . M is forwarded to tag i through tag j. If 8 server under the same timestamp. Here, malicious users is not valid, tag m terminates the protocol. Otherwise may take this opportunity to replay reader i’s message to reader i decrypts with and obtains and tag m. But since tag m only stores the information in the . If and match, reader i updates its first successful authentication, replayed messages are maximum query times, i.e. , and offline unable to change anything. Also, tag m’s responses delegation transfer is done. Reader i Reader j contain a nonce , which change in each communication. Tag m m RIDi , Tlisti  {{TIDm , RIDj , Tlist j  {{TIDm , RK j , TIDm , Secretm , TSm , So, despite the possibility of replay attacks in this part, m m m m m m m m m RKi , RCi , DM i }}, DCi RC j , DM j }},RIDi , DCi Rlist  {{RID , RK ,TC }} m i i i they cannot change anything. m m Derive TIDm ', TC j , RIDi ', DC i ' , r4 ', r5 from M 6 If (r ' r ) and (TID ' TID ) and (RID ' RID ) and (DC m ' DC m ) 4 4 m m i i i i C. MITM Attacks m m m RC j  TC j  DC i m m M 7  LE (RK j , RC j || r5 ) First, our reader-tag messages are protected with DT  DT confirm encryption algorithms. Second, in our delegation transfer Else M  r 7 4 or when a delegated reader accesses a tag, the update of m If DC i ' 0 DT  DT maximum query times requires the tag’s reconfirmation RIDi Error Else with the delegated reader. Since adversaries are unable to DT  DT Failed 4. M 7 launch replay attacks and they do not have or , 5. DT m Derive RC j , r5 ' from M 7 If (DT  DTconfirm ) m m m they are unable to counterfeit tags or to launch MITM Terminate If (r5 ' r5 ) and (RC j  TC j  DCi ) m m TC j  RC j attacks, either. m m m TCi  TCi  DCi M  LE(RK m ,TID || TC m || r || r ) 8 i m i 4 5 D. Forward Secrecy Else Terminate Because we use timestamps to control our delegated 6. M8 6. M8

m Derive TIDm ', TCi from M8 authority, once the timestamp is updated old delegation

If (TIDm  TIDm ') m m messages are all cleared. Old information will not be RCi  TCi exposed to new users. Hence, forward secrecy is secured. Figure 7. Offline delegation transfer (2)

E. Backward Secrecy delegation more useful and flexible in a mobile RFID environment. Our delegation message is protected by a session key . If Tag m wants to read the message, it needs to TABLE II. PROTOCOL COMPARISONS generate the key by hashing , and . Thus, Protocols Fouladgar Lee Yang Our even though attackers can obtain , they are unable to break because the session key is a hash value. Threats [5] [9] [15] scheme Mutual X ○ ○ ○ Attackers cannot trace back the elements of a hash authentication function from a hash value. Once changes in the Replay attacks ○ ○ ○ ○ MITM attacks ○ ○ ○ ○ next session, changes as well. Adversaries will not be able to track messages in following sessions. Hence, Forward secrecy ○ ○ ○ ○ Backward secrecy X X ○ ○ backward secrecy is secured. Guessing attacks X ○ ○ ○ F. Guessing Attacks Location privacy ○ ○ ○ ○ Data privacy ○ ○ ○ ○ Though our communications are all secured with keys, DoS attacks ○ ○ X ○ Offline delegation malicious users may eavesdrop on our messages and then X X X ○ launch guessing attacks. Therefore, we use random transfer numbers as responses when a reader or a tag fails to pass IV. PERFORMANCE our authentication. This can effectively lower the chance of guessing attacks. This section analyzes our protocol’s performance and compares our performance with that of other related G. Location Privacy studies. Here we use to denote the time for one Because we put random numbers in our lightweight en/decryption; : the time for one hash communications, our messages change in each session. function; : the time to generate a random number. Despite eavesdropping, eavesdroppers cannot even tell Table 3 depicts the detailed computation requirement for whether the messages they overhear come from the same our reader and tag when we run the delegation scheme. If tag. So, they are unable to track our tags’ location. there are errors during the communications, the loads can even be lower. When errors occur, we only respond with a H. Data Privacy random number. No further en/decryption will be required.

Our delegation message is protected by and our As for the target reader i, it only runs one lightweight reader-tag communications are secured with or encryption algorithm during delegation transfer. Therefore,

. That is to say, without these keys, attackers can by we leave it out of our analysis. no means pass our authentication and access our tags’ data. Besides, since replay, MITM and guessing attacks cannot TABLE III. COMPUTATION LOAD OF OUR PROTOCOL breach our protocol, we can say without a back-end Devices Reader Tag server’s authorization illegitimate reader are unable to Actions access our tags. Hence, tags’ data privacy is secured. Mutual authentication Reading I. DoS Attacks Offline delegation transfer Our tag does not change its keys during reading, offline As shown in Table 3, our use of random numbers in authentication, or offline delegation transfer. First, it almost every action helps us prevent guessing attacks. Since our mutual authentication requires a tag to store the acquires or from its back-end server’s delegation messages. Then it runs a hash function to first legitimate delegation message, a delegated reader generate a session key . Therefore, there will be no does not need to generate any random number for this action. It only needs one decryption. But a tag has to run a asynchronous update of keys in our protocol. Still, asynchrony may occur when has been updated but hash function to generate ; decrypt ; and encrypt . When a delegated reader access a tag, the is missing. and will stay the same. two’s computation loads are the same. The former needs Nonetheless, such asynchrony can be fixed up in the next two encryptions and one decryption and the latter one access. It will not affect our readers’ reading or delegation encryption and two decryptions. In offline delegation transfer. transfer, a tag has to encrypt for reader i, so its In Table 2, we compare our protocol with other computation load is one encryption more than reader j’s. delegation protocols. It is obvious that our scheme is able Next, we compare our scheme’s computation load with to resist most network threats and is capable of delegation that of other delegation protocols, as shown in Table 4. For transfer. Compared with Fouladgar et al.’s protocol, our an offline reader, when it searches a tag’s information in scheme achieves mutual authentication by securing our its authorization table, e.g. , the computation load reader-tag communications with lightweight encryption should be taken into account. In Table 4, we also assume algorithms. As mentioned above, our protocol is able to that the information of a tag to be accessed must exist in guarantee backward secrecy, which is impossible in the reader’s authorization table. In the cases of multiple Fouladgar et al.’s and Lee et al.’s schemes. The best part is access, i.e. a reader being delegated authority to access that our protocol is the only one capable of offline multiple tags, we divide the reader’s total computation delegation transfer in this comparison. Such ability makes loads by the number of tags. And we begin to count a tag’s

TABLE IV. TABLE VI: AVERAGE COMPUTATION LOADS OF DELEGATION PROTOCOLS. Devices Schemes Reader Tag

Hash-Based Hash-Based Fouladgar et al. [5]

Encryption-Based Encryption-Based

Same timestamp Same timestamp

Lee et al. [9]

Different timestamp Different timestamp

Same timestamp Same timestamp Yang [10] [15]

Different timestamp Different timestamp

Same timestamp Same timestamp Our scheme Different timestamp Different timestamp

computation load after it receives a reader’s request. Here we use to denote how many tags a reader is allowed to ACKNOWLEDGMENT access; : reader’s current timestamp; : tag’s current This work was supported in part by National Science timestamp; : the maximum value of a timestamp; : Council under the grants NSC101-2221-E-033-016-MY2. how many times a tag has been queried (a tag’s counter in Lee et al.’s scheme); : a reader’s current query times (a REFERENCES reader’s counter in Yang’s scheme); : the maximum delegated query times. [1] H. B. Chen, W. B. Lee, Y. H. Zhao, Y. L Chen, As shown in Table 4, we can find that it takes much “Enhancement of the RFID security method with ownership computation for a reader to verify a tag’s messages. And a transfer,” Proceedings of the 3rd International Conference tag’s computation load varies from scheme to scheme and on Ubiquitous Information Management and it is not affected by the number of delegated readers. Communication, pp. 251-254, 2009, Suwon, Korea. [2] EPCglobal Inc, Retrieved Jul. 11, 2013, from Though Fouladgar et al.’s protocol [5] demands low http://www.epcglobalinc.org/home computation for their reader and tag, their scheme is [3] S. Fouladgar, and H. Afifi, “A simple delegation scheme for unable to perform reader-tag mutual authentication and RFID systems (SiDeS),” Proceedings of the IEEE therefore is vulnerable to certain network threats. The International Conference on RFID, pp. 1-6, 2007, computation loads in Lee et al.’s approach [9] are highly Grapevine, TX, USA. influenced by their use of timestamps and by their key [4] S. Fouladgar, and H. Afifi, “An efficient delegation and updating. Every time when Yang’s tag receives a request transfer of ownership protocol for RFID tags,” Proceedings from a reader, it has to compute a complex hash chain to of the First International EURASIP Workshop on RFID generate a session key, so as to authenticate the reader. It Technology, pp. 59-62, 2007, Vienna, Austria. [5] S. Fouladgar, and H. Afifi, “A simple privacy protecting gets worse in their first query because the tag also needs to scheme enabling delegation and ownership transfer for add and into the computation. This has RFID tags,” Journal of Communications, pp. 6-13, 2007. caused quite a burden for an RFID tag since it only has [6] M. Hell, T. Johansson, and W. Meier, “Grain – a stream limited computing ability. cipher for constrained environments,” International Journal In our scheme, when under the same timestamp a reader of Wireless and Mobile Computing, vol. 2, no. 1, pp. 86-93, needs to run two en/decryption algorithms if the reader-tag 2007. authentication fails; three en/decryption algorithms if the [7] A. Juels, “RFID security and privacy: a research survey,” authentication is successful. Our reader’s average IEEE Journal on Selected Areas in Communications, vol. computation load will not outweigh other schemes’ 24, no. 2, pp. 381-394, 2006. [8] G. Kapoor, and S. Piramuthu, “Vulnerabilities in some readers. And our tag computes three en/decryption recently proposed RFID ownership transfer protocols,” algorithms in both situations. Judging from the average IEEE Journal of Communications Letters, vol. 14, no. 3, pp. computation loads, our proposed scheme has better 260-262, 2010. performance in every aspect. [9] N. Y. Lee, and Y. H. Lee, “Off-line authentication protocol for RFID tags,” Proceedings of The E-Learning and V. CONCLUSION Information Technology Symposium (EITS), pp. 34, 2008. In this paper, we propose a delegation transfer protocol [10] J. N. Luo, M. H. Yang, and P. Y. Hsu, “Enhanced to allow offline readers to transfer their delegated delegation transfer protocol for mobile RFID,” Proceedings of Cryptology and Information Security Conference 2011, authority to another authorized reader in the mobile RFID Yunlin, Taiwan. environment. Our protocol is also designed to secure [11] D. Molnar, A. Soppera, and D. Wagner, “A scalable, against certain network threats, such as replay attacks, delegatable pseudonym protocol enabling ownership MITM attacks, DoS attacks in asynchronous update, transfer of RFID tags,” Proceedings of Selected Areas in counterfeit tags, and guessing attacks. It can guarantee Cryptography, vol. 3897, pp. 276-290, 2005. forward/backward secrecy, data privacy, and data privacy.

[12] K. Osaka, T. Takagi, K. Yamazaki, and O. Takahashi, “An Jia-Ning Luo holds a PhD degree in efficient and secure RFID security method with ownership Computer Science of National Chiao transfer,” Proceedings of International Conference on Tung University, Taiwan. He specializes Computational Intelligence and Security, vol. 2, pp. in network security, operating systems, 1090-1095, 2006. network administration and network [13] A. Poschmann, G. Leander, K. Schramm and C. Paar, “New programming. He is currently working Light-Weight Crypto Algorithms for RFID,” Proceedings on NFC-based protocols; RFID of International Symposium on Circuits and Systems (2007. ownership transfer; eWallet security. ISCAS), pp. 1843-1846, 2007. [14] M. H. Yang, and J. N. Luo, “Authentication protocol in mobile RFID network,” Proceedings of the Fourth Ming-Hour Yang received his doctoral International Conference on Systems (ICONS), pp. 108-113, degree in Computer Science & Info. 2009. Engineering at National Central [15] M. H. Yang, “Controlled delegation protocol in mobile University, Taiwan. His research mainly RFID networks,” EURASIP J. on Wireless focuses on network security and system Communications and Networking 2010. doi: security with particular interests on 10.1155/2010/170150. security issues in RFID and NFC security [16] M. H. Yang, “Across-authority lightweight ownership communication protocols. Topics transfer protocol,” Electronic Commerce Research and include: mutual authentication protocols; Applications, vol. 10, no. 4, pp. 375-383, 2011. secure ownership transfer protocols; polymorphic worms; tracing mobile attackers.