Introduction to secret sharing based secure multiparty computation in health data

Abstract

Background

Joint analyses across multiple health datasets can increase statistical power and improve the generalisability of research findings. However, limitations on data sharing often prevent researchers from fully realising these benefits. Existing approaches such as federated analytics involve sharing information, which poses challenges due to data governance and security restrictions.

Secure multiparty computation (SMPC) is a set of cryptographic techniques that allows joint analyses across multiple private datasets with zero information sharing except for the agreed outputs. Despite its transformative potential in health research, SMPC has received relatively little attention within the health data landscape.

Objectives

This article gives an introduction to secret sharing based SMPC that is accessible with no prior knowledge assumed. We explain how secret sharing techniques work, and the security guarantees they offer. We also discuss SMPC software, and offer our view on the most promising approaches to implementation.

Conclusion

SMPC has significant potential for enabling privacy-preserving analyses, and could become a standard tool in the future for collaborative health data research. As efforts to improve data access and integration continue, it will be increasingly important for health data researchers to have an understanding of SMPC so they can use it effectively.

Introduction

An ever-present challenge for health data research is balancing the benefits of research against the risk of compromising private information. Ideally, researchers would have the ability to combine multiple datasets in the custody of different data controllers to carry out joint analyses. This can improve power, precision and validity of studies, ultimately translating into better individual health outcomes. However, this often cannot be done due to data governance regulations that are designed to minimise the risk of disclosure of sensitive information.

There are many existing approaches to this issue. A simple strategy is to pseudonymise datasets and deposit them together in a secure data environment (SDE). However, this is frequently not possible because it involves sensitive data leaving the custody of the data controllers, often across institutional or jurisdictional boundaries. Federated analysis (FA) allows model fitting without sharing raw datasets but typically requires repeated exchanges of summary statistics or model updates, which can leak private information and require complex governance arrangements. The continuous flow of information between parties in FA makes it impractical for data controllers to precisely characterise, audit, and approve what is being shared at each step, particularly given the cumulative disclosure risk that can arise over time.

Secure multiparty computation (SMPC) offers an alternative approach that enables pooled analyses of private datasets with zero information sharing except for the agreed outputs of the analysis.^{1 2} The result of the calculation is identical to what would be obtained if there were no restrictions on data sharing. However, the parties involved at most learn the result, while learning nothing else about each other’s data.

It is important to stress that the fact that someone learns the final result is inherent to any meaningful analysis, whether performed centrally, using FA or via SMPC—otherwise the computation would serve no purpose. Potential inferences that may be drawn from the released outputs are therefore not a failure of SMPC itself but a general issue of disclosure control. In practice, this can be addressed through standard mechanisms such as restricting who is authorised to receive the outputs. The guarantee of SMPC is that the computation process reveals nothing beyond outputs that are intentionally released.

SMPC places almost no restrictions on what kind of analysis can be performed or what kind of data can be analysed. It can be used with datasets of all types and modalities, including numeric, text, images, etc. It supports a wide range of analytical tasks, from simple database-style queries (counts, sums, cross-tabulations) to standard statistical analyses (linear and logistic regression, survival models etc), and training or performing inference with artificial intelligence (AI) models.

A key advantage of SMPC over many existing approaches is that its privacy guarantees are underpinned by mathematically rigorous security proofs. These proofs formally establish that no information is revealed to any party except for explicitly agreed outputs. As a result, SMPC obviates the need for cumbersome data sharing agreements and disclosure control between parties.

In principle, SMPC opens up the possibility of routinely performing joint analysis of any health datasets, held anywhere in the world. For example, the UK’s National Health Service holds extraordinarily rich health data that could be used to substantially improve our understanding of a range of diseases, treatments and health system performance. However, these data are frequently fragmented and siloed-off. Establishing data-sharing agreements, ethical approvals and governance arrangements can take years, delaying or preventing critical research. SMPC has already been shown to be viable and practical in health data applications.^{3 4}

Many other practical use cases in health data are possible with SMPC. For example, generating adequate statistical power to study treatments or outcomes for very rare diseases often requires combining data across many institutions or jurisdictions. SMPC can enable pooled analyses across all sites without any site relinquishing control of its data. Or consider an AI diagnostic tool that significantly outperforms human experts, trained on private health data and deployed in an SDE where it cannot be exported for data governance reasons. SMPC can enable a clinician to obtain outputs from this tool with no disclosure of private information. SMPC could also be used to link datasets that that cannot typically be jointly analysed, such as individual-level health and personal finance data, to perform, for example, health economics analyses. Box 1 provides an example use case for SMPC.

Box 1. Example use case.

A research team aims to evaluate the safety of a newly licensed anticoagulant used to prevent stroke in patients with atrial fibrillation. Following regulatory approval, there remains uncertainty about rare adverse events such as intracranial haemorrhage. Because these events are uncommon, sufficient statistical power requires combining data across multiple UK health boards. Using secure multiparty computation (SMPC), the workflow might proceed as follows:

1. Each participating site stores patient data locally in a secure data environment (SDE).

2. SMPC software is installed within each SDE.

3. The research team agrees on the analytical methods, identifies which parties will receive the results, and agrees on statistical disclosure control procedure for releasing outputs from SDEs.

4. Data are cleaned and harmonised across sites.

5. SDEs are connected securely (eg, via a virtual private network).

6. SMPC is used to perform the joint analysis without sharing any information except for the agreed results.

7. Analysis outputs are released only to the agreed recipients, and then put through statistical disclosure control before leaving the SDEs.

Added value of SMPC:

• Enables multisite analyses while preserving patient privacy.

• Increases statistical power.

• Raw data stays in local SDE and is never sent to other sites.

• No summary statistics are shared.

• Parties do not learn anything beyond the agreed on results.

• No statistical disclosure control is required during the analysis.

The additional security offered by SMPC does not come for free—there is inevitably a performance overhead relative to a traditional plaintext analysis. However, advances in implementations and infrastructure have substantially reduced this gap, making practical SMPC analysis feasible for real data science tasks. For example, one protocol trained a logistic regression model with two parties on 70 000 samples in under 10 min of online time over a wide-area network.⁵ Models such as ordinary least squares linear regression, naïve Bayes classifiers, and methods that estimate causal effects through matching or weighting incur only minimal overhead relative to plaintext implementations. More generally, SMPC frameworks offer a menu of protocol choices with different trade-offs between security and efficiency, allowing analyses to be tailored to the security and performance requirements in any given application.

SMPC has extraordinary potential and may become a standard tool for health informatics in the future. In order to use SMPC techniques effectively, it is necessary to have basic knowledge of them. In this article, we give an introduction to secret sharing based SMPC that is accessible with no prior knowledge assumed. We provide clear explanations of how SMPC works, the security guarantees different it provides and a guide to getting started with SMPC. Our goal is to provide a basic knowledge that can serve as a springboard for researchers in the field of health data to incorporate SMPC into their own work.

Basic concepts

Before diving into how SMPC works, this section introduces some basic ideas from cryptography. These concepts provide the foundation for understanding how SMPC protocols are designed and why they are secure.

The basic goal of cryptography is to enable secure communication between a number of parties. This can be done by executing a cryptographic protocol.

Cryptographic protocol: An agreed set of rules and procedures that allow parties to interact towards achieving a security goal.

Cryptographic protocols are often constructed from cryptographic primitives.

Cryptographic primitive: A low-level operation that performs a specific cryptographic function.

Primitives are the building blocks of cryptographic protocols. Primitives are useful because if they are proven to be secure in a composition-friendly setting such as the universal composability framework, a protocol that repeatedly applies them will have a similar level of security.⁶

Security of a cryptographic protocol is most easily conceptualised in terms of an adversary that attempts to break the privacy of the parties.

Adversary: A malicious entity that tries to undermine the security of a protocol, usually by attempting to learn private information.

Traditionally, cryptographic techniques aimed at providing security against adversaries that are not intended participants in the communication. In the SMPC, however, the goal is to protect the parties’ privacy from each other.

Several parties may collude to break the privacy of the protocol. This can be captured through the idea of corruption.

Corruption: A corrupted party cooperates with the adversary to some degree. This could involve disclosing information to the adversary or deviating from the protocol. The adversary may have the ability to corrupt several parties.

In cryptography, terms such as ‘adversary’ and ‘corruption’ are used to describe potential deviations from the protocol that a system is designed to withstand, and do not carry the everyday connotations of malice. In particular, these terms do not necessarily imply that participating institutions or individuals are intentionally acting against the analysis. Rather, they provide a formal way to model a range of different risks including accidental errors, curiosity about other sites’ data, unintended information leakage or malicious attacks.

It is useful to distinguish between different types of corruption, because we may be interested in protocols that are secure against adversaries with different capabilities.

Passive/semihonest corruption: A passively corrupted party executes the protocol but leaks information to the adversary. An adversary that uses only this type of corruption is referred to as ‘honest but curious’.

Active/malicious corruption: An actively corrupted party is completely controlled by the adversary.

Passive (semihonest) corruption may be the most relevant for collaborative health data analysis. In this setting, parties are often trusted to follow agreed analytical procedures and are motivated by shared scientific or clinical goals, rather than by a desire to undermine the computation. Nevertheless, governance, legal and reputational considerations mean that parties may wish to minimise any possibility of unintended information leakage.

Proofs that SMPC protocols are secure often use the ideal/real world paradigm.

Ideal world: A scenario where the parties’ inputs are sent to a trustworthy external party that does the desired computation and reveals the result.

The goal of SMPC is to achieve the same outcome as the ideal world, without making use of a trusted external party. SMPC protocols are provably secure, meaning that there are mathematical proofs showing that in the real world, where the parties do not have access to a trusted third party, an adversary will learn no more than it would learn in the ideal world.

Different cryptographic protocols provide security guarantees of different strengths. The main types of security we will be interested in here are information theoretic security and computational security.

Information theoretic security: Security against adversaries that have infinite computational power.

Computational security: Security against adversaries that have a realistic amount of computational power. This typically means that cryptographic techniques are used whose security relies on the computational difficulty of problems such as factoring large numbers. Cryptosystems with this level of security are in widespread use, for example, for secure messaging.

An important class of calculations that can be performed using SMPC is arithmetic circuits.

Arithmetic circuit: An algorithm for calculating a series of additions and multiplications, represented as a directed acyclic graph.

The initial nodes are inputs to the calculation. All other nodes perform the operation they are labelled with and pass the result forward. For example, the result of evaluating the arithmetic circuit in figure 1 is 9.

Figure 1. An arithmetic circuit.

Secret sharing based SMPC

Now that we have covered some basic ideas in cryptography, we are ready to look at how SMPC protocols actually work. One of the most widely used and practical approaches is based on the idea of secret sharing. At a high level, secret sharing allows the parties to split up a piece of private information so that no single person has access to it, but it can still be recovered by some number of parties working together. A useful analogy is to think of a private piece of information stored in a lock box, where each party holds a separate key, and the box can only be opened when all parties use their keys simultaneously.

Secret sharing: This refers to a method for distributing a secret among a group. Each party has a share of the secret. No individual on their own has information about the secret, but some minimum number of parties can combine their shares to recover the secret.

Threshold secret sharing scheme with threshold t: A secret sharing scheme that is secure against an adversary that corrupts at most t parties.

It is important to distinguish between the corruption threshold and the number of parties required to reconstruct a secret. The corruption threshold is the maximum number of parties that can be corrupted without compromising security of the protocol. Typically the number of parties required to recover the secret is one higher than the corruption threshold. In the rest of this section, we will introduce the basic ideas behind secret sharing and explain how it ensures privacy even when some participants may be compromised. We begin with a simple example of additive secret sharing.

Additive secret sharing

Consider three people, Alice Bob and Carol, wish to calculate the sum of their salaries. However, they do not wish to disclose their salary to anyone. They can achieve their goal with additive secret sharing as follows.

Let us say Alice’s salary is 100k. She randomly chooses two numbers (the numbers must be drawn from a uniform distribution. Digital computers cannot in general represent real numbers with full precision. For this reason, secret sharing schemes typically draw from the uniform distribution over a finite subset of integers. This can be used to represent real numbers in a finite range to any desired degree of accuracy. Modular arithmetic guarantees closure under arithmetic operations. For more detail, see section 1 of the online supplemental material), for example, 20k and 30k, then chooses a third so that they sum to her salary—50k. These numbers are called shares.

Alice distributes the shares—she keeps 50k, gives 20k to Bob, and 30k to Carol. Bob and Carol do the same with their salaries. Each party has three shares given by the columns in table 1.

Table 1. Additive secret sharing example.

	Alice	Bob	Carol	Salary
Alice	50k	20k	30k	100k
Bob	−30k	80k	100k	150k
Carol	150k	100k	−50k	200k
	170k	200k	80k

Each party adds up the shares they have received. They reveal this total to the other parties and then sum them to get 450k.

During this procedure, no one learned anything about each other’s salary. This is because they only sent random numbers to each other that do not carry any information.

In this example, all three parties had to combine their shares to recover a secret. This is therefore an example of a threshold scheme with a threshold of two—it is passively secure against up to two parties being corrupted.

There is a reason why we used three parties in this example rather than two. When there are only two parties, knowing the sum of the salaries allows the parties to infer each other’s salary. Although the parties still only learn the result of the calculation, in this case that is sufficient to reconstruct the other party’s secret.

This is not always the case in general SMPC with two parties. If they carried out a more complex calculation where each party had multiple input values, learning the result of the calculation would not allow parties to reconstruct each other’s inputs.

It is straightforward to add or multiply additively shared secrets by a publicly known number. To add a constant c, a single party adds c to their share. To multiply by the constant c, all parties multiply their share by c.

While additive secret sharing preserves addition, it does not preserve the multiplication. That means multiplying together shares of two different secrets does not give a share of the product of those secrets.

Additive secret sharing achieves passive security so long as at least one party is not corrupted. It is possible to extend this to active security. Further details can be found in^{1 2}

Product to sum conversion

Additive secret sharing allows parties to compute sums of private values. For more complex calculations, multiplication is needed. However, multiplication is significantly more challenging to implement than addition, and is the reason for almost all of the complexity in secret sharing based SMPC.

One way we might try to proceed is by ‘converting’ multiplication into addition. There are several ways of achieving this product to sum conversion.

Beaver triples: A beaver triple consists of three numbers a, b, c such that c = ab, where a and b are uniformly randomly chosen, and the parties hold additive shares of a, b and c.

If the parties have a Beaver triple, they can securely compute the product of two additively shared secrets.⁷ Section 2 of the online supplemental material explains how this can be done. As a result, if the parties can generate additive Beaver triples, they can compute any arithmetic circuit.

One way of generating Beaver triples is using a trusted share dealer—an external party whose only involvement in the computation is making Beaver triples. The trusted share dealer chooses a and b randomly, multiplies together to get c and distributes additive shares of a, b, c to the parties. Note, however, that security of any protocol based on this procedure additionally relies on the trusted share dealer not being corrupted.

One might ask how using a trusted share dealer is an improvement on the parties sending their inputs to a trusted external party that carries out the computation and reveals the result. The reason is that even if the trusted share dealer is corrupted, learning the inputs to the computation requires also corrupting at least one party during the calculation, which limits the attack scope.

A major advantage of using Beaver triples is that it enables a split between offline and online phases.

Offline/preprocessing phase: The steps of a protocol that do not depend on the inputs to the computation.

Online phase: The steps of a protocol that depend on the inputs to the computation.

This has the benefit that the offline phase can be carried out in idle time when the parties are not busy. For example, the parties may build up a store of Beaver triples at night-time when their computers are least busy. Informally, Beaver triples act like rocket fuel for the calculation. They are prepared in advance and then quickly burned during the online phase to perform the computation efficiently.

Beaver triples typically cannot be reused because this leaks private information (to see why this is so, see section 2 of the online supplemental material). Beaver triples can also be generated without a trusted share dealer using homomorphic encryption techniques, but this usually incurs a significantly greater computational cost than using a trusted share dealer. More detail on this can be found in Ref.⁷

Shamir secret sharing

In this section, we introduce another secret sharing scheme, called Shamir secret sharing. This is a secret sharing method that relies on the fact that certain curves are completely determined by a finite set of points. As a simple example, a straight line is uniquely determined by two points, because there is exactly one straight line that goes through any given pair of points.

This can be used as the basis of a secret sharing scheme in the following way. Let us say the secret is 10. We randomly choose a straight line whose value at x = 0 is 10. An example can be seen in figure 2.

Figure 2. Shamir secret sharing example.

Any point on the line at a whole number value for x is a share of the secret, for example, (1, 15), (2, 20). One point alone provides no information about the secret. However, if we know both points we can draw a straight line through them and interpolate to x = 0 and recover the secret 10.

This idea can be extended so that n shares are needed to recover the secret. This is achieved by polynomials that are uniquely determined by n points, instead of straight lines that are determined by two points (polynomials of degree d are used. These are uniquely determined by (d + 1) distinct points. For more information, see section 3 of the online supplemental material).

Unlike additive secret sharing, Shamir shares preserve both addition and multiplication (the proof of this can be found in section 3 of the online supplemental material). Addition/multiplication for Shamir shares is done by adding/multiplying the γ-values at each point, as illustrated in table 2.

Table 2. Shamir secret sharing example.

Polynomial	Secret	First share	Second share
f1=10+5x	10	(1, 15)	(2, 20)
f2=2+8x	2	(1, 10)	(2, 18)
f1+f2=12+13x	12=10+2	(1, 25=15+10)	(2, 38=20+18)
f1×f2=20+90x+40x2	20=10×2	(1, 150=15×10)	(2, 360=20×18)

In additive secret sharing, any share can be distributed to any party. However, in Shamir secret sharing, each party must receive shares that correspond to a particular x value.

A publicly known number can be added or multiplied to a secret encoded by Shamir shares by performing the same operation on the y-value of the shares.

Because Shamir secret sharing preserves addition and multiplication, it raises the possibility of securely computing any arithmetic circuit. However, a complication arises in the case of multiplication, because it increases the number of shares required to recover the secret (this is due to the fact that multiplying polynomials of degree d and e, respectively, results in a polynomial of degree (d+e). The secrets encoded using these polynomials require (d+1), (e+1) and (d+e+1) points or shares to recover, respectively. For more detail, see section 3 of the online supplemental material). Thus if we proceeded naively, it is possible to end up in a situation where all the parties together do not have enough shares to recover the secret.

This can be handled using techniques that reduce the number of shares required to recover a secret (for more information on reduction, see section 3 of the online supplemental material). This requires at least one round of communication between the parties, so the number of rounds of network communication required is at least proportional to the number of multiplication operations. In practice, this number can be large, so this can often end up as the main bottleneck in many applications.

Active security

So far, we have discussed passive security for Shamir secret sharing. However, we can also allow for security against an active adversary as follows.

Consider four parties labelled 1, 2, 3 and 4, that have shares (1, 15), (2, 20), (3, 25), (4, 30), respectively, generated from the blue line in figure 3. Any two honest parties can combine their shares to reconstruct the blue line and recover the secret 10. However, if one of the parties is corrupt and reports a modified value, then any value can be recovered.

Figure 3. Active security in Shamir secret sharing example.

For example, in figure 3, if party 1 falsely reports their share as (1, 25) from the red line, while party 2 honestly reports their share as (2, 20) from the blue line, then the red line is reconstructed instead of the blue line, leading to the incorrect value 30 being recovered.

One way of guarding against this is having more parties report their shares. For example, if party 3 honestly reports their share, the three reported points (1, 25), (2, 20) and (3, 25) do not lie on a straight line, indicating that someone is falsely reporting. However, in this case, it is not possible to reliably determine who the dishonest party is, or to recover the secret of 10.

But if parties 2, 3 and 4 honestly report their shares, it can be inferred that party 1 is falsely reporting. That is because the points reported by parties 2, 3 and 4 together lie on a straight line (blue), while the point reported by party 1 is the ‘odd one out’. In this case, the falsely reported share can be identified and removed, and the secret can be correctly recovered.

More generally, let there be n parties, of whom t are actively corrupted, and (d+1) shares are required to recover the secret. Then if

• n–d ≤t, false reporting cannot be detected.

• n–d>t, false reporting can be detected.

• n–d>2t, false reporting can be corrected.

Other operations

Additive and Shamir secret sharing can be used to compute any arithmetic circuit. How can other operations such as division, exponentials, logarithms, comparison operators (=, ≥, >) etc be calculated?

The trick is to represent these operations as arithmetic circuits. For example, exponentiation can be computed by repeatedly multiplying a number by itself. It turns out that an extremely broad range of calculations, including comparisons and non-linear operators, can be computed to any desired degree of approximation by an arithmetic circuit.

However, translating complex functions into arithmetic circuits efficiently is not always straightforward. Some techniques for calculating common functions are discussed in the online supplemental material of Ref.⁸ and the references cited there.

Implementations

There are multiple open-source SMPC frameworks available. We do not provide a comprehensive review here, and only highlight three implementations we believe are promising. A more comprehensive survey of SMPC tools can be found in Ref.⁹

The MP-SPDZ (Multi-Protocol SPDZ) framework is notable for its versatility in the range of different SMPC protocols it supports.¹⁰ It is actively maintained and allows practitioners to write functions in a Python-like high-level language, and compiles into a series of executables that the parties run. MP-SPDZ supports garbled circuits and secret sharing protocols across many security settings. Because of the breadth of different protocols it supports, it is particularly well-suited for benchmarking SMPC routines.

CrypTen is an SMPC framework developed by researchers at Facebook AI, with a specific focus on machine learning applications.⁸ CrypTen closely mirrors the PyTorch API, making it particularly accessible to machine learning practitioners. CrypTen uses additive secret sharing and Beaver triples generated by a trusted share dealer, thus operating under the honest-but-curious threat model.

Sequre is a domain-specific programming language designed for SMPC in a biomedical setting.¹¹ It uses Python-like syntax and semantics, incorporating custom compile-time analysis and optimisation. Sequre also uses additive secret sharing and Beaver triples generated through a trusted share dealer, thus operating under the honest-but-curious threat model.

Discussion

SMPC offers a promising solution to the problem of enabling pooled analyses across private datasets without compromising security of sensitive data. The potential applications in health data are extensive. In this paper, we have presented an introduction to SMPC designed to equip health data researchers with the tools required to incorporate SMPC into their own work. The subject of SMPC is vast and rapidly evolving, and our presentation therefore necessarily omits many important topics. We direct readers to Refs.^{1 2} for a more thorough introduction to SMPC.

One of the biggest challenges for practical applications of SMPC in health data is its additional computational complexity. While significant strides have been made towards optimisation, desirable calculations can still be impractically expensive. The biggest bottleneck is typically the volume of communication required.

On the other hand, clever study design/statistical modelling choices can considerably reduce the computational load, or shift it so that most of it occurs before the parties need to communicate. This is particularly true for models that eliminate independent variables through matching or weighting, and models that do not require an iterative fitting process, such as ordinary least squares and naïve Bayes.

Another significant challenge lies in creating user-friendly software for SMPC. A key issue will be to abstract away from the details of cryptographic protocols so that it can be used easily by individuals with no prior knowledge of SMPC or cryptography. For example, it may not be obvious to users why an offline phase is required where a perishable stock of Beaver triples or double sharings is built up. This is significant departure from how analyses are conducted in a non-SMPC setting.

We believe the security paradigm that is most likely to be implemented in practical health data SMPC applications is passive, or ‘honest but curious’. If the parties have been entrusted as the controllers of health data, and they trust the integrity of each other’s data, we believe it is unlikely that actively malicious behaviour will be a major concern. Techniques that achieve active security also come at significant additional computational cost, which are unlikely to be justified.

While there are still key challenges that must be addressed before SMPC techniques are widely adopted in health data, we believe there is reason for optimism. In our view, currently the most promising approaches are based on secret sharing. They achieve information theoretic security, meaning security against adversaries that have an infinite amount of computational power, and practical levels of efficiency that are well suited to health data analyses. The use of Beaver triples or double sharings means the calculation can be separated into online and offline phases. That said, SMPC is still an evolving field, and novel techniques and optimisations may become available in coming years that are even more attractive.