Skip Content
You are currently on the new version of our website. Access the old version .
NetworkNetwork
  • Feature Paper
  • Article
  • Open Access

25 January 2022

Delegated Proof of Secret Sharing: A Privacy-Preserving Consensus Protocol Based on Secure Multiparty Computation for IoT Environment
 †

,
and
1
Department of Computer Science and Engineering, University of South Carolina, Columbia, SC 29208, USA
2
Air Force Research Laboratory, Rome, NY 13441, USA
*
Author to whom correspondence should be addressed.
Approved for Public Release; Distribution Unlimited. Case Number AFRL -2022-0191. Dated 13 Jan 2022.

Abstract

With the rapid advancement and wide application of blockchain technology, blockchain consensus protocols, which are the core part of blockchain systems, along with the privacy issues, have drawn much attention from researchers. A key aspect of privacy in the blockchain is the sensitive content of transactions in the permissionless blockchain. Meanwhile, some blockchain applications, such as cryptocurrencies, are based on low-efficiency and high-cost consensus protocols, which may not be practical and feasible for other blockchain applications. In this paper, we propose an efficient and privacy-preserving consensus protocol, called Delegated Proof of Secret Sharing (DPoSS), which is inspired by secure multiparty computation. Specifically, DPoSS first uses polynomial interpolation to select a dealer group from many nodes to maintain the consensus of the blockchain system, in which the dealers in the dealer group take turns to pack the new block. In addition, since the content of transactions is sensitive, our proposed design utilizes verifiable secret sharing to protect the privacy of transmission and defend against the malicious attacks. Extensive experiments show that the proposed consensus protocol achieves fairness during the process of reaching consensus.

1. Introduction

In a distributed system, the consensus is the task of reaching an agreement on some specific values among a group of processes. Consensus is helpful in the following application scenarios: leader electing, synchronizing replicated state machines, deciding to commit or abort for distributed transactions, etc. As one realization of the distributed system, a blockchain network is dependent on the consensus protocol to achieve a common status for all nodes in the network [1]. Consensus protocols are designed to maintain the reliability in a network involving multiple unreliable nodes; therefore, it is necessary to assume that some communications are not available, and the consensus protocol must be fault-tolerant.
To maintain the integrity of the blockchain network, various consensus protocols have been proposed, and many of them have been employed extensively. Proof of Work (PoW) has the main idea of producing a cryptographic hash, and the concept was invented by Dwork and Naor in 1993 to deter denial-of-service attacks and other service abuses, such as email spam [2]. PoW was then introduced by Satoshi Nakamoto for describing the design of Bitcoin as the foundation of its consensus [3]. In PoW, participants are required to perform some time-consuming and complex computation, such as the hashing in Bitcoin, and the result of the computation can be validated quickly. The consumed time, device wear, and energy are considered as the guarantees that can prevent the abuse of the blockchain network service. Meanwhile, the consumption brought by the complex computation, typically called “mining” in Bitcoin, overwhelms the usage of electricity in some countries with a population of more than 10 million, such as Argentina, Netherlands, and United Arab Emirates [4].
Unlike the PoW protocol, Proof of Stake (PoS) does not prompt extreme amounts of energy consumption. In PoS, the production of a new block is based on the amount of stake (coins in cryptocurrency) a participant holds [5]. The principle in the back is that the participant that holds the most stakes cherishes the worth of the blockchain network the most and is not willing to lose the wealth, so the probability that this participant is honest is quite high. However, an often discussed point about PoS is that it probably leads to the centralization of the blockchain network since the blockchain network utilizing PoS favors participants with a higher amount of stakes, and a more substantial participant will use the profit to increase the production ability of new blocks; thus, a more substantial participant grows faster than a participant with a smaller stake. After some point, the cost of entering the group of block producers becomes too high, causing many other participants to quit, resulting in centralization [6].
In addition to these two most popular consensus protocols, there are some other competitive ones, including Proof of Elapsed Time (PoET), Proof of Luck (PoL), and Delegated Proof of Stake (DPoS). Both PoET and PoL utilize the capacity of a Trusted Execution Environment (TEE), such as Intel’s Software Guard Extension, to achieve consensus. PoET generates a random waiting time for each participant in the blockchain network, in which the one whose waiting time expires first will win the selection and obtain the privilege of producing a new block [7]. PoL makes all participants generate a random number in each round of block producing, and the participant with the largest time is the winner [8]. DPoS is a hybrid consensus protocol that utilizes the representative democratic. Nodes in the blockchain network can vote for a few delegates who are responsible for the network maintenance and new block packing.
The Internet of Things (IoT) network has evolved because of the advancement of multiple techniques, including embedded systems, wireless sensors, and automation. IoT devices are widely adopted in the market of smart homes, healthcare systems, manufacturing, etc. However, there are many serious issues exposed along with the development of IoT ecology, especially in the areas of security and scalability. Security is a major concern for the center server and sensors at the edge of the IoT network. The center server of the IoT network is an obvious target of DDoS attacks, which have the potential to cause the paralysis of the entire network. Another issue is about the scalability. Along with the fast increase in the number of connected devices, the overhead of the authentication process, address assignment, and frequent communications will impose growing pressure on the center server.
Meanwhile, the sensors and edge devices in the IoT network may become the breaking point of malicious attackers due to the following reasons of lacking compliance on manufacturers and the complicated upgrade management [9]. Many IoT devices come out with undiscovered vulnerabilities in the hardware and software. For example, a group of hackers discovered one security vulnerability that can be used to perform a man-in-the-middle attack and gain the user’s Gmail login credential [10]. Since there is no standard for the IoT connection module and interface, these security issues can not be upgraded and fixed easily, especially on the hardware side.
Blockchain can help mitigate the security and scalability concerns associated with IoT in the way of security and scalability. The transformation from centralization to decentralization brought by the integration of blockchain avoids the risk of single-point failure and alleviates the pressure of communication over the entire network, such that the scalability is improved. At the same time, the maintenance of the network does not rely on the center server; therefore, the influence of the targeted DDoS attack can be reduced. The key idea of integrating IoT with blockchain is simple, but the implementation raises many challenges, and the most serious one is the choice of consensus protocol since consensus protocol forms the backbone of the blockchain network and affects efficiency and security.
As we mentioned above, PoW is the most well-known consensus protocol, and it has been shown that it is an effective approach for the operation of the cryptocurrency system. However, it is not suitable for the IoT network due to the high energy consumption. PoET has significantly lower energy consumption, but reaching a consensus relies on the specific hardware platform, which is not practical for the large-scale deployment in the IoT environment. Proof of Capacity (PoC) is also similar to PoW, but the complex computation is replaced by the capacity of storage. It is well known that IoT devices are constrained by their small storage capacity and slow storage speed, which makes PoC not a viable choice. Other consensus protocols, such as the variants of PoS and Byzantine Agreement Methods, have higher efficiency and lower energy consumption than PoW, but few of them focus on the privacy of communication within the blockchain network. In most consensus protocols, the built blockchain network provides transparency by allowing all the authorized participants to review the content of the transaction and track the past blocks. This can help track the malicious actions and source but may leak sensitive information in some special application scenarios.
Most of the current existing consensus protocols have some common shortcomings, such as low efficiency, centralization trend, high energy consumption, and privacy issues. The problems of low efficiency and high energy consumption make them impractical for the application of blockchain networks in the IoT environment. These issues motivate us to propose a privacy-preserving and efficient consensus protocol, which enables the blockchain network to be deployed in resource-constrained IoT networks.
In this work, we present a consensus protocol that provides fairness during the election of nodes to pack the new block and preserves privacy during information transmission while maintaining efficiency. Our contributions can be summarized as follows:
  • To achieve the fairness of the election, we propose a random algorithm to randomly choose several nodes as the packers based on all of the nodes’ given parameters.
  • The feature of privacy-preserving is implemented with verifiable secret sharing, in which the information is split and then encrypted so as to protect the sensitive information during transmission.
  • We propose one method to keep the efficiency of the election when the number of nodes in the blockchain network is very large.
  • Evaluation results and analysis show the efficiency and security of our scheme.
The remainder of the paper is organized as follows. In Section 2, we give a description about secret sharing and an overview of existing consensus protocols used in the IoT environment. In Section 3, we introduce the design assumptions and ideas of the proposed DPoSS consensus protocol, and then present it with pseudocode. In Section 4, we give an analysis on security and privacy. In Section 5, we discuss the possible application scenarios and compare our scheme with some existing blockchain systems, which are integrated with secure multi-party computations. In Section 6, we conclude the paper and discuss the future work.

3. Design

In this section, we present the design of our novel consensus protocol. From the above description about consensus protocol, we found three existing problems of the current popular consensus protocols: efficiency, centralization, and privacy issues. Therefore, we ask the following research questions:
Q1.
How to improve the efficiency of the blockchain system from the perspective of consensus protocol and reduce the waste of energy?
Q2.
How to guarantee the democracy or fairness during the selection of the new block packer to avoid the centralized control by one or a small group of nodes while reducing the ratio of malicious nodes being selected?
Q3.
How to protect the privacy of the blockchain network participants when the information being transmitted is sensitive?
To answer these questions, we proposed a novel consensus protocol called Delegated Proof of Secret Sharing (DPoSS), which is suitable for the application scenario of an IoT environment. DPoSS is designed based on the following assumptions:
  • The IoT network includes many edge devices and more sensors connected to the edge devices. The blockchain network consists of only those edge devices; sensors are not included as the nodes of the blockchain network.
  • Each node in the blockchain network has it own pair of a public key and a private key. The node’s public key is available to all other nodes, and its private key is known only to itself and the control center, if established.
  • Our proposed DPoSS relies on one group of delegate nodes in the blockchain network instead of all nodes, as in the case of PoW. With DPoSS, every node has the opportunity to be elected as a delegate, denoted as “teller”; all other unelected nodes are called “fishers”.
  • Sensors are not able to vote for delegates due to the constraints on the abilities of computation power, battery, and transmission bandwidth.
Basically, there are two kinds of nodes in the blockchain network during the processing of consensus: regular nodes (fishers) and delegate nodes (tellers). We do not define and confine the principle to choose or screen the tellers for the various applications of the IoT network because there are many options available, such as random choosing and PoW-like method, in which the first several nodes successfully figure out one simple problem will be the tellers. Meanwhile, there is also no requirement of the number of tellers. The appropriate number of tellers depends on the threshold of secret sharing. For the convenience of discussion, we denote the number of all nodes (fishers and tellers) as m and denote the number of tellers as n.

3.1. Election

Assume that there are some connected nodes already, and every node has its own pair of public and private keys. To prevent the 51% attack, the first block of the blockchain network is produced by the system maintainer, such as the control center, instead of the first connected node. Before the proceeding of any transaction, the election must be finished since the responsibilities of the tellers include both the packing of a new block and the spreading of transactions.
In general, the election is implemented by a verifiable random number generation based on the polynomial interpolation. If there are m + 1 running nodes in the blockchain network, and each node contributes one data point P i : ( x i , y i ) of the polynomial interpolation of m degree such that no two data points are the same, one equation of the polynomial can be deduced from the data points provided by the running nodes. All m + 1 coefficients can be used to build one random number by performing the xor operations. For example, there are four running nodes in the blockchain network, and the provided data points are P 0 ( 1.5, 1.2) , P 1 ( 0.2, 0 ) , P 2 ( 1 , 0.5) , P 3 ( 5 , 1 ) , so the deduced equation of the polynomial would be
f ( x ) = 2.2535× 10 2 × x 3 1.8679× 10 1 × x 2 + 5.4717× 10 1 × x + 1.1709× 10 1
and the coefficients, such as 2.2535× 10 2 and 1.1709× 10 1 , are the factors used to build the random number.
The steps for the general election can be described as follows:
  • All the nodes randomly pick one data point P i : ( x i , y i ) and broadcast the data point with a timestamp. If two or more nodes pick a conflicting data point such that they share the same x value or they share the same x and y values, the node whose timestamp is later will be asked to pick another data point until there is no conflict.
  • Build the polynomial of the form f ( x ) = a 0 + a 1 x + . . . + a n x n based on all received data points and generate the random number result r.
  • Choose first k nodes whose data point has the value of | x y | is closest to the generated random number r.
  • These k nodes form the group of dealers and dealers take turns to pack the new block. The dealer that has already packed the new block loses the identity and the permission of the dealer until the dealer group is empty; at that time, a new round of election will be initiated.
In step 2, the random number is computed by bitwise xor operation on all coefficients of the interpolated polynomial. Since most of the coefficients are not integers and some of them are very big or very small, we concatenate all the coefficients together into a long string C according to the degree order, and then split the concatenated string C into an array A ( n ) of n number based on the globally consistent value range of data points from all nodes in order to make the final random number close to data points from all nodes. For example, if the range of all nodes’ data points are within ( 0 , 100 ) , then C will be cut as one integer every two digits so that all elements of array A ( n ) stand in the same plane with all data points, and the result of bitwise xor stands in it.
Each data point has two values x i and y i , but the calculation of bitwise xor can only yield one single value instead of one pair. To solve this problem, the separated array A ( n ) needs some changes, for example, reducing by 1 for all numbers in array A ( n ) . Thus, we obtain two random numbers to form a random point as the reference to choose k closest data points, and their senders form the dealer group to pack the new block. The algorithm to generate the random point is presented in Algorithm 1.
Algorithm 1: Algorithm to generate random data points. The parameters X and Y are the collections of data points such that X contains all x i and Y contains all y i .
1:
procedure BITWISE( X , Y )
2:
     d e g r e e = X . s i z e ( )
3:
     p o l y = F u n c P o l y n o m i a l F i t ( X , Y , d e g r e e )    ▹ Polynomial interpolation
4:
     c o e s = p o l y . c o e f f i c i e n t s ( )             ▹ Return all coefficients
5:
    for  c o e in c o e s  do
6:
        Make all coefficient value positive
7:
        Delete the decimal point
8:
        Concatenate them together as one string S
9:
    Split S as an array of integers A
10:
    Substract each element in A ( n ) by one number to form another array B
11:
     x = b i t w i s e X O R ( A )
12:
     y = b i t w i s e X O R ( B )
13:
    return  x , y
Interpolation is a method to discover more data points based on the known data points. In other words, interpolation can help to obtain the unique mathematical expression that can cover all given data points. The method we used is Lagrange’s interpolation formula such that if y = L ( x ) takes the values y 0 , y 1 , , y n corresponding to x = x 0 , x 1 , , x n , then the Lagrange form polynomial L ( x ) is
L ( x ) = j = 0 n y j l j ( x )
of Lagrange basic polynomials
l j ( x ) = i = 0 , i j n x x i x j x i
If any of the nodes have doubts about the validation of the built polynomial, the verification can be conducted individually. The node has the polynomial of the form f ( x ) = a 0 + a 1 x + + a n x n and its own data point ( x i , y i ) and verifies if y i = f ( x i ) is correct or not. If y i = f ( x i ) , this indicates that this node’s data point participates in the building of the polynomial that yields the random number; otherwise, the generated random number is not valid.

3.2. Election on Large Network

The time complexity of the election solution is O ( n 2 ) and auxiliary space is O ( 1 ) , which means that when the number of nodes in the blockchain network becomes large to a certain extent, the action to build the polynomial for all nodes is no longer efficient. For extremely large blockchain networks, one extra cryptographic sortition step is necessary for the election. Based on the VRF’s properties of pseudo-randomness, uniqueness, and verifiability, each node can calculate a random number within the predefined range, such as [ 0 , 1 ) , and according to the total number of nodes in the blockchain network, a value k can be set as the number of groups to separate all the nodes. For example, all the nodes need to be divided into four groups, the predefined range [ 0 , 1 ) can be partitioned into [ 0 , 0.25) , [ 0.25, 0.5) , [ 0.5, 0.75) , and [ 0.75, 1 ) . Then, each group will build one polynomial for selecting dealers in each group, and the selected dealers in each group will form a larger group of dealers. Because of the existing of multiple groups, the total number of dealers should be adjusted in each group in order to maintain the balance between the number of dealers and the number of nodes.

3.3. Transactions

In the IoT network, the information may flow from the sensor to the control center through the blockchain network, and the control center can also send messages to one or more sensors. The information flow in both directions is achieved through the employment of the lightweight communication protocol designed specifically for the IoT network, such as MQTT and CoAP [28]. In the IoT network integrated with blockchain, the smallest unit of communication is called a transaction. The tellers are in charge of packing a new block of transactions, and all the nodes help to spread the transactions just like in the regular blockchain network.
If the control center requests data from one or more target sensors, this transaction will be directly sent to the blockchain network. Each node in the blockchain network will check if the target sensors are connected to itself; if so, the node will send the transaction to the connected sensors.
If the transaction is initiated from a sensor, no matter if it is a publish message or response message, the transaction will be sent to the connected edge nodes. This transaction will be split into n pieces (n is the number of tellers), and then spread through the blockchain network. These split n pieces will be encrypted using the public key of tellers. Therefore, except for the node that splits the transaction and the control center, no other node can merge these encrypted pieces and fetch the sensitive information. Because the control center is aware of the tellers’ private key, the control center is able to recover the original information sent by the sensors. In this way, even if one or some nodes are controlled by a malicious attacker, the attacker still cannot break the protection of the information; thus, the privacy is preserved.

3.4. Security

With the scheme of secret sharing, the secret sent to the control center through the blockchain network can be privacy-preserved. However, there is one special case in which the node in charge of the job of splitting and distributing is not honest anymore, which may cause the transaction information to be garbled from the very beginning. As shown in Figure 1, they indicate a ( 2 , 3 ) -threshold secret sharing system in which any two shares can reconstruct the secret, but there exists at least one security issue: the dealer is malicious so that the secret shares sent to three players are not incorrect. For example, the share sent to the third player is garbled, and it is possible that the reconstruction will fail. To solve this problem, we choose to integrate the Verifiable Secret Sharing instead of the basic secret sharing, such as Shamir’s Secret Sharing.
Figure 1. A ( 2 , 3 ) -threshold secret sharing. Any 2 shares or all 3 shares can reconstruct the original secret.

4. Analysis and Evaluation

In this section, we provide some analysis about the proposed consensus protocol in terms of security, fault tolerance, and efficiency.

4.1. Fault Tolerance

A blockchain is essentially a distributed and decentralized network that shares a common state. However, even though various consensus protocols have been designed to maintain the agreement on all nodes, it is still possible that this agreement does not occur due to some fault. The endeavor to achieve and maintain this agreement under possible faults is called fault tolerance.
We note that our proposed consensus protocol is based on secret sharing, which refers to splitting one secret S to m shares ( S 1 , S 2 , , S m ) and distributing shares to m participants, and one important feature of secret sharing is that the secret can be reconstructed with t (t stands for a threshold and t < m ) or more shares presented. Such a ( t , n ) -threshold secret sharing system can be used to implement the fault tolerance in the following way:
  • Information of any t or more S i shares makes S easily computable. This means that the secret S can be easily reconstructed from any combination of t shares.
  • Information of any t 1 or fewer S i shares will leave the secret S completely undetermined. This means that the secret S cannot be reconstructed with fewer than t shares.
  • One extreme case of such a secret sharing system is that t = m so that all shares are required to build the original secret.
With the ( t , n ) -threshold secret sharing system, the fault tolerance depends on a majority of the tellers, so the tolerance rate is less than 51% of tellers. For instance, if the transaction was split into 12 shares, then setting t = 6 cannot make sure the reconstruction of the secret since these 6 tellers could be all controlled by the attacker, even though the possibility of device failure still exists. If the value of t is set to be larger than 6, then the secret can be recovered, and the consensus can still be reached.

4.2. Random Number Distribution

In cryptography, confusion and diffusion are two critical properties in the processing of secure cipher [29], and diffusion indicates the connection between the plaintext and ciphertext. In our design, the distribution of generated random numbers should have no obvious connection with any data point given by the nodes in the blockchain network. To show the randomness of the generated random data points and scattered distribution, we simulate the distribution using several rounds of polynomial interpolation of degree 1000 and plot all rounds’ data points in the coordinate plane. As shown in Figure 2, the red dots represent the data points in 1000 rounds of polynomial interpolation. We can see that there is no obvious pattern, which shows the randomness of k data points selection and the fairness of dealer selection.
Figure 2. Distribution of random data points generated in 1000 rounds.

4.3. Efficiency

We experiment to show the approximate time used to build the polynomial, as shown in Table 1. With a prototype implemented on a machine with Intel Core i7 10700f CPU, we can see that building a polynomial with a Lagrange form for 20,000 degrees needs around 2 s, while the polynomial with degree 10,000 only takes less than 0.5 s. These experimental results show that our scheme is quite efficient. Although some nodes in the blockchain network may be equipped with lower end processors, it should be capable of handling the work of building a polynomial with thousands of nodes according to our results.
Table 1. Running time used to build the polynomial with Lagrange form.

5. Discussion

In this section, we present some application scenarios of our proposed consensus protocol. The comparison between our design and some similar consensus protocols based on secure multi-party computations is given as follows.

5.1. Application Scenarios

Blockchain technology produces a structure of data with inherent security qualities since it is based on cryptography. In most blockchain and distributed ledger applications, the data are structured into multiple blocks, and each block can be used to carry information. The encryption and protection on the blocks make our proposed design especially suitable for blockchain systems that transmit sensitive information, such as cloud computing and financial systems.
Individuals and small companies tend to deploy their services on the cloud instead of purchasing and maintaining their own servers because of many benefits, including cost-saving, fast deployment, scalability, etc. However, confidentiality and integrity of the data in a remote cloud computing environment are some of the security concerns. If the cloud service, or a connected device, is breached, sensitive data could be accessed [30]. The data including personal health information, personally identifiable information, trade secrets, and intellectual property are often the targets of data breaches and require robust security protection in cloud computing [31]. Even though cloud computing and blockchain seem to be deceptively in conflict from the perspective of infrastructure that cloud computing is representative of centralized computing and the blockchain typically stands for decentralization, but there are many fields on which blockchain and cloud computing can be integrated [32]. For example, the storage of the cloud computing environment can be built based on blockchain with our design so that the stored data are split and individually encrypted. The advantage of our design over encryption on undivided data is risk diversification. Meanwhile, the inherent features of blockchain including parallel throughput bandwidth and data tamper resistance are also retained in our design.
Blockchain technology has supported multiple cryptocurrency ecosystems and has inspired the interest of the financial sectors. The financial industry has already started the experiment with blockchain to see how the distributed ledger techniques can leverage financial transactions. However, due to the characteristics of sensitivity in the financial transactions, the blockchain system applied in the financial industry tends to be a private blockchain. In the private blockchain, only a few participants can read and write on the distributed ledger to prevent data leakage. With our design, the public blockchain can also be used to build the transaction systems based on blockchain such that the communication between nodes is split and encrypted, and the decryption can only occur when the number of recipients agreed on is more than a predefined threshold value.

5.2. Comparison

Luo et al. [33] proposed a consensus algorithm based on secure MPC, which incorporates Yao’s millionaire algorithm. Specifically, one candidate group of 101 nodes is selected first, and then the election process is conducted within the group. During the election process, Yao’s millionaire algorithm, one of the secure MPC, permits the comparison between different nodes’ stake to be qualified as the “proxy” node of the generation block. By contrast, our design does not need extra communication if the blockchain network scale is not extraordinary large. Moreover, our design uses the secure MPC in both the election process and the communication process, which enhances the overall security.
Zhong et al. [34] introduced the overview on how secure MPC can be performed using blockchain techniques. Secure MPC and blockchain are both of distributed form, so they are compatible with each other. There are many other practical applications that benefit from the integration of secure MPC and blockchain, such as smart city [35], health record system [36], electronic voting [37], and storage system [38]. However, all these applications of secure MPC are based on blockchain, while we use secure MPC to improve the security, efficiency, and equity of the blockchain system.
Through the above-mentioned comparison, we show that our contribution lies in the novel use of secure MPC and the combination of blockchain and secure MPC.

6. Conclusions

This paper proposes an improved consensus protocol, which is integrated with verifiable secret sharing, the polynomial interpolation, and verifiable random function when the blockchain network is very large. We have combined these ideas into a new consensus protocol that not only takes charge of the packing of new blocks but also maintains the privacy of information transmission. The distribution experiment shows the randomness of the node selection using polynomial interpolation, which provides fairness for every node in the blockchain network. The observed running time demonstrates the efficiency of our approach.
Our future work will focus on two aspects. First, we plan to conduct a larger experiment to verify the efficiency of our consensus protocol. Second, we plan to improve our design on the modularization so that different types of secret sharing schemes can be changed under different application scenarios.

Author Contributions

Conceptualization, T.G. and C.-T.H.; methodology, T.G.; formal analysis, T.G.; writing—original draft preparation, T.G.; writing—review and editing, L.N. and C.-T.H.; supervision, C.-T.H.; funding acquisition, L.N. All authors have read and agreed to the published version of the manuscript.

Funding

This research was supported in part by the Air Force Office of Scientific Research through SystemsPlus, Inc. contract number FA9550-20-F-0005 and the Air Force Research Laboratory through the Information Directorate’s Information Institute® contract number FA8750-20-3-1003.

Data Availability Statement

No new data were created or analyzed in this study. Data sharing is not applicable to this article.

Conflicts of Interest

The authors declare no conflict of interest.

Special Note

Approved for Public Release; Distribution Unlimited. Case Number AFRL -2022-0191. Dated 13 Jan 2022.

References

  1. Xiao, Y.; Zhang, N.; Li, J.; Lou, W.; Hou, Y.T. Distributed consensus protocols and algorithms. Blockchain Distrib. Syst. Secur. 2019, 25, 1–31. [Google Scholar]
  2. Dwork, C.; Naor, M. Pricing via processing or combatting junk mail. In Proceedings of the Annual International Cryptology Conference, Santa Barbara, CA, USA, 16–20 August 1992; pp. 139–147. [Google Scholar]
  3. Nakamoto, S. Bitcoin: A peer-to-peer electronic cash system. Decentralized Bus. Rev. 2008, 21260. [Google Scholar]
  4. Criddle, C. Bitcoin Consumes More Electricity than Argentina. Available online: https://www.bbc.com/news/technology-56012952 (accessed on 25 September 2021).
  5. Frankenfield, J. Proof-of-Stake (PoS). Available online: https://www.investopedia.com/terms/p/proof-stake-pos.asp (accessed on 25 September 2021).
  6. He, P.; Tang, D.; Wang, J. Stake Centralization in Decentralized Proof-of-Stake Blockchain Network. SSRN 2020. [Google Scholar] [CrossRef]
  7. Chen, L.; Xu, L.; Shah, N.; Gao, Z.; Lu, Y.; Shi, W. On security analysis of proof-of-elapsed-time (poet). In Proceedings of the International Symposium on Stabilization, Safety, and Security of Distributed Systems, Boston, MA, USA, 5–8 November 2017; pp. 282–297. [Google Scholar]
  8. Milutinovic, M.; He, W.; Wu, H.; Kanwal, M. Proof of luck: An efficient blockchain consensus protocol. In Proceedings of the 1st Workshop on System Software for Trusted Execution, Trento, Italy, 12–16 December 2016; pp. 1–6. [Google Scholar]
  9. IntellectSoft. Top 10 Biggest IoT Security Issues. Available online: https://www.intellectsoft.net/blog/biggest-iot-security-issues (accessed on 25 September 2021).
  10. Neagle, C. Smart Refrigerator Hack Exposes GMAIL Login Credentials. Available online: https://www.networkworld.com/article/2976270/smart-refrigerator-hack-exposes-gmail-login-credentials.html (accessed on 25 September 2021).
  11. Beimel, A. Secret-sharing schemes: A survey. In Proceedings of the International Conference on Coding and Cryptology, Qingdao, China, 30 May–3 June 2011; pp. 11–46. [Google Scholar]
  12. Shamir, A. How to share a secret. Commun. ACM 1979, 22, 612–613. [Google Scholar] [CrossRef]
  13. Chor, B.; Goldwasser, S.; Micali, S.; Awerbuch, B. Verifiable secret sharing and achieving simultaneity in the presence of faults. In Proceedings of the 26th Annual Symposium on Foundations of Computer Science (sfcs 1985), Portland, OR, USA, 21–23 October 1985; pp. 383–395. [Google Scholar]
  14. Feldman, P. A practical scheme for non-interactive verifiable secret sharing. In Proceedings of the 28th Annual Symposium on Foundations of Computer Science (sfcs 1987), Los Angeles, CA, USA, 12–14 October 1987; pp. 427–438. [Google Scholar]
  15. Pedersen, T.P. Non-interactive and information-theoretic secure verifiable secret sharing. In Proceedings of the Annual International Cryptology Conference, Santa Barbara, CA, USA, 11–15 August 1991; pp. 129–140. [Google Scholar]
  16. Gennaro, R.; Rabin, M.O.; Rabin, T. Simplified VSS and fast-track multiparty computations with applications to threshold cryptography. In Proceedings of the Seventeenth Annual ACM Symposium on Principles of Distributed Computing, Puerto Vallarta, Mexico, 28 June–2 July 1998; pp. 101–111. [Google Scholar]
  17. Gilad, Y.; Hemo, R.; Micali, S.; Vlachos, G.; Zeldovich, N. Algorand: Scaling byzantine agreements for cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles, Shanghai, China, 28–31 October 2017; pp. 51–68. [Google Scholar]
  18. Micali, S.; Rabin, M.; Vadhan, S. Verifiable random functions. In Proceedings of the 40th Annual Symposium on Foundations of Computer Science (cat. No. 99CB37039), New York City, NY, USA, 17–19 October 1999; pp. 120–130. [Google Scholar]
  19. Hanke, T.; Movahedi, M.; Williams, D. Dfinity technology overview series, consensus system. arXiv 2018, arXiv:1805.04548. [Google Scholar]
  20. Boneh, D.; Lynn, B.; Shacham, H. Short signatures from the Weil pairing. J. Cryptol. 2004, 17, 297–319. [Google Scholar] [CrossRef] [Green Version]
  21. Uddin, M.A.; Stranieri, A.; Gondal, I.; Balasubramanian, V. An efficient selective miner consensus protocol in blockchain oriented iot smart monitoring. In Proceedings of the 2019 IEEE International Conference on Industrial Technology (ICIT), Melbourne, Australia, 13–15 February 2019; pp. 1135–1142. [Google Scholar]
  22. Lao, L.; Dai, X.; Xiao, B.; Guo, S. G-PBFT: A location-based and scalable consensus protocol for IOT-Blockchain applications. In Proceedings of the 2020 IEEE International Parallel and Distributed Processing Symposium (IPDPS), New Orleans, LA, USA, 18–22 May 2020; pp. 664–673. [Google Scholar]
  23. Puthal, D.; Mohanty, S.P.; Yanambaka, V.P.; Kougianos, E. Poah: A novel consensus algorithm for fast scalable private blockchain for large-scale iot frameworks. arXiv 2020, arXiv:2001.07297. [Google Scholar]
  24. Andola, N.; Venkatesan, S.; Verma, S. PoEWAL: A lightweight consensus mechanism for blockchain in IoT. Pervasive Mob. Comput. 2020, 69, 101291. [Google Scholar]
  25. Yazdinejad, A.; Srivastava, G.; Parizi, R.M.; Dehghantanha, A.; Karimipour, H.; Karizno, S.R. Slpow: Secure and low latency proof of work protocol for blockchain in green iot networks. In Proceedings of the 2020 IEEE 91st Vehicular Technology Conference (VTC2020-Spring), Antwerp, Belgium, 25–28 May 2020; pp. 1–5. [Google Scholar]
  26. Makhdoom, I.; Tofigh, F.; Zhou, I.; Abolhasan, M.; Lipman, J. PLEDGE: An IoT-oriented Proof-of-Honesty based Blockchain Consensus Protocol. In Proceedings of the 2020 IEEE 45th Conference on Local Computer Networks (LCN), Sydney, Australia, 16–19 November 2020; pp. 54–64. [Google Scholar]
  27. Dorri, A.; Jurdak, R. Tree-chain: A fast lightweight consensus algorithm for iot applications. In Proceedings of the 2020 IEEE 45th Conference on Local Computer Networks (LCN), Sydney, Australia, 16–19 November 2020; pp. 369–372. [Google Scholar]
  28. Naik, N. Choice of effective messaging protocols for IoT systems: MQTT, CoAP, AMQP and HTTP. In Proceedings of the 2017 IEEE International Systems Engineering Symposium (ISSE), Vienna, Austria, 11–13 October 2017; pp. 1–7. [Google Scholar]
  29. Shannon, C.E. A mathematical theory of cryptography. Bell Labs Tech. J. 1949, 28, 656–715. [Google Scholar] [CrossRef]
  30. Muñoz, A.; Maña, A.; González, J. Dynamic Security Properties Monitoring Architecture for Cloud Computing. In Security Engineering for Cloud Computing: Approaches and Tools; IGI Global: Hershey, PA, USA, 2013; pp. 1–18. [Google Scholar]
  31. AvastBusinessTeam. Data Security Issues in Cloud Computing; Avast: Prague, Czech Republic, 2020. [Google Scholar]
  32. Gai, K.; Guo, J.; Zhu, L.; Yu, S. Blockchain meets cloud computing: A survey. IEEE Commun. Surv. Tutor. 2020, 22, 2009–2030. [Google Scholar] [CrossRef]
  33. Luo, Y.; Deng, X.; Wu, Y.; Wang, J. MPC-DPOS: An efficient consensus algorithm based on secure multi-party computation. In Proceedings of the 2019 2nd International Conference on Blockchain Technology and Applications, Xi’an, China, 9–11 December 2019; pp. 105–112. [Google Scholar]
  34. Zhong, H.; Sang, Y.; Zhang, Y.; Xi, Z. Secure multi-party computation on blockchain: An overview. In Proceedings of the International Symposium on Parallel Architectures, Algorithms and Programming, Guangzhou, China, 12–14 December 2019; pp. 452–460. [Google Scholar]
  35. Cha, J.; Singh, S.K.; Kim, T.W.; Park, J.H. Blockchain-empowered cloud architecture based on secret sharing for smart city. J. Inf. Secur. Appl. 2021, 57, 102686. [Google Scholar] [CrossRef]
  36. Thwin, T.T.; Vasupongayya, S. Blockchain based secret-data sharing model for personal health record system. In Proceedings of the 2018 5th International Conference on Advanced Informatics: Concept Theory and Applications (ICAICTA), Krabi, Thailand, 14–17 August 2018; pp. 196–201. [Google Scholar]
  37. Bartolucci, S.; Bernat, P.; Joseph, D. SHARVOT: Secret SHARe-based VOTing on the blockchain. In Proceedings of the 1st International Workshop on Emerging Trends in Software Engineering for Blockchain, Gothenburg, Sweden, 27 May–3 June 2018; pp. 30–34. [Google Scholar]
  38. Mesnager, S.; Sınak, A.; Yayla, O. Threshold-Based Post-Quantum Secure Verifiable Multi-Secret Sharing for Distributed Storage Blockchain. Mathematics 2020, 8, 2218. [Google Scholar] [CrossRef]
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Article Metrics

Citations

Article Access Statistics

Multiple requests from the same IP address are counted as one view.