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: [email protected]) College of Computing, Prince of Songkla University, Phuket Campus, Phuket, Thailand (e-mail: [email protected])
arXiv:2607.23698v1 [cs.CR] 26 Jul 2026
Corresponding author: Norrathep Rattanavipanon (e-mail: [email protected]).
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