ELASTIC D4.1: Wasm, eBPF and TEE enablement on edge
Abstract
This deliverable presents the enablement and evaluation of WebAssembly (Wasm), extended Berkeley Packet Filter (eBPF), Trusted Execution Environments (TEEs), and Federated Learning (FL) for IoT edge nodes. It includes an assessment of lightweight Wasm runtimes, such as WAMR, for executing portable workloads, alongside proposed extensions to the WASI interface enabling secure, low-level hardware access. Furthermore, it explores the use of eBPF/XDP for in-kernel network filtering and observability, including its integration with AI-driven Intrusion Detection Systems (AI-IDS) to support real-time threat detection at the edge. The deliverable also investigates the applicability of TEEs for secure workload execution and remote attestation in constrained environments. AI processing and distributed AI workloads are analysed, leveraging Wasm's lightweight footprint and fast startup times. The findings contribute architectural guidelines, performance evaluations, and preliminary insights toward the realisation of trusted and efficient data processing and orchestration across the edge–cloud continuum.
Full text
Horizon Europe Framework Programme HORIZON JU Research and Innovation Action Reliable Services and Smart Security Efficient, portabLe And Secure orchesTration for reliable servICes D4.1: Wasm, eBPF and TEE enablement on edge Abstract: This deliverable presents the enablement and evaluation of WebAssembly (Wasm), extended Berkeley Packet Filter (eBPF), Trusted Execution Environments (TEEs), and Federated Learning (FL) for IoT edge nodes. It includes an assessment of lightweight Wasm runtimes, such as WAMR, for executing portable workloads, alongside proposed extensions to the WASI interface enabling secure, low-level hardware access. Furthermore, it explores the use of eBPF/XDP for in-kernel network filtering and observability, including its integration with AI-driven Intrusion Detection Systems (AI-IDS) to support real-time threat detection at the edge. The deliverable also investigates the applicability of TEEs for secure workload execution and remote attestation in constrained environments. AI processing and distributed AI workloads are analysed, leveraging Wasm's lightweight footprint and fast startup times. The findings contribute architectural guidelines, performance evaluations, and preliminary insights toward the realisation of trusted and efficient data processing and orchestration across the edge– cloud continuum. Contractual Date of Delivery 31/08/2025 Actual Date of Delivery 31/08/2025 Deliverable Security Class Public Editor Ana Kovacevic, Nenad Gligoric (ZEN) Contributors ERS, TID, THD, IMEC, UVC, AMA, AAL, POLITO, TUC, ZEN Internal Reviewers Miika Komu, Jimmy Kjällman, and Petri Laari (ERF) Christian Gehrmann (LUN)
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 2 - August 31, 2025 The ELASTIC Consortium Part. No. Participant organisation name Participant Short Name Role Country 1 POLYTECHNEIO KRITIS TUC Coordinator EL 2 ERICSSON AB ERS Principal Contractor SE 3 OY L M ERICSSON AB ERF Principal Contractor FI 4 TELEFONICA INNOVACION DIGITAL SL TID Principal Contractor ES 5 THALES SIX GTS FRANCE SAS THS Principal Contractor FR 6 THALES DIS FRANCE SAS THD Principal Contractor FR 7 INTERUNIVERSITAIR MICROELECTRONICA CENTRUM IMEC Principal Contractor BE 8 ULTRAVIOLET CONSULT DOO UVC Principal Contractor RS 9 AALTO KORKEAKOULUSAATIO SR AAL Principal Contractor FI 10 LUNDS UNIVERSITET LUN Principal Contractor SE 11 ABSTRACT MACHINES SAS AMA Principal Contractor FR 12 PRIVREDNO DRUSTVO ZENTRIX LAB DRUSTVO SA OGRANICENOM ODGOVORNOSCU PANCEVO ZEN Principal Contractor RS 13 POLITECNICO DI TORINO POLITO Principal Contractor IT
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 3 - August 31, 2025 Document Revisions & Quality Assurance Internal Reviewers 1. Miika Komu, Jimmy Kjällman and Petri Laari, ERF 2. Christian Gehrmann, LUN Revisions Version Date By Overview 1.4 31/08/2025 TUC, THS Comments and approval from the PC and the STPM 1.3 28/08/2025 TUC Quality check 1.2 28/08/2025 ERF, LUN Approval from the IRs 1.1 27/08/2025 ZEN 2nd draft 1.0 05/08/2025 ERF, LUN, THS Comments on the 1st draft 0.9 26/07/2025 ZEN First draft 0.8 25/07/2025 ALL Partner inputs integrated 0.7 27/05/2025 ZEN ToC - Final version 0.6 12/05/2025 AAL Corrections to subsections 2.4 & 4.1 0.5 02/05/2025 TID Feedback 0.4 14/04/2025 ALL Comments on the TOC 0.3 07/04/2025 ZEN, ERS/ERF, TUC Section confirmations & WAMR-related comments 0.2 27/03/2025 TUC Feedback on structure 0.1 26/03/2025 ZEN TOC - First draft, section leads Disclaimer The work described in this document has been conducted within the ELASTIC project. This project has received funding from the European Union’s Horizon Europe research and innovation programme under grant agreement No 101139067. This document does not reflect the opinion of the European Union, and the European Union is not responsible for any use that might be made of the information contained therein. This document contains information that is proprietary to the ELASTIC Consortium partners. Neither this document nor the information contained herein shall be used, duplicated, or communicated by any means to any third party, in whole or in parts, except with prior written consent of the ELASTIC Consortium. The quality of this deliverable was improved with the assistance of digital tools; all content was reviewed and approved by the authors.
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 4 - August 31, 2025 Table of Contents LIST OF FIGURES ................................................................................................................................................ 6 LIST OF ABBREVIATIONS ................................................................................................................................ 7 EXECUTIVE SUMMARY .................................................................................................................................... 9 1 INTRODUCTION....................................................................................................................................... 11 1.1 PURPOSE AND SCOPE OF THE DOCUMENT ............................................................................................ 11 1.2 RELATION TO WORK PACKAGES, DELIVERABLES, AND ACTIVITIES .................................................... 11 1.3 CONTRIBUTION TO WP4 AND PROJECT OBJECTIVES ............................................................................ 11 1.4 STRUCTURE OF THE DOCUMENT .......................................................................................................... 12 2 ARCHITECTURE AND COMPONENTS............................................................................................... 13 3 WEBASSEMBLY FOR IOT EDGE NODES .......................................................................................... 15 3.1 WEBASSEMBLY FOR IOT DEVICES ....................................................................................................... 15 3.2 KEY FEATURES ENABLING EFFICIENT EXECUTION: SANDBOXING, PORTABILITY, SMALL BINARY SIZE, AND HIGH EFFICIENCY ........................................................................................................................................ 16 3.3 CHALLENGES AND OPTIMISATION STRATEGIES ................................................................................... 17 3.4 AI ON IOT DEVICES USING WASM ...................................................................................................... 18 3.4.1 Enhanced Local Model Inference with Rust Burn and WebAssembly ........................................... 18 3.4.1.1 Motivation and Framework Selection ................................................................................................... 18 3.4.1.2 ELASTIC Extensions and the Propeller Orchestrator .......................................................................... 19 3.4.1.3 Deployment Workflow and Integration ................................................................................................ 19 3.4.2 Federated Learning on IoT devices ................................................................................................ 20 3.4.3 Extending the ERAIA Framework with WebAssembly ................................................................... 24 3.4.4 Implementation Strategy for Federated Learning using Wasm at the Edge .................................. 25 3.5 IMPLEMENTATION OF WASM-CAPABLE IOT NODE - S0 BOARD ........................................................... 28 3.5.1 Hardware Overview ....................................................................................................................... 29 3.6 WASM MICRO RUNTIME (WAMR) .................................................................................................... 30 3.6.1 WAMR Feasibility .......................................................................................................................... 31 3.6.2 Performance and security optimisations for resource-constrained edge devices .......................... 31 3.6.3 WAMR Deployment on Zephyr RTOS ............................................................................................ 32 3.7 WASI FOR IOT NODES AND CYBER-PHYSICAL DEVICES ....................................................................... 34 3.7.1 Existing WASI support for IoT edge devices .................................................................................. 34 3.7.2 ELASTIC developments of WASI proposals for IoT edge devices ................................................. 35 3.7.2.1 GPIO WASI API design ....................................................................................................................... 36 3.7.2.2 GPIO WASI Example Usage ................................................................................................................ 38 3.7.2.3 GPIO WASI Evaluation ........................................................................................................................ 39 3.8 CONCLUSION ........................................................................................................................................ 41 4 EBPF FOR IOT SECURITY AND NETWORK OPTIMISATION ..................................................... 42 4.1 EBPF AND XDP FOR REAL-TIME NETWORK FILTERING ON IOT GATEWAYS ......................................... 42 4.1.1 Types of XDP-offloaded packet forwarding ................................................................................... 43 4.1.2 Security policy enforcement with XDP-offloaded Netfilter flowtables ........................................... 44 4.1.3 Performance evaluation ................................................................................................................. 46 4.1.4 IoT Packet filtering aspects ............................................................................................................ 47 4.2 EBPF FOR NETWORK SECURITY MECHANISMS ON EDGE NODES ........................................................... 49 4.2.1 eBPF based policy and intent based solutions for IoT ................................................................... 49 4.2.2 Encrypted/proprietary IoT traffic processing and monitoring on the edge ................................... 50 4.2.3 eBPF based observability, detection and monitoring on the edge ................................................. 51 4.2.4 eBPF and AI-IDS security mechanism on edge nodes ................................................................... 52 4.3 CONCLUSION ........................................................................................................................................ 54 5 TRUSTED EXECUTION ENVIRONMENTS (TEES) FOR IOT ......................................................... 55 5.1 TEE STANDARDS FOR IOT SECURITY .................................................................................................. 55
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 5 - August 31, 2025 5.2 HARDWARE-BASED ATTESTATION AND REMOTE ATTESTATION PROTOCOLS FOR NATIVE AND BYTECODE SOFTWARE ........................................................................................................................................ 59 5.3 USAGE AND AVAILABILITY OF TEES ON CONSTRAINED DEVICES......................................................... 61 5.3.1 ARM TrustZone .............................................................................................................................. 61 5.3.2 RISC-V Keystone Enclaves ............................................................................................................. 62 5.3.3 RISC-V CoVE ................................................................................................................................. 62 5.3.4 ARM CCA ....................................................................................................................................... 64 5.3.5 Android ........................................................................................................................................... 64 5.4 HARDWARE-BACKED TEE FOR IOT SECURITY ON ESP32-C6 ............................................................. 65 5.4.1 Boot Sequence and Lifecycle .......................................................................................................... 67 5.4.2 Trust Anchors and Attestation ........................................................................................................ 68 5.4.3 Cryptographic Services and Key Management .............................................................................. 69 5.5 CONCLUSION ........................................................................................................................................ 69 6 CONCLUSION AND NEXT STEPS ........................................................................................................ 70
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 6 - August 31, 2025 List of Figures Figure 1. A simplified overview of the ELASTIC architecture. ............................................................ 13 Figure 2. Federated Learning with TEE and WebAssembly ................................................................. 22 Figure 3. ERAIA overview with distributed workers deployed, e.g., on IoT Gateways. ...................... 24 Figure 4. ERAIA Intelligence Processors Units (IPU) composed to build an Intelligence Data Pipeline. Each Worker runs on a GraalVM with support for WASM workloads (GraalWasm). ......................... 25 Figure 5. The S0 IoT board running Zephyr RTOS and WAMR .......................................................... 29 Figure 6. The ELASTIC developments in standardising a WASI GPIO interface and providing host implementations and demo guest applications showcasing its functionality ......................................... 35 Figure 7. Test setup for the Native and WebAssembly benchmarks. The Benchmark process changes the value of the first pin and times how long it takes for the Testapp to read this value and set the second pin to the same value. ............................................................................................................................. 40 Figure 8. Ping-pong test for Native (left) and WASM (right) implementation, on cycle ...................... 40 Figure 9. Memory usage comparison GPIO: native vs WASM............................................................. 41 Figure 10. Overview of Netfilter’s “flowtable” forwarding offload. Solid arrows represent the packets’ data path, dashed arrows symbolise the flowtable control path. ............................................................ 44 Figure 11. Schematic representation of the data and control paths for the XDP flowtable offload forwarding technique, with special focus on the packet filtering function. ........................................... 45 Figure 12. Representation of the experimental setup used for measuring the performance of different forwarding solutions in Linux. ............................................................................................................... 46 Figure 13. Throughput (left) and latency (right) of the XDP-accelerated Linux flowtable data plane relative to other relevant configurations. ............................................................................................... 47 Figure 14. Architecture of the first version of the integrated ELASTIC security tool, combining the eBPF framework with the AI-IDS module on low resources edge device. ..................................................... 54 Figure 15. Roles and messages in RATS architecture. .......................................................................... 56 Figure 16. High-level overview of the ACE architecture. ..................................................................... 63 Figure 17. ESP32‑C6 TEE architecture illustrates the high-level split: the REE (user-mode) application and OS issue service calls to the secure machine-mode firmware, which in turn encloses trusted hardware modules (PMP/PMA, APM, MMU, eFuse, crypto engines) inaccessible from the REE. ..... 66 Figure 18. ESP32‑C6 TEE boot/lifecycle flow ...................................................................................... 68
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 7 - August 31, 2025 List of Abbreviations ACE Assured Confidential Execution AI Artificial Intelligence AI-IDS Intelligence-driven Intrusion Detection System AOT Ahead-of-Time (compilation) API Application Programming Interface APM Access Permission Management BLAS Basic Linear Algebra Subprograms CoAP Constrained Application Protocol CBOR Concise Binary Object Representation CCA Arm Confidential Compute Architecture CVMs Confidential Virtual Machines CPU Central Processing Unit DPDK Data Plane Development Kit DRM Digital Rights Management DTLS Datagram Transport Layer Security EAT Entity Attestation Token eBPF extended Berkeley Packet Filter EMI electromagnetic interference FedAvg Federated Averaging FIB Ethernet forwarding base (FIB) FIB Forwarding Information Base FL Federated Learning GPIO General-Purpose Input/Output GPU Graphics Processing Unit HAL Hardware Abstraction Layer IDS Intrusion Detection System IPUs Intelligent Processing Units IoT Internet of Things JCA Java Cryptographic Architecture JIT Just-in-Time (compilation) LKNS Linux Kernel Network Stack LoRa Long Range LwM2M Lightweight Machine-to-Machine
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 8 - August 31, 2025 MEC Multi-Access Edge Computing ML Machine Learning NIC Network Interface Card ONNX Open Neural Network Exchange OP-TEE Open Portable Trusted Execution Environment OTA Over-the-Air PMA Physical Memory Attributes PMP Physical Memory Protection PoC Proof-of-Concept RATS Remote Attestation Procedures RoT root-of-trust RTOS Real-Time Operating System RTT Round-Trip Time SAU Secure Attribution Unit SDF Semantic Definition Format TCB Trusted Computing Base TEE Trusted Execution Environment TEEP Trusted Execution Environment Provisioning TLS Transport Layer Security TPM Trusted Platform Module TPS Trusted Platform Services UPF User Plane Function WAMR WebAssembly Micro Runtime WASI WebAssembly System Interface Wasm WebAssembly WGPU Web Graphics Processing Unit WP Work Package XDP eXpress Data Path
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 9 - August 31, 2025 Executive Summary Deliverable D4.1: Wasm, eBPF and TEE Enablement on Edge presents the initial results of Task 4.1 – Support for Wasm, eBPF and TEEs on IoT Edge Nodes. In line with the objectives, the task aimed to investigate the feasibility and optimise the deployment of WebAssembly (Wasm) workloads on resource-constrained devices, extend runtime capabilities for secure hardware access via WebAssembly System Interface (WASI), explore the use of eBPF/XDP for in-kernel observability and low-latency packet processing on IoT gateways, and assess the applicability of TEEs for integrity and authenticity of code execution. The work reported here provides a solid technical foundation for trusted, portable, and efficient workload execution across heterogeneous and distributed environments in the ELASTIC architecture. The activities in Task 4.1 have focused on both assessing the feasibility of these technologies in IoT scenarios and producing concrete prototypes that validate their applicability. The evaluation of the WebAssembly Micro Runtime (WAMR) on microcontroller-based platforms such as the ESP32-C6 confirmed its suitability as a portable runtime for constrained environments, achieving low memory footprint execution, Ahead-of-Time (AOT) compilation, and compatibility with real-time operating systems such as Zephyr RTOS. Additional performance and security optimisations were assessed, including modular runtime configuration, capability-based access to host resources, deterministic execution for real-time control, and avoidance of runtime code generation to mitigate side-channel risks. This ensures that the same application logic can run securely and efficiently across diverse CPU architectures, addressing the objective of reducing integration complexity in heterogeneous edge deployments. Beyond the runtime layer, the deliverable explores the role of Wasm in Edge AI and Federated Learning (FL). The integration of Rust-based deep learning libraries such as Burn enabled deployment of quantised models for efficient inference on constrained devices. A Wasm and TEE-based FL architecture has been designed to enable trusted, privacy-preserving training workflows through remote attestation, ensuring that model updates are both authentic and securely executed. In addition, the ERAIA dataflow engine has been extended to support Wasm-based compute modules, targeting secure, lightweight execution of Intelligent Processing Units (IPUs) within distributed AI pipelines. Another major achievement is the extension of the WASI with a GPIO API for secure, standardised access to digital and analogue pins on IoT devices. The design follows portability, security, flexibility, and simplicity principles, allowing compatibility with a wide range of hardware backends. The interface was benchmarked for latency and memory overhead, demonstrating that secure hardware access can be integrated without degrading performance. The deliverable also examines the application of eBPF and XDP for in-kernel observability and control on Linux-based IoT gateways. A flowtable-based packet-forwarding mechanism integrated with Netfilter was implemented and benchmarked for throughput and latency. Capabilities such as filtering, packet tagging, and real-time monitoring were demonstrated, along with integration into AI-driven intrusion detection systems (IDS) for enhanced security analytics on resource-constrained platforms. This approach addresses the objective of providing programmable, low-overhead network control at the edge. Finally, the use of TEE environments was investigated for hardware-based isolation of critical operations, including secure boot, cryptographic processing, and machine learning model execution. Various TEE technologies were analysed, including ARM TrustZone, Keystone, and ARM CCA. A prototype implementation was described on the ESP32-C6 microcontroller,
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 16 - August 31, 2025 environments where bandwidth and energy are limited. Furthermore, the Wasm runtime provides an isolated (sandboxed) environment, meaning that user code can be executed safely and separately from the device’s critical system. This is essential when an IoT device runs potentially untrusted or externally delivered code, such as plug-in modules or tasks received from the cloud, as the sandbox prevents such code from compromising the device’s stability or security. Together, these features make Wasm highly relevant for smart devices and sensors with limited resources, enabling them to run more complex applications (such as local data processing, ML, etc.). 3.2 Key Features Enabling Efficient Execution: sandboxing, portability, small binary size, and high efficiency A detailed analysis of Wasm capabilities and its broader technological landscape was presented in Deliverable 1.1 – Wasm and eBPF Landscape. In this section, we summarise the functionalities most relevant to IoT devices and edge computing scenarios, focusing on aspects that directly impact performance, security, and portability in resource-constrained environments. Sandboxed Execution. One of the core strengths of Wasm is its secure execution model. Wasm modules run within an isolated virtual machine (a sandbox) that enforces strict memory safety and access control. Modules cannot interact with the host system or memory directly; instead, they communicate only through explicitly defined interfaces. The sandboxed environment is especially beneficial for running externally delivered or untrusted code (e.g., dynamic plugins or cloud-sent tasks) on edge devices without risking system stability or security. Portability Across Architectures. Wasm is architecture-neutral. Its bytecode format allows the same module to be executed on a variety of hardware platforms, including ARM, x86, and RISC-V, as long as a compatible Wasm runtime is available. This makes it possible to write application logic once, compile it to Wasm, and deploy it uniformly across a heterogeneous IoT ecosystem without platform-specific adaptations 4 . Such portability greatly simplifies development, deployment, and maintenance in distributed systems composed of diverse devices. Small Binary Footprint. One of the key advantages of using Wasm in embedded scenarios is the extremely compact size of Wasm modules, which is particularly beneficial in IoT contexts where memory and bandwidth are constrained. For instance, the WAMR, tailored for embedded use, has a base size of approximately 60 KB for the interpreter, and as little as 30 KB for the AOT compiled runtime on devices such as Cortex-M4 microcontrollers 5 . Such minimal footprint enables fast over-the-air updates, reduces flash storage requirements, and allows Wasm modules to coexist with other critical software components on constrained devices. High Execution Efficiency. Despite its portability and security overhead, Wasm is engineered for performance. It supports Just-In-Time (JIT) and AOT compilation into native instructions, allowing it to achieve speeds close to that of native code. This makes it viable for executing relatively demanding tasks directly on IoT devices, such as real-time sensor data filtering, signal encoding, or even lightweight ML inference, without offloading computation to the cloud. 4 T. Orlando, L. D’Agati, F. Longo, and G. Merlino, “A survey of WebAssembly usage for embedded applications: Safety and portability considerations,” Journal of Systems Architecture, vol. 145, 2023, Art. no. 102747. [Online, Available: https://doi.org/10.1016/j.sysarc.2023.102747] 5 WebAssembly Micro Runtime (WAMR). Bytecode Alliance. [Online]. Available: https://bytecodealliance.github.io/wamr.dev/ [Accessed: Jun. 10, 2025].
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 17 - August 31, 2025 Moreover, Wasm modules exhibit extremely fast startup times, often faster than traditional containers or scripting runtimes, making them well-suited for event-driven execution models. Controlled Host Interactions. A key security and reliability advantage of Wasm is its controlled interaction with the host environment. All communication between a module and the host must be explicitly defined through imports and exports, reducing the attack surface and enforcing strict boundaries. The WASI 6 standard further supports safe, minimal, and modular interaction with system resources. This model ensures that Wasm modules can operate securely even in untrusted or multi-tenant environments, which is especially relevant when executing user-defined logic on edge devices. Performance Optimisation in IoT. Performance optimisation is essential in IoT contexts, where resources are scarce and efficiency is critical. The binary format of Wasm is compact and fast to parse and compile, significantly reducing the time from code download to execution. Additionally, as support for concurrency and multithreading evolves (e.g., through Wasm threads), developers can increasingly take advantage of multi-core edge devices to parallelise computation. These capabilities enable Wasm-based applications to respond quickly, conserve energy, and scale across various edge workloads, from simple event handlers to more complex distributed AI components, as emphasised in P.P. Ray 7 , where the authors highlight Wasm’s reduced code size, fast startup time, and lightweight runtime as key enablers for edge environments. 3.3 Challenges and Optimisation Strategies Despite its many advantages, deploying Wasm in resource-constrained IoT environments introduces several technical challenges that must be carefully addressed. These challenges can be broadly categorised into three domains: performance limitations, security concerns, and memory/resource constraints. Performance. Although Wasm aims for near-native execution speed, performance can still be impacted under certain conditions common in IoT contexts. Some Wasm runtimes rely on interpretation rather than JIT or AOT compilation, which can significantly reduce execution efficiency. Additionally, many IoT devices lack hardware support for floating-point operations or advanced instruction sets, making them ill-suited for complex computational tasks. The absence of mature multi-threading support in some Wasm runtimes further limits opportunities for parallel execution. To mitigate these issues, developers can adopt optimisation strategies such as using AOT compilation where available (e.g., WAMR AOT), minimising floating-point and dynamic memory usage, and restructuring hot code paths for sequential execution 8 . In scenarios with heavier computational needs, tasks can also be offloaded to nearby edge gateways with greater processing capabilities. Security. While sandboxing model provides strong isolation from the host environment, it is not immune to specific security risks, especially when untrusted code is deployed over-the-air (OTA) to devices in the field. Poorly designed or overly permissive host bindings can allow Wasm modules to interact with system-level resources in unintended ways, potentially breaching security boundaries. Additionally, without robust mechanisms for module signing and verification, malicious or tampered modules may be executed. Side-channel attacks, such as those based on timing or cache behaviour, also remain a theoretical concern in shared 6 WebAssembly System Interface (WASI). [Online]. Available: https://wasi.dev/ [Accessed: Jun. 10, 2025]. 7 P. P. Ray, "An overview of WebAssembly for IoT: Background, tools, state-of-the-art, challenges, and future directions," Future Internet, vol. 15, no. 8, Aug. 2023. [Online]. Available: https://doi.org/10.3390/fi15080275 8 S. Kakati and M. Brorsson, “WebAssembly beyond the Web: A Review for the Edge-Cloud Continuum,” 2023 3rd International Conference on Intelligent Technologies (CONIT), 2023, pp. 1–6, doi: 10.1109/CONIT59222.2023.10205816.
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 18 - August 31, 2025 environments 9 . To address these risks, it is important to enforce capability-based security using WASI or custom bindings with minimal privileges, verify module integrity before execution, and restrict host APIs to only the minimal set of functions required for safe operation. Memory and resource constraints. Inefficient memory usage in Wasm modules, particularly those written in low-level languages like Rust, C or C++, can lead to fragmentation, stack overflows, or heap exhaustion. While the lack of garbage collection in these languages enables more deterministic and fine-grained memory control, it also imposes a greater burden on developers to explicitly manage memory allocation and deallocation in order to avoid fragmentation and memory leaks. In addition, frequent instantiation of modules may cause resource churn and increase energy consumption, which is especially problematic for batterypowered devices. Recommended optimisation strategies include using static memory allocation and precomputed buffers, limiting stack usage through shallow function calls and minimal recursion, and reusing persistent module instances rather than creating new ones for each task or event. 3.4 AI on IoT devices using WASM Wasm enables portable, sandboxed ML model execution on edge/IoT devices, offering significant advantages including cross-platform portability across heterogeneous hardware, strict runtime isolation for security, dynamic OTA updates via Wasm module replacement, and near-native computational efficiency ideal for real-time inference. Platforms like wasmCloud 10 demonstrate these capabilities for distributed AI workloads, leveraging Wasm's lightweight footprint and fast startup times. For instance, a field camera can execute a pre-trained object detection model within a Wasm module, making local decisions without cloud dependency while maintaining the flexibility to run the same module on more powerful hardware when needed. The objective of this section is to examine how Wasm can be leveraged to enable secure, efficient, and portable AI/ML workloads across heterogeneous edge environments. We first examine how local inference using the Rust-based Burn framework and Wasm runtimes can optimise performance on constrained nodes. Next, we present an initial implementation strategy for FL using Wasm modules and TEEs. Finally, we outline an extension of the actorbased ERAIA framework to incorporate Wasm workloads, aiming to improve modularity, performance, and cross-platform deployment in intelligent data pipelines. 3.4.1 Enhanced Local Model Inference with Rust Burn and WebAssembly 3.4.1.1 Motivation and Framework Selection A key objective is to deploy intelligent applications efficiently across the heterogeneous cloudedge continuum. This requires a deep learning framework that is both performant on training hardware and deployable on resource-constrained edge devices. Several frameworks were considered, including Lite Runtime 11 , ExecuTorch 12 , and ONNX Runtime 13 . While capable, these often involve a conversion step (e.g., to TFLite or ONNX format) which can introduce compatibility issues and limit access to advanced operators. 9 M. E. Mazaheri, S. B. Sarmadi, and F. T. Ardakani, “A Study of Timing Side-Channel Attacks and Countermeasures on JavaScript and WebAssembly,” ISC International Journal of Information Security, vol. 14, no. 1, pp. 37–51, Sep. 2021. 10 wasmCloud, “Build, manage, and scale WebAssembly apps.” [Online]. Available: https://wasmcloud.com/. [Accessed: Jul. 18, 2025]. 11 “LiteRT overview,” ai.google.dev. https://ai.google.dev/edge/litert [accessed July 18, 2025]. 12 “ExecuTorch — Stable Documentation,” pytorch.org. https://docs.pytorch.org/executorch/stable/index.html [accessed Aug. 28, 2025]. 13 “ONNX Runtime — Home,” onnxruntime.ai. https://onnxruntime.ai/ [accessed July 18, 2025].
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 19 - August 31, 2025 The Burn framework 14 was selected for ELASTIC due to its native Rust foundation, which provides memory safety and enables direct compilation to Wasm and bare-metal targets. Its primary advantage is a hardware-agnostic backend system that allows a model trained on a cloud GPU to be executed on an edge CPU with zero code changes, eliminating conversion bottlenecks. Burn’s design aligns with ELASTIC's needs for extreme flexibility, small binary size, and support for a wide range of hardware targets, from servers to microcontrollers. Burn's architecture supports this through multiple backends: WGPU for cross-platform GPU acceleration, Candle for lightweight CPU inference, and NDArray for devices without accelerators. For edge deployment, Burn's static INT8 quantisation is critical, reducing model sizes by approximately 4×. This is achieved through quantisation-aware training techniques to minimise accuracy loss. Furthermore, its embedded-first design supports no_std environments via feature flags, achieves binary footprints under 500KB, and employs optimisations like kernel fusion. 3.4.1.2 ELASTIC Extensions and the Propeller Orchestrator To address the challenge of managing distributed inference workloads, Propeller orchestrator was developed. Propeller 15 is designed to manage Wasm modules across the cloud-edge continuum, from cloud servers down to microcontrollers. Its architecture combines a central manager service with distributed light-weight worker nodes ("proplets"), using MQTT and SuperMQ 16 for IoT messaging. A key differentiator is its integration of the WebAssembly Micro Runtime (WAMR) on Zephyr RTOS, enabling dynamic workload distribution and deployment on highly constrained devices. As Propeller is part of WP2, further architectural and implementation details are provided in D2.1 17 . Propeller enhances the Burn-based pipeline by allowing developers to push compiled Wasm modules to OCI registries and then deploy them through declarative manifests that specify runtime parameters like memory constraints. 3.4.1.3 Deployment Workflow and Integration The deployment workflow integrates Burn with Wasm toolchains. Developers compile Rustbased Burn models to Wasm targets using the standard Rust toolchain: cargo build --target wasm32-wasi The resulting binaries are then further optimised with tools like Binaryen's wasm-opt for size reductions of up to 40%. Evaluation and Limitations While Burn provides significant advantages, our evaluation also identified limitations. The framework is still young, resulting in a less mature ecosystem compared to established frameworks (e.g., a smaller model zoo). Furthermore, its novel use of Rust traits and generic types can present a steeper learning curve for developers accustomed to Python-centric frameworks. 14 “Burn,” https://burn.dev/ [accessed Aug. 28, 2025]. 15 “Propeller,” https://docs.propeller.abstractmachines.fr/ [accessed July 18, 2025]. 16 “SuperMQ,” https://docs.supermq.abstractmachines.fr/ [accessed July 18, 2025]. 17 ELASTIC Project, Lightweight and Robust Orchestrating Mechanisms – Initial Version (Deliverable D2.1), Zenodo, 2025. doi: 10.5281/zenodo.15100798
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 20 - August 31, 2025 Practical implementations demonstrate the efficiency of this stack. A Raspberry Pi 4 smart camera deployment using Burn-compiled YOLOv8n (INT8-quantised) within Wasmtime achieves 15 FPS inference at 9ms per image - less than half the latency of Python-based TFLite equivalents. The solution consumes just 18MB memory versus 85MB for Python, with cold starts completing in 3ms versus 1.2 seconds. 3.4.2 Federated Learning on IoT devices In IoT and edge computing environments, vast amounts of data are generated on devices such as sensors, cameras, and smart hubs. The traditional approach of sending all this data to the cloud for centralised analysis becomes impractical due to limited bandwidth, latency issues, and privacy concerns. On the other hand, FL enables training of a shared ML model directly on the devices, ensuring that sensitive data never leaves the local environment. This preserves user privacy and reduces the need for continuous high-throughput connectivity. However, executing ML at the edge faces significant challenges. IoT/edge devices often operate in untrusted environments, are physically exposed, and potentially subject to compromise. There are several risks, most notably risk of model poisoning (a malicious device may send corrupted model updates) and data leakage through gradients or model weights shared during the FL process 18 19 . Additionally, these devices lack a unified root of trust as each device may have a different level of reliability, complicating trust in training results. Besides security challenges, there are resource limitations, since devices vary in processor architecture, available RAM, and power supply. This environmental heterogeneity makes it difficult to develop a single ML solution that works across all platforms; traditionally, applications must be adapted for different operating systems and hardware architectures. Moreover, an FL system at the edge must cope with unreliable connectivity. In real-world deployments, the network is often intermittent, and edge clients vary greatly in capabilities. It is unrealistic to expect that all devices will be constantly available or have server-grade processing power. Therefore, FL logic must be lightweight and robust to function under such conditions. Wasm-based Federated Learning In the context of edge-based ML, Wasm is increasingly being explored as a promising enabler of portability and runtime isolation. Several initiatives and projects have already demonstrated its potential for deploying ML) workloads on heterogeneous IoT devices. For instance, the open-source WasmEdge 20 project enables AI inference directly within Wasm modules, allowing popular ML frameworks to be compiled into Wasm and executed across a range of device architectures. Similarly, WAMR 21 is tailored for embedded and edge devices, supporting the WASI standard to ensure safe and secure interaction between Wasm modules and the host environment. WAMR is lightweight enough to operate on microcontrollers while offering features such as JIT compilation to improve performance on more capable edge hardware. However, FL in this domain is still in its early stage, but there are clear signs of its potential. For example, Gottschalk et al. 22 proposed a framework, which presents one of the first 18 M. Fang, X. Cao, J. Jia, and N. Gong, "Local model poisoning attacks to Byzantine-robust federated learning," in Proc. 29th USENIX Security Symposium (USENIX Security 20), 2020, pp. 1605–1622. 19 X. Jin, P.-Y. Chen, C.-Y. Hsu, C.-M. Yu, and T. Chen, "Cafe: Catastrophic data leakage in vertical federated learning," in Advances in Neural Information Processing Systems, vol. 34, pp. 994–1006, 2021. 20 “WasmEdge,” https://wasmedge.org/ [accessed Jul. 18, 2025]. 21 “WAMR (WebAssembly Micro Runtime),” https://bytecodealliance.github.io/wamr.dev/ [accessed Jul. 18, 2025]. 22 F. Gottschalk, S. Schulte, N. Hemadasa, E. Ebrahimi, J. Edinger, and D. Kaaser, “Towards WebAssembly-Based Federated Learning,” in Proc. 11th IFIP WG 6.12 European Conf. on Service-Oriented and Cloud Computing (ESOCC 2025), Lecture
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 21 - August 31, 2025 comprehensive studies on using Wasm for FL. Their evaluation, using the FEMNIST 23 dataset, compared Wasm to native binaries and TensorFlow 24 FL framework. Results showed that while Wasm is around 35% slower than native code, it is significantly more portable and outperforms TensorFlow Federated by 83% in the single-thread regime, and is 35% faster in the multi-thread mode. Although their focus is on early-stage experimentation, the findings confirm the potential of Wasm as a unifying execution layer for FL workloads in distributed IoT settings. In addition to low-level IoT implementations, Garofalo et al. 25 proposed a Web-centric FL framework called FLAT, which runs FL directly in web browsers using ONNX Web and Wasm. While their system enables portable, dependency-free FL across heterogeneous clients in the cloudedge continuum, it is not specifically tailored for resource-constrained IoT devices. Instead, the approach focuses on browser-based environments, leveraging FedAvg over MNIST 26 and CIFAR-10 datasets to demonstrate cross-platform compatibility. The W3C FL Community Group further reinforces this direction, describing Wasm as an ideal portable deployment format for ML models in diverse runtime environments 27 . As part of the ELASTIC project, we have developed a novel FL architecture tailored for heterogeneous edge environments. This architecture leverages Wasm to ensure portability and sandboxed execution of training logic across diverse IoT devices, while TEE is used to provide integrity guarantees and secure model handling. Designed specifically for the ELASTIC framework, the architecture addresses the need for lightweight, modular, and secure orchestration of FL tasks at the edge. It comprises a central orchestrator and multiple IoT clients (e.g., Raspberry Pi) that collaboratively train a global model without sharing raw data. Key architectural features include: Wasm-based model distribution, isolated execution on the client side, and secure aggregation of model updates. Figure 2 provides an overview of the architecture and the role of each component. Notes in Computer Science, vol. 15547, pp. 40–54, Springer, Feb. 2025. [Online]. Available: https://books.google.rs/books?id=9JJIEQAAQBAJ 23 S. Caldas, S. M. K. Duddu, P. Wu, T. Li, J. Konečný, H. B. McMahan, V. Smith, and A. Talwalkar, “LEAF: A benchmark for federated settings,” arXiv preprint arXiv:1812.01097, 2019, doi: 10.48550/arXiv.1812.01097. 24 “TensorFlow Federated,” https://www.tensorflow.org/federated [accessed Jul. 18, 2025]. 25 M. Garofalo, M. Colosi, A. Catalfamo, and M. Villari, “Web-Centric Federated Learning over the Cloud-Edge Continuum Leveraging ONNX and WASM,” in Proc. 2024 IEEE Symposium on Computers and Communications (ISCC), Larnaca, Cyprus, 2024, pp. 1–6. [Online]. Available: https://doi.org/10.1109/ISCC60571.2024.10456321 26 L. Deng, “The MNIST database of handwritten digit images for machine learning research,” IEEE Signal Processing Magazine, vol. 29, no. 6, pp. 141–142, Nov. 2012, doi: 10.1109/MSP.2012.2211477. 27 “W3C Federated Learning CG,” https://github.com/w3c/federated-learning-cg [accessed Jul. 18, 2025].
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 22 - August 31, 2025 Figure 2. Federated Learning with TEE and WebAssembly The orchestrator is a service that manages the entire FL process, including model distribution, result aggregation and attestation management. Further details on the internal modules, as well as refinement of orchestration strategies and internal architecture, will be addressed in Deliverable 4.2 - Secure, lightweight and federated ML orchestration on the edge. Essentially, the orchestrator enables collaboration among distributed IoT devices in a reliable and scalable manner. At the beginning of each training round, the orchestrator initiates the process by distributing the global model (or just its current parameters) in the form of a Wasm module to remote devices. These modules contain precisely defined local training logic, compiled and configured by the orchestrator, and are executed directly on IoT clients within an isolated and portable runtime environment. Upon completing local training, clients return results in the form of gradients or updated model weights, back to the orchestrator. These data are then aggregated using standard strategies, most commonly the Federated Averaging (FedAvg) 28 algorithm. To ensure the integrity of the entire process, communication between the orchestrator and devices is cryptographically secured. Each Wasm module that the orchestrator sends to a client for its execution carries a digital signature that must be verified by the client before execution. Similarly, clients sign the results they return in order to prevent model replacement attacks. A key security functionality of the orchestrator is the implementation of a remote attestation mechanism, which enables the 28 X. Li, K. Huang, W. Yang, S. Wang, and Z. Zhang, “On the convergence of FedAvg on non-IID data,” arXiv preprint arXiv:1907.02189, 2019. [Online]. Available: https://arxiv.org/abs/1907.02189
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 23 - August 31, 2025 orchestrator to verify that the execution of the Wasm module is indeed occurring in a trusted and isolated environment. Based on the attestation report provided by the client, the orchestrator decides whether the training results will be accepted. This ensures that only verified and authentic contributions are included in the aggregation. IoT devices act as distributed clients in the FL system and play a crucial role in local data processing and model training. In the proposed architecture, these devices operate as trusted executors of FL tasks, using Wasm as a universal and isolated runtime for local processing. Each device in the system has an installed Wasm runtime environment, which allows secure and portable execution of modules delivered by the central orchestrator. Upon receiving a Wasm module, the device first performs cryptographic verification of the module's digital signature. This step ensures the module is authentic and that its content was not compromised during transmission. After successful verification, the client launches the module within a sandboxed Wasm environment, ensuring high execution security. The Wasm runtime restricts the device’s access to only permitted resources, such as specific CPU cycles, memory ranges, and allowed system functions. Any attempt to access unauthorised memory locations, network services, or file systems outside the sandbox is automatically blocked. This further enhances client-side security and enables the detection of potentially malicious modules. On the orchestration layer, several runtime coordination mechanisms are being considered. Wasm-native orchestrators such as WasmCloud provide capability-based routing and actormodel isolation that may align with FL modularity, but lack primitives for training round synchronisation and secure model aggregation. Conversely, existing FL libraries like Flower 29 offer fine-grained control over the training lifecycle but do not natively support Wasm module deployment. Therefore, we are currently assessing the feasibility of lightweight, hybrid orchestration mechanisms. These orchestration strategies for FL will be formally explored in Task 4.3. TEE-based Federated Learning Several research papers have addressed the challenge of securing the FL process by leveraging TEEs. The main idea is to ensure that sensitive parts of the training process, such as model parameters and gradients, are handled within secure enclaves, either on the client side, the server side, or both. For instance, Kuznetsov et al. 30 propose an end-to-end SecureFL framework that employs Intel SGX on the cloud aggregator side and ARM TrustZone on edge devices. In addition, Mo et al. 31 propose PPFL, a privacy-preserving FL framework that adopts a layer-wise training strategy inside TEEs to defend against common privacy attacks. Each model layer is updated sequentially within TEE-protected environments, ARM TrustZone on client devices and Intel SGX on the server, addressing enclave memory limitations. Their evaluation demonstrates that PPFL achieves strong privacy guarantees and comparable model utility to standard FL, without incurring significant communication or system overhead 32 . 29 “Flower: A Friendly Federated AI Framework,” https://flower.ai/ [accessed Jul. 18, 2025]. 30 E. Kuznetsov, Y. Chen, and M. Zhao, “SecureFL: Privacy Preserving Federated Learning with SGX and TrustZone,” in Proc. 6th ACM/IEEE Symposium on Edge Computing (SEC), San Jose, CA, USA, Dec. 2021, pp. 1–13. 31 F. Mo, H. Haddadi, K. Katevas, E. Marin, D. Perino, and N. Kourtellis, “PPFL: Privacy-preserving Federated Learning with Trusted Execution Environments,” in Proceedings of the 19th Annual International Conference on Mobile Systems, Applications, and Services (MobiSys ’21), ACM, 2021, pp. 94–108. 32 F. Mo, H. Haddadi, K. Katevas, E. Marin, D. Perino, and N. Kourtellis, “PPFL: Privacy‑preserving Federated Learning with Trusted Execution Environments,” Proc. 19th Int. Conf. on Mobile Systems, Applications and Services (MobiSys ’21), 2021.
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 24 - August 31, 2025 3.4.3 Extending the ERAIA Framework with WebAssembly One of the main challenges of processing the data of IoT devices is to bring intelligence to data pipelines and to enable this functionality at the level of the devices. The framework proposed at Hernandez et al. 33 , ERAIA, represents a significant advancement in IoT data processing frameworks, offering a reactive, actor-based system that enables intelligent data pipelines across distributed environments. The framework, depicted in Figure 3, addresses critical IoT challenges through integrated data management capabilities, optimised latency and throughput optimisations for complex algorithms, flexible AI computation deployment, robust distributed computing mechanisms, and dynamic reconfiguration capabilities. Its architecture, built around modular IPUs demonstrates impressive performance across various hardware platforms while maintaining scalability in both vertical and horizontal dimensions. Figure 3. ERAIA overview with distributed workers deployed, e.g., on IoT Gateways. Extending ERAIA to incorporate Wasm workloads presents a compelling opportunity for resource-constrained IoT environments. GraalVM 34 could serve as an enhanced runtime environment for ERAIA, leveraging its polyglot capabilities to execute Wasm modules alongside existing JVM-based code, while utilising the Truffle framework 35 for efficient interpretation of Wasm bytecode. The transformation of IPUs into Wasm-based modules would deliver platform-independent that is critical for heterogeneous IoT landscapes. Particularly suitable for the transformation code of IPUs, Wasm implementation would allow computationally intensive algorithms to run with near-native performance while leveraging Wasm's memory model for efficient state management and data persistence, addressing the key performance bottlenecks identified in the original ERAIA implementation (e.g., using Python). The IPUs are depicted in Figure 4. 33 A. Hernandez, B. Xiao and V. Tudor, "ERAIA - Enabling Intelligence Data Pipelines for IoT-based Application Systems," 2020 IEEE International Conference on Pervasive Computing and Communications (PerCom), Austin, TX, USA, 2020, pp. 19, doi: 10.1109/PerCom45495.2020.9127385. 34 “GraalVM,” https://www.graalvm.org/ [accessed Jul. 18, 2025]. 35 “Truffle Language Implementation Framework,” https://www.graalvm.org/latest/graalvm-as-a-platform/languageimplementation-framework/ [accessed Jul. 18, 2025].
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 25 - August 31, 2025 Figure 4. ERAIA Intelligence Processors Units (IPU) composed to build an Intelligence Data Pipeline. Each Worker runs on a GraalVM with support for WASM workloads (GraalWasm). For resource-constrained environments, Wasm integration offers substantial benefits including reduced footprint characteristics, enhanced security, improved performance, and seamless cross-platform deployment. Wasm modules typically require less storage space than equivalent JVM bytecode, demonstrate more predictable memory usage patterns, and exhibit significantly lower startup times compared to Python-based alternatives 36 . The security posture of ERAIA would be substantially enhanced through Wasm's sandboxed execution model, providing strong isolation between the IPUs without compromising performance. Performance improvements represent perhaps the most compelling argument for Wasm integration, offering near-native execution speed that would dramatically reduce the overhead for data transformation functions, potentially eliminating the 60-75ms processing penalty observed with Python integration. Additionally, Wasm's "compile once, run anywhere" approach perfectly complements ERAIA's distributed architecture, allowing the same processing logic to execute efficiently across diverse hardware platforms without recompilation. Implementation considerations for this extension would include careful selection of appropriate Wasm runtimes such as Wasmtime or WAMR that could be embedded within ERAIA workers, optimisation of memory management strategies to minimise data copying between processing stages, adaptation of ERAIA's actor model to accommodate Wasm execution contexts, and enhancement of the framework's migration capabilities to efficiently transfer Wasm module states between workers during dynamic reconfiguration events. The integration would maintain ERAIA's architectural integrity while significantly expanding its deployment options while preserving its core strengths in flexibility, scalability, and real-time processing capabilities. This approach would build upon ERAIA's existing virtualisation support, extending it to embrace the emerging standard for portable, efficient code execution that is increasingly relevant for next-generation IoT systems. 3.4.4 Implementation Strategy for Federated Learning using Wasm at the Edge While the architectural design of FL using Wasm and TEEs provides a conceptual framework, a practical implementation strategy is essential to validate feasibility on resource-constrained edge nodes. The proposed implementation within ELASTIC will demonstrate a working prototype of FL where all training code is executed inside Wasm modules, with attestation and secure communication used to ensure the integrity of the process. 36 “Python vs Wasm Benchmarks: Which programming language or compiler is faster,” https://programming-languagebenchmarks.vercel.app/python-vs-wasm [accessed Jul. 18, 2025].
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 32 - August 31, 2025 managed via explicit import/export interfaces, while WASI support enforces capability-based, least-privilege access to host resources. Last, the attack surface is further reduced through static compilation, avoiding runtime code generation, and deterministic execution, which eliminates timing variability that could be exploited in side-channel or denial-of-service attacks. 3.6.3 WAMR Deployment on Zephyr RTOS The Zephyr Project, a scalable and open-source Real-Time Operating System (RTOS) hosted by the Linux Foundation, was selected as the deployment environment after an evaluation of candidate RTOS options. The choice was guided by several requirements: support for resourceconstrained microcontrollers, availability of a modular and configurable kernel, integration with modern security primitives (e.g., secure boot, memory protection), and the ability to host Wasm runtimes. Alternatives such as FreeRTOS and RIOT were considered, but Zephyr provided the strongest alignment with the project’s needs due to its broad hardware support, active community, and comprehensive networking and driver subsystems. In particular, Zephyr’s proven capability to integrate with the WAMR was a decisive factor, as it enabled running Wasm modules with minimal additional porting effort. It should also be noted that hardware considerations played a role in narrowing down the options. As described in Section 3.5, the S0 board and its RISC-V microcontroller have firstclass support in Zephyr’s upstream tree, meaning device drivers and board definitions were already available. This reduced the engineering burden compared to other RTOS candidates that would have required significant porting effort. Thus, the selection of Zephyr was not arbitrary but a combination of technical fit (security, modularity, Wasm integration) and pragmatic hardware alignment, making it the most suitable foundation for this work. Environment and Toolchain Preparation To enable deployment and experimentation, a local development environment was set up on an Ubuntu 22.04 host machine. Following the official Zephyr Project guide, all required dependencies - including the Zephyr SDK and the west meta-tool - were installed to support project management, source synchronization, and board-specific builds. Zephyr’s flexible build system allowed for fine-grained control over board configurations and runtime integration layers. For the target platform, the ESP32-S3 SoC, binary hardware abstraction layer (HAL) blobs were required to enable peripheral access for Wi-Fi and Bluetooth functionality. They were integrated into the Zephyr workspace using the command: west blobs fetch hal_espressif The HAL is critical, as it enables the Zephyr kernel to interface with the extensive set of integrated peripherals and system-level features inherent to the ESP32-S3 SoC. The successful operation of the system relies on Zephyr managing the underlying components. This encompasses a wide range of functionalities including wireless connectivity (Wi-Fi Driver, Bluetooth® Low Energy, ESP-WIFI-MESH, RF Coexistence, and Wi-Fi Security), low-level system services (Bootloader, Application Startup Flow, Partition Tables, RF Calibration, and Hardware Abstraction), memory management (Support for External RAM, Memory Types, and SPI Flash Configuration), debugging and reliability (JTAG Debugging, Core Dump, Fatal Errors, Error Handling, Application Level Tracing), and power management (Deep-sleep Wake Stubs, Low Power Modes). The integration also leverages tooling and conventions for firmware updates, build processes, and language support, such as Device Firmware Upgrade (DFU) via USB, the Build System, and Linker Script Generation. To complement the HAL integration, a
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 33 - August 31, 2025 set of Python packages specific to Espressif’s development framework was installed using `pip`. The tools were necessary to enable firmware flashing, serial communication, and realtime debugging, and included utilities such as pyserial, esptool.py, idf_monitor, and pyelftools. Integration of WAMR as a Zephyr Module With the host environment established, the WAMR source code was integrated into the Zephyr project. This was accomplished by utilising Zephyr's west meta-tool, which manages external repositories as modules. The WAMR repository was added to the project’s west.yml manifest file as an external dependency. Executing the west update command then instructed the tool to clone the WAMR source code into the project's modules/wamr directory. Wasm Application Compilation A sample application was written in C and compiled to a Wasm binary. The wasi-sdk was utilised, as its clang compiler is configured to target the wasm32-wasi architecture. The C source file was compiled into a minimal Wasm binary using the following command, which specifies the target, optimisation level, and linker flags to create a non-executable side module suitable for embedding. clang --target=wasm32 -O3 -z stack-size=4096 \ -Wl,--initial-memory=65536,--allow-undefined \ -Wl,--strip-all,--no-entry \ -nostdlib -o hello_world.wasm hello_world.c As the target deployment does not assume a file system, the resulting binary was converted into a C-style byte array, allowing the Wasm module to be directly compiled into the Zephyr firmware. The xxd utility was used for this conversion: xxd -i hello_world.wasm > wasm_app.h The above generated header file was then included in the main application source of the Zephyr project. Zephyr Project and Build Configuration A Zephyr project was configured to integrate the WAMR module and the embedded Wasm application for the ESP32-S3 target. The target hardware was the Espressif ESP32-S3DevKitM development board, identified in the Zephyr build system as esp32s3_devkitm/esp32s3/procpu. The project configuration file was modified to enable WAMR and configure the ESP32-S3 hardware. PSRAM support was enabled to provide additional heap memory, which is crucial for Wasm execution given the static allocation model for linear memory in WAMR. The build script was configured to pass target-specific definitions to the WAMR build system. For the ESP32-S3's Xtensa LX7 architecture, the WAMR target was set to XTENSA. The AOT compilation mode was explicitly disabled in favour of the interpreter, which is better suited for the above class of microcontroller. Debugging symbols and runtime logs were enabled in the prj.conf file to observe WAMR's internal lifecycle events, such as module loading, memory allocation, and WASM function invocation.
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 34 - August 31, 2025 Firmware Compilation and Flashing The final firmware image was compiled and deployed to the ESP32-S3 hardware. Prior to the initial flash, the device's onboard flash memory was completely erased to ensure a clean state using the esptool.py utility. python3 -m esptool --chip esp32s3 erase_flash The Zephyr application, including the MCUboot bootloader, the Zephyr kernel, and the embedded WAMR runtime with the Wasm application, was compiled using the west command below: west build -b esp32s3_devkitm/esp32s3/procpu. -- - DWAMR_BUILD_TARGET=XTENSA -DWAMR_BUILD_AOT=0 The compiled firmware binaries were flashed to the ESP32-S3 board via its UART USB port using the west flash command, which automatically handles the two-stage boot process involving MCUboot and the main application image. After flashing, the device was reset. The application's execution, including the output from the Wasm module running within WAMR, was monitored via the serial console using the command: west espressif monitor 3.7 WASI for IoT nodes and cyber-physical devices 3.7.1 Existing WASI support for IoT edge devices This section briefly explains the existing support and gaps for WASI for IoT edge devices. A more thorough analysis of WASI can be found in D1.1. Wasm was originally designed to run binary code in the browser with a stricter type system than JavaScript. However, its usefulness beyond the browser quickly became evident. Wasm allows for platform-independent, sandboxed code execution. By design, it prioritises security and sandboxing, but this makes interaction with the host environment difficult and nonstandardised. WASI was developed to address this limitation. WASI defines a standardised set of APIs that WASM-targeted code can use to interact with the environment - such as filesystems, networking, and command-line interfaces. This standardisation furthers the “write once, run anywhere” paradigm. For example, code developed for an IoT sensor from one manufacturer could run unmodified on a sensor from another. The release of WASI Preview 2 introduces the Component Model, which provides a richer type system and capability-based security, enabling better module interoperability. While WASI already has support for more than 30 interfaces, such as file system I/O, network sockets, and HTTP requests, most of those interfaces are focussed on cloud workloads communicating over high-level APIs such as HTTP or TCP/IP sockets. As such, there is little support in WASI for interfacing with hardware using low-level protocols such as USB, GPIO, and SPI. Some approaches, such as WASM-IO 39 , make it possible for Wasm workloads to access external hardware without using WASI. However, the downside of that approach is that it is not standardised and requires extensive custom runtime modifications to enable it. In contrast, WASI is an API standardised by the W3C, and popular runtimes such as Wasmtime 39 M. Seidler, A. Krause, and P. Ulbrich, “Extending Lifetime of Embedded Systems by WebAssembly-based Functional Extensions Including Drivers.” 2025. [Online]. Available: https://arxiv.org/abs/2503.07553
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 35 - August 31, 2025 already have pluggable support for adding new WASI interfaces. Therefore, we propose to extend WASI by proposing multiple new IoT device-specific WASI interfaces. We expect this standards-first approach will enable a large ecosystem of forwards-compatible compilers, libraries and hardware abstraction layers that enable seamless interaction between Wasm workloads and connected hardware. 3.7.2 ELASTIC developments of WASI proposals for IoT edge devices In order to address the challenges in using Wasm on IoT nodes and cyber-physical devices, ELASTIC is extending Wasm runtimes and the WASI to support secure access to hardware resources. As part of Task 2.1, we have been developing support for communicating with external hardware using the USB and I2C protocols. D2.1 reports that work. As part of T4.1, we are also developing a more generic and low-level standard to communicate with devices supporting Generic Pin I/O (GPIO) protocols. This section reports on that work. Figure 6 shows the different ELASTIC innovations for GPIO support in Wasm in their broader context of the Wasm runtime. Figure 6. The ELASTIC developments in standardising a WASI GPIO interface and providing host implementations and demo guest applications showcasing its functionality General Purpose Input Output is a peripheral interface used by hardware to talk to the outside world by means of pins. It is the basis of many protocols like I2C and SPI. GPIO comes in two flavours: digital and analogue. • With digital GPIO, signals are represented by a binary 1 or 0. Where a 1 means active and a 0 means inactive. What a binary 1 or 0 represents in a voltage signal depends on the configuration of the chip and the chip driver itself. • With analogue GPIO, signals are represented by a range of values depending on the resolution of the used chip. The Arduino Uno, for example, has a 10-bit ADC, meaning that 0V up to Vmax is mapped in the interval [0, 1023].
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 36 - August 31, 2025 It is important for our interface to support both types of GPIO, to have the widest compatibility with existing use cases and hardware. For example, in a smart factory, digital GPIO is often used for powering simple LED displays or reading simple buttons, while analogue GPIO is used for reading vibration sensors. 3.7.2.1 GPIO WASI API design The full API of this proposal is available in the wasi-gpio repository in the W3C WebAssembly GitHub organisation. 40 A proof of concept implementation for the host part of this interface is available on GitHub 41 , as well as multiple demo guest implementations showing the functionality of this interface. The design of the WASI GPIO API follows four key principles: ● Portability: The interface must abstract away platform-specific details, allowing components to run on diverse hardware without modification. This also means the interface should be similar enough to existing GPIO HAL libraries to make it easy to port existing code to this interface. ● Security: Access to GPIO resources is governed by capability-based policies, ensuring strict control over hardware usage. While the actual enforcement of access control policies is up to the runtime, the interface is designed in a way that runtimes supporting capability-based security can apply that security layer to the interface. This is achieved by ensuring all functions are tied to a resource, ensuring the runtime can deny access to a function by denying access to the associated resource, i.e., the capability. ● Flexibility: The API supports both digital and analogue GPIO, with rich configuration options and interrupt capabilities. While this means not all GPIO controllers and devices will support all the functionality of this interface, it ensures that even the most complex existing applications can be ported. This means that a runtime might mock certain interfaces based on the capabilities of the underlying hardware. ● Simplicity: Despite its flexibility, the interface is designed to be intuitive and easy to use for developers. The GPIO API is divided into three main interfaces: 1. General Interface: Defines shared types and error variants. 2. Digital Interface: Provides access to digital GPIO functionality. 3. Analog Interface: Provides access to analog GPIO functionality. An additional delay interface is included for testing purposes but is scheduled for removal in favor of wasi:clocks. Pin Types The API defines seven distinct pin types. ● Digital Interface Pins: ○ digital-output-pin ○ digital-input-pin ○ digital-input-output-pin ○ stateful-digital-output-pin ● Analog Interface Pins: 40 “wasi-gpio/gpio.wit,” https://github.com/WebAssembly/wasi-gpio/blob/main/wit/gpio.wit [accessed Jul. 18, 2025]. 41 “wasi-gpio-implementations,” https://github.com/idlab-discover/wasi-gpio-implementations/ [accessed Jul. 18, 2025].
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 37 - August 31, 2025 ○ analog-output-pin ○ analog-input-pin ○ analog-input-output-pin Each pin type is represented as a resource with associated methods for configuration, state manipulation, and interrupt handling. Pin configuration Pin configuration is specified using structured flags and records. Key configuration options include: ● Pin Mode: Input, output, or input-output. ● Active Level: Specifies whether the pin is considered "active" when it is at a high voltage (active-high) or low voltage (active-low). Depending on the usage and physical wiring of pins, different modes may be preferred. For example, to implement SPI, the pin connected to the chip-select lines should be set to active-low. ● Pull Resistor: Indicates whether an internal pull-up or pull-down resistor should be enabled. Pull-up resistors connect the pin to a high voltage level, while pull-down resistors connect it to ground. ● Initial State: For output pins, this defines whether the pin should start in an active or inactive state upon initialisation. ● Analog Backend: For analogue output pins, this specifies the technology used to generate analogue signals: ○ PWM (Pulse Width Modulation): Simulates analogue output by rapidly toggling a digital signal. The duty cycle determines the average voltage. ○ DAC (Digital-to-Analog Converter): Converts digital values directly into corresponding analog voltages. This provides smoother and more precise analogue output than PWM. These configurations are passed during pin construction and can be queried at runtime Interrupt Support Interrupts are essential for responsive embedded applications. The API supports: ● Digital Interrupts: ○ Watch for specific states (active/inactive). ○ Watch for edge transitions (rising/falling). ● Analog Interrupts: ○ Trigger when signal rises above or falls below a threshold. Interrupts are implemented using the pollable type from wasi:io, allowing asynchronous-like behaviour in a synchronous environment. Pin labelling and access control The interface itself defines pins by labels such as GPIO1 and GPIO2. How these labels translate to the physical pins is left open to implementations. Operating systems generally also identify GPIO pins using labels, so a simple implementation would be that the labels passed by this interface are simply the labels as set by the operating system itself. Our implementation, however, includes the possibility to map application-level labels passed over the interface to physical labels as used by the operating system. This way, application code could use higher-level generic virtual labels (vlabels) such as LED1, while the operating system translates this into a physical label (plabel) such as GPIO1. The advantage of this approach is
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 38 - August 31, 2025 that it allows you to write more portable code that can handle changes in which pins correspond to which functionality. This way, each runtime could map the same higher-level label to a different physical pin based on the configuration of the device. A second optional addition of our implementation is making it possible to define the permissions of a guest using capability-based security. While the interface itself is designed to support capability-based security, whether a runtime implements it can vary between runtimes. We envision simple runtimes allowing any access by default while more complex runtimes give each workload only limited access as specified by a security orchestrator. Our implementation allows operators to specify the pin label mapping and access control using a toml configuration file. Resource Lifecycle Pin resources are constructed using static methods and are tied to the virtual labels (vlabels) defined in a policy file. When a resource goes out of scope, it can be replaced with a new resource using the same physical pin but a different mode. 3.7.2.2 GPIO WASI Example Usage To better illustrate the interface, this section walks through some example code showing how to use the interface from Rust code. 1. Define the Pin in the Policy File Before a component can access a pin, the host must define it in the policy file: This maps the virtual label LED1 to the physical pin GPIO2 and allows it to be used as a digital output and a digital input. 2. Construct the Pin Resource In your WebAssembly component, you can construct the pin using the get method: Here, flags is a configuration object that can specify: ● Initial state (active/inactive)
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 39 - August 31, 2025 ● Active level (high/low) ● Pull resistor (optional) 3. Set the Pin State Once the pin is constructed, you can control its output voltage using: Alternatively, you can use: These methods abstract away the actual voltage level, which depends on the active level configuration (e.g., active-high means 3.3V is active). 4. Clean Up When the pin resource goes out of scope, it is automatically dropped. You can then reinitialise it with a different mode if needed. 3.7.2.3 GPIO WASI Evaluation We implemented both the host side of this interface in the Wasmtime runtime, and the guest side of this interface as a Wasm application as shown in Figure 7. This section explains the performance overhead of the proposed WASI interface compared to the native Linux GPIO API. All code is run on a Raspberry Pi 4. The operating system running on it is an unmodified Ubuntu Server 24.10 64 bit. The benchmarks are performed using Wasmtime instead of the previously mentioned WAMR runtime because wasi-gpio is a WASI Preview 2 interface, while WAMR currently only supports WASI Preview 1 interfaces. The benchmarks are performed on Linux instead of the aforementioned Zephyr OS because Wasmtime does not yet have stable support for Zephyr. Benchmarking is performed using a ping-pong test. This test measures the average time it takes for the implementation to react to a pin event by sending the same event back. Figure 7 shows the test setup. • The “Testapp” is the application whose latency is being measured. In the WebAssembly benchmarks, this application runs as a WebAssembly module and uses the WASI GPIO interface. It continuously reads one pin and sets the second pin at the value of the first pin. • The “Benchmark process” is the application that completes the ping-pong chain and measures the latency of the Testapp. This process starts by turning on the first pin, and measuring the time from when the first pin is on until it reads a change in the second pin. The time at which the first pin is on is approximated by taking the average between the time before and after changing the first pin in the Benchmark process.
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 40 - August 31, 2025 Figure 7. Test setup for the Native and WebAssembly benchmarks. The Benchmark process changes the value of the first pin and times how long it takes for the Testapp to read this value and set the second pin to the same value. To reduce the impact of scheduling noise, each benchmark was repeated 10.000 times. Figure 8 shows the resulting latency distribution of the benchmarks. While the native implementation averages an overhead of 205 nanoseconds, the Wasm implementation averaged an overhead of 1100 nanoseconds, more than a 5x increase in latency. While this is a large relative overhead, it is very small in absolute terms: less than 0.001 ms compared to native execution. This latency overhead is acceptable for all except the most stringent hard real-time workloads. Figure 8. Ping-pong test for Native (left) and WASM (right) implementation, on cycle However, the memory overhead of this system is more significant. Figure 9 shows the memory overhead of a simple GPIO application running natively versus in Wasmtime using GPIO. This shows a total overhead (runtime + workload) of about 1.3 MB. Although this overhead could be reduced by using a runtime optimised for low-resource devices, such as WAMR, we expect that running an application in Wasm will always involve a significant memory overhead.
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 41 - August 31, 2025 Figure 9. Memory usage comparison GPIO: native vs WASM. 3.8 Conclusion This section has demonstrated Wasm is a viable and efficient execution model for constrained IoT edge environments. The integration and evaluation of the WAMR runtime on platforms such as the ESP32-C6 confirmed its ability to deliver low-overhead, sandboxed execution with deterministic behaviour, addressing key requirements for secure and portable edge computing. The extension of WASI with support for GPIO access further validated Wasm’s capacity to interact with hardware-level resources in a standardised and modular way, enabling safe execution of device-specific functionalities. The deployment of quantised ML inference using lightweight Rust-based frameworks, along with the integration of Wasm into actor-based systems like ERAIA, illustrates how Wasm can support real-time data processing and decisionmaking directly on heterogeneous edge devices. Furthermore, a novel FL architecture has been defined, combining Wasm for portable training execution with TEEs for attested model handling and secure communication, enabling end-to-end protection of distributed learning workflows across diverse clients. These technical outcomes establish Wasm as a robust building block for future developments within the ELASTIC architecture, specifically in the areas of workload mobility, secure orchestration, and modular execution across the cloud-edge continuum.
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 48 - August 31, 2025 Mpps), minimise latency, and maximising throughput. The proposed solution provides 10Mpps, using 85% of the CPU compared to DPDK. One complex task case where speed and efficiency play an important role is data model conversion. eBPF programs are typically small and constrained in size and operations. The purpose of the limitations is to make sure that the CPU is not occupied indefinitely, allowing it to be available for other processing tasks. Tail calls in eBPF enable chaining multiple eBPF programs to run sequentially 60 . Unlike traditional function calls, tail calls do not return to the calling function. This allows more complex operations to be executed, when the operations can be split into separate eBPF programs. The number of tail calls is limited to 31. Given that one eBPF program can contain up to one million instructions, this effectively allows a maximum complexity of approximately 31 million instructions. For application data processing, this means that tasks, such as data model conversions, can be performed directly within eBPF/XDP when a packet arrives. For example, an MQTT payload could be translated into an SDF payload. As with any such implementation, the benefits and drawbacks should be carefully evaluated before implementation. eBPF based solutions can bring enhancement for MQTT message routing. The MQTT Broker routes messages to subscribers based on the topic descriptions. A MQTT Broker architecture could be centralised (single broker) or distributed (multiple coordinating brokers) architecture. A MQTT usually sits in the cloud or in the edge, and there are lightweight variants that can run directly on low-powered devices. Traditional MQTT cluster approaches face numerous challenges including data consistency maintenance, complex load balancing, fault tolerance implementation, inefficient cross-shard communication, limited elasticity, operational complexity, difficult migration processes, inadequate monitoring, and bi-directional communication issues 61 . Clustering techniques improve performance and scalability by allowing multiple servers to handle requests simultaneously, making it easier to manage large datasets. Sharding is the practice to distribute data across multiple nodes/clusters, as to ensure scalability, resilience/fault-tolerance and high-performance communication. For MQTT clusters, the published data is handled by a load balancer which distributes it to the MQTT shards or nodes. The subscriber retrieves it via a dispatcher (with a routing service). An eBPF based solution can be employed to enhance load balancing functionality in MQTT cluster sharding, with the help of a fast path. By implementing kernel-level packet inspection and routing, the solution enables direct message forwarding to the appropriate shard based on fixed or variable MQTT header information, eliminating unnecessary broker-level processing. This eBPF-driven sharding mechanism operates under cluster manager control, ensuring coordinated distribution policies while maintaining cluster-wide visibility. The solution can be deployed at an IoT gateway which has eBPF support, on which an eBPF application generated by the MQTT cluster manager. The eBPF application contains all the necessary information for routing of the MQTT messages to the appropriate MQTT shard, bypassing the MQTT loadbalancer, thus shortening the data path. As an enhancement to classical IP based routing, in this case the routing is performed by using the MQTT topic, ensuring a shorter data path between 60 Liz Rice, John Fastabend, “eBPF: Yes, it’s Turing Complete!”, blog post, Isovalent, 12.9.2024, https://isovalent.com/blog/post/ebpf-yes-its-turing-complete/ [Accessed: June 18, 2025] 61 Navigating the Challenges of MQTT Sharding for IoT Scalability: https://www.hivemq.com/blog/navigating-challenges-ofmqtt-sharding-for-iot-scalability/ [Accessed: June 18, 2025]
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 49 - August 31, 2025 the data producer (publisher) and data consumer (subscriber), enhancing privacy and data protection by distributing data directly to intended recipients. Topic based routing at the IoT gateway has some limitations, for example in secure scenarios with encrypted MQTT traffic, as the solution described above requires access to the MQTT packet content for the MQTT topic. Examples of three variations which can be employed to still make use of MQTT topic based routing at the IoT gateway level are provided next. In the first case, MQTT traffic ingested from constrained client devices which do not support TLS (computational overhead), the TLS encryption will be used from the IoT gateway onwards to the MQTT broker. In this case, the IoT gateway will have access to the MQTT topics. In the second case, MQTT encrypted traffic originating from the device, the IoT gateway can have a SSL/TLS proxy functionality so MQTT data will be decrypted/inspected/re-encrypted at the IoT gateway level. In the third case, COSE MQTT payload representation can be used for encryption. In this case, similarly like above, the IoT gateway can have a COSE decryption/reencryption functionality which can be for the whole MQTT payload or only for the MQTT topic object (the key can be exchanged between the MQTT cluster manager and the IoT Gateway during the setup phase), or (if not sensitive) the MQTT topic object can be sent in clear (while the value is encrypted). The former is generally similar with attribute-based encryption techniques where different keys are used to access different attributes/parts of the payload. The result is a significantly more robust and scalable IoT messaging infrastructure that leverages kernel-space efficiency to reduce latency, improve throughput, and enable seamless horizontal scaling while minimising the traditional overhead associated with broker-level sharding implementations. 4.2 eBPF for network security mechanisms on edge nodes eBPF can enable security-related tasks on constrained IoT nodes, such as lightweight monitoring, policy enforcement, and anomaly detection, supporting secure operation without introducing high overhead. 4.2.1 eBPF based policy and intent based solutions for IoT One network security solution for edge nodes could leverage eBPF technology to create isolated security mechanisms that operate directly within the kernel space, controlled by a central management system. This approach would allow for real-time monitoring and protection without modifying the kernel source code. By implementing encrypted communication channels between a central management server and edge devices, security policies could be remotely deployed and updated across distributed networks. For example, a Lightweight Machine-to-Machine (LwM2M) 62 device management system could serve as the central management platform, providing standardised interfaces for device provisioning, configuration management, and security policy distribution. The solution would feature a verification system to validate all code before execution, preventing potentially harmful operations while allowing legitimate security functions to access necessary hardware resources. This architecture would enable continuous monitoring of network traffic, device status, and potential threats directly at the edge, with minimal performance impact. Security operations would remain isolated from user space, protecting them from tampering even if user-level systems were compromised. The framework could support dynamic security policy enforcement, allowing for immediate responses to emerging threats without service interruption or physical access to devices. This 62 Alliance, Open Mobile. "Lightweight machine to machine technical specification." Technical Specification OMA-TSLightweightM2M-V1 (2013).
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 50 - August 31, 2025 would be particularly valuable in IoT environments where devices are deployed in physically insecure locations but still require enterprise-grade security protections. In a short definition, a policy is a collection of guidelines or rules that determine an action. In IT systems policies play an important role as they define procedures for accessing, securing and interacting with these systems. Policies express in an imperative way rules that describe what to decide and how to maintain a specific situation. In contrast, Intents are an abstract type of policies which describe in a declarative way outcomes and states which the system needs to reach. Compared with policies where the rules to follow and the recipes towards a goal or state are well defined, intents define only the goal or state and leave the path to reach those at the latitude of the underlying framework. The languages supporting policies and intents are adapted to the properties of each, imperative for the former, declarative for the latter and, most often, both of them are domain specific. According to Nguyen et al. 63 IoT orchestration deployment engines are 71% declarative, 23% imperative and 6% mixed. Kasem-Madani and Meier 64 investigate solutions and languages for security and privacy policies and their conclusion is that their majority are imperative and machine-readable. Intents and declarative based languages are closer to the business layer (human language) as they describe outcomes and expectations, while imperative languages are closer to the devices and processes as they describe the exact steps and rules that need to be followed. There are a number of challenges raised by the heterogeneity of the IoT domain and the history and scope of the already existing policy and intent frameworks. Two of these challenges are related to the interoperability and penetration of policy languages, and can be tackled by eBPF based solutions are related to the interoperability and penetration of policy languages. The interoperability challenge is caused by the design, expressiveness, and syntax of the policy languages, that depends on the goal intended to be achieved which results in a large number of specialised solutions63. The penetration challenge is caused by a lack a solutions going down to device level62 (due to specialised devices/software and “black-box” nature), and most of them cover cloud, edge and fog . One solution which can tackle both of these could employ a semantic representation solution, such as the Semantic Definition Format (SDF) 65 (tackling interoperability) and an eBPF based policy engine which can perform the policy evaluation (tackling the black-box nature). Such a solution will enable a reduction in the large number of specialised IoT solutions and also in simplifying the process of switching between Declarative languages and Imperative languages – translating the policies and intents defined at the upper layers (business layers) to the lower layers, closer to the processes and devices (constrained IoT). 4.2.2 Encrypted/proprietary IoT traffic processing and monitoring on the edge Another area that eBPF/XDP can enhance security operations is IoT traffic processing and monitoring. In 66 , Björk et al. used eBPF / XDP for a Proof-of-Concept (PoC) implementation. In the PoC, the eBPF implementation was used in Data fabric context, and it aggregated Constrained Application Protocol (CoAP) traffic with Concise Binary Object Representation (CBOR) serialisation. When the operation field in the incoming packet was set to one, the 63 Nguyen, P., Ferry, N., Erdogan, G., Song, H., Lavirotte, S., Tigli, J.Y. and Solberg, A., 2019, July. Advances in deployment and orchestration approaches for IoT-a systematic review. In 2019 IEEE international congress on Internet of Things (ICIOT) (pp. 53-60). IEEE. 64 Kasem-Madani, S. and Meier, M., 2015. Security and privacy policy languages: A survey, categorization and gap identification. arXiv preprint arXiv:1512.00201. 65 Koster, M., Bormann, C. and Keränen, A., 2022. Semantic Definition Format (SDF) for Data and Interactions of Things. Internet Engineering Task Force, Internet-Draft draft-ietf-asdf-sdf-11. https://www.ietf.org/archive/id/draft-ietf-asdf-sdf01.html 66 Joonas Björk, "IoT Data Integration with In-Network Computing", Bachelor's thesis, 26.4.2024, Aalto University.
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 51 - August 31, 2025 packet was processed in the eBPF, and its value field was aggregated to an eBPF map. After aggregation, the packet was dropped. Every 10th incoming packet processed in the eBPF was not dropped, but instead, it was modified and passed to the user space. The modification that was done for the packet was changing the operation field to three, and the value field to contain the average of all ten previously processed values. This simulates a situation where some of the packets which do not require complex processing are handled in eBPF, thus saving userspace application processing time. Further, the work proposed to use eBPF programs for full parsing of CBOR payloads in the eBPF, but this was not prototyped. Monitoring encrypted communication is not a trivial task in scenarios where the decryption key is not available, such as scenarios where the owner of the communication network is different from the owner of the data transmitted (e.g., in smart metering scenarios). In these cases, detecting user or device misbehaviour and adversarial attacks relies on monitoring solutions (e.g., Intrusion Detection Systems functionality) which take into consideration patterns extracted from encrypted traffic features. In IoT scenarios where devices are sending and receiving data and commands with predefined patterns, lightweight monitoring models and solutions can be deployed on the IoT gateways, enabling collecting information on encrypted proprietary and open-source IoT protocols. Tudor et al. 67 show how characteristics extracted from encrypted IoT traffic (e.g., payload bytes in and out, number of packets, session duration, interpacket timings) can be employed to detect the type of commands exchanged with IoT devices via two different IoT protocols. Implementing a similar lightweight component in eBPF on IoT gateways can enable timely and accurate data exposure towards a Behavioural Based Intrusion Detection/Prevention system, enabling monitoring of encrypted or unencrypted, proprietary or open-source IoT protocols used to exchange commands between the control centre and the IoT devices. 4.2.3 eBPF based observability, detection and monitoring on the edge Another field where the usage of eBPF could prove useful within an IoT network is in the observability, detection and monitoring tasks. Accurate examination of the behaviour and sideeffects of the offloaded functional workloads to the network’s far-edge can in fact ensure that the system operates as expected and help the early detection of anomalies and attacks. This has traditionally been a major selling point of eBPF’s feature set, thanks to its powerful kernel programmability and low-overhead aspects; moreover, the reduced footprint associated with deploying eBPF-based observability tools ensures transparent compatibility with most IoT devices that run Linux. Thanks to the relative maturity of the eBPF observability toolset, several complete solutions have already been made available from the likes of Sysdig and Isovalent. Falco 68 , for example, can instrument the kernel with system call and event capture functionality in order to perform dynamic attack detection; crucially, output logs and traces can be exported externally (such as through a built-in Prometheus 69 exporter), enabling the consumption of this data to not overload the resource-constrained IoT nodes. Tetragon 70 extends this functionality by implementing a configurable mitigation algorithm on top of the eBPF-based detection, which can automatically block incoming attacks. 67 Tudor, V., Almgren, M. and Papatriantafilou, M., 2015, April. Harnessing the unknown in advanced metering infrastructure traffic. In Proceedings of the 30th Annual ACM Symposium on Applied Computing (pp. 2204-2211). 68 falcosecurity, “GitHub - falcosecurity/falco: Cloud Native Runtime Security,” GitHub, Jan. 28, 2025. https://github.com/falcosecurity/falco [accessed Jun. 26, 2025]. 69 “GitHub - prometheus/prometheus: The Prometheus monitoring system and time series database.,” GitHub. https://github.com/prometheus/prometheus [accessed Jun. 26, 2025]. 70 cilium, “GitHub - cilium/tetragon: eBPF-based Security Observability and Runtime Enforcement,” GitHub, Dec. 13, 2024. https://github.com/cilium/tetragon [accessed Jun. 26, 2025]
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 52 - August 31, 2025 Last, eBPF’s ability to provide fine-grained, real-time telemetry from within the Linux kernel of an IoT device could serve as a rich data source for AI models, enabling accurate detection of subtle anomalies and complex attack patterns. The low-overhead nature of eBPF ensures that data collection does not strain the limited resources of IoT devices, while AI algorithms can process this data using low level High-Performance Computing tools in order to identify threats with greater adaptability than traditional rule-based systems. Wang et al. 71 presented a highperformance IDS architecture that leverages eBPF for in-kernel packet filtering and system monitoring, achieving significantly improved throughput and reduced overhead compared to traditional IDS solutions. Ben-Yair et al. 72 introduced a hybrid approach combining eBPFbased kernel telemetry with machine learning models to detect performance anomalies in real time with minimal system overhead. 4.2.4 eBPF and AI-IDS security mechanism on edge nodes As presented in the previous sections, the eBPF framework is a kernel-level framework, which can be used for monitoring and tracing low-level edge node system activities. Through the execution of secure and sandboxed programs within the edge node Linux kernel, eBPF provides a lightweight mechanism for in-kernel observability, which is particularly advantageous for the performance analysis and the security monitoring of workloads when deployed on resourceconstrained edge platforms. In addition to its observability functions, eBPF enables the realtime monitoring of edge node system events, thereby providing a foundational capability for high-performance intrusion detection while maintaining minimal operational overhead. In order to extend these capabilities, the integration of eBPF with an Artificial Intelligencedriven Intrusion Detection System (AI-IDS) has been investigated within the ELASTIC. This combination has been identified as particularly beneficial for central server ELASTIC nodes, i.e., WP1, and it is extended to IoT and edge computing ELASTIC environments, where the processing and the analysis security-relevant data at the source level is critical for ensuring lowlatency, scalable, and resource-efficient security monitoring. By substantially reducing the transmission of raw telemetry to user-space or remote processing infrastructures, the eBPF-AIIDS integration supports the timely detection and classification of security threats across large volumes of edge node events. In the context of the server-based ELASTIC environment, the functional characteristics of the eBPF-based capture tool were presented in D1.1. This tool constitutes an innovative intrusion detection component, developed around a TCP message capture framework optimised to enhance data acquisition performance while minimising system overhead during active capture operations. On the cluster-based version, the data interception is conducted prior to the encryption – that might be imposed by any Service Mesh or other infrastructure management services – and prior to packetisation, thereby reducing computational complexity and improving processing efficiency. At the core of this mechanism is an eBPF program attached to the tcp_sendmsg kernel function, the TCP-specific implementation of the generic socket sendmsg operation. Upon interception of application-generated TCP messages, the eBPF program transmits them to the backend AI-IDS component for analysis, thus sparing the server nodes from potentially computationally intensive operations. 71 Wang, Shie-Yuan, and Jen-Chieh Chang. "Design and implementation of an intrusion detection system by using extended BPF in the Linux kernel." Journal of Network and Computer Applications 198 (2022): 103283. 72 Ido Ben-Yair, Pavel Rogovoy, and Nezer Zaidenberg. 2019. AI & eBPF based performance anomaly detection system. In Proceedings of the 12th ACM International Conference on Systems and Storage (SYSTOR '19). Association for Computing Machinery, New York, NY, USA, 180. https://doi.org/10.1145/3319647.3325842
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 53 - August 31, 2025 Complementing the eBPF capture tool, the server-based AI-IDS framework—also detailed in D1.1 is an innovative hardware-accelerated intrusion detection solution, combining two principal capabilities: (i) the performance and scalability benefits of a hardware-implemented IDS, and (ii) the adaptive threat detection capabilities enabled by artificial intelligence. The hardware IDS is based on Snort 73 , one of the most widely utilised network security systems, and incorporates a highly parallelised, hardware-optimised pattern-matching architecture 74 , 75 , whereby independent modules concurrently process separate eBPF-derived data streams. In parallel, the AI-based subsystem utilises a machine learning-based, semi-supervised online learning approach to dynamically generate, refine, and update the signature and patternmatching structures employed for intrusion detection. The optimised detection models are deployed to the FPGA-based processing engine, enabling real-time, adaptive intrusion detection and mitigation in dynamic environments, while leveraging the event streams forwarded by the eBPF capture tool. Building upon the individual characteristics of the two tools presented in the server-based ELASTIC solution, the project has progressed towards the integration of the eBPF framework with the AI-IDS into a unified security toolchain for deployment on low-resource IoT edge nodes. The integrated tool enables localised, efficient and adaptive network security monitoring. Within this system, the eBPF framework is utilised to capture and pre-process network stack activity - such as outbound TCP messages - inside the Linux kernel of each edge node. These events are subsequently forwarded to the AI-IDS module, which facilitates proactive threat detection, adaptive learning from emerging attack vectors, and rapid incident response, all while preserving the performance, energy efficiency, and operational integrity of resource-constrained devices. This IoT edge-node integrated approach incorporates AI-driven mechanisms to enable the continuous and dynamic updating of the cybersecurity system, ensuring that the detection logic evolves in line with new and sophisticated threat landscapes. As presented in Figure 14, the first implementation of this combined toolset has been deployed on a Pynq-Z1 platform—a low-cost, resource-constrained edge device—demonstrating the feasibility of embedding hardware-accelerated AI-IDS capabilities alongside eBPF kernel-level event capture in a constrained environment. Through this integration, the ELASTIC framework is extended with a unified, hardwareaccelerated, and AI-enhanced security architecture capable of providing resource efficient, lowlatency, and adaptive intrusion detection at the edge. This direction strengthens the resilience and performance of distributed IoT and edge computing infrastructures. The first version of the two tools integration, i.e., eBPF and AI-IDS, mapped on a low resources IoT device, i.e., Pynq Z1, has been implemented, Figure 14. The final integration of the eBPF tool with the hardwareaccelerated AI-driven IDS on ELASTIC IoT edge devices, as well as the results of the evaluation and validation activities, will be documented and presented in the forthcoming ELASTIC WP4 deliverables, which will focus on the edge device security tools. 73 Roesch, Martin. "Snort: Lightweight intrusion detection for networks." Lisa. Vol. 99. No. 1. 1999. 74 Deyannis D., et al. "The diversification and enhancement of an ids scheme for the cybersecurity needs of modern supply chains." Electronics 11.13 (2022): 1944. 75 Papadogiannaki E., et al. "A reconfigurable IDS framework for encrypted and non-encrypted network data in supply chains." 2023 International Conference on Engineering and Emerging Technologies (ICEET). IEEE, 2023.
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 54 - August 31, 2025 Figure 14. Architecture of the first version of the integrated ELASTIC security tool, combining the eBPF framework with the AI-IDS module on low resources edge device. 4.3 Conclusion The integration of eBPF into IoT and edge environments demonstrates its strong potential as a lightweight yet powerful framework for enhancing network security. Across policy enforcement, encrypted traffic monitoring, observability, and AI-assisted intrusion detection, eBPF provides a common foundation for achieving real-time protection with minimal performance overhead. By enabling in-kernel programmability, it ensures that security operations remain isolated from user space and resilient against tampering, while also supporting interoperability between imperative and declarative policy frameworks. Within ELASTIC, the combination of eBPF with AI-driven IDS mechanisms represents a significant step toward adaptive and resource-efficient intrusion detection on constrained devices. The first integrated prototypes confirm the feasibility of deploying hardware-accelerated AI-IDS alongside eBPF-based monitoring even on low-cost IoT boards. This toolchain extends the ELASTIC framework with scalable and adaptive security capabilities, ensuring resilience against evolving threats in distributed IoT and edge computing infrastructures.
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 55 - August 31, 2025 5 Trusted Execution Environments (TEEs) for IoT Having explored Wasm as a portable execution layer and eBPF/XDP as an in-kernel observability and security mechanism, this section now turns to TEEs as a complementary approach to workload protection on IoT edge nodes. While Wasm and eBPF primarily provide software-level isolation and programmability, TEEs introduce hardware-backed guarantees for code and data integrity. There are two main benefits of using TEEs on constrained devices in the ELASTIC project: • Complementary security: TEEs can host Wasm runtimes or safeguard sensitive parts of AI and FL pipelines, ensuring that execution remains trustworthy even on physically exposed IoT devices. • Consistency across technologies: Just as eBPF enhances network control and Wasm standardises execution portability and sandboxing, TEEs provide a hardware-based trusted foundation for attestation and confidential computation. IoT devices are typically resource-constrained, physically accessible, and often deployed remotely in environments where they can be exposed to potential attackers. These conditions make them prime targets for attacks. TEEs provide a secure enclave within the processor, enabling protection of critical operations and data even if the main operating system is compromised. In IoT, TEEs serve the following key purposes: • Isolation of sensitive logic, including AI/ML models, authentication routines, and attestation workflows - similar to non-IoT devices. • Resistance to physical tampering by isolating sensitive code, thereby reducing the software components and data an attacker can exploit even if they gain physical access to the device. • Protection of device secrets such as cryptographic keys and identity credentials. A common use case for TEEs on IoT devices is to store certificates and private keys or credentials in TEEs and use them to establish a safe connection to the cloud. Also, those keys can be used to sign output data and provide data integrity, which can be used both for sensor measurements on far edge (especially in the case of constrained protocols that do not provide TLS or TLS is too battery-intensive) and more complex data such as results of the execution of an AI algorithm for more resourceful devices. Other use cases include secure OTA, payments, authentication and authorisation, and digital rights management (DRM). A more details about the usage of TEEs and attestation in the ELASTIC project can be found in the Deliverable 3.1 76 . 5.1 TEE Standards for IoT Security Attestation represents a mechanism through which information about the TEE can be delivered to a client or another TEE, allowing the client to verify that information and trust the TEE. Afterward, the client can potentially transfer or receive sensitive data or code to or from the TEE. Remote attestation is the attestation process where the TEE is run on a remote server, and the client needs to verify that the TEE is secure and configured correctly. 76 ELASTIC Project, Lightweight Confidential Computing Platform - Initial version (Deliverable D3.1), to appear, 2025.
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 56 - August 31, 2025 The IETF RATS working group has defined a flexible architecture 77 that defines the roles of participants in remote attestation and the messages exchanged between them. Figure 15. Roles and messages in RATS architecture. The roles defined in Figure 15 are: • Attester - an entity that wants to prove its authenticity and integrity. This entity generates evidence, as shown in the figure. The evidence is the attestation report. • Verifier - an entity that uses evidence and additional information to verify the attestation report (evidence) it got from the attester. It then sends the attestation results to the relying party. • Relying party - the entity/client that wants to send sensitive data or code to the attester but needs assurance that the attester is secure. • Endorser - an entity, typically the manufacturer, whose information (endorsements) can help verify the evidence. The endorsements are usually information about the integrity of the evidence. • Reference value provider - an entity, typically the manufacturer, that provides reference values to the Verifier. • Verifier Owner - an entity that produces appraisal policies for evidence that the Verifier uses. • Relying Party Owner - an entity that produces appraisal policy for attestation results that the relying party uses. The information that is being passed from one entity to another in Figure 12 is: • Evidence - set of claims about the attesting environment. It contains information about the software and hardware used by the TEE. In the case of Intel and AMD, the evidence is a hardware-signed report with the mentioned information. • Endorsements - represent a secure statement or a set of claims, in an open format, that some entity (e.g., a manufacturer) vouches for the integrity of the device’s various capabilities. 77 “Remote ATtestation procedureS (RATS) Architecture,” ietf.org. https://datatracker.ietf.org/doc/rfc9334/ [accessed Jul. 18, 2025].
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 57 - August 31, 2025 • Reference values - are a set of values that represent the current “nominal values” of claims inside the evidence. • Attestation results - carry information about the result of verifying the evidence. The attestation result can be a set of boolean values about the set of claims of the evidence. The Verifier signs the attestation result for the Relying party to trust the attestation result. • Appraisal policies - specify what claims in evidence or the attestation results are valid based on reference values and endorsements. To establish a secure channel with the TEE, in other words, with the Attester, the Evidence or the Attestation Results must be cryptographically connected to the secure channel. That way, the Relying Party will know that the other end of the secure channel is connected to the Attester. One of the most common ways to establish a secure channel is to use TLS cryptographic protocol. The TLS that has the Evidence or Attestation Results bound to it is called Attested TLS (aTLS). There are two IETF drafts that are being worked on regarding aTLS. The first draft is titled “Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 78 .” This work utilises TLS extensions to transport Evidence or Attestation Results to the receiving Client or Server. A part of this draft can be implemented using OpenSSL support for custom TLS extensions. Full code will not be shown, but only a snippet that defines the extensions. int add_custom_tls_extension(SSL_CTX *ctx, tls_connection *conn) { uint32_t flags_nonce = SSL_EXT_CLIENT_HELLO | SSL_EXT_TLS1_3_ENCRYPTED_EXTENSIONS; uint32_t flags_attestation = SSL_EXT_CLIENT_HELLO | SSL_EXT_TLS1_3_CERTIFICATE; int ret = 1; void *data = NULL; if (conn != NULL) { data = (void*)&conn->tls_ext_data; } ret = SSL_CTX_add_custom_ext(ctx, EVIDENCE_REQUEST_HELLO_EXTENSION_TYPE, flags_nonce, evidence_request_ext_add_cb, evidence_request_ext_free_cb, data, evidence_request_ext_parse_cb, data); if (ret != 1) { return 0; } ret = SSL_CTX_add_custom_ext(ctx, ATTESTATION_CERTIFICATE_EXTENSION_TYPE, flags_attestation, attestation_certificate_ext_add_cb, attestation_certificate_ext_free_cb, 78 “Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS),” https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/ [accessed Jul. 18, 2025].
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 64 - August 31, 2025 5.3.4 ARM CCA ARM CCA represents the next evolution in secure computing for Armv9-A based processors. It introduces Realms - isolated execution environments that are protected from both the host OS and hypervisor. CCA was designed with cloud-edge convergence in mind, supporting finegrained isolation and hardware-backed attestation for secure multi-tenant and privacy-critical workloads. Benefits of ARM CCA: • Strong isolation: realms are isolated from the OS, hypervisor, and other applications. • Multi-tenant capable: supports concurrent secure workloads on shared hardware. • Modern threat model: protects against a broader class of attacks including rogue OS/hypervisor. • Attestation and memory encryption: enables confidential workloads in hybrid edge/cloud environments. Drawbacks of ARM CCA: • Hardware requirements: requires Armv9-A CPUs, which are not found in deeply embedded MCUs. • High system complexity: designed for richer operating systems, not bare-metal or realtime use. • Not suited for ultra-constrained devices: power and memory budgets may be prohibitive. • Still emerging: early in adoption with limited field-tested deployments in edge IoT. 5.3.5 Android The software on many IoT devices is tightly controlled by their manufacturer, along with hardware features such as secure boot. As a result, these devices can provide some TEE-like functionality, even with little-to-no involvement from a hardware-backed TEE that will not normally execute user-supplied code. Restricting the TEE to manufacturer-supplied software is necessary in split-world TEEs like TrustZone, which does not provide any kind of intra-TEE isolation. Android devices normally use a combination of secure boot and various access control mechanisms to prevent application software from modifying the operating system itself or from making unauthorised interactions with other applications, thereby providing similar isolation guarantees to many TEEs, albeit enforced by software rather than hardware. This "software TEE" functionality complements the true hardware-backed TEEs that are used by Android devices for a variety of functionality, and most relevant here, the hardware-backed keystore 90 . The keystore uses the TEE to protect key material itself, but also to provide key attestation, which uses the TEE's remote attestation functionality to provide evidence for the claim that a particular key is protected by the hardware-backed keystore, and subject to certain access restrictions. These claims can include the requirement for biometric or other authentication immediately before the key is used (functionality that is itself implemented 90 "Hardware-backed Keystore", https://source.android.com/docs/security/features/keystore, [accessed Jul. 22, 2025].
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 65 - August 31, 2025 within the TEE), but also the platform's belief regarding which applications have access to the key 91 , as expressed by Android application IDs, versions, and code-signing certificates. This combination of identifiers is sufficient to uniquely identify the application in question, as the inclusion of the signing certificate assures the verifier that the application ID and version correspond to those assigned by the developer, assuming that the developer does not sign multiple binaries with the same application ID and version. This functionality can then be used to provide attestation functionality to normal Android applications, which can: 1. Create a keypair in the hardware-backed keystore, 2. Request an attestation certificate over the keypair's public key, 3. Use the combination of keypair and attestation certificate to demonstrate that a statement was signed by some application. Though less robust than attestation mechanisms that eliminate the OS from its TCB, this approach allows for attestation of user applications despite the limitations of a split-world TEE, which can be valuable for applications such as authorisation (e.g. in a bank's ID application to demonstrate that a user was shown a transaction and gave their consent) or data provenance (e.g., in a camera app that demonstrates that a photograph was taken directly from the camera without modification). 5.4 Hardware-Backed TEE for IoT Security on ESP32-C6 TEEs are central to ELASTIC’s vision of secure and reliable IoT edge computing, as they enable sensitive workloads (e.g., AI inference, secure communication protocols) to be isolated from untrusted application code. As introduced in Section 3.5, the ESP32-C6 was selected as a representative hardware platform for evaluating lightweight secure execution in resourceconstrained devices. Its built-in hardware-backed TEE (ESP-TEE) makes it possible to enforce a split between a secure execution world and a normal application world, thereby aligning with ELASTIC’s architectural need for trusted components on heterogeneous edge nodes. The ESP32-C6 incorporates a layered root of trust (RoT) and privilege separation based on RISC-V hardware features. At reset, the immutable RoT, consisting of the on-chip BootROM, isolation/peripheral hardware, crypto accelerators, and eFuse-stored keys, is implicitly trusted 92 . Above this hardware RoT sits an updatable RoT comprising the second-stage bootloader and the TEE firmware. The TEE firmware (running entirely in the highest-privilege RISC‑V machine-mode) is responsible for secure configuration of the system, interrupt and exception management, and providing protected services (e.g. cryptographic operations, secure storage, attestation) to the Rich Execution Environment (REE) 93 . 91 “AttestationApplicationId Schema – Attestation,” https://source.android.com/docs/security/features/keystore/attestation#attestationapplicationid-schema [accessed Jul. 18, 2025]. 92 “ESP-TEE: Architecture – Simplified Overview,” https://docs.espressif.com/projects/espidf/en/latest/esp32c6/security/tee/tee.html#architecture-simplified-overview [accessed Jul. 18, 2025]. 93 “ESP-TEE: Advanced Topics – Detailed Architecture,” https://docs.espressif.com/projects/espidf/en/latest/esp32c6/security/tee/tee-advanced.html [accessed Jul. 18, 2025].
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 66 - August 31, 2025 Figure 17. ESP32‑C6 TEE architecture illustrates the high-level split: the REE (user-mode) application and OS issue service calls to the secure machine-mode firmware, which in turn encloses trusted hardware modules (PMP/PMA, APM, MMU, eFuse, crypto engines) inaccessible from the REE. The ESP32-C6 leverages RISC‑V privilege levels and dedicated hardware to isolate its two worlds. The CPU operates in either Machine (M) mode or User (U) mode: the TEE runs in Mmode (highest privilege) and the REE in U-mode (lower privilege) 94 . Any attempt by U-mode code to access an M-mode resource or perform privileged instructions triggers a trap. In addition, the ESP32-C6 provides PMP and Physical Memory Attributes (PMA) units. The TEE configures PMP regions to enforce read/write/execute permissions on SRAM and flash for each world, preventing REE code from reading or writing TEE memory 95 . For example, a reserved region at the top of the high-performance (HP) SRAM is allocated to the TEE for its code, stacks, and heap, with PMP policies (set in M-mode) preventing any U-mode access. Likewise, external flash is partitioned so that TEE code (and secure storage regions) reside in protected partitions: the Access Permission Management (APM) peripheral further locks down accesses to the SPI flash controller and MMU registers for TEE partitions while PMP secures the flash cache 96 . In effect, the combination of RISC‑V privilege levels, PMP/PMA settings, and the APM firewall implements a hardware-enforced “secure world” vs “normal world” separation on the ESP32-C6. Only the TEE (M-mode firmware) may configure these boundaries at boot, and thereafter any unauthorised REE access to reserved SRAM, flash or protected peripherals will generate an exception 97 94 “ESP-TEE: Architecture – Simplified Overview,” https://docs.espressif.com/projects/espidf/en/latest/esp32c6/security/tee/tee.html#architecture-simplified-overview [accessed Jul. 18, 2025]. 95 “ESP-TEE: Detailed Architecture,” https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/security/tee/teeadvanced.html#detailed-architecture [accessed Jul. 18, 2025]. 96 “ESP-TEE: External Memory (Flash),” https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/security/tee/teeadvanced.html#external-memory-flash [accessed Jul. 18, 2025]. 97 “ESP-TEE: Peripherals,” https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/security/tee/teeadvanced.html#peripherals [accessed Jul. 18, 2025].
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 67 - August 31, 2025 5.4.1 Boot Sequence and Lifecycle The ESP32-C6 boot-up flow is modified to establish the chain-of-trust for the TEE. First, the on-chip BootROM (immutable and trusted) launches the second-stage bootloader (in secure mode). The bootloader loads both the signed TEE image and the signed REE (application) image from flash 98 . It then hands control to the TEE firmware in Machine mode. The TEE firmware performs system initialisation: it sets up the secure interrupt vector table, configures PMP/PMA regions for internal and external memory, programs the APM registers to enforce peripheral access policies, and registers its heap and interrupt handlers 99 . Once hardware resources are locked down, the TEE switches the CPU to U-mode and jumps to the REE entry point, where the normal application begins execution. Secure interrupts (dedicated via a separate pin) remain routed to the TEE, but otherwise the REE executes in isolation from the TEE services 100 . This sequence is illustrated in Figure 18, which shows the ESP32-C6 TEE boot and lifecycle flow. Throughout this lifecycle, Secure Boot v2 is active: the second-stage loader verifies the signatures of the bootloader, TEE and REE images before execution97. The same signing key (and scheme) is used for both images, tying them into a unified trust chain. Thus at boot and during any OTA update the hardware RoT and BootROM ensure only authenticated TEE firmware can run. In addition, post-boot integrity can be verified using Espressif’s remote attestation service. In practice, attestation works by having the device generate an EAT that summarises its security state. The process follows a standard flow: the Relying Party sends a nonce-based Attestation Request (AR) to the device REE, which forwards it to the TEE. The TEE collects relevant claim information (e.g., firmware image hashes, device identity, boot status), signs it with the device-unique attestation key, and returns the signed evidence back through the REE. The attestation service (verifier) checks the signature against the device’s certificate chain and compares the claims with reference values; the Relying Party then decides on the device’s trustworthiness based on this verification. This attestation flow extends the guarantees of Secure Boot into the operational phase by allowing the system to detect tampering or rollback even after boot. Note that the flash encryption key (stored in eFuses) is never exposed to software, so even if REE code tries to read the raw flash contents of TEE partitions, it sees only ciphertext. (Enabling SPI1 flash protection forces all REE flash accesses through the TEE code, for an even stronger isolation guarantee at some performance cost 101 . 98 “ESP-TEE: Scope of Protection,” https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/security/tee/tee.html#scopeof-protection [accessed Jul. 18, 2025]. 99 “ESP-TEE: System Initialization,” https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/security/tee/teeadvanced.html#system-initialization [accessed Jul. 18, 2025]. 100 “ESP-TEE: Interrupts,” https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/security/tee/teeadvanced.html#interrupts [accessed Jul. 18, 2025]. 101 “ESP-TEE: External Memory (Flash),” https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/security/tee/teeadvanced.html#external-memory-flash [accessed Jul. 18, 2025].
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 68 - August 31, 2025 Figure 18. ESP32‑C6 TEE boot/lifecycle flow After reset the second-stage bootloader loads and verifies both TEE and REE firmware images (chain-of-trust via Secure Boot). The CPU then enters the TEE (M-mode) where the trusted firmware configures memory, interrupts and security boundaries before jumping back to Umode to run the untrusted application 102 . At runtime, secure interrupts (e.g. crypto or SWDT) are serviced in M-mode, while REE interrupts use the U-mode vector table. 5.4.2 Trust Anchors and Attestation The foundation of trust in the ESP32-C6 TEE is the hardware RoT and on-device key material. Critical keys (e.g., Secure Boot public key hash, flash encryption key, chip ID) are fused into on-chip eFuses, anchoring the device’s identity and integrity. The TEE attestation service extends this by providing cryptographically-signed device “evidence” to external parties 103 . In an attestation protocol, a remote verifier sends a challenge (nonce) to the device; the REE forwards it into the TEE which gathers claimed values (chip ID, firmware hashes, version, development/production mode, etc.) and constructs an EAT in JSON form 104 . Crucially, the TEE signs this token with an ECDSA key stored in secure storage (again provisioned within a TEE-protected flash partition) so that the private key never leaves the secure world 105 . The public key hash corresponding to this slot is included in the token. The remote service verifies the signature and compares reported measurements to reference values before trusting the device. In this way, the TEE itself becomes a trust anchor: its root keys and identity are guaranteed by hardware, and it vouches for the device’s state using internally-managed cryptographic keys. This mechanism underpins secure channel establishment as well - for example, the REE could request the TEE to perform a TLS key generation or handshake using protected keys, then expose only encrypted data to the outside, knowing that the key material never touches untrusted memory. 102 “ESP-TEE: Boot-up Flow,” https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/security/tee/teeadvanced.html#boot-up-flow [accessed Jul. 18, 2025]. 103 “ESP-TEE: Attestation Overviewhttps://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/security/tee/teeattestation.html#overview [accessed Jul. 18, 2025]. 104 “ESP-TEE: Sample EAT in JSON Format,” https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/security/tee/teeattestation.html#sample-eat-in-json-format [accessed Jul. 18, 2025]. 105 “ESP-TEE: Entity Attestation Token,” https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/security/tee/teeattestation.html#entity-attestation-token [accessed Jul. 18, 2025].
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 69 - August 31, 2025 5.4.3 Cryptographic Services and Key Management Within the secure world, all cryptographic primitives and sensitive key operations are handled by dedicated hardware and isolated software. The ESP32-C6 includes crypto accelerators for AES, SHA, ECC (for ECDSA/ECDH), HMAC, and a digital signature module 106 . These peripherals are explicitly placed under the TEE’s exclusive control: any attempt by U-mode code to read/write their registers is blocked by the APM (causing a fault). The TEE firmware exposes these capabilities via secure service calls. For instance, an application in the REE may request the TEE to encrypt data with a key stored in secure storage; the TEE then invokes the AES engine with the key read from encrypted flash (the REE has no access even to encrypted key material). All TEE-resident keys and secrets (including attestation keys, asymmetric key pairs, certificates, etc.) are stored in an encrypted flash partition that is decrypted only inside the secure environment 107 . The TEE manages its own heap and stacks (in reserved SRAM), and it includes secure libraries for hashing, signing, and encryption that leverage the hardware units. Importantly, eFuse-stored keys (such as the flash encryption root key) remain inaccessible to both worlds once burned; any global root key is used only within hardware engines (AES key ladder) and never exposed in software 108 . 5.5 Conclusion TEEs extend the ELASTIC architecture with a hardware-based layer of trust, complementing the portability of Wasm and the programmability of eBPF. Whereas Wasm and eBPF primarily provide software-level isolation, portability, and observability, TEEs anchor execution in the underlying hardware, ensuring that even devices deployed in untrusted or physically exposed environments can operate with integrity and confidentiality. The evaluations carried out on multiple platforms, such as ARM TrustZone, RISC-V Keystone/CoVE, ARM CCA, and ESP32-C6, demonstrate that TEEs are becoming increasingly available even in constrained IoT-class devices. They provide the mechanisms required for secure workload isolation, cryptographic services, attestation, and confidential execution of AI/FL pipelines, enabling trustworthy participation of edge nodes in distributed and federated orchestration scenarios. Importantly, TEEs allow the same workloads that benefit from Wasm’s portability and eBPF’s flexibility to run inside an attested, tamper-resistant environment, thereby reinforcing end-toend trust across the system. By integrating TEEs alongside Wasm and eBPF, the ELASTIC framework adopts a multi-layered security and orchestration model: • Wasm ensures portable and efficient execution across heterogeneous devices. • eBPF enables programmable, fine-grained network control and observability. • TEEs establish a hardware-backed trusted foundation for attestation and confidential computation. This layered approach ensures that lightweight orchestration at the edge is not only efficient and portable, but also rooted in strong trust guarantees. 106 “ESP-TEE: Peripherals,” https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/security/tee/teeadvanced.html#peripherals [accessed Jul. 18, 2025]. 107 “ESP-TEE: User Guide,” https://docs.espressif.com/projects/esp-idf/en/latest/esp32c6/security/tee/tee.html [accessed Jul. 18, 2025]. 108 “ESP-TEE: Scope of Protection,” https://docs.espressif.com/projects/espidf/en/latest/esp32c6/security/tee/tee.html#scope-of-protection [accessed Jul. 18, 2025].
ELASTIC D4.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 70 - August 31, 2025 6 Conclusion and Next Steps This deliverable presented the outcomes of Task 4.1, which explored the enablement and integration of lightweight execution and security frameworks, including Wasm, eBPF, FL, and TEEs, on resource-constrained IoT edge nodes within the ELASTIC architecture. The evaluation of Wasm demonstrated its potential to provide platform-independent, sandboxed execution with low overhead, making it highly suitable for deploying dynamic and secure workloads at the edge. Key runtime environments such as WAMR were assessed for their memory efficiency and portability, while ELASTIC-led enhancements to WASI interfaces showcased how Wasm can securely interact with hardware-level resources in IoT systems. In parallel, the application of eBPF and XDP technologies was investigated as a powerful tool for real-time network observability, traffic filtering, and lightweight policy enforcement. Through experimentation with kernel-level packet processing and integration with Linux flowtables, the results validated the benefits of eBPF for achieving high-throughput, low-latency data paths in edge gateways while maintaining security policy compliance. Wasm-based FL infrastructure is analysed and described. Lastly, the analysis of TEE technologies such as ARM TrustZone, RISC-V Keystone, and ARM CCA highlighted their respective applicability across heterogeneous IoT devices. Remote attestation mechanisms and proposals for enhancing standardisation (e.g., OP-TEE, IETF TEEP) were examined in the context of securing Wasm runtimes and sensitive workloads. The outcomes of Task 4.1, such as lightweight Wasm runtime evaluation, secure module distribution methods, and attestation mechanisms, will directly feed into the implementation and validation activities in WP5, particularly within the two ELASTIC demonstrators. These include an IoT Data Fabric as a Native 6G Infrastructure Capability (Demonstrator 1) and Privacy-preserving confidential computing platform to migrate in-premise sensitive IT services to the cloud (Demonstrator 2), where the developed components will be tested in real-world scenarios. Looking forward, the results of Task 4.1 also establish the technical foundation for the broader objectives of WP4. In the next phase, the focus will expand to secure orchestration of federated ML workloads (Task 4.3), deployment of TinyML and hardware-accelerated edge models (Task 4.2), and advanced security mechanisms for embedded systems (Task 4.4). This ensures continuity between the exploratory work carried out in Task 4.1 and the upcoming tasks of WP4, while maintaining strong alignment with the project’s overall objectives.