In this section, we will provide a detailed description of our scheme.
5.1. Overview
As shown in
Figure 1, we designed a novel and efficient scheme to combine private information about users in healthcare centers and insurance companies to make valuable decisions while validating the correctness of decision-making results. The scheme is based on the SPDZ protocol and Pedersen commitments and is divided into offline and online phases. The offline phase primarily provides the necessary preprocessing and information exchange for the subsequent online computation phase and generates the required parameters for validation. The online phase enables the participants to securely compute the decision results together, without revealing their respective private inputs and ultimately returns the results to HV for correctness validation. The decision-making algorithm used in the online computation phase is derived from real-world applications, which will be described in detail in the last subsection of this section.
Online phase: In this phase, SMPC nodes carry out the computational steps and obtain the required decision-making results while protecting privacy. However, to validate the results, modifying the shared values in the original SPDZ protocol with Pedersen commitments is essential. On the other hand, we assumed that there is a transcript
on the HV to store the communication data sent by the computational nodes, and we used Algorithm 1 to keep an eye on all values needed for validation.
Algorithm 1: Store_Load—algorithm for storing and loading message on the transcript . |
|
Offline phase: As the name suggests, this phase can be completed in advance, allowing it to generate the necessary randomness for the online computation phase. For example, it can createsecret keys for message authentication codes, ample multiplication triples, commitment parameters required for result validation, etc. These preprocessing and generation of necessary parameters in the offline phase significantly enhance the efficiency of online computation. The SMPC nodes run the offline phase of the protocol, preparing all correlated randomness for the online phase, including some parameters necessary for the validator.
5.2. Online Phase
To enforce the validation of the output, it is essential to modify the shared values in the original SPDZ protocol. Specifically, we propose altering the inputs, opened values, and outputs of the computational nodes at the point of their commitment. These modified values are then transmitted to the transcript on the HV, where the correctness of all intermediate steps can be verified. The Pedersen commitment scheme is information-theoretically hiding during the whole computation process. When we open a Pedersen commitment , we reconstruct both x and , and the HV can check that it is correct.
Let
,
, and then, we define the new way to represent shared value
x with a Pedersen commitment as
where
is a representation of
x as introduced in
Section 4.1. Similarly, with this new linear representation, we can perform the same operations linearly as in
Section 4.1. We can still employ Beaver’s circuit randomization technique for the multiplication of
and
since the representation is linear.
Given that operations in the online phase depend on multiplication triples and the randomness required for the validation phase, we define the functionality that describes the behavior and output of the preprocessing. In general, must perform the following: (1) establish an additively secret-sharing MAC key ; (2) generate random shared values to be used during Input; (3) generate shared Beaver triples for every multiplication to be performed in the online phase.
In
Figure 2, we present the protocol of the online phase. It uses
for the offline phase and the transcript
for all communication.
At the beginning step Prepare, the parties generate the parameters of the Pedersen commitment via a Common Reference String (CRS), establish the secret shared MAC key , as well as produce views for random triples , where . Once the offline phase is called to obtain the initial randomness, a new input-independent view can be utilized to generate the values for the Input step. Each party submits a value to the computation, where each uses the new to secretly open it. Then, each can check the correctness of the commitment on it and use to mask his/her input.
Similarly, in
Compute, the provided triples (
) will be used in the computation. They are used to multiply with linear operations as follows:
and are opened values. Other linear operations (addition, subtraction, or with publicly known constants) can be performed locally. The last operation left for the step is outputting the results. Here, we ran the MAC check to verify the result y and its correlated ; thus, the parties can open the output and send the result to transcript pending further validation.
In the final step Validate, the validator HV will execute the calculation process gate by gate as was performed by . For the records on the transcript , the HV checks every opened value. When this is performed, the result of the computation and the commitment of [y] will finally be checked for correctness against the views on .
5.3. Offline Phase
As described above, the offline phase has to produce views of secure MAC key , views of Beaver triples, and a masked input m.
We reused a homomorphic encryption scheme like Damgård et al. in [
10] to achieve these goals. Let
be such a scheme. It must support the evaluation of circuits with polynomially many additions and one homomorphic multiplication. It should also facilitate distributed vital generation. Each participant obtains a share of the secret decryption key in this process, while all parties possess the public encryption key. Then, the secret-sharing decryption key will be utilized for distributed decryption, which involves processing a ciphertext and distributing the resulting plaintext to each party involved. Here, each participant can employ NIZKPs to guarantee the correctness and security of scheme
.
The first step is to generate a secret-sharing MAC key
, which is used to calculate the product with the input shared value and, then, Reshare the result. As shown in Algorithm 2, it is a functionality for distributed MAC key generation. Its result is a ciphertext, and we can learn the value by using distributed decryption in
. However, we really need a
-shared value. A sub-protocol
(shown in Algorithm 3) can produce a ciphertext as a plain
-shared value.
Algorithm 2: MacKeyGen—algorithm for generating a secret-sharing MAC key. |
|
With the algorithm , similarly, we can easily generate a -shared random value. Now, the rest of the preprocessing phase is how to generate Beaver triples. Like the above functionality, we assumed that each party already knows the public encryption key and has an additive secret sharing of the decryption key . Simultaneously, parameters for the Pedersen commitments are known. The parties are assumed to have run the algorithm . Thus, each party has an additive secret sharing of the MAC key and an encryption . Now, we briefly describe the functionality :
- (1)
Using the same method in the algorithm , each party can hold two random -shared values and . Each party calculates ciphertexts and together with the NIZKPs of both. Then, they broadcast , , and the NIZKPs to all other parties and . When each receives the ciphertexts and the corresponding NIZKPs from all parties, check all the NIZKPs. If cheaters exist, abort.
- (2)
Utilizing the additive and multiplicative homomorphic properties of the scheme , all parties compute: (1) a ciphertext such that ; (2) a ciphertext such that ; (3) an encryption of the product of a and b.
- (3)
The parties run the algorithm on , resulting in a secret sharing , where .
Finally, we can assemble these components to obtain the offline protocol
(shown in
Figure 3). Steps 1–4 utilize the algorithms described above to generate the needed randomness for the online computation. Likewise, these generated random values need to be validated. Benefiting from the fact that the corresponding commitments and NIZKPs were generated at each phase and sent to
, the HV can validate their correctness in
Validate.
Algorithm 3: Reshare—algorithm for producing a plain -shared value. |
|
5.4. Decision-Making Algorithm
Based on the protocol above, Algorithm 4 is proposed to describe the decision-making algorithm, which is a case in the health insurance scenario. We used it as the basis of the experimental phase.
Algorithm 4: Dec_Make—algorithm for making a health insurance decision using SMPC. |
|
This algorithm’s inputs are two two-dimensional matrices from the medical records and insurance information, and the output is a matrix with size since there are nine different decision outcomes. Firstly, the algorithm verifies if specific diseases exist in the input matrices. Then, it applies other decision rules to modify the corresponding values in the output matrix. It is important to note that not all rules are explicitly listed in the algorithm. Lastly, multiple modifications can occur in the result matrix during numerous judgments, so the algorithm identifies the first changed value in each row. Based on this information, the algorithm generates a new result matrix, yielding the correct decision outcome.