Dispute Resistance Multilayered RFID Partial Ownership Transfer With Blockchain

Frontend supply chains involve the transfer of large quantities of products. Therefore, incomplete transfer and product loss are inevitable. This paper presents a high-efficiency group ownership transfer protocol that incorporates blockchains to enable the efficient transfer of large quantities of products and prevent disputes regarding transfer completion. This protocol collocates authenticated information of a manufacturer with its exclusive blockchain address to generate an initial transaction block. The blockchain is then used to trace the original product manufacturers to prevent counterfeiting, and a grouping proof is employed to prevent disputes regarding transfer comprehensiveness. The proposed protocol was capable of resisting common off-chain radio frequency identification ownership transfer attacks, indicating its security. A security testing tool was employed to prove whether the on-chain smart contracts could also resist the attacks on blockchain. The analysis and experiment results revealed that the proposed protocol required fewer messages for ownership transfer and half the calculation time compared with the existing protocols. Thus, for the simultaneous transfer of ownership of a massive number of tags, the proposed protocol is the most efficient, with a reduced calculation time, thus making it most suitable for bulk cargo ownership transfer in the frontend supply chain environment.


I. INTRODUCTION
According to the prediction by Statista, e-commerce is flourishing [1]. In 2020, the global retail e-commerce sales amounted to US$4.28 trillion in 2020 and are predicted to grow to US$5.42 trillion in 2022 at a growth rate of 26%. To improve cargo management efficiency, product supply chains began to apply radio frequency identification (RFID) tags on products for automatic inventory and ownership management.
Ownership transfer in a product supply chain is carried out at the backend as well as the frontend [2], [3]. Retailers and consumers in the backend supply chain transfer the ownership The associate editor coordinating the review of this manuscript and approving it for publication was Jiafeng Xie.
of only a few products each time. Because of privacy concerns related to individuals' consumption habits and purchase of sensitive products, studies on single-tag ownership transfer [4], [5], [6], [7], [8], [9], [10] have focused on security and privacy issues but have overlooked problems associated with transfer efficiency [3]. By contrast, manufacturers and wholesalers in the frontend supply chain may transfer the ownership of a large quantity of products each time. Therefore, group tag transfer protocols have been proposed to enhance the efficiency of bulk cargo ownership transfer [11], [12], [13], [14], [15], [16], [17], [18], [19]. However, because of the sheer quantity of products, preventing incomprehensive transfer, accidents, or employee theft during transportation is difficult, which may hinder the successful delivery of the products to their destinations, incurring disputes. Theft that occurs in the supply chain, with up to US$30 billion being lost each year [20]. On average, participating retailers attributed the greatest portion of losses (33.2%) to external theft, followed by internal employees [21].
Consumers and government worldwide have begun to emphasize traceability [22] to ensure that their products come from desired manufacturers. Therefore, product supply chains have employed RFID tags on products to record production, storage, and sales information in all stages in a supply chain. Consumers read these tags and acquire product information through an object name server, which helps them identify counterfeit or pirated products [23]. However, when these tags are displayed in public, they are vulnerable to attackers' duplication. Moreover, conventional business models rely on centralized trusted third-party servers. If these servers do not have comprehensive security mechanisms such as communication standards, attackers can still pose as authorized agencies or incur man-in-the-middle attacks on servers such as ONS [24]. Consequently, consumers purchase counterfeit or pirated products because of false information. To satisfy both consumers' needs for product traceability and information security, the production and sales history of products is recorded in distributed ledger technology to prevent consumers from acquiring incorrect transaction information [25].
To secure information privacy and traceability of a product within its life cycle and make it suitable for bulk cargo transfers in a frontend supply chain, a hierarchical mobile RFID structure was constructed in this study by applying multiple mobile readers. A high-efficiency group ownership transfer method integrated with blockchains was introduced. This method enables the off-chain ownership transfer of products with RFID tags and the on-chain tracing of the ownership transfer information. The information was consistent between off-chain and on-chain ownership. In addition, the proposed method enables the management of ownership and product manufacturing information through smart contracts. Product ownership transfer history is recorded in blockchains, which are unchangeable. Thus, blockchains can be used to trace the original manufacturers and prevent product counterfeiting. The ownership transfer protocol incorporates grouping proofs to prevent disputes on product transfer comprehensiveness. The major contributions are as follows: (1) the protocol enables the transfer of a large of tags at one time through a multilayered reader securely; (2) the protocol is capable of cross-authority ownership transfer; (3) the protocol enables partial ownership transfer, wherein the ownership of one or more RFID tags is transferred at one time; (4) the protocol verifies the comprehensiveness of product transactions through grouping proofs and enables the clarification of the attribution of responsibility when disputes occur; (5) the protocol prevents known RFID tagged ownership transfer attacks such as replays, eavesdropping, and tag counterfeiting; (6) the protocol enables the management of multiple manufacturers through a single contract to reduce blockchain transaction costs. The results of an analysis revealed that the proposed protocol requires lower message and computational load than the existing group ownership transfer protocols with grouping proofs.
The remainder of the paper is organized as follows. Section 2 reviews the previously literature. Section 3 presents the environmental assumptions considered in this study and the structure of the multilayered reader incorporating a blockchain. Section 4 describes the protocol and smart contract proposed in this study, which are used to initialize and transfer ownership as well as update keys. Section 5 describes the security analysis of common RFID attacks and the comparison of security between the proposed protocol and the existing group ownership transfer protocols. Section 6 presents a comparison of the efficacy of the proposed protocol with that of the existing group ownership transfer protocols. Section 7 concludes this study and proposes future directions.

II. RELATED WORK
To clearly attribute responsibilities for lost products, Juels et al. [26] proposed the Yoking-proof protocol, in which a grouping proof is generated during the transfer of products between the original and new owners to ensure that the products are successfully and completely delivered; this prevents both parties from repudiating the completed transactions and product delivery. Nevertheless, attackers can initiate replay attacks by replaying some of the grouping proofs to generate comprehensive, legal grouping proof without the actual products in the transaction. Saito and Sakurai [27] proposed grouping proofs based on timestamps to prevent replay attacks; however, attackers can also control timestamps to initiate replay attacks. Piramuthu [28] employed random numbers to develop a protocol that ensures information freshness of grouping proof. Nevertheless, Lopez et al. [29] point out that attackers can eavesdrop the original grouping proof information and replace partial sessions of the grouping proofs to generate legal grouping proofs, which may create an inconsistency between the transferred products and the original products. Lopez et al. [29] proposed a grouping proof protocol that considers such multiple proof attacks.
However, the efficacy of this protocol is limited because conventional grouping proofs are generated according to a specific order [26], [27], [28], [29], [30], [31], [32], [33]. Because generating and recombining grouping proofs one by one is time-consuming, computing methods that do not require waiting sequences, such as broadcast messages and exclusive OR (XOR), can be employed to shorten the time required to generate a grouping proof [34], [35], [36], [37], [38], [39], [40], [41]. However, when tags return messages simultaneously and anticollision algorithms such as treewalker and Aloha are used to stagger message response time, attackers can utilize the time difference and generate grouping proofs from tags that are not generated at the same time points [42]. Furthermore, when the number of tags exceeds the maximal number a reader can read and must be read in batches, the overall reading time exceeds the threshold value, preventing the generation of legal grouping proofs [43]. Yang et al. [15] proposed a hierarchical group tag transfer mechanism in which multiple readers read tags simultaneously, thereby overcoming the reading limitations and effectively preventing known attacks against RFID. However, when the grouping proof protocol, which safeguards comprehensive product delivery, and the tag group transfer protocol, which performs ownership transfer, are executed separately, transfer efficacy is impeded [44], [45]. Tsai et al. [44] combined these two protocols for identity authentication and random number generation and proposed an ownership transfer protocol that incorporates grouping proofs, which safeguarded both the efficacy and security of tag group ownership transfer.
In order to guaranteed the genuineness of RFID tags in the post supply chain, Toyoda et al. [2] proposed a blockchainbased ownership management system in which product and owner information is signed and recorded in a blockchain. Consumers can acquire the proof of possession of products through the blockchain. Thus, attackers who counterfeit product tags cannot modify the transaction history of the products in the blockchain and cause consumers to acquire incorrect products. Nevertheless, attackers may still acquire an owner's true identity through the blockchain address of a transaction, leading to privacy risks [46]. Kosba et al. [47] proposed Hawk, a smart contract that applies zero-knowledge proofs to protect blockchain data privacy. However, attackers can learn about the direction of commerce for a product by tracking its electronic product code (EPC). The EPCglobal standard [48] has been implemented to protect consumers' privacy by hiding tag codes, but attackers can still acquire these codes by using noncompliant readers [49].

III. MULTILAYERED OWNERSHIP TRANSFER METHOD RESISTANT TO OWNERSHIP TRANSFER DISPUTES
The proposed ownership transfer method incorporates offchain ownership transfer of products with RFID tags and onchain ownership transfer history and is suitable for bulk cargo transfer in a frontend supply chain. It employs a multilayered mobile RFID reader to read a large number of tags simultaneously, thereby improving transfer efficacy. To implement our scheme, we leverage Ethereum, a blockchain-based consensus platform that enables the integration of product ownership into tags and blockchains.

A. PRELIMINARIES
As depicted in Fig. 1, the supply chain composed of five actors, i.e. manufacturers, warehouses, wholesalers, retailers and customers. The proposed logistic ownership transfer system consists of off-chain and on-chain blocks. In the upper area encircled with bold lines in Fig. 1 is off-chain area, Under the assumption that each supply chain actor has possess a backend server and multiple mobile RFID readers. The supply chain actor is able to reads multiple RFID tags simultaneously by using multiple readers which authorized by their own backend server for product ownership transfer. The backend server is used to manage the actor's own tag key and serves as a node in the blockchain for running smart contracts. The main reader is marked with M , and those that are unmarked are auxiliary readers. The auxiliary readers receive the property ownership transfer messages transmitted by the main readers and further transmit them to the RFID tags of the products allocated to the auxiliary readers, thereby assisting in ownership transfer and the generation of grouping proofs.
The lower area, which is on chain area, encircled with dotted lines features two on-chain smart contracts, one namely the system management contract, which is used to authenticate manufacturers, and the other namely product management contract, which records the ownership transfer history of each product.
The manufacturers need to register their information through the system management contract before selling their products. In order to avoid any non-authorized actors from illegally issuing the ownership of products, the administrator verifies the correctness of the on-chain manufacturer data and authorizes the manufacturers to access the product management contract. (GS1 [50] is a suitable administrator. Currently, manufacturers applying RFID for logistics management have registered their data on GS1).
Next, the supply chain actors can use the product management contract to transfer products and receive products The remainder of this section describes the on-chain manufacturer and product registration procedure and the off-chain environmental assumptions.

B. ON-CHAIN ENVIRONMENTAL ASSUMPTIONS AND REGISTRATION
In the proposed ownership transfer system, in order to sell their products, manufacturers are required to register their information in the blockchain. Assume Manufacturer A uses a secure channel to submit its blockchain address Addr A and manufacturer data Data A (e.g., name, factory addresses, and contacts) to the administrator for identity authentication (Step 1, Fig. 2). After the identity and data are verified to be correct, the administrator issues an EPC prefix PRC A to manufacturer A and submits Addr A , Data A , and PRC A to the system management contract (Step 2, Fig. 2). After receiving PRC A , Manufacturer A also submits Addr A , Data A , and PRC A to the system management contract (Step 3, Fig. 2). After the system management contract confirms that the data submitted by Manufacturer A and the administrator are consistent, the contract records Addr A , Data A , and PRC A and authorizes Manufacturer A to register their products through the product management contract.
After Manufacturer A receives the authorization to register a product, he/she can use Addr A to generate a transaction message with a product tag identification (ID) code through the backend server and submit it to the product management contract for registration. After the contract receives the message and confirms with the system management contract that the code can be registered in Addr A , it assigns Addr A as the original owner of the product. The symbols used in this study and their definitions are presented in Table 1.

C. OFF-CHAIN ENVIRONMENTAL ASSUMPTIONS AND METHODS
Product tag ID are recorded in the blockchain to integrate the product ownership in the tag and blockchain. During ownership transfer, to ensure the consistency between the on-chain and off-chain transaction products, the ownership of the blockchain and RFID tag of a product must be transferred simultaneously. Because the volumes of logistics frontend products are large, a group key is established on the backend server. A single multicast message is transmitted to all the tags belonging to the same group to reduce the number of times the message is transferred. However, when the number of tags exceeds the upper limit of the messages a reader can read [43], the tags must be read using more than one message. Therefore, a multilayered reader is employed in this study to enable the main readers to distribute messages to their own auxiliary readers, thereby controlling the number of tags each reader must process below the upper limit. Thus, tags can be read simultaneously using all readers. To enable backend servers to generate multicast messages to target tags and reduce the number of tags each reader is VOLUME 10, 2022 required to read, the tags must be grouped, and appropriate group keys must be generated accordingly. In this study, n tags are grouped to generate a k-ary group tag tree with the height of log k n k + 1. Each subtree differs from the tree in heights no greater than 1. See Fig. 3(a) for the rules of coding each group node. The nodes are coded in order from top to bottom and from left to right. When the code of a node is v, its parent and child nodes are coded v−1 n/k − 1 and directly connected to a tag are defined as leaf group nodes (G leaf ,q e ). Fig. 3(b) presents a 3-ary (k = 3) group tag tree consisting of 26 tags (n = 26). According to (1), the tags T 1 e , T 2 e , and T 3 e are connected to the leaf group node G leaf ,1 e (q = 1). In other words, the first group node is G 4 e . Furthermore, the nodes from T 1 e to T 9 e are grouped into the nodes G 4 e , G 5 e , and G 6 e and belong to the parent group node G 1 e .
Assume each tag T i e has a unique tag ID (TID i e ) and shares with its owner's backend server the tag key TK i e [51], and the group key GK q e is calculated using the keys shared by all tags under the group node G p e . If the tag T i e belongs to the group node G p e , then T i e can decrypt the messages encrypted by the group key GK q e . As shown in Fig. 3(b), the tags T 1 e , T 2 e , and T 3 e belong to G 4 e , and tag keys TK 1 , TK 2 , and TK 3 can be used to generate the group key GK 4 e . To ensure security of message transmission, the backend servers and readers are hypothesized to share keys (Fig. 4). The backend servers of the original (ori) and new (new) owners share the key DK . The backend server of the original owner (D ori ) shares with its main reader (R 0 ori ) the key RK ori . The m-th auxiliary reader (R m ori ) shares with the main reader (R 0 ori ) the key MK m ori . Similarly, the backend server of the new owner (D new ) shares with its main reader (R 0 new ) the key RK new . The s-th auxiliary reader (R s new ) shares with the main reader (R 0 new ) the key MK s new .

IV. RFID TAG OWNERSHIP TRANSFER PROTOCOL
For the traceability of ownership transfer, smart contracts are applied to record ownership outgoing and incoming. The records are integrated with the off-chain RFID tags of actual products. A multilayered mobile RFID reader is implemented to simultaneously read a large number of tags to enhance transfer efficiency. The process of ownership transfer is divided into ownership outgoing and incoming.

A. OWNERSHIP OUTGOING
When ori transfers its tag set T ori to new (Fig. 5), the main reader of ori (R 0 ori ) binds the transfer message (OT ), random number (r 0 ), the ID of the main reader of new (RID 0 new ), and the ID set of the transferred tags (TID ori ) with the outgoing tag for new. The key RK ori shared between R 0 ori and the server D ori is then used to encrypt the message M 1 to D ori .
After D ori receives the message M 1 , it generates the random number r 0 and integrates it into the decrypted M 1 . The message is then encrypted with DK , the key shared by D ori and D new . The message M 2 is then transmitted from D ori to D new .
After D new receives and decrypts M 2 and authenticates its source, it generates the random number r 1 and creates new key TK i new for each tag TK i ori in TID ori . The key is used to encrypt the ID of each incoming tag TID i ori . Subsequently, D new provides the hash values used by the blockchain to verify all transferred tags (H TK i new ⊕ r 1 ), the blockchain address used for receiving the products (Addr new ), and random number r 0 to D ori .
After D ori decrypts the message M 3 from D new , confirms r 0 as the random value for the transaction, and authenticates the source of the message, it employs the outgoing function SingOut()in the product management contract and its blockchain address Addr ori to set up all the TID i ori of the tag TID ori to the outgoing status. When the product management contract confirms that the owner possesses the ownership of TID ori , it generates the random number r 2 for completion of status setting.
After D ori receives r 2 from the product management contract (Fig. 6), it combines M 3 from D new with r 2 and generates an outgoing message M i 123638 VOLUME 10, 2022 which are then encrypted as M 5 by using RK ori , the key shared by D ori and R 0 ori . M 5 is then transmitted to R 0 ori . After R 0 ori decrypts M 5 and authenticates its source using TID i ori , according to the group TID i ori belongs to, it outgoings M 5 and distributes the message to all auxiliary readers according to the number of tags each reader can afford to read. As shown in Fig. 6, after the j-th auxiliary reader (R j ori ) receives the message, it decrypts the message into M 7 by using MK j ori , the key shared by R j ori and R 0 ori . A multicast message is then transmitted to the tags of the affiliated groupR j ori . As illustrated in Fig. 6, after T i ori , the tag in the group governed by R j ori , receives the multicast message, decrypts M 7 by using TK i ori , the key shared by T i ori and D ori , and authenticates the source of the message by verifying TID i ori , it generates a random value r i 3 . TK i ori is then used to encrypt r 2 , r i 3 , and TID i ori into M i 8 , which is returned to R j ori , forwarded to R 0 ori , and finally returned to D ori , thus completing the ownership outgoing. The actual product is thus transferred to the new owner (new), who then performs the ownership incoming.

B. OWNERSHIP INCOMING
After the new owner (new) receives the product (Fig. 7), the grouping proof of the product is generated before its tag is transferred to prevent subsequent disputes. Because new may have a different authority from that of the original owner (ori), the main reader of new (R 0 new ) must first acquire authorization from D ori through the backend server D new . RK new , the key shared by R 0 new and D new , is used to encrypt the tag ID set of the received product TID ori and the blockchain address of new (Addr new ) into M 1 , which is then transmitted to D new .
After D new decrypts M 1 , confirms the consistency between TID ori and the tag ID of the transferred product TID ori , and authenticates the source of the message, it generates a random number r 4 . DK is then used to encrypt TID ori , Addr new , and r 4 into request message M 2 , which is transmitted to D ori .
After D ori receives M 2 and confirms that TID ori and Addr new are consistent with the transfer information, it generates the message M The tag T i ori decrypts M 6 , authenticates its source, and verifies that its own ID TID i ori is correct and that the random number r i 3 has been generated by itself through the outgoing process. The key TK i ori is applied to calculate MAC(TK i ori , r 2 r i 3 ), and the message M i 7 is returned to R j new and forwarded to R 0 new . R 0 new performs an XOR calculation on messages transmitted by all auxiliary readers and converts them into the grouping proof of the product, returning it to D new .
After D new receives the grouping proof, it retains the proof for use to solve any dispute that occurs in the transaction. The proof is signed using the private key PV new and transmitted to D ori through the message M 10 .
After D ori receives M 10 and verifies the consistency of the grouping proof and the signature of new using PB new , the public key of new, D ori encrypts all the tag keys TK i ori into M 11 with DK . M 11 is then transmitted to D new for key update.
After D new receives M 11 , it starts performing the on-chain and off-chain ownership transfer. As depicted in Fig. 8, D new applies the updated key TK i new from the outgoing process and the random numbers generated by all the actors in the communication to update the key for each tag T i ori . The original TK i new is then encrypted into M i renew , which VOLUME 10, 2022   After T i ori receives M i 14 , it recalculates the key hash, authenticates the message source, and confirms that the key hash and the random numbers r 2 and r i 3 are consistent with M j 14 . The key in M j 14 is then updated as TK i new , and its key hash and random numbers r 2 and r i 3 are emptied. Subsequently, the message is encrypted into the completion message M i 15 by using a new tag key, returned to R j new , forwarded to R 0 new , and finally returned to D new . After D new receives M 17 from all the tags, it employs the incoming function SignIn() in the product management contract and the blockchain address Addr new to initiate the incoming process. The ownership of TID ori is requested. After the product management contract confirms that Addr new belongs to the new owner, it generates a new ownership record, thus completing the on-chain and off-chain ownership incoming.
In the proposed protocol, all tags can be transferred with only one protocol execution step regardless of the total number of tags. The number of required auxiliary readers is related to the number of leaf group nodes. When all the tags to be transferred belong to the same leaf group node, only one auxiliary reader is required to complete their ownership transfer. Conversely, when the tags to be transferred belong to z different leaf group nodes, z auxiliary readers are required to complete their ownership transfer. When the number of auxiliary readers exceeds the upper limit of the main reader's simultaneous reading capacity (r), an additional auxiliary reader must be implemented to assist in the message transmission. Accordingly, the number of auxiliary readers is calculated as z + z * r −1 + z * r −2 + . . . + 1. As depicted in Fig. 3 (b), the original owner (ori) intends to transfer six tags (T 1 ori -T 6 ori ) to the new owner (new). The ori -TID 6 ori ) and the recipient blockchain address (Addr new ) and sent to D ori . The product management contract in the D ori blockchain then records the updated hash values, as listed in the table on the right of Fig. 9 After D ori receives the random number r 2 generated by the contract, it distributes the hash values for updating the keys (TID 1 ori H TK 1 new ⊕ r 1 , TID 2 ori H TK 2 new ⊕ r 1 , . . . , TID 6 ori H TK 6 new ⊕ r 1 ) and random number r 2 to the auxiliary readers (R 1 ori and R 2 ori ) through R 0 ori . Auxiliary reader R 1 ori receives from R 0 ori the update messages required for the tags T 1 ori , T 2 ori , and T 3 ori , which belong VOLUME 10, 2022 to the same tag group. The messages are then transmitted to T 1 ori , T 2 ori , and T 3 ori . Similarly, R 2 ori receives from R 0 ori the update messages required for the tags T 4 ori , T 5 ori , and T 6 ori , which belong to the same tag group. The messages are then transmitted to T 4 ori , T 5 ori , and T 6 ori . After the tag has the source of its ownership transfer message and ID verified, a confirmation message is sent from R 1 ori or R 2 ori to D ori . After D ori confirms to have received the confirmation messages from all the tags, the products are transferred to the new owner.
After the new owner (new) receives the products, the main reader R 0 new acquires the ownership transfer messages encrypted with keys GK 4 ori and GK 5 ori respectively from D ori through D new . Through the auxiliary reader R 1 new , multicast ownership transfer messages encrypted with GK 4 ori are transmitted to T 1 ori , T 2 ori , and T 3 ori ; similarly, through R 2 new , multicast ownership transfer messages encrypted with GK 5 ori are transmitted to T 4 ori , T 5 ori , and T 6 ori . After the tags receive the messages, they generate different parts of their grouping proof and return their messages. The main reader R 0 new then runs an XOR calculation on the returned messages to assemble the grouping proof, which is then transmitted to D new . The grouping proof is signed by D new by using its private key PV new and transmitted to D ori . Subsequently, D new requests the tag keys TK 1 ori -TK 6 ori of the transferred products from D ori . After D ori receives the message and confirms the authenticity of the grouping proof by verifying the signature with the new owner's public key PB new , it transmits TK 1 ori -TK 6 ori to D new . After D new receives the tag keys, it generates a message with new tag keys TK 1 new -TK 6 new and transmits it to R 1 ori or R 2 ori through R 0 new . The message is then distributed to T 1 ori , T 2 ori , and T 3 ori through R 1 ori and to T 4 ori , T 5 ori , and T 6 ori through R 2 ori . After each tag (e.g., T 1 ori ) authenticates the source of the ownership transfer message and confirms the authenticity of the key (e.g., TK 1 new ) by using the hash value (e.g., H TK 1 new ⊕ r 1 ), the product tag is updated as TK i new , and the reader returns confirmation messages from tags to D new . D new confirms the completion of the update of all the tags and transmits the incoming message embedded with the tag ID set TID ori to the blockchain, prompting the product management contract to record the ownership transfer as shown in the grey area of Fig. 9, thus completing the on-chain and off-chain ownership transfer.

V. SECURITY ANALYSIS
A total of five communication paths are involved in the proposed protocol, namely backend server to blockchain, backend server to backend server, backend server to main reader, main reader to auxiliary reader, and auxiliary reader to tag. The communication among backend server to blockchain, and backend server to backend server. Their computation power is strong enough for encryption algorithms like Advanced Encryption Standard (AES) [52] and RSA [53]. Because the messages between back-end servers are encrypted with secure cryptographic systems, wired network security issues will not be discussed in this paper.
Communications between backend server to main reader, usually comply with security standards IEEE802.11i [54]. Therefore, we leave them out of discussion in this paper. Herein, the security of the communication between off-chain mobile readers and tags in the proposed protocol and of the on-chain smart contracts is assessed.

A. OFF-CHAIN SECURITY
Secure ownership transfer relies on preventing attacks during the transfer process. Therefore, a security analysis was conducted on the commonplace threats to ownership transfer, including security problems such as secret leakage, replay attacks, denial-of-service (DoS) attacks, man-in-the-middle (MitM) attacks, counterfeit tags or readers, and window problems as well as problems associated with forward security.

1) PREVENTING SECRET LEAKAGE
The ideal protocol must prevent attackers from acquiring sensitive information. In the proposed protocol, each message when transmitted is protected through symmetric key encryption, and the shared keys are deployed through secure channels in the initial stage. This prevents attackers from acquiring keys to decrypt the messages.

2) PREVENTING REPLAY ATTACKS
Attackers can eavesdrop and preserve the information previously transmitted by a protocol. Therefore, the ideal protocol must ensure that replayed old messages cannot evade authentication. In the proposed protocol, random numbers are generated by the backend servers of the original and new owners, tags, and blockchains and encrypted together with messages for transmission. Thus, the messages at each transfer contain random number changes to ensure message freshness, thereby preventing attackers from replaying acquired messages to evade authentication.

3) PREVENTING ASYNCHRONOUS DoS ATTACKS
During the updating of keys, the ideal protocol must prevent attackers from blocking the update process, which renders the keys out of sync and prevents them from being saved. In the proposed protocol, all the messages are encrypted with shared keys. Therefore, only the situations in which messages are lost or blocked by attackers are discussed. During the outgoing process, the original owner only enters the key hashes provided by the new owner into the tags and product management contract. When the hash values in the tags are not yet updated, the original owner may resend the messages. During the incoming process, the new owner saves the two keys before and after the update. Thus, the key before the update can still be used to communicate with the tags in the event the messages are blocked.

4) PREVENTING COUNTERFEIT TAG OR READER ATTACKS
The ideal protocol must prevent attackers from counterfeiting readers or tags to steal ownership. In the proposed protocol, attackers attempting to counterfeit tags must acquire tag keys and IDs, which have been allocated to the tags through secure channels. Moreover, the confidentiality of transmission is protected, preventing attackers from counterfeiting tags. Attackers attempting to counterfeit readers must acquire reader keys and IDs, which have similarly been deployed through secure channels. Because the confidentiality of transmission is protected, attackers are unable to counterfeit readers.

5) PREVENTING MitM ATTACKS
Because the proposed protocol prevents attackers from counterfeiting tags or readers and from evading authentication through replay attacks, the protocol can secure against MitM attacks.

6) PREVENTING WINDOW PROBLEMS
During ownership transfer, the ideal protocol must ensure that the original and new owners do not possess the ownership simultaneously. In the proposed protocol, after the original owner enters the updated hash value provided by the new owner, the original owner can no longer modify the hash value with the original key and must use the key provided by the new owner to do so.

7) FORWARD SECRECY
When the original owner transfers tag ownership, the new owner provides only the updated hash values, which are entered into the tags by the original owner, thus completing the tag transfer. After the new owner acquires the tag keys, the tag keys are updated with new keys. This prevents the original owner from learning about the updated keys and tracing the subsequent tag information, thus protecting the forward secrecy. Table 2 presents a comparison between the proposed protocol and the protocols in other studies in terms of the defense against Secret Leakage (SL), replay attacks (RA), DoS attacks (DoS), MitM attacks (MitM), counterfeit attacks (IA), and window problems (WP) as well as on forward security (FS), grouping proofs (GP), group transfer (GT), partial tag ownership transfer (POT), traceability (TB), and the ability to complete ownership transfer with only one protocol execution (OTF). Here, O indicates that the protocol fully prevents a particular type of attack or fulfills a particular characteristic; indicates that the protocol partially prevents particular type of attack or fulfills a particular characteristic; and X indicates that the protocol is completely incapable of preventing a particular type of attack or does not fulfill a particular characteristic.
According to Table 2, the protocols by Zuo [19] and Tsai et al. [38] are incapable of preventing some attacks or do not fulfill some security characteristics. The protocol by Zuo [19] is incapable of preventing asynchronous DoS attacks. Attackers can intercept the XOR calculation of multiple messages of preceding ownership transfer and replace the information with new keys, thus resulting in inconsistency between tags and the keys saved by the new owner and preventing tags from being updated by the new owner [11]. Moreover, the grouping proof generated by Zuo's protocol [19] updates its key after ownership transfer. This prevents tag groups from generating a grouping proof identical to the one in the authentication server so that the consistency in the number of products transferred can be verified, inhibiting the solution of disputes on incomplete ownership transfer. Finally, group numbers are assigned to tags in advance in the protocol by Zuo [19]. During the transfer process, all the tags within a group must be simultaneously transferred, and transferring only a part of the tags is impossible. The protocol by Tsai et al. [44] effectively prevents all the listed attacks. However, because it lacks a mechanism to trace manufacturers and does not record the history of ownership transfer, it is incapable of tracing the source manufacturers of products. Furthermore, when tags are divided into different groups, the protocol by Tsai et al. [44] must be executed multiple times to complete the ownership transfer, thereby lowering the transfer efficacy (see Section 5 for further details). By contrast, the protocol proposed in this study both effectively prevents most of the known ownership transfer attacks and traces tag sources. Additionally, it is the only protocol capable of completing key updates in only one execution step.
Next, we apply GNY logic [55] to proof the off-chain security of our proposed protocol. The verification has four parts: 1. Defines the message transferred in the protocol. (Table 4) 2. Assumptions about the initial state. (Table 5) 3. Goals of the protocol. (Table 6) 4. The process of the proof. (Table 7) Table 3 defines the symbols used in the GNY logic proof. For the logic equation numbers used in Table 7, such as T1 and P1, please refer to GNY logic [55]. If initial assumptions are required, the term ''IA'' is used.

B. ON-CHAIN SECURITY
The security of the smart contracts in the proposed protocol were verified using Oyente, a smart contract security testing tool. Oyente reads smart protocols and detects several types of VOLUME 10, 2022   contract errors that may be vulnerable to attacks. Table 8 and  Table 9 list the Oyente test results for the system management contract and product management contracts, respectively. The results confirm that both contracts are effectively protected against all common attacks.

VI. PERFORMANCE EVALUATION
Herein, the efficacy of the proposed group ownership transfer protocol incorporating blockchains is presented. The required on-chain calculation resources and the volumes of messages and calculations required for off-chain RFID ownership transfer were analyzed.

A. SMART CONTRACT PERFORMANCE EVALUATION
Geth was applied to provisions of three Ethereum nodes, namely the administrator, the manufacturer and the logistics company. Ethereum wallet was employed to calculate the processing fees required for the smart contracts when ownership is registered in Ethereum (Table 10).
1. 522,796 and 543,955 gas are required to deploy the system management contracts and product management contracts, respectively. 2. Any manufacturer intending to register its products in the blockchain must apply for administrator review to earn authorized access to the product management contract. Each manufacturer, administrator must pay 125,922 gas to register a manufacturer in system management contracts. Besides, the manufacturer needs to pay 128,749 gas for confirmation. 3. Each manufacturer must submit the product's ID to the product management contracts and pay 113,362 gas to acquire initial ownership. 4. When a product is being transferred, its original owner must deliver an ownership outgoing application from the blockchain, and the new owner must then file an ownership incoming request. The requests are verified by the product management contract and the ownership transfer is completed. The original owner must pay 51,389 gas for the process, and the new owner must pay 19,741 gas to acquire the ownership of the product. Fig. 10 illustrates the average processing fees required according to the number of times a product is transferred. When each manufacturer holds 10,000 products and transfers them 16 times, the average transfer cost is 78,223 gas. Because transferring cost shares the smart contract deployment cost, a contract is considerably more cost-efficient while increasing the number of transformations.

B. RFID PROTOCOL MESSAGE AND COMPUTATIONAL LOAD ANALYSIS
The message and computational loads required to transfer n tags were compared between the proposed protocol and the protocols by Zuo [19] and Tsai et al. [38]. In the frontend supply chain, manufacturers and wholesalers may simultaneously transfer a number of products exceeding the upper reading limit of a reader per operation, inhibiting transfer efficacy. Therefore, main readers are set up in the proposed protocol to distribute tag groups to different auxiliary readers, enabling auxiliary readers to read group tags simultaneously.  Because the proposed protocol is the first secure ownership transfer protocol that reads group tags simultaneously   through multiple readers, an overhead is applied to coordinate readers for reading multiple tag groups simultaneously in a secure manner. To fairly compare the efficacy of the proposed protocol with that of other group ownership transfer protocols, multiple messages parallelly transmitted by readers are defined as one message, and the parallel calculations conducted simultaneously in different readers are not repeated.
Currently, only the proposed protocol and the protocols by Zuo [19] and Tsai et al. [38] are capable of performing simultaneous group ownership transfer and grouping proof generation. These protocols were compared, and the results   verified that the proposed protocol is the most efficient for secure frontend logistics ownership transfer.
When a reader uses a k-ary group tag key tree to transfer n tags, n/k groups must be transferred. Table 11 lists the number of messages required by the three mentioned protocols to perform ownership transfer. The off-chain outgoing and incoming stages require 6+k +2 n k and 10+4k +3 n k messages, respectively. Accordingly, completing a transfer process requires a total of 16 + 5k + 5 n k . In the protocol by Tsai et al. [44], outgoing readers distribute group keys to incoming readers in an out-of-band manner and do not integrate key distribution into the protocol. Consequently, tags belonging to different groups cannot be simultaneously read and must be read in separate protocol executions. Therefore, a relatively large number of messages are required for the simultaneous processing of tag groups in the proposed protocol of this study. Because the protocol by Zuo [49] does not support partial ownership transfer and updates an entire tag group at one time with a group key, fewer messages are required for ownership transfer using this protocol. However, generating a grouping proof in this protocol requires the sequential cascading of all tags; this requires a higher number of messages than does broadcasting messages to all tags, through which grouping proofs can be generated without following the tag sequence. Moreover, because the protocol proposed by Zuo [49] does not employ multiple readers to read tags simultaneously, it requires the highest number of messages to complete ownership transfer and generate grouping proofs. Fig. 11 presents a comparison between the proposed protocol, the protocols by Zuo [49] and Tsai et al. [37] in terms of the number of messages required to complete ownership transfer. When a 3-ary key tree is used for the secure transmission of each tag group, with a maximum of only three tags, the present proposed protocol requires fewer messages than the other two previous protocols for simultaneously processing more than five tags; the difference is particularly pronounced when more than 128 tags must be processed. Thus, for the simultaneous transfer of ownership of a massive number of tags, the proposed protocol is the most efficient, with a reduced calculation time, thus making it most suitable for bulk cargo ownership transfer in the frontend supply chain environment. Table 12 lists the computational loads required for each facility, where T E indicates the time required for symmetric encryption and decryption; T S refers to the time required for signature; T H indicates the time required for calculating the hash value; and T RNG is the time required for generating a random number and a key. Logic operations such as XOR are not discussed because they require much shorter calculation times than the mentioned variables. The protocol by Zuo [19] features owners as server with high calculation capabilities; in the protocol by Tsai et al. [44], couriers and recipients are designated as servers for analyzing calculation capabilities. Nevertheless, the protocol proposed in this study requires the lowest volume of calculation for tags and readers with low calculation capabilities.
For easy comparison of the efficacies of the three protocols, the computational loads for all the facilities in each protocol were summed (Table 13). Although the protocol proposed in this study requires the lowest computational loads for facilities with low calculation capabilities, such as tags and readers, compared with the other two protocols, the required calculation in the proposed protocol is primarily concentrated in servers. Therefore, the comparison approach is relatively unfair to the proposed protocol. Nevertheless, the proposed protocol still requires considerably lower computational loads than the other two protocols.
To accurately and fairly compare the computational load of the three protocols, AES-128 was set as the general symmetric key encryption method. Each encryption or decryption requires 1,032 cycles [56]. Given that an RFID tag  can execute 3.55 million clock cycles per second [57], the clock cycle was calculated, followed by the time required to complete ownership transfer. As depicted in Fig. 12, although the comparison method is disadvantageous to the proposed protocol, the proposed protocol requires half the calculation time as that required by other protocols, and the difference increases with the increase in the number of tags. Accordingly, both the message and computational load comparisons indicate that the proposed protocol is the most suitable for transferring the ownership of a large number of products in frontend logistics.

VII. CONCLUSION
We have proposed a blockchain-based high-efficacy group ownership transfer protocol that suitable for bulk cargo transfer in a frontend supply chain environment. The advantage of this protocol is that product ownership transfer history recorded using the blockchain, which cannot be tampered with. This enables consumers to use the blockchain to trace the original manufacturers of all products and thereby prevent counterfeiting. Moreover, the protocol generates grouping proofs to prevent disputes regarding the comprehensiveness of ownership transfer.
Our agreement enables efficient transfer of the ownership of one or more RFID tags simultaneously. In processing more than five tags simultaneously, the proposed protocol requires fewer messages than the existing group ownership transfer protocols with grouping proofs; the difference is particularly pronounced when more than 128 tags are transferred. The experiment results revealed that the calculation time required by the proposed protocol was half of that required by other protocols. Thus, for the simultaneous transfer of ownership of a massive number of tags, the proposed protocol is the most efficient.
We used GNY logic to verify the off-chain security of the proposed group ownership transfer protocol. We verify that participants can achieve mutual authentication between group tags and the backend server while ensuring that messages are not maliciously replayed, through GNY logic. Security analysis results have shown that the proposed protocol can prevent most RFID ownership transfer attacks, such as SL, replay, DoS, counterfeit tag or reader, and MitM attacks.
Furthermore, Oyente was employed to test the on-chain security of the smart contracts to ensure that these contracts are capable of resisting all commonplace attacks, thereby verifying that the proposed protocol is secure for both on-chain and off-chain transfers.