A Traceable and Verifiable Tobacco Products Logistics System with GPS and RFID Technologies

Abstract

Tobacco products are an addictive commodity. According to the World Health Organization’s (WHO) latest statistics data, tobacco kills more than eight million people each year. In 2003, the WHO proposed the Framework Convention on Tobacco Control (FCTC) to provide an effective framework for the control of tobacco products to governments around the world. In the field of tobacco products, the hardest problem is how to prevent counterfeit tobacco products and smuggling. To solve the problems, we proposed a blockchain-based traceable and verifiable logistics system for tobacco products with global positioning system (GPS) and radio-frequency identification (RFID) Technologies. In this research, we provide an overview of system architecture, and also define the protocol and the smart contract in every phase that stores data into the blockchain center. We realized a decentralized database and authentication system that uses blockchain and smart contract technology; every protocol in every phase was designed to achieve the integrity of data and non-repudiation of message. Every tobacco product’s shipping record will be completed by scanning the RFID tag and retrieving the GPS with a mobile reader, where the record will be updated and validated in the blockchain center. In the end, the security and costs of the system were analyzed, and a comparison was made with the EU’s (European Commission) method. Our system is more flexible for transportation, more secure in the communication protocol, and more difficult to tamper and forge data. In general, the proposed scheme solved the problem of tobacco products counterfeiting and tracking issues.

1. Introduction

1.1. Background

According to the Food and Drug Administration (FDA), tobacco products means “any product made or derived from tobacco that is intended for human consumption, including any component, part, or accessory of a tobacco product (except for raw materials other than tobacco used in manufacturing a component, part, or accessory of a tobacco product)” [1]. Tobacco products include cigarettes, cigars, etc. Tobacco contains the stimulant alkaloid nicotine, which easily makes people addicted.

Since the emergence of tobacco, there have been various studies showing the disadvantages of tobacco products, which can easily damage the lungs, heart, and liver. Common diseases of smoking tobacco include cancer, cardiovascular disease, chronic bronchitis, male sexual dysfunction, pregnant women affect the fetus, etc. Except for the diseases it causes to smokers, smoking tobacco also causes air pollution, and second-hand smoke will also affect the people around smokers. According to the World Health Organization’s (WHO) latest statistical data, tobacco kills more than eight million people each year, with seven million people deaths because of direct tobacco use and 1.2 million non-smokers who are exposed to second-hand smoke [2].

In 2003, the WHO published the Framework Convention on Tobacco Control (FCTC) which provides price and tax measures and non-price measures to reduce the demand for tobacco products [3]. In these decades, many countries worldwide are constantly following the framework established by the WHO, especially by raising the tax rate of tobacco products. Because of the increase in tax rates, the price of tobacco products to the consumer has also increased. Most of the manufacturers or retailers do not report the actual sales volume to the government to more profit, which means that more and more smuggled tobacco products are sold on the market. Smuggled tobacco products cannot be controlled and certified by the government, and there may be elements in the product that affect human health more [4]. In addition, the government has the responsibility to care nation’s health as well as the responsibility to eliminate the smuggled tobacco products.

Recently, to eliminate smuggled products, the European Commission has worked out the mechanisms of tobacco product tracking [5]. In addition, the United States’ FDA also regulates tobacco products with strict standards [6].

To track and identify products, we need a data carrier along with sticks or prints on the package of products. The most common and simple data carrier on the market is the barcode, which include one-dimensional (1D) and two-dimensional (2D) barcodes. GS1 is the largest not-for-profit organization [7], and they developed the global standards for barcodes, so that the standards can be universally used all over the world. Barcodes have many limitations that make them unsuitable for logistics tracking such as easy to damage, easy to copy, easy to decode, and they must be scanned individually. Because of these shortcomings, other options have to replace the barcode in the next technology, which is radio-frequency identification (RFID). RFID is a technology that is able to store and retrieve data in the RFID tags, so is the best method to use in supply chains [8,9]. RFID accelerates the speed of inventory, and it is more convenient to calculate the total amount of incoming and outgoing logistics.

Unfortunately, data carriers alone cannot track the delivery process of tobacco products. The information in the system can be easily maliciously or deliberately falsified by anyone. Blockchain technology can solve the problem of information reliability. Kamilaris et al. [10] proposed a blockchain-based method for agriculture and food supply chains, where the research showed that blockchain can make the supply chain more transparent and reliable. Therefore, blockchain is a new technology that can realize the traceability and authentication of the logistics record.

In this study, we proposed a traceable and verifiable tobacco products logistics system that involved blockchain, GPS and RFID technologies. All the tobacco packages produced by the manufacturer must have an RFID tag with ID. These IDs are issued by an official organization. After the tobacco products are produced, all the logistics processes must be sent and chained in the blockchain center. The proposed scheme achieves the goal of data decentralization, is hard to tamper with, has traceability, and is authenticated. It is also convenient for the consumer to verify, for manufacturers to manage, and for the auditor to audit.

1.2. Related Works

Several related works are listed in

Table 1. Survey of related works.

Authors	Year	Objective	Technologies	1	2	3	4	5	6
Wyld [9]	2008	RFID tag sticks to cigarettes and taxes	RFID	N	Y	N	N	Y	N
Wang et al. [11]	2011	RFID tag integration into a cigarette pack	RFID	N	Y	N	N	Y	N
Carvalho et al. [8]	2012	Deploy RFID to fashion supply chains	RFID	N	N	Y	Y	Y	N
Shi et al. [12]	2012	Track and trace system for supply chains	RFID	N	N	Y	Y	Y	Y
Prasanna et al. [13]	2012	Logistics vehicle load balancing and tracking mechanism	RFID, GPS, GSM	N	N	Y	Y	Y	N
Li et al. [14]	2016	Tobacco logistics retroactive system	RFID, database	N	Y	Y	Y	Y	N
Liu et al. [15]	2018	Financial service platform for tobacco supply chain	Blockchain	Y	Y	Y	N	N	N
Humayun et al. [16]	2020	Smart logistics and transportation using IoT and Blockchain	Blockchain, IoT	Y	N	Y	Y	N	N

Notes: 1: Focus on a blockchain, 2: Focus on tobacco products, 3: Proposing an architecture or framework, 4: Focus on logistics, 5. RFID/GPS-enabled, 6: Security analysis, Y: Yes, N: No.

. The key points of concern are listed in the table.

RFID technology has been used in the trace system for supply chains for many years. Wyld [9] evaluated the uses of RFID tags on cigarette packs. The research explains how the RFID works as well as how the RFID can solve the products’ smuggling problem and inventory control as the technology can be scanned to verify whether the taxes have been paid or not. Wang et al. [11] redesigned a passive ultra high frequency (UHF) RFID tag and integrated it into a cigarette pack, where the tag was only 0.5 mm thick. Neither of these two studies mentioned how to use RFID to implement a supply chain system.

Some research has been implemented in the supply chain of non-tobacco products. In 2012, Carvalho et al. [8] deployed RFID technology in the case of fashion supply chain management (FSCM). Shi et al. [12] also proposed a RFID-enabled trace system implemented with the Electronic Product Code (EPC) global network, which is a global data exchange standard for supply chain networks, where the user can query product information via scanning the RFID with the EPC. These studies have proposed a good architecture for implementation in the supply chain, but the studies lacked integrity and traceability of data.

Aside from implementing RFID technology, global positioning system (GPS) can also be integrated into logistics tracking systems. Prasanna et al. [13] proposed a logistics vehicle tracking mechanism in 2012, where the authors implemented a GPS device in the vehicle to record and track the real-time location and used the global system for mobile communication (GSM) to upload those data to the server. The GPS helps to bind and record the delivery location of the products, and this location can improve the data completeness of the logistics system. Unfortunately, the authors did not analyze or prove the security of their system.

Regarding tobacco product-related systems, Li et al. [14] proposed a retroactive system with a database. Their system could solve the problem of product tracking, but the security of traditional databases may be challenged. For example, if the administrator’s account is maliciously logged in, the data in the database can be easily tampered with by the attacker and hard to trace. Liu et al. [15] briefly introduced a financial service platform for the tobacco supply chain. These studies have provided a framework of the tobacco products’ supply chain system, however, although the second research mentioned the use of blockchain technology, the description was not complete, and it did not mention how blockchain was applied.

Recently, Humayun et al. [16] applied blockchain technology and IoT in the logistics system. The research analyzed the advantages of applying blockchain and IoT technology, but they did not analyze the security issues.

The studies listed above have advantages and disadvantages for us to refer to. Consequently, we proposed a system with a comprehensive architecture with security. In this research, we applied blockchain, RFID, and GPS technology to achieve the complete tobacco products’ logistics system.

The remaining sections of this paper are organized as follows. Section 2 briefly introduces the technologies that are used in our proposed scheme. Section 3 proposes our scheme. Section 4 analyzes the security issues. The computation cost, communication performance, and comparison discussion are given in Section 5. Finally, Section 6 concludes this paper.

2. Preliminary

2.1. Consortium Blockchain and Smart Contract

Blockchain is a technology that was carried forward by Nakamoto [17], who used blockchain to realize a decentralized peer-to-peer cryptocurrency. Blockchain is a distributed database, with the characteristic that it is difficult to arbitrarily tamper.

A smart contract is a program that can be executed automatically. The most famous blockchain-based smart contract in the world was implemented by Buterin in 2014 [18], who also founded Ethereum. The blockchain-based smart contract can be implemented in various domains, for example, digital property [19], logistics systems [20], the exhibition of cultural relics [21], will management [22], firearm management [23], etc.

In general, the most widely used blockchain currently is Ethereum [18], which is a public blockchain where everyone can store and validate the block data transparently. In order to solve privacy issues and make blockchain technology more suitable for enterprises, more types of blockchain architectures have also been developed such as private blockchain [24] and consortium blockchain [25]. In particular, the consortium blockchain is a blockchain between public and private. Generally, it is possible to specify how many peers can own the ledger, and then which peer can conduct transactions and own part of the ledger. On the other hand, every blockchain system has an important consensus algorithm to validate the blockchain, and there are various types of consensus algorithms such as Proof-of-Work (PoW), Proof-of-Stake (PoS), and Practical Byzantine Fault Tolerance (PBFT) [26].

To solve the problems encountered in business such as data privacy issues, real-time transactions, modular expansion, etc., the Linux Foundation has developed a blockchain architecture of chaincode (also known as a smart contract with additional features) that is more suitable for commercial applications, the Hyperledger Fabric [27]. The Hyperledger Fabric is a permissioned blockchain, where the chain contains the chaincode, ledger, and channel. The common implementation of the consensus algorithm in the blockchain is PBFT. Therefore, it is different from other types of blockchain architecture because it does not need a cryptocurrency-based mechanism to mine, in order to validate the ledger or execute the smart contract.

Figure 1 shows an example of the Hyperledger Fabric network from the official documentation [28]. The notation of nodes in the figures are as follows: Application (A), Certificate Authority (CA), Channel (C), Peer (P), Ordering Service (O), Ledger (L), Chaincode (S), Organization (R), and Channel Configuration (CC). The organization is defined by the Membership Services Provider (MSP), where every organization configures the channel configuration and makes each node join in a secure private channel. The certificate authority generates the certificates to the nodes, and the certificates must be signed in every transaction. When any client executes an application, the application sends a transaction proposal to all endorsing peers via the configured channel. These peers reply to a signed proposal response to the application. The transaction will package into a block by ordering the service node; the node also orders and distributes it to every peer, then the transaction is done and updates to the blockchain network.

Our scheme proposes tobacco products logistics with Hyperledger Fabric framework, where the purpose is to have more throughput for the transactions, solve the personal privacy problem, and be more suitable for the government to manage.

2.2. ECDSA

The elliptic curve digital signature algorithm (ECDSA) is the derived type of the digital signature algorithm (DSA) [29]. Johnson et al. [30] introduced that ECDSA be accepted in any global standard. ECDSA is accepted in the following standards: ISO 14888-3, ANSI X9.62, IEEE 1363-2000, FIPS 186-4, ANSI X9.142-2020.

ECDSA involves the concept of elliptic curve cryptography (ECC), the characteristic of ECC reduces the key size in the algorithm and also provides a faster calculation speed compared to DSA. According to the NIST’s minimum security-strength requirement [31], the length of n with 224 bits and SHA-512/224 for digital signature generation is required.

2.3. BAN Logic

Burrows–Abadi–Needham Logic (BAN Logic) is a method of authenticating communication protocols that was first proposed by Burrows et al. [32] in 1990. It is important to prove the security and integrity of the protocol, and the main purpose is to prove that there are no security issues in the security protocol, and that the protocol can also meet the designer’s expectations of the method.

2.4. Threat Model

According to Table 1, we sorted and reviewed the past research, and found some research gaps. Therefore, we sorted out the threat patterns that need to be overcome. The threats are generally due to system security vulnerabilities, which may cause the system to be attacked illegally by an external malicious person, or may cause the system to crash and leak data. As a result, the tobacco products logistics system will suffer from potential risks. The related risks are defined as follows:

(1)

Data integrity issues: All data stored with the system must be integrated. The system must ensure that the data will not be modified by anyone during the transmission and storing process.

(2)

Decentralized database: The blockchain center can be known as the decentralized database, with multiple agencies maintaining the same ledger or data in different locations. Once the data are verified and added to the blockchain, the block is chained with a timestamp and the previous block hash value; every modification with the blockchain needs to be verified. Therefore, it is hard to change the data in the blockchain center, and the decentralization characteristics can achieve data transparency and reliability.

(3)

Decentralized authentication: The authentication inherits the decentralized database’s characteristics. This is more secure than the general database that is set up with the central server architecture.

(4)

Message repudiation issues: To ensure the undeniable transmission of the message sent by the sender, a signature mechanism needs to be implemented to prove the message is signed by the sender.

(5)

Message transmission issues: The system must be ensured that the message will not be intercepted and altered during transmission.

(6)

Tobacco product counterfeiting issues: The counterfeiting of tobacco products can harm the health of the smoker, they never know the legal origin and quality of the products. Furthermore, the counterfeiting products will also cause the original manufacturer to lose their reputation.

(7)

Tobacco product tracking issues: These issues are linked to counterfeit issues. The government needs a complete tracking system to manage the logistics status of tobacco products.

(8)

Fair arbitration: Every system that is managed or used by a human with multiple parties cannot avoid dispute. To avoid disputing the legality of tobacco products, fair arbitration should be considered to clarify smuggled tobacco products.

(9)

Known attacks:

• Man-in-the-middle attack: The sender needs to communicate to the receiver, the attacker intercepts the message in the middle, then the attacker is able to obtain the message from the sender and resend the same message to the receiver. Therefore, the message will be exposed, because the attack can easily obtain the content of the message in the middle.
• Replay attack: The attacker sniffs the message sent by the sender, so the attackers can replay the message.

3. The Proposed Scheme

In this research, we proposed a blockchain-based traceable and authenticated tobacco products logistics system with GPS and RFID technologies. The proposed system is constituted of the following twelve parties: ID issuer, tobacco ID tag, mobile reader, competent authorities, manufacturer, distributor, logistics, retailer, consumer, arbitrator, auditors, and blockchain center. The system framework is shown in Figure 2.

3.1. System Architecture

• ID Issuer (IDI): An official organization authorized by the government of the country. They receive the application of the tobacco products’ ID from the manufacturer. This party checks the validity of the manufacturer; if they are a legal company, a list of tobacco products will be generated by the chaincode in the blockchain center.
• Tobacco ID Tag (TID): A unique ID issued by the ID issuer. The ID is a sticker-based material with a RFID tag. Every pack of legal tobacco products should have one ID tag to prevent smuggled products.
• Mobile reader (MR): A mobile device that can read tobacco ID tags and can position the location with GPS. Every party involved in the logistics phase must have at least one MR such as the manufacturer, logistics, distributor, or retailer. These parties need to log in to the MR with their private key. Every TID on the tobacco products should be scanned by MR when the tobacco products are produced, sent, or received by the shipper or recipient.
• Competent authorities (CA): Multiple official organizations that are authorized by the government of the country such as the Food and Drug Administration (FDA), Federal Trade Commission (FTC), Tobacco Tax, Trade Bureau (TTB), etc. Every CA must have the ledger in the blockchain center to ensure and verify the integrity of the data. The CA that provide the permits for the production of tobacco products have the highest authority and mainly deal with any connection from other parties.
• Manufacturer (MF): A company that produces tobacco products; it can also be a tobacco importer. Before producing tobacco products, they need to apply the product’s ID from the ID Issuer. The ID that is applied and obtained from the IDI should be applied to the tobacco package.
• Blockchain Center (BCC): The blockchain that records the logistics information of the tobacco products. When a manufacturer needs to produce tobacco products, they need to apply an ID from the IDI, the ID is generated from the BCC’s chaincode, then the TID is sent to IDI via CA before finally going to the MF. Every record of the tobacco products will need to be chained with the given ID. The chaincode in the BCC keeps checking the number of tobaccos during the logistics.
• Distributor (DI): A company buying a large number of tobacco products from the MF is known as a wholesaler. They are also sellers who sell products to retailers.
• Logistics (LG): A company responsible for transporting the tobacco products. They mostly use trucks to transport the products. All products entering or leaving the transportation need to scan the logistics information via MR to BCC and chain it, for example, the ID, timestamp, and GPS location.
• Retailer (RT): A shop or store selling the unit packet of tobacco products to the consumer.
• Consumer (CS): An ordinary person that needs to buy tobacco products from the retailer.
• Arbitrator (AB): An official agent that is able to use a mobile device with the Internet to find counterfeit or illegal tobacco products whether the tobacco products are in retailers, distributors, etc.
• Auditors (AU): A third-party agency. If either party is unsure of the legal source of the tobacco products, the auditors have the right to prove if there are any problems in the logistics process.

Figure 2 presents the scenarios that illustrate the process of tobacco products from the manufacturer to consumers through the distributor, retailer, and multiple logistics. There will be more than one manufacturer, distributor, retailer, and logistics in reality, so we used the basic elements to represent in this figure. A detailed description is as follows:

Step 1.

All parties involved in the tobacco products logistics chain must register an account from the BCC to obtain a unique ID and a private and public key pair.

Step 2.

When the manufacturer needs to produce a batch of tobacco products, they need to apply to the IDI for the ID to every pack, batch, or any aggregation level of the tobacco products.

Step 3.

The IDI sends the application to the CA, then the CA requests from the BCC to execute a chaincode. The BCC responds to the IDI with a list of IDs that corresponds to every pack of tobacco products.

Step 4.

The IDI approves the application from the MF and responds a list of IDs to them.

Step 5.

After receiving the IDs, MF produces tobacco products. Every pack of tobacco products needs to send the GPS location, ID, the timestamp of production, and the MF’s ID by the MR to the CA, then the information is sent and chained in the BCC.

Step 6.

The MF requests LG to deliver the products to the DI to distribute the tobacco products.

Step 7.

When LG receive the products, they need to scan and send the products’ GPS location, ID, timestamp, and LG ID to the CA, then the information is sent and chained in the BCC.

Step 8.

After LG arrive at the DI, the information of the GPS location, ID, timestamp, and LG ID also needs to be sent and chained in the BCC via CA.

Step 9.

DI needs to scan and send the products’ GPS location, ID, timestamp, and DI’s ID to CA, the information is sent and chained in the BCC.

Step 10.

DI needs LG to deliver the products while the DI sells the tobacco products to the RT.

Step 11.

Once LG receives the products from the DI, they need to scan and send the products’ GPS location, ID, timestamp, and LG ID to the CA, then the information is sent and chained in the BCC.

Step 12.

LG delivers the tobacco products to the RT, the information of the GPS location, ID, timestamp, and LG ID also needs to be sent and chained in the BCC via the CA.

Step 13.

To ensure the validity and total amount, the RT requests to scan and send the products’ GPS location, ID, timestamp, and RT ID to the CA in the last logistics session, then the information is sent and chained in the BCC. Next, the retailer starts to sell tobacco products to the consumers.

Step 14.

A consumer goes to a retailer to buy tobacco products. The consumer needs to provide their ID for the legal transaction.

Step 15.

RT sends all the transactional information including the CS ID, transaction ID, RT ID, and timestamp to the CA, then the transactional information is sent and chained in the BCC.

Step 16.

The transaction is done between the RT and CS. The tobacco product is traced until this step.

Step 17.

If any party has a dispute or doubts the legality of the tobacco product, the party can submit an arbitration request to the arbitrator.

Step 18.

The details of the tobacco products’ logistic records were chained in the BCC, and the AB can retrieve and verify the logistics record from the BCC.

3.2. Notation

$I{D}_X$	X is the identity, issued by blockchain center. The format of the ID is [random serial number + timestamp] (total 144 bits)
$TI{D}_Y$	Y is the tobacco identity, which is issued by ID issuer. The format of the ID is [random serial numbers + ID Issuer ID + manufacturer ID + manufacturing timestamp] (total 224 bits)
$q$	A k-bit of prime number
$GF(q)$	Finite group of $q$
$E$	The elliptic curve defined on finite group
$G$	A generating point based on the elliptic curve $E$
$k_i$	The ith random value on the elliptic curve
$(r_{X_{\mathrm{i}}},s_{X_i})$	Elliptic curve signature value of X
$(x_{X_i},y_{X_i})$	An ECDSA signature value of X
$d_X$	The ECDSA’s private key of party X
$Q_X$	The ECDSA’s public key of party X
$Pu{k}_X$	The public key of party X, issued by the BCC
$Pr{k}_X$	The private key of party X, issued by the BCC
$C_{X_i}$	The ith ciphertext of X
$H(M)$	One way hash function
$h_{X_i}$	The ith hash value of X
$T_i$	The ith timestamp
$\tau$	The threshold for checking the validity of a timestamp
$M_i$	The ith message from a sender
$E_{Pu{k}_X}(M)/D_{Prk{x}_X}(M)$	Encrypt/decrypt message M with a public key or private key of party X
$F1\stackrel{?}{=}F2$	Verify that F1 is equal to F2 or not

3.3. Initialization Phase

First, we raised a blockchain center network architecture, as shown in Figure 3. There are three types of peers in the network. The CA peer is the peer governed by multiple competent authorities, so every CA’s peer has a chaincode and blockchain ledger. The BCC network also has a blockchain certificate authority (BCA). The BCA is authorized by the government department to issue authorization-related certificates to every access party such as the MF, LG, DI, and RT. Every access party has its own private channel that connects to the CA’s network, and the ledger is synchronized with the CA’s peers. Every information update through the execution of chaincode must be verified and endorsed by the CA’s peer. If it is valid, the ordering peers will order the transaction record to all of the CA’s peers.

Figure 4 and Figure 5 show the fundamental chaincode structure of our scheme. Figure 4 shows the structure to store the information of the access parties (APs); the enumeration of the role type is defined on the right side. Figure 5 shows the structure to store the tobacco product information, where every detail of the tobacco product will be appended to the structure when it passes through each access party.

3.4. Registration Phase

All parties that want to be a part of the system need to register from the BCA. The BCA generates and sends the public key and private key pair to the parties. The registration process from any access party to the blockchain center is shown in Figure 6.

Step 1.

AP provides the primary information (e.g., name, role) and sends a registration request to the BCC.

Step 2.

BCC generates an ECDSA private key $d_X$ and calculates public key $Q_X:$

$$Q_X=d_{X}G$$

(1)

The application of registration needs to be manually approved by the CA. If the application is approved, the chaincode “Registration” will be triggered; the algorithm is shown in Algorithm 1. Then, BCC sends $(I{D}_X,d_X,Q_X)$ parameters to the AP.

Step 3.

AP receives $(I{D}_X,d_X,Q_X)$ and keeps the parameters for signing the signature message.

Algorithm 1. Chaincode registration of the proposed scheme.

var AP []AP_Information func Registration (X_name string, X_detail string, var X_role RoleType) (UID string) {   UID = GenerateUniqueID()   AP = append (AP, AP_Information{    ID: UID,    Name: X_name,    Detail: X_detail,    Role: X_role,   })   return UID }

3.5. Authentication Phase

In this phase, we assumed that user A is a sender, and user B is a receiver. Every sender and receiver needs to sign and verify their message with the “Sign” and “Verify” function that is shown in Algorithm 2. These two functions implement the ECDSA to achieve identity authentication. The sender generates a signature with a “Sign” function to the receiver. When the receiver receives the message, they execute a “Verify” function to verify. Similarly, when the receiver needs to respond to a message from the sender, the receiver also needs to execute a “Sign” function, then the sender needs to execute the “Verify” function when receiving the response message to ensure each other’s true identities. The flow of the process is shown in Figure 7.

Step 1.

Firstly, user A chooses a random number $k_1$, then generates the message:

$$M_1=(I{D}_A|\left|I{D}_B\right||T_1)$$

(2)

Next, user A calculates the parameters of ECDSA:

$$h_1=H(M_1)$$

(3)

$$(x_{A_1},y_{A_1})=k_{1}G$$

(4)

Afterward, the signatures are generated by executing the function “Sign” in Algorithm 2. In detail, it generates the signatures with the parameters:

$$r_{A_1}=x_{A_1}\mathrm{mod}n$$

(5)

$$s_{A_1}=x_{A_1}{}^{-1}(h_1+r_{A_1}{d}_A)\mathrm{mod}n$$

(6)

A message is encrypted by user B’s public key:

$$C_{A_1}=E_{Pu{k}_B}(M_1)$$

(7)

User A sends a message $(I{D}_A,I{D}_B,C_{A_1},(r_{A_1},s_{A_1}))$ to user B.

Step 2.

IDI receives the message at $T_2$ and uses its private key to decrypt $C_{A_1}$:

$$M_1=D_{Pr{k}_B}(C_{A_1})$$

(8)

Then, user B checks for the validation of the timestamp:

$$(T_2-T_1)\stackrel{?}{\le }\tau$$

(9)

Next, user B executes the function “Verify” in Algorithm 2. In detail, it calculates the following parameters:

$$h_{A_1}{}^{\prime }=H(M_1)$$

(10)

$$u_1=h_{A_1}{}^{\prime }{s}_{A_1}{}^{-1}\mathrm{mod}n$$

(11)

$$u_2=r_{A_1}{s}_{A_1}{}^{-1}\mathrm{mod}n$$

(12)

$$(x_{A_1}{}^{\prime },y_{A_1}{}^{\prime })=u_{1}G+u_2{Q}_A$$

(13)

User B uses those calculated parameters to validate the signature:

$$x_{A_1}{}^{\prime }\stackrel{?}{=}{r}_{A_1}\mathrm{mod}n$$

(14)

If the signature is valid, then user B selects a random number $k_2$ and generates a message:

$$M_2=(I{D}_B|\left|I{D}_A\right||T_3)$$

(15)

Next, user B calculates the hash value and the parameters of ECDSA to generate the signatures $(r_{B_1},s_{B_1})$. The signatures are generated by executing the function “Sign” in Algorithm 2:

$$h_{B_1}=H(M_2)$$

(16)

$$(x_{B_1},y_{B_1})=k_{2}G$$

(17)

$$r_{B_1}=x_{B_1}\mathrm{mod}n$$

(18)

$$s_{B_1}=x_{B_1}{}^{-1}(h_{B_1}+r_{B_1}{d}_B)\mathrm{mod}n$$

(19)

A message is encrypted by user A’s public key:

$$C_{B_1}=E_{Pu{k}_A}(M_2)$$

(20)

Then, user B sends the message $(I{D}_B,I{D}_A,C_{B_1},(r_{B_1},s_{B_1}))$ to user A.

Step 3.

User A receives the message at $T_4$, then decrypts the cipher message by its private key:

$$M_2=D_{Pr{k}_A}(C_{B_1})$$

(21)

Then, user A checks for the validation of the timestamp:

$$(T_4-T_3)\stackrel{?}{\le }\tau$$

(22)

Next, user A executes the function “Verify” in Algorithm 2. User A calculates the parameters:

$$h_{B_1}{}^{\prime }=H(M_2)$$

(23)

$$u_1=h_{B_1}{}^{\prime }{s}_{B_1}{}^{-1}\mathrm{mod}n$$

(24)

$$u_2=r_{B_1}{s}_{B_1}{}^{-1}\mathrm{mod}n$$

(25)

$$(x_{B_1}{}^{\prime },y_{B_1}{}^{\prime })=u_{1}G+u_2{Q}_B$$

(26)

User A uses those calculated parameters to validate the signature:

$$x_{B_1}{}^{\prime }\stackrel{?}{=}{r}_{B_1}\mathrm{mod}n$$

(27)

Algorithm 2. Authentication of the proposed scheme.

func Sign (h string, k string, d string) (r string, s string) {   (x, y) = k * G;   r = x % n   s = (h + r * d)/x % n   return r, s } func Verify (h string, r string, s string) (result string) {   u1 = h/s % n   u2 = r/s % n   (x, y) = u1 * G + u2 * Q   if x == r {     return “valid”   }else{     return “invalid”   } }

3.6. Issuing ID and Manufacture Phase

This is the most important phase to generate the ID of the tobacco products. The flowchart is shown in Figure 8. The related chaincode is shown in Algorithm 3.

Step 1.

Before the MF starts manufacturing the tobacco products, they need to send an application to the IDI to get a obtain of TID. First, the MF chooses a random number $k_3$, then generates the message with the number and information of the tobacco products:

$$M_3=(I{D}_{MF}|\left|I{D}_{IDI}\right|\left|Num\right|\left|Info\right||T_5)$$

(28)

Next, the MF calculates the hash value with the message:

$$h_{M{F}_1}=H(M_3)$$

(29)

and executes the function “Sign” shown in Algorithm 2 to generate the signatures:

$$(r_{M{F}_1},s_{M{F}_1})=Sign(h_{M{F}_1},k_3,d_{MF})$$

(30)

A message is encrypted by the IDI’s public key:

$$C_{M{F}_1}=E_{Pu{k}_{IDI}}(M_3)$$

(31)

MF sends a message $(I{D}_{MF},I{D}_{IDI},C_{M{F}_1},(r_{M{F}_1},s_{M{F}_1}))$ to IDI to apply TID.

Step 2.

IDI receives the message at $T_6$ and uses its private key to decrypt $C_{M{F}_1}$:

$$M_3=D_{Pr{k}_{IDI}}(C_{M{F}_1})$$

(32)

Then, the IDI checks for the validation of the timestamp:

$$(T_6-T_5)\stackrel{?}{\le }\tau$$

(33)

Next, IDI calculates the parameters:

$$h_{M{F}_1}{}^{\prime }=H(M_3)$$

(34)

IDI executes the function “Verify” in Algorithm 2 to validate the signature:

$$Verify(h_{M{F}_1}{}^{\prime },r_{M{F}_1},s_{M{F}_1})$$

(35)

If the signature is valid, then IDI sends a request to the CA for the further ID issuing process. IDI selects a random number $k_4$ and generates a message:

$$M_4=(I{D}_{MF}|\left|I{D}_{IDI}\right|\left|I{D}_{CA}\right|\left|Num\right|\left|Info\right||T_7)$$

(36)

Next, IDI calculates the hash value and executes the function “Sign” in Algorithm 2 to generate the signature:

$$h_{ID{I}_1}=H(M_4)$$

(37)

$$(r_{ID{I}_1},s_{ID{I}_1})=Sign(h_{ID{I}_1},k_4,d_{IDI})$$

(38)

A message is encrypted by the CA’s public key:

$$C_{ID{I}_1}=E_{Pu{k}_{CA}}(M_4)$$

(39)

Then, the IDI sends the message $(I{D}_{IDI},I{D}_{CA},C_{ID{I}_1},(r_{ID{I}_1},s_{ID{I}_1}))$ to the CA.

Step 3.

Once CA receives the message at $T_8$, then decrypt the cipher message by its private key:

$$M_4=D_{Pr{k}_{CA}}(C_{ID{I}_1})$$

(40)

Then, CA checks for the validation of the timestamp:

$$(T_8-T_7)\stackrel{?}{\le }\tau$$

(41)

Next, CA calculates the hash value:

$$h_{ID{I}_1}{}^{\prime }=H(M_4)$$

(42)

The CA executes the function “Verify” in Algorithm 2 to validate the signature:

$$Verify(h_{ID{I}_1}{}^{\prime },r_{ID{I}_1},s_{ID{I}_1})$$

(43)

If the signature is valid, then the chaincode “IDIssue” is triggered to generate a list of TID, the algorithm of which is shown in Algorithm 3. First, CA selects a random number $k_5$ and generates a message with a list of TID:

$$M_5=(I{D}_{CA}|\left|I{D}_{IDI}\right|\left|I{D}_{MF}\right||List<TID>||T_9)$$

(44)

Next, the CA calculates the hash value and executes “Sign” in Algorithm 2 to generate the signature:

$$h_{C{A}_1}=H(M_5)$$

(45)

$$(r_{C{A}_1},s_{C{A}_1})=Sign(h_{C{A}_1},k_5,d_{CA})$$

(46)

A message is encrypted by the CA’s public key:

$$C_{C{A}_1}=E_{Pu{k}_{IDI}}(M_5)$$

(47)

Then, CA sends the message $(I{D}_{\mathrm{CA}},I{D}_{IDI},C_{C{A}_1},(r_{C{A}_1},s_{C{A}_1}))$ to IDI.

Step 4.

IDI receives the message at $T_{10}$, then decrypts the cipher message by its private key:

$$M_5=D_{Pr{k}_{\mathrm{IDI}}}(C_{C{A}_1})$$

(48)

Then, IDI checks for the validation of the timestamp:

$$(T_{10}-T_9)\stackrel{?}{\le }\tau$$

(49)

Next, IDI calculates the hash value:

$$h_{C{A}_1}{}^{\prime }=H(M_5)$$

(50)

IDI executes the function “Verify” in Algorithm 2 to validate the signature:

$$Verify(h_{C{A}_1}{}^{\prime },r_{C{A}_1},s_{C{A}_1})$$

(51)

If the signature is valid, IDI sends a response message to MF with a list of TID. IDI selects a random number $k_6$ and generates a message:

$$M_6=(I{D}_{MF}|\left|I{D}_{IDI}\right||List<TID>||T_{11})$$

(52)

Next, IDI calculates the hash value and executes the function “Sign” in Algorithm 2 to generate the signature:

$$h_{ID{I}_2}=H(M_6)$$

(53)

$$(r_{ID{I}_2},s_{ID{I}_2})=Sign(h_{ID{I}_2},k_6,d_{IDI})$$

(54)

A message is encrypted with MF’s public key:

$$C_{ID{I}_2}=E_{Pu{k}_{MF}}(M_6)$$

(55)

Then, IDI sends the message $(I{D}_{IDI},I{D}_{MF},C_{ID{I}_2},(r_{ID{I}_2},s_{ID{I}_2}))$ to MF.

Step 4.

MF receives the message from IDI, then decrypts the cipher message by its private key:

$$M_6=D_{Pr{k}_{MF}}(C_{ID{I}_2})$$

(56)

Then, MF checks for the validation of the timestamp:

$$(T_{12}-T_{11})\stackrel{?}{\le }\tau$$

(57)

Next, MF calculates the parameter:

$$h_{ID{I}_2}{}^{\prime }=H(M_6)$$

(58)

MF executes the function “Verify” in Algorithm 2 to validate the signature:

$$Verify(h_{ID{I}_2}{}^{\prime },r_{ID{I}_2},s_{ID{I}_2})$$

(59)

If the signature is valid, then the MF is able to use the list of TID to manufacture. When the MF produces a tobacco product, a TID should be stuck with the pack, then the MR is used to scan the tag, and a chaincode “Manufacture” is triggered to update the information of the tobacco product, the algorithm of which is shown in Algorithm 3.

Algorithm 3. Chaincode of issuing ID and manufacture of the proposed scheme.

var TP []Tobacco_Product count:= 0 func IDIssue (Info string, string ID_MF, int num, string CA_Signature, IDI_Signature string, MF_Signature string) (list_TID []string){   for i:= 0; i < num; i++ {   count = count + 1     TP = append (TP, new Tobacco_Product{       TID: GenerateTID(),       Product_Information: Info,       Generate_Datetime: time.Now(),       Manufacturer_ID: MID,       CA_Signature: CA_Signature,       IDI_Signature: IDI_Signature,       MF_Signature: MF_Signature     })     list_TID = append(list_TID, TP[count].TID)   }   return list_TID } func Manufacture ( ID_MF string, TID string, GPSLoc string){   index:= SearchTID(TP, TID)   TP[index].Manufacturing_Datetime = time.Now()   TP[index].Factory_ID = ID_MF   TP[index].GPSLocation = GPSLoc }

3.7. Logistics Phase

We assumed three roles to operate in this phase: shipper (SHP), logistics (LG), and the recipient (RCP). As per the system architecture shown in Figure 2, we can assume that the shipper is a manufacturer, distributor, or retailer; the recipient is a distributor or retailer; and the logistics is a company that transfers tobacco products between the shipper and recipient. The flowchart of the logistics phase is shown in Figure 9 and Figure 10. The chaincode of logistics is shown in Algorithm 4.

Step 1.

When the SHP needs to ship a batch of tobacco products to the RCP, SHP must ship via LG. Initially, SHP selects a random number $k_7$ and generates a message with a list of TID:

$$M_7=(I{D}_{SHP}|\left|I{D}_{LG}\right||List<TID>||T_{13})$$

(60)

SHP calculates the hash value and executes “Sign” in Algorithm 2 to generate signatures $(r_{SH{P}_1},s_{SH{P}_1})$:

$$h_{SH{P}_1}=H(M_7)$$

(61)

$$(r_{SH{P}_1},s_{SH{P}_1})=Sign(h_{SH{P}_1},k_7,d_{SHP})$$

(62)

A message is encrypted by LG’s public key:

$$C_{SH{P}_1}=E_{Pu{k}_{LG}}(M_7)$$

(63)

Then, SHP executes the chaincode function “Shipping”, as shown in Algorithm 4. Next, SHP sends the message $(I{D}_{SHP},I{D}_{LG},C_{SH{P}_1},(r_{SH{P}_1},s_{SH{P}_1}))$ to LG.

Step 2.

LG receives the message at $T_{14}$, then decrypts the cipher message by its private key:

$$M_7=D_{Pr{k}_{LG}}(C_{SH{P}_1})$$

(64)

Then, LG checks for the validation of the timestamp:

$$(T_{14}-T_{13})\stackrel{?}{\le }\tau$$

(65)

Next, LG calculates the hash value to validate the signature via “Verify” in Algorithm 2:

$$h_{SH{P}_1}{}^{\prime }=H(M_7)$$

(66)

$$Verify(h_{SH{P}_1}{}^{\prime },r_{SH{P}_1},s_{SH{P}_1})$$

(67)

If the signature is valid, LG using MR triggers a chaincode function “Receiving” to scan and check that $List<TID>$ is equal to the actual tobacco products in the real world, the function of which is shown in Algorithm 4. Then, LG sends a response message to the SHP. LG selects a random number $k_8$ and generates a message:

$$M_8=(I{D}_{LG}|\left|I{D}_{SHP}\right||T_{15})$$

(68)

Next, LG calculates the hash value to generate the signatures via executing a “Sign” function in Algorithm 2:

$$h_{L{G}_1}=H(M_8)$$

(69)

$$(r_{L{G}_1},s_{L{G}_1})=Sign(h_{L{G}_1},k_8,d_{LG})$$

(70)

A response message is encrypted with SHP’s public key:

$$C_{L{G}_1}=E_{Pu{k}_{SHP}}(M_8)$$

(71)

Then, LG sends the message $(I{D}_{LG},I{D}_{SHP},C_{L{G}_1},(r_{L{G}_1},s_{L{G}_1}))$ to SHP.

Step 3.

SHP receives the message from LG, then uses its private key to decrypt the cipher message:

$$M_8=D_{Pr{k}_{SHP}}(C_{L{G}_1})$$

(72)

Then, SHP checks for the validation of the timestamp:

$$(T_{16}-T_{15})\stackrel{?}{\le }\tau$$

(73)

If the timestamp is valid, SHP calculates the hash value to validate the signatures via executing a “Verify” function in Algorithm 2:

$$h_{L{G}_1}{}^{\prime }=H(M_8)$$

(74)

$$Verify(h_{L{G}_1}{}^{\prime },r_{L{G}_1},s_{L{G}_1})$$

(75)

If the signature is valid, then SHP starts shipping these tobacco products to the RCP.

Algorithm 4. Chaincode of logistics of the proposed scheme.

func Shipping ( ID_SHP string, ID_RCP string, TIDs []string, GPSLoc string, Signature string) {   for i:= 0; i < TIDs.Length; i++ {     index:= SearchTID(TIDs[i]);     TP[index].TransportRecord.Shipper_ID = ID_SHP     TP[index].TransportRecord.Shipper_GPSLocation = GPSLoc     TP[index].TransportRecord.Shipper_Datetime = time.Now()     TP[index].TransportRecord.Recipient_ID = ID_LG     TP[index].TransportRecord.SHP_Signature = Signature   } } func Receiving ( ID_SHP string, ID_RCP string, TIDs []string, GPSLoc string, Signature string) {   for i:= 0; i < TIDs.Length; i++ {     index:= SearchTID(TIDs[i])     TP[index].TransportRecord.Recipient_GPSLocation = GPSLoc     TP[index].TransportRecord.Recipient_Datetime = time.Now()     TP[index].TransportRecord.RCP_Signature = Signature   } }

Step 1.

When LG arrives at the RCP location, LG starts communication and sends the batch of tobacco products to RCP. First, LG selects a random number $k_9$ and generates a message with a list of TID:

$$M_9=(I{D}_{\mathrm{LG}}|\left|I{D}_{RCP}\right||List<TID>||T_{17})$$

(76)

LG calculates the hash value and executes the function “Sign” in Algorithm 2 to generate the signature:

$$h_{L{G}_2}=H(M_9)$$

(77)

$$(r_{L{G}_2},s_{L{G}_2})=Sign(h_{L{G}_2},k_9,d_{LG})$$

(78)

A message is encrypted by the RCP’s public key:

$$C_{L{G}_2}=E_{Pu{k}_{RCP}}(M_9)$$

(79)

Then, LG executes chaincode “Shipping”, as shown in Algorithm 4. Next, LG sends the message $(I{D}_{LG},I{D}_{RCP},C_{L{G}_2},(r_{L{G}_2},s_{L{G}_2}))$ to RCP.

Step 2.

RCP receives the message at $T_{18}$, then decrypts the cipher message by its private key:

$$M_9=D_{Pr{k}_{RCP}}(C_{L{G}_2})$$

(80)

Then, RCP checks for the validation of the timestamp:

$$(T_{18}-T_{17})\stackrel{?}{\le }\tau$$

(81)

Next, RCP calculates the hash value and executes the function “Verify” in Algorithm 2 to validate the signature:

$$h_{L{G}_2}{}^{\prime }=H(M_9)$$

(82)

$$Verify(h_{L{G}_2}{}^{\prime },r_{L{G}_2},s_{L{G}_2})$$

(83)

If the signature is valid, RCP uses MR to trigger a chaincode “Receiving” to scan and check that $List<TID>$ is equal to the actual tobacco products, as shown in Algorithm 4. If the batch of tobacco products has no problem, then RCP sends a response message to LG. RCP selects a random number $k_{10}$ and generates a message:

$$M_{10}=(I{D}_{RCP}|\left|I{D}_{LG}\right||T_{19})$$

(84)

Next, RCP calculates the hash value and executes the function “Sign” to generate the signatures:

$$h_{RC{P}_1}=H(M_{10})$$

(85)

$$(r_{RC{P}_1},s_{RC{P}_1})=Sign(h_{RC{P}_1},k_{10},d_{RCP})$$

(86)

A response message is encrypted with the LG’s public key:

$$C_{RC{P}_1}=E_{Pu{k}_{LG}}(M_{10})$$

(87)

Then, the RCP sends the message $(I{D}_{RCP},I{D}_{LG},C_{RC{P}_1},(r_{RC{P}_1},s_{RC{P}_1}))$ to LG.

Step 3.

LG receives the message, then uses its private key to decrypt the cipher message:

$$M_{10}=D_{Pr{k}_{LG}}(C_{RC{P}_1})$$

(88)

Then, LG checks for the validation of the timestamp:

$$(T_{20}-T_{19})\stackrel{?}{\le }\tau$$

(89)

If the timestamp is valid, LG calculates the hash value and executes the function “Verify” to validate the received signatures:

$$h_{RC{P}_1}{}^{\prime }=H(M_{10})$$

(90)

$$Verify(h_{RC{P}_1}{}^{\prime },r_{RC{P}_1},s_{RC{P}_1})$$

(91)

If the signature is valid, then a round of shipping from the SHP to RCP is done.

3.8. Consumption Phase

When a consumer goes to purchase tobacco products from a retailer, the processing flow is shown in Figure 11.

Step 1.

CS goes into the RT location and selects one or more tobacco products, then proceeds to the checkout process.

Step 2.

RT starts the checkout process. First, the RT scans the TID of chosen tobacco products from CS. Then, RT selects a random number $k_{11}$ and generates a message with a list of TID:

$$M_{11}=(I{D}_{RT}|\left|I{D}_{CA}\right||List<(TID,Price,DateTime)>||T_{21})$$

(92)

RT calculates the hash value and executes the function “Sign” in Algorithm 2 to generate the signatures:

$$h_{R{T}_1}=H(M_{11})$$

(93)

$$(r_{R{T}_1},s_{R{T}_1})=Sign(h_{R{T}_1},k_{11},d_{RT})$$

(94)

A message is encrypted by CA’s public key:

$$C_{R{T}_1}=E_{Pu{k}_{CA}}(M_{11})$$

(95)

Then, RT sends the message $(I{D}_{LG},I{D}_{RCP},C_{L{G}_2},(r_{L{G}_2},s_{L{G}_2}))$ to CA.

Step 3.

CA receives the message at $T_{22}$, then decrypts the cipher message by its private key:

$$M_{11}=D_{Pr{k}_{CA}}(C_{R{T}_1})$$

(96)

Then, CA checks for the validation of the timestamp:

$$(T_{22}-T_{21})\stackrel{?}{\le }\tau$$

(97)

Next, the CA calculates the hash value and executes the function “Verify” in Algorithm 2 to validate the signatures:

$$h_{R{T}_1}{}^{\prime }=H(M_{11})$$

(98)

$$Verify(h_{R{T}_1}{}^{\prime },r_{R{T}_1},s_{R{T}_1})$$

(99)

If the signature is valid, CA executes a chaincode “Purchase”, as shown in Algorithm 5, where a purchasing record is received and updated to the BCC. Then, CA selects a random number $k_{12}$ and generates a message:

$$M_{12}=(I{D}_{CA}|\left|I{D}_{RT}\right||List<PID>||T_{23})$$

(100)

Next, CA calculates the parameters and executes the function “Sign” to generate the signatures:

$$h_{C{A}_2}=H(M_{12})$$

(101)

$$(r_{C{A}_2},s_{C{A}_2})=Sign(h_{C{A}_2},k_{12},d_{CA})$$

(102)

A response message is encrypted with RT’s public key:

$$C_{C{A}_2}=E_{Pu{k}_{RT}}(M_{12})$$

(103)

Then, CA sends the message $(I{D}_{\mathrm{CA}},I{D}_{RT},C_{C{A}_2},(r_{C{A}_2},s_{C{A}_2}))$ to LG.

Step 4.

RT receives the message, then uses its private key to decrypt the cipher message:

$$M_{12}=D_{Pr{k}_{\mathrm{RT}}}(C_{C{A}_2})$$

(104)

Then, RT checks for the validation of the timestamp:

$$(T_{24}-T_{23})\stackrel{?}{\le }\tau$$

(105)

If the timestamp is valid, RT calculates the hash value and executes the function “Verify” to validate the signatures:

$$h_{C{A}_2}{}^{\prime }=H(M_{12})$$

(106)

$$Verify(h_{C{A}_2}{}^{\prime },r_{C{A}_2},s_{C{A}_2})$$

(107)

If the signature is valid, then RT prints an invoice with the purchase information $List<(TID,Price,DateTime,PID,I{D}_{RT})>$

Step 5.

RT gives the printed invoice and tobacco products to the CS, then the transaction is completed.

Algorithm 5. Chaincode of consumption of the proposed scheme.

func Purchase ( ID_RT string, TIDs []string, Price []float, GPSLoc string) (Purchase_ID []string, Payment_DT []time.Time){   for i:= 0; i < TIDs.Length; i++ {     index:= SearchTID(TIDs[i])     TP[index].Retailer_ID = ID_RT     TP[index].Payment_Datetime = time.Now()     TP[index].Payment_GPSLocation = GPSLoc     TP[index].Purchase_ID = GeneratePurchaseID()     TP[index].Payment_Price = Price[i]     Purchase_ID = append(Purchase_ID, TP[index].Purchase_ID)     Payment_Datetime = append(Payment_Datetime, TP[index].Payment_DT)   }   return Purchase_IDs }

3.9. Verification Phase (Consumer-End)

Sometimes consumers may doubt the legality of the tobacco products that they purchased from the retailer, so they can use the mobile application to check the legality of the tobacco products. Figure 12 shows the consumer checking flowchart where the detailed steps are as follows:

Step 1.

Consumers are required to provide the consumption information by mobile application such as the tobacco ID (TID), retailer ID, purchase ID, and the timestamp purchase that is printed in the invoice.

Step 2.

The application executes a chaincode “GetTobaccoInfo”, as shown in Algorithm 6.

Step 3.

If the TID is valid, the BCC returns the tobacco detailed information. Otherwise, the BCC returns that the TID is not valid, so we can determine that this is an illegal tobacco product or trade.

Step 4.

The mobile application shows the results of the chaincode, where consumers can obtain the legality and logistics status of the tobacco products.

Algorithm 6. Chaincode verification of the proposed scheme.

func GetTobaccoInfo (TID string, RetailerID string, PurchaseID string, PurchaseDateTime time.Time) (result string){   index:= SearchTID(TID)   if index >= 0   && TP[index]. Retailer_ID == RetailerID   && TP[index]. Purchase_ID == PurchaseID   && TP[index]. Payment_Datetime == PurchaseDateTime {     result = TP[index]’s information   }else{     result = “Tobacco invalid” }   return result } func Verification (string ID_AP, string TID, RoleType type) (Is_legal bool){   index:= SearchTID(TID)   if type == RoleType.Manufacturer {     If ID_AP!= TP[index].Manufacturer_ID {       return false     }   }else{     last_index:= len(TransportRecord)-1     If ID_AP!= TP[index].TransportRecord[last_index].Recipient_ID {       return false     }   }   return true }

3.10. Verification Phase (Auditor-End)

In particular, government agencies will regularly check whether there are counterfeit tobacco products on the market that have not been approved or authenticated by the CA. Figure 13 shows the audit mechanism flow to verify the tobacco products. The detailed steps are as follows:

Step 1.

AU uses the MR to scan the TID of tobacco products randomly from the company such as a retailer, logistics, distributor, or manufacturer.

Step 2.

The application will send the selected tobacco ID, company ID, and its role type to CA.

Step 3.

CA triggers a chaincode “Verification” in the BCC to verify the legality of tobacco products, where the chaincode is shown in Algorithm 6.

Step 4.

BCC returns the legality result to the CA.

Step 5.

CA responds to the result to the AU, if it is not legal, then the AU enforces the law on the illegal tobacco product and company.

3.11. Arbitration Phase

When any access party doubts the authenticity of the origin of the tobacco products, they can arbitrate its legality through a third-party arbitrator. The arbitration flow is shown in Figure 14. The detailed steps are described as follows:

Step 1.

AP provides the specific tobacco products’ TID to the AU.

Step 2.

AU sends a request message with their signature and TID to the BCC.

Step 3.

BCC checks the signature; if the signature is valid, then the AU responds to a list of signatures to the AU.

Step 4.

The AU starts to check the validity of signatures.

• If the RT signature is illegal, then the record is forged by the RT.
• Then, the AU extracts the list of the “Transport Record” of tobacco information and obtains the RCP and SHP signature.
• If the RCP signature is illegal, then the record is forged by the RCP.
• If the SHP signature is illegal, then the record is forged by the SHP.
• Confirm that the record is the last data of the list of “Transport Record”. If it is not, go to step 4b, otherwise go to the next step.
• If the MF signature is illegal, then the record is forged by the MF.
• If there are no illegal signatures, then the logistics record is legal and verified by the AU.

4. Security Analysis

4.1. Mutual Authentication

We used BAN logic to verify the mutual authentication in the authentication phase. The notation of BAN logic is described below.

${\left\{X\right\}}_K$	The message X is encrypted by a key K
$P\stackrel{SK}{\leftrightarrow }Q$	P and Q use a shared key SK to communicate
$P|\equiv X$	P believes X (belief rule)
$P⊲X$	P sees X (seeing rule)
$P|\sim X$	P once said X (message meaning rule)
$P|\Rightarrow X$	P has jurisdiction over X (jurisdiction rule)
$\#(X)$	The message X is new (freshness rule)

The goals of the authentication analysis are:

• G1:$A|\equiv A\stackrel{x_{A_1}}{\leftrightarrow }B$
• G2: $A|\equiv B|\equiv A\stackrel{x_{A_1}}{\leftrightarrow }B$
• G3: $B|\equiv A\stackrel{x_{B_1}}{\leftrightarrow }B$
• G4: $B|\equiv A|\equiv A\stackrel{x_{B_1}}{\leftrightarrow }B$
• G5:$A|\equiv I{D}_B$
• G6:$A|\equiv B|\equiv I{D}_B$
• G7: $B|\equiv I{D}_A$
• G8:$B|\equiv A|\equiv I{D}_A$

According to the authentication algorithm, BAN logic was used to produce an idealized form as follows:

• M1: UserA→UserB$({\{I{D}_A,I{D}_B,T_1\}}_{Pu{k}_B},r_{A_1},s_{A_1})$
• M2: UserB→UserA$({\{I{D}_B,I{D}_A,T_3\}}_{Pu{k}_A},r_{B_1},s_{B_1})$

To analyze the proposed scheme, the following assumptions were made:

• A1:$A|\equiv \#(T_1)$
• A2:$B|\equiv \#(T_1)$
• A3:$A|\equiv \#(T_3)$
• A4:$B|\equiv \#(T_3)$
• A5:$A|\equiv B|\Rightarrow B\stackrel{x_{B_1}}{\leftrightarrow }A$
• A6:$B|\equiv A|\Rightarrow A\stackrel{x_{A_1}}{\leftrightarrow }B$
• A7:$A|\equiv B|\Rightarrow I{D}_B$
• A8:$B|\equiv A|\Rightarrow I{D}_A$

• User B authenticates user A

By M1 and the seeing rule, derive:
$B⊲({\{I{D}_A,I{D}_B,T_1\}}_{Pu{k}_B},r_{A_1},s_{A_1})$	(Statement 1)
By A2 and the freshness rule, derive:
$B|\equiv \#({\{I{D}_A,I{D}_B,T_1\}}_{Pu{k}_B},r_{A_1},s_{A_1})$	(Statement 2)
By (Statement 1) and the message meaning rule derive:
$B|\equiv A|~(I{D}_A,I{D}_B,T_1,r_{A_1},s_{A_1})$	(Statement 3)
By (Statement 2), (Statement 3) and the nonce verification rule, derive:
$B|\equiv A|\equiv (I{D}_A,I{D}_B,T_1,r_{A_1},s_{A_1})$	(Statement 4)
By (Statement 4) and the belief rule, derive (G4):
$B|\equiv A|\equiv A\stackrel{x_{A_1}}{\leftrightarrow }B$	(Statement 5)
By (Statement 5), A6, and the jurisdiction rule, derive (G3):
$B|\equiv A\stackrel{x_{A_1}}{\leftrightarrow }B$	(Statement 6)
By (Statement 4) and the belief rule, derive (G8):
$B|\equiv A|\Rightarrow I{D}_A$	(Statement 7)
By (Statement 7), A8, and the belief rule, derive (G7):
$B|\equiv I{D}_A$	(Statement 8)

b.

User A authenticates user B

By M1 and the seeing rule, derive:
$A⊲({\{I{D}_B,I{D}_A,T_3\}}_{Pu{k}_A},r_{B_1},s_{B_1})$	(Statement 9)
By A3 and the freshness rule, derive:
$A|\equiv \#({\{I{D}_B,I{D}_A,T_3\}}_{Pu{k}_A},r_{B_1},s_{B_1})$	(Statement 10)
By (Statement 9) and the message meaning rule derive:
$A|\equiv B|~(I{D}_B,I{D}_A,T_3,r_{B_1},s_{B_1})$	(Statement 11)
By (Statement 10), (Statement 11) and the nonce verification rule, derive:
$A|\equiv B|\equiv (I{D}_B,I{D}_A,T_3,r_{B_1},s_{B_1})$	(Statement 12)
By (Statement 12) and the belief rule, derive (G2):
$A|\equiv B|\equiv B\stackrel{x_{B_1}}{\leftrightarrow }A$	(Statement 13)
By (Statement 13), A5 and the jurisdiction rule, derive (G1):
$A|\equiv B\stackrel{x_{B_1}}{\leftrightarrow }A$	(Statement 14)
By (Statement 12) and the belief rule, derive (G6):
$A|\equiv B|\Rightarrow I{D}_B$	(Statement 15)
By (Statement 15), A7, and the belief rule, derive (G5):
$A|\equiv I{D}_B$	(Statement 16)

By (Statement 6), (Statement 8), (Statement 14), and (Statement 16), these statements authenticate the identities of user A and user B mutually in the proposed scheme.

4.2. Unforgeable Record

We implemented a blockchain-based system in the proposed scheme shown in Figure 15. Each CA had a ledger, and the blocks in the ledger were synchronized with the PBFT consensus algorithm. When an accessing party executes a chaincode function, the modification of the chaincode will be chained to the ledger. The latest ledger will be validated from every CA department that participates in the blockchain center. It is hard to modify and forge the data in the ledger.

Furthermore, we designed the structure of data as shown in Figure 4 and Figure 5. The structure of the chaincode stores the complete information of tobacco including the manufacturer and logistics record with GPS location. Therefore, all information and the logistics records of tobacco can be tracked. Consequently, the logistics records cannot be forged and can be tracked correctly in our blockchain-based system.

4.3. Non-Repudiation

In the proposed scheme, we used ECDSA to achieve the repudiation issues. Every message transmitted by the sender must sign with their private key, then the receiver can be verified using its public key. We have sorted a list of verification equations that need to be verified by the receiver in every phase, as shown in

Table 2. Non-repudiation’s verification of the proposed scheme.

Phase	Party		Verification Function
	Sender	Receiver
Authentication Phase	A	B	$Verify(h_{A_1}{}^{\prime },r_{A_1},s_{A_1})$
	B	A	$Verify(h_B{}^{\prime },r_{B_1},s_{B_1})$
Issuing and Manufacture Phase	MF	IDI	$Verify(h_{M{F}_1}{}^{\prime },r_{M{F}_1},s_{M{F}_1})$
	IDI	CA	$Verify(h_{ID{I}_1}{}^{\prime },r_{ID{I}_1},s_{ID{I}_1})$
	CA	IDI	$Verify(h_{C{A}_1}{}^{\prime },r_{C{A}_1},s_{C{A}_1})$
	IDI	MF	$Verify(h_{ID{I}_2}{}^{\prime },r_{ID{I}_2},s_{ID{I}_2})$
Logistics Phase (Shipping)	SHP	LG	$Verify(h_{SH{P}_1}{}^{\prime },r_{SH{P}_1},s_{SH{P}_1})$
	LG	SHP	$Verify(h_{L{G}_1}{}^{\prime },r_{L{G}_1},s_{L{G}_1})$
Logistics Phase (Receiving)	LG	RCP	$Verify(h_{L{G}_2}{}^{\prime },r_{L{G}_2},s_{L{G}_2})$
	RCP	LG	$Verify(h_{RC{P}_1}{}^{\prime },r_{RC{P}_1},s_{RC{P}_1})$
Consumption Phase	RT	CA	$Verify(h_{R{T}_1}{}^{\prime },r_{R{T}_1},s_{R{T}_1})$
	CA	RT	$Verify(h_{C{A}_2}{}^{\prime },r_{C{A}_2},s_{C{A}_2})$

.

4.4. Integrity

To ensure the integrity of data when communicating between the sender and receiver, we used the hash function to hash data in the signature value. The signatures with the hash value of all the phases are listed in

Table 3. Non-repudiation’s verification of the proposed scheme.

Phase	Party		Signature
	Sender	Receiver
Authentication Phase	A	B	$(r_{A_1},s_{A_1})=Sign(h_{A_1},k_1,d_A)$
	B	A	$(r_{B_1},s_{B_1})=Sign(h_{B_1},k_2,d_B)$
Issuing and Manufacture Phase	MF	IDI	$(r_{M{F}_1},s_{M{F}_1})=Sign(h_{M{F}_1},k_3,d_{MF})$
	IDI	CA	$(r_{ID{I}_1},s_{ID{I}_1})=Sign(h_{ID{I}_1},k_4,d_{IDI})$
	CA	IDI	$(r_{C{A}_1},s_{C{A}_1})=Sign(h_{C{A}_1},k_5,d_{CA})$
	IDI	MF	$(r_{ID{I}_2},s_{ID{I}_2})=Sign(h_{ID{I}_2},k_6,d_{IDI})$
Logistics Phase (Shipping)	SHP	LG	$(r_{SH{P}_1},s_{SH{P}_1})=Sign(h_{SH{P}_1},k_7,d_{SHP})$
	LG	SHP	$(r_{L{G}_1},s_{L{G}_1})=Sign(h_{L{G}_1},k_8,d_{LG})$
Logistics Phase (Receiving)	LG	RCP	$(r_{L{G}_2},s_{L{G}_2})=Sign(h_{L{G}_2},k_9,d_{LG})$
	RCP	LG	$(r_{RC{P}_1},s_{RC{P}_1})=Sign(h_{RC{P}_1},k_{10},d_{RCP})$
Consumption Phase	RT	CA	$(r_{R{T}_1},s_{R{T}_1})=Sign(h_{R{T}_1},k_{11},d_{RT})$
	CA	RT	$(r_{C{A}_2},s_{C{A}_2})=Sign(h_{C{A}_2},k_{12},d_{CA})$

, for example, in the issuing and manufacture phase, the MF signs the signature $s_{M{F}_1}$ with a hash value $h_{M{F}_1}$. All the signatures were calculated with the ECDSA and verified by the receiver, as shown in Table 2.

4.5. Resist Known Attacks

4.5.1. Replay Attack

To resist replay attack, every encrypted message is added to a sending timestamp and check to see whether the timespan is valid. The timestamp is validated in every phase to resist replay attack, and the validations are shown in Equations (9), (22), (33), (41), (49), (57), (65), (73), (81), (89), (97), and (105). For example, in the issuing ID and manufacture phase, MF adds a timestamp $T_5$ in the message $M_3$, then encrypts the $M_3$ with a cipher message $C_{M{F}_1}$. The IDI decrypts the message after receiving the cipher message, then checks for the validation of the timestamp. The related equations are shown as follows:

$$M_3=(I{D}_{MF}|\left|I{D}_{IDI}\right|\left|Num\right|\left|Info\right||T_5)$$

(108)

$$C_{M{F}_1}=E_{Pu{k}_{IDI}}(M_3)$$

(109)

$$M_3=D_{Pr{k}_{IDI}}(C_{M{F}_1})$$

(110)

$$(T_6-T_5)\stackrel{?}{\le }\tau$$

(111)

Scenario: The attacker listens to a message that is sent from the sender to the receiver. After that, the attacker re-sends the same message to the receiver to achieve a replay attack.

Analysis: The receiver decrypts and obtains the timestamp in the message, then subtracts the timestamp with the current time; if the timespan is larger than the threshold, it means that the message is a replay attack, so the attack is foiled.

4.5.2. Main-in-the-Middle Attack (MITM)

The MITM is an attack where an attacker will be in the middle of the sender and receiver, listening or modifying the messages between each other. In the method, we added an encryption and decryption mechanism to the communication protocol. These encrypted and decrypted scenarios are shown in Equations (7), (8), (20), (21), (31), (32), (39), (40), (47), (48), (55), (56), (63), (64), (71), (72), (79), (80), (87), (88), (95), (96), (103), and (104). For example, in the logistics shipping phase, SHP encrypts the message $M_7$ to a cipher message $C_{SH{P}_1}$ with LG’s public key $Pu{k}_{LG}$. The LG decrypts the message after receiving the cipher message with their private key $Pr{k}_{LG}$. The related equations are shown as follows:

$$C_{SH{P}_1}=E_{Pu{k}_{LG}}(M_7)$$

(112)

$$M_7=D_{Pr{k}_{LG}}(C_{SH{P}_1})$$

(113)

Scenario: The attacker eavesdrops or tampers with the communication messages between the sender and receiver and analyzes the content.

Analysis: The message is encrypted with the receiver’s public key, and the receiver must have a relevant private key to decrypt the message. However, the attacker did not have the private key of the receiver, so they are unable to decrypt the message to learn the content of the transmission.

5. Discussion

5.1. Computation Cost

First, we analyzed the computational costs of each phase. We used asymmetrical encryption/decryption, hash functions, addition, subtraction, multiplication, and division operation as the basis for calculating the costs. The costs of each phase are shown in

Table 4. Computation costs of the proposed scheme.

Phase	1st Role	2nd Role	3rd Role
Authentication Phase	User A: 2Tasy + 2Th + 2Tadd + 1Tsub + 4Tmul + 3Tdiv	User B: 2Tasy + 2Th + 2Tadd + 1Tsub + 3Tmul + 3Tdiv	N/A
Issuing and Manufacture Phase	Manufacturer: 2Tasy + 2Th + 2Tadd + 1Tsub + 4Tmul + 3Tdiv	IDI Issuer: 4Tasy + 4Th + 4Tadd + 2Tsub + 6Tmul + 6Tdiv	Competent Authorities: 2Tasy + 2Th + 2Tadd + 1Tsub + 3Tmul + 3Tdiv
Logistics Phase (Shipping)	Shipper: 2Tasy + 2Th + 2Tadd + 1Tsub + 4Tmul + 3Tdiv	Logistics: 2Tasy + 2Th + 2Tadd + 1Tsub + 3Tmul + 3Tdiv	N/A
Logistics Phase (Receiving)	Logistics: 2Tasy + 2Th + 2Tadd + 1Tsub + 4Tmul + 3Tdiv	Recipient: 2Tasy + 2Th + 2Tadd + 1Tsub + 3Tmul + 3Tdiv	N/A
Consumption Phase	Consumer: N/A	Retailer: 2Tasy + 2Th + 2Tadd + 1Tsub + 4Tmul + 3Tdiv	Competent Authorities: 2Tasy + 2Th + 2Tadd + 1Tsub + 3Tmul + 3Tdiv

Notes: T_asy: asymmetrical encryption/decryption; T_h: a hash operation; T_add: an additional operation; T_sub: a subtraction operation. T_mul: a multiplication operation; T_div: a division operation; T_exp: an exponential operation

.

5.2. Communication Performance

In

Table 5. Communication costs of the proposed scheme.

	Message Length	4G (100 Mbps)	5G (20 Gbps)
Authentication Phase	3648 bits	36 µs	0.18 µs
Issuing and Manufacture Phase	7296 bits	71 µs	0.36 µs
Logistics Phase (Shipping)	3648 bits	36 µs	0.18 µs
Logistics Phase (Receiving)	3648 bits	36 µs	0.18 µs
Consumption Phase	3648 bits	36 µs	0.18 µs

Notes: L_ID: an ID (144 bits); L_m: a cipher message (512 bits); L_sig: signature parameters (1024 bits).

, the communication performance was analyzed within every phase. The maximum transmission speed is 100 Mbps in a 4G environment, and the maximum transmission speed is 20 Gbps in a 5G environment [33].

In our analysis, it was assumed that an ID message required 144 bits, a cipher message required at least 512 bits, and a signature message required 1024 bits. We assumed 512 bits of a cipher message by the minimum length of the message (2 IDs, 1 Timestamp, and 2 others) that is sent at the issuing ID and manufacture phase, which is 2 × 144 bits + 1 × 64 bits + 2 × 80 bits = 512 bits.

With the above definition, we used the transmitted message as the calculated communication cost. For example, in the logistics shipping phase, SHP sends two IDs, one cipher message, one signature to LG, then LG sends two IDs, one cipher message, and one signature to SHP for a response message. In total, it requires 4 × 144 bits + 2 × 512 bits + 2 × 1024 bits. In a 4G environment, it only takes 36 µs to transfer all the messages. In a 5G environment, the transmission time only needs 0.18 us to complete the authentication phase.

5.3. Comparison

We used the EU’s final report [5] as the target of comparison, and

Table 6. Comparison of the tobacco products logistics system.

	EU’s Scheme [5]	Our Scheme
Database	General database	Blockchain-based Decentralized ledger
Flexibility	Low	High
Data integrity	Low	High
Message non-repudiation	N/A	High
Traceable record	Yes	Yes
Verifiable record	No	Yes
Tampering data	Easy	Hard
Tracking record establishment	Pre-set routing	Update routing dynamically
Security analysis	Yes	Yes

shows the comparison between our scheme and the EU’s tobacco products logistics tracking system.

The EU has proposed a scheme with a general database with the defined field. The flexibility of the general database is very low, because the predefined field is fixed in advance, and the query connection between multiple tables is hard to modify when the system needs to upgrade. Our scheme used a blockchain-based decentralized ledger, so the blockchain has the characteristics of high flexibility and data integrity. By the way, we used the signature mechanism to ensure the message non-repudiation issue.

Additionally, both systems can trace the data record. However, our scheme provides verifiability between the records as the blockchain system has a strong connection between every record with blocks, and the newly added block contains the hash value of the previous block to ensure that the data are not easily tampered with.

According to the EU’s scheme, they need to set up the routing path before generating the tobacco ID. Compared to the EU scheme, our method can update the routing path dynamically via the logistics phase, where every record is appended to the chaincode’s tobacco information. Therefore, the manufacturer, distributor, or retailer can transport the tobacco products more flexibly.

To sum up, our blockchain-based method can improve the security and integrity of data and provide greater flexibility in updating logistics information.

6. Conclusions

We proposed a traceable and verifiable blockchain-based logistics system for tobacco products. We also proposed the chaincode algorithm and complete system architecture was raised in the scheme. Every tobacco product’s logistics record can be scanned and recorded to the blockchain center via a mobile reader, so the authorized department or consumer can easily track the logistics of tobacco products. If there is any doubt about the tobacco products, any party is able to send a request to a third-party arbitrator to check which part in the supply chain is illegal.

For the security of our system, we applied the ECDSA in the communication protocol to achieve a more secure system. The security of the system was analyzed such as mutual authentication, unforgeable data, non-repudiation, and integrity. In particular, for mutual authentication, we used BAN logic to prove that the communication was secure. Furthermore, the proposed protocol also prevents replay attacks and man-in-the-middle attacks, and it is hard to attack our system with validation of the timestamp and encryption/decryption of communication messages.

We also compared our proposed scheme with the EU’s scheme. The EU provides a general framework for the system, whereas our scheme focused more on how to realize the system with blockchain-based, GPS and RFID technologies. In the comparison, we found that our system had higher flexibility and was more secure.

To sum up, our research achieved the following contributions:

(1)

Clarifies the Hyperledger Fabric architecture and applies the blockchain technology to the field of transporting tobacco products.

(2)

The proposed blockchain-based system synchronizes the logistics record in the ledger via a secure private channel. Tobacco products are hard to forge or smuggle by a malicious party.

(3)

A verification phase was designed to provide consumers and auditors with the ability to check the legality of tobacco products. When illegal tobacco products are found, the access party can raise any doubts and the arbitrator can find out which party acted illegally in the logistics process.

(4)

Compared with the EU’s scheme, the access party can scan the TID and update to the blockchain during the logistics phase, so the mechanism provides a flexible way to update the logistics records to the blockchain.

(5)

Provide security verification and simulation against known threats or attacks.

(6)

Use BAN Logic to prove the security of mutual authentication.

This research proposes a system architecture that uses blockchain, GPS and RFID technologies to trace logistics records. This structure is also applicable to the application example of information tracking of all enterprise organizations and alliance chains.