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.
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 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 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.
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.
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. 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 .(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 .
3.2. 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.
3.2.1. Token Generation
When an SW submits a new undisclosed vulnerability , 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:
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.
|
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:
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:
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 (), and behaviors record (), 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.
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): the ID of the i-th SW who requests the undisclosed vulnerability in the sharing environment.(ii): the trust value of . In the block head, can be quickly retrieved by TA.(iii): the meta information of an undisclosed IIoT vulnerability.
3.3.2. Block Body
In the block body, the log data of an SW (such as ) are hashed to build the Merkle tree. Except for tokenaccess and tokentracing, the log data of contain the following elements:(i): the historical trust data of , which can be used to evaluate the trust value of before the access.(ii): the current trust data of , which can be used to update the trust value of after the access.(iii): the access request record of to an information.(iv): the flag whether a false information has been released.
3.4. Internal Leakage Prevention with One-Step Traceability
To prevent SWs leaking the acquired information, 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 on the leakage side.
As shown in Figure 5, the functional structure of codepreleak is consisted of self-checking and self-destruct.
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 is inconsistent, it will trigger self-destruct. can be calculated as follows:
Algorithm 2 is performed to match verification value.
|
3.4.2. Self-Destruct
If , the leakage has not happened. That is, the information has not left the SW host. The protection payload continues to lurk.
If , it may leak . That is, the uiv information has left the SW host. In this case, the protection payload will be activated immediately to destroy .
At the same time as the self-destruct event, can automatically send encrypted feedback to TA.(i): the ID of undisclosed IIoT vulnerability.(ii): the time to codepreleak send the feedback message.
Algorithm 2 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 by [33].where is the probability of duality behaviors, , .
Take as an example, and 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: . Considering that the trust value is limited in the interval [0, 1], can be described as follows:
When and , is always calculated as 1. The is completely trusted under this condition.
Obviously, the base trust value 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 to , the trust value Tri of SW can be further evaluated as follows:
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 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.
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 Table 1. 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.
As 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.where 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 . Assuming there are L hidden layers in total, then 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. () are, respectively, set as the threshold of high, low, and medium trust value. The specific distinction rules are as follows: R1: for , the ’s access request for an uiv message will be accepted. In this situation, is classified as honest. R2: for , the ’s access request for an uiv message will be rejected. In this situation, is classified as dishonest. R3: for , it is difficult to determine the access authorities of . In this situation, 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 denote number of conspirators of .
If , there are no conspirators. Hence, is temporarily considered as honest.
If , may have several external conspirators. The trust value of will be set to 0. As a result, will be removed from the CVD and barred from rejoining.
3.5.3. Trap External Conspirators
If 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, 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.
|
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 Table 2.
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 called is embedded into the uiv message, which checks that whether the current MAC address is the same as the present destination address in . The MAC address of the device is always fixed, it is impossible to be modified. Furthermore, the is calculated by the hash operation , and that is dynamically updated at the end of each uiv access. The dual dynamics ensures that cannot be inferred. According to , makes the protection payload be activated immediately to destroy , 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:For instance, when and .
Therefore, it is nearly impossible to tamper with the continuous logs maintained in Block p 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 Table 3.
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. Figure 7 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.
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 neural network (RNN) and convolutional neural network (CNN). 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. 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.
Then, 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. 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 Figure 10, 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.
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.
(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) in multiplicative operation (MUL) in . 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.
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. 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.
(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 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. 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.
Data Availability
The data required for simulation are generated through experiments.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
The study was supported by the National Natural Science Foundation of China (No. 61802302) and the Natural Science Basic Research Program of Shaanxi (No. 2019JM-442).