Source-linked AI summary

Chiron: Privacy-preserving Machine Learning as a Service

Tyler Hunt, Congzheng Song, Reza Shokri, Vitaly Shmatikov, Emmett Witchel

arXiv:1803.05961v1cs.CR

TL;DR

Existing ML-as-a-service requires users to disclose training data, even though providers commonly keep model design and training details proprietary. Chiron combines SGX enclaves with Ryoan confinement to protect data while preserving black-box service operation, and its evaluated training performance and model accuracy are practical for common uses. The system also supports distributed training across concurrent enclaves.

  • Problem

    Existing ML-as-a-service platforms require users to reveal training data to providers, creating a barrier for sensitive datasets while providers keep models and algorithms proprietary.

  • Method

    Chiron runs a standard ML toolchain in SGX enclaves and confines untrusted provider model-creation code with Ryoan while supporting enclave coordination through a parameter server.

  • Results

    Chiron preserves trained-model accuracy on ImageNetLite while slowing training by 16%, and evaluates convergence, scalability, and performance on CIFAR and ImageNet.

  • Takeaways & Limitations

    Chiron enables data holders to use outsourced ML without disclosing training data while retaining providers’ private models, configuration parameters, and training algorithms.

  • Takeaways & Limitations

    Chiron inherits SGX side-channel limitations, including leakage through cache accesses, page accesses, and execution time.

Abstract

from arXiv · show

Major cloud operators offer machine learning (ML) as a service, enabling customers who have the data but not ML expertise or infrastructure to train predictive models on this data. Existing ML-as-a-service platforms require users to reveal all training data to the service operator. We design, implement, and evaluate Chiron, a system for privacy-preserving machine learning as a service. First, Chiron conceals the training data from the service operator. Second, in keeping with how many existing ML-as-a-service platforms work, Chiron reveals neither the training algorithm nor the model structure to the user, providing only black-box access to the trained model. Chiron is implemented using SGX enclaves, but SGX alone does not achieve the dual goals of data privacy and model confidentiality. Chiron runs the standard ML training toolchain (including the popular Theano framework and C compiler) in an enclave, but the untrusted model-creation code from the service operator is further confined in a Ryoan sandbox to prevent it from leaking the training data outside the enclave. To support distributed training, Chiron executes multiple concurrent enclaves that exchange model parameters via a parameter server. We evaluate Chiron on popular deep learning models, focusing on benchmark image classification tasks such as CIFAR and ImageNet, and show that its training performance and accuracy of the resulting models are practical for common uses of ML-as-a-service.

1. Introduction

ML-as-a-service gives data holders access to advanced prediction without requiring their own expertise or infrastructure, but conventional services expose training data and preserve proprietary models through black-box access. Chiron addresses both concerns by confining provider code while retaining provider control over model design and supporting concurrent enclave training.

  • Modern ML’s accuracy motivates data holders, but configuration complexity and scarce expertise make deployment difficult for non-experts.
  • Conventional ML-as-a-service exposes sensitive training data to providers, discouraging owners from using services for confidential datasets.
  • Commercial services commonly hide training algorithms and models, giving customers black-box API access while protecting provider intellectual property.
  • Chiron enables outsourced training without revealing users’ training data, while allowing providers to choose and configure models adaptively.
  • Ryoan confines provider code inside an SGX-backed enclave, preventing data exfiltration while users verify the sandbox and generic ML toolchain.
  • Chiron supports concurrent training through a parameter server and data-oblivious channels, and evaluates convergence, scalability, and performance on CIFAR and ImageNet.

2. Background

The background introduces supervised ML models, iterative training, deep-learning parallelism, symbolic computation, and black-box ML services. Chiron preserves the separation between proprietary model design and generic model training while relying on hardware protections with known rollback limitations.

  • 2.1 Machine learning: An ML model maps inputs to target outputs using parameters, and supervised training optimizes those parameters against labeled data while controlling overfitting.
  • 2.1 Machine learning: Deep learning uses layered nonlinear mappings and can scale through concurrent models that exchange parameters via a parameter server.
  • 2.1 Machine learning: Training repeatedly processes data batches, computes loss, and updates parameters until convergence, a fixed iteration count, or acceptable validation accuracy.
  • 2.2 Symbolic computation: Symbolic ML libraries represent models as computational graphs whose operations can be optimized and compiled into executable code.
  • 2.2 Symbolic computation: Theano examples define logistic regression and a two-layer neural network by specifying parameters, losses, and update functions for training.
  • 2.3 Machine learning as a service: ML-as-a-service exposes convenient training APIs while often hiding model type and learning-algorithm implementation details from users.
  • 2.3 Machine learning as a service: Chiron preserves proprietary model design separately from generic batch-based training, while SGX persistence lacks freshness guarantees and requires additional rollback defenses.

3. Threat Model

Chiron assumes an untrusted platform and protects users’ training data while preserving the provider’s black-box ML-service model. Its threat model excludes denial of service and recognizes unresolved risks from model outputs and SGX-related channels.

  • Training data remains confidential even when the provider defines the model architecture, loss, optimization functions, and hyper-parameters.
  • Chiron assumes the entire platform, including the operating system and hypervisor, is untrusted.
  • By default, users receive no information about model architecture or training, matching many commercial ML-as-a-service practices.
  • Chiron relies on Ryoan sandboxing and SGX, with trust placed in public sandbox and toolchain components rather than the hidden model.
  • Denial of service is outside the threat model because providers can refuse training, skip it, or return an inaccurate model.
  • Black-box model access can leak training data, while the threat remains poorly understood and lacks generic mitigations.

4. Design

Chiron confines provider-controlled model creation inside Ryoan while keeping a generic ML toolchain trusted and accessible through controlled interfaces. Distributed enclaves coordinate training through a parameter server, and users receive only model access.

  • Chiron’s training enclave combines Ryoan sandboxing, trusted administrative code, and a standard ML toolchain such as Theano.
  • Provider code selects model architecture, loss, optimization, hyper-parameters, and input transformations, potentially adapting choices to user data.
  • The ML toolchain compiles the provider’s model description into executable, model-specific training code inside the enclave.
  • Provider code feeds transformed user data to the training code, while SGX and Ryoan prevent it from observing model state.
  • Distributed training uses a dedicated parameter-server enclave that exchanges model parameters with training enclaves working on separate data shards.
  • Users attest training enclaves and verify that they connect to the same parameter server before sending data.
  • The training enclave exposes controlled interfaces for reading data, building and training models, examining and testing models, and completing training.
  • An alternative that sandboxes generated toolchain code could reduce the trusted computing base but may impose execution overheads as high as 43%.

5. Implementation Issues

Chiron adapts enclave compatibility, compilation, parameter coordination, and memory handling to support ML training within SGX. Its prototype assumes each data shard fits in enclave memory, with streaming available when it does not.

  • Chiron uses an SGX compatibility layer in libc to marshal system calls, unmarshal results, and protect against known Iago attacks.
  • Chiron replaces gcc with libclang and LLVM’s execution engine because enclave compilation cannot write files without leaking model-building activities.
  • The parameter server applies application-level encryption and aggregates received parameter updates in memory before returning updated values.
  • Inconsistent platform time can deny service, but the parameter server is designed not to leak data through a timing channel.
  • The prototype assumes each data shard fits in enclave memory, although current SGX hardware restricts enclave memory to 128MB.
  • When data exceeds memory, trusted code streams configurable chunks at a fixed rate, while efficient insufficient-memory policies remain future work.

6. Limitations

Chiron remains exposed to SGX and Chiron-specific side channels, lacks GPU support, and cannot guarantee protection against data leakage through model behavior. These constraints bound its deployment scope and confidentiality guarantees.

  • Ryoan blocks software-interface exfiltration but inherits SGX limitations involving processor monitoring and covert or side channels.
  • SGX page-table manipulation can expose enclave page-level traces that application-specific attacks may use to reconstruct fine-grained secrets.
  • Users cannot verify that hidden provider model-setup code is data-oblivious, limiting software mitigation of page-based side channels.
  • The prototype does not mitigate timing channels encoded through training iterations, coordination delays, training time, refusal to terminate, or inaccurate outputs.
  • Chiron cannot use GPUs because current GPUs lack the hardware-supported trusted execution environments on which it fundamentally relies.
  • Protecting user data processed on a GPU from the GPU operator is not addressed by techniques known to the authors.

7. Evaluation

Chiron is evaluated on CIFAR and ImageNetLite using SGX performance modeling and distributed training configurations. It incurs moderate training overhead, preserves ImageNetLite accuracy, and keeps query overhead below 1%, while parameter-exchange choices affect accuracy.

  • Evaluation setup: The SGX performance model incorporates enclave-exit penalties, including measured explicit exits of 3.9 microseconds and involuntary exits of 3.14 microseconds.Page faults, system calls, interrupts, TLB flushes, and enclave-boundary argument copying contribute to modeled overhead.
  • CIFAR experiments: Up to 6%: fixed-rate parameter communication can reduce test accuracy, while higher communication rates produce more accurate models.The accuracy decrease is attributed to gradient staleness in asynchronous distributed learning.
  • CIFAR experiments: 4–20%: Chiron’s ideal parameter-exchange policy lags baseline training performance.Most overhead occurs during enclave training; 90% or more of enclave exits arise from page faults, and exchange policies change performance little.
  • ImageNetLite experiments: 16%: Chiron slows ImageNetLite training with 16 enclaves while preserving the trained model’s accuracy.The experiment uses the one-third Avg exchange policy, selected because CIFAR experiments showed it provided the best model accuracy.
  • ImageNetLite experiments: Less than 1%: Chiron’s performance impact on model queries.Queries must be invoked through Chiron.
  • Cost analysis: ImageNetLite outsourced training raises compute cost from $36.19 to $43.12, while network cost ranges from $7.67 to $23.00 by exchange policy.The cited baseline costs $36.19 for compute and $7.67 for network I/O.

8. Related Work

Related work spans secure SGX environments, side-channel attacks, cryptographic ML, and leakage from trained models. Chiron differs by protecting user data from an untrusted service-provider platform while keeping provider models and algorithms secret.

  • Secure ML environments: Collaborative learning typically exposes model architecture and algorithms, whereas ML-as-a-service keeps them secret and proprietary to the provider.Data-oblivious learning can address page-fault side channels, but clients must verify the entire enclave codebase.
  • Secure ML environments: CQSTR confines untrusted ML code under a trusted platform operator, while Chiron protects user data from an untrusted platform operator.The systems address opposite trust relationships.
  • Cryptographically protected ML: Cryptographic techniques have enabled privacy-preserving simple classifiers and inference on encrypted data, but practical encrypted training of deep neural networks is not established.The related-work discussion specifically identifies ImageNet-scale deep-network training as a performance challenge.
  • Model leakage: Black-box model access can enable membership inference, and malicious training algorithms can make models leak substantial portions of their training data.Differentially private learning is described as a mitigation for training-dataset leakage.
  • Model leakage: Chiron’s threat scenario assumes the dataset owner and model user are the same and that no other party, including the service operator, receives model-query access.This assumption corresponds to many common ML-as-a-service uses.
  • Secure ML environments: Existing SGX systems support legacy applications or protected data processing but generally assume all enclave code is trusted; Chiron protects data from untrusted code.This distinction addresses outsourced ML settings in which provider code is not public to users.
  • Side-channel attacks on SGX: SGX protections remain vulnerable to page-fault, bus-monitoring, cache, power, and timing side channels.Processor monitoring units and branch-history or uncore counters can also expose information about enclave execution.

9. Conclusion

Chiron enables outsourced ML without disclosing training data to service providers, while preserving the current practice of keeping models, configuration parameters, and training algorithms private.

  • Conclusion: Chiron supports privacy-preserving outsourced ML without requiring providers to disclose their models, configuration parameters, or training algorithms.This design matches current ML-as-a-service practice while protecting the user’s training data.
Loading 1803.05961v1…