Slalom: Fast, Verifiable and Private Execution of Neural Networks in Trusted Hardware

Abstract: As Machine Learning (ML) gets applied to security-critical or sensitive domains, there is a growing need for integrity and privacy for outsourced ML computations. A pragmatic solution comes from Trusted Execution Environments (TEEs), which use hardware and software protections to isolate sensitive computations from the untrusted software stack. However, these isolation guarantees come at a price in performance, compared to untrusted alternatives. This paper initiates the study of high performance execution of Deep Neural Networks (DNNs) in TEEs by efficiently partitioning DNN computations between trusted and untrusted devices. Building upon an efficient outsourcing scheme for matrix multiplication, we propose Slalom, a framework that securely delegates execution of all linear layers in a DNN from a TEE (e.g., Intel SGX or Sanctum) to a faster, yet untrusted, co-located processor. We evaluate Slalom by running DNNs in an Intel SGX enclave, which selectively delegates work to an untrusted GPU. For canonical DNNs (VGG16, MobileNet and ResNet variants) we obtain 6x to 20x increases in throughput for verifiable inference, and 4x to 11x for verifiable and private inference.

Reviews and author responses:

In response to the below reviews, we have made the following main changes to our paper:

- As suggested by the second reviewer, we have moved some of the content from the Appendix back to the main body. These include the microbenchmark results, as well as a discussion of the challenges in extending Slalom to DNN training.

- We have included new results for evaluating Slalom on ResNet models. This showcases Slalom's broad applicability to more complex models than the feed-forward architectures we had evaluated so far. We also illustrate Slalom's graceful scaling to very deep networks (e.g., the 152-layer ResNet with a 4.6x increase in private and verifiable throughput over the baseline).

- We have unified all figures to primarily display Slalom's *savings* over the baseline, rather than the raw throughput in images per second.

We thank the reviewer for the extremely positive review of our paper. As noted in our responses to the other reviewers, we have made some editorial changes to the paper (mainly moving some experiments from the Appendix into the main body), and we have included additional results for ResNet architectures as suggested by the second reviewer.

To answer your insightful questions:

1. This is a great question, and such a system has recently been suggested in [1] (see below), which we now reference in our writeup. Probably the main differentiator is that in such a system, every single user requires trusted hardware (e.g., a recent Intel CPU), whereas in the cloud-outsourcing scheme which we and others have considered, only the server requires specialized hardware. 
Using Slalom's techniques in a client-side execution might work, but the downside is that our algorithm assumes that the untrusted host has knowledge of the computed model. 
One client-side application where Slalom might come in useful is for guaranteeing integrity in Federated Learning. Here, each client evaluates a model on their own data, and the server may need some guarantees that those computations were performed correctly.

2. We have added a note for this, thanks.
    
3. Our evaluation primarily focuses on throughput. Low latency is also desirable of course, but this might require using a different untrusted processor as GPUs tend to be outperformed by CPUs when operating on single-element batches. In our experiments, we evaluate batches of images (around 16 images) on the GPU, and then verify a single image at a time in the TEE. By replacing the GPU with a high-end CPU, we could thus also achieve low latency using Slalom.
    
4. VGG16 has the particularity that the feature extraction part (i.e., without the dense layers) makes up roughly 95% of the model's computation, but uses only maybe 5% of the weights (simply because VGG16's first dense layer is huge). So outsourcing only the dense layers would unfortunately leave the client to do most of the work.
What we had in mind here was the use of VGG16's features as a building block for other models (e.g., object detection with SSD). We performed some preliminary experiments with SSD and a VGG16 backend and found that Slalom could also achieve around 10x speed improvements for such object-detection tasks.

5. Indeed, as you correctly note, the pre-computation takes the same time as the baseline computation in the TEE. The results in Section 4.3 do not include this pre-computations as we would of course not obtain any savings by doing so.
A similar approach is taken by many Cryptographic approaches to secure outsourcing (of ML tasks or other computations). The rationale is that the pre-computation is data-independent and can be performed offline (e.g., during periods of low system use) and thus doesn't count towards the cost of the online throughput (or latency as discussed above). 

[1] MLCapsule: Guarded Offline Deployment of Machine Learning as a Service, Hanzlik et al., https://arxiv.org/abs/1808.00590

We thank the reviewer for the positive review and insightful comments. It is encouraging to hear that our paper was easy to read for someone outside the field of HW security and privacy.
    
We have made some changes to our manuscript to better illustrate the limitations and scalability of our approach. We have moved our micro-benchmarks from the Appendix to the main body, as suggested by the second reviewer. These benchmarks show that as the computation performed in a layer gets larger (e.g., more channels in a convolution), the savings incurred by Slalom increase!
In principle, Slalom scales linearly with the number of layers added to a model, so long as all the pre-computed values do not exceed SGX's memory limits. To illustrate, we have experimented with the family of ResNet architectures, that range from 18 to 152 layers (and 44MB to 230MB of weights). For five different models (18, 34, 50, 101 and 152 layers), Slalom provides large savings in throughput (4.4x-14.4x) and the savings tend to be larger for larger networks. We have added these results to our manuscript and we believe they illustrate Slalom's applicability and scalability to large models. In particular, the 152-layer ResNet model is among the deepest and most accurate models trained on ImageNet to date.
Lastly, we have also moved a section from the Appendix to the main body wherein we discuss some limitations and challenges with extending Slalom to DNN training. The main issues here are with weights changing during training which hinders quantization, pre-computation of Freivalds' checks, as well as pre-computed blinding factors for privacy.
    
Regarding the usefulness of integrity checks, these are also meant as a security guarantee. The threat model we consider here is that the server might *intentionally* compute incorrect values and send these back to the client. The SafetyNets paper by Ghodsi et al. contains a good discussion of reasons why a client may want integrity guarantees from the server. One example is a "model-downgrade attack", where the server runs a cheaper (i.e., smaller) model than advertised, to minimize costs. More generally, it is commonly agreed upon in the cryptographic community that privacy without integrity is an insufficient guarantee (e.g., by tampering with a client's results and observing the side effects, a server might later learn something about the client's data).

For quantization, we simply assume that inputs are standard RGB images in the range [0, 255]. We then choose the quantization scales for inputs and weights so that none of the intermediate values in the network ever grow beyond p=2^23. The inputs of all layers after the first one are simply assumed to lie in the interval [-p/2, p/2].

We thank the reviewer for the positive review and insightful comments.

We followed the suggestion to make use of 10 pages of content (we originally found the ICLR Call for Papers to be somewhat unclear in this regard). We have moved parts of the Appendix into the main body, i.e., the SGX microbenchmarks as well as our discussion of challenges with extending Slalom to DNN training.

We agree that the notation PR_{s \overset{s}{\gets}\mathbb{S}^{n}}[...] is overly verbose and we have removed the redundant in our updated manuscript. We have also added a definition for a negligible function.
    
We followed the great suggestion to apply Slalom to more complex architectures. We have added experiments with ResNet models which make use of residual connections (handling concatenation layers would require similar changes to our framework). Extending Slalom's integrity checks (the left part in Figure 1) is quite trivial. The TEE simply applies Freivalds' algorithm to every linear operator and makes sure that it performs appropriate "book-keeping" of which layers' outputs correspond to which other layers' inputs. For privacy (the right part in Figure 1), things can get a bit more complicated as the TEE and GPU have to interact for each linear layer. For a residual layer, the TEE and GPU essentially run Slalom on both "paths" of the layer one after the other. The TEE saves intermediate results in its memory and then merges the results. The same would work for concatenation layers. Our results with ResNets are on par with those obtained with VGG16 and MobileNet. We tried different variants (18, 34, 50, 101 and 152 layers), and achieve 6.6-14.4x speedups for integrity and 4.4x-9.0x speedups with additional privacy.

In this paper, the authors consider solving three ML security related challenges that would primarily arise
in the cloud based ML model. Namely, they consider the setting where a client wishes to obtain predictions
from an ML model hosted on a server, while being sure that the server is running the model they believe is being run
and without the server learning nothing about their input. Additionally, the server wishes for the user to learn 
nothing about the model other than its output on the user's input. To solve this problem, the authors introduce a
new scheme for running ML algorithms in a trusted execution environment. The key idea is to oursource expensive
computation involved with forwarding images through a model to an untrusted GPU in a way that still allows for
the TEE to verify the integrity of the GPU's output. Because the authors' method is able to utilize GPU computing,
they achieve substantial speed-ups compared to methods that run the full neural network in trusted hardware.

Overall, I found the paper to be very well written and easy to digest, and the basic idea to be simple. The 
authors strike a nice balance between details left to the appendix and the high level overview explained in
the paper. At the same time, the authors' proposed solution seems to achieve reasonably practicable performance
and provides a simple high-throughput solution to some interesting ML security problems that seems readily
applicable in the ML-as-a-cloud-service use case. I only have a few comments and feedback.

I would recommend the authors use the full 10 pages available by moving key results from the appendix to the main
text. At present, much of the experimental evaluation performed is done in the appendix (e.g., Figures 3 through 
5). 

The notation PR_{s \overset{s}{\gets}\mathbb{S}^{n}}[...] is not defined anywhere as far as I can tell
before its first usage in Lemma 2.1. Does this just denote the probability over a uniform random draw of
s from \mathbb{S}? If so, I might recommend just dropping the subscript: A, B, and C being deterministic
makes the sample space unambiguous. "negl(\lambda)" is also undefined. 

In section three you claim that Slalom could be extended to other architectures like residual networks.
Can you give some intuition on how straightforward it would be to implement operations like concatenation
(required for DenseNets)? I would expect these operations could be implemented in the TEE rather than 
on the coprocessor and then verified. However, the basic picture on the left of Figure 1 may then change,
as the output of each layer may need to be verified before concatenation? I think augmenting the right
of Figure 1 to account for these operations may be straightforward. It would be interesting to see
throughput results on these networks, particularly because they are known to substantially outperform
VGG in terms of classification performance.

The authors propose a new method of securely evaluating neural networks. The approach builds upon existing Trusted Execution Environments (TEE), a combination of hardware and software that isolates sensitive computations from the untrusted software stack. The downside of TEE is that it is expensive and slow to run. This paper proposes outsourcing the linear evaluation portions of the DNN to an untrusted stack that's co-located with the TEE. To achieve privacy (i.e., the input isn't revealed to the untrusted evaluator), the approach adds a random number r to the input vector x, evaluates f(x+r) on the untrusted stack, then subtracts off f(r) from the output. This limits the approach to be applicable to only linear functions. To achieve integrity (verify the correctness of the output), the paper proposes testing with random input vectors (an application of Freivalds theorem, which bounds the error probability). The techniques for integrity and privacy works only on integer evaluations, hence the network weights and inputs need to be quantized. The paper tries to minimize degradation in accuracy by quantizing as finely as numerically allowable, achieving <0.5% drop in accuracy on two example DNNs. Overall, compared to full evaluation in a TEE, this approach is 10x faster on one DNN, and 40x to 64x faster on another network (depending on how the network is formulated).

Disclaimer: I am a complete outsider to the field of HW security and privacy. The paper is very readable, so I think I understand its overall gist. I found the approach to be novel and the results convincing, though I may be missing important context since I'm not familiar with the subject.

To me, the biggest missing piece is a discussion of the limitations of the approach. How big of a network can be evaluated this way? Is it sufficient for most common applications? What are the bottlenecks to scaling this approach?

It's also not clear why integrity checks are required. Is there a chance that the outsourcing could result in incorrect values? (It's not obvious why it would.)

Lastly, a question about quantization. You try to quantize as finely as possible (to minimize quantization errors) by multiplying by the largest power of 2 possible without causing overflow. Since quantization need to be applied to both input and network weights, does this mean that you must also bound the scale of the input? Or do you assume that the inputs are pre-processed to be within a known scale? Is this possible for intermediate outputs (i.e., after the input has been multiplied through a few layers of the DNN)?

Pros:
- Simple yet effective approach to achieve the goals laid out in the problem statement
- Clearly written
- Thorough experiments and benchmarks
- Strong results

Cons:
- No discussion of limitations
- Minor questions regarding quantization and size limits

Disclaimer: reviewer is generally knowledgeable but not familiar with the subject area.


Given the growing interest in building trust worthy and privacy protecting AI systems, this paper demonstrates a novel approach to achieve these important goals by allowing a trusted, but slow, computation engine to leverage a fast but untrusted computation engine. For the sake of protecting privacy, this is done by establishing an additive secret share such that evaluation on one part of the share is performed offline and the computation on the other part of the share is performed on the untrusted engine. To verify the correctness of the computation on the untrusted server, a randomized algorithm is used to sample the correctness of the results. Using these techniques, the authors demonstrate an order of magnitude speedup compared to running only on the trusted engine and 3-4 orders of magnitude speedup compared to software-based solutions.

Overall this is a strong paper which presents good ideas that have influence in ML and beyond. I appreciate the fact that the authors are planning to make their code publicly available which makes it more reproducible. Below are a few comments/questions/suggestions 

1.	This papers, and other papers too, propose mechanisms to protect the privacy of the data while outsourcing the computation on a prediction task. However, an alternative approach would be to bring the computation to the data, which means performing the prediction on the client side. In what sense is it better to outsource the computation? Note that outsourcing the computation requires both complexity on the server side and additional computation on the client side (encryption & decryption).
2.	You present the limitations of the trust model of SGX only in the appendix while in the paper you compare to other techniques such as Gazzelle which have a different trust model and assumption. It makes sense to, at least, hint the reader on these differences. 
3.	In section 2.2: “has to be processed with high throughput when available” is it high throughput that is required or low latency?
4.	In Section 4.3: in one of the VGG experiment you computed only the convolution layers which, as you say, are commonly used to generate features. In this case, however, doesn’t it make more sense that the feature generation will take place on the client side while only the upper layers (dense layers) will be outsourced?
5.	In section 4.3 “Private Inference” : do you include in the time reported also the offline preprocessing time? As far as I understand this should take the same amount of time as computing on the TEE.


Meta-review: The authors propose a new method of securely evaluating neural networks. 

The reviewers were unanimous in their vote to accept. The paper is very well written, the idea is relatively simple, and so it is likely that this would make a nice presentation.

Decision: accepted-oral-papers