PaperlayerView exact revision on arXiv

Source-linked AI summary

Automated TEE Adaptation with LLMs: Identifying, Transforming, and Porting Sensitive Functions in Programs

Ruidong Han, Zhou Yang, Chengyan Ma, Ye Liu, Yuqing Niu, Siqi Ma, Debin Gao, David Lo

arXiv:2502.13379v3cs.CRcs.SE

TL;DR

Adapting existing programs to TEEs requires substantial domain knowledge and manual intervention for sensitive-code isolation and constrained execution environments. AUTOTEE uses LLMs, iterative compiler feedback, functional-equivalence checks, and secure port-based integration to transform sensitive functions into TEE-resident code. 91.8% of Java code and 84.3% of Python code are successfully transformed with GPT-4o, while sensitive-function detection achieves an average F1-score of 0.94.

  • Problem

    Adapting existing programs to TEEs requires substantial domain knowledge and manual intervention for sensitive-code isolation and constrained execution environments.

    Source: §I · p. 1

  • Method

    AUTOTEE uses LLMs, iterative compiler feedback, functional-equivalence checks, and secure port-based integration to transform sensitive functions into TEE-resident code.

    Source: §I · p. 2, §V · p. 12

  • Results

    91.8% of Java code and 84.3% of Python code are successfully transformed with GPT-4o, while sensitive-function detection achieves an average F1-score of 0.94.

    Source: §I · p. 2

  • Takeaways & Limitations

    AUTOTEE reduces manual engineering effort for partitioning, porting, and validating high-level programs for TEE adoption.

    Source: §V · p. 12, §VIII · p. 14

    AUTOTEE does not fully exclude humans from the loop, and its equivalence validation may not capture all semantic aspects.

    Source: A. Threats to Validity · p. 12, B. Limitation · p. 13

Abstract

from arXiv · show

Trusted Execution Environments (TEEs) isolate a special space within a device memory that is not accessible to the normal world (also known as the untrusted environment), even when the device is compromised. Therefore, developers can utilize TEEs to provide robust security guarantees for their programs, protecting sensitive operations, such as encrypted data storage, fingerprint verification, and remote attestation, from software-based attacks. Despite the robust protections offered by TEEs, adapting existing programs to leverage such security guarantees is challenging, often requiring extensive domain knowledge and manual intervention, which makes TEEs less accessible to developers. This motivates us to design AUTOTEE, the first Large Language Model (LLM) enabled approach that can automatically identify, transform, and port functions containing sensitive operations into TEEs with minimal developer intervention. By manually reviewing 68 repositories, we constructed a benchmark dataset consisting of 385 sensitive functions eligible for transformation, on which AUTOTEE achieves a F1 score of 0.94 on Java and 0.87 on Python. AUTOTEE effectively transforms these sensitive functions into TEE-compatible versions, achieving success rates of 91.8% and 84.3% for Java and Python, respectively, when using GPT-4o.

I. INTRODUCTION

AUTOTEE addresses the difficulty of adapting high-level programs to TEEs by automatically identifying, transforming, validating, and integrating sensitive functions. On a benchmark from 68 repositories, it achieves strong detection and transformation results for Java and Python.

A. Trusted Execution Environments

  • TEEs protect sensitive operations by isolating their memory from the normal world, including when the operating system or hypervisor is compromised.Examples include encrypted storage, fingerprint verification, and remote attestation.Source: §I · p. 1, A. Trusted Execution Environments · p. 2

I. INTRODUCTION

  • Existing TEE adaptation is difficult because developers must isolate security-critical code and accommodate constrained environments that often lack high-level-language runtimes and familiar APIs.These constraints motivate selective function-level porting rather than moving entire applications into TEEs.Source: §I · p. 1
  • AUTOTEE automatically identifies, partitions, and transforms sensitive functions into TEE-protected versions, reducing manual code modifications for Java and Python programs.The approach replaces human-in-the-loop porting with LLM-enabled automation.Source: §I · pp. 1–2
  • AUTOTEE extracts leaf functions, asks an LLM to identify cryptography- or serialization-related operations, and transforms selected functions into native implementations.Leaf functions do not invoke other user-defined functions, simplifying the porting unit.Source: §I · pp. 1–2
  • The system validates transformed code through compiler checks, generated tests, coverage feedback, and output comparison before integrating it with the original program.Validated native code runs in the TEE through port-based communication and attestation support.Source: §I · p. 2
  • 91.8% of Java code and 84.3% of Python code are successfully transformed with GPT-4o.A transformation succeeds when the generated code produces outputs identical to the original under automatically generated test inputs.Source: §I · p. 2
  • AUTOTEE achieves an average F1-score of 0.94 for sensitive-function detection across its benchmark.The benchmark contains 385 sensitive leaf functions manually collected from 68 Python and Java repositories.Source: §I · p. 2

B. Large Language Models & ReAct Prompting

LLMs struggle with code transformation because static internal knowledge cannot dynamically verify generated code. AUTOTEE combines LLM analysis with ReAct-style external feedback, while defining sensitive operations around cryptography and serialization and targeting TEE-compatible native code.

B. Large Language Models & ReAct Prompting

  • LLMs cannot reliably assess transformation correctness through static knowledge alone, motivating interaction with compilers and runtime environments.Code transformation requires understanding, rewriting, and validating the original program.Source: B. Large Language Models & ReAct… · p. 2
  • ReAct decomposes tasks into thought-action-observation cycles that use external tools to obtain information and revise decisions.Compiler messages can indicate whether generated code is compilable.Source: B. Large Language Models & ReAct… · pp. 2–3

C. Sensitive Operations

  • Sensitive operations are defined as abstract actions that directly affect program integrity and security.The paper focuses on cryptographic operations and serialization.Source: C. Sensitive Operations · p. 3
  • Cryptographic sensitive functions include encryption, decryption, signatures, verification, hashing, and secure key management.The category includes seed generation and cryptographic random-number generation.Source: C. Sensitive Operations · p. 3
  • Serialization is treated as sensitive because insecure deserialization can cause information leakage or remote code execution.The paper presents TEE placement as a possible mitigation and allows prompts to be adapted for additional categories.Source: C. Sensitive Operations · p. 3

A. Methodology Design

  • AUTOTEE uses LLMs to identify sensitive code and iteratively refine native implementations with compiler checks and functional-equivalence validation.The transformed code is subsequently integrated with the original program for protected execution.Source: A. Methodology Design · p. 3
  • AUTOTEE’s methodology targets sensitive program regions, transforms them into TEE-compatible native code, and securely reconnects them to the original application.The design aims to preserve compilability and functional equivalence while minimizing manual intervention.Source: A. Methodology Design · p. 3

B. Overview

AUTOTEE processes programs through AST-based leaf-function extraction, LLM-based sensitivity identification, native-code transformation, validation, and TEE integration. Its scope is constrained to self-contained functions with simple cross-language data interfaces and supported libraries.

B. Overview

  • AUTOTEE constructs an AST, extracts leaf functions, identifies sensitive ones, generates tests, transforms them, validates the result, and installs validated executables in the TEE.Failed transformations are refined with ReAct until they satisfy compilation and equivalence checks.Source: B. Overview · p. 3

1) Leaf Function:

  • Leaf functions are lowest-level functions that do not depend on other user-defined functions, reducing call-chain complexity during porting.They implement specific sensitive operations and serve as utilities within larger call chains.Source: 1) Leaf Function · p. 3
  • AUTOTEE restricts leaf-function arguments to primitive types and basic composite structures to reduce cross-language compatibility problems.Examples include integers, floating-point values, arrays, and strings.Source: 1) Leaf Function · p. 3
  • Supported public libraries can be replaced with equivalent implementations in the TEE environment without analyzing developer-defined library internals.Cross-language equivalence mappings support this replacement process.Source: 1) Leaf Function · p. 4, Table I · p. 4
  • AST processing identifies function declarations and designates a function as a leaf when its body contains no calls to project-defined functions.Python uses the ast module, while Java uses JavaParser.Source: 1) Leaf Function · p. 4

2) Sensitive Function Identification:

  • The sensitivity detector looks for cryptographic or serialization APIs, security-related keywords, and recognizable cryptographic patterns.The supported examples include hashlib.sha256, Fernet, and encryption-related terms.Source: 2) Sensitive Function Identification · p. 4
  • Three prompts progressively request a sensitivity judgment, the sensitive-operation type, and the statements supporting that judgment.The function is labeled sensitive only if the final multi-round analysis retains the sensitive classification.Source: 2) Sensitive Function Identification · pp. 4–5

3) Test Inputs Generation:

AUTOTEE generates coverage-guided tests, transforms sensitive functions into Rust, and validates the resulting executable against the original implementation. Failed compilation or equivalence checks trigger iterative refinement, with randomness controlled for deterministic comparison.

3) Test Inputs Generation:

  • AUTOTEE asks an LLM to generate diverse test inputs that maximize line and branch coverage for each identified sensitive function.Java uses JaCoCo and Python uses pytest-cov to measure coverage.Source: 3) Test Inputs Generation · p. 5
  • 100% line and branch coverage is pursued through iterative test generation, using coverage reports to request additional inputs when needed.The loop stops at full coverage or after three consecutive iterations without improvement.Source: 3) Test Inputs Generation · p. 5

D. Code Transformer

  • Sensitive functions are transformed into Rust to obtain a memory-safe native implementation suitable for the TEE.The choice targets risks including buffer overflows, dangling pointers, and uninitialized memory.Source: D. Code Transformer · p. 5

1) Initial Transformation:

  • Few-shot examples guide the LLM’s initial transformation from source code into Rust with required dependencies.The initial prompts ask the model to understand the function’s objective and then perform the translation.Source: 1) Initial Transformation · p. 5

2) Compilability Check and Equivalence Validation:

  • Cargo first checks compilability, after which AUTOTEE compares original and transformed outputs on the same test inputs.The transformed Rust code is compiled into an executable and invoked through an external call from the original program.Source: 2) Compilability Check and Equivalence… · p. 5
  • Randomized cryptographic behavior is made deterministic for validation by mocking random sources or using fixed seeds when supported.This enables output comparison between otherwise functionally equivalent implementations.Source: 2) Compilability Check and Equivalence… · p. 5
  • Compilation or equivalence failures trigger ReAct actions that modify the generated code and repeat validation.The process uses action-generated feedback to refine the implementation.Source: 2) Compilability Check and Equivalence… · p. 5, Figure 3 · p. 5

3) Iterative Refinement:

AUTOTEE iteratively refines generated native code using compiler feedback and functional-equivalence checks, then adapts it to platform-specific TEE constraints.

3) Iterative Refinement:

  • The ReAct process repeatedly modifies generated code and uses external feedback to satisfy compilability and functional-equivalence checks.The process continues until the program is executable and passes equivalence validation or reaches the evaluation threshold TH=20.Source: 3) Iterative Refinement · pp. 5–6
  • The refinement agent can search compiler issues, modify code, update dependencies, check compilability, and validate equivalence.Equivalence validation is invoked after compilation succeeds and reports either equivalent outputs or a differing test input.Source: 3) Iterative Refinement · p. 6

4) Platform Adaptation:

  • Platform adaptation adjusts APIs, environment-variable handling, and timer usage for process-based TEEs with compatibility constraints.Environment variables are hardcoded during preprocessing, and unsupported CPU timers are replaced with system-level timer APIs.Source: 4) Platform Adaptation · p. 6

E. Execution Linker

AUTOTEE links transformed Rust functions running inside TEEs to original applications through attested, encrypted communication, and evaluates the system on manually labeled Java and Python repositories.

E. Execution Linker

  • The execution linker connects normal-world client code with functionally equivalent Rust code executing inside a TEE through secure port-based communication.The client replaces the original function with a TEE call, while the transformed code executes the equivalent function inside the TEE.Source: E. Execution Linker · p. 6
  • The workflow verifies the transformed code through attestation, establishes TLS, exchanges encrypted arguments, and returns the result before binary signing.The attestation server checks quote legitimacy and code integrity before the client initiates the secure channel.Source: E. Execution Linker · p. 6

IV. EVALUATION

  • The evaluation asks whether AUTOTEE identifies sensitive functions, preserves functionality after transformation, and controls resource consumption.Experiments use GPT-4o, Qwen2.5, DeepSeek, and LLaMA3.1, with Intel SGX as the selected TEE platform.Source: §IV · p. 7, A. Experiment Preparation · p. 7

A. Experiment Preparation

  • The benchmark contains manually reviewed leaf functions from 38 Java and 30 Python repositories, with labels requiring agreement among three reviewers.The retained benchmark includes 232 sensitive Java functions, 153 sensitive Python functions, and randomly added normal functions.Source: A. Experiment Preparation · p. 7
  • Few-shot transformation examples were manually implemented in Rust and cross-reviewed for semantic equivalence before use.Disagreements identified during review were resolved by manually refining the transformations.Source: A. Experiment Preparation · p. 7

B. RQ1: Identification Accuracy

AUTOTEE detects sensitive functions most accurately with GPT-4o, while staged prompting improves F1 by adding detail only when needed.

1) Identification Result:

  • 0.958 Java F1 and 0.883 Python F1 are GPT-4o’s highest average detection scores, with statistically significant advantages over several competing models.GPT-4o significantly outperforms all compared models on Java and outperforms Qwen2.5 and LLaMA3.1 on Python at the 99% confidence level.Source: 1) Identification Result · p. 7, Table II · p. 8
  • Detection errors arise when bit shifts, array manipulations, or dictionary keys resemble cryptographic operations, while Python’s dynamic features obscure sensitive behavior.The passage attributes the Java–Python gap to Java’s explicit types and structured APIs versus Python’s dynamic typing and flexible syntax.Source: 1) Identification Result · pp. 7–8

2) Prompt Strategy Influence:

  • 0.868 to 0.909 to 0.931 Java F1 results show that adding prompts incrementally improves Qwen2.5 detection performance.Python F1 also rises from 0.791 with P1 to 0.868 with the full P1&2&3 configuration.Source: 2) Prompt Strategy Influence · p. 8, Table III · p. 8
  • Staged prompting reduces unnecessary token consumption while preserving detection accuracy by filtering candidates before applying more detailed prompts.The strategy applies a concise first prompt and adds further prompts only when necessary.Source: 2) Prompt Strategy Influence · p. 8

C. RQ2: Transformation

AUTOTEE evaluates sensitive-function transformation using labeled Java and Python functions, generated tests, and iterative LLM refinement. GPT-4o achieves the strongest reported transformation results, reaching 91.8% for Java and 84.3% for Python.

C. RQ2: Transformation:

  • 385 manually labeled sensitive functions from 232 Java and 153 Python functions formed the transformation benchmark.Using labeled sensitive functions isolates transformation effectiveness from sensitive-function identification errors.Source: C. RQ2: Transformation · p. 8

1) Metric:

  • #Equivalent counts transformations functionally consistent after initial transformation or iterative refinement, while #Direct counts cases succeeding without refinement.Avg. Iter. excludes direct cases and measures iterations among successful refined transformations.Source: 1) Metric · p. 8

2) Coverage of Generated Test Inputs:

  • Generated test inputs achieved 98.2% Java line coverage, 100% Java branch coverage, and 100% coverage for both Python measures.Sensitive Java functions themselves reached 100% coverage when class-initialization coverage was excluded.Source: 2) Coverage of Generated Test Inputs · p. 8

3) Initial Transformation:

  • Initial prompting alone transformed fewer than 21% of cases, typically succeeding only on simple string-processing functions without branching.Failures involved imports, cryptographic initialization, and error handling.Source: 3) Initial Transformation · p. 8

4) Iterative Refinement:

5) Category Influence:

Transformation success varies by function category and language, while remaining broadly stable across function-size groups. Cryptographic operations are easier to transform than serialization, and type annotations particularly help Python transformations.

5) Category Influence:

  • 87.3% Java and 84.1% Python average success rates for cryptography exceeded 78.6% and 74.2% for serialization.Cryptography follows more standardized library patterns, whereas serialization involves heterogeneous structures and nested data handling.Source: 5) Category Influence · p. 9, Table V · p. 9

6) Code Language Influence:

  • Type annotations added 4 GPT-4o, 10 Qwen2.5, and 9 DeepSeek successful Python transformations.The resulting success rates were 86.2%, 73.9%, and 82.3%, respectively.Source: 6) Code Language Influence · p. 9, Table VI · p. 9
  • Python transformations are harder partly because dynamic typing provides less semantic information and equivalent Rust libraries may lack Python functionality.Manual type annotations improved transformation outcomes, especially for Qwen2.5 and DeepSeek.Source: 6) Code Language Influence · p. 9

7) Code Complexity Influence:

8) Integration and System-Level Testing:

System-level testing exposes mostly environmental integration failures, while failure analysis identifies cryptographic and bit-level reasoning as major challenges. Equivalence validation gives AUTOTEE its strongest comparison result, and repeated trials show generally stable outcomes.

8) Integration and System-Level Testing:

  • Two of 94 Java transformations and one of 15 Python transformations introduced new test failures, all attributed to TEE environmental incompatibilities.The causes were unavailable elliptic-curve dynamic linking and disallowed temporary-file I/O across the TEE boundary.Source: 8) Integration and System-Level Testing · p. 10

9) Failure Analysis:

  • Sophisticated cryptography accounted for 46.2% of failures, while shift operations accounted for 22.9%.The authors associate these failures with mathematical reasoning, bit-level manipulation, and differing language semantics.Source: 9) Failure Analysis · p. 10

10) Comparison and Analysis:

  • AUTOTEE achieved the highest success rate when iterative refinement used equivalence validation alongside compilability checks.Compilability checks alone made most outputs executable but did not ensure equivalence to the original code.Source: 10) Comparison and Analysis · p. 11

11) Stability:

  • Across 37 repeated-trial samples, GPT-4o, Qwen2.5, and DeepSeek retained broadly similar success rates with minor fluctuations.The repeated experiments included 23 Java and 14 Python instances.Source: 11) Stability · p. 11

D. RQ3: Resource Consumption

AUTOTEE’s resource costs arise from LLM transformation and TEE execution overhead. DeepSeek is cheaper than GPT-4o, while runtime overhead is proportionally largest for fast functions and smaller for computationally intensive ones.

1) Resource Consumption in LLMs:

2) Practical Resource Consumption of Execution:

  • TEE execution generally increases resource consumption because of transmission delays and attestation verification.Measurements include TLS communication, quote verification, and function execution.Source: 2) Practical Resource Consumption of… · p. 11
  • A function with 0.2 ms original execution time increased to 251 ms inside the TEE; AES-CFB encryption incurred approximately 143× overhead, while RSA key generation increased only 1.6× from 212 ms.Source: 2) Practical Resource Consumption of… · p. 12

V. DISCUSSION

AUTOTEE automates TEE adoption through sensitive-function identification, code transformation, and validation, while preserving secure communication and memory safety. The evaluation notes strong test coverage but bounds generality by dataset composition, labeling scope, hardcoded environment variables, and remaining human involvement.

V. DISCUSSION

  • Remote attestation, memory-safe Rust, and TLS-protected serialized arguments support integrity and confidentiality across the trusted–untrusted boundary.The Execution Linker encrypts and serializes function arguments during cross-boundary interactions.Source: §V · p. 12
  • AUTOTEE automates partitioning, LLM-driven Rust transformation, and differential validation, reducing manual dependency analysis, systems expertise, and test-maintenance effort.ReAct refinement and automated differential testing compare original and trusted components for functional equivalence.Source: §V · p. 12

A. Threats to Validity

  • LLM-generated tests achieved 100% line and branch coverage for targeted leaf functions, increasing confidence in tested equivalence while not capturing every semantic aspect.The validation remains based on executing original and transformed functions on identical inputs and comparing outputs.Source: A. Threats to Validity · p. 12
  • The study does not cover all models or application scenarios, so results may not generalize beyond the evaluated four models and 385 labeled sensitive functions.The authors call for evaluation on additional models, datasets, and domains.Source: A. Threats to Validity · p. 13
  • Sensitive-function labeling is restricted to well-defined categories and uses independent expert review with adjudication to improve objectivity and reproducibility.The construct is grounded in established literature and predefined labeling criteria.Source: A. Threats to Validity · p. 13
  • A second review of 372 sampled functions reached Cohen’s κ of 0.907 and found 97.5% consistency with initial labels, supporting dataset reliability despite an initially ad hoc process.Eleven disagreements were resolved by a third author.Source: A. Threats to Validity · p. 13

B. Limitation

  • Hardcoded environment variables may hinder migration across hardware platforms, leaving manual checking and modification in the workflow.The authors explicitly retain some human involvement rather than fully eliminating the human-in-the-loop process.Source: B. Limitation · p. 13
  • The evaluation is concentrated in cryptographic projects, where sensitive functions are more prevalent than in many real-world workloads, limiting demonstrated software-domain diversity.The authors plan broader project coverage despite describing the methodology as domain-agnostic.Source: B. Limitation · p. 13

VII. RELATED WORK

Prior TEE-porting and code-transformation approaches address isolation, runtime support, or translation, but AUTOTEE combines selective native-code migration with LLM transformation and validation. The paper reports successful GPT-4o transformations while identifying broader invocation support, stronger testing, and integration-error handling as future directions.

A. Application Porting to TEE

  • Earlier TEE-porting methods include customized JVM isolation, model partitioning, embedded-device isolation, accelerator protection, and security-sensitive component extraction.These approaches differ in trusted-computing-base size, device support, and partitioning strategy.Source: A. Application Porting to TEE · p. 13
  • AUTOTEE migrates only a small portion of critical code into the TEE as native code, preserving functionality while avoiding additional runtime overhead.This contrasts with approaches that port larger runtime environments or increase the trusted computing base.Source: A. Application Porting to TEE · p. 13

B. Code Transformation

  • Unlike prior translators limited to syntactic conversion or specific source domains, AUTOTEE uses LLM transformation with compilability checks and equivalence validation without prior training data.The related code-transformation methods include C-to-Rust conversion, style transfer, C-to-CUDA translation, and interactive human-machine translation.Source: B. Code Transformation · pp. 13–14

VIII. CONCLUSION AND FUTURE WORK

  • GPT-4o successfully transformed 91.8% of Java code and 84.3% of Python code while preserving functional equivalence and successful compilation.The reported results support the paper’s TEE-porting objective across both evaluated languages.Source: §VIII · p. 14
  • AUTOTEE’s source-level design is intended to extend across languages and to sensitive operations such as network communication, privilege management, and resource-intensive workflows when recognizable code patterns exist.Extension requires appropriate parsing and code-analysis tools.Source: §VIII · p. 14
  • Current migration supports only basic external library calls with direct TEE equivalents, leaving complex data structures and non-standard libraries for future work.The authors also plan more rigorous test suites to strengthen equivalence verification and improve transformation success rates.Source: §VIII · p. 14
  • Current evaluation generates test inputs but not integration or system tests, motivating feedback-driven refinement and proactive exclusion of transformations likely to cause integration errors.These planned additions target failures that function-level testing may not expose.Source: §VIII · p. 14

Related papers

Loading 2502.13379v3…