Using Secure Multi-Party Computation to Protect Privacy on a Permissioned Blockchain

Abstract

The development of information technology has brought great convenience to our lives, but at the same time, the unfairness and privacy issues brought about by traditional centralized systems cannot be ignored. Blockchain is a peer-to-peer and decentralized ledger technology that has the characteristics of transparency, consistency, traceability and fairness, but it reveals private information in some scenarios. Secure multi-party computation (MPC) guarantees enhanced privacy and correctness, so many researchers have been trying to combine secure MPC with blockchain to deal with privacy and trust issues. In this paper, we used homomorphic encryption, secret sharing and zero-knowledge proofs to construct a publicly verifiable secure MPC protocol consisting of two parts—an on-chain computation phase and an off-chain preprocessing phase—and we integrated the protocol as part of the chaincode in Hyperledger Fabric to protect the privacy of transaction data. Experiments showed that our solution performed well on a permissioned blockchain. Most of the time taken to complete the protocol was spent on communication, so the performance has a great deal of room to grow.

1. Introduction

Traditional centralized systems provide efficient and personalized service, but the negative effects of centralization are increasingly appearing: corruption, inequality and privacy issues. As it turns out, some decentralized technologies [1] are urgent. Blockchain is a peer-to-peer and decentralized ledger technology that has the characteristics of transparency, consistency, immutability and traceability. First popularized for crypto-currency systems such as Bitcoin [2], blockchain has seen explosive development in recent years. There are two types of blockchain: public and permissioned. Anyone can freely join a public blockchain and submit proposals, whereas a permissioned blockchain is dominated by a group of known nodes and restricts joining the network via access control.

A core problem is that all users who have joined the blockchain see an identical ledger, making it thorny to handle transactions that rely on confidential data [3]. Access control mechanisms are usually used to deal with the privacy requirements of the associated stakeholders in decentralized networks [4] such as blockchains. One instance is the Hyperledger Fabric Channel, which protects privacy by restricting data access, but the problem still exists, resulting from the fact that nodes in the same channel deal with identical transactions. A simpler solution is public key cryptography. In this solution, the participant encrypts a message using his public key and submits it to the ledger, but ciphertexts under different public keys can not be collaboratively analyzed. The privacy issues limit the wide application of blockchain.

Excitingly, the cryptographic technology of secure multi-party computation is a perfect way to deal with the problem of privacy. This concept dates back to what is called “Yao’s millionaires’ problem” [5], a famous problem introduced by Andrew Yao in 1982. Formally, we assume that n participants ($P_1,P_2,\dots ,P_n$) all hold the secret data $x_1,x_2,\dots ,x_n$ and that they are willing to cooperate to compute a function $(y_1,y_2,\dots ,y_n)$ ← $F(x_1,x_2,\dots ,x_n)$. Throughout the whole process, each participant $P_i$ only learns his own value $x_i,y_i$, and information can be derived from $y_i$. Beyond that, he learns nothing. Many studies have been undertaken in order to design secure multi-party computation (MPC) protocols, such as oblivious transfer [6], garbled circuit [7], homomorphic encryption [8] and the linear secret sharing scheme [9,10].

Secure MPC provides enhanced privacy, correctness and independence of inputs, and guarantees output delivery. Blockchain perfectly suits secure MPC protocols because they all deal with security and trust issues in distributed environments [11]. There are many practical scenarios that benefit from utilizing secure MPC based on blockchain, such as statistical analysis of health data [12], anonymous electronic voting [13], initial public offering(IPO) [3] and edge computing [14].

In this paper, we propose a publicly verifiable, secure MPC protocol to protect the transaction privacy of a permissioned blockchain. The protocol contains two parts: an on-chain computation phase and an off-chain preprocessing phase. Operations such as key generation, data encryption and generating pre-processing data are implemented off-chain, and secure computations are performed on-chain. The execution of the on-chain protocol is integrated as part of the chaincode in Hyperledger Fabric [15]. Concretely, this paper makes the following contributions:

(1) In the on-chain phase, we facilitate additive secret sharing and the Paillier cryptosystem, an additive homomorphism encryption scheme, to preserve the confidentiality of private data. Computations are based on encrypted shares and can be parallelized, which greatly resolves the N-1 attack problem. We integrated the on-chain protocol as part of the smart contract to utilize its correctness and verifiability. (2) We adopted zero-knowledge proof technology, specifically that of Pedersen [16], to construct a non-interactive verifiable secret sharing scheme and to prove the correctness of calculation tasks. Any stage and any intermediate result can be verified by opening commitments. (3) In the off-chain phase, based on Beaver randomization technology [17], we designed a new protocol to generate $<a,b,c,d>$ quadruples, making it possible to perform multiplication on encrypted secret shares (differently from SPDZ [18]). (4) Finally, we describe how to integrate our secure MPC protocol into Hyperledger Fabric. By adding a pluggable component called "decryptor" to Hyperledger Fabric, we allow peers to process decryption requests during the endorsement phase, which eliminates communication interactions among participants and the blockchain. For as long as decryptors are online, what participants need to do is encrypt, input and wait for outputs.

The remainder of the paper is structured as follows. In Section 2, previous studies on privacy protection in blockchains are briefly reviewed. In Section 3, details of the proposed method are described. Section 4 discusses the security issues surrounding the proposed method. In Section 5, experimental results of the computational performance are presented. In Section 6, we provide our conclusions on the work presented in this paper.

2. Related Work

Many works have been done to protect privacy in the blockchain in recent years. Frequently used cryptographic techniques [19] for privacy protection in blockchains [20,21,22,23] include ring signature, mixing services and zero-knowledge proof.

Here we mainly focus on investigating the development of the combination of blockchain and secure MPC. Bitcoin was first utilized to obtain fairness in a secure multi-party protocol [24,25,26]. Other researchers have also endeavored to deploy secure MPC on blockchains to solve the problem of privacy.

Sánchez [27] considered outsourcing encrypted computation to cloud-based blockchain and rewarding miners for generating preprocessing data for secure multi-party computation. To provide correctness, verifiability and privacy confidentiality for smart contracts in the blockchain, they combined proof-carrying code and secure multi-party computation, which effectively handle Gyges and DAO attacks. In addition, zero-knowledge proofs of proofs is used to prove the validity of smart contracts. Enigma, proposed by Zyskind et al. [28], is a blockchain-based decentralized computation platform. Their architecture consists of two parts: blockchain and Enigma. Enigma is an off-chain network responsible for private and intensive computations. Blockchain deals with access control, identity management, link protocols and the tamper-proof log of events in Enigma. They made a series of performance improvements to secure MPC, such as hierarchical secure MPC, adaptable circuits and network reduction, making the technology practical even when used in a large network. Kosba et al. [29] proposed HAWK, a user-friendly framework for creating smart contracts with guaranteed privacy. Hawk provides a compiler with which programmers have no necessity to implement any cryptography. It relies on a trusted manager to handle confidential data and the manager is trusted not to leak secrets, which can be implemented by trusted hardware or instantiated with multi-party computation. Choudhuri et al. [30] used witness encryption to transform the fairness problem in secure MPC into the one in decryption. They utilized bulletin boards such as Google’s certificate transparency logs and a blockchain to record some publicly untamable information. Participants need to release to the bulletin board tokens with shares, which others could use to decrypt ciphertext, and then they must publish their secret in limited time.

Some researchers focused on Hyperledger Fabric, a typical permissioned blockchain hosted by the Linux Foundation. Benhamouda et al. [31] used secure MPC to support private-data computation in Hyperledger Fabric. In contrast to previous studies, they integrated secure MPC protocols as part of the smart contract rather than running them in an off-chain network. However, their solution requires “privileged clients” that have access to the same private key peers used for data encryption. Ghadamyari et al. [12] also focused on Hyperledger Fabric. Although they facilitated the Paillier cryptosystem to obtain data privacy and used access control list rules to restrict access to the ledger, data owned by different participants are encrypted by the same public key, resulting in disclosing privacy when the owner of the private key and the invoker of the smart contract conspire.

The previous work can be classified into two main types: on-chain secure MPC protocols that integrate the protocols into the blockchain architecture itself, and off-chain secure MPC protocols that offload intensive computation to an off-chain network. Benhamouda [31] described a comparison between these two types of protocols, and we briefly sum that up as follows: Running the secure MPC on-chain enables us to take use of the blockchain facilities for communication and identity management, which need to be re-implemented in the off-chain secure MPC protocol. The core advantage of an off-chain secure MPC protocol is its efficiency of computation, but the situation is more applicable to permissionless blockchains, which are typically slower than permissioned ones. Thus, on-chain secure MPC protocols are more applicable to be deployed on permissioned blockchains, such as Hyperledger Fabric.

Our MPC-over-Fabric architecture is similar to the on-chain secure MPC protocol described by Benhamouda [31], but not quite the same. One key difference is that we do not require “privileged clients” or a “helper server”, which may raise some security concerns. Without any security assumptions, we add a pluggable component called a “decryptor” to the peer responsible for decrypting during the endorsement phase. Another difference is that secrets belong to the participants—the data providers who take part in computation through clients of the blockchain. Participants split their secrets into shares and encrypt these shares using different public keys, ensuring no single participant can see all of them. Endorsement peers only execute smart contracts, but those in [31] also serve as the entities with the secrets.

3. The Proposed Method

3.1. Overview of Our Framework

In this section, we describe the main framework of the proposed secure MPC computation scheme. Figure 1 shows the proposed architecture for secure MPC based on a blockchain, which contains two phases: an on-chain computation phase and an off-chain preprocessing phase. Operations such as generating preprocessing data, key generation and data encryption are implemented off-chain, and secure computations are performed on-chain. The execution of MPC computation protocol is integrated as part of the chaincode in Hyperledger Fabric.

The related parties are briefly explained as follows:

• Participant: the data owner.
• Peer: compute node in Hyperledger Fabric, concretely the endorsement node.
• Decryptor: a component in the Peer assisting decrypting during the endorsement phase. (details can be seen in Section 3.4.3).
• Compute function: the computational logic provided by participants.
• On-chain MPC protocol: the auxiliary protocol utilized to perform on-chain, secure, multi-party computation.
• Quadruple generation protocol: the protocol used to generate preprocessing data ($<a,b,c,d>$ quadruples) for on-chain secure multi-party computation.
• Sacrifice protocol: the protocol used to check whether a quadruple is valid.

A jointly secure computation task proceeds according to the following steps:

• (Off-chain preprocessing phase): All participants use the quadruple generation protocol to obtain a sufficient number of $<a,b,c,d>$ quadruples and check whether the quadruples are valid using the sacrifice protocol. This step is not necessary for every task. A huge number of quadruples can be generated in advance for future tasks.
• (On-chain computation phase): All participants break raw input values to secret shares, encrypt secret shares and quadruple shares, generate commitments and submit all of them to the ledger.
• (On-chain computation phase): Participants store the addresses of decryptors to the ledger.
• (On-chain computation phase): The invoker (one of the participants) invokes the MPC smart contract to execute the computation task.
• (On-chain computation phase): Participants decrypt their outputs, which can also be carried out by decryptors, and reconstruct the final result.

3.2. The Algorithms Used

In this section, we describe the cryptography algorithms used in our protocol.

(1)

Additive homomorphism encryption

Additive homomorphic encryption allows one to perform computations on ciphertext. The result of the calculation is the encryption of their sum.

Let AHE = (KeyGen, Enc, Dec, Add, Sub, cMul) be an instance of an asymmetric additive homomorphism encryption scheme. We will use the following definitions: The message space is denoted as $\stackrel{\sim }{M}$, and the ciphertext space is denoted as $\stackrel{\sim }{C}$. ⊕ denotes the addition of $\stackrel{\sim }{C}$ and ⊖ denotes the subtraction of $\stackrel{\sim }{C}$. The multiplication of a scalar plaintext $m\in \stackrel{\sim }{M}$ and a ciphertext $c\in \stackrel{\sim }{C}$ is denoted as ⊗, and the encryption of the plaintext message m is denoted as $\overline{m}\in \stackrel{\sim }{C}$. AHE is denoted as follows:

• KeyGen($\kappa$): takes the security parameter $\kappa$ as the input, and outputs the private key sk and the public key pk.
• Enc(pk, m): takes the message $m\in \stackrel{\sim }{M}$ and the public key pk as the inputs, and outputs the ciphertext $\overline{m}\in \stackrel{\sim }{C}$.
• Dec(sk, c): takes the ciphertext $c\in \stackrel{\sim }{C}$ and a private key sk as the inputs, and outputs the decrypted result $m\in \stackrel{\sim }{M}$.
• Add(c1, c2): takes two ciphertexts $c1,c2\in \stackrel{\sim }{C}$ as the inputs, and outputs the ciphertext $c3=c1⨁c2$, so that $Dec(sk,c3)=Dec(sk,c1)+Dec(sk,c2)$
• Sub(c1, c2): takes two ciphertexts $c1,c2\in \stackrel{\sim }{C}$ as the inputs, and outputs the ciphertext $c3=c1\ominus c2$, so that $Dec(sk,c3)=Dec(sk,c1)-Dec(sk,c2)$
• cMul(m1, c1): takes the scalar $m1\in \stackrel{\sim }{M}$ and the ciphertext $c1\in \stackrel{\sim }{C}$ as the inputs, and outputs the ciphertext $c2=m1⨂c1\in \stackrel{\sim }{C}$, so that $Dec(sk,c2)=m1\ast Dec(sk,c1)$

In this paper, we use the popular Paillier [32] cryptosystem as the additive homomorphism encryption scheme due to its simple structure and high execution efficiency. It has been applied to many practical scenarios, such as electronic voting and federated learning. The Paillier cryptosystem has the plaintext space ${\mathbb{Z}}_N$ and the ciphertext space ${\mathbb{Z}}_{N^2}$*, and N is the security parameter.

(2)

Additive secret sharing

In this paper, we use (n,n)-threshold additive secret sharing scheme and its implementation is as follows [33].

• Secret shares: To share a secret a, the dealer chooses $n-1$ random shares $a_j$ ($j=1,2,\dots ,n-1$) in GF(p), and computes $a=a_n+{\sum }_{j=1}^{n-1}{a}_i\left(modp\right)$. The dealer then sends the shares $a_i$ to participant $P_i$ ($i=1,\dots ,n$).
• Secret reconstruction: All participants collaboratively reconstruct the secret: $a={\sum }_{j=1}^n{a}_i\left(modp\right)$.

The above implementation possesses additive homomorphism. Concretely, if participants $P_1,P_2,\dots ,P_n$, respectively, hold shares $a_1,a_2,\dots ,a_n$ and $b_1,b_2,\dots ,b_n$ that are associated with secrets a and b, the shares of $(a+b)$ are $a_1+b_1,a_2+b_2,\dots ,a_n+b_n$.

(3)

Pedersen

Pedersen [16,34] is a non-interactive commitment scheme with additive homomorphism, so we can easily perform the same calculation on commitments to prove the correctness of the results at any stage. We use Pedersen to construct our non-interactive verifiable secret sharing scheme. There are three phases in the Pedersen scheme used in our proposed method:

• Setup Phase: All participants agree on an elliptic curve E over a field $F_n$, a generator $G\in E/F_n$ and $H\in E/F_n$.
• Commitment Phase: Participant $P_i$ chooses a random number $r\in F_n$, and computes the point $Com{m}_i=C(x_i,r)=r\ast G+x_i\ast H$, which represents the commitment for $P_i$’s secret $x_i$. r is a blinding factor that prevents observers from guessing $x_i$. $P_i$ sends $Com{m}_i$ to the receiver $P_j$.
• Open Phase: $P_i$ sends ($x_i$, r) to the receiver $P_j$ and $P_j$ verifies whether $r\ast G+x_i\ast H$ equals $Com{m}_i$. $P_j$ refuses the commitment if they are not equal.

The Pedersen algorithm also has additive homomorphism and it is easy to prove the following equations:

$$\begin{array}{c}\hfill Comm(v1+v2,r1+r2)=Comm(v1,r1)+Comm(v2,r2)\\ \hfill Comm(v1-v2,r1-r2)=Comm(v1,r1)-Comm(v2,r2)\\ \hfill Comm(c\ast v,c\ast r)=c\ast Comm(v,r)\end{array}$$

3.3. The Secure MPC Protocol

In this section, we present the core idea of our secure MPC protocol. Since a blockchain is completely public, we aim to build a protocol for multi-party arithmetic computation over $F_p^k$, which is composed of addition and multiplication, and has the following characteristics:

• Privacy confidentiality: All the input values and output values are in encrypted form and no one learns anything except his own input secret and output values.
• Publicly verifiable: Computations can be publicly executed and are controlled by no one. Any step during computation can be publicly verified.

Similarly to SPDZ [18], structured in an offline phase and an online phase, our solution consists of an on-chain computation phase and an off-chain preprocessing phase. We combine additive secret sharing and the Paillier cryptosystem to preserve the confidentiality of privacy. Computations are based on encrypted shares, which can be parallelized. What is more, the Pedersen system is utilized to ensure the verifiability of secret sharing and computations.

We assume a publicly trusted processor (PTP), which can be instantiated with a trusted execution environment (TEE) or a trusted player. In this paper, the smart contract in the blockchain plays the role of PTP. PTP receives inputs, calculates functions and generates outputs without mistakes. All behaviors of PTP are public and can be verified.

3.3.1. On-Chain Computation Procotol

The on-chain computation phase consists of four sub-protocols—protocol input, protocol addition, protocol multiplication and protocol output. We assume enough $<a,b,c,d>$ quadruples have been generated in the off-chain preprocessing phase. Details about quadruple generation can be seen in Section 3.3.2.

• Protocol Input

• All participants $P_i(i=1,2,\dots ,m)$ use the Paillier algorithm to generate their private key $s{k}_i$ and public key $p{k}_i$.
• Each participant $P_i$ serves as a dealer, who uses additive secret sharing to break his secret $S_i$ to n shares $S_{ij}$ ($j=1,2,\dots ,n$), and then $P_i$ encrypts the share for $P_j$ using $P_j$’s public key:

  $$\overline{S_{ij}}\leftarrow Enc(p{k}_j,S_{ij}),j=1,2,\dots ,n$$

  (1)
• $P_i$ chooses n random blinding factor $x_{ij}\in F_n$($j=0,1,2,\dots ,n$), and computes the commitments for shares $S_{ij}$($j=1,2,\dots ,n$):

  $$Com{m}_{ij}=C(S_{ij},x_{ij})\leftarrow x_{ij}\ast G+S_{ij}\ast H,j=1,2,\dots ,n$$

  (2)
• $P_i$ encrypts the blinding factor:

  $$\overline{x_{ij}}\leftarrow Enc(p{k}_j,x_{ij}),j=1,2,\dots ,n$$

  (3)
• $P_i$ generates the commitment of the secret value itself:

  $$Com{m}_i=C(S_i,x_0)\leftarrow x_0\ast G+S_i\ast H,x_0=\sum _{k=1}^n{x}_k$$

  (4)
• Finally, $P_i$ submits his input

  $$\{\overline{S_{i1}},\overline{S_{i2}},\dots ,\overline{S_{in}},Com{m}_i,Com{m}_{i1},Com{m}_{i2},\dots ,Com{m}_{in},\overline{x_{i1}},\overline{x_{i2}},\dots ,\overline{x_{in}}\}$$

  (5)

  to PTP.

Other participants $P_j(j\ne i)$ can freely get $P_i$’s input from PTP and decrypt $\overline{S_{ij}},\overline{x_{ij}}$ using his secret key $s{k}_j$, and then open and verify the commitments by checking whether the following equations are all true:

$$\begin{array}{cc}\hfill Dec(s{k}_j,\overline{x_{ij}})\ast G& + Dec(s{k}_j,\overline{S_{ij}})\ast H=Com{m}_{ij}\hfill \\ & Com{m}_i=\sum _{k=1}^{n}Com{m}_{ik}\hfill \end{array}$$

(6)

If true, the share $S_{ij}$ is valid and $P_i$ splits his secret value correctly, meaning the $P_i$ has honestly submitted his input.

Moreover, participants must submit enough quadruples $<a,b,c,d>$ and commitments of quadruples shares to PTP before computation. $P_i$ encrypts his quadruple shares using his public key $p{k}_i$ and submits it to PTP:

$$<\overline{a_{ik}},\overline{b_{ik}},\overline{c_{ik}},\overline{d_{ik}}>\leftarrow Enc(s{k}_i,<a_{ik},b_{ik},c_{ik},d_{ik}>),kistheindexofquadruples$$

(7)

(2)

Protocol Addition

An addition gate is defined as follows:

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill \{\overline{y_1},\overline{y_2},\dots ,\overline{y_n}\}& \leftarrow \tilde{F}(\overline{<S_1>},\overline{<S_2>},\dots ,\overline{<S_m>})\hfill \\ \hfill \overline{<S_k>}& \leftarrow (\overline{S_{k1}},\overline{S_{k2}},\dots ,\overline{S_{kn}}),k=1,2,\dots ,m\hfill \end{array}\end{array}$$

(8)

The inputs are the encrypted shares of secret inputs $S_i$ ($i=1,2,\dots ,m$), and there are n output values for n participants. The i-th output value $\overline{y_i}$ is a ciphertext encrypted by $P_i$’s public key $p{k}_i$. We define the addition gate as computation of any linear function:

$$F(·)\leftarrow \sum _{i=1}^m{c}_i\ast S_i$$

(9)

• To compute $S_i+S_j$, PTP computes:

  $$\overline{y_k}=\overline{S_{ijk}}\leftarrow \overline{S_{ik}}\oplus \overline{S_{jk}},k=1,2,\dots ,n$$

  (10)
• For a public scalar $c\in GF\left(p\right)$ and a secret input $S_i$, to compute $c\ast S_i$, PTP computes:

  $$\overline{y_k}=\overline{S_{cik}}\leftarrow c\otimes \overline{S_{ik}},k=1,2,\dots ,n$$

  (11)
• To compute $c+S_i$, PTP computes:

  $$\begin{array}{c}\overline{y_k}=\overline{S_{cik}}\leftarrow \overline{c_k}\oplus \overline{S_{ik}},k=1,2,\dots ,n\\ (\overline{c_1}=Enc(s{k}_1,c),\overline{c_j}=Enc(s{k}_j,0)(j=2,\dots ,n))\end{array}$$

  (12)

Since both (n,n)-threshold additive secret sharing and the Paillier cryptosystem are additively homomorphic, any linear function with n inputs can be computed locally without interactions.

Then, we can prove the equation:

$$F(S_1,S_2,\dots ,S_m,c_1,c_2,\dots ,c_m)=\sum _{k=1}^{n}Dec(s{k}_k,\overline{y_k})$$

(13)

• For $S_i+S_j$:

  $$\sum _{k=1}^{n}Dec(s{k}_k,\overline{y_k})=\sum _{k=1}^n(S_{ik}+S_{jk})=S_i+S_j$$

  (14)
• For $c\ast S_i$:

  $$\sum _{k=1}^{n}Dec(s{k}_k,\overline{y_k})=\sum _{k=1}^{n}c\ast S_{ik}=c\ast S_i$$

  (15)
• For $c+S_i$:

  $$\sum _{k=1}^{n}Dec(s{k}_k,\overline{y_k})=(c+S_{i1})+\sum _{k=2}^n(0+S_{ik})=c+S_i$$

  (16)

Moreover, the commitments of outputs can be calculated in the same way to provide the verifiability:

$$Com{m}_{y_k}\leftarrow F(Com{m}_{1k},Com{m}_{2k},\dots ,Com{m}_{mk},c_1,c_2,\dots ,c_m),k=1,2,\dots ,n$$

(17)

$$Com{m}_y\leftarrow F(Com{m}_1,Com{m}_2,\dots ,Com{m}_m,c_1,c_2,\dots ,c_m)$$

(18)

The result holds since the Pedersen algorithm is additively homomorphic.

Note that we do not need open commitment after every addition gate, resulting from the fact that the addition gate can be automatically operated by PTP without interactions (except the final one).

(3)

Protocol Multiplication

A multiplication gate is defined as follows:

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill \{\overline{y_1},\overline{y_2},\dots ,\overline{y_n}\}& \leftarrow \stackrel{\sim }{F}(\overline{<S_1>},\overline{<S_2>},\dots ,\overline{<S_m>})\hfill \\ \hfill \overline{<S_k>}& \leftarrow (\overline{S_{k1}},\overline{S_{k2}},\dots ,\overline{S_{kn}})\hfill \end{array}\end{array}$$

(19)

The input is the encrypted shares of secret inputs $S_i$ ($i=1,2,\dots ,m$), and there are n output values for n participants. The i-th output value $\overline{y_i}$ is a ciphertext encrypted by $P_i$’s public key $p{k}_i$. We define the multiplication gate as the computation of the multiplicative monomial:

$$F(·)\leftarrow \prod _{i=1}^m{S}_i$$

(20)

Multiplication consumes $<a,b,c,d>$ quadruples, which is similar to Beaver triples [17]. The basic process is as follows:

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill x\ast y& =(x-a+a)\ast (y-b+b)\hfill \\ \hfill & =(x-a)(y-b)+a(y-b)+b(x-a)+ab\hfill \\ \hfill & =t\ast s\ast d+a\ast s+b\ast t+c\hfill \end{array}\end{array}$$

(21)

a, b and c are random finite field elements unknown to everyone, and d equals 1. d is necessary because it makes it possible to perform Beaver Multiplication [17] in encrypted form.

To compute $S_i\ast S_j$, there are three steps:

• Obtain the encrypted shares of $S_i-a$ and $S_j-b$:

  $$\begin{array}{c}\hfill \begin{array}{cc}\hfill \overline{T_{siak}}& \leftarrow \overline{S_{ik}}\ominus \overline{a_k},k=1,2,\dots ,n\hfill \\ \hfill \overline{T_{sjbk}}& \leftarrow \overline{S_{jk}}\ominus \overline{b_k},k=1,2,\dots ,n\hfill \end{array}\end{array}$$

  (22)
• Obtain t, s and $ts$:

  $$\begin{array}{c}\hfill \begin{array}{cc}\hfill t\leftarrow \sum _{k=1}^n& Dec(s{k}_k,\overline{T_{siak}})\hfill \\ \hfill s\leftarrow \sum _{k=1}^n& Dec(s{k}_k,\overline{T_{sjbk}})\hfill \\ \hfill ts& \leftarrow t\ast s\hfill \end{array}\end{array}$$

  (23)
• Obtain the encrypted shares of $S_i\ast S_j$:

  $$\overline{y_k}=\overline{T_{sijk}}\leftarrow (ts\otimes \overline{d_k})\oplus (s\otimes \overline{a_k})\oplus (t\otimes \overline{b_k})\oplus \left(\overline{c_k}\right),k=1,2,\dots ,n$$

  (24)

Now we have:

$$\begin{array}{cc}\hfill \sum _{k=1}^{n}Dec(s{k}_k,\overline{y_k})& =\sum _{k=1}^n(ts\ast d_k+s\ast a_k+t\ast b_k+c_k)\hfill \\ \hfill & =ts\ast \sum _{k=1}^n{d}_k+s\ast \sum _{k=1}^n{a}_k+t\ast \sum _{k=1}^n{b}_k+\sum _{k=1}^n{c}_k\hfill \\ \hfill & =ts+s\ast a+t\ast b+c\hfill \\ \hfill & =(S_i-a)\ast (S_j-b)+a\ast (S_j-b)+b\ast (S_i-a)+a\ast b\hfill \\ \hfill & =(S_i-a+a)\ast (S_j-b+b)\hfill \\ \hfill & =S_i\ast S_j\hfill \end{array}$$

(25)

Therefore, the result is correct.

To reduce the communication complexity and improve the computation efficiency, we build our multiplication gate in a hierarchical way, as shown in Figure 2. Assuming the length of a multiplicative monomial is m, then the depth of the multiplication gate is $log\left(m\right)$, and computations in the same layer can be performed in parallel. The maximum depth of an arithmetic computation equals the maximum depth of monomials—$log\left(m\right)$.

$$log\left(M\right)\leftarrow max(log\left(m_1\right),log\left(m_2\right),\dots )$$

(26)

As with the addition gate, we can perform the same computation on the blinding factor $x_{ij}$ to get the commitments of the outputs, and verify the correctness by opening commitments. In contrast, some decryption operations exist in the multiplication gate, which are performed by participants (decryptors) rather than PTP, leading to untrusted interactions. However, we do not need to open commitments after every multiplication gate. We can open commitments forwardly only when it fails to open the final commitments.

Any tamper behavior during the decryption phase would never succeed because PTP detects the attack by checking the commitments.

(4)

Protocol Output

The output is n ciphertexts, i-th of which is encrypted by $P_i$’s public key $p{k}_i$.

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill \{\overline{y_1},\overline{y_2},\dots ,\overline{y_n}\}& \leftarrow \stackrel{\sim }{F}(\overline{S1},\overline{S2},\dots ,\overline{Sn})\hfill \\ \hfill \sum y_i& =F(s_1,s_2,\dots ,s_n)\hfill \end{array}\end{array}$$

(27)

The input values are secretly shared by the input gate and the computations of the addition gate and multiplication gate are based on encrypted shares, which reveal no information about input values. According to the analysis above, the corresponding commitments of the output values can be opened and checked, ensuring the result is corrected.

Participants require all the decrypted shares to recover the final result:

$$Y\leftarrow \sum _{i=1}^{n}Dec(s{k}_i,\overline{y_i})$$

(28)

3.3.2. Off-Chain Preprocessing Protocol

The off-chain preprocessing phase generates multiplicative $<a,b,c,d>$ quadruples, which is independent of inputs and can be generated in large amounts in advance.

$$c=a\ast b,d=1$$

(29)

a, b and c are random finite field elements unknown to everyone. Our off-chain protocol is similar to that in SPDZ [18], but there are some modifications to support our on-chain protocol. Like the generation of Beaver triples in [18,35], generating the quadruples is an expensive process based on somewhat homomorphic encryption (SHE), but it is independent of the onchain protocol so it can be preprocessed.

Participants distributedly generate a quadruple $<a,b,c,d>$ where a, b and c are unknown to everyone and d equals 1. $P_i$ holds $a_i,b_i,c_i,d_i$, which is the i-th share of $<a,b,c,d>$. The details of the generation are provided below.

• Each participant $P_i$ generates $a_i,b_i\in F_p^k$. Let

  $$a:=\sum _{i=1}^n{a}_i,b:=\sum _{i=1}^n{b}_i$$

  (30)
• Each participant $P_i$ computes and broadcasts

  $$\overline{a_i}\leftarrow Enc(pk,a_i),\overline{b_i}\leftarrow Enc(pk,b_i)$$

  (31)
• All participants set

  $$\overline{a}\leftarrow \overline{a_1}\oplus \dots \oplus \overline{a_n},\overline{b}\leftarrow \overline{b_1}\oplus \dots \oplus \overline{b_n},\overline{d}=Enc(pk,1)$$

  (32)
• All participants compute $\overline{c}\leftarrow \overline{a}\otimes \overline{b}$
• Participants set

  $$\begin{array}{c}\hfill \begin{array}{cc}\hfill (c_1,\dots ,c_n,\overline{c^{{}^{\prime }}})& \leftarrow Reshare(\overline{c},NewCiphertext)\hfill \\ \hfill (d_1,\dots ,d_n,\overline{d^{{}^{\prime }}})& \leftarrow Reshare(\overline{d},NewCiphertext)\hfill \end{array}\end{array}$$

  (33)
• Participants invoke “Sacrifice” to check that indeed $a\ast b=c$:

  $$\{true,false\}\leftarrow Sacrificing(<a,b,c>)$$

  (34)

“Reshare” and “Sacrifice” are the same as that in SPDZ, and an overview of them is provided below:

Protocol Reshare($\overline{m}$, NewCiphertext): Takes a ciphertext $\overline{m}\in \stackrel{\sim }{C}$ as the input, and outputs a new secret sharing $m_1,m_2,\dots ,m_n\in \stackrel{\sim }{M}$ and a new “fresh” ciphertext $\overline{m^{{}^{\prime }}}\in \stackrel{\sim }{C}$ such that $Dec(sk,\overline{m^{{}^{\prime }}})={\sum }_i{m}_i$.

Protocol Sacrifice ($<a,b,c>$): Takes a triple and outputs whether the triple satisfies $c=a\ast b$.

3.4. On-Chain Secure MPC in Hyperledger Fabric

3.4.1. A Brief Introduction to Hyperledger Fabric

In Hyperledger Fabric, peers have access to the ledger and execute specific programs—chaincode (smart contract). Clients send transaction proposals to one or more peers with setting the endorsement policy. The endorsing peers then execute the chaincode to decide whether the transaction should be endorsed. If so, endorsing peers change the state on the ledger according to the targeted chaincode. An endorsement policy is a condition on what endorses a transaction [15]. Thus a pre-specified endorsement policy is necessary when installing specific chaincode. Some example endorsement policies include “at least one from among the four organizations” and “all organizations”.

A critical detail is that all endorsing peers see identical transaction proposals (no matter whether they would be accepted in the next phase). Transactions are executed and verified in the endorsement phase so we run our on-chain compute protocol during that phase.

3.4.2. A Crucial Additional Component

A participant is a data provider who connects to the blockchain network by a client. Any participant can own at least one peer, through which he can join in one or more organizations in Fabric. As mentioned earlier, participants store encrypted inputs in the ledger (PTP). As inputs are encrypted by different public keys, we need to deal with the question of how to perform decryption while executing multiplication gate. Unlike the solution of Benhamouda [31], we do not require “privileged clients” or a “helper server”. Participants each store their private keys locally in one of their peers that serves as a “decryptor”, which is responsible for processing decryption requests during the endorsement phase. A decryptor does not need to be an endorsing node, but it must remain online during the endorsement phase.

The decryptor utilizes cache technology to avoid processing duplicate decryption requests since different endorsing peers execute identical transactions during the endorsement phase. When receiving same requests, decryptors immediately obtain the result from the cache and respond. A decryptor is a pluggable component, so we do not need to do many code modifications to Fabric.

Moreover, a decryptor helps to eliminate communication interactions among participants and the blockchain. For as long as the decryptors are online, all a participant needs to do is encrypt and submit his input and wait for the outputs.

3.4.3. Implementation Details

The details of our secure MPC protocol are explained in Section 3.3. Here, we describe how the protocol can be integrated into Fabric.

Our MPC library was written in C++, and we used Java chaincode in Fabric. To call the MPC library in Java chaincode, we used JNI [36] technology, which allows us to call C++ code from Java. We used a customized Docker container, fabric-javaenv, where our MPC library was installed.

In regard to the implementation, there are two problems. The first is how the chaincode find the correct decryptors that it needs to communicate with. The second problem is how to tell decryptors the progress of the computation so it can verify whether the decryption request is valid and whether to accept the request. To solve the first problem, we opted for simple solutions where decryptors’ addresses (IP address and port) are dynamically written into the ledger as transaction proposals by clients in advance. The solution requires no code modifications to Hyperledger Fabric.

To solve the second problem, we need some definitions to the data packet of the decryption request:

The mpcId is a unique id used to distinguish different computation requests. The stepId, which increases from 0, represents the progress of the current computation and is controlled by the chaincode. With mpcId and stepId, decryptors are able to check whether the request corresponds to a correct step by calculating the commitments locally and opening commitments after decrypting the data. If succeeding in opening commitments, decryptors store them into the cache and respond. If it fails, they ignore the request. Note that the results of decryption are some random values, which reveal no information about input values.

4. Security Analysis

In this section, we discuss the security issue of our solution. As we pointed out at the beginning, the most critical problem is the leakage of the input data. No one should be able to learn anything except for their own inputs and outputs.

Data privacy and Privacy control: The combination of homomorphic encryption and secret sharing allows computations to be performed on the encrypted shares. $P_i$ encrypts different share using different participants’ public key so that other participants can only see their own authorized share, which are meaninglessly random values and would never reveal any valid information about $P_i$’s input value $S_i$. No secret can be reconstructed without decrypting all the shares. What’s more, intermediate data (t and s) generated by decryptors are meaninglessly random values if no participant knows a or b of the $<a,b,c,d>$ quadruple (actually it is). According to our settings, $P_i$ holds the i-th share of a and b, and no one knows a or b. Commitment $Comm(x,a)$ is theoretically private since there exist many possible combinations of x and a that would generate the same Comm. Even with the same private data a, $Comm(x,a)$ would be totally different when different values of x exist. If x is truly random, an attacker would be completely unable to figure out a [37].

Resistance to collusion attacks: In our solution, a secret is broken into shares by the additive secret sharing scheme and then different shares are encrypted by different participants’ public key. The threshold of the additive secret sharing scheme is n, which means our scheme remains safe even there are up to $n-1$ conspiracy adversaries among the participants. PTP automatically verifies the data decrypted by decryptors by opening commitments so that decryptors fail upon tampering.

Publicly verifiable MPC: Participants can verify whether the input value is valid and whether the dealer is honest by opening commitments. Due to commitments being public and automatically computed by PTP, everyone can check the correctness of the result by opening commitments. Although there are interactions in the multiplication gate, an active attack can be defended against, since any tamper behavior during the decryption phase would never succeed because PTP detects the attack by verifying the commitments.

Trust model: The trust model of the proposed on-chain secure MPC protocol depends on the endorsement policy set when installing the chaincode. For example, if the trust model allows no more than k adversarial participants, we can simply set an endorsement policy that demands at least $k+1$ endorsing peers, guaranteeing that transactions tampered by some adversaries will never be successfully endorsed.

5. Experimental Results and Discussions

Our running environment was ubuntu 18.04, Intel(R) Core(TM) i5-6400 CPU @ 2.70 GHz, 16 GB of RAM and Hyperledger Fabric v1.4.0. We used the customized Docker container fabric-javaenv, as mentioned in Section 3.4.3, for chaincode execution. Peers and chaincode were all running on separate Docker containers on the same machine. We communicated with the blockchain network using Hyperledger Fabric SDK for Java v1.4.0. In all of our experiments, each organization had only a single peer and peers belonged to different participants. We set “all organizations” as the endorsement policy, meaning that the number of participants equals the number of computing nodes.

5.1. Comparison of Running Time Based on Different Key Sizes

In this experiment, we studied the impact of key size in Paillier Cryptosystem on running time. We jointly computed the weighted average of inputs from 10 participants and set i as the weight of $P_i$. Thus, the function is

$$F(·)=\frac{{\sum }_{i=1}^{n}i\ast S_i}{{\sum }_{i=1}^{n}i},n=10$$

(35)

Figure 3 shows the total response time for securely computing the above function based on our secure MPC protocol, and the CPU time in a single node (ignoring the consensus time or communication time).

(1) It can be seen that the total response time ranges from 91.61 milliseconds for 512 bits to 430.48 milliseconds for 4096 bits, and the CPU time in a single node ranges from 1.71 milliseconds for 512 bits to 14.3 milliseconds for 4096 bits. Both response time and CPU time grow with the increase in key size. This is normal because of the larger ciphertext and the increasing computational complexity, but it leads to higher security.

(2) In addition, the CPU time is negligible compared to the total response time. Even when the key size is 4096 bits, the CPU time accounts for less than 4% of the total response time, and most of the time is spent on communication and reaching consensus, meaning that the performance has a lot of room to grow with the increasing optimization of communication channels.

The NIST [38] recommends 2048-bit key as the standard key size. Therefore, for simplicity, we use a 2048-bit key in the following experiments.

5.2. Comparison of Response Time Based on Different Schemes

In this experiment, we compared the response times for securely computing the sum of two inputs with an increase in the number of participants (computing nodes) based on three other schemes and our solution in this paper. The results are shown in Figure 4.

Scheme 1 offloads private and intensive computations to an off-chain network. Similar to our solution, scheme 2 runs the secure MPC protocol on-chain and uses the Paillier cryptosystem. Scheme 3 has the same architecture as that in scheme 2, but we replace its homomorphic encryption scheme with BFV [39] to support multiplicative homomorphic operations by using the SEAL [40] (an open-source library contributed by Microsoft).

(1) As illustrated, when there are no more than 20 computing nodes, our solution takes less time compared to scheme 1, but it seems that scheme 1 has a better performance when the network is large. This is because scheme 1 only stores MACs [18] and commitments on the blockchain for verification. Additionally, they separate the verification from computation, which is offloaded to an off-chain network. The architecture makes it efficient to perform computations in a large network, but it has similar performance in a small one. Differently, we take the on-chain way. When peers finish endorsement, both computations and verifications are done. The one-step method saves the performance. When the network grows, the overhead time required for consensus increases gradually, resulting in long latency. Therefore, our solution is more suitable for computations in permissioned blockchain, such as Hyperledger Fabric, which meets the initial goal in this paper.

(2) We can see that scheme 2 consumes the least time. However, compared with our solution, the time consumption difference is quite small. Both of us use the Paillier cryptosystem, but organizations in scheme 2 encrypt values using the same key. Although they use access control list (ACL) rules to control access to the ledger, there still exists a conspiracy between the key owner and smart contract invoker. Differently, our scheme remains safe even there are up to $n-1$ conspiracy adversaries according to the above analysis. What is more, scheme 2 only supports addition operations or scalar multiplication operations, but we are able to perform multiplication on ciphertext, which is deserved at the expense of a small loss in the computational performance.

(3) Figure 4 shows that scheme 3 consumes the most time among all solutions based on blockchain, because the performance of fully homomorphic encryption (FHE) is currently quite inefficient. Many experts and scholars are making efforts to find a balance between utility, protection and performance.

(4) In addition, we can see that, even for 20 nodes, the running time of our solution is about 350 milliseconds, which is longer than the time it takes to commit a block (concretely 2254 milliseconds for ten organizations in our experimental environment).

6. Conclusions and Future Work

In this paper, we proposed a publicly verifiable, secure MPC protocol consisting of two parts: an on-chain computation phase and an off-chain preprocessing phase. The scheme has the following advantages: (1) Privacy confidentiality: all input values and output values are in encrypted form and everyone learns nothing except his own input secret and output values. (2) Correctness and verifiability: Computations can be publicly executed and are controlled by no one. All the steps during computation can be publicly verified. We also described how the proposed secure MPC protocol can be integrated into Hyperledger Fabric, which helps to handle transactions that rely on confidential data owned by different participants. The scheme greatly guarantees the privacy of smart contract execution. The experiments showed that our solution had good execution efficiency. Meanwhile, most of the time taken to complete the protocol was spent on communication so the performance has a great deal of room to grow.

The expensive communication costs limit our solution’s scalability to a larger network. In the future, we will explore the ways in which communication times and data exchange during computation can be reduced, or try to build a more efficient P2P communication channel for the decryptor. Moreover, using the proposed method to solve practical problems such as statistical analysis on credit data with guaranteed privacy is also among our plans.