An Efficient and Secure Method for Simultaneous Ownership Transfer of Multiple Mobile Readers

In recent years, radio frequency identification technology has developed rapidly and has been applied in supply chains. Products in supply chains are varied and may belong to several different owners. Ownership transfer requires the consent of a majority of owners. This article proposed a method suitable for simultaneously transferring the ownership of a large number of goods. The method does not require a trusted third party and can securely and efficiently transfer group ownership for multiple owners with multiple tags. The old and new owner groups can be classified as different authorities. This method can be used in mobile readers to transfer one, some, or all tags in a group. It includes mutual authentication between tags, readers, and backend servers, and can ensure that only assigned owners can obtain the tag ownership. The method proved can resist most known attacks, such as secret disclosure attacks and replay attacks. It can also prevent attacks from the dishonest original owners. Finally, through experiments, we compared the proposed method with other many-to-many ownership transfer methods and demonstrated that the proposed method has better security and fewer transmitted messages than other methods.

and more flexible read and write speed, higher reliability, and robust performance. However, EPC Gen2 might yield to security and privacy violations if not handled properly. The RFID tags can be accessed by any nearby readers, which means that anyone could use the RFID tags to track items or identify the people associated with them through time and space [4].
Ownership transfer is a secure process of transferring ownership from old owners to new owners. In a supply chain management system, the manufacturers manufacture a product with RFID tag and sell it to a reseller and then to the consumer, the ownership of the tag is transferred to the last owner (the consumer), and the tag information is also transferred in the end of the process [5].
Ownership transfer schemes are categorized by the number of readers and tags involved in the transfer, such as one reader on one tag [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], one reader on multiple tags [16], [17], [18], [19], [20], and multiple readers on multiple tags [21], [22], [23]. Osaka et al. [7] proposed the one-to-one ownership transfer method. However, in this method, the message for updating the key may be tampered with by attackers, resulting in a desynchronization attack (DA). Forward security (FS) cannot be ensured, and the windowing problem (WP) cannot be avoided [24], [25]. Although Jappinen and Hämäläinen [26] inspected the integrity of the updated key's message to reduce the possibility of asynchrony between the tag and the backend server, they were unable to eliminate the problem because the method of inspecting the updated key's message could still be tampered with by an attacker [25]. Thus, Chen et al. [8] proposed a new protocol for avoiding FS and DAs. However, this method still had problems in terms of backward security (BS), inability of ensuring the privacy of the location, and the WP [9], [27]. Shen et al. [11] proposed using Chebyshev polynomials to ensure secure transmission during ownership transfer. By reducing the amount of message necessary for transfer protocols, efficiency was increased. However, if the attacker initiated an attack within the time threshold value, replay attacks (RAs) could still occur. Yang and Hu [28] proposed the self-organized time-division multiple access protocol that can support mobile readers without requiring trusted third party (TTP) for the transfer of tag ownership, resolving all of the aforementioned attacks. Aghili and Mala [29] proposed an ownership transfer protocol that could handle a dishonest original owner. The protocol prevents the original owner from attempting to regain ownership immediately after transferring ownership. Although the protocol could prevent attacks by the original owner, it was only effective for transfers of one tag at a time. Ownership could not be effectively transferred for a large number of tags.
In addition, in recent years, some studies have used blockchain technology to perform ownership transfer [12], [13], [14]. In [14], the transferred information is recorded on the blockchain using smart contracts of the Ethereum system.
To overcome this previous owner attack (OA), conducting attacks to secret disclosure after ownership transfer, and to protect owner privacy [29], this study proposes a multiowner multitag group ownership transfer (GOT) protocol that does not require a TTP, is secure, and is efficient. In the proposed method, the old and new owner groups are divided under different authorities. When an old owner asks for ownership transfer, we examine whether the number of agreeing owners exceeds a threshold to determine whether to transfer ownership. The ownership of the tag can then be safely transferred to the new ownership group. The proposed method has the following advantages.
1) This method can be used with mobile readers.
2) It can transfer tags belonging to two different authorities.
3) This method can transfer ownership for one tag, some tags, or all tags. 4) Mutual authentication between the tags, the readers, and the backend server occurs. 5) Only the designated multiowner can obtain ownership of the tag. 6) Ownership transfer can be conducted when most owners agree. 7) It prevents attacks by the original owner. 8) The proposed secure ownership transfer protocol can prevent secret disclosure attacks (SDAs), tag/reader impersonation, RAs, and message modification. It also provides FS and BS and prevents the WP. 9) The ownership transfer protocol is efficient. The method is effective for any number of readers and tags. An increase in owners or tags does not substantially increase the number of messages or the computational requirements. The rest of this article is structured as follows. Section II describes the related work of ownership transfer protocols. Section III introduces the settings for an ownership transfer protocol and the relationship between tags, readers, and backend servers. Section IV details the proposed protocol. Section V analyzes the security of this ownership transfer method and compares it to relevant studies. Section VI analyzes the performance of this method and compares it to relevant studies. Finally, Section VII concludes the article.

II. RELATED WORKS
A factory at the beginning of a supply chain typically conducts ownership transfer for a large number of products simultaneously. Zuo [16] proposed a method for this situation. It involved using a group key to simultaneously verify and transfer ownership of multiple tags. However, a DA was possible when the key is updated at the end of the process [11]. Jannati and Falahati [17] proposed a method that increased the difficulty of an attack after updating a key. However, this method could only transfer all of the tags at once; it could not transfer only some tags. Lee et al. [19] integrated quadratic residue theory and homomorphic encryption to strengthen security. They used a cloud server to increase the efficiency of the method. However, their proposal still had problems, including SDAs, reader impersonation attacks (IAs), tag tracking, and FS [30]. Moazami and Safkhani [30] solved these problems and solved the DA in [31]. Yang [18] proposed a protocol for the ownership transfer of a group of tags. The method used the group communication key shared by the backend servers and the tags to generate a partial group communication key to transfer the ownership of all tags in a group simultaneously. In addition to supporting mobile readers, the method could fend off most known attacks. However, the method still has the WP in which the previous and new owners simultaneously have ownership before a TTP updates the key for the tags [27]. Tsai et al. [20] and Yang et al. [33] proposed a method of ownership transfer and grouping proof. In the protocol, the ownership transfer of a subset of tags can be conducted, and the method could ensure that the tags within a group were simultaneously and comprehensively transferred. Lee et al. [34] proposed a time bound group ownership delegation protocol based on homomorphic encryption and quadratic residue that is similar to their GOT protocol [35]. Kumar et al. [36] proposed time bound group ownership delegation protocols, which will revoke the ownership after a certain period of time, and over time, the ownership is revoked. Moazami and Safkhani resolved the security issues in [35].
If a product simultaneously has multiple owners, such as a product purchased by a joint venture, ownership cannot be transferred with the agreement of just one owner. The agreement of the majority of the owners must be obtained to conduct ownership transfer. Kapoor et al. [21] proposed a multiowner group tag ownership transfer protocol. However, the TTP's protocol is threatened by RAs and DAs 0. Moreover, the method could only transfer ownership for one tag. To transfer the ownership of numerous tags, the protocol must be run once for each tag, resulting in poor efficiency. Sundaresan et al. [22] proposed a TTP-based lightweight multiowner multitag ownership transfer method. However, for each tag and owner, substantial messages, calculations, and transmission time were required. Moreover, this method had difficulties with tag tracking and suffered from the FS problem [35]. Luo and Yang [23] proposed a group tag ownership transfer protocol via TTP. The protocol supports multiple transfers, and only assigned owners could participate in the ownership transfer. Most attacks could be prevented. However, the WP of dishonest owners remained. Previous owners could take back ownership before the tag key is updated [29].

III. OWNERSHIP TRANSFER METHOD INVOLVING MULTIOWNERS TRANSFERRING MULTITAGS
In this study, we proposed a novel RFID ownership transfer mechanism without using a TTP. In our system, there will be multiple owners who jointly own a group of RFID tags. To initiate the ownership transfer process of the RFID tags, a majority of owners must first agree to the transfer. After confirmation of the agreement, a delegated mobile reader will transfer the ownership of a subset of the tags to another group of owners. The contents of the selected RFID tags will also be transferred from the original owners' server to the new owners' server. We assume that the tag has limited computing power. In order to avoid tags from becoming a bottleneck, tags will only use lightweight ciphers. The detailed system structure is described in the following sections.
The proposed framework is presented in Fig. 1. In the original ownership group, one member's mobile reader R i 1 initiates the ownership transfer. Most readers in R i−o respond and agree to the transfer of ownership. Then, a message is sent to the new owners' reader R j−n to transfer ownership. The details of the process are described in Section IV. Fig. 1 indicates that mutual connections are required between server and server, server and mobile reader, and mobile reader  and tag. On the basis of the computing capacity of these devices, we divided these connections into two parts for the discussion. The dashed lines (1) and (2) in Fig. 1 indicate secure communications channels between servers and the mobile readers. The radio symbol (3) in Fig. 1 indicates the wireless secure communication channels between the mobile readers and the tags, but the encryption methods that establish secure communications between tags and mobile readers are relatively weak [44] due to the limitation of RFID tag's hardware. The wireless channels are under threat of attacks, such as eavesdropping attacks, RAs, and man-in-the-middle attacks (MitMs). The symbols and their definitions are presented in Table I.
We assumed the environment for the ownership transfer of tag management services had four characteristics.
First, the backend server manages and stores the ownership relationship between all mobile readers and tags, as presented in Fig. 2. For example, suppose D i and D j each manage three mobile readers Mobile readers, such as R i 1 , do not store ownership data; they are only responsible for transferring messages. Mobile readers are each controlled by only one server. The backend server managing ownership transfer with mobile readers may be controlled by the same or different authorities. We assumed that a mobile reader has one owner to simplify the introduction of the ownership transfer process. Among the backend servers D i , the server numbered DID i has authority over a total of m readers. Any one reader R i m has an independent number RID i m . For a reader R i x controlled by D i that intends to transfer the ownership to reader R i y under D j 's authority, the relationship in (1) must be satisfied Second, each mobile reader has ownership of one or more tags. Each tag belongs to one or more owners. As presented in Fig. 2, the mobile readers To facilitate the description of GOT, we use G o s (see Fig. 3) to indicate the three tag groups that are to be transferred out, where The set of readers that co-own the tag group the reader set R i−o that co-owns the tag group G o s comprising of p tags would like to transfer the ownership of G o s 's ownership to the nth owner of the reader set R j−n that co-owns the tag group G n s comprising q tags, these reader sets and tag sets must satisfy the relationship in (2). A reader of an old owner does not transfer any tags to any reader of an original owner, and no tags are shared by either transferring party Third, to use a broadcast message to simultaneously transfer part of the group of tags in the reader set R i−o containing the tag group G o s with p tags, we generate a k-ary group key tree. The height of the tree is h max = log k ( p k ) + 1. The numbering sequence of the k-ary group is from top to bottom and left to right. The parent node number is G o s−1 k , and the child node numbers are from G o s * k+1 to G o s * k+k . The numbering rules are presented in Fig. 4(a). We divided the group into a 3-ary group key tree (k = 3), and we defined the key at the top layer that owns all tag groups as GK o 0 . The group relationships are presented in Fig. 4 Fourth, the definition of a leaf group is a group con-  backend server D j has a key tree; thus, the right side of Fig. 5 indicates that on the transfer of a key tree tag to the multiowner reader group R j−n , the tag is inserted on the far right of the tag group G n 2 . The tag names are T 4 n , T 5 n , and T 6 n . The tag number in R j−n may not be the same as that in R i−o . This example reveals how each server can provide its controlled tags with unique numbers; thus, number overlaps between servers will not occur. The process is described in detail in Section IV.

IV. MULTIOWNER MULTITAG OWNERSHIP TRANSFER PROTOCOL
In this section, we propose a new RFID protocol for transferring the ownership of some or all of a group of tags with multiple owners. The protocol contains three stages: initial, obtaining group tag transfer licensing, and transferring group tag ownership. During the initial stage, each participant must securely obtain the shared key. Next, group tag transfer licensing is obtained. The old owner first confirms that most owners agree to transfer ownership and collect the tag information. Next, group tag ownership is transferred. The tag information is verified, and the key and the secret value for the server assuming ownership (the receiving server) and for the tag are updated.

A. Initial Stage
Before implementing the protocol, each participant must securely obtain a shared key (see Fig. 6).
1) Servers D i and D j share the key K ij .
2) The server that initially owns the tags (the sending server), D i , and its reader set, The receiving server D j and each reader in the reader set

B. Obtaining Group Tag Transfer Licensing
Without loss of generality, Fig. 7 shows that any reader R i 1 of the ownership group R i−o may initiate ownership transfer, transferring part of the tag groups G o s to the reader group R j−n . Reader R i 1 uses the key K i 1 it shares with the server D i to encrypt the ownership transfer request OT request , the server identification code of the receiving server DID j , the multiowner reader set of the object transferred into R j−n , the tag group to be transferred G o s , and the random number N r used to generate message M 1 sent to server D i to bind the objects to be transferred. When The signed MP S x and the random number N r in M 2 are be encrypted using the key K i x shared by both parties to form message M 3 , which is sent to server D i .
When D i receives M 3 from any reader R i x in the reader set R i−o , it uses the key it shares with that reader K i x to decrypt the message. If the message includes the random number N r sent to the reader, as the signature example in (3, m) in Fig. 8, readers R i 1 , R i 2 , and R i 3 return part of the signatures MP S 1 , MP S 2 , and MP S 3 , respectively. Then, a threshold signature is generated [43]. D i uses the public group key UGK i of the reader set R i−o to verify whether the number of owners agreeing to transfer ownership surpasses the threshold value. D i uses the group key GK o s to encrypt the confirm message OT Conf irm , the group tag number that is to be transferred, GID o s , and a random number N r . If the threshold is not met, OT Conf irm is replaced with OT F ail , and together with GID o s and N r , message M 5 is generated. This process inhibits guessing attacks (GAs) by attackers pretending to be readers. Finally, M 5 is encrypted using the key K i 1 shared by the owner reader R i 1 to produce message M 4 , which is sent to owner reader R i 1 .
After the owner reader R i 1 receives M 4 , it uses the shared key MT v is encrypted using the key K i 1 shared with D i to generate message M 7 to send to the managing server D i of R i 1 . If so, server D i then uses key K ij shared with the receiving server D j to encrypt the ownership transfer request OT request , the server identification code of the transfer object DID j , the multiowner reader set of the transfer object R j−n , group tag G o s , and random number N r to create message M 8 to send to D j . D j prepares to update the shared key on the tags.

C. Transfer the Ownership of a Tag Group
When D j receives message M 8 , it uses the shared key K ij to decrypt the message. It first verifies whether DID j is the same as that received and verifies whether R j−n is under DID j 's authority. If the verification is successful, D j uses key K ij  shared by both servers to encrypt D j 's confirmation message OT Conf irm and the hashed secret value H(S j−n ) to create message M 9 to return to D i .
When D i uses the shared key K ij to decrypt M 9 , it verifies the random number N r to avoid RAs. It also checks for OT Conf irm . If so, a new group key GK n is generated and the Chinese remainder theorem (6) is used to calculate message M 10 to send the new group key GK n to each tag Then, the key K ij shared by both servers is used to encrypt the reader set R j−n , the group number If the random number is incorrect or if it receives a failure message OT F ail , another random number N r is generated to replace the random number in M 13 . This procedure prevents attackers from conducting GAs.
When D j receives the ownership transfer message M 11 from D i , it uses the shared key K ij to decrypt M 11 . Server D j first verifies whether R j−n is under the authority of D j . Then, after D j obtains the group tag G o s , it transfers the tag to reader R j−n and obtains group key GK n . It also uses the group key encryption tag identification T ID n v to add each tag T ID n v , the new shared key of the backend server T K n v , and the group key GK n s into the corresponding cells in the database T ID n v of D j , as shown in the top of Fig. 5.
After the owner reader R i 1 receives message M 12 , the key K i 1 shared with D i is used to decrypt, and then M 13 is directly broadcast to the tags. After the tags receive M 13 , they first use GID o s to confirm that the message includes the group tag G o s , and then they use the group key GK o s to decrypt the message and verify the random number N r and the hashed secret value H(S i−o ). After verification, the tags conduct a modulus operation on M 10 and their own keys T K o v . Next, they conduct exclusive or computing (XOR) with T K o v to obtain the new group key GK n . Subsequently, the hashed secret value of the original owner, H(S i−o ), is updated to the hashed secret value of the new owner, H(S j−n ). The new group key GK n is used to encrypt tag identification code T ID n v to replace the key T K n v shared by the tag and the receiving server D j . Finally, the group key is updated in GK n s .

D. Transferring Multiple Group Tags Simultaneously
If the transferred tags belong to the same group, transfer is only conducted once. However, if the number of tags to be

E. Update Groups and Balance Key Tree
After the proposed ownership transfer protocol is used to update the shared key of each tag and the receiving server and the tag group key, the group tags join the tag group under the authority of the receiving group. When tags join or leave a group, we must add or delete the group key because if the key tree is imbalanced, transfer efficiency is reduced. In the worst case, a tag must store p group keys. Thus, we can use the balanced tree management protocol proposed by Ng et al. [44] to solve the key tree imbalance problem following tags joining or leaving a tree. Moreover, we can use the method proposed by Xu and Huang [45] using maximum distance separable codes, to update group keys. The key of a child group can use the maximum distance separable matrix to calculate an update message and broadcast it to the tag groups. Tags owning a child group key can use the received update message to calculate the new parent group key. Moreover, they proved that using the key tree to build 3-ary trees results in the fewest calculations and optimal efficiency. We can use these methods to update the group communication key and to balance the key tree.

V. SECURITY ANALYSIS
In the proposed method, we have three different communications channels: 1) between backend servers, 2) between backend servers and mobile readers, and 3) between mobile readers and tags. It is easy to establish secure communication in the first two channels by using modern cryptography tools. Due to the limitation of RFID hardware, many cryptographic models of security fail to express important features of RFID systems [32], therefore the third channel is not secure; thus, this section discusses common threats during ownership transfer, such as secret disclosure, replay, man-in-the-middle, tracking, desynchronization, tag/reader impersonation, windowing, dishonest original owners, and FS and BS.

A. Prevent SDA
The protocol must prevent attackers from obtaining sensitive information from messages exchanged by participants. In our protocol, preshared symmetric key encryption was used. The attacker cannot obtain the preshared key, nor can they read the encrypted messages.

B. Prevent RAs
Attackers may eavesdrop on messages and store them. Therefore, protocols must prevent attackers from replacing messages with previously stored messages. In our protocol, a random number N r is generated and encrypted with the message during each stage of the communication process. Thus, messages in each ownership transfer are unique and cannot be replayed.

C. Prevent Tag Tracking Attacks (TAs)
A protocol must prevent attackers from tracking the locations of tags. Even for the same tag, the messages differ due to the random number N r and changed tag keys. Thus, attackers cannot analyze the relationship between messages by obtaining several messages, nor can they decrypt the message content to obtain the tag identification code T ID o v . Thus, they cannot track tag locations.

D. Prevent DAs
A protocol must prevent attackers from denying key updating or causing message loss resulting in asynchronous keys and unreadable tags. Because messages are encrypted using a key and N r , we only consider the situations in which messages are blocked by an attacker or are lost during transmissions. Until the key is updated, tags are still owned by the sending server. During protocol execution, if any message is lost or blocked, the process can be restarted. The backend server stores the initial key before the final tag key update; thus, if a tag does not update its key, the server can still use the previous key to communicate with the server.

E. Prevent Tag/Reader IAs
The protocol can prevent attackers from impersonating a tag or reader to gain ownership. are transmitted to the tag securely during the registration stage. Because messages transmitted during this process are encrypted by the key, the attacker cannot decrypt the message and thus cannot impersonate the tag. To impersonate a reader, attackers must obtain DID i , DID j , R j−n , G o s , and K i 1 . However, these were also all securely transmitted to the reader during the registration stage; thus, attackers cannot impersonate readers.

F. Prevent MitMs
The protocol must prevent attackers from intercepting messages, editing their content, and resending them. Because all messages are encrypted with the random number N r , which is made at the beginning during communication, attackers cannot impersonate tags or readers to modify the message. Attackers also cannot use RAs. Thus, they cannot impersonate tags or readers to conduct MitMs.

G. Prevent WP
A protocol must avoid situations in which both the old and new owners simultaneously have ownership of a tag. During the final key update, the sending server simultaneously transmits the key to the receiving server and the tag, and updates the secret value, the tag, the key shared by the servers, and the group key of the tag. After this update, the old owner no longer has ownership. The old owner or attackers also cannot replay the key update message from the previous stage to update the key on the tag. Thus, we can avoid the WP.

H. Reduce GAs
Although messages are encrypted, communications between readers and tags use wireless communication; thus, attackers can infer that the transfer has failed if no message is transmitted. Otherwise, the transfer was successful. An attacker can use this information to conduct a GA. Message M 13 is an example of how the protocol avoids this attack. If the verification fails, only the random number is changed, and a message of the same length is transmitted. Thus, attackers are prevented from guessing the transmitted content. However, an attacker can attack successfully in two situations.
First, the attacker can use brute force to guess the final updated key message M 13 to cause the key of the tag and the server to be asynchronous. If the message after encryption is d bits, the probability of guessing the correct message is 1 2 2d . Second, an attacker may have eavesdropped on all steps, collected all messages transmitted between tags and readers, and intercepted the last updated key message M 13 . Next time the reader generates the same random number N r , an attacker can replay an intercepted message to cause the key of the tag and the server unsynchronized. The probability of this occurring is analyzed using the birthday problem. The probability of success is approximately 1 − e − u 2 2 d+1 , where u is the number of attacker attempts. If the random number is 32 b, the attacker must intercept 9.3 × 10 3 messages to achieve a success rate of 1%.

I. Backward Security
The key shared by the tag and the server is not directly sent to the next owner. Instead, a randomly generated group key and tag identification code are encrypted to generate a new shared key. Thus, the new owner cannot use the new shared key to decrypt the content in the tag about previous transactions.

J. Forward Security
In the final key update, the sending server simultaneously transmits the new key to the receiving server and the tag. Readers of the sending server are only responsible for transmitting the message. Even if a sending server's reader obtains this message, it cannot decrypt the content because it lacks the new shared key.

K. Dishonest Original Owner
A previous owner may be an attacker; after ownership is transferred, they immediately carry out an attack to regain ownership. In our protocol, we update the secret value of the tag, the shared key of the servers, and the group key after ownership transfer. Moreover, we ensured BS and avoided the WP; thus, after the new owner updates the key and calculates a new secret value and key, the old owner cannot regain ownership.
We compared our protocol and other ownership transfer methods. We compared SDA, RA, MitM, TA, DA, IA, the WP, GA, FS, BS, dishonest original OA, GOT, transferring partial tags (OPT), assigning transfer target (ATT), and partial owner agreement (POA). The symbol O indicates that a protocol is secure for the attack, X indicates that the protocol is vulnerable to the attack, and means that the protocol is not completely secure. Table II reveals that other protocols are vulnerable to some attacks. For example, the protocol of Kapoor et al. is vulnerable to WP and DA because the attacker can intercept the key update message. It is also vulnerable to RAs and TAs [38]. In the protocol of Sundaresan et al., an attacker can decrypt messages to obtain secret values and can replay messages; thus, the method is vulnerable to RA and TA and lacks FS [35]. Moreover, although that protocol could simultaneously transfer multiple tags, it allows ownership transfer without the consent of a majority of owners. Thus, this protocol is incomplete in terms of group ownership. Although the protocol of Luo and Yang can prevent most attacks, it is vulnerable to a dishonest original owner [29]. TBGODP + proposed by Moazami and Safkhani [37] cannot provide partial ownership transfer. Although they claim that they use threshold signature to obtain the agreement of most owners, their protocol does not include a comprehensive partial signature and inspection process. Thus, only our proposed protocol is secure from all existing attacks. Specifically, our protocol is superior to others in that only our protocol is secure for a dishonest old owner. Moreover, we use Proverif [48], a cryptographic protocol verifier in the formal model to prove the correctness of our protocol. The result shows that our protocol is secure.

VI. PERFORMANCE ANALYSIS
In this section, we analyze the calculations and the number of messages required for the proposed ownership transfer protocol. To fairly compare our method with other methods, we assumed that there are m old owners and n new owners, and p tags are successfully transferred. T E , T LE , T P RNG , and T H indicate the time required for conducting one encrypting or decrypting calculation, for one lightweight encrypting or decrypting calculation, for generating a random number, and for conducting a hash function calculation, respectively. Each time the server generates a key, we conduct one T P RNG . The time required for a reader to generate a partial signature is T SIG , and the time required for the server to generate and verify a signature is T V E . Because the key required for each reader to generate a partial signature is generated before the protocol, the generation time is not included in the calculation time. Compared with the time required for cryptographic calculations, the time required for logical calculations is negligible. Thus, logical calculations were not included in the analysis. Table III reveals that if the number of tags is large, the required calculation time of Kapoor et al. is excessive. The protocol proposed by Sundaresan et al. only involves lightweight computational pseudo-random number generator (PRNG); thus, its reader and server require few calculations. However, the protocol has several security problems. The protocol also does not require majority owner agreement before conducting the transfer. Moreover, this protocol can only transfer all tags from the owners all at once; it cannot transfer a subset of the tags. These limitations enable the protocol to have favorable performance for the reader and the server. Still, that protocol owners cannot use a single broadcast message to transfer all tags but must use the group key for each tag to generate transfer messages. Thus, the calculation time is determined by the number of owners and tags, affecting the performance. Compared to the method of Luo and Yang, the proposed protocol does not require additional processing or calculations for communicating with a TTP. Moreover, if the server asks owners whether they agree to the ownership transfer, the protocol of Luo and Yang involves using the key shared by the server and each owner to generate individual messages and transmit them to each owner. Our protocol only generates one message and broadcasts it to all owners to reduce the required calculations. Thus, although the proposed method requires partial signing and verification so to obtain majority owner approval, our computational efficiency is still superior to that of Luo and Yang.
As an example, the number of the original owner and the new owners both as 10, the lightweight symmetrical key encryption method for the RFID tags as DES lightweight extension (DESL) with each encryption and decryption requires 144 cycles and the general symmetrical key encryption method as AES-128 with each encryption and decryption requires 1032 cycles [40]. For an RFID tag with a computational speed of 3.55 MHz clock cycle in a second [46], we calculated the clock cycles and obtained the time required for ownership transfer. We used the method of RSA+digital signature algorithm (DSA) to calculate the time required for the threshold signature verification. The time required to generate a partial signature is 5 ms, and that for synthesizing and verifying a signature is 26 ms [47]. Logistics applications typically require numerous objects to be transferred; thus, to analyze these multitag protocols' performance in logistics applications, we increased the number of tags from 100 to 25 600 to observe changes in the calculation times of these protocols. Fig. 11 presents the computations conducted by readers. The protocol proposed by Kapoor et al. can only transfer one tag at a time; thus, its calculation times increase rapidly as the number of tag increases. The protocol of Luo and Yang cannot use broadcast messages to communicate between servers and readers to obtain partial signatures for the readers. The protocol of Sundaresan et al. has the shortest reader calculation time primarily because that method only used lightweight computational element PRNG, does not conduct extra calculations to gain majority owner approval, and because it does not calculate the partial group key required for transferring a subset of tags. These limitations result in their protocol having several security problems.   at a time; thus, its calculation times increase rapidly as the number of tag increases. The protocol of Sundaresan does not conduct extra calculations to gain majority owner approval, so its calculation time is substantially reduced. However, because the owner cannot use a single broadcast message to transfer all tags but instead must use the group key to generate a transfer message for each tag, if the number of tags exceeds approximately 20 000 the required calculation time exceeds that of our method. Fig. 13 presents the calculations required by the tags. Because the method of Kapoor et al. requires executing the entire protocol for each transferred tag, the calculation time rapidly increases as the number of tags increases. Because the tag calculations in our protocol are only four lightweight encryption and decryption calculations for each tag (see Table III), which is far lower than other protocols, our protocol requires the least calculation time.
Compared with readers and servers, tags have limited calculation ability; thus, the tag calculation amount is typically a performance bottleneck and should be reduced. Our protocol substantially reduces the calculation burden for tags. Fig. 13 indicates that for any number of tags, the calculation time required by our method is less than that of other methods. For readers, because both our protocol and the protocol of Luo and Yang require owner consent and because the time required for signature and verification is 5000 times greater than for regular encryption [40], [47], both methods require more time than Sundaresan et al. did. However, as presented in Table II, this step is required for security.
In addition to the calculation time, the number of messages required to complete a protocol is a major factor affecting a protocol's performance. Because the network delay time is typically far greater than the calculation time, sending fewer messages substantially affects the performance of the algorithm. Table IV compares the number of messages required by our protocol and by other protocols. Table IV reveals that the required number of messages increases rapidly as the number of tags increases in Kapoor et al.'s protocol. For the protocol of Sundaresan et al., the number of messages also increases rapidly as the number of tags and readers increases. In the protocol of Luo and Yang, the server cannot use a single message to ask whether each reader agrees to transfer ownership. Moreover, when collecting tag information, each tag must send a message to the server via the reader; thus, the protocol generates a higher number of messages than our proposed protocol. Fig. 14 presents the correlation between tag number and the number of messages. If the number of tags is small, the numbers of messages sent in the protocol do not vary substantially. If the number of tags exceeds 400, a clear difference can be observed between protocols. Both the protocols of Kapoor et al. and Sundaresan et al. require quickly increasing numbers of messages as the number of tags increases. Also, the number of messages required by our method is approximately half of that of Luo and Yang's protocol.

VII. CONCLUSION
In this article, we proposed a secure RFID ownership transfer protocol with multiple owners and multiple tags. Our proposed protocol is the only protocol that can obtain agreement from a majority of owners before transferring the ownership of a subset of a tag group. Compared with other multiowner multitag ownership transfer methods, our method is the most secure and requires the fewest messages transmitted; thus, it has the highest computational efficiency. The protocol uses partial signature to confirm whether the number of agreeing owners exceeds a threshold value. We proved our protocol can resist the most common attacks during RFID ownership transfer, such as secret disclosure, replay, man-in-the-middle, tracking, desynchronization, tag or reader impersonation, the WP, and GA. We ensured FS and BS and could assign the transfer subject. The method was also not vulnerable to attacks by the previous owner.
To verify the performance of our method, we used experimental analysis to compare our protocol and other protocols in terms of the computational efficiency and the number of messages required for the tags, readers, and servers participating in the protocol for a set number of owners. The experimental results showed that compared to other multiowner multitag transfer methods, the proposed protocol required fewer messages and computations, and thus could have practical applications in the logistics.