Toward Blockchain-Enabled Supply Chain Anti-Counterfeiting and Traceability

Abstract

Existing product anti-counterfeiting and traceability solutions across today’s internationally spanning supply chain networks are indeed developed and implemented with centralized system architecture relying on centralized authorities or intermediaries. Vulnerabilities of centralized product anti-counterfeiting solutions could possibly lead to system failure or susceptibility of malicious modifications performed on product records or various potential attacks to the system components by dishonest participant nodes traversing along the supply chain. Blockchain technology has progressed from simply being a use case of immutable ledger for cryptocurrency transactions, to a programmable interactive environment of developing decentralized and reliable applications addressing different use cases globally. Key areas of decentralization, fundamental system requirements, and feasible mechanisms of developing decentralized product anti-counterfeiting and traceability ecosystems utilizing blockchain technology are identified in this research, via a series of security analyses performed against solutions currently implemented in supply chain industry with centralized architecture. The decentralized solution will be a secure and immutable scientific data provenance tracking and management platform where provenance records, providing compelling properties on data integrity of luxurious goods, are recorded and verified automatically across the supply chain.

1. Introduction

The problem of counterfeit product trading, including luxurious goods or pharmaceutical products, has been one of the major challenges the supply chain industry has been facing in an innovation-driven global economy. The situation has been alarming with an exponential growth of counterfeit and pirated goods worldwide, for which it has also plagued companies with multinational supply chain networks.

The analytical study [1] published by the Organization for Economic Cooperation and Development (OECD) and European Union Intellectual Property Office (EUIPO) in 2019 regarding the global trading activities of counterfeit and pirated products has suggested the volume of international trade of counterfeit and pirated products increased from $250 billion in 2007, to up to $461 billion in 2013, representing approximately 2.5% of world imports. The imports of counterfeit and pirated products into EU amounted to nearly $116 billion, representing 5% of EU imports approximately. The results have been alarming according to the latest statistics published in 2016, suggested that the volume has already further amounted to as much as $509 billion representing 3.3% of world trade and 6.8% of imports from non-EU countries.

The battle against counterfeit product trading remains a significant challenge; it is simultaneously of significant and growing concern to the globalized economy not to mention all the affected industries, such as the markets included in [2] and innumerable branded product companies. Trading activities in counterfeit goods not only infringe on trademarks and copyrights, and negatively impact on sales and profits of industries, but also generate profits for organized crime at the expense of the affected companies and governments. Counterfeit trading activities also pose broader adverse effects to the economy, public health, safety, and security of the wider community. Counterfeit product trading activities are operated swiftly in the globalized economy, misusing free trade zones according to the authors of [3], taking advantage of many legitimate trade facilitation mechanisms and thriving in economies with weak governance standard and limited innovative options to combat product counterfeits. In response to the growing concern in product counterfeit, innovative, fully functional, integrable, and affordable product anti-counterfeiting solutions with traceability functionalities have been widely and urgently demanded. These solutions are expected to utilize cutting-edge technologies so as to ensure the provenance and traceability of genuine products throughout the supply chain counterfeiting, and these suggested solutions should be widely adopted regardless of industries, size of the companies, and its supply chain systems.

Given the growing concern in counterfeit trading activities, though there have already been a variety of innovative product anti-counterfeiting solutions introduced in supply chain industry, the main research question is as follows:

“Why would existing anti-counterfeiting and traceability systems benefit from decentralization enabled by blockchain technology to better combat the rampant counterfeiting attacks?”

The main question could further be addressed via answering the following sub-questions throughout the research:

• Why can blockchain be utilized to decentralize the supply chain anti-counterfeiting and traceability system?
• What are the security limitations and concerns of existing supply chain anti-counterfeiting and traceability systems?
• What are the advantages introduced by decentralized supply chain anti-counterfeiting and traceability systems?

Given the main research question and the set of sub-questions derived from it, it is common to follow an organized way of exploring them stepwise in this research. An exploratory research method, as depicted in [4], will be adopted in this research in computing. Contrary to existing conceptual blockchain implementations applied in different industries with less explanation on why decentralization is needed for these use cases, this research is taking a rather different approach to have a thorough process involving a series of security analyses on an existing product anti-counterfeiting and traceability system—NFC-Enabled Anti-Counterfeiting System (NAS). The insightful findings from the security analyses will further elaborate why these solutions could benefit from decentralization, on which a decentralized version of these supply chain software solutions could be developed and implemented.

The fundamental ideas and use cases of blockchain technology, categorized into different phases, are explained in the research. The reasons why implementations of Blockchain 2.0 should be adopted to decentralize the existing product anti-counterfeiting and traceability systems are also elaborated, before stepping into the overview on one of the existing product anti-counterfeiting and traceability system—NAS. This research will focus on explaining the reasons why these existing supply chain software solutions, including NAS, would benefit from decentralization enabled by blockchain technology.

Based on the findings and opportunities identified from these analyses, a set of fundamental system requirements of developing a decentralized product anti-counterfeiting and traceability system is also defined. The decentralized solutions, such as the Decentralized NFC-Enabled Anti-Counterfeiting System (dNAS), are aimed at delivering a more secure and higher quality approach to verify authenticity and provenance of luxurious products, such as bottled wine. With the use of peer-to-peer blockchain networks and distributed storage technologies, it will be possible to eliminate an absurd amount of cost for on-chain storage and provide a much higher level of privacy, reliability, and quality of service compared with existing anti-counterfeiting and traceability solutions with centralized architecture. The decentralized version of the existing solutions, such as dNAS, could also define a framework and practice for different nodes along the supply chain to integrate the low-cost, real-time, and immutable blockchain technology into their daily supply chain workflows.

2. Background

Given the growing concern around the trading activities of counterfeit products, anti-counterfeiting solutions have been developed and implemented in the supply chain systems of different industries.

Related Work of Anti-Counterfeiting and Traceability Systems

The starting point, such as in [5], is always digitalizing the multi-node supply chain system under which the supply chain network will at least be operating with a Point-of-Sale (POS) system integrated with the states of a data storage system updated at different nodes along the supply chain. Wireless communication technologies, such as Radio-frequency Identification (RFID) or near-field communication (NFC), which is a subset of RFID, powering the Internet of Things (IoT) are mostly the existing solutions that the centralized architectures are currently based on. The tags with wireless communication capabilities are packaged on the packets of goods or the product itself for identification, anti-counterfeiting, and traceability purposes.

The RFID-based solutions in [6,7] and NFC-based solutions in [8,9] both require dedicated applications or authentication servers to integrate with these tags so as to perform writing, reading, and validating features on the data stored in these tags with the product identifier (PID). Its metadata are also stored in a database system of applications for the purpose of validation at later stage to respond to any potential counterfeiting attack at different supply chain nodes. The work in [10] utilized simple barcode technology, such as QR code, to retrieve the product identifiers by scanning the products and querying corresponding records throughout the dedicated backend database systems to retrieve metadata of specific PIDs so as to prove the authenticity with the PIDs validated and detailed product data retrieved, such as in [11] where this method was implemented for drug anti-counterfeiting.

For instance, with the wider adoption of these wireless communication and barcode technologies, the concept of RFID-enabled track-and-trace anti-counterfeiting was also proposed in [12,13], respectively, to combat counterfeiting activities. RFID-enabled anti-counterfeiting approaches are further analyzed and compared with potential implementation issues in [7,14]. The EPCglobal traceable system to support anti-counterfeiting is further extended in [15,16]. The authors of [17] suggested the use of a Wireless Sensor Network (WSN) and geospatial technologies, such as Geographic Information System (GIS), Global Positioning System (GPS), and Remote Sensing (RS), for mobile assets-tracking operations; these are among the technologies that have been applied in product traceability systems.

Nevertheless, many of the existing implementations for product anti-counterfeiting in the supply chain industry are indeed built with centralized architecture relying on a trusted server, database, and applications. These implementations are solely controlled and managed by the manufacturers or suppliers of the products, for coordinating and managing product authentication with participation contributed from different nodes along the supply chain of different industries.

3. Decentralizing with the Blockchain Technology

In this section, following the advantages introduced by the blockchain technology, the modern core blockchain concepts including those of blockchain 1.0 and blockchain 2.0 are explained. A variety of current blockchain implementations applied to different types of supply chain industries is also mentioned. The reasons why developing decentralized solutions based on existing systems of centralized architecture is a pragmatic way going forward to improve the challenging product counterfeiting in the wider supply chain industry are also given.

3.1. Blockchain at the Core

The decentralized architecture could bring more advantages to the existing centralized product anti-counterfeiting system, and an example could be decentralizing NAS utilizing blockchain technology. As described in the first Blockchain use case [18], Blockchain is a distributed ledger technology recording and sharing all the transactions that occur within a dedicated peer-to-peer network. It is essentially a decentralized timestamp service with a virtual machine to execute signed scripts that operates on signed data. It utilizes a distributed ledger to store scripts and data with mutual consensus reached among participating nodes running on the same blockchain network.

The blockchain network consists of multiple nodes that maintain a set of shared states and perform transactions updating the states which could be divided into ledger state, block state, and transaction state as depicted in Figure 1. Blockchain transactions, as described in [19], need to go through the mining process. The transactions must be validated by the majority or agreed fraction among the participating network nodes, depending on which consensus protocol is adopted, before being ordered and packaged into a timestamped block which is also known as block signing.

The blockchain network can be generally categorized either as permissionless (public network) or permissioned network. The former is an open distributed ledger network, such as in [18,20], where any node can join the network and where any two peers can conduct transactions without any authentication performed by any central authority. The latter is a controlled distributed ledger (like in [21]) where the decision-making and validation process are kept to one organization or few organizations forming a consortium with or without the staking concept. In permissioned networks, the consortium administrator or certificate authority determines who can join the network as a validator node or listener node, if there is no logic of on-chain governance available. All nodes are authenticated in advance, and their identities are known to other nodes running on the same network and in the same consortium, at least to the administrator.

The general blockchain data structure is demonstrated in Figure 2. The first block is always referred as the genesis block, and a block consists of a header and a body. The block body contains the list of transactions. The number of transactions that can fit into a block is dependent on the block size (block gas limit) and the transaction size (gas spent per transaction). The block header, as discussed in [22], contains a wide variety of fields, including timestamp, Merkle root hash representing the hash value of every transaction in the block, and the hash pointer of the previous block header for which different blocks are “chained” to each other by putting this field of hash for every next block. There are more fields, such as the nonce which is the 32-bit field incremented until the equation is solved and difficulty which is needed for the Proof-of-Work (PoW) protocol. PoW is heavily linked with computation process known as mining, for which miners are the nodes to calculate the block header hash termed as “solving the puzzle”. The differences between blockchains and databases are also explained in [23].

Based on the Proof-of-Work consensus protocol, the block is said to be mined if a miner finds its nonce such that the hash of block header is less than the difficulty target, based on the work in [18]. Modern blockchain is also characterized into four main aspects, apart from being utilized merely as the distributed ledger: the self-executing smart contract, immutability, cryptography, and consensus.

3.2. Starting from the Original Blockchain 1.0—The Bitcoin Network

Blockchain is often regarded as the underlying technology of Bitcoin [18]—peer-to-peer version of electronic cash, namely, the decentralized virtual currency, which does not require any existing currency institutions to circulate and is of fixed currency circulation. The Bitcoin network is indeed the first use case adopting blockchain technology. Bitcoin aimed at offering a purely peer-to-peer version of electronic cash which would allow online payments to be sent directly from one party to another without involving a financial institution. The main benefits of such a decentralized virtual currency system are the prevention of double spending, single point of control, and potential failure due to the reliance of trusted third parties and intermediaries. The Bitcoin network relies heavily on decentralized consensus and its cryptographic properties with use of digital signature instead, offering new transparency to finance industry, which have normally been of great security concerns on virtual currencies.

Blocks of the Bitcoin network are mined through a computationally-intensive process also known as the Proof-of-Work consensus protocol. The detailed process of PoW is depicted in [24], requiring significant computational resources to solve a cryptographic hash-based puzzle, and the solution could be worked out by trial-and-error based on the targeted difficulty set per block. The consensus must be reached before a new block could be created with respective transactions packed in the new block. As there are many miner nodes available on the open Bitcoin network, every miner on the network competes to generate a valid Proof-of-Work consensus for the block. It will take approximately 10 min on average with the current setting of the Bitcoin network for a miner to create a block successfully and receive the mining reward which has been halved on predefined milestone blocks (also known as the “halving” as explained in [25]) of the Bitcoin network. The Proof-of-Work adopted in the Bitcoin network would prevent the Sybil attackers from promoting a dishonest blockchain supporting their malicious agendas, offering a way for honest nodes to overcome Byzantine failures as well as accepting the next block on the canonical chain. This process is arguably the most difficult part of implementing a consensus protocol where many attack vectors would be focused on, for which a Byzantine failure (or fault) is a condition of a distributed network, where participating nodes may fail, and there is imperfect information on whether a specific node has failed.

There are also conditions for which a transaction in the Bitcoin network would be validated and so a successful state transition would then attain. For instance, (1) digital assets involved in the transaction of transfer operations should exist, (2) by enforcing asymmetric cryptography to produce signatures every node should only spend the coins they own and not those of others, and (3) every transaction should be supplied with enough values to the inputs field of every transaction by summing up all the Unspent Transaction Outputs (UTXOs) the sending blockchain nodes owned. The concept of UTXO is demonstrated in Figure 3.

With the scripting ability of the Bitcoin network alongside its Proof-of-Work consensus algorithm requiring validation performed by participating nodes when the state-transitioned function is validated, the faulty transactions, such as the one sending the same fund twice, will receive an error and therefore be aborted. However, some malicious nodes could try to fork the chain and place a second transaction before the first requiring the calculation of upcoming blocks with the updated block headers, which would require the creation of a separate chain longer than the original chain to be the canonical one as nodes are programmed to settle on the chain with largest investment value which is the canonical chain. The authors of [26] suggested that the Bitcoin network could not actually solve the Byzantine Generals problem in general, as attackers could theoretically be computationally unlimited and dominate more than 51% share of the computation power. The overall mining hash rate of the network to perform double-spend operation faster than that on the canonical chain, also known as the 51% attack under which the analysis on the probability of solving n number of blocks consecutively faster than the canonical chain is demonstrated in Figure 4.

There are research and development efforts performed based on the Bitcoin model in the field of decentralized electronic payment, such as Litecoin in [27]. These counterparts, being anything other than the original Bitcoin, were grouped as “altcoins”, in which some basically are hard-forked versions of Bitcoin, while others have their own underlying native blockchain network with their own consensus protocols, such as Ethereum. With the advent of increasingly more native blockchain networks with their own consensus protocols and proposed data structures to be supported, blockchain provides a way for untrusting parties on a peer-to-peer network to agree on contents of a vastly replicated database. The blockchain industry has been focused on exploring more use cases other than merely the decentralized electronic payment using blockchain technology. The development of Blockchain 1.0 has undoubtedly set the premise for new ideas around decentralized autonomous organization and provided a solid basis for the development of Blockchain 2.0 protocols.

3.3. Overview of Blockchain 2.0—The Programmable Blockchain

Given the fact that the Bitcoin network only offers basic scripting functionality, with the advent of the open-source Ethereum, which was published as in [28] back in 2014, Ethereum is no longer limited to transaction records, and is more effective and robust than its counterpart Bitcoin. The Ethereum blockchain network is a programmable blockchain that can perform any arbitrarily complex computation unlike those predefined operations performed in transactions of Bitcoin. Ethereum allows developers to create their own operations of any complexity in smart contracts, utilizing the Turing-completeness programming language and the flexibility brought by the smart contract enabling more possibilities to the blockchain. Ethereum has therefore often been dubbed as Web 3.0 due to the fact that the architecture of Ethereum opens up more ideas of general applications with transactions related to data processing and transfer of digital assets, not only the typical use cases, such as decentralized cryptocurrencies.

3.3.1. States and Accounts

To get started, Ethereum is an account-based blockchain, instead of the Unspent Transaction Outputs (UTXO)-based blockchain like Bitcoin network, under which all account states stored locally as a form of state data with the predefined data structure of Merkle Patricia tree. As described in [20], Ethereum blocks contain a list of transactions and the Merkle root hash of entire state tree on transactions which are packed in every block. Every node on the network stores two types of states: the overall blockchain state and the state data containing a list of accounts and their associated states.

There are also two general types of Ethereum accounts: (1) externally owned accounts (EOAs) with key pairs generated and assigned for signature-based validations or signing transactions on the network, and (2) contract accounts, which essentially act as autonomous agents containing code that only act once they receive a message that has initiated its functionalities to read from and write to internal storage of the deployed smart contracts. The authors of [28,29] also proved that contract accounts can send messages to its counterparts with embedded calls to methods of other deployed smart contracts, which is basically another type of account on Ethereum blockchain.

3.3.2. Smart Contracts and Ethereum Virtual Machine

Entities on any consensus mode of Ethereum network are able to write smart contracts with methods to define transaction formats, access permission of the methods, state conversion equations suggested in [30], and literally any self-defined rules applied to method declarations with examples demonstrated in [31].

Entities in the network could first write and deploy a smart contract to the network for its decentralized applications to interact with, via its dedicated node using the blockchain client. The smart contract source code, written in Solidity for instance, is then encoded into Ethereum bytecode by the Solidity compiler. The bytecode is added to the data field of a transaction and deployed to the transaction pool of the network queuing to be picked up for further processes. The typical workflow of the smart contract source code is described in Figure 5.

As detailed in [32], the miners would then pick up the transaction via its node client, pack the validated transaction into a new block, and run the hexadecimal bytecode data of the transaction with its Ethereum Virtual Machine (EVM), which is the execution environment for running transaction code to reach a consensus. The work in [28] details a more complex set of instructions to be compiled in the form of smart contracts, to generate operation codes (e.g., PUSH1 0 × 60 PUSH1 0 × 40 MSTORE) and run based on the operation codes each time a specific method in the smart contract related to a specific transaction that is invoked following the rules set within the deployed smart contract. The smart contract could then have state transitioned on each miner’s local persistent storage on state data, only if data of the transaction are executed by the EVM successfully. For miner nodes on the network to be able to validate state changes brought by the transaction with the deployed smart contracts, they would be required to run the data, which is the bytecode with operation codes, retrieved from the transaction, on its EVM to check if it is actually a valid state transition. This would impose a large computational redundancy on the network, but it is necessary in order to reach the decentralized consensus.

There is also an inherent constraint on the number of computational steps a transaction can perform, which is limited with a concept of “Gas”—essentially the cost incurred by totaling all the methods of a deployed smart contract executed in a submitted transaction. The cost calculation is based on the gas spending guideline of each functional pattern predefined in [28]. Nodes will need to specify a maximum amount of gas they are willing to pay per transaction, and if not explicitly stated, then the client implementation of the network (e.g., Go-Ethereum, Parity) would determine the amount automatically. The storage shall be as lean as possible as it could cost an absurd amount of resources. There are current technologies which could enable decentralized data storage, such as in [33], and therefore decentralized solutions could be built and not required to stick with central database architecture. Every block, created by miners after the consensus reached among nodes running on the network, has a block gas limit similar to the transaction gas limit. The gas limit is the upper bound on the amount of computation a transaction can perform on its workflow in the network, and that is why people think Ether as the crypto fuels of Ethereum due to a fact that gas cost will be paid in Ether.

3.4. Blockchain 1.0 Versus Blockchain 2.0 and Later Versions

Blockchain implementations have been phased based on their development and use cases described in [34,35], respectively. While Blockchain 1.0, with the representative example of the Bitcoin network [18], focused on the development of cryptocurrencies for peer-to-peer electronic payments, Blockchain 2.0, such as Ethereum explained in [20,28] as well as Hyperledger Fabric discussed in [21], enabled the concept of smart contract. Blockchain 2.0 has a more flexible data structure and functionality enabled by deployed smart contracts. Blockchain 3.0 focuses on developing ÐApps essentially having back-end logic patterns running on a decentralized peer-to-peer platform with a dedicated user interface of it. Blockchain 4.0 focuses more on matching blockchain technology and its implementations usable especially to those Industry 4.0 business demands, such as process automation, enterprise resource planning, and integration of different execution systems respectively.

Starting from Blockchain 1.0, the Bitcoin network [18] is indeed the first use case of blockchain technology, aimed at offering a peer-to-peer version of electronic cash. The Proof-of-Work consensus algorithm applied to Bitcoin network, its unique UTXOs model, and the potential hash rate-based double-spending in [36], which could still exist in Bitcoin network, are the major characteristics and topics discussed and advanced among Bitcoin or even the entire blockchain development community. Blockchain 2.0 moved on enabling programmable blockchains with Ethereum. A variety of underlying concepts of Ethereum blockchain, such as account-based, smart contracts, gas, and Ethereum Virtual Machine, as well as explaining how Ethereum, is designed and progressed to be different from, and even more capable than, Bitcoin network, are explained in [20,28], respectively, as representative examples.

There are indeed extensive differences in terms of implementation and usage in both phases. Figure 6 demonstrates the most crucial differences in different perspectives, followed by explanations on why modern decentralized solutions would be developed with frameworks and functionalities provided and enabled in Blockchain 2.0.

• State: In Bitcoin, there are only two states, not to mention UTXO, that could either be “spent” or “unspent”, and so there is no contract or script to keep any internal state other than these two states. Ethereum enables more flexibility to create such contracts by utilizing the concepts of externally owned accounts and contract accounts. The multi-state can be defined given the functionalities of smart contracts. Once transactions are validated, packaged into their respective mined blocks, and appended to the blockchain, they are no longer allowed to be modified. If such modification on the specific blocks took place, it will invalidate every subsequent block intended to be appended to the blockchain.
• Block Time: The creation of a block in the Ethereum main net takes only 12 s (while block time could be specified in enterprise implementations of Ethereum), which is considerably faster than that in Bitcoin network taking nearly 10 min. Every transaction will then be validated and packed in a block quicker due to the faster block time in Ethereum but it would lead to decreased security, attributed by the faster block time, which has already been addressed by multiple block confirmations.
• Storage: In the Bitcoin network, only fixed scripts and data can be stored in a block, while self-defined scripts, in a form of smart contracts, can be executed with states stored on Ethereum blockchain implying that more methods are enabled. Many different applications can therefore be implemented on Ethereum or its Blockchain 2.0 counterparts.
• Turing Completeness: The script in the Bitcoin network does not support loops, so infinite loops can be prevented, while Ethereum provides more flexibility in script writing of its smart contract implementations and Turing completeness as it employs different methods to eradicate infinite loops.

While the open-source Ethereum blockchain has been planning a major Ethereum 2.0 (Eth2) upgrade to its network to address scalability concerns, there has been an array of blockchain frameworks in Blockchain 2.0. These frameworks are available for developing decentralized solutions based on a concept of enterprise blockchain, such as Hyperledger Fabric depicted in [21] or Tendermint Core developed based on the system approaches covered in [37,38]. Like Ethereum, all of these have been seeking to prove that enhanced security, enhanced degree of decentralization, and enhanced scalability are not at odds.

3.5. Related Work of Blockchain Implementations

With the advancement of blockchain development in recent years, there have been some existing blockchain innovations developed in different domains and in combination with other emerging technologies to decentralize software systems with centralized architecture of different purposes. A blockchain-based digital certificate system and blockchain-enabled system for personal data protection were proposed in [39,40], respectively. Furthermore, the works in [41,42] have also given an overview of blockchain-based applications developed in different domains where a variety of examples of blockchain systems and use cases are developed, could be found in healthcare domain, as depicted in [43,44], focused on decentralizing health record management and storage.

Blockchain innovations have also been implemented across the supply chain industry, and some are specifically with use cases of decentralizing and improving product traceability and anti-counterfeiting aspects of the supply chain industry. The authors of [45] have proposed a concept of a blockchain system to enhance transparency, traceability, and process integrity of manufacturing supply chains, while an Ethereum-based fully decentralized traceability system for Agri-food supply chain management named AgriBlockIoT was developed in [46]. Furthermore, there is a wide range of blockchain innovations applied in supply chain industry, such as the novel blockchain-based product ownership management system in [47], a blockchain-based anti-counterfeiting system coupled with chemical signature for additive manufacturing described in [48], and an ontology-driven blockchain design for supply chain provenance in [49], as well as a temperature monitoring and anti-counterfeiting system approach for pharmaceutical supply chains as depicted in [50].

Some implementations are conceptualized and developed based on computation-extensive permissionless blockchain networks and consensus algorithms, aiming at full decentralization over scalability and stability of such decentralized systems developed. Instead of developing blockchain implementations based on conceptual design, decentralizing legacy anti-counterfeiting systems with centralized architecture already implemented in the industry, further with blockchain innovations integrated with, would be a more pragmatic way to start with so as to provide timely support to improve the snowballing situation of product counterfeits in supply chain industry.

4. The NFC-Enabled Anti-Counterfeiting System—NAS

One of the solutions to answer the growing concerns on product counterfeiting in different supply chain systems of wine industry is the NFC-enabled Anti-Counterfeiting System (NAS). The NAS in [51] was developed and implemented back in 2014, aiming at providing an innovative and fully functional alternative, based on Near-field communication technology and cloud-based microservices architecture with centralized storage structure, solely hosted by any winemaker, to help improve the worsening situation of product counterfeiting especially for the wine industry. NAS with centralized data architectures, which are predominantly based on typical and familiar cloud-based client–server architecture style, is demonstrated in Figure 7.

The whole NAS solution consists of five main components: (1) the back-end system with web-based database management user interface for wine data management performed by winemakers, for which management of data columns of specific wine products which are in their custody can be performed by winemakers; (2) an NFC-enabled mobile application, ScanWINE, for tag-reading purpose of wine products at retailer points for wine consumers or supply chain participants of the supply chain before accepting these wine products; (3) another NFC-enabled mobile application, TagWINE, performing tag writing purpose for wine at wine bottling stage by winemakers; (4) the NFC tags packaged on wine bottlenecks for those purposes and actions; and (5) any NFC-enabled smartphones or tablets of supply chain participants and wine consumers along the supply chain.

There are four major categories of data to be processed along the supply chain with NAS: (1) nodal transaction history data, (2) supply chain data, (3) wine pedigree data which is processed with its dedicated controllers based on their predefined schema and data models, and (4) unsuccessful validation data returned from any unsuccessful validation at the stage of accepting wine products. As wine products being processed and handled by different nodes along the supply chain with data updated by scanning NFC tags of the wine products using tag-reading ScanWINE with the state of wine record to be updated accordingly to the database. These categories of data are updated along the supply chain until the point of purchase at which wine consumers use tag-reading ScanWINE to scan NFC tags and retrieve data such as the wine pedigree data and transaction data for real-time validation to determine if a wine product is counterfeit or not.

A unique identifier is assigned to each wine product and is written into the NFC tag. Such tag-attached wine products are then shipped from winemakers to different nodes along the supply chain. During the transportation process of these wine products along the supply chain, each involved node could scan the NFC tags and adds the aforementioned four categories of data into these NFC tags, respectively. In this way, the next node can check whether or not the wine products have already passed through the legitimate supply chain. If any inconsistency is found at any node, such wine products may be considered as counterfeits and should be returned to winemakers. However, once the wine product reached post-purchase stage and circulated in any customer-to-customer markets, its authenticity is no longer guaranteed, as anyone who has an NFC reader can interfere and clone tags’ data. Therefore, it is important to develop anti-counterfeiting systems that could work even when the data stored in tags is cloned in post-purchase supply chain with attacks detected and prevented on any potential adversary changes.

5. Security Analysis on NAS

In this section, a series of security analyses are performed on NAS, with findings of these security analyses also elaborated and discussed so as to identify which areas of NAS could be improved and strengthened, in terms of security, with the conception of decentralized product anti-counterfeiting and traceability solution enabled by blockchain technology.

5.1. Asset Analysis

The asset analysis of NAS, as described in Appendix B.1, lists ten constituent assets of NAS which are categorized into components of hardware, software, and data. Hardware assets are NFC-enabled mobile devices and NFC tags, while software assets of NAS are the two NFC-enabled mobile applications and the database operation web application. As described in the system overview of NAS, the data model of NAS is indeed based on four types of data assets: data of, wine pedigree, transaction history, supply chain, and unsuccessful records.

The (1) NFC tags (A04), (2) transaction history data (A06) of a wine record, and the (3) backend database (A10), which is solely managed by winemakers, storing all sorts of data components listed in the asset analysis, are among the three most probable system components susceptible to security risks according to ratings assigned to each component of confidentiality, integrity and availability (the CIA methodology).

5.2. Threat Analysis

Based on the result of asset analysis and system components identified, which are susceptible to security risks, a threat analysis is therefore performed against NAS, with every threat as described in Appendix B.2. Every possible threat to NAS could be categorized into either (1) physical NFC tag threats or (2) system threats.

Regarding physical NFC tag threats, the most probable and risky threats identified are as follows:

• Tag cloning (T01) for which each NFC tag used for product tagging and anti-counterfeiting purpose has a unique identifier. If the identifier information is exposed to attackers, the data stored in a tag could easily be cloned into another tag.
• Tag disabling (T03) for which adversaries could take advantage of wireless nature of NFC systems in order to disable tags, from any further interaction with NFC tags, temporarily or permanently, by changing the state of NFC tags.
• Tag’s data modification (T04) for which NFC tags use writable memory and so an adversary can take advantage of such a feature to modify or delete valuable data from memory of any involved NFC tag, during any tag reading and tag writing process. Unsecured configuration or even misconfiguration on NFC tags could also allow attackers compromising NAS as a whole.

These physical NFC tag threats are primarily attributed by a weak and fully centralized authentication and authorization mechanism adopted to change data states stored in NFC tags and any unsecured configuration on NFC tags during every tag writing and tag reading process.

While regarding system threats, the most probable and risky threats identified are as follows:

• Man-in-the-middle relay attack (T08) for which in a relay attack, an adversary acts as a man-in-the-middle. An adversarial device is placed surreptitiously between a legitimate NFC tag and mobile applications or mobile applications with dedicated backend database which is on logged-in state. Adversaries could obtain unauthorized access or unintentional information disclosure on the confidential data related to transactions or the supply chain as a whole.
• Tracking and tracing (T10), for which, via sending queries and obtaining same responses from an NFC tag at various locations, it can then determine where an NFC tag of a specific product is located physically with location data supplied. A malicious hacker may also obtain login data, via brute-forcing or dictionary attacks, to spoof and log in to mobile applications or web applications registered with the same login data as legitimate users.
• Denial-of-service (T11) for which DoS attacks are usually physical attacks, such as jamming the system with noise interference, blocking radio signals, removing, or even disabling NFC tags, causing different system components or the entire system to work improperly. Without sufficient auditing logs and monitoring functionalities of different system components, it would be unable to investigate any system misuse and compromise, security breach over leakage of confidential data.
• Spoofing attack on data of product records (T14) when attackers get some information about the identity of NFC tags either by detecting communication between mobile applications and legitimate NFC tags or by physical exploration on these NFC tags, attackers could then clone the NFC tags. Poor code quality on microservices enabling interaction between mobile applications and the backend database of product records, such as weak authorization and authentication with dummy passwords or without database backup path, could lead to data theft on the confidential data of processed product records maintained in NAS.

These system threats are majorly attributed by the single-point processing, storage, and failure due to the fact that operations and data of NAS are managed and controlled solely by winemakers as the anti-counterfeiting and traceability features of NAS are built on specific winemakers and around industrial operations enabled by NFC technology or other tag-communication technologies. Furthermore, vulnerabilities such as weak authentication and authorization as well as in lack of sufficient auditing logs and effective API monitoring tools could also give rise to threats, such as man-in-the-middle relay attack, tracking-and-tracing, and spoofing attack. Adversaries could manipulate vulnerabilities to obtain unauthorized access or unintentional information disclosure over the confidential data such as the transaction data, wine pedigree data, or supply chain data. The disclosure of confidential data would then lead to adverse manipulation on product records and so disability of anti-counterfeiting functionalities of NAS could be expected. Adversaries could also make use of vulnerabilities, such as unsecured configuration on servers, poor security implementation over the code base on possible attacks, as well as lacking audit logs and API performance monitoring, to perform denial-of-service (DoS) attacks on different system components of NAS affecting its service availability, stability, and performance.

6. Discussion of Research Results

With blockchain fundamentals explained, how blockchain technology could impose security upgrades to existing product anti-counterfeiting and traceability systems, such as NAS, of supply chain industry, and the results gathered from security analyses performed on NAS, this section will cover the summary of vulnerabilities identified in existing product anti-counterfeiting and traceability systems. The opportunities of decentralizing anti-counterfeiting and traceability in supply chain industry and potential concerns on developing decentralized solutions for supply chain industry, are also identified.

6.1. Summary of Vulnerabilities on Centralized System Architecture

Among NAS and other existing anti-counterfeiting alternatives with centralized architecture, utilizing wireless tag communication technologies, there could be at least three common probable counterfeit attacks applied to these anti-counterfeiting solutions. These attacks manipulating threats listed under the physical NFC tag threats and system threats according to the threat analyses performed are (1) modification of product records stored in tags, such as fabricating product identifiers or vintages of any product; (2) cloning of metadata stored in tags such as those genuine product records to any counterfeit product tag; and (3) removal of a legitimate tag from a genuine product and its reapplication to any other counterfeit products.

It has come to a point that even though the implementation of NAS itself is already more effective and secured than most of its typical supply chain anti-counterfeiting and traceability counterparts, with original product records being validated at any node along the supply chain, the centralized architecture of NAS could still pose risks in data integrity and product authenticity as any node, not only winemakers, along the supply chain have full control of product records stored in their own database architectures. In case different nodes along the supply chain are untrusting to each other, there could still be possibilities that a product record being duplicated adversely leading to a situation that product consumers could still purchase a product counterfeit at retail points, with fabricated wine records retrieved from NAS or its counterparts implemented in specific supply chain industries.

The typical architecture of centralized supply chains creates several concerns. First, there is a tremendous processing burden on servers, as significant numbers of products processed by multiple supply chain nodes. Second, substantial storage is required to store authentication records for every single processed product. Third, with centralized systems, traditional supply chains inherently have the problem of single-point failure and so potential service downtime and data loss could be expected. All in all, centralized product anti-counterfeiting and traceability systems, such as NAS, rely on a centralized authority to combat counterfeit products which would result in single-point processing, storage, and failure and those potential attacks via manipulating the security threats identified in threat analysis performed against NAS.

6.2. Opportunities of Decentralizing Supply Chain Anti-Counterfeiting and Traceability

To better prevent risks and overcome threats with vulnerabilities initiated by centralized architecture, Blockchain Technology (or other Distributed Ledger Technologies built with decentralized networks) stands out as a potential framework to establish a modernized, decentralized, trustworthy, accountable, transparent, and secured supply chain innovation against counterfeiting attacks, compared with those developed on centralized architecture, with comparison between two as detailed in Figure 8.

Given a variety of advantages, such as prevention of single-point failure, better resilience, and availability of being applied among supply chain participants, introduced with the blockchain technology and concept of decentralized application, to have a more secured and sophisticated supply chain system against counterfeiting attacks, it has well proven that decentralized supply chain anti-counterfeiting and traceability are in demand. The decentralized solutions are worth developing and implementing in supply chain industry, starting with a new solution or developing a novel prototype with a decentralized architecture, based on legacy solutions, such as NAS, to reinforce the innovative idea of product anti-counterfeiting. There are also a variety of opportunities that autonomous and decentralized supply chain anti-counterfeiting and traceability solutions could bring to supply chain industry as explained in the following.

6.2.1. Improved Data Integrity of Supply Chain

With the advent of blockchain technology and other technologies such as distributed file storage, a multi-layered data storage and validation mechanism, involved with on-chain and off-chain data operations, on product records could be implemented in decentralized solutions of supply chain anti-counterfeiting and traceability.

The on-chain and off-chain storage and validation could then be in place to ensure data integrity and prevent the decentralized solutions from any attempted attacks. The attacks could be cloning attacks on NFC tags, modification attacks in case product identifiers and signatures stored in NFC tags are inconsistent with its counterparts stored in the backend databases or on-chain storage with deployed smart contracts, or reapplication attacks in case both read count and write count are inconsistent to its counterparts stored off-chain and on-chain respectively.

With the decentralization enabled by the blockchain network, data integrity of processed product records is further improved which could further coupled with a concept of digital-asset tokenization representing every single product processed on the decentralized solutions. Any state change on specific product record could only be initiated with invoking methods on an open smart contract deployed to the network, with its transaction now needing to be validated with consensus reached, with other nodes held and run by different participating entities of supply chain industry, on the network. The immutability of transaction states related to any state transition of specific product record operations would mean that any state change processed on the network could be referred and queried based on individual transaction hashes and block numbers, which could further be confirmed on blockchain explorers connected to blockchain nodes running on the specific blockchain network.

6.2.2. Strengthened Security Considerations

Given the security considerations deployed to different possible validation mechanisms of any product record validation operation to improve data integrity, and according to the findings from the threat analysis performed against NAS, a variety of security attacks existed in NAS are no longer valid. Those attacks could well be prevented with errors thrown if they are detected before a state transition could be completed on a specific product record.

Any state transition on product records is required on-chain and off-chain validations performed against the data of product records, with respective transactions also validated by other blockchain nodes running on the same blockchain network. These validation steps of product record validation operation are now required to include signature generation and signing procedures, with key management modules offered to users, on any attempted state transition on product records. Regarding security considerations applied to the deployed smart contracts, which will be required if any blockchain 2.0 implementation is adopted to decentralize the supply chain anti-counterfeiting and traceability, multiple validation syntax on specific conditions are developed and included in different methods of smart contracts. This would prevent the system from being manipulated by potential attacks, such as reapplication attacks in which the on-chain write count and its counterpart stored off-chain do not actually match.

Design patterns with the role restriction concept of the deployed smart contract could also be introduced, so as to enable access authorization for authenticated node accounts held by specific entities of supply chain industry, to different methods defined in the deployed smart contracts. The security model on data integrity of NAS is currently based only on operations before the point of purchase. It could further be extended when the supply chain anti-counterfeiting and traceability functions are properly decentralized, as long as the post-purchase wine consumers of consumer-to-consumer market are also registered entities or even running nodes in the decentralized solutions.

6.2.3. High Availability of System Functionalities

Ensuring high-level operational performance of different system components to maintain system functionalities for different product record operations is key to the system implementation of NAS or any other supply chain anti-counterfeiting and traceability systems. With opportunities of system security and data integrity on product record now highly dependent on the system decentralization, the availability of data and states stored, as well as those decentralized system components, becomes more significant to the overall availability of system functionalities.

Regarding the decentralized solutions, the availability and resilience on data and states stored on blockchain network or any other decentralized system components are assured and can even be enhanced with increasing number of blockchain nodes running on the blockchain network owing to the fact that each node of these networks keeps the copy of the states stored in persistent volume dedicated to these distributed nodes. Availability of the blockchain network would also be enhanced with increased amount of blockchain nodes running on the blockchain network in which availability could be preserved as long as there is at least a blockchain node running on the network.

Dedicated persistent volume storage could also be assigned to each node instance running on the blockchain network to store blockchain states and individual chain data, so as to benefit from faster synchronization and data recovery on states to any new blockchain nodes connected to the network. This will then assure the availability of blockchain nodes and the blockchain network as a whole, as failed blockchain nodes could be reconnected to synchronize and process transactions sent to the network immediately. Nonetheless, availability of the data stored on-chain will be preserved with the smart contracts deployed to the blockchain network as long as it is actively running and mining new blocks constantly. The off-chain database and the app-backend service could also be made distributed with individual instances with which every participant under the decentralized solutions could now host their own instance of the supply chain anti-counterfeiting and traceability ecosystems.

6.3. Potential Concerns on Development of Decentralized Solutions

According to the summary of vulnerabilities on centralized system architecture, with opportunities of developing the decentralized solutions also identified, a set of fundamental system requirements of a decentralized version of NAS, namely, the Decentralized NFC-Enabled Anti-Counterfeiting System (dNAS), is also proposed with potential concerns on developing such decentralized solutions elaborated in the following.

6.3.1. Manageable System Integration Model

It is understood that not every user of the decentralized solutions would possess with in-house technical capacity to maintain its own instance of system components constituting the decentralized solutions. A manageable system integration model will need to be in place to help promote adoptions of the decentralized solutions from its centralized counterparts, which have been implementing and adopted in the wider supply chain industry, among different potential users in supply chain industry and for different stakeholders of industries to collaborate for good to help improve the worsening situation of product counterfeits, with the process integrity also conserved.

Such a manageable system integration model could provide another layer of indirection, allowing potential users to safely manage their own keys and the backup of product records in case anything unexpected goes wrong with system components of the decentralized solutions. An organization or alliance of major industry participants could act or be voted as leaders and host system components such as microservices, mobile applications, and even the decentralized blockchain nodes forming a blockchain network, as a fail-over and manage requests from these potential users of the decentralized solutions. A common data model of product records, applied to the decentralized solutions, should also be defined with additional metadata added after completing different types of industrial operations or steps declared in product data operation such as data validation and data creation steps both off-chain and on-chain, in order to facilitate a seamless process of data migration and integration.

6.3.2. Degree of Decentralization

The degree of decentralization is dependent and based on the chosen mechanism of manageable system integration. This will also require promoting adoption of such decentralized solutions, implying that some software components of the decentralized solutions are still expected to be hosted by intermediaries. The intermediaries could be backend databases, mobile applications, and backend application, with users only keeping hold of secrets or instances of decentralized system components such as blockchain nodes assigned to registered entities to the decentralized solutions.

The decentralized model could be substantiated with the blockchain network and its chosen consensus algorithm. Implementations of a blockchain network with its dedicated blockchain interface provide a certain degree of decentralization when it comes to transactions being validated and packed in a block on-chain with the respective methods of deployed smart contract invoked as well as proposing state changes on-chain registry for peer authentication and the blockchain network. Decentralization around smart contract management and deployment, management of software component instances of the decentralized solutions, and management of the distributed network protocols might be limited depending on the choice of blockchain implementations adopted but would definitely not be solely managed by product producers in the supply chain industry.

6.3.3. Limited Scalability

Scalability can somehow contradict with the degree of decentralization defined in the current setting of blockchain implementations. The decentralized solutions generally take more computation time for the same set of operations performed with centralized solutions, such as NAS, and so it is expected that decentralized systems are generally less scalable than its centralized counterparts owing to the fact that consensus is needed for every state changed on the data of processed product records.

The multi-layered validation and creation mechanism of product records processed in the decentralized solutions could in all likelihood imply decreased scalability as they could now involve more steps to store or even update representations of any product record, given these state transitions on product records involved are required to be processed in the decentralized system components as well. In case the number and size of product records grow with more products circulating in the supply chain, longer computation time is definitely needed for these product record operations with more computation resources committed on data processing of product records stored in the off-chain backend database structure. Data stored and processed on decentralized system components, such as the blockchain network, should be kept minimum, given the computation resources needed for these decentralized processes could be exponential compared with its centralized counterparts. The requests sent to the existing microservices and blockchain interface could be handled sequentially for which a new request could be processed only if the previous one is completed. The single-threaded handling of these microservices, involved in any end-to-end product record operations, could possibly hinder the scalability of the decentralized solutions as a whole.

Given the extra decentralized processes required in the decentralized solutions from the point of invoking endpoints made available in blockchain interface all the way to the blockchain network. The size of the blockchain will grow over time with more transactions validated and packed in blocks mined, not to mention a new block could be created in an interval of block time defined when initiating the blockchain network. It could take fairly long period of time for any new blockchain node to synchronize with other blockchain nodes to get to the latest global states of the network. The long synchronization time would hinder the user experience for participants using the decentralized solutions when the size of blockchain is too bulk. Though there are potential scalability concerns on any proposed decentralized solutions, it is still worth decentralizing the supply chain anti-counterfeiting and traceability, if comparing with the benefits brought by decentralization, such as the strengthened data integrity and improved system security with distributed instances enabling individual nodes along the supply chain collaborating to combat product counterfeits.

6.3.4. Potential Security Vulnerabilities

Every registered instance of the decentralized solutions is normally assigned with a blockchain node and an account of which a key pair could be generated and assigned to registered instances for their storage and management. Key pairs are required to validate and send transactions with its local blockchain node via the chosen blockchain client protocol. The same key pair could be retrieved and utilized over and over again without a concept of proper key rotation and management, and it is possible that the key pair could be compromised and thus the aforementioned attacks could still be made possible to create vulnerabilities and threats to the decentralized solutions.

Following the compromised key secrets, distributed denial of service (DDoS) could also be made possible as long as the blockchain node is hosted with enough computation resource, and it is possible to spam the blockchain network with a huge amount of transactions to be processed. The denial-of-service attack could also be performed by any malicious registered node, though they are part of the supply chain industry. A distributed key management module with key rotation functionalities to store and manage the key secrets should be implemented in the decentralized solutions, and a security authentication layer should also be added on top of the key management module whenever the blockchain interface, owned by the same registered instance, retrieves the key pair.

While for the data of product records stored and processed on decentralized components of decentralized solutions, such as the smart contracts deployed to the blockchain network and the service instance of any distributed file storage implemented, any blockchain node assigned to the registered entities could interpret and retrieve product record subsets if requested. The retrieval of product records is possible only if the unique identifier of processed products is supplied, as these product record subsets stored with the deployed smart contracts might not be encrypted and obfuscated with any hash algorithms. Though application of data security is really dependent on which types of blockchain network and consensus algorithm are adopted, which could generally categorized either into “permissioned” or “permissionless”, the decentralized solutions could adopt. Any data stored and processed on any decentralized system component should be kept minimum, obfuscated, and even encrypted to prevent from any potential malicious manipulation.

The publicity of the smart contract source code could also cause security vulnerabilities. Unlike the source code of different system components in NAS, which has the option to have its code base open-sourced or completely privatized, the smart contract code of decentralized solutions is always open and easily accessible by blockchain nodes running on the same network. Malicious users of the decentralized solutions running blockchain nodes could therefore look for human-induced vulnerabilities if any method of the deployed smart contracts is not implemented correctly.

6.3.5. Privacy Concern

As discussed in the potential security vulnerabilities, lacking a key rotation mechanism would imply the same public address is possible to be mapped to an actual registered node. The system role identifier of each registered node could further be mapped to a true identity of the representative organization or entity of the supply chain industry, by other registered nodes running on the same blockchain network if the decentralized solutions are developed in a setting with permissioned blockchain implementations.

Although public addresses stored on-chain could be obfuscated with hash functions applied, events could be emitted when methods of the deployed smart contracts are invoked, whenever there is a new transaction initiated on product record operations related to the same public addresses. The related events are later received by the event listener of every blockchain service instance. With more events emitted involving the same set of public addresses, it is more likely a specific public address could be mapped to an actual registered instance, and so its transaction volume could still be derived by other users of the decentralized solutions, which could potentially be its competitors. In addition to public addresses, these data fields could directly relate to physical entities and cause privacy concern if there is no privacy-preserving technology in place for these sensitive data fields. If the NFC tags are not deactivated properly when the respective products are consumed or transferred, it could possibly lead to a privacy threat based on any unencrypted or unobfuscated data field of specific product records stored in the NFC tags. Privacy-preserving technologies are required with use cases defined, based on chosen mechanisms on data processing and validation procedures to be included in the decentralized solutions.

7. Conclusions

Based on the growing concern in product counterfeiting of supply chain industry, the contributions of this research are to determine if anti-counterfeiting and traceability solutions currently adopted in supply chain industry could benefit from a certain degree of decentralization, via a series of security analyses: functional analyses performed against NAS. The possible opportunities and a list of fundamental system requirements of a decentralized version on NAS are also identified. Further statistical analyses on the research references of this research were also performed and demonstrated in Appendix A, where 86% of the research references of this research were published between 2012 and 2021, in which 44% were actually published within the past 5 years, and 20% of research references were actually published by IEEE.

A thorough explanation of blockchain technology is covered in this exploratory research so as to rationalize why the decentralized solutions should be developed with existing Blockchain 2.0 implementations, and why blockchain technology should be utilized to decentralize current solutions. There are mainly two categories of threats identified in these centralized solutions: physical NFC tag threats and system threats. These indicate the fact that tag-cloning, tag-disabling, tag’s data modification, man-in-the-middle relay attack, spoofing attack on product data, and denial-of-service are among the most probable and risky threats to NAS as well as other existing anti-counterfeiting and traceability systems built with any software system component and wireless tag component.

The discussion of research results indicated some potential opportunities, which are exactly the potential advantages of decentralizing the existing supply chain anti-counterfeiting solutions where it has been maintained merely by product producers or in the case of NAS—the winemakers. The opportunities, such as (1) the improved data integrity with a decentralized product record management with state transitions on product records only accepted if its respective transaction is validated and the block is mined on the blockchain network; (2) the strengthen security considerations on data of product records processed with multilayered validations in place; and (3) the high availability on system components and data of product records enabled by the decentralized system components, including the blockchain network to prevent from possible system downtime and unavailability.

There are also potential concerns on actual development of the decentralized solutions: (1) the manageable system integration model on whether it could promote adoptions among the industry participants; (2) degree of decentralization which could be contradicting the performance and throughput of processing product records; (3) the limited scalability attributed by the extra decentralized processes and multilayered validations on processing product data; (4) the security vulnerabilities attributed by lack of proper key management and rotation mechanism; and (5) the privacy concern on true identities of targeted entities being exposed, which could be mapped basing on a public address of repetitive uses, by other malicious entities running instances of the decentralized solutions, and even nodes on the same blockchain network. A fundamental set of system requirements for the Decentralized NFC-Enabled Anti-Counterfeiting System (dNAS), which is proposed to decentralize NAS of centralized architecture, is therefore defined, according to the potential concerns discussed. The system requirements defined will clarify the actual development and implementation of dNAS to take place in a separate research where the proposed system use cases, architecture and implementation will be elaborated with explanation on why the proposed decentralized solution could combat product counterfeiting in supply chain industry.