ELASTIC D3.1: Lightweight Confidential Computing Platform - Initial version

Horizon Europe Framework Programme HORIZON JU Research and Innovation Action Reliable Services and Smart Security Efficient, portabLe And Secure orchesTration for reliable servICes D3.1: Lightweight Confidential Computing Platform - Initial version Abstract: This deliverable presents the initial specification and design of the ELASTIC lightweight confidential computing platform, which aims to provide a secure, efficient, and portable execution environment for privacy-sensitive workloads. The platform leverages Trusted Execution Environments (TEEs) and WebAssembly (Wasm) to enable secure and architecture-agnostic deployment across heterogeneous edge, cloud, and embedded environments. The document defines a Hardware Abstraction Layer (HAL) to enable interoperability across platforms, details support for secure system services such as cryptographic material distribution, and addresses mechanisms for remote attestation using standard and platform-specific approaches. The document also explores the integration of Wasm runtimes with TEEs, secure memory and I/O handling, cryptographic services, remote attestation procedures, and workload orchestration. This initial version lays the foundation for a privacy-preserving computing framework capable of supporting secure function-as-a-service (FaaS) deployments and cross-platform workload migration, aligned with the broader goals of the ELASTIC project. Contractual Date of Delivery 31/08/2025 Actual Date of Delivery 31/08/2025 Deliverable Security Class Public Editor Dusan Borovcanin(UVC) Contributors UVC, LUN, AAL, THD, ERF, THS Internal Reviewers Drasko Draskovic (AMA) Gregory Chrysos(TUC) ELASTIC D3.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 MICRO-ELECTRONICA 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 D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 3 - August 31, 2025 Document Revisions & Quality Assurance Internal Reviewers 1. Gregory Chrysos, TUC 2. Drasko Draskovic, AMA Revisions Version Date By Overview 1.0 31/08/2025 TUC, THS Comments and approval from the PC and the STPM 0.9 31/08/2025 TUC Quality check 0.8 29/08/2025 TUC, AMA Comments and approval from the IRs 0.7 28/08/2025 UVC, LUN, AAL, THD, ERF, THS 2nd draft 0.6 20/08/2025 TUC, AMA, THS Comments on the 1st draft 0.5 05/08/2025 UVC 1st draft 0.4 03/07/2025 UVC, LUN, AAL, THD, ERF, THS Input received 0.3 27/05/2025 UVC Updated TOC 0.2 03/04/2025 THS, TUC, THD Comments on the TOC 0.1 26/03/2025 UVC TOC Disclaimer The work described in this document has been conducted within the ELASTIC project. This project has received funding from the Smart Networks and Services Joint Undertaking (SNS JU) under 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 D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 4 - August 31, 2025 Table of Contents LIST OF TABLES 7 LIST OF FIGURES 8 LIST OF ABBREVIATIONS 9 EXECUTIVE SUMMARY 12 1 INTRODUCTION 13 1.1 PURPOSE AND SCOPE OF THE DOCUMENT 13 1.2 RELATION TO WORK PACKAGES, DELIVERABLES AND ACTIVITIES 13 1.3 CONTRIBUTION TO WP3 AND PROJECT OBJECTIVES 13 1.4 STRUCTURE OF THE DOCUMENT 14 2 BACKGROUND AND MOTIVATION 15 2.1 ALIGNMENT WITH THE ELASTIC ARCHITECTURE 15 2.2 OVERVIEW OF WEBASSEMBLY (WASM) AND ITS ECOSYSTEM 17 2.2.1 WebAssembly 17 2.2.2 Wasm format 17 2.2.3 Wasm sandboxing 17 2.2.4 WebAssembly System Interface 18 2.2.5 WebAssembly runtime 19 2.2.6 Development and deployment of standalone WebAssembly applications 19 3 WASM LANDSCAPE 21 3.1 WASM RUNTIMES, PERFORMANCE AND LIMITATIONS 21 3.1.1 WebAssembly Micro Runtime 21 3.1.2 Wasmtime 22 3.2 EARLY IMPLEMENTATIONS OF WEBASSEMBLY IN TEES 22 3.2.1 Se-Lambda 23 3.2.2 Teaclave 23 3.2.3 AccTEE 23 4 WASM AND TRUSTED EXECUTION ENVIRONMENTS 25 4.1 INTRODUCTION TO TRUSTED EXECUTION ENVIRONMENTS (TEES) 25 4.2 OVERVIEW OF TRUSTED EXECUTION ENVIRONMENTS (INTEL SGX, AMD SEV, TDX, ARM CCA, RISC-V KEYSTONE) 25 4.2.1 Intel SGX 26 4.2.2 AMD SEV and AMD SEV-SNP 26 4.2.3 Intel TDX 27 4.2.4 ARM CCA 28 4.2.5 RISC-V Keystone 28 4.3 WASM RUNTIME INSIDE TEE 29 4.3.1 TWINE 29 4.3.2 WaTZ 31 4.3.3 Enarx 32 4.3.4 Veracruz 33 4.4 CONCLUSION ON WASM TRUSTED RUNTIMES 34 4.5 ISOLATION AND EXECUTION MODEL OF TEE-PROTECTED WASM APPLICATIONS 34 4.6 INTERFACING WITH HARDWARE I/O DEVICES 35 4.6.1 WASI: Design Principles and Operational Model 35 4.6.1.1 System Call Mediation in Trusted Execution Environments 35 4.6.2 Limitations in WASI-TEE Integration 36 4.6.3 Future Directions for WASI and WebAssembly Runtimes 36 5 HARDWARE ABSTRACTION LAYER (HAL) 38 5.1 HAL ANALYSIS AND DESIGN GOALS 38 ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 5 - August 31, 2025 5.1.1 Smart manufacturing 39 5.1.1.1 Manufacturing analytics deployment scenario 40 5.1.1.2 Edge control manufacturing deployment scenario 41 5.1.1.3 Data protection and performance expectations 42 5.1.2 IT Services Cloud Migration 43 5.1.2.1 IT service cloud migration deployment scenario 44 5.1.2.2 Data protection and performance expectations 45 5.1.3 Proactive Maintenance 46 5.1.3.1 Proactive maintenance deployment scenario 46 5.1.3.2 Data protection and performance expectations 48 5.2 HAL REQUIREMENTS 48 5.2.1 Requirements Derivation Principle 49 5.2.2 Dependencies 49 5.2.3 HAL functions 50 5.2.3.1 Smart Manufacturing 50 5.2.3.2 IT Service Cloud Migration 51 5.2.3.3 Proactive maintenance 52 5.2.4 User characteristics 53 5.2.5 Limitations 53 5.2.6 Assumptions and Dependencies 54 5.2.7 Apportioning of requirements 54 5.2.8 External interfaces 54 5.3 HAL ARCHITECTURE 55 5.3.1 Implementation Considerations 57 5.4 HAL INTERFACES SPECIFICATION 57 5.4.1 Clock 58 5.4.2 Random 58 5.4.3 Object storage 58 5.4.4 Sockets 59 5.4.5 Cryptography 59 5.4.6 GPU 60 5.4.7 Resource allocation 61 5.4.8 Event handling 61 5.4.9 Protected internal communication 61 5.4.10 HAL functions 62 5.5 LINUX HAL COMPONENT 62 5.5.1 Virtual TPM 63 5.5.2 How is HAL constructed? 63 5.5.3 How does the Linux HAL component work? 64 5.6 ELASTIC TEE HAL CONCLUSIONS 64 6 REMOTE ATTESTATIONS 66 6.1 BACKGROUND 66 6.2 IETF REMOTE ATTESTATION PROCEDURES (RATS) 66 6.2.1 RATS Architecture and its Protocols 66 6.2.1.1 RATS Architecture 67 6.2.1.2 RATS Protocols 70 6.2.2 Remote Attestation functionality in hardware 72 6.2.2.1 AMD SEV-SNP (x86) 72 6.2.2.2 Intel TDX (x86) 73 6.2.2.3 RISC-V (Keystone) 74 6.2.2.4 OpenTitan 74 6.2.3 Remote attestation functionality in software 75 6.2.3.1 Enarx 75 6.2.3.2 WaTZ 78 6.2.3.3 Veracruz 79 6.2.3.4 Microsoft Azure 79 6.2.3.5 AWS 80 6.2.3.6 Google Cloud Platform 81 6.2.3.7 Linux configfs-tsm 83 6.2.3.8 VERAISON 83 6.2.3.9 Trustee 84 ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 6 - August 31, 2025 6.3 HAL FOR REMOTE ATTESTATION MECHANISMS 85 6.4 SECURITY AND ROBUSTNESS ENHANCEMENT OF THE ATTESTATION MECHANISM 87 6.5 EFFICIENT AND LIGHTWEIGHT PROTOCOLS 90 6.5.1 Exploration of lightweight protocols 90 6.5.2 Impact on System Performance 91 6.6 REMOTE ATTESTATION HARDWARE ABSTRACTION LAYER 91 6.6.1 Abstraction Layer for Attester 92 6.6.1.1 Attester-provided information with the Multi-platform Attestation Component 92 6.6.1.2 Wasm-specific considerations for attestation 92 6.6.2 Abstraction layer for verifier 92 6.6.2.1 Evidence verification with the Multi-platform Attestation Component 93 7 CONFIDENTIAL COMPUTING PLATFORM IMPLEMENTATION 94 7.1 SELECTION OF A BASE RUNTIME AND REQUIRED MODIFICATIONS 94 7.2 INTEGRATION OF WASM RUNTIME WITH TEES AND HAL 94 7.3 REMOTE ATTESTATION FOR SERVERLESS COMPUTING 95 7.4 EVIDENCE VERIFICATION WITH THE MULTI-PLATFORM ATTESTATION COMPONENT 95 8 SECURITY ADVANCEMENTS 97 8.1 ISOLATION GUARANTEES IN A SHARED INFRASTRUCTURE 97 8.2 MITIGATING SECURITY RISKS IN WASM-BASED APPLICATIONS USING TEES 98 8.3 SECURE KEY MANAGEMENT AND CRYPTOGRAPHIC PROTECTIONS 98 9 PORTABILITY AND WORKLOAD MIGRATION 100 9.1 SEAMLESS MIGRATION ACROSS HARDWARE PLATFORMS 100 9.2 REDUCING VENDOR LOCK-IN WITH CROSS-PLATFORM SUPPORT 100 10 USE CASES AND APPLICATIONS 102 10.1 SECURE FUNCTION-AS-A-SERVICE (FAAS) WORKLOADS IN TEE 102 10.2 CONFIDENTIAL COMPUTING FOR CLOUD AND EDGE ENVIRONMENTS 102 10.3 POTENTIAL INDUSTRY APPLICATIONS 103 10.3.1 Demonstrator 1 103 10.3.2 Demonstrator 2 104 11 CONCLUSIONS AND NEXT STEPS 105 11.1 SUMMARY OF CONTRIBUTIONS 105 11.2 FUTURE ENHANCEMENTS AND RESEARCH DIRECTIONS 105 ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 7 - August 31, 2025 List of Tables Table 1: Entities in the smart manufacturing deployments scenario ..................................................... 39 Table 2: Entities in the IT services cloud migration deployment scenario ............................................ 43 Table 3: Entities in the proactive maintenance deployment scenario .................................................... 46 Table 4: Required functions identified from the smart manufacturing deployment case ...................... 50 Table 5: IT Service Cloud Migration functions ..................................................................................... 51 Table 6: Proactive Maintenance functions ............................................................................................. 52 Table 7: HAL Capabilities function ....................................................................................................... 55 Table 8: The Clock Interface.................................................................................................................. 58 Table 9: The Random Interface.............................................................................................................. 58 Table 10: The Object Storage Interface ................................................................................................. 58 Table 11: The Sockets Interface ............................................................................................................. 59 Table 12: The Cryptography Interface ................................................................................................... 59 Table 13: GPU Interface ........................................................................................................................ 60 Table 14: The Resource Allocation Interface ........................................................................................ 61 Table 15: The Event Handling Interface ................................................................................................ 61 Table 16: The Protected Internal Communication Interface .................................................................. 62 Table 17: HAL Platform Capabilities Interface ..................................................................................... 62 ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 8 - August 31, 2025 List of Figures Figure 1. Detailed overview of the ELASTIC architecture ................................................................... 16 Figure 2. Compiling C to a Wasm binary executing with different Wasm R/Ts & Frameworks .......... 20 Figure 3. Components of AccTEE (Source) .......................................................................................... 24 Figure 4. Overview of TWINE's Workflow (Source) ............................................................................ 30 Figure 5. Architecture of WaTZ ............................................................................................................ 32 Figure 6. Analytics smart manufacturing deployment scenario............................................................. 40 Figure 7. Edge control smart manufacturing deployment scenario. ...................................................... 42 Figure 8. IT migration deployment scenario. ......................................................................................... 44 Figure 9. The proactive maintenance deployment scenario. .................................................................. 47 Figure 10. The TEE HAL architecture. .................................................................................................. 56 Figure 11. HAL Configuration ............................................................................................................... 64 Figure 12. Conceptual Data flow (IETF RFC 9334).............................................................................. 67 Figure 13. High-level architecture of an attester (IETF RFC 9334) ...................................................... 68 Figure 14. Simple attestation of CC ....................................................................................................... 69 Figure 15. Layered attestation in CC ..................................................................................................... 69 Figure 16. Global attestation as a composite device .............................................................................. 70 Figure 17. Distributed Attestation .......................................................................................................... 70 Figure 18. Enarx Sequence Diagram ..................................................................................................... 77 Figure 19. Enarx Architecture ................................................................................................................ 78 Figure 20. Veraison Architecture ........................................................................................................... 84 Figure 21. Trustee Attestation Service overview ................................................................................... 85 Figure 22. Attestation flow between Verifier and Attester in the Elastic architecture framework ........ 86 Figure 23. Attestation Component Mechanism. At runtime, each attestation attests to the code of all components jointly, despite just a single interaction between client and component, no ongoing interactions between components. ......................................................................................................... 89 Figure 24. Attestation Orchestration ...................................................................................................... 90 Figure 25. Multi-platform Attestation .................................................................................................... 93 ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 9 - August 31, 2025 List of Abbreviations AK Attestation Key AOT Ahead-Of-Time compiler ARK AMD Root Key AS Attestation Service ASK AMD SEV Key ASP AMD Secure Processor CC Confidential Computing CCA ARM Confidential Compute Architecture CoRIM Concise Reference Integrity Manifest CPU Central Processing Units CRL Certificate Revocation Lists CVM Confidential VM CWT CBOR Web Token (CWT) DCAP Data Centre Attestation Primitives DES Disk Encryption Sets DICE Device Identifier Composition Engine DWARF Debugging With Attributed Record Formats EA Exported Authenticators EAR Entity Attestation Result EAT Entity Attestation Token EC European Commission EPC Enclave Page Cache FaaS Function-as-a-Service GCP Google Cloud Platform GP API Global Platform API standard HAL Hardware Abstraction Layer HMAC Hashed Message Authentication Code ICDE International Conference on Data Engineering IDE Integrity and Data Encryption IMA Linux Integrity Measurement Architecture I/O Input/Output IoT Internet of Things ITA Intel Trust Authority ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 16 - August 31, 2025 Figure 1. Detailed overview of the ELASTIC architecture D3.1 addresses the functionality required for components in the “Trust & Control” block and provides the required confidential computing functionality in the “Isolation” block, supporting WP3’s overall objective of delivering a secure, privacy-preserving and portable execution environment. This deliverable specifically covers the preliminary versions of the components highlighted in the colour “berry” in the detailed ELASTIC architecture. These components are: ● WasmHAL-Trust component is a hardware abstraction layer (HAL) designed to provide the Wasm runtime with the necessary abstraction to operate as a portable, programmable platform across diverse cloud and processor environments. D3.1 discusses the HAL’s architecture, research challenges, and initial implementation. The HAL component architecture, research, challenges and implementation are discussed in detail throughout D3.1. This component is a part of ELASTIC Demonstrator 2. (IT/OT - Privacy-preserving CC platform to migrate on-premise sensitive IT services). ● The Remote Attestation component will allow remote parties to establish trust by obtaining cryptographic evidence typically from Hardware Roots of Trusts, such as Trusted Platform Modules (TPMs) or TEEs to establish trust in cloud and distributed environments. The industry state-of-the-art, the proposed ELASTIC architecture, and the implementation challenges including TPMs and TEEs are discussed extensively through the D3.1 document. Remote Attestation will be showcased as part of both Demonstrator 1 (distributed remote attestation requirements in the IoT data fabric 6G infrastructure capability) and Demonstrator 2. ● The Key Broker Service component will facilitate remote attestation, providing secure key delivery as the relying party for successful attestation. The “Relying Party” ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 17 - August 31, 2025 architecture is discussed in detail in D3.1 and proposed implementation will adhere to the RATS (Remote ATtestation ProcedureS). Demonstrator 2 will utilise a Key Broker Service to establish remote attestation for the decryption of Wasm workloads for private public cloud migration following the principles recommended for transport of sensitive workload. 2.2 Overview of WebAssembly (Wasm) and Its Ecosystem With JavaScript being outdated to accommodate the more sophisticated applications, such as video streaming in the Web, WebAssembly was introduced in 2017 to address this issue. This section provides a brief introduction to Wasm, its format, runtime, sandboxing features and the WASI. 2.2.1 WebAssembly Wasm is an open standard developed by the World Wide Web Consortium (W3C) Community Group 2 , with the aim of creating a "safe, portable, low-level code format designed for efficient execution and compact representation 3 ". Wasm was initially aimed at enhancing web application performance within web-browser environments, but its increased safety and extended programming language support have made it the primary choice for the operation of secure runtimes and frameworks within TEEs, regardless of the hardware platform utilised. As Wasm is portable across various existing hardware architectures, both desktop and mobile, making it essentially hardware agnostic. Examples of such frameworks are Enarx 4 and TWINE 5 . Wasm utilises sandboxing and in memory-safe execution to provide a secure operating environment. Additionally, it is essentially language independent, allowing it to run in standalone mode or embedded within browsers. 2.2.2 Wasm format Wasm is a bytecode format that can be used by a compiler as cross-platform target architecture and subsequently be interpreted or recompiled for execution on a wide variety of underlying platforms. Wasm has been widely adopted and is supported by many programming high-level languages. The compiled program is encapsulated into a Wasm module, which includes the Wasm bytecode, but also defines global variables, memory allocations, and imports and exports, analogously to other binary formats such as ELF 6 or DWARF 7 . However, this module is not directly executable but requires a runtime environment that will either interpret it or translate it to native code. 2.2.3 Wasm sandboxing Wasm was originally conceived as a means to safely execute untrusted compiled code within web-based environments. i.e., primarily web browsers. However, its appealing properties such 2 https://www.w3.org/community/webassembly/ 3 https://www.w3.org/TR/wasm-core-2 4 https://enarx.dev 5 Ménétrey, J., Pasin, M., Felber, P., & Schiavoni, V. (2021, April). Twine: An embedded trusted runtime for webassembly. In 2021 IEEE 37th International Conference on Data Engineering (ICDE) (pp. 205-216). IEEE. 6 http://refspecs.linux-foundation.org/elf/ 7 https://dwarfstd.org/ ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 18 - August 31, 2025 as portability, performance, and security have extended its utilisation to non-web (standalone) environments, including server-side and embedded systems. In Wasm, the executable code (a "module") runs within a sandbox, and the hosting environment (the "host") strictly controls the system resources that the module can access. The module cannot access outside memory and it does not have direct access to hardware, I/O, or the operating system, and can only interact with the environment through imported functions provided by the host. This restricted access model helps prevent malicious behaviour, and therefore, ensures security. The component of the host that provides access to these external resources and APIs (e.g., JavaScript APIs in a browser) is known as the "embedder". Wasm provides the sandboxed software with a linear addressed memory space, isolated from the host system and other modules memory, unless explicitly shared by the host. This isolation is combined with restricted I/O access, thus it provides a high level of security, and allows the execution of arbitrary code from untrusted sources. The module's memory can be expanded or contracted at runtime, but the Wasm v2.0 specification 8 does not allow the creation or use of additional memory spaces by a single module. By design, a Wasm module requires a runtime environment for execution. This runtime manages critical aspects of the module's interaction with the host environment, including I/O operations, memory management, and function imports/exports. These interactions must be explicitly defined and carefully controlled to ensure seamless and secure execution across different environments. 2.2.4 WebAssembly System Interface The WebAssembly System Interface 9 (WASI) is a standardised system interface designed to facilitate the execution of Wasm in non-web environments. The need for a system interface became apparent after Wasm release, given that programming languages typically rely on OS system calls to access resources and files. To ensure Wasm remains portable across various machine architectures, a standardised system interface, such as WASI is essential. Wasm, with its goal of being portable across any machine, did not originally have such system call capabilities. WASI offers this characteristic by providing a standardised API that enables Wasm modules to perform I/O operations, access the system clock, and communicate over networks while maintaining portability. Applications can import these interfaces---i.e., the Wasm module can declare that it requires functions from the runtime with certain identifiers---and call them in order to access host functionality, mediated by the runtime. The application binaries can be executed on any machine with a WASI-compliant runtime, regardless of the underlying OS, ensuring Wasm’s portability while expanding its capabilities beyond the browser. WASI v0.2 10 , also, introduces a component model, which facilitates both system interfaces and modules to be specified in a high-level form that allows easier composition of different components. These specifications are expressed in the WebAssembly Interface Type (WIT) 11 interface definition language and they are a primary output of the WASI standardisation effort. 8 https://webassembly.github.io/spec/core/syntax/modules.html 9 https://wasi.dev/ 10 https://github.com/WebAssembly/wasi-random/tree/v0.2.0 11 https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 19 - August 31, 2025 The sandboxed application cannot directly access outside resources, but only via WASI interfaces that are implemented by the embedder. Because of this, the access control model does not need to match that of the underlying operating system. WASI takes advantage of this to introduce a capability-based security model, where applications can only access system resources like files via an unforgeable handle that is associated with the permissions granted to the application, allowing much greater flexibility than a lowest-common-denominator approach that provides only the security features available in all relevant platforms. System interfaces, like WASI, are needed only in standalone applications where system access (like file I/O or networking) is needed directly from the application. In web environments, the browser sandbox and JavaScript APIs provide controlled access to system resources, meaning that a separate system interface is not needed. 2.2.5 WebAssembly runtime Wasm modules must be translated to native code or interpreted by a runtime, which can be within a web browser, a library, or a standalone application. In either case, the runtime executes the Wasm instructions, manages memory, and provides the system interface. For web-based Wasm environments, JavaScript engines within browsers are used to execute the code, e.g., V8 (in Google Chrome and Microsoft Edge), SpiderMonkey (in Mozilla Firefox), and JavaScriptCore (in Safari). For non-web-based applications, a variety of runtimes are dedicated to Wasm execution, the most well-known being: ● Wasmtime 12 : A runtime written in Rust with a focus on security and performance. It provides robust support for a wide range of platforms (Windows, macOS, and Linux) and can be embedded into applications written in several languages (e.g., Rust, C, and Python). ● Wasmer 13 : Advertised as a universal Wasm runtime, it can be run on Edge, desktop, cloud, and browser. Wasmer provides libraries that allow it to be embedded into applications written in a wide range of languages (e.g., Rust, C, C++, D, Zig, and Python). ● WasmEdge 14 : A lightweight and compact runtime optimised for edge computing and decentralised applications (e.g., smart contract). It provides support for WASI and can be integrated into many cloud-native tools. Many other runtimes exist, including WAMR, WAVM, Deno, Lucet, Wascc, and a runtime embedded into Node.js. These runtimes ensure the core properties of Wasm, such as portability, safety, and integration, but are designed and optimised for specific applications or platforms. Thus, choosing the most suitable runtime is crucial to achieve optimal performance in a particular application area. 2.2.6 Development and deployment of standalone WebAssembly applications Figure 2 below, provides an example of compiling C code to Wasm binary and executing it with different runtimes and frameworks. 12 https://wasmtime.dev/ 13 https://wasmer.io/ 14 https://github.com/WasmEdge/WasmEdge ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 20 - August 31, 2025 A specific sequence of steps is required to generate executable Wasm code suitable for execution outside the browser environment. First, the program is written in a language that has Wasm support; these are relatively widespread due to support by the Low Level Virtual Machine (LLVM) compiler infrastructure, and include C, C++, and Rust. The code is then compiled to a Wasm module, which can be deployed to any of the application's supported platforms. The code is then executed by a suitable runtime, which will execute the compiled Wasm module and provide access to available system interfaces. Figure 2. Compiling C to a Wasm binary executing with different Wasm R/Ts & Frameworks ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 21 - August 31, 2025 3 Wasm Landscape Wasm was originally designed for execution within web-based environments, i.e., primarily web browsers. A runtime environment is required by Wasm modules or codebytes for being loaded into and executed within. This is true regardless of the environments (web-based or not) and platforms, where Wasm is deployed. Wasm runtimes enable the execution of Wasm codebytes in standalone mode and expand its applications beyond web-based ones. This section presents the related works with the standalone Wasm applications within a TEE . Moreover, in Section 3.1 we give an overview of the relevancy of these runtimes to other WPs of ELASTIC than WP3. 3.1 Wasm Runtimes, Performance and Limitations One of the ELASTIC objectives focuses on addressing the efficiency and the portability of edge workload orchestration with the deployment of isolation technologies into edge and possibly far-edge environments. Therefore, Wasm runtimes as introduced in this section might be of particular interest for such resource limited or lightweight isolation and orchestration needs. A characterisation study of standalone Wasm runtimes has been published by the University of Georgia 15 . The outcomes of this study have highlighted the significant impact of executing Wasm runtimes with regards to various performance criteria for the host platform. In more details, one of the main conclusions is that Wasm runtimes should be selected with care to the target platform and that compilation and code optimisation techniques should be assessed as well. To cover the ELASTIC needs, selection criteria for Wasm runtimes are introduced as follows: ● Lightweight design. Lightweight Wasm runtimes shall be considered to address edge and far-edge devices. ● Minimal performance impact. By design Wasm runtimes are adding an overhead compared to natively executed binaries. Thus, computational time or executed instructions are affected by Wasm. Therefore, in ELASTIC, we must aim for runtimes that minimise these impacts. ● Minimal memory footprint. Depending on the underlying technology for code compilation and/or interpretation, the memory consumed by the Wasm runtime might greatly vary. Thus, in ELASTIC the goal is to leverage runtimes that minimise the memory footprint. There are several Wasm runtimes 16 that can be utilised to execute Wasm binary. However, in this report we only focus on the noteworthy Wasm runtimes. 3.1.1 WebAssembly Micro Runtime WebAssembly Micro Runtime (WAMR) 17 is an open source, lightweight, high-performance, highly configurable standalone 18 Wasm runtime that is developed by the bytecode alliance community. WAMR is developed utilising C, where AoT runtime binary size is 50 KiB whereas the interpreter size is 85 KiB. WAMR is equipped with features that make WAMR compatible 15 Wang, W. (2022, November). How far we’ve come–a characterization study of standalone WebAssembly runtimes. In 2022 IEEE International Symposium on Workload Characterization (IISWC) (pp. 228-241). IEEE 16 https://github.com/appcypher/awesome-wasm-runtimes 17 https://github.com/bytecodealliance/wasm-micro-runtime 18 Without relying on a browser ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 22 - August 31, 2025 with a variety of use cases, such as cloud computing, IoT and edge devices. WAMR key specifications and features can be summarised as follows: ● Light footprint with small binary runtime files. This is true regardless of the mode selected for executing the modules. Moreover, WAMR has only a few external dependencies. ● Multiple execution modes. The users can explicitly configure the execution of their bytecodes with an interpreter, an ahead-of-time compiler (AOT), or a just-in-time compiler (JIT). ● Fast compilation time with a near-native speed for both AOT and JIT compilers. ● Portability. Its employing interpretation enables Wasm binary’s cross-platform execution, for example on Linux and Windows. ● WASI compatible, as WAMR provides support for native libc, built-in libc, and WASI instructions. ● Multiple systems support, with implementations for Windows, Linux, MacOS, and Android. The above-mentioned features make WAMR a favourable choice for researchers and developers. Also, WAMR is ported and suitable to run on top of an embedded RTOS, specifically Zephyr. Moreover, the configurable features can be finely tuned and adjusted to accommodate the specifications of the intended applications and the used TEEs. 3.1.2 Wasmtime Another standalone Wasm runtime is called Wasmtime. Wasmtime is also developed by the bytecode alliance community, and thus targets the same properties, to be open source, lightweight, high-performance and highly configurable standalone Wasm runtime. In addition to Go, Python and Rust, Wasmtime supports natively C/C++, .NET and Ruby, while the community also supports Elixir and Perl languages. Wasmtime key specifications and features are summarised below, making Wasmtime another favourable choice for researchers and developers and the most widely used standalone Wasm runtime. ● Multiple execution modes. Wasmtime is designed to perform fast and securely for applications of any scale. This runtime can be also used in the application scenarios, where controlling CPU and optimising the memory consumption is required, such as in a Wasm trusted runtime (i.e., the Wasm runtime built for a TEE). ● WASI Compatible. Wasmtime supports API compliance with the WASI standard. ● Multiple systems support. Wasmtime has the ability to be used both as a commandline utility and/or to be used in the larger applications as an embedded library 19 . 3.2 Early Implementations of WebAssembly in TEEs The rapid expansion of cloud computing presents security and privacy challenges. This is due to the fact that most of the applications leveraging cloud computing require managing highly sensitive data, such as personal data for healthcare providers, financial records, and industrial secrets. Managing highly sensitive data requires the establishment of trust between multiple parties in order to provide privacy-preserving and confidential computing services. The 19 https://docs.wasmtime.dev ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 23 - August 31, 2025 industry’s answer to these challenges is to develop TEEs (technologies such as Intel SGX 20 , AMD SEV-SNP 21 , Arm CCA 22 , and Arm TrustZone 23 ). These technologies can provide hardware-based TEEs for executing codes within their respective processors. Major cloud computing providers, such as AWS and Azure, utilise TEEs. Wasm trusted runtimes are designed to execute unmodified and language-independent applications inside TEEs. While TEEs provide a sandboxed environment within the processor, Wasm runtimes provide sandboxed software runtimes nested within TEEs. In the following, we first briefly mention the early trials on running Wasm in a TEE. Then, we present the state-of-the-art on Wasm trusted runtimes and frameworks. Teaclave, Se-Lambda, and AccTEE are three of the noteworthy early trials on enabling the execution of Wasm binaries in a TEE. In this subsection, we give a brief introduction to these three tools. 3.2.1 Se-Lambda Se-Lambda 24 was developed in 2018 and uses Intel SGX to provide the double-sandboxed environment. Se-Lambda provides serverless computing framework and remote attestation mechanisms. It was built on top of OpenLambda 25 . 3.2.2 Teaclave Teaclave 26 developed in 2019 and runs on Intel SGX and integrates Wasm Micro Runtime as an executor. Teaclave is an open-source platform that provides remote attestation. Teaclave enables developers to write programs in Rust and execute them in enclaves. Some sources do not consider Teaclave as a trusted runtime, but as a tool that facilitates interpreting WebAssembly bytecode in a sandboxed environment. 3.2.3 AccTEE AccTEE 27 uses Intel SGX as its TEE. AccTEE is open-source, and it offers a doublesandboxing environment. AccTEE was developed in 2019, and as an “early” trusted runtime relied to the Node.js 28 JavaScript runtime as a building component. Moreover, to execute JavaScript and Wasm, the developers of AccTEE utilised Chrome’s JavaScript engine V8. Figure 3 below illustrates the components of AccTEE. 20 https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/overview.html 21 https://www.amd.com/en/developer/sev.html 22 https://www.arm.com/architecture/security-features/arm-confidential-compute-architecture 23 https://www.arm.com/technologies/trustzone-for-cortex-a 24 Qiang, W., Dong, Z., & Jin, H. (2018). Se-lambda: Securing privacy-sensitive serverless applications using sgx enclave. In Security and Privacy in Communication Networks: 14th International Conference, SecureComm 2018, Singapore, Singapore, August 8-10, 2018, Proceedings, Part I (pp. 451-470). Springer International Publishing. 25 https://www.usenix.org/conference/hotcloud16/workshop-program/presentation/hendrickson 26 https://teaclave.apache.org/docs/executing-wasm/ 27 Goltzsche, D., Nieke, M., Knauth, T., & Kapitza, R. (2019, December). Acctee: A webassembly-based two-way sandbox for trusted resource accounting. In Proceedings of the 20th International Middleware Conference (pp. 123-135). 28 https://nodejs.org/en ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 24 - August 31, 2025 Figure 3. Components of AccTEE (Source 29 ) 29 Goltzsche, D., Nieke, M., Knauth, T., & Kapitza, R. (2019, December). Acctee: A webassembly-based two-way sandbox for trusted resource accounting. In Proceedings of the 20th International Middleware Conference (pp. 123-135). ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 25 - August 31, 2025 4 Wasm and Trusted Execution Environments This section examines the synergies between WebAssembly and TEEs in greater depth. It provides a comparative overview of key TEE technologies (e.g., Intel SGX, AMD SEV, ARM CCA, RISC-V) and evaluates efforts to run Wasm within these environments. Projects such as TWINE 30 ,WaTZ 31 , Enarx 32 , and Veracruz 33 are discussed in terms of architecture, limitations, and use case applicability. The section also introduces key challenges in secure memory isolation, syscall management, and hardware interfacing. 4.1 Introduction to Trusted Execution Environments (TEEs) Trusted Execution Environments (TEEs) are secure, isolated regions within a processor that provide confidentiality and integrity guarantees for data and code during execution. TEEs operate independently of the operating system and other privileged software, thereby protecting sensitive computations even in the presence of a compromised host system. In the context of ELASTIC, TEEs play a pivotal role in enabling privacy-preserving and trustworthy services across multi-tenant and multi-provider environments. They support the secure execution of workloads in edge and cloud scenarios, mitigate risks from untrusted infrastructure components, and serve as the enforcement mechanism for secure enclaves. Despite their strong isolation guarantees, TEEs pose several technical challenges: ● Limited resources, such as memory constraints. ● Restricted runtime environments, often requiring specific development models. ● Complex attestation mechanisms, which must be integrated into broader software stacks. To address these challenges, the ELASTIC platform explores the integration of Wasm with TEEs. This combination offers a portable, lightweight, and language-agnostic execution model that can be embedded into TEEs with minimal overhead. By leveraging Wasm sandboxing and TEE hardware isolation together. This is sometimes referred to as “double sandboxing”. ELASTIC strengthens the protection of data-in-use and enables flexible deployment of secure services across heterogeneous hardware environments. 4.2 Overview of Trusted Execution Environments (Intel SGX, AMD SEV, TDX, ARM CCA, RISC-V Keystone) By leveraging hardware-backed isolation, TEEs are increasingly adopted to support confidential computing paradigms across cloud, edge, and embedded systems. This section provides an overview of key TEE technologies relevant to the ELASTIC platform, focusing on their architecture, capabilities, and suitability for running secure Wasm workloads. 30 Ménétrey, J., Pasin, M., Felber, P., & Schiavoni, V. (2021, April). Twine: An embedded trusted runtime for webassembly. In 2021 IEEE 37th International Conference on Data Engineering (ICDE) (pp. 205-216). IEEE. 31 Ménétrey, J., Pasin, M., Felber, P., & Schiavoni, V. (2022, July). WaTZ: A trusted WebAssembly runtime environment with remote attestation for TrustZone. In 2022 IEEE 42nd International Conference on Distributed Computing Systems (ICDCS) (pp. 1177-1189). IEEE. 32 https://enarx.dev 33 https://veracruz-project.com ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 32 - August 31, 2025 inserts this copy into a sandboxed memory. It then computes the required hash to be used for attestation, and finally executes the code. To design the WaTZ attestation mechanism, the developers created a new service as a new kernel module for OP-TEE. This new module provides the functionality to produce evidence for the relevant parties, when a proof of the applications’ authenticity is needed. Figure 5 illustrates the architecture of WaTZ. Figure 5. Architecture of WaTZ 47 4.3.3 Enarx Enarx 48 is an open-source framework that provides a Wasm trusted run-time with attestation mechanism 49 . The current implementations (Enarx 0.7.0 January 2023) 50 include supports for both Intel SGX and AMD SEV. The initial goal of the Enarx project was to create a CPU architecture-independent runtime, to provide a convenient method for developing applications without requiring code modifications for compatibility with different hardware technologies. The core focus of Enarx is to provide protection for data-in-use, i.e., the data in the processor, while a code is being executed. This is done by assuming all components outside the Keep 51 are untrusted, except the Keep platform and the CPU with its firmware. Any other components, such as the hypervisor, the kernel, and the operating system, are unable to access the code inside the trusted Keep. Although shifting the burden of establishing trust from the user is advantageous, in the context of secure computation, trust does not necessarily mean security. Therefore, Enarx employs several design principles to ensure data security. These principles 52 are minimal trust computing base, minimum trust relationship, deployment-time, network stack, security at rest, auditability, memory safety, and no backdoors. Enarx uses the following components in its architecture: 47 Ménétrey, J., Pasin, M., Felber, P., & Schiavoni, V. (2022, July). WaTZ: A trusted WebAssembly runtime environment with remote attestation for TrustZone. In 2022 IEEE 42nd International Conference on Distributed Computing Systems (ICDCS) (pp. 1177-1189). IEEE. 48 https://enarx.dev 49 https://hackmd.io/@enarx/rJ55urrvo 50 https://blog.enarx.dev/enarx-0-7-0-gutenberg-castle/ 51 The developers of Enarx refer to an instance of a TEE as a Keep. 52 https://webthesis.biblio.polito.it/31077/ ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 33 - August 31, 2025 ● A Loader (in process-based TEEs like SGX) or a Virtual Memory Manager (or hypervisor in VM-based TEEs like SEV-SNP). ● A Linux microkernel (shim). ● A Wasm runtime (Wasmtime). ● A WASI Interface. Enarx components form an abstraction layer for the host's system. This abstraction layer is to ensure that workloads are isolated and protected using TEEs. Instead of replacing the system’s software layers, Enarx provides a secure layer over them. It utilises the WASI and the Wasm runtime, i.e., Wasmtime, to provide APIs and networking necessary for secure code execution. This abstraction allows developers to create applications without needing detailed knowledge of the target system hardware. By leveraging Wasmtime JIT compiler and WASI portability, the developers of the Enarx framework ensured the code portability across platforms without compromising security. The security measures in Enarx are prevalent in its steps of executing code. The developer can write an application in any language supported by Wasm and compile the code with Enarx as a compilation target. Thereafter, a Keep must be initiated by Enarx to execute that code on the host’s machine, which is realised in three steps. 1. Attestation. It is a verification step, where the guest verifies the authenticity of the Keep within the host machine. This step is performed by the Enarx attestation measurement. (Section 6.2.3.1 provide additional details on Enarx remote attestation functionality) 2. Packaging. After a successful attestation handshake, Enarx employs encryption algorithms to encrypt the guest’s application and data. The encryption is an additional layer for data-in-use protection inside the Keep. With the isolation of the Keep, it will prevent any software layer, even a privileged one, from accessing and reading the data as plain text. 3. Provisioning. The last step is the encrypted data (code) into the Keep, as well as provisioning the resources required for code execution. Any abnormality during execution, such as requesting an unauthorised system call or additional memory allocation, triggers a termination call for the Keep and its associated data. 4.3.4 Veracruz Veracruz 53 is a framework that provides Wasm trusted runtime. Veracruz is focusing on VMbased TEE technologies for future development 54 , such as Arm CCA and AWS Nitro 55 Enclaves. In Veracruz WASI was chosen as the programming model, often described as "POSIX for WebAssembly," as it provides a system interface for tasks such as accessing Veracruz's inmemory filesystem, generating random bytes, and similar operations. In this context, the Veracruz runtime functions as a basic operating system for WebAssembly. By leveraging WASI, developers can utilise existing libraries and standard programming practices when building applications for Veracruz. WASI employs a capability-based security model, ensuring that programs can only access functionalities they have granted explicitly permission to use. 53 https://veracruz-project.com 54 https://github.com/veracruz-project/veracruz/issues/330 55 https://aws.amazon.com/ec2/nitro/ ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 34 - August 31, 2025 There is a difference between TWINE and Veracruz. TWINE provides a sandboxed environment to run untrusted and arbitrary code, whereas Veracruz presents a framework to develop Wasm applications in a TEE for privacy-preserving application scenarios. Veracruz also provides attestation 56 . In Veracruz, for the Wasm runtime also Wasmtime is chosen by the developers as the Veracruz JIT engine. 4.4 Conclusion on Wasm Trusted Runtimes Two Wasm runtimes have been selected in this report in accordance with ELASTIC selection criteria and were introduced in Section 3. The first one, WAMR, is a lightweight Wasm runtime specifically targeting resource-limited environments. The second, Wasmtime, was chosen due to its significantly higher performance compared to other runtimes, and thus making it wellsuited to achieve the efficiency and portability objectives of ELASTIC research program. The Enarx project stands out as one of the most advanced implementations for securely running Wasm workloads within TEEs so far. Its modular architecture and comprehensive TEE support make it a good guideline for developing secure and flexible frameworks. Enarx supports both Intel SGX and AMD SEV. By leveraging Enarx's design principles and components, we can effectively address key challenges, such as workload isolation, attestation, and cross-TEE compatibility. Moreover, TWINE offers a comprehensive trusted runtime for Intel SGX. WaTZ provides Wasm runtimes for small edge-scale Arm processors, and therefore, can be a suitable casestudy for WP4. Veracruz is more suitable for privacy-preserving application scenarios. Teaclave, AccTEE, and Se-Lambda were earlier trials on running Wasm in a TEE, and thus, are not the focus of the ELASTIC project. 4.5 Isolation and execution model of TEE-protected Wasm applications The Wasm execution model is highly flexible in terms of the isolation that it provides. A Wasm component includes not only the modules that contain its bytecode, but also directives specifying how to instantiate memory, which memory is accessible to each module, as well as how the functions imported and exported by each module that need to be linked together, or exposed outside the component in order to be called or satisfied by the runtime itself. Where components are independent of each other, they can be separated in order to avoid any shared resources; this allows the use of mutually-distrusting components within a single runtime. This is known as the shared-nothing model, and allows us to use Wasm for intraprocess isolation within a single TEE. This increases the scalability of the platform to allow larger numbers of components than a platform would be able to support with a TEE-percomponent approach, since the overhead from instantiating a Wasm component is much less than that of instantiating an entire confidential VM. System calls for Wasm applications are provided using normal imports and exports, specified by WASI standards. As a result, when instantiating a subcomponent, a component may instead specify that the subcomponent's access to the wider system is to instead virtualised by another component implementing a standard WASI interface, as exemplified by the WASI Virt tool 57 , that allows developers to easily place untrusted components into an isolated virtual environment. 56 Brossard, M., Bryant, G., El Gaabouri, B., Fan, X., Ferreira, A., Evans, E. G., ... & Xiong, S. (2023). Private delegated computations using strong isolation. IEEE Transactions on Emerging Topics in Computing, 12(1), 386-398 57 https://github.com/bytecodealliance/WASI-Virt ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 35 - August 31, 2025 However, by incorporating TEEs and other specialised hardware features into a Wasm platform, we lose the ability to depend solely on standard implementations of these interface standards. Wasm runtimes provide implementations of many WASI interfaces that transform WASI calls into native system calls, whether using POSIX interfaces or some other platform-specific interface. The use of specialised hardware forces us to determine how to best implement these interfaces ourselves, whether in the runtime or in Wasm itself. 4.6 Interfacing with Hardware I/O Devices Wasm operates on a stack-based architecture and utilises a contiguous, byte-addressable linear memory for managing state within a module. However, Wasm modules are inherently sandboxed – by default, they are isolated from host system resources and cannot perform common operations, such as file I/O, network access, or console output. To address this limitation, WASI was introduced. WASI defines a standardised, capabilitybased interface for performing system-level operations in a secure and portable manner, enabling Wasm binaries to run consistently across heterogeneous operating systems and runtime environments. 4.6.1 WASI: Design Principles and Operational Model WASI acts as a system interface for WebAssembly modules outside the browser and adheres to several key design principles: ● Portability: WASI enables "compile once, run anywhere" binaries, extending beyond the source-level portability offered by traditional standards, such as POSIX. ● Security: Leveraging Wasm intrinsic sandboxing, WASI adopts a capability-based security model. Modules access resources through unforgeable handles (e.g., preopened file descriptors), thereby constraining access and minimising attack surfaces. ● Modularity: WASI is composed of discrete interface modules. This allows runtime environments to implement only the components required by their context. For instance, a runtime on an embedded system might support random number generation and clock access without implementing file system functionality. 4.6.1.1 System Call Mediation in Trusted Execution Environments When Wasm workloads are executed within a TEE (such as those enabled by the Enarx framework) system call mediation is performed through a carefully structured sequence of operations designed to maintain the confidentiality and integrity guarantees of the enclave. System calls are initiated by the Wasm module through WASI. These invocations do not interact directly with the host operating system. Instead, they are intercepted within the enclave boundary. The TEE's shim layer is responsible for serializing the syscall number along with its arguments into a designated shared memory region—commonly referred to as a Sallyport block. Once the syscall is encoded, the TEE triggers a secure interrupt, such as a VM exit, to notify the untrusted host that a system-level operation is required. The host then performs the requested operation and writes the resulting data or status code back into the Sallyport block. Following this, the control returns to the enclave, where the shim deserializes the result and passes it to the Wasm runtime. At every stage of this round-trip, strict validation and sanitisation procedures are enforced. Sensitive data that crosses the enclave boundary may be encrypted, and all interactions are closely controlled to ensure that only authorised system calls are ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 36 - August 31, 2025 executed. This mediation layer plays a critical role in preventing unintended information leakage or unauthorised host-level access, thereby preserving the trusted computing guarantees expected within TEEs. 4.6.2 Limitations in WASI-TEE Integration Despite the significant progress enabled by the WASI and its integration with TEEs, several architectural and implementation challenges remain. One foundational limitation lies in the restricted data types supported by the WebAssembly, which includes only basic numeric types (i32, i64, f32, and f64). Complex data structures must be manually encoded into linear memory and manipulated using tooling such as wasm-bindgen or waPC, which introduces additional complexity and potential for error. The growth of the TCB is another area of concern. While Wasm runtimes like Wasmtime are compact and memory-safe due to their Rust-based implementation, the inclusion of the WASI layer and its supporting libraries expands the TCB surface. This expansion increases the number of trusted components and, consequently, the attack surface. The correctness and security of these components are paramount, as any vulnerability within the runtime, WASI interface, or auxiliary libraries can compromise the enclave’s isolation guarantees. Interactions across the enclave boundary add further vulnerability. Mediation of syscalls, particularly those handling file I/O or networking, introduces potential exposure if not implemented securely. Additionally, WebAssembly itself does not offer native protections against side-channel attacks: even within the confines of trusted hardware, workloads may leak sensitive information through mechanisms such as cache timing or page-fault–based side channels. Research has demonstrated the reality of sophisticated side-channel attacks— including the combination of cache and page-table signals—against SGX and SEV enclaves. 58 Hardware-level concerns further affect the trust model. Vulnerabilities in TEE technologies such as Intel SGX or AMD SEV, or in their associated firmware, can undermine the integrity of the entire system. Finally, performance and memory overheads are non-trivial. TEEs inherently introduce latency—particularly process-based TEEs like SGX, which suffer from higher contextswitching costs compared to VM-based solutions like SEV. 59 Additionally, encrypted memory access can degrade performance by 2–4% depending on the workload. Memory overhead is similarly increased due to encryption requirements and the inability to share memory pages across workloads, leading to reduced memory efficiency relative to traditional containers or virtual machines. 4.6.3 Future Directions for WASI and WebAssembly Runtimes The WebAssembly and WASI ecosystems continue to evolve, addressing both current limitations and broadening their applicability through ongoing standardisation efforts: ● Extended Interface Types: WebAssembly has standardised multi-value return types, enabling functions to return multiple values 60 . Additionally, reference types (externref) and higher-level interface constructs are under development to support non-numeric values and structured communication between host and module. 58 https://repository.gatech.edu/server/api/core/bitstreams/337be412-9412-4767-9d0d-edb187a0a38c/content 59 [2408.00443] An Experimental Evaluation of TEE technology Evolution: Benchmarking Transparent Approaches based on SGX, SEV, and TDX 60 https://github.com/WebAssembly/spec/blob/main/proposals/multi-value/Overview.md ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 37 - August 31, 2025 ● Module Interoperability: Recent proposals include module linking and support for shared memory and threads, essential for enabling languages such as Java and Swift to run efficiently under Wasm. 61 ● Runtime Enhancements: Significant work is underway to incorporate garbage collection support for managed languages like Python or Java, as well as to implement asynchronous I/O, file watching, and locking primitives. A WASI Sockets standard is also emerging, though its final form remains under discussion. 62 61 https://eunomia.dev/blog/2025/02/16/wasi-and-the-webassembly-component-model-current-status/ 62 https://bytecodealliance.org/articles/wasmtime-27.0 ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 38 - August 31, 2025 5 Hardware Abstraction Layer (HAL) This section contains the specifications for the HAL for confidential computing as defined by the ELASTIC project. It specifies the TEE HAL and introduces its deployment scenarios. This specification serves as the basis for the complete confidential computing framework within the project. Requirements for the TEE HAL are derived based on the provided deployment scenarios. Next, interfaces on an abstract level fulfilling the requirements are listed, while detailed implementation recommendations will be made in the next phase of the project. 5.1 HAL Analysis and Design Goals ELASTIC WP3 addresses portable computing using trusted execution environments. The solution’s core is the ability to run Wasm applications on different confidential computing platforms. The HAL specification is essential to enabling this and is a core building stone to achieve the WP3 objectives. This specification is a prerequisite to fulfil the ELASTIC architecture concerning executing portable functions with confidential computing requirements. It supports the on-demand execution and orchestration needed to realise the WP1, WP2, and WP4 frameworks when the functions have strong security/privacy expectations. This HAL specification will also support the realisation of the WP5 pilot use cases. As the HAL alone will not be enough to achieve these goals; it is important to ensure agnostic solutions that can be realised on important current and future confidential computing platforms. The objective to create a privacy-preserving, architecture-agnostic, efficient, and secure execution environment requires solutions that allow protected deployment of workloads on many different types of secure execution environments with different edge resources and platforms. The ELASTIC HAL design will enable such interoperability. We put special efforts into identifying core HAL functionality and an architecture that can support a wide range of confidential computing platforms. Even if this does not allow agnostic secure deployment in all aspects, i.e., attestation handling, it will be an important step in achieving platform agnostic confidential platform resource accesses. The ELASTIC HAL will support a wide range of use cases with different security demands. To accomplish this, we have worked with a broad set of different deployment scenarios that represent typical usage for confidential computing. That does not mean that the HAL is limited to these scenarios, but these scenarios are carefully chosen to show the most important ELASTIC HAL deployments. Consequently, they will ensure that the specified HAL will be able to support the ELASTIC use cases and several other similar future use cases. As it is not practical to work on multiple deployment scenarios simultaneously, thus, we decided to limit the specification work to three different scenarios. An absolute requirement from ELASTIC point of view, is the support for the two demonstrators use cases, which are defined in the ELASTIC project. Based on this, it is natural to use these two demonstrators as deployment scenarios for the HAL framework, too. The following two TEE deployment scenarios were taken from the pilot use cases: ● Smart manufacturing ● IT Services Cloud Migration In order to complement these deployments, we have searched for a complementing scenario. The scenario was chosen based on the contributing research team’s needs. Based on this, the following scenario was added: ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 39 - August 31, 2025 ● Automotive proactive maintenance Below, we describe the three selected deployment scenarios in more detail. All scenario descriptions follow the same logical structure, i.e., scenario overview, description of involved entities, graphical description of the scenario and main actions, and finally, a summary of the security and performance expectations for the particular scenario. The first two scenarios used in this analysis are based on the ELASTIC demonstrator scenarios. This specification was delivered prior to the finalisation of the pilot scenarios, consequently, additional requirements might come up to the ELASTIC TEE HAL in the next phase of the project. 5.1.1 Smart manufacturing Smart manufacturing allows advanced production analytics as well as real-time production control. Traditional production plants have been controlled locally, with the overall management only at the central level. The Industry 4.0 paradigm 63 allows advanced analytics of production data combined with advanced coordinated production control, which can be enabled with the extension and complement of existing production infrastructures. However, to save costs and simplify management, production analytics and control can also be outsourced to third-party edge cloud resources. This is an attractive solution for new and small-scale production units. The analytics and controls into the two use cases have rather different demands and characteristics. Hence, rather than treating them as a single deployment scenario, we chose to describe them separately. This means this deployment scenario covers the following two sub-deployment scenarios: ● Advanced federated analytics of production data ● Edge-based production control Smart manufacturing can include a lot of different entities and different Industry 4.0 reference architectures, which can have different structures and entities. Here, we will only introduce entities essential for the understanding of the data flow and HAL platform usage in the deployment scenarios. Other entities are excluded for simplicity reasons. The entities and their roles are listed in Table 1 below. Table 1: Entities in the smart manufacturing deployments scenario Entity Description Role Controller - C The controller is responsible for controlling a production plant. It communicates with sensors and actuators to complete its tasks. The controller can be local, running on edge or in the cloud The local control entity in the scenario Product - P The product is the entity produced by the production plants. Some products have advanced communication interfaces and can communicate with external entities. This is the actual product subject to be manufactured in the scenario. Analytics Engine - A The analytics engine performs analytics tasks on production data and may also communicate with other analytics engines connected to the local or remote production plant. Responsible for production analytics processing. 63 L. Y. Nakagawa, P. O. Antonino, F. Schnicke, R. Capilla, T. Kuhn and Pe. Liggesmeyer, “Industry 4.0 reference architectures: State of the art and future trends”, Computers & Industrial Engineering, Vol. 256, 2021, https://doi.org/10.1016/j.cie.2021.107241. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 40 - August 31, 2025 Plant Production Manager - M The plant production manager's function is responsible for scheduling production tasks and gathering production information to optimise production flows. Production configuration and supervision. Edge Computing Resource - E An edge computing resource allows accelerating computing tasks close to the fabric. We here only consider edge computing resources with TEE and Wasm support. Edge resource to perform computing tasks requested by M entity. Edge Storage Resource - ES An edge storage resource allows non-volatile storage at the edge. Edge resource to store data from the production system. Cloud Computing Resource - C A cloud resource allows the execution of arbitrary computing tasks remotely. Cloud resource to perform computing tasks requested by the M entity. Cloud Storage Resource - CS A cloud storage resource enables remote non-volatile storage. Cloud resource to store data from the production system. 5.1.1.1 Manufacturing analytics deployment scenario This specification considers two different manufacturing deployment scenarios. The first scenario is an analytics scenario, where edge and central computing and storage resources are used to perform production flow analytics. The scenario is depicted in Figure 6 below. Figure 6. Analytics smart manufacturing deployment scenario. To better understand the scenario, we describe below the typical information flows and actions in this deployment scenario. 1. The scenario shows three different plants producing three different products, i.e., cars, buses, and wireless routers. All these products have network connectivity at the final production stage network connectivity. 2. The production at each plant is under control of one or several controllers. The devices control actuators, robots, or similar entities in the plant. This deployment scenario is limited only to local controllers. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 41 - August 31, 2025 3. A management system is in charge of the production plants. In the scenario description, a remote management function was taken into account, but it can be placed anywhere in the system with similar functionality. The management system is responsible for configuring controllers and all the other connected entities in the plants as well as analytics functions. 4. According to this deployment scenario, the management functions launch analytics functions (A) on edge resources in the system. The analytics function is assumed to run as Wasm processes on TEE enabled edge resources (E). The management functions, first, identify the suitable edge computing and storage resources to associate with each analytics function in the system. Next, the management system selects the suitable Edge execution resources. The identified TEE enabled resources are verified and if the verification succeeds, the analytics Wasms are launched on the identified resources. Once an analytics Wasm is launched, the management function configures protected analytics data passing from the production plant to the launched Wasm. This includes setting up the needed connectivity channels and protection mechanisms of these channels, which feed data from the production plant to the corresponding Wasm. This can be data from controllers, actuators, or even data from products themselves. To perform its tasks, the analytics Wasm needs access to non-volatile Edge Storage resources (ES) as well as a protected GPU hardware acceleration at E. The different analytics functions in the system are interconnected, such that federated analysis between different plants can take place in the system. 5. Optionally as shown in the deployment scenario, analytics functions (A) can also be launched on external cloud resources. These functions might collect results from local analytics functions in order to build “global” analysis models for the system. When this configuration applies, it is the management function that is responsible for identifying and verifying such analytics Wasm cloud resources and launching them in the system. Last, it is the management function that sets up the necessary data channel feeds from local (edge also) analytics functions to the central analytics function, as well as feeding analytics results back to the management system. 6. The dotted lines in Figure 6 show the analytics data flow in the system. All data flows are assumed to take place, using integrity and confidentiality-protected data channels. 7. The management function is assumed to control all production in the system based on the received analytics results. The non-dotted arrows show the control data flow used by the management system when reconfiguring production controllers in the system based on analytics results. All these control flows are assumed to take place over integrity and confidentiality-protected channels. 5.1.1.2 Edge control manufacturing deployment scenario The second manufacturing deployment situation is based on the case, where the production control is moved from local controllers to edge controllers. This scenario presents a more advanced control functionality for the ELASTIC framework. Figure 7 shows this second deployment for smart manufacturing. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 48 - August 31, 2025 5.1.3.2 Data protection and performance expectations Here, we summarise the main data protection and performance implications for the proactive maintenance deployments described in Section 5.1.3.1. Security Wasm modules provided by the manufacturer that detect latent faults should not be accessible to vehicle owners or network operators, since they may contain commercially sensitive information such as proprietary fault detection algorithms. This requirement can be met through the use of ELASTIC’s TEE-hosted Wasm runtime and orchestration technology. Data reported from the vehicle must not be modifiable by the end-user, to ensure owners get a warranty replacement of a non-defective engine that has failed due to abuse, nor should they hide an already-detected fault in an attempt to hide it from a buyer. This can be ensured by 's ELASTIC Wasm runtime using its containing TEE to attest itself to the manufacturer and using secure storage (perhaps within the TEE, or perhaps by outsourcing it to the ECU) in order to record detected faults. Commercially sensitive data collected by the ECU must not be easily available except to the manufacturer system and manufacturer-approved software. Also, unapproved software should not be allowed to issue commands to the ECU that might affect sensitive functionality, such as those related to emissions. We do so in this case by requiring that the fault-diagnosing Wasm module attest itself to the ECU before it begins communication. Performance The ELASTIC TEE-enabled Wasm runtime must be able to perform real-time data processing by the highest-volume combination of sensors that the manufacturer wishes to monitor simultaneously. Not all sensors need to be monitored simultaneously, as some potential faults may manifest themselves only in certain regimes, e.g., the faults that are only visible when the engine is outputting significant power need not be checked when the vehicle is parked, or inconsistent outputs from a parking sensor cannot be diagnosed when a vehicle is on the highway. The attested link between VAPP and ECU must have sufficient capacity to transmit all relevant data to the VAPP. When this is not the case, it may be necessary to have an ELASTIC-enabled ECU that can perform data minimisation using a sandboxed Wasm module. VAPP must have the capability to run enough Wasm modules so that it can handle all active “soft recalls”, i.e., one module for each fault which is neither confirmed nor eliminated. MFG's ELASTIC orchestration capability must be capable of scaling to the manufacturer's entire fleet of vehicles. Based on this, it must be possible to realistically deploy a module to millions or tens of millions of vehicles promptly. 5.2 HAL Requirements This section defines the ELASTIC HAL requirements. We start by giving a short overview of the requirement derivation principles used and then the actual documentation of the requirements follow. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 49 - August 31, 2025 5.2.1 Requirements Derivation Principle We follow the ISO/IES/IEEE 29148 standard for requirements engineering 64 . The standard assumes direct access to system stakeholders. As we do not have that scheme, the deployment scenarios documented in the previous section are the starting point for the derivation of stakeholder requirements. Apart from this limitation, the TEE HAL requirements are defined using the 29148-software requirement’s structure. The first step of a 29148 requirements process is to identify stakeholder requirements. These requirements were (mainly) identified as part of the deployment scenarios presented in Section 5.1. The standard recommends the following process steps: 1. Define the constraints at the system level, i.e., they are defined in the scope of this document. 2. Define a representative set of activity sequences to identify all required services, i.e., they are obtained in the deployment scenarios documented in Section 5.1. 3. Identify the interaction between the users and the system, i.e., they are analysed in the deployment scenarios documented in Section 5.1. 4. Specify security requirements, which are described per deployment scenario in Section 5.1, too. The next step, according to the standard, is the collection of the requirements definitions. We followed the five process steps defined in IEEE 29148 framework: 1. Definition of function boundary, 2. Define each function that the system is required to perform, 3. Define necessary implementation constraints, 4. Define technical and quality in-use measurements, 5. Specify system requirements and functions The requirements in Section 5.2.1 are structured according to these 29148 recommendations listed above. 5.2.2 Dependencies The ELASTIC TEE HAL needs to allow Wasm workloads with strong confidentiality and integrity demands to be executed on different platforms supporting secure execution. In particular, the ELASTIC HAL must allow workloads to be migrated and deployed on different TEE architectures without losing any functionality. Hence, the HAL functions in this specification will enable Wasm interoperability without compromising security or performance. This in turn implies that the HAL is fully dependent on the implementation and support given in the particular TEE. To achieve this, we have chosen to keep the HAL functionality on a generic level as much as possible. Running Wasm inside a TEE requires a suitable Wasm runtime supporting the HAL. Hence, the HAL realisation is strongly dependent on the runtime. However, the HAL specification does not assume a specific runtime but it is defined on a generic level. The runtime is not enough to support the HAL, thus, a complete framework, which can handle the secure execution and HAL support on a TEE is required. 64 “System and software engineering – Lif cycl processes – Requirements engineering”, ISO/OES/IEEE 29148, 2011. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 50 - August 31, 2025 5.2.3 HAL functions The HAL functions support the ELASTIC deployment cases. To make it easy to follow the functions, they are structured in the next subsections according to their origin, i.e., the three different deployment scenarios that were presented in Section 5.1. Some functions are common for the different scenarios, in those cases, the functions are only specified in the first scenario in which they appear. Some motivations are the same for several requirements but we have chosen to repeat them in each case subsection such that it becomes clear what is the motivation behind each and every derived requirement. Some requirements identities (first column) have been included with brackets indicating that these specific requirements have a lower priority compared to the other requirements. The priority indicates the importance for support in the ELASTIC HAL reference implementation. 5.2.3.1 Smart Manufacturing The manufacturing deployment case was presented in Section 5.1.1. We analysed two different sub-cases: one case on distributed analytics and a second for edge and cloud-based manufacturing control. The analysis resulted in a set of required functions which are listed, explained, and the motivation described Table 4. Table 4: Required functions identified from the smart manufacturing deployment case ID Function Description Motivation 1 Secure transport, TCP and UDP This interface allows the Wasm application to set up external TLS and DTLS connections in client or server mode. Wasm analytics engines must be able to collect data from external sources and set-up secure data channels with a central analytics engine without risk of data confidentiality and integrity. 2 Encryption/Decrypt ion (in a general sense for different types of cryptographic primitives) An interface for the acceleration of common symmetric and asymmetric cryptographic primitives. Secure Wasm workloads for analytics will need an object security mechanism to process incoming data. Platform support for the main primitives accelerates analytics performance, simplifies Wasm deployment on different platforms, and reduces Wasm code size. Secure control of production processes will, also, need specific real-time adapted cryptographic protocols. 3 Integrity check Integrity will be provided with message authentication and signature primitives as part of the encryption/decryption support, see ID 2. See ID 2 4 Accelerated GPUbased computation An interface for access to graphics processing units for analytics. Analytics for factory production performance will need access to the hardware acceleration module. Real-time control of production flow might require hardware acceleration for the control process. 5 Access to random number generator An interface to a cryptographically sound random number generator. Secure exchange of analytics data using security mechanisms will require access to a cryptographically sound random source. Protected real-time control will also need access to a cryptographically sound random source. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 51 - August 31, 2025 6 Clock An interface to the system clock. Wasm secure control will require access to a reliable system clock. Wasm analytics tasks will need access to a reliable system clock to perform their tasks. 7 Non-volatile storage An interface for long-time storage. A TEE for edge control should be available in periods. It improves the management and the performance if not all control configuration data is transferred when a workload is terminated (and instead kept in non-volatile storage). Furthermore, new control modules should be able to be deployed in real time using configurations from an old Wasm control workload. 8 Secure non-volatile storage An interface to secure longtime storage. Data for non-volatile storage (see ID 7) might be confidential and must then be stored protected. 9 Resource allocation An interface for the Wasm to request more or less computing and memory resources from the platform. Analytics engines should have the possibility to request more resources and/or inform the platform of the resource needs. This allows better resource utilisation of the TEE compute platform. 10 Secure external event handler An interface to an external event handler can be used in order to receive trig events for other Wasm workloads on the same or a different platform. Secure control of remote processes will benefit from the handling of external events. Event handling will also enable coordinated control between different Wasm controlling workloads. 11 Wasm to Wasm protected internal communication An interface for the communication between different Wasm workloads executing on the same TEE VM. Some control tasks will take place with multiple collaborating workloads. A protected internal interface will enable such collaborative control without sacrificing security. 5.2.3.2 IT Service Cloud Migration The IT service cloud migration case was presented in Section 5.1.2. The analysis resulted in a set of expected functions. The most important platform functionality to support the IT migration case is the TEE agent. Such agents can be implemented in different ways. As the migration agent would be an essential infrastructure component, it is not natural to implement the agent as a Wasm workload but instead, as a native component running on the TEE. We moved on the function analysis based on this assumption, which implies that functional requirements on the HAL for this case are rather limited. The identified functions are listed, explained, and the motivation described in Table 5. Table 5: IT Service Cloud Migration functions ID Interface type Description Motivation 1 Secure TCP and UDP transport, This interface allows the Wasm application to set up external TLS and DTLS connections in client or server mode. The migrated service must be able to establish a connection with the user over a protected channel. It is also a requirement that migrated services shall be able to keep existing security associations and transport channels after migration. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 52 - August 31, 2025 7 Non-volatile storage An interface for long-time data storage. By supporting non-volatile storage for different Wasm workloads, it is possible to share data with new, migrated Wasm workloads, which speeds up and simplifies the migration for some workloads. 8 Secure non-volatile storage An interface to secure longtime data storage. Data for non-volatile storage (see ID7) might be confidential and must then be stored protected. 9 Resource allocation An interface for the Wasm to request more or less computing and memory resources from the platform. Migrated workload should be able to request the needed computing and memory resources. This allows better resource utilisation of the TEE compute platform. [12] Runtime attestation An interface for the Wasm to obtain the attestation (measurement) of the Wasm runtime Attestation is an expected property of the platform and the Wasm framework to allow deployment of workloads. However, the migrated workload might need to obtain the result of the attestation operation. [13] Platform attestation An interface for the Wasm to obtain the attestation (measurement) of the hosting platform Attestation is an expected property of the platform and the Wasm framework to allow deployment of workloads. However, a migrated workload might need to obtain the result of the attestation operation. 5.2.3.3 Proactive maintenance The proactive maintenance case was presented in Section 5.1.3. The analysis resulted in a set of identified functions. According to this deployment scenario, the Wasm workload performs advanced analytics on a TEE-enabled vehicle platform. Such analytics tasks require the possibility to “poll” the available hardware/software on the vehicle, as well as the possibility to access such resources on the vehicle. This implies lots of additional interface capabilities of the TEE of a not-so-generic type. Consequently, we marked here such functions with lower priority indicated with brackets ([]) around the ID in Table 6. The reason for making these function interfaces less prioritised is that this deployment scenario is not an ELASTIC use case and will not be used for any demonstrator in the ELASTIC project. This, also, means that these functions will not be part of the ELASTIC core HAL. The identified functions are listed, explained, and motivated in Table 6. Table 6: Proactive Maintenance functions ID Interface type Description Motivation 1 Secure TCP and UDP transport, This interface allows the Wasm application to set up external TLS and DTLS connections in client or server mode. The MNT needs to report status back to the MFG over a protected interface. 2 Encryption/Decr yption An interface for the acceleration of common symmetric and asymmetric encryption and decryption processes. The MNT needs to make diagnostic requests to the vehicle’s internal entities. Some of those might run proprietary authentication, confidentiality and integrity protection mechanisms. Platform support for the main primitives accelerates diagnostics performance, simplifies Wasm ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 53 - August 31, 2025 deployment on different platforms, and reduces Wasm code size. 3 Integrity check Integrity will be provided with message authentication and signature primitives as part of the encryption/decryption support, see ID 2. See ID 2 4 Access to random number generator An interface to a cryptographically sound random number generator. Protected collection of diagnostic data will require access to a cryptographically sound random source. 5 Clock An interface to the system clock. Diagnostics operations will require access to a reliable system clock. [12] Runtime attestation An interface for the Wasm to obtain the attestation (measurement) of the Wasm runtime The MFG might need to be able to verify integrity of the TEE runtime without communicating interactively [14] Vehicle system discovery An interface for the diagnostics Wasm to collect information of the locally supported functions and vehicle status. The MFG needs to be able to collect information on the hardware and software configurations applicable to the particular vehicle, subject to the diagnostics operations. Even if such information is typically already available at the MFG, specific local configurations and hardware changes might have been performed on the vehicle and some functions might even not be available due to faults. [15] Key handler An interface to request the needed key used to enable inside vehicle secure connection to vehicle entities. The MFG needs to set up secure connections with the different vehicle entities to collect diagnostic information. This interface allows the MFG to collect the key and credential information needed to set up such secure connections. [16] Secure CAN transport An interface to set up secure connections between the TEE and other vehicle entities over the CANbus and other, non-Ethernet local buses. The vehicle might support non-Ethernet internal communication means. Then, the TEE must be able to set up connections to vehicle entities without risk of sniffing or interference. 5.2.4 User characteristics The Wasm workloads communicate with the external world via the HAL. All user interactions with the workload take place through a network connection with specific interfaces. Hence, the HAL must provide good performance for setting up and maintaining secure connections. All other user aspects are handled on the application level not directly affecting the HAL design or functions. 5.2.5 Limitations Our analysis only takes into consideration the HAL functions needed to support the three deployment scenarios. Additional requirements would allow us to support a broader set of HAL functions. Even if this is the case, the requirements identified in our analysis constitute a suitable set considering the ELASTIC use cases and scope for running Wasm on TEE. Hence, we are comfortable that the identified requirements will provide a sound basis for the ELASTIC TEE HAL architecture. The TEE HAL architecture allows consistent extension opening up for ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 54 - August 31, 2025 covering additional HAL requirements.. Even if this is the case, it is important to notice that the HAL as specified here is not a generic TEE HAL. Such generic HAL would require requirements analysis from a very broad set of stakeholders. Consequently, it cannot serve in its present form as a draft standard. However, the defined requirements and specifications can provide a basis for potential future standardisation efforts. The requirements are not dependent on the actual runtime or TEE platform. However, this specification only considers two TEE platforms, which will be provided with detailed interface implementation recommendations. It is a major effort to provide such detailed interface recommendations requiring implementation resources beyond the scope of the ELASTIC project. Hence, we have decided to only provide those details for two major TEE platforms: ● AMD SEV-SNP 65 ● Intel TDX 66 5.2.6 Assumptions and Dependencies The HAL requirements assume the platform will support a suitable Wasm runtime inside the subject TEE. The realisation of such runtime is not within the scope of this specification. Within the ELASTIC project, we have the working assumption that the ELASTIC TEE runtime will be built upon the Enarx project architecture 67 . The HAL support and implementation is heavily dependent on the runtime technology as well as the TEE platform as such (See also the limitations above). 5.2.7 Apportioning of requirements The HAL requirements are generic for any ELASTIC TEE platform claiming ELASTIC support. The requirements apply to the platform providing the runtime for ELASTIC secure Wasm. Specific requirements The TEE HAL has no specific requirements beyond what is needed to be able to run Wasm on the TEE runtime. 5.2.8 External interfaces The TEE HAL defines the Wasm interface on the platform. In order to implement the HAL support on a specific TEE, the runtime must be integrated with several other platform functions. The way to provide these integrations is subject to the TEE-specific HAL implementation. That means that all the listed HAL functions must be supported on the TEE platforms, i.e., AMD SEV-SNP and Intel TDX. However, for a platform that lacks the support for the needed HAL functions, some interfaces might not be available. This may cause problems when running Wasm workloads on different platforms, as the workload might assume interfaces not available on the platform where it is currently mapped. To handle this, we have identified an additional mandatory ELASTIC HAL interface function specified in Table 7 below. 65 https://www.amd.com/en/developer/sev.html 66 https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/overview.html 67 Enarx, Confidential Computing with WebAssembly, https://enarx.dev/ ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 55 - August 31, 2025 Table 7: HAL Capabilities function ID Interface type Description Motivation 17 Platform capabilities This interface allows Wasm workloads to request the supported HAL functions on the current platform. Different TEE platforms might have different external interfaces as well as internal capabilities. To allow a Wasm application to run on platforms with different capabilities, it must be able to retrieve the specific HAL support on the current platform. Usability requirements The Wasm runs on the TEE without any direct user interface. It shall be easy to deploy and manage Wasm on different TEE platforms. The principles for managing and updating Wasm on the TEE are outside the scope of the TEE HAL specification. Performance requirements The TEE HAL needs an acceptable response time and speed for interfaces allowing direct external and internal communication. The definition of acceptable performance is contextdependent and varies according to the specific use case. However, we will set lower bounds on acceptable response time as well as data rates for internal communication interfaces in the TEE HAL product requirements we will provide at the end of the project. Design constraints The ELASTIC TEE HAL configuration has been defined based on the test cases. The main goal is to support the ELASTIC two demonstrators using a generic and extensible architecture. It is also derived with just two TEEs within scope. Future extensions shall be straightforward though with the selected design approach. Standard compliance The TEE HAL interface will follow the principles and recommendations as used by the WASI subgroup of the W3C standard 68 . The functions identified in this specification are independent of the WASI standard interface. However, whenever an appropriate function is already adopted by WASI, we have chosen to incorporate it also for the TEE HAL. The WASI is a living standard, and the most developed functions are currently in the “implementation” phase 69 . Verification The TEE HAL will be verified once the specification is complete through a reference implementation. The reference implementation will be tested on at least two different TEEs, AMD SEV-SNP and Intel TDX, and the verification will take place by at least two different ELASTIC partners. Test scripts will be shared between partners but not released. 5.3 HAL Architecture The HAL architecture follows the common principle of the WASI as defined by the Bytecode Alliance 70 . WASI can be implemented using both core Wasm modules and modules built according to the so-called “component model”. The latter model is a way to build Wasm binaries with wrappers that allow interoperable function passing between different Wasm 68 WASI W3C subgroup, https://wasi.dev 69 https://github.com/WebAssembly/WASI/blob/main/Proposals.md 70 [2408.00443] An Experimental Evaluation of TEE technology Evolution: Benchmarking Transparent Approaches based on SGX, SEV, and TDX ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 56 - August 31, 2025 applications. WASI as defined by the Bytecode Alliance is currently in stage WASI 0.2. This latest release uses the component model, which is considered the future WASI model. Hence, a component model should be used for implementations claiming ELASTIC TEE HAL compliance. WASI can be used on different TEEs. However, the ELASTIC TEE HAL only supports specific implementations, such as AMD SEV, Intel TDX and ARM CCA. This restriction has been chosen as these are the dominating TEEs on the market. The TEE HAL framework is based on the generic ELASTIC architecture and its architecture is used when running ELASTIC Wasm workload on TEEs. Figure 10 gives an overview of the TEE HAL architecture. Figure 10. The TEE HAL architecture. The TEE HAL needs to be supported with a compliant Wasm runtime in the TEE. This specification does not mandate any specific runtime, but the ELASTIC TEE HAL reference implementation will be based on Wasmtime 71 , which is also the runtime used by the Enarx project 72 . Wasmtime has been chosen due to its wide support. This means that the ELASTIC TEE HAL-compliant Wasm workload will use the standard Wasmtime principles with the correct bindings to the unique ELASTIC TEE HAL functions. However, when using the WASI 0.2 functions of the ELASTIC HAL, the standard bindings will be used, and no particular ELASTIC adaptations need to be done. The ELASTIC TEE HAL is based on two specific components, which are the TEE hardware platform and the WASI-based runtime. 71 https://github.com/bytecodealliance/wasmtime 72 https://enarx.dev/ ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 57 - August 31, 2025 TEE hardware platform The ELASTIC HAL is TEE agnostic, but each runtime that implements the HAL needs to be carefully adapted to the specific TEE platform. The ELASTIC HAL reference implementation supports only two TEEs, the AMD SEV-SNP and the Intel TDX. Wasm Runtime Any Bytecode Alliance 73 -compatible runtime can be used to implement the ELASTIC HAL. Some runtimes require considerably more effort to be compliant with this HAL specification. The ELASTIC HAL reference implementation is based on the Enarx open-source project with Wasmtime as the runtime. 5.3.1 Implementation Considerations The ELASTIC HAL will be based on WASI 0.2 as a baseline. This implies that the Bytecode Alliance component model must be used for implementing and using the ELASTIC HAL. Consequently, the interface functions will be specified using the standard “.wit” file format. All implementations claiming ELASTIC HAL TEE compliance need to support the defined “.wit” interfaces. This specification does not define the “.wit”-interfaces but the ELASTIC HAL functions (see next Section), which, as they are already part of WASI 0.2, reference the standardised interfaces and the corresponding “.wit” definitions. The ELASTIC HAL-specific interface functions, including “.wit” definitions, will be released as part of the ELASTIC HAL reference implementation. 5.4 HAL Interfaces Specification This section contains the ELASTIC TEE HAL interface functions. The interfaces follow the Bytecode Alliance WASI 0.2 specifications with suitable extensions to cover the requirements identified in Section 5.2. The interface specifications list the included functions and their motivations. The actual interface is specified with .wit files as part of the ELASTIC HAL reference implementation. Each function is specified with a reference to the requirement(s) it supports. The requirements are referenced using the requirements numbering defined in Section 5.2. The last column in the interface lists refers to the WASI 0.2 support. Some functions have a draft WASI version, versions are indicated as “proposed” or “no”. Proposed or draft WASI interfaces will be used whenever they are suitable, which is based on further evaluation when the detailed interfaces in the ELASTIC TEE HAL are defined/implemented. This specification covers all the HAL functions needed to support the deployment scenarios. Not all of them are supported by the ELASTIC TEE reference implementation. The reference implementation only covers the most important/high priority functions. This allows the reference implementation to be the basis for research evaluations and to support the ELASTIC demonstrator. Future extensions of the reference implementation are envisioned in the future, beyond the end of the project. The interfaces are described on a generic level. The HAL is expected to be of the traditional request-response type, but it will also contain functions for setting up buffers and streams. Consequently, the interface operation will depend on the type of function it provides. The detailed operation of the different interface functions will be specified in the .wit files reference implementation. However, not all HAL functions will be provided as references. 73 https://github.com/bytecodealliance ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 64 - August 31, 2025 5.5.3 How does the Linux HAL component work? An overview of the structure of the Linux Hal is given in Figure 11 below. The HAL is combined with AMD SEV-SNP or Intel TDX to provide a fully encrypted VM that can be verified using remote attestation. QEMU and OVMF are used to boot the CVMs. During boot with SEV-SNP, the AMD Secure Processor (AMD SP) computes a hash of the VM contents and embeds it into the attestation report. This value is proof of what is currently running inside the VM. SEV-SNP is used to measure OVMF. In more detail, the vTPM is utilised to determine which kernel and file system is running in the CVM. OVMF and vTPM are loaded into memory as part of the initial CVM memory load. During this process, the SEV-SNP measures this initial memory, thereby assessing the OVMF and vTPM. The rest of the HAL, the kernel, and the initramfs are hashed, and their hashed values are used to extend the values of the Platform Configuration Registers (PCRs) of the vTPM. The OVMF calculates the hash of the kernel and uses it to extend the value of PCR4. Then, the kernel calculates the hash of the initramfs and the kernel command line and uses these values to extend the value of PCR9. The content of the PCRs is trusted because the vTPM is running inside the CVM and in layer VMPL0. The whole HAL configuration is presented in the following diagram. The green colour represents the trusted part of the system, while the red represents the untrusted part. Figure 11. HAL Configuration 5.6 ELASTIC TEE HAL conclusions In this section, we have described the process for identifying the proper TEE HAL architecture, functions to support, and implementation recommendations. We have taken a well-proven engineering approach to the problem, starting with identifying use cases, which we refer to here ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 65 - August 31, 2025 as deployment scenarios. The deployment scenarios were selected based on the ELASTIC demonstration use cases, with some additional cases covering additional aspects of usage in the automotive domain. Using a well-proven requirements engineering approach following the IEEE 29148 framework, we have then derived ELASTIC TEE HAL requirements. We have evaluated different architecture options for the TEE HAL and chosen an architecture in alignment with the overall ELASTIC architecture as defined in D1.1. Using this architecture, we specified the TEE HAL interface functions and showed how they cover the previously identified requirements. The detailed specification of the functions is not given in this document but is part of the ELASTIC TEE HAL reference implementation. Finally, the TEE HAL interface functions as such are not enough to provide a fully working TEE solution running Wasm, but additional implementation aspects are needed in order to realise a working solution. In the last part of this section, we described how such fully working solutions can be provided using a Linux HAL component. Altogether, the provided specification gives the prerequisite for the continued development of secure deployment and running of sensitive Wasm workloads on different TEEs currently available on the market. As the requirements process is also extensively documented, it can easily be extended to support additional deployment scenarios and to derive new requirements aligned with the old requirements. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 66 - August 31, 2025 6 Remote Attestations Remote attestation enables parties to establish a high level of confidence, as far as the trustworthiness of remote peers. Remote attestation is a fundamental security technique that allows a remote party (the verifier), to assess the trustworthiness of a system component (the attester), by obtaining cryptographic evidence about its identity, configuration, and integrity. This evidence is typically generated from hardware roots of trust, such as Trusted Platform Modules (TPMs) or Trusted Execution Environments (TEEs) and is crucial for establishing trust in distributed and cloud-native environments. For network exchanges, one entity often needs to assess the trustworthiness of a remote peer before establishing a connection with it and authorising the access to its API. This is particularly critical in cloud and distributed systems, where connections span from the core to the edge and extend to far-edge devices within a cloud continuum. In these environments, entities establish dynamic connections with peers across diverse security domains that are not known a priori, which is a characteristic of zero-trust environments. 6.1 Background The IETF Remote ATtestation ProcedureS (RATS) working group defined a standardised architecture and procedures for interoperable remote attestation across diverse platforms and use cases. The RATS standard specifies roles such as Attester, Verifier, and Relying Party, and formalises the process where the Verifier appraises attestation Evidence from the Attester to produce an Attestation Result, which the Relying Party then uses to make trust decisions. Even though the Remote Attestation procedure itself is standardised, the used TEEs forming the Hardware Root of Trust differentiate concerning the measurement they take on the Attester and the evidence that is provided to the Verifier. As a consequence, the used hardware platform impacts the remote attestation procedure. The following sections describe the state-of-the-art remote attestation procedure as specified by IETF, the attestation procedure done by TEEs and the remote attestation as part of a software stack to ensure compatibility and interoperability with other systems. Additionally, the role and applicability of lightweight protocols tailored for the IoT domain are assessed, along with a description of possible architecture options and their current realisations to support the goal of abstraction and broader trust enablement. 6.2 IETF Remote ATtestation procedureS (RATS) IETF - RATS defines a standardised architecture and protocols to enable remote attestation, allowing devices to prove their integrity and trustworthiness to remote parties in an interoperable way. It specifies roles (Attester, Verifier, Relying Party, etc.) and processes for exchanging and evaluating evidence of device state. 6.2.1 RATS Architecture and its Protocols IETF has defined an architecture for remote attestation including the various roles within Remote Attestation in its specification (RFC 9334 77 ) and the associated procedures and protocols to convey evidence for appraisal to a verifier and attestation results to a relying party 77 H. Birkholz, D. Thaler, M. Richardson, N. Smith, and W. Pan, "Remote ATtestation procedureS (RATS) Architecture," RFC 9334, Internet Engineering Task Force, Jan. 2023, doi: 10.17487/RFC9334. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 67 - August 31, 2025 within the draft specification “The Reference Interaction Models for Remote Attestation Procedures” 78 . 6.2.1.1 RATS Architecture The IETF RFC 9334 defines an architecture for the remote attestation that is depicted by the Figure 12: Figure 12. Conceptual Data flow (IETF RFC 9334) Attester The attester is an entity that creates the evidence that is conveyed to a Verifier. It consists of at least one attesting environment and at least one target environment. The Figure 13 shows the two types of environments within an attester: 78 H. Birkholz, M. Eckel, W. Pan, and E. Voit, "Reference Interaction Models for Remote Attestation Procedures," InternetDraft draft-ietf-rats-reference-interaction-models-14, IETF, Feb. 2025. [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-rats-reference-interaction-models/ ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 68 - August 31, 2025 Figure 13. High-level architecture of an attester (IETF RFC 9334) The Attester is an entity responsible for generating and signing a collection of Claims known as Evidence regarding its running environment(s). This Evidence serves to demonstrate the state or trustworthiness of the device. The architecture defines two principal types of environments co-located within the Attester entity: ● Attesting Environment: This environment collects Claims and generates the signed Evidence and conveys it to the Verifier. ● Target Environment: This is the environment about which the Evidence is gathered. In some implementations, Target and Attesting Environments can be combined or multiple such environments may exist in layered or composite forms. The claims collected by the Attesting Environment from the Target Environment are in general measurements and information of the Target Environment which finally are suited to prove trustworthiness when composed to the Evidence. Such information and measurements can be collected by reading some system registers, calling into subsystems or by measuring some assets such as code, memory or other characteristics of the Target Environment. The Attesting Environment then generates the Evidence by formatting the collected claims and by using key material and cryptographic functions for ciphering and signing. An attester may be layered and in this case consists of one or more nested environments, and consists of a cascade of staged environments. The environment of layerx has the responsibility of measuring the next environment of layerx+1 before the environment of layerx+1 is started, this process allows the establishment of a robust trust chain throughout the layers. As a consequence the bottom layer (Layer0) of such attester has an attesting environment that is immutable and trusted by the verifier and referred to as “root of trust”. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 69 - August 31, 2025 There could also be an environment that is a composite entity composed of multiple subentities. Each entity has an attester generating the evidence of its trustworthiness. Among these attesters, only one or more communicate with the verifier, the lead attester. The lead attester collects the evidence of all attesters and generates evidence about the whole composite entity. Verifier The verifier uses ● the Evidence provided by the attester, ● the reference values provided from reference value providers, ● Endorsements provided from endorsers and, ● Appraisal policy for Evidence provided by the verifier owner to assess the trustworthiness of the attester. The verifier generates the attestation results that may be used by relying parties. Relying party The relying party is an entity that uses the attestation result and applying its own policies (appraisal policies for attestation result) makes some application specific decisions. Attester in the confidential computing case In case of attestation of a confidential computing environment, there could be several implementations using: ● a simple attester when the confidential computing environment use a single workload, ● a layered attester when the confidential computing implements several VM or container of a node, ● a composite attester, when a distributed system of several VMs, containers, or other components are implemented using several confidential computing environments or non CC environments, ● a distributed attester, which collectively attests a distributed system of several VMs, containers, or other attesters. Figures 14,15, 16, and 17 below depict the different cases. Figure 14. Simple attestation of CC Figure 15. Layered attestation in CC ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 70 - August 31, 2025 Figure 16. Global attestation as a composite device Figure 17. Distributed Attestation 6.2.1.2 RATS Protocols The Reference Interaction Models for Remote Attestation Procedures are described in the draft IETF document “The Reference Interaction Models for Remote Attestation Procedures” (draftietf-rats-reference-interaction-models-13 79 )”. The document is a high-level description of the protocol used for conveying the evidence from attester to the verifier. It describes three interaction models: ● Challenge/response remote attestation ● Uni-directional remote attestation ● Streaming remote attestation 79 H. Birkholz, M. Eckel, W. Pan, and E. Voit, "Reference Interaction Models for Remote Attestation Procedures," InternetDraft draft-ietf-rats-reference-interaction-models-14, IETF, Feb. 2025. [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-rats-reference-interaction-models/ ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 71 - August 31, 2025 These interaction models may use additional trusted third parties (TTPs) such as broker and handle distributors. These interaction models between Verifier and Attester differentiate by initiating party of the attestation and whether an ongoing flow (streaming)of attestation data (Evidence) is provided. In the Challenge/Response model, the Verifier initiates the process by sending a challenge to the Attester. This challenge typically includes a nonce, a random value used to ensure the freshness of the attestation. The Attester must respond with Evidence that proves its current state in response to that specific challenge. This interaction ensures that the attestation is timely and specifically bound to the request, offering strong guarantees about the current status of the Attester and the freshness of the provided Evidence. It is an interactive procedure involving a direct challenge from the Verifier and a corresponding response. Uni-Directional Remote Attestation procedures can be initiated by the Attester or Verifier. The Attester can proactively send Evidence to the Verifier without an explicit challenge for each attestation. The freshness of this Evidence is guaranteed by external trusted mechanisms such as cryptographically signed timestamps, often provided by third parties like a Time Stamping Authority. This model supports situations where the Attester pushes attestation data independently, either on its own schedule or upon a prior solicitation, allowing for less latency and simpler, one-way communication. It is suitable when continuous or repeated attestations are needed without the overhead of a challenge-response exchange for each one but may also create overhead by unsolicited pushes of Evidence to the Verifier. The Streaming remote attestation model builds on these by enabling ongoing, subscriptionbased attestation. The Attester continuously streams Evidence to one or more Verifiers, leveraging observer or publish-subscribe messaging patterns and sometimes involving brokers to distribute messages. This approach is well-suited to scenarios requiring continuous monitoring of the Attester’s state, providing an ongoing flow of attestation data. Both the Challenge/Response and Uni-Directional models can be adapted to operate within this streaming framework, allowing for flexible deployment depending on the use case. While all these models share key attestation elements like Evidence generation, conveyance, and appraisal, they primarily differ in how freshness or validity handles are generated and used and have slight differences concerning overhead and delay. The Challenge/Response model uses a nonce provided per request, Uni-Directional relies on externally generated time-based handles, and Streaming establishes subscription states for continuous attestation updates. These models offer varied interaction patterns to meet a range of security and operational requirements for remote attestation in networked environments and either of said methods can be used for final demonstrators depending on exact circumstances. The Entity Attestation Token (EAT/ RFC9711) 80 An Entity Attestation Token (EAT) is a message made up of claims about an entity, e.g., a target environment in an attester. This claims set is used by a relying party, server or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestationoriented claims. The hierarchies induced by a layered attestation and composite devices are modelled using a nesting of EATs and of claim-sets. 80 L. Lundblade, G. Mandyam, J. O’Donoghue, C. Wallace, and M. Richardson, "The Entity Attestation Token (EAT)," RFC 9711, IETF, Apr. 2025. [Online]. Available: https://www.rfc-editor.org/info/rfc9711 ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 72 - August 31, 2025 This document defines some common claims that are potentially of broad use and is extensible to allow also proprietary claims or further claims to be standardised. The Entity Attestation Result (EAR, draft-ietf-rats-ear) 81 The Entity Attestation Result (EAR), is a message format used by a verifier to encode the outcome of an appraisal performed on an attester's evidence. EAR includes an embedded AR4SI "trustworthiness vector" that contains further evaluation results, simplifying the definition and enforcement of authorisation policies by relying parties. The EAR is either a CWT or a JWT. EAR supports simple devices with a single attester and composite devices with multiple attesters, enabling separate examination of each attester's state. This document defines some mandatory claims such as the verifier identity, issuance time, and appraisal status, but also optional fields like raw evidence and user-supplied nonces for freshness. 6.2.2 Remote Attestation functionality in hardware 6.2.2.1 AMD SEV-SNP (x86) AMD SEV-SNP (Secure Encrypted Virtualisation - Secure Nested Paging) characteristics and Remote attestation specifics for AMD SEV-SNP are listed in section 4.2.2 of this document. Protocols & Verification ● Evidence Generation: The attestation report, which serves as cryptographic evidence, is acquired from the CPU. This process typically involves hypervisor APIs, and opensource tools like QEMU and KVM support launching AMD SEV-SNP VMs and facilitating this evidence acquisition. AMD has upstreamed its patches for Linux kernel (version 6.11 and later) and QEMU (version 9.1 and later) to support confidential VM launching. The AMD Secure Processor (ASP), also known as Platform Security Processor (PSP), a closed-source ARM TrustZone-based co-processor, is internally responsible for creating, monitoring, and maintaining the security environment and plays a role in the attestation process. o The guest VM requests an attestation report by issuing an SNP_GUEST_REQUEST_REPORT instruction. o The request includes a user-supplied nonce to guarantee freshness and may include additional runtime data (e.g., measurements). o The Secure Processor returns a binary attestation report, signed with AMD’s device-specific key. o The VM sends the report to the remote verifier. ● Attestation Report Structure: The SEV-SNP attestation report is a binary structure containing fields such as Version, Guest SVN, Policy, Family ID, Image ID, VMPL, Signature algorithm, Current TCB, Platform info, Report data (CVM-provided data), Measurement (hash of initial guest memory), Host data, ID key digest, Author key digest, Report ID, Chip ID, Committed TCB, Current/Committed Build/Minor/Major firmware versions, Launch TCB, and the Signature of the report. 81 T. Fossati, E. Voit, S. Trofimov, and H. Birkholz, "EAT Attestation Results," Internet-Draft draft-ietf-rats-ear-00, IETF, Apr. 2025. [Online]. Available: https://datatracker.ietf.org/doc/html/draft-ietf-rats-ear-00 ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 73 - August 31, 2025 ● Verification: Verification of the attestation report can be performed using various tools and services. The report's signature and the TCB are verified using a Versioned Loaded Endorsement Key (VLEK) or a chip-unique Versioned Chip Endorsement Key (VCEK). The VLEK, when used, is signed by AMD's certificate chain (AMD SEV Key (ASK) and AMD Root Key (ARK)), which is available from the AMD Key Distribution Service. Tools such as the sev library 82 or snpguest tool 83 can be used for VLEK acquisition and report verification. Furthermore, frameworks like the Trustee project also support the verification of SEV-SNP reports with VLEK keys by default. o The verifier uses AMD’s ARK and ASK certificate chain to validate the report signature and verify platform integrity and configuration. o The report allows a verifier to validate platform authenticity (via AMD certificate chain), guest integrity (via the measurement field), freshness (via report_data containing a hash of the verifier’s nonce), configuration policy, and key binding (binding the measurement to a public key for secure communication). 6.2.2.2 Intel TDX (x86) With Intel TDX, the attester is a Trusted Domain (TD), i.e., a hardware-isolated VM 848586 . The evidence generated and verified is called a TD quote. Quote generation Within the platform, the attestation procedure consists of generating a local report with measurements of the TD and then converting the report to a signed quote, which is the evidence a remote verifier can appraise. Several trusted components within the platform participate in this procedure. Firstly, a challenger (e.g., a relying party) requests a TD (attester) to attest itself. The TD requests a report from the platform’s Intel TDX module (via a specific TDCALL), which in turn requests a report from the CPU HW (via a SEAMREPORT instruction). The report contains input data provided by the TD (REPORTDATA; e.g., a nonce from the challenger), measurements of the TD (e.g., from its build (MRTD) and boot/execution (RTMR)), and Security Version Numbers of elements in the TCB. This report is signed with a Hashed Message Authentication Code (HMAC) using a key only available to trusted components within the same CPU, and is returned to the TD. Secondly, the TD requests the platform’s TD Quoting Enclave (TDQE) to create a signed quote from the report (e.g., via another TDCALL or socket). The TDQE requests the CPU to verify the signature of the report (via the EVERIFYREPORT2 instruction), and if the verification is successful, it converts the report to a Quote by signing it with an Attestation Key (AK). The signed quote is returned to the TD, which sends it to the challenger. As a prerequisite to the steps above, the TDQE has generated the AK certificate used for signing quotes. The AK, in turn, is bound to the Provisioning Certification Key (PCK) by the platform’s Provisioning Certification Enclave (PCE) provided by Intel. The PCK X.509 certificate is 82 https://github.com/virtee/sev 83 https://github.com/virtee/snpguest/ 84 https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/documentation.html 85 https://download.01.org/intel-sgx/sgx-dcap/1.23/linux/docs/Intel_TDX_DCAP_Quoting_Library_API.pdf 86 https://dl.acm.org/doi/pdf/10.1145/3652597 ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 80 - August 31, 2025 o A teeNonce is provided by the client to ensure freshness and prevent replay attacks. o The SEV-SNP report is obtained by interacting with the underlying hardware, while the vTPM quote is fetched from the virtual TPM. ● Verification (Centralised Verification Model): Azure uses the Microsoft Azure Attestation (MAA) service as a centralised attestation verifier. The MAA service validates attestation reports and issues signed JWT tokens containing security claims. o Service Submission: Combined report parameters are generated and submitted to a MAA service endpoint. MAA validates the report against Azure's known configurations. o Token Verification: MAA returns a signed JWT token containing security claims. Token validation involves retrieving the MAA public key set and verifying the token signature to ensure authenticity and integrity. o Token Claims Structure: The MAA token contains security-relevant claims within the x-ms-isolation-tee namespace, including hardware identity claims (xms-sevsnpvm-familyId, x-ms-sevsnpvm-imageId, x-ms-sevsnpvmlaunchmeasurement), security version claims (x-ms-sevsnpvm-bootloader-svn, x-ms-sevsnpvm-tee-svn, x-ms-sevsnpvm-snpfw-svn, x-ms-sevsnpvmmicrocode-svn), and runtime security claims (x-ms-sevsnpvm-guestsvn, x-mssevsnpvm-idkeydigest, x-ms-sevsnpvm-reportid). o Policy Generation: Attestation policies are dynamically generated from validated MAA token claims, encompassing image identity, launch measurement, security versions, key validation, report correlation, and TCB composition. ● Integration with Lightweight Confidential Computing Platform: ELASTIC will utilise the vTPM feature of Azure CVMs for runtime measurements, adhering to the TPM 2.0 specification and providing measured boot verification based on the trusted launch feature of Trusted Launch VMs. While Azure does not provide direct access to OVMF files or images, it offers its MAA service for attestation verification. Azure's confidential computing aims to provide enhanced data protection for workloads in the cloud by ensuring that data remains encrypted and isolated during processing. By leveraging hardware-backed TEEs, Azure helps customers meet stringent regulatory and compliance requirements for sensitive data, reducing the attack surface from cloud operators and privileged insiders. Integration with projects, like Trustee, further emphasises its commitment to interoperability and robust attestation in the broader confidential computing ecosystem. Azure's VMGuestStateOnly encryption and virtual TPMs contribute to establishing a verifiable trusted execution environment. 6.2.3.5 AWS AWS supports Nitro Enclaves as well as AMD SEV-SNP Confidential VMs 94 in EC2. In the latter case, attestation is based on the normal SEV-SNP attestation workflows and attestation report structure 95 , and the report is acquired from the CPU (e.g., via the /dev/sev-guest 94 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sev-snp.html 95 https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56860.pdf#page=56 ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 81 - August 31, 2025 device or configfs-tsm in Linux CVMs). The certificate used for verifying the signature and TCB of the attestation report is, however, a Cloud Service Provider-specific Versioned Loaded Endorsement Key 96 (VLEK) rather than a chip-unique Versioned Chip Endorsement Key (VCEK). The VLEK certificate can be acquired from the CPU in a similar way as the report. The VLEK is signed with AMD’s certificate chain (AMD SEV Key (ASK) and AMD Root Key (ARK)) available from the AMD Key Distribution Service. In SEV-SNP guests, attestation report and VLEK acquisition, as well as their use for report verification, can be performed using tools such as the sev library or the snpguest utility. Verification of SEV-SNP reports with VLEK keys is natively supported, for example, by the Trustee framework. Currently the Measurement field in reports from AWS EC2 SEV-SNP instances contains a measurement of the CVM’s Open Virtual Machine Firmware (OVMF), i.e., the UEFI environment 97 provided by AWS. The reference value for the measurement can be calculated from an OVMF firmware image by using, e.g., the sev-snp-measure 98 tool. To measure also, e.g., the operating system, further attestation procedures based on NitroTPM quotes need to be used 99 . 6.2.3.6 Google Cloud Platform Google Cloud Platform (GCP) offers Confidential Computing as a service, leveraging hardware-based TEEs to protect data in use. GCP's approach to confidential computing is primarily built around Confidential VMs, which are encrypted virtual machines designed to keep data encrypted in memory and in transit between the VM and other services. Supported TEEs and Integration GCP's Confidential VMs utilise AMD SEV technology. Specifically, they run on AMD EPYC processors with SEV, which encrypts the entire VM's memory, providing a hardware-backed isolation boundary. This ensures that data remains encrypted even when processed by the CPU, protecting it from the cloud provider, hypervisor, and other VMs on the same host. Additionally, GCP is expanding its confidential computing offerings to include support for TDX in certain regions and instance types, providing another hardware-backed TEE option for users. Lightweight Confidential Computing Platform deploys confidential computing workloads on GCP utilising AMD Milan-based N2D instances with SEV-SNP for memory encryption and integrity protection. The TEE management agent operates within these CVMs, fetching attestation reports and executing secure computations. Attestation Mechanisms GCP's Confidential VMs employ attestation to verify the integrity and authenticity of the confidential environment. ● Evidence Generation: The attestation evidence for GCP Confidential VMs is generated by the underlying AMD SEV hardware. This evidence includes cryptographic measurements of the VM's initial state, such as the bootloader, kernel, and initial configuration. These measurements are signed by the AMD Secure Processor (PSP), 96 https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/user-guides/58369-010-versioned-loadedendorsement-key-certificate-definition.pdf 97 https://github.com/aws/uefi 98 https://github.com/virtee/sev-snp-measure 99 https://github.com/aws/uefi/issues/13 ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 82 - August 31, 2025 which acts as a hardware root of trust. The CVM generates a SEV-SNP attestation report and a vTPM quote. Both teeNonce and vTpmNonce are provided to ensure freshness. The vTPM quote is fetched by opening a connection to the TPM device (/dev/tpmrm0 or /dev/tpm0), and the TPM attestation key is used to retrieve the quote, including PCR values and event log. The SEV-SNP report is fetched directly from the guest environment. ● Verification: The attestation report (evidence) generated by the AMD SEV hardware can be verified by a relying party. This verification process typically involves: o Signature Validation: Verifying the digital signature on the attestation report using AMD's public keys to ensure its authenticity and that it originated from a genuine AMD SEV platform. o Measurement Appraisal: Comparing the measurements contained in the report against known good (reference) values. These reference values represent the expected and trusted configuration of the Confidential VM. Any deviation indicates a potential compromise or unauthorised modification. o Freshness Verification: The attestation report includes a nonce or challenge provided by the relying party, ensuring that the report is current and not a replay of a previous attestation. ● GCP provides mechanisms and APIs to facilitate this attestation process, allowing users to verify the integrity of their confidential VMs before deploying sensitive workloads. This enables a "zero-trust" model, where users can cryptographically verify the trustworthiness of the cloud environment. The vTPM quote's signature is verified by the AK public key. PCR values within the quote are checked against expected golden values, and the event log is replayed to ensure consistency with PCR values. The SEV-SNP attestation report is verified against policy parameters. GCP's OVMF file, while closed source, can be downloaded, and it uses standard Linux distributions, allowing verification of attestation report values against the OVMF file and Linux distribution. Trusted Platform Module (TPM) Cocos AI uses the vTPM feature of CVMs on GCP for runtime measurements. This vTPM, although emulated by the hypervisor and not running inside the hardware-protected CVM context, adheres to the TPM 2.0 specification. It provides a launch attestation report based on the measured boot feature of Shielded VMs. Cocos AI leverages Linux Integrity Measurement Architecture (IMA) to ensure comprehensive file system integrity on GCP Confidential VMs. While IMA offers an appraise feature, Cocos AI adopts a local verification approach. This is because many public cloud providers offer images without pre-calculated file measurements, which could prevent the VM from booting if kernel-enforced appraisal were used. Instead, Cocos AI's in-VM agent fetches the current IMA measurement log. A CLI tool can then request this data and combine it with TPM PCR 10 values (or quotes). Verification is performed in user space, either locally or by forwarding to a remote attestation service. This design avoids boot failures on images without built-in measurements, while still leveraging IMA’s tamper-evident logs for post-boot integrity checking. Linux IMA is enabled through grub command line arguments, specifically ima_policy=tcb. On VM startup, Cocos AI applies a configuration file that changes the grub command line by editing /etc/grub/default/ file. After updating grub, the VM is rebooted to activate the IMA kernel feature. To ensure every file on the filesystem is measured, Cocos AI uses a command ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 83 - August 31, 2025 that accesses each file without reading its contents, triggering IMA measurement. All files in the system are measured, and their measurements are stored in the /sys/kernel/security/integrity/ima/ascii_runtime_measurements file. Key Features ● Memory Encryption: All data in the VM's memory is encrypted with a dedicated perVM encryption key, which is generated and managed by the hardware and never leaves the CPU. ● Data Integrity: AMD SEV-SNP, which is an enhancement to SEV, provides integrity protection for the VM's memory, preventing unauthorised tampering. ● Simplified Deployment: Confidential VMs are designed to be easy to deploy and manage, integrating seamlessly with existing Google Cloud services and workflows. ● Compliance and Security: By offering strong data-in-use protection, GCP's Confidential Computing helps organisations meet stringent regulatory and compliance requirements for sensitive data. ● No Code Changes: Applications can run in Confidential VMs without requiring any code modifications, simplifying the migration of existing workloads to a confidential environment. Integration with the ELASTIC Framework For the ELASTIC project, the integration with Google Cloud Platform's Confidential Computing capabilities would involve leveraging its AMD SEV-SNP based Confidential VMs. The ELASTIC HAL would abstract the underlying TEE specifics, allowing Wasm workloads to run securely and portably on GCP. The remote attestation mechanisms provided by GCP, augmented by Cocos AI's integration with vTPM and Linux IMA, would be crucial for verifying the integrity of the ELASTIC Wasm runtime and the deployed applications, ensuring that the confidential computing guarantees are maintained within the GCP environment. This aligns with ELASTIC's objective of providing a privacy-preserving, architecture-agnostic, efficient, and secure execution environment. 6.2.3.7 Linux configfs-tsm configfs-tsm 100 provides a common platform-agnostic kernel ABI for, e.g., generating attestation reports (i.e., evidence) in Linux VMs. This file-based ABI is included in the Linux kernel starting from kernel version 6.7, and is currently available with AMD SEV-SNP, Intel TDX, and Arm CCA VMs. This ABI does not address evidence verification. A simple example of generating a new report with configfs-tsm: A new subdirectory for a report is first created under /sys/kernel/config/tsm/report/ in the VM attesting itself, input data for the report (e.g., a hash of a nonce) is then written to a file named inblob in that subdirectory, and the corresponding report (in a platform-specific format) can subsequently be read from a file named outblob. 6.2.3.8 VERAISON Project VERAISON 101 is an open source framework for building an attestation verification service based on the IETF RATS architecture and data formats specified in the IETF RATS working group. 100 https://github.com/CCC-Attestation/meetings/blob/main/materials/SamuelOrtiz_LinuxKernelAttestationABI.pdf 101 https://github.com/veraison ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 84 - August 31, 2025 VERAISON includes functionality for provisioning endorsements and trust anchors as CoRIM 102 (Concise Reference Integrity Manifest) tokens, and verifying evidence and producing corresponding results in the JWT/CWT-based EAR 103 (EAT Attestation Result) format, and related libraries and tools. Attestation Schemes define the evidence token structure, expected endorsements and trust anchors, and how evidence is appraised. VERAISON currently implements support for Arm CCA, PSA IoT, RIoT DICE, TPM EnactTrust, Parsec TPM, and Parsec CCA attestation schemes. Schemes are implemented as Go plugins. VERAISON can also use OPA policies for making further appraisal decisions and insert claims to results after evidence has been processed by an Attestation Scheme. The overall architecture of VERAISON is shown in Figure 20. VERAISON exposes REST endpoints for provisioning endorsements & reference values (Provisioning) and policies (Management) and for submitting evidence for verification (Verification). Internally, gRPC is used for communication between components. Figure 20. Veraison Architecture 6.2.3.9 Trustee The Trustee 104 project contains components for attesting confidential guests and delivering secrets to them. It originates from the Confidential Containers project but can be applied also in other contexts. Trustee supports a variety of TEE hardware platforms. Trustee includes an Attestation Service (AS) for verifying attestation evidence, as well as a Reference Value Provider Service (RVPS) for managing reference values and a Key Broker Service (KBS) for provisioning of secrets. The input to the Attestation Service is platform-specific evidence, e.g., from an Attestation Agent 105 inside a guest (typically a TEE, which acts as an attester). The AS outputs attestation results as JSON Web Tokens, which can be used by the KBS or other Verification Demanders (i.e., relying parties). The AS can currently verify evidence from Intel TDX (as-is or with vTPM on Azure), Intel SGX, AMD SEV-SNP (as-is with VCEK or VLEK keys, or with vTPM on Azure), ARM CCA, Hygon CSV, and IBM Secure Execution (SE). In the verification process, the AS: 102 https://datatracker.ietf.org/doc/draft-ietf-rats-corim/ 103 https://datatracker.ietf.org/doc/draft-fv-rats-ear/ 104 https://github.com/confidential-containers/trustee 105 https://github.com/confidential-containers/guest-components/tree/main/attestation-agent ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 85 - August 31, 2025 1. Verifies the signature of the evidence and resolves the evidence into JSON claims (e.g., about the TCB status) in a platform-specific Verifier Driver. 2. Evaluates the claims, such as measurements, in the evidence against Open Policy Agent (OPA) policies (in a Policy Engine) and reference values (queried from the RVPS). The IDs of policies to evaluate are included in attestation requests, and the corresponding results are included in the output token. An overview 106 of the interaction between the Verification Demander and Attestation Service is shown in Figure 21: Figure 21. Trustee Attestation Service overview Trustee’s Attestation Service can be used over REST or gRPC APIs or as a library (Rust crate). The Policy Engine and Verifier Drivers are part of the AS, whereas the RSVP component can either be built into the AS or run separately, in which case it is used by the AS via gRPC. Integration of VERAISON as a backend to Trustee has been proposed 107 . 6.3 HAL for Remote Attestation mechanisms Giving the roles for the remote attestation procedure as outlined in 6.2.1 typical remote attestation flows include the following steps: ● The Verifier (or sometimes even via relying party) may initiate the attestation by sending a request to the Attester. A nonce is included in said request for freshness to prevent replay attacks. ● The Attester collects the requested claims and generates the Evidence, which it sends back to the Verifier along with event logs including the nonce. ● The Verifier appraises the Evidence, using endorsements (trusted assertions about the Attester's keys or identity) and reference values (expected measurements or configurations). ● The Verifier produces Attestation Results and sends them to the Relying Party. ● The Relying Party applies its policies to the Attestation Results and makes a trust decision. The diagram below (Figure 22) shows the attestation flow between Verifier and Attester shown in the ELASTIC architecture. 106 https://github.com/confidential-containers/trustee/tree/main/attestation-service 107 Attestation Everywhere – OC3 2025: https://www.youtube.com/watch?v=c4lyaG-lTug ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 86 - August 31, 2025 Figure 22. Attestation flow between Verifier and Attester in the Elastic architecture framework The underlying HW module performs the measurements and collects the claims i.e., computing HASH and stores the measurements. The quoting enclave takes the measurements, composites data for evidence and signs it with the attestation key. The evidence and associated nonce are transferred to the Verifier, potentially via a secure runtime or interface (for example, a WASIenabled runtime if running in a WebAssembly environment). As it can be seen from the above figure, the remote attestation HAL implementation may be needed at both sides, i.e., in the Attester in accordance with the overall Elastic architecture but also on the Verifier side. The different hardware platforms (Intel SGX, AMD SEV, RISC-V Keystone) collect the measurements and create the evidence for remote attestation in slightly different ways, containing different information within the evidence and collected claims. Means each of the attestation platforms and their flow and formats has its nuances, but the core principles of measurement, signed report generation, and cryptographic verification are common. This procedure is going to be used for abstracting remote attestation for the various TEE HW modules and SW stacks to achieve a unified remote attestation framework considering HAL. The different hardware TEEs, and the way they act for remote attestation is outside the scope of ELASTIC and they can in general not be modified for security reasons. Hence, they need to be considered and taken as provided by the corresponding Hardware platform provider. This means for the HAL abstraction layer especially with respect to remote attestation implementations need to be realised at both ends, i.e., at the Attester and the Verifier in order to achieve unified remote attestation framework for the different HW TEEs. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 87 - August 31, 2025 Even though implementation for remote attestation abstraction from the different TEEs used, may need to be performed at both sides of the implementation, effort spent at each side may vary depending on actual solution realised. One solution already partially realised acquires all necessary information related to underlying hardware used within the Attester, provides this together with the Evidence to the Attestation Verifier, where based on additional information a corresponding Attestation Module within the Verifier can be instantiated for attestation. This approach and more detailed description will be described in the following section. However, a remote attestation HAL architecture is also being considered, which would entail additional effort on the HAL within the Attester. The evidence provided from different TEEs could be wrapped into a general evidence provisioning container, transferred to the verifier, where the evidence is unwrapped and based on original evidence the verifier could approach the related trust authority for performing the actual attestation. The potential architecture is under investigation and will be described in a later version of WP3 deliverables, i.e., D3.3. From the current perspective, further solution envisions introducing standardised and unified APIs at the HAL layer, providing a consistent and formally specified interface for attestation evidence collection and quote generation on the Attester side, as well as evidence appraisal and verification on the Verifier side regardless of the underlying TEE technology. This approach would support different TEEs accommodating their diverse measurement and evidence formats within a single abstraction. Such standardised and unified APIs would enable developers to integrate remote attestation capabilities more easily across heterogeneous software stacks, reducing the need for custom integrations per platform. Defining such APIs could support pluggable TEE modules, improve portability, and accelerate the adoption of a unified remote attestation framework, while ensuring consistency and interoperability for both Attester and Verifier components involved in the remote attestation process. 6.4 Security and Robustness Enhancement of the Attestation Mechanism While TEEs provide reliable and trustworthy attestation mechanisms for systems that are contained within the boundary of a single machine, attestation of distributed systems is less straightforward in contrast with simple and layered attestation., A single attestation can prove the trustworthiness of one or several applications respectively while a single distributed application may require many attestations in order to prove its trustworthiness. Not only must each component of the application attest itself individually to the client, but it must also attest that it forms part of a consistent larger structure. This significantly limits the level of security and robustness that can be achieved by attestation in real-world cloud-based systems, where the deployment of components is subject to the whim of an untrusted orchestrator. Consolidating application components into a single TEE that can provide an all-encompassing attestation is not possible, since modern cloud applications are commonly constructed from distributed microservices deployed across many nodes, possibly spanning multiple geographic regions. In such settings, verifying the integrity and configuration of the system as a whole is significantly more complex than attesting a single component. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 88 - August 31, 2025 Although some prior works 108 , 109 , 110 attempt to scale attestation to multiple devices, these solutions focus on elements of the system and do not provide assurance of the system as a whole. In practice, an application might consist of multiple components that each individually pass attestation, yet the overall configuration may be inconsistent, outdated, or even insecure. To address this gap, we propose a novel remote attestation protocol designed for distributed applications. Instead of focusing solely on individual nodes or components, our protocol enables an entire application, comprising multiple distributed, mutually distrustful components, to be attested as a cohesive unit. The final product of our protocol is an attestation manifest, which binds each application component to a long-term identity and captures the configuration of the application. The attestation manifest is a verifiable, tamper-evident representation of the application’s global state. This allows verifiers to reason about both code integrity and application structure. We demonstrate the feasibility of this protocol by implementing it using Intel SGX enclaves and Intel TDX TDs for each component and an untrusted orchestrator. The main contributions of this work include: ● A technology-agnostic distributed attestation protocol. ● A novel protocol that allows a distributed application to collectively attest its components as a unified system, rather than as independent units. ● Introduction of attestation manifest. Our system introduces the concept of an attestation manifest, enabling mutual recognition among components and system-wide consistency checks. ● Implementation with Intel SGX and Intel TDX. We implement the proposed protocol using Intel SGX and TDX to demonstrate its practicality, and evaluate the feasibility of using an untrusted orchestrator. The proposed system is presented in Figure 23 and it includes the following entities: 1. A distributed application composed of multiple components running in TEEs. 2. A client that requests the services of one of those components. The client may also be one of the components itself. 3. Optionally, an orchestrator that manages the application. The components can also selforganise. A component in our terminology refers to any self-contained part of the application that participates in its execution and attestation. Each component must have means of producing remote attestation quotes. Moreover, it should have a method of including a customised hash in the quote. The orchestrator, if present, facilitates application-wide identity association and attestation. 108 N. Asokan, Ferdinand Brasser, Ahmad Ibrahim, Ahmad Reza Sadeghi, Matthias Schunter, Gene Tsudik, and Christian Wachsmann, "SEDA: Scalable embedded device attestation", Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security (CCS), pp. 964–975, 2015 109 Mauro Conti, Edlira Dushku, and Luigi V. Mancini, RADIS: "Remote attestation of distributed IoT services", Proceedings of the 6th International Conference on Software Defined Systems (SDS), 2019. 110 Haofan Zheng and Owen Arden, "Secure distributed applications the Decent way", Proceedings of the 2021 International Symposium on Advanced Security on Software and Systems (ASSS ’21), pp. 29–42, 2021. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 89 - August 31, 2025 In our system model, the challenger is the client or the component that starts the attestation. This challenger, also, plays the role of the verifier and is presented with the final result of the attestation. Figure 23. Attestation Component Mechanism. At runtime, each attestation attests to the code of all components jointly, despite just a single interaction between client and component, no ongoing interactions between components. Each component on start up generates a key pair. Henceforth, each instance that has generated a key pair can be uniquely referred to using that key pair. At the next step, each component shares their role and the public key with the orchestrator. Each component should know the role that they play in the application so that they announce it and commit it in the first message. This step can be altered to a different form of declaration between module and orchestrator. For example, IP association can be a superior choice in some systems. The orchestrator adds the public key to manifest. When all the components have claimed a public key, the manifest is completed. Orchestrator broadcasts the manifest to all the associated components. The components first verify that the manifest matches their understanding of the application. In particular, each role of the application has been claimed by a component and their own public key is associated with the role they have chosen. Afterwards, each component's TEE performs an attestation over the identifier of its own role, as well as the manifest as a whole, e.g., by generating a hash of the concatenated two and including the hash in the report data field of an SGX or TDX attestation. This step is needed to make sure that all the components agree on what specific instances make up their application. Then, each of the components sends the generated remote attestation quote to the orchestrator. At this step, the attestation of every component is available at the orchestrator and an application-wide attestation can be formed. Finally, the attestation manifest is sent back to each component that participated in the attestation process. The component assures that the report data value is accurate. If the expected code hash of the role is provided in the pre-manifest, it can also ensure that the identities claimed agree with the generated report. This attestation manifest can be provided to clients as the application attestation. This flow is described in Figure 24. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 96 - August 31, 2025 We have so far implemented these components for verifying AMD SEV-SNP and Intel TDX evidence. Additionally, we leverage WebAssembly component signing and support HTTP access via WASI, e.g., for fetching certificates for evidence signature verification, from components when needed. Furthermore, we have integrated the ability to load these components to the Confidential Container open source project's Trustee verifier to provide a unified and extensible attestation service, offering a consistent interface for attesting across different platforms via HTTPS. Platform-agnostic verification functionality (e.g., policy evaluation, result signing) is implemented within the Trustee attestation service, whereas signature verification and checking against reference values is handled by the components. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 97 - August 31, 2025 8 Security Advancements Security is a cornerstone of the ELASTIC project, and this chapter analyses how TEEs and Wasm runtimes together ensure strong isolation and trust guarantees. It evaluates common threats and mitigation strategies, including side-channel protection, key management, and secure API exposure. The section ensures that security is not an afterthought but an integral part of the system's design. 8.1 Isolation Guarantees in a Shared Infrastructure In modern distributed systems, such as multi-tenant cloud environments, strong workload isolation is critical. ELASTIC is designed to provide robust security guarantees even when applications share the same physical infrastructure. The architecture supports both logical and hardware-enforced isolation mechanisms to protect workloads from interference, leakage, and compromise. Wasm runtimes and TEEs are ideal for running untrusted or third-party code safely by providing a sandboxed execution model preventing code from accessing host resources unless explicitly allowed. Wasm modules are useful for serverless functions supporting systems where multiple programming languages are used, allowing developers to leverage strengths of different languages for specific tasks, leading to more flexibility and efficient solutions. Wasm protects sensitive computations and data remain protected even from cloud providers and system administrators. When Wasm is used within containers or VMs, the modules are also much smaller and faster to start than containers or VMs because of reduced resource overhead. TEEs provide hardware-backed enclaves where sensitive workloads can run with strong protections against external tampering, memory inspection, or interference from privileged software layers like the host operating system or hypervisor. This ensures that both code and data remain confidential and verifiable during execution, even in hostile or untrusted environments. For workloads that do not require enclave-based execution, ELASTIC employs standard Linux process isolation features to enforce separation. Isolation extends to the system’s interaction with hardware through a portable HAL that includes Wasm runtime. The HAL mediates access to memory and I/O devices, ensuring that workloads cannot access or interfere with underlying physical resources outside their allocated context. This is particularly important in edge environments, where devices may not support full virtualisation and direct hardware access must be tightly controlled. Security boundaries in ELASTIC are further reinforced through cryptographic means. Sensitive data is encrypted both in transit and at rest, and when operating within enclaves, also while in use. Each tenant or application can be assigned its own key material, which is managed either through a pluggable key broker service or through enclavespecific provisioning mechanisms. To enhance trust and auditability, ELASTIC supports remote attestation of workloads running in secure enclaves. This allows external systems to verify the integrity, origin, and configuration of code before trusting its output or granting access. This capability is vital in shared infrastructures, where users may not have control over the physical hosts but still require verifiable security guarantees. Together, these mechanisms form a comprehensive isolation model that ensures workloads remain protected from one another, regardless of deployment scale or environment. Whether deployed in tightly constrained edge devices or large-scale multi-tenant clouds, ELASTIC enforces clear boundaries and strong security properties without sacrificing performance or flexibility. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 98 - August 31, 2025 8.2 Mitigating Security Risks in Wasm-based Applications using TEEs Since TEEs provide HW-based isolation from the host towards applications, and Wasm provides SW-based isolation from the applications towards the host, and both also contribute to isolation between applications, the two technologies can be used for complementing each other. For example, TEEs can help with dealing with the residual risk of a break-out from a Wasm sandbox to the host, by preventing access to other applications on that same host even in such a scenario. The remote attestation functionality of TEEs can significantly enhance the security of Wasmbased applications in a server-side context, where the scale of applications naturally results in them being spread across several physical machines. This creates a need to establish trust between Wasm components and runtimes across machine boundaries, something that can be achieved effectively with the use of TEEs and remote attestation in a way that eliminates the need for trust in operating system code or the orchestration platform. 8.3 Secure Key Management and Cryptographic Protections Cryptographic protection is used within Remote Attestation to ensure uniqueness and originality of the evidence collected in the Attester when transferred to the external verifier. Furthermore the signing with the attestation key ensures that the verifier can validate that a trusted TEE was used for collecting the evidence. In addition the usage of a Key Broker Service for encryption of sensitive workload during transport is an important functionality related scenarios which are standardised and described in ETSI NFVSec026 114 where the Key Broker acts as the Relying party within the RATS architecture. In ETSI NFVSec026 the key hierarchy for protection of data in transit and Transparent Encryption Architecture is explained in detail. Transporting sensitive Wasm workload from one Cloud to another Cloud in encrypted form is often used. Prior transfer the key is released from the key broker service to encrypt the Wasm workload and hence the workload is secured during transport. After transfer the Remote Attestation Platform (the verifier) receives the attestation measurement done by the Attester. The Remote Attestation Platform (Verifier) sends the attestation result to the Key Broker Service acting as Relying party, which upon successful attestation releases the key for decrypting the Wasm workload which can be used within Public Cloud afterwards. The basic principle is depicted and realised in Demonstrator 2 and is in line with scenarios recommended for transport of sensitive workload as described in ETSI NFVSec026 when Key Brooker acts as Relying party. Besides the known usage we will explore and implement further approaches for usage, secure generation, storage, and usage of cryptographic keys to improve security in the project. Initial investigations have already shown first implementation/deployment barriers which need to be addressed within the remaining ELASTIC project time. The API to key broker service ensuring interoperability when interfacing with Verifier (i.e., interfacing via HAL etc.) needs to be addressed, as also the integrating with diverse TEEs and cloud environments. The current state-of-the-art in use is widespread and relies often on proprietary, legacy key management practices. Hence, there is future need for widespread retrieved results to 114 ETSI, "Network Functions Virtualisation (NFV) Release 5; Management and Orchestration; Architecture enhancement for Security Management Specification," ETSI GS NFV-IFA 026 V5.2.1, Dec. 2024. [Online]. Available: https://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/026/05.02.01_60/gs_NFV-IFA026v050201p.pdf ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 99 - August 31, 2025 standardisation ensuring interoperability in key provisioning and attestation protocol such as described in NFVSec026. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 100 - August 31, 2025 9 Portability and Workload Migration The existence of Wasm as an abstract compilation targets for a wide variety of languages, with well-defined interfaces designed to be genuinely independent of the underlying platform. This platform-independence allows the creation of truly serverless cloud-computing platforms that allow applications to be written once and then run anywhere, without any knowledge of the cloud service provider's concrete implementation decisions. 9.1 Seamless Migration Across Hardware Platforms The ELASTIC architecture is designed with portability and hardware abstraction at its core, enabling seamless migration of workloads across diverse platforms, i.e., from cloud servers to edge devices, and from x86 to ARM-based systems. The combination of a minimal Linux build, a Wasm runtime, and virtualisation-based TEE provides a powerful and portable foundation for running workloads across heterogeneous hardware platforms with minimal friction. A minimal Linux build serves as a streamlined and predictable base. By stripping the operating system down to only the essential components required for bootstrapping and hardware interaction, it eliminates much of the variability and complexity typically associated with fullfeatured distributions. At the same time, being minimal does not imply inflexibility. The base can remain lean while still supporting the breadth of drivers required for diverse edge and cloud hardware, by including modular kernel configurations and loadable drivers. Linux was chosen for its hardware support, long-term stability, and a vast ecosystem of open-source tools and active community support. This balance ensures consistency across hardware vendors without sacrificing compatibility, making it an ideal base layer for portable systems. WebAssembly contributes architecture-neutral execution capabilities. Once an application is compiled to Wasm, it can run on any machine equipped with a compatible runtime. The Wasm abstraction layer handles the differences in instruction sets and system interfaces, freeing developers from the need to recompile or customise applications for each target platform. This makes WebAssembly particularly effective for creating highly portable, container-like workloads with minimal overhead. TEEs provide hardware-backed security, allowing workloads to run in isolated enclaves that protect data and code integrity even in untrusted host environments. Virtualisation-based TEEs offer consistent behaviour across hardware vendors, which further enhances portability by ensuring that the security model does not need to change during migration, but also ensuring that there are no code changes needed to add a TEE support. When combined, these three components form a cohesive, lightweight, and secure execution stack that enables seamless migration of workloads between devices, datacentres, and edge environments. 9.2 Reducing Vendor Lock-in with Cross-Platform Support ELASTIC is designed to give developers and operators maximum freedom in how and where their applications are deployed. A central design goal is to avoid lock-in to any single vendor, cloud provider, hardware architecture, or proprietary runtime environment. Instead, ELASTIC promotes an open, portable, and future-proof software stack. By targeting WebAssembly, ELASTIC decouples application binaries from operating systems, instruction sets, and even programming languages. This allows developers to build once and deploy anywhere: on-prem, at the edge, or across cloud providers. ELASTIC avoids closed APIs and vendor-specific runtimes. This allows developers to later migrate their application ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 101 - August 31, 2025 from an on-premises private cloud to a public cloud platform as their business scales, as we show in Demonstrator 2, or conversely, to easily migrate from public to private cloud should they later need to support customers with special regulatory requirements. It also targets POSIX-compliant system interfaces, and standard Linux syscalls. While support for full OCIcompliant container integration is under development, the platform is architected with interoperability in mind. This ensures that as the OCI integration matures, ELASTIC workloads will integrate smoothly with standard container tooling, registries, and deployment workflows. One of the goals is a modular TEE Integration, including Intel TDX, AMD SEV, and ARM TrustZone — via a modular abstraction layer. This approach ensures that secure workloads can run on different platforms without reengineering or coupling to a specific enclave implementation. Also, ELASTIC targets to apply authentication and authorisation policies consistently across environments, without depending on cloud-specific IAM implementations. This ensures workload behaviour remains consistent even as deployment targets change. The benefits of this approach are: ● Portability: Wasm ensures that workloads can execute across different architectures without recompilation, while minimal Linux provides a uniform base layer. ● Security: TEEs maintain consistent, hardware-enforced protections across platforms. TEEs are optional and other ELASTIC components can work without TEEs and attestation in scenarios where such approach makes sense. ● Efficiency: The slim footprint of minimal Linux and the runtime isolation of Wasm allow for fast boot times and low overhead. ● Flexibility: This architecture supports cloud, edge, and embedded environments alike, enabling fluid migration and scaling. Also, Wasm is a portable binary format supported by many programming language tools, which provides a flexibility for developers to use their preferred tools rather than imposing artificial limitations. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 102 - August 31, 2025 10 Use Cases and Applications To validate the platform’s practical relevance, this section outlines three primary use cases: secure Function-as-a-Service (FaaS) workloads, confidential computing for cloud-edge infrastructure, and real-world industrial scenarios. These examples illustrate how the technologies and architecture proposed in the document address concrete business and technical needs. 10.1 Secure Function-as-a-Service (FaaS) Workloads in TEE Wasm provides a lightweight, portable, and sandboxed execution model. It provides the user with the capability to write code in a high-level language (C/C++, GO, Rust, etc.) and compile it into Wasm. This decouples application logic from the hardware architecture, enabling TEEs to enforce strong isolation guarantees without requiring platform-specific rewrites. Combining FaaS with Wasm runtimes inside TEEs enable a highly secure, scalable, and portable model for executing ephemeral workloads on untrusted infrastructure. When deployed within a TEE, such as Intel TDX or AMD SEV-SNP, the Wasm runtime can securely isolate and execute untrusted or tenant-provided functions without exposing the underlying host or sensitive data. Wasm module’s platform-agnostic nature simplifies deployment across heterogeneous hardware while maintaining a consistent trust boundary enforced by the TEE. One example of Wasm in TEEs is Enarx. The Enarx runtime, "Keep" (TEE), provides a secure and isolated execution environment that ensures data confidentiality and code integrity, even from the host operating system or cloud provider. With its minimal trusted computing base and hardware abstraction layer, Enarx facilitates the deployment of secure applications across both public and private infrastructure. The workloads are provided by a component called the Drawbridge. The Drawbridge provides a repository of Wasm applications that the Keep can fetch, but only after a successful attestation verification has been completed. Another example is the Propeller - a component developed within the ELASTIC project under WP2 115 . Propeller is a next-generation orchestrator designed for Wasm workloads that spans the cloud-to-edge continuum. It enables deployment of Wasm applications from cloud servers down to resource-constrained microcontrollers. It supports FaaS deployment models and integrates with OCI-compliant registries. Additionally, by leveraging the WebAssembly Micro Runtime (WAMR) on platforms like Zephyr RTOS and coupling it with a secure service mesh (via SuperMQ), Propeller ensures both performance and security at its core. 10.2 Confidential Computing for Cloud and Edge Environments Multiple cloud providers already offer TEE services, often referred to as Confidential VMs (CVMs). These solutions are based mainly on Intel and AMD TEE technology. Intel includes SGX (a process-based TEE) and TDX (a VM-based TEE), while AMD offers SEV/SEVES/SEV-SNP (also VM-based TEEs). The problem with public cloud TEE support is that the VM firmware is usually closed-source, as seen in the cases of Azure and GCP, whereas AWS is the only CSP with an open-source VM firmware. The closed-source VM firmware makes it difficult for the relying party (the user of the CVM) to verify the TEE attestation report. Another problem is that the user needs to rely on the CSP to perform attestation verification. 115 ELASTIC Project, Lightweight and Robust Orchestrating Mechanisms – Initial Version (Deliverable D2.1), Zenodo, 2025. doi: 10.5281/zenodo.15100798 ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 103 - August 31, 2025 Multiple hardware IoT devices support TEEs. One of them is Arm's TrustZone, available on Cortex-M and Cortex-A processors, and Arm Confidential Computing Architecture (CCA) available on Cortex-A processors. These implementations come with security limitations: ● The user must unquestioningly trust the hardware manufacturer. ● The TCB of existing TEEs is static, meaning it cannot be customised for different applications. ● Embedded TEEs, such as Cortex-A TrustZone, can only have one TEE at a time. ● Embedded TEEs do not encrypt memory. ● The TEE shares a processor code with the rest of the system, making it a target for sidechannel attacks. ● Embedded TEEs do not have native hardware support for remote attestation. The large TCB of the TEE and the transition between the TEE and the non-secure part of the IoT software can leave the TEE vulnerable to attacks. ● On Cortex-A, the confused deputy attacks can allow a non-TEE application to read and write any memory location in the kernel by tricking the TEE to perform operations. ● The software TCBs in TEEs are large and can lead to control-flow hijacking attacks. ● Cortex-M TrustZone supports an unlimited number of TEE entrances through the SG instruction and exits through the BXNS and BLXNS instructions. This model makes it hard to implement a secure channel between a non-secure software application and a secure application. Another problem with embedded TEE solutions is the performance overhead. The performance is impacted by context switching between secure and non-secure applications, as well as a large software TCB. 10.3 Potential Industry Applications 10.3.1 Demonstrator 1 In Demonstrator 1, An IoT Data Fabric as a Native 6G Infrastructure Capability, TEEs and attestation are employed to address requirements for data protection and policy compliance, while enabling the integration of diverse devices and edge platforms within the data fabric. The demonstrator, its requirements, and how components described in this deliverable are utilised in it are described in more detail in D5.1 116 . Scenarios considered for this demonstrator are Predictive Maintenance, Cross-factory Data Sharing, and Real-time Robot Control. These are related to the Proactive Maintenance and Smart Manufacturing scenarios described for the HAL in Section 5.1.3 and 5.1.1. In these scenarios, an IoT data fabric that crosses organisational boundaries introduces new risks due to the difficulty of administrative control by any one party. TEEs provide secure environments for processing sensitive data in the fabric, and attestation provides methods for trust establishment between heterogeneous data fabric entities. Leveraging them together with secure orchestration, communication, and key provisioning and management mechanisms 116 ELASTIC Project, Specification of the ELASTIC Demonstrators and validation plan (Deliverable D5.1), to appear, 2025. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 104 - August 31, 2025 allows the various participants in the data fabric to be assured of how data is being created and used by other parties, e.g., based on attributes and policies set for the data. As an example, a data provider may define that its data should only be processed in the data fabric by entities conforming to a specific policy. The policy may require (or imply) that these entities are TEEs executing specific Wasm modules/components and attested using verifiers and parameters the provider trusts. The data fabric facilitates that the entities dealing with the data within the fabric, as well as data consumers they send data to, are instantiated and attested (via the HAL and attestation procedures defined in ELASTIC) according to the policy, and provisions keys for secure communication and storage accordingly. 10.3.2 Demonstrator 2 Demonstrator 2 addresses the use case/scenario of securely migrating sensitive IT services from on-premise infrastructures to public cloud environments. ● Companies trust private clouds because they have physical and administrative control of the machines running their software. ● Public cloud platforms are not always trusted because unknown personnel are managing the hardware and software on the computing platforms, which may be shared with unknown parties. ● TEEs allow trust in public cloud platforms by allowing companies to establish trust in the security of the computing platform using purely technical means, using features such as attestation to ensure that the cloud platform will be at least as secure as the local "private cloud" platform. The IT services are implemented as one or several Wasm workloads. The migration itself is secured by the encryption of the IT Service during the transport by keys delivered by a Key Broker Service only releasing them if the execution environment on-premise and in the cloud have been successfully attested. The attestation of the execution environments guarantees that the IT Service remains protected in integrity and in confidentiality before, during and after the migration. Corresponding scenarios on transport of sensitive data involving remote attestation and key - broker service are described in NFV SEC026. The Reliable Enclave Migration protocol Service wants to securely transfer the Wasm workload from Private Cloud to Public Cloud, both clouds belong to the same trust domain, i.e., have a common verifier for remote attestation. The key is released from the KBS to the Reliable Enclave Migration Protocol Service to encrypt the Wasm workload prior to transfer. After transfer, the Remote Attestation Platform (the verifier) receives the attestation measurement done by the TEE Management Software Agent. As the TEE Software Management Agent is within HAL, the Remote Attestation Platform (verifier) should receive the attestation evidence in an abstracted form. The Remote Attestation Platform (Verifier) sends the attestation result to the KBS acting as Relying party, which upon successful attestation releases the key for decrypting the Wasm workload, which can be used within Public Cloud afterwards. The basic principle is depicted in the high-level architecture and the procedure is in line with NFVSec026 when Key Brooker acts as Relying party. ELASTIC Demonstrator 2 is described in detail in D5.1. ELASTIC D3.1 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 105 - August 31, 2025 11 Conclusions and Next Steps 11.1 Summary of Contributions Lightweight Confidential Computing Platform within ELASTIC project delivers a unified software architecture that addresses the challenges of portability, security, and interoperability in modern distributed systems. By combining a minimal Linux foundation, the WebAssemblybased execution, and the support for TEEs, the Platform enables secure and seamless deployment of workloads across heterogeneous hardware platforms — from cloud infrastructure to edge devices. A major contribution of ELASTIC lies in its ability to decouple application logic from specific hardware and vendor environments, while still relying on confidential computing primitives provided by those hardware vendors. Through the use of open standards and modular abstractions, the platform reduces vendor lock-in and ensures long-term sustainability and adaptability. Its integration of a portable WebAssembly runtime and evolving support for OCIcompatible containers highlights a strong commitment to cross-platform compatibility and future-proof design. The Platform also introduces a layered security model that provides robust isolation guarantees in shared infrastructures. This includes hardware-enforced confidentiality using TEEs, OS-level process containment, and cryptographic data protection — all governed by a unified, identity-aware policy framework. One of the crucial components that the platform supports is the TEE remote attestation mechanism, which provides the user a means to verify and validate the confidentiality of the platform. Together, these mechanisms ensure strong security properties even in multi-tenant or adversarial environments. At the heart of ELASTIC is the use of WebAssembly as a universal runtime format. Wasm technologies form a foundational layer of the platform, enabling a lightweight and efficient execution model that is ideally suited for modern serverless and, more specifically, FaaS applications 11.2 Future Enhancements and Research Directions There are several areas in which we will improve for the next revision as we focus on work for D3.3 and the final version of the platform. Most of these future improvements are targeted towards practical use of the platform in WP5 and ELASTIC demonstrators. A key research direction involves combining distributed attestation mechanisms with the WebAssembly Component Model and its integration into HAL specified in this document. This integration will enable fine-grained measurement and verification of multi-component Wasm applications, where individual modules can be attested independently, then verified and assembled securely at runtime. To support this, a unified attestation interface for multicomponent applications is planned. This interface will account for the identities and measurements of all participating Wasm components, enabling secure assembly and reuse of modular software, as well as increasing the breadth of functionality that can be implemented using runtime-agnostic Wasm modules and loaded at deployment time, rather than requiring implementation of potentially-niche functionality directly within the runtime. In parallel, ELASTIC will strengthen its support for data protection at rest by introducing a Key Broker Service and implementing transparent encryption mechanisms. Keys will be provisioned specifically for confidential computing workloads and bound to verified enclave states via attestation. This ensures that encrypted storage (e.g., filesystems or volumes) is accessible only within authorised and measured execution environments. The project will also explore secure provisioning of cryptographic keys using attestation-based mechanisms that enforce strict access control tied to runtime workload identity. This is a