CrypTFlow: Secure TensorFlow Inference

I Introduction

Secure multiparty computation (or MPC) allows a set of mutually distrusting parties to compute a publicly known function on their secret inputs without revealing their inputs to each other. This is done through the execution of a cryptographic protocol which guarantees that the protocol participants learn only the function output on their secret inputs and nothing else. MPC has made rapid strides - from being a theoretical concept three decades ago , to now being on the threshold of having real world impact. One of the most compelling use cases for MPC is that of machine learning (ML) - e.g. being able to execute inference over ML algorithms securely when the model and the query are required to be hidden from the participants in the protocol. There has been a flurry of recent works aimed at running inference securely with MPC such as SecureML , MinioNN , ABY3 , CHET , SecureNN , Gazelle , Delphi , and so on. Unfortunately, these techniques are not easy-to-use by ML developers and have only been demonstrated on small deep neural networks (DNNs) on tiny datasets such as MNIST or CIFAR. However, in order for MPC to be truly ubiquitous for secure inference tasks, it must be both effortless to use and capable of handling large ImageNet scale DNNs.

In this work, we present CrypTFlow, a first of its kind system, that converts TensorFlow inference code into MPC protocols at the push of a button. By converting code in standard TensorFlow, a ubiquitous ML framework that is used in production by various technology companies, to MPC protocols, we significantly lower the entry barrier for ML practitioners and programmers to use cryptographic MPC protocols in real world applications. We make the following four contributions:

First, we provide a compiler, called Athos, from TensorFlow to a variety of secure computation protocols (both 2 and 3 party) while preserving accuracy. In the absence of Athos, all prior works require manually re-implementing ML models in an MPC friendly low-level language/library, and hence, their evaluations have been limited to small benchmarks where this task is feasible.

Second, we provide a semi-honest secure 3-party computation protocol, Porthos, that outperforms all prior protocols for secure inference and enables us to execute, for the first time, the inference of ImageNet scale networks in about 30 seconds.

Third, assuming a minimally secure hardware which guarantees the integrity of computations, we show a novel technique, Aramis, that compiles any semi-honest secure MPC protocol to a malicious secure MPC protocol. Aramis only relies on these integrity checks and assumes no confidentiality guarantees for data residing within the hardware. Aramis enables the first implementations of DNN inference secure against malicious adversaries.

Fourth, we demonstrate the ease-of-use, efficiency and scalability of CrypTFlow by evaluating on (a) ResNet50 , which won the ImageNet Large Scale Visual Recognition Challenge in 2015 ; (b) DenseNet121 , a convolutional neural network that won the best paper at CVPR 2017. These networks have heavily influenced the ML community with thousands of citations each. To demonstrate that CrypTFlow is immediately useful in healthcare, we also evaluate CrypTFlow on DNNs used for prediction of lung diseases and diabetic retinopathy.

Our toolchain and all of our benchmarks are publicly availablehttps://github.com/mpc-msri/EzPC.We now describe our results in more detail.

CrypTFlow outperforms prior work on ease-of-use, scalability, and efficiency. It automatically compiles TensorFlow code to MPC protocols with no loss in classification accuracy. This makes CrypTFlow the first secure inference system to produce a Top 1 accuracy of $76.45\%$ and Top 5 accuracy of $93.23\%$ for predictions running securely on the ImageNet dataset. Furthermore, in the 3-party (3PC) setting, this can be done in about $30$ seconds with semi-honest security and about $2$ minutes with malicious security. Prior work in the area of secure inference has been limited to small networks over tiny datasets such as MNIST or CIFAR. Moreover, these implementations are limited to security against weaker semi-honest adversaries, that are assumed not to modify the code of the MPC protocol. In contrast, our largest network ResNet-200 has 200 layers, 65 million parameters, over 1000 ImageNet classes, and the user can choose between semi-honest and malicious security – the latter also protects against adversaries who can deviate from the MPC protocol specification arbitrarily. We have evaluated CrypTFlow on secure inference over DNNs that are at least an order of magnitude larger than the state-of-the-art . Even on MNIST/CIFAR, CrypTFlow has lower communication complexity and is more efficient than prior and concurrent works . Furthermore, CrypTFlow is the first system to implementABY3 provided a theoretical protocol to convert their semi-honest protocol into a malicious secure protocol on much smaller benchmarks than CrypTFlow, but did not provide an implementation or experimental validation. malicious security for secure DNN inference. We show that the overhead of Aramis over semi-honest protocols is small and varies between 25% and 3X depending on the size of the computation. Moreover, by very conservative estimates, Aramis based secure DNN inference is faster than state-of-the-art malicious secure MPC inference protocols by at least an order of magnitude (and also the maliciously secure MPC protocols for general computation ). Hence, on inference tasks, prior MPC protocols are either much slower than Aramis or fail to provide security against malicious adversaries.

I-B Components of CrypTFlow

We describe the three components of CrypTFlow next. Athos (Section III). Athos is a compiler that compiles TensorFlow inference code to secure computation protocols. There are several challenges in doing so. For optimizations (Section III-D), the compiler needs the dimensions of all the tensors occurring in the dynamic Python code. The compiler is designed to be modular (Section III-C) and it provides facilities for plugging in various MPC protocols. To demonstrate this modularity, we have implemented the following backends: ABY-based 2-party computation (2PC), Porthos-based semi-honest secure 3-party computation (3PC), and Aramis-based malicious secure 3-party computation.

The threat model of Aramis is significantly stronger than the prior work on MPC using secure hardware . Specifically, in our threat model, not only is the host operating system outside the Trusted Computing Base, but it is also allowed to observe the entire state of the hardware (including user data). In contrast, for security of the protocol, the prior works require that the hardware hides the state from the host and even if data is decrypted and computed upon inside the hardware, it cannot be viewed by the host. In Section V, we describe the Aramis threat model in more detail, formalize the secure hardware as an ideal functionality, provide a formal description of the malicious secure MPC protocols, and formally prove their security. The ideal functionality can potentially be realized using various hardware platforms that provide code attestation and signing, e.g., STM32H7, MediaTek MT3620, CEC1702, ARMTrustZone, Intel’s SGX, etc. We provide a proof-of-concept implementation of Aramis by using SGX as the underlying secure hardware.

Aramis is general and can be applied to any semi-honest secure MPC protocol. To demonstrate this, we derive malicious secure MPC protocols from both semi-honest GMW (2 party protocol) and Porthos (3 party protocol). Porthos compiled with Aramis gives the first experimentally vetted maliciously secure protocol for neural network inference with at most 3X overhead over semi-honest security. While these were the semi-honest protocols we applied Aramis to, one could potentially obtain performant maliciously secure variants of several other recent semi-honest secure inference protocols (e.g. ), and MPC protocols for other applications .

I-C Organization of the paper

We provide an end-to-end walkthrough of our system to illustrate the overall toolchain in Section II. In Section III, we describe our compiler Athos. Section IV describes our improved 3-party semi-honest secure protocol for neural networks. We describe Aramis that compiles any semi-honest secure protocol into a malicious secure protocol, in Section V. We present all our experimental results in Section VI, related works in Section VII and conclude in Section VIII.

II Motivating Example

In this section, we describe the end-to-end working of CrypTFlow through an example of logistic regression. The high-level toolchain is shown in Figure 1. We describe how code compilation happens from TensorFlow to MPC protocols.

The CrypTFlow toolchain takes as input code written in vanilla TensorFlow. For example, consider the code snippet for logistic regression over MNIST dataset in TensorFlow as shown in Figure 2. Our compiler first generates the TensorFlow graph dump (as shown in Figure 3(a)) as well as metadata to help compute the dimensions of all the tensors (Figure 3(b)). III-A provides more details on the frontend. Next, the TensorFlow graph dump is compiled into a high-level intermediate language HLIL. The code snippet for logistic regression in HLIL is shown in Figure 4(a). Next, Athos’ float-to-fixed converter translates the floating-point HLIL code to fixed-point code in a low-level intermediate language LLIL. This step requires Athos to compute the right precision to be used for maximum accuracy (Section III-B). Figure 4(b) shows the LLIL code snippet for logistic regression. The function calls in this sequence can be implemented with a variety of secure computation backends - e.g. ABY for the case of 2-party secure computation, Porthos for the case of semi-honest 3-party secure computation (Section IV) and Aramis (Section V) for the malicious secure variant. Different backends provide different security guarantees and hence vary in their performance. For this example, the three backends take 227ms, 6.5ms, and 10.2ms respectively.

III Athos

Athos compiles ML inference code written in TensorFlow to MPC protocols. It has the following main components:

Frontend. Athos frontend compiles TensorFlow code to a high-level intermediate language (HLIL). HLIL supports floating-point tensors and sequence of function calls (corresponding to the TensorFlow nodes) that manipulate tensors. The main challenge in the frontend is to reconcile dynamic typing in TensorFlow to static typing in HLIL. TensorFlow code, written in Python, does not have tensor dimensions, whereas our HLIL has explicit tensor dimensions as it enables the compiler to perform analyses and optimizations.

Float-to-fixed converter. While ML models use floating-point arithmetic, MPC protocols operate on fixed-point arithmetic. Rather than requiring the programmers to manually convert (or re-train) their models to integers, Athos performs the conversion automatically, without compromising on the inference accuracy.

Modular LLIL. Athos compiles floating-point HLIL code to fixed-point code in a low-level intermediate language (LLIL). LLIL is a C-like imperative language that supports integer tensors, loops, conditionals, and functions. LLIL also makes it easier for different cryptographic backends to be plugged into Athos. It precisely specifies the interface that it requires the cryptographic protocols to implement, while providing a library for other operations. The LLIL is compiled down to the MPC protocol code.

Optimizations. Athos implements MPC specific optimizations as well as several standard dataflow analyses and compiler optimizations. The design of HLIL and LLIL, and the choice of them being statically typed, is partly motivated by the requirements of these analyses.

Below we explain each of these components in detail.

Athos frontend compiles the input TensorFlow models to HLIL (described next) with explicit tensor dimensions. To obtain these dimensions, the frontend first runs TensorFlow code on one dummy input and generates TensorFlow metadata that has all the required information. The metadata is then translated to HLIL.

We discuss some details of the frontend. A plain dump of the TensorFlow metadata contains some nodes that are semantically irrelevant for actual inference, e.g. identity, assign, etc. To avoid representing these nodes in HLIL, we first prune the TensorFlow graph to remove such nodes, specifically we use the TensorFlow graph transform tool for this purpose. Next, Athos desugars the remaining (tens of) TensorFlow nodes to HLIL, while keeping the number of functions in HLIL as small as possible. TensorFlow also supports “broadcasting” that allows operations on tensors of incompatible dimensions and sizes. For example, due to broadcasting, addition of a four-dimensional tensor with a one-dimensional tensor is a valid operation. Athos frontend passes the broadcasting information to HLIL, which then accounts for it by compiling it to the appropriate LLIL library function call.

Figure 5 shows the HLIL (we use $\overline{r}$ to denote sequences of floating-point constants, and similarly for other syntactic categories). It is a simple language of floating-point tensors ($\hat{M}$), with dimensions ($n$) and sizes as explicit type annotations ($\hat{\tau}[n]$), and the ${\mathtt{main}}$ is a sequence of variable declarations and function calls.

We next discuss how Athos performs float-to-fixed conversion on HLIL programs.

III-B Float-to-fixed

As observed earlier, most ML models are expressed using floating-point, while MPC protocols operate on integers. For large models, we cannot expect the programmers to manually translate or re-train floating-point ML models to integer code (the common approach in literature on secure inference ). Furthermore, it is well-known that floating-point operations are much more inefficient than fixed-point when evaluated securely () – we re-confirm this by performing two-party secure multiplication using both fixed-point and floating-point arithmetic to showcase the difference. This is illustrated in Table I which shows the huge overheads associated with floating-point arithmetic. In future, if efficient protocols for floating-point become available then we can directly compile HLIL to them, but until then Athos automatically performs the translation.

As an example of the conversion process, consider the program $M_{1}*M_{2}$ that multiplies the row vector $M_{1}=[400.1,200.1]$ with the column vector $M_{2}=[0.3,0.1]^{T}$. Then in infinite precision Real arithmetic the result of the computation $400.1*0.3+200.1*0.1$ is $140.04$. Single-precision floating-point arithmetic with 32 bits only has a 23-bit mantissa and computes the approximately correct result 140.040009. We use $0.1f$ to denote the floating-point number closest to the Real number $0.1$. Given $s=24$, $F(M_{1}*M_{2})$ results into the following program over integers

which results in the following computation with 64-bit integers

The final result is 2349481329 that represents the real number $\frac{2349481329}{2^{24}}=140.040000021457672119140625$ which is good approximation of the desired result $140.04$. Although it is feasible to constuct examples where fixed-point computations can be imprecise, ML usually operates on normalized values and we have observed that Athos does not lose accuracy in practice (Table VI).

Athos, assigns the same bit-width $b$ and the same scale $s$ to all network parameters. While we could use different $b$ and $s$, our experimental results show that same values for all parameters works quite well in practice. We keep the scale public for efficiency: division with $2^{s}$ when $s$ is secret is much more expensive than when $s$ is public. Moreover, scaling down operations (division by $2^{s}$) cause loss of precision, as they lose significant bits, and hence need to be minimized. Therefore, Athos scales down only once per matrix multiplication and does not scale down matrix additions.

While we use machine integer width (64) for $b$, finding a good value of $s$ is difficult. We explain the various tradeoffs that govern the choice of $s$ and then discuss our solution.

Suppose, in our example, $s$ is set too low: $s=2$. Then $F([400.1f,200.1f]*[0.3f,0.1f])$ is $(1600*1+800*0)>>2$, which represents the Real number $400/4=100$. This result is far from 140.04. Here, low scale values have lead to loss of significant bits. In particular, 0.1 has been rounded to zero causing an imprecise result. Ideally we want to set the scale to a large value so that the integers have many significant digits.

Next, suppose $s$ is set to a very high value, e.g., 60. Then, the computation $\rho_{60}(400.1f)*\rho_{60}(0.3f)$ overflows 64-bit integers and the result is garbage (multiplication of these two large positive numbers would become a negative number).

Thus, scale can neither be very low nor very high; we need to find a sweet spot. To determine an appropriate value of $s$, we sweep over all its possible values $\{0,1,\ldots,b-1\}$ and choose the value that leads to the best accuracy. For the example $400.1f*0.3f+200.1f*0.1f$, the most accurate result is obtained at $s=24$. In general, machine learning algorithms have a validation dataset that is used for hyperparameter tuning. We consider scale as a hyperparameter and select the scale that leads to a fixed-point classifier implementation that performs the best on the validation set. The scale chosen by Athos is a leakage function that depends on the weights of the model. Athos gives a methodical way of picking this scale that prior works did manually. Hence, leakage by Athos is similar to all prior works on secure inference.

III-C Modular LLIL

Athos compiles HLIL to LLIL, a crypto-aware, C-like intermediate language that has only integer-valued tensors. Figure 6 shows the syntax of LLIL. This language has sufficient expressiveness required to implement ML inference tasks. In particular it supports arrays, basic arithmetic, loops, branching, functions, and $\mathtt{extern}$ declarations. LLIL makes the Athos interface to the MPC cryptographic protocols explicit. We observe that the tensor operations in a typical TensorFlow code fall into two categories: those that do not change the values but just copy the data around (e.g. squeeze to remove dimensions of size 1 from a tensor, pad to pad a tensor with various kinds of paddings, transpose to take the transpose of a tensor, and concat to concatenate two tensors into a single tensor), and those that compute new values. For functions that do not manipulate shares (denoted by $f$), LLIL provides a library with their implementations that is automatically added as a prelude to LLIL programs. Changing the underlying crypto protocol does not require changes to these library functions and this library can be used by all crypto developers. These functions are implemented in LLIL and are compiled to C++ code.

Share-manipulating functions (${\mathtt{extern}}\;d$) are required to be implemented in the cryptographic backend. All a crypto developer needs to do is to implement these functions, and then she would be able to directly evaluate the protocols on ML models used in practice. We describe these functions with their signatures and intended semantics in Table II. Concretely, we provide three implementations of these functions: using the 2PC protocols of ABY , 3PC protocols of SecureNN , and Porthos (Section IV).

Finally, Athos compiles LLIL programs to C++ and links them with the cryptographic MPC protocol implementation.

III-D Optimizations

Athos intermediate languages are designed to be amenable to static analysis. In particular, we have implemented several standard dataflow analyses and compiler optimizations : reaching definitions, liveness analysis, and so on. These analyses help with optimizing memory utilization and we have observed savings reaching up to 80%. To demonstrate the ease of implementing analyses and optimizations, we provide an example each: (a) a peephole optimization ReLU MaxPool Switching on HLIL to improve efficiency of DNNs that use ReLU and MaxPool, and (b) an analysis Counting Scale Down operations on LLIL to determine the number of scale down operations done in order to prevent loss in accuracy (a similar analysis was done manually in ).

Most TensorFlow developers have adopted the convention of expressing DNN layers using the MaxPool(ReLU($\cdot$)) idiom. For protocols like Porthos and SecureNN that reduce ReLU and MaxPool to secure comparison protocols, ReLU(MaxPool($\cdot$)) can be much more efficient than MaxPool(ReLU($\cdot$)) as this significantly reduces the number of comparisons. As opposed to SecureNN, where this was done manually, we have built a peephole optimization pass on HLIL that replaces occurrences of ${\mathtt{MaxPool}}(a,b,{\mathtt{ReLU}}(A));$ with ${\mathtt{ReLU}}({\mathtt{MaxPool}}(a,b,A));$. For example, if the input matrix $A$ has dimensions $112\times 112\times 64$ and we compute a MaxPool with $2\times 2$ windows. Then, the output matrix has dimensions $56\times 56\times 64$. Hence, the latter needs to compute only one fourth the number of ReLUs compared to the former. In this case, the optimized code is over $3\times$ better in communication and over $2\times$ faster in our experimental setup (Section VI).

III-D2 Counting Scale Down operations

We describe an analysis to count the number of scale down operations in an LLIL code. The analysis uses an environment $\rho$ that maps tensors to the number of elements they contain. This environment is populated using variable declarations in the code. The analysis makes a single pass over ${\mathtt{main}}$ and for each call ${\mathtt{ScaleDown(A,s)}}$ accumulates $\rho(A)$ into a counter. The final value of the counter provides the number of scale down operations in the code.

Note that this analysis is easy to describe as the LLIL code contains dimensions of all the tensors explicitly. Hence, the compiler can statically populate $\rho$. This analysis is impossible to perform on the TensorFlow Python code as the sizes of tensors are unknown at compile time.

IV Porthos

We now describe Porthos, our improved secure 3PC protocol that provides semi-honest security against one corrupted party and privacy against one malicious corruption. The notion of privacy against malicious corruption (introduced by Araki et al. ) informally guarantees that privacy of inputs hold even against malicious party as long as none of the parties participating in the protocol learn the output of the computation (this is relevant, for example, when computation is offloaded to servers). Porthos builds upon SecureNN but makes crucial modifications to reduce communication. We first describe our protocols that reduce communication and summarize concrete improvements in Table III.

We reduce communication for both linear as well as non-linear layers of DNNs. Linear layers include fully connected layers as well as convolutional layers. We improve the communication for convolutional layers and our optimization gains get better with larger filter sizes. With regards to non-linear layers (ReLU and MaxPool), we modify how two of the protocols in SecureNN are used – ComputeMSB and ShareConvert. As we explain below, this directly translates to better communication for both ReLU and MaxPool computations. At a very high level, we trade communication with compute by modifying the way certain shares are generated in the protocol. Convolution. In SecureNN, secure computation of convolutional layers is done by reducing them to a (larger) matrix multiplication. As an example, $2$-dimensional convolution of a $3\times 3$ input matrix $X$ (with single input channel and stride 1) with a filter $Y$ of size $2\times 2$ reduces to a matrix multiplication as follows:

In the above matrix multiplication, we call the left matrix (derived from $X$) as the “reshaped input” (say, $X^{\prime}$) and the right matrix (derived from $Y$) as the “reshaped filter” (say, $Y^{\prime}$). The matrix multiplication is computed securely using a matrix Beaver triple based protocol. Later, the output can be reshaped to get the output of convolution in correct shape. In this protocol, matrices being multiplied are masked by random matrices of same size and communicated and hence, the communication grows with the size of the matrices. We observe that this is quite wasteful for convolution because the reshaped input image (the first matrix in multiplication) has many duplicated entries (e.g., $x_{2}$ in row 1 and row 2) that get masked by independent random values. Let size of $X$ be $m\times m$ and size of $Y$ be $f\times f$. Then, the size of $X^{\prime}$ is $q^{2}\times f^{2}$, where $q=m-f+1$. In Porthos, we optimize the size of matrix-based Beaver triples for convolution by exploiting the structure of re-use of elements as the filter moves across the image. At a high level, we pick random matrix of size matching $X$ for masking and communication only grows with size of $X$ (i.e., $m^{2}$) instead of $X^{\prime}$ (i.e., $q^{2}f^{2}$) in SecureNN.

Activation Functions. In SecureNN protocols for computing activations such as ReLU and MaxPool start with parties $P_{0}$ and $P_{1}$ having shares of values over $L=2^{64}$. For both of these, parties run a protocol called $\mathsf{ComputeMSB}$ to evaluate most significant bit (MSB) of secret values. This protocol require shares over $L-1$. So parties run a protocol called $\mathsf{ShareConvert}$ to convert shares over $L$ to shares over $L-1$. Both protocols $\mathsf{ComputeMSB}$ and $\mathsf{ShareConvert}$ require $P_{2}$ to send fresh shares of a value to $P_{0}$ and $P_{1}$. In SecureNN, both of these shares were picked by $P_{2}$ and explicitly communicated to $P_{0}$ and $P_{1}$. As mentioned before, shares of a value $x$ are $r$ and $x-r$, where $r$ is a appropriately picked uniformly random value. We observe that since one of the shares is truly random, it can be computed as the output of a shared PRF key between $P_{2}$ and one of the parties, say $P_{0}$. This cuts the communication of this step to half. Moreover, since many activations are computed in parallel, we can carefully “load-balance” this optimization between $P_{0}$ and $P_{1}$ to reduce the communication to half on the critical path. We implement this load-balance optimization and observe that this reduces the overall communication of $\mathsf{ShareConvert}$, $\mathsf{ComputeMSB}$, $\mathsf{ReLU}$ and $\mathsf{MaxPool}$ by $25\%$.

V Aramis

In this section, we describe Aramis, a general technique to convert any semi-honest secure MPC protocol into a secure MPC protocol tolerating malicious corruptions by relying on secure hardware. The threshold of corrupted parties tolerated by the semi-honest protocol is retained in the malicious secure protocol by our technique. Threat Model. We consider a strong threat model where not only does the adversary control the operating system of the corrupted parties (i.e., the host operating system is outside the Trusted Computing Base) but also observes the entire state of their secure hardware. Aramis makes a very minimal trust assumption of integrity on hardware, namely that of code attestation (the outputs generated by the hardware are indeed from the code that it attested to). This implicitly requires the hardware to possess a trusted component that can produce signatures and this signature scheme cannot be forged by the adversary. However, the adversary can see the state (i.e., all the code and the user data) of the hardware belonging to the corrupted parties, i.e., we do not assume confidentiality of state. Prior works that combine MPC and hardware (SGX) make stronger trust assumption on the hardware of both confidentiality and integrity, and hence, provide security only in a weaker threat model where the hardware hides the data residing in it from the adversary. Overview. At a very high level, Aramis exploits the following (well-known) observation: in order for a semi-honest protocol to be made maliciously secure, one must ensure that all messages sent by every party $P_{i}$ are computed honestly according to the specification of the semi-honest protocol consistent with $P_{i}$’s input and the transcript so far. The next observation we make is that if party $P_{i}$ possesses hardware whose code can be attested by party $P_{j}$ (and vice-versa), then $P_{j}$ can obtain guarantees on the correctness of protocol messages sent by $P_{i}$ as long as these messages are computed and signed by $P_{i}$’s hardware. Using these observations, we can convert a semi-honest secure protocol into one that is maliciously secure by having every protocol message of $P_{i}$ be computed by the trusted hardware that $P_{i}$ executes. We shall now describe our techniques in more detail. We first describe the ideal functionality that is assumed out of the hardware in Section V-A. We then describe our technique in Section V-B. Finally, we provide an implementation of Aramis using Intel SGX as the underlying secure hardware. We explain how Intel SGX can realize the ideal functionality in Section V-C and challenges in porting semi-honest MPC protocols to SGX in Section V-D.

Description. We formally define the ideal functionality for attested executions in Figure 7. The functionality is parameterized by a signing key pair $(\mathsf{vk},\mathsf{sk})$. Let $\mathsf{Sign}_{\mathsf{sk}}(m)$ denote the signing algorithm on message $m$ and $\mathsf{Verify}_{\mathsf{vk}}(m,\sigma)$ denote verification of signature $\sigma$ on message $m$. At a high level, this functionality allows users to specify a function $g$ to the ideal functionality once using the $\mathsf{Commit}$ command. The functionality returns a token $\mathcal{T}_{g}$ generated as $\mathsf{Sign}_{\mathsf{sk}}(H(g))$, where $H$ is a collision resistant hash function. Note that this token is publicly verifiable given $g$ and $\mathsf{vk}$. Let $\mathsf{state}_{\mathsf{ctr}}$ be an internal state that the functionality maintains, indexed by $\mathsf{ctr}$ – this state can be maintained by signing it along with $\mathsf{ctr}$ and verifying the signature of the state on every input message. When the functionality $\mathcal{F}_{\textrm{\tiny{attest}}}$ is initialized, the initial state $\mathsf{state}_{0}$ is empty (or, $\epsilon$). Subsequent invocations of the functionality is done on input $w_{\mathsf{ctr}}$ using the $\mathsf{Compute}$ command. The function $g$ is a deterministic mapping from $(\mathsf{ctr},w_{\mathsf{ctr}},r_{\mathsf{ctr}},\mathsf{state}_{\mathsf{ctr}-1})$ to $(y_{\mathsf{ctr}},\mathsf{state}_{\mathsf{ctr}})$, where $r_{\mathsf{ctr}}$ is the required randomness. The functionality picks randomness $r_{\mathsf{ctr}}$, evaluates $g$ and provide a signature on the function output $y_{\mathsf{ctr}}$ using the signing key $\mathsf{sk}$. Furthermore, $(y_{\mathsf{ctr}},\mathsf{state}_{\mathsf{ctr}})$ is always given to party $P$ such that $\mathsf{state}_{\mathsf{ctr}}$ contains $r_{\mathsf{ctr}}$ in clear and this ensures that there is no information hidden from $P$ and we only assume correct execution of $g$. That is, the ideal functionality can evaluate functions and provide signed outputs and these outputs could have anyway been computed by party $P$ given knowledge of $g,w_{\mathsf{ctr}},r_{\mathsf{ctr}},\mathsf{ctr},\mathsf{state}_{\mathsf{ctr}}$, which are all known to $P$. Thereby, we only assume that the functionality will sign the output of $g$ on the appropriate input and not hide any data from $P$. This significantly weakens what is assumed from the trusted hardware.

V-B Semi-honest security to malicious security

Our technique takes any semi-honest secure MPC protocol and converts it into a malicious secure MPC protocol in the $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk},\mathsf{sk})}-$hybrid model. The idea is to have messages sent by every party $P_{i}$ to every other party $P_{j}$ in the semi-honest protocol be computed by the corresponding $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{i},\mathsf{sk}_{i})}$ functionality interacting with $P_{i}$, where $(\mathsf{vk}_{i},\mathsf{sk}_{i})$ are keys used by the functionality. These messages can be verified by functionality $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{j},\mathsf{sk}_{j})}$ interacting with $P_{j}$. We assume that every $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{i},\mathsf{sk}_{i})}$ knows the verification key $\mathsf{vk}_{j}$ used by functionalities of all other parties $P_{j}$ in a reliable manner. Later, we show how to achieve this through the use of remote attestation in the context of Intel SGX. We now set notation and describe the next message function of any semi-honest secure MPC protocol and how we modify it for our use. Next message function. Let $\pi(\cdot)$ be the next message function of any semi-honest secure MPC protocol. $\pi(\cdot)$ takes the following values as input - two party ids $i$ and $j$, input $x_{i}$, a round number $\mathsf{ctr}$, randomness $r_{i,j,\mathsf{ctr}}$ and $\mathsf{Transcript}_{i}$, which includes the transcript of all messages sent and received by the party $P_{i}$ so far. Given these, $\pi(\cdot)$ outputs $y_{\mathsf{ctr}}^{i,j}$, which is the message that $P_{i}$ must send to $P_{j}$ in round $\mathsf{ctr}$ and also updates $\mathsf{Transcript}_{i}$ appropriately. Additionally, $\pi(\cdot)$ takes message $y_{\mathsf{ctr}}^{j,i}$ sent by $P_{j}$ to $P_{i}$ at round $\mathsf{ctr}$ and update $\mathsf{Transcript}_{i}$ with this message. We now describe how to modify $\pi(\cdot)$ to $\pi^{*}(\cdot)$ to incorporate checks to detect malicious behavior. Modified next message function. $\pi^{*}(\cdot)$, is the modified function that builds upon $\pi(\cdot)$ and we describe it for $P_{i}$.

For $\mathsf{ctr}=1$, Let $x_{i}$ be the input of $P_{i}$ in $\pi(\cdot)$. Then, $(\mathsf{ctr},x_{i})$ is stored as $\mathsf{state}_{1}$ (also called as $\mathsf{Transcript}^{1}_{i}$) and sent to $P_{i}$.

When $\pi^{*}(\cdot)$ receives a message $M=(y_{\mathsf{ctr}}^{j,i},\mathsf{ctr},\sigma)$ from party $P_{j}$, it runs $\mathsf{Verify}_{\mathsf{vk}_{j}}((y_{\mathsf{ctr}}^{j,i},\mathsf{ctr}),\sigma)$. If verification succeeds, it appends $M$ to $\mathsf{Transcript}_{i}$. Else, $P_{i}$ aborts.

$\pi^{*}(\cdot)$ on input $(\mathsf{ctr},\mathsf{state}_{\mathsf{ctr}-1},j)$ computes the next message from $P_{i}$ to $P_{j}$ as follows: It checks that $\mathsf{state}_{\mathsf{ctr}-1}$ contains a valid transcript of all messages computed so far. If it verifies, it picks randomness $r_{i,j,\mathsf{ctr}}$ and runs $\pi(\mathsf{ctr},\mathsf{state}_{\mathsf{ctr}-1},j,r_{i,j,\mathsf{ctr}})$ to compute next message $y^{i,j}_{\mathsf{ctr}}$ and updated state $\mathsf{state}_{\mathsf{ctr}}$ (containing $r_{i,j,\mathsf{ctr}}$). Else it outputs $\bot$. Note that $\mathsf{state}_{\mathsf{ctr}-1}$ already contains input $x_{i}$, the input of party $P_{i}$.

Malicious MPC in the $\mathcal{F}_{\textrm{\tiny{attest}}}-$hybrid model. The malicious MPC protocol works as follows: Each party $P_{i}$ invokes $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{i},\mathsf{sk}_{i})}$ with the command $\mathsf{Commit}$ using function $\pi^{*}(\cdot)$ described above and sends the received token $\mathcal{T}^{(i)}_{\pi^{*}}$ to other parties $P_{j}$. It receives similar tokens $\mathcal{T}^{(j)}_{\pi^{*}}$ from party $P_{j}$ and verifies it under $\mathsf{vk}_{j}$. Party $P_{i}$ aborts if any of these verifications fail. If all verifications succeed, it proceeds with running $\pi^{*}(\cdot)$ inside $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{i},\mathsf{sk}_{i})}$ as described formally in Figure 8.

Malicious Security. Next, we prove that if $\pi$ is secure against semi-honest adversaries, then the protocol described in Figure 8 is an MPC protocol secure against malicious adversaries with the same corruption threshold. We prove the following result using the standard simulation paradigm in Appendix A-B.

Let $\pi(\cdot)$ be a semi-honest secure MPC protocol securely realizing $\mathcal{F}_{\textrm{\tiny{mpc}}}^{f}$. Then, protocol $\mathsf{Prot}_{\tiny{\mathsf{malicious}}}(P_{1},\cdots,P_{n})$ described in Figure 8 securely realizes $\mathcal{F}_{\textrm{\tiny{mpc}}}^{f}$ in the $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{i},\mathsf{sk}_{i})}-$hybrid model (with $i\in[n]$) against malicious adversaries.

We note that the ideal functionality assumed out of the hardware can potentially be realized using various hardware platforms that provide code attestation and secure signing, e.g., STM32H7, MediaTek MT3620, CEC1702, ARMTrustZone, Intel SGX, etc. In this work, we provide an implementation of Aramis based on Intel SGX.

SGX allows a host to create a protected region known as an enclave. Intel gives integrity guarantees, that is, the code and the data residing in the enclave, once attested, cannot be modified by the host or the operating system. When SGX receives a $\mathsf{Commit}$ command (Figure 7) for a function $g$, then it creates an enclave with code $g$. Randomness $r_{\mathsf{ctr}}$ of Figure 7 can be sampled in SGX using sgx_read_rand command. The attestation token $\mathcal{T}_{g}$ is generated by SGX communicating with Intel’s Attestation Service (IAS) and this token is publicly verifiable given $g$ and public verification key corresponding to Intel’s Report Signing Key. The key-pair $(\mathsf{vk},\mathsf{sk})$ for ECDSA signature scheme is also generated inside the enclave and the verification key $\mathsf{vk}$ is sent as payload to IAS during the generation of the attestation token. The token $\mathcal{T}_{g}$ contains the verification key $\mathsf{vk}$ in the clear and this $\mathsf{vk}$ can be used to verify the signed outputs $y_{\mathsf{ctr}}$. Now, on receiving the $\mathsf{Compute}$ command, the enclave starts executing the code of $g$ and produces outputs signed under $\mathsf{sk}$.

While running MPC in the $\mathcal{F}_{\textrm{\tiny{attest}}}$-hybrid, we require the enclave to reliably have verification keys used by enclaves of all other parties. This can be done by attaching the following prelude to $\pi^{*}$ (the code running inside SGX): Read the tokens of all parties, parse them to obtain the verification keys, and verify the signature on the tokens using verification key of Intel’s Report Signing key. Note that since all the parties are running the same function $\pi^{*}$ (appended with this prelude), they can compute the hash of $\pi^{*}$ locally and compare it with the hash in the tokens (which has been signed by Intel’s IAS) of all the other parties, proceeding only if they all match perfectly.

V-D Implementation challenges with Intel SGX

We outline some of the key challenges in implementing MPC between multiple SGX enclaves that involve multiple rounds of interaction and operate over large volumes of data.

In SGX, all the enclave content, including code, and related data is stored in a special region of memory known as the Enclave Page Cache (EPC). The size of EPC is fixed in BIOS and can have a maximum size of 128MB. Typically, paging facilitates the execution of enclaves which cannot fit in EPC and any page that is evicted out is encrypted before storing it on unprotected memory . This additional overhead has detrimental effects on the overall performance of the enclave application. We reduce the working set of secure inference tasks to limit these overheads.

ReLU and MaxPool functions: We split the computation of memory-intensive non-linear functions into chunks that fit in the EPC to avoid paging. However, lower chunk sizes increase the number of rounds, and so, the chunk sizes must be carefully selected. For ResNet50, we set the chunk sizes for ReLU and MaxPool layers to be 40 MB and 10 MB respectively. For our network configurations, the increase in rounds is justified by the elimination of paging costs and reduction in end-to-end runtimes.

Convolution and Matrix Multiplication functions: For the linear functions, we block the matrices into smaller ones, process the blocks, and aggregate them. We ensure that individual blocks fit in EPC.

Liveness Analysis: Athos implements liveness analysis (Section III-D) which reduces the memory footprint of the compiled DNNs. For example, the memory footprint of ResNet50 reduces from 1100 MB to 397 MB due to liveness analysis. When chunking and liveness analysis are done together, the memory footprint of ResNet50 comes down to 297MB.

V-D2 Porting Interactive Protocols to SGX

To the best of our knowledge, we are the first work to implement highly interactive protocols in SGX and this comes with unique challenges. For example, whenever data is passed across the enclave’s protected memory region, it has to be marshalled in/out of the region. The performance of marshalling depends on the size of the parameters crossing the bridge. Larger parameters imply slower marshalling , while smaller parameters increase the total numbers of cross-bridge calls (which have an overhead of their own). Thus, we tune the payload size carefully. We also implement the techniques in for optimizing communication involving enclaves.

VI Experiments

Overview. In this section, we present our experimental results. First, in Section VI-A, we use CrypTFlow to securely compute inference on the ImageNet dataset using the following TensorFlow programs: ResNet50 https://github.com/tensorflow/models/tree/master/official/r1/resnet and DenseNet121 https://github.com/pudae/tensorflow-densenet. We also show that the performance of semi-honest and malicious protocols generated by CrypTFlow scale linearly with the depth of DNNs. Second, in Section VI-B, we show that CrypTFlow outperforms prior works on secure inference of DNNs. Next, we evaluate each component of CrypTFlow in more detail. In Section VI-C, we show that the fixed-point code generated by Athos matches the accuracy of floating-point ResNet50 and DenseNet121. We show in Section VI-D how the optimizations in Porthos help it outperform prior works in terms of communication complexity and overall execution time. In Section VI-E, we show the overhead of obtaining malicious secure MPC (over semi-honest security) using Aramis for GMW and Porthos. We show Aramis-based malicious secure inference outperforms pure crypto-based malicious secure protocols by huge margins in Section VI-E1. Finally, in section VI-F, we discuss two case-studies of running CrypTFlow on DNNs for healthcare. We begin by providing details of the systems used to run our experiments. System Details. All our large benchmark experiments are in a LAN setting on 3.7GHz machines, each with 4 cores and with 16 GB of RAM running Linux Ubuntu 16.04. The measured bandwidth between each of the machines was at most 377 MBps and the latency was sub-millisecond. Since we wanted to use the same machines to benchmark both our semi-honest as well as our malicious secure protocols, we were constrained to use machines that had Intel SGX enabled on them - this led to machines that had considerably lower bandwidth between them (377 MBps) than those normally used by prior works in the area (e.g. used networks with bandwidth of 1.5 GBps). For Aramis, we used Intel SGX SDK version 2.4. The compilation time of CrypTFlow is around 5 sec for ResNet50, 35 sec for DenseNet121 and 2 minutes for ResNet200.

We briefly describe our benchmarks and then present performance results.

ResNet50 is a network that follows the residual neural network architecture. The residual nodes employ “skip connections” or short cuts between layers. It consists of 53 convolution layers with filters of size up to $7\times 7$, and 1 fully connected layer of size $2048\times 1001$. The activation function between most layers is batch normalization (Appendix -B) followed by ReLU. After the first convolutional layer, the activation function also includes a MaxPool.

DenseNet121 is a form of residual neural network that employs several parallel skips. It consists of 121 convolutional layers with filters of size up to $7\times 7$. The activation function between these layers is usually batch normalization, followed by ReLU. Some layers also use MaxPool or AvgPool.

Performance. Table IV shows performance of CrypTFlow on these benchmarks. We measure communication as total communication between all $3$ parties - each party roughly communicates a third of this value. The communication in semi-honest secure and malicious secure inference is almost the same. Thus demonstrating that ImageNet scale inference can be performed in about 30 seconds with semi-honest security and in under two minutes with malicious security. The malicious protocol of CrypTFlow is about 3x slower than the semi-honest version.

Scalability. We show that the running time of CrypTFlow-based protocols increases linearly with the depth of DNNs. We compile ResNet-$n$ (where $n$, the approximate number of convolutional layers, varies from 18 to 200) with CrypTFlow and evaluate with both semi-honest (Porthos) and malicious secure protocols (Aramis) in Figure 10. Our largest benchmark here is ResNet-$200$, the deepest version of ResNet on the ImageNet dataset , which has 65 million parameters. Other ResNet-$n$ benchmarks have between 11 to 60 million parameters Specifically, 11, 22, 25, 44 and 60 million parameters for ResNet-$n$ for $n=$ 18, 34, 50, 101, and 152 respectively.. We observe that the communication and runtime increase linearly with depth. Even with increasing depth, the overhead of malicious security (over semi-honest security) remains constant at about 3X.

VI-B Comparison with prior work

In this section, we show that CrypTFlow outperforms prior works on secure inference of DNNs on the benchmarks they consider, i.e., tiny 2–4 layer DNNs over the MNIST and CIFAR-10 datasets. We stress that these benchmarks are very small compared to the ImageNet scale DNNs discussed above. In order to provide a fair comparison, for these experiments, we use a network with similar bandwidth as prior works (1.5 GBps) and machines with similar compute (2.7 GHz).

Table V shows that Porthos outperforms prior (ABY3 , ChameleonChameleon is a 2PC protocol in the online phase but requires a trusted third party in the offline phase. We report overall time here. , and SecureNN ) and concurrent (QuantizedNN ) semi-honest secure 3PC works on the MNIST dataset. It is well-known that 3PC-based techniques like Porthos are much faster than techniques based on 2PC and FHE. We relegate comparison between Porthos and 2PC/FHE works to Appendix A-A. We omit comparisons with as their published MSB protocol was incorrect .

VI-C Athos experiments

Accuracy of Float-to-Fixed. We show that Athos generated fixed-point code matches the accuracy of floating-code on ResNet50 and DenseNet121 in Table VI. The table also shows the precision or the scale that is selected by Athos (Section III-B). We observe that different benchmarks require different precision to maximize the classification accuracy and that the technique of “sweeping” through various precision levels is effective. We show how accuracy varies with precision in Appendix A. Evaluating accuracy also helps validate the correctness of our compilation .

Modularity. Since CrypTFlow is modular, we can compile it to various MPC backends. To demonstrate this ability, we also add a 2PC semi-honest secure protocol ABY to CrypTFlow. The performance with this backend is in Table VII. We ran logistic regression (LR) as well as a small LeNet network which comprises of 2 convolutional layers (with maximum filter size of $5\times 5$) and 2 fully connected layers, with ReLU and MaxPool as the activation functions. This evaluation shows that CrypTFlow can be easily used for a variety of backends.

VI-D Porthos experiments

Since Porthos builds on SecureNN, we compare them in mode detail. As described earlier, Porthos improves over the communication complexity of SecureNN both for convolutional layers as well as for non-linear activation functions. We have already compared SecureNN and Porthos on benchmarks considered in SecureNN in Table V. Additionally, we also compare Porthos and SecureNN on ImageNet scale benchmarks in Table VIII. For this purpose, we add the code of SecureNN available at as another backend to CrypTFlow. These results show that Porthos improves upon the communication of SecureNN by a factor of roughly 1.2X–1.5X and the runtime by a factor of roughly 1.4X–1.5X.

VI-E Aramis experiments

We demonstrate that Aramis based malicious secure protocols are better suited for large scale inference tasks compared to pure cryptographic solutions. We compare the performance of Porthos compiled with Aramis and the concurrent work of QuantizedNN that uses the MP-SPDZ framework to also provide a malicious secure variant of their protocol. Both these approaches provide security for the same setting of 3PC with 1 corruption. On the four MNIST inference benchmarks A/B/C/D in the MP-SPDZ repository, Aramis is 10X/46X/44X/15X faster.

VI-F Real world impact

We discuss our experience with using CrypTFlow to compile and run DNNs used in healthcare. These DNNs are available as pre-trained Keras models. We converted them into TensorFlow using and compiled the automatically generated TensorFlow code with CrypTFlow.

In , the authors train a DenseNet121 to predict lung diseases from chest X-ray images. They use the publicly available NIH dataset of chest X-ray images and end up achieving an average AUROC score of 0.845 across 14 possible disease labels. During secure inference, we observed no loss in accuracy and the runtime is similar to the runtime of DenseNet121 for ImageNet.

Diabetic Retinopathy (DR), one of the major causes of blindness, is a medical condition that leads to damage of retina due to diabetes . In recent times, major tech companies have taken an interest in using DNNs for diagnosing DR from retinal images . Predicting whether a retina image has DR or not can be done securely in about 30 seconds with CrypTFlow.

VII Related Work

High level languages. CrypTFlow is the first system to compile pre-defined TensorFlow code to secure MPC protocols. There have been prior works that compile from lower-level, domain-specific languages to MPC. Examples include Fairplay , Wysteria , ObliVM , CBMC-GC , SMCL , , Sharemind , EzPC , and SPDZ . Reimplementing large DNNs in the input format of these tools is a formidable task. PySyft and TF-Encrypted are ongoing efforts that also aim to compile DNNs to MPC protocols. In contrast to CrypTFlow that compiles standard TensorFlow code, these works require reimplementing the DNNs in a dialect of PyTorch/TensorFlow. To the best of our knowledge, these systems have not been evaluated on ImageNet scale tasks. Fixed-point in MPC. Although the use of fixed-point for secure computations is well-known , prior works on secure inference have addressed the float-to-fixed problem by either generating a fixed-point model by hand (), or by using non-standard training algorithms that output fixed-point models (). Both of these approaches are unsatisfactory. In particular, some of the challenges that one would face with the latter include: a) the need to train again on the whole training data which is both computationally expensive, and impossible if the training data is unavailable; and b) training algorithms that generate integer models is still an active research area and an overwhelming majority of ML training algorithms still generate floating-point models. Athos alleviates all these problems by working with a trained model and being completely oblivious to the training procedure. The ML users can train their networks in the manner they see fit and then use Athos to get fixed-point code. Finally, even with retraining, TensorFlow-generated binary/integer networks suffer significant accuracy loses whereas Athos matches the accuracy of floating-point models. Float-to-fixed. The research literature in float-to-fixed for digital signal processors is rich and spans several decades. However, it is only recently that these schemes have been adapted to machine learning. Some recent float-to-fixed schemes show promise by quantizing floating-point models to 8-bit or 16-bit integers. One could potentially use one of these systems in place of our float-to-fixed component – however, their compatibility with MPC protocols is unclear. Additionally, since we use higher bit-width of 64, not surprisingly, the accuracy of CrypTFlow is better. Secure Machine Learning. There has been a flurry of recent results () in the area of secure machine learning, both in the 2-party , as well as in the 3-party setting . The most relevant to our work are ABY3 and SecureNN that both provide 3-party semi-honest secure computation protocols for a variety of neural network inference and training algorithms, with somewhat similar performance guarantees. Porthos, our 3-party semi-honest protocol, outperforms both these works. We also remark that there have been other recent works , that modify the inference or training algorithms in order to obtain performance benefits. These are applicable only to specialized benchmarks. For example, the works that use fully homomorphic encryption (e.g., ) do not support secure evaluation of ReLUs, XONN requires DNNs to have binary weights, etc. On the other hand, we focus on standard inference algorithms and CrypTFlow has much wider applicability. Hardware-based security. Our work is the first to provide experimentally validated malicious secure inference of ML algorithms at the scale of ResNet50. As discussed earlier, we achieve this by relying on minimally secure hardware to provide integrity. Prior works that use hardware enclaves for secure computation assume that the enclave hides all data residing in it from the host. Thus, unlike Aramis, these systems are not secure against an adversary that can observe the SGX state. The only prior work that assumes a weaker trust assumption from the hardware is that of . Similar to our work, they assume that the hardware provides integrity. However, their work is in the context of zero-knowledge proofs and other fundamentally asymmetric primitives that require only one enclave and not interactive protocols between multiple enclaves.

VIII Conclusion

CrypTFlow is the first end-to-end system that translates high-level TensorFlow inference code to MPC protocols. It has 3 components - a) compiler from TensorFlow to MPC, b) an improved semi-honest 3PC protocol for DNNs, and c) a generic technique to convert semi-honest secure protocols to malicious secure ones. Using CrypTFlow, we demonstrate the first instance of secure inference on large benchmarks such as ResNet50 and DenseNet121 on the ImageNet dataset with both semi-honest (in about thirty seconds) and malicious security (in less than two minutes). CrypTFlow’s modular design supports a variety of backends, and we hope that it can serve as a testbed for benchmarking new MPC protocols in the area.

Going forward, we would like to plugin protocols like SPDZ and Delphi in CrypTFlow. Our more ambitious goal is to extend CrypTFlow to support TensorFlow training. It is a challenging problem since in the absence of the GPU support, the overheads of MPC protocols for secure training can be prohibitive.

IX Acknowledgements

We thank our shepherd Xiao Wang, and anonymous reviewers for their valuable feedback. We also thank Sridhar Gopinath, Aayan Kumar, Wonyeol Lee, Sundararajan Renganathan, and Kapil Vaswani for helpful discussions.

References

-A Algorithms used by Porthos

The additional algorithms that reshape filters, input, and output, used by Porthos are shown in Algorithms 2, 3, and 4.

-B Batch Normalization

Batch Normalization is used to normalize the inputs to intermediate layers across a mini-batch of images. For a batch $B$ of inputs, let $\mu_{B}$ and $\sigma_{B}^{2}$ be the mean and the variance respectively. For an input $x$, the output of the batch normalization layer is defined as

where $\gamma$ and $\beta$ are the model parameters learned during training phase. In the inference phase, $\mu_{B}$ and $\sigma_{B}^{2}$ represent the mean and variance of the entire training dataset.

-C Accuracy of Athos

Appendix A Accuracy of Athos

In this section, we present the Top 1 and Top 5 accuracies of Athos on the ImageNet dataset.

See Table X which validates the well-known fact that 3PC protocols like Porthos are much faster than 2PC/FHE-based approaches. We omit other 2PC/FHE works (, etc.) as the performance comparisons are similar and do not provide additional insights.

A-B Proof of malicious security

For simplicity, consider the case of single malicious party $P_{i}$. Informally, we argue that our technique constrains $P_{i}$ to follow the instructions of the semi-honest protocol $\pi(\cdot)$ faithfully. Or, deviating from faithful execution would result in some honest party to abort. The first $\mathsf{Compute}$ invocation of $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{i},\mathsf{sk}_{i})}$ fixes the input of $P_{i}$ used in the protocol. Since every other $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{j},\mathsf{sk}_{j})}$ reliably knows the verification key $\mathsf{vk}_{i}$ used by $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{i},\mathsf{sk}_{i})}$, it checks the signatures on the function description (i.e., $\mathcal{T}^{(i)}_{\pi^{*}}$) as well as the messages of the protocol. The unforgeability of the signature scheme guarantees that $P_{i}$ cannot forge signatures on incorrectly generated protocol messages. Note that we use this property to ensure that both of the following signatures cannot be forged: (a) signatures under $\mathsf{vk}_{i}$ on messages generated by $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{i},\mathsf{sk}_{i})}$ and sent to honest $P_{j}$ (b) signatures under $\mathsf{vk}_{j}$ on messages sent by $P_{j}$ being fed into $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{i},\mathsf{sk}_{i})}$. Also, $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{i},\mathsf{sk}_{i})}$ provides correct randomness to generate messages of $P_{i}$ in the semi-honest secure protocol. Hence, all messages from $P_{i}$ to any honest party $P_{j}$ are generated correctly as directed by $\pi$. This argument can be easily extended to multiple colluding corrupt parties.

Formally, we give a security proof using the standard simulation paradigm (we refer the reader to for details on the paradigm). That is, the protocol in Figure 8 securely realizes the ideal MPC functionality described in Figure 9 against malicious adversaries.

Let $\pi(\cdot)$ be a semi-honest secure MPC protocol securely realizing $\mathcal{F}_{\textrm{\tiny{mpc}}}^{f}$. Then, protocol $\mathsf{Prot}_{\tiny{\mathsf{malicious}}}(P_{1},\cdots,P_{n})$ described in Figure 8 securely realizes $\mathcal{F}_{\textrm{\tiny{mpc}}}^{f}$ in the $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{i},\mathsf{sk}_{i})}-$hybrid model (with $i\in[n]$) against malicious adversaries.

Let $\mathcal{A}$ be the real world adversary. Ideal world adversary $\mathcal{S}$ that simulates the view of $\mathcal{A}$ is as follows: Let $\mathcal{S}^{\prime}$ be the ideal world adversary or the semi-honest simulator for $\pi$ (this exists because $\pi$ is semi-honest secure). $\mathcal{S}$ picks $\{(\mathsf{vk}_{k},\mathsf{sk}_{k})\}_{k\in[n]}$ and gives $\{\mathsf{vk}_{k}\}_{k\in[n]}$ to $\mathcal{A}$. We denote a corrupt party by $P_{i}$ and honest party by $P_{j}$. Next, when $\mathcal{A}$ invokes an instance of $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{i},\mathsf{sk}_{i})}$ on command $\mathsf{Commit}$ for a corrupted party $P_{i}$, $\mathcal{S}$ simulates the correct behavior of $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{i},\mathsf{sk}_{i})}$. Also, $\mathcal{S}$ sends correctly generated tokens $\{\mathcal{T}^{(j)}_{\pi^{*}}\}$ for all honest parties to $\mathcal{A}$. When $\mathcal{S}$ receives token from $\mathcal{A}$ corresponding to a corrupted party $P_{i}$, it checks it against $\pi^{*}$ and $\mathsf{vk}_{i}$. It aborts if verification fails. When $\mathcal{A}$ invokes $\mathcal{F}_{\textrm{\tiny{attest}}}^{(\mathsf{vk}_{i},\mathsf{sk}_{i})}$ with $x_{i}$, $\mathcal{S}$ stores it as input of $P_{i}$. When $\mathcal{A}$ commits to inputs of all corrupt parties, $\mathcal{S}$ sends these to $\mathcal{F}_{\textrm{\tiny{mpc}}}^{f}$ to learn output $y$. It sends inputs of corrupt parties and outputs $y$ to $\mathcal{S}^{\prime}$ that generates the view of the adversary in the semi-honest protocol, that contains the randomness for all corrupt parties as well as the transcript of the protocol. Using this, it is easy for $\mathcal{S}$ to simulate the view of $\mathcal{A}$ in the rest of the protocol. The indistinguishability of the adversary’s view in real and ideal executions follows from the semi-honest security of $\pi$. ∎