A Blockchain-Based Framework for Supply Chain Provenance

The complexity of the electronics supply chain has grown significantly due to the expansion of globalization in the 21st century. Electronic parts are now manufactured, distributed, and sold globally. Ensuring the security and integrity of the supply chain has become extremely challenging due to the widespread infiltration of untrusted hardware, specifically, counterfeit and cloned parts. Especially, the provenance of microelectronics and commercial off-the-shelf (COTS) parts becomes prohibitively difficult to track and calls for immediate solutions. In this paper, we present a non-destructive way of ensuring the traceability of electronic parts in the supply chain. We have implemented a blockchain-based framework, which helps to track and trace every chip while they are circulating in the supply chain. The proposed framework is built upon a permissioned blockchain. Hyperledger is used for implementing this framework. A detailed analysis is carried out to present the feasibility of our proposed approach.


I. INTRODUCTION
Due to the rise of globalization, it is now extremely challenging to ensure the security and integrity of the electronics supply chain.Numerous reports pointed out the widespread infiltration of counterfeit integrated circuits (ICs) in our critical infrastructures.The majority of these reports highlights ICs that are reclaimed from the used and discarded electronic waste, and are commonly known as recycled ICs [1].Information Handling Services reported that the potential annual risk of the global supply chain from counterfeiting is at $169 billion and increasing [2].As the operational life of our critical infrastructures (e.g., various defense and aerospace systems) are much longer than the life of electronic parts, it is necessary to obtain obsolete parts, which are no longer in production by the original component manufacturers (OCMs), from untrusted third party suppliers who are often located offshore [3], [4].In addition, cloned parts are also on the rise [5]- [7].Recently, the groundbreaking hardware hack on the supply chain, introduced by Bloomberg in October 2018, actually sets off an alarm [8].The article reported an example of a state sponsored vulnerability accomplished through the insertion of a tiny microchip, not much bigger than a grain of rice, that wasn't part of the boards' original design.According to the article, investigators determined that the chips allowed the attackers to create a stealth doorway into any network that included the altered machines.By compromising the supply chain, adversaries could effect well-known top United States companies and government services.
Aiming to address and respond to the supply chain security problems, the U.S. Department of Defense (DoD) has introduced a new supply chain risk management strategy named "Deliver Uncompromised" [9] which aims to secure and ensure the deliveries of military and government supply chains.In addition, the National Institute of Standards and Technology (NIST) also updated their cyber security framework with new supply chain security definitions and policies [10] where a supply chain management category has been added into the framework core.However, while some criteria and policies are established, the real world implementation and practice are still in infancy and evolving.

A. CONTRIBUTIONS
The detection of a compromised device is extremely challenging as there are a wide variety of parts with different resources already in the supply chain.Finding a one-size-fitsall solution is our primary objective such that the majority of devices can be authenticated using this single solution.Ensuring the security of the supply chain requires the authenticity for all parts, which can be guaranteed if we can track the parts through trusted suppliers back to their true origin.To an extent, some level of protection exists today that addresses the detection of counterfeit and cloned devices, however, a complete solution for the traceabilty of a part in the supply chain is yet to be developed.In this paper, we propose to use blockchain technology to ensure the security and integrity of the supply chain by enabling traceability of electronic parts.In our design, blockchain and smart contracts enable the reliable traceability and verification for parts, while they travel in the supply chain.A "smart contract" is a computer protocol intended to digitally facilitate, verify, or enforce the negotiation or performance of a contract.Smart contracts allow the performance of credible transactions without third parties.These transactions are trackable and irreversible.In addition, a smart contract is used more specifically in the general purpose computation that takes place on a blockchain using cryptographic hash chains.The major contributions of this paper are summarized as follows: • We proposed a novel architecture, which uses a lowcost blockchain instance for providing traceability of electronic parts or devices.The traceability is ensured using a unique device ID, which can be programmed into the device using one-time programmable memory (commonly known as electronic chip ID or ECID [11]), or a unique identification can be obtained for a physically unclonable function (PUF) [12]- [16].The detection of counterfeit ICs (primarily the recycled ones) can be ensured using ECID, while PUFs can provide protection against cloning.The origin of a device, the trace of travel in the supply chain, and its bill of materials can be accurately tracked, and this solution can used for verifying its authenticity.A simple query to the blockchain will show all the necessary information for such a purpose.• To the best of our knowledge, our proposed blockchainbased framework is the first approach that comprehensively addresses in-transit thefts, human errors, delivery and management failures, and dishonest entities in the supply chain in a comprehensive way.Note that a device ownership transfer generally can be triggered and controlled by device owners in any traditional blockchainbased solutions.Wrong electronic parts could accidentally be sent, which leads to the inappropriate ownership transfer.Logistic and transportation could be delayed or failed due to external causes (e.g., weather, natural disasters, etc.), the receiver of a part may cancel the original order even when the ownership of a part have already been transferred in the blockchain.Parts could also be stolen by adversaries during the transportation.Note that these stolen parts are still valid since ownerships are already transferred to a trusted participant in the blockchain.Moreover, a receiver of parts can deny the transfer or acceptance of part after the ownership transfer is completed.Therefore, directly transferring the ownership within one transaction creates irreversible results in the traditional blockchainbased systems, which could cause further security and management risks.To address these aforementioned threats, we propose a confirmation-based ownership transfer in our blockchain-based framework for enabling device traceability.In this proposed framework, a twotransaction-based ownership management is proposed.
After the ownership transfer transaction has been sent by the sender, an additional confirmation transaction from the receiver is required.The ownership transfer will be completed once the mutual agreement between sender and receiver is reached.This will automatically tag the items, which are missing during the transportation, human errors, and delivery failures.• We implemented a prototype system to demonstrate the feasibility of our proposed approach.A permissioned blockchain (Hyperledger Fabric [17]) is used along with a non-resource intensive consensus algorithm, where most of the previous works were implemented via Proof of Work (PoW) based permissionless blockchain (e.g., Ethereum).The features of consortium blockchain and Hyperledger eliminate the cost of a transaction fee and improve the efficiency by using a non-resource intensive consensus algorithm.

B. RELATED WORK
A significant amount of research has been directed to ensure the security and integrity of the supply chain by the efficient detection and avoidance of counterfeit ICs [1], [18]- [30].The approaches can be categorized into different categories -(i) standards [18], [31]- [33], (ii) statistical data analysis [22]- [25], [34], [35], (iii) on-chip sensors and structures [27]- [29], [36]- [39] and (iv) unique markers [40].Even though these solutions can provide some levels of detection of counterfeit ICs, none of them can provide the traceability information, such as the origin, manufacturer, bill of materials, and travel trace in the supply chain.The integration of blockchain and supply chain receive widespread attention, since the inherent properties and features of blockchain could significantly enhance the traceability, transparency, and reliability of the supply chain [41], [42].Some researchers discussed, proposed, and analyzed various blockchain based frameworks to refine the traceability for supply chain [43]- [52].By leveraging the blockchain, the traceability of food [44], [47], [51], healthcare [48], [52] and post delivery supply chain [43] could be enhanced.Contrary to the traditional blockchain-based tracking (e.g., food and healthcare products), electronic devices possess an advantage of integrating unclonable ID, which can be generated from a PUF embedded into the device, and thus can enable efficient and low-cost tracking (e.g., registration, verification, and status update).
The authors in [53] introduced a blockchain-based framework, which ensures the authenticity of electronics with the help of an unclonable ID generated from a SRAMbased PUF.Xu et al. provided a comprehensive solution and summary for using blockchain to improve and secure the integrity of electronic supply chain [54].However, these two solutions do not provide detailed traceability and ownership information for a device.Islam et al. proposed a method that uses PUF and blockchain to enhance authenticity and traceability of parts in the supply chain [55].However, the device ownership transfer is simply triggered and controlled by device owners.This design may lead to potential security issues.Human errors, delivery and management failures, intransit thefts, and dishonest participants are still threatening supply chain even with implementation of blockchain for tracking [56].
Note that blockchain was first introduced by Bitcoin [57] and is now widely used by the cryptocurrencies.Blockchain is known as a distributed and shared digital ledger, where all the transactions and records are hashed and stored in the chain to provide both integrity and transparency.Certain blockchains also support the smart contract [17], [58] which allows the user to run Turing-complete scripts on the chain.Using a smart contract (also known as chaincode in Hyperledger) enables the user to store and manage data inside of the blockchain, various of applications such as Filecoins [59] and Storj [60] have been proposed.

C. ORGANIZATION
The rest of the paper is organized as follows: we introduce our proposed novel blockchain-based framework in Section II.The implementation details are described in Section III.The analysis of our design are performed in Section IV.Finally, we conclude our paper in Section V.

II. PROPOSED BLOCKCHAIN-BASED FRAMEWORK FOR SUPPLY CHAIN PROVENANCE
Ensuring traceability for devices is critical for providing trust among different entities in the electronics supply chain.This section presents a blockchain-based framework to allow an entity to track electronic devices.Figure 1 describes a simplified version of the supply chain, which consists of five different types of entities -design authority, contract manufacturer, distributor, end user/customer, and adversary.The raw material and logistics service providers are omitted in this model for simplicity.Even our simplified model demonstrates the complexities of the supply chain with a limitless number of possibilities for an adversary to introduce their compromised product.Note that, a design authority (DA) can be described as entity in the supply chain who owns the intellectual property (IP) of a design and could produce the device or assembly or have their product produced by a contract manufacturer.Many of the DAs of microelectronic devices do not own a manufacturing plant (foundry or fab) and outsource the fabrication to contract manufacturers due to the prohibitively high-cost of building and maintaining a foundry [61].Once the chips are fabricated from a foundry, two possible distribution scenarios may occur -(i) the design authority could ask the contract manufacturer to send back all the parts, and distribute them by itself, or (ii) the contract manufacturer directly sends the parts to the customer or DA authorized distributors.Note that, many of the distributors in the supply chain may not be authorized by the design authority to distribute their parts.Distributors that are not authorized by the design authority are often called Independent Distributors or Brokers.
Figure 1 shows an abstract view of the electronics supply chain that consists of a design authority (DA), a contract manufacturer (CM ), several distributors (D 1−n ), an end user/customer (C), and an adversary (A).We generally treat the design authority, contract manufacturer, and the customer as trusted and highlighted in green.The distributors can be of both (trusted and untrusted) types and highlighted in light brown, whereas the adversaries are always untrusted and highlighted in red.The adversary A can make cloned devices, or can integrate counterfeit (recycled) devices or tampered devices with hardware Trojans or malware into the supply chain.To address this problem, it is necessary for the customer C to track the origin and the trace of the devices travelled in the supply chain.It is absolutely necessary to develop a framework that can provide the traceability, in which the trace of legitimate devices (CM We propose to use a blockchain-based architecture to provide a comprehensive, persistent and reliable device tracking and verification service for different manufacturers, distributors and customers.By using blockchain, all the entities will be able to securely record the device ownership trans-

A. CONSORTIUM-BASED BLOCKCHAIN
Generally, consortium blockchain is a permissoned blockchain formed by a group of known and verified members.The consortium blockchain (e.g., Hyperledger) eliminates the cost of a transaction fee and improves the efficiency by using a non-resource intensive consensus algorithm.As a result, a consortium blockchain could minimize the cost of the daily operations in the supply chain, which is ideal for building a supply chain tracking system.In this blockchain based system, design authority, contract manufacturers, and distributors are the major members of blockchain and they have to be registered as "nodes" in blockchain.Each of the nodes must create and maintain an identity (i.e., address, account or a participant identity) in the system.Any addition (new member), replacement or duplication of identities must be notified to and accepted by all the major members identified in the chain.The major members could be notified based on a buyer/seller transaction or a more broad based notification system based on the security needs of the transaction.A customer could also be registered with an identity in the blockchain.In such way, the post-sale traces could be recorded in the blockchain as well.If the customer is not registered in the blockchain infrastructure, any redistribution of the devices confronts risks the security since the re-distribution procedure is not officially certificated and protected by the provenance system.
On the other hand, the underlying functionalities that provide the actual data storage and management are implemented by smart contract or chaincode.The smart contract or the chaincode needs to be internally advertised and dis-tributed, and all the entities have to install the scripts locally.The creation, maintenance and deprecation of the scripts need to be verified by all the major members identified in the chain.This procedure could be performed on-chain or offchain.One blockchain could run multiple smart contracts to maintain and manage different types of devices.

B. INITIALIZATION AND REGISTRATION OF DEVICE
The design authority and contract manufacturers could register devices type (i.e., electronic device types) on the chain.Each type of device needs to be registered separately in the blockchain.This could be achieved by using smart contracts.The creation and registration of these device types are written into the blockchain and are visible to all the members downstream in the chain and by those major members identified upstream who require notification.Note that, only the design authority and contract manufacturers could register the device types in the blockchain system.Any other participants like distributors and customers could not register the device type in the system due to the defined blockchain policy.
Once the device types are registered in the blockchain, the design authority or contract manufacturer needs to register the devices manufactured from the production line.For traceability purposes, a unique device ID is necessary, which can be easily constructed by integrating an ECID, PUF or a unique identification to the device.Instead of placing the ID directly to blockchain, we propose to store the hash of the ID.This provides an additional security as it prevents one to determine the original ID unless he/she actually possesses the device.For each device, design authority or contract manufacturer needs to upload the hash of the ID into the blockchain (e.g., stored in an array in the smart contract).All the uploaded hashes and the number of the entries are known by all the members, however, since the IDs are hashed, none of the actual IDs would be leaked.In addition, the same logic applies with the device type registration; only the design authority and contract manufacturer producing the devices are allowed to register the devices into the blockchain.
Let us now consider an example, suppose contract manufacturer (CM ) registers device type H in the blockchain, it can then upload the same type of devices produced from a manufacturing unit.If it wants to register N devices, it need to compute N hashed IDs and upload into the chain under device type H.Note that it cannot upload any device ID except for this device type.However, it can register another device type under class K and upload K-type devices into the chain.This procedure is depicted in the Figure 3.The registration procedure relies on the implementation of smart contracts, and all the data of the contracts are stored in the blockchain ledger.

C. TRANSACTION FOR DEVICE TRANSFER
To ensure traceability, it is required to record the transfer of an device among different entities in the supply chain.This can easily be implemented in our proposed blockchain-based framework shown in Figure 3. Initially, there are N copies of device type H stored in the blockchain.If the contract manufacturer CM decides to send N 1 copies of device H to Distributor D 1 , a specific device transfer transaction needs to be sent, including the data of the devices.In addition, a smart contract/chaincode would be triggered by this transfer transaction to perform further processing (change the data stored in the blockchain).Besides the normal fields of the transaction (details varies on different blockchain platforms), the transaction for a device transfer may need four additional elements in the payload: the device type that is being transferred, the amount of a device, the identifiers (IDs) of the devices, and the new owner of the device.As shown in the Figure 3, contract manufacturer CM sends a device transfer transaction with additional data (H, N 1 , ID 1 , D 1 ) which represent N 1 of H with device ID 1 would be transferred to Distributor D 1 (N 1 ≤ N ).Note that, for transferring N 1 entries in the blockchain, depending on the implementation, the transaction could be N 1 transactions, and each of them contains one hashed ID, or only one transaction (or several) contains all the hashed IDs.
Generally, design authority, contract manufacturers, and distributors are allowed to initiate transactions for the device transfer, as long as they own a certain amount of devices.However, the actual ownership of the device that is declared to be transferred in the device transfer transaction would not be transferred to the new owner until a confirmation transaction is received.The primary reasons for receiving an additional confirmation transaction from the receiver of the device (devices) are the following.First, the receiver of an device must acknowledge the number of received items, such that every device is accounted for.The receiver needs to compare the hash of the device IDs with the hash stored in the chain.If any mismatch is found, the transaction will be cancelled due to this compromised device.Appropriate parties in the chain will be notified to take appropriate actions when there are mismatches.Second, the receiver cannot deny the acceptance of the delivered shipment.Without the confirmation, none of the devices in the shipment is recorded as legitimate transferred in the blockchain.Finally, one can easily track missing devices that never reach the receiver.This could be helpful if an adversary intercepts the shipment and stole devices during the transit.

D. TRANSACTION FOR DEVICE TRANSFER CONFIRMATION
Upon receiving a specific number of electronic devices from an entity (e.g., a manufacturer or a distributor), the new owner of the device needs to send out the confirmation transaction.A device transfer is not completed and verified until a confirmation of the transfer has been made.The trace and the ownership of the device would be transferred in the smart contract only after the confirmation.
Figure 3 shows the detailed process of how a transaction is first created, then validated, and finally added to the blockchain.At step  Note that, in this system, the smart contract keeps track of the unconfirmed device transfer transaction.Only the valid receivers (that have unconfirmed transfers) could initiate the confirmation transactions.In addition, the time-to-live of the device transfer could be enabled to define the expiration time of the transfer.When a transfer is accidentally created, or the receiver node is failed, the transfer transaction could be set to automatically expire after a certain period of time.

E. VERIFICATION AND TRACKING
Whenever a participant physically receives a device, it is required to verify its identity (ID) which is present (hashed) in the blockchain.The verification procedure requires the retrieval of the unique device ID, which can be accessed by using JTAG interface [62] or other unique identification methods that are tamper proof.One could verify the hashed device ID with the hashed ID records stored in the blockchain through the blockchain query functions (details are described in Section III-B).The original manufacturer, current owner, and other major members identified for the chain could be alerted with information that includes historical traces of the device as a result of this query.If the ID does not exist in the system, a flag will be raised and the device will be identified as suspicious.Note that, the verification and tracking procedure do not alter the data stored in the blockchain, thus no actual transaction would be made and the entire procedure is highly efficient.

F. MINING IN PROPOSED PROVENANCE SYSTEM
Regardless which consensus algorithm would be applied in the blockchain-based framework, one of the most crucial configuration set ups is to decide the miners.Mining, in the context of blockchain technology, is the process of adding transactions to the ledger of existing transactions, known as the blockchain.According to the design and the purpose of the system, all the major members (manufacturers and distributors) of the blockchain are permissioned and known.It is reasonable and reliable to adopt all the major members to be valid and potential miners (endorsers).

III. IMPLEMENTATION DETAILS
As Hyperledger Fabric is becoming one of the most promising and successful blockchain platforms, it is our selection of framework.Hyperledger Fabric is introduced and maintained by IBM [17].The native permissioned architecture and non-resource intensive consensus mechanism of Hyperledger perfectly matches the requirements of implementing the proposed blockchain.

A. BLOCKCHAIN NETWORK MODEL
The Hyperledger blockchain network model which includes the underlying data structures used in our proposed implementation is shown in Figure 4.The type entity defines the blockchain participants with corresponding attribute (e.g., design authority, contract manufacturer, distributor, and customer).An type deviceTypes is created to define the types of devices, which needs to be and can only be registered by the design authority and contract manufacturer.These device types represent different types of devices already circulating in the supply chain.For example, Intel Pentium processor can be a device type.In order to avoid a device to be sent multiple times before its confirmation has been made, an enum transferStatus declares the transfer status of the device (e.g., NOT_IN_TRANSFER, IN_TRANSFER).This status attribute helps to identify whether a device is available for transfer.The type device consists of following attributes: device ID, device type, transfer status, receiver of the transfer (if exist), original manufacturer, current owner and device traces.Finally, four functions register, transfer, confirmation and query are defined.The detailed transaction processing functions are introduced in the following section (Section III-B).Note that, the type entity should be maintained by the blockchain admin in the chaincode, so that the participants are regulated permissioned to access the chaincode.

B. CHAINCODE IMPLEMENTATION
The registration of devices and device types are carried out by the register function, which is described in Algorithm 1.
The register function requires three arguments: a registration flag, a device type, and a device ID.First, the function checks that whether the caller is valid DA or CM, if the check fails, an error message is returned.If the flag is set to 0, it means the call is for device type registration.The function would then create a device type and verify that it has not been registered in chain, and finally store it into blockchain.On the other hand, if flag is set to 1, this function would create and initialize a device data record in blockchain with provided device type and hashed device ID.If the flag is set to some other values, the function returns error.Algorithm 2 illustrates deviceTransfer() function, which is used to transfer devices.The function first retrieves the device data record from blockchain.If the current transfer transaction sender is not the owner of the device, the function fails.Then the function checks whether the device is available for transferring, and then updates the status and data.Note that, the transfer function handler only updates the basic information of the device.The actual ownership and the trace of the device would not be updated.This pseudocode only describes the scenario of transferring a single device, and one could easily alter it to transfer certain amount of a particular type of device.In addition, the expiration time could be enabled as an optional feature (introduced in Section II-D), which is omitted in the algorithm.The Algorithm 3 describes Transfer Confirmation Function TransferConfirmation().Given a successful confirmation, the actual ownership of the device would be transferred and the trace of the device would be updated.The function first needs to check the validity of the transaction creator, and then update the data of the device.Note that the failed, partial, and complete transfer confirmation flag (mentioned in Section II-D) could be enabled as an option.
The Algorithm 4 describes the details of tracking and verification function.This function is performed by using the query feature of the Hyperledger system.There are two types of queries: first type is the normal query, as shown in Algorithm 4, which simply returns the data stored in the chaincode with mapped keyword.Another type of query is rich query, which could deeply utilize the underlying mechanism of state database and enables the user to perform SQL-like queries.For instance, one could send a SQL-like query to retrieve all the devices belonging to one distributor.In addition, the query functions could be exposed to the users via API/Webpage (RESTful API [63]).One could trigger the query with the hashed device ID to get the corresponding device information from outside of the infrastructure.Note that, query transactions will not be appended into blockchain, since it only queries the data stored in chaincode without altering it.On the other hand, all the transactions invoked by register, transfer, confirmation functions will be appended into blockchain.A sample transaction details is shown in Figure 5.All the write operations and data stored in blockchain are recorded in transaction history with details.Later query functions will initiate transactions to retrieve the stored data from the chaincode.Moreover, one could also use blockchain explorers (i.e., Hyperledger Explorer [64]) to manually check the transaction details as well.

C. ACCESS CONTROL
In order to regulate and secure the operations in the blockchain system, access policies are needed and created in our prototype infrastructure.Part of the core access control policies of prototype system are depicted in Figure 6.Note that, the policies are enforced in order to give access to the operations, otherwise, operations are denied.The policy R 1 allows all the users to read the resource stored in the blockchain.R 2 grants design authority the access to device records.R 3 allows design authority to create the device.Note that, two similar policies for enabling contract manufacturers to create device type and create device are omitted here.In addition, all the other participants (distributors and users) are not allowed to create a device record, but they could update the device record by using specific transactions.R 4 allows a participant to update a device with device transfer transaction if the participant is the owner of the device.R 5 allows the receiver of a device to update the ownership and quantity in the blockchain once a valid confirmation transaction is received.

D. PERFORMANCE EVALUATION
Note that, hardcore performance evaluation of Hyperledger Fabric platform is not the major objective of this paper.In addition, a number of works have already measured the overall performance of the Hyperledger platform with detailed metrics and comprehensive analysis [65]- [67].The scalability and reliability of Hyperledger Fabric platform have already been proved.Here, we only measure some of the specific performance metrics of the prototype system, such as the latency and throughput of transactions and queries, in order to prove the applicability of our framework.We setup an evaluation environment with 3 machines, each of them equipped with 8 core CPU and 16GB RAM.As depicted in Figure 7, 10 organizations in single channel with CouchDB state databases are created with Hyperledger Fabric 1.4.1 [68] using docker containers [69].The block size is set to 30 with 500ms batch timeout (details related to block size selection can be found in [67], [70]).Hyperledger Caliper [71] is used as the blockchain benchmark tool.The endorsement policy follows the default "N of N" policy , namely, a transaction needs to be endorsed by all 10 organizations.Thus, the complexity of endorsement is provided.Since Raft [72] is adopted as new consensus module in Hyperledger Fabric to replace Kafka [73], 3 RAFT orderers are deployed on these 3 machines.With these configurations, multihost blockchain system, multi-organization communication, and orderer services with fault tolerance are all provided.In addition, one client on machine 1 is created to send the transactions.
As all the register, transfer and confirmation transactions perform both read and write operations on blockchain, we observe similar behaviors for throughput and latency.Thus, they could be combined as read/write (R/W) transactions, and their performance mainly depends on the speed of write operations.On the other hand, query transactions are read only transactions, the performance should be faster than R/W transactions.Both R/W, and query transaction throughput and latency performances within different transaction rate are shown in Figure 8.  Generally, read only query transactions have better performance than the R/W transactions as we expected.However, R/W and query transactions reach the throughput bottleneck at 22 and 25 tps, respectively.Before the transaction rate exceeds the throughput bottleneck, transactions can be committed with a latency less than 1.5 seconds.The system is running with 500ms block timeout with a block size of 30.This signifies that a block is generated either after 30 transactions are received or the timeout of 500ms is reached.Therefore, the submitted transactions have to wait for the timeout when the transaction rate is low.For example, when the transaction rate is 1 tps, the average latency of query transaction is at around 0.95s (500ms timeout time and processing and transmission delay in the system).
In addition, as the transactions are continuously sent from the client, the later transactions received in each block timeout period should have lower latency.Thus, the overall average latency slightly decreases to 0.76s, when the transaction rate reaches 10 tps.Moreover, the later transactions need to be held at the orderers if the transaction rate exceeds the maximum throughput.The accumulated and queued transactions would have higher latency, and it can be observed that the latency keeps increasing after transaction rate exceeds 20 tps, which is shown in the Figure 8.
The performance is related to various factors, such as, network delay, consensus delay among multiple orderers, chaincode execution time, endorsement delay, and block validation delay.Note that, this environment is running with single channel, but the overall system throughput should always be linear to the channel numbers, as long as the system has not reached the "real" overall system bottleneck [67].Namely, two times of throughput could be achieved by using 2 channels, 10 times could be derived with 10 channels, etc.However, a certain throughput bottleneck of the system exist, so that no matter how many channels are created, the throughput cannot exceed this threshold.In addition, one could further optimize the system performance by increasing computational power, changing endorsement policies, and using different state database, more details can be found at [67].Note that, although replacing CouchDB with LevelDB could improve the performance by 3X, rich query is only supported in CouchDB.
Even with the performance in current environment, our proposed framework could still work properly.With transaction rate lower than the single channel bottleneck, both of the R/W and query transactions could be processed in 1.5s, which is sufficient for the provenance scenario.One could design the chaincode to operate multiple devices information in blockchain within one transaction.One transaction is sufficient enough to represent one shipment, as all the IDs of parts ready for shipping can be added in this single transaction.Note that, the objective of this paper is to demonstrate the implementation of blockchain-based framework that can address device traceability issue.As transportation of parts take longer time to reach to the receiver, a transaction can be queued and added in a appropriate time.Our blockchain based provenance framework can address the real world traceability issues.

IV. SECURITY ANALYSIS
The primary objective of the proposed blockchain-based framework is to enable traceability for electronic parts and devices.It is necessary to evaluate the security of the framework such that an adversary cannot find a way to tamper the actual traceability information.In this section, we analyze various attacks and show that the framework is resistant to such scenarios.

A. ILLEGITIMATE DEVICE REGISTRATION
Illegitimate registration occurs when an untrusted entity (e.g., a rogue employee of a manufacturer) registers fake IDs into the blockchain.It can also happen if the credentials of an employee are compromised.An employee can also register a device in the blockchain unintentionally (by mistake).It is thus important for a manufacturer to identify if such registration occurs.In addition, deregistering fake devices (removing IDs) from the blockchain is possible.All the data in proposed framework is stored in chaincode or a smart contract.Even though the transactions in the blockchain are irreversible and tamper-resistant, the data stored in the smart contract or chaincode is still manageable and changeable.See the details at [74].It is necessary to grant access these functionalities to the authorized personnel (trusted) only.Note that one can still find out when such fake IDs have been removed as the blockchain keeps track of the operations.
No matter how the fake IDs are registered in the blockchain, the fake devices must have ownership traces start from the manufacturer's warehouse, so that the provenance root could be considered as valid.Therefore, those fake IDs must be initially transferred from manufacturer to the distributor/customer in blockchain, and the distributor/customer must confirm the delivery of matched devices.Assume that an adversary has some rogue employees in manufacturer CM , which produces X amount of parts.The illegitimate registration attack consists of following phases: 1) A rogue employee at the manufacturing site uploads F number fake device IDs instead of uploading F authentic device IDs into the blockchain.
2) The manufacturer (CM) sends F number authentic devices to the distributors or customers.Note that CM is trusted in our model and produces authentic parts.
3) The adversary intercepts the shipment of the authentic parts and then replaces them with their counterfeit counterparts.4) The distributors or customers receives the fake parts assuming they are authentic.They retrieve the device IDs and compared with the blockchain data.The verification will pass as the rogue employee at the manufacturing site uploads these IDs of the counterfeit parts.5) Finally, the distributors or customers send the confirmation transaction in blockchain and the transactions are recorded permanently.
This entire attack is valid only when the authentic devices can be smoothly transferred out from the manufacturing site.This can easily be implemented by an additional verification stage to certify whether these devices are authorized to leave the manufacturing site.A query in the blockchain will reveal whether these devices are present in the system.If this step is followed, no authentic device will leave the site.However, if adversary launches the aforementioned attack by uploading 2F number of device IDs (both F number of counterfeit and authentic devices) into the blockchain (Step 1).In this case, authentic devices will pass the verification stage as their IDs are already in the system.Fortunately, this can be detected as the inventory will show additional F devices which are not present at the site.Moreover, this can also be detected during registering the fake IDs as there will be a mismatch between the actual production number and registration number in the blockchain.

B. ILLEGITIMATE TRANSFER
The illegitimate transfer occurs when a illegitimate and incorrect transfer transaction is accidentally (faulty operation) or intentionally (attack) sent.Suppose manufacturer M sends out some electronic parts to distributor D 1 , however, M accidentally sends a device transfer transaction to distributor D 2 .In this case, the actual devices are held by D 1 , but the corresponding transaction is not available for D 1 to make the confirmation.D 1 needs to request manufacturer M to resend the transfer in the blockchain.Meanwhile, as the D 2 does not receive any devices, it is not reasonable for D 2 to confirm and pay for the devices.Thus, illegitimate transfers could not be confirmed.Similarly, suppose a manufacturer M is compromised and all its devices are transferred out by an adversary.This attack can also be detected easily since no actual physical devices are sent to that distributor, the receiver will not confirm the transfer or make the payment.There is no reason for a distributor to confirm a transaction until it receives the actual number of devices.The illegitimate transfer transactions could be cancelled or rejected.This is achieved by enabling time-to-live in transfer transaction, or setting a failed confirmation flag in confirmation transaction.In addition, optional functions can be created to directly cancel a illegitimate transfer before it has been confirmed, and this functionality should be accessible to authorized personnel only.

C. ILLEGITIMATE OFF-CHAIN DISTRIBUTION
The owners of the electronic parts could sell parts to the the open market, such as independent distributors or brokers, who are not a member of our proposed blockchain-based framework.In such cases, the distribution of the devices are not recorded in the blockchain.We refer this as an illegitimate off-chain distribution.One could also buy a part from an off chain market if he/she is not concerned about the authenticity of the part.In such cases, it is not recommended to sell or purchase the parts off chain as it would not allow us to guarantee the full traceability of parts.We could not enforce the authenticity for all the manufacturers', distributors', and customers' trades and therefore the record of the electronic parts in the provenance system as well, so only the devices recorded in the system from trusted suppliers are protected from counterfeiting and tampering.

V. CONCLUSION
We presented a novel blockchain based framework to provide traceability for electronic parts in the supply chain.For each device registered and distributed in the framework, one could track its origin, trace of travel, and the bill of materials in an efficient and reliable manner.All the manufacturers, distributors, and end users or customers could benefit from the framework, since it helps to protect the supply chain from counterfeit devices.We implemented our proposed framework using Hyperledger Fabric and performed detailed performance evaluation on throughput and latency.We performed a comprehensive security analysis for this framework to ensure that it is secure and reliable.Additional research is needed to explore the use of PUF and other unique device IDs, which could help to link the physical device to blockchain in tamper-resistant manner.

Figure 1 :
Figure 1: An abstract view of the electronics supply chain consisting of a design authority, a contract manufacturer, several distributors, a customer and two adversaries.

Figure 3 :
Figure 3: Operations and Transactions in the Proposed Blockchain-based Framework.

Figure 4 :
Figure 4: Data Structure of the Blockchain Network Model

Algorithm 4 :
Pseudocode for Tracking and Verification Function, TrackAndVerify() Input: Hash of the device IDs, HIDs 1 Fetch the device data record with key (HID);

Figure 5 :
Figure 5: A snapshot of the transaction details in Hyperledger Fabric blockchain.

Figure 6 :
Figure 6: Access Control Policies for our proposed blockchain-based framework.

Figure 8 :
Figure 8: Latency and throughput of the proposed blockchain implementation using Hyperledger Fabric.
1, device registration is completed.Contract manufacturer CM registers device type H to the Manufacturer CM uploads X entries of type H.Manufacturer CM uploads X entries of type H.