PaperlayerView exact revision on arXiv

Source-linked AI summary

Protecting CPU AI On Edge TEEs: WebAssembly's Promise and Practical Challenges

Friedrich Vandenberghe, Lachlan Gunn, Bruno Volckaert, Merlijn Sebrechts

arXiv:2610.12050v1cs.CRcs.SE

TL;DR

Root access can expose edge AI model weights, while TEE constraints make it difficult to run existing applications unmodified. The paper runs unaltered AI models through WAMR in OP-TEE and reports 22% overhead and 6% slower inference latency, with remaining compatibility and performance limits.

  • Problem

    Root access can expose edge-device AI model weights, while TEE constraints prevent developers from simply recompiling existing applications to run inside them.

    Source: §I · p. 1

  • Method

    The approach uses an extended WAMR runtime to execute unaltered AI models inside OP-TEE and has a distributor sign and encrypt models for provisioning.

    Source: B. AI model Distributor · p. 4, §IX · p. 7

  • Results

    The solution has 22% overhead and 6% slower inference latency when running in OP-TEE.

    Source: §IX · p. 7

  • Takeaways & Limitations

    The work demonstrates the feasibility of executing unaltered AI models inside a TEE while safeguarding model confidentiality.

    Source: §X · pp. 7–8

    Only no multithreading and memory limits remain among the OP-TEE constraints it bypasses; AI support is also limited by WASI workloads, supported ONNX operators, and absent GPU acceleration.

    Source: §IX · p. 7, A. WebAssembly System Interface · p. 7, §X · p. 8

Abstract

from arXiv · show

AI models on edge hardware contain important intellectual property (IP), but an adversary can steal it when they achieve root access. Trusted Execution Environments (TEE) like Arm TrustZone protect against these Operating System (OS) level attacks. However, they are challenging to use. More precisely, it is difficult to run unaltered applications inside a TEE. This work presents a solution that allows the execution of unaltered AI models, compiled to WebAssembly, on the WebAssembly Micro Runtime (WAMR) in OP-TEE for Arm TrustZone. Additionally, this work provides an AI model distributor that encrypts the WebAssembly binary and places the encryption key in one of the device's fuses. This way, only the WAMR Trusted Application (TA) in OP-TEE can decrypt and execute the AI model. A thorough evaluation of our solution shows that it incurs an additional overhead of 22% in comparison to an application manually ported to OP-TEE, while also facilitating the execution of unaltered AI models with an additional inference latency of 6% without significant porting effort. Overall, there is a pressing need to safeguard the IP of AI models and this work shows that there is a real promise in WebAssembly, but there remain some practical challenges.

I. INTRODUCTION

Root access can expose edge AI model weights, while the constrained environment of a TEE makes unaltered applications difficult to run. The paper proposes a WebAssembly-based platform and model-distribution approach for executing AI models in Arm TrustZone, and evaluates its performance and practical limits.

I. INTRODUCTION

  • Root access can expose AI model weights, while TrustZone’s constrained environment makes running existing applications require significant porting effort and specialized expertise.The porting effort must be repeated for each TEE platform.Source: §I · p. 1
  • Existing approaches leave gaps: TREO supports only C applications, while WaTZ did not address unaltered AI models and requires a trustworthy second party for key release.The latter requirement conflicts with use cases where devices boot without internet access.Source: §I · p. 1
  • The proposed platform integrates WAMR with Arm TrustZone and distributes AI models for execution inside the TEE.It is evaluated on an NVIDIA Jetson AGX Orin, supports ONNX models, and works fully offline.Source: §I · pp. 1–2
  • The paper asks whether unmodified AI models can run in Arm TrustZone through WebAssembly and how execution performance compares with native code.The introduction also raises how developments in WAMR affect performance, but the supplied question text is incomplete.Source: §I · p. 2
  • The work contributes a TrustZone WebAssembly runtime, a computer-vision demonstration, performance benchmarks against TEE-specific native code, and a discussion of limitations.The supplied contribution passage also identifies future work for WebAssembly machine-learning tasks.Source: §I · p. 2

II. BACKGROUND

The background introduces the secure execution environment and the constraints that complicate running ordinary applications inside it. In particular, OP-TEE TAs lack standard application facilities and impose programming and threading restrictions.

A. Arm TrustZone

  • Arm TrustZone separates Normal World and Secure World execution, with TAs accessing secure physical memory unavailable to the Normal World.Execution switches between the worlds through the Secure Monitor Call instruction.Source: A. Arm TrustZone · p. 2

B. OP-TEE

  • OP-TEE provides an API and OS framework for communication between the TEE and Trusted Applications.Its components support transitions from the Normal World through the Secure Monitor and TEE OS to a TA.Source: B. OP-TEE · p. 2
  • OP-TEE constrains application development: TAs use the GlobalPlatform API rather than a C standard library, cannot spawn threads, and have limited language support.First-class support is for C and C++, with experimental Rust support; applications must adhere to the GP API.Source: B. OP-TEE · p. 2

C. WebAssembly

The section outlines WebAssembly and ONNX as portable building blocks for AI execution, then describes WAMR and secure boot mechanisms relevant to the system. It also notes a memory-allocation consequence of WAMR’s use in OP-TEE.

C. WebAssembly

  • WebAssembly is a portable binary compilation target, with WASI interfaces extending access to resources such as files, networking, I/O, and machine learning.WASI has three preview versions; the first provides traditional C-like interfaces, while later previews add the Component Model and concurrency capabilities.Source: C. WebAssembly · p. 2

D. ONNX Runtime

  • ONNX supports interoperability by defining common model building blocks and a common file format, while onnx2c compiles ONNX models to C for microcontroller inference.onnx2c implements only half of available ONNX operations and does not support backpropagation.Source: D. ONNX Runtime · pp. 2–3

E. WebAssembly Micro Runtime

  • WAMR is a lightweight runtime for edge devices, and its version 2.0.0 mmap-based linear-memory allocation can consume memory available to other TAs.In OP-TEE, mmap allocations are handled outside the TA’s carved-out address space, creating a denial-of-service effect on other TAs.Source: E. WebAssembly Micro Runtime · p. 3

F. Secure Boot

  • Secure boot authenticates each subsequent boot stage before execution, rooted in on-die read-only memory and write-once fuse-stored keys.The fuse storage prevents those keys from being altered when the device is flashed later.Source: F. Secure Boot · p. 3

III. RELATED WORK

Prior efforts reduce the work needed to run applications in TrustZone, but each has constraints in language support, availability, or device and workload coverage. The paper’s threat model assumes a trusted model distributor and a device with protected memory and secure boot.

III. RELATED WORK

  • TREO runs unmodified or minimally changed C programs in OP-TEE, but supports only C and OP-TEE version 4.2.The cited version was released in April 2024.Source: §III · p. 3
  • PARTEE uses TEE partitions to run unmodified Linux applications, but the project is not open source or generally available.The passage reports little information about the project after its initial white paper.Source: §III · p. 3
  • WaTZ provides a WAMR-based Wasm runtime and remote attestation for Arm TrustZone, while a later extension addresses smart contracts rather than edge-AI IP protection.WaTZ is limited to one board, and the later approach does not address protecting edge-based AI model intellectual property.Source: §III · p. 3

IV. THREAT MODELLING

  • The threat model assumes a trusted distributor and an untrusted device with a confidential-computing environment that protects memory and has a secured boot process.The distributor trains, signs, and encrypts the model, then provisions it over a secure network or on storage placed in the device.Source: §IV · p. 3

A. Adversary Model

The threat model covers an attacker with post-provisioning control of the REE and its interfaces, but excludes several physical and cryptanalytic attacks. The work evaluates model and platform confidentiality.

A. Adversary Model

  • Post-provisioning attackers may control the REE and interfaces with the aim of stealing model IP, but cannot compromise the distributor or interfere with pre-provisioning communications.The model assumes secure TEE memory protections, secure TEE software except Wasm modules, and secure boot.Source: A. Adversary Model · pp. 3–4, B. Assumptions · p. 4

C. Out-of-scope Threats

  • The threat model excludes side-channel, fault-injection, hardware supply-chain, invasive physical, and quantum-cryptanalytic attacks.Examples include TEE.fail, Battering RAM, and Differential Power Analysis.Source: C. Out-of-scope Threats · p. 4

D. Security Objectives

  • The evaluation targets model confidentiality during commissioning, transfer, and execution, plus application confidentiality against post-provisioning device attackers..Source: D. Security Objectives · p. 4

V. ARCHITECTURE

The architecture provisions device keys and distributes encrypted Wasm models for execution by a Secure-World TA. A Normal-World handler transfers the encrypted model to that TA.

V. ARCHITECTURE

  • The Secure-World TA verifies the Wasm signature, decrypts the binary, and executes it in WAMR; the Normal World cannot see the binary contents.The architecture describes offline execution, with a provider key burned into device hardware.Source: §V · p. 4, Figure 2 · p. 4

A. Provisioning

  • Provisioning embeds the TA-signing public key in the TEE OS image and burns a Key-Derivation Key (KDK) into protected device fuses.Using a KDK rather than storing model keys directly supports cryptosystem agility.Source: A. Provisioning · p. 4

B. AI model Distributor

  • The distributor trains, signs, and encrypts the model, then delivers it either over a secure network connection or on storage placed inside the device..Source: B. AI model Distributor · p. 4

C. Model Handler

D. Extended WebAssembly Runtime

The extended WAMR TA authenticates, decrypts, and executes encrypted Wasm models in the TEE. The proof of concept uses an ONNX digit-recognition model and an OP-TEE implementation.

D. Extended WebAssembly Runtime

  • The extended runtime TA takes the encrypted model from the handler, verifies its signature, authenticates and decrypts it, then executes it in WAMR.The TA extends WAMR with Arm TrustZone support and a KDK-based Wasm decryption module.Source: D. Extended WebAssembly Runtime · p. 5

VI. IMPLEMENTATION

  • The proof of concept validates feasibility and examines potential architectural and security-methodology shortcomings..Source: §VI · p. 5

A. AI model

  • The model is an ONNX computer-vision digit recognizer trained on MNIST, converted to C with onnx2c, then compiled to Wasm, encrypted, and signed..Source: A. AI model · p. 5

B. WebAssembly Runtime

  • The implementation forks WaTZ, adapts it to WAMR's AOT ABI, and adds support for the Jetson AGX Orin and OP-TEE 4.8 in QEMU..Source: B. WebAssembly Runtime · p. 5

C. Encryption of the WebAssembly binary

Startup measurements show decryption time rises with encrypted Wasm binary size while other TA startup components remain fairly constant. The evaluation also specifies the encryption design and benchmark setup.

C. Encryption of the WebAssembly binary

  • The Wasm binary is encrypted with an AES key derived in counter mode via NIST-SP 800-108 KDF from an AES KDK, using AES-CMAC as the PRF because the hardware accelerator supports only that option.Encryption uses 128-bit AES-GCM, avoiding separate authentication-tag computation.Source: C. Encryption of the WebAssembly binary · p. 5

A. Test Setup

  • The evaluation measures startup, PolyBench runtime, and MobileNetV2 inference latency using 500 executions per benchmark on a Jetson AGX Orin.Runtime measurements omit signature verification and use an already decrypted Wasm binary; native and WAMR runs are compared on OP-TEE and Linux.Source: §VII · p. 5, A. Test Setup · pp. 5–6

B. Startup latency

  • Decryption time increases linearly with encrypted binary size, while the other TA startup components remain fairly constant across sizes.Fig. 4 measures startup components for AOT-compiled Wasm binaries from 1 to 10 MiB.Source: B. Startup latency · p. 6, Figure 4 · p. 6

C. Inference Latency

MobileNetV2 inference adds little latency in TEE WAMR relative to REE WAMR, while PolyBench’s larger overhead comes from WAMR rather than the TEE transition. The native OP-TEE inference comparison is unavailable because the generated application exceeds OP-TEE’s loading limit.

C. Inference Latency

  • 21.7µs (+5.61%) is the mean MobileNetV2 inference slowdown when switching from REE WAMR to TEE WAMR.The native OP-TEE comparison is absent because the 13.59 MiB ONNX model and generated C code produce a 14.9 MiB TA too large for OP-TEE to load.Source: C. Inference Latency · p. 6, Table I · p. 6

D. WebAssembly vs Native Code

  • 263.67µs (+22.11%) is the slowdown from native OP-TEE execution to WAMR, while switching REE WAMR to TEE WAMR adds 19.85µs (+1.38%).Fig. 5 and Table II report mean execution times for PolyBench as a single application.Source: D. WebAssembly vs Native Code · p. 6, Table II · p. 6, Figure 5 · p. 6
  • WAMR accounts for the main PolyBench slowdown, rather than the transition from REE to TEE.The figure marks averages with red diamonds.Source: Figure 5 · p. 6

E. Comparison with Original WaTZ

The solution is slightly faster than the original WaTZ, with a reported 0.7% gain that is not significant. Its threat evaluation describes protections against root-access attempts to compromise the TA or extract the model, while noting remaining OP-TEE constraints.

E. Comparison with Original WaTZ

  • The updated WAMR is 0.7% faster than WaTZ’s 2021 version, a difference the authors say is not significant.The comparison uses the same test setup and hardware as the other tests.Source: E. Comparison with Original WaTZ · p. 6

VIII. THREAT EVALUATION

A. Platform confidentiality

  • Root access does not let an adversary read or modify TA memory during execution or load a custom TA, because Arm TrustZone protects memory and OP-TEE verifies TA signatures.The trusted distributor holds the private key used to sign the solution; that key is not present in OP-TEE.Source: A. Platform confidentiality · p. 7

B. Model confidentiality

  • The encrypted model may be accessible to an attacker, but decrypting it requires a key derived inside the Secure World; authenticated encryption also blocks chosen-ciphertext weight probing.Model encryption does not prevent denial-of-service attacks while the model is stored on disk.Source: B. Model confidentiality · p. 7

IX. DISCUSSION & LIMITATIONS

  • No multithreading and memory limits remain among OP-TEE’s design constraints despite the solution’s 22% overhead versus manually ported code.The discussion also reports 6% slower inference latency for AI models running in OP-TEE.Source: §IX · p. 7

A. WebAssembly System Interface

The paper demonstrates WebAssembly execution of unaltered AI models in a TEE, while identifying performance and compatibility limits. Its conclusion reports overheads against native OP-TEE and WAMR baselines, and the implementation faces device-specific memory constraints.

A. WebAssembly System Interface

  • Because wasi-nn differs from ONNX and lacks updated WebNN capabilities, the implementation compiles models into runtime-free applications rather than relying on an AI runtime.The authors state that either an AI runtime must run fully in Wasm or be ported to OP-TEE to work around this limitation.Source: A. WebAssembly System Interface · p. 7

B. Arm TrustZone

  • Memory availability cannot be known without the target device, and the solution depends on OP-TEE Core memory-management extensions outside the application's reserved space.Applications must stay within the memory limits of their chosen device.Source: B. Arm TrustZone · p. 7

X. CONCLUSION

  • 22% slowdown versus native execution inside OP-TEE; MobileNetV2 inference latency had a 5.61% slowdown versus WAMR inside OP-TEE.Recent WAMR was 0.7% faster than the 2021 WAMR version used in WaTZ.Source: §X · p. 8
  • Limited ONNX operators and WASI machine-learning support, plus absent GPU acceleration, constrain accelerated models; broader support requires an ONNX runtime and WASI neural-network advances.The authors identify these as compatibility and performance limitations.Source: A. WebAssembly System Interface · p. 7, §X · p. 8
Loading 2610.12050v1…