Secure Multiparty Computation from SGX [chapter]

Raad Bahmani, Manuel Barbosa, Ferdinand Brasser, Bernardo Portela, Ahmad-Reza Sadeghi, Guillaume Scerri, Bogdan Warinschi
2017 Lecture Notes in Computer Science  
Isolated Execution Environments (IEE) offered by novel commodity hardware such as Intel's SGX deployed in Skylake processors permit executing software in a protected environment that shields it from a malicious operating system; it also permits a remote user to obtain strong interactive attestation guarantees on both the code running in an IEE and its input/output behaviour. In this paper we show how IEEs provide a new path to constructing general secure multiparty computation (MPC) protocols.
more » ... ur protocol is intuitive and elegant: it uses code within an IEE to play the role of a trusted third party (TTP), and the attestation guarantees of SGX to bootstrap secure communications between participants and the TTP. In our protocol the load of communications and computations on participants only depends on the size of each party's inputs and outputs and is thus small and independent from the intricacy of the functionality to be computed. The remaining computational load-essentially that of computing the functionality -is moved to an untrusted party running an IEE-enabled machine, an appealing feature for Cloud-based scenarios. However, as often the case even with the simplest cryptographic protocols, we found that there is a large gap between this intuitively appealing solution and a protocol with rigorous security guarantees. We bridge this gap through a comprehensive set of results that include: i. a detailed construction of a protocol for secure computation for arbitrary functionalities; ii. formal security definitions for the security of the overall protocol and that of its components; and iii. a modular security analysis of our protocol that relies on a novel notion of labeled attested computation. We implemented and extensively evaluated our solution on SGX-enabled hardware, providing detailed measurements of our protocol as well as comparisons with software-only MPC solutions. Furthermore, we show the cost induced by using constant-time, i.e., timing side channel resilient, code in our implementation. This work was supported by the European Union's 7th Framework Program (FP7/2007(FP7/ -2013 under grant agreement n. 609611 (PRACTICE). 5 We discuss the issue of side-channels that may disrupt the isolation barrier at the end of the paper. and built-in cryptographic attestation mechanisms guarantee the integrity of the code and its I/O behaviour to a remote user. The functionality outlined above suggests a simple, natural, and effective design for general multiparty computation: load the functionality to be computed into an IEE (which plays the role of a trusted third party) and have users provide inputs and receive outputs via secure channels to the IEE. Attestation ensures that the function and its inputs have not been tampered with and that the users receive, untampered, the outputs of the computation. The resulting protocol is extremely efficient when compared to existing solutions that cannot rely on such hardware assumptions. Indeed, the load of communications and computations on protocol participants is very small and independent of the intricacy of the functionality that is being computed; it depends only on the size of each party's inputs and outputs. The remaining computational load -essentially that of computing the functionality expressed as a transition function in a standard programming language -is moved to an untrusted party running an IEE-enabled machine. This makes the protocol very appealing for Cloud scenarios. The appealing intuition obscures the significant gap between this simple idea and a cryptographic protocol with rigorous security guarantees. There are multiple obstacles to overcome, including: i. the lack of private channels between the users and the remote machine; ii. the need to authenticate/agree on a computation in a setting where communication between parties is inherently asynchronous and only mediated by the IEE; iii. the need to ensure that the "right" parties are engaged in the computation; iv. dealing with the interaction between different parts of the code that coexist within the same IEE, sharing the same memory space, each potentially corresponding to different users; and v. ensuring that the code running inside an IEE does not leak sensitive information to untrusted code running outside. In this paper we bridge this gap through a comprehensive set of results that include: i. a detailed construction of a protocol for MPC computation for arbitrary functionality; ii. formal security definitions for the security of the overall protocol and that of its components; iii. a modular security analysis of our protocol that relies on a novel notion of labelled attested computation; and iv. an open-source implementation of our protocol and a detailed experimental analyis in SGX-enabled hardware. Our results Generic secure multiparty computation. The main result of the paper is a highly efficient protocol for the secure multiparty computation of an arbitrary reactive functionality F . The protocol follows the simple design outlined earlier. We load into an IEE code that first executes (in parallel) key-exchanges with the intended users; the code then executes whatever (reactive) functionality F one would like to implement. In this latter stage, the input/output communication is over secure channels initialized with the keys exchanged earlier. The communication and computational load for a user comprises a standard key exchange, a constant number of public key signature verifications, and the secure transfer of inputs/outputs to/from the functionality using authenticated encryption. This makes the client-side of the protocol suitable for deployment in (modest) mobile devices. Importantly, the computational overhead on the server side is also very small. Finally, our protocol is non-interactive in the sense that each user can perform an initial reusable set-up, and then provide its inputs and receive outputs independently of other protocol participants, which means that it provides a solution for "secure computation on the web" [24] with standard MPC security. We provide a rigorous analysis of security for our protocol in a simulation-based security model where the adversary controls an IEE-enabled remote machine. We model this machine as an incorruptible party, which can be seen as a new hardware assumption. Our execution model allows the adversary to control all the communications between protocol participants and this remote machine, but it does not allow the adversary to corrupt the machine itself. The security assumptions on this type of hardware differ from those considered in [28]: the honest parties never access trusted hardware directly. Access to hardware is always through the attacker, who can manipulate the code submitted by an honest participant. The downside of our approach, in addition to the obvious requirement that one trusts the hardware manufacturer, is that we still require a PKI to authenticate public parameters (namely those of the SGX machine) and we focus on the static corruption model. Our choices also have implications in the composability of our results and, indeed, recent independent work [36] sheds some light on this issue. We expand on this in the related work section. Labeled attested computation. Our protocol relies on ideal functionalities viewed as programs written as transition functions in a programming language compatible with the IEE-enabled machine. We instrument these programs to run inside an IEE and add bootstrapping code that permits protocol participants to establish independent secure channels with the functionality so that they can send inputs and receive outputs from it. The crux of the protocol is to ensure the attestation guarantees which convince the parties that they are involved in the "right" run Game Auth Π,A (1 λ ): List ← [] key ←$ Gen(1 λ ) (m, t) ←$ A Auth (1 λ ) Return Ver(key, m, t) = T ∧ m ∈ List Oracle Auth(m): List ← (m : List) t ← Mac(key, m) Return t Game UF Σ,A (1 λ ): List ← [] (pk, sk) ←$ Gen(1 λ ) (m, σ) ←$ A Sign (1 λ , pk) Return Vrfy(pk, m, σ) = T ∧ m ∈ List Oracle Sign(m): List ← (m : List) σ ← Sign(sk, m) Return σ
doi:10.1007/978-3-319-70972-7_27 fatcat:wunetkom2fbatjfy4ebzadb2d4