arXiv CSopen access

Verifiable and Confidential DNN Inference on Low-End Edge Devices

V E C O DI: Verifiable and Confidential DNN Inference on Low-End Edge Devices Mohamed Khalil Kiri∗ , Ivan De Oliveira Nunes† , Aurélien Francillon∗ , and Norrathep Rattanavipanon‡ ∗ EURECOM, France † University of Zurich, Switzerland

arXiv:2606.07470v1 [cs.CR] 5 Jun 2026

‡ Prince of Songkla University (PSU), Phuket, Thailand

Abstract—Deploying deep neural network (DNN) inference on low-end edge devices raises two key challenges: protecting model confidentiality against a potentially compromised edge system and enabling verifiable inference without incurring prohibitive overhead. Existing approaches either house (partial) models and inference software within trusted execution environments (TEEs), resulting in high cost and an applicationdependent trusted computing base (TCB), or execute in untrusted environments, providing little security. In this work, we present V E C O DI, a framework for verifiable and confidential DNN inference on constrained edge devices. At its core, V E C O DI introduces S HANGRI -L A, a new execution abstraction on TrustZone-M TEEs that establishes a third runtime environment with privileges strictly between the Secure and Non-Secure Worlds. V E C O DI leverages S HANGRI L A to execute untrusted inference code in the Non-Secure World while using minimal application-agnostic Secure-World support to protect model confidentiality and enable verifiability (with respect to proper execution of inference code and model parameters) of inference results. We realize V E C O DI on a real-world NUCLEO-L552ZE-Q development board and opensource its prototype. Our results show V E C O DI’s small TCB, memory footprint, and runtime overhead, making it a practical option for secure inference in low-end edge devices.

1. Introduction Edge computing has emerged as a paradigm for performing inference with machine learning (ML) models, particularly deep neural networks (DNNs), in latency-sensitive and resource-constrained environments [1]. In this paradigm, DNN models are trained in centralized infrastructures (e.g., the cloud) by service providers, referred to as model providers, and subsequently deployed to edge devices, such as sensor and actuator microcontrollers. These low-cost devices then perform DNN inference locally, enabling realtime decision-making for several modern IoT applications such as remote medical diagnostics, autonomous systems, and industrial monitoring [1]. However, moving from centralized to decentralized deployments creates new attack vectors. First, training DNN models typically requires substantial computational resources, as well as significant effort in collecting and curating training data. As such, model providers

often consider these models to be valuable intellectual property/assets that must be protected [2]. However, when deployed at the edge, DNN models are exposed to stronger adversarial capabilities, where device-controlled adversaries have both physical and software access to the device. This enables such adversaries to: (1) directly extract the model, either at rest (e.g., from on-device flash memory) or at runtime, and (2) mount model extraction attacks [3] by reconstructing the deployed model via performing a large number of carefully crafted inference queries. These threats introduce a new challenge of model confidentiality for model providers in edge deployments. Second, edge inference outcomes are often used to drive critical decision-making. For example, in autonomous systems, object detection results are used to identify obstacles (e.g., pedestrians) and trigger braking upon detection. Similarly, in remote medical diagnostics, ECG analysis results may be used to detect cardiac abnormalities and initiate timely intervention [1]. However, edge devices operate under strict constraints in terms of cost, size, and power, which limit the deployment of sophisticated security mechanisms. As a result, these low-end devices are more vulnerable to malware infestation, leading to a surge in IoT malware targeting edge devices in recent years [4]. Once compromised, such malware can take control of the entire software stack and produce spoofed inference results to manipulate downstream decisions, potentially endangering physical environments and users. To address this second class of attacks, verifiable inference is necessary. In traditional centralized settings, this is typically not a major concern, as the model providers have full control over powerful inference devices. To enable model confidentiality with low performance overhead, recent work leverages Trusted Execution Environments (TEEs), giving rise to a class of techniques known as TEE-Shielded DNN Partitioning (TSDP) [5], [6], [7], [8]. These techniques partition a DNN into two disjoint components: (i) privacy-sensitive and (ii) privacy-insensitive parts. The privacy-sensitive components are executed within the TEE, while the remaining parts are left unprotected. Despite good performance, this line of work suffers from a key limitation: it enlarges the trusted computing base (TCB) by incorporating DNN inference code directly into the TEE, thereby increasing both the software footprint and the attack surface to already-constrained/vulnerable edge devices. Moreover, many of these approaches [6], [7], [8]

overlook model extraction attacks, leaving this important issue unaddressed. On the other hand, prior work on verifiable inference either assumes that the entire inference pipeline is executed within TEEs [9], [10], [11] or relies on cryptographic techniques in conjunction with TEEs [12], [13]. The former is often undesirable in edge settings, as DNN models may exceed the limited memory capacity of the TEE. The latter, while more flexible, can introduce significant computational overhead, making it unsuitable for power-constrained devices. More importantly, both approaches still suffer from TCB bloat due to the inclusion of complex and potentially buggy inference code within the TEE. A compromise of such code could escalate into other high-assurance components (e.g., secure key storage, secure software update) that live in the same TEE, as is the case with ARM TrustZone-M – a commonly used TEE for low-end edge devices. In light of these challenges, we introduce V E C O DI, a TrustZone-M-based framework that simultaneously enables model confidentiality and verifiable inference for DNNs on low-end edge devices. Unlike prior TEE-based approaches, V E C O DI does not place DNN inference code or data in the Secure World. Instead, it introduces a new abstraction, S HANGRI -L A, which serves as a third runtime environment alongside TrustZone-M’s Secure and Non-Secure Worlds. S HANGRI -L A resides in the Normal World memory but operates with elevated privileges enforced by the Secure World. This design enables reuse of existing Normal World functionality, avoiding cross-world code duplication. At the same time, S HANGRI -L A guarantees the confidentiality and integrity of its code and data – both at rest and during execution – even when the Normal World is untrusted. In addition, S HANGRI -L A can directly access hardware I/O peripherals, preventing interference from the Normal World on the physical acquisition of data. Despite these capabilities, it remains less privileged than the Secure World, ensuring that a compromised or faulty S HANGRI -L A cannot impact Secure World components. Finally, S HANGRI L A requires only minimal, application-agnostic code in the Secure World. This code can be thoroughly tested or formally verified once and reused across multiple S HANGRI L A applications. At the protocol level, we combine S HANGRI -L A isolation abstraction with two key features. First, an inference authorization protocol allows the model provider to limit the number/frequency of inferences that can be performed; this mitigates model extraction attacks that threaten model confidentiality. Second, we extend S HANGRI -L A to generate a verifiable proof of inference execution that accompanies each inference result. This proof allows an external verifier to assess whether: (1) the inference inputs were correctly captured from physical interfaces; (2) inference code is executed correctly on the intended DNN model and authentic input; and (3) the reported inference result corresponds exactly to this execution instance. This also supports privacy, since the proof validation does not require raw inputs used by the edge device that may contain sensitive user information (e.g., consider an image recognition case).

Contributions Our main contributions are as follows: 1- Third Runtime Environment. We introduce S HANGRI L A, a lightweight execution abstraction on top of TrustZoneM. It provides a third runtime environment that is protected from Normal World compromise, while ensuring that any compromise within S HANGRI -L A cannot affect the Secure World. At the same time, S HANGRI -L A physically lives in Normal World and thus can reuse existing Normal World code, reducing the overall software footprint. We believe S HANGRI -L A is of independent interest beyond secure DNN inference, as it enables third-party developers to deploy arbitrary trusted applications on TrustZone-M without modifying core Secure World components. 2- Secure and Verifiable DNN Inference. We build upon the S HANGRI -L A abstraction to achieve both model confidentiality and verifiable inference on low-end edge devices. First, we equip S HANGRI -L A with an inference authorization mechanism to mitigate model extraction attacks. Second, we enable S HANGRI -L A to generate verifiable proofs of input retrieval and inference execution, allowing external verifiers to validate results without accessing sensitive raw input data. Along with these extensions, S HANGRI -L A is used to construct V E C O DI: a protocol executed between inference stakeholders to realize confidential and verifiable DNN inference. 3- Practical Deployment and Evaluation. We implement V E C O DI on a NUCLEO-L552ZE-Q development board [14] and open-source its prototype [15]. Our evaluation results demonstrate the practical benefits of V E C O DI: Compared to prior TEE-based solutions, V E C O DI eliminates the need to place inference code in the Secure World, reducing the TCB by 95.64%. Moreover, V E C O DI incurs only 0.83 ms (0.07%) runtime overhead, making it well-suited for resource-constrained devices. Finally, we demonstrate real-world applicability through a case study on camera-based edge image classification.

2. Background 2.1. TrustZone for ARM Cortex-M MCUs ARM TrustZone-M provides hardware-enforced isolation for Cortex-M microcontrollers by partitioning the system into two domains: the Secure World and the Normal World. Each domain can only access memory regions assigned to its corresponding security state. Memory regions, including code, data, and peripherals, are classified as Secure, Non-Secure, or Non-Secure Callable (NSC) through the Security Attribution Unit (SAU) and the Implementation-Defined Attribution Unit (IDAU), both configured by Secure-World code at boot time. This ensures that only Secure-World code can access Secure memory, while Non-Secure code is restricted to Non-Secure regions. To enable controlled invocation, the Secure World exposes APIs that can be called by the Normal World through designated NSC entry points. These entry points are the only

locations where control can transfer from the Non-Secure World to the Secure World, preventing arbitrary jumps into Secure-World code. As a result, the Normal World cannot tamper with the execution of Secure-World code except through explicitly defined APIs, and cannot access SecureWorld resources protected by the SAU and IDAU, ensuring strong isolation between these two worlds. In practice, the Secure World contains a small trusted computing base (TCB) consisting of security-critical components (e.g., secure boot, key storage, and attestation) to minimize the attack surface. In contrast, the Non-Secure World hosts a significantly larger software stack, including the operating system and user applications. We also note that, unlike the IDAU, the SAU can be reconfigured at runtime by the Secure World, allowing memory regions to transition dynamically between Secure and Non-Secure states.

2.2. Remote Attestation and Proof of Execution Remote Attestation (RA). RA allows a remote verifier to establish trust in the software state of a target device [16]. To be secure, RA requires a root of trust (RoT) on the target device (e.g., TrustZone-M TEE) to measure the software to be attested and sign (or MAC) the measurement result under a device-specific attestation key, yielding attestation evidence. The verifier can validate the evidence by checking the signature/MAC using the pre-shared verification key and matching the measurement against a known-good (golden) reference. While RA certifies what software is installed, it offers no guarantee over what the device subsequently computes. Proof of Execution (PoX). PoX extends RA evidence to include execution information [17]. The RoT attests not only to code identity but to the fact that a designated function F ran to completion on a given input and produced a given output within the attested device. As illustrated in Figure 1, the protocol follows a challenge-response exchange between a verifier and a prover device: 1- Request. Verifier issues request containing a cryptographic challenge. It also specifies which function F should be executed and optionally a verifier-provided input InF . 2- Execution. Upon receiving it, the prover computes OutF ← F(InF ); the RoT monitors this execution and immediately aborts it if the execution is tampered with. Note that F code may contain direct access to hardware I/O peripherals for data acquisition (i.e., it should contain it when performing inference on an edge sensor device). 3- Proof generation. The RoT produces attestation evidence Tproof . This token should be bound to the challenge received in the request, the executed F binary, its legal entry point, InF , and OutF . Crucially, Tproof should only be produced if F execution is completed successfully and (for timeliness) after the receipt of the challenge it is bound to. 4- Response. The prover returns (OutF , Tproof ); The verifier accepts OutF as authentic if and only if Tproof is successfully verified using the verification key and the mea-

2 execute OutF ← F(InF ) ⃝

1 request ⃝

Verifier

Prover

4 (OutF , Tproof ) ⃝

5 accept OutF if Tproof valid. ⃝

3 compute Tproof ⃝

Figure 1: Generic Proof-of-Execution (PoX) workflow. surement matches the expected challenge, F binary, received OutF , and expected input InF (if any).

2.3. TEE-Shielded DNN Partitioning Running a full DNN inside a low-end TrustZone-M TEE is generally infeasible: Secure RAM is measured in tens of kilobytes, whereas even compact models require orders of magnitude more memory. TEE-Shielded DNN Partitioning (TSDP) addresses this by decomposing a model M into two sub-networks: a sensitive component Mpri sequestered in the Secure World, and a public component Mpub executed in the Normal World under the device’s full memory and compute budget. The choice of boundary is dictated by the target security property, e.g., model protection [5], [18] or execution efficiency [19]. Regardless of objective, TSDP requires hosting Mpri alongside a full inference engine (e.g., TFLite Micro) inside the Secure World, inflating the TCB beyond the minimality required for a secure RoT. End-to-end latency is similarly constrained: on cycle-limited MCUs, fine-grained partitions that maximize security coverage do so at the cost of frequent pipeline stalls on each domain crossing.

3. System/Threat Models and Goals 3.1. System and Threat Models System Model. We consider an edge inference setting that comprises four stakeholders: - Model provider (P VD): curates training data, provides the DNN model M , and authorizes access to it. - Edge device (D EV): a single-core MCU equipped with a low-cost TrustZone-M TEE. Note that MCUs lack memory management units, making them unsuitable for isolation mechanisms based on virtual memory (e.g., operating system- or hypervisor-based). Our model reflects this. - Model consumer (C SM): obtains authorization from P VD to run inference on D EV. - Verifier (V RF): receives inference results and validates their trustworthiness before downstream use. Although logically distinct, V RF’s role can be implemented by another entity, e.g., in practice, a single entity can play both V RF and C SM roles, where the consumer of a result also locally verifies it. As illustrated in Figure 2, secure edge inference consists of four interactions among these stakeholders:

Model Provider (Pvd)

I1: Provisioning

I2: Authorization

tion

riza

tho

Au I2:

ce

ren

Infe I3:

Edge Device (Dev)

Model Consumer (Csm)

I4: Verification

Verifier (Vrf)

Figure 2: Interactions between P VD, D EV, C SM, and V RF. I1: Provisioning. P VD securely provisions D EV with required cryptographic material and installs the input-retrieval and inference code, F, along with M on D EV. I2: Authorization. C SM requests permission from P VD to use M on D EV. If approved, P VD issues an authorization token TC SM on M ’s identifier IDM , encoding C SM’s usage policy on M . I3: Inference. C SM invokes inference on D EV along with the input InF and Tu which is an authenticated token issued by C SM to execute one inference instance. Upon validation, D EV executes F(InF ) with M , producing an inference result OutF along with a proof Tproof . I4: Proof Verification. C SM sends OutF and Tproof to V RF, which validates the authenticity of OutF w.r.t. the expected F and Tproof , and accepts OutF if verification succeeds. Threat Model. We consider two adversary cases AM and AI with different goals. The goal of AM is to extract M . AM can compromise D EV (except for its TEE-protected code and data), C SM, and V RF. AM cannot compromise P VD who already possesses M . By compromising D EV, AM gains full control over its communication channels, enabling message interception, modification, replay, and injection. It also controls all untrusted software on D EV, with the ability to read, write, and execute arbitrary code and data in the Normal World. AM also has physical access to D EV, allowing it to extract sensitive information (e.g., a DNN model) that is stored unprotected in D EV’s Flash memory (e.g., via Flash dump). For AI , the goal is to convince V RF to accept a forged inference result OutF , that is: one that was not produced by the timely execution of the correct inference software on D EV using appropriate model parameters and external inputs (if any). AI can compromise D EV (except for TEEprotected state), and C SM to achieve its goal. Assumptions. We assume P VD is trusted: as it already possesses M , it has no incentive to act as AM . Conversely, being the model provider, it can already choose M , gaining no advantage from behaving as AI . D EV is assumed to be equipped with a TrustZone-M TEE, whose Secure World code is trusted and free of vulnerabilities. This assumption is corroborated by our design principle of avoiding a potentially large inference function F in the Secure World. Following the typical TrustZoneM trust model [4], we assume an underlying secure boot process that guarantees the integrity of Secure World code at boot time, as well as secure persistent storage restricted

to Secure World accesses [20]. To protect against attacks based on Direct Memory Access (DMA) controllers, we assume that D EV is equipped with a security DMA controller capable of specifying DMA access permissions for memory regions, such as the Global TrustZone Controller (GTZC) available on our NUCLEO-L552ZE-Q prototype board. The trusted P VD is responsible for ensuring F correctness, i.e., it correctly retrieves input data from properly configured peripherals and performs inference without leaking sensitive information (i.e., M ). However, given its size, there is still a chance for P VD to make mistakes and introduce vulnerabilities in F. In such a case, while it is not possible to guarantee inference integrity, V E C O DI ensures that the Secure World remains unaffected (in contrast to the alternative of housing F in the Secure World). Out-of-Scope Attacks. Following the standard TrustZone-M threat model [21], we do not consider physical attacks such as side-channel attacks, fault injection, invasive hardware modification, or denial-of-service attacks. While powerful against this class of devices, these attacks are orthogonal to this work and require dedicated/independent countermeasures [21], [22], [23].

3.2. Goals Under the above system and threat models, V E C O DI aims to achieve: G1 (Model Confidentiality). AM should not learn any information about M beyond what P VD allows. This goal consists of two sub-goals: G1-1 (Direct Leakage Protection): Even with compromised D EV, AM cannot access M or any function of M , except for OutF and Tproof . G1-2 (Indirect Leakage Mitigation): Since OutF may still leak information about M (e.g., via model extraction attacks), AM must not be able to invoke F more than what P VD explicitly authorizes. Remark. V E C O DI deliberately leaves the number of authorized invocations configurable by P VD. This is appropriate because P VD understands the model and is best positioned to set this limit, which may vary across different M -s and application scenarios. Choosing suitable limits is orthogonal to V E C O DI’s architectural support. G2 (Verifiable Inference). An adversary AI must not be able to trick V RF into accepting invalid inference results. It consists of two sub-goals: G2-1 (Authenticity): V RF must be able to detect invalid pairs (OutF , Tproof ) submitted by AI . In particular, this happens when: (1) OutF is forged without executing F, (2) OutF is produced by executing F on a different D EV, (3) OutF is produced by executing F on the right D EV but using a different model than M , or (4) OutF results from an incomplete execution of F on D EV or from the execution of code different from F. G2-2 (Privacy): To preserve D EV owner’s privacy, V RF must be able to validate (OutF , Tproof ) without access to the inference input, which may contain sensitive data.

Remark. The inference input is distinct from InF . The latter denotes a public input to F, containing only non-sensitive information (e.g., preprocessing parameters or peripheral configuration settings), hence not critical to the D EV owner’s privacy. In contrast, the inference input is not a part of InF ; it is acquired internally during execution through sensorreading operations and subsequently passed to the inference pipeline within F. G3 (Low Overhead). To accommodate D EV’s limited resources, V E C O DI must incur minimal overhead on D EV. We consider three types of overhead: G3-1 (TCB): The increase in Secure World TCB size must be small and independent of F, allowing the same TCB to support arbitrary implementations of input retrieval and inference. G3-2 (Memory): V E C O DI should minimize memory usage by avoiding duplication of code or model data across Secure and Normal Worlds whenever possible. G3-3 (Latency): V E C O DI must minimize runtime overhead during inference.

(Mpub ). Here, Mpri is provisioned in encrypted form and executed in Secure World, similar to D2; Mpub is managed and executed in the Normal World, as done in D1. This design is commonly used in prior TEE-based work [5], [7], [27] to achieve G1-1 on potentially untrusted devices. Since Mpri is typically much smaller than Mpub , this design reduces secure memory requirements compared to D2, partially addressing G3-2 (Memory). However, it does not resolve G3-1 (TCB), as Secure World must still host F to ensure correct usage of Mpri . Moreover, G3-3 (Latency) can be negatively impacted due to frequent world switches between Secure and Normal Worlds, with overhead depending on the partitioning strategy, e.g., approaches like TEESlice [5], which distribute private components across multiple layers, can incur substantial switching costs. Finally, this design still limits the use of emerging low-cost hardware accelerators for executing Mpri . TABLE 1: Memory access control of TrustZone-M domains with the introduction of S HANGRI -L A; C and D indicate code and data, respectively, while PrivD and PubD refer to private and public data. RO indicates read-only access.

4. Design Overview 4.1. Challenges Simultaneously achieving G1 to G3 is challenging. To illustrate this, we focus on a subset of these: G1-1 and G3. Even under this simplification, we show that commonly used designs in the literature – D1, D2, and D3 – fail to satisfy both of them. Since V E C O DI also targets more goals, it faces even more challenges. D1: Full Normal World Execution. We start with a strawman approach that executes F entirely in Normal World. While this approach naturally satisfies G3 and is easy to deploy, it provides no security guarantees: AM can trivially violate G1-1, e.g., by extracting M from D EV’s flash/RAM while AI can steal the attestation key in Normal World, resulting in a successful forgery of Tproof . D2: Fully Secure World Execution. At the other end of the spectrum, F can be placed and executed entirely in the Secure World. To protect M at rest, P VD can provision it in encrypted form (during I1: Provisioning), which is then decrypted and loaded into secure RAM for execution by F post-boot. This satisfies G1-1, not G3. In particular, G3-1 (TCB) is violated, as the Secure World must include F, which is application-specific (e.g., dependent on input sensors and inference implementations). Additionally, G32 (Memory) is strained, since D EV must store both an encrypted version of M in flash and a plaintext version in secure RAM. Finally, this design limits the use of emerging ML hardware accelerators (e.g., microNPUs [24], Edge TPUs [25]), which are typically exposed to and managed by the Normal World [26], thereby hindering potential performance gains. D3: Split Inference Across Worlds. A middle-ground partitions M into private (Mpri ) and public components

NW Normal World (NW) S HANGRI -L A Secure World (SW)

C

D

C

✓ ✓ ✓

✓ ✓ ✓

RO ✓ ✓

S HANGRI -L A PrivD PubD × ✓ ✓

RO ✓ ✓

SW C

D

× × ✓

× × ✓

4.2. High-Level Intuition From D1–D3, we observe that G3 is achieved only by D1. This suggests that extending D1 with stronger security mechanisms could enable us to achieve both G1-1 and G3. Guided by this insight, we propose a new abstraction, S HANGRI -L A, which executes F in Normal World, inheriting D1’s benefits for achieving G3. To enforce G1-1, we introduce a small, F-agnostic component in the Secure World that elevates S HANGRI -L A privilege during its execution, placing its privilege between Normal and Secure Worlds. With this new privilege, Normal World cannot access or tamper with S HANGRI -L A’s code and data, ensuring G1-1. At the same time, S HANGRI -L A is prevented from interfering with Secure World. As a result, this design enables third-party developers to deploy isolated code without modifying highly trusted Secure World components. Overall, S HANGRI -L A establishes a new, third, runtime environment on TrustZone-M where the privilege relationships among the three environments are summarized in Table 1. Composition with Cryptographic Authorization and Proofs of Execution. To achieve complete protection, we compose S HANGRI -L A to support G1-2 and G2 without sacrificing G3. Specifically, S HANGRI -L A is extended with two features: (1) an authorization mechanism that allows a trusted party to control who can invoke S HANGRI -L A and how often, thereby enforcing G1-2 (assuming F correctly performs input retrieval and inference over M ), and (2) a proof-of-execution mechanism that enables Secure World

LifeCycle

NS RAM

Non-Exist

...

Inactive

...

Active

...

(a) S HANGRI -L A Lifecycle.

Flash

datapriv

datapriv

runtime data

...

code

data

...

...

code

data

...

...

code

data

pub

pub

pub

enc_data

enc_data

enc_data

priv

priv

priv

...

...

...

(b) Gray denotes Non-Secure state; Green denotes Secure.

Figure 3: Overview of S HANGRI -L A lifecycle (a) and its corresponding TrustZone-M memory state (b). to produce verifiable evidence that isolated code within S HANGRI -L A executed correctly and that a given output corresponds to that execution.

5. S HANGRI -L A Isolation Abstraction: A Third Runtime Environment on TrustZone-M Here, we describe S HANGRI -L A, starting with its highlevel lifecycle and then detailing the Secure-World APIs used to orchestrate its lifecycle state.

5.1. Lifecycle of S HANGRI -L A The lifecycle of S HANGRI -L A (Figure 3a) consists of three states: Non-Exist, Inactive, and Active, with transitions controlled by four Secure World APIs. On a new D EV, S HANGRI -L A is in the Non-Exist state. During provisioning, Provision API is called to install the necessary S HANGRI -L A metadata (e.g., code/data hash and keys), while Authorize configures access control policies such as permitted users and usage limits. These steps prepare S HANGRI -L A for deployment but do not instantiate it, so it remains in the Non-Exist state. To create an executable instance, the Normal World invokes Create. This validates S HANGRI -L A’s code and data with the stored metadata, initializes and assigns it the access privileges defined in Table 1, and transitions it to the Inactive state, where it is ready to run. Invoking Execute transitions S HANGRI -L A to the Active state, during which it executes F. Upon completion, it returns to the Inactive state. This enables repeated executions by alternating between Inactive and Active via Execute. While in the Inactive state, Authorize can be invoked to update S HANGRI -L A authorization policy without requiring re-creation. When the S HANGRI -L A instance is no longer needed, Destroy can be invoked to erase its sensitive state and release its memory back to the Normal World, returning to the Non-Exist state. Next, we describe how the aforementioned Secure World APIs are designed/implemented using TrustZone-M.

5.2. Secure-World APIs To orchestrate the S HANGRI -L A lifecycle, we maintain its context in secure persistent storage and expose a set of Secure-World APIs that allow the Normal World to trigger controlled state transitions without directly accessing or manipulating S HANGRI -L A code and data. As a basic form, we provide Provision, Create, Execute, and Destroy, which together ensure that S HANGRI -L A adheres to the privilege model in Table 1. We further introduce two optional extensions: (1) an Authorize API that allows D EV owner to specify which users may access S HANGRI -L A and how many times it can be invoked, and (2) an input flag to Execute that enables generation of a proof of execution, allowing an external verifier to validate the authenticity of the output. All APIs are summarized in Algorithm 1, while the corresponding TrustZone-M security states of S HANGRI -L A memory across its lifecycle are illustrated in Figure 3b. 5.2.1. Provision (Line 2-5). Unlike the other APIs, Provision is only accessible to a trusted entity, e.g., during device manufacturing or via a Secure-World update mechanism that verifies the integrity of the S HANGRI -L A configuration prior to its installation. It takes as input the S HANGRI -L A owner’s public key pko and a public identifier s id describing the S HANGRI L A instance, containing its code F, entry point entry , and a data identifier d id that captures both public data datapub and encrypted private data enc datapriv (if any). If enc datapriv is present, a decryption key kdec is also provided. Optionally, the API accepts a user public key pku and an access limit limit, specifying which user is authorized to invoke F (which executes within S HANGRI L A) and how many times it may be executed. Upon invocation, it computes a hash of s id to serve as a unique identifier for the S HANGRI -L A instance, initializes its Secure-World context (CT X ) with the provided input, sets the instance’s usage counter to 0, and places the instance in the Non-Exist state. 5.2.2. Authorize (Line 6-12). This API updates the access policy of a provisioned S HANGRI -L A. It takes as input a user public key pku , a new limit limit, a unique

Algorithm 1: S HANGRI -L A Secure World APIs 1

Context: CT X : Hs id → (kdec , pko , pku , data id, entry, usage, limit, state)

API Provision(kdec , pko , pku , s id, limit) Hs id ← Hash(s id) 4 parse (data id, entry) from s id 5 CT X[Hs id ] ← (kdec , pko , pku , data id, entry, 0, limit, Non-Exist)

2

3

API Authorize(pku , limit, Hs id , To ) if Hs id ∈ / CT X then 8 abort

6

7

11

retrieve pko from CT X[Hs id ] if limit ≤ CT X[Hs id ].limit or not Verify (pko , To , pku ∥limit∥Hs id ) then abort

12

CT X[Hs id ].{pku , limit} ← {pku , limit}

9 10

API Create(s id) Hs id ← Hash(s id) 15 if Hs id ∈ / CT X then 16 return failure

13

14

17 18 19 20

parse (F, datapub , enc datapriv ) from s id mark (F, datapub , datapriv ) as Secure datapriv ← Dec(CT X[Hs id ].kdec , enc datapriv ) CT X[Hs id ].state ← Inactive

API Execute(u, In, Hs id , proof, Tu ) / CT X then if Hs id ∈ 23 abort

21

22

24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

40

(pko , pku , data id, entry, usage, limit, state) ← CT X[Hs id ] if state ̸= Inactive or usage ≥ limit or u ≤ usage then abort

if not Verify (pku , Tu , u ∥ In ∥ Hs id ∥ proof ) then abort disable interrupts CT X[Hs id ].state ← Active allocate S HANGRI -L A stack mark (F, datapub , datapriv ) as Non-secure OutF ← execute entry(In) erase stack mark (F, datapub , datapriv ) as Secure CT X[Hs id ].{usage, state} ← {u, Inactive} enable interrupts if proof then Tproof ← Sign(skD EV , F ∥ u ∥ data id ∥ InF ∥ OutF ∥ pko ) return (OutF , Tproof )

API Destroy(Hs id ) / CT X then if Hs id ∈ 43 abort

41

42

44 45 46

erase datapriv mark (F, datapub , datapriv ) as Non-secure CT X[Hs id ].state ← Non-Exist

S HANGRI -L A identifier Hs id , and an authorization token To over (pku , limit, Hs id ) produced by the S HANGRI L A owner. Upon invocation, it verifies that a S HANGRI L A instance identified by Hs id has been provisioned and validates To using pko . If both checks succeed, it updates the instance’s context with pku and limit accordingly. This API enables the S HANGRI -L A owner to dynamically change the authorized user and adjust the number of allowed invocations for that user.

5.2.3. Create (Line 13-20). This API initializes a S HANGRI -L A instance from its provisioned configuration, taking s id as input. Then, it retrieves the memory regions corresponding to the code F, public data datapub , and encrypted private data enc datapriv from the instance’s context. It then uses the TrustZone-M’s SAU and security DMA controller (recall Section 2 and 3.1) to ephemerally mark the code and datapub regions as Secure, protecting them from both Normal World access and Non-Secure DMA. If encrypted private data exists, the API allocates a region datapriv , ephemerally marks it as Secure, and decrypts enc datapriv using kdec into this region. To prevent unauthorized reads by external peripherals, the API places datapriv in a Non-Secure RAM region that does not overlap with any memory-mapped peripheral regions. Finally, it sets the S HANGRI -L A lifecycle state to Inactive, indicating that the instance has been populated with code and data and is ready for execution. As illustrated in Figure 3b, after this call, all S HANGRI -L A code and data are in the Secure state, preventing access or modification by the Normal World. Remark. Although F and its data are temporarily marked as Secure, F is never executed in this state. Instead, it is atomically restored to Non-Secure immediately before execution (see Execute below), ensuring that the S HANGRI -L A state cannot be altered between its definition and execution and at the same time maintaining isolation between F and the Secure World TCB. 5.2.4. Execute (Line 21-40). This API performs a single F invocation in S HANGRI -L A. It takes as input a user message containing the post-execution usage counter u, F input InF , H(s id), and a signed token Tu over this message produced by the user. Upon invocation, it looks up a S HANGRI -L A instance from Hs id and retrieves its context. It further checks that: (1) the instance is in the Inactive state, (2) the provided counter u is consistent with the current usage (i.e., u ≥ usage + 1), (3) the invocation does not exceed limit, and (4) authenticity of Tu using pku . If all checks succeed, Secure World prepares execution of F in S HANGRI -L A as follows: it disables interrupts, sets the S HANGRI -L A state to Active, and allocates a dedicated stack at a fixed location (that does not overlap with memory-mapped peripheral regions) in Normal World. Next, Secure World marks F, datapub and datapriv as Non-Secure (see Figure 3b) and calls F entry point (entry ) to execute F with input InF in the Normal World. Once F execution completes, control returns to Secure World (this is achieved by requiring an NSC at the end of F). The Secure World then erases the S HANGRI -L A stack, restores S HANGRI -L A code and data to Secure state, increments the usage counter, and sets the lifecycle state back to Inactive before reenabling interrupts. If a proof of execution is required, Secure World generates Tproof by signing (F, u, data id, InF , OutF ) using the D EV-bound attestation key skD EV . Finally, it returns (Tproof , OutF ) to the caller.

5.2.5. Destroy (Line 41-46). This API tears down a S HANGRI -L A instance Hs id . Upon invocation, Secure World erases all sensitive data in datapriv . It then marks F, datapub and datapriv regions as Non-Secure, releasing the memory back to the Normal World. Finally, it sets the S HANGRI -L A lifecycle state to Non-Exist.

5.3. S HANGRI -L A Security Analysis We argue that S HANGRI -L A isolation abstraction achieves the following security properties: P1: Privilege Separation. We show that the four core APIs – Provision, Create, Execute (without proofof-execution), and Destroy – are sufficient to enforce the privilege model in Table 1. During Execute, F runs atomically with interrupts disabled, and control is not returned to Normal World until both F and Execute complete. This prevents Normal World from interrupting execution to access datapub or datapriv (which are in Non-Secure state) while S HANGRI -L A is in the Active state. A compromised Normal World may attempt to access S HANGRI -L A code and data outside the Active state. When S HANGRI -L A is in the Inactive state, such access is prevented by the SAU, as all S HANGRI -L A memory regions are marked Secure (Figure 3b). DMA-based attacks are mitigated in the same way, since the Secure/NonSecure memory attributes also apply to DMA accesses. The remaining opportunity is when S HANGRI -L A is in the Non-Exist state. In this state, F and datapub reside in Non-Secure flash and may be read or modified. However, any tampering is detected during Create, as the recomputed Hs id (over F and datapub ) will not match the provisioned value, preventing S HANGRI -L A from being created. For datapriv , confidentiality is preserved since it exists only in encrypted form in the Non-Exist state. A subtle case arises if the device resets while S HANGRI L A is in the Active or Inactive state, where datapriv or its derived runtime state may persist in Non-Secure RAM. To address this, we propose either: (i) extending SecureWorld initialization to clear all Non-Secure RAM at boot, or (ii) having Execute record the stack region in its context and extending Secure-World initialization to detect incomplete executions and securely erase the corresponding memory. We note that S HANGRI -L A always lives/executes in the Non-Secure state and therefore cannot access or interfere with higher-assurance Secure-World components. F code and data are only marked as Secure in between Create and Execute, but never executed in this state, being brought back to Non-Secure upon Execute invocation. This dynamic remarking indeed is what enables S HANGRI L A existence and an intermediate security state between Normal and Secure Worlds. At the same time, executing in the Non-Secure state allows S HANGRI -L A to access and reuse existing Non-Secure code when needed. As a result, these satisfy the privilege model in Table 1.

P2: Authorization of S HANGRI -L A Invocation. We show that, with the addition of the Authorize API, only authorized users can invoke F in S HANGRI -L A, and they cannot exceed the usage limit specified by the owner. An unauthorized user cannot execute F because their public key is not registered in the S HANGRI -L A (Secure World-protected) context. The Execute API requires a user message signed by the authorized user and verifies it against the authorized user’s public key pku . Without access to the corresponding private key, an adversary cannot produce a valid signature and thus cannot run a S HANGRI L A instance. Furthermore, Authorize updates the authorized user and usage limit only upon receiving a valid owner-signed message (verified using pko ). The usage counter is restricted to Secure World and checked during Execute to ensure that each invocation is fresh and does not exceed the specified limit. This prevents both overuse and replay attacks. P3: PoX Unforgeability. Finally, when the proof-ofexecution feature is enabled (proof = 1 in Execute), we show that a valid Tproof can only be produced if F is executed correctly within S HANGRI -L A. We adopt the notion of correct execution from prior work [17], where F must execute completely from its entry point to its exit point without interruption and the value of OutF must be determined by this execution. Tproof is generated inside Secure World via the Execute API using skD EV and covers (F, u, data id, InF , OutF ). Since skD EV is not accessible to the Normal World, an adversary cannot forge a valid Tproof . Consequently, a valid Tproof can only be obtained by successfully invoking Execute, which runs F with input InF inside S HANGRI -L A to produce the corresponding output OutF . Any attempt to modify InF or OutF results in an invalid proof, as both are cryptographically bound in Tproof . Also, interrupting F execution to induce an incomplete execution is not possible due to interrupts being disabled during F execution. A reset during Execute may cause F to terminate prematurely; however, in this case, no Tproof is produced, since it is generated only upon successful completion of Execute. In all cases, an adversary cannot forge Tproof without having to execute F inside S HANGRI -L A with the correct InF and produced OutF .

6. V E C O DI: Edge Inference Protocol Building on the S HANGRI -L A abstraction and its Secure-World APIs (Section 5), we present V E C O DI protocol realizing interactions I1–I4 defined in Section 3.

6.1. I1–I4 in V E C O DI I1: Provisioning P VD prepares the software F with entry point entry . F is a self-contained binary that bundles the input-retrieval code (e.g., a sensor driver), the inference library, and the glue code connecting them, executing both

back-to-back, i.e., it first retrieves the inference input directly from D EV’s hardware peripherals, then immediately runs DNN inference on it. Given a DNN model M , P VD assigns its ID as M ID and then applies a TSDP partitioning strategy to split it into Mpri and Mpub . It then generates kdec and uses it to encrypt Mpri . Using s id, P VD installs F, Mpub , and encrypted Mpri in the Normal World of D EV, while provisioning the corresponding S HANGRI -L A metadata to the Secure World via Provision API. Besides s id and kdec , this metadata also includes P VD’s public key pkP VD , and optionally the authorized user’s public key pkC SM and the usage limit. Note that V E C O DI is generic and supports both using and not using TSDP. In the latter case Mpri is the entire model and Mpub is empty. I2: Authorization C SM requests permission from P VD to invoke inference on D EV. If approved, P VD issues a signed authorization token TC SM that grants the user with public key pkC SM access to the S HANGRI -L A instance identified by Hs id with a usage limit limit. C SM forwards TC SM to D EV, which invokes the Authorize API to update the access policy of the corresponding S HANGRI -L A instance. Upon successful verification of TC SM , the Secure World registers pkC SM and limit for Hs id . I3: Inference To perform inference, C SM first invokes the Create API to instantiate the S HANGRI -L A instance identified by Hs id . It then constructs a request containing the next usage counter u, the input InF , the identifier Hs id , and a flag proof = 1 indicating that a proof of execution is required. This request is signed using skC SM to produce an inference token Tu . C SM submits the request and Tu to the Execute API. Upon successful verification, Execute runs the corresponding function F within S HANGRI -L A, which retrieves input data (e.g., from a sensor) and performs inference using M , producing an output OutF . Since proof = 1, this invocation returns a proof of execution Tproof . I4: Proof Verification C SM forwards (OutF , Tproof ) to V RF. V RF checks that Tproof is a valid token under pkD EV over the expected pkP VD , u, F, M ID , InF , and OutF .

6.2. V E C O DI Security Analysis We show that V E C O DI satisfies G1 and G2. Our arguments build on the security properties of S HANGRI -L A established in Section 5.3. G1-1 (Direct Leakage Protection). The DNN model M is partitioned into Mpub and Mpri , where Mpub is deliberately set as public by P VD. Thus, G1-1 concerns only the protection of Mpri . In V E C O DI, Mpri is treated as private data within S HANGRI -L A and therefore inherits P1: Privilege Separation that guarantees the access control guarantees in Table 1. In particular, untrusted Normal World on D EV cannot access Mpri in plaintext. Outside D EV, the only point at which Mpri is handled in plaintext is during I1: Provisioning by

P VD. As AM excludes P VD, AM cannot directly observe Mpri , satisfying G1-1. G1-2 (Indirect Leakage Protection). Indirect leakage through overused or unauthorized inference queries is mitigated through I2: Authorization in V E C O DI. Therein, C SM must obtain a valid TC SM from P VD, which will be enforced on D EV by the Authorize API before any inference can be executed through Execute. As a result, V E C O DI inherits P2: Authorization of S HANGRI -L A Invocation, preventing unauthorized AM from performing inference on M more than P VD’s specified usage limit. G2-1 (Authenticity). In V E C O DI, I3: Inference requires invoking the Execute API, thereby inheriting P3: PoX Unforgeability of S HANGRI -L A. In particular, any attempt by AI to forge an inference result OutF or its corresponding proof Tproof will be detected by V RF. Freshness is ensured through the inclusion of u in Tproof , where u serves as a nonce to prevent replay attacks. V RF can obtain an up-todate value of u from a trusted source, such as P VD. Moreover, since F encapsulates both input retrieval and inference, a valid Tproof guarantees that the inference input is obtained without being tampered with and that F executes completely without interruption. The acquisition of local D EV sensor inputs is implemented in F code and thus implicitly checked by checking F proper execution. As Tproof also covers authentic M ID and pkP VD (protected on D EV through Secure World’s secure storage), V RF can determine whether the inference is performed using the right DNN model M . In sum, V E C O DI assures that OutF is the authentic result of executing F on input InF using the model identified by M ID , as provisioned by P VD. Thus, G2-1 is fulfilled. G2-2 (Privacy). In I4: Proof Verification, verification relies on public information, including F, InF , M ID , pkP VD , OutF and Tproof . Importantly, the raw inference input is neither revealed nor required during verification, as it is acquired and processed internally within S HANGRI -L A (also not exposed to D EV’s Normal World). Hence, V E C O DI preserves D EV raw inputs privacy, satisfying G2-2.

7. Evaluation We implement V E C O DI on a NUCLEO-L552ZE-Q development board [14] with an ARM Cortex-M33 MCU, 192 KB of Normal-World SRAM (NS RAM), and 64 KB of Secure-World SRAM (S RAM). For DNN inference, we use ResNet [28], which is commonly used in low-end edge inference studies [27], [29], [30]. Following [27], we partition the model into Mpub and Mpri by placing the last three layers in Mpri . This yields |M | = 76.375 KB, with |Mpri | = 38.625 KB and |Mpub | = 37.75 KB. We perform I1: Provisioning offline by manually installing F, emulating secure factory provisioning; hence, provisioning time is excluded from our measurements. Additional

TABLE 2: TCB comparison: V E C O DI vs the baseline.

TABLE 3: Inference latency of V E C O DI vs. baseline.

V E C O DI API

LOC

% of Baseline (34,865 LOC)

NS baseline

V E C O DI

Overhead

Authorize Create Execute Destroy

264 576 451 232

0.76% 1.65% 1.29% 0.66%

1160.93 ms

1161.76 ms

0.83 ms (0.07%)

Total TCB

1523

4.36%

TABLE 4: V E C O DI latency breakdown. Metric

implementation details are provided in Appendix A, and limitations/extensions are discussed in Appendix B. Baseline. We compare V E C O DI against a baseline where F and inference-result generation execute entirely in the Secure World. To provide comparable security guarantees, the baseline authenticates inference requests and signs inference outputs using a D EV-bound key. This baseline corresponds to D2 in Section 4.1.

7.1. Results for G3-1 (TCB) The baseline runs F in the Secure World, so the TCB includes F, which is dominated by the CMSIS-NN library. The remaining code handles request authentication and output signing, which are negligible compared to the library. Table 2 reports the Secure-World TCB of D EV, broken down by component and compared to the baseline. As expected, Create and Execute have larger TCB contribution due to validation checks, memory management, and cryptographic operations. In contrast, Destroy has the smallest TCB, as it performs a simple operation of memory erasure. Compared to the baseline, V E C O DI reduces the TCB from 34,865 LOC to 1523 LOC (4.36% of the baseline). More importantly, the TCB on D EV is agnostic to F, and hence to sensor reading driver and inference library, making it unchanged across different combinations of sensorinput reading implementation and model architectures/DNN library (e.g., TensorFlow-Lite [31]). This contrasts with the baseline approach, where the TCB grows with a new F function, making it hard to realize for multiple F variants. This satisfies G3-1 (TCB).

7.2. Results for G3-2 (Memory) In the baseline, the full model M executes in the Secure World and is treated as confidential. To prevent extraction from Flash (Flash dump), M must be stored encrypted and decrypted into S RAM at runtime, creating two copies: ciphertext in Flash and plaintext in S RAM. In the test case, this requires 76.375 KB of S RAM (does not actually fit into the NUCLEO-L552ZE-Q available S RAM). In contrast, V E C O DI partitions M into Mpub and Mpri . Only Mpri is stored encrypted in Flash, while Mpub remains in plaintext and can be accessed directly from Flash at runtime. During execution, V E C O DI instantiates S HANGRI L A that decrypts Mpri into the protected NS RAM. Thus, only Mpri is duplicated, whereas Mpub exists as a single Flash-resident copy.

Cycles Latency (ms)

Authorize

Create

Execute

Destroy

50,273,157 457.03

8,423,049 76.57

127,793,297 1161.76

290,201 2.64

As a result, V E C O DI substantially reduces runtime memory duplication and moves the duplicated memory footprint away from S RAM. Unlike the baseline, the duplicated model portion Mpri resides in NS RAM (securely protected by S HANGRI -L A) rather than in S RAM, making more Secure-World memory available to other security-critical services. Also, since V E C O DI is agnostic to the partitioning strategy, deployments can further reduce memory overhead by selecting strategies that minimize the size of Mpri . This satisfies G3-2 (Memory).

7.3. Results for G3-3 (Latency) For G3-3 (Latency), we measure the end-to-end inference latency of Execute. All results reported are obtained as the average over 100 executions. For the baseline, the full decrypted model M requires about 76.375 KB. However, S RAM is limited to 64 KB, making the baseline infeasible for direct comparison. Instead, we use an NS baseline, which mimics the original baseline design but loaded in the Normal World, where a larger RAM size is available (192 KB). Table 3 reports the inference latency of V E C O DI (via the Execute API) and the NS baseline. Compared to the baseline, V E C O DI adds only 0.83 ms of latency, for a total runtime of 1161.76 ms. The overhead includes memory region reconfiguration, S HANGRI -L A stack setup and erasure, and state management. The PoX computation adds an additional 230.38 ms to generate the cryptographic signature/proof sent to V RF. However, in the baseline, the inference output must also be signed by the Secure World (to at least authenticate D EV), resulting in the same cost also applying to the NS baseline. The runtimes of the remaining operations are shown in Table 4. As the runtime of Create and Destroy depends on the size of Mpri , we further evaluate their runtime across varying Mpri sizes. Figure 4a shows that Create latency scales linearly with Mpri , increasing from 19.32 ms at 5 KB to 76.57 ms at 39.5 KB. By comparison, Destroy remains substantially faster (Figure 4b), ranging from 0.448 ms to 2.639 ms across the same configurations. In practical deployments, S HANGRI -L A construction and destruction would likely occur once per session rather than once per inference, making their amortized overhead small.

Latency (ms)

Latency (ms)

TABLE 5: Comparison with prior TrustZone (TZ)-based work on edge inference (∼ means partially-fulfilled).

3

80 60 40 20 0

2

0

5 10 15 20 25 30 35 39

5 10 15 20 25 30 35 39

Mpri size (KB)

Mpri size (KB)

(a) Create

TEE

G1-1

G1-2

G2-1

G2-2

G3-1

G3-2

G3-3

Darknetz [7] ShadowNet [8] ASGARD [32] SecureQNN [27]

TZ-A TZ-A TZ-A TZ-M

✓ ✓ ✓ ✓

∼ × × ∼

× × × ×

× × × ×

× × × ×

✓ ✓ × ✓

✓ × × ✓

V E C O DI

TZ-M

✓

✓

✓

✓

✓

✓

✓

1

(b) Destroy

Figure 4: Latency of Create and Destroy.

7.4. Case Study To validate V E C O DI in a realistic deployment setting, we implement a complete image classification pipeline on the NUCLEO-L552ZE-Q board (including image acquisition via UART from a hardware camera interface). D EV receives images over a UART-based camera stream, runs inference using the encrypted ResNet model, and returns classification results. This pipeline is included in our opensource repository. The case study follows V E C O DI protocol in Section 6.2: During I1: Provisioning, P VD partitions M and provisions both the model and F onto D EV in an offline phase. Next, in I2: Authorization, C SM obtains authorization from P VD and forwards the resulting TC SM to D EV, which updates the access policy with a bounded inference budget. During I3: Inference, C SM creates the corresponding S HANGRI -L A instance and issues inference requests within the authorized budget. Once the budget is exhausted, the S HANGRI -L A instance is destroyed. We then verify inference outcomes in I4: Proof Verification. Across 10 sequential inference executions, V E C O DI incurs an average latency of 1428.42 ms per inference compared to 1427.57 ms for the NS baseline, indicating negligible runtime overhead. Security tests. We further validate V E C O DI against attacker actions, consistent with our threat model, by executing one directed negative test per attack type: Memory Access Attacks. We attempt to read the S HANGRI -L A protected RAM region holding Mpri from Non-Secure code, and similarly attempt to write protected Flash regions mapped to S HANGRI -L A code. All cases trigger hardware faults and are blocked by SAU, confirming correct memory isolation. Protocol Attacks. We test three protocol violations: (i) replaying a previously valid inference request, (ii) issuing an inference request after budget exhaustion, and (iii) forging the session-model binding Hs id . All are rejected without modifying Secure state. These tests confirm that V E C O DI enforces authorization, freshness, and model-identity binding per goals introduced in Section 3.2. Combined with the low latency overhead (Section 7.3), the reduced Secure memory footprint, and the model-independent Secure TCB (Table 2), these results show that V E C O DI is a viable and secure approach for resource-constrained Cortex-M devices.

8. Related Work Secure DNN Inference with TEEs. Recent work uses TEEs to secure DNN inference on edge devices. One approach executes the entire inference pipeline inside a TEE and uses attestation for verifiability [9], [10], [11], [33]. However, these systems rely on higher-end hardware, such as custom GPUs [9], Intel SGX [10], or NVIDIA H100 [11], making them unsuitable for the low-cost devices targeted in this work. A lighter alternative is TEE-shielded DNN partitioning (TSDP) [5], which splits inference between protected layers inside the TEE and unprotected layers outside it. Prior work protects the exposed computation either by obfuscating layers/activations before offloading [6], [12], [13], or by selecting private layers to execute inside the TEE based on efficiency [5], [32], [19] or leakage risks [7], [8], [27]. However, both full-TEE inference and TSDP-based designs require inference-related code to reside inside the trusted environment. On TrustZone-based systems, this enlarges the Secure-World TCB and increases the attack surface. In contrast, V E C O DI executes inference code in S HANGRI -L A, at the same privilege level as untrusted software but shielded from it, avoiding inference-code inclusion in the Secure World. Since V E C O DI does not modify the model architecture or inference pipeline, it remains compatible with existing TSDP strategies. Table 5 compares V E C O DI with prior TrustZone-based systems. Verifiable Execution and Isolation on Edge Devices. Our S HANGRI -L A abstraction resembles enclave-/realmbased execution on higher-end platforms such as Intel SGX and ARM CCA. However, TrustZone does not natively provide such an abstraction for executing security-sensitive code in the Normal World while isolating it from other Normal-World software; this is especially challenging on TrustZone-M, which lacks virtual memory and user-space isolation. Prior work brings enclave-style execution to TrustZoneA [34], [35], but these designs rely on hardware features unavailable on low-end TrustZone-M devices: Penglai [34] requires an MMU, while Sanctuary [35] assumes multicore platforms. Other low-end-device mechanisms provide specific services, such as software integrity verification [36], [37], [38], [39], verifiable function execution [40], [17], [41], secure software updates [42], [43], confidential sensor input protection [44], [45], or compartmentalization [46]. While these approaches provide important building blocks, none of them achieves the full set of goals targeted in this work by themselves.

9. Conclusion We presented V E C O DI, a system architecture for confidential and verifiable DNN inference on ARM TrustZone-M platforms. V E C O DI builds on a new execution abstraction, S HANGRI -L A, which introduces a third execution environment in the Non-Secure World while enforcing strong isolation via Secure-World controls. This design allows inference code to run without expanding the Secure-World TCB, while still protecting sensitive model components and enabling verifiable execution.

References [1]

[2]

[3]

[4]

[5]

[6]

[7]

E. Li, L. Zeng, Z. Zhou, and X. Chen, “Edge ai: On-demand accelerating deep neural network inference via edge computing,” IEEE transactions on wireless communications, vol. 19, no. 1, pp. 447–457, 2019. M. Xue, Y. Zhang, J. Wang, and W. Liu, “Intellectual property protection for deep learning models: Taxonomy, methods, attacks, and evaluations,” IEEE Transactions on Artificial Intelligence, vol. 3, no. 6, pp. 908–923, 2021. F. Tramèr, F. Zhang, A. Juels, M. K. Reiter, and T. Ristenpart, “Stealing machine learning models via prediction {APIs},” in 25th USENIX security symposium (USENIX Security 16), pp. 601–618, 2016. S. Pinto and N. Santos, “Demystifying arm trustzone: A comprehensive survey,” ACM computing surveys (CSUR), vol. 51, no. 6, pp. 1–36, 2019. D. Li, Z. Zhang, M. Yao, Y. Cai, Y. Guo, and X. Chen, “Teeslice: Protecting sensitive neural network models in trusted execution environments when attackers have pre-trained models,” ACM Transactions on Software Engineering and Methodology, vol. 34, no. 6, pp. 1–49, 2025. J. Hou, H. Liu, Y. Liu, Y. Wang, P.-J. Wan, and X.-Y. Li, “Model protection: Real-time privacy-preserving inference service for model privacy at the edge,” IEEE Transactions on Dependable and Secure Computing, vol. 19, no. 6, pp. 4270–4284, 2021. F. Mo, A. S. Shamsabadi, K. Katevas, S. Demetriou, I. Leontiadis, A. Cavallaro, and H. Haddadi, “Darknetz: towards model privacy at the edge using trusted execution environments,” in Proceedings of the 18th International Conference on Mobile Systems, Applications, and Services, pp. 161–174, 2020.

[8]

Z. Sun, R. Sun, C. Liu, A. R. Chowdhury, L. Lu, and S. Jha, “Shadownet: A secure and efficient on-device model inference system for convolutional neural networks,” in 2023 IEEE Symposium on Security and Privacy (SP), pp. 1596–1612, IEEE, 2023.

[9]

S. Volos, K. Vaswani, and R. Bruno, “Graviton: Trusted execution environments on {GPUs},” in 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18), pp. 681–696, 2018.

[10] V. Duddu, L. J. Gunn, and N. Asokan, “Laminator: Verifiable ml property cards using hardware-assisted attestations,” in Proceedings of the Fifteenth ACM Conference on Data and Application Security and Privacy, pp. 317–328, 2024. [11] P. Chantasantitam, A. I. Caulfield, V. Duddu, L. J. Gunn, and N. Asokan, “Pal* m: Property attestation for large generative models,” arXiv preprint arXiv:2601.16199, 2026.

[18] J. Wang, Y. Wu, H. Liu, B. Yuan, R. Chamberlain, and N. Zhang, “Ip protection in tinyml,” in 2023 60th ACM/IEEE Design Automation Conference (DAC), pp. 1–6, 2023. [19] Z. Jian, X. Liu, Q. Dong, L. Cheng, X. Xie, and T. Li, “Smartzone: Runtime support for secure and efficient on-device inference on arm trustzone,” IEEE Transactions on Computers, vol. 74, no. 6, pp. 2144– 2158, 2025. [20] J. Gonzalez and P. Bonnet, “Tee-based trusted storage,” 2014. [21] T. Ban and D. Hu, “Physical attack mitigation in trusted firmware-m.” https://trustedfirmware-m.readthedocs.io/en/tf-mv2.1.1/design docs/ tfm physical attack mitigation.html, 2024. Accessed: 2026-05-26. [22] S. Pouyanrad, F. Alder, and J. T. Mühlberg, “Automated side-channel analysis of arm trustzone-m programs,” in European Symposium on Research in Computer Security, pp. 494–513, Springer, 2024. [23] X. M. Saß, R. Mitev, and A.-R. Sadeghi, “Oops..! i glitched it again! how to {Multi-Glitch} the {Glitching-Protections} on {ARM}{TrustZone-M},” in 32nd USENIX Security Symposium (USENIX Security 23), pp. 6239–6256, 2023. [24] J. Millar, Y. Huang, S. Sethi, H. Haddadi, and A. Madhavapeddy, “Benchmarking ultra-low-power µnpus,” in Proceedings of the 31st Annual International Conference on Mobile Computing and Networking, pp. 1060–1074, 2025. [25] A. Yazdanbakhsh, K. Seshadri, B. Akin, J. Laudon, and R. Narayanaswami, “An evaluation of edge tpu accelerators for convolutional neural networks,” arXiv preprint arXiv:2102.10423, vol. 1, no. 6, 2021. [26] Trusted Firmware-M Project, “Corstone SSE-320 with Ethos-U85 Example Subsystem for Ecosystem FVP.” https://tf-m.docs.trustedfir mware.org/en/latest/platform/arm/mps4/corstone320/README.html, 2026. Accessed: 2026-04-28. [27] M. Costa, T. Gomes, and S. Pinto, “Secureqnn: Shielding the intellectual property of qnns in tinyml systems,” IEEE Internet of Things Journal, vol. 12, no. 21, pp. 44642–44655, 2025. [28] S. Targ, D. Almeida, and K. Lyman, “Resnet in resnet: Generalizing residual architectures,” arXiv preprint arXiv:1603.08029, 2016. [29] S. K. Ghosh, A. Raha, and V. Raghunathan, “Energy-efficient approximate edge inference systems,” ACM Transactions on Embedded Computing Systems, vol. 22, no. 4, pp. 1–50, 2023. [30] X. Liu, Y. Song, Z. Li, J. Chi, L. Jiang, and J. Li, “Ed-res: Splitting resnet with collaborate distributed inference on edge devices,” in Proceedings of the 2025 ACM CoNEXT Workshop Edge-Cloud Collaboration for AI, pp. 38–43, 2025.

[12] F. Tramer and D. Boneh, “Slalom: Fast, verifiable and private execution of neural networks in trusted hardware,” arXiv preprint arXiv:1806.03287, 2018.

[31] R. David, J. Duke, A. Jain, V. Janapa Reddi, N. Jeffries, J. Li, N. Kreeger, I. Nappier, M. Natraj, T. Wang, et al., “Tensorflow lite micro: Embedded machine learning for tinyml systems,” Proceedings of machine learning and systems, vol. 3, pp. 800–811, 2021.

[13] H. Zhang, Z. Wang, M. Dhamankar, M. Fredrikson, and Y. Agarwal, “Verisplit: Secure and practical offloading of machine learning inferences across iot devices,” arXiv preprint arXiv:2406.00586, 2024.

[32] M. Moon, M. Kim, J. Jung, and D. Song, “Asgard: Protecting ondevice deep neural networks with virtualization-based trusted execution environments.,” in NDSS, 2025.

[14] STMicroelectronics, “NUCLEO-L552ZE-Q: STM32 Nucleo-144 Development Board with STM32L552ZE MCU.” https://www.st.com/e n/evaluation-tools/nucleo-l552ze-q.html, 2026. Accessed: 2026-0428.

[33] S. P. Bayerl, T. Frassetto, P. Jauernig, K. Riedhammer, A.-R. Sadeghi, T. Schneider, E. Stapf, and C. Weinert, “Offline model guard: Secure and private ml on mobile devices.,” 2020.

[15] A. Authors, “V E C O DI repo.” https://anonymous.4open.science/r/Ve CoDI-9BC0, 2026. [16] J. Ménétrey, C. Göttel, A. Khurshid, M. Pasin, P. Felber, V. Schiavoni, and S. Raza, “Attestation mechanisms for trusted execution environments demystified,” in IFIP International Conference on Distributed Applications and Interoperable Systems, pp. 95–113, Springer, 2022. [17] I. D. O. Nunes, K. Eldefrawy, N. Rattanavipanon, and G. Tsudik, “{APEX}: A verified architecture for proofs of execution on remote devices under full software compromise,” in 29th USENIX Security Symposium (USENIX Security 20), pp. 771–788, 2020.

[34] E. Feng, X. Lu, D. Du, B. Yang, X. Jiang, Y. Xia, B. Zang, and H. Chen, “Scalable memory protection in the {PENGLAI} enclave,” in 15th {USENIX} Symposium on Operating Systems Design and Implementation ({OSDI} 21), pp. 275–294, 2021. [35] F. Brasser, D. Gens, P. Jauernig, A.-R. Sadeghi, and E. Stapf, “Sanctuary: Arming trustzone with user-space enclaves.,” in NDSS, vol. 100, p. 102, 2019. [36] K. Eldefrawy, G. Tsudik, A. Francillon, and D. Perito, “Smart: secure and minimal architecture for (establishing dynamic) root of trust.,” in Ndss, vol. 12, pp. 1–15, 2012.

[37] I. D. O. Nunes, K. Eldefrawy, N. Rattanavipanon, M. Steiner, and G. Tsudik, “{VRASED}: A verified {Hardware/Software}{CoDesign} for remote attestation,” in 28th USENIX Security Symposium (USENIX Security 19), pp. 1429–1446, 2019. [38] J. Noorman, P. Agten, W. Daniels, R. Strackx, A. Van Herrewege, C. Huygens, B. Preneel, I. Verbauwhede, and F. Piessens, “Sancus: Low-cost trustworthy extensible networked devices with a zerosoftware trusted computing base,” in 22nd USENIX Security Symposium (USENIX Security 13), pp. 479–498, 2013. [39] I. D. O. Nunes, S. Jakkamsetti, N. Rattanavipanon, and G. Tsudik, “Toward remotely verifiable software integrity in resource-constrained iot devices,” IEEE Communications Magazine, vol. 62, no. 7, pp. 58– 64, 2024. [40] N. Rattanavipanon and I. D. O. Nunes, “Slapp: Poisoning prevention in federated learning and differential privacy via stateful proofs of execution,” IEEE Transactions on Information Forensics and Security, 2025. [41] A. J. Neto, N. Rattanavipanon, and I. D. O. Nunes, “Pearts: Provable execution in real-time embedded systems,” in 2025 IEEE Symposium on Security and Privacy (SP), pp. 3765–3782, IEEE, 2025. [42] I. De Oliveira Nunes, S. Jakkamsetti, Y. Kim, and G. Tsudik, “Casu: Compromise avoidance via secure update for low-end embedded systems,” in Proceedings of the 41st IEEE/ACM International Conference on Computer-Aided Design, pp. 1–9, 2022. [43] I. De Oliveira Nunes, K. Eldefrawy, N. Rattanavipanon, and G. Tsudik, “Pure: Using verified remote attestation to obtain proofs of update, reset and erasure in low-end embedded systems,” in 2019 IEEE/ACM International Conference on Computer-Aided Design (ICCAD), pp. 1–8, IEEE, 2019. [44] I. D. O. Nunes, S. Hwang, S. Jakkamsetti, and G. Tsudik, “Privacyfrom-birth: Protecting sensed data from malicious sensors with versa,” in 2022 IEEE Symposium on Security and Privacy (SP), pp. 2413– 2429, IEEE, 2022. [45] P. De Vaere, F. Stöger, A. Perrig, and G. Tsudik, “The sa4p framework: Sensing and actuation as a privilege,” in Proceedings of the 19th ACM Asia Conference on Computer and Communications Security, pp. 873–885, 2024. [46] L. Tyler and I. D. O. Nunes, “Untrusted code compartmentalization for bare metal embedded devices,” IEEE Transactions on ComputerAided Design of Integrated Circuits and Systems, vol. 43, no. 11, pp. 3419–3430, 2024. [47] Trusted Firmware Project, “Trusted Firmware-M (TF-M).” https://ww w.trustedfirmware.org/projects/tf-m/, 2026. Accessed: 2026-04-28. [48] L. Lai, N. Suda, and V. Chandra, “Cmsis-nn: Efficient neural network kernels for arm cortex-m cpus,” arXiv preprint arXiv:1801.06601, 2018. [49] A. Caulfield, N. Rattanavipanon, and I. De Oliveira Nunes, “Asap: reconciling asynchronous real-time operations and proofs of execution in simple embedded systems,” in Proceedings of the 59th ACM/IEEE Design Automation Conference, pp. 721–726, 2022.

Appendix A. Implementation Details We implement V E C O DI on a NUCLEO-L552ZE-Q development board [14], which integrates an ARM CortexM33 MCU running at 110MHz with 512KB of Flash memory and 256KB of SRAM, where 192KB is used for the Normal World (NS RAM) and the remaining 64KB is reserved for the Secure World (S RAM). Secure World Setup. The Secure World runs Trusted Firmware-M (TF-M) [47], a reference Secure Processing

Environment for Armv8-M systems. We extend TF-M to implement V E C O DI Secure-World APIs on D EV. Specifically, we use the TF-M Crypto Partition to provide cryptographic services and expose them to the Normal World via NSC veneers. For digital signatures on D EV, we rely on TFM’s ECDSA APIs (PSA_ALG_ECDSA) for signing and verification. At boot, TF-M configures five of the eight SAU regions. Regions 0 and 1 map the Flash and SRAM assigned to the Normal World. Regions 2-4 are reserved for NSC veneers, peripherals, and platform-specific registers, and are left unchanged by our implementation. When an S HANGRI -L A instance enters the Inactive state via the Create API, it dynamically reconfigures additional SAU regions to isolate its code and data. For SRAM, Region 1 is disabled, while Regions 6 and 7 are configured to cover all NS RAM except the private-data region, which thus becomes part of Secure state by default. For Flash, we reconfigure Region 0 to cover the area preceding the S HANGRI -L A code and public data, and Region 5 to cover the following region up to Secure Flash. Upon transitions to other lifecycle states, the Secure-World APIs restore the SAU configuration to its boot-time defaults. S HANGRI -L A Setup. In our experiments, F running inside S HANGRI -L A performs two tasks: (1) acquiring an inference input and (2) executing inference. For (1), we use a simple routine that reads an image from Flash memory to establish a lower-bound timing baseline. A real-world sensor pipeline using an external camera is presented later in Section 7.4. For (2), we use the CMSIS-NN library [48], which provides optimized DNN kernels with low memory overhead for Arm Cortex-M processors. As our target model, we adopt ResNet [28], a lightweight architecture widely used in prior edge-inference work [27], [29], [30]. Following CMSIS-NN guidelines, we apply fixed-point quantization, resulting in a model size of 76.375KB. With ResNet, V E C O DI supports arbitrary TSDP partitioning strategies that split the model into Mpub and Mpri . In our evaluation, we follow [27], designating the final three layers of ResNet as private to reduce the risk of model-stealing attacks. These layers form Mpri and are provisioned in encrypted form in Flash during I1, while the remaining layers Mpub remain unprotected. As such, the full model size is |M | = 76.375 KB, with |Mpri | = 38.625 KB and |Mpub | = 37.75 KB.

Appendix B. Discussion, Limitations, and Extensions Multiple Inferences per Execution. Our case study focuses on producing a proof for a single inference while preserving model confidentiality. However, the design can be extended to support verifiable execution over multiple sensor inputs within a single invocation. Rather than invoking Execute repeatedly, F can be written in a way to accept an additional parameter specifying the number of sensor readings to acquire. During execution, F records multiple inputs within the S HANGRI -L A stack. After collecting the required number of inputs, F performs batched inference

over the recorded data, producing a vector of outputs. Since S HANGRI -L A generates a proof that binds execution to the correct invocation of F, the resulting proof can also attest that the output vector was produced from the specified batch of inputs under a single execution context. Supporting this extension would additionally require Execute to account for the total number of inferences performed within one invocation when enforcing the authorized usage limit. Interrupt-driven F. To ensure verifiable execution, V E C O DI currently relies on S HANGRI -L A to disable interrupts during execution of F. As a result, F must not depend on interrupt-driven behavior. While this assumption holds in our case study, it may not apply to applications where F relies on interrupt-triggered sensor inputs. One possible extension is to incorporate an interrupt-compatible proof-of-execution mechanism such as [49]. Doing so permits interrupts during execution by enforcing read-only protection over program memory and the interrupt vector table (IVT), while computing a hash of the IVT snapshot before execution begins. The resulting hash can then be incorporated into Tproof or the generated proof to preserve execution integrity despite interrupt handling. Cryptographic Choice. V E C O DI protocol relies on public-key cryptography for authentication and proof generation. While this overhead is generally acceptable for P VD, C SM, and V RF, it may be expensive for resource-constrained D EV-s. In V E C O DI, D EV maintains three keys: pkP VD , pkC SM , and skD EV . The first two are used to authenticate requests in Authorize and Execute, respectively, while skD EV is used to generate Tproof . To reduce computational overhead on D EV, V E C O DI can replace public-key operations with symmetric-key ones. Since P VD controls provisioning, it may install a shared symmetric key k1 during Provision instead of relying solely on pkP VD . Then, during I2: Authorization, P VD first authenticates C SM through standard PKI. Upon successful authentication, C SM generates a fresh symmetric session key k2 and securely provides it to P VD. P VD then constructs a Authorize request encrypted (via authenticated encryption) using k1 , embedding both the authorization policy and k2 . After receiving the request, D EV decrypts it using k1 , recovering k2 and using it in place of (skC SM , pkC SM ) in subsequent interactions. However, replacing skD EV with a symmetric key introduces additional trust assumptions. In particular, V RF would need to share the same secret key with D EV in order to validate proofs, requiring V RF to be trusted. This changes the stakeholder model described in Section 4, where AM can include V RF. Moreover, by design, a symmetrickey option does not support multiple mutually distrusting V RF-s, since all of them would need access to the same shared secret. One possible workaround is to designate P VD as the sole V RF. Under this model, external parties seeking to validate Tproof would query P VD, who performs verification on their behalf.