MLCapsule: Guarded Offline Deployment of Machine Learning as a Service

1 INTRODUCTION

• MLaaS offers convenient access to models, but server queries raise input-privacy and network-exposure concerns, while client-side deployment risks exposing models and enabling unrestricted queries.The introduction also notes the computational overhead of encryption for state-of-the-art deep models.Source: §1 · p. 1

1.1 Our Contributions

• MLCapsule keeps the model and computation secret during client-side execution while aiming to preserve provider control, intellectual-property protection, pay-per-query operation, and user data privacy.The data stays on the client, enabling offline execution.Source: §1.1 · p. 2
• ML model secrecy formalizes local deployment by requiring that a client can simulate MLCapsule using only a server-side model API.Under this definition, an attack on MLCapsule can also be performed against the server-side API.Source: §1.1 · p. 2
• The proof-of-concept uses Intel SGX and modular MLCapsule layers that decrypt provider-provisioned weights and execute standard ML layers inside an isolated execution environment.The implementation evaluates VGG-16 and MobileNet and compares convolution and dense layer execution with standard implementations.Source: §1.1 · p. 2
• MLCapsule integrates defenses against reverse engineering, membership inference, and model stealing, with the paper reporting negligible computation overhead.The authors demonstrate two proposed defenses and use a previously proposed model-stealing defense.Source: §1.1 · p. 2

2.1 Model Secrecy and Data Privacy

• Local inference keeps user data on the device and avoids network communication with the provider, eliminating attacks due to that communication.The requirements also call for protecting provider intellectual property and enabling pay-per-query access.Source: §2.1 · p. 2
• A client-side white-box model could expose private parameters and allow unlimited queries, so MLCapsule aims to make client-side deployment indistinguishable from server-side access.The paper treats model architecture as public and parameters as private, while noting that architecture protection could be added using code-privacy tools.Source: §2.1 · p. 2

2.2 Protection against Advanced Attacks

• The threat model includes model stealing, reverse engineering, and membership inference through black-box queries, and requires defenses that integrate into MLCapsule.The cited prior work is described as showing that standard MLaaS cannot prevent these attacks.Source: §2.2 · pp. 2–3

3.1 SGX

• SGX enclaves isolate code and data, support sealing and attestation, and have an application memory limit of 90 MB; the paper also notes software side-channel attacks and rollback vulnerability.The authors state that the then-current SGX generation should not be used in practice because a demonstrated attack compromises the system; counters or distributed software strategies can prevent rollback.Source: §3.1 · p. 3

3.2 Definition for SGX-like Hardware

• The hardware abstraction models enclave setup, loading, execution, attested execution, and quote verification, with hidden enclave state and attestations that third parties can verify.The paper adopts Fisch et al.’s abstraction, focusing on remote attestation for its instantiation.Source: §3.2 · pp. 3–4
• Remote-attestation unforgeability is framed as a challenger–adversary game in which security means no adversary wins with non-negligible probability.The experiment gives the adversary access to hardware operations and checks whether it can produce a valid quote not already recorded by the challenger.Source: §3.2 · p. 4

3.3 Public Key Encryption

• A public-key encryption scheme comprises key generation, encryption, and decryption, with correctness requiring decryption of an encryption to recover the message.The background also defines chosen-plaintext indistinguishability using an adversary’s advantage in the Figure 1 experiment.Source: §3.3 · p. 4

SGX for ML

• Prior SGX-for-ML systems address oblivious access, training, or split inference; MLCapsule is presented as the first offline-deployment system coupled with defenses against state-of-the-art black-box attacks.The comparison names Slalom and split-network work as related approaches.Source: §4 · p. 4

Cryptographic Solutions for ML Models

• Homomorphic encryption can protect inputs and outputs but is described as inefficient for deep models and unsuitable for transparent model defenses, while not providing the paper’s notion of perfect privacy.The cited passage contrasts these approaches with MLCapsule’s client-side execution.Source: §4 · pp. 4–5

Watermarking ML Models

• Watermarking passively supports model ownership claims, whereas MLCapsule is distinguished by client-side deployment that resembles server-side access and can actively mitigate attacks.The passage identifies watermarking approaches by Adi et al. and Zhang et al..Source: §4 · p. 5

Model Stealing and Reverse Engineering; Membership Inference

• The paper distinguishes API-based model stealing from reverse engineering of model details and membership inference, and describes defenses for each within MLCapsule.It proposes a reverse-engineering defense, a membership-inference defense, and evaluates the feasibility of Prada for model stealing.Source: §4 · p. 5

5 MLCAPSULE

• MLCapsule targets local classification of a provider’s pre-trained model while retaining provider control over the model.The section presents simplicity as the scheme’s main advantage.Source: §5 · p. 5

5.1 Overview

• The design assumes an isolated execution environment, public knowledge of the network design, and protection for its trained weights and biases.The discussion focuses on deep networks but says the approach generalizes to linear models.Source: §5.1 · p. 5
• During setup, the user attests that the enclave is running before the provider supplies secrets; the enclave seals them for later use without further provider communication.The user can inspect the enclave code, and classification runs locally so input data does not leave the platform.Source: §5.1 · pp. 5–6

5.2 Discussion on Requirements

• Offline local execution and inspectable secure-hardware code let users check for communication with the provider; the paper concludes this protects user input.The user can stop execution if the inspected code contains a communication command with the service provider.Source: §5.2 · p. 6
• A query threshold enforces a fixed paid query count, but does not support fine-grained purchases; a signed, lossy collision-resistant function is offered as an alternative.The alternative requires a service-provider signature under a function of queried data sent in the clear.Source: §5.2 · p. 6
• The enclave’s isolation is intended to give users no greater model-stealing advantage than access to a server-side API.Source: §5.2 · p. 6

6.1 Formalization of MLCapsule

• MLCapsule formalizes Train, Obtain, Provide, and Classify, with correctness requiring local classification to match the original model’s output.Model secrecy requires a simulator such that an adversary’s distinguishing advantage between real and simulated interactions is negligible.Source: §6.1 · p. 7

6.2 Instantiation of MLCapsule

• The instantiation has the user run a program in secure hardware, return its public key and attestation, and receive encrypted model secrets from the provider.The enclave decrypts the model secret for classification inside the hardware.Source: §6.2 · p. 7

6.3 Security

• The concrete instantiation is model secure if its public-key encryption is indistinguishable under chosen-plaintext attacks and its hardware functionality has unforgeable remote attestation.Source: §6.3 · p. 7
• The proof uses a game sequence: remote-attestation unforgeability rules out valid requests without running the program, and encryption security supports replacing the model-secret ciphertext with an encryption of zero.The proof also replaces oracle responses with direct model outputs, which it says preserves the adversary’s advantage by correctness.Source: §6.3 · pp. 7–8

7.1 Implementation

• MLCapsule layers accept standard layer inputs and sealed weights, unseal the weights inside the enclave, and pass them to standard layer functions.The modular layers use ECALLs and were implemented in C++; evaluation focused on inference because setup attestation and decryption are standard tasks.Source: §7.1 · pp. 8–9, §7 · p. 8

7.2 Evaluation

• Convolutional-layer overhead averaged around 1.2 and peaked at 2.3, while depthwise separable convolution was comparable to standard layers.Applying activation functions or pooling after convolution did not significantly affect execution time.Source: Table 2 · p. 9, §7.2 · p. 9
• Around 2-times overhead: VGG-16 and MobileNet classification with MLCapsule took about twice as long as standard execution without SGX protection.Source: Table 3 · p. 9, §7.2 · p. 10
• Layer timing includes memory allocation, copying sealed data into the enclave, unsealing, computation, and memory release.Source: §7.1 · p. 9

7.1 Implementation

• A 90 MB memory limit caused performance degradation for a 4096×4096 dense layer; encrypting data in 2 MB chunks reduced memory use for data requiring over 48 MB.The layer's execution time fell from 1 s to 0.097 s after optimization.Source: §7.1 · p. 9

7.2 Evaluation

• Dense-layer overhead reached at most 25 times across kernel dimensions; without -O3 optimization, overhead was around a factor of 3.The authors attribute the performance increase to optimized compilation.Source: Table 1 · p. 9, §7.2 · p. 10

8.1 Detecting Reverse Engineering

• The reverse-engineering defense trains a classifier on crafted kennen-io inputs versus benign MNIST images, then denies service locally when it detects a malicious input.The test used 4,500 crafted and 4,500 benign training images; the tested evaluation set contained 500 of each, disjoint from training.Source: §8.1 · p. 10
• 100% classifier accuracy detected every tested kennen-io attack on its first malicious example, with no benign MNIST sample denied.The classifier added 0.832 ms per image; the authors caution that kennen-io is not stealthy and future attacks may be harder to detect.Source: §8.1 · p. 10

8.2 Detecting Model Stealing

• Prada detects model stealing by tracking query-set growth: benign queries generally grow the set, whereas malicious samples generally do not.The measured overhead is below 0.1 seconds for less than 45 MB of data, then rises sharply as enclave memory operations increase.Source: §8.2 · p. 10
• With Prada and a 3,000-query detection set, GTSRB queries were delayed by almost 2 seconds, or a factor of five; CIFAR and MNIST delays were around 35 ms.The cited Table 4 reports overhead for Prada with 3,000 samples, enough to query 5,000 benign samples.Source: §8.2 · p. 11, Table 4 · p. 11

8.3 Membership Inference

• The membership defense adds more noise to low-entropy posteriors, with c controlling noise magnitude, and publishes the noised posterior without modifying the model.The noise is mixed with the posterior using the training-data class distribution as the prior; the predicted labels stay the same.Source: §8.3 · pp. 11–12
• At c near 0.5, membership-inference AUC fell from 0.97 to almost 0.5 while target-model accuracy remained unchanged.At that setting, JSD and the correct-class posterior difference remained below 0.25; the defense added 0.026 ms to computation.Source: §8.3 · p. 12

9 DISCUSSION

• The formal security result does not cover side-channel attacks such as timing attacks, and evasion attacks remain a difficult-to-defend threat.The authors state that current state-of-the-art defenses are applied before inference and can be integrated into MLCapsule without overhead.Source: §9 · p. 12
• Because an enclave is tied to a person and setting up a fresh one takes effort, providers may identify and expel clients found running attacks.Source: §9 · p. 12

• MLCapsule provides model security and control at the level of conventional server-side MLaaS while keeping user data on the client.Source: §10 · pp. 12–13
• MLCapsule supports pay-per-view monetization and advanced model protections, including against model stealing and reverse engineering.Source: §10 · p. 13
• Because several inference attacks rely on repeated queries, MLCapsule can mediate direct or indirect access to the model.The paper names membership inference, reverse engineering, and adversarial perturbations as examples of such attacks.Source: §10 · p. 13