Vind: A Blockchain-Enabled Supply Chain Provenance Framework for Energy Delivery Systems

Enterprise-level energy delivery systems (EDSs) depend on different software or hardware vendors to achieve operational efficiency. Critical components of these systems are typically manufactured and integrated by overseas suppliers, which expands the attack surface to adversaries with additional opportunities to infiltrate into EDSs. Due to this reason, the risk management of the EDS supply chain is crucial to ensure that we are knowledgeable about the vulnerabilities in software and hardware components that comprise any critical part, quantifiable risk metrics to assess the severity and exploitability of the attack, and provide remediation solutions that can influence a prioritized mitigation plan. There is a need to realize cyber supply chain risk management for industrial control systems’ hardware, software, and computing and networking services associated with bulk electric system (BES) operations. This article proposes a blockchain-based cyber supply chain provenance platform (“Vind”) for EDSs to realize data provenance in a cyber supply chain ecosystem.


INTRODUCTION
To achieve reliable and efficient energy delivery system (EDS) operations, utility companies typically adopt various software/hardware products and solutions developed by third-party vendors. The enterprises have realized significant advantages due to such outsourcing activities in terms of continuous support services, just-in-time deliveries, elimination of inventories, globalization, and reduced operational cost. Although these proprietary commercial-off-the-shelf solutions offer high interoperability characteristics with a large variety of product features which the consumer enterprise may not need, integration of such products and services in the critical EDS infrastructures significantly increases the risk of supply chain-related threats, which could adversely impact the reliability of bulk electric systems (BESs). In the past, several attempts (Ellison and Woody, 2010;Du et al., 2013;CSRC, 2018) have shown how adversaries use strategic attack campaigns for extortion, malicious data alterations, and exfiltrations. Attack via a manufacturer source code or product and attack via vendor remote access are two such attack scenarios (Liang et al., 2018). The software supply chain attacks are becoming prevalent and disrupting the inherent trust between the software provider and the consumer. Thus, the involvement of multitude vendors, suppliers, distributors, and integrators in EDSs must be well handled, and the supply chain risks introduced in the BES should be mitigated through cyber-secure approaches.
There is a need to manage the third-party and supply chain risks for BESs. The plan will involve processes and actions for the utility companies, vendors, and suppliers to strengthen the supply chain risk management. However, the successful realization of this standard hinges on the users, owners, and operators of BESs and the third-party software/hardware vendors as well as suppliers who are engaged in implementing various processes related to BESs. Since these responsible entities must develop one or more documented risk management plan by identifying and assessing the cyber risks involved in BESs, it is important to build a collaborative security ecosystem where multiple stakeholders can seamlessly handle the vendor-identified incidents through effective notification, coordination, disclosure, and validation mechanisms. In this way, the enterprises will have increased visibility into the methods, applications, and services to ensure integrity and authenticity of all software provided by the vendors, thus providing a viable way to manage the evolving cyber risks on the BES.
Typically, current state-of-the-art provenance systems can be deployed through logging and auditing technologies to manage the cyber supply chain risk (Ivanov, 2018). However, these technologies are not effective in the cyber supply chain infrastructure, which are complex in nature, due to several layers of interoperating suppliers and vendors across geographical and organizational boundaries. To identify the origin, cause, and impact of violations in the cyber supply chain infrastructures, the collection of forensics and logs from diverse and disparate sources is required, which is an insurmountable task. At the same time, logs only provide a sequential history of actions related to every application.
We address the challenge of providing a resilient mechanism to monitor and audit the processes involved in the vendor's software and hardware components of BESs. There is an increased responsibility on the vendors to adopt software integrity criteria and controls. The challenges for meeting supply chain risk management requirements (Goff et al., 2014) (Contract, 2020 involve a) timely notification, coordination, and disclosure of vendor-identified incidents; b) software integrity and authenticity; c) vendor remote access; and d) information system planning. Realizing these functionalities is critical for BESs, which would allow devising quantifiable risk metrics to assess the severity and exploitability of BESs and develop prioritized risk remediation solutions. While it is of utmost importance to develop a framework of cyber-secure supply chain management, the multi-ownership environment introduces additional challenges to establish inherent trust among the involved entities. Provisioning transparency and provenance-tracking services are therefore critical in order to build trust and automate the supply chain risk management process. The recent emergence of Blockchain technology has shown its true potential in offering a tamper-resistant distributed ledger platform that can be used to maintain data provenance in an effective and secure manner. However, the practical deployment of Blockchain for better management of the supply chain risks in BESs has not been well studied. Further, the common issues existing in the cloudbased data storage, such as the lack of data privacy, lack of data immutability, lack of traceability, and lack of data provenance, are still hindering around in the integration process of Blockchain technology. Therefore, in this article, we propose a Blockchain-based cyber supply chain provenance system ("Vind") for EDSs. At a macro level, the approach followed to build Vind involves 1) the customer outlining the performance and security requirements, 2) the vendor identifying the appropriate hardware and software suppliers that will meet the supply chain provenance requirements, and 3) the suppliers ensuring that they report the desired information that allows the customers to improve auditability, attribution, and provenance of their critical assets. The system also involves the integration of vulnerability databases that would allow reporting to the stakeholders about potential vulnerability risks associated with any component, and the supplier will be notified to provide remediation plans.
The Vind platform is built on top of Rahasak blockchain, which is highly scalable in terms of storage capability (Bandara et al., 2018;. This blockchain can be used to share the asset supply chain information between multiple parties in EDSs. All the physical/software asset information in EDSs and their supply chain management information are stored in the blockchain. The supply chain management functions are implemented as blockchain smart contracts in the Vind platform (Bandara et al., 2019;2020). In this article, a performance evaluation of the underlying blockchain storage in the Vind platform is presented. The evaluation shows the scalability and transaction throughput features in the Vind blockchain system. Following are the main contributions from Vind.

A blockchain-based cyber supply chain provenance platform is
proposed to address the requirements of the supply chain risk management. 2. Permissioned blockchain has been used to store all the physical/software asset information in EDSs and their supply chain provenance information. 3. Blockchain-based audit storage has been introduced to store the audit logs of software/hardware assets and entities in the Vind platform. 4. To address the privacy concerns in the blockchain, off-chain storage has been integrated into the blockchain.
The rest of the article is organized as follows. Sections 2 and 3 discuss the architecture and implementation details of the Vind platform. Section 4 presents the performance evaluation of Vind. Related works are discussed in Section 5. Finally, Section 6 concludes the article. Figure 1 depicts the architecture of the Vind platform. Vendors, companies, and service providers and administrators are the main stakeholders in the Vind platform. The service provider is the host of the Vind platform. The service provider's main function is to on-board vendors and companies into the platform without the central authority. Besides, the service providers will offer services to various system entities but are not trusted from the architecture perspective. All the registration information will be verified by the blockchain node for authenticity and future validation. The service provider cannot modify the registration information on the blockchain ledger, which is immutable and tamper-resistant. Vendors produce hardware/software products, and companies purchase these software/hardware products from the vendors, which can be identified as assets. Each asset in the Vind platform is represented with a unique digital identity (e.g., UUID). Blockchain provides a tamper-evident, shared digital ledger that records data in a public or private peer-to-peer network. Blockchain can be used to share the asset supply chain information between multiple parties in EDSs. All the physical/software asset information in EDSs and their supply chain provenance information are stored in the blockchain. All the blockchain functions of the Vind platform are implemented with smart contracts. More information about these smart contracts is discussed in Section 2.3. Companies, vendors, and service providers are the blockchain clients of the application. They will provide web/mobile applications to interact with blockchain functions. Each blockchain client has its own offchain storage. Off-chain storage can store confidential data in blockchain peers. The hash of the data stored in off-chain storage can be published in the blockchain. In this way, Vind has addressed the common issues in cloud-based data storage, lack of data privacy, lack of data immutability, lack of traceability, and lack of data provenance.

Functionality
Vind platform facilitates the following features related to vendor/ company/asset life cycle management and supply chain management. There are separate smart contracts to handle each of these functions in the Vind blockchain, as shown in Figure 1. There are three main stakeholders in the Vind platform: vendors, companies, and service provider/administrator. An identity contract handles the identity registrations of each of these entities. We have used a self-sovereign-based approach when registering the identities in the Vind platform (Mühle et al., 2018;Baars, 2016). Once identity is registered, the entity will be onboard into the Vind platform. Basically, stakeholder's life cycle management of the Vind platform will be handled by the Identity contract. Service providers who are the maintainer of the Vind platform have the privilege to manage the life cycle of the vendors and companies (basically edit, delete vendor/company profiles). The software/hardware products in the EDS will be supplied by the vendors. Companies (e.g., energy company/power plant) purchase the products from vendors (purchased software/ hardware products identified as assets in the energy company). When new assets are purchased in an energy company, their information needs to be saved in the blockchain. This asset life cycle management is handled by Asset contract 13. Theasset contract supports functionality to create and search assets in the blockchain. Once an asset is onboarded into the energy company, there is an agreement formed between the vendor and the company. This agreement defines the supply chain risk management agreement terms (Goff et al., 2014;Contract, 2020). This agreement negotiation and the establishment is handled by the Agreement contract 14.
Various notifications (which relate to assets in the energy companies) will be generated and sent to a responsible person in the energy company and other organizations. All these notification generation and sending functionalities will be handled by the Notification contract 15. There are four main notification scenarios in the Vind platform: a) notification about vendoridentified attack incidents related to the products or services (coordination of responses to vendor-identified incidents related to the products or services), b) notification about vendor-identified issues related to the products or services, c) notification by vendors when remote or onsite access should no longer be granted to vendor representatives, and d) disclosure by vendors of known vulnerabilities related to the products or services. We have integrated the automatic attack discovery and notification function of assets in the Vind platform by using the common vulnerability exposure search API (CVE search API) (Pham and Dang, 2018). CVE search API is a service that contains a list of CVE security vulnerabilities of common software products. There is a public CVE database available with all known vulnerabilities of software products. We have incorporated a CVE search API to find known vulnerabilities of software products/assets in the Vind platform and notify them to the corresponding vendors and companies. In the Vind platform, we have run our own CVE search API service. It periodically fetches the vulnerabilities published in the public CVE search API and generates notifications based on the vulnerability.
There are various patches that can be sent for the software products which are used by the energy companies. The integrity of these patches needs to be verified by using a cryptographic method [e.g., SHA256 hashing (Gueron et al., 2011)]. This integrity checking and verification functionality are implemented with the Verification contract. There should be coordination of controls for vendor-initiated interactive remote access and system-to-system remote access with a Vendor. For example, when a third-party support person gets access (login) to troubleshoot a software product at the energy company, their access information should be traced. These access information tracing will be implemented with the Trace contract. The audit log of the assets, notifications, and identities is maintained in the Vind platform's blockchain ledger. This audit log contains all the events that happened (e.g., create, edit, and delete) to the assets, identities, and notifications in the Vind platform. It provides the data provenance of the Vind platform on top of the blockchain ledger.

Vind Use Case
Consider a scenario where Vendor A, Company B, and the Vind service provider (Vind administrator) want to procure products and services in the Vind platform. The necessary interactions occurring among these entities can be depicted as presented in Figure 2. The administrator can log in to the system and manage FIGURE 2 | Interaction diagram of a use case in Vind. Vind admin onboard vendors and companies into the platform. When a company purchases a product from the vendor, agreement will be formed. The notifications regarding the products will be generated by vendors.
Frontiers in Blockchain | www.frontiersin.org August 2021 | Volume 4 | Article 607320 the entities in the platform, Supplementary Appendix Figures  16, 17. In this scenario, first, the administrator will onboard Company A and Vendor A into the Vind platform. When onboarding, it registers basic information of the entities such as email, name, and other information in the blockchain, Supplementary Appendix Figures 18, 19. These onboarding functions of the blockchain are implemented in the Identity smart contract. Once onboarded, vendors and companies can register into the platform by using the Vind mobile app/Web application with the given e-mail address as the user identifier (e.g., username). Once logged-in, vendors can view the products they have and the companies using those products from the portal, Supplementary Appendix Figures 20-22. Vendors need to onboard their products into the platform via the Web application, Supplementary Appendix Figure 23. Companies can view the purchased products (e.g., assets) and their information from the company portal, Supplementary  Appendix Figures 24, 25. These product and asset life cycle management functions are implemented with Asset contracts in the blockchain. When a company is purchasing a product from a vendor, that product can be onboarded to the company through the company web portal, Supplementary Appendix Figure 26. Assume Company A is going to buy the product of Vendor A. When buying a product (asset), the company needs to specify the asset information and cyber supply chain agreement terms, Supplementary Appendix Figure 27. At this time, the vendor and company execute a supply chain agreement contract. The agreement contract in Vind will implement the functionalities needed to automate the supply chain risk management requirements and notify Vendor A. Then, Vendor A fetches the agreement terms from the blockchain and decides whether to accept or reject these terms, Supplementary Appendix Figure 28. If vendors accept the terms, Product A will be linked to Company A in the Vind platform as an asset.
If, for instance, the vendor identifies an issue in Product A, it must follow the agreement terms and is required to notify the issue to Company A. This functionality is integrated with Vind to enable the seamless release of software patches, notification of vulnerabilities, and software updates for the products to the companies. In order to ensure the integrity of the patches and updates, they will be signed by the PGP key of the vendors. Company users can enter the serial # of the patch and check the integrity. Vind will allow the release of patches and updates to the companies only when the integrity is verified. In each of the above steps, audit logs will be created and stored in the blockchain, Supplementary Appendix Figures 29, 30.

VIND IMPLEMENTATION
We have built the production version of the Vind platform to support high scalability and high transaction load. To cope with the high transaction load and back pressure (Destounis et al., 2016) operations, we have adopted a reactive stream-based approach using Akka streams (Davis, 2019). All the services in the Vind platform are implemented as small services (micro-services) with the single responsibility principle. These services are dockerized (Merkel, 2014) and deployed using the Kubernetes (Burns et al., 2016) container orchestration system. All the microservice communications are handled via the Apache Kafka (Kreps et al., 2011) message broker. We run 3 Kafka broker nodes with 3 Zookeeper nodes in Vind. The platform is running as a permissioned blockchain system in a private cloud. Figure 3 shows the architecture of the Vind platform.
Rahasak blockchain (Bandara et al., 2018; has been used to implement the functionalities of the Vind platform. Rahasak is a big data-friendly enterprise-level, a scalable blockchain platform. The back-pressure operation of the scalable application is handled with the reactive streaming-based approach in the Rahasak blockchain. It comes with concurrency-enabled Aplos smart contracts (Bandara et al., 2019;2020) which are written with the Scala functional programming language (Odersky et al., 2004) and Akka actors (Hewitt, 2010;Gupta, 2012). This smart contract platform supports high transaction throughput with supporting concurrent transaction execution on the blockchain. Rahasak blockchain facilitates full-text with the blockchain asset using Elasticsearch-based search API. We have selected the Rahasak blockchain to implement the Vind platform due to these enterprise-level features on it. We were able to support high transaction load, handle large volumes of back-pressure operations, and support full-text search on Vind using the Rahasak blockchain.
All the functionalities of the Vind platform are implemented with Aplos smart contracts in the Rahasak blockchain. There are four main smart contracts: a) identity contract, b) asset contract, c) notification contract, and d) verification contract. Web/mobile apps are the client applications on the Vind platform, invoking various functions implemented in smart contracts on the blockchain. The main functionalities include onboarding vendors, asset management in blockchain, report incidents, patch management, and view audit log. The requests generated from Web/mobile apps will be directed to blockchain smart contracts via the Vind gateway service which is HTTP REST API built with Golang (Schmager et al., 2010). Mobile/web client authentication/authorization will be handled by JWT-based (Jones, 2011) auth service in the Vind platform. Web/mobile client credential information will be stored in auth-storage (database) in the auth service. The asset in the Vind platform has assigned a unique digital identity. This identity is embedded in the QR code. The Vind mobile application comes with a QR code scanner. It can scan the QR code and fetch all the audit log information and attack information which are related to the software/hardware asset from the blockchain and visualize it.
The off-chain storage can store confidential data in the Vind platform. Each peer in the network has its own off-chain storage. They store confidential data on it and publish the hash of those data into the blockchain ledger. We have used Apache Cassandra (Lakshman and Malik, 2010) distributed storage to build the offchain storage in the Vind platform. The off-chain storage is connected with Kibana and Grafana (Reelsen, 2014) analytics' dashboard to do the data visualizations. The CVE search API is a service that contains a list of all related CVE security vulnerabilities of common software products. There is a public

Transaction Throughput
For this evaluation, we recorded the number of invoke transactions and query transactions that can be executed in each peer in the Vind platform. Invoke transaction creates a record in the ledger and updates the status of the assets in the blockchain. Query searches the status of the underlying blockchain ledger. They neither create transactions in the ledger nor update the asset status. We flooded concurrent transactions for each peer and recorded the number of completed results. As shown in Figure 4, we have obtained consistent throughput in each peer on the Vind platform. Since queries are not updating the ledger status, it has high throughput (2 times) compared to invoke transactions. Then the invoke transaction throughput of Vind is tested with different blockchain ledgers. We have implemented the Vind blockchain ledger service with Rahasak, BigchainDB, and Hyperledger Fabric platforms, and compared the transaction throughput results. As shown in Figure 5, the Vind ledger with Rahasak performs with a higher transaction throughput than BigchainDB and Hyperledger Fabric. The main reason for these observations is the enterpriselevel features available in the Rahasak blockchain. Similar to invoke transactions, the Query operation throughput of the Vind FIGURE 3 | Microservices-based architecture in the Vind platform. The platform is running as a permissioned blockchain system in a private cloud.
Frontiers in Blockchain | www.frontiersin.org August 2021 | Volume 4 | Article 607320 6 blockchain ledger tested with different blockchain platforms. Rahasak serves its query API via Apache Lucene index-based search API. BigchainDB facilitates the query API with MongoDB and Hyperledger Fabric with CouchDB. Query transaction throughput of Rahasak is higher than that of both BigchainDB and Hyperledger Fabric, as shown in Figure 6.

Transaction Scalability
For this evaluation, we recorded the number of executed invoke/ query transactions (per second) over the number of blockchain peers in the network. We issued concurrent transactions in each blockchain peer and recorded the number of executed transactions. Figure 7 shows the transaction scalability comparison of the Vind platforms' blockchain. When adding a node to the cluster, it nearly linearly increases the transaction throughput. This means the transaction latency will be decreased when adding blockchain peers to the cluster. Query transactions have high scalability when comparing to invoke transactions. The main reason is query transactions are not updating the ledger status like invoke transactions. Then we have tested the Vind  platforms' blockchain ledger scalability results with the different blockchain systems. As shown in Figure 8, the transaction scalability of the Vind ledger is compared in Rahasak, BigchainDB, and Hyperledger Fabric. Vind blockchain ledger with Rahasak has a higher scalability than that with BigchainDB and Hyperledger Fabric blockchains. Both Hyperledger Fabric and BigchainDB blockchains do not support the real-time transaction-enabled blockchain architecture. Rahasak blockchain supports the real-time transaction-enabled "Validate-Execute-Group" blockchain architecture. Also, Rahasak blockchain supports the concurrent transaction execution-enabled smart contract platform which does not exist in BigchainDB or Hyperledger fabric. Due to these reasons, the Vind ledger with the Rahasak blockchain has higher scalability than BigchaindDB and Hyperledger Fabric.

Transaction Execution Rate
Next, we evaluate the transaction execution rate in the Vind platform. We tested the number of submitted transactions and   Figure 9 shows how the transaction execution rate varies when having different numbers of blockchain peers in the Vind. When the number of peers increases, the rate of executed transactions is increased relatively. Figure 10 shows the number of executed transactions and submitted transactions in a single blockchain peer. There is a backpressure operation (Destounis et al., 2016;Davis, 2019) between the rates of submitted transactions and executed transactions. We have used a reactive streaming-based approach with Apache Kafka to handle the back-pressure operations in the Vind platform.

Search Performance
Vind allows searching its transaction information and asset information via underlying Rahasak blockchains' Lucene index-based search API (Gormley and Tong, 2015). For this evaluation, we issued concurrent search queries into Vind and computed the search time. As shown in Figure 11, to search 2 million records connected, it took 4 ms of time.  When the transaction count increases in the block, these factors will be increased. Due to this reason, when the transaction count increases, block generation time also increases correspondingly. As shown in Figure 12, it takes approximately 8 s to increase a block when creating blocks of 10 k transactions.

RELATED WORKS
Much research has been conducted to integrate blockchain with the supply chain management (Korpela et al., 2017). In this section, we briefly discuss the main features and architecture of these research projects.  Frontiers in Blockchain | www.frontiersin.org August 2021 | Volume 4 | Article 607320 10 "Supply chain risk" (Mylrea and Gourisetti, 2018) and "EDS supply chain" (Liang et al., 2018) works proposed blockchainbased supply chain management systems for energy delivery systems. The supply chain risk effort mainly focused on utilizing proof of authority (PoA)-based permissioned blockchain to manage the supply chain life cycle in the EDSs. The supply chain of the EDS implemented the supply chain functions in energy delivery systems using hyperledger fabric blockchain smart contracts. These functions include identity management, product verification, access control, contract execution, and monitoring.
"HACCP supply chain" (Tian, 2017), "AgriBlockIoT" , "Multichain WSC" (Biswas et al., 2017), and "Agrifood Supply Chain" (Tian, 2016) works proposed blockchain-based food supply chain management and traceability systems. The HACCP supply chain system has given an example scenario to demonstrate how it works in the food supply chain with HACCP. This system is built on top of the BigchainDB scalable blockchain system to support highly scalable applications. The AgriBlockIOT system can rely either on the Ethereum or the Hyperledger Sawtooth publicly available blockchain implementations, while it is able to integrate various IoT sensor devices. As a use case, they have implemented and discussed traditional food supply chain scenarios from agricultural farms to customer consumption on top of the blockchain. Multichain WS proposed a blockchainbased wine supply chain traceability system which is built over a multichain-permissioned blockchain platform (Greenspan, 2015). The proposed solution is designed and implemented with five entities in the wine supply chain, namely, grape grower, wine producer, bulk distributor, filler/packer, and retailer. Agrifood Supply Chain is built to help Chinese agrifood markets to enhance their food safety and quality. They mainly rely on the RFID technology to implement data acquisition, circulation, and sharing in production, processing, warehousing, distribution, and sales links of the agrifood supply chain.
"Manufacture supply chain" (Abeyratne and Monfared, 2016) work proposed the supply chain traceability system for manufacturing domain. The manufacturing of cardboard boxes is used as an example to demonstrate how such technology can be used in a global supply chain network. The proposed approach comprises a decentralized distributed system that uses blockchain(s) to collect, store, and manage key information of each product throughout its life cycle. When a product moves its life cycle, each actor (e.g., producers, suppliers, manufacturers, distributors, retailers, and finally the end consumer) logs information about the product and its current status on the blockchain network. Each product would be attached with an information tag, which could be in the form of a barcode, RFID, or QR code. The registered actors in the system can access the physical asset's virtual profile and life cycle events by scanning the tag.
The comparison summary of these supply chain management platforms and the Vind platform is presented in Table 1. It compares implemented blockchain platform, blockchain type, consensus, application domain, scalability, and privacy-level details.

CONCLUSION AND FUTURE WORK
With Vind, we have introduced a blockchain-based cyber supply chain provenance platform for energy delivery systems. It has addressed the requirements of supply chain risk management. We have used blockchain to store all the physical/software asset information, their supply chain provenance information, and audit log information in EDSs. To address privacy concerns, off-chain storage has been integrated into the blockchain. By using the Rahasak blockchain to build the Vind platform, we were able to achieve higher transaction throughput and meet the scalability requirements. We have demonstrated the scalability and transaction throughput requirements with extensive empirical evaluations. Version 1.0 of the Vind platform as described above in this article is currently running as a prototype.

DATA AVAILABILITY STATEMENT
The raw data supporting the conclusion of this article will be made available by the authors, without undue reservation.

AUTHOR CONTRIBUTIONS
EB: methodology, software implementation and draft preparation. DT: investigation, writing-reviewing and editing. XL: investigation, writing-reviewing and editing. SS: supervision, investigation, writing-reviewing and editing.

FUNDING
This work was funded by the Department of Energy (DOE) Office of Fossil Energy (Federal Grant No. #DE-FE0031744).