Scalable and secure product serialization for multi-party perishable good supply chains using blockchain

serialization aims to allocate unique serial numbers to products in a supply chain. The security challenges to product serialization are: • Valid serial numbers can be stolen and used to label fake products. Thus uniqueness of a serial number should be veriﬁable at any stage of its lifecycle in a supply chain. • A planned change of custody of a product in distribution can be corrupted by a few intimidatory nodes. Compliance with the planned change of custody should be veriﬁable. • The manufacturer and the consumer should be able to verify that perishable food products with expired shelf life are discarded. In this paper


Introduction
Product serialization intends to allocate unique serial numbers to products in a supply chain. Unique serial numbers can be generated by the manufacturer or by a regulator who can assign serial numbers to a manufacturer and the manufacturer can use these numbers to serialize its product. Serialization is important to ensure product authenticity and safety. Although interoperable data format for serialization and data standard [1] are in use for product serialization, the current state of the art in product serialization lacks security evident from a high volume of counterfeit products. It is reported [2] that annually global businesses lose up to US$597 billion per year due to fake products and counterfeiting will lead to the loss of 5.4 million jobs globally. Counterfeit medicines [3] costs US$200 billion annually and up to 10 million people die from fake medicine every year. The security challenges [4] to product serialization are the following: • Security of serial numbers: Valid serial numbers can be stolen and used to label fake products. Thus uniqueness of a serial number should be verifiable at any stage of its lifecycle in a supply chain. • Secure Change of Custody: A planned change of custody of a product in distribution can be corrupted by a few intimidatory nodes. Compliance with the planned change of custody should be verifiable by the consumer of the product. • Control over the serial number -Perishable Food: The manufacturer should be able to ensure that perishable food products with expired shelf life are discarded. • Multi-party supply chain: In this paper, we consider a multi-party supply chain where no party has absolute control over the entire supply chain. We consider regulators, manufacturers, intermediators (logistics service providers, cold storage providers etc), retailers, consumers as members of the supply chain. In such a federated supply chain, parties may not trust each other and have various levels of concern for the first three challenges. For example, regulators may be only concerned about the security of serial numbers to prevent counterfeit products. The manufacturer may be primarily concerned about discarding perishable goods with expired shelf life. The intermediator may be concerned about the proper change of custody of the product.
In this paper, we use blockchains to develop a product serialization method that solves the above security issues. Blockchains can revolutionise security and transparency in supply chains by providing a secure data-sharing platform in a multi-party environment. Although blockchains can provide a secure data storage of these events, a high volume of such events poses scalability problems for blockchains. In this paper, we solve the product serialization problem using offline channels of blockchains. Our solution significantly reduces the number of transactions needed to be recorded in the blockchain. We propose a secure serialization protocol to verify the authenticity of serial numbers despite not engaging with the blockchain.
The state of art blockchain-based traceability solutions for perishable good supply chains uses IoTs to monitor the supply chain and smart contracts to ensure traceability in the supply chain. However, the state of art solutions do not solve the above-mentioned problems. In this paper, we mitigate these problems as our main contributions are as follows: Secure serialisation: We have developed a product serialization method which prevents a counterfeiter to copy a genuine serial number to label a counterfeit product. The existing traceability solutions for food supply chains may analyze the transactions to detect non-uniqueness of serial numbers. Thus these solutions do not prevent copying genuine serial numbers. Trust in multi-party supply chains: In a multi-party supply chain, various parties have trust issues as a party wants to ensure that another party has shipped genuine products and another party has not shipped products with expired shelf life. The existing blockchain-based supply chain management solutions do not solve these trust issues. Control for perishable goods: We present a serialization solution that prevents the distribution of products with expired shelf life. The existing blockchain-based supply chain management solutions do not prevent the distribution of products with expired shelf life. Secure change of custody: Our serialization solution ensures that a pre-defined distribution path is followed for a product. The existing blockchain-based traceability solutions can prove whether or not a pre-defined distribution path is followed. But it can not enforce the movement of a product in a supply chain in a predefined path. Scalability: Our solution is scalable as it uses offline channels in a blockchain. Existing solutions except Hyperledgerbased solutions are not scalable. Moreover, Hyperledger uses proof of authority which requires a certain level of trust among the parties as only a fraction of peers of the blockchain act as transaction validators.
The paper is organised as follows: in Section 2 we describe the blockchain and offline channels used in this paper, in Section 3 we define the serialization security issues as trust problems among various parties in a supply chain, in Section 4 we describe our serialisation method with blockchains, in Section 5 we analyse security of the proposed solution, in Section 6 we discuss related literature, and we conclude the paper in Section 7 .

Problem statement: serialization in supply chains
In this paper, we will consider a multi-party supply chain [5] composed of a regulator, a manufacturer, a set of intermidiator parties (logistics, cold-storage providers, etc.), a retailer and a set of customer. We consider the scenario when none of these parties has absolute control over the supply chain. The regulator is responsible for assigning valid serial numbers to the manufacturer, the manufacturer is responsible for labelings of the products with these serial numbers, the intermediator nodes are responsible for moving the products through the distribution line, the retailer is responsible for selling the product before its expiry date ( Fig. 1 ).
We will represent a supply chain network as a directed graph G = (V, E) where nodes indicate parties (distributors, suppliers, wholesalers, retailers) engaged in a supply chain and edges indicate the possible path of change of custody of a product. P = (p 1 , . . . , p n ) be a set of products to be distributed in the supply chain G . A distribution plan of a product p i is a path in G which indicates the sequence of change of custody of p i . The distribution plan of a product is known by at least one party in V. δ( p i ) ⊂( v i × v j ) will denote the distribution plan for the product p i . θ ( p i ) will denote the planner of the product p i . θ ( p i ) will be responsible to ensure that p i moves according to the plan δ( p i ). Each path δ( p i ) is a directed acyclic weakly connected subgraph of G . Id = (i 1 , . . . , i m ) be the set of serial numbers to be assigned with the products.  1. A multi-party supply chain. The regulator is responsible for physical movement serial numbers to the manufacturer, the manufacturer is responsible for the movement of labeled products to the intermediators, the intermediators are responsible for the movement of labelled products to the retailer and the retailer is responsible for the movement of labelled products to the consumer.

Definition 2.
In a supply chain SC = < G, P, ID, θ , δ >, products are following proper change of custody if any party v i in a distribution plan v 1 → v 2 → . . . v n can verify that the actual product movement followed the path v 1 → v 2 → . . . v i −1 as per the distribution plan. Definition 3. Serialisation procedure in a supply chain SC = < G, P, ID, θ , δ > is consists of methods to assign and retrieve serial numbers of the products in a supply chain. A serialisation procedure is correct if all products are following proper change of custody.
In this paper, we develop a correct serialisation method for a multi-party supply chain. In a multi-party supply chain, there are trust issues among the parties and a correct serialisation method must address these trust issues.

Trust problem 1
The regulator does have control over the supply chain. Its objective is to assign a unique serial number of each product. Further, in the case of perishable food supply chains, it wants to ensure that food products are sold before their expiry dates. Its objective is based on reducing counterfeit items from the market and reduce the social implications of counterfeit perishable food products such as death from fake medicine or disease outbreak from consuming counterfeit foods.
Adversary: The models of adversaries are: • Adversarial Manufacturer: the manufacturer may label multiple products with the same serial number.
• Adversarial Intermediator: The intermediator parties may steal the genuine serial number from a product in the distribution line and use it to label and inject fake products into the supply chain. • Adversarial Retailer: The retailer may collude with an adversarial manufacturer to label counterfeit products with stolen serial numbers.

Mitigation:
The regulator can trust the supply chain if it is not possible to use a serial number more than once to label products and in case of perishable food products, the products must be sold before its expiry date.

Trust problem 2
The concern of the manufacturer in a multi-party supply chain is the proper change of custody of the product, sale of the product before its shelf life expires, and prevention of fake products labelled with stolen products.
Adversary: The models of adversaries are: • Adversarial Intermediator: The intermediator parties may steal the genuine serial number from a product in the distribution line and use it to label and inject fake products into the supply chain. Such actions will impact the revenue of the manufacturer. Also, the intermediators may not follow the planned change of custody of a product. Such disruption in the change of custody may impact the quality of the product. For example, the manufacturer may plan that a product should stay in cold storage as it is transferred from location to another location. But the intermediator nodes may skip the cold storage and this may lead to decay in product quality. • Adversarial Retailer: The retailer may sell the product after its expiry date. It may cause health issues of the consumers and such events will impact the brand value of the manufacturer.

Mitigation:
The manufacturer can trust the supply chain if (a) it is not possible to use a serial number more than once to label products and in case of perishable food products, (b) it is not possible to disrupt planned change of custody and (c) not possible to sell the products after its expiry date.

Trust problem 3
The intermediators want to distribute products with genuine serial numbers, which are not expired. Adversary: The models of adversaries are: • Adversarial manufacturer / Intermediator: An intermediator must ensure that it has received a product according to a correct planned change of custody. • Adversarial Retailer: The intermediator must ensure that it has received products before its shelf life has expired.

Mitigation:
The intermediators can trust the supply chain if (a) it is not possible to disrupt the planned change of custody and (b) it is not possible to receive products with expired shelf life.

Trust problem 4
The retailer wants to sell genuine and not-expired products. Adversary: The models of adversaries are: • Adversarial manufacturer / intermediator: The manufacturer or the intermediator may distribute fake products labelled with stolen serial numbers. • Shelf life of products: The intermediator may give the retailer products with expired shelf life.

Mitigation:
The retailer can trust the supply chain if (a) it is not possible to disrupt the planned change of custody and (b) it is not possible to receive products with expired shelf life.

Trust problem 5
The consumer wants to buy genuine and not expired products. Adversary: The models of adversaries are: • Adversarial Retailer: The retailer may sell multiple products with the same serial number or may sell products after their shelf life expires.

Mitigation:
The retailer can trust the supply chain if it is not possible to use a serial number more than once to label products and in case of perishable food products, the products have not reached their expiry dates before they deliver it to the retailer. The consumer should be able to check if the supply chain has exhibited a proper change of custody to move its product.

Scalability problem
In this paper, we use blockchains to develop a correct serialisation method in a multi-party supply chain. Proof of work or Proof of stake based blockchains have scalability problems. In a large supply chain with numerous products in its distribution line scalability is a significant issue. We use offline channels to mitigate scalability problems. In the next section we describe offline channels used in Bitcoin's Lightning network. In this paper, we will use similar offline channels for serialization.

Blockchains
Simplified workflow of proof of work or proof of stake-based blockchains is as follows ( Fig. 2 ): 1. Transactions are created by peers usually using unspent-transaction-output rules which states that to create a new transaction it must have input transactions which are not used in any other transaction as the input transactions and value of the new transaction is at most the total value of the input transactions. Although there are other blockchain systems which use different transaction creation rules. 2. After creating the transaction the peer publishes the transaction to the blockchain network. This new transaction will be added in a block by a miner. 3. After creating a new block a miner solves the proof of work puzzle by producing a random string such that its Hash has a predefined pattern. After solving the mining puzzle, the miner publishes the new block to the blockchain network. 4. Other miners, upon receiving the new block will verify the transactions in this block and verify if the puzzle has solved correctly. If the new block is correct then it will be added to the blockchain. 5. Each block contains a parent block information. After verifying the new block, a miner will add the new block as the child block of the block labelled as the parent block in the new block. 6. The new block will be regarded as the blockchain head if its distance from the first block is more than any other block. 7. It may be possible that the new block's parent block is not the last known blockchain head. In such a case, if the distance from the new block to the first block is more than any other block then the miner will regard the shortest path from the new block to the first block as the valid blockchain.

Offline channels
The basic protocol for using an offline channel (for Bitcoin Lightning network [6] ) is as follows (shown in ( Figs. 3 and 4 )): 1. Offline channels use Hashed Time Locked Contracts 1 to create and update channels. 2. Say Alice and Bob wants to create a channel between them with balances 10 tokens (each contributes 5 tokens). 3. Alice and Bob creates two pairs of lock (hash) and key (random string). They exchange the locks. 4. Bob creates a 'confirmation transaction' as follows: (a) There is a multi-signature address between them which requires a signature from both to transfer funds from it. We will call this address M 1 . (b) Bob creates transactions from M 1 which states that Bob will get 5 tokens and the remaining 5 tokens will go to another multisignature address between them. We will call this address M 2 . (c) The 5 tokens in M 2 will be given to Alice after 10 days or Bob can claim it if it can produce the key to the lock of Alice. 5. Bob signs this transaction and sends it to Alice who can use it to get tokens from the channel by signing it and publishing it to the blockchain network. 6. Alice produces a mirrored confirmation transaction and sends it to Bob. The confirmation transactions ensure that both parties can recover from if they fund the channel between them. 7. Now Alice and Bob transfer funds in the multi-signature address by creating transactions in the blockchain and hence the channel becomes operational. 8. Both parties should exchange keys and create new confirmation transaction to update the channel. They do not need to update the blockchain as the update confirmation transactions. 9. If any party announces a confirmation transaction then the channel closes.
Further, the offline channel network supports Path-Based Fund Transfer (PBT). A PBT uses a path between two parties in a channel network for funds transfer between them. The path is a collection of channels and PBT allows peers without a mutual channel to transfer fund in offline. A PBT protocol [6] for this offline channel network is as follows: 1. Say Alice wants to send funds to Carol via Bob. 2. Carol will create a lock and a key. 3. In the multi-signature address between Carol and Bob, a contract will be created as follows: (a) Bob will send 5 tokens to this address.

Secure serialisation with offline channels
In this paper, we will use proof-of-work based consensus model for blockchains and Bitcoin Lightning network as a model of offline channels. The blockchain network is consists of nodes from the regulator, the manufacturer, the intermediators, the retailers, and the consumers. Briefly, our serialisation solution is as follows ( Fig. 5 ): • We introduce a concept of local serial numbers between pairs of parties who are involved in an immediate change of custody of products. The local serial numbers are used to record the change of custody event between two parties. We use bi-directional offline channels similar to Bitcoin Lightning network as discussed in Section 3 , to generate these local serial numbers. The main blockchain records the creation of channels, i.e., the initial assignment of serial numbers but does not need to record the updated assignment of local serial numbers. For example, an offline channel between parties A and B records that, A has the local serial numbers x 1 , x 2 . An updated channel may indicate that A has serial number x 1 and B has serial number x 2 , i.e., A has transferred serial number x 1 to B. It means there was a product with the label x 1 and A sent it to B . • Next, similar to Path-based fund transfer, we will use a path among all parties in a planned change of custody for such local serial number transfer among pairwise parties. • First, the regulator sends a genuine serial number to the manufacturer using such an offline channel and the manufacturer labels a product with the serial given by the regulator. • Next, the manufacturer receives a request for a product from the retailer and the payment for it. The manufacturer forms a planned change of custody of the product and informs the retailer about the identification number of the product to be sent and planned change of custody. • We develop a protocol to record the change of custody from the manufacturer to the retailer via intermediator nodes using offline channels and local serial numbers among them. The protocol is similar to PBT. • Next, once a consumer buys a product, the PBT in the previous step is extended as the consumer becomes the last node (recipient of a PBT). The consumer initiates the execution of the PBT. If all contracts are executed from the consumer to the regulator then it means that the product has followed the proper change of custody. • We use Hashed Time Lock Contracts and time in these contracts is at most the shelf-life of a product. Hence a successful PBT execution will happen before a product's shelf life expires. • The regulator issues a set of unique serial numbers. The manufacturer creates PBTs only using unique serial numbers hence, serial numbers can not be reused i.e., stolen and used in counterfeiting.
Next, we present a detailed description of the above-mentioned procedure: First we will discuss how to create channels for local serial numbers. Next, we will show how a regulator sends the serial number to the manufacturer, how the manufacturer records change of custody information to the retailer, and how the consumer is included in change of custody events and how it verifies a proper change of custody by executing a PBT.

Creation of local serial numbers
In this paper, we will use proof of work-based blockchains such as Bitcoin. However, the proposed solution can be implemented in any model of blockchains that allows the creation of a multi-signature address. This is because we will need multi-signature addresses to create an offline channel.
We will use the Bitcoin transaction data structure with additional field serial numbers which can be empty. This additional data field does not change the transaction acceptance and consensus principles of the Bitcoin blockchain model. Protocol 1 assigns secret local serial numbers to the parties in a supply chain. A party A may be assigned a set of local serial numbers which satisfies the following properties: • These serial numbers are only known to A . The blockchain network records A 's commitment to these numbers, i.e., A can choose the local serial numbers and does not reveal it to anyone but it can not modify these numbers. • If there is a change of custody of a product from A to B using a local serial number H ( H ( H ( k ))) then B can only prove that it has received the product from A if B can present k . • In Protocol 1 A creates a serial number by creating a random text k and it's Hash H ( k ). A uses H ( k ) in a transaction tx 1 to B. B sends back these serial numbers to A by creating a transaction tx 2 whose input is tx 1 . B can be any node in the blockchain or A can create a new transaction to itself to generate new serial numbers. • A party can only use local serial numbers if it is mentioned in unspent transactions and only this party knows the key to this serial number. • Further, it is required that Tx 1 is unspent and all parties in a supply chain will be given a fixed number of unspent transactions (with random serial numbers) which they will use to generate the first set of serial numbers.

Creation of offline channels for serial numbers
The protocol for creating a new channel between two parties A and B is as follows (shown in Fig. 6 ):    H ( a 1 ), H ( a 2 )). As these transactions are recorded in the blockchain, the channel between A and B becomes operational.

A creates a key K A (random string) and Lock H ( K A ) (Hash of K A ). A informs B about H ( K A ). Similarly, B informs
Next, the protocol to update a channel is as follows (shown in Fig. 7 ): 1. First, both parties exchange the key for their respective locks in the last confirmation transaction. Next, they prepare updated confirmation transactions.

Regulator to manufacturer
The serialisation protocol for transferring serial numbers from the regulator to the manufacturer is as follows (Illustrated in Fig. 8 ): • We will use channel creation and updating protocol for local serial number transfer for secure transfer of serial number from the regulator to the manufacturer.
• The initial channel balance between them is as follows: Let H (k 1 ) , . . . , H (k n ) are the Hash of serial numbers k 1 , . . . , k n .
According to the first HLTC of this channel, all serial numbers will be assigned to the regulator's account after a finite timeout. • The manufacturer can request a set of serial numbers from the regulators and upon receiving such a request, the regulator will update the channel. For example, by updating the channel as serial numbers H (k 2 ) , . . . , H (k n ) belong to the regulator and the serial number H ( k 1 ) belongs to the manufacturer, the manufacturer reveals k 1 to the manufacturer.

Manufacturer to retailer
The protocol for serialisation for transferring serial numbers from the manufacturer to the retailer is as follows: • The retailer places the order of a product by paying for it to the manufacturer. After receiving the payment, the manufacturer prepares a planned change of custody of the product and informs the retailer about H ( K 1 ) ( K 1 is the serial number that the manufacturer received from the regulator) and sequence of public keys of all parties in the planned change of custody of the product. • The manufacturer communicates and creates a sequence of HTLCs where each intermediator participates in two HTLCs.
In each of these HTLC there are two locks H ( H ( K 1 )) and H ( E ( P k ( I 1 ), K x )) (Hash of ciphertext for string K x and the public key of intermediator I 1 .)  • The manufacturer informs I 1 about E ( P k ( I 1 ), K x ) as I 1 can decrypt it with its private key to produce its Hash to satisfy the HTLC lock requirement. • The time mentioned in each HTLC is less than the shelf life of the product and less than the time in the previous contract.
• HTLCs are formed as the product moves through the supply chain and it is only triggered by either the retailer or the consumer (described in the next section).
The above sequence of HTLCs can have the following outcomes of executions: • The retailer or the consumer triggers the sequence of HTLCs before the shelf life of the product expires by sending H ( K 1 ) to all intermediator nodes using Onion routing. In this example, the encrypted message from the retailer to the intermediator I 2 is: By decrypting it, I 2 will know that the key to the HTLC is H ( K 1 ) and the remaining message should be sent to I 1 . Successful execution of HTLCs before the time mentioned in each HTLC will mean that the product is sold before its expiry date. • If the HTLCs are not executed using H ( K 1 ) then it will be executed using the timeout option. It will indicate that either the product is not sold and it can not be sold in the future.

PBT execution by consumer
The protocol for serialization from the retailer to the consumer is as follows: • The consumer pays for the product and receives H ( k 1 ) from the retailer.
• The consumer then informs the manufacturer about the identity of the consumer as its public key and label of the product H ( H ( K 1 )). • The manufacturer asks the consumer to establish an HTLC with the retailer with time out within next few minutes, the first Lock as H ( H ( K 1 )) and second lock as E ( P k ( C ), K 3 ) where P k ( C ) is the public key of the consumer and K 3 is a random string. • This means the sequence of HTLC contracts for the product H ( H ( K 1 )) is extended with a new HTLC contract. • Next, the consumer triggers the HTLC contracts by producing H ( K 1 ) and D ( Priv K ( C ), E ( P k ( C ), K 3 )) ( Priv K ( C ) is the private key of the consumer).

Incentives for HTLC execution
In the previous sections, we used HTLCs to transfer local serial number between two parties. The incentive for executing PBTs in the Bitcoin Lightning network is to claim back funds. For example, assume that there are two HTLCs in a PBT as HTLC 1 between A and B and HTLC 2 between B and C . Here B is an intermediator node for a PBT between A and C. HTLC 2 is triggered by C as it produces the key to the lock of HTLC 2 . B should use the same key to trigger HTLC 1 . In crypto-currency networks, the incentive for B is to claim back tokens. In this case, B is claiming back tokens from A by trigging HTLC 1 which has already sent to C in HTLC 2 . The incentives for B to trigger HTLCs in the PBTs mentioned in previous sections are as follows ( Figs. 9 and 10 ): • All parties are given fixed numbers to initial serial numbers and unspent serial numbers are required to create new serial numbers. • Hence it is in the interest of node B to trigger the HTLC and claim local serial numbers from A , which it will use to create new local serial numbers.

Physical labelling of products
Products in the supply chain will have physical labelling H ( H ( K 1 )) where K 1 is the actual serial number only known to the regulator and the manufacturer. Note that, after receiving a purchase order from the retailer, the manufacturer forms the sequence of HTLCs. As the product moves in through the intermediators, the product label is recorded and relevant events are recorded separately. These events are needed before the execution of the PBT. The retailer only execute the PBT after receiving the product and intermediators can not record product movement event without physically accessing the product, i.e., reading RFID tags in close proximity.

Offline network topology
The proposed solution is designed for a large scale supply chain where no party has absolute control over the supply chain and parties have various levels of trust issues with other members of the supply chain. We use offline channel networks similar to the Lightning network of Bitcoin. Besides the members of the supply chain, i.e., regulator, manufacturer, intermediators, retailer, consumers, there may be other permissioned nodes who can facilitate serialisations.

Scalability
Our solution improves the scalability of the serialisation by using offline channels. Offline channels improve scalability by reducing the number of transactions needed to be recorded in the blockchain. There are only two transactions needed to be recorded for every channel. One transaction is needed to open the channel and one transaction is needed to close the channel. We use channels to transfer local serial numbers from one party to another. We allow a limited number of serial numbers to be used in one channel. Hence channels are regularly closed (i.e., change of serial number assignment is recorded in the blockchain). If in a channel a party can transfer x serial numbers to another party then reduction in number  Fig. 11 illustrates the sequence of events as a serial number propagates through a supply chain according to our serialisation method. At t 1 the regulator records (in the blockchain and visible to all members of the blockchain) H ( H ( H ( K 1 ))) as a local serial number using the procedure mentioned in Section 4 . At t 2 , the regulator sends serial number K 1 to the manufacturer using an offline channel between them as mentioned in Section 4 . At t 3 , the retailer places an order for the product and receives H ( k 1 ) as the serial number. The manufacturer chooses a planned change of custody of the product through intermediator nodes and creates a sequence of HTLCs. In this example, there is one intermediator. At t 4 the intermediator knows about H ( H ( K 1 )) as Lock of the HTLC. At t 5 the retailer knows about H ( H ( K 1 )) as Lock of the HTLC. At time t 6 the consumer buys the product and gets the HTLC with lock H ( H ( K 1 )) and key H ( K 1 ) (at time t 7 ). The consumer triggers the chain of HTLCs as the intermediator and the manufacturer receive H ( K 1 ) at t 8 and t 9 respectively. We will use this sequence of events to describe the attack scenarios.

Solution to trust problem 1
Stealing serial numbers: Uniqueness of serial numbers is a concern for the regulator. In this case, an adversary steals a genuine serial number and label counterfeit products with it. Serial numbers can be stolen in the following scenarios: • At t 1 : The manufacturer records a valid serial number K 1 as H ( H ( H ( K 1 ))). All members of the blockchain network can access H ( H ( H ( K 1 ))) but it can not generate K 1 from it and hence no other party can label products using K 1 . • At t 2 : The manufacturer receives the serial number at t 2 and it can label multiple products with the same serial number.
In this case, there will be multiple PBTs to the consumer with the same lock for the HTLCs. As channels from manufacturer to consumer are regularly closed and reopened, transactions with the same lock for HTLC will be recorded in the blockchain. The regulator can periodically search the transaction list to find a duplicate lock for HTLCs. Hence the regulator can find that the manufacturer has labelled multiple products with the same serial number. • At t 3 : The retailer knows about the Hash of the serial number K 1 . It is possible that the retailer reveals H ( K 1 ) to an adversarial manufacturer who wants to label a counterfeit product with H ( H ( K 1 )) and create a similar sequence of HTLCs. In this case, if the sequence of HTLCs is executed then the blockchain will record multiple sequences of HTLCs with the same lock. The regulator can detect that by searching the transactions in the blockchain. A similar explanation holds if the consumer at t 6 , t 7 reveals H ( K 1 ) to an adversarial manufacturer.
• At t 4 : The intermediator has the information H ( H ( K 1 )) as lock of the HTLCs and physical label of the product. It is possible to label a fake product with H ( H ( K 1 )) but it is not possible to create the sequence of HTLCs as it is not possible to construct H ( K 1 ) from H ( H ( K 1 )). • At t 8 : The intermediator knows H ( K 1 ) as the key to lock in its HTLC. It may share the key with an adversarial manufacturer but as mentioned before the regulator can search the transactions for HTLCs with duplicate locks.

Solution to trust problem 2
• Change of custody: We claim that the product will be verified if it has propagated according to a planned change of custody because: • It is not possible to execute the HTLCs by parties who are not in the planned change of custody. Note that, we include an additional Lock in the HTLC and its key can be only decrypted using the private key of a party. Hence an illegal change of custody will not be possible as long as combinations of public-private keys are secure. • The shelf life of perishable food products: The manufacturer can be assured that a product is either sold before its expiry date or discarded after its shelf life expires.
• The manufacturer decides on the time of each HTLC and it can choose the time locks in such a way that in the last HTLC the time is at most the shelf life of the product. This means either the product can not be sold after its shelf life as HTLC will not be executed. • Stealing serial numbers: The manufacturer may be concerned about stolen serial numbers. Serial number stealing scenarios from t 3 to t 9 are applicable in this case. As explained in trust problem 1, in these scenarios serial numbers can not be stolen.

Solution to trust problem 3
• Change of custody: The change of custody problem for an intermediator node is to ensure that it receives a product and sends a product according to a correct change of custody. The intermediator can be assured of proper change of custody because: • Only a manufacturer decides on a planned change of custody and it communicates with intermediator as proper HTLCs are created. • It is possible that an adversarial manufacturer creates a change of custody with stolen serial numbers. In such a case, as mentioned in trust problem 1, the regulator can search for duplicate locks in HTLCs. • The shelf life of perishable food products: The intermediator can ensure that it received a product before its shelf life expires because: • If an intermediator receives a product after the shelf life expires then it will mean that time in its HTLC has also expired. Hence it can not receive and send a product with expired shelf life.

Solution to trust problem 4
• The change of custody: We claim that the retailer can verify that a product will be verified if it has propagated according to a planned change of custody: • The retailer can initiate the execution of the sequence HTLCs by providing H ( K 1 ) to the intermediator node. It means that HTLCs with the lock H ( H ( K 1 )) will be executed and hence change of custody for the product labelled with H ( H ( K 1 )) occurred. • The retailer decides on additional key x 1 for each intermediator where the lock is E PK I 1 (x 1 ) ( x 1 encrypted public key of intermediator I 1 ). Only I 1 can decrypt the additional lock in its HTLC.
• The shelf life of perishable food products: The retailer can ensure that it receives a product before its shelf life expires.
• Same explanation as trust problem 3.

Solution to trust problem 5
• Change of custody: The consumer can verify that a product has propagated according to a planned change of custody because: • As the product is sold, the retailer informs the consumer H ( K 1 ) and forms an additional HTLC where H ( H ( K 1 )) is the lock. The consumer can trigger the sequence of HTLCs and the successful execution of the HTLCs will indicate that proper change of custody is followed. • The shelf life of perishable food products: The consumer can ensure it buys a product before its shelf life is expired because: • The time in the sequence of HTLCs from the manufacturer to the retailer is such that maximum time is less than the shelf life of the product. Hence successful execution of the HTLCs means that the product is sold before its shelf life has expired.