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

With the large-scale deployment of industrial Internet of things (IIoT) devices in 5/6G environments, the number of vulnerabilities threatening IIoTsecurity is growing dramatically, including a mass of undisclosed IIoTvulnerabilities 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 oﬀering chances for dishonest SWs to internally leak undisclosed IIoTvulnerabilities. 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. +e 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-prooﬁng of dynamic token and the transparency of undisclosed IIoT vulnerabilities sharing. +e simulation results indicate that our proposed scheme is resilient to suppress dishonest SWs and protect the IIoT undisclosed vulnerabilities eﬀectively.


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][2][3][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]. +e 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]. +ese 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]. +ere 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. +erefore, 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. +e 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 token access , 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 token access . To avoid malicious inference, token access should be updated dynamically. At the end of SW access, the current token access is revoked.
A new random number is integrated into the hash generation of token to get a new token access as the next access credential. Meanwhile, the current token access and the MAC address of SWs are hashed to create the traceability token called token tracing , 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 code preleak is embedded into an uiv message, which checks that whether the current MAC address is the same as the preset destination address in token tracing . 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, code preleak 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 token tracing to trap their external conspirators.
+e architecture of this paper is as follows. In Section 2, 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.

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.
+ese 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.

)reat 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][22][23]. +erefore, while protecting the sharing of uiv information, the responsibility of SWs should be traced back.

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 privacypreserving solution for public information sharing allows to trace malicious users.
+e 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.

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.

System Architecture.
To prevent uiv leakage, we first present the system architecture of the UIV-TSP scheme. Figure 2 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 of SW i . (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 as SW 1 , SW 2 . . . SW m .

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

Token Generation.
When an SW submits a new undisclosed vulnerability vul j , each internal SW is assigned a corresponding token called token access , which is only held by the system and cannot be seen by anyone. TA generates the initial token access through a hash function. Meanwhile, we define vul meta as the meta information of an uiv. +e initial token access can be calculated as follows: Even if an SW is granted access through identify authentication, the uiv cannot be acquired without token access . Algorithm 1 is performed to generate and update token access .

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, token access will be update as follows: Meanwhile, the current token access and the MAC address of the SW are hashed to create the traceability token called token tracing . Token tracing can be defined as follows: token tracing ⟵ H token access ‖mac current . (3) In our scheme, token tracing can be stealthily sneaked into the acquired vul j information as the traceability credential. +e execution strategies of dynamic token management can be executed with four steps, the more details are given in [29].

Blockchain-Assisted Continuous Logs
Storage. Due to the advantages including transparency, traceability, and tamperproofing, 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. +ese continuous logs, including dynamic token, trust value of SW (Tr i ), and behaviors record (R[i]), 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 Figure 4.

Block
Head. +e 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) SW i : the ID of the i-th SW who requests the undisclosed vulnerability in the sharing environment.
(ii) Tr i : the trust value of SW i . In the block head, Tr i can be quickly retrieved by TA.
(iii) vul meta : the meta information of an undisclosed IIoT vulnerability.

Block Body.
In the block body, the log data of an SW (such as SW i ) are hashed to build the Merkle tree. Except for token access and token tracing , the log data of SW i contain the following elements: If token access in blockchain then (4) Update token access , token access ↔ SW i (5) else (6) Store token access , token access ↔ SW i (7) If end of request access, then (8) Revoke token access (9) tokent racing ⟵ H(token access ‖mac current ) (10) token access ⟵ H(SW i ‖vul meta ‖tp‖nonce′) (11) Store token access , SW i ↔ token tracing (12) Embed token tracing to vul j (13) End If (14) End If (15)  information. (iv) F false : the flag whether a false uiv information has been released.

Internal Leakage Prevention with One-Step Traceability.
To prevent SWs leaking the acquired vul j information, vul j should be self-destruct when they leave the host of SWs onestep. +us, we design a benign self-triggering logic bomb code preleak . 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]. code preleak is composed of trigger condition and response payloads. +e 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 vul j on the leakage side.
As shown in Figure 5, the functional structure of code preleak is consisted of self-checking and self-destruct.
3.4.1. Self-Check. Once the uiv information enters the SW host, code preleak will extract the current SW host Mac address and the revoked token to compute the verification value. +en, code preleak will match the verification value to token tracing . If the result V c is inconsistent, it will trigger selfdestruct. V c can be calculated as follows: Algorithm 2 is performed to match verification value.

Self-Destruct.
If V c � 0, the leakage has not happened. +at is, the uiv information has not left the SW host. +e protection payload continues to lurk. If V c � 1, it may leak vul j . +at is, the uiv information has left the SW host. In this case, the protection payload will be activated immediately to destroy vul j .
At the same time as the self-destruct event, code preleak can automatically send encrypted feedback ef � token tracing , vul j , SW i , mac current , t feedback } to TA.
(i) vul j : the ID of undisclosed IIoT vulnerability. (ii) t feedback : the time to code preleak send the feedback message.
Algorithm 2 is performed to activate the protection payload.

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.  mechanism, if an SW often leaks information, he will get a low trust value.

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 by Beta(α, β) [33].
where θ is the probability of duality behaviors, 0 ≤ θ ≤ 1, α > 0, β > 0. Take SW i as an example, sec i and lek i denote the number of secret-keeping and leakage in the sharing environment, respectively. +e expectation value of the beta function can be calculated as follows: E[Beta(α, β)] � α/(α + β). Considering that the trust value BT i is limited in the interval [0, 1], BT i can be described as follows: When sec i ≥ 1 and lek i � 0, BT i is always calculated as 1. +e SW i is completely trusted under this condition.
Obviously, the base trust value BT i 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: With the punishment of P i to BT i , the trust value Tri of SW can be further evaluated as follows:

Security and Communication Networks
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 SW i 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. +at 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.
+e 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. +e complete input feature description is shown in Table 1. +ere are two hidden layers with totally 16 hidden neurons. +e 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.
As we know, it is essential to learn which appropriate weights and biases that make FNN have good performance. +e 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.
where α L j represents the j-th activation of the last neuron, and L represents the current layer. +en, the j-th activation of the previous layer is α (L−1) j . Assuming there are L hidden layers in total, then n L− 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.

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. +e specific distinction rules are as follows: R1: for Tr i > δ h , the SW i 's access request for an uiv message will be accepted. In this situation, SW i is classified as honest.
R2: for Tr i < δ l , the SW i 's access request for an uiv message will be rejected. In this situation, SW i is classified as dishonest. R3: for δ l < Tr i < δ m , it is difficult to determine the access authorities of SW i . In this situation, SW i 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 SW i .
If μ i � 0, there are no conspirators. Hence, SW i is temporarily considered as honest.
If μ i ≥ 1, SW i may have several external conspirators. +e trust value of SW i will be set to 0. As a result, SW i will be removed from the CVD and barred from rejoining.

Trap External Conspirators.
If SW i is a semihonest SW, a false uiv message can be released to trap his external conspirators. +is false uiv information is set to a valid time.
Within the valid time, code preleak 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, SW i 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. Algorithm 3 is performed to trap external conspirators.

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.

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 Table 2.

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 called code preleak is embedded into the uiv message, which checks that whether the current MAC address is the same as the present destination address in token tracing . +e MAC address of the device is always fixed, it is impossible to be modified. Furthermore, the token tracing is calculated by the hash operation h(·), and token access that is dynamically updated at the end of each uiv access. +e dual dynamics ensures that 8 Security and Communication Networks token tracing cannot be inferred. According to V c ⟵ token tracing �� H(token access , mac current )?, V c � 1 makes the protection payload be activated immediately to destroy vul j , so it is believed that our UIV-TSP scheme can resist uiv leakage.

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. +erefore, 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 Input Layer (11) Hidden Layer (8) Hidden Layer (8) Output Layer (1) Tr sw x 9 x 10 x 11 Figure 6: Structure of the feedforward neural network.
(4) Else (5) Acquire MAC current (6) V c ⟵ token tracing �� H(token access , mac current )? (7) IfV c � 1then (8) Assign access authorities (9) IfExtract(vul j ) �� F false then (10) Go to step 8. (11) Else (12) Send an encrypted feedback message e f to TA. Security and Communication Networks trusted sharing environment with leakage-resilience construction. +e 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. +erefore, 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 l p under the condition that there are a number of sharing regions, the number of blocks that need to be tampered (t p ) is calculated as follows: For instance, t p � 1, 398, 100 when n r � 4 and l p � 10. +erefore, it is nearly impossible to tamper with the continuous logs maintained in Block p due to the huge resource consumption.

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,  Invoke Self-Destruct (9) Else: (10) mac current not in path i (11) path i add (mac current ) (12) End if (13) Else (14) Release normal vul j to SW. TensorFlow, and other python libraries. +e default simulation elements are shown in Table 3.
+e simulations are executed in cycle-based manner. At each cycle, a certain percentage of SWs are randomly selected as dishonest SWs. +e 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.
+e 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. +e proportion of benign access record samples to malicious access record samples in the training set is almost 1 : 1. +en, 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. +en, the parameters obtained are used for feedforward neural network training, and the performance is evaluated by cross validation. Figure 7 shows the variation of model scores under different learning rates. +e x-coordinate represents the learning rate, while the y-coordinate represents the model score. +e 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.
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: We compare the performance of feedforward neural network (FNN) for identifying malicious SWs with two other well-known deep learning models, namely, recurrent    Table 4 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. +at 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. +erefore, we conclude that FNN is a suitable deep learning algorithm for SW trust evaluation. +en, we analyze the detection and false alarm rate of our UIV-TSP scheme (i.e., probability of successful detection leaker) in Figures 8 and 9. To analyze the effectiveness better, we compare UIV-TSP with the undisclosed IIoT vulnerabilities sharing protection (UIV-SP) scheme without trust mechanism.
In this simulation, the detection rate of UIV-TSP is better than UIV-SP in Figure 8, while the false alarm rate of UIV-TSP is lower than UIV-SP in Figure 9. +erefore, our designed trust mechanism can improve the performance of   UIV-SP distinctly in the construction of trusted sharing environment. +en, 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 Figure 10, it is obvious that UIV-TSP is better than UIV-SP in suppressing leakage behaviors. +is 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.
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 Figure 11, the uiv leakage probability of UIV-TSP is also lower than UIV-SP.
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), publickey encryption/decryption (PKE), cryptographic hash function (HASH), and exponential operation (EXP) in G q multiplicative operation (MUL) in G q . As shown in Table 5, we compare UIV-TSP with three types of traditional schemes.
It 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.

Security and Communication Networks 13
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 define k 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. +e reason is that the sharing data in UIV-TSP need not to  In summary, our UIV-TSP scheme can prevent the uiv information leakage effectively, which merely requires limited traceability delay caused by multiple shared SWs.

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 Figure 13, UIV-TSP can be applied to several IIoT scenarios, such as energy, logistics, manufacturing, and transportation.
Take the IIoT manufacturing as an example. Once an IIoT manufacturing vendor reports a new uiv in CVD, he can select several SWs. +en, TA will assign token access to each of them and store token access 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 tamperresistant. After the access, token tracing and code preleak can be stealthily sneaked into the acquired uiv information. Once the uiv information is one step away from the selected SW host, code preleak 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 IIoTmanufacturing devices. Under the circumstances, uiv can be made public.

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 code preleak , 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.

Data Availability
+e data required for simulation are generated through experiments.

Conflicts of Interest
+e authors declare that they have no conflicts of interest.