PaperlayerView exact revision on arXiv

Source-linked AI summary

INTCC: A Framework for Interactive Confidential Computing

Qingzhe Bing, Kaiyuan Zhang, Yinqian Zhang

arXiv:2609.35552v1cs.CR

TL;DR

Static remote attestation does not cover the human-driven interactions required by workflows such as LLM fine-tuning and exploratory analysis. IntCC partitions interactive control from a verifiable runtime and combines proxy dispatch, information-flow control, and privacy-preserving verification; evaluations report practical overhead across real-world workloads.

  • Problem

    Remote attestation covers a TEE’s initial state, not dynamic post-launch interactions required for interactive workflows, which also create mutual distrust over data protection and workflow privacy.

    Source: §1 · p. 1

  • Method

    IntCC separates unmeasurable interaction into an Interactive Controller and mediates sensitive operations in a policy-governed Verifiable Runtime, using proxy dispatch, lattice-based information-flow control, and privacy-preserving verification.

    Source: §1 · p. 2, §3.4 · p. 5

  • Results

    < 5% overhead for LLM fine-tuning and < 17% for data analysis, while IntCC effectively thwarts data exfiltration on real-world workloads.

    Source: §1 · p. 2

  • Takeaways & Limitations

    IntCC’s evaluation supports interactive LLM fine-tuning and data analysis with practical overhead while maintaining data confidentiality and verifiable runtime compliance.

    Source: §1 · p. 2, §9 · p. 13

    Current zero-knowledge proof generation can be a bottleneck as audit frequency or deployment scale grows.

    Source: §7 · p. 12

Abstract

from arXiv · show

Confidential computing leverages Trusted Execution Environments (TEEs) to ensure the confidentiality and integrity of data in use. However, TEEs rely on remote attestation to guarantee the integrity of their initial memory state. This model is fundamentally at odds with interactive development workflows. In scenarios like LLM fine-tuning and exploratory data analysis, data processors need human-in-the-loop capabilities, including dynamic code injection, intermediate state inspection, and hyperparameter tuning, all of which inherently violate the static, one-time integrity guarantees of traditional remote attestation. To reconcile this tension, we propose the interactive confidential computing paradigm, a system architecture enabling untrusted data processors to execute dynamic, non-deterministic operations within TEEs without compromising data confidentiality. Driven by the insight that inherently unmeasurable human interaction must be excluded from the Trusted Computing Base (TCB), we logically partition the TEE into an interactive controller and a verifiable runtime. To realize this paradigm, we present INTCC, a framework featuring three key mechanisms: (1) a proxy-based dispatch system to preserve the native development experience; (2) a fine-grained information flow control mechanism based on a security lattice to prevent data leakage; and (3) a privacy-preserving verifiable execution mechanism to guarantee the runtime compliance of dynamic workflows. We implement INTCC on AMD SEV-SNP using Confidential Containers and evaluate it across diverse real-world workloads. Our experiments demonstrate that INTCC effectively balances security and interactivity, incurring a practical overhead of less than 5% for LLM fine-tuning and under 17% for data analysis relative to baseline execution.

1 Introduction

Traditional remote attestation measures a TEE’s initial state, but interactive workflows require unanticipated code, state inspection, and tuning. IntCC separates interactive control from a verifiable runtime and combines that design with confidentiality controls and privacy-preserving runtime verification.

1 Introduction

  • IntCC addresses the conflict between static TEE attestation and interactive workflows that require dynamic code injection, intermediate-state inspection, and hyperparameter tuning.These post-launch operations cannot be anticipated at launch time, while data owners and processors also distrust one another over data misuse and disclosure of proprietary workflows.Source: §1 · pp. 1–2
  • IntCC excludes unmeasurable human interaction from the TCB by separating an Interactive Controller from a Verifiable Runtime that mediates sensitive operations under a prescribed policy.Processors can use familiar ecosystems such as PyTorch, while operations on sensitive assets remain mediated by the Verifiable Runtime.Source: §1 · p. 2
  • Canonical audit evidence commits to dynamic execution traces and proves in zero knowledge that they satisfy predefined policies.This mechanism avoids disclosing the data processor’s proprietary code or plaintext execution traces.Source: §1 · p. 2
  • Three mechanisms provide native usability, confidentiality, and runtime compliance: proxy-based dispatch, lattice-based information flow control, and privacy-preserving verifiable execution.The information-flow mechanism enforces confidentiality, while verifiable execution supports runtime compliance.Source: §1 · p. 2
  • < 5% overhead for LLM fine-tuning and < 17% for data analysis, with IntCC reported to thwart data exfiltration on real-world workloads.The framework was implemented on AMD SEV-SNP using Kata Containers.Source: §1 · p. 2

2 Background

Confidential computing protects data in use through TEEs, but attestation covers the initial state rather than later human-driven interactions. LLM fine-tuning, exploratory analysis, and application diagnosis all require such interactions, which create confidentiality risks in conventional TEE workflows.

2.1 Confidential Computing

  • Remote attestation validates a CVM’s initial measured state, but cannot attest to non-deterministic post-launch interactions, leading existing frameworks to restrict external interaction.This black-box model conflicts with the iterative and observability needs of cloud-native applications.Source: §2.1 · p. 2

2.2 Application Scenarios for Interactive Confidential Computing

  • LLM fine-tuning requires runtime monitoring, hyperparameter adjustment, and sample inspection, while exposing I/O boundaries can risk leaking private training data.The passage identifies loss-curve monitoring and adjustments to learning rate or batch size as examples.Source: §2.2 · p. 3
  • Exploratory analysis and confidential-application debugging require iterative code or pipeline changes and runtime inspection, yet traditional diagnostics can expose sensitive assets.Examples include inspecting distribution summaries, stack traces, and variables.Source: §2.2 · p. 3
  • Across these scenarios, dynamic code injection, runtime observability, and non-deterministic operations conflict with traditional TEEs’ static measurement and confidentiality guarantees.The scenarios include fine-tuning, exploratory analysis, and application diagnosis.Source: §2.2 · p. 3

3 Motivation

Interactive workloads require actions that static TEE measurements cannot anticipate, creating tension between observability and measurable trust. IntCC responds with a partitioned architecture and mechanisms for compatibility, information-flow control, and privacy-preserving runtime compliance.

3.1 The Dilemma between Interactivity and Measurability

  • Interactive workloads inject unmeasured human inputs and dynamic code, so enabling interactivity conflicts with the static boundary required for TEE measurability.The resulting dilemma is whether to preserve measurable TEE security or allow interactive operations.Source: §3.1 · p. 3

3.2 System Model

  • The system model includes data owners, processors, auditors, and a cloud provider, with processors seeking interactive access while keeping their source code and execution traces proprietary.Owners require confidentiality and prevention of misuse; auditors verify compliance with owner-prescribed policies.Source: §3.2 · p. 3

3.3 Threat Model

  • The threat model treats the cloud provider and data processors as untrusted, while also protecting processor workflow privacy from auditors; it assumes TEE hardware isolation remains intact.The security goals include confidentiality of owner assets and processor intellectual property, plus runtime policy compliance and verifiability.Source: §3.3 · pp. 3–4

3.4 Design Goals and Technical Challenges

  • Logical partitioning keeps inherently unmeasurable human interaction outside the TCB and confines measurable sensitive operations to a Verifiable Runtime.The design rationale is that including unmeasurable interactive logic would invalidate the TCB’s attestation-based chain of trust.Source: §3.4 · p. 4
  • The design targets transparent compatibility, interactivity without leakage, and verifiable execution, while balancing cross-domain performance, information-flow, and privacy challenges.Traditional data copying can make partitioned execution costly; strict noninterference can limit usability; and disclosed traces can reveal proprietary workflows.Source: §3.4 · pp. 4–5

3.5 Our Solution

  • IntCC combines proxy dispatch, lattice-based information-flow control, and privacy-preserving verifiable execution to preserve usability, restrict outputs to approved declassification, and prove policy compliance.The runtime mechanism binds dynamic traces to the attested Runtime and proves compliance in zero knowledge without exposing the workflow.Source: §3.5 · p. 5

4 Framework Design

IntCC separates human-driven post-launch control from a measured runtime that governs sensitive computation. Proxies, information-flow control, and privacy-preserving verification support interaction while preserving confidentiality and runtime compliance.

4.1 Overall Architecture

  • The Controller hosts unmeasured post-launch logic outside the integrity TCB, while the attested Runtime protects private data and enforces policy as the measured root of trust.The architecture can use distinct SGX enclaves, isolated containers within one CVM, or nested TEEs.Source: §4.1 · pp. 5–6

4.2 Proxy-based Dispatch System

  • Shadow objects mirror Runtime interfaces without holding data; opaque handles route calls to the Runtime, whose results return as handles, while low-sensitivity data may be serialized.The Controller uses local syntax while the Runtime executes operations on the concrete assets.Source: §4.2.1 · p. 6, §4.2.2 · p. 6

4.3 Security Lattice Based Information Flow Control

  • The security lattice orders labels from L through N, A, and T to H; operations assign outputs the inputs’ least upper bound to prevent unauthorized downgrading.Join handles information-flow convergence, while meet is reserved for policy composition.Source: §4.3.1 · p. 7

4.3.2 Explicit Declassification and Boundary Audits.

  • Sensitivity can be lowered only through centrally registered, pre-audited declassification functions; the gRPC response is the sole exit, and only L-labeled values leave as concrete data.Other container-level sinks, including outbound networking and arbitrary host file I/O, are disabled.Source: §4.3.2 · p. 7

4.4 Privacy-Preserving Verifiable Execution Mechanism

  • The Runtime commits its canonical interaction trace in the hardware attestation report and proves in zero knowledge that it is committed and IFC-compliant without revealing the trace.Owners or auditors verify policy compliance; processors can compare their local trace with the commitment to check authenticity and detect omission or substitution.Source: §4.4.1 · p. 8, §4.4.2 · p. 8
  • Verification establishes runtime policy compliance, not full-program correctness or whether an arbitrary workload fulfilled unstated processor intent.The scope relies on remote attestation to establish that the trace came from the genuine Runtime and reflects its execution.Source: §4.4.3 · p. 8

5 Implementation

IntCC is implemented in Python on AMD SEV-SNP with Confidential Containers, using dynamic dispatch, runtime policy enforcement, and trace-based verification. Its implementations support interactive machine-learning and analytical stacks with limited framework-extension effort.

5 Implementation

  • The Python implementation comprises approximately 3,200 LoC and runs on AMD SEV-SNP using Confidential Containers; supporting new complex orchestration frameworks requires no more than 200 LoC.Python was chosen to support dynamic computational graphs, runtime reflection, and dynamic object instantiation.Source: §5 · p. 8
  • Controller-side interception marshals calls into Protobuf requests with opaque handles; the Runtime resolves them, executes backend operations, and registers returned objects under fresh handles.A remote reflection path forwards metadata queries and synthesizes controller-side stubs for dynamic Python libraries.Source: §5 · p. 8
  • The Runtime dispatcher joins object labels, checks each invocation against policy, denies or executes it, and applies explicit declassification rules where authorized.A response-boundary guard returns only L-labeled objects as concrete values; higher-labeled outputs remain inside the Runtime or are rejected.Source: §5 · p. 8
  • Each dynamic operation adds an IFC trace entry; the Runtime hashes the canonical trace into the attestation report and uses an SP1-based zero-knowledge backend to prove commitment and policy compliance.The verifier checks the proof against the public output and a verification key derived from the guest ELF.Source: §5 · pp. 8–9
  • IntCC supports interactive fine-tuning with PyTorch, PEFT, and LLaMA-Factory, and analytics with Dask, DuckDB, and Pandas over TPC-H.The paper reports fewer than 200 LoC of core orchestration changes to support these ecosystems.Source: §5 · p. 9

6 Evaluation

The evaluation measures IntCC’s performance overhead against a monolithic confidential baseline and tests its defenses against data theft, reconstruction, and pipeline tampering. Results show low overhead across fine-tuning and data-analysis workloads, alongside effective protection and useful privacy-preserving previews.

6.1 Performance Evaluation

  • 4.50% processing-time overhead for CNN/DailyMail, 4.55% for XSum, and 4.53% for Alpaca; Llama-3-8B and Qwen3-8B were 0.81% and 0.75% slower than the native baseline.For Pythia fine-tuning, overhead decreased with model size, reaching 0.9% for Pythia-6.9B.Source: §6.1.1 · pp. 9–10
  • Pandas incurred 6.32% end-to-end overhead, Dask 11.16%, and DuckDB 16.56% on TPC-H SF=10.The authors characterize end-to-end overhead below 17% as an acceptable and competitive trade-off for practical deployments.Source: §6.1.2 · p. 10
  • Proxy-system overhead was the largest latency component for Dask (76.3%), Pythia-6.9B fine-tuning (66.1%), and Pandas (55.8%), while zero-knowledge proving accounted for 69.5% of DuckDB overhead.The authors attribute proxy costs to coordination in gRPC worker threads; DuckDB’s low absolute penalty makes cryptographic costs proportionally dominant.Source: §6.1.3 · p. 10

6.2 Security Evaluation

  • IntCC neutralized all simulated direct-theft attempts, thwarted gradient-reconstruction attempts through DP-protected intermediate states, and detected dropped optimizer.step() requests during audit.The theft tests included printing tensors, writing files, and outbound HTTP requests; pipeline deviations produced a runtime hash mismatch against the attested commitment.Source: §6.2.1 · p. 11
  • The PII sanitization engine achieved an overall F1-Score of 0.9510 on 5,000 OntoNotes 5.0 samples.The evaluation describes sanitized previews as supporting structural understanding and code debugging while minimizing the attack surface.Source: §6.2.2 · p. 11
  • At privacy budget ε=2.0, noisy-gradient MSE stabilized at 0.7535, and the noisy 90th-percentile token length (1556) was statistically equivalent to ground truth (1539).In the max_length case study, the sanitized view led to the same example configuration, max_length=2048, as direct data access.Source: §6.2.3 · p. 12

7 Discussion

IntCC’s limits center on proof-generation costs, dependence on owner-defined security policies, and the exclusion of covert-channel defenses.

Overhead of Zero-Knowledge Proving

  • Zero-knowledge proof generation can bottleneck interactive workloads as audit frequency grows or deployments scale.The authors identify prover latency and resource consumption as the practical constraint, and propose more efficient SNARK/STARK backends or hardware acceleration as future directions.Source: §7 · p. 12

Programmable Security Policies

  • IntCC’s effectiveness depends on the expressiveness and correctness of data-owner policies, while declassification rules are currently registered statically.The authors propose allowing processors to upload sandboxed declassification logic, with future proof-carrying code validated by IntCC-Runtime.Source: §7 · p. 12

Limitations against Covert Channels

  • IntCC constrains explicit and partial implicit flows but does not cover covert channels such as timing, termination, scheduling, or resource contention.The authors identify program analysis, deterministic padding, or secure multi-execution as possible supplementary interventions.Source: §7 · p. 12

8 Related Work

Related systems constrain trusted execution at the system, language, or workload level, whereas IntCC is positioned as an application-level, workload-agnostic framework for interactive tasks.

Confining Untrusted Software in TEEs

  • IntCC’s application-level logical partition is orthogonal to NestedSGX and vSGX, which use guest-level privilege separation and require extensive hypervisor or guest OS modifications.Source: §8 · p. 12

Language- or Framework-Level Constraints

  • PoBF’s compile-time Rust analysis assumes predictable computation graphs, making it ill-suited to exploratory, dynamic Python data-science workflows.Source: §8 · p. 12

Privacy-Preserving Model Tuning and Data Analytics

  • Atlas audits the machine-learning lifecycle but does not address secure interactivity against untrusted data processors; DLBox is limited to model training workloads.Source: §8 · p. 12
  • Laputa and PICACHV provide workload-specific analytics guarantees, while IntCC is presented as supporting LLM fine-tuning, data analysis, and other interactive tasks.Source: §8 · pp. 12–13

9 Conclusion

IntCC operationalizes interactive confidential computing by separating control from execution, enforcing lattice-based information flow control, and verifying runtime compliance. The paper concludes that it supports human-in-the-loop LLM fine-tuning and data analysis with practical overhead.

9 Conclusion

  • IntCC combines control–execution separation, lattice-based information flow control, and verifiable runtime compliance to securely support human-in-the-loop operations.Source: §9 · p. 13
  • Evaluations confirmed that IntCC supports complex LLM fine-tuning and data analysis tasks with practical overhead.Source: §9 · p. 13
Loading 2609.35552v1…