A Hybrid Approach to Secure Function Evaluation Using SGX

TL;DR

This paper proposes a hybrid secure function evaluation protocol leveraging SGX enclaves, balancing trust and security, and demonstrating significant performance improvements for privacy-preserving computations.

Contribution

It introduces a novel SGX-based SFE protocol with flexible partitioning, formal security guarantees, and practical implementations for real-world privacy tasks.

Findings

38x performance improvement over garbled circuits

Effective enclave protections against side-channel attacks

Successful application to privacy-preserving database queries and navigation

Abstract

A protocol for two-party secure function evaluation (2P-SFE) aims to allow the parties to learn the output of function $f$ of their private inputs, while leaking nothing more. In a sense, such a protocol realizes a trusted oracle that computes $f$ and returns the result to both parties. There have been tremendous strides in efficiency over the past ten years, yet 2P-SFE protocols remain impractical for most real-time, online computations, particularly on modestly provisioned devices. Intel's Software Guard Extensions (SGX) provides hardware-protected execution environments, called enclaves, that may be viewed as trusted computation oracles. While SGX provides native CPU speed for secure computation, previous side-channel and micro-architecture attacks have demonstrated how security guarantees of enclaves can be compromised. In this paper, we explore a balanced approach to 2P-SFE on SGX-enabled processors by constructing a protocol for evaluating $f$ relative to a partitioning of $f$. This approach alleviates the burden of trust on the enclave by allowing the protocol designer to choose which components should be evaluated within the enclave, and which via standard cryptographic techniques. We describe SGX-enabled SFE protocols (modeling the enclave as an oracle), and formalize the strongest-possible notion of 2P-SFE for our setting. We prove our protocol meets this notion when properly realized. We implement the protocol and apply it to two practical problems: privacy-preserving queries to a database, and a version of Dijkstra's algorithm for privacy-preserving navigation. Our evaluation shows that our SGX-enabled SFE scheme enjoys a 38x increase in performance over garbled-circuit-based SFE. Finally, we justify modeling of the enclave as an oracle by implementing protections against known side-channels.

Tables

Table 1. Table 1. Execution times (in ms) for each protocol, benchmarked with the Unix time command. All SGX programs were run for 100 iterations, and GC programs were run for 10 iterations. X ’s represent runs that would not complete in a timely manner. -’s indicate programs we did not run due to hybrid Millionaires not being implemented.

	Time (ms)
Program	Naïve	SGX-enabled SFE		Hybrid	GC
Millionaires1024	113 $\pm$ 3%	114 $\pm$ 2%		-	697 $\pm$ 2%
Millionaires4096	111 $\pm$ 2%	110 $\pm$ 2%		-	1,640 $\pm$ 1%
Millionaires16384	116 $\pm$ 3%	114 $\pm$ 3%		-	5,468 $\pm$ 0.2%
Millionaires262144	121 $\pm$ 2%	121 $\pm$ 2%		-	82,960 $\pm$ 0.4%
Dijkstra20	112 $\pm$ 4%	118 $\pm$ 4%		1,814 $\pm$ 0.2%	1,086 $\pm$ 0.4%
Dijkstra50	111 $\pm$ 3%	115 $\pm$ 3%		1,820 $\pm$ 0.2%	4,788 $\pm$ 0.1%
Dijkstra100	112 $\pm$ 2%	120 $\pm$ 3%		2,333 $\pm$ 0.2%	20,023 $\pm$ 0.02%
Dijkstra200	117 $\pm$ 2%	128 $\pm$ 1%		6,560 $\pm$ 0.2%	78,905 $\pm$ 0.02%
Dijkstra250	119 $\pm$ 2%	133 $\pm$ 1%		23,330 $\pm$ 0.2%	122,990 $\pm$ 0.009%
Dijkstra1000	125 $\pm$ 2%	343.9 $\pm$ 0.7%		51,670 $\pm$ 0.1%	1,972,700 $\pm$ 0.04%
Dijkstra10000	412.8 $\pm$ 0.6%	21,211 $\pm$ 0.03%		215,940 $\pm$ 0.09%	X
		Linear	Tree
Database500x2500	123 $\pm$ 4%	150.9 $\pm$ 0.7%	1,663.0 $\pm$ 0.09%	18,250 $\pm$ 0.2%	327,390 $\pm$ 0.01%
Database1000x2500	116 $\pm$ 3%	224 $\pm$ 1%	3,218.6 $\pm$ 0.09%	45,020 $\pm$ 0.1%	631,200 $\pm$ 0.05%
Database1500x5000	117 $\pm$ 1%	356.2 $\pm$ 0.3%	8,300.1 $\pm$ 0.05%	112,800 $\pm$ 0.2%	X
Database5000x5000	116.4 $\pm$ 0.9%	1,398 $\pm$ 0.1%	31,037 $\pm$ 0.05%	351,800 $\pm$ 0.2%	X
Database5000x25000	146 $\pm$ 1%	3,538.5 $\pm$ 0.03%	91,919 $\pm$ 0.04%	1,690,000 $\pm$ 0.1%	X

Equations

$$\Pr\,\big{[}(\mathbf{a},\mathbf{b},\mathbf{y}_{0},\mathbf{y}_{1}){\>{\leftarrow{\raisebox{0.75pt}{$\scriptscriptstyle\$$

}}}\>}\scriptsize{\mathsf{Exec}}_{\mathcal{P},k}(a,b):(\mathbf{y}_{0}[\ell],\mathbf{y}_{1}[\ell])=f(a,b)\,\big{]}=1.$$

$$\displaystyle\Pr\Big{[}$$

$$\displaystyle\scriptsize{\mathsf{Out}}_{\mathrm{\Pi},k}^{i}(\mathbf{a},\mathbf{b},\varepsilon)=y_{i}\Big{]}=1\,,$$

$${\mathsf{Adv}}_{\mathrm{\Pi },\mathcal{P},f,i}^{\text{sfe}}(\mathcal{A},\mathcal{S},k)=2\cdot \mathrm{Pr}\left[{\mathsf{Exp}}_{\mathrm{\Pi },\mathcal{P},f,i}^{\text{sfe}}(\mathcal{A},\mathcal{S},k)=1\right]-1.$$

$${\mathsf{Adv}}_{\mathrm{\Pi },f,i}^{\text{sfembox-odd}}(\mathcal{A},\mathcal{S},k)=2\cdot \mathrm{Pr}\left[{\mathsf{Exp}}_{\mathrm{\Pi },f,i}^{\text{sfembox-odd}}(\mathcal{A},\mathcal{S},k)=1\right]-1.$$

$$(\mathbf{y}_{0}[j],\mathbf{y}_{1}[j],\pi,\mathit{st}){\>{\leftarrow{\raisebox{0.75pt}{$\scriptscriptstyle\$$

}}}\>}\mathrm{\Pi}_{\mathrm{o}}[\mathcal{P}.f_{j}](1^{k},u,v,\mathit{st})\,;\vspace*{-0.5em}$$

$$(\mathbf{y}_{0}[j],\mathbf{y}_{1}[j],\pi,\mathit{st}^{\prime}){\>{\leftarrow{\raisebox{0.75pt}{$\scriptscriptstyle\$$

}}}\>}\mathrm{\Pi}_{\mathrm{e}}[\mathcal{P}.f_{j}](1^{k},u,v,\varepsilon)\,.\vspace*{-0.5em}$$

$$(\varepsilon,B,\pi,\mathit{st}^{\prime}){\>{\leftarrow{\raisebox{0.75pt}{$\scriptscriptstyle\$$

}}}\>}\mathrm{\Pi}_{\mathrm{ot}}(1^{k},e,b,\varepsilon).\vspace*{-0.5em}$$

$$(y_{0},y_{1},\pi,\mathit{st}^{\prime}){\>{\leftarrow{\raisebox{0.75pt}{$\scriptscriptstyle\$$

}}}\>}\mathrm{\Pi}(1^{k},a,b,\mathit{st}).$$

$${\mathsf{Adv}}_{\mathcal{G}}^{\mathrm{priv}}(\mathcal{A},\mathcal{S},k)=2\cdot \mathrm{Pr}\left[{\mathsf{Exp}}_{\mathcal{G}}^{\mathrm{priv}}(\mathcal{A},\mathcal{S},k)=1\right]-1.$$

$$\mathrm{Pr}\left[{\mathsf{Out}}_{\mathrm{\Pi },k}^{\mathrm{Bob}}((X_1^0,X_1^1,\dots ,X_n^0,X_n^1),b)=(X_1^{b_1},\dots ,X_n^{b_n})\right]=1$$

$$\mathrm{Pr}\left[{\mathsf{Out}}_{\mathrm{\Pi },k}^{\mathrm{Alice}}((X_1^0,X_1^1,\dots ,X_n^0,X_n^1),b)=\epsilon \right]=1,$$

$${\mathsf{Adv}}_{\mathrm{\Pi },i}^{\mathrm{pfe}}(\mathcal{A},\mathcal{S},k)=2\cdot \mathrm{Pr}\left[{\mathsf{Exp}}_{\mathrm{\Pi },i}^{\mathrm{pfe}}(\mathcal{A},\mathcal{S},k)=1\right]-1.$$

$$\mathsf{Adv}^{\mathrm{\scriptsize{\textup{ind\$}}}}_{\mathrm{\Gamma}}(\mathcal{A})={\Pr\left[\,{K{\>{\leftarrow{\raisebox{0.75pt}{$\scriptscriptstyle\$$

}}}\>}\mathcal{K}:\mathcal{A}^{\mathcal{E}_{K}(\cdot)}=1}\,\right]}-{\Pr\left[\,{\mathcal{A}^{$(\cdot)}=1}\,\right]}$$

$${\mathsf{Adv}}_{\mathrm{\Pi },\mathcal{P},f,i}^{\text{sfe}}(\mathcal{A},\mathcal{S},k)\le$$

$$+$$

$$\mathrm{Pr}\left[X_j=1|d=1,d^{\prime }=1\right]=\mathrm{Pr}\left[{\mathsf{Exp}}_{\mathrm{\Pi },\mathcal{P},f,i}^{\text{sfe}}(\mathcal{A},\mathcal{S},k)=1|c=1\right]$$

$$\mathrm{Pr}\left[X_j=1|d=0,d^{\prime }=0\right]=\mathrm{Pr}\left[{\mathsf{Exp}}_{\mathrm{\Pi },\mathcal{P},f,i}^{\text{sfe}}(\mathcal{A},\mathcal{S},k)=1|c=0\right].$$

$$\mathrm{Pr}\left[X_j=1\right]$$

$$\displaystyle\hskip 15.0pt+{\Pr\left[\,{\mathsf{Exp}^{\mathrm{\scriptsize{\textup{sfe}}}}_{\mathrm{\Pi},\mathcal{P},f,i}(\mathcal{A},\mathcal{S},k)=1|c=0}\,\right]}\Big{)}$$

$$=\frac{1}{2}\cdot \mathrm{Pr}\left[{\mathsf{Exp}}_{\mathrm{\Pi },\mathcal{P},f,i}^{\text{sfe}}(\mathcal{A},\mathcal{S},k)=1\right].$$

$$2\cdot {\mathsf{Adv}}_{{\mathrm{\Pi }}_{\mathrm{o}}[f_j],f_j,i}^{\text{sfembox-odd}}({\mathcal{B}}_{\mathrm{o}},{\mathcal{S}}_{\mathrm{o}},k)\ge {\mathsf{Adv}}_{\mathrm{\Pi },\mathcal{P},f,i}^{\text{sfe}}(\mathcal{A},\mathcal{S},k).$$

$$2\cdot {\mathsf{Adv}}_{{\mathrm{\Pi }}_{\mathrm{e}}[f_j],\mathcal{I},f_j,i}^{\text{sfe}}({\mathcal{B}}_{\mathrm{e}},{\mathcal{S}}_{\mathrm{e}},k)\ge {\mathsf{Adv}}_{\mathrm{\Pi },\mathcal{P},f,i}^{\text{sfe}}(\mathcal{A},\mathcal{S},k).$$

$${\mathsf{Adv}}_{\mathrm{\Pi },\mathcal{I},f,i}^{\text{sfe}}(\mathcal{A},\mathcal{S},k)\le {\mathsf{Adv}}_{\mathcal{G}}^{\mathrm{priv}}({\mathcal{B}}_{\mathcal{G}},{\mathcal{S}}_{\mathcal{G}},k)+{\mathsf{Adv}}_{{\mathrm{\Pi }}_{\mathrm{ot}}}^{\mathrm{pfe}}({\mathcal{B}}_{\mathrm{ot}},{\mathcal{S}}_{\mathrm{ot}},k).$$

$${\mathsf{Adv}}_{\mathrm{\Pi },\mathcal{I},f,i}^{\text{sfe}}(\mathcal{A},\mathcal{S},k)\le {\mathsf{Adv}}_{{\mathrm{\Pi }}_{\mathrm{ot}}}^{\mathrm{pfe}}({\mathcal{B}}_{\mathrm{ot}},{\mathcal{S}}_{\mathrm{ot}},k).$$

$$(\varepsilon,B,\pi,\mathit{st}^{\prime}){\>{\leftarrow{\raisebox{0.75pt}{$\scriptscriptstyle\$$

}}}\>}\mathrm{\Pi}_{\mathrm{ot}}(1^{k},e^{\prime},b,\varepsilon)$$

$${\mathsf{Adv}}_{\mathrm{\Pi },f,i}^{\text{sfembox-odd}}(\mathcal{A},\mathcal{S},k)\le {\mathsf{Adv}}_{\mathrm{\Gamma }}^{\text{ind\$}}(\mathcal{B})$$

$${\Pr\left[\,{K{\>{\leftarrow{\raisebox{0.75pt}{$\scriptscriptstyle\$$

}}}\>}\mathcal{K}:\mathcal{B}^{\mathcal{E}_{K}(\cdot)}=1}\,\right]}={\Pr\left[\,{\mathsf{Exp}^{\mathrm{\scriptsize{\textup{sfe\mbox{-}odd}}}}_{\mathrm{\Pi},f,i}(\mathcal{A},\mathcal{S},k)=1|c=1}\,\right]}$$

$$\mathrm{Pr}\left[{\mathcal{B}}^{\$(\cdot )}=0\right]=\mathrm{Pr}\left[{\mathsf{Exp}}_{\mathrm{\Pi },f,i}^{\text{sfembox-odd}}(\mathcal{A},\mathcal{S},k)=1|c=0\right]$$

$${\mathsf{Adv}}_{\mathrm{\Gamma }}^{\text{ind\$}}(\mathcal{B})$$

$$={\mathsf{Adv}}_{\mathrm{\Pi },f,i}^{\text{sfembox-odd}}(\mathcal{A},\mathcal{S},k).$$

Full text

In this paper, we explore a balanced approach to 2P-SFE on SGX-enabled processors by constructing a protocol for evaluating $f$ relative to a partitioning of $f$. This approach alleviates the burden of trust on the enclave by allowing the protocol designer to choose which components should be evaluated within the enclave, and which via standard cryptographic techniques. We describe SGX-enabled SFE protocols (modeling the enclave as an oracle), and formalize the strongest-possible notion of 2P-SFE for our setting. We prove our protocol meets this notion when properly realized. We implement the protocol and apply it to two practical problems: privacy-preserving queries to a database, and a version of Dijkstra’s algorithm for privacy-preserving navigation. Our evaluation shows that our SGX-enabled SFE scheme enjoys a 38x increase in performance over garbled-circuit-based SFE. Finally, we justify modeling of the enclave as an oracle by implementing protections against known side-channels.

secure function evaluation; SGX; partitioning; protocols

††copyright: acmlicensed††journalyear: 2019††conference: ACM ASIA Conference on Computer and Communications Security; July 9–12, 2019; Auckland, New Zealand††booktitle: ACM Asia Conference on Computer and Communications Security (AsiaCCS’19), July 9–12, 2019, Auckland, New Zealand††price: 15.00††doi: 10.1145/3321705.3329835††isbn: 978-1-4503-6752-3/19/07††ccs: Security and privacy Formal security models††ccs: Security and privacy Privacy-preserving protocols††ccs: Security and privacy Hardware-based security protocols

1. Introduction

Secure function evaluation (SFE) describes the process of multiple parties collectively computing a function and receiving its output without learning the inputs from any other party. Originally proposed in the 1980s, SFE was primarily of theoretical interest until the 2000s, when practical implementations of two-party SFE (2P-SFE) became available. Since then, interest in the space has dramatically increased and the costs of computation have been lowered by orders of magnitude.

Despite this success in reducing the costs of SFE, it is still not yet sufficiently practical to be used in applications where (near) real-time performance is required. This is in large part due to the substantial number of cryptographic operations that the parties need to perform. In the 2P-SFE case, this is often manifested by representing the function to be computed over as a circuit and garbling all of its input and output wires, as well as truth tables associated with each logic gate.

Hardware support for secure computing offers a chance to reduce these costs. Specifically, Intel’s Software Guard Extensions (SGX) provides secure memory regions (called enclaves) inside which code and data can live outside of the purview of the operating system or system administrator. This platform thus offers the potential to enable SFE without the often crippling overheads of the associated cryptographic constructions. While SGX provides native CPU speed for secure computation, previous side-channel and micro-architecture attacks have demonstrated how security guarantees of enclaves can be compromised. Controlled-channel attacks (xu2015controlled, ) leverage the page fault handler to leak sensitive information inside an enclave. Leaky Cauldron (leaky, ) shows memory side channel hazards in SGX ranging from TLB to DRAM modules. Meltdown (meltdown, ) and Spectre (spectre, ) attacks can also be applied to enclaves, and Foreshadow (foreshadow, ) has successfully extracted the CPU attestation key from enclaves thus breaking the SGX remote attestation. Some of these attacks could be mitigated by microcode update or system hardening. However, they do expose two important questions:

1. (1)

Is it reasonable to put all secrets into an enclave? 2. (2)

What could we do if SGX might be compromised?

This paper goes beyond simply introducing SGX to SFE (smcsgx-other, ). Rather, in addition to reducing the computation required for 2P-SFE operations, our scheme provides provable assurance that the most sensitive inputs of either party will remain protected. In summary, our main contributions111Our source code will be made available on https://github.com/FICS/smcsgx. are as follows:

• •

Design of Hybrid SFE Scheme: We provide a new construction that considers the partitioning of a function into multiple segments, some to be executed within an SGX enclave and the others within a garbled circuit. We surface the idea of partitioning a function $f$ as a first-class primitive in the design, as different partitionings induce different schemes, with different efficiency and trust assumptions.

• •

Formal Protocol Analysis: We formalize two-party protocols with an explicit oracle, to support analysis of SFE protocols that leverage an SGX enclave. We also formalize a best-possible notion of 2P-SFE for our setting — traditional 2P-SFE is not possible, in general — and prove that our Hybrid SFE scheme, properly realized, meets this notion.

• •

Evaluation and Case Studies: We provide practical scenarios for using our SFE schemes, including a database interacting with a client for privacy-preserving queries and a location-finding scenario with a privacy-preserving Dijkstra’s algorithm. Our extensive evaluation demonstrates the overhead of these operations and shows that in the hybrid SFE scheme, we increase performance by up to 38x compared to garbled circuits. We also provide an empirical demonstration of resilience to controlled-channel attacks.

Outline

The rest of the paper proceeds as follows: Section 2 provides a high-level view of our hybrid approach; Section 3 provides preliminary notation; Section 4 provides a detailed formal treatment of SGX-enabled SFE; Section 5 defines and analyzes our hybrid protocol; Section 6 discusses side-channels and mitigations for our implementation; Section 7 presents the design and implementation of the protocol schemes within a real SGX environment; Section 8 describes our experimental evaluation; Section 9 considers related work; and Section 10 concludes.

2. Hybrid Approach High-level View

SGX provides a very efficient platform for secure computation. However, the trust model associated with SGX is substantially different than with garbled circuits or other cryptographic approaches to SFE. The secure enclave in which the computation is being performed must attest to the remote party providing data that it is trustworthy. To do this, the enclave must be issued an identifier by Intel and must use an attestation service provisioned by Intel. Unfortunately, Foreshadow attacks have demonstrated that it is hard to guarantee that the sensitive code and data are running in a real enclave rather than an emulation environment even if SGX remote attestation succeeds, leaving alone threats from other side-channel and micro-architecture attacks. Furthermore, the size of the enclave is limited by the enclave page cache, which is limited to approximately 128 MB.222128 MB may be sufficient to run a single application that is not memory-intensive, but it cannot support entire web servers or databases with substantial memory usage. It is especially not enough for a cloud environment, in which multiple subscribers must share the EPC memory of a cloud server. Running multiple full applications would lead to expensive process-swapping operations, negatively impacting performance. Besides these performance considerations, the Intel SGX SDK requires developers to partition programs in order to reduce the TCB contribution of the enclave. For these reasons, parties may not want to rely solely on SGX to compute a function $f$ on their private inputs. However, traditional approaches to SFE using garbled circuits, even using the most efficient schemes, are still orders of magnitude slower than performing the same operations non-securely.333In certain scenarios, secure computation based on the GMW construction may outperform garbled circuit execution (Schneider2013-ma, ) but the larger point still remains about the substantial overhead incurred by privacy-preserving schemes.

We consider the middle ground: parts of the computation of $f$ are performed using SGX, and parts are performed using traditional SFE mechanisms. Exactly how one partitions the function is an efficiency- and security-critical matter. The efficiency viewpoint has already been touched upon, so we take up the security viewpoint.

Our setting is loosely captured in Figure 1. Alice and Bob would like to carry out a protocol for 2P-SFE of $f(a,b)$. Alice has black-box access to an SGX enclave that her environment hosts. (We will justify this black-box modeling in a moment.) Bob, the remote party, shares a secret key with the enclave, used to establish a secure communication channel; Alice has view of this channel, but does not possess the key. As Alice and Bob carry out the protocol, Alice will make “queries” to her enclave, asking it to compute intermediate functions that are specified by a given partitioning of $f$. She provides private input (related to $a$) as part of these queries, and Bob provides private input (related to $b$) via the secure channel. The results of these enclave queries are visible to Alice, and used in subsequent parts of the protocol for computing $f(a,b)$.

Thus, intermediate information about the computation of $f$ is leaked to Alice, even when she participates honestly. This implies that, in general, the standard notion of 2P-SFE is not possible in this setting. A bad partitioning of $f$ may result in intermediate values that leak information about private inputs $a$ and $b$ of Alice and Bob.

We define, and aim to achieve, the best possible SFE notion in this setting. Namely, to show that a protocol for computing $f(a,b)$ leaks nothing more than $f(a,b)$ and the intermediate values. That is, 2P-SFE with respect to a particular way of partitioning the function.

We formally model an SGX enclave as a black-box, but in reality, an enclave may leak information about the computations it performs due to timing side channels, memory access patterns, and controlled-channel attacks on program flow (xu2015controlled, ). Enclave malware was recently demonstrated to be capable of cache attacks on co-located enclaves, recovering nearly entire RSA private keys within 5 minutes (malwaregx, ). To support our black-box modeling of an enclave, we include mitigations for side-channels in our implementations.

3. Preliminaries

In order to design a secure hybrid scheme using SGX, we first introduce the fundamental protocols and their associated notations. This includes our main protocol involving two parties Alice and Bob, an introduction to Garbled Circuit (GC) syntax, and finally 1-2 oblivious transfer in the context of this work.

Let $\mathrm{dom}f$ denote the domain of a function $f$. We use $\varepsilon$ to denote the empty string. If $a$ and $b$ are strings, let $a\,\|\,b$ denote their concatenation. Let y{\>{\leftarrow{\raisebox{0.75pt}{\scriptscriptstyle$}}}\>}A(x_{1},\ldots) denote the execution of a randomized algorithm $A$ on input $(x_{1},\ldots)$ and assigning of the output to $y$. We write $y\leftarrow A(x_{1},\ldots)$ if $A$ is deterministic. Algorithms are randomized unless noted otherwise.

3.1. Protocols

An oracle-relative, two-party protocol $\mathrm{\Pi}$ is a two-party protocol played by $\mathrm{Alice}$ and $\mathrm{Bob}$, in which one or both may have access to an explicitly defined oracle $\mathcal{O}$. The parties and the oracle all have local, private state, which includes a long-term input that is determined during protocol initialization and accessible across protocol executions. In our SGX-enabled protocols, the oracle abstracts an SGX enclave that is part of $\mathrm{Alice}$’s environment, and the long-term inputs of $\mathrm{Bob}$ and the oracle encode a shared key.

Protocols are executed with respect to players’ private inputs. Executing the protocol on $(a,b)$ means to initiate $\mathrm{Alice}$’s state with private input $a$ and $\mathrm{Bob}$’s state with private input $b$, and exchange messages until both players halt. (We assume each player and the oracle have been provisioned with their long-term inputs.) This is denoted (y_{0},y_{1},\pi,\mathit{st}^{\prime}){\>{\leftarrow{\raisebox{0.75pt}{\scriptscriptstyle$}}}\>}\mathrm{\Pi}(1^{k},a,b,\mathit{st}) where $\mathit{st}$ is the initial state of $\mathcal{O}$, $y_{0}$ and $y_{1}$ are the final states of $\mathrm{Alice}$ and $\mathrm{Bob}$ respectively, and $\mathit{st}^{\prime}$ is the final state of $\mathcal{O}$. String $\pi$ is a “transcript” of the protocol execution.444The transcript serves no functional purpose, so we omit the details here. $\scriptsize{\mathsf{Out}}_{\mathrm{\Pi},k}^{i}(a,b,\mathit{st})$ is the random variable denoting the final state of player $i$ when executing protocol $\mathrm{\Pi}$ on $(a,b)$ with $\mathit{st}$ as the oracle’s initial state. (Integer $k$ is the security parameter.) Refer to Appendix A.1 for more details.

Note that our protocol syntax admits trivially secure SFE protocols. For us, the oracle provides a way to abstractly capture an SGX enclave, and our formalization provides a convenient way to reason about SGX-enabled SFE protocols.555Although we choose to reason about SGX-enabled SFE protocols with access to an oracle, it is also possible to prove composition for protocols without oracles.

Adversarial model

We will consider the security of oracle protocols in the presence of semi-honest (sometimes called honest-but-curious) adversaries. This means each player executes the protocol faithfully, but may otherwise act arbitrarily to violate security. All of our notions ask the adversary to distinguish its view of the protocol from the output of a simulator, which is given the private input of the corresponding player (and only the length of the other player’s private input). Although a semi-honest model may not be sufficient for certain classes of real-world applications, it offers a natural first step towards SGX-enabled SFE. In many situations, we can expect computing parties to have a mutual interest in fulfilling the protocol correctly. Our model nevertheless does not prevent an adversary from attempting to break into the enclave.

3.2. Garbling schemes

We adopt the syntax of Bellare, Hoang, and Rogaway (garbling, ) for garbled circuits. A garbling scheme is a quadruple of algorithms $\mathcal{G}=(\scriptsize{\mathsf{Gb}},\scriptsize{\mathsf{En}},\scriptsize{\mathsf{De}},\scriptsize{\mathsf{Ev}})$; the first is randomized, while the rest are deterministic. The garbling algorithm $\scriptsize{\mathsf{Gb}}$ takes as input $1^{k}$ and a function $f$, and outputs a triple of strings $(F,e,d)$. This is written (F,e,d){\>{\leftarrow{\raisebox{0.75pt}{\scriptscriptstyle$}}}\>}\scriptsize{\mathsf{Gb}}(1^{k},f). String $e$ describes the encoding function, and $X\leftarrow\scriptsize{\mathsf{En}}(e,x)$ denotes the encoding of $x$ under $e$; we call $X$ the garbled input. String $F$ describes the garbled function, and $Y\leftarrow\scriptsize{\mathsf{Ev}}(F,X)$ denotes evaluating $F$ on $X$, yielding the garbled output $Y$. Finally, string $d$ describes the decoding function, and $y\leftarrow\scriptsize{\mathsf{De}}(d,Y)$ denotes the decoding of $Y$ under $d$, yielding the final output $y$. The garbling scheme $\mathcal{G}$ is correct if for every function $f$, for every $x$ in the domain of $f$, and for every $(F,e,d)$ in the range of $\scriptsize{\mathsf{Gb}}(1^{k},f)$, it holds that $f(x)=\scriptsize{\mathsf{De}}(d,\scriptsize{\mathsf{Ev}}(F,\scriptsize{\mathsf{En}}(e,x)))$.

Garbling circuits were introduced by Andrew Yao (Yao1982, ). His construction, as well as most recent designs, have an additional syntactic property necessary for SFE. A garbling scheme is called projective if the encoding algorithm may be written as a pair of algorithms $(\scriptsize{\mathsf{EnA}},\scriptsize{\mathsf{EnB}})$ such that $\scriptsize{\mathsf{En}}(e,(a,b))=\scriptsize{\mathsf{EnA}}(e,a)\,\|\,\scriptsize{\mathsf{EnB}}(e,b)$ for every $(a,b)\in\mathrm{dom}f$. (See Appendix A.2 for a more formal definition.)

Bellare, Hoang, and Rogaway (garbling, ) formalize a security notion for garbling schemes, which we will use here. The privacy of a garbling scheme captures the adversary’s ability to discern anything about $f$ or $x$ given only $F$, $X$, and $d$. The notion is parameterized by side information about the function $f$ — for example, the length of its encoding, or the topology of the circuit used to compute it. The adversary is given the side information as input. In the SFE setting, the side information is $f$ itself. We formalize the simulation-based privacy notion of (garbling, ) in Appendix A.2.

3.3. 1-2 oblivious transfer

A standard way of facilitating secure multiparty computation (and achieving SFE in particular) is to compose a projective garbling scheme with an oblivious transfer protocol (rabin2005exchange, ). A 1-2 (one-of-two) transfer protocol is a two-party protocol in which $\mathrm{Alice}$ possesses two equal-length strings $X^{0}$ and $X^{1}$ and $\mathrm{Bob}$ possesses a bit $b$. Roughly speaking, a 1-2 transfer protocol is oblivious if $\mathrm{Bob}$ learns $X^{b}$ (and only $X^{b}$) and $\mathrm{Alice}$ learns nothing. More generally, $\mathrm{Alice}$ may possess a sequence of strings $(X^{0}_{1},X^{1}_{1},\ldots,X^{0}_{n},X^{1}_{n})$ and $\mathrm{Bob}$ a string $b$ of length $n$, and the goal is to obliviously transfer $(X_{1}^{b_{1}},\ldots,X_{n}^{b_{n}})$ to $\mathrm{Bob}$. We formalize this security property in Appendix A.3.

4. SFE for Partitioned Functions

We next describe our construction of SFE for partitioned functions.

Our main protocol partitions the computation of a function into a sequence of round functions, each depending on a piece of the players’ private input. Odd-round functions are evaluated within $\mathrm{Alice}$’s enclave and may depend on its state. Even-round functions are stateless and evaluated using standard cryptographic techniques.

We first give the syntax of an partitioning scheme that captures this computational model.666Our aim is to demonstrate the possibility of combining SGX and Garbled Circuits for SFE, given a proper partitioning scheme. Partitioning is itself a hard problem that we do not attempt to solve; entire papers (zdancewic, ; partition_web, ) have been dedicated to it. Four possible partitioning schemes for SGX programs are explored by Atamli-Reineh and Martin (partition_sgx_casestudy, ), ranging from the naïve placement of entire applications in an enclave to separating out sensitive components into individual enclaves. We then define secure evaluation of a function relative to a partitioning of it, which captures the intermediate results available to $\mathrm{Alice}$ and $\mathrm{Bob}$.

4.1. $\ell$-way even-odd partitioning schemes

Let $\ell$ be a positive integer and $f$ be a function of two inputs and two outputs. An $\ell$-way even-odd partitioning scheme $\mathcal{P}$ for $f$ is a sequence of round functions $(f_{1},\ldots,f_{\ell})$ and a pair of probabilistic algorithms $(\scriptsize{\mathsf{SpA}},\scriptsize{\mathsf{SpB}})$. Let $(a,b)\in\mathrm{dom}f$ and $k$ be a positive integer. On input $(1^{k},a)$, algorithm $\scriptsize{\mathsf{SpA}}$ outputs an $\ell$-vector of strings $\mathbf{a}$. Similarly, on input $(1^{k},b)$, algorithm $\scriptsize{\mathsf{SpB}}$ outputs an $\ell$-vector of strings $\mathbf{b}$. These are the local inputs of $\mathrm{Alice}$ and $\mathrm{Bob}$, respectively. Even-round function evaluations are stateless, while odd-round function evaluations carry state from one odd-round to the next. This allows us to model stateful SGX computation. Even-numbered functions map two strings ($\mathrm{Alice}$ and $\mathrm{Bob}$’s local inputs) to two strings ($\mathrm{Alice}$ and $\mathrm{Bob}$’s outputs), and odd-numbered functions map three strings ($\mathrm{Alice}$ and $\mathrm{Bob}$’s local inputs, and the state of the oracle) to three strings ($\mathrm{Alice}$ and $\mathrm{Bob}$’s outputs and the oracle’s updated state).

We define the execution of $\mathcal{P}$ in Figure 3. (See Figure 2 for an illustration.) The partitioning scheme $\mathcal{P}$ is correct for $f$ if for every positive integer $k$ and every $(a,b)\in\mathrm{dom}f$, it holds that

[TABLE]

We define $\mathcal{I}$ as the 1-way even-odd partitioning scheme defined for every function $f$ as follows. Let $(a,b)\in\mathrm{dom}f$ and $k$ be a positive integer. On input $(1^{k},a)$, algorithm $\mathcal{I}.\scriptsize{\mathsf{SpA}}$ outputs a 1-vector containing $a$, and on input $(1^{k},b)$, algorithm $\mathcal{I}.\scriptsize{\mathsf{SpB}}$ outputs a 1-vector containing $b$. Correctness demands that $\mathcal{I}.f_{1}=f$. We call $\mathcal{I}$ the identity partition.

4.2. Partition-relative (2P)-SFE

Let $f$ be a function of two inputs and two outputs and let $\mathcal{P}$ be a partitioning scheme for $f$. Syntactically, a protocol $\mathrm{\Pi}$ for evaluating $f$ relative to $\mathcal{P}$ is an oracle protocol played by $\mathrm{Alice}$ and $\mathrm{Bob}$ with the following correctness condition: for each $i\in\{\mathrm{Alice},\mathrm{Bob}\}$, every positive integer $k$, and every $(a,b)\in\mathrm{dom}f$, where $(y_{\mathrm{Alice}},y_{\mathrm{Bob}})=f(a,b)$, it holds that

[TABLE]

Defining SFE

Our base notion of SFE will be stated relative to a given partitioning scheme and admits the traditional notion of SFE as a special case. We formalize the idea that a protocol securely evaluates a function (relative to a partitioning of that function) if nothing is leaked to either party beyond that which follows from its own local inputs and outputs.777If $\mathrm{Alice}$’s or $\mathrm{Bob}$’s private input is leaked in the intermediate values, this is a failure of the partitioning, not of the SFE protocol. To do so, we insist that each party’s view of the protocol’s execution can be computed without interacting with the other party.

Let $f$ be a function, $\mathcal{P}$ be a partitioning scheme for $f$, and $\mathrm{\Pi}$ be an oracle protocol for evaluating $f$ relative to $\mathcal{P}$. Security is captured by the game defined in the top-left panel of Figure 9 (located in the Appendix). We sketch the notion here. The security experiment is associated to player $i\in\{\mathrm{Alice},\mathrm{Bob}\}$, adversary $\mathcal{A}$, simulator $\mathcal{S}$, and security parameter $k$. The goal of the adversary is to distinguish the view of player $i$ from the output of $\mathcal{S}$, which is given $f$, player $i$’s local inputs and outputs, and only the length of the other player’s inputs and outputs. To begin, the adversary chooses a pair of inputs $(a,b)\in\mathrm{dom}f$ and the inputs are split according to $\mathcal{P}$. A challenge bit $c$ is chosen. If $c=1$, then the protocol is executed and the adversary is handed $i$’s view of the protocol execution, derived from the transcript; if $c=0$, then the simulator is executed and the adversary is given its output. The adversary wins if it outputs $c$. The advantage of $\mathcal{A}$ in the game instantiated with simulator $\mathcal{S}$ at security parameter $k$ is defined as

[TABLE]

We say that $\mathrm{\Pi}$ securely evaluates $f$ relative to $\mathcal{P}$ if for each $i\in\{\mathrm{Alice},\mathrm{Bob}\}$ and every polynomial-time $\mathcal{A}$, there exists a polynomial-time $\mathcal{S}$ such that $\mathsf{Adv}^{\mathrm{\scriptsize{\textup{sfe}}}}_{\mathrm{\Pi},\mathcal{P},f,i}(\mathcal{A},\mathcal{S},k)$ is negligible as a function of the security parameter $k$. We refer to such a protocol as an SFE-secure protocol for $f$ relative to $\mathcal{P}$.

When $\mathcal{P}=\mathcal{I}$, our notion reduces to standard SFE, and we simply say that $\mathrm{\Pi}$ securely evaluates $f$, dropping the reference to the partitioning.

5. Hybrid SFE-SGX

Now having discussed our model for Secure Function Evaluation (SFE) on a partitioned function, we extend this to the context of computing using Intel SGX. It is critical that we define our own syntax and construction, despite formalisms already existing (smcsgx-other, ; sinha2015moat, ), as there is no previous work that partitions Secure Multiparty Computation between SGX hardware and traditional Garbled Circuits.

Let $\mathcal{P}$ be an $\ell$-way even-odd partitioning of $f$, where $f_{1},\ldots,f_{\ell}$ are the round functions. The main technical result of this section says, loosely, that if one possesses protocols for securely evaluating $f_{1},\ldots,f_{\ell}$, then these can be composed to give a protocol for securely evaluating $f$ relative to the information leaked by the component functions. This result highlights the need to carefully consider how $f$, and the private inputs $a,b$, are partitioned. Concretely, one may have a protocol for securely computing $f_{1}(a_{1},b_{1},\mathit{st})$, which leaks nothing more about $a_{1},b_{1},\mathit{st}$ than $f_{1}$ does itself. But $f_{1}$ may, for example, leak all of $a_{1}$. The claimed implication will hold, but if $a_{1}=a$, there is no security in the classical sense of SFE.888We note that this particular leakage is ameliorated if $a_{1}$ itself leaks no efficiently computable information about $a$, e.g., $a_{1}$ is an encryption of $a$ under a secret key.

Before we can state our main result, we define (as technical tools) syntax and security notions for protocols for even- and odd-round function evaluations.

Even-round protocols

An even-round protocol $\mathrm{\Pi}$ is an oracle protocol played by $\mathrm{Alice}$ and $\mathrm{Bob}$ for evaluating functions of two inputs and two outputs. We write $\mathrm{\Pi}[f]$ to denote the protocol instantiated with a particular function $f$. Correctness demands that for each $i\in\{\mathrm{Alice},\mathrm{Bob}\}$, every $(a,b)\in\mathrm{dom}f$, and every positive integer $k$, it holds that $\Pr[\scriptsize{\mathsf{Out}}^{i}_{\mathrm{\Pi}[f],k}(a,b)=y_{i}]=1$ where $(y_{\mathrm{Alice}},y_{\mathrm{Bob}})=f(a,b)$. We consider the SFE security of even-round protocols relative to the identity partition.

Odd-round protocols

An odd-round protocol $\mathrm{\Pi}$ is an oracle protocol played by $\mathrm{Alice}$ and $\mathrm{Bob}$ for evaluating functions of three inputs and three outputs. We write $\mathrm{\Pi}[f]$ to denote the protocol instantiated with a particular function $f$. Correctness demands that for each $i\in\{\mathrm{Alice},\mathrm{Bob}\}$, every $(a,b,\mathit{st})\in\mathrm{dom}f$, and every positive integer $k$, it holds that $\Pr[\scriptsize{\mathsf{Out}}^{i}_{\mathrm{\Pi}[f],k}(a,b,\mathit{st})=y_{i}]=1$, where $(y_{\mathrm{Alice}},y_{\mathrm{Bob}},\mathit{st}^{\prime})=f(a,b,\mathit{st})$ for some $\mathit{st}^{\prime}\in\{0,1\}^{*}$.

Defining SFE-ODD

We introduce a new security notion for odd-round protocols. The main distinction from standard SFE is that the adversary specifies the oracle’s initial state. Security of odd-round protocols is defined in the top-right panel of Figure 9 (located in the Appendix). We define the advantage of adversary $\mathcal{A}$ in the game instantiated with simulator $\mathcal{S}$ as

[TABLE]

We say that $\mathrm{\Pi}$ is an SFE-ODD-secure protocol for $f$ if for each $i\in\{\mathrm{Alice},\mathrm{Bob}\}$ and every polynomial-time adversary $\mathcal{A}$, there exists a polynomial-time simulator $\mathcal{S}$ such that the function  $\mathsf{Adv}^{\mathrm{\scriptsize{\textup{sfe\mbox{-}odd}}}}_{\mathrm{\Pi},f,i}(\mathcal{A},\mathcal{S},k)$ is negligible as a function of $f$.

5.1. The hybrid SFE-SGX protocol

Our main protocol is defined in Figure 4. Let $f$ be a function of two inputs and two outputs and let $\mathcal{P}$ be an $\ell$-way even-odd partitioning scheme for $f$. The protocol is composed from $\mathcal{P}$, an odd-round protocol $\mathrm{\Pi}_{\mathrm{o}}$, and an even-round protocol $\mathrm{\Pi}_{\mathrm{e}}$. The protocol is defined on $\ell$-vectors $\mathbf{a}$ and $\mathbf{b}$ corresponding to $\mathrm{Alice}$ and $\mathrm{Bob}$’s respective split inputs. They first execute $\mathrm{\Pi}_{\mathrm{o}}[\mathcal{P}.f_{1}]$ with private inputs $(\mathbf{a}[1],\mathbf{b}[1])$ with oracle $\mathrm{\Pi}_{\mathrm{o}}.\mathcal{O}$. As a result, $\mathrm{Alice}$ gets $\mathbf{y}_{0}[1]$, $\mathrm{Bob}$ gets $\mathbf{y}_{1}[1]$, and the oracle’s state gets updated to $\mathit{st}$ where $(\mathbf{y}_{0}[1],\mathbf{y}_{1}[1],\mathit{st})=\mathcal{P}.f_{1}(\mathbf{a}[1],\mathbf{b}[1],\varepsilon)$. Next, they execute $\mathrm{\Pi}_{\mathrm{e}}[\mathcal{P}.f_{2}]$ on private inputs $(\mathbf{a}[2]\,\|\,\mathbf{y}_{0}[1],\mathbf{b}[2]\,\|\,\mathbf{y}_{1}[1])$ and with oracle $\mathrm{\Pi}_{\mathrm{e}}.\mathcal{O}$. $\mathrm{Alice}$ gets $\mathbf{y}_{0}[2]$ and $\mathrm{Bob}$ gets $\mathbf{y}_{1}[2]$ as a result. $\mathrm{Alice}$ and $\mathrm{Bob}$ continue in this way, alternating between odd-round and even-round evaluations. Correctness of $\mathcal{P}$ ensures that $(\mathbf{y}_{0}[\ell],\mathbf{y}_{1}[\ell])=f(a,b)$.

We instantiate the even-round protocol using standard techniques from GC-based SFE and specify an example, constructed from a projective garbling scheme and a 1-2 transfer protocol, in Figure 5. This protocol does not make use of an oracle, relying only on the security of its constituent cryptographic primitives.

Finally, we instantiate the odd-round protocol using the SGX module (modeled as an oracle) and a symmetric encryption scheme $\mathrm{\Gamma}=(\mathcal{K},\mathcal{E},\mathcal{D})$. (SGX uses AES-GCM with a random initialization vector. See Appendix A.4 for syntax and security notions for symmetric encryption.) The protocol is defined in Figure 6. $\mathrm{Bob}$ shares a key with $\mathrm{Alice}$’s enclave. To evaluate a function $f$ on $(a,b)$, $\mathrm{Bob}$ encrypts $b$ and sends it to $\mathrm{Alice}$, who then sends the function, her own input, and $\mathrm{Bob}$’s ciphertext to the SGX module. The module decrypts $b$, evaluates the function (which depends on its internal state), then returns the result to $\mathrm{Alice}$.

The hybrid SFE-SGX protocol instantiated with $\mathrm{\Pi}_{\mathrm{sgx}}$ and $\mathrm{\Pi}_{\mathrm{gc}}$ is useful for evaluating functions whereby $\mathrm{Alice}$ gets the result and $\mathrm{Bob}$ gets nothing. More precisely, $\mathrm{\Pi}_{\mathrm{hyb}}[\mathcal{P},\mathrm{\Pi}_{\mathrm{sgx}},\mathrm{\Pi}_{\mathrm{gc}}]$ is well-defined when $\mathcal{P}$ is an even-odd partitioning of a function $f$ such that for every $(a,b)\in\mathrm{dom}f$, it holds that $f(a,b)=(y,\varepsilon)$ for some string $y$. This is not always desirable; in some applications,  $\mathrm{Bob}$ should receive the final result. To address this, we specify the dual protocol of hybrid SFE-SGX, whereby $\mathrm{Bob}$ learns all of the intermediate results, including the final result, and $\mathrm{Alice}$ learns nothing.

5.2. The dual hybrid SFE-SGX protocol

Let $f$ be a function of two outputs and two inputs such that for every $(a,b)\in\mathrm{dom}f$, there exists a string $y$ such that $f(a,b)=(\varepsilon,y)$. Let $\mathcal{P}$ be an even-odd partitioning scheme for $f$. Protocol $\mathrm{\Pi}_{\mathrm{gc}}^{\prime}$ is like its dual $\mathrm{\Pi}_{\mathrm{gc}}$, except that $\mathrm{Alice}$ also sends $\mathrm{Bob}$ the string $d$, the means to decode, in step 1. In step 3, $\mathrm{Bob}$ computes $Y\leftarrow\scriptsize{\mathsf{Ev}}(F,A\,\|\,B)$ and decodes $y\leftarrow\scriptsize{\mathsf{De}}(d,Y)$ and halts on $y$. $\mathrm{Alice}$ halts on output $\varepsilon$. Protocol $\mathrm{\Pi}_{\mathrm{sgx}}^{\prime}$ is like its dual $\mathrm{\Pi}_{\mathrm{sgx}}$, except that in step 3, after computing $(y,\mathit{st})\leftarrow f(a,b,\mathit{st})$, the oracle encrypts $y$ under $K$ and returns the ciphertext to $\mathrm{Alice}$. $\mathrm{Alice}$ transmits the ciphertext to $\mathrm{Bob}$ and halts on $\varepsilon$. Finally, $\mathrm{Bob}$ decrypts and halts on $y$.

Then $\mathrm{\Pi}_{\mathrm{hyb}}[\mathcal{P},\mathrm{\Pi}_{\mathrm{sgx}}^{\prime},\mathrm{\Pi}_{\mathrm{gc}}^{\prime}]$ is, syntactically, a protocol for evaluating $f$ relative to $\mathcal{P}$. Unlike its dual, $\mathrm{Bob}$ receives the final and intermediate outputs and $\mathrm{Alice}$ receives nothing.999Some applications may require both $\mathrm{Alice}$ and $\mathrm{Bob}$ to receive intermediate and final outputs. We note that our hybrid SFE-SGX and dual hybrid SFE-SGX protocols would behave like traditional GC if both parties are given the final output, but intermediate outputs must be handled more carefully. Intermediate outputs based from odd-rounds may leak information about the more-sensitive data handled by even-rounds. This is a line of inquiry beyond the scope of this paper, but it is certainly important.

5.3. Case Study: Database

Having exhaustively defined the necessary partitioning scheme in developing a hybrid model for SGX, we present two case studies to demonstrate real-world use of our protocols.

The first of these involves querying a database. $\mathrm{Alice}$ provides a database with $n$ rows, and $\mathrm{Bob}$ issues $k$ select queries against it. Each query retrieves a single 64-bit entry associated with the index provided as input. The results of the queries are returned to $\mathrm{Bob}$.101010Although the database program we architect resembles a simple key-value store, it offers an initial demonstration that database retrieval is possible according to our hybrid scheme. No work had previously attempted to combine a database application across SGX and GC. Our database supports both retrieval and updates to data entries in a manner which corresponds to GET and SET requests against production databases. The goal in this setting is to provide the requested entries to $\mathrm{Bob}$ without revealing any queried indices to $\mathrm{Alice}$. Using our hybrid protocol, $\mathrm{Bob}$ would protect his most sensitive queries using GC-based computation and the less sensitive ones with SGX-enabled computation. Such a scenario may be practical in the case of a database implementing a simple Multilevel Security (MLS) scheme, where data is encoded at one of two levels (i.e., secret, top secret). This approach would allow the existence of queries to potentially (but not necessarily) top secret data to be obfuscated, without incurring the expense of using garbled circuits for all accesses.

Hybrid Program

This program can be evaluated using the dual hybrid SFE-SGX protocol. Some portion of the queries entered by $\mathrm{Bob}$ are considered highly sensitive, meaning $\mathrm{Bob}$ is especially concerned with not having them revealed. $\mathrm{Bob}$ splits his $k$ queries into two bins corresponding to $f_{1}$, the SGX portion of the program, and $f_{2}$, the GC portion. $\mathrm{Alice}$ loads the database into her enclave, which will evaluate $f_{1}$, and $\mathrm{Bob}$ issues queries against the enclave from his bin of less-sensitive inputs. Once the requested entries are returned to $\mathrm{Bob}$, the two parties switch from $f_{1}$ to $f_{2}$ by having $\mathrm{Alice}$’s enclave pass the database into the garbled circuit as $y_{1}$, the garbled version of the database. $\mathrm{Bob}$ garbles the inputs corresponding to his highly sensitive queries by performing 1-2 OT with $\mathrm{Alice}$. $\mathrm{Bob}$ then evaluates the garbled circuit and receives the requested entries associated with his more sensitive inputs. $\mathrm{Alice}$ has no output.

Intuition for Further Rounds

If the output $\mathrm{Bob}$ receives in the second round above advises the next set of data queries, the program’s evaluation may be extended into further rounds. At this stage, $\mathrm{Alice}$ does not know $\mathrm{Bob}$’s GC output from the prior round, but any future queries, if dependent on this intermediate output, may leak information to $\mathrm{Alice}$ about $\mathrm{Bob}$’s sensitive inputs. If there are many result sets which could have advised $\mathrm{Bob}$’s next set of queries (or if $f_{2}$ was empty), $\mathrm{Bob}$ may continue as before, splitting his queries into two bins corresponding to $f_{1}$ and $f_{2}$, participating in another series of odd- and even-rounds. Otherwise (if $\mathrm{Bob}$’s next set of queries could only be a result of a few specific outputs from the initial GC round), all subsequent queries must be made exclusively in even-rounds (by emptying $f_{1}$ or filling it with dummy queries).

5.4. Case Study: Dijkstra’s Shortest-Path

Our second case study uses Dijkstra’s shortest-path algorithm. This algorithm finds the shortest path between two nodes in a graph. Again, there are two parties, $\mathrm{Alice}$ and $\mathrm{Bob}$. The graph topology is known to both $\mathrm{Alice}$ and $\mathrm{Bob}$, but only $\mathrm{Bob}$ knows the edge weights. $\mathrm{Bob}$ provides as input the graph’s edge weights, and $\mathrm{Alice}$ inputs the starting and ending points. The goal of SFE in this setting is for $\mathrm{Alice}$ to receive the shortest path from her starting point to her ending point while not learning $\mathrm{Bob}$’s edge weights.

Hybrid Program

This program is evaluated using the standard hybrid SFE-SGX protocol. Some subset of the nodes in the graph make up a highly-sensitive portion of the map (graph), and $\mathrm{Bob}$ is especially concerned with not having the edge weights incident to them revealed while routing through that portion of the map. The highly-sensitive portion will be routed solely in a garbled circuit during $f_{2}$, whereas the less-sensitive portion will be routed within the SGX module during $f_{1}$. The final route may contain nodes from both portions (Figure 7 demonstrates how a graph may contain both highly-sensitive and less-sensitive portions). Any route through the graph is allowed to travel into and out of the sensitive part of the graph a single time; this is possible by setting edge weights in a specific way. The path must not start or end in the highly sensitive part of the graph. This partitioning could be useful in a scenario where roads traverse private/government property with selective access, the topological features of which must remain undisclosed.

The initial Dijkstra computation is run as $f_{1}$ in $\mathrm{Alice}$’s enclave. $\mathrm{Alice}$’s input to $f_{1}$ is the starting and ending points, and $\mathrm{Bob}$ passes the less-sensitive edge weights into the enclave. A route through the non-sensitive portion of the graph is calculated. This route is returned to $\mathrm{Alice}$ from the enclave, though it only covers the non-sensitive portion of the graph and may not yet be the complete route. Afterward, a garbled circuit is used to route through the highly-sensitive portion of the graph; the garbled circuit is evaluated regardless of whether the path goes through the highly-sensitive portion of the graph. The entrance and exit nodes for the sensitive portion of the graph are provided by the enclave as $y_{1}$ to $f_{2}$. $\mathrm{Alice}$ has no input into $f_{2}$. $\mathrm{Bob}$’s input into $f_{2}$ is the collection of sensitive edge weights. Upon evaluation of the garbled circuit associated with $f_{2}$, $\mathrm{Alice}$ receives as output the route through the highly sensitive portion of the graph. $\mathrm{Bob}$ has no output.

Intuition for Further Rounds

At the completion of the first series of rounds, $\mathrm{Alice}$ knows a shortest path between her starting and ending points. This may be part of a larger path, in the case that there are certain nodes $\mathrm{Alice}$ must visit en-route. However, $\mathrm{Alice}$’s new starting and ending points will not be dependent on the prior output. More rounds may nevertheless be required if, for instance, the same node should not be revisited, in which case the modified graph (with visited nodes removed) will be fed directly into the next series of rounds while $\mathrm{Alice}$ provides her new starting and ending points (for continuing the path).

5.5. Security of hybrid SFE-SGX

Our main result is that the composition of an odd-round and an even-round protocol achieves secure function evaluation relative to a particular partitioning of the function. The following theorem says that as long as the evaluations of even-round functions are SFE-secure and the evaluations of odd-round functions are SFE-ODD-secure, then the hybrid SFE-SGX protocol securely evaluates function $f$ relative to even-odd partitioning scheme $\mathcal{P}$ for $f$. We discuss proofs of this section’s theorems in Appendices A.5, A.6, and A.7.

Theorem 5.1.

Let $f$ be a function of two inputs and two outputs and $\mathcal{P}$ be an $\ell$-way even-odd partitioning scheme for $f$, where $\ell$ is a positive integer. Let $\mathrm{\Pi}_{\mathrm{e}}$ be an even-round protocol and $\mathrm{\Pi}_{\mathrm{o}}$ be an odd-round protocol. Let $\mathrm{\Pi}=\mathrm{\Pi}_{\mathrm{hyb}}[\mathcal{P},\mathrm{\Pi}_{\mathrm{o}},\mathrm{\Pi}_{\mathrm{e}}]$ as defined in Figure 4. If $\mathrm{\Pi}_{\mathrm{o}}[\mathcal{P}.f_{j}]$ is an SFE-ODD-secure protocol for evaluating $\mathcal{P}.f_{j}$ for every odd $j$ and $\mathrm{\Pi}_{\mathrm{e}}[\mathcal{P}.f_{j}]$ is an SFE-secure protocol for evaluating $\mathcal{P}.f_{j}$ for every even $j$, then $\mathrm{\Pi}$ securely evaluates $f$ relative to $\mathcal{P}$.

The following theorem is a standard result, which says that the composition of a private, projective garbling scheme and a 1-2 oblivious transfer protocol yields secure evaluation of the even-round functions.

Theorem 5.2.

Let $f$ be a function of two inputs and two outputs, $\mathcal{G}$ be a projective garbling scheme, $\mathrm{\Pi}_{\mathrm{ot}}$ be a 1-2 transfer protocol, and let $\mathrm{\Pi}=\mathrm{\Pi}_{\mathrm{gc}}[f,\mathcal{G},\mathrm{\Pi}_{\mathrm{ot}}]$ as defined in Figure 5. If $\mathcal{G}$ is private and $\mathrm{\Pi}_{\mathrm{ot}}$ is oblivious, then $\mathrm{\Pi}$ is an SFE-secure protocol for $f$.

This result represents the best-case scenario in the setting where $\mathrm{Alice}$ is given the internal state of her SGX module. Since even-round evaluations remain secure, she learns nothing beyond that which follows from the result of each even-round computation and possession of the inputs $\mathrm{Bob}$ sent encrypted to the SGX module.

Lastly, the following theorem says that, viewing the SGX module as an oracle, secure symmetric encryption suffices for SFE-ODD-secure evaluation of the odd-round functions. (IND$ refers to the standard indistinguishability notion for encryption schemes defined in Appendix A.4.)

Theorem 5.3.

*Let $f$ be a function of three inputs and three outputs, $\mathrm{\Gamma}=(\mathcal{K},\mathcal{E},\mathcal{D})$ be a symmetric encryption scheme, and let $\mathrm{\Pi}=\mathrm{\Pi}[f,\mathrm{\Gamma}]$ as defined in Figure 6. If $\mathrm{\Gamma}$ is IND$*-secure, then$\mathrm{\Pi}$is SFE-ODD-secure for$f$.

We remark that the protocol $\mathrm{\Pi}_{\mathrm{hyb}}$ instantiated with $\mathrm{\Pi}^{\prime}_{\mathrm{gc}}$ and $\mathrm{\Pi}^{\prime}_{\mathrm{sgx}}$ as the even- and odd-round protocols is also secure. The proof follows closely the justifications of Theorems 5.2 and 5.3.

In the next section, we justify modeling SGX as a black-box by addressing side-channel attacks. But first, we remark that even if these protections do not suffice, our protocol still provides a measure of assurance. Suppose, in the worst case, that $\mathrm{Alice}$ is given the internal state of her enclave (and hence any keys shared with $\mathrm{Bob}$). Secure evaluation of $f(a,b)$ is out of reach in this setting, since $\mathrm{Alice}$ learns some of $\mathrm{Bob}$’s local inputs and outputs. Still, $\mathrm{Bob}$’s most sensitive inputs remain secure (even upon enclave compromise, as an enclave only handles private inputs for odd-rounds): $\mathrm{Alice}$ learns nothing about them beyond that which follows from knowing the state of her enclave and the result of the computation.

6. Side-Channel Attack Mitigations

Unfortunately, SGX enclaves suffer from side-channels which may leak data regarding program execution and data (intel-sgx-enclave-manual-windows, ; tsgx17, ; stancesc, ). In order to continue evaluating our hybrid scheme, we must justify the oracle assumption on SGX heuristically by using code modifications to close known side channels.111111For this work, our mitigations are applied manually for each function. The availability of a tool that automates this process would make it easier to adopt our hybrid protocol. These channels are associated with timing and program flow, which allow an outside observer to infer what path a program takes during its execution or what memory is being accessed (due to access times), and memory accesses, where an attacker observes the parts of RAM accessed by the program.

Timing

We take steps to ensure our programs run for the same amount of time regardless of the input, underlying values in memory, or the result. We ensure both branches of every if statement take the same amount of time and fix loop bounds that could otherwise reveal how many times a loop executes (timingprotections, ). An example of this would be to have each branch perform the same amount of work (e.g., a single assignment to a variable).

Program Flow

Even though if statements take the same amount of time, controlled-channel attacks (xu2015controlled, ) on the program flow are still possible (i.e., if the true code branch causes a instruction page miss, then this leaks information). To further mitigate these, we modify all if statements to prevent branches. For example, if(a == b) c = 1 else c = 2 can be converted into the branch-free version int t = a == b; t = makeSameAsBit0(t), c = (t & 1) | (($\neg$t) & 2), where makeSameAsBit0 sets all bits of t to the least-significant bit. In the new version, there is no branch that would reveal information about the program flow.121212Our approach differs from Raccoon (raccoon, ), which executes multiple program paths on a given input; instead, we do away with branching paths altogether prior to execution.

Memory Accesses

Any query to a specific array index will reveal the memory page that was queried if that page faulted. Additionally, cache side channels can reveal to motivated attackers which data or code memory addresses are being accessed (brumley2009cache, ). To counter this, we move RAM accesses from programs to a binary search tree (BST)-based Oblivious RAM (ORAM)-like construction loosely based on Path ORAM (stefanov2013path, ). This modification distributes array accesses across many randomized memory accesses, as is visually apparent in Figure 8. The security model for our BST structure is similar to that of other ORAM systems, but is different in two important ways: (1) we deal with a trusted module in a compromised, malicious operating system (ren2013design, ) which may attempt timing-based attacks, and (2) our modifications are designed to hide program flow, not just data access patterns.131313As opposed to traditional (e.g., Path) ORAM, we do not deal with a client/server setting, in which the server is not trusted to correctly perform the ORAM. The ORAM functionality within the enclave can be verified during attestation, making it unnecessary to maintain the position map and stash in a separate “trusted client.”

Let us briefly summarize the design of our system.

• •

Our BST forest contains two trees, each with about half the nodes at any given time and in a sorted order, but no duplicate entries with the other. Each node has a key-value pair, where the key is array index and the value is the data.

• •

Every query for a node must descend through each tree all the way to a leaf. After the query, each node along the path is removed, moved to a different RAM location, and randomly added back into a tree. To hide where each key and data were moved, we place every deleted node’s data to a contiguous segment of memory, then randomly swap them using the const-time and branch-free operations from before.

• •

To hide the actual query, $\log(n)$ queries are issued to each tree for every real query.

Whenever there is code that may reveal the searched index, we employ constant-time and branch-free techniques from the program flow section to hide the information.

7. Design and Implementation

In Section 5, we assumed $\mathrm{Alice}$ possessed an SGX module with which $\mathrm{Bob}$ shared a secret key. Here, and in our implementation, we assume for simplicity that both parties possess an SGX module. The two modules share a key unknown to either $\mathrm{Alice}$ or $\mathrm{Bob}$, constructed during SGX remote attestation and used to set up a secure communication channel between the modules. We refer to the party who executes code in his/her enclave as the evaluator. The other party is called the sender.

We implement our protocols using Intel’s SGX SDK for Linux (01intelsgx, ). Rather than simply replacing GC computation using SGX (smcsgx-other, ), we provide the first implementation that we are aware of combining SGX and GC together to perform 2P-SFE, which is essentially a general form of computation model for 2P-SFE to use SGX. Unlike previous work (smcsgx-other, ), we also share our experience of using Intel SDK with SGX-enabled hardware to develop real-world SFE applications.

Program Partitions

When developing programs for use in the SGX environment, it is particularly important to understand the security considerations of code and data use. The first step is to partition the program into two parts. The trusted partition of the program is kept within the enclave, while the remainder is developed outside of the enclave. This program partitioning is required to minimize the application’s trusted computing base and to save enclave memory. In our experience, the enclave’s memory is fixed by a BIOS setting.141414In our environment, enclave memory was limited to 128 MB. This represents a substantially different programming paradigm from what is required in other SGX-like environments such as the OpenSGX (jain2016opensgx, ) emulator, where programs of any size are assumed able to fit entirely within the enclave environment.

All of our SGX test programs are executed inside of the evaluator’s enclave. All other components, such as code to handle sockets and message processing, are kept outside the enclave. In total, $10,172$ SLOC151515Source Lines of Code (SLOC) generated using David A. Wheeler’s ‘SLOCCount.’ were written between the sender and evaluator enclaves and their accompanying untrusted applications.

Enclave Restrictions

Unlike OpenSGX, where enclave implementations can take advantage of existing libraries, real enclaves not only require library code to be statically linked, but also use trusted libraries. Static linking guarantees each enclave is self-con-tained and needs no extra libraries to be installed to where it is deployed. The trusted libraries created by Intel for enclave programs are crafted to avoid illegal161616We borrow this verbiage from the official Intel SGX documentation. instructions (e.g., fprintf) that will crash enclave programs at runtime. Certain functions (e.g., strcpy) are excluded, though variants providing similar functionality (e.g., strncpy) are often available. Functions that would otherwise access data outside the enclave (e.g., fopen) are also excluded.

The Intel SGX SDK provides trusted C and C++ libraries, as well as other trusted libraries (e.g., for SGX runtimes and cryptographic operations). We follow these restrictions, primarily using a subset of C functions and some basic C++ built-in data structures (e.g., vector). When needed, we use the SGX SDK trusted libraries for API replacements or alternate functions. For example, we use sgx_read_rand, which accesses the hardware random number generator directly, instead of rand. Similarly, we rely on the trusted libraries’ cryptographic APIs instead of OpenSSL/GnuTLS.

SGX/SDK Restrictions

The SGX remote attestation protocol relies on Intel’s Enhanced Privacy ID (EPID) (Anati13, ) technology to verify that the remote enclave is running on an Intel-authenticated, SGX-enabled CPU. To use EPID, a signed certificate must first be obtained from a recognized certificate authority and registered with Intel Development Services. For the purposes of this work, we do not purchase a certificate for registration with Intel and do not implement the EPID part of remote attestation. For our experiments, we instead enable the debug flag when building our SGX applications to skip EPID. After skipping EPID, the sender in our setup verifies the measurement of the evaluator’s enclave by checking the signed value contained in the SGX quote (from the attestation) against the known “good” quote of the enclave.

We encountered instances where we received errors from SGX when attempting to create and read data from large enclaves. Unlike normal programs, enclaves require explicit settings for both stack and heap size. Both also need to be 4K aligned (a normal page size). For memory-hungry enclaves, maximum stack and/or heap sizes must be increased in the enclave configuration file.171717The default maximum heap size (or total memory available for dynamic allocation) of an enclave is 1 MB. Any further allocation would either trigger an out-of-memory error if the application is in an ECall, or crash the enclave and application.

Garbled Circuit Implementation

We used the Frigate semi-honest garbled circuit compiler and semi-honest protocol implementation provided by Mood et al. (Mood2016, ). This implementation is a hand-tuned version of the garbled circuit system by Kreuter et al. (Kreuter2012, ); it uses the point-and-permute (pointandpermute, ), garbled row reduction (Pinkas2009, ), and free XOR (KS08b, ) optimizations, amongst many others, to improve computational efficiency and reduce network bandwidth.

8. Experiments

We used three common programs in the SFE literature to evaluate the performance of our implementation. We compared our hybrid SFE-SGX protocol to naïve SGX-enabled SFE (function evaluation in the enclave without side-channel protections), SGX-enabled SFE (with side-channel protections), and standard GC-based SFE.

We tested our implementation on two HP Envy360 laptops with Intel quad core i7-6500U CPUs at 2.50GHz with a 64KB L1 cache, 512KB L2 cache, 4MB L3 cache and 8 GB RAM. Both machines were connected on a VLAN to the same switch via Gigabit Ethernet.

8.1. Test Programs

The two programs used for evaluation of our hybrid SFE-SGX protocol were introduced in Section 5, being Database and Dijkstra’s shortest-path. Additionally, we use the Millionaires Problem for evaluation of our naïve SGX-enabled SFE and SGX-enabled SFE protocols.181818We use the Millionaires Problem only to illustrate the differences in performance of our naïve SGX-enabled SFE/SGX-enabled SFE protocols and pure GC. We do not implement a hybrid version, but not due to its incompatibility with hybrid computation. We now present configurations of each test program, with additional detail for hybrid versions of Database and Dijkstra.191919In Section 5, we provided intuition for extending the hybrid versions of Database and Dijkstra into further rounds. That discussion was meant primarily to demonstrate that SFE could be achieved for functions requiring more than two rounds. We keep our evaluation versions of these applications at two rounds, as this is sufficient to show the overhead of transitioning between SGX and GC evaluation.

Database

The database holds 64-bit entries. We experiment using both the tree-based ORAM (described in Section 6) and a simple linear search for comparison (marked as tree and linear in Table 1). For example, Database500x2500 executes 2,500 select202020The time-complexity for set and select queries is the same in this setup, though it requires the addition of an extra 64 bits of input per set. queries on 500 entries. This program demonstrates the time it would take to use a database in a larger application with our protocols. As many programs set and modify entries of the database multiple times in the same run, we have more queries than the size of the database in our tests to explore the efficiency as the query size increases.

For our tests, we establish 5% of the queries to be highly-sensitive and only ever entered into the garbled circuit in even rounds.

Dijkstra

The graph contains $n$ nodes, each with 4 edges. Edge weights are 32 bits. For example, Dijkstra20 considers 20 nodes.

To test this setup, we define the number of (1) nodes in the less sensitive portion of the graph, (2) nodes in the more sensitive portion of the graph, and (3) entrances and exits from the more sensitive portion of the graph. Depending on the start and end points, a route may or may not need to traverse the sensitive portion of the graph. Even if the route does not, we evaluate the circuit to avoid leaking information about the path computed in the enclave.

Test cases are labeled according to the number of nodes in the less sensitive graph. We run the following tests: for the 20-node less sensitive graph, we consider 12-entrances or exits to the sensitive graph and a 20-node sensitive graph. We also run similar tests with the following configurations: 50 (12, 20), 100 (22, 25), 200 (32, 50), 250 (42, 100), 250 (42, 100), 1000 (52, 150), and 10000 (62, 250).

Millionaires

Inputs are two $n$-bit unsigned integers. Output is a single bit, informing each party whose input is larger. For example, Millionaires1024 takes 1024 bits of input from each party.

8.2. Results

Table 1 presents our results, which we summarize below.

Hybrid SFE-SGX vs. GC-based SFE

By only requiring part of the computation to use a garbled circuit, we can increase performance by up to 38x versus pure GC-based SFE in the case of Dijkstra with 1000 nodes. The Database application also demonstrated noticeable improvements, being 18x faster in the 500x2500 case.

Although the hybrid SFE-SGX protocol requires more rounds of computation by virtue of the splitting between even (GC) and odd (SGX) rounds, it achieves less communication overhead than pure GC-based SFE. In odd rounds, the amount of data exchange is much smaller, with there being no oblivious transfer or relaying back of lengthy garbled outputs. The enclave owner may communicate with its enclave at little or no cost, while the other party may communicate with the enclave over the secure channel. This exchange handled in the odd rounds lets us reduce the size of the garbled circuit transmitted in even rounds.

The increase in performance is also dependent upon the size of the computation, determined by each user’s requirements for their data. We expect the improvement would be even more substantial for Dijkstra10000 and larger database cases which were not run.

Hybrid SFE-SGX vs. SGX-enabled SFE

Our hybrid SFE-SGX protocol combines garbled circuits with SGX-enabled SFE, which includes side-channel protections. All else being the same, use of a garbled circuit results in a performance reduction vs. SGX-enabled SFE by up to 150x in the worst case, Dijkstra with 1000 nodes.

SGX-enabled SFE vs. GC-based SFE

Our SGX-enabled SFE protocol is up to 5736x faster than a pure GC execution of Dijkstra1000. In the worst case, the SGX-enabled SFE program is only 6x faster; this is for the smallest experiment, a Millionaires program with 1024 bits of input. In larger programs, our results show drastic improvements compared to the garbled circuit implementation.

SGX-enabled SFE vs Naïve SGX-enabled SFE

Our results show, unsurprisingly, that without memory protections, the naïve SGX-enabled SFE protocol outperforms the SGX-enabled SFE protocol for both Dijkstra and Database, due to the necessity of hiding the memory access pattern in SGX-enabled SFE, by anywhere from 1.04x (for Dijkstra50) to 630x (for Database5000x25000 with Tree ORAM). The runtime for Millionaires is almost the same for both protocols.

ORAM vs Linear Search

Our results show that the overhead of the tree ORAM we created is not competitive with a simple linear search for the program sizes we were able to test; this is somewhat surprising given the difference in the fraction of the database that must be searched. The speed of the tree-based ORAM was reduced (from the typical $O(polylog(n))$ complexity for ORAM schemes) for several reasons, including increased time to delete each node from the tree, and time to mix the node data after it has been removed from the tree ($O(n^{2})$-time complexity). Thus the linear search is faster for an array database due to a number of factors including the overhead of the ORAM, branch prediction, and caching.

9. Related Work

SFE Computation on secure data has long been a goal of the theory and systems communities. Mechanisms such as Yao’s garbled circuit protocol (Yao1982, ) provided proof that arbitrary secure computation was possible, but proved too inefficient for practical use. More than two decades later, Fairplay (Malkhi2004, ) provided the first practically efficient implementation of this construction. Since then, a variety of GC-based SFE protocols have been developed in the semi-honest (Lindell2000, ; Kruger2006, ; Huang2011, ), covert (Miyaji2010, ; Damgard2010, ; Aumann2010, ) and malicious  (Lindell2011, ; Kreuter2012, ; sS13, ) adversarial models. Combined with other efforts to reduce bandwidth (Kamara2012, ; CMTB2013, ) and circuit size (BHKR2013, ; KMSB13, ), execution times of applications using garbled circuits for secure computation have dropped by over five orders of magnitude in the last decade. A range of privacy-preserving versions of applications have thus been created, including databases (Crescenzo14, ), navigation (CMTB2013, ; WZPM16, ), biometrics (Carter2015, ; BCF14, ), and genomics (Huang2011, ). However, these applications still introduce substantial computational overhead. Bahmani et. al (smcsgx-other, ) share our goal of using SGX to achieve secure computation but leave the entire computation to the enclave. Ohrimenko et. al (oblivML, ) similarly rely entirely on SGX for multi-party machine learning. We realize the limitations of such a naïve usage of SGX and instead propose partition-relative SFE that combines SGX with garbled circuits for stronger assurances.

SGX Most SGX solutions are in favor of putting the whole application or libOS into an enclave, including Haven (haven, ), SCONE (scone, ), Graphene-SGX (graphene-sgx, ), and Ryoan (ryoan, ), putting full trust into SGX and holding a large TCB inside the enclave. While Intel SGX SDK and Panoply (panoply, ) mandate program partitioning to minimize the TCB, the assumption is the security guarantee of enclaves would not be compromised. A number of attacks have been demonstrated against SGX. AsyncShock (asyncshock, ) exploits synchronization bugs in enclaves using a pre-release version of the Intel SGX SDK. Controlled-channel attacks (xu2015controlled, ) use memory access patterns to exfiltrate sensitive information from secure enclaves. Cache-based side-channel attacks (malwaregx, ; brasser2017software, ) are also shown possible. Other side-channel vulnerabilities (microwalk, ) are also found within the Integrated Performance Primitives (IPP) cryptographic library used by Intel SGX SDK. Micro-architecture attacks have also proven to work on enclaves; these include Meltdown (meltdown, ) and Spectre (spectre, ). Foreshadow (foreshadow, ) attacks extract the attestation key from enclaves thus breaking SGX remote attestation. All these attacks show that SGX can be compromised. Countermeasures include T-SGX (tsgx, ), SGX-Shield (sgx-shield, ), ROTE (rote, ), Sanctum (sanctum, ), etc., ranging from software enhancement to hardware changes. While these defenses are useful to secure SGX applications, our hybrid approach allows SGX to be compromised by leveraging SFE to secure the most sensitive computation.

Others Employing the SGX enclave to securely perform some or all of the evaluation of a function $f$ echoes secure outsourcing. Chaum and Pedersen first proposed the idea of outsourcing using “wallets with observers” (walletsWithObservers, ). Hohenberger and Lysyanskaya introduced the untrusted but much more computationally powerful worker (howtoOutsource, ). Follow-on works founded the idea of a verifiable, outsourceable computation scheme (gennaroUntrustedWorkers, ) and further improved on this idea (zaatar, ; pinocchio, ; geppetto, ). Tramèr et al. (sealedglass, ) previously modeled the enclave as a black-box, albeit in a weaker sense, by keeping only critical functionalities secret from the host. Town Crier (towncrier, ) also treats the enclave as a black-box, trusted for confidentiality and integrity. From a theoretical standpoint, our notion of partition-relative SFE is closely related to the study of non-simultaneous SFE initiated by Halevi, Lindell, and Pinkas (halevi2011, ). Their result justifies our assertion that the notion of partition-relative SFE is the strongest-possible security objective in our setting.

10. Conclusion

Secure function evaluation (SFE) allows mutually distrusting parties to compute the result of a function without leaking anything to others but suffers from large runtime overhead. Intel SGX provides a natural environment for secure computation, but side-channel and micro-architecture attacks can leak data from enclaves. We propose a hybrid approach to combine SFE and SGX, by formalizing what it means to partition the computation of a function $f$ into a piece evaluated with SGX and another piece evaluated using SFE (garbled circuits). We defined secure evaluation of a function relative to such a partitioning of that function and proved our scheme achieves this notion. Our comprehensive evaluation of two case studies shows that we achieve a 38x speedup over traditional garbled circuit methods with our SGX-enabled SFE and points to a way to ensure safer and faster secure computation.

Acknowledgements.

This work is supported in part by the Sponsor US National Science Foundation https://www.nsf.gov/ under grant numbers Grant #CNS-1540217, Grant #CNS-1564444, and Grant #CNS-1642973. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation.

Appendix A Appendix

Let $[1..\ell]$ denote the set of integers from 1 to $\ell$. If $\mathbf{a}$ is a vector over strings, let $\scriptsize{\mathsf{len}}(\mathbf{a})[i]=|\mathbf{a}[i]|$ for every $i\in[1..|\mathbf{a}|]$. A function $\epsilon(\cdot)$ is negligible if for every positive polynomial $p(\cdot)$, there exists a $k_{0}$ such that for every $k\geq k_{0}$, it holds that $\epsilon(k)<1/p(k)$. Both an adversary and a simulator are randomized algorithms.

A.1. Protocols

We define syntax and execution semantics for two-party protocols in which one or both players have access to an explicitly defined oracle. An oracle-relative, two-party protocol is a triple $\mathrm{\Pi}=(\scriptsize{\mathsf{Init}},\scriptsize{\mathsf{Proc}},\mathcal{O})$ where $\scriptsize{\mathsf{Init}}$ and $\scriptsize{\mathsf{Proc}}$ are randomized algorithms and $\mathcal{O}$ is an oracle. Let 0 and 1 denote the (non-oracle) protocol parties.

Fix security parameter $k\geq 0$. Algorithm $\scriptsize{\mathsf{Init}}$ takes as input $1^{k}$ and outputs a triple of strings $(L_{0},L_{1},L_{\mathcal{O}})$ called the long-term inputs of parties 0, 1 and oracle $\mathcal{O}$ respectively. This is written (L_{0},L_{1},L_{\mathcal{O}}){\>{\leftarrow{\raisebox{0.75pt}{\scriptscriptstyle$}}}\>}\scriptsize{\mathsf{Init}}(1^{k}).

Algorithm $\scriptsize{\mathsf{Proc}}$ takes as input the identity $i$ of a message recipient, their long-term input $L_{i}$, their current state $\mathit{st}_{i}$, and the message $m$ being delivered. It outputs a message $m^{\prime}$ (to be sent to $1-i$), the coins $w_{i}$ used in the computation, the updated state $\mathit{st}_{i}^{\prime}$, and an indication of whether to halt $(\bot)$ or continue ($\top$). The algorithm is given oracle access to $\mathcal{O}(L_{\mathcal{O}},\cdot)$. On input $(L_{\mathcal{O}},x)$, the oracle performs some operation (specified by the protocol) on the string $x$ and its current state, updates its state, and returns a string to the player. This is written (m^{\prime},w_{i},\mathit{st}_{i}^{\prime},\delta){\>{\leftarrow{\raisebox{0.75pt}{\scriptscriptstyle$}}}\>}\scriptsize{\mathsf{Proc}}^{\mathcal{O}}_{i}(L_{i},\mathit{st}_{i},m) where $\delta\in\{\bot,\top\}$.

Protocols are executed with respect to the players’ private inputs. Executing the protocol with input $(a_{0},a_{1})$, where $a_{0}$ and $a_{1}$ are strings (or vectors over strings) means to initialize $\mathit{st}_{i}=(1^{k},a_{i})$ for $i\in\{0,1\}$, and facilitate the exchange of messages between 0 and 1 until both halt. More formally, the protocol consists of a sequence of calls to $\scriptsize{\mathsf{Proc}}_{i}^{\mathcal{O}}(\cdot,\cdot,\cdot)$ alternating between $i=0$ and $i=1$. The protocol specifies which player starts. This is denoted

[TABLE]

The transcript consists of the inputs $1^{k}$, $a_{0}$, $a_{1}$, and $\mathit{st}$, the outputs of each call to $\scriptsize{\mathsf{Proc}}$, and all of the oracle queries made by $\scriptsize{\mathsf{Proc}}$, along with their responses.

Let $\omega=\scriptsize{\mathsf{View}}_{\mathrm{\Pi},k}^{i}(\pi)$ denote the view of player $i$ for the particular execution of $\mathrm{\Pi}$ transcribed by $\pi$. In particular, string $\omega$ encodes $i$’s initial state, and the portions of $\pi$ that correspond to an execution $\scriptsize{\mathsf{Proc}}_{i}^{\mathcal{O}}(\cdot,\cdot,\cdot)$, i.e. those corresponding to party $i$.

Composing oracle protocols

Let $(\mathrm{\Pi}_{1},\ldots,\mathrm{\Pi}_{\ell})$ be a sequence of protocols. A protocol $\mathrm{\Pi}$ constructed from their composition is defined as follows. The initialization algorithm $\mathrm{\Pi}.\scriptsize{\mathsf{Init}}$ executes each $\mathrm{\Pi}_{j}.\scriptsize{\mathsf{Init}}$ and returns the triple $(\mathbf{L}_{0},\mathbf{L}_{1},\mathbf{L}_{\mathcal{O}})$ where $\mathbf{L}_{0}[j]$ (resp. $\mathbf{L}_{1}[j]$ and $\mathbf{L}_{\mathcal{O}}[j]$) denotes the long-term input of player 0 (resp. player 1 and oracle $\mathrm{\Pi}_{j}.\mathcal{O}$) in protocol $\mathrm{\Pi}_{j}$. Executing $\mathrm{\Pi}$ on inputs $(1^{k},a_{0},a_{1},\mathit{st})$, where $a_{0}$ and $a_{1}$ are strings (or vectors over strings) means to iteratively execute $\mathrm{\Pi}_{j}$ for each $j$ from 1 to $\ell$ on inputs specified by the protocol, except that $\mathit{st}$ is the initial state of oracle $\mathrm{\Pi}_{1}.\mathcal{O}$. During the execution of $\mathrm{\Pi}_{j}$, the algorithm $\mathrm{\Pi}_{j}.\scriptsize{\mathsf{Proc}}$ is given oracle access to $\mathrm{\Pi}_{j}.\mathcal{O}(\mathbf{L}_{\mathcal{O}}[j],\cdot)$. The output is the tuple $(y_{0},y_{1},\pi,\mathit{st}^{\prime})$ where $y_{0}$ and $y_{1}$ are the final states of players 0 and 1 respectively after executing $\mathrm{\Pi}_{\ell}$, string $\pi=(\pi_{1},\ldots,\pi_{\ell})$, where $\pi_{j}$ is the transcript of the $j$-th protocol, and $\mathit{st}^{\prime}$ is the final state of oracle $\mathrm{\Pi}_{\ell}.\mathcal{O}$. Finally, let $\scriptsize{\mathsf{View}}_{\mathrm{\Pi},k}^{i}(\pi)=(\scriptsize{\mathsf{View}}_{\mathrm{\Pi}_{j},k}^{i}(\pi_{j}))_{j=1}^{\ell}$.

A.2. Garbling schemes

A garbling scheme $\mathcal{G}=(\scriptsize{\mathsf{Gb}},\scriptsize{\mathsf{En}},\scriptsize{\mathsf{Ev}},\scriptsize{\mathsf{De}})$ is projective if $e$ (the second output of the garbling algorithm) is a sequence $(X^{0}_{1},X^{1}_{1},\ldots,X^{0}_{n},X^{1}_{n})$ of strings called tokens such that $\scriptsize{\mathsf{En}}(e,x)=(X_{1}^{x_{1}},\ldots,X_{n}^{x_{n}})$ where $x=x_{1}\cdots x_{n}$.

Let $\mathcal{G}$ be a projective garbling scheme, $f:\{0,1\}^{n}\to\{0,1\}^{*}$ be a function, and $(F,e,d)$ be a triple of strings in the range of $\scriptsize{\mathsf{Gb}}(1^{k},f)$. Let $\ell\leq n$ be an integer, and let $r=n-\ell$. Then if $a\in\{0,1\}^{\ell},b\in\{0,1\}^{r}$, and $x=a\,\|\,b$, we define $\scriptsize{\mathsf{EnA}}(e,a)$ and $\scriptsize{\mathsf{EnB}}(e,b)$ so that $\scriptsize{\mathsf{En}}(e,x)=\scriptsize{\mathsf{EnA}}(e,a)\,\|\,\scriptsize{\mathsf{EnB}}(e,b)$. That is, $\scriptsize{\mathsf{EnA}}(e,a)=(X_{1}^{a_{1}},\ldots,X_{\ell}^{a_{\ell}})$ and $\scriptsize{\mathsf{EnB}}(e,b)=(X_{\ell+1}^{b_{1}},\ldots,X_{n}^{b_{r}})$.

PRIV

We specify the simulation-based notion of [9] (instantiated in our setting) in the bottom-left panel of Figure 9. This game captures an adversary’s advantage in distinguishing the output of the garbling algorithm on input $(f,x)$ from the output of the simulator on input $(f,f(x))$. A garbling scheme is “secure” if for every reasonable adversary, there exists a simulator such that this advantage is “small”. Intuitively, this captures the idea that if a garbling scheme is secure, then possession of the garbled function, garbled input, and the final output leaks only a negligible amount information about the input $x$ to the circuit evaluator. We define the advantage of $\mathcal{A}$ in the game with simulator $\mathcal{S}$ at security parameter $k$ as

[TABLE]

We say that $\mathcal{G}$ is private if for every polynomial-time adversary $\mathcal{A}$, there exists a polynomial-time simulator $\mathcal{S}$ such that the function $\mathsf{Adv}^{\mathrm{\scriptsize{priv}}}_{\mathcal{G}}(\mathcal{A},\mathcal{S},k)$ is a negligible function of $k$.

A.3. 1-2 oblivious transfer

A 1-2 transfer protocol is a two-party protocol $\mathrm{\Pi}$ played by $\mathrm{Alice}$ and $\mathrm{Bob}$ with the following correctness condition: when executed with $\mathrm{Bob}$’s private input $b=b_{1}\cdots b_{n}\in\{0,1\}^{n}$ and $\mathrm{Alice}$’s private input of a sequence of tokens $(X^{0}_{1},X^{1}_{1},\ldots,X^{0}_{n},X^{1}_{n})$, it holds that

[TABLE]

and

[TABLE]

where $|X_{j}^{0}|=|X_{j}^{1}|$ for each $j\in[1..n]$.

We define oblivious transfer (OT) in the presence of a semi-honest adversary. Following [9, section 7.1], we formulate the security of OT as an instance of private function evaluation, or PFE. Here Alice has private function $f$ and Bob has a private input $x$ in the domain of $f$. The goal is that Bob learns $f(x)$ without learning anything about $f$ (except $|f|$) and Alice learns noting about $x$ (except $|x|$). In the case of 1-2 OT, the private function corresponds to the map $b\mapsto(X^{b_{1}}_{1},\ldots,X^{b_{n}}_{n})$ (and hence encodes $\mathrm{Alice}$’s tokens) and the private input is $\mathrm{Bob}$’s string $b$. The length of this map is a function of $|(X^{0}_{1},X^{1}_{1},\ldots,X^{0}_{n},X^{1}_{n})|$.

PFE

Security is captured by an experiment defined in the bottom-right of Figure 9 associated to player $i\in\{\mathrm{Alice},\mathrm{Bob}\}$, adversary $\mathcal{A}$, and simulator $\mathcal{S}$. If $i=\mathrm{Alice}$, the goal of the adversary is to distinguish $\mathrm{Alice}$’s view from the output of $\mathcal{S}$, which is given as input the security parameter, the function, and the length of $\mathrm{Bob}$’s private input. If $i=\mathrm{Bob}$, the goal of the adversary is to distinguish player $\mathrm{Bob}$’s view from the output of $\mathcal{S}$, which is given as input the security parameter, the input $x$, the value $f(x)$, and the length of the private function. The advantage of $\mathcal{A}$ in the game instantiated with simulator $\mathcal{S}$ at security parameter $k$ is defined as

[TABLE]

We say that $\mathrm{\Pi}$ is PFE-secure if for each $i\in\{\mathrm{Alice},\mathrm{Bob}\}$ and every polynomial-time adversary $\mathcal{A}$, there exists a polynomial-time simulator $\mathcal{S}$ such that the function $\mathsf{Adv}^{\mathrm{\scriptsize{pfe}}}_{\mathrm{\Pi},i}(\mathcal{A},\mathcal{S},k)$ is a negligible function of $k$.

OT

We say that a 1-2 transfer protocol is oblivious if it is a secure PFE protocol.

A.4. Symmetric encryption

We give the standard concrete security notion for symmetric encryption. A symmetric encryption scheme $\mathrm{\Gamma}$ is a triple of randomized algorithms $(\mathcal{K},\mathcal{E},\mathcal{D})$. Algorithm $\mathcal{K}$ outputs a string $K$ called the key. Algorithm $\mathcal{E}$ takes as input the key $K$, a message $M\in\{0,1\}^{*}$, and outputs a ciphertext $C\in\{0,1\}^{*}$. Algorithm $\mathcal{D}$ takes as input the key $K$, a ciphertext $C$, and deterministically outputs the message $M$. Correctness demands that for key $K$ and every message $M$ (in the implicit message space), it holds that {\Pr\left[\,{C{\>{\leftarrow{\raisebox{0.75pt}{\scriptscriptstyle$}}}\>}\mathcal{E}_{K}(M):\mathcal{D}_{K}(C)=M}\,\right]}=1.

IND$

We associate to an adversary and encryption scheme an experiment in which the adversary is given an oracle, which it may query any number of times. After interacting with its oracle, it outputs a bit. We define the advantage of an adversary $\mathcal{A}$ in attacking $\mathrm{\Gamma}$ as

[TABLE]

where oracle \(\cdot)$ outputs a random bit string of appropriate length, i.e. as long as a ciphertext corresponding to the query would be.

A.5. Proof of Theorem 5.1

It suffices to prove the following claim: Let $f_{j}=\mathcal{P}.f_{j}$ for every $j\in[\ell]$ and let $i\in\{\mathrm{Alice},\mathrm{Bob}\}$. Let $\mathcal{A}$ be an adversary and $\mathcal{S}_{\mathrm{o}}$ and $\mathcal{S}_{\mathrm{e}}$ be simulators. There exist adversaries $\mathcal{B}_{\mathrm{o}}$ and $\mathcal{B}_{\mathrm{e}}$ and a simulator $\mathcal{S}$ such that

[TABLE]

Moreover, if $\mathcal{A}$, $\mathcal{S}_{\mathrm{o}}$, and $\mathcal{S}_{\mathrm{e}}$ are polynomial-time, then so are $\mathcal{B}_{\mathrm{o}}$, $\mathcal{B}_{\mathrm{e}}$, and $\mathcal{S}$.

We first construct the adversary $\mathcal{B}_{\mathrm{o}}$ from $\mathcal{A}$ and the simulator $\mathcal{S}$ from $\mathcal{S}_{\mathrm{o}}$ and $\mathcal{S}_{\mathrm{e}}$. Let $j\in[1..\ell]$ be odd. We sketch the construction of adversary $\mathcal{B}_{\mathrm{o}}$ on input for odd-round function $f_{j}$. Let $\mathcal{B}_{\mathrm{o}}$ be the adversary specified in Figure 10. In its $\scriptsize{\mathsf{pick}}$ phase, adversary $\mathcal{B}_{\mathrm{o}}$ is given as input $(1^{k},f_{j})$. It first executes $\mathcal{A}$ in its $\scriptsize{\mathsf{pick}}$ phase on input of the security parameter and $f$. When $\mathcal{A}$ outputs $(a,b,\sigma)$ where $(a,b)\in\mathrm{dom}f$ and $\sigma\in\{0,1\}^{*}$, adversary $\mathcal{B}_{\mathrm{o}}$ splits $a$ and $b$ according to $\mathcal{P}$, then evaluates $f$ according to $\mathcal{P}$ up to the $(j-1)$-th round. It returns the appropriate inputs to the $j$-th round as its choice and specifies $(\sigma,j)$ as its state to carry-over to the next phase of the game. Let $(u,v,\mathit{st},(\sigma,j))$ denote $\mathcal{B}_{\mathrm{o}}$’s output.

Let $d$ denote the challenge bit in the SFE-ODD game played by $\mathcal{B}_{\mathrm{o}}$. In its $\scriptsize{\mathsf{guess}}$ phase, adversary $\mathcal{B}_{\mathrm{o}}$ gets as input a string $\omega$, which is player $i$’s view of $\mathrm{\Pi}_{\mathrm{o}}[f_{j}]$ executed on input $(1^{k},u,v,\mathit{st})$ if $d=1$, and the output of the simulator (given player $i$’s inputs) otherwise. Adversary $\mathcal{B}_{\mathrm{o}}$ flips a coin $d^{\prime}$. If it comes up heads, then it emulates $\mathcal{A}$ in the SFE game when its challenge bit is 1; otherwise it emulates $\mathcal{A}$ in the SFE game instantiated with a simulator $\mathcal{S}$, which is specified by $\mathcal{B}_{\mathrm{o}}$. In particular, player $i$’s view of odd-round protocol executions is simulated by $\mathcal{S}_{\mathrm{o}}$ and even-round protocol executions are simulated by $\mathcal{S}_{\mathrm{e}}$.

Finally, adversary $\mathcal{B}_{\mathrm{o}}$ substitutes the (possibly-simulated) view of the $j$-th round execution with its own input $\omega$. It then executes $\mathcal{A}$’s $\scriptsize{\mathsf{guess}}$ phase on input of the emulated view and $\mathcal{A}$’s carry-over state $\sigma$. When $\mathcal{A}$ outputs its guess $c^{\prime}$, adversary $\mathcal{B}_{\mathrm{out}}$ outputs $c^{\prime}$.

If $d=1$ and $d^{\prime}=1$, then the reduction perfectly emulates $\mathcal{A}$ in the SFE game when its challenge bit is 1; on the other hand, if $d=0$ and $d^{\prime}=0$, then the reduction perfectly emulates $\mathcal{A}$ instantiated with $\mathcal{S}$ with the challenge bit being 0. Let $X_{j}=\mathsf{Exp}^{\mathrm{\scriptsize{\textup{sfe\mbox{-}odd}}}}_{\mathrm{\Pi}_{\mathrm{o}}[f_{j}],f_{j},i}(\mathcal{B}_{\mathrm{o}},\mathcal{S}_{\mathrm{o}},k)$. By construction, we have that

[TABLE]

where $c$ denotes the challenge bit in $\mathcal{A}$’s game. Similarly, we have

[TABLE]

Hence, and since $d$ and $d^{\prime}$ are independent,

[TABLE]

It follows that

[TABLE]

Now let $j\in[1..\ell]$ be even. Adversary $\mathcal{B}_{\mathrm{e}}$ is constructed from $\mathcal{A}$ in a similar manner. (We skip the details for brevity.) It emulates the same simulator $\mathcal{S}$ emulated by $\mathcal{B}_{\mathrm{o}}$. An identical argument yields

[TABLE]

Summing over all $j\in[1..\ell]$ yields the claim.

Due to space constraints, we refer the reader to our associated technical report (anonymized for submission) for full proofs of Theorems 5.2 and 5.3.

A.6. Proof of Theorem 5.2

It suffices to prove the following: Let $\mathcal{A}$ be an adversary and $\mathcal{S}_{\mathcal{G}}$ and $\mathcal{S}_{\mathrm{ot}}$ be simulators. For each $i\in\{\mathrm{Alice},\mathrm{Bob}\}$, there exist a pair of adversaries $\mathcal{B}_{\mathcal{G}}$ and $\mathcal{B}_{\mathrm{ot}}$ and a simulator $\mathcal{S}$ such that

[TABLE]

Moreover, if $\mathcal{A}$, $\mathcal{S}_{\mathcal{G}}$, and $\mathcal{S}_{\mathrm{ot}}$ are polynomial-time, then so are $\mathcal{B}_{\mathcal{G}}$, $\mathcal{B}_{\mathrm{ot}}$, and $\mathcal{S}$.

Our argument follows closely the proof of [9, thm 14], except that our goal is SFE. We begin with the case where $i=\mathrm{Alice}$. It suffices to specify $\mathcal{B}_{\mathrm{ot}}$ and simulator $\mathcal{S}$ such that

[TABLE]

During its $\scriptsize{\mathsf{pick}}$ phase, adversary $\mathcal{B}_{\mathrm{ot}}$ executes $\mathcal{A}$ on its $\scriptsize{\mathsf{pick}}$ phase, getting $(a,b,\sigma)$ in return. It then samples random coins $w$ and executes the garbling algorithm, specifying $w$ as the coins of execution. Let $(F,e,d)$ denote the output. Define $g$ as the map $b\mapsto(X^{b_{r}}_{\ell+1},\ldots,X^{b_{r}}_{n})$ where $\ell=|a|$, $r=|b|$, $n=\ell+r$, and $e=(X^{0}_{1},X^{1}_{1},\ldots,X^{0}_{n},X^{1}_{n})$. Finally, adversary $\mathcal{B}_{\mathrm{ot}}$ returns $(g,b,\sigma)$. Let $\omega$ denote the (possibly-simulated) view given to $\mathcal{B}_{\mathrm{ot}}$ during its $\scriptsize{\mathsf{guess}}$ phase. It constructs $\mathrm{Alice}$’s view from $w$, $\omega$, $Y=\scriptsize{\mathsf{Ev}}(F,\scriptsize{\mathsf{EnA}}(e,a)\,\|\,\scriptsize{\mathsf{EnB}}(e,b))$, and her initial state and executes $\mathcal{A}$ in its $\scriptsize{\mathsf{guess}}$ phase on the constructed view and its carry-over state $\sigma$. Finally, return whatever $\mathcal{A}$ returns. In doing so, adversary $\mathcal{B}_{\mathrm{ot}}$ perfectly emulates $\mathcal{A}$ in its game instantiated with a simulator $\mathcal{S}$ specified by the reduction and constructed from $\mathcal{S}_{\mathrm{ot}}$.

We now turn to the case where $i=\mathrm{Bob}$. First, we construct the adversary $\mathcal{B}_{\mathrm{ot}}$ from $\mathcal{S}_{\mathrm{ot}}$ and $\mathcal{A}$ as specified above. We construct $\mathcal{B}_{\mathcal{G}}$ as follows. During its $\scriptsize{\mathsf{pick}}$ phase, adversary $\mathcal{B}_{\mathcal{G}}$ executes $\mathcal{A}$ in its $\scriptsize{\mathsf{pick}}$ phase on input $(1^{k},f)$, getting $(a,b,\sigma)$ in return. Adversary $\mathcal{B}_{\mathcal{G}}$ then returns $(f,(a,b),\sigma)$. On input $(\scriptsize{\mathsf{guess}},F,X,d,\sigma)$, adversary $\mathcal{B}_{\mathcal{G}}$ does as follows. Since $\mathcal{G}$ is projective, there exists a sequence of tokens $e=(Z_{1}^{0},Z_{1}^{1},\ldots,Z_{n}^{0},Z_{n}^{1})$ (unknown to $\mathcal{B}_{\mathcal{G}}$) such that $X=A\,\|\,B$ where $A=\scriptsize{\mathsf{EnA}}(e,a)$ and $B=\scriptsize{\mathsf{EnB}}(e,b)$. Let $r=|b|$ and write $B$ as the sub-sequence $(B_{1},\ldots,B_{r})$ of $e$. For each $i\in[1..r]$, let $X_{i}^{b_{i}}=B_{i}$ and let $X_{i}^{1-b_{i}}$ be a random token. Let $e^{\prime}=(X^{0}_{1},X^{1}_{1},\ldots,X^{0}_{n},X^{1}_{n})$. Execute

[TABLE]

and let $\omega^{\prime}\leftarrow\scriptsize{\mathsf{View}}^{\mathrm{Bob}}_{\mathrm{\Pi}_{\mathrm{ot}},k}(\pi)$. Adversary $\mathcal{B}_{\mathcal{G}}$ constructs $\mathrm{Bob}$’s view from $F$, $A$, $\omega^{\prime}$, and $\mathrm{Bob}$’s initial state, then executes $\mathcal{A}$ in its $\scriptsize{\mathsf{guess}}$ stage with this view and its carry-over state $\sigma$. Finally, it outputs whatever $\mathcal{A}$ outputs.

Lastly, we specify the simulator $\mathcal{S}$ as follows. On input $(1^{k},\scriptsize{\mathsf{len}}(\mathbf{a}),\mathbf{b},\mathbf{y})$ where $\mathbf{a}[1]=a$, $\mathbf{b}[1]=b$, and $\mathbf{y}[1]=f(a,b)$, the simulator executes (F,X,d){\>{\leftarrow{\raisebox{0.75pt}{\scriptscriptstyle$}}}\>}\mathcal{S}_{\mathcal{G}}(1^{k},f,f(a,b)) and \omega^{\prime}{\>{\leftarrow{\raisebox{0.75pt}{\scriptscriptstyle$}}}\>}\mathcal{S}_{\mathrm{ot}}(1^{k},|g|,b,B), where $g$ is the map defined by $b\mapsto(X_{\ell+1}^{b_{1}},\ldots,X_{n}^{b_{r}})$ for some set of tokens $(X^{0}_{1},X^{1}_{1},\ldots,X^{0}_{n},X^{1}_{n})$ output by the garbling algorithm. (These lengths are known since the simulator knows the function $f$.). It constructs $\mathrm{Bob}$’s view from $F$, $X$, $\omega^{\prime}$, and his initial state and returns it.

Since each of $\mathcal{B}_{\mathrm{ot}}$ and $\mathcal{B}_{\mathcal{G}}$ perfectly emulate $\mathcal{A}$ in its game instantiated with $\mathcal{S}$, the claim holds.

A.7. Proof of Theorem 5.3

The theorem statement in the body is somewhat informal, since we formalize IND$-security concretely instead of asymptotically. (In particular, we do not associate a security parameter to the IND$ game.) Nevertheless, the claim we prove here sufficient to establish the theorem for the natural asymptotic definition.

We prove the following claim: Let $\mathcal{A}$ be an adversary. For each $i\in\{\mathrm{Alice},\mathrm{Bob}\}$, there exists an adversary $\mathcal{B}$ and a simulator $\mathcal{S}$ such that for every $k$, it holds that

[TABLE]

Moreover, adversary $\mathcal{B}$ has about the same runtime as $\mathcal{A}$ and $\mathcal{S}$ runs in constant time.

We start again with $i=\mathrm{Bob}$. $\mathrm{Bob}$’s view consists only of its initial state and its coins for encrypting its message to $\mathrm{Alice}$. Clearly there exists a simulator $\mathcal{S}$ such that $\mathsf{Adv}^{\mathrm{\scriptsize{\textup{sfe\mbox{-}odd}}}}_{\mathrm{\Pi},f,i}(\mathcal{A},\mathcal{S},k)=0$.

Now consider $\mathrm{Alice}$’s view. Fix a positive integer $k$. Adversary $\mathcal{B}$ first executes (a,b,\mathit{st},\sigma){\>{\leftarrow{\raisebox{0.75pt}{\scriptscriptstyle$}}}\>}\mathcal{A}(\scriptsize{\mathsf{pick}},1^{k},f) and asks $b$ of its oracle, getting $x$ in response. It then constructs $\mathrm{Alice}$’s view $\omega$ from her initial state, $x$, and $y$ where $(y,\mathit{st}^{\prime})=f(a,b,\mathit{st})$. It then executes c^{\prime}{\>{\leftarrow{\raisebox{0.75pt}{\scriptscriptstyle$}}}\>}\mathcal{A}(\scriptsize{\mathsf{guess}},\omega,\sigma) and returns $c^{\prime}$.

If $\mathcal{B}$ has an encryption oracle, then it perfectly emulates $\mathcal{A}$ in its game with $c=1$ as the challenge bit. If $\mathcal{B}$ is a \(\cdot)$oracle, then it perfectly emulates$\mathcal{A}$in its game with$c=0$and a simulator$\mathcal{S}$ specified by the reduction. Hence,

[TABLE]

and

[TABLE]

where $i=\mathrm{Alice}$. Finally,

[TABLE]