Domain-Polymorphic Programming of Privacy-Preserving Applications ∗ Dan Bogdanov Peeter Laud Jaak Randmets Cybernetica AS fdan.bogdanov,peeter.laud,[email protected] April 22, 2014 Abstract Secure Multiparty Computation (SMC) is seen as one of the main enablers for secure out- sourcing of computation. Currently, there are many different SMC techniques (garbled circuits, secret sharing, homomorphic encryption, etc.) and none of them is clearly superior to others in terms of efficiency, security guarantees, ease of implementation, etc. For maximum efficiency, and for obeying the trust policies, a privacy-preserving application may wish to use several dif- ferent SMC techniques for different operations it performs. A straightforward implementation of this application may result in a program that (i) contains a lot of duplicated code, differing only in the used SMC technique; (ii) is difficult to maintain, if policies or SMC implementations change; and (iii) is difficult to reuse in similar applications using different SMC techniques. In this paper, we propose a programming language with associated compilation techniques for simple orchestration of multiple SMC techniques and multiple protection domains. It is a simple imperative language with function calls where the types of data items are annotated with protection domains and where the function declarations may be domain-polymorphic. This allows most of the program code working with private data to be written in a SMC-technique- agnostic manner. It also allows rapid deployment of new SMC techniques and implementations in existing applications. We have implemented the compiler for the language, integrated it with an existing SMC framework, and are currently using it for new privacy-preserving applications. 1 Introduction Secure multiparty computation (SMC) is a cryptographic method for n different parties to evaluate a function (y1; : : : ; yn) = f(x1; : : : ; xn) so that each party Pi provides the input xi and learns the output yi such that no party can learn the inputs or outputs of another party. The first protocols for secure multiparty computation ∗This research was, in part, funded by the Defense Advanced Research Projects Agency (DARPA). The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the U.S. Government. Distribution Statement A (Approved for Public Release, Distribution Unlimited). This research has also been supported by the European Regional Development Fund through the Estonian Center of Excellence in Computer Science, EXCS, and by the Estonian Research Council through grant IUT27-1. 1 were proposed by Yao [34]. The techniques have been developed since then and several practical implementations of programmable secure computation have been created [21, 5, 15, 11]. When developing an application making use of SMC techniques (or other, possibly non-cryptographic secure computation techniques), we may want to use more than one technique simultaneously, and/or we may want to defer the choice of particular SMC techniques to a later stage of develop- ment. The main reason for this is efficiency | different operations may be fastest using different techniques, even when considering the costs of translating between data representations [19]. Con- fidentiality policies may compound this issue, stating that different pieces of data must be treated with techniques providing protection against different kinds of adversaries (passive vs. active; the size of coalitions it's able to form). In this case, we may use faster techniques for data needing less protection. Also, in our quest for speed, we may want to try out and profile different SMC techniques; this should be possible without rewriting the application. We have responded to the wish to simultaneously use multiple SMC techniques by developing a secure computation runtime which is modular and makes the integration of new techniques easy. The application programmer, in order to make full use of the capabilities of the runtime, needs a language to express the functionality of the application and the possible choices of SMC techniques, without being forced to commit to particular techniques too early. The goal of this paper is to present such a programming language, describe its compilation and integration with the runtime. The design of the language has been somewhat inspired by Jif [23]. Several design choices have also been affected by our unique practical experience in developing SMC applications. Our contribution. In this paper we present an implementation of the secure programming model. Our main contributions include the introduction of protection domains as an abstraction for a set of SMC protocols and the design of a programming language (an extension of SecreC [17, 31]) that uses protection domains as its foundation. The notion of protection domains is elaborated on in Sect. 2 of this paper. The language is a simple, strongly typed imperative language where each variable and piece of data carries its protection domain as part of its type information. Importantly, our type system supports protection domain polymorphism. This allows the actual choices of SMC techniques to be done after the implementation of the subroutines of the application. This also allows the development of libraries of common privacy-preserving functionalities that can be used with many SMC techniques. To obtain speed-ups from the existence of particularly fast protocols for some common functionality with some SMC technique, our language also supports overloading (full and partial) of polymorphic functions. The language and its type system are described in Sect. 3. We have developed a compiler for our programming language that translates programs that use protection domains to bytecode executables that run on a secure computation runtime that enforces the protection domain restrictions. In this paper (Sect. 4 and Sect. 5), we present the translation of our language to a monomorphic intermediate language; its further translation to bytecode is standard. Related work. Several languages for programming secure computation systems have been pro- posed [21, 25, 15, 32, 22]. However, these language do not provide a clear separation of data with different policies on the type system level. Furthermore, some of them are fixed to a single secure computation paradigm. Our design has been influenced by the Decentralized Label Model (DLM) [24] and its implemen- 2 tation in Jif [23]. A label in DLM is closely related to our notion of a protection domain and label polymorphism appeared in Jif. The polymorphism is even more fine-grained in information flow analyses for programs in ML [27] or Haskell [20]. Our choice of following the imperative paradigm was influenced by its ubiquity in cryptographic literature. 2 Protection Domains We start by defining the protection domains and their kinds. Definition A protection domain kind (PDK) is a set of data representations, algorithms and protocols for storing and computing on protected data. Definition A protection domain (PD) is a set of data that is protected with the same resources and for which there is a well- defined set of algorithms and protocols for computing on that data while keeping the protection. Each protection domain belongs to a certain protection domain kind and each protection domain kind can have several protection domains. A typical example of a PDK is secret sharing, with implementations for sharing, reconstruction, and arithmetic operations on shared values. A PD in this PDK would specify the actual parties doing the secret sharing, and the number of cooperating parties for reconstruction. Another example of a PDK is a fully homomorphic encryption scheme with operations for encryption, decryption, as well as for addition and multiplication of encrypted values. Here different keys correspond to different PD-s. Non-cryptographic methods for implementing PDK-s may involve trusted hardware or virtualization. In general, a PDK has to provide 1. A list of data types used in the PDK. 2. For each data type in a PDK we need: (a)a classification and declassification functions to convert between public and protected representation of values, (b) protocols or functions that perform operations on protected values The functions performing secure operations should be universally composable so they can be com- bined into programs [7]. Constructing a useful PDK from secure multiparty computation is non-trivial, as many such schemes only support a few secure operations. It may be possible to construct more complex secure computation operations by composing simpler ones, but dedicated protocols have been shown to be more efficient in practice. We have identified several protocol suites that are suitable for implementation as protection domain runtimes with some work, including, but not limited to [2, 5, 10]. Our programming model includes a special public protection domain that does not apply any protective measures. The public protection domain is useful for working with values like public constants that do not have to be hidden. Our programming language will allow the application developer to define protection domain kinds and instantiate these kinds as individual protection domains. Each PDK (including the 3 public one) supports a range of data types and operations on those data types; the operations are accessed through system calls whose implementation (as a cryptographic algorithm or protocol) is beyond the scope