A Comment on Privacy-Preserving Scalar Product Protocols as proposed in "SPOC"

TL;DR

This paper critically analyzes Lu et al.'s privacy-preserving scalar product protocol, demonstrating its insecurities and proving it cannot be secure without cryptographic assumptions, thus cautioning against its use.

Contribution

It reveals the insecurity of a widely cited PPSP protocol and provides theoretical proof of its fundamental limitations without cryptographic assumptions.

Findings

Lu et al.'s protocol is insecure against specific attacks.

The protocol cannot be made secure without cryptographic assumptions.

Impossibility results confirm inherent insecurity of the protocol.

Abstract

Privacy-preserving scalar product (PPSP) protocols are an important building block for secure computation tasks in various applications. Lu et al. (TPDS'13) introduced a PPSP protocol that does not rely on cryptographic assumptions and that is used in a wide range of publications to date. In this comment paper, we show that Lu et al.'s protocol is insecure and should not be used. We describe specific attacks against it and, using impossibility results of Impagliazzo and Rudich (STOC'89), show that it is inherently insecure and cannot be fixed without relying on at least some cryptographic assumptions.

Equations

$$\begin{array}{rl}\{S_0(a,f(a,b)){\}}_{a,b}& \stackrel{c}{\approx }\{{\text{view}}_0^{\Pi }(a,b){\}}_{a,b}\text{ and}\\ \{S_1(b,f(a,b)){\}}_{a,b}& \stackrel{c}{\approx }\{{\text{view}}_1^{\Pi }(a,b){\}}_{a,b},\end{array}$$

$${\log }_{2}n+{\log }_{2}q+k_3$$

$${\log }_{2}n+{\log }_{2}q+k_4$$

$${\log }_{2}n+k_3+k_4$$

$$\text{If }\text{nicefrac}E\alpha \approx c_1\text{then output guess }\overrightarrow{b^{\prime }}\text{, else output guess }\vec{b}.$$

Full text

1 Introduction

The scalar product is a fundamental operation in linear algebra that is used in a variety of fields, e.g., serving as the basis of deep neural networks, biometric characterization, or computer graphics. Suppose two parties $P_{0}$ and $P_{1}$ with respective input vectors $\vec{a}$ and $\vec{b}$ want to securely compute the scalar product $\vec{a}\cdot\vec{b}=\sum_{i=1}^{n}a_{i}b_{i}$ such that $P_{0}$ obtains the result $\vec{a}\cdot\vec{b}$ without revealing anything else about $\vec{b}$ to $P_{0}$ or anything about $\vec{a}$ to $P_{1}$. This secure two-party computation of the scalar product is an important building block for preserving privacy in many applications. In 2013, Lu et al. [1] proposed a privacy-preserving scalar product (PPSP) protocol in their paper titled “SPOC: A Secure and Privacy-Preserving Opportunistic Computing Framework for Mobile-Healthcare Emergency”. This protocol relies on “multi-party random masking and polynomial aggregation techniques” [2], where absolutely no public-key cryptography is used. In fact, their protocol does not make any cryptographic assumptions at all and the authors claim that it achieves information-theoretic security. As shown in [2], the protocol is much faster than public-key based protocols using homomorphic encryption. Since then, this protocol has been and is still used in many privacy-preserving solutions, e.g., [3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20], including support vector machines [17], facial expression classification [9], medical pre-diagnosis [18], and speaker verification [10, 11].

In this comment paper, we present devastating attacks against the original [1] and subsequent [2] versions of Lu et al.’s protocol. Our attacks fully break privacy and show that the protocol should not be used in applications. Before presenting our concrete attacks in §3, we first show in §2 why Lu et al.’s protocol is inherently insecure and can only be fixed if at least some public-key cryptography is used.

2 Lu et al.’s Protocol Cannot Be Secure

A fundamental issue with privacy-preserving tasks is that the absence of attacks does not guarantee privacy. To assure the privacy of new protocols, a formal proof of security is needed. Using established simulation-based security notions, such proofs show that only what can be computed from a priori information can be learned by executing the protocol. In this section, we will show that Lu et al.’s protocol cannot be secure under the established security notions.

2.1 Formalizing Secure Two-Party Computation

Formally, the secure two-party computation (STPC) of a function $f(a,b)$ on inputs $a$ from $P_{0}$ and $b$ from $P_{1}$ by a protocol $\Pi$ is defined by a simulator $S=(S_{1},S_{2})$ that simulates the views of the parties participating in $\Pi$ [21, chapter 7]:

[TABLE]

where $\stackrel{{\scriptstyle c}}{{\approx}}$ denotes computational indistinguishability. $S_{i\in\{0,1\}}$ is computationally (ploynomial-time) bounded and needs to simulate $\text{view}^{\Pi}_{i}$, which contains all incoming messages received by $P_{i}$ during the execution of $\Pi$. If such a simulator exists, then the protocol is considered secure because everything that can be learned from participating in the protocol ($\{\text{view}^{\Pi}_{i}(a,b)\}_{a,b}$) can also be learned by information that is known to the party anyway ($S_{i}$ sees either the input $a$ or $b$ and the output $f(a,b)$). Conversely, if no such simulator exists, then the distribution generated by any $S$ can be distinguished from the distribution of the views of the protocol execution, meaning that a party observing the view reveals more information than just knowing its own input and the output. This is the established notion and the de facto standard to model secure computation tasks for privacy-preserving solutions. Thus, in order to ensure the security of a protocol, a security proof of indistinguishability is needed [22]. The model we are concerned with here is in the context of semi-honest (or passive) security, where $P_{0}$ and $P_{1}$ honestly follow the protocol but try to learn additional information.

In the above definition, it suffices to show that one party can distinguish between different inputs of the other party based on the observed execution of a protocol to break its privacy. For instance, in our specific attacks against Lu et al.’s privacy-preserving protocol (cf. §3.2), we will show that $P_{0}$ can distinguish between different inputs of $P_{1}$ regardless of the output, thereby learning more than the minimal amount of information implied by the input and the output. Because this additional information is hard to specify and highly depends on the use case, protocols where this distinction is possible are considered insecure.

2.2 A secure PPSP Protocol has to rely on Cryptographic Hardness Assumptions

In the following, we will put Lu et al.’s PPSP protocol in relation to well-established cryptographic primitives, showing that PPSP has to rely on public-key cryptography. A summary of these relations can be found in Figure 1.

More precisely, PPSP is closely related to a primitive called oblivious transfer (OT). In OT, a party $P_{0}$ inputs a choice bit $b$ and $P_{1}$ inputs two bits $(x_{0},x_{1})$. $P_{0}$ receives $x_{b}$ as output without learning any information about $x_{1-b}$ and without revealing any information about $b$ to $P_{1}$. OT is a strong primitive that implies many more fundamental cryptographic building blocks such as STPC [24].

Of course, STPC can be used to realize PPSP and known and secure PPSP protocols usually rely on STPC based on homomorphic encryption or OT [25]. Since OT implies STPC, it follows that OT implies PPSP. Conversely, the existence of a PPSP protocol would imply OT, as OT is just a special case of PPSP where $\vec{a}=(\overline{b},b)$ and $\vec{b}=(x_{0},x_{1})$. Therefore, PPSP is equivalent to OT and requires the same assumptions required for OT like, e.g., public-key cryptography, noisy channels, or hardware tokens.

OT can also be used to implement symmetric key exchange (SKE) [26, 27]. Impagliazzo and Rudich [23] proved that a black-box reduction of SKE to one-way functions (the central building block of symmetric cryptography) would imply $P\neq NP$. This means that SKE and thus OT very likely require at least some complexity-theoretic assumptions of public-key cryptography, as otherwise a proof of $P\neq NP$ would be found. As such, all PPSP protocols that rely solely on symmetric cryptography or make no cryptographic hardness assumptions at all (like Lu et al.’s protocol) must be flawed.

3 Lu et al.’s Protocol Is Insecure

Lu et al.’s PPSP protocol first appeared in [1] as a sub-protocol in a privacy-preserving healthcare framework and was later extended in [2] by introducing fixes to preserve privacy. The protocol is shown in Figure 2, with the extensions of [2] underlined. Before presenting our specific attacks, we briefly outline how the protocol works.

3.1 How the Protocol is supposed to work

Correctness stems from the observation that $E=\sum_{a_{i}\neq 0,b_{i}\neq 0}a_{i}b_{i}\alpha^{2}+\sum_{a_{i}=0,b_{i}\neq 0}b_{i}c_{i}\alpha+\sum_{a_{i}\neq 0,b_{i}=0}r_{i}(a_{i}\alpha+c_{i})+\sum_{a_{i}=0,b_{i}=0}r_{i}c_{i}$ and therefore ${E\mod\alpha^{2}}$ contains all addends that are not multiples of $\alpha^{2}$, i.e., all addends except $\sum_{a_{i}\neq 0,b_{i}\neq 0}a_{i}b_{i}\alpha^{2}$. Thus, $\vec{a}\cdot\vec{b}=\frac{E-(E\mod\alpha^{2})}{\alpha^{2}}$ under the constraint that $\sum_{a_{i}\neq 0,b_{i}\neq 0}a_{i}b_{i}\alpha^{2}+\sum_{a_{i}=0,b_{i}\neq 0}b_{i}c_{i}\alpha+\sum_{a_{i}\neq 0,b_{i}=0}r_{i}(a_{i}\alpha+c_{i})+\sum_{a_{i}=0,b_{i}=0}r_{i}c_{i}<p$ and $\sum_{a_{i}=0,b_{i}\neq 0}b_{i}c_{i}\alpha+\sum_{a_{i}\neq 0,b_{i}=0}r_{i}(a_{i}\alpha+c_{i})+\sum_{a_{i}=0,b_{i}=0}r_{i}c_{i}<\alpha^{2}$. To make the analysis of our attacks easier, we translate the latter inequality onto the corresponding bit-length parameters, resulting in the following conditions necessary for correctness:

[TABLE]

A violation of any of the above inequalities would result in the protocol being incorrect for some or even all inputs. The parameters used for randomly masking the inputs, $k_{3}$ and $k_{4}$, are both set to $128$ to allow for a randomness source of 128-bit. As a result of the above constraints when assuming an input space of ${n=q=2^{32}}$, the parameters are set to $k_{1}=512$ and $k_{2}=200$ in [2] to ensure correctness. Similar assumptions can be found in the original protocol [1].

The protocol’s security is entirely based on masking values with random addends or factors. In the first step, $P_{0}$ masks all values $C_{i}$ by multiplying with $s$. For $a_{i}=0$, just a random $c_{i}$ is masked, while a random $c_{i}$ added to $\alpha\cdot a_{i}$ is masked otherwise. The intention behind $s$ and all $c_{i}$ is to hide any information about $a_{i}$ and, indeed, it is impossible to distinguish between different $a_{i}$ based on the uniform distribution from which all $c_{i}$ are drawn. $\alpha$ and $p$ serve no security purpose but ensure correctness. In step 2, $P_{1}$ either randomizes $C_{i}$ by multiplying with the random $r_{i}$ or it just multiplies $b_{i}\cdot\alpha$ to $C_{i}$. The supposed idea here is that, because $b_{n+1}=b_{n+2}=0$, $\sum_{i}C_{i}$ is randomized by the addends $r_{n+1}\cdot C_{n+1}$ and $r_{n+2}\cdot C_{n+2}$. Thus it seems that different values of $D$ from different $\vec{b}$ should not be distinguishable. There exist some proof sketches of the protocols in [1, 2] and some of the works building on them. The security analyses do not rely on the established indistinguishability-based security notions presented in §2.1, but instead make use of ad-hoc security notions that are based around the principle that the input cannot be reconstructed. Below, we will present specific distinguishing attacks that even allow $P_{0}$ to check whether $P_{1}$’s input is a candidate $\vec{b}$. This obviously violates privacy and shows that contrary to the established primitives, the ad-hoc security definitions used for the proofs do not capture any useful sense of privacy.

3.2 Our Specific Attacks

One can immediately see why the original protocol of [1] is broken: $D=\sum_{b_{i}=0}C_{i}+\sum_{b_{i}\neq 0}b_{i}\cdot\alpha\cdot C_{i}$. Since $D$ is completely deterministic and depends only on $\alpha,C_{i},$ and $\vec{b}$, party $P_{0}$ can easily distinguish different values of $\vec{b}$ because it knows $\alpha$ and all $C_{i}$. For instance, for $\vec{b}=\vec{0}$, $P_{1}$ will return $\sum_{i=1}^{n}C_{i}$ whereas for $\vec{b^{\prime}}=(1,0,\ldots,0)$, $P_{1}$ will return $\alpha\cdot C_{1}+\sum_{i=2}^{n}C_{i}$. This attack works for any value of $\vec{a}$.

3.2.1 Attack on the fixed Protocol for $\vec{a}=\vec{0}$

The above vulnerability was fixed in [2] by introducing random addends to $D$ via $b_{n+1}=b_{n+2}=0$. Operations based on public-key cryptography still do not appear in the protocol. Thus, the security of this version is implausible as well (cf. §2.2). Indeed, we found another attack that can distinguish different $\vec{b}$. At first, we consider this attack for the case of $\vec{a}=\vec{0}$, because then the output of the ideal functionality is equal to [math] and yields no knowledge about $\vec{b}$. In that case, the ability to distinguish any distinct $\vec{b}$ clearly demonstrates that information about the inputs is leaked. Using the following strategy, $P_{0}$ can distinguish between $\vec{b}=\vec{0}$ and $\vec{b^{\prime}}=(1,0,\ldots,0)$ after computing $E$ in step 3:

[TABLE]

Our attack relies on the different sizes of the parameters and works because they create a conflict between security and correctness: to prevent our attack, the parameters have to be changed in such a way that they violate the correctness constraints. More specifically, for $\vec{b^{\prime}}$, $P_{0}$ receives $E=\alpha\cdot c_{1}+\sum_{i=2}^{n+2}r_{i}c_{i}$. In our attack, $P_{0}$ will compute $\nicefrac{{E}}{{\alpha}}=c_{1}+\frac{\sum_{i}r_{i}c_{i}}{\alpha}$. Since $|c_{1}|=k_{3}$ and $|\frac{\sum_{i}r_{i}c_{i}}{\alpha}|=\log_{2}n+k_{3}+k_{4}-k_{2}$, $\nicefrac{{E}}{{\alpha}}\approx c_{1}$ except for the $\log_{2}n+k_{3}+k_{4}-k_{2}$ least significant bits. Conversely, for $\vec{b}$, $P_{0}$ receives $E=\sum_{i=1}^{n+2}r_{i}c_{i}$ and thus will only obtain some $|\nicefrac{{E}}{{\alpha}}|=\log_{2}n+k_{3}+k_{4}-k_{2}$ bit integer. Hence, to make our distinction impossible, the parameters need to satisfy at least $k_{3}\leq\log_{2}n+k_{3}+k_{4}-k_{2}\Leftrightarrow k_{2}-\log_{2}n\leq k_{4}$, which violates Equation 1b necessary for correctness.

The attack can also be extended to distinguish between any $\vec{b}$ by checking whether $\nicefrac{{E}}{{\alpha}}\approx\sum_{i}b_{i}c_{i}$. Similar to the reasoning above, the attack can only be prevented if at least $k_{2}\leq k_{4}$, which also violates Equation 1b. Not only does this break privacy because it allows for distinguishing any $\vec{b}$, this also enables an adversary to check whether a suspected input $\vec{b}$ is the real one.

3.2.2 Attack on the fixed Protocol for any $\vec{a}$

Even though the previous attack is enough to violate privacy, we will further show how to adapt it when using any $\vec{a}$ as input. Knowing its own input $\vec{a}$ and the suspected input $\vec{b}$, $P_{0}$ just checks whether $\nicefrac{{E}}{{\alpha}}\approx\sum_{a_{i}\neq 0}a_{i}b_{i}\alpha+\sum_{a_{i}=0}b_{i}c_{i}$. Analogously to the analysis in §3.2.1, this distinction could only fail if $|\sum_{a_{i}\neq 0}a_{i}b_{i}\alpha+\sum_{a_{i}=0}b_{i}c_{i}|\leq|\sum_{a_{i}\neq 0,b_{i}=0}r_{i}c_{i}+\sum_{a_{i}=0,b_{i}=0}\frac{r_{i}c_{i}}{\alpha}|$ which, taking into account Equations 1a and 1b, requires that $2(k_{2}+\log_{2}q)-k_{3}\leq k_{4}$. This would contradict Equation 1c and therefore violate correctness.

3.2.3 Evaluation

To show the feasibility of our attacks, we implemented them alongside the protocol. Our implementation shows that for the parameters used in [2], any user input $\vec{b}$ can easily be distinguished and even detected by $P_{0}$. The implementation is freely available as open source and can be found online at https://encrypto.de/code/SPOCattack.

We also evaluate the protocol’s correctness as well as the effectiveness of our attacks depending on varying parameters. The results are presented in Figure 3 for varying values of $k_{4}$ and confirm the contradiction between the protocol’s correctness and its security. Under the correctness constraints of Equations 1a, 1b, 1c, all of our attacks are close to 100% accurate. Conversely, the protocol is entirely correct for these parameter choices as well. When Equation 1b is broken with $k_{4}\geq k_{2}-\log_{2}q-\log_{2}n$, the absolute correctness error starts to appear and rises rapidly. Shortly after this, when the accuracy threshold $k_{4}\geq k_{2}$ of our first attack distinguishing any $\vec{b}$ is passed, its accuracy quickly drops to the baseline of 50% (the accuracy of randomly guessing between two $\vec{b}$). The same occurs after the threshold for our second distinguishing attack is passed, at which point the maximum correctness error of $k_{1}-2k_{2}=112$ bit is already reached. Furthermore, to demonstrate that our attacks even allow to test for a certain $\vec{b}$, we also evaluate both attacks by distinguishing a random $\vec{b}$ from a $\vec{b^{\prime}}$ that only differs from $\vec{b}$ by 1 in one position. Our evaluation shows that, though the accuracies drop earlier than for random $\vec{b^{\prime}}$, these attacks work for the standard parameters and that therefore a precise testing and searching for $P_{1}$’s input is possible. Notably, we evaluate the correctness for $\vec{b}=\vec{0}$, as Equation 1b comes from the random addends resulting from all $b_{i}=0$. When using a completely random $\vec{b}$, the correctness error only starts to appear at $k_{4}\geq k_{2}+64=264$ but, since the protocol should be correct for any input, we display the results for $\vec{b}=\vec{0}$.

Our implementation establishes that in any application using the protocol, $P_{0}$ can check whether $P_{1}$ has a certain input (like, e.g., a certain illness in a healthcare application). Clearly, this is a severe violation of privacy and serves as a reminder that the security notions used by the protocol’s security analysis (cf. §3.1) are insufficient and that the established definitions based on indistinguishability (cf. §2.1) should be used instead. As outlined in §2.2, similar attacks will inadvertently still be possible even if additional randomizations are introduced to prevent these concrete attacks as long as no cryptographic assumptions are utilized.

4 Conclusion

We showed in §2.2 that protocols for the secure two-party computation of the scalar product imply oblivious transfer. As a result, such protocols very likely require public-key cryptography. Lu et al.’s protocol [1, 2] is an example in academic use today that does not rely on such assumptions and is thus inherently insecure. Indeed, we found specific attacks that we have verified with an implementation, showing that their protocol does not guarantee privacy. With this comment paper we want to stress that (at least some) expensive public-key cryptography is necessary for such protocols and that new protocols should be proven secure in established formal frameworks to catch such flaws.

Acknowledgments

We want to thank the anonymous reviewers for their helpful feedback. This work was supported by the DFG as part of project A.1 within the RTG 2050 “Privacy and Trust for Mobile Users” and as part of project E4 within the CRC 1119 CROSSING, and by the BMBF and the HMWK within CRISP.