Orchestrating Product Provenance Story: When IOTA ECOSYSTEM Meets The Electronics Supply Chain Space

TL;DR

This paper presents a framework using IOTA's permissioned ledger and Masked Authenticated Messaging to enhance trustworthy, tamper-proof provenance tracking in the electronics supply chain, addressing blockchain scalability and confidentiality challenges.

Contribution

It introduces a novel IOTA-based provenance framework with MAM for secure, confidential, and transparent supply chain data management in electronics manufacturing.

Findings

Efficient construction time for provenance data varies with payload size.

The framework ensures tamper-proof and confidential supply chain information.

Enhanced traceability of product journey at each supply chain step.

Abstract

"Trustworthy data" is the fuel for ensuring transparent traceability, precise decision-making, and cogent coordination in the supply chain (SC) space. However, the disparate data silos act as a trade barrier in orchestrating the provenance of product story starting from the transformation of raw materials into the circuit board to the assembling of electronic components into end products available on the store shelf for customers. Therefore, to bridge the fragmented siloed information across global supply chain partners, the diffusion of blockchain (BC) as one of the advanced distributed ledger technology (DLT) takeover the on-premise legacy systems. Nevertheless, the challenging constraints of blockchain including scalability, accessing off-line data, fee-less microtransactions and many more lead to the third wave of blockchain called IOTA. In this paper, we propose a framework for supporting provenance in the electronic supply chain (ECS) by using permissioned IOTA ledger. Realizing the crucial requirement of trustworthy data, we use Masked Authenticated Messaging (MAM) channel provided by IOTA that allows the SC players to procure distributed information while keeping confidential trade flows, tamper-proof data, and fine-grained accessibility rights. To identify operational disruption, we devise a transparent product ledger through transaction data and consignment information to keep track of the complete product journey at each intermediary step during SC processes. Furthermore, we evaluate the secure provenance data construction time for varying payload size.

Figures

Tables

Table 1. Table 1 : Current research efforts pertaining to blockchain-based solutions for SC use-cases and their security aspects.

	SC Technical Challenges
SC Category	Scheme	D	C	I	A	S	AC	Audit	T	OFD	IoT/IIoT	BCID	QI
Food/Agriculture	[13]	✓	✓	✓	✓	$⊝$	✗	✗	✗	✗	$⊝$	✗	✗
	[14]	✓	✓	✓	✓	✗	✗	✗	✗	✗	✗	✗	✗
	[15]	✓	✓	✓	✓	✓	✓	✓	✗	✗	✓	✓	✗
	[16]	✓	✓	✓	✓	$⊝$	✗	✗	✗	✗	✓	✓	✗
	[17]	✓	✓	✓	✓	✗	✗	✗	✗	✗	$⊝$	✗	✗
	[18]	✓	✓	✓	✓	✗	✗	✗	✗	✗	$⊝$	✗	✗
Pharmaceutical/Healthcare	[19]	✓	✓	✓	✓	✓	✗	✗	✗	✗	✗	$⊝$	✗
	[20]	✓	✓	✓	✓	✗	$⊝$	$⊝$	✗	✗	✗	✗	✗
	[21]	✓	✓	✓	✓	✗	✗	$⊝$	✗	✗	✓	✓	✗
Electronics	[22]	✓	✓	✓	✓	$⊝$	✓	✓	$⊝$	✗	✗	✓	✗
	[23]	✓	✓	✓	✓	$⊝$	$⊝$	✗	$⊝$	✗	✓	✗	✗
Generic	[24]	✓	✓	✓	✓	✗	✓	✗	$⊝$	✗	✗	✓	✗
	[25]	✓	✓	✓	✓	✓	✓	$⊝$	✗	✗	✗	✓	✗
	[26]	✓	✓	✓	✓	✗	$⊝$	✗	✗	✗	✓	✓	✗
	[27]	✓	✓	✓	✓	✓	✓	✓	✗	✗	✓	✓	✗
$⊝$=discussed but details are not provided.

Table 2. Table 2 : List of notations

Symbol	Description
SC	Supply Chain
ESC	Electronic Supply Chain
QC	Quality Control
$T_{ID}$, $B_{ID}$, $C_{ID}$, $S_{ID}$	Transaction ID, Batch ID, Component ID, Sensor ID
$Payloa{d}_a$, $Payloa{d}_f$	Attach payload, Fetch payload
$D_p$	Data publisher or Seller
$D_r$	Data receiver or Buyer
$𝒦$	Authorization key
${𝒦}_{pu}$, ${𝒦}_{pr}$	Public key pair, Private key pair
$T_{Data}$, $A_{Data}$	Transaction data, Auxiliary data
$P_{Data}$, $P_{collect}$, $P_{aggr}$	Provenance data, Provenance collect, Provenance aggregate
$T_{Data}$, $A_{Data}$, $S_{Data}$	Transaction data, Auxiliary data, Sensor data
$Co{n}_{info}$	Consignment information
$Re{g}_{cert}$	Certificate by regulatory authority
$s\_d$	data from sensor devices
$Sr{c}_{ID}$, $Pre{v}_{TID}$	Source ID, Previous Transaction ID

Table 3. Table 3 : Specifications for hardware platforms.

Platform name	CPU	CPU core	Number of cores
Desktop machine	Intel Core i5-3330	-	4 (per socket)
Raspberry Pi 3B [110]	BCM2837	Cortex-A53	4

Table 4. Table 4 : Average time measured and energy consumption estimated for attaching and fetching data from the tangle through Raspberry Pi 3B.

Operation	Average Time (sec)	Energy Consumption (J)
Attach	23.1	5.1
Fetch	6.4	1.4

Table 5. Table 5 : Channel splitting example scenario: fine-grained access rights.

Channel ID	Policies	Queries	Result
SID: SK_GIH003	Allow $B_3$ to access: $T_{Data}$, $A_{Data}$	Fetch: $Sale{s}_{info}$ from $S_1$	Access Denied
	Allow $S_{sub}$ to access: $T_{Data}$, $A_{Data}$, $Sale{s}_{info}$, $Clien{t}_{info}$, $Advertisin{g}_{info}$	Fetch: $Manufacturin{g}_{info}$from $S_1$	Access Denied
		Fetch: $Sale{s}_{info}$ from $S_1$	Access Granted
SID: CN_SHE005	Allow $B_1$ to access: $T_{Data}$, $A_{Data}$, $Clien{t}_{info}$	Fetch: $Clien{t}_{info}$ from $S_{sub}$	Access Granted
	Allow $B_2$ to access: $T_{Data}$, $A_{Data}$, $Sale{s}_{info}$	Fetch: $Clien{t}_{info}$ from $S_{sub}$	Access Denied

Equations

$$Payload\leftarrow T_{Data}||A_{Data}||S_{Data},$$

$$T_{Data}\leftarrow T_{ID}||Selle{r}_{ID}||Buye{r}_{ID}||Co{n}_{info},$$

$$A_{Data}\leftarrow QC||Re{g}_{cert}||optional\_field,$$

$$S_{Data}\leftarrow S_{ID}||Channe{l}_{ID}||s\_d||timestamp.$$

$$Receipt\leftarrow T_{ID}||status,$$

$$P_{Data}\leftarrow Channe{l}_{ID}||T_{ID}||Sr{c}_{ID}||Pre{v}_{TID},$$

Full text

\keepXColumns

1 Introduction

Electronics Supply Chain (ESC) revolves around an intricate and intensive process during which raw materials or natural resources are transformed into circuit boards and electronic components, integrated and assembled into end products, and ultimately made available to the customers. Such a complex product evolution journey involving collaboration among multiple Supply Chain (SC) participating entities, each performing different operations on a product (or its parts), may raise several questions. For instance, how to identify the granular details of the underlying processes such as who, when, what, where, and how the product was derived. To answer these questions, SCs need a track and trace mechanism called provenance to construct a complete lineage of data about products’ origin, production, modification, and custody process [1]. Provenance in SC can enable the enterprises to choreograph their demand-supply circle, perform risk assessment, maximize revenues, investigate reasons for product recalls, and forecast their future goals. Furthermore, provenance ensures the integrity of data during data debugging, reconciliation, replication, decision making, performance tuning, auditing, and forensic analysis [2, 3, 4, 5, 6]. However, procuring product provenance data is an exhaustive task which gives rise to several other challenging issues concerning the collection, distribution, accessibility, and security of data. For instance, (i) how to collate provenance data from disparate data silos, complex data aggregation processes, and on-premise operational practices and procedures, (ii) how to assure integrity, reliability, and resiliency of data, (iii) how to ensure the distributed data accessibility and availability to legitimate participating entities, and many more.

Due to the unavailability of a platform that can provide one-size-fits-all solution to orchestrate product provenance story, it is hard to differentiate between reliable and counterfeit products. To this end, the proliferation of counterfeit products deteriorates consumer trust and also causes reputational damage to the company’s image. For instance, defense system manufacturers face difficulty in detecting counterfeit items, as counterfeiters attempt to imitate materials, part numbers, and serial numbers to simulate authentic parts [7]. Similarly, Integrated Circuits (ICs) counterfeiting has been observed in many industrial sectors, including computers, telecommunications, and automotive electronics [8]. For example, in 2018 Orange County electronics distributor was charged with selling counterfeit integrated circuits for military and commercial use [9]. To mitigate the risk effectively across the SC, atomistic sources of risk are required that involves scrutinizing a restricted part of the SC and is suitable for low-value and less complex components. Alternatively, holistic sources of risk are required that involves a comprehensive analysis of the SC and is preferable for high-value and complex components [10]. In both of these cases, contingency planning is required to identify the root cause of operational disruption and to identify the fraudulent middleman.

The inception of Distributed Ledger Technology (DLT) solves SC challenges by facilitating distributed, immutable, transparent, and fault-tolerant data aggregation across multiple entities (both physical and digital) [11]. In this regard, the blockchain-based architecture is used as a potential solution to fulfill the digital SC requirements in a plethora of SC use-cases (as discussed in Table 1). Table 1 outlines the current research efforts that use blockchain-based solutions for SC use-cases while considering their security aspects.

However, the current blockchain solutions lack many striking features such as scalability, offline data accessibility, fee-less transactions, and quantum-immunity that are among the desirable features in digital SC. To adequately address these limitations, IOTA [12] brings a transformation in the third generation of DLT. Following a scalable and quantum-immune approach, it securely accelerates tracking and tracing of multiple trade events in the SC even in the offline mode, and consequently enhance provenance data construction to identify counterfeit products.

In this paper, we propose an IOTA-based framework for supporting provenance in the ESC. By integrating the Masked Authenticated Messaging (MAM) protocol on top of IOTA (as shown in Fig. 1), our proposed framework provides transparent traceability of data throughout the SC ensuring trustworthy and quality data.

The main contributions of this paper are summarized as follows.

• •

We present a technological evolution of the SC management system starting from legacy systems to the state-of-art DLT. We also investigate the significance of integrating provenance in the ESC and address the research gaps and highlight the key factors for adopting IOTA in the SC in comparison to existing blockchain-based solutions.

• •

For product traceability, we propose an IOTA-based provenance framework that encapsulates the diverse product story as provenance data at each intermediary process in the ESC. Such a strategy solves the product counterfeiting issue in addition to the problem of fragmented and asymmetric information. To address the security issues, the MAM channel is leveraged to ensure confidential trade flow among competitors, to preserve data integrity, and to provide fine-grained data access to the trusted SC players only.

• •

Finally, we evaluate and show that the proposed scheme in terms of attaching SC data to the IOTA ledger and constructing provenance data by fetching data for varying payload sizes is admissible for the ESC. Furthermore, we develop a proof-of-concept for the proposed scheme on the Raspberry Pi 3B hardware platform to mimic the IoT-integrated ESC and analyze the measured average time and energy consumption incurred during attaching and fetching provenance data from the IOTA tangle which we find justifiable for resource-constrained IoT devices deployed in the SC.

The rest of the paper is organized as follows. Section 2 surveys related work. Section 3 provides an overview of IOTA, SC, and discusses the significance of integrating IOTA to support provenance in SC. Section 4 introduces the system model and Section 5 describes the proposed IOTA framework for the ESC. Section 6 presents the simulation results and discusses the security analysis of the proposed approach. Finally, Section 7 concludes the paper with an outlook on future work.

2 Related Works

In this section, we discuss the existing solutions for SC.

2.1 Legacy Systems: Enterprise Software Solutions for SC

In literature, many works analyzed the limitations of ERP systems. For example, [28] discussed the reasons for ERP dissatisfaction including, huge storage and networking requirements, training overheads, business process re-engineering, and software-related customization tasks. [29] identified disadvantages of ERP such as privacy concerns, high cost of ERP software incurred during the implementation, maintenance, upgrading, and time-consuming customization, to name a few. Similarly, in [30], the authors discussed ERP system misfits (in terms of data, functional, and output) that arise from incompatibilities between ERP packages and organizational requirements. In addition to the aforementioned drawbacks, handling transactions in ERP systems are complex and rampant because each organization maintains its own ledger. Due to this fact, information discontinuity and desynchronization as a weak link may increase the possibility of human error or fraud whereas reliance on a middleman for validation leads to inefficiencies.

2.2 Cloud-Based Solution for SC

In comparison to ERP systems, cloud-based solutions, for instance, Software as a Service–SaaS, are plugged into SC to provide several benefits including fault tolerance, high availability, scalability, flexibility, reduced overhead for users, reduced cost of ownership, on-demand services, etc. [31]. However, the adoption of cloud-based solutions may create new risks to the SC. For instance, trusting a third-party platform to store confidential information related to SC system, applications, and customer data can raise security and privacy issues [32, 33]. Similarly, storing data or sensor values in a secure and confidential manner is still under question in cloud-based solutions. Hence, introducing cloud-based solutions raise significant concerns about privacy, security, data integrity, intellectual property management, audit trails, compatibility, and reliability [34, 35]. Moreover, in case of a cloud service outage, all SC operations will have a catastrophic effect on the data availability and ultimately deteriorate the overall performance of the system [36, 37].

2.3 DLT-Based Solution for SC

The imperative transition to adopt DLT in SC received significant attention in recent years as a solution to many challenges stemmed from the existing legacy system and privacy issues due to the multi-party access [38]. In this regard, the nascent technology of blockchain allows companies to record every event within a SC on a distributed ledger that is shared among all participants, not owned by anyone, solve important glitches in traceability, and record events in a secure, immutable, and irrevocable way.

Blockchain has a very constructive role in SC from different perspectives. For instance, blockchain can provide design decisions and solve technical challenges (as shown in Fig. 5) faced by SC. Furthermore, blockchain-based architecture for SC that leverages public or private blockchain, can use different platforms such as Ethereum, Hyperledger Fabric, and Ripple. Many promising blockchain-enabled solutions have been proposed in literature where blockchain is leveraged in SC across different industries, for instance, food, agriculture, pharmaceutical, electronics SCs, to name a few. In Table 1, we summarized technical blockchain-based solutions for various SC categories (application-specific or generalized solutions) and associated shortcomings either in the context of the proposed scheme or the blockchain in particular. In Industry 4.0, blockchain can automate processes among IIoT, cyber-physical systems, and supply partners [39]. For example, [40] discusses the integration of blockchain into the manufacturing industry for data integrity and resilience. Similarly, in [41], the authors propose a block-chain based platform for small and medium manufacturing enterprises (SMEs) to solve issues such as security, scalability, and big data problems.

In the following, we discuss non-technical works in literature that focus on the technical and non-technical challenges of blockchain-based deployed systems in SCs, for example, in [42], the authors highlight technical, educational, and regulatory challenges and barriers in agriculture and food SCs. In [43], the authors discuss open research challenges in blockchain-based use-cases, including the Internet of Medical Things (IoMT), healthcare data management, and SC management. Furthermore, the authors of [44] also provide an overview of the challenges associated with blockchain adoption and deployment for the health SC with a focus on pharmaceutical, Internet of Healthy Things (IoHT), and public health. In [45], the authors discuss the factors that bring a positive impact on blockchain-based ESC. Similarly, many other use cases are discussed in [46, 47, 48, 49].

Recently, various worldwide enterprises have played a significant role in providing blockchain-based platforms for supporting friction-less traceability and transparency in SC, for instance, IBM’s blockchain framework [50] has been adopted by Walmart, Nestle, Unilever, and other players in the global Food Supply Chain (FSC) [51]. Other notable blockchain-enabled SC frameworks include Hyperledger [52], skuchain [53], Provenance [54], Blockverify [55], Multichain [56], etc. However, the proprietary and private blockchain-based solutions are unable to address the specific requirements or needs in the public domain and portray blockchain as a black-box.

2.4 Limitations of Blockchain in SC

Most of the blockchain-based solutions adopted for SC theoretically cover advantages, potential challenges, and future directions [57, 58, 59, 60, 61]. However, the underlying constraints of blockchain are overlooked by the current solutions. Among other constraints, quantum-resistance and scalability are noteworthy. Ongoing efforts to address these potential issues are underway, for instance, to meet the challenging requirement of quantum future, some of the emerging blockchain solutions that already support post-quantum techniques are Quantum Resistant Ledger (QRL) [62], Corda [63], Quantum-secured blockchain [64], and DL-for-IoT [65], etc. Solutions such as sharding and off-chain are expected to solve the scalability problem of the blockchain. However, these solutions have their own drawbacks. For instance, sharding requires to synchronize the running of operations among different processes on different shards. Furthermore, the overheating of a targeted single shard due to many cross-shard transactions is another problem that requires the ranking of these transactions to prevent overloading of block producers on the target shard. Similarly, off-chain solutions suffer from the following limitations: (i) introduce additional layers of complexity as the protocols are built on the top of the blockchain, (ii) may face objection by government and business communities due to their censorship-resistant nature. Directed Acyclic Graph (DAG)-based blockchain design is another effort to overcome the scalability issue caused by the sequential chain-based design of the traditional blockchain [66]. The authors of [67, 68, 69] provide a comparative analysis of DAG-based blockchain schemes.

Many of current research works are assuming, though some with skepticism, that blockchain technology will be adopted in the SC industry. For instance, some of their concerns are as follows: considering the connection between physical and digital world, how to ensure the reliability of data from SC entities and sensors [70], security concerns due to quantum computing and latency issues with the increasing number of nodes in the network [71, 72], lack of privacy and Garbage In Garbage Out (GIGO) problem [11], lack of information leading to existence of gray markets [66] and decision paralysis due to information overload, etc. But paradoxically on the other side, solutions such as [1, 59, 73, 57, 60, 74, 75] focus on the significance of using blockchain in SC. Overall, most of the proposed schemes (discussed in Table 1) failed to address the potential current problem (such as scalability) and future issues (such as quantum-resistance) of blockchain. Moreover, other technical requirements of SC such as accessibility and auditability based on roles and access levels, are also overlooked.

The common denominator among DLTs is their reliance on a distributed, decentralized peer-to-peer network, and consensus mechanism. However, DLTs vary substantially in terms of the underlying data structure, fault tolerance, and consensus approaches [76]. In addition to blockchain and its different flavors, other well-known DLTs are tangle, hashgraph [77], sidechain, and holochains [78]. In [76], the authors provide a comparative analysis of DLTs, whereas, in [68], the authors compare classical blockchain with DAG-based blockchain. Considering the primary challenge, i.e., scalability, faced by blockchain-based solutions in SCs, we consider a DAG-based DLT, i.e., IOTA. In comparison to other DLTs, IOTA exhibits quantum immune nature, provides off-line data accessibility, and supports fee-less microtransactions that are important factors for future SCs. Some of the striking features of IOTA DLT are discussed in Section 3.3.3.

2.5 Our Research Contributions

In the presence of the existing research, we highlight the main contributions of our work. This research is aimed to highlight the current research gaps in SCs and propose a state-of-the-art approach to resolve them. Though the existing blockchain-based solutions for SC has solved the primitive problems associated with disjoint data fragments, third party dependency, data security, and many other problems related to legacy systems. Nevertheless, there are still a few issues with the existing solutions that need to be addressed. In this regard, our contributions include the following key factors that are required to incorporate in a DLT-enabled SC.

Firstly, why the transition from the mainstream blockchain to IOTA is required? We adopt IOTA DLT upon realizing the overlooked constraints of blockchain. For instance, scalability issues particularly in case of growing participating entities; accessing data from freights in remote areas or off-line mode; dealing with transaction fees, and finally reliance on the security of current cryptographic primitives keeping in view the not-so-far arrival of quantum computers. The details about such constraints are discussed in Section 3.3.3. Secondly, how to create transparency towards the consumers? To win consumer trust, it is important to give them a sheer picture of the product journey. We devise a mechanism that involves reconstructing a trustworthy product provenance story, thus enabling customers to drive a real change. Thirdly, how to define customized data access control rights? We use the MAM protocol to provide fine-grained data access privileges to facilitate the trade secrets of participating entities. Fourthly, how to identify counterfeit products? We construct provenance data such that it includes complete information to identify the illegitimate or defective item.

For illustrative purposes, we consider the example of mobile phones in ESC. While keeping the underlying framework same, the proposed model is suitable for any commodity in ESC. Furthermore, it can be customized to other non-electronics SCs (for example, food-agriculture, pharmaceuticals) keeping in view the diverse requirements driven by their specific business needs and additional information (e.g., expiry dates or any other precautionary measures). For instance, food-agriculture, pharmaceuticals, or any other cold chain differs from ESC as they are subject to sensitive temperature and environmental conditions necessary to maintain the quality of perishable items in terms of temperature, humidity, etc. Similarly, ESC differs from other SCs based on quality testing, such as expiry period in case of cold chains are completely different from the warranty period determined through failure testing/product life testing of electronic components. Other differences include the packaging and assembling of components at various stages. Such requirements of cold SCs can be facilitated through our proposed model by continuous monitoring and reporting of the sensor data at frequent intervals to ensure the quality of products while allowing the integration of any optional information. Therefore, by tweaking the parameters based on the details of the underlying SC case, the proposed framework can be applied to any other SC.

3 IOTA in SC: An Overview

In this section, we provide a quick overview of the key terms in IOTA and SC. We also emphasize on using IOTA DLT in the SC.

3.1 IOTA

IOTA is a public, permissionless, and a distributed ledger that leverages directed acyclic graph (DAG) data structure termed as tangle for storing interlinked but individual transactions exchanged among peers [12]. Fig. 2 shows a tangle graph where each square-block represents a transaction/site which is propagated by a node. Every new transaction attached to the tangle graph forms an edge set. To create a transaction, a node (i) creates and signs a transaction with its private key, (ii) use the Markov Chain Monte Carlo (MCMC) algorithm [79] to choose and validate two other non-conflicting unconfirmed transactions (tips), and (iii) solve a cryptographic puzzle (known as Hashcash [80]) to perform Proof of Work (PoW) for preventing Sybil attack. Transaction status can be categorized as confirmed transactions (green nodes), uncertain transactions (red nodes), and unconfirmed transactions or tips (grey nodes) as shown in Fig. 2. The revolutionary features of IOTA including scalability, decentralization, zero transaction fee, speedy microtransactions, off-line capability, and quantum security enables it to gain ground not only in Machine-to-Machine (M2M) economy but also in application areas encompassing IIoT.

3.2 Supply Chain System

Supply chain encompasses coordination and collaboration among channel partners (suppliers, intermediaries, third-party service providers, and customers) for planning and managing of upstream and downstream process-based activities such as the transformation of natural resources/raw materials, sourcing, procurement, production, conversion, and logistics [81]. Fig. 3 shows the primary entities involved in the production of mobile phones in the ESC.

3.3 Motivation: Integrating Provenance Support in the Electronics Supply Chain Through IOTA

SCs empower participants for collaborative commerce in a global value chain. A product (for instance, mobile phone) journey from sand to hand, comprise of numerous chained phases during which components are produced, sourced, refined, integrated, and assembled by multiple entities ubiquitously. Nevertheless, numerous friction points thwart SCs from accomplishing their maximum potential, for instance, opaque mechanics of global commerce, complexity (upstream and downstream), manual processes, and divergent standards. Furthermore, SCs are held back by imperfect and asymmetric information as huge volumes of veracious data are inaccessible to the SC players during cross-border trading resulting in communication gaps, increased costs, forfeited data, erroneous data aggregation, scattered information, market failures, or absence of markets at all. Therefore, it can be concluded that a sustainable SC stipulates two pivotal features to be incorporated: (i) Product story (ii) Orchestrating episodes of product story.

3.3.1 Provenance: Product Story

To trace the audit trail of data, provenance plays a significant role in constructing a "product story" throughout the SC. The product story (or product traceability) enables the seller-buyer pair to trace the product from its inventory procurement process to its point of sale and hence provides an efficient way for tackling counterfeits or determine liability in the event of faulty records. For instance, upon scanning the Quick Response (QR) code, the consumer can look at the product story.

3.3.2 IOTA: Orchestrating Episodes of Product Story

Relying solely on provenance to notch trustworthy data is not sufficient, therefore, to efficiently and proactively systematize the product story in terms of provenance data, we collocate the product story episodes in a tamper-proof product ledger perpetuated by IOTA. IOTA is a promising technology that could play an indispensable role in providing salient features desirable for SC including decentralized, distributed, and interoperable data stream to consortium members. Furthermore, it provides data auditability to identify accountable actors causing data contamination, reasonable confidentiality and privacy of the trade flows, facilitating access control on immutable and trustworthy data. In essence, coalescing real-time provenance data through resource-constrained sensors (such as track and trace of precise location information, transfer of custody, monitoring environmental conditions or temperature fluctuations during storing and shipping product through GPS, RFID tags, temperature sensors, humidity sensors, etc.) that can drive decision-making power during risk mitigation forecasting.

3.3.3 Striking Features of IOTA

IOTA leads to a paradigm shift in the third generation of DLTs by providing a solution to the challenging constraints encountered by the blockchain. In essence, the IOTA platform breaks out the blockchain trilemma as it exhibits the following salient features essential to SC in contrast to the blockchain.

Scalability: In the SC space, the transaction load is expected to increase based on actors and activities in the network over time. Traditional blockchain runs into scaling snag as the transactions and the validation of said transactions are siloed and often at odds with each other. A permissioned blockchain has the potential to scale to a few hundred nodes [82], which may affect the latency and throughput of the network. For instance, the processed transactions per second (TPS) of the mainstream blockchain platforms like Bitcoin (7 TPS) and Ethereum (15 TPS) is very limited because the blocks cannot be created simultaneously due to a single linear chain of blocks [83]. To address the problem of scalability, [82, 84, 85] used the concept of sharding single blockchain ledger i.e., processing of transactions is distributed across multiple nodes in parallel. However, the block-less design of IOTA scales horizontally can theoretically improve transaction efficiency and claims to resolve the problem of scalability without any need to take care of global and local ledgers. 2. 2.

IOTA for IoT: Cost-effective miniaturized things or objects with storage, computational, and networking capabilities are providing promising solutions to optimize myriad events of track-and-trace in the supply cycle. Such synergistic integration of IoT and SC results in the cyber-physical system concept of Industry 4.0 [86]. However, IoT-linked security crises may breach the system security making it vulnerable to attacks, for instance, NotPetya, Stuxnet, PyPi, ShadowPad, and many other SC attacks. To cope with such situations, IOTA provides a high end-to-end security level called Masked Authenticated Messaging (MAM) protocol that facilitates encrypted data communication and securely anchors it to the tangle in a quantum-proof fashion. Moreover, through the MAM channel, access privileges can be tailored, thereby making it a perfect platform to build tomorrow’s trade facilitation systems in SC. 3. 3.

Off-line transaction: IOTA supports the off-line capability for handling scenarios such as information retrieval from remote areas and sensors on a container of a freighter ship that loses connectivity during ocean transportation. This mechanism is called "partitioning" during which a tangle in IOTA can get branch off by creating an off-line cluster and back into the network upon Internet connectivity, thereby securing the local transactions. 4. 4.

Speedy and zero-fee transactions without miners: Blockchain can be used for payments in many notable application areas. However, PoW based blockchains [87] require transaction fees due to the presence of miners and are not suitable for micropayments. Similarly, private, permission-based blockchains are lightweight [88] but lack important properties for PoW based blockchains, such as censorship resistance [89]. Unlike blockchains, IOTA is based on the concept of users equal to validators. IOTA is free from miners i.e., all participants need to contribute their computation power to maintain the network and hence does not charge any transaction fee. Furthermore, by enabling transactions to be validated in parallel, IOTA has the highest TPS among other distributed ledger.

Machines with digital wallets: Though blockchain has also enabled M2M communications, for instance, [90] presents an example of the chemical industry where blockchain is employed to establish an M2M electricity market. However, the chained-based blockchains have certain limitations as discussed in Section 2.4.

IOTA has also powered resource-constrained devices to participate in the M2M world. Being a powerful catalyst in the M2M economy, it allows machines to interact seamlessly and instantly transact with each other through its bi-directional off-tangle payment channel called Flash Channel allowing massive volumes of nano and microtransactions [91]. One such electric autonomous vehicle example scenario is suggested in [92]. Thus, IOTA can enable the automotive to pay autonomously for services including parking, charging batteries, tolls taxes, usage-based insurances, and many more [93] (as shown in Fig. 4). In September 2018, the Netherlands successfully completes testing for electric car charging station using IOTA [94]. Another practical application of a digital twin with IOTA is CarPass [95] for vehicle telematics data (e.g. mileage, trips, environmental, maintenance data) [96]. The data marketplace is also an interesting application that simulates the connected devices running IOTA protocol to share secure and valuable real-time data [97]. 6. 6.

Quantum immune: The reliance of blockchain technology on classical digital signatures makes it prone to quantum attack due to which an attacker equipped with a quantum computer can forge a digital signature or impersonate that user [98, 99]. Realizing the fact arises due to quantum nervousness, IOTA uses the Winternitz One-Time Signature Scheme (WOTS) [100] which is a quantum-resistant algorithm. Nonetheless, there is an ongoing debate on the ability of blockchain to survive against quantum computers [101, 102, 103] and efforts are underway for quantum-safe blockchains [98].

4 System Model

In this section, we provide an overview of the design parameters necessary for the SC system. We describe the network model and the data model that we consider for our proposed IOTA-based provenance scheme for SC. We also present the provenance model along with the outline of elemental provenance data components that are utilized in our proposed scheme. Finally, we discuss the security goals that our proposed scheme aims to achieve. Table 2 lists the major symbols used throughout the paper.

4.1 Design Approach

In this subsection, we highlight the technical and non-technical factors that must be considered before designing a provenance-based solution for SC. We also provide a succinct overview of how these design principles can solve potential SC challenges (shown in Fig. 5).

The first factor is to identify the information type and source, for instance, level of information (coarse-grained or fine-grained), data acquiring source such as digital assets or humans (each having different repercussions), etc. Comprehensive data aggregated from multiple data sources plays a significant role in solving many problems such as data traceability, risk factors in trade events, etc.

The second factor is to identify erroneous data in the system to ensure data trustworthiness which in turn can solve many issues such as bullwhip effect, GIGO problem, trust issues between seller-buyer pair, etc. Erroneous data refers to the state of data before it arrives at the ledger, i.e., during data generation and data transit. Erroneous data can be generated (either maliciously or mistakenly) by (i) source/data originator, (ii) intermediate entities, (iii) SC participating entity, and (iv) sensors or other technologies connecting the physical and digital world.

The third factor is to identify the best practices for Supply Chain Risk Management (SCRM). SCRM involves processes to identify risk events and to activate a plan accordingly to mitigate its effect. Problems such as shrinkage, outage, natural disasters, economic crisis, etc. are covered under this factor.

The forth factor is the integration of state-of-the-art technologies such as IoT, IIoT, and others. Such integration can automate the processes of inventory with minimal human involvement.

The fifth factor is the evaluation of non-technical factors such as Ethical, Sustainable, and Responsible (ESR) operations as discussed in [66]. ESR operations deal with issues, such as labor conditions, child labor, responsible usage of natural resources (land, water, energy), etc.

Note that, the above-mentioned factors are tightly inter-linked with each other, i.e., failure to exercise any one of the factors can highly affect the outcome of the other factor.

4.2 Network Model

Our network model consists of SC entities (participating and non-participating) and sensors. In the following, we outline two main data sources in the ESC, i.e., SC players and sensors.

4.2.1 SC Players

Following are the participating players in ESC.

(i) Raw producers, (ii) Suppliers, (iii) Manufacturers, (iv) Warehouses, (v) Logistics, and (vi) Retailers. The raw producers provide raw materials to the supplier to produce chip-sets and other peripherals. Those components are fabricated and assembled at a manufacturing unit. The finished products (for instance, mobile phones) are delivered to the warehouses for distribution. Finally, customers can purchase them from designated retailers.

Additionally, there are non-participating players such as (i) customers, and (ii) researchers/analysts. Non-participating members including customers and researchers are not involved in the SC process; however, they may need to fetch the production and manufacturing information about the products. Hence, they are also considered as part of our network model.

4.2.2 Sensors

Sensors are used to connect the physical world to the digital world. Sensors are affixed to batches during logistics and transportation to provide information such as location, temperature, humidity, etc. Due to the resource-constrained nature of sensors, we assume that such devices act as light nodes and may utilize the full nodes for performing computationally expensive tasks of the IOTA framework. For further processing, interpretation, and analysis of data, the sensor data is fetched from the tangle to track and trace SC events.

4.3 Data Model

We assume that each SC entity acts as a Data Publisher ($D_{p}$) and publishes its data (also referred to as attaching data) on its MAM channel identified by $Channel_{ID}$. On the other hand, the interested viewers act as a Data Receiver ($D_{r}$) and subscribe to the desired channel ($\mathcal{C}$) to gain access to the data (also referred to as fetching data) by using an authorization key ($\mathcal{K}$). The term $\mathcal{K}$ is collectively used for public $\mathcal{K}_{pu}$ and private $\mathcal{K}_{pr}$ key pairs.

In the context of SC, $D_{p}$ and $D_{r}$ can be referred to as Seller and Buyer respectively. The data (also referred as payload) consists of (i) Transaction data ($T_{Data}$), (ii) Auxiliary data ($A_{Data}$), and (iii) Sensor data ($S_{Data}$) can be represented as:

[TABLE]

$T_{Data}$ consists of transaction ID ($T_{ID}$), trade event as $\langle source,destination\rangle$ pair, i.e., seller ID ($Supplier_{ID}$) and buyer ID ($Buyer_{ID}$), and consignment information ($Con_{info}$). $Con_{info}$ may include batch ID ($B_{ID}$), component ID ($C_{ID}$), make and model number (as depicted in Fig. 7 and Fig. 9). Other granular details such as quantity, unit price, vehicle ID, etc., can also be included as a part of $Con_{info}$.

$A_{Data}$ consists of Quality Control ($QC$) parameters (such as ISO certifications/accreditation, warranty, etc.), regulatory endorsements certificates ($Reg_{cert}$), and optional field ($optional\_field$). We consider $optional\_field$ to store application-specific or user-specific information, for example, pre-defined agreements among trading entities. In our case, we use this field to store packaging information (i.e., traceability information) related to items that may need to be packed together and extracted at a later stage such as during assembling mobile phone parts or during burning software on ICs. Traceability information includes where a particular package is reopened by which entity due to what reason. Besides, it may contain information about shrinkage events in case of loss or damage to physical goods. Among other quality control parameters, warranty plays an effective role as it provides a marketing strategy to attract customers and also signals product quality [104]. In our case, this factor can also contribute to establishing a trust relationship among buyers (consumers) and sellers (honest or dishonest) in the long run. The regulatory endorsements can help to ascertain that SC processes are abiding by ethical practices and environmentally-responsible operations. The exercising of such ESR operations requires the involvement of regulatory bodies (NGOs, governments, industry self-regulators) to conduct a periodic on-site inspection of the units and provide verifiable certificates ($Reg_{cert}$) as shown in Fig. 6.

$S_{Data}$ consists of sensor ID ($S_{ID}$) assigned to each sensor, $Channel_{ID}$ of $D_{p}$ publishing the sensor data ($s\_d$) such as location, temperature, humidity along with timestamp information. During transportation and logistics of goods, $s\_d$ is attached to the tangle and can be accessed by seller-buyer pair to acquire $Con_{info}$ as shown in Fig. 6. The granularity level of $s\_d$ can be customized depending on the requirements, for instance, coarse-grained data by averaging temperature data or fine-grained data by using channel splitting option.

When a product or its parts are received by the buying entity, the receipt ($Receipt$) is generated to log the completion of the trade event between the seller-buyer pair (as shown in Fig. 6).

[TABLE]

where $T_{ID}$ and $status$ represent the transaction ID and status of the received item respectively. The purpose of introducing this transaction is threefold: (1) to keep track of the successful transactions to avoid any fake-progressive sub-chains, (2) to indicate any loss or damage event, and (3) to integrate trade finance process in SC.

4.4 Provenance Model

Deriving the product story primarily involves collecting provenance data ($P_{Data}$) based on $\langle source,destination\rangle$ pairs while traversing through the SC process. Therefore, to construct and assemble $P_{Data}$, firstly the payload (holding complete transaction and auxiliary data) is fetched from the ledger and secondly the required information is acquired from the fetched payload ($Payload_{f}$). The key factors to devise product provenance are:

[TABLE]

where $Channel_{ID}$ refers to the current ID of source, $Src_{ID}$ refers to the channel ID of destination (i.e., immediate $Channel_{ID}$ of SC entity), and $Prev_{TID}$ refers to the on-going transaction in the channel of $Src_{ID}$ pertaining to the fact that there can be multiple on-going transactions in that channel. Note that depending on the query, additional information can be obtained from $T_{Data}$, $A_{Data}$, and $S_{Data}$ accordingly. Also, $P_{Data}$ can be encoded on a QR code to be used by SC entities.

4.5 Security Goals

Keeping in view the requirements of SC, our proposed scheme aims to achieve the following security properties:

Data confidentiality: To hide classified trade information among competitors, it is essential to encrypt data communication. 2. 2.

Access control rights: Defining access control rights is indispensable to conceal classified trade information among competitors. Moreover, sharing only a subset of data at any desired point in time must be allowable by the SC player. 3. 3.

Restrictions on data retrieval: Upon joining the data stream of the SC process, SC players must only be able to retrieve the information at or after their entry point to the process with no privileges to previous transaction streams. 4. 4.

Data integrity: Integrity of trade events must also be ensured during data creation and sharing. 5. 5.

Non-repudiation: Any participating entity must not be able to deny an SC event that has happened or SC data that has been produced.

5 Proposed Framework: Procuring Provenance in ESC Through IOTA

In this section, we provide a brief overview of the characteristics and working of the MAM protocol provided by IOTA. We also devise the proposed framework for provenance in SC using IOTA with the help of algorithms and flow diagrams.

5.1 Masked Authenticated Messaging (MAM)

To ensure secure, encrypted, and authenticated data stream on the tangle, we leverage a MAM module that provides a channel where data owner who publishes the data and data viewers who subscribe, meet. Using the gossip protocol, the message from the data publisher is propagated through the network and can be accessed by the channel subscribers only.

5.1.1 Generating Message Chain

A MAM transaction bundle consists of two sections including (i) Signature, (ii) MAM.

Fig. 8 shows the main components of MAM Transaction Bundle.

The “MAM section” contains the masked message. To post a masked message, MAM deploys Merkle tree-based signature scheme [105] that requires the creation of a root to view the payload. Furthermore, to support forward transaction linking, the MAM section also contains a connecting pointer i.e.,nextRoot and other associated entities that are required for fetching the next payload. The approach to access the payload depends on the channel mode used, for instance, restricted channel mode requires authorization key pairs to encode and decode messages.

For the validity check of the MAM section, data publishers add a signature in the MAM bundle and store it in the signature Message Fragment(sMF) of the transaction. Such transactions are stored in “Signature section” of the MAM bundle. A comprehensive working of the MAM protocol is explained in  [106].

5.1.2 Access Control and Provision of Authenticated Data

To control the data accessibility and visibility in the tangle, MAM provides the following channel modes: (i) public: address = root i.e., by using the address of the message, any random user can decode it, (ii) private: address = hash(root) i.e., the hash of the Merkle root is used as the address, thus, preventing random users from deciphering message as they are unable to derive the root from the hash, and (iii) restricted: address = hash(root) + authorization key i.e., the hash of the authorization key and the Merkle root is used as address, thereby allowing only authorized parties to read and reconstruct the data stream. Changing the authorization key results in revoking permission to access the data without requiring the data publisher to change its $Channel_{ID}$. It is important to note that considering the confidential trade flow requirements of the SC players, we prefer the use of restricted channel mode of MAM. Furthermore, to enforce the ownership of the channel, signature validation is performed upon message reception to authenticate the source of the message or in other words to validate the ownership of the publisher. Failure to signature verification results in an invalid message.

5.2 Provenance in ESC

In this subsection, we provide a detailed description of the proposed provenance-based SC framework.

5.2.1 Seed Generation

To initiate the communication process based on the address and private key requires a seed. A seed is more like a private key and consists of 81 characters including upper case alphabets and digit 9. The seed generation process uses environmental noise (for example, device drivers, network packet timing, etc.) as an input to a Cryptographic Secure Pseudorandom Number Generator (CSPRNG), to produce random seed values.

5.2.2 Setting Security Level, Channel Mode, and Key Generation

IOTA has defined three security levels: 1 (low), 2 (medium), or 3 (high). The default security level is 2; however, we use the recommended security level 3. To keep the communication confidential, we set the channel mode as “restricted” so that the authorized parties can access the data based on shared authorization key pairs. $\mathcal{K}$ is used to encrypt and decrypt the payload by a sender and receiver entities, respectively. The cryptographic keys can be shared among the participating parties by using any of the existing key exchange technique, for instance, Elliptic Curve Cryptosystems (ECDSA [107] or ECDH [108]). However, the existing key exchange systems have an Achilles’ heel due to the not-so-far quantum computing attacks, therefore, a lattice-based public-key cryptosystem Nth Degree Truncated Polynomial Ring (NTRU) [109] must be adopted as it allows to generate and exchange key pairs in a quantum secure way. In our case, we use the NTRU key exchange protocol.

5.2.3 Data Publishing

Each SC player creates a channel $\mathcal{C}$ to publish its data on the tangle. For further details of the payload and its sub-entities, we refer to Section 4.3. Upon selection of channel mode, security level, and authorization key, finally, the MAM transaction bundle is attached ($Payload_{a}$) to the tangle. Algorithm 1 illustrates the steps of data publishing.

5.2.4 Data Receiving

The interested SC players subscribe to the channel to view the published data. The subscribers are able to receive or fetch payload ($Payload_{f}$) based on root and decipher the payload based on $\mathcal{K}$ as presented in Algorithm 2.

Recalling the notion “IOTA for IoT”, it is important to mention that IOTA enables flexible integration of the sensor data ($S_{Data}$) in the tangle. Hence, $S_{Data}$ can be published, fetched, and analyzed following a similar approach as that of data publishing and data receiving. For instance, the consignment information can be acquired by the seller or buyer as shown in Fig. 6.

5.2.5 Collecting and Aggregating Provenance Data

Collecting $P_{Data}$ consists of three steps: (i) fetching payload ($Payload_{f}$), (ii) collecting provenance ($P_{collect}$), and (iii) aggregating provenance ($P_{aggr}$). Firstly, the payload is fetched from the tangle. Secondly, upon fetching the payload, $P_{collect}$ collects the information using key identifiers as mentioned in eq. 3. Thirdly, the collected provenance information is maintained as $P_{aggr}$ along with other granular details (including consignment information, timestamped sensor data, quality control information, etc.). Finally, $P_{aggr}$ is then stored as $P_{Data}$. $\langle Src_{ID}\rangle$ refers to the channel address of the SC player who publishes the data through transaction $Prev_{TID}$. Throughout the chain, $\langle Src_{ID}\rangle$ helps in locating back to the intermediaries and ultimately the originator. Hence, moving to the next channel to collect, and aggregate provenance information is based on $\langle Src_{ID}\rangle$ and $Prev_{TID}$ to obtain the respective transaction. The process of fetching and aggregating provenance continues until the supplier is found. The steps for collecting and aggregating provenance data from the payload are illustrated in Algorithm 3.

In order to explain the fetching and aggregating of $P_{Data}$, let us consider Fig. 9. Suppose that a SC player (customer or analyst) wants to trace back the product journey. Firstly, key identifiers are fetched i.e., $T_{ID}$=SM-G8846, $Product_{ID}$=R39H50JCOA, and $Channel_{ID}$=R_ID: SK_SEL679 from the Retailer channel. Secondly, fetched data and auxiliary data are aggregated and collected in $P_{Data}$. Thirdly, based on the $\langle Src_{ID}\rangle$=SK_SEL002 and $Prev_{TID}$=SM-G4993, the provenance information (for instance, $Pack_{ID}$= SKGIHP001), is then fetched from next Warehouse channel such that $Prev_{TID}$ equals $T_{ID}$. Similarly, following $Prev_{TID}$=SM-S7850 and $\langle Src_{ID}\rangle$=M_ID: SK_PYE001 the information related to batch $B_{ID}$, model# and make is obtained from Manufacturing Unit channel. Here we can see that the batches holding components may arrive from different suppliers located in different countries. Hence, based on $T_{ID}$=SM-S7850, $B_{ID}$=SKPYEL01D and $C_{ID}$=SKPYE100A information are obtained. Also $\langle Src_{ID}\rangle$=S_ID: SK_GIH003 is used to reach the respective Supplier channel. Since $\langle Src_{ID}\rangle$=NULL, therefore, no further $channel_{ID}$ is required to fetch more information. It is important to note that the additional information can be collected and aggregated from $T_{Data}$, $A_{Data}$, and $S_{Data}$ based on the user’s query (Step 7). The query results also depend on access privileges defined by the SC players. Furthermore, the data can be fetched from any channel by any of the participating entities at any instant of time by using provenance key identifiers.

6 Performance Evaluation

In this section, we evaluate the proposed IOTA-based provenance scheme for SC. Overall, we consider 4 IOTA operations including (i) create, (ii) PoW, (iii) attach the payload to the tangle, and (iv) fetch payload from the tangle. Among these operations, we focus on attaching and fetching latency metrics. We also analyze the security of the proposed scheme with respect to SC requirements.

6.1 Simulation Setup

6.1.1 Hardware

To evaluate the performance of the proposed scheme, we use a desktop machine and a Raspberry Pi 3B. The summary of hardware specifications for the test environment is shown in Table 3.

6.1.2 Software

To evaluate IOTA operations, we use JavaScript and compile it for the considered target platforms. Both target platforms are running Linux operating system (Ubuntu 16.04 LTS). For operations including creating payload, attaching payload to the tangle, and fetching payload from the tangle, we use the current implementation of MAM protocol. We evaluate the proposed scheme for security level 3. For local PoW, we use CCurl111https://github.com/iotaledger/ccurl library developed and maintained by the IOTA Foundation. For local PoW, we use a PoW proxy server that acts as a dedicated proxy server to perform PoW for the targeted node. We also use a remote node selected from the available IOTA nodes list which is responsible for carrying out PoW on behalf of the targeted node.

6.2 Evaluation Metrics

We put emphasis on the latency metric for the evaluation of IOTA operations. Each experiment is evaluated 100 times for security level 3. To represent the data distribution, we choose violin graph [111] that befits our representation requirements of the results. The violin graph indicates median (a white dot), quartiles (thick black bar) with whiskers reaching up to 1.5 times the inter-quartile range (thin black bar), and kernel probability density (colored area) that shows the distribution shape of data. With reference to the proposed scheme, parameters of the violin graph can be interpreted as follows: median represents the central value for performing IOTA operations (including creating, attaching, and fetching) whereas quartiles represent the overall range of data while performing IOTA operations. Starting with payload creation, Fig. 10 shows that the time required to create the payload is almost negligible. However, it is observed that for payload size 900 the distribution of data is different in comparison to others. The reason for such different behavior is particularly because of the creation of the bundle. In addition, if the payload size increases more than 2187 trytes (1300 characters) additional transactions in the bundle are required.

Next, we analyze the process of attaching payload to the tangle, fetching payload from the tangle, and PoW (local and remote) due to the fact that such IOTA operations have significant time delays in comparison to creating payload.

It is important to note that the attach phase corresponds to $Payload_{a}$ (attaching payload (consisting of $T_{Data}$ and $A_{Data}$)) while the fetch phase corresponds to $Payload_{f}$ (fetching payload) from which $P_{Data}$ can be constructed. Depending on the query criteria and access privileges defined on the basis of channel splitting, $P_{Data}$ can be constructed. For simplicity, we consider that the query acquires every possible detail (i.e., entire payload) during the fetch phase based on which the provenance information can be derived upon the request of participating and non-participating entities.

Keeping in view the above-mentioned definitions of attaching and fetching data, firstly, we perform the attaching and fetching of payload (shown in Fig. 11) by relying on a remote node and secondly, we perform the attaching and fetching of payload (shown in Fig. 12) by using a local node. In either of the cases, it is observed that the attaching process consumes more time in comparison to the fetching process. Both the attaching and fetching phases are independent of the payload size ranging from 100 to 900 characters. Similarly, we compare the attach and fetch process with respect to remote and local nodes. Figure 13 shows that relying on a remote node to perform PoW incurs time delays and hence consumes time, whereas, local PoW does not incur much delays. In particular, Fig. 13 represents the distribution of data for performing IOTA operations remotely and locally such that the median value for attaching payload is around 17 sec and 12 sec respectively, while the median value for fetching data is around 2 sec and 1 sec respectively.

Similarly, to simulate the proposed scheme on an IoT platform, we use Raspberry Pi 3B. On this platform, we consider attaching and fetching process in terms of time and energy constraints. In order to include sensor data, we use the Digital Humidity Temperature sensor (DHT11). We assume that any other sensor data can be integrated in a similar way to attach and fetch sensor data to/from the tangle, respectively. Firstly, we compute the average time required to attach and fetch payload (including sensor data) to and from the tangle, respectively (shown in Fig. 14). In particular, Fig. 15 represents the distribution of data for performing IOTA operations remote such that the median value for attaching payload is around 20 sec while the median value for fetching data is around 2 sec.

Secondly, we compute the energy consumption by CPU. Out of 4 cores of Raspberry Pi 3B, a single core (power consumption= 221.0 mW per core) is utilized for attaching and fetching data. The measured average time and energy consumption (evaluated 100 times for security level 3) are given in Table 4. It is important to mention that we only consider Raspberry Pi 3B as a light node with the Minimum Weight Magnitude (MWM) parameter set to 14; where MWM is the PoW complexity currently used in the IOTA mainnnet. Thirdly, we compute the CPU and memory consumption during attaching and fetching phases. Irrespective of payload size, the fetching process consumes more CPU and memory (as shown in Fig. 16). Since during fetching operation, tasks are carried out by Raspberry Pi 3B itself rather than the remote node, hence, it consumes more CPU and memory.

6.3 Informal Security Analysis

In this subsection, we revisit the security claims mentioned in Section 4.5 and justify them to evaluate the performance of our proposed provenance-based scheme for ESC.

Claim 1: Data confidentiality.

Justification: The data is stored on the channel in encrypted form. Hence, only those $D_{r}$ having access to the $Channel_{ID}$ and authorization key ($\mathcal{K}$) can obtain and decrypt the payload.

Claim 2: Access control rights.

Justification: MAM channel enables the off-shooting channel (as shown in Fig. 17) particularly when the entirety of data is not intended to be shared. Such fine-grained access to data is desired in many scenarios in ESC. For example, the retailer may share the sales data or customer buying pattern data with the marketing companies while preserving the customer Personally Identifiable Information (PII). Similarly, the idea of channel splitting can also be used to limit access to a company’s trade secrets from joint ventures, suppliers, distributors, or customers. Another significant use-case example scenario is when a company is buying some of its product’s components from its competitor company. Defining access rights (i.e., grant and revoke) on data is based on an authorization key ($\mathcal{K}$) used in the restricted mode. The key is exchanged with the legitimate SC players only and can be changed to revoke access rights without any need to change the $Channel_{ID}$. The other modes provided by MAM channel includes public and private. Further details related to the MAM channel are provided in Section 5.1.

To illustrate the process of fine-grained access through channel splitting, let us consider a scenario. Suppose, a seller $S_{1}$ (SID: SK_GIH003) is selling components (for instance, DRAM chips) to a buyer $B_{3}$. $S_{1}$, also outsources its components to one of its partner sub-seller $S_{sub}$ (SID: CN_SHE005) who further sells components to other buyers $B_{1}$ and $B_{2}$. $S_{1}$ and $S_{sub}$ define access control rights for their buyers so that they are able to retrieve the required information from them. The information, in particular, can be generalized as $T_{Data}$, $A_{Data}$, $Sales_{info}$ (showing sales pattern), $Client_{info}$ (list of clients), $Manufacturing_{info}$ (manufacturing process), $Advertising_{info}$ (advertising strategies). The defined policies and a few example queries are discussed in Table 5. The query results can be retrieved on the basis of provenance key elements.

Claim 3: Restrictions on data retrieval.

Justification: To enforce a restriction on previous data in the message chain, we exploit forward secrecy, i.e., the subscriber can only locate and retrieve transactions at or after their point of entry in the channel, but not before their point of entry (as shown in Fig. 18). Upon locating the transaction $t_{n}$, the subscriber can retrieve the address of the next transaction $t_{n+1}$ (as shown in Fig. 18). When the masked message of one generation is decrypted, unmasked message contains nextRoot that is used for viewers to find the message of the next generation of the channel.

Claim 4: Preserving data integrity during trade events.

Justification: Sensor tampering or data modification may occur during data creation or data transit phase thereby causing the GIGO problem. For example, in our SC case, the sensor can be tampered to change the readings leading to false data creation or the sensor data can be maliciously altered during communication. To address the former problem, we can rely on any of the existing solutions such as the use of Physical Unclonable Functions (PUF) provided in [112]. For the latter problem, we employed the MAM channel restricted mode for secure communication. Furthermore, it is assumed that IoT sensors are calibrated periodically. Another concern is how to ensure that a rogue participating entity is not corrupting the data? Some of the following solutions in the literature can be leveraged to solve this issue. A rating system for buyers and sellers based on previous trade events can be used. For instance, in [113], the authors used a reputation-based trading system which allows high reputations sellers to access better offers from the buyers. Another such solution is proposed in [114, 115] to enable monetary punishment mechanism to discourage any malicious changes in data or revoking trader’s participation in the SC based on trust evaluation [116]. Though all of the above solutions are proposed in combination with the blockchain ledger; however, they can be incorporated into the IOTA through oracles on the top (i.e., the concept of smart contracts in IOTA is underway [117, 118]).

To eliminate the GIGO problem in our proposed scheme, we adopted a combination of the below-mentioned solutions to mitigate the effect of adulteration. Firstly, we include product traceability through provenance data at each intermediate step in SC processes. Secondly, the inclusion of the warranty parameter can also help in establishing trust among entities in the long run. Thirdly, the verification of the transactions by both buyer and supplier can also confirm any fraudulent activity, for instance, $Receipt$ transaction in our proposed solution. Finally, the attacker can not repudiate once found guilty (claim 5). It is also worth noting that the adversary in a permissioned ledger requires consideration of many other possible security scenarios (for instance, attacks by an internal or external adversary, colluding users, etc.) and is out of the scope of this paper.

Claim 5: Non-repudiation.

Justification: To handle repudiation of trade events by any of the participating entities, transactions on the IOTA ledger ensure the immutability of data, the existence of SC events, and associated data carried out by the particular entity.

6.4 Outstanding Issues and Challenges in IOTA Ledger

Analogous to the blockchain, IOTA also faces security and stability issues. Currently, IOTA is relying on a coordinator COO for consensus that is responsible for the continuous generation of trust-able transactions to help to secure the infant tangle network from a double-spending attack. The two main problems arise due to the presence of COO include (i) single point of attack that can paralyze the whole tangle if COO stops working or taken over, and (ii) curtailing scalability of IOTA. However, to optimize the designed system, Coo-less IRI (CLIRI) [119] is recently introduced which is considered to be an important step towards the maturity of IOTA protocol, thereby making it a permissionless and scalable DLT. znet is also launched as the first iteration of the coordinator-less testnet [120]. Hence, research is still ongoing on key improvement areas that would allow the desired decentralization. Keeping in mind the compatibility requirements for IOTA, we assume that the proposed scheme will be compatible with any up-gradation in the IOTA or the application layer MAM protocol.

Similar to the forking problem in blockchain, tangle also suffers from parasite chains in which an attacker makes a side tangle to double-spend the money. This problem can also be referred to as double-spending attack [121] discussed in detail in [12]. Though according to IOTA paper, parasite chain attack can be prevented when nodes use the MCMC tip selection strategy under the assumption that the main tangle has more hashing power than the attacker. However, as opposed to the assumption, attack analysis is still under discussion by the community [122]. In the literature, [123] suggested a solution to simulate against parasite attack by proposing the matrix model for the MCMC tip selection algorithm.

For highly energy-constrained IoT devices (such as battery-powered) performing computationally expensive tasks is not practically possible without hardware-accelerated cryptography. Nevertheless, powerful devices such as Raspberry Pi are still capable of doing IOTA operations as light node [89].

Another important issue is the staggering amount of transactions received by IOTA nodes which off course results in ever-increasing memory and CPU requirements. To combat this situation, a snapshot is performed to either reduce the size of the tangle or to reduce the burden on memory-constrained nodes. A snapshot essentially throws away all the transaction history and resets the IOTA ledger to a list of all the addresses that have a nonzero balance. Therefore, such a global snapshot prunes the database to create room for newer transactions. It is hard for node owners with limited storage (IoT devices), to store full transaction history. To handle such situations, a local snapshot feature can be used that allows node owners to delete old transactions and keep their tangle database small. This option facilitates faster synchronization, lower resource requirements, and eliminates the need to wait for global snapshots [124]. For many scenarios, data needs to be stored for an extensive period of time. In order to deal with such use cases, the IOTA Foundation provides a permanode solution called Chronicles [125]. This solution, enables node owners to have unbounded storage of the tangle’s entire history and makes it accessible at scale. In the context of SC, both permanode solution and local snapshot can be used depending on the situation and requirements. For instance, in the case of resource-constrained devices, local snapshot can be adopted, however, in the case of the SC process, permanode solution can be adopted. Such features can be incorporated into our proposed work upon finalizing these features by IOTA Foundation.

In this proposed framework, we adopt a 2-tier approach to orchestrate provenance in the ESC. In the first tier, we collect SC data flowing across each SC participant, store securely in a distributed IOTA ledger, and manage data access rights. In the second tier, we construct provenance data to trace and track the product journey at each intermediate step in the SC cycle. Such a 2-tier approach provides an optimal strategy to carry out SC processes. For example, the first tier resolves the problems of fragmented data repositories and enables the SC participants to hide their trade secrets by defining data access rights while the second tier resolves the problems of identification of counterfeit products and helps in achieving customer’s trust.

7 Conclusion and Future Research Directions

In this paper, we target two key issues, i.e., disparate data repositories, and untrustworthy data disseminating in the electronics supply chain space. To address these obstacles, we employ IOTA permissioned ledger that uses MAM protocol at the application layer to allow distributed and trustworthy data accessible to only authorized SC players. By exploiting the MAM channel, the data publishers share their data securely while allowing the authorized data receivers to access it. Therefore, it is feasible to construct the product provenance story through trustworthy sources and immutable data streams flowing across the global supply chain. In addition to the construction of secure provenance information, we also measure the energy consumption by the Raspberry Pi 3B IoT-based platform to ensure the suitability of the proposed scheme on resource-constrained devices.

For future work, we plan to survey other existing DLTs and compare them with IOTA in terms of performance (scalability, latency, and throughput) and device resource usage (CPU, memory, and energy consumption). Depending on the infrastructure, different types of sensors are deployed in different SC application areas. Therefore, we also want to port the proposed provenance-enabled SC system to other ARM-based devices to evaluate their compatibility across different platforms. As discussed in Subsection 6.3 (Claim 4), evaluating traders in SC based on the mechanism of trust scores to facilitate honest buyers and sellers is also part of our forthcoming research. From the perspective of SC management, introducing trade finance process to replace traditional finance procedures and risk management (for example, environmental risks) are other potential extensions of our proposed scheme. Regarding the applicability of the proposed approach, SC data can be monetized to allow other business communities to learn and analyze the current industry trends and traits. This involves the integration of the current hyped technologies such as Artificial Intelligence (AI) and Machine Learning (ML). For this purpose, querying data can be customized based on access privileges or anonymization techniques. Such information can also help in studying forecasting future events to avoid inaccuracies and ultimately take possible measures against the bullwhip effect. Lastly, addressing challenges (such as real-time performance, coexistence, and interoperability) associated with IIoT, impacting the proposed SC system are among other interesting areas that are required to be explored.