SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

Digital Object Identifier 10.1109/ACCESS.2024.0429000

SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings AMARIN LAOHAJIRAPAN1 , NORRATHEP RATTANAVIPANON2

1 2

College of Computing, Prince of Songkla University, Phuket Campus, Phuket, Thailand (e-mail: 6730621007@psu.ac.th) College of Computing, Prince of Songkla University, Phuket Campus, Phuket, Thailand (e-mail: norrathep.r@psu.ac.th)

arXiv:2607.23698v1 [cs.CR] 26 Jul 2026

Corresponding author: Norrathep Rattanavipanon (e-mail: norrathep.r@psu.ac.th).

ABSTRACT Remote attestation (RA) is a lightweight security primitive for detecting software compromise on IoT devices. Traditional RA schemes require atomic, non-interruptible memory measurements, making them difficult to deploy alongside real-time workloads. SMARM addresses this limitation by measuring memory in a secret, shuffled block order, reducing the non-interruptibility period to the duration of a single block measurement. However, SMARM was originally designed for microkernel-based systems and has not been studied in RTOS-driven real-time environments. In this work, we present the first systematic study of SMARM in real-time RTOS-based setups. We implement SMARM on commodity ARM TrustZone-M hardware running FreeRTOS and Zephyr, and introduce the Frequency Accuracy Ratio (FAR) to quantify the extent to which attestation can coexist with real-time execution under varying workloads. Our evaluation shows that SMARM’s real-time compatibility is highly sensitive to block size: large blocks significantly degrade real-time availability, while small blocks incur substantial secure-storage overhead, limiting deployability on memory-constrained devices. To address this limitation, we propose SMARM+, a family of enhanced SMARM variants consisting of SMARM+PRNG and SMARM+FPE. They are designed to reduce secure-storage requirements while preserving SMARM’s security guarantees and real-time behavior. Our evaluation highlights the trade-off between secure-storage reduction, attestation runtime, and energy overhead, and provides guidance on selecting among SMARM, SMARM+PRNG, and SMARM+FPE for different deployment settings. INDEX TERMS Remote attestation, real-time IoT systems, TrustZone-M, RTOS, IoT security, formatpreserving encryption.

I. INTRODUCTION

I

convince the verifier that it is currently running an expected software configuration, and thus is free from a malware compromise. As illustrated in Figure 1, a typical RA protocol consists of three steps:

To address this challenge, Remote Attestation (RA) has emerged as a lightweight security primitive for detecting software compromise on such devices. At a high level, it is a challenge-response protocol between a constrained IoT device, referred to as the prover, and a more powerful entity acting as the verifier. The goal of RA is for the prover to

(1) The verifier sends a fresh challenge (e.g., a random nonce or a monotonically increasing counter) to the prover. (2) Upon receiving the challenge, the prover computes an authenticated integrity measurement – realized as either a message authentication code (MAC) or a digital signature – over its program memory along with the received challenge, and returns the result as attestation evidence to the verifier. (3) The verifier checks the evidence against a known reference value corresponding to a valid software state; a successful match assures the verifier that the prover is

NTERNET-OF-THINGS (IoT) devices have become integral to modern society, widely deployed in many domains, such as smart healthcare, industrial automation, and smart infrastructure. As their usage continues to grow (approaching 20 billion devices worldwide as of 2025 [1]), they have also become attractive targets for large-scale malware attacks [2]. However, due to the resource-constrained nature, deploying sophisticated security mechanisms (e.g., anti-virus) is often impractical in IoT devices.

VOLUME 11, 2023

1

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

FIGURE 1: Remote Attestation (RA) workflow and memory measurement strategies. not infected by malware. To prevent roving malware [3] that relocates itself to evade detection, traditional RA techniques [4]–[6] require the computation in Step (2) to execute atomically, i.e., with interrupts disabled. While effective, this approach also prevents normal applications from executing in Step (2), rendering such schemes unsuitable for real-time systems. SMARM [3] was proposed as an alternative memory measurement strategy to relax the atomicity requirement. As illustrated in Figure 1, rather than measuring program memory sequentially with interrupts disabled, SMARM allows interrupts to be re-enabled after each memory block is measured. On its own, this relaxation would permit roving malware to interrupt the measurement task in Step (2) and relocate itself to evade detection. Hence, SMARM proposes an additional technique to mitigate this by measuring the memory blocks in a private and random (i.e., shuffled) order. To be secure, SMARM safeguards the shuffled order in a secure storage that cannot be accessed by untrusted software. Intuitively, since the roving malware does not know which memory blocks have already been measured, its probability of successfully evading detection is significantly reduced. With this technique, SMARM reduces the non-interruptibility period from the entire program memory to a single-block measurement, substantially improving real-time availability of RA. In this work, we observe two limitations of SMARM. First, SMARM was designed and prototyped atop the HYDRA architecture [5], which relies on a formally verified seL4 microkernel [7] to secure the measurement task and store the shuffled order. While this design provides strong security guarantees due to the formal verification of seL4, realtime IoT deployments commonly rely on lightweight RTOSes such as FreeRTOS, rather than microkernel-based systems. As such, it limits the practicality and wide-scale adoption of SMARM in RTOS-based systems. Second, SMARM was evaluated in experimental settings that do not consider realtime workloads. Although the results show a significant reduction in the non-interruptibility period, it remains unclear whether SMARM can truly co-exist with real-time systems. In light of these limitations, this work makes the following 2

contributions: • Design and implementation of SMARM on RTOSbased platforms (Section III). We present a design and implementation of SMARM that is compatible with widely-adopted RTOSes. The key challenge is to preserve SMARM’s security guarantees without relying on a formally verified microkernel, while maintaining compatibility with RTOS-based execution environments. To resolve this challenge, our design leverages the ARM TrustZone-M security extension as a trust anchor in place of seL4. TrustZone-M is increasingly available on modern MCU platforms [8], making our solution practical and readily deployable on off-the-shelf realtime IoT devices. • Evaluation of SMARM under real-time workloads (Section IV). We present the first systematic evaluation of SMARM in real-time environments using two widely deployed RTOSes, FreeRTOS and Zephyr. To quantify real-time coexistence during attestation, we introduce a new metric, Frequency Accuracy Ratio (FAR). Our results show that SMARM’s real-time compatibility is highly sensitive to the measurement block size: small blocks preserve near-ideal task execution, whereas larger blocks significantly degrade real-time availability. On the other hand, achieving real-time compatibility requires smaller blocks, which substantially increase SMARM’s secure-storage requirement, exposing a key limitation for deployment on highly resourceconstrained MCUs. • Addressing SMARM limitation (Section V-VI). We propose SMARM+, enhanced variants of SMARM that reduce secure-storage requirements while preserving real-time compatibility and security guarantees. The first variant (SMARM+PRNG) reduces storage from O(n log n) to O(n) bits while the second (SMARM+FPE) further reduces storage to O(1). Our evaluation shows that both variants incur different performance overheads, demonstrating a trade-off between secure-memory usage, attestation latency, and energy consumption. II. BACKGROUND

This section reviews the background of SMARM and ARM TrustZone-M architecture used as basis in this work. A. SMARM: SHUFFLED MEASUREMENTS AGAINST ROVING MALWARE

Remote attestation (RA) for low-end embedded devices has traditionally relied on atomic memory measurements, as in SMART, HYDRA, and VRASED, where the entire attested memory region is hashed in a single non-interruptible sweep with interrupts disabled [4]–[6], [9]. These designs provide strong security guarantees but inherently conflict with realtime workloads, since they block all interrupts for a period that scales with the size of the attested memory. The key idea of SMARM [3] is to enhance the RA workflow (see Figure 1) VOLUME 11, 2023

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

by measuring memory in a shuffled (i.e., unpredictable and private) order. Specifically, SMARM partitions the prover’s memory into n fixed-size blocks, M = {M1 , . . . , Mn }, which are measured according to a one-time shuffled order rather than a fixed/predictable sequence. Figure 2 illustrates the SMARM workflow. Upon receiving a one-time challenge, chal, from the verifier, a secure environment on the prover computes an attestation response via the following steps:

FIGURE 2: The workflow of SMARM [3] 1) Permutation Generation. The prover computes a permutation σ over the memory block indices [1, . . . , n], where σ determines the measurement order for the current attestation instance, i.e., the block Mσ(i) is measured at step i. SMARM’s main security requires σ to be fresh and private for each attestation instance; to achieve these, SMARM instantiates this permutation using the Fisher-Yates shuffle method [10]: σ = FisherYates(seed, [0, . . . , n − 1]), where its PRNG seed is derived from k and chal: k is a pre-shared secret key between the prover and the verifier, and chal is the verifier’s challenge. After this, it stores σ in secure storage and initializes the loop counter i to 0. 2) Atomic Block Measurement. At iteration i, the prover’s secure environment retrieves σ(i) from secure storage, disables system-wide interrupts, and measures (i.e., hashes) the corresponding memory block Mσ(i) . After the measurement, it re-enables interrupts and increments i. 3) Loop Check. The secure environment checks whether all memory blocks have been measured by testing whether i = n. If not, it repeats the previous step. 4) Finalization. After all blocks in M have been measured, the prover’s secure environment computes a MAC over the final measurement using the key k and sends the result to the verifier as the attestation response. With possession of k and chal, the verifier can reconstruct the permutation used in the current instance and thereby VOLUME 11, 2023

validate the received attestation response against the expected measurement of M . a: Security

SMARM considers a threat model in which the adversary can exploit software vulnerabilities on the prover to gain control over all software except for the secure execution environment and secure storage. In particular, the adversary is allowed to read/write and execute arbitrary code anywhere in the prover’s memory. In addition, SMARM assumes a Knowledge of Future Volume (KFV) malware, which may use the aforementioned capabilities to interrupt the secure execution after each block measurement and learn how many memory blocks have already been measured. Under this threat model, SMARM provides a theoretical analysis of its defense. Assuming the worst-case scenario in which the malware fits entirely within a single memory block, the optimal evasion strategy for KFV malware is to interrupt after each block measurement and relocate itself to a different block. For large n, this strategy yields an evasion probability converged to approximately 37% [3]. To increase the likelihood of detection, SMARM proposes repeating the shuffled measurements multiple times for each attestation instance; for example, performing the shuffled measurements seven times reduces the evasion probability to below 10−3 [3]. To meet security, SMARM assumes architectural support for a secure execution environment that provides the following security guarantees: (S1) Controlled execution: the attestation code can only be invoked and return via well-defined entry and exit points (i.e., no mid-code entry or early exit), and it may only be interrupted between consecutive block measurements; (S2) Key secrecy: the attestation key k is accessible exclusively to the attestation code; and (S3) Private measurement order: the order in which memory blocks are measured must not be known by KFV malware. This is realized by keeping the permutation σ in memory that is inaccessible to untrusted software.

FIGURE 3: SMARM prototype atop the HYDRA architecture.

b: Implementation

In its prototype (shown in Figure 3), SMARM realizes this secure execution environment using the HYDRA architec3

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

ture [5], which targets MMU-equipped devices and is built atop the formally verified seL4 microkernel [7]. Leveraging seL4’s verified isolation properties, HYDRA executes the attestation code within a privileged user-space task, referred to as the measurement task. This task is isolated from all other user-space tasks, can access all device memory required for measurement while its own memory remains inaccessible to other tasks. To enforce (S1), the measurement task can only be invoked via a dedicated IPC endpoint and returns solely with the attestation response. At runtime, the measurement task is initially assigned the highest priority, ensuring that it cannot be preempted while measuring a memory block. After completing each block measurement, the task lowers its priority and explicitly yields the CPU execution, allowing other tasks (malicious or real-time tasks) to execute between consecutive measurements. When the measurement task is scheduled again, it restores its priority to the highest level and proceeds with the next atomic block measurement. Finally, HYDRA configures access control of memory regions in seL4 such that only the measurement task can access k and σ, thereby satisfying (S2) and (S3). c: Evaluation

The security of SMARM fundamentally relies on the secrecy of the permutation σ, which necessitates secure storage that is inaccessible to untrusted software. For a prover memory M partitioned into n blocks, SMARM requires at least |σ| = n · ⌈log2 n⌉ bits of secure storage to store σ, making the overhead linear in n. Reducing the secure storage requirement therefore necessitates lowering the value of n. However, as each block has size B = |M |/n, a smaller n implies a larger block size to be measured atomically. This, in turn, increases the noninterruptibility period tdisabled during attestation in SMARM. As a result, SMARM exhibits an inherent trade-off between secure storage size and real-time availability. SMARM evaluates this trade-off on the i.MX6 SabreLite platform, a development board representative of low-cost IoT devices [3], [11]. Figure 4 illustrates the tension: increasing the block size B (equivalent to reducing n) alleviates the secure storage requirement, but it also increases tdisabled . Conversely, selecting a small B minimizes tdisabled (improving real-time availability during attestation) at the cost of a much larger secure storage overhead, which may be impractical for resource-constrained devices. In addition, SMARM performed an additional experiment that evaluates the overall attestation runtime under different values of two parameters: tdisabled and tslice , where the latter represents a time-slice duration that a normal application task runs between consecutive block measurements. The results showed that both tdisabled and tslice directly affect the total attestation time with their high value leading to a longer attestation time. Nonetheless, the work in [3] did not evaluate the extent to which the SMARM technique impacts the realtime guarantees of time-sensitive tasks, leaving it unclear 4

FIGURE 4: SMARM trade-off between non-interruptibility period tdisabled and secure storage requirement |σ| for a fixed memory size |M | = 256 MB on the i.MX6 SabreLite device.

which block size should be used in a given strict real-time setting. B. TRUSTZONE-M ARCHITECTURE

ARM TrustZone for Cortex-M [12] (or TrustZone-M in short) provides a production-ready Trusted Execution Environment (TEE) for low-cost IoT devices. TrustZone-M is commercially available on Cortex-M microcontrollers, which are estimated to be deployed in over 22 billion devices worldwide [8]. It provides hardware-enforced isolation by partitioning software execution into two isolated runtime environments: the Secure and Non-Secure worlds. Following the TEE’s design principle, TrustZone-M runs untrusted application software (including RTOS and user applications) in the Non-Secure world, while placing small security-critical software in the Secure world. Although isolated, both worlds still execute on the same physical CPU core, sharing the system’s interrupts; these interrupts are globally managed by the Nested Vectored Interrupt Controller (NVIC), allowing interrupts to happen cross-world boundaries. As a result, execution in the Secure world may be interrupted by the Non-Secure world; also it is possible for the Secure world to disable all sources of interrupts (e.g., via the CPSID instruction), thereby preventing the Non-Secure world from executing and enabling atomic execution of a Secure-world function. In this work, we rely on the following security properties offered by TrustZone-M: •

Isolation at Hardware Level. TrustZone-M provides strong separation between the Secure and Non-Secure worlds through dedicated hardware components: the Security Attribution Unit (SAU) and the ImplementationDefined Attribution Unit (IDAU), which jointly define the security attribution of memory and peripherals at the hardware level [12]. These components govern access to all system resources including program/data memory and peripherals. As a result, code executing in the NonSecure world cannot read or modify Secure-world code VOLUME 11, 2023

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

or data, even in the presence of a fully compromised Non-Secure software stack. • Restricted Secure-World Entry. TrustZone-M restricts access to Secure-world functionality to a set of explicitly defined entry points located in the Non-Secure Callable (NSC) region. This region is part of Secure memory and is protected from modification by Non-Secure software. Together with TrustZone-M’s secure state transition mechanism (enforced in hardware), this restriction ensures that Secure-world functions are invoked only in their entirety. Recent studies of TrustZone-M based IoT systems highlight that misconfiguration, improper partitioning of peripherals, and weak key storage practices can undermine the intended isolation guarantees, leading to practical exploits even when the hardware security extensions are present [13], [14]. These findings motivate our use of TrustZone-M as a tightly scoped root of trust: SMARM+ confines security-critical state (e.g., attestation keys and permutation metadata) to the Secure world, while treating the Non-Secure RTOS and application stack as fully adversarial.

to contain many kernel-level vulnerabilities, e.g., CVE-201816525 that enables remote code execution in FreeRTOS or CVE-2024-6137 that leads to malicious writes to Zephyr’s kernel memory [19], [20]. An adversary can exploit such vulnerabilities to break isolation, rendering SMARM insecure on these platforms. Therefore, simply replacing seL4 with an RTOS of choice is insufficient to make SMARM secure. Instead, our design leverages ARM TrustZone-M to provide hardware-enforced isolation mechanisms available on off-the-shelf embedded platforms. Next, we describe the system model considered in this work, followed by the corresponding threat model. B. SYSTEM & THREAT MODEL TrustedZone-M Hardware Isolation Boundery

Non-Secure World

Secure World (Trusted TEE)

Adversary (Untrusted/Compromised) Control

Real-time Application Tasks

SMARM Wrapper Task

RTOS Kernel

Trusted

Secure Storage Attestation Key

SMARM Service

Permutation

III. REALIZATION OF SMARM ON RTOS-BASED SYSTEMS

This section describes our efforts to realize SMARM in RTOS systems. We begin by discussing the non-trivial challenges that preclude a simple extension of existing SMARM prototype (HYDRA-based one) to RTOS, thereby motivating the need for a new direction in this work. A. CHALLENGES OF ADAPTING SMARM TO RTOS

A naive approach is to adapt HYDRA-based prototype of SMARM to operate atop an RTOS. In principle, this would correspond to replacing the seL4 microkernel with an RTOS kernel while leaving user-level tasks (including the measurement task) unchanged. However, such an approach raises several security issues. Recall the HYDRA-based SMARM prototype in Figure 3. First, to satisfy (S1)-(S3), it relies on seL4’s isolation guarantees to protect the measurement task (that implements the SMARM logic) from other untrusted tasks. These isolation guarantees are absent in commonly deployed RTOSes. For example, vanilla FreeRTOS [15], the most commonly used RTOS in commercial real-time embedded systems, operates under bare-metal settings in which all tasks execute at the same privilege level. As a result, other (potentially compromised) tasks can freely access all system resources, including k and σ used by the measurement task, hence easily breaking (S2) and (S3). Similarly, the default configuration of NuttX [16] provides no inter-task isolation. Even when considering RTOSes that offer some form of memory isolation, e.g., the MPU version of FreeRTOS [17] or Zephyr OS [18], these protections are not backed by formal verification, unlike seL4. This means their security guarantees only hold as long as the kernel itself remains uncompromised. In practice, these RTOSes have been shown VOLUME 11, 2023

CPU Core

TrustZone-M(SAU/IDAU)

NVIC (Interrupt Controller)

ARM Cortex-M Hardware Layer

FIGURE 5: Our proposal of SMARM on RTOS using TrustZone-M We consider a prover implemented on an ARM CortexM device equipped with TrustZone-M, which divides execution into two runtime environments: the Secure world (trusted TEE) and Non-Secure worlds (untrusted). The NonSecure world hosts untrusted software including the RTOS kernel and real-time application tasks. In contrast, SMARM’s security-critical logic is assumed to be trusted, resides in the Secure world and is accessible from the Non-Secure world only via a NSC call. We adopt the same threat model as SMARM: an adversary can exploit software vulnerabilities to gain full control over all untrusted software. Under our system model, this corresponds to the adversary fully compromising the entire Non-Secure world. Since the Secure world is assumed to be trusted, the adversary cannot tamper with the SMARM logic residing in the Secure world. In addition, we consider KFV malware that can interrupt Secure-world execution after each block measurement (via NVIC control; see Section II-B), with the aim of relocating malicious code across memory blocks to evade detection. Following SMARM, we consider hardware/physical attacks, side-channel attacks and denialof-service (DoS) attacks to be out of scope. C. SMARM ON RTOS USING TRUSTZONE-M

We propose a new realization of SMARM that coexists with an RTOS and real-time application tasks without requiring 5

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

Algorithm 1 Pseudocode of SMARM Service Notation: Memory M , block size B, number of blocks n, key k, challenge chal 1: seed ← Hash(chal, k) 2: σ = FisherYates(seed, [0, . . . , n − 1]) 3: HMAC.Init(k) 4: for i ← 0 to n − 1 do 5: DisableInterrupts 6: HMAC.Update(hmac, Mσ[i] , B) 7: EnableInterrupts 8: end for 9: att-evidence ← HMAC.Finalize(hmac) Output: att-evidence

custom hardware. Unlike the naive approach discussed in Section III-A, this design leverages the hardware-enforced isolation provided by TrustZone-M, retaining SMARM’s security even if an adversary fully compromises all untrusted software in the Non-Secure world. 1) Components

In addition to the unmodified RTOS kernel and real-time application tasks, we decompose SMARM into two components, as illustrated in Figure 5. Wrapper Task. The Wrapper Task is implemented as a regular RTOS task executing in the Non-Secure world. It serves as an interface between the verifier (or other tasks responsible for prover-verifier communication) and the Secureworld SMARM logic. Upon receiving an attestation request, the wrapper task invokes the Secure Service, obtains the attestation evidence, and forwards it to the verifier. To allow preemption by real-time tasks, we configure the wrapper task to run at the lowest priority. Secure Service. The Secure Service resides entirely in the Secure world and is exposed to the Non-Secure world via an NSC entry point. When invoked with an attestation request, it executes the SMARM logic as described in Section II-A and detailed in Algorithm 1, then returning the attestation evidence to the caller. To enforce atomic block measurements, the service disables interrupts via the CPSID instruction immediately before each block measurement and re-enables them upon completion. As a result, (S1) is guaranteed in this design by preventing partial execution of the Secure Service and disallowing interruptions during block measurements. To satisfy (S2), we store the attestation key k persistently in Secure storage that is accessible only from the Secure world. At runtime, all k-related materials reside in Secure RAM, which is inaccessible to the Non-Secure world. Similarly, to satisfy (S3), the permutation σ, once generated, is not exposed to Non-Secure RAM and therefore cannot be inferred by KFV malware. KFV malware cannot also perform replay attacks since σ is based on a one-time challenge chal and a secret k. 2) Security

Since the SMARM Service satisfies all three security requirements (S1)–(S3), our new realization of SMARM retains the 6

same security guarantees as the original SMARM design [3]. The SMARM Wrapper Task, in contrast, is not part of the trusted computing base (TCB) and serves only a functional role: it enables attestation requests from the untrusted NonSecure world to invoke the SMARM Service. Accordingly, this wrapper task can be treated as untrusted and executed entirely in the Non-Secure world. Indeed, an adversary may compromise this wrapper; however, such a compromise does not enable the adversary to forge valid attestation evidences or to gain more information than what is already achievable by KFV malware. At most, a compromised wrapper task can refuse to call the SMARM Service, resulting in DoS attacks that are outside the scope of this work. A more formal proof (based on cryptographic reduction) of our realization of SMARM on RTOS and TrustZone-M can be found in Appendix A. 3) Workflow Verifier

Non-Secure World (SMARM Wrapper Task)

World Boundary

Secure World (SMARM Service)

(1)Send Challenge (2)Invoke Service (NSC Call) Loop

Measurement Loop (Preemptible betweem blocks)

Yield CPU (Interruptible)

Measure Block

Resume Service (4) Return Evidence (5) Foward Evidence

FIGURE 6: The end-to-end workflow of our new SMARM proposal using TrustZone-M To complete this section, we describe the end-to-end interaction between the verifier and the SMARM components on the prover, as illustrated in Figure 6: 1) The verifier sends a fresh challenge to the prover. The challenge is received by the SMARM Wrapper Task executing in the Non-Secure world; optionally, other tasks may receive the challenge and forward it to the wrapper. 2) Upon receiving the challenge, the SMARM Wrapper Task invokes the SMARM Service through an NSC entry point. 3) The SMARM Service executes the SMARM logic inside the Secure world, following Algorithm 1. Notably, after each block measurement completes, execution may return to the Non-Secure world, where the RTOS can preempt the SMARM Wrapper Task (which runs at the lowest priority) to schedule real-time tasks. 4) After completing the attestation, the SMARM Service returns the attestation evidence to the SMARM Wrapper Task. 5) Finally, the SMARM Wrapper Task forwards the evidence to the verifier. If the verifier receives no or invalid evidence, it treats the prover as compromised. VOLUME 11, 2023

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

IV. EVALUATION OF SMARM ON RTOS-BASED SYSTEMS

This section evaluates our TrustZone-M-based SMARM realization on RTOS platforms, focusing on implementation details, non-interruptibility behavior, and real-time availability under different workloads.

interruptibility periods on our target device. Together with the storage analysis in Figure 4, the results show that our realization preserves SMARM’s original performance tradeoffs [3]. However, these trends do not directly reveal the impact on real-time availability, which we examine in the next subsection.

A. IMPLEMENTATION

We implement the new realization of SMARM on an STM32 Nucleo-144 development board [21], which is equipped with an ARM Cortex-M33 MCU running at 110MHz, 512KB of flash storage, and 256KB of SRAM; it also supports the TrustZone-M security extension. In our configuration, 256KB of flash and 128KB of SRAM are allocated to the Secure world, with the remaining memory assigned to the Non-Secure world. On the software side, the Non-Secure world runs an unmodified RTOS, where our prototype supports both FreeRTOS and Zephyr, compiled with size optimizations (-Os). We implement the SMARM Wrapper Task as a regular RTOS task in the Non-Secure world, consisting of 115 lines of C code. The Secure-world software implements the SMARM Service as detailed in Algorithm 1, where we use SHA-256 as the hash function for memory block measurement and HMACSHA256 to compute the attestation evidence. The Secureworld implementation consists of 153 lines of C code and contributes 33,968 bytes to TCB. B. NON-INTERRUPTIBILITY PERIOD

1RQLQWHUUXSWLELOLW\SHULRGSHUEORFNPV



     







%ORFNVL]HE\WHV







FIGURE 7: Non-interruptibility period tdisabled of our SMARM proposal on the STM32 Nucleo-144 platform. Each point is averaged over five runs and standard deviations are below 1%. We first evaluate SMARM on our STM32 Nucleo144 prototype, focusing on the non-interruptibility period tdisabled , i.e., the time spent in an atomic block measurement. Since tdisabled depends on the block size B, we consider B ∈ {64, 128, 256, 512, 1024, 2048, 4096} bytes and run SMARM using both FreeRTOS and Zephyr as the underlying RTOS. Figure 7 reports the measured tdisabled for each block size. As expected, tdisabled grows approximately linearly with B, confirming that larger blocks lead to longer nonVOLUME 11, 2023

To evaluate the impact of SMARM on real-time availability in RTOS-based systems, we consider a simplified yet representative scenario of real-time settings where SMARM runs alongside a single real-time task TRT . In particular, we model three classes of practical real-time workloads by varying TRT frequency: 1) High real-time workload where TRT runs at 1000Hz 2) Medium real-time workload – 100Hz 3) Low real-time workload – 10Hz Although our setup includes only one real-time task, it is intentionally conservative. Our purpose is to identify the conditions under which SMARM and real-time settings fail to co-exist. In other words, if this co-existence does not hold in this simplified setting, it is unlikely to do so in more complex deployments with multiple real-time tasks. We measure fobserved using the on-chip hardware cycle counter and convert cycles to time using the 110 MHz CPU clock. b: Metric





a: Experimental Setup

To quantify the impact of SMARM on real-time availability, we introduce the Frequency Accuracy Ratio (FAR), defined as fobserved . (1) FAR = fbaseline

)UHH5726 =HSK\U



C. REAL-TIME AVAILABILITY: SETUP & METRIC

Here, fobserved denotes the execution frequency of the realtime task TRT when SMARM is active (including both the SMARM Wrapper Task and SMARM Service). In contrast, fbaseline denotes the baseline frequency of TRT in the absence of SMARM-induced interference, i.e., SMARM without disabled interrupts (Lines 5 and 7 in Algorithm 1). Intuitively, FAR measures how well the real-time task maintains its intended execution rate in the presence of SMARM. FAR = 1.0 means that SMARM introduces no interference due to non-interruptible operations. As these non-interruptible operations increasingly delay task execution, the observed frequency of TRT decreases, leading to a lower FAR. Remark. FAR does not replace schedulability analysis. It measures the frequency-level interference caused by SMARM’s non-interruptible block measurements, assuming TRT is already schedulable in the baseline SMARM configuration where interrupts are not disabled. If this assumption does not hold, the problem is an orthogonal scheduling issue independent of SMARM. 7

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

Frequency Accuracy Ratio (FAR)

1.2 1.0 0.8 0.6 0.4 0.2 0.0

FreeRTOS (Cortex-M33) Zephyr RTOS (TF-M)

64

128

256

512 1024 Block Size (Bytes)

2048

4096

2048

4096

2048

4096

(a) High real-time workload Frequency Accuracy Ratio (FAR)

1.2 1.0 0.8 0.6 0.4 0.2 0.0

FreeRTOS (Cortex-M33) Zephyr RTOS (TF-M)

64

128

256

512 1024 Block Size (Bytes)

(b) Medium real-time workload

Frequency Accuracy Ratio (FAR)

1.2 1.0 0.8 0.6 0.4 0.2 0.0

FreeRTOS (Cortex-M33) Zephyr RTOS (TF-M)

64

128

256

512 1024 Block Size (Bytes)

(c) Low real-time workload

FIGURE 8: Real-time availability of SMARM under different real-time workloads

D. REAL-TIME AVAILABILITY: RESULTS

Figure 8 reports FAR across different block sizes, real-time workloads, and RTOS choices. Across all configurations, we observe a consistent trend: FAR remains close to 1.0 for B ≤ 1024 bytes, but degrades noticeably as the block size increases. At B = 2048 bytes, FAR decreases to approximately 0.55 on FreeRTOS and 0.65 on Zephyr under medium/high real-time workloads, while remaining around 0.75 under low workloads. At B = 4096 bytes, FAR drops further to 0.27 on FreeRTOS and 0.32 on Zephyr across all workload settings. These results indicate that SMARM cannot reliably preserve 8

real-time availability at these larger block sizes. Both RTOS-s exhibit nearly identical FAR trends. This suggests that the dominant source of interference is SMARM’s atomic block measurement rather than RTOSspecific scheduling behavior. In particular, the block size B, which directly determines the non-interruptibility period, emerges as the primary factor affecting real-time availability. However, these results also reveal a key limitation of SMARM. To maintain FAR ≈ 1.0 across all evaluated settings, we must use relatively small block sizes (B ≤ 1024 bytes). Under SMARM, smaller blocks imply a larger number of memory partitions and therefore increased secure storage for the permutation σ, ranging from 576 bytes at B = 1024 bytes to approximately 13 KB at B = 64 bytes. Such storage demands can become problematic in Secureworld deployments that must coexist with other services, such as confidential DNN inference [22], control-flow integrity monitoring [23], or secure key storage [14]. In these scenarios, dedicating between several hundred bytes and tens of kilobytes of Secure RAM solely for storing σ may be impractical. V. SMARM+: REDUCING SECURE STORAGE IN SMARM

In this section, we propose SMARM+, enhanced versions of SMARM that reduce secure storage requirements while preserving its real-time behavior and security guarantees. SMARM+ retains the same high-level structure as SMARM, consisting of the Wrapper Task and the Secure Service. The Wrapper Task remains unchanged, while we redesign the Secure Service to reduce the secure storage overhead. The key idea of SMARM+ is to trade secure storage for additional computation, thereby enabling the use of smaller block sizes under tight secure-memory budgets. We present two variants of SMARM+. The first variant, SMARM+PRNG (Section V-A), reduces the secure storage requirement from O(n log n) to O(n). The second variant, SMARM+FPE (Section V-B), eliminates the need for secure storage altogether, at the cost of significantly longer overall runtime. A. SMARM+PRNG – REDUCING SECURE STORAGE TO O(N)

Algorithm 2 describes the operation of the Secure Service in SMARM+PRNG (note that the Wrapper Task remains unchanged). Instead of storing the full permutation σ to determine the measurement order, SMARM+PRNG uses a bitmap used of size n to track which memory blocks have already been measured, i.e., used[i] contains a bit indicating whether block M [i] has been measured by SMARM+PRNG. SMARM+PRNG first initializes used to all zeros (Line 1), indicating that no blocks have been measured. It then initializes a PRNG using the challenge chal and key k (Lines 2–3). For each measurement iteration, SMARM+PRNG determines the next block to measure as follows. It first computes VOLUME 11, 2023

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

Algorithm 2 SMARM+PRNG (secure world) Notation: Memory M , block size B, number of blocks n, key k, challenge chal 1: for all i ∈ {0, . . . , n − 1}: used[i] ← 0 ▷ new: bitmap initialisation 2: seed ← Hash(chal, k) 3: PRNG.Init(seed) 4: HMAC.Init(k) 5: for rm ← 0 to n − 1 do 6: rem ← n − rm 7:

r ← PRNG.RandInt(1, rem)

8:

idx ← FindKthZero(used, r)

9: used[idx] ← 1 10: DisableInterrupts 11: HMAC.Update(hmac, Midx , B) 12: EnableInterrupts 13: end for 14: att_evidence ← HMAC.Finalize(hmac)

Output: att_evidence

SMARM. In this context, soundness requires that (1) all memory blocks are measured exactly once, and (2) the order of block selection is randomized. For (1), in each iteration, the algorithm selects an index idx such that used[idx] = 0, and then sets it to 1. Since each iteration flips exactly one bit from 0 to 1, and there are n such bits, after n iterations all entries in used are set to 1. This means that every block is selected exactly once, and no block is measured more than once. For (2), randomness follows from the use of PRNG seeded with the secret (random) key k. At each iteration, SMARM+PRNG samples a uniform random integer r ∈ [1, rem]. The mapping from r to the r-th zero entry in used establishes a one-to-one correspondence between r and the set of remaining blocks. Therefore, each unmeasured block is selected with equal probability at each step. As a result, the overall measurement order is a uniformly random permutation over all n blocks. 3) Security

the number of remaining (unmeasured) blocks, denoted as rem (Line 6) and then generates a random integer r ∈ [1, rem] (Line 7). Since r does not directly correspond to a valid block index (some blocks may have already been measured), SMARM+PRNG scans the used bitmap to locate the r-th zero entry and maps it to a block index idx (Line 8). The selected block is then marked as measured by setting used[idx] ← 1 (Line 9). Subsequently, Midx is measured following the same way as in SMARM. This process repeats until all blocks have been covered, after which the attestation evidence is computed and becomes the output of the Secure Service (Line 14). 1) Secure Storage vs. Runtime Trade-off.

Compared to SMARM, SMARM+PRNG replaces the secure storage of the permutation σ with a bitmap used. Since used contains n entries, it requires n bits of secure storage. This reduces the storage requirement from n · ⌈log2 n⌉ bits in SMARM to n bits in SMARM+PRNG. This reduction in storage comes at the cost of potential additional runtime overhead. In SMARM, the permutation σ is generated once (e.g., via FisherYates in Algorithm 1) before the measurement loop, after which each block index can be retrieved in constant time. In contrast, SMARM+PRNG determines the next block indices on-the-fly by scanning the used bitmap to locate the r-th unmeasured block. This requires traversing up to O(n) entries per iteration. Consequently, while SMARM+PRNG reduce secure storage to O(n), it introduces additional per-block computation, which can increase the overall attestation runtime, especially for large n. 2) Soundness.

We first establish the soundness of SMARM+PRNG, i.e., showing that SMARM+PRNG is functionally equivalent to VOLUME 11, 2023

Here, we provide informal arguments that SMARM+PRNG retains the same security as SMARM by fulfilling the same security guarantees (S1)-(S3) defined in Section II; we refer to Appendix A-D for a formal (reduction-based) security proof of SMARM+PRNG. (S1) Controlled execution. Recall in Section III that SMARM guarantees (S1) by (i) relying on TrustZone-M to restrict entry into the Secure world to well-defined entry points (Section II-B), and (ii) disabling interrupts during each block measurement to ensure atomic execution. SMARM+PRNG preserves both design choices by implementing its logic as a Secure-world service and maintaining interrupt disablement during block measurement. Therefore, (S1) is directly inherited in SMARM+PRNG. (S2) Key secrecy. SMARM+PRNG does not modify the generation, storage, or usage of the attestation key k. As in SMARM, k is stored and accessed exclusively within the Secure world. Hence, SMARM+PRNG preserves (S2). (S3) Private measurement order. In SMARM+PRNG, the measurement order is implicitly determined by the used bitmap, which resides in Secure RAM inaccessible to the Non-Secure world where KFV malware may reside. B. SMARM+FPE – ELIMINATING SECURE STORAGE

We observe that SMARM instantiates PRP using the Fisher– Yates shuffle [10], which produces a random permutation over n elements. While Fisher–Yates is time-efficient (i.e., in O(n)), it requires materializing the entire permutation, resulting in O(n log n) bits of secure storage in SMARM. In SMARM+FPE, we eliminate this storage overhead by instead instantiating the PRP using format-preserving encryption (FPE) [24], [25]. FPE is a symmetric encryption primitive that preserves the domain of its inputs, i.e., for a 9

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

Algorithm 3 SMARM+FPE (secure world) Notation: Memory M , block size B, number of blocks n, key k, challenge chal 1: (ffx_key, tweak) ← KDF(k, chal) 2: FFX.Init(ffx_key, tweak) 3: HMAC.Init(k) 4: for i ← 0 to n − 1 do 5: idx ← FFX.Enc(i) 6: DisableInterrupts 7: HMAC.Update(hmac, Midx , B) 8: EnableInterrupts 9: end for 10: att_evidence ← HMAC.Finalize(hmac)

Output: att_evidence

given encryption key from the set K and a given finite domain D, it defines an encryption as: FPE.Enc : K × D → D By construction, FPE.Enc realizes a bijection over D, and thus directly serves as a PRP. In SMARM+FPE, we instantiate FPE using the FFX construction [26]. FFX implements FPE using a Feistel network [27], where each round function can be realized as a block cipher. To keep the design lightweight, we use Speck [28], a block cipher optimized for efficient software execution on resource-limited platforms, which aligns with our target deployment setting. Algorithm 3 describes how SMARM+FPE integrates FFX into the block measurement process. First, SMARM+FPE derives the FFX key and tweak from the attestation key k and the challenge chal (Line 1), and initializes the FFX instance accordingly (Line 2). During the i-th iteration, SMARM+FPE determines the next block to measure by using the instantiated FFX to encrypt i (Line 5). The resulting idx is then used to retrieve and measure the corresponding memory block, following the same procedure as in SMARM. After all blocks have been measured, SMARM+FPE computes and returns the attestation evidence in the same manner as SMARM. 1) Secure Storage vs. Runtime Trade-off.

SMARM+FPE eliminates the need for any per-block permutation state in secure memory. This leaves SMARM+FPE secure storage with only the FPE encryption key and the HMAC state, both of which are O(1) in size and independent of n. This elimination of permutation storage comes at the cost of additional per-block (non-atomic) computation. In SMARM, each block index is retrieved in constant time from the pre-computed σ. In SMARM+PRNG, each iteration requires an O(n) scan of the used bitmap. In SMARM+FPE, each iteration invokes FFX.Enc, which performs one FPE encryption using Speck as the underlying round function. While this operation does not depend on n, i.e., O(1) runtime complexity, this operation is more complex than the scan 10

operation in SMARM+PRNG, potentially making its runtime longer for a smaller n. Consequently, SMARM+FPE trades all permutation storage for a constant per-block cryptographic cost, making it the most storage-efficient variant at the expense of higher perblock computation compared to SMARM. 2) Soundness.

Similar to Section V-A2, we argue the soundness by showing that in SMARM+FPE, (1) all memory blocks are measured exactly once, and (2) the order of block selection is randomized. SMARM+FPE iterates over i ∈ {0, . . . , n − 1} and maps each i to a block indices idx = FFX.Enc(i). Since FFX.Enc implements a bijection over the domain {0, . . . , n − 1}, each value of idx is distinct for distinct values of i. Therefore, every block is measured exactly once and no block is measured more than once, fulfilling (1). (2) directly follows from the fact that FFX instantiates pseudo-random permutation and the order of block selection in SMARM+FPE is simply {FFX.Enc(0), FFX.Enc(1), . . . , FFX.Enc(n − 1)}, making it a uniformly random permutation over all n blocks. 3) Security

We informally argue how SMARM+FPE satisfies (S1)-(S3) (in Section II) while providing a formal reduction proof in Appendix A-E. (S1) Controlled execution. SMARM+FPE preserves both design choices of SMARM for enforcing (S1): it implements its logic as a Secure-world service accessible only via TrustZone-M NSC entry points (Section II-B), and it disables interrupts during each block measurement via the CPSID instruction to ensure atomic execution. Therefore, (S1) is directly inherited in SMARM+FPE. (S2) Key secrecy. SMARM+FPE does not modify the generation, storage, or usage of the attestation key k. As in SMARM, k is stored and accessed exclusively within the Secure world and is used only to derive the FFX key and tweak, which also do not leak from the Secure world. Hence, SMARM+FPE preserves (S2). (S3) Private measurement order. In SMARM+FPE, the measurement order is determined by FFX.Enc, whose output depends on the secret key k and the one-time challenge chal. Since k resides exclusively in Secure RAM inaccessible to the Non-Secure world, KFV malware cannot compute or predict the permutation. VI. EVALUATION OF SMARM+ ON RTOS SYSTEMS

In this section, we evaluate the two SMARM+ variants against the baseline SMARM along three dimensions: secure storage size, overall attestation runtime, and energy consumption. We reuse the experimental setup and FAR metric introduced in Section IV. As established in Section IV that VOLUME 11, 2023

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

FreeRTOS and Zephyr exhibit similar results in SMARM, our experiments here therefore focus only on FreeRTOS.

FAR < 1.0 (B>1024)

10,000

SMARM SMARM+PRNG SMARM+FPE

1,000

100

64

128

256

512

1024

2048

4096

Block sizeB(bytes)

FIGURE 9: Storage requirement for each scheme with varying block sizes. The dashed red line marks B = 1024 bytes, beyond which FAR drops below 1.0. Runtime (ms) B (bytes)

SMARM

SMARM+PRNG

SMARM+FPE

64 128 256 512 1024 2048 4096

644 562 521 500 490 484 481

9,310 2,730 1,066 630 526 494 484

4,229 2,325 1,423 945 726 611 553

TABLE 1: Overall attestation runtime of SMARM baseline and the two SMARM+ variants. The shaded row (B = 1024 bytes) marks B = 1024 bytes, beyond which FAR drops below 1.0. Figure 9 compares the secure storage requirements of SMARM and both SMARM+ variants across different block sizes B. Both SMARM+ schemes substantially reduce secure storage overhead relative to SMARM across all evaluated configurations. The magnitude of reduction varies across the two variants as B changes. For SMARM+PRNG, the storage benefit is greater when n is large (equivalently, when B is small). For example, SMARM+PRNG achieves a 13× reduction at B = 64 bytes (13,312 → 1,024 bytes), while the reduction decreases to approximately 7× at B = 4096 bytes (112 → 16 bytes). This trend arises because both SMARM+PRNG and SMARM’s storage requirements scale with n, albeit with different asymptotic costs. In contrast, SMARM+FPE requires a fixed secure storage footprint of only 16 bytes for FPE-related key material, independent of B/n. As a result, it achieves increasingly larger reductions as B decreases. At B = 64 bytes, SMARM+FPE provides an 832× reduction compared to SMARM, far exceeding the reduction achieved by SMARM+PRNG. As B increases, however, the relative benefit becomes narrower, VOLUME 11, 2023

Runtime overhead vs. SMARM (%)

Secure storage || (bytes, log scale)

A. SECURE STORAGE

and both variants provide comparable storage savings at large block sizes such as B = 4096 bytes. At the largest block size that still achieves 1.0 FAR (B = 1024 bytes), SMARM+PRNG reduces the storage requirement from 576 bytes to 64 bytes, corresponding to a 9× reduction. SMARM+FPE further lowers the requirement to 16 bytes, achieving approximately a 36× reduction relative to SMARM. +1000%

SMARM+PRNG

FAR < 1.0 (B>1024)

SMARM+FPE

+100%

+10%

+1% 64

128

256

512

1024

2048

4096

Block sizeB(bytes)

FIGURE 10: Overall runtime overhead of SMARM+PRNG and SMARM+FPE relative to SMARM baseline across block sizes. The dashed red line marks B = 1024 bytes, beyond which FAR drops below 1.0.

B. OVERALL ATTESTATION RUNTIME

Figure 10 presents the runtime overhead of SMARM+PRNG and SMARM+FPE relative to SMARM (when executed without interruption), while the corresponding absolute runtimes are reported in Table 1. The results show that both variants introduce additional runtime compared to SMARM, with the overhead becoming more pronounced as the block size B decreases. In most cases, SMARM+FPE tends to incur higher runtime overhead than SMARM+PRNG due to the need to perform an FPE operation for each block selection. However, for very small block sizes (B = 64 or 128 bytes), SMARM+PRNG becomes slower. This is because its bitmap-based block selection requires scanning O(n) entries per iteration, where n grows inversely with B. As a result, the cumulative scan cost becomes dominant for small blocks, leading to large overhead (e.g., 13.5× of SMARM runtime at B = 64 bytes). This makes SMARM+PRNG less suitable for settings requiring very small block sizes. At B = 1024 bytes, SMARM+PRNG incurs only a moderate runtime increase of 7% (526 ms vs. 490 ms). For this configuration, the bitmap scan contributes little to the total execution time, which is largely dominated by hashing and HMAC-SHA256 computation over memory blocks. In comparison, SMARM+FPE incurs around 48% overhead (726 ms vs. 490 ms). C. ENERGY CONSUMPTION

We measure board-level energy per attestation round using an FNIRSI FNB58 USB power meter in series between the 11

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

Board-level Energy (mJ)

E. DISCUSSION

Our results suggest that the choice among SMARM, SMARM+PRNG, and SMARM+FPE depends not only on block size and runtime/energy overhead, but also on the available secure storage size that depends on how Secure RAM is allocated alongside the attestation service. When Secure RAM is dedicated primarily to attestation, such as in attestation-focused architectures [4], [5], baseline SMARM is the most attractive option. In these settings, the permutation array can reside entirely in Secure RAM without competing with other services, making SMARM the simplest and most runtime-efficient design. When Secure RAM must be shared with additional platform secrets [14], SMARM+PRNG becomes a more practical choice. At B ≥ 512 bytes, it achieves a 9× storage reduction while incurring only 5–26% runtime and energy overhead relative to SMARM, making it the most balanced option for resource-constrained deployments. For example, on the STM32 Nucleo-144 platform, selecting B ≥ 512 bytes allows the bitmap to remain sufficiently small while preserving space for co-resident secure assets and maintaining low runtime overhead. In more constrained environments where Secure RAM is heavily contended, SMARM+FPE is often preferable. This scenario arises when the Secure world simultaneously hosts multiple security-critical services, such as confidential deeplearning inference [22] or RTOS-aware control-flow integrity monitoring [23]. Because SMARM+FPE requires only a constant-size storage footprint, it minimizes Secure RAM usage and enables coexistence with other secure services. Finally, we observe that neither SMARM+PRNG nor SMARM+FPE changes FAR behavior across different block sizes B. To validate this empirically, we measured FAR for both variants using the same methodology described in Section IV under low/medium/high real-time workloads. The results closely match the baseline SMARM measurements reported in Section IV, indicating that the proposed modifications influence storage and runtime overhead but do not alter real-time interference characteristics for a given block size.

B (bytes)

SMARM

SMARM+PRNG

SMARM+FPE

64 128 256 512 1024 2048 4096

190.2 168.0 155.2 148.6 145.2 143.3 141.0

2,650 780 310 183 153 144 141

1,243 700 425 289 221 187 170

TABLE 2: Board-level energy consumption per attestation round; the shaded row marks B = 1024 bytes, the largest block size preserving FAR ≈ 1.0.

host PC and the NUCLEO-L552ZE-Q board, sampling at 100 Hz. Results are reported in Table 2. SMARM shows only small energy variation across block sizes B, from 190 mJ at B = 64 to 141 mJ at B = 4096. In contrast, both SMARM+ variants show stronger dependence on B: at B = 64, SMARM+PRNG consumes 2,650 mJ (13.9× SMARM) due to its O(n) bitmap scan, while SMARM+FPE consumes 1,243 mJ (6.5×) from per-block FFX.Enc calls. At the operating point B = 1024 bytes, overhead narrows to 5% for SMARM+PRNG (153 mJ) and 52% for SMARM+FPE (221 mJ). D. TRADE-OFF

The results indicate that no single scheme simultaneously minimizes both secure storage and attestation runtime across all block sizes B, highlighting an inherent trade-off between these two objectives. For small block sizes (B ≤ 256 bytes), SMARM incurs substantial storage overhead (2-13 KB). Although SMARM+PRNG reduces storage, its bitmap-based selection incurs significant runtime and energy overhead at large n: at B = 64 bytes, SMARM+PRNG consumes 2,650 mJ (13.9× SMARM). In this range, SMARM+FPE is the most suitable option, achieving larger storage reduction while maintaining lower energy consumption (1,243 mJ vs. 2,650 mJ at B = 64 bytes). For medium block sizes (512–1024 bytes), SMARM+PRNG provides the best balance across all three dimensions. At B = 1024 bytes, it achieves a 9× storage reduction, only 7% runtime overhead (526 ms vs. 490 ms), and only 5% energy overhead (153 mJ vs. 145 mJ) relative to SMARM— making it the most energy-efficient SMARM+ variant at the recommended operating point. SMARM+FPE is also viable at this point, offering larger storage savings (36×) at the cost of higher runtime (726 ms) and energy overhead (221 mJ, 52% above SMARM). For large block sizes (B ≥ 2048 bytes), both variants have comparable storage, runtime, and energy results. However, this regime significantly reduces FAR below 1.0 (Section IV), making it unsuitable for real-time workloads.

12

VII. RELATED WORK Work

RTOS RT eval. No extra HW Secure Storage

SMARM [3] PRoM [29] HAtt [30] ITERATOR [31]

× × × ×

× × × ×

✓ ✓ × ✓

O(n log n) O(n log n) O(n log n) O(n)

SMARM+PRNG (ours) SMARM+FPE (ours)

✓ ✓

✓ ✓

✓ ✓

O(n) O(1)

TABLE 3: Position of our work w.r.t. prior work in shuffledmeasurement remote attestation schemes.

A. SHUFFLED MEASUREMENT TECHNIQUES IN REMOTE ATTESTATION

Several works have extended SMARM [3] core idea of measuring memory blocks in a shuffled order, each addressing VOLUME 11, 2023

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

specific challenges in attestation for IoT devices. PRoM [29] applies shuffled measurement to multi-core IoT devices. Rather than measuring all blocks sequentially on a single core, PRoM distributes the attestation across multiple cores, reducing the overall attestation time and improving availability compared to SMARM. However, PRoM must inherit SMARM’s need for non-interruptible block measurement. PRoM also has not been evaluated under realtime workloads, leaving its impact on time-sensitive tasks unknown. HAtt [30] improves availability by using Physical Unclonable Functions (PUFs) to secure attestation secrets and adopts SMARM’s randomized measurement approach. Similar to SMARM, HAtt mandates per-block atomicity. Furthermore, HAtt introduces a hardware dependency on PUFs that may not be available on standard TrustZone-M MCUs, limiting its deployability on off-the-shelf embedded platforms. ITERATOR [31] adopts a different strategy. In an offline phase, it constructs a Cuckoo filter over all memory blocks to represent the valid software state. During runtime, ITERATOR incrementally verifies memory through two operations: Attest, which validates a newly selected block against the filter, and Check, which re-validates k randomly chosen previously measured blocks to defend against relocation malware. ITERATOR still requires interrupts to remain disabled during each consecutive Attest-Check sequence. As such, non-interruptible execution is not eliminated in ITERATOR. While aforementioned studies build upon SMARM’s core idea, they have neither been implemented on RTOS platforms nor evaluated under real-time workloads, leaving their practicality in realistic real-time deployments questionable. Moreover, they inherit SMARM’s secure-storage limitation, which can become prohibitive on memory-constrained devices. Although ITERATOR reduces storage complexity to O(n) through Cuckoo filters, its actual overhead depends on parameters such as the target false-positive rate and load factor [32], resulting in a larger constant cost in practice. In contrast, SMARM+PRNG requires exactly n bits of storage with no additional asymptotic constant overhead, while SMARM+FPE eliminates storage dependence on n entirely. Table 3 summarizes the differences between our work and prior work in shuffled measurements. B. OTHER APPROACHES TO REALIZE INTERRUPTIBLE ATTESTATION

Beyond shuffled measurements, several alternative approaches have been proposed to relax the atomicity requirement imposed by traditional RA schemes [4], [5], [9], [33], [34]. Self-measurement techniques [31], [35], [36] allow the prover to initiate attestation independently of the verifier, enabling measurements to be scheduled at times that minimize interference with real-time tasks. Other works [37]–[39] permit interrupts during attestation by additionally measuring interrupt vector tables (IVTs), based on the intuition that VOLUME 11, 2023

malicious interrupt-driven behavior will be reflected in the attestation evidence. A different line of research relies on hardware support to reduce attestation latency or measurement disruption. Examples include hardware-assisted memory monitoring or evidence generation [40]–[43], which can minimize or eliminate non-interruptible execution windows. Finally, some approaches [44], [45] focus on preventing malware persistence by enforcing strict write protection policies that block unauthorized memory modifications. These alternatives are complementary to shuffled measurements and address different aspects of interruptible attestation. Studying how shuffled measurements can be combined with these techniques to jointly improve security and realtime compatibility is an interesting direction for future work. VIII. CONCLUSION

This paper presented the first systematic study of shuffledmemory remote attestation in real-time RTOS-based IoT systems. We realized SMARM on commodity TrustZoneM hardware running FreeRTOS and Zephyr, replacing its original microkernel-based design while preserving the same security guarantees. Our evaluation revealed a fundamental limitation of SMARM: small block sizes preserve real-time availability but require substantial secure storage, restricting deployment on memory-constrained devices. To address this limitation, we proposed SMARM+ with two variants that reduce securestorage requirements through different design trade-offs. Experimental results show that both variants significantly lower secure-storage overhead while preserving SMARM’s realtime compatibility, at the cost of additional attestation runtime and energy overhead. At the recommended operating point (B = 1024 bytes), SMARM+PRNG incurs only 7% runtime and 5% energy overhead over SMARM, while SMARM+FPE offers larger storage savings at the cost of 48% runtime and 52% energy overhead.Overall, SMARM+ provides a practical foundation for deploying shuffled remote attestation on realtime platforms with limited secure storage. APPENDIX A FORMAL SECURITY ANALYSIS

This section provides a formal security analysis of our TrustZone-M-based SMARM realization in Section III and the two SMARM+ variants in Section V. Our goal is to show that each construction satisfies the three security requirements (S1)-(S3) defined in Section II under standard cryptographic and hardware assumptions. We refer to λ as the security parameter, negl (λ) for any negligible function, and PPT for probabilistic polynomialtime. All algorithms receive 1λ as an implicit input. We denote by [n] the set {0, . . . , n−1} of memory block indices. A. PRELIMINARIES

Definition 1 (Pseudorandom Function (PRF)). A keyed function F : {0, 1}λ × {0, 1}∗ → {0, 1}λ is a pseudorandom 13

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

function (PRF) if for every PPT distinguisher D, h i h i AdvPRF (λ) = Pr DF(k,·) (1λ ) = 1 − Pr DR(·) (1λ ) = 1 D ≤ negl (λ) $

where k ← − {0, 1}λ and R is a uniformly random function. Definition 2 (Pseudorandom Generator (PRNG)). A deterministic function G : {0, 1}λ → {0, 1}ℓ(λ) with ℓ(λ) > λ is a pseudorandom generator if for every PPT distinguisher D, AdvPRNG (λ) = |Pr[D(G(s)) = 1] − Pr[D(r) = 1]| D ≤ negl (λ) $

$

where s ← − {0, 1}λ and r ← − {0, 1}ℓ(λ) . Definition 3 (Pseudorandom Permutation (PRP)). A keyed family of bijections E : {0, 1}λ ×[n] → [n] is a pseudorandom permutation over domain [n] if for every PPT distinguisher D, h i h i AdvPRP (λ) = Pr DE(k,·) (1λ ) = 1 − Pr Dπ(·) (1λ ) = 1 D ≤ negl (λ) $

where k ← − {0, 1}λ and π is a uniformly random permutation over [n]. Our proofs rely on the following standard cryptographic assumptions: Assumption A.1 (SHA-256 as PRF). Keyed hash is a PRF (Definition 1) when keyed over {0, 1}256 . This is the standard assumption [46] and is widely accepted for SHA-256 as the underlying cryptographic hash function. Assumption A.2 (PRNG security). The PRNG used in SMARM+PRNG, seeded with a uniformly random value, produces output that is computationally indistinguishable from a uniform random string (Definition 2). Assumption A.3 (FFX-Speck as PRP). The FFX construction [26] instantiated with the Speck block cipher [28] is a PRP (Definition 3) over domain [n], provided that no adversary is given access to an encryption or decryption oracle for the underlying FFX instance. We also assume the following assumptions about TrustZone-M. Assumption A.4 (TrustZone-M Isolation). No code executing in the Non-Secure world can read or write memory regions assigned to the Secure world by the SAU/IDAU configuration, even under full-software compromise of Non-Secure world. Assumption A.5 (TrustZone-M Entry Integrity). Secureworld functions are invocable from the Non-Secure world only via explicitly designated NSC entry points. Mid-function entry and early exit are prevented by the secure state transition mechanism enforced in hardware. 14

B. SECURITY GAME

We define a unified measurement-order indistinguishability game that captures S3 for all three constructions. S1 and S2 are architectural properties enforced by TrustZone-M hardware and are addressed separately in Section A-C. Definition 4 (Measurement-Order Indistinguishability Game MOIΠ A (λ)). Let Π be a memory measurement scheme over n blocks. The game MOIΠ A (λ) between a challenger C and a PPT adversary A proceeds as follows: $

1) Setup. C samples a secret key k ← − {0, 1}λ and initializes Π with k. $ 2) Challenge. The verifier sends a fresh challenge chal ← − λ {0, 1} ; C makes chal available to A. 3) Adversary capabilities. A controls all Non-Secureworld software. Concretely, A: • knows n, chal , and the complete specification of Π; • observes the wall-clock timestamps t1 , . . . , tn at which interrupts are re-enabled after each block measurement (KFV capability [3]); • may read or write any Non-Secure RAM address at any time. 4) Output. A outputs a predicted permutation σ̂ ∈ Perm([n]). 5) Win condition. Let σ Π be the actual measurement order produced by Π on inputs (k, chal ). A wins if σ̂ = σ Π . The advantage of A against Π is i 1 h Π (λ) − , (λ) = Pr A wins MOI AdvMOI A A,Π n! where n!1 is the probability of a correct random guess over Perm([n]). We say Π satisfies measurement-order indistinguishability if AdvMOI A,Π (λ) ≤ negl (λ) for every PPT A. C. SECURITY OF THE TRUSTZONE-M-BASED SMARM

Theorem A.1 (Security of RTOS-based SMARM). The TrustZone-M-based SMARM realization (SMARM-TZM) described in Section III satisfies: (S1) Controlled Execution, (S2) Key Secrecy, and (S3) Private Measurement Order. Proof. (S1) Controlled Execution. The SMARM Service is implemented entirely in the Secure world and is accessible from the Non-Secure world only through a designated NSC entry point. By Assumption A.5, the hardware prevents both mid-code entry into the Secure world and premature return to the Non-Secure world. The adversary can influence Secureworld execution only when interrupts are enabled after each block measurement, i.e., Line 7 of Algorithm 1. At that point, an interrupt may temporarily transfer control away from the SMARM Service, but upon resumption execution returns to the same interrupted location; it cannot redirect control to any other Secure-world code location. Moreover, interrupts are disabled during each block measurement, so the adversary cannot interrupt the execution of an individual block. VOLUME 11, 2023

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

Therefore, Secure-world execution is confined to the intended SMARM control flow, satisfying (S1). (S2) Key Secrecy. The attestation key k is provisioned once and stored in Secure flash, which the SAU/IDAU configuration marks as Secure-only. At runtime, all k-derived materialresides exclusively in Secure RAM. By Assumption A.4, no Non-Secure code, including a fully compromised RTOS or any application task, can read or write these locations. Hence, k is never exposed to the adversary, satisfying (S2). (S3) Private Measurement Order. We show that no PPT adversary A can predict the permutation σ used in a given attestation instance with non-negligible advantage. Recall σ is generated by FisherYates(seed , [0, . . . , n−1]), where seed = Hash(chal , k). After generation, σ is stored in Secure RAM and never written to Non-Secure RAM. By Assumption A.4, A cannot read σ directly. We argue that A cannot compute σ from chal alone. Suppose, for contradiction, that A could predict σ with nonnegligible advantage. Since σ is a deterministic function of seed , this implies A can recover seed . But seed = Hash(chal , k), and by Assumption A.1 (SHA-256 as PRF), an adversary that knows chal but not k cannot distinguish seed from a uniformly random string with nonnegligible probability. This contradicts our supposition; hence AdvMOI A,SMARM-TZM (λ) ≤ negl (λ), satisfying (S3).

D. SECURITY OF SMARM+PRNG

Theorem A.2 (SMARM+PRNG Security). SMARM+PRNG satisfies (S1)-(S3). Specifically, let Π be SMARM+PRNG. For every PPT adversary A, AdvMOI A,Π (λ)

≤ negl (λ),

Proof. Suppose |p0 − p1 | > negl(λ). Then, we can construct a PRF distinguisher B1 as follows: B1 receives oracle access to either F = SHA256(k, ·) (real PRF) or a truly random function R. It queries its oracle on chal to obtain the seed, runs the rest of SMARM+PRNG honestly, and outputs whatever A outputs. When B1 oracle is the real PRF, it simulates G0 perfectly; when it is R, it simulates G1 perfectly. Hence AdvPRF B1 (λ) ≥ |p0 − p1 | > negl(λ), contradicting Assumption A.1. Game G2 : Replace PRNG output with uniform random. Given a uniformly random seed (as in G1 ), we further replace the PRNG outputs r0 , . . . , rn−1 with truly uniform random $ integers ri ← − [1, n − i] for each i. Let p2 = Pr[A wins in G2 ]. Lemma A.2. |p1 − p2 | ≤ AdvPRNG (λ). B2 Proof. A PRNG seeded with a uniformly random value (as in G1 ) is computationally indistinguishable from a uniform random string by Assumption A.2. Any PPT distinguisher B2 that separates G1 from G2 directly breaks Assumption A.2. In G2 , each ri is a fresh uniform sample from [1, n−i], independent of A’s view. The mapping FindKthZero(used , ri ) is a bijection between [1, n−i] and the set of remaining (unmeasured) block indices at step i. Hence, the resulting sequence (idx 0 , . . . , idx n−1 ) is a uniformly random permutation over [n]: at each step i, the selected block is chosen uniformly at random from the n − i remaining blocks, and this process produces the uniform distribution over Perm([n]). As such, A’s best strategy in G2 is random guessing: p2 = n!1 , resulting in: 1 1 AdvMOI A,Π (λ) = p0 − n! ≤ |p0 − p1 | + |p1 − p2 | + (p2 − n! ) PRG ≤ AdvPRF B1 (λ) + AdvB2 (λ)

Proof. (S1) and (S2) are inherited from Theorem A.1 unchanged: SMARM+PRNG retains the same TrustZone-M architecture, the same NSC entry point, and the same SecureRAM storage for k and all derived material. We prove (S3) via the following games:

This proves Theorem A.2.

Game G0 : Real scheme. This is the MOIΠ A (λ) game (Definition 4) with Π being SMARM+PRNG, where the measurement is performed in the following order:

Theorem A.3 (SMARM+FPE Security). SMARM+FPE satisfies (S1)-(S3). Specifically, let Π be SMARM+FPE. For every PPT adversary A,

seed = SHA256(chal ∥ k) PRNG state = PRNG.Init(seed ) ri = PRNG.RandInt(1, n − i) for i = 0, . . . , n − 1 idx i = FindKthZero(used , ri )

≤ negl (λ).

E. SECURITY OF SMARM+FPE

AdvMOI A,Π (λ) ≤ negl (λ), Proof. (S1) and (S2) are inherited from Theorem A.1 by the same argument as in the proof of Theorem A.2. We prove (S3) via the following games:

The sequence (idx 0 , . . . , idx n−1 ) constitutes the measurement order σ Π . Let p0 = Pr[A wins in G0 ].

Game G0 : Real scheme. The measurement order in SMARM+FPE is:

Game G1 : Replace seed with uniform random. We replace $ seed = SHA256(chal ∥ k) with seed ← − {0, 1}256 . All other steps are identical. Let p1 = Pr[A wins in G1 ].

(key, tweak ) = KDF(k, chal ),

Lemma A.1. |p0 − p1 | ≤ AdvPRF B1 (λ). VOLUME 11, 2023

idx i = FFX.Enckey, tweak (i) for i = 0, . . . , n − 1. Since FFX.Enc is a bijection over [n], the sequence (idx 0 , . . . , idx n−1 ) is σ Π . Let p0 = Pr[A wins in G0 ]. 15

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

Game G1 : Replace KDF output with uniform random key. We replace (key, tweak ) = KDF(k, chal ) with $ (key, tweak ) ← − {0, 1}2λ . All other steps are identical. Let p1 = Pr[A wins in G1 ]. Lemma A.3. |p0 − p1 | ≤ AdvPRF B1 (λ). Proof. We prove by reduction to the PRF security in Assumption A.1. Suppose |p0 − p1 | is non-negligible. We show how to construct a PPT distinguisher B1 against the PRF security of KDF(k, ·). B1 is given access to an oracle function which is either KDF(k, ·) for a secret key k or a uniformly random function with the same output length. To simulate the game, B1 queries O on chal and parses the response as (key, tweak ). It then uses this pair as the FFX key material and runs the remainder of G0 exactly as specified for A. When the oracle is KDF(k, ·), the simulation is identical to G0 . If the oracle is a uniformly random function, then (key, tweak ) is uniform and independent, so the simulation is identical to G1 . Therefore, B1 distinguishes the PRF oracle from a random function with non-negligible advantage |p0 − p1 |, breaking Assumption A.1 (since KDF(k, ·) is instantiated as HMAC-SHA256(k, ·) and is assumed to be a PRF by Assumption A.1) Game G2 : Replace FFX with a truly random permutation. Given a uniformly random FFX key (as in G1 ), we replace $ FFX.Encffx _key,tweak with a truly random permutation π ← − Perm([n]). Let p2 = Pr[A wins in G2 ]. Lemma A.4. |p1 − p2 | ≤ AdvPRP B2 (λ). Proof. We prove by reduction to the FFX security in Assumption A.3. Suppose |p1 − p2 | is non-negligible. We show how to construct a PRP distinguisher B2 with oracle access to either FFX.Enck ′ (real PRP) or a truly random permutation π over [n]. B2 runs A using its oracle as the FFX instantiation (querying on i = 0, . . . , n − 1) and forwards A’s output as its own distinguishing bit. When the oracle is the real PRP, this simulates G1 perfectly; when it is π, it simulates G2 perfectly. Hence this makes AdvPRP B2 (λ) also non-negligble, contradicting Assumption A.3. In G2 , the measurement order is a uniformly random per$ mutation π ← − Perm([n]), independent of everything the adversary knows. Hence, p2 = n!1 , resulting in: 1 1 AdvMOI A,Π (λ) = p0 − n! ≤ |p0 − p1 | + |p1 − p2 | + (p2 − n! ) PRP ≤ AdvPRF B1 (λ) + AdvB2 (λ)

≤ negl (λ). This proves Theorem A.3. 16

ACKNOWLEDGMENT

The authors used Claude and ChatGPT as an AI assistant to support drafting and editing of portions of this manuscript, including literature review text, section organization, proof assistant, and language refinement. All technical content, experimental results, and conclusions were verified and approved by the authors REFERENCES [1] Statista, ‘‘IoT connections worldwide 2034.’’ https://www.statista.com/sta tistics/1183457/iot-connected-devices-worldwide/, 2025. Accessed: 22 December 2025. [2] Kaspersky, ‘‘Kaspersky unveils an overview of IoT-related threats in 2023.’’ https://www.kaspersky.com/about/press-releases/kaspersky-u nveils-an-overview-of-iot-related-threats-in-2023, 2023. Accessed: 22 December 2025. [3] X. Carpent, N. Rattanavipanon, and G. Tsudik, ‘‘Remote attestation of IoT devices via SMARM: Shuffled measurements against roving malware,’’ in Proceedings of the 2018 IEEE International Symposium on Hardware Oriented Security and Trust (HOST), pp. 9–16, IEEE, 2018. [4] K. Eldefrawy, A. Francillon, D. Perito, and G. Tsudik, ‘‘SMART: Secure and minimal architecture for (establishing dynamic) root of trust,’’ in Proceedings of the Network and Distributed System Security Symposium (NDSS), Internet Society, 2012. [5] K. ElDefrawy, N. Rattanavipanon, and G. Tsudik, ‘‘HYDRA: Hybrid design for remote attestation (using a formally verified microkernel),’’ in Proceedings of the 10th ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec), pp. 99–110, ACM, 2017. [6] I. De Oliveira Nunes, K. Eldefrawy, N. Rattanavipanon, M. Steiner, and G. Tsudik, ‘‘VRASED: A verified hardware/software co-design for remote attestation,’’ in Proceedings of the 28th USENIX Security Symposium, pp. 1429–1446, 2019. [7] G. Klein, K. Elphinstone, G. Heiser, J. Andronick, D. Cock, P. Derrin, D. Elkaduwe, K. Engelhardt, R. Kolanski, M. Norrish, T. Sewell, H. Tuch, and S. Winwood, ‘‘seL4: Formal verification of an OS kernel,’’ in Proceedings of the 22nd ACM Symposium on Operating Systems Principles (SOSP), pp. 207–220, 2009. [8] T. Ensergueix, ‘‘Cortex-M23 and Cortex-M33 — security foundation for billions of devices.’’ https://developer.arm.com/community/arm-communi ty-blogs/b/architectures-and-processors-blog/posts/cortex-m23-and-cor tex-m33---security-foundation-for-billions-of-devices, 2016. Accessed: 4 January 2026. [9] B. Kuang, A. Fu, W. Yu, S. Huang, and D. He, ‘‘A survey of remote attestation in Internet of Things: Attacks, countermeasures, and prospects,’’ Computers & Security, vol. 112, p. 102498, 2022. [10] R. A. Fisher and F. Yates, Statistical Tables for Biological, Agricultural and Medical Research. Edinburgh: Oliver and Boyd, 1 ed., 1938. [11] Boundary Devices, ‘‘i.MX6 Sabre Lite development board.’’ https://boun darydevices.com/product/nitrogen6x- sabrelite- compatible/, 2013. Accessed: 4 February 2026. [12] Arm Limited, ‘‘TrustZone for Cortex-M.’’ https://www.arm.com/technolo gies/trustzone-for-cortex-m, 2024. Accessed: 12 February 2026. [13] L. Luo, Y. Zhang, C. C. Zou, B. Pearson, B. Keating, C. White, X. Shao, Z. Ling, H. Yu, and X. Fu, ‘‘On security of TrustZone-M-based IoT systems,’’ IEEE Internet of Things Journal, vol. 9, no. 12, pp. 9334–9347, 2022. [14] Silicon Labs, ‘‘AN1271: Secure key storage.’’ https://www.silabs.com/d ocuments/public/application-notes/an1271-efr32-secure-key-storage.pdf, 2020. Accessed: 12 February 2026. [15] Amazon Web Services, ‘‘FreeRTOS: Real-time operating system for microcontrollers.’’ https://www.freertos.org, 2023. Accessed: 4 February 2026. [16] Apache Software Foundation, ‘‘NuttX: Real-time operating system (RTOS) for embedded systems.’’ h t t p s : / / n u t t x . a p a c h e . o rg /, 2024. Accessed: 4 February 2026. [17] Amazon Web Services, ‘‘FreeRTOS-MPU: Memory protection unit support.’’ https://www.freertos.org/Security/04-FreeRTOS-MPU-memory-p rotection-unit, 2023. Accessed: 12 February 2026. [18] Linux Foundation, ‘‘Zephyr Project: A scalable real-time operating system supporting multiple hardware architectures.’’ https://www.zephyrproject. org, 2024. Accessed: 4 February 2026. VOLUME 11, 2023

Laohajirapan et al.: SMARM+: Analyzing and Enhancing Shuffled Measurements for Remote Attestation in Real-Time IoT Settings

[19] O. Karliner, ‘‘CVE-2018-16525: Remote code execution in FreeRTOS+TCP UDP protocol.’’ https://blog.zimperium.com/freertos- tcpip -stack-vulnerabilities-put-wide-range-devices-risk-compromise-smart-h omes-critical-infrastructure-systems/, 2018. Accessed: 4 February 2026. [20] NIST, ‘‘CVE-2024-6137: Out-of-bounds write in Zephyr RTOS memory management.’’ https://nvd.nist.gov/vuln/detail/CVE-2024-6137, 2024. Accessed: 4 February 2026. [21] STMicroelectronics, ‘‘STM32L552ZE-Q Nucleo-144 development board.’’ https://www.st.com/en/evaluation-tools/nucleo-l552ze-q.html, 2020. Accessed: 4 February 2026. [22] M. S. Islam, M. Zamani, C. H. Kim, L. Khan, and K. W. Hamlen, ‘‘Confidential execution of deep learning inference at the untrusted edge with ARM TrustZone,’’ in Proceedings of the 13th ACM Conference on Data and Application Security and Privacy (CODASPY), pp. 153–164, ACM, 2023. [23] T. Kawada, S. Honda, Y. Matsubara, and H. Takada, ‘‘TZmCFI: RTOSaware control-flow integrity using TrustZone for Armv8-M,’’ International Journal of Parallel Programming, vol. 49, no. 3, pp. 472–491, 2021. [24] M. Bellare, T. Ristenpart, P. Rogaway, and T. Stegers, ‘‘Format-preserving encryption,’’ in Proceedings of the 16th International Workshop on Selected Areas in Cryptography (SAC), pp. 295–312, Springer, 2009. [25] M. Dworkin, ‘‘Recommendation for block cipher modes of operation: Methods for format-preserving encryption,’’ Tech. Rep. Special Publication 800-38G, National Institute of Standards and Technology (NIST), 2016. [26] M. Bellare, P. Rogaway, and T. Spies, ‘‘The FFX mode of operation for format-preserving encryption,’’ NIST Submission, 2010. Draft 1.1, February 20, 2010. [27] V. T. Hoang and P. Rogaway, ‘‘On generalized Feistel networks,’’ in Proceedings of the 30th Annual Cryptology Conference (CRYPTO), pp. 613– 630, Springer, 2010. [28] R. Beaulieu, D. Shors, J. Smith, B. Treatman-Clark, B. Weeks, and L. Wingers, ‘‘The SIMON and SPECK families of lightweight block ciphers,’’ in Proceedings of the 52nd ACM/EDAC/IEEE Design Automation Conference (DAC), pp. 1–6, 2015. [29] M. N. Aman, M. H. Basheer, S. Dash, A. Sancheti, J. W. Wong, J. Xu, H. W. Lim, and B. Sikdar, ‘‘PRoM: Passive remote attestation against roving malware in multi-core IoT devices,’’ IEEE Sensors Journal, vol. 21, no. 22, pp. 24799–24814, 2021. [30] M. N. Aman, A. Basheer, and B. Sikdar, ‘‘HAtt: Hybrid remote attestation for the Internet of Things with high availability,’’ IEEE Internet of Things Journal, vol. 7, no. 8, pp. 7220–7233, 2020. [31] N. Sponziello, A. Sateesan, M. Masoom Rabbani, N. Mentens, N. Dragoni, and E. Dushku, ‘‘ITERATOR: Interruptible remote attestation through cuckoo filters,’’ IEEE Internet of Things Journal, vol. 12, no. 24, pp. 54746–54763, 2025. [32] B. Fan, D. G. Andersen, M. Kaminsky, and M. D. Mitzenmacher, ‘‘Cuckoo filter: Practically better than bloom,’’ in Proceedings of the 10th ACM International on Conference on emerging Networking Experiments and Technologies, pp. 75–88, 2014. [33] 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. [34] J. Noorman, J. Van Bulck, J. T. Mühlberg, F. Piessens, P. Maene, B. Preneel, I. Verbauwhede, J. Götzfried, T. Müller, and F. Freiling, ‘‘Sancus 2.0: A low-cost security architecture for IoT devices,’’ ACM Transactions on Privacy and Security, vol. 20, no. 3, pp. 1–33, 2017. [35] X. Carpent, N. Rattanavipanon, and G. Tsudik, ‘‘ERASMUS: Efficient remote attestation via self-measurement for unattended settings,’’ in Proceedings of the 2018 Design, Automation & Test in Europe Conference (DATE), pp. 1191–1194, IEEE, 2018. [36] X. Carpent, K. Eldefrawy, N. Rattanavipanon, A.-R. Sadeghi, and G. Tsudik, ‘‘Invited: Reconciling remote attestation and safety-critical operation on simple IoT devices,’’ in Proceedings of the 55th Annual ACM/EDAC/IEEE Design Automation Conference (DAC), pp. 1–6, ACM, 2018. [37] A. Joia Neto and I. De Oliveira Nunes, ‘‘ISC-FLAT: On the conflict between control-flow attestation and real-time operations,’’ in Proceedings of the 29th IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), 2023. [38] A. Caulfield 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 (DAC), pp. 1–6, ACM, 2022. VOLUME 11, 2023

[39] M. Grisafi, M. Ammar, M. Roveri, and B. Crispo, ‘‘PISTIS: Trusted computing architecture for low-end embedded systems,’’ in Proceedings of the 31st USENIX Security Symposium, pp. 3953–3970, USENIX Association, 2022. [40] D. Li Calsi and V. Zaccaria, ‘‘Interruptible remote attestation of lowend iot microcontrollers via performance counters,’’ ACM Transactions on Embedded Computing Systems, vol. 22, no. 5, pp. 1–19, 2023. [41] G. Dessouky, S. Zeitouni, T. Nyman, A. Paverd, L. Davi, P. Koeberl, N. Asokan, and A.-R. Sadeghi, ‘‘LO-FAT: Low-overhead control flow ATtestation in hardware,’’ in Proceedings of the 54th Annual ACM/EDAC/IEEE Design Automation Conference (DAC), pp. 1–6, ACM, 2017. [42] G. Dessouky, T. Abera, A. Ibrahim, and A.-R. Sadeghi, ‘‘LiteHAX: Lightweight hardware-assisted attestation of program execution,’’ in Proceedings of the 2018 IEEE/ACM International Conference on ComputerAided Design (ICCAD), pp. 1–8, ACM/IEEE, 2018. [43] S. Zeitouni, J. Noorman, J. T. Mühlberg, L. Davi, F. Piessens, and A.R. Sadeghi, ‘‘ATRIUM: Runtime attestation resilient under memory attacks,’’ in Proceedings of the 2017 IEEE/ACM International Conference on Computer-Aided Design (ICCAD), pp. 1–8, ACM/IEEE, 2017. [44] 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 2022 IEEE/ACM International Conference on Computer-Aided Design (ICCAD), pp. 1–9, ACM/IEEE, 2022. [45] I. De Oliveira Nunes, S. Jakkamsetti, N. Rattanavipanon, and G. Tsudik, ‘‘On the TOCTOU problem in remote attestation,’’ in Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (CCS), pp. 2606–2622, ACM, 2021. [46] M. Bellare, R. Canetti, and H. Krawczyk, ‘‘Keying hash functions for message authentication,’’ in Annual international cryptology conference, pp. 1–15, Springer, 1996.

AMARIN LAOHAJIRAPAN received the B.Eng. degree in Computer Engineering from Thammasat University in 2016. He is currently pursuing the M.Sc. degree in Computing at Prince of Songkla University, Phuket Campus, Thailand. His research interests include IoT security, remote attestation, and real-time embedded systems.

NORRATHEP RATTANAVIPANON received the Ph.D. degree in computer science from the University of California, Irvine, in 2019. Currently, he is an Assistant Professor with the College of Computing, Prince of Songkla University, Phuket Campus. His research interests include security and privacy, particularly in embedded systems and IoT security, software and binary analysis, and security/privacy in machine learning systems. His research has been published in premier computer security and embedded system venues, including USENIX Security, IEEE S&P, ACM CCS, ICCAD, and DAC. He is also a regular member of the technical program committees for top-tier security conferences.

17

Related documents

• WarpGuard: Towards Control-Flow Attestation for Heterogeneous CPU-GPU Execution#370276
• "They don't care about this": A Systematic Study of TEE Build Reproducibility in the Wild#998942
• Making every test count: Insights from a test kit efficiency audit.#437015
• Proof of Useful Attestation: A Consensus Primitive for Attestation-Native Chains#224398
• Drishti: AI-Led Human-Directed Vulnerability Auditing for 5G Cores#622450