# UIV-TSP: A Blockchain-Enabled Antileakage Sharing Protection Scheme for Undisclosed IIoT Vulnerabilities

Authors: Wenbo Zhang; Jing Zhang; Yifei Shi; Jingyu Feng
Journal: Security and Communication Networks
 (2022)

---

## Abstract

With the large-scale deployment of industrial Internet of things (IIoT) devices in 5/6G environments, the number of vulnerabilities threatening IIoT security is growing dramatically, including a mass of undisclosed IIoT vulnerabilities that lack mitigation measures. Coordination vulnerability disclosure (CVD) is one of the most popular vulnerabilities sharing solutions, in which security workers (SWs) can develop undisclosed vulnerability patches together. However, CVD assumes that SWs are all honest and thus offering chances for dishonest SWs to internally leak undisclosed IIoT vulnerabilities. To combat such internal threats, we propose an undisclosed IIoT vulnerabilities sharing protection (UIV-TSP) scheme against internal leakage. In this paper, a dynamic token is an implicit access credential for an SW to acquire an undisclosed vulnerability message, which is only held by the system and constantly updated with the SW access. The latest updated token can be stealthily sneaked into the acquired information as the traceability token to prevent internal leakage. To quickly distinguish dishonest SWs, the feedforward neural network (FNN) is adopted to evaluate the trust value of SWs. Meanwhile, we design a blockchain-assisted continuous logs storage method to achieve the tamper-proofing of dynamic token and the transparency of undisclosed IIoT vulnerabilities sharing. The simulation results indicate that our proposed scheme is resilient to suppress dishonest SWs and protect the IIoT undisclosed vulnerabilities effectively.


---

## Body

## 1. Introduction

With the gradual deployments and applications of 5/6G, the Internet of things (IoT) technology is being applied to every part of our lives [1–4]. As a subset of IoT, industrial Internet of things (IIoT) has recently attracted attention [5]. By leveraging sensors, actuators, GPS devices, and mobile devices, the IIoT technology is being applied to advance the development of many industrial systems [6]. The industrial systems where this IIoT technology is integrated include energy [7], manufacturing [8], logistics [9], and transportation [10].Currently, IIoT devices have been widely deployed with weak security features or a lack of security [11]. These features have made IIoT devices as a good target for attackers with malicious intentions, and in many cases, exploits using IIoT devices have been occurring [12]. There is an urgent need for a solution that provides a lightweight and low-cost mechanism for collaborative security response of IIoT devices against emerging vulnerabilities [13].However, the IIoT vendors generally have weak security emergency response capabilities. It is better to invite some security workers (such as organizations, institutions, or white hats) to help them mitigate the new vulnerabilities of IIoT devices. In order to standardize the process of vulnerabilities patching and accelerate the development of mitigation measures, the vulnerability disclosure policy has been presented in [14], including vulnerabilities reporting, sharing, coordinating, and patching. An IIoT vulnerability can be officially disclosed after the patch is made; otherwise, it is called an undisclosed IIoT vulnerability (uiv). According to the vulnerability disclosure policy, the IIoT vendors can report a new uiv and share it with some security workers (SWs) who develop their patches together by means of the coordination vulnerability disclosure (CVD).Unfortunately, CVD is a set of guidelines without mandatory measures [14, 15]. CVD assumes that SWs are all honest and thus offering chances for dishonest SWs to internally leak undisclosed IIoT vulnerabilities. Due to the widespread use of IIoT devices, the leakage of an uiv message could cause a large-scale damage. Therefore, it is necessary to prevent the internal leakage of the uiv. Although a lot of works have been done in the field of threat intelligence sharing [16, 17], they focus on the sharing protection of disclosed vulnerability information. Little attention has been paid to the sharing protection of undisclosed vulnerability information.In this paper, we propose an undisclosed IIoT vulnerabilities trusted sharing protection (UIV-TSP) scheme against internal leakage. To enable endogenously secure IIoT, our final objective is to prevent the leakage of uiv until their patches are released. The main contributions of this paper are as follows:(1)
Introduce dynamic token as the implicit access credential and traceability clue for an SW. When uploading a new uiv, each internal SW is assigned a corresponding token called tokenaccess, which is only held by the system and cannot be seen by anyone. Even if an SW is granted access through identify authentication, an uiv message cannot be acquired without tokenaccess. To avoid malicious inference, tokenaccess should be updated dynamically. At the end of SW access, the current tokenaccess is revoked. A new random number is integrated into the hash generation of token to get a new tokenaccess as the next access credential. Meanwhile, the current tokenaccess and the MAC address of SWs are hashed to create the traceability token called tokentracing, which is embedded in the undisclosed IIoT acquired by an SW.(2)
Design a blockchain-assisted method to store the continuous logs of all SWs for the UIV-TSP scheme. To ensure the tamper-proofing of dynamic token, the original token and its all-subsequent updates should be stored on the blockchain. To achieve the transparency of uiv sharing, their metadata and the related SW access records are also stored on the blockchain.(3)
Present an internal leakage prevention method with one-step traceability. A benign logic bomb called codepreleak is embedded into an uiv message, which checks that whether the current MAC address is the same as the preset destination address in tokentracing. Due to the confidentiality, an uiv message can only be reached by one step to the SW host that is licensed by the system. Once the uiv information leaves the SW host, codepreleak will automatically trigger the self-destruct program to prevent leaks.(4)
Adopt the trust mechanism based on deep learning to evaluate the trust value of SWs according to their historical behaviors in an automatic and dynamic manner. With high trust value, honest SWs would be accepted to acquire uiv. With low trust value, dishonest SWs would be rejected. With medium trust value, it is difficult to determine the access authorities of semihonest SWs who may be suspiciously dishonest SWs. In this case, we can release a false uiv with tokentracing to trap their external conspirators.The architecture of this paper is as follows. In Section2, we introduce the related works. Our UIV-TSP scheme is proposed in Section 3. In Section 4, we analyze the performance of UIV-TSP from the perspective of security and cost. We also discuss the application of UIV-TSP solution and future work in Section 5. Finally, we conclude the paper in Section 6.


## 2. Related Work

### 2.1. Vulnerability Disclosure Policy

ISO/IEC 29147 defines vulnerability disclosure as a process through which vendors and vulnerability finders may work cooperatively in finding solutions that reduce the risks associated with a vulnerability [14]. Currently, CVD [15] is a good choice to develop undisclosed vulnerability patches together among security workers. As shown in Figure 1, the CVD process is consisted of gathering, coordinating, disclosing, and patching, and more details are given in [15]. Furthermore, there are two extreme cases for vulnerability disclosure: (1) public disclosure: disclosure as soon as the vulnerability information is received. (2) private disclosure: keep the vulnerability information security. Both of them are regarded as irresponsible sharing.Figure 1
Flowchart of vulnerability disclosure policy [15].These vulnerability disclosure schemes all rely on guidelines, but in practice, guidelines are not mandatory. Once a participant breaks the guidelines, the entire vulnerability disclosure process will be paralyzed, thus increasing the threat risks from the attackers.


### 2.2. Threat Intelligence Sharing

To prevent the leak of sensitive data in threat intelligence containing uiv, many studies have integrated cryptography primitives into their threat intelligence sharing scheme. Vakilinia et al. [16] designed a mechanism enables the organizations to share their cybersecurity information anonymously. Meanwhile, they proposed a new blind signature based on BBS+ to reward contributions anonymously. Badsha et al. [17] proposed a privacy preserving protocol where organizations can share their private information as an encrypted form with others and they can learn the information for future prediction without disclosing any private information. de Fuentes et al. [18] introduced PRACIS, a scheme for cybersecurity information sharing that guarantees private data forwarding and aggregation by combining STIX and homomorphic encryption primitives. Homan et al. [19] leveraged the security properties of blockchain and designed a more effective and efficient framework for cybersecurity information sharing network. Preuveneers et al. [20] employed blockchain and CP-ABE to offer fine-grained protection and trustworthy threat intelligence sharing with the ability to audit the provenance of threat intelligence.However, these schemes are helpful to protect the uiv information sharing, while the sharing protection of uiv information has not been involved. Without mitigation measures, the leakage of an undisclosed IIoT vulnerability could cause a large-scale damage [21–23]. Therefore, while protecting the sharing of uiv information, the responsibility of SWs should be traced back.


### 2.3. Data Leakage Prevention

Currently, some researchers focus on leveraging cryptography algorithms to implement an accountable and efficient data sharing in research of tracing data leakage. Mangipudi et al. [24] presented a committed receiver oblivious transfer (CROT) primitive to fairly track the traitor of leaked data by oblivious transfer (OT) protocol and zero knowledge (ZkPok). Huang et al. [25] designed an accountable and efficient data sharing scheme for industrial IoT (IIoT), named ADS/R-ADS/E-ADS, in which data receiver’s private key (i.e., evidence) is embedded in sharing data, and data owner can pursue the responsibility of a public for profits while without permission. Zhang et al. [26] proposed a fair traitor tracing scheme to secure media sharing in the encrypted cloud media center by proxy re-encryption and fair watermarking. Ning et al. [27] presented a traitor tracing with CP-ABE scheme by two kinds of noninteractive commitments. Based on signatures, Imine et al. [28] proposed a novel accountable privacy-preserving solution for public information sharing allows to trace malicious users.The above schemes all contribute to the sharing of threat intelligence. Nevertheless, these schemes cannot deal well with the trade-off between traceability time and robustness. A lightweight traceability scheme is required to uiv sharing.


## 2.1. Vulnerability Disclosure Policy

ISO/IEC 29147 defines vulnerability disclosure as a process through which vendors and vulnerability finders may work cooperatively in finding solutions that reduce the risks associated with a vulnerability [14]. Currently, CVD [15] is a good choice to develop undisclosed vulnerability patches together among security workers. As shown in Figure 1, the CVD process is consisted of gathering, coordinating, disclosing, and patching, and more details are given in [15]. Furthermore, there are two extreme cases for vulnerability disclosure: (1) public disclosure: disclosure as soon as the vulnerability information is received. (2) private disclosure: keep the vulnerability information security. Both of them are regarded as irresponsible sharing.Figure 1
Flowchart of vulnerability disclosure policy [15].These vulnerability disclosure schemes all rely on guidelines, but in practice, guidelines are not mandatory. Once a participant breaks the guidelines, the entire vulnerability disclosure process will be paralyzed, thus increasing the threat risks from the attackers.


## 2.2. Threat Intelligence Sharing

To prevent the leak of sensitive data in threat intelligence containing uiv, many studies have integrated cryptography primitives into their threat intelligence sharing scheme. Vakilinia et al. [16] designed a mechanism enables the organizations to share their cybersecurity information anonymously. Meanwhile, they proposed a new blind signature based on BBS+ to reward contributions anonymously. Badsha et al. [17] proposed a privacy preserving protocol where organizations can share their private information as an encrypted form with others and they can learn the information for future prediction without disclosing any private information. de Fuentes et al. [18] introduced PRACIS, a scheme for cybersecurity information sharing that guarantees private data forwarding and aggregation by combining STIX and homomorphic encryption primitives. Homan et al. [19] leveraged the security properties of blockchain and designed a more effective and efficient framework for cybersecurity information sharing network. Preuveneers et al. [20] employed blockchain and CP-ABE to offer fine-grained protection and trustworthy threat intelligence sharing with the ability to audit the provenance of threat intelligence.However, these schemes are helpful to protect the uiv information sharing, while the sharing protection of uiv information has not been involved. Without mitigation measures, the leakage of an undisclosed IIoT vulnerability could cause a large-scale damage [21–23]. Therefore, while protecting the sharing of uiv information, the responsibility of SWs should be traced back.


## 2.3. Data Leakage Prevention

Currently, some researchers focus on leveraging cryptography algorithms to implement an accountable and efficient data sharing in research of tracing data leakage. Mangipudi et al. [24] presented a committed receiver oblivious transfer (CROT) primitive to fairly track the traitor of leaked data by oblivious transfer (OT) protocol and zero knowledge (ZkPok). Huang et al. [25] designed an accountable and efficient data sharing scheme for industrial IoT (IIoT), named ADS/R-ADS/E-ADS, in which data receiver’s private key (i.e., evidence) is embedded in sharing data, and data owner can pursue the responsibility of a public for profits while without permission. Zhang et al. [26] proposed a fair traitor tracing scheme to secure media sharing in the encrypted cloud media center by proxy re-encryption and fair watermarking. Ning et al. [27] presented a traitor tracing with CP-ABE scheme by two kinds of noninteractive commitments. Based on signatures, Imine et al. [28] proposed a novel accountable privacy-preserving solution for public information sharing allows to trace malicious users.The above schemes all contribute to the sharing of threat intelligence. Nevertheless, these schemes cannot deal well with the trade-off between traceability time and robustness. A lightweight traceability scheme is required to uiv sharing.


## 3. Our Proposed UIV-TSP Scheme

With dynamic token, we propose an undisclosed IIoT vulnerabilities sharing protection scheme called UIV-TSP to prevent uiv leakage until their patches are released. Concretely, the UIV-TSP scheme consists of four collaborative modules: dynamic token management, blockchain-assisted continuous logs storage, internal leakage prevention with one-step traceability, and trust-based SWs distinction.


### 3.1. System Architecture

To prevent uiv leakage, we first present the system architecture of the UIV-TSP scheme. Figure2 illustrates the overall system architecture of our scheme, which consists of the following entities:(1)
Trusted authority (TA): trusted authority is responsible for processing SW’s access requests, generating and updating dynamic token, and evaluating trust value ofSWi.(2)
Security workers (SWs): there exist some workers who access uiv information in the sharing environment to develop their mitigation measures. We describe three types of workers: (1) honest SWs who do not engage in unauthorized access; (2) semihonest SWs who have a chance of committing malicious behavior; (3) dishonest SWs who often leak uiv information. In this paper, SWs are defined asSW1,SW2…SWm.Figure 2
System architecture of the UIV-SP scheme.


### 3.2. Dynamic Token Management

We introduce dynamic token as the implicit access credential and traceability clue for an SW. As shown in Figure3, the lifecycle of dynamic token is consisted of generation and update.Figure 3
Lifecycle of dynamic tokens.


#### 3.2.1. Token Generation

When an SW submits a new undisclosed vulnerabilityvulj, each internal SW is assigned a corresponding token called tokenaccess, which is only held by the system and cannot be seen by anyone. TA generates the initial tokenaccess through a hash function. Meanwhile, we define vulmeta as the meta information of an uiv. The initial tokenaccess can be calculated as follows:(1)tokenaccess=HSWivulmetatpnonce.Even if an SW is granted access through identify authentication, the uiv cannot be acquired without tokenaccess. Algorithm 1 is performed to generate and update tokenaccess.Algorithm 1: Pseudocode of token generation and update.
(i)
Input:SWi(ii)
Output: tokenaccess(1)
IfSWi in SWpoolthen(2)
tokenaccess=HSWi‖vulmeta‖tp‖nonce.(3)
If tokenaccess in blockchain then(4)
Update tokenaccess, tokenaccess↔SWi(5)
else(6)
Store tokenaccess, tokenaccess↔SWi(7)
If end of request access, then(8)
Revoke tokenaccess(9)
tokentracing⟵Htokenaccess‖maccurrent(10)
tokenaccess⟵HSWi‖vulmeta‖tp‖nonce′(11)
Store tokenaccess, SWi↔tokentracing(12)
Embedtokentracing to vulj(13)
End If(14)
End If(15)
End If


#### 3.2.2. Token Update

To avoid malicious inference, we integrate a one-time random number into the hash generation of token to update token dynamically. At the end of SW access, tokenaccess will be update as follows:(2)tokenaccess⟵HSWivulmetatpnonce′.Meanwhile, the current tokenaccess and the MAC address of the SW are hashed to create the traceability token called tokentracing. Tokentracing can be defined as follows:(3)tokentracing⟵Htokenaccess‖maccurrent.In our scheme, tokentracing can be stealthily sneaked into the acquired vulj information as the traceability credential. The execution strategies of dynamic token management can be executed with four steps, the more details are given in [29].


### 3.3. Blockchain-Assisted Continuous Logs Storage

Due to the advantages including transparency, traceability, and tamper-proofing, many studies have integrated blockchain into the prior works to implement a reliable and efficient data storage [30]. In general, there are three types of blockchain data storage patterns [31]:(1)
Public blockchain: a public blockchain is the blockchain that can read by anyone in the world, anyone can send transactions to and expect to see them included, if they are valid, and anyone can participate in the consensus process, which determines what blocks get added to the chain and what the current state is.(2)
Private blockchain: a private blockchain is the blockchain where can write by only one organization.(3)
Consortium blockchain: a consortium blockchain is the blockchain where the consensus process is controlled by a preselected set of miners.Since token can only be held by the system, the public blockchain does not meet the requirements. Hence, a private blockchain-assisted storage method is designed to centralized storage logs. To prevent attackers from tampering with data, the logs of SWs’ activities in the shared process should also be continuously recorded on the blockchain. These continuous logs, including dynamic token, trust value of SW (Tri), and behaviors record (Ri), are also only held by the system. It can be found that the private blockchain is suitable for our scheme.In the blockchain, the block structure of continuous logs storage is shown in Figure4.Figure 4
Block structure of continuous logs storage.


#### 3.3.1. Block Head

The block head is slightly different from the traditional structure. Except for previous hash, timestamp, Merkle root, and block ID, several new elements are integrated into the block head:(i)
SWi: the ID of the i-th SW who requests the undisclosed vulnerability in the sharing environment.(ii)
Tri: the trust value of SWi. In the block head, Tri can be quickly retrieved by TA.(iii)
vulmeta: the meta information of an undisclosed IIoT vulnerability.


#### 3.3.2. Block Body

In the block body, the log data of an SW (such asSWi) are hashed to build the Merkle tree. Except for tokenaccess and tokentracing, the log data of SWi contain the following elements:(i)
seciold,lekiold: the historical trust data of SWi, which can be used to evaluate the trust value of SWi before the access.(ii)
secinew,lekinew: the current trust data of SWi, which can be used to update the trust value of SWi after the access.(iii)
Ri: the access request record of SWi to an uiv information.(iv)
Ffalse: the flag whether a false uiv information has been released.


### 3.4. Internal Leakage Prevention with One-Step Traceability

To prevent SWs leaking the acquiredvulj information, vulj should be self-destruct when they leave the host of SWs one-step. Thus, we design a benign self-triggering logic bomb codepreleak. A logic bomb is a piece of code consisting of a trigger condition and a payload; when the trigger condition is met, the bomb is triggered (or activated) and the payload code gets executed [32].codepreleak is composed of trigger condition and response payloads. The trigger condition is designed to detect the access environment difference between honest SWs and dishonest SWs, so that the protection payload will be activated to destroy vulj on the leakage side.As shown in Figure5, the functional structure of codepreleak is consisted of self-checking and self-destruct.Figure 5
Functional structure of codepreleak.


#### 3.4.1. Self-Check

Once the uiv information enters the SW host, codepreleak will extract the current SW host Mac address and the revoked token to compute the verification value. Then, codepreleak will match the verification value to tokentracing. If the result Vc is inconsistent, it will trigger self-destruct. Vc can be calculated as follows:(4)Vc⟵tokentracing==Htokenaccess,maccurrent?.Algorithm2 is performed to match verification value.Algorithm 2: Pseudocode implementation of Match verification value and self-destruct.
(i)
Input: uiv(ii)
Output: access/deny(1)
tokentracing=extractvulj(2)
If tokentracingnot invulj(3)
Go to step 15.(4)
Else(5)
AcquireMACcurrent(6)
Vc⟵tokentracing==Htokenaccess,maccurrent?(7)
IfVc=1then(8)
Assign access authorities(9)
IfExtractvulj==Ffalsethen(10)
Go to step 8.(11)
Else(12)
Send an encrypted feedback messageef to TA.(13)
Destroy the targetvulj(14)
End if(15)
End if


#### 3.4.2. Self-Destruct

IfVc=0, the leakage has not happened. That is, the uiv information has not left the SW host. The protection payload continues to lurk.IfVc=1, it may leak vulj. That is, the uiv information has left the SW host. In this case, the protection payload will be activated immediately to destroy vulj.At the same time as the self-destruct event,codepreleak can automatically send encrypted feedback ef=tokentracing,vulj,SWi,maccurrent,tfeedback to TA.(i)
vulj: the ID of undisclosed IIoT vulnerability.(ii)
tfeedback: the time to codepreleak send the feedback message.Algorithm2 is performed to activate the protection payload.


### 3.5. Trust-Based SWs Distinction

Trust mechanism can be adopted to evaluate the trust value of SWs according to their historical behaviors. With trust value, we can quickly distinguish honest SWs and dishonest SWs. For semihonest SWs, we can further validate their credibility by tracing whether they have external conspirators. Different SWs will gain different access authorities to acquire uiv information.


#### 3.5.1. Trust Value Evaluation

In the process of vulnerabilities information sharing, the behaviors of an SW are generally dualistic: secret-keeping and leakage. With trust mechanism, if an SW often leaks information, he will get a low trust value.To quantify these duality behaviors, the beta function is one of the most popular trust value evaluation methods. It first counts the number of secret-keeping and leakage by an SW and then calculates the trust value with beta function denoted byBetaα,β [33].(5)Betaα,β=Γα,βΓαΓβθα−11−θβ−1,where θ is the probability of duality behaviors, 0≤θ≤1, α>0,β>0.TakeSWi as an example, seci and leki denote the number of secret-keeping and leakage in the sharing environment, respectively. The expectation value of the beta function can be calculated as follows: EBetaα,β=α/α+β. Considering that the trust value BTi is limited in the interval [0, 1], BTi can be described as follows:(6)BTi=1+seci1+seci+leki.Whenseci≥1 and leki=0, BTi is always calculated as 1. The SWi is completely trusted under this condition.Obviously, the base trust valueBTi that decays too slowly will give dishonest SWs more opportunities to leak. So, it is very essential to introduce a penalty factor, which can be calculated as follows:(7)Pi=e−seci+leki/seci.With the punishment ofPi to BTi, the trust value Tri of SW can be further evaluated as follows:(8)Tri=1+seci1+seci+leki⋅e−seci+leki/seci,leki<seci,0,leki≥seci.In the (8), the Tri means the comprehensive trust value of SWs, which introduces a penalty factor to cause Tri to decrease faster when leakage occurs. Unfortunately, the trust mechanism utilizing the beta reputation engine is suitable for scenarios with a small amount of trust data. When the trustworthiness of SWi is not represented by duality behaviors, as in the case of the collusion clique construction, it is possible for some malicious SWs to exhibit rational behaviors to avoid the detection. That is, they can keep high trust value in an alternant process by truly sharing their uiv information or leaking uiv information to their conspirators.To suppress such behaviors, the special reputation engine is adopted to prevent the SW trust value growth of some rational conspirators at the uiv information sharing. Once the TA receives messages from an SW regarding some uiv information requests, the trust value of the SW will calculate by applying the feedforward neural network (FNN) algorithm [34], which is depicted in Figure 6.Figure 6
Structure of the feedforward neural network.The input layer of FNN consists of 11 input nodes, such as the collaborators of the target SW, the average trust value of SW collaborators, and the number of SW’s conspirators. The complete input feature description is shown in Table1. There are two hidden layers with totally 16 hidden neurons. The output layer produces the trust value of SW, so the result of SW trust evaluation depends on a set of individual trust parameters rather than duality parameters. Likewise, the output of the FNN algorithm will be stored on the blockchain.Table 1
The input features of the FNN algorithm.
Input featuresDescription of the input featuresNumber of the target SW collaboratorsA collection of collaborators for the target SW, including collaborator identities. An integer representing the number of SW’s collaboratorsci∈0,2000Average trust value of SW collaboratorsA real number between 0 and 1, where 0 and 1 represent the honest collaborator and dishonest collaborator, respectively.Number of SW’s conspiratorsAn integer representing the number of SW’s conspiratorsμi∈0,2000.Current number of SW participating behaviorsThe latest uiv shared and statistical behavior characteristics, represented as a real numberparinew∈0,100Current number of SW rejected behaviorsThe latest uiv shared and statistical behavior characteristics, represented as a real numberrejinew∈0,100Current number of SW leak behaviorsThe latest uiv shared and statistical behavior characteristics, represented as a real numberlekinew∈0,50Current number of SW keep-secret behaviorsThe latest uiv shared and statistical behavior characteristics, represented as a real numbersecinew∈0,50Number of SW historical participating behaviorsPrevious uiv shared and statistical behavior characteristics, represented as a real numberpariold∈0,100Number of SW historical rejected behaviorsPrevious uiv shared and statistical behavior characteristics, represented as a real numberrejiold∈0,100Number of SW historical leak behaviorsPrevious uiv shared and statistical behavior characteristics, represented as a real numberlekiold∈0,50Number of SW historical keep-secret behaviorsPrevious uiv shared and statistical behavior characteristics, represented as a real numberseciold∈0,50As we know, it is essential to learn which appropriate weights and biases that make FNN have good performance. The feedforward neural network based on BP (backpropagation) algorithm constructs the identification of plant and inverse controller. Formula (9) describes how the cost in a neural network is computed.(9)cost=∑j=0nL−1αjL−yj2,where αjL represents the j-th activation of the last neuron, and L represents the current layer. Then, the j-th activation of the previous layer is αjL−1. Assuming there are L hidden layers in total, then nL−1 represents the neuron in the last hidden layer before the output layer. In actual calculations, costs are always finding the differences of each neuron from the expected target output minus the current output.By introducing the feedforward neural network algorithm, the trust value of SWs can be calculated accurately and learn the potential behavior patterns among the malicious SWs. In this case, we further design the distinction rules can successfully identify which SWs are malicious.


#### 3.5.2. Distinction Rules

SWs can be split into honest, dishonest, and semihonest based on their trust value. (δh,δl,δm) are, respectively, set as the threshold of high, low, and medium trust value. The specific distinction rules are as follows:R1: forTri>δh, the SWi’s access request for an uiv message will be accepted. In this situation, SWi is classified as honest.R2: forTri<δl, the SWi’s access request for an uiv message will be rejected. In this situation, SWi is classified as dishonest.R3: forδl<Tri<δm, it is difficult to determine the access authorities of SWi. In this situation, SWi is classified as semihonest who may be suspiciously dishonest SWs.To validate the credibility of semihonest SWs, we can trace whether they have conspirators. Letμi· denote number of conspirators of SWi.Ifμi=0, there are no conspirators. Hence, SWi is temporarily considered as honest.Ifμi≥1, SWi may have several external conspirators. The trust value of SWi will be set to 0. As a result, SWi will be removed from the CVD and barred from rejoining.


#### 3.5.3. Trap External Conspirators

IfSWi is a semihonest SW, a false uiv message can be released to trap his external conspirators. This false uiv information is set to a valid time.Within the valid time, codepreleak will not trigger the protection payload and provide the feedback messages, which can be employed to build a set of leak path. Once an external conspirator is trapped, SWi can be regarded as dishonest.After the valid time, the protection payload is activated to destroy the false uiv message, so as not to spread too widely. Algorithm3 is performed to trap external conspirators.Algorithm 3: Pseudocode implementation of trap external conspirators.
(i)
Input:SWi(ii)
Output:pathi(1)
Init trust value of SW,pathi, μi number of conspirators of SW(2)
Tri evaluate based on the feedback ef, retrieves SW historical trust values Tri(3)
Ifδl<Tri<δmthen(4)
Release falsevulj to SW to induce unauthorized behavior, Ffalse=true(5)
SWi↔tokentracing Extract the tokentracing corresponding to the malicious SW(6)
μi++ increased number of SW conspirators(7)
If valid time expire then(8)
Invoke Self- Destruct(9)
Else:(10)
maccurrent not in pathi(11)
pathi add (maccurrent)(12)
End if(13)
Else(14)
Release normalvulj to SW.(15)
End if


## 3.1. System Architecture

To prevent uiv leakage, we first present the system architecture of the UIV-TSP scheme. Figure2 illustrates the overall system architecture of our scheme, which consists of the following entities:(1)
Trusted authority (TA): trusted authority is responsible for processing SW’s access requests, generating and updating dynamic token, and evaluating trust value ofSWi.(2)
Security workers (SWs): there exist some workers who access uiv information in the sharing environment to develop their mitigation measures. We describe three types of workers: (1) honest SWs who do not engage in unauthorized access; (2) semihonest SWs who have a chance of committing malicious behavior; (3) dishonest SWs who often leak uiv information. In this paper, SWs are defined asSW1,SW2…SWm.Figure 2
System architecture of the UIV-SP scheme.


## 3.2. Dynamic Token Management

We introduce dynamic token as the implicit access credential and traceability clue for an SW. As shown in Figure3, the lifecycle of dynamic token is consisted of generation and update.Figure 3
Lifecycle of dynamic tokens.


### 3.2.1. Token Generation

When an SW submits a new undisclosed vulnerabilityvulj, each internal SW is assigned a corresponding token called tokenaccess, which is only held by the system and cannot be seen by anyone. TA generates the initial tokenaccess through a hash function. Meanwhile, we define vulmeta as the meta information of an uiv. The initial tokenaccess can be calculated as follows:(1)tokenaccess=HSWivulmetatpnonce.Even if an SW is granted access through identify authentication, the uiv cannot be acquired without tokenaccess. Algorithm 1 is performed to generate and update tokenaccess.Algorithm 1: Pseudocode of token generation and update.
(i)
Input:SWi(ii)
Output: tokenaccess(1)
IfSWi in SWpoolthen(2)
tokenaccess=HSWi‖vulmeta‖tp‖nonce.(3)
If tokenaccess in blockchain then(4)
Update tokenaccess, tokenaccess↔SWi(5)
else(6)
Store tokenaccess, tokenaccess↔SWi(7)
If end of request access, then(8)
Revoke tokenaccess(9)
tokentracing⟵Htokenaccess‖maccurrent(10)
tokenaccess⟵HSWi‖vulmeta‖tp‖nonce′(11)
Store tokenaccess, SWi↔tokentracing(12)
Embedtokentracing to vulj(13)
End If(14)
End If(15)
End If


### 3.2.2. Token Update

To avoid malicious inference, we integrate a one-time random number into the hash generation of token to update token dynamically. At the end of SW access, tokenaccess will be update as follows:(2)tokenaccess⟵HSWivulmetatpnonce′.Meanwhile, the current tokenaccess and the MAC address of the SW are hashed to create the traceability token called tokentracing. Tokentracing can be defined as follows:(3)tokentracing⟵Htokenaccess‖maccurrent.In our scheme, tokentracing can be stealthily sneaked into the acquired vulj information as the traceability credential. The execution strategies of dynamic token management can be executed with four steps, the more details are given in [29].


## 3.2.1. Token Generation

When an SW submits a new undisclosed vulnerabilityvulj, each internal SW is assigned a corresponding token called tokenaccess, which is only held by the system and cannot be seen by anyone. TA generates the initial tokenaccess through a hash function. Meanwhile, we define vulmeta as the meta information of an uiv. The initial tokenaccess can be calculated as follows:(1)tokenaccess=HSWivulmetatpnonce.Even if an SW is granted access through identify authentication, the uiv cannot be acquired without tokenaccess. Algorithm 1 is performed to generate and update tokenaccess.Algorithm 1: Pseudocode of token generation and update.
(i)
Input:SWi(ii)
Output: tokenaccess(1)
IfSWi in SWpoolthen(2)
tokenaccess=HSWi‖vulmeta‖tp‖nonce.(3)
If tokenaccess in blockchain then(4)
Update tokenaccess, tokenaccess↔SWi(5)
else(6)
Store tokenaccess, tokenaccess↔SWi(7)
If end of request access, then(8)
Revoke tokenaccess(9)
tokentracing⟵Htokenaccess‖maccurrent(10)
tokenaccess⟵HSWi‖vulmeta‖tp‖nonce′(11)
Store tokenaccess, SWi↔tokentracing(12)
Embedtokentracing to vulj(13)
End If(14)
End If(15)
End If


## 3.2.2. Token Update

To avoid malicious inference, we integrate a one-time random number into the hash generation of token to update token dynamically. At the end of SW access, tokenaccess will be update as follows:(2)tokenaccess⟵HSWivulmetatpnonce′.Meanwhile, the current tokenaccess and the MAC address of the SW are hashed to create the traceability token called tokentracing. Tokentracing can be defined as follows:(3)tokentracing⟵Htokenaccess‖maccurrent.In our scheme, tokentracing can be stealthily sneaked into the acquired vulj information as the traceability credential. The execution strategies of dynamic token management can be executed with four steps, the more details are given in [29].


## 3.3. Blockchain-Assisted Continuous Logs Storage

Due to the advantages including transparency, traceability, and tamper-proofing, many studies have integrated blockchain into the prior works to implement a reliable and efficient data storage [30]. In general, there are three types of blockchain data storage patterns [31]:(1)
Public blockchain: a public blockchain is the blockchain that can read by anyone in the world, anyone can send transactions to and expect to see them included, if they are valid, and anyone can participate in the consensus process, which determines what blocks get added to the chain and what the current state is.(2)
Private blockchain: a private blockchain is the blockchain where can write by only one organization.(3)
Consortium blockchain: a consortium blockchain is the blockchain where the consensus process is controlled by a preselected set of miners.Since token can only be held by the system, the public blockchain does not meet the requirements. Hence, a private blockchain-assisted storage method is designed to centralized storage logs. To prevent attackers from tampering with data, the logs of SWs’ activities in the shared process should also be continuously recorded on the blockchain. These continuous logs, including dynamic token, trust value of SW (Tri), and behaviors record (Ri), are also only held by the system. It can be found that the private blockchain is suitable for our scheme.In the blockchain, the block structure of continuous logs storage is shown in Figure4.Figure 4
Block structure of continuous logs storage.


### 3.3.1. Block Head

The block head is slightly different from the traditional structure. Except for previous hash, timestamp, Merkle root, and block ID, several new elements are integrated into the block head:(i)
SWi: the ID of the i-th SW who requests the undisclosed vulnerability in the sharing environment.(ii)
Tri: the trust value of SWi. In the block head, Tri can be quickly retrieved by TA.(iii)
vulmeta: the meta information of an undisclosed IIoT vulnerability.


### 3.3.2. Block Body

In the block body, the log data of an SW (such asSWi) are hashed to build the Merkle tree. Except for tokenaccess and tokentracing, the log data of SWi contain the following elements:(i)
seciold,lekiold: the historical trust data of SWi, which can be used to evaluate the trust value of SWi before the access.(ii)
secinew,lekinew: the current trust data of SWi, which can be used to update the trust value of SWi after the access.(iii)
Ri: the access request record of SWi to an uiv information.(iv)
Ffalse: the flag whether a false uiv information has been released.


## 3.3.1. Block Head

The block head is slightly different from the traditional structure. Except for previous hash, timestamp, Merkle root, and block ID, several new elements are integrated into the block head:(i)
SWi: the ID of the i-th SW who requests the undisclosed vulnerability in the sharing environment.(ii)
Tri: the trust value of SWi. In the block head, Tri can be quickly retrieved by TA.(iii)
vulmeta: the meta information of an undisclosed IIoT vulnerability.


## 3.3.2. Block Body

In the block body, the log data of an SW (such asSWi) are hashed to build the Merkle tree. Except for tokenaccess and tokentracing, the log data of SWi contain the following elements:(i)
seciold,lekiold: the historical trust data of SWi, which can be used to evaluate the trust value of SWi before the access.(ii)
secinew,lekinew: the current trust data of SWi, which can be used to update the trust value of SWi after the access.(iii)
Ri: the access request record of SWi to an uiv information.(iv)
Ffalse: the flag whether a false uiv information has been released.


## 3.4. Internal Leakage Prevention with One-Step Traceability

To prevent SWs leaking the acquiredvulj information, vulj should be self-destruct when they leave the host of SWs one-step. Thus, we design a benign self-triggering logic bomb codepreleak. A logic bomb is a piece of code consisting of a trigger condition and a payload; when the trigger condition is met, the bomb is triggered (or activated) and the payload code gets executed [32].codepreleak is composed of trigger condition and response payloads. The trigger condition is designed to detect the access environment difference between honest SWs and dishonest SWs, so that the protection payload will be activated to destroy vulj on the leakage side.As shown in Figure5, the functional structure of codepreleak is consisted of self-checking and self-destruct.Figure 5
Functional structure of codepreleak.


### 3.4.1. Self-Check

Once the uiv information enters the SW host, codepreleak will extract the current SW host Mac address and the revoked token to compute the verification value. Then, codepreleak will match the verification value to tokentracing. If the result Vc is inconsistent, it will trigger self-destruct. Vc can be calculated as follows:(4)Vc⟵tokentracing==Htokenaccess,maccurrent?.Algorithm2 is performed to match verification value.Algorithm 2: Pseudocode implementation of Match verification value and self-destruct.
(i)
Input: uiv(ii)
Output: access/deny(1)
tokentracing=extractvulj(2)
If tokentracingnot invulj(3)
Go to step 15.(4)
Else(5)
AcquireMACcurrent(6)
Vc⟵tokentracing==Htokenaccess,maccurrent?(7)
IfVc=1then(8)
Assign access authorities(9)
IfExtractvulj==Ffalsethen(10)
Go to step 8.(11)
Else(12)
Send an encrypted feedback messageef to TA.(13)
Destroy the targetvulj(14)
End if(15)
End if


### 3.4.2. Self-Destruct

IfVc=0, the leakage has not happened. That is, the uiv information has not left the SW host. The protection payload continues to lurk.IfVc=1, it may leak vulj. That is, the uiv information has left the SW host. In this case, the protection payload will be activated immediately to destroy vulj.At the same time as the self-destruct event,codepreleak can automatically send encrypted feedback ef=tokentracing,vulj,SWi,maccurrent,tfeedback to TA.(i)
vulj: the ID of undisclosed IIoT vulnerability.(ii)
tfeedback: the time to codepreleak send the feedback message.Algorithm2 is performed to activate the protection payload.


## 3.4.1. Self-Check

Once the uiv information enters the SW host, codepreleak will extract the current SW host Mac address and the revoked token to compute the verification value. Then, codepreleak will match the verification value to tokentracing. If the result Vc is inconsistent, it will trigger self-destruct. Vc can be calculated as follows:(4)Vc⟵tokentracing==Htokenaccess,maccurrent?.Algorithm2 is performed to match verification value.Algorithm 2: Pseudocode implementation of Match verification value and self-destruct.
(i)
Input: uiv(ii)
Output: access/deny(1)
tokentracing=extractvulj(2)
If tokentracingnot invulj(3)
Go to step 15.(4)
Else(5)
AcquireMACcurrent(6)
Vc⟵tokentracing==Htokenaccess,maccurrent?(7)
IfVc=1then(8)
Assign access authorities(9)
IfExtractvulj==Ffalsethen(10)
Go to step 8.(11)
Else(12)
Send an encrypted feedback messageef to TA.(13)
Destroy the targetvulj(14)
End if(15)
End if


## 3.4.2. Self-Destruct

IfVc=0, the leakage has not happened. That is, the uiv information has not left the SW host. The protection payload continues to lurk.IfVc=1, it may leak vulj. That is, the uiv information has left the SW host. In this case, the protection payload will be activated immediately to destroy vulj.At the same time as the self-destruct event,codepreleak can automatically send encrypted feedback ef=tokentracing,vulj,SWi,maccurrent,tfeedback to TA.(i)
vulj: the ID of undisclosed IIoT vulnerability.(ii)
tfeedback: the time to codepreleak send the feedback message.Algorithm2 is performed to activate the protection payload.


## 3.5. Trust-Based SWs Distinction

Trust mechanism can be adopted to evaluate the trust value of SWs according to their historical behaviors. With trust value, we can quickly distinguish honest SWs and dishonest SWs. For semihonest SWs, we can further validate their credibility by tracing whether they have external conspirators. Different SWs will gain different access authorities to acquire uiv information.


### 3.5.1. Trust Value Evaluation

In the process of vulnerabilities information sharing, the behaviors of an SW are generally dualistic: secret-keeping and leakage. With trust mechanism, if an SW often leaks information, he will get a low trust value.To quantify these duality behaviors, the beta function is one of the most popular trust value evaluation methods. It first counts the number of secret-keeping and leakage by an SW and then calculates the trust value with beta function denoted byBetaα,β [33].(5)Betaα,β=Γα,βΓαΓβθα−11−θβ−1,where θ is the probability of duality behaviors, 0≤θ≤1, α>0,β>0.TakeSWi as an example, seci and leki denote the number of secret-keeping and leakage in the sharing environment, respectively. The expectation value of the beta function can be calculated as follows: EBetaα,β=α/α+β. Considering that the trust value BTi is limited in the interval [0, 1], BTi can be described as follows:(6)BTi=1+seci1+seci+leki.Whenseci≥1 and leki=0, BTi is always calculated as 1. The SWi is completely trusted under this condition.Obviously, the base trust valueBTi that decays too slowly will give dishonest SWs more opportunities to leak. So, it is very essential to introduce a penalty factor, which can be calculated as follows:(7)Pi=e−seci+leki/seci.With the punishment ofPi to BTi, the trust value Tri of SW can be further evaluated as follows:(8)Tri=1+seci1+seci+leki⋅e−seci+leki/seci,leki<seci,0,leki≥seci.In the (8), the Tri means the comprehensive trust value of SWs, which introduces a penalty factor to cause Tri to decrease faster when leakage occurs. Unfortunately, the trust mechanism utilizing the beta reputation engine is suitable for scenarios with a small amount of trust data. When the trustworthiness of SWi is not represented by duality behaviors, as in the case of the collusion clique construction, it is possible for some malicious SWs to exhibit rational behaviors to avoid the detection. That is, they can keep high trust value in an alternant process by truly sharing their uiv information or leaking uiv information to their conspirators.To suppress such behaviors, the special reputation engine is adopted to prevent the SW trust value growth of some rational conspirators at the uiv information sharing. Once the TA receives messages from an SW regarding some uiv information requests, the trust value of the SW will calculate by applying the feedforward neural network (FNN) algorithm [34], which is depicted in Figure 6.Figure 6
Structure of the feedforward neural network.The input layer of FNN consists of 11 input nodes, such as the collaborators of the target SW, the average trust value of SW collaborators, and the number of SW’s conspirators. The complete input feature description is shown in Table1. There are two hidden layers with totally 16 hidden neurons. The output layer produces the trust value of SW, so the result of SW trust evaluation depends on a set of individual trust parameters rather than duality parameters. Likewise, the output of the FNN algorithm will be stored on the blockchain.Table 1
The input features of the FNN algorithm.
Input featuresDescription of the input featuresNumber of the target SW collaboratorsA collection of collaborators for the target SW, including collaborator identities. An integer representing the number of SW’s collaboratorsci∈0,2000Average trust value of SW collaboratorsA real number between 0 and 1, where 0 and 1 represent the honest collaborator and dishonest collaborator, respectively.Number of SW’s conspiratorsAn integer representing the number of SW’s conspiratorsμi∈0,2000.Current number of SW participating behaviorsThe latest uiv shared and statistical behavior characteristics, represented as a real numberparinew∈0,100Current number of SW rejected behaviorsThe latest uiv shared and statistical behavior characteristics, represented as a real numberrejinew∈0,100Current number of SW leak behaviorsThe latest uiv shared and statistical behavior characteristics, represented as a real numberlekinew∈0,50Current number of SW keep-secret behaviorsThe latest uiv shared and statistical behavior characteristics, represented as a real numbersecinew∈0,50Number of SW historical participating behaviorsPrevious uiv shared and statistical behavior characteristics, represented as a real numberpariold∈0,100Number of SW historical rejected behaviorsPrevious uiv shared and statistical behavior characteristics, represented as a real numberrejiold∈0,100Number of SW historical leak behaviorsPrevious uiv shared and statistical behavior characteristics, represented as a real numberlekiold∈0,50Number of SW historical keep-secret behaviorsPrevious uiv shared and statistical behavior characteristics, represented as a real numberseciold∈0,50As we know, it is essential to learn which appropriate weights and biases that make FNN have good performance. The feedforward neural network based on BP (backpropagation) algorithm constructs the identification of plant and inverse controller. Formula (9) describes how the cost in a neural network is computed.(9)cost=∑j=0nL−1αjL−yj2,where αjL represents the j-th activation of the last neuron, and L represents the current layer. Then, the j-th activation of the previous layer is αjL−1. Assuming there are L hidden layers in total, then nL−1 represents the neuron in the last hidden layer before the output layer. In actual calculations, costs are always finding the differences of each neuron from the expected target output minus the current output.By introducing the feedforward neural network algorithm, the trust value of SWs can be calculated accurately and learn the potential behavior patterns among the malicious SWs. In this case, we further design the distinction rules can successfully identify which SWs are malicious.


### 3.5.2. Distinction Rules

SWs can be split into honest, dishonest, and semihonest based on their trust value. (δh,δl,δm) are, respectively, set as the threshold of high, low, and medium trust value. The specific distinction rules are as follows:R1: forTri>δh, the SWi’s access request for an uiv message will be accepted. In this situation, SWi is classified as honest.R2: forTri<δl, the SWi’s access request for an uiv message will be rejected. In this situation, SWi is classified as dishonest.R3: forδl<Tri<δm, it is difficult to determine the access authorities of SWi. In this situation, SWi is classified as semihonest who may be suspiciously dishonest SWs.To validate the credibility of semihonest SWs, we can trace whether they have conspirators. Letμi· denote number of conspirators of SWi.Ifμi=0, there are no conspirators. Hence, SWi is temporarily considered as honest.Ifμi≥1, SWi may have several external conspirators. The trust value of SWi will be set to 0. As a result, SWi will be removed from the CVD and barred from rejoining.


### 3.5.3. Trap External Conspirators

IfSWi is a semihonest SW, a false uiv message can be released to trap his external conspirators. This false uiv information is set to a valid time.Within the valid time, codepreleak will not trigger the protection payload and provide the feedback messages, which can be employed to build a set of leak path. Once an external conspirator is trapped, SWi can be regarded as dishonest.After the valid time, the protection payload is activated to destroy the false uiv message, so as not to spread too widely. Algorithm3 is performed to trap external conspirators.Algorithm 3: Pseudocode implementation of trap external conspirators.
(i)
Input:SWi(ii)
Output:pathi(1)
Init trust value of SW,pathi, μi number of conspirators of SW(2)
Tri evaluate based on the feedback ef, retrieves SW historical trust values Tri(3)
Ifδl<Tri<δmthen(4)
Release falsevulj to SW to induce unauthorized behavior, Ffalse=true(5)
SWi↔tokentracing Extract the tokentracing corresponding to the malicious SW(6)
μi++ increased number of SW conspirators(7)
If valid time expire then(8)
Invoke Self- Destruct(9)
Else:(10)
maccurrent not in pathi(11)
pathi add (maccurrent)(12)
End if(13)
Else(14)
Release normalvulj to SW.(15)
End if


## 3.5.1. Trust Value Evaluation

In the process of vulnerabilities information sharing, the behaviors of an SW are generally dualistic: secret-keeping and leakage. With trust mechanism, if an SW often leaks information, he will get a low trust value.To quantify these duality behaviors, the beta function is one of the most popular trust value evaluation methods. It first counts the number of secret-keeping and leakage by an SW and then calculates the trust value with beta function denoted byBetaα,β [33].(5)Betaα,β=Γα,βΓαΓβθα−11−θβ−1,where θ is the probability of duality behaviors, 0≤θ≤1, α>0,β>0.TakeSWi as an example, seci and leki denote the number of secret-keeping and leakage in the sharing environment, respectively. The expectation value of the beta function can be calculated as follows: EBetaα,β=α/α+β. Considering that the trust value BTi is limited in the interval [0, 1], BTi can be described as follows:(6)BTi=1+seci1+seci+leki.Whenseci≥1 and leki=0, BTi is always calculated as 1. The SWi is completely trusted under this condition.Obviously, the base trust valueBTi that decays too slowly will give dishonest SWs more opportunities to leak. So, it is very essential to introduce a penalty factor, which can be calculated as follows:(7)Pi=e−seci+leki/seci.With the punishment ofPi to BTi, the trust value Tri of SW can be further evaluated as follows:(8)Tri=1+seci1+seci+leki⋅e−seci+leki/seci,leki<seci,0,leki≥seci.In the (8), the Tri means the comprehensive trust value of SWs, which introduces a penalty factor to cause Tri to decrease faster when leakage occurs. Unfortunately, the trust mechanism utilizing the beta reputation engine is suitable for scenarios with a small amount of trust data. When the trustworthiness of SWi is not represented by duality behaviors, as in the case of the collusion clique construction, it is possible for some malicious SWs to exhibit rational behaviors to avoid the detection. That is, they can keep high trust value in an alternant process by truly sharing their uiv information or leaking uiv information to their conspirators.To suppress such behaviors, the special reputation engine is adopted to prevent the SW trust value growth of some rational conspirators at the uiv information sharing. Once the TA receives messages from an SW regarding some uiv information requests, the trust value of the SW will calculate by applying the feedforward neural network (FNN) algorithm [34], which is depicted in Figure 6.Figure 6
Structure of the feedforward neural network.The input layer of FNN consists of 11 input nodes, such as the collaborators of the target SW, the average trust value of SW collaborators, and the number of SW’s conspirators. The complete input feature description is shown in Table1. There are two hidden layers with totally 16 hidden neurons. The output layer produces the trust value of SW, so the result of SW trust evaluation depends on a set of individual trust parameters rather than duality parameters. Likewise, the output of the FNN algorithm will be stored on the blockchain.Table 1
The input features of the FNN algorithm.
Input featuresDescription of the input featuresNumber of the target SW collaboratorsA collection of collaborators for the target SW, including collaborator identities. An integer representing the number of SW’s collaboratorsci∈0,2000Average trust value of SW collaboratorsA real number between 0 and 1, where 0 and 1 represent the honest collaborator and dishonest collaborator, respectively.Number of SW’s conspiratorsAn integer representing the number of SW’s conspiratorsμi∈0,2000.Current number of SW participating behaviorsThe latest uiv shared and statistical behavior characteristics, represented as a real numberparinew∈0,100Current number of SW rejected behaviorsThe latest uiv shared and statistical behavior characteristics, represented as a real numberrejinew∈0,100Current number of SW leak behaviorsThe latest uiv shared and statistical behavior characteristics, represented as a real numberlekinew∈0,50Current number of SW keep-secret behaviorsThe latest uiv shared and statistical behavior characteristics, represented as a real numbersecinew∈0,50Number of SW historical participating behaviorsPrevious uiv shared and statistical behavior characteristics, represented as a real numberpariold∈0,100Number of SW historical rejected behaviorsPrevious uiv shared and statistical behavior characteristics, represented as a real numberrejiold∈0,100Number of SW historical leak behaviorsPrevious uiv shared and statistical behavior characteristics, represented as a real numberlekiold∈0,50Number of SW historical keep-secret behaviorsPrevious uiv shared and statistical behavior characteristics, represented as a real numberseciold∈0,50As we know, it is essential to learn which appropriate weights and biases that make FNN have good performance. The feedforward neural network based on BP (backpropagation) algorithm constructs the identification of plant and inverse controller. Formula (9) describes how the cost in a neural network is computed.(9)cost=∑j=0nL−1αjL−yj2,where αjL represents the j-th activation of the last neuron, and L represents the current layer. Then, the j-th activation of the previous layer is αjL−1. Assuming there are L hidden layers in total, then nL−1 represents the neuron in the last hidden layer before the output layer. In actual calculations, costs are always finding the differences of each neuron from the expected target output minus the current output.By introducing the feedforward neural network algorithm, the trust value of SWs can be calculated accurately and learn the potential behavior patterns among the malicious SWs. In this case, we further design the distinction rules can successfully identify which SWs are malicious.


## 3.5.2. Distinction Rules

SWs can be split into honest, dishonest, and semihonest based on their trust value. (δh,δl,δm) are, respectively, set as the threshold of high, low, and medium trust value. The specific distinction rules are as follows:R1: forTri>δh, the SWi’s access request for an uiv message will be accepted. In this situation, SWi is classified as honest.R2: forTri<δl, the SWi’s access request for an uiv message will be rejected. In this situation, SWi is classified as dishonest.R3: forδl<Tri<δm, it is difficult to determine the access authorities of SWi. In this situation, SWi is classified as semihonest who may be suspiciously dishonest SWs.To validate the credibility of semihonest SWs, we can trace whether they have conspirators. Letμi· denote number of conspirators of SWi.Ifμi=0, there are no conspirators. Hence, SWi is temporarily considered as honest.Ifμi≥1, SWi may have several external conspirators. The trust value of SWi will be set to 0. As a result, SWi will be removed from the CVD and barred from rejoining.


## 3.5.3. Trap External Conspirators

IfSWi is a semihonest SW, a false uiv message can be released to trap his external conspirators. This false uiv information is set to a valid time.Within the valid time, codepreleak will not trigger the protection payload and provide the feedback messages, which can be employed to build a set of leak path. Once an external conspirator is trapped, SWi can be regarded as dishonest.After the valid time, the protection payload is activated to destroy the false uiv message, so as not to spread too widely. Algorithm3 is performed to trap external conspirators.Algorithm 3: Pseudocode implementation of trap external conspirators.
(i)
Input:SWi(ii)
Output:pathi(1)
Init trust value of SW,pathi, μi number of conspirators of SW(2)
Tri evaluate based on the feedback ef, retrieves SW historical trust values Tri(3)
Ifδl<Tri<δmthen(4)
Release falsevulj to SW to induce unauthorized behavior, Ffalse=true(5)
SWi↔tokentracing Extract the tokentracing corresponding to the malicious SW(6)
μi++ increased number of SW conspirators(7)
If valid time expire then(8)
Invoke Self- Destruct(9)
Else:(10)
maccurrent not in pathi(11)
pathi add (maccurrent)(12)
End if(13)
Else(14)
Release normalvulj to SW.(15)
End if


## 4. Performance Analysis

In this section, we conduct performance analysis on the UIV-TSP scheme. We analyze the security of the proposed scheme and then perform computer simulation to further analyze the cost of the proposed scheme.


### 4.1. Security Analysis

In this section, we analyze how UIV-TSP can achieve the following security requirements: uiv sharing against leakage, blockchain storage against continuous logs tampering. To analyze the security better, we also compare UIV-TSP with some typical data leakage prevention (DLP) schemes in Table2.Table 2
Comparison of data leak prevention scheme.
SchemeData leakage preventingTransmission confidentialityContinuous logs tamperingUIV-TSPYesYesYesCROTNoNoNoADSNoYesNoR-ADSNoYesNoE-ADSNoYesNo


#### 4.1.1. UIV Sharing against Internal Leakage

Challenge 1: Dishonest SW may disclose uiv to cause a large-scale damage.Lemma 1.
UIV-TSP is resistant internal leakage for uiv.Proof.
In the UIV-TSP scheme, a benign logic bomb calledcodepreleak is embedded into the uiv message, which checks that whether the current MAC address is the same as the present destination address in tokentracing. The MAC address of the device is always fixed, it is impossible to be modified. Furthermore, the tokentracing is calculated by the hash operation h⋅, and tokenaccess that is dynamically updated at the end of each uiv access. The dual dynamics ensures that tokentracing cannot be inferred. According to Vc⟵tokentracing==Htokenaccess,maccurrent?, Vc=1 makes the protection payload be activated immediately to destroy vulj, so it is believed that our UIV-TSP scheme can resist uiv leakage.


#### 4.1.2. Blockchain Storage against Continuous Logs Tampering

Challenge 2: the trusted sharing environment with leakage-resilience construction relies on the trust value evaluation. Trust mechanisms evaluate the trust value of SWs according to their historical behaviors. Attackers can tamper with their historical logs to disturb trust mechanism and promote their trust quickly. Therefore, it is impossible to distinguish honest SWs.Lemma 2.
UIV-TSP is resistant to continuous logs tampering.Proof.
In our UIV-TSP scheme, a blockchain-assisted method to store the continuous logs of all SWs for the trusted sharing environment with leakage-resilience construction. The original token and its all-subsequent updates should be stored on the blockchain, which is a sequence of blocks, which holds a complete list of transaction records like conventional public ledger. Each block points to the immediately previous block via a reference that is essentially a hash value of the previous block called parent block [35]. Just like a linked list, each block depends on its previous block. Therefore, if the continuous logs maintained in a block are tampered, its latter blocks chained on the blockchain must be modified. Obviously, the longer the blockchain created, the higher cost it takes to tamper with a block. Assuming the number of latter blocks related on Block p is lp under the condition that there are a number of sharing regions, the number of blocks that need to be tampered (tp) is calculated as follows:(10)tp=pm+pm2+…+pmlp=pmlp+1−pmpm−1.
For instance,tp=1,398,100 when nr=4 and lp=10.
Therefore, it is nearly impossible to tamper with the continuous logs maintained in Blockp due to the huge resource consumption.


### 4.2. Experimental Analysis

We perform simulations to validate the performance of the UIV-TSP scheme in Python 3.7.6, combined with NumPy, pandas, matplotlib, keras, TensorFlow, and other python libraries. The default simulation elements are shown in Table3.Table 3
Description of simulation elements.
ParametersDescriptionDefaultSWiNumber of SWs2000perPercentage of dishonest SWs10%–50%δThreshold of trust value(0.2, 0.5, 0.8)CycleNumber of cycle simulation200εEmbedded times of access credential(1, 2, 3, 4)kThe length of access credential(256, 512, 1024)The simulations are executed in cycle-based manner. At each cycle, a certain percentage of SWs are randomly selected as dishonest SWs. The behavioral pattern of honest SW is modeled to always keep secret, while dishonest SWs may leak an uiv message sometimes. Without punishment, dishonest SWs will hinder the establishment of a trusted vulnerability message sharing environment. In this section, the performance and overload of the proposed UIV-TSP scheme are experimentally evaluated under various settings.The simulation uses 2,000 SWs to generate 399,284 access record samples for training. Meanwhile, all the data generated are outputted to a.csv file. The proportion of benign access record samples to malicious access record samples in the training set is almost 1 : 1. Then, the data used are split to 70% training, and 30% validation.After dividing the dataset, this paper uses the Adam optimization algorithm to obtain the optimal parameter combination, such as learning rate, epochs, and batch size. Then, the parameters obtained are used for feedforward neural network training, and the performance is evaluated by cross validation. Figure7 shows the variation of model scores under different learning rates. The x-coordinate represents the learning rate, while the y-coordinate represents the model score. The shaded graph indicates the fluctuation range of the model score for this training. It can be seen that the training score and testing score reach the optimal value when the learning rate is 0.1, epoch = 10, and batch_size = 16.Figure 7
FNN learning rate score.In order to evaluate the performance of the trust mechanism based on FNN algorithm, we analyze four evaluation metrics, namely, precision (P), recall (R), accuracy (A), and F1-score (F1). In this paper, the precision and recall are defined as follows:(11)A=number of truly SWs detectedtotal number of SWs=TP+TNTP+TN+FP+FN,R=number of truly malicious SWs detectedtotal number of truly malicious SWs=TPTP+FN,P=number of truly malicious SWs detectedtotal number of malicious SWs=TPTP+FP,F1=2∗P∗RP+R.We compare the performance of feedforward neural network (FNN) for identifying malicious SWs with two other well-known deep learning models, namely, recurrent neural network (RNN) and convolutional neural network (CNN). Table4 shows that the FNN performs best in terms of the accuracy, recall, precision, and F1-score. In addition, FNN clearly lower than the other algorithms in terms of the training time costs. That is because the FNN algorithm has obvious advantages in network structure, and owns simpler node connections than RNN. Due to the convolution operation, CNN will require more computation. Therefore, we conclude that FNN is a suitable deep learning algorithm for SW trust evaluation.Table 4
Comparison of the performance of different algorithms.
AccuracyRecallPrecisionF1-scoreTime (s)FNNTrain0.97510.95180.95460.9532228Test0.97360.90500.91420.9096CNNTrain0.74280.83700.64860.7306337Test0.74220.83660.64810.7305RNNTrain0.88040.84550.84470.8452410Test0.87800.84540.84470.8449Then, we analyze the detection and false alarm rate of our UIV-TSP scheme (i.e., probability of successful detection leaker) in Figures8 and 9. To analyze the effectiveness better, we compare UIV-TSP with the undisclosed IIoT vulnerabilities sharing protection (UIV-SP) scheme without trust mechanism.Figure 8
Detection rate under the percentage of dishonest SWs.Figure 9
Alarm rate under the percentage of dishonest SWs.In this simulation, the detection rate of UIV-TSP is better than UIV-SP in Figure8, while the false alarm rate of UIV-TSP is lower than UIV-SP in Figure 9. Therefore, our designed trust mechanism can improve the performance of UIV-SP distinctly in the construction of trusted sharing environment.Then, we validate the performance of our UIV-TSP scheme against dishonest SWs, in terms of suppressing leakage behaviors. Dishonest SWs will leak uiv in the sharing environment. Consequently, some leakage behaviors may generate in each cycle, which may cause unnecessary waste of network resources. So, the key performance indicator of UIV-TSP is to suppress these leakage behaviors. As shown in Figure10, it is obvious that UIV-TSP is better than UIV-SP in suppressing leakage behaviors. This means that the trust mechanism plays a key role in the detection of dishonest SWs. In this simulation, δ is set as (0.2, 0.5, 0.8), respectively.Figure 10
Suppressing leakage behaviors.We also analyze the uiv leakage prevention performance of UIV-TSP in terms of leakage probability. In this simulation, the percentage of dishonest SWs is set as 30%, respectively. As shown in Figure11, the uiv leakage probability of UIV-TSP is also lower than UIV-SP.Figure 11
Probability of leakage at differentδ. (a) δ=0.8. (b) δ=0.5. (c) δ=0.2.
(a)(b)(c)Finally, we evaluate the traceability performance of UIV-TSP in terms of computational complexity. We count the number of time-consuming operations such as the symmetric-key encryption/decryption (SKE), public-key encryption/decryption (PKE), cryptographic hash function (HASH), and exponential operation (EXP) inGq multiplicative operation (MUL) in Gq. As shown in Table 5, we compare UIV-TSP with three types of traditional schemes.Table 5
Computational complexity.
SKEHASHPKEEXPMULCROT4t8t3t6t + 32t + 1ADS2t2tN/AN/AN/AR-ADS2t2tN/AN/A4kt + 2tOurs workN/A3tN/AN/AN/AIt can be found that UIV-TSP cannot require any exponential operation or public-key encryption/decryption. Moreover, the requirements for hash and symmetric key operations are limited in UIV-TSP.To further evaluate the traceability performance of UIV-TSP in terms of computational complexity, we can observe the traceability delay of UIV-TSP and these traditional schemes.We run 200 rounds of experiments and obtain their average traceability delay as the result. We definek as the length of access credential. In our UIV-TSP scheme, the access credential is a dynamic token. In the traditional schemes, the access credential is the private key of a user. A sufficient length of k can contribute to the collision resistance generated by hashing. As the length of k increases, the user capacity will be improved. Of course, with the increase of k and the embedded times of access credential, the traceability delay grows as well. As shown in Figure 12, UIV-TSP is more computationally efficient than ADS and CROT. The reason is that the sharing data in UIV-TSP need not to perform oblivious transfer (OT) and zero-knowledge proof. Once the embedded times vary from 1 to 4, the number of OT increases linearly.Figure 12
Average tracing delay. (a)k = 256. (b) k = 512. (c) k = 1024.
(a)(b)(c)In summary, our UIV-TSP scheme can prevent the uiv information leakage effectively, which merely requires limited traceability delay caused by multiple shared SWs.


## 4.1. Security Analysis

In this section, we analyze how UIV-TSP can achieve the following security requirements: uiv sharing against leakage, blockchain storage against continuous logs tampering. To analyze the security better, we also compare UIV-TSP with some typical data leakage prevention (DLP) schemes in Table2.Table 2
Comparison of data leak prevention scheme.
SchemeData leakage preventingTransmission confidentialityContinuous logs tamperingUIV-TSPYesYesYesCROTNoNoNoADSNoYesNoR-ADSNoYesNoE-ADSNoYesNo


### 4.1.1. UIV Sharing against Internal Leakage

Challenge 1: Dishonest SW may disclose uiv to cause a large-scale damage.Lemma 1.
UIV-TSP is resistant internal leakage for uiv.Proof.
In the UIV-TSP scheme, a benign logic bomb calledcodepreleak is embedded into the uiv message, which checks that whether the current MAC address is the same as the present destination address in tokentracing. The MAC address of the device is always fixed, it is impossible to be modified. Furthermore, the tokentracing is calculated by the hash operation h⋅, and tokenaccess that is dynamically updated at the end of each uiv access. The dual dynamics ensures that tokentracing cannot be inferred. According to Vc⟵tokentracing==Htokenaccess,maccurrent?, Vc=1 makes the protection payload be activated immediately to destroy vulj, so it is believed that our UIV-TSP scheme can resist uiv leakage.


### 4.1.2. Blockchain Storage against Continuous Logs Tampering

Challenge 2: the trusted sharing environment with leakage-resilience construction relies on the trust value evaluation. Trust mechanisms evaluate the trust value of SWs according to their historical behaviors. Attackers can tamper with their historical logs to disturb trust mechanism and promote their trust quickly. Therefore, it is impossible to distinguish honest SWs.Lemma 2.
UIV-TSP is resistant to continuous logs tampering.Proof.
In our UIV-TSP scheme, a blockchain-assisted method to store the continuous logs of all SWs for the trusted sharing environment with leakage-resilience construction. The original token and its all-subsequent updates should be stored on the blockchain, which is a sequence of blocks, which holds a complete list of transaction records like conventional public ledger. Each block points to the immediately previous block via a reference that is essentially a hash value of the previous block called parent block [35]. Just like a linked list, each block depends on its previous block. Therefore, if the continuous logs maintained in a block are tampered, its latter blocks chained on the blockchain must be modified. Obviously, the longer the blockchain created, the higher cost it takes to tamper with a block. Assuming the number of latter blocks related on Block p is lp under the condition that there are a number of sharing regions, the number of blocks that need to be tampered (tp) is calculated as follows:(10)tp=pm+pm2+…+pmlp=pmlp+1−pmpm−1.
For instance,tp=1,398,100 when nr=4 and lp=10.
Therefore, it is nearly impossible to tamper with the continuous logs maintained in Blockp due to the huge resource consumption.


## 4.1.1. UIV Sharing against Internal Leakage

Challenge 1: Dishonest SW may disclose uiv to cause a large-scale damage.Lemma 1.
UIV-TSP is resistant internal leakage for uiv.Proof.
In the UIV-TSP scheme, a benign logic bomb calledcodepreleak is embedded into the uiv message, which checks that whether the current MAC address is the same as the present destination address in tokentracing. The MAC address of the device is always fixed, it is impossible to be modified. Furthermore, the tokentracing is calculated by the hash operation h⋅, and tokenaccess that is dynamically updated at the end of each uiv access. The dual dynamics ensures that tokentracing cannot be inferred. According to Vc⟵tokentracing==Htokenaccess,maccurrent?, Vc=1 makes the protection payload be activated immediately to destroy vulj, so it is believed that our UIV-TSP scheme can resist uiv leakage.


## 4.1.2. Blockchain Storage against Continuous Logs Tampering

Challenge 2: the trusted sharing environment with leakage-resilience construction relies on the trust value evaluation. Trust mechanisms evaluate the trust value of SWs according to their historical behaviors. Attackers can tamper with their historical logs to disturb trust mechanism and promote their trust quickly. Therefore, it is impossible to distinguish honest SWs.Lemma 2.
UIV-TSP is resistant to continuous logs tampering.Proof.
In our UIV-TSP scheme, a blockchain-assisted method to store the continuous logs of all SWs for the trusted sharing environment with leakage-resilience construction. The original token and its all-subsequent updates should be stored on the blockchain, which is a sequence of blocks, which holds a complete list of transaction records like conventional public ledger. Each block points to the immediately previous block via a reference that is essentially a hash value of the previous block called parent block [35]. Just like a linked list, each block depends on its previous block. Therefore, if the continuous logs maintained in a block are tampered, its latter blocks chained on the blockchain must be modified. Obviously, the longer the blockchain created, the higher cost it takes to tamper with a block. Assuming the number of latter blocks related on Block p is lp under the condition that there are a number of sharing regions, the number of blocks that need to be tampered (tp) is calculated as follows:(10)tp=pm+pm2+…+pmlp=pmlp+1−pmpm−1.
For instance,tp=1,398,100 when nr=4 and lp=10.
Therefore, it is nearly impossible to tamper with the continuous logs maintained in Blockp due to the huge resource consumption.


## 4.2. Experimental Analysis

We perform simulations to validate the performance of the UIV-TSP scheme in Python 3.7.6, combined with NumPy, pandas, matplotlib, keras, TensorFlow, and other python libraries. The default simulation elements are shown in Table3.Table 3
Description of simulation elements.
ParametersDescriptionDefaultSWiNumber of SWs2000perPercentage of dishonest SWs10%–50%δThreshold of trust value(0.2, 0.5, 0.8)CycleNumber of cycle simulation200εEmbedded times of access credential(1, 2, 3, 4)kThe length of access credential(256, 512, 1024)The simulations are executed in cycle-based manner. At each cycle, a certain percentage of SWs are randomly selected as dishonest SWs. The behavioral pattern of honest SW is modeled to always keep secret, while dishonest SWs may leak an uiv message sometimes. Without punishment, dishonest SWs will hinder the establishment of a trusted vulnerability message sharing environment. In this section, the performance and overload of the proposed UIV-TSP scheme are experimentally evaluated under various settings.The simulation uses 2,000 SWs to generate 399,284 access record samples for training. Meanwhile, all the data generated are outputted to a.csv file. The proportion of benign access record samples to malicious access record samples in the training set is almost 1 : 1. Then, the data used are split to 70% training, and 30% validation.After dividing the dataset, this paper uses the Adam optimization algorithm to obtain the optimal parameter combination, such as learning rate, epochs, and batch size. Then, the parameters obtained are used for feedforward neural network training, and the performance is evaluated by cross validation. Figure7 shows the variation of model scores under different learning rates. The x-coordinate represents the learning rate, while the y-coordinate represents the model score. The shaded graph indicates the fluctuation range of the model score for this training. It can be seen that the training score and testing score reach the optimal value when the learning rate is 0.1, epoch = 10, and batch_size = 16.Figure 7
FNN learning rate score.In order to evaluate the performance of the trust mechanism based on FNN algorithm, we analyze four evaluation metrics, namely, precision (P), recall (R), accuracy (A), and F1-score (F1). In this paper, the precision and recall are defined as follows:(11)A=number of truly SWs detectedtotal number of SWs=TP+TNTP+TN+FP+FN,R=number of truly malicious SWs detectedtotal number of truly malicious SWs=TPTP+FN,P=number of truly malicious SWs detectedtotal number of malicious SWs=TPTP+FP,F1=2∗P∗RP+R.We compare the performance of feedforward neural network (FNN) for identifying malicious SWs with two other well-known deep learning models, namely, recurrent neural network (RNN) and convolutional neural network (CNN). Table4 shows that the FNN performs best in terms of the accuracy, recall, precision, and F1-score. In addition, FNN clearly lower than the other algorithms in terms of the training time costs. That is because the FNN algorithm has obvious advantages in network structure, and owns simpler node connections than RNN. Due to the convolution operation, CNN will require more computation. Therefore, we conclude that FNN is a suitable deep learning algorithm for SW trust evaluation.Table 4
Comparison of the performance of different algorithms.
AccuracyRecallPrecisionF1-scoreTime (s)FNNTrain0.97510.95180.95460.9532228Test0.97360.90500.91420.9096CNNTrain0.74280.83700.64860.7306337Test0.74220.83660.64810.7305RNNTrain0.88040.84550.84470.8452410Test0.87800.84540.84470.8449Then, we analyze the detection and false alarm rate of our UIV-TSP scheme (i.e., probability of successful detection leaker) in Figures8 and 9. To analyze the effectiveness better, we compare UIV-TSP with the undisclosed IIoT vulnerabilities sharing protection (UIV-SP) scheme without trust mechanism.Figure 8
Detection rate under the percentage of dishonest SWs.Figure 9
Alarm rate under the percentage of dishonest SWs.In this simulation, the detection rate of UIV-TSP is better than UIV-SP in Figure8, while the false alarm rate of UIV-TSP is lower than UIV-SP in Figure 9. Therefore, our designed trust mechanism can improve the performance of UIV-SP distinctly in the construction of trusted sharing environment.Then, we validate the performance of our UIV-TSP scheme against dishonest SWs, in terms of suppressing leakage behaviors. Dishonest SWs will leak uiv in the sharing environment. Consequently, some leakage behaviors may generate in each cycle, which may cause unnecessary waste of network resources. So, the key performance indicator of UIV-TSP is to suppress these leakage behaviors. As shown in Figure10, it is obvious that UIV-TSP is better than UIV-SP in suppressing leakage behaviors. This means that the trust mechanism plays a key role in the detection of dishonest SWs. In this simulation, δ is set as (0.2, 0.5, 0.8), respectively.Figure 10
Suppressing leakage behaviors.We also analyze the uiv leakage prevention performance of UIV-TSP in terms of leakage probability. In this simulation, the percentage of dishonest SWs is set as 30%, respectively. As shown in Figure11, the uiv leakage probability of UIV-TSP is also lower than UIV-SP.Figure 11
Probability of leakage at differentδ. (a) δ=0.8. (b) δ=0.5. (c) δ=0.2.
(a)(b)(c)Finally, we evaluate the traceability performance of UIV-TSP in terms of computational complexity. We count the number of time-consuming operations such as the symmetric-key encryption/decryption (SKE), public-key encryption/decryption (PKE), cryptographic hash function (HASH), and exponential operation (EXP) inGq multiplicative operation (MUL) in Gq. As shown in Table 5, we compare UIV-TSP with three types of traditional schemes.Table 5
Computational complexity.
SKEHASHPKEEXPMULCROT4t8t3t6t + 32t + 1ADS2t2tN/AN/AN/AR-ADS2t2tN/AN/A4kt + 2tOurs workN/A3tN/AN/AN/AIt can be found that UIV-TSP cannot require any exponential operation or public-key encryption/decryption. Moreover, the requirements for hash and symmetric key operations are limited in UIV-TSP.To further evaluate the traceability performance of UIV-TSP in terms of computational complexity, we can observe the traceability delay of UIV-TSP and these traditional schemes.We run 200 rounds of experiments and obtain their average traceability delay as the result. We definek as the length of access credential. In our UIV-TSP scheme, the access credential is a dynamic token. In the traditional schemes, the access credential is the private key of a user. A sufficient length of k can contribute to the collision resistance generated by hashing. As the length of k increases, the user capacity will be improved. Of course, with the increase of k and the embedded times of access credential, the traceability delay grows as well. As shown in Figure 12, UIV-TSP is more computationally efficient than ADS and CROT. The reason is that the sharing data in UIV-TSP need not to perform oblivious transfer (OT) and zero-knowledge proof. Once the embedded times vary from 1 to 4, the number of OT increases linearly.Figure 12
Average tracing delay. (a)k = 256. (b) k = 512. (c) k = 1024.
(a)(b)(c)In summary, our UIV-TSP scheme can prevent the uiv information leakage effectively, which merely requires limited traceability delay caused by multiple shared SWs.


## 5. Industrial Applications Discussion

Since the IIoT vendors generally have weak security emergency response capabilities, some SWs can be invited to help them path a new uiv by means of CVD. Our UIV-TSP scheme can prevent the uiv leakage effectively in CVD and trace the dishonest SWs with limited traceability delay. As shown in Figure13, UIV-TSP can be applied to several IIoT scenarios, such as energy, logistics, manufacturing, and transportation.Figure 13
Industrial application case of UIV-TSP.Take the IIoT manufacturing as an example. Once an IIoT manufacturing vendor reports a new uiv in CVD, he can select several SWs. Then, TA will assign tokenaccess to each of them and store tokenaccess on the blockchain. Without the implicit access credential, the unselected SWs cannot acquire uiv. With the implicit access credential, a selected SW can only acquire uiv on the basis of his high trust value. In this way, the uiv sharing can be restricted within the scope of permission, and the leakage problem of dishonest SWs can be avoided in advance.In our UIV-TSP scheme, the metadata of uiv and the related SW access records are also stored on the blockchain, which can make the access logs of the uiv sharing as tamper-resistant. After the access, tokentracing and codepreleak can be stealthily sneaked into the acquired uiv information. Once the uiv information is one step away from the selected SW host, codepreleak will destroy the uiv information and sends back feedback containing the token, thus avoiding a widespread damage to the users of the IIoT manufacturing devices after the uiv leakage. When the mitigation measures are developed, the uiv patch will be accurately distributed to the target IIoT manufacturing devices. Under the circumstances, uiv can be made public.


## 6. Conclusion and Future Works

In this paper, we propose an undisclosed IIoT vulnerabilities trusted sharing protection scheme against internal leakage. To facilitate the detection of leakage behaviors, we design a dynamic token as the implicit access credential and traceability clue. Assisted by blockchain, the continuous access logs of SWs can be securely stored. To prevent the leakage of a vulnerability, we present a benign logic bomb called codepreleak, which is embedded into the undisclosed IIoT vulnerability information. A trust management system based on deep learning is adopted to evaluate the trust value of SWs, which can quickly distinguish SWs. Simulation results indicate that our proposed scheme is resilient to suppress dishonest SWs, and merely require limited traceability delay.For future works, we will investigate on the selfish SWs and motivate them to develop the mitigation measures of undisclosed IIoT vulnerabilities under the protection of UIV-TSP.



---

*Source: 2500213-2022-10-10.xml*