NoSneaky: A Blockchain-Based Execution Integrity Protection Scheme in Industry 4.0

The advancement of information technology allows the creation of smart devices that not only are programmable, but also can perform machine-to-machine communication in order to reach a flexible large-scale manufacturing strategy in Industry 4.0. However, as more components are connected to the Internet, cybercriminals can perform malicious actions remotely. As one lasting threat, sabotaging smart devices' execution integrity can cause a large financial loss, i.e., causing malfunctioning. Hence, it is important to secure the execution integrity of smart devices in Industry 4.0. Motivated by the emerging blockchain technology, in this article, we focus on how blockchain can help Industry 4.0 application protect execution integrity and propose a blockchain-based execution protection scheme named NoSneaky, which is low-cost and can be easily integrated into the current production systems. In the evaluation, we demonstrate its performance and effectiveness in securing the execution integrity.

important topic [3], [4]. The issue of imprecise reflection can cause difficulties and potential monetary loss during production and simulation. As an attacker, the ability of breaking and tearing the reflection virtual or physical in an Internet of Things (IoT)-embedded and information-driven assembly line is good enough to become an ideal hostage to ransom the production organization [5]. Furthermore, there are other common but critical situations that can affect the reflection, e.g., a malfunctioned device. Both can result in unqualified productions, or procedures not correctly done according to the preset standard.
As machines are capable of networking, these inaccurately reflected digital data can cause severe issues, as untruthful information may be broadcasted around the whole network. For example, a standard canning operation requires proper sealing and vacuuming before canned product can be sterilized at hot temperatures. If the vacuuming is not processed correctly due to malfunction or wrong configuration, it not only can result in a problematic product, but also can damage the assembly line due to high air pressure in the can.
Ensuring the reflection between virtual and physical trust and confidence is important for factories when moving them from digital model to digital twin, which can fully utilize the advantages of Industry 4.0 with security. When any malicious events being detected, a prevention step should be involved as soon as possible.
To ensure that all outputs from production lines are close to what people like and what they expect, a second pair of eye is involved, with the advent of blockchain technology; it can be deployed as a log service and guidance reference [6].
Hence, we propose NoSneaky, i.e., a blockchain-based solution to enhance the connection security between the digital object to be realized expectedly and the physical object. To implement a simple and easy-to-understand scenario, our system is based on the following assumption.
Given a digital command, then there is an expected outcome being observed, if the reflected physical action or actions are being performed correctly.
Based on the given assumption, what we can secure is the bonding between the given command and the expected outcome. If the result breaks this bonding, then the alert or respected actions will be raised and performed. The bonding information should have the highest integrity, which means the auditability and transparency of these records should be highly regarded. Furthermore, this information should be highly available under different circumstances. With all these requirements, blockchain technology is considered as a promising solution for storing up such information [7]. Each storage unit, called block, is secured with hash and proof generated by consensus algorithms. Furthermore, each block is hash-connected toward the preceding blocks, creating a chainlike structure with enhanced security due to the computational cost to tamper [8], [9].
Motivated by the abovementioned challenge and requirements, in this work, we propose and implement NoSneaky, a blockchain-based execution integrity protection scheme, which does not require, or only require, a little adaption of the current production system to integrate. That is, NoSneaky can effectively lower the deployment cost in practice. The contributions of our work can be summarized as follows.
1) We design NoSneaky to help check the execution integrity of smart devices in Industry 4.0. We particularly analyze how to select a suitable underlying blockchain platform and develop some critical components, such as executor, monitor, validator, trust/responsible list, and action report/integrity datastore. 2) In the evaluation, we implement NoSneaky (with detailed software and hardware configurations) and examine its performance under malicious entities. Our results demonstrate that our proposed system can protect a production system from execution integrity attack. The rest of this article is organized as follows. Section II introduces the background of blockchain technology and discusses related work on blockchain-based solutions in Industry 4.0. Section III describes our proposed NoSneaky in detail. Section IV presents the environmental configuration and the experimental results. Section V discusses the limitation and open challenges. Finally, Section VI concludes this article.

II. BACKGROUND AND RELATED WORK
The application of blockchain technologies into the Industry 4.0 domain is countless; however, not many of them are applied into the realm of execution integrity. In this section, we briefly introduce the background on blockchain and related work on blockchain-based applications for Industry 4.0.

A. Background on Blockchain
Blockchain got its name due to the data structure of its basic storage unit (see Fig. 1) and the mechanism that keeps data on-chain immutable with high integrity.
The hash of the previous blocks is contained in the next new block such that alternating any selected block must redo all the blocks connected after. More importantly, the nonce, which is related with the consensus algorithm, acts as a protection to the block [10]. Nonce is an added number such that when added into the hashing process, the outcome should satisfy the system's setting goal, resulting in a nonce that is difficult to produce, but is easy to validate [11]. For example, for a proof-of-work (PoW) consensus algorithm, it should satisfy the difficulty index during block generation.
Since consensus algorithms are the mechanism used to ensure only one unified blockchain version, it provides a protection nonce for each block, which enables the immutability to blockchain. It can be regarded as the core of blockchain [12].
Different algorithms can provide various advantages alongside with disadvantages [13]. For instance, some of them are suitable for a large public network, but may be inefficient in the ratio of transaction throughput and consumed resources. Some may be suitable for a small private network, whereas the network is costly when scaling.

B. Related Work on Blockchain in Industry 4.0
In recent years, blockchain technology has become popular and has been studied in helping design suitable Industry 4.0 applications. For example, Lin et al. [14] introduced BSeIn, i.e., a blockchain-based secure mutual authentication system that can ensure the fine-grained access control polices in Industry 4.0. It could provide privacy and security protection by integrating attribute signature, multi-receivers encryption, and message authentication code, as well as anonymous authentication and auditability.
Fernandez-Carames et al. [15] focused on unmanned aerial vehicles (UAVs) and utilized blockchain technology to keep certain inventory data gathered through UAVs. The blockchain is used to ensure the data trustworthiness and the data availability. Demertzis et al. [16] considered how to safeguard the network communication between traded Industrial Internet of Things devices, and then designed a deep autoencoder neural network to identify malicious events in the associated blockchain transactions within a critical infrastructure network. Faridi et al. [17] introduced a blockchain-based product traceability system for textile manufacturers. It can facilitate all stakeholders to track and monitor the product quality and ensure the efficiency of the supply chain.
Shukla et al. [18] focused on digital twin in Industry 4.0 and introduced a six-layered architecture for digital twin to help estimate the detection via an ensemble technique and a public Ethereum blockchain. Qu et al. [19] aimed to enhance the cognitive computing in the Industry 4.0 automation and developed a blockchain solution for Big Data-driven cognitive computing based on federated learning. The blockchain-enabled federated learning can help reach a quick convergence with the advanced verifications and member selections. More relevant studies of blockchain-based Industry 4.0 can refer to several surveys [20], [21], [22], [23].
By analyzing the existing work, most of them are focusing on the protection of data storage in Industry 4.0 via blockchain, or how to build a secure, trusted communication channel. Different from the current state of the art, our work focuses on how to ensure the integrity of execution result and develops NoSneaky, a blockchain-based execution integrity protection scheme. Our work aims to stimulate more research on building a secure Industry 4.0 application via blockchain.

C. Digital Twin and Blockchain in Manufacturing
Utilizing blockchain to secure digital twin in manufacturing is very common. Huang et al. [24] proposed a blockchain-secured data management system for digital twin of product. It utilized blockchain's characteristic of decentralization to provide storage, access, and sharing in a large number of parties with access control, authenticity, and version control. The smart contract functionality in blockchain provides automation with trust and automation with data sharing procedure. Mandolla et al. [25] proposed a blockchain-integrated additive manufacturing (AM) process that can securely interconnect between AM infrastructures in aviation industry. This is because aviation components require incredible precision during manufacturing, securing digital model and parameters till manufacturing process for aviation safety. Putz et al. [26] proposed a system that utilized blockchain decentralization and auditability to provide an auditable and secure management system of Industry 4.0 digital twin assets. Furthermore, it utilized smart contracts to develop DApps and ensure fine-grained access control. This created a system with integrity and availability. Finally, Leng et al. [27] developed a blockchain-based system that resolved the inconsistency between overview planning and local execution during manufacturing.
There are many existing frameworks that utilize blockchain to protect digital twins; however, few of them are focusing on ensuring the given objects and parameters that could be correctly reflected to the physical objects. Furthermore, many of them required further integration (e.g., updating software or adding support firmware) with the system that runs currently. Though, our NoSneaky performs similarly on functionality, it provides a solution that is noninvasive to the current system. As it can be run on its own network with observation from the side, the only component that requires integration is the Validator. Although it can be hooked up to shut-off power directly, it requires integration with the current system to allow performing further actions.

III. OUR APPROACH-NOSNEAKY
This section first briefly introduces and discusses how we select the underlying blockchain platform, and then describes the system design and workflow of NoSneaky.

A. Underlying Blockchain Platform
Though there are lots of blockchain platforms loading with different advantages, not all of them are suitable for our demands. As we look into a typical assembly line, we immediately notice the following characteristics.
1) Fixed Count of Smart Devices: The smart devices on each different part of the assembly line are usually fixed and known. Variations are possible from time-to-time, but not as frequent as a public blockchain network. Furthermore, the joining and the leaving within the network must be done by authorized personnel. 2) Real-Time: Each step on the assembly line should be finished on time. As the success of NoSneaky's operations is heavily relied on the push and pull of data to blockchain, the blockchain transactions must be completed before the target reaches the checkpoint. Otherwise, there will be no data for the checkpoint to observe. Transaction speed must be stable and fast; blockchain system that has unstable transaction speed is not favorable. 3) Smart Contract Supported: Smart contracts not only provide a simple way of storing data, but also provide partial automation with trust and transparency as well as multiple parties involved. First, maintaining a fast and steady transaction speed is critical; however, the blockchain type should also be carefully considered. For example, a federated blockchain can resist better against 51% attack compared to a pure privately controlled permissioned blockchain, which can provide a cost-effective solution for some platforms that do not have enough information technology (IT) equipment to hold a private blockchain. However, such implementation cannot be done in a closed network, as it does not allow communication among multiple production lines, due to security practices. Table I gives the features among some typical private and federated blockchains. We finally decided our platform as Go-Quorum due to its speed and the following features.
1) Ethereum Compatible: Ethereum can be considered as one of the most widely used DApps and smart contract platforms. Since GoQuorum is compatible with Ethereum on both DApps and smart contracts, it makes our system portable. If there exists a platform that outperforms Go-Quorum and, at the same time, is Ethereum compatible, then switching platforms can be easily done. 2) Ethereum virtual machine (EVM) Supported: The combination of Solidity + EVM is not the only choice for the smart contract platform. However, compared to other platforms that tend to run smart contracts' code on bare metal [28], EVM's structure can naturally minimize the remote code execution. In addition, as given in Table II, GoQuorum tends to be the quickest one when testing the transaction performance by deploying comparatively a large quantity of data (e.g., a smart contract with 100 KB of binaries or more).
We noticed that the speed of deploying a new contract can be severely different between platforms, while each of its processing time remains stable. Though deploying smart contracts may display a huge variation between platforms, completing one single transaction, such as pushing a new record into the smart contract, can remain fast and efficient.
Hence, we decided to select GoQuorum as our platform, not only because of its speed, but also due to its similarities with Ethereum. NoSneaky   Fig. 2 shows the system design of NoSneaky. We assume a production line with many smart devices that are controlled Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply. machinery, i.e., Actors, where each actor is externally embedded with a monitor. Several critical check-points with validators should observe the outcome made by the actor. To prevent possible security issues, monitors should be connected with their own proprietary network, which is different and separate from the typical control network. Executors can remain their communication through their own network.

B. System Design of
Though performing a full rewrite of the smart devices', onboard firmware may provide the best system performance, the requirement of reimplementing the firmware to integrate NoSneaky can be costly. This is the reason why we use nonintrusive way to monitor the system. Many devices have data output for debugging, hence we adopt such a way to monitor what and when the action is conducted. To achieve this, we introduce four critical roles and entities in our system.
The following are four major roles in NoSneaky. 1) Actor: The actor is the smart device that can command the machinery on the assembly line in order to perform real actions on the product. We assume that such device is embedded with an interface where we can read its status, and that it will constantly report the undertaken actions. The Actor is not part of the NoSneaky system, but is the machinery controlling device that NoSneaky is constantly monitoring. 2) Monitor: The monitor is an additional smart device that only listens to the output information from the Actor, as we assume that most of the available commercial devices may not allow any modification toward its firmware. The Monitor will not interact with the Actor (i.e., sending commands through interface). It will report the Actor's actions, such as completing an expected task, and upload the action report onto the blockchain.

3) Validator:
The validator is the additional smart device that observes the physical outcome of the product through sensors. It will refer to reports given by the Monitors, and the information about the action integrity data on the blockchain. If the reports look odd according to action integrity data, then the preset action will be taken, and an alarm will be raised. 4) System Administrator: This is the role that defines rules for action integrity data on the blockchain, managing both trust and responsible lists. In a close view of the relation between the actor and the monitor, we implemented an example diagram by utilizing Audrino as actor, while a Raspberry Pi as monitor. Both are connected to universal asynchronous receiver/transmitter (UART) serial interface with each other.
Arduino-the Actor will periodically report its actions to Raspberry Pi-the Monitor. However, the Raspberry Pi and the monitor can constantly receive reports on when and what have happened on its monitoring device, as shown in Fig. 3.
There are four important data entities in NoSneaky, as follows. 1) Trust List: This is a list of Monitors' addresses. It is used to ensure that only devices in the list can make action reports onto the blockchain. The report sent by others will be rejected. Fig. 4 shows the structure of Monitor. a) m_Address: The address of Monitor's account. b) friendly_name: A column to store a meaningful human name for the Monitor, e.g., sterilizer. c) dType: A column to store the device type on which the Monitor is monitoring. 2) Responsible List: This is a list of Validators' addresses, with a hashmap that stores their responsible Monitor(s). The structure can refer to Fig. 4. a) v_Address: The address of Validator's account. b) friendly_name: A column to store a meaningful name for the Monitor, e.g., assembly line 2. c) mp_Addresses: A column that tells the responsible area of this Validator. 3) Action Report: This is a data entity stored on the blockchain that allows Monitors to store the reports. The Validator will retrieve the latest report from the same entity. The structure can refer to Fig. 4. a) m_Address: The address of Monitor that makes this report. b) timeStamp: The timestamp of when such report has been made. c) outputHash: The hash value of hash(Output Information from Actors). d) confirmed: The boolean value that shows whether such report has been successfully processed by the Validator or not. e) alert: The boolean value that shows whether the Validator detects anomalies. f) m_Sign: The signature of the report made by the Monitor. g) v_Sigm: The signature of the report made by the Validator after the report has been processed. 4) Action Integrity Data: This is a set of policies stored on the blockchain that is defined by System Administrators. It regulates what given command is bonded with what expected outcome. The structure can refer to Fig. 4. a) dType: The device type we are going to define the sets of expected actions and outcomes. b) resultBond: The resultBond mapping provides a map that bonds the hash(Output Information from Actors) to the value of hash(Expected Result).
For example, if we expect a bronze outlook of the product when the Actor states to the Monitor: Temperature Ok!, then we can define the bond as: hash(Temperature Ok!)=> hash(Bronze). To simplify the relationship between the roles and entities, Fig. 5 shows the access permission of different data entities and roles.
From the Administrator's perspective of view, they have the utmost power of managing everything, except for the action report. From the Monitor's perspective of view, the only action that it can perform is to send out data to the action report. The action report will reference whether the report sender is on the Trust List, if not, the report will be rejected. Finally, from the Validator's perspective of view, it can reference all entities except for the Trust List. Validators require querying the Responsible List to know which Monitor is under its responsibility. Accessing both the action report and the action integrity data enables Validators to verify the report and the physical outcome of the product.

C. Workflow of NoSneaky
Here, we introduce the workflow regarding how to configure the system in the first time, how the report can be made, and how the validator prevents misbehavior from malfunctioning or tampered executors.
1) Defining and Initializing: System administrator must predefine the following data entities to activate the system. a) Trust List: Administrators must deploy and give a set of Monitors to the system so that the system can initiate with an access list of who can make the action report. b) Responsible List: Administrators must deploy and give a set of Validators to the system so that the Validators can know who to look and what to expect. c) Action Integrity Data: Administrators must provide a set of policies for Validators to follow and compare. 2) Monitoring and Reporting: If the Monitor is in the listening mode, then it will not respond to any output made by the Actor. Suppose that when each action is taken by the Actor, there should be an output that can tell such action is performed. In our assumption, an Actor-controlled machinery only has limited operations, especially when the scenario is on an assembly line where most machineries have only one expected operation. If any output has been made, the Monitor will create a data record with the data structure Report and deliver the report into the action report on the blockchain.
3) Validating and Preventing: The Validators will first grab two sets of reports as follows. a) Reports listed as "unconfirmed": Any report that is noted as confirm = false.

2) Reports That Have timeStamp Around a Reasonable
Time: Any report that is sent in the reasonable time duration according to timeStamp. Suppose the assembly line has to take 10 s from the Actor to the Validator, then the reasonable time duration should be around 10 s. Afterwards, the Validators will trigger the workflow to check a report's original state, as shown in Fig. 6.
In the first step, the Validator will check whether the timeStamp provided by the report looks reasonable. For example, it considers a tampered value if a timeStamp is far away from now in the future, or is far away from the past. After checking the timeStamp, the Validator will check other properties that should only be proposed by Validators. If any of these properties do not appear in its predefined status, the Validator will raise an alert and take actions.   If the report looks reasonable, then the Validator will start checking the observed result and compare it with the output from the action integrity data on the blockchain, as shown in Fig. 6. For our NoSneaky, the action integrity data will be difficult to tamper, as blockchain requires all nodes to hold a full or partial copy of the chain. For a successful attempt, an attacker has to not only swap the locally stored blockchain of all involved nodes at once, but also calculate all hashes that are connected after the transaction.

IV. EVALUATION
In the evaluation, our testbed was running on a virtualized environment constructed by vmware ESXi 7.0, and each virtual machine (VM) was given a 2-core Intel Xeon W-2133 CPU, 4 GB RAM, and 48 GB of HDD. Within each VM, we installed mxLinux 21 as the operating system and GoQuorum v21.7 as the blockchain platform.
As shown in Fig. 7, there are three actor-monitor combinations and one validator. On the validator machine, a shared folder was used to receive the output from actors. We adopted  the following reaction rule: if any output result raises an alert, then the validator will shut down the VM of the corresponding generator.

A. Experimental Flow
This section presents an evaluation to investigate the performance of our system, with the design as follows.
1) Actor: A program was constantly generating files every 5 s, and in each file, a character represents as the executed result. Meanwhile, an inter-process communication (IPC) pipeline is created so that the Monitor can receive the output information from the Actor. If the Actor successfully performs an operation, it will print out "Generated Successfully" through IPC socket to the Monitor, and at the same time, print out the character into the file, i.e., the expected outcome is "a". However, we deliberately crippled some generators to have a chance of randomly printing out other characters. 2) Monitor: A program was constantly listening to the output information from the Actor through the IPC and putting the output result to the blockchain, as shown in Fig. 8. 3) Validator: A program reads the executing results from the Actor and compares them with the information on the blockchain. If the Validator figures out that a particular generator provides an answer that does not match with what the Monitor suggested, it will command the vmware ESXi to shut down the problematic generator (namely the corresponding VM). In our testing scenario, we designed three generators (actor/monitor combinations) with one validator machine. The configuration of trust list (containing Monitors) is given in Table III. Note that all Actors were controlling, respectively, a device type called generator. While this device type can have  Table IV), if it reports "Generated Successfully", the outcome should be "a". Finally, as there is only one validator, the Responsible List only has one record, as given in Table V.

B. Implementation Methods of Actor
There are generally two implementation methods of Actor: 1) one is an active method; and 2) the other is a passive method. The active method requires the Actor to report every step that is about to perform, and every step must obtain the Validator's approval to continue. If the Actors are all honest, such implementation can terminate malicious actions as soon as possible.
We deliberately implemented another version of Actor that requires an execution permit from the Validator, and then compared how much it may affect. In this testing case, all Actors output one character alongside with a string of report information; however, the modified version was required to send the operation and the expected output before the modified version can continue the operation (see Table VI).
The main difference between modified version 1 and modified version 2 is that during a malicious event, the modified version 1 provides malicious estimated execution results to the Validator, whereas the modified version 2 provides faked estimated execution results and continues performing malicious outcome.
The outcome of Table VI is not surprising. The active method has a slight advantage if the Actor is honest, reporting the malicious activities in the execution estimation and sending it to the Validator, which can shut down the VM at once. However, this implementation does not make sense for an attacker; if an attacker's goal is to sabotage the production line, with the knowledge of such system, he or she may not report the malicious activities in the phase of requesting the execution permit. This is the reason why we implemented the modified version 2, which is closer to what an attacker would perform in practice.
However, it makes the active prevention useless and wasted. This is because the first round of gaining the execution right does not stop anything, but takes time to complete the step. Once the malicious outcome was performed and the Validator was detected, it would have the same protection performance of the passive detection method, while the additional time cost in the first round makes such method more undesirable.

C. Malicious Monitors
In addition to the Actors, the Monitors can also be malicious. In practice, the main goal of attackers is to fool the Validator. However, it can be challenging to do the followings.
1) Covering for the Actor: It is obvious that the Monitors can be not truthful, by reporting the good, without minding whatever outcome an Actor has reported. However, the Validator can still detect the malicious outcome, by comparing it with the data on the blockchain. 2) Not Reporting: The situation of not reporting is intriguing.
If the outcome is the right action, whether reporting or not, will not make an impact. However, if the outcome is undesirable, it can still be detected when the Validator performs a seek-up search of the action integrity datastore. The disadvantage is that this action takes some time to complete. However, when malicious event is detected, the Validator can take actions (i.e., shutting down the VM) to prevent it from the beginning. 3) Falsifying Report: This is a similar problem to "covering for the Actor". The main difference is what to falsify. If the outcome is undesirable, eventually such device will be shut down or offline, according to what actions have been programmed. If the outcome is desirable, the purpose of falsifying a report will not cause any loss for the company.

D. Blockchain Fork Attack
When the network is small, the influence of a fork attack can be tremendous. However, it depends on when the attack can be launched. If the fork attack occurs in a later stage, the Validator can still rely on the integrity datastore, which is usually created when the blockchain is initiated. The fork attack can, indeed, mess up the report system; however, it usually will not happen in the initial setup stage. Furthermore, we encourage the implementation method to hold this audit system in a proprietary network, which should be separated from the control network. A closed network may have some inconveniences, but if considering that the environment of a production line is usually fixed and stable, the closed network may provide more benefits with security.

V. DISCUSSION
In this work, we introduce how blockchain can provide integrity protection on data or execution result. However, due to the resource limitation, we cannot examine the system on a large-scale network. Instead, we investigated the system in a small-scale network environment with three actors and one validator. We discuss some open challenges as follows.
1) Malicious Validators: In our proposed NoSneaky, both validators and the system administrators should be wellprotected from the attacker. It is relatively easy in a small-scale network, but it may become quite challenging if the network is extended. In our system, multiple validators can be applied. As long as not all validators are malicious at the same time, we can still prevent the malicious validator. However, the protocols between different validators should be upgraded so the malicious validators can be phased out. Such implementation can provide better protection. 2) Scalability of Blockchain: As assembly cooperation between machines based on data sharing is feasible, we can expect that such cooperative manner will be extended to cross-organizations. When production projects involve with multiple parties, the network of NoSneaky will be extended. Making NoSneaky scalable is the top priority, as we have not tested NoSneaky in a large-scale environment. The voting-based consensus algorithms tend to have performance degradation with the network extending. As of 2025, the expected count of IoT devices can up to 75.44 billion [29], which is almost twice the number as 2022, we can expect the same thing occurred to the assembly line. Hence, we need to examine any method that can make blockchain-based applications efficient and speedy, especially in a large and dynamic network.

VI. CONCLUSION
In Industry 4.0, the interconnectivity provides many benefits, such as flexibility and scalability. However, the interconnected online factories may also face various security threats, e.g., production integrity. In this work, we aimed to introduce NoSneaky, which is a blockchain-based and low-cost solution to protect the production line from getting sabotaged by cybercriminals. We particularly discussed why to choose GoQuorum as the underlying blockchain platform and presented the main roles and entities in NoSneaky, i.e., executor, monitor, validator, trust/responsible list, and action report/integrity datastore. The blockchain is mainly used for checking and ensuring the integrity of reported outcome. In the evaluation, we implemented our system and provided the detailed configurations of software and hardware. The results demonstrated the viability and the effectiveness of NoSneaky in defending against malicious execution reports in a production system.