1
D-MUTRA: DLT-based MUTual Remote Attestation for Multi-Agent Systems
arXiv:2608.01938v1 [cs.CR] 3 Aug 2026
Adam Zahir, Vincent Lefebvre, Mark Angoustures, Milan Groshev, and Carlos J. Bernardos
Abstract—Multi-agent systems (MAS) comprise autonomous software agents that collaborate to perform complex tasks in cyber-physical domains, including multi-robot coordination and the Industrial Internet of Things (IIoT). In such distributed environments, a compromised agent may execute modified software while appearing trustworthy, causing other agents to act on false information and corrupting the mission. Agents must therefore establish and maintain mutual trust throughout operation. Remote attestation (RA) is a well-established technique for this purpose, enabling a remote agent to assess the integrity of a potentially compromised agent. However, conventional RA approaches face significant limitations in MAS: integrity guarantees are restricted to boot or application-load time, designs rely on centralized trusted verifiers or security hardware, and attestation records lack transparency and auditability. To address these limitations, this paper presents D-MUTRA, a blockchainbased framework that introduces a mutual RA protocol in which agents measure their runtime integrity while verifying that of their peers, acting as both prover and verifier. The framework operates entirely in software and relies on two components: a Security-as-a-Service that instruments agents with lightweight measurement and verification capabilities, and a smart contract that coordinates the attestation protocol in a decentralized and transparent manner. We implement a proof-of-concept on a private Ethereum blockchain using Hyperledger Besu and evaluate it in a swarm robotics scenario built with Robot Operating System (ROS) and the Gazebo simulator. Results show that D-MUTRA enables agents to continuously attest one another, detects malicious software modifications, and scales to large deployments with negligible overhead on protected applications. Index Terms—Remote Attestation, Blockchain, Distributed Security, Multi-Agent Systems, Cyber-Physical Systems
I. I NTRODUCTION Multi-Agent Systems (MAS) are composed of autonomous software agents that collaborate to solve complex problems in cyber-physical domains, such as multi-robot systems, the Industrial Internet of Things (IIoT), and autonomous network management [1]. In such distributed environments, a compromised agent may execute modified software while appearing trustworthy, causing other agents to act on false information and corrupting the mission. Ensuring that agents execute the intended software is therefore a fundamental security requirement in MAS [2], commonly addressed through remote attestation (RA), a mechanism that enables a remote entity, the Adam Zahir and Carlos J. Bernardos are with the Department of Telematics, Universidad Carlos III de Madrid, 28911 Leganes, (e-mail: [email protected]; [email protected]) Vincent Lefebvre and Mark Angoustures are with sarl TAGES SOLIDSHIELD, 06110 Le Cannet, France (e-mail: [email protected]; [email protected]) Milan Groshev is with the IE School of Science and Technology, 28046, Madrid, Spain (e-mail: [email protected])
verifier, to assess the integrity of a potentially compromised device or software agent, the prover [3]. However, conventional RA provides only a point-in-time guarantee, typically at boot or application loading, leaving runtime modifications undetected [4]. Runtime integrity verification (RIV) addresses this limitation by continuously measuring software integrity during execution, extending RA assurances throughout the agent’s operational lifetime. Despite extensive research on RA and RIV [5]–[13], existing schemes rely on a trusted verifier to evaluate the integrity of remote devices. However, MAS operate as peers and must continuously verify each other’s integrity, as compromises may occur at any point during execution. We define this trust model as mutual RA, in which agents act as both prover and verifier and sustain this mutual verification continuously through RIV. This continuous, mutual verification must remain lightweight, as frequent measurements strengthen security but add computational overhead that impacts the performance of the protected applications [14]. Realizing mutual RA further requires tamper-resistant infrastructure that operates without a central authority while ensuring secure, transparent, and immutable interactions. Distributed Ledger Technologies (DLTs) such as blockchain naturally satisfy these requirements. Although prior work has explored decentralizing RA through collaborative verification schemes [15], [16] and blockchain [17]–[21], these approaches assume a unidirectional trust model and depend on dedicated security hardware, such as a Trusted Platform Module (TPM) or Trusted Execution Environment (TEE) (e.g., Intel SGX or ARM TrustZone). To the best of our knowledge, no existing work supports mutual RA through blockchain technology. To address this gap, we propose D-MUTRA (DLT-based MUTual Remote Attestation): a blockchain-based framework for mutual RA in MAS. D-MUTRA allows distributed agents to continuously measure their own integrity at runtime while simultaneously verifying that of their peers. The framework is implemented entirely in software without hardware dependencies and relies on two key components: a Security-as-aService (SECaaS) backend that equips agents with lightweight measurement and verification capabilities before deployment, and a blockchain smart contract that coordinates the protocol in a decentralized and auditable manner. The smart contract dynamically assigns the verifier role to the most recently attested agent, creating a chain of trust in which every verifier is the last verified participant. In summary, the contributions of our research are as follows: • We introduce D-MUTRA, a blockchain-based framework for mutual RA in MAS that enables agents to continuously prove their own integrity and verify that of their
2
peers at runtime, applicable to any software application running on commodity hardware. • We implement a working prototype of D-MUTRA on a private Ethereum blockchain using the open-source Hyperledger Besu platform. • We experimentally evaluate D-MUTRA in a swarm robotics scenario, demonstrating its performance, scalability, and security resilience. • We provide a security analysis covering common attack vectors, including software tampering, impersonation, and denial-of-service attacks. The rest of the paper is organized as follows. Section II provides the necessary background to understand the concepts discussed in the paper. Section III outlines the key challenges of mutual RA in MAS. Section IV describes the D-MUTRA architecture and workflows. Section V analyzes its security properties. Sections VI and VII present the experimental evaluation and results. Section VIII discusses the results, limitations, and future work. Section IX compares related work. Finally, Section X concludes the paper. II. BACKGROUND A. Multi-Agent Systems Multi-Agent Systems (MAS) are composed of software programs (agents) that cooperate within a shared environment to execute tasks that would be impractical for a single agent to perform alone. By distributing computation and decisionmaking, MAS improve scalability, flexibility, and fault tolerance. Representative applications include multi-robot systems, the IIoT, and autonomous network management [1]. The distributed and autonomous characteristics that make MAS effective also introduces security concerns. Compromised agents may disrupt system behavior, manipulate shared information, or influence collective decisions [2]. Before exchanging data or collaborating, agents must establish mutual trust by verifying two properties: i) identity, that a peer is the entity it claims to be, and ii) software integrity, that its executable code and runtime state have not been maliciously modified. While identity can be established through standard authentication mechanisms such as public-key cryptography, verifying software integrity requires a security mechanism known as remote attestation (RA). B. Remote Attestation RA enables a remote entity to assess over a network whether the software running on a device has been modified or deviates from a trusted configuration [3]. A typical RA protocol involves two parties: the verifier, which evaluates attestation evidence, and the prover, the device under inspection. The prover generates cryptographic measurements of its software through a Root of Trust (RoT) component, which provides a trusted foundation for the measurement process. Attestation may be initiated by the verifier through a challenge-response protocol to obtain fresh measurements from the prover or performed periodically. The prover sends the resulting evidence to the verifier, which compares it against known-good reference
measurements to assess device trustworthiness. RA schemes are generally classified into three categories. Hardware-based solutions [22], [23] equip the prover with a dedicated security component, such as a TPM [24] or a TEE (e.g., Intel SGX [25] or ARM TrustZone [26]), to generate and sign attestation evidence. These components provide tamperresistant key storage and strong integrity guarantees. However, dependence on vendor-specific hardware limits portability and increases deployment costs. Software-based solutions [27], [28] eliminate hardware dependencies by relying entirely on software mechanisms, such as cryptographic hashing of program memory, to verify device integrity. These approaches suit legacy devices and heterogeneous hardware environments but typically require strong adversarial assumptions, including direct communication between prover and verifier, and lack secure storage for cryptographic keys or attestation code. Hybrid approaches [29], [30] combine software techniques with lightweight hardware components such as Read-Only Memory (ROM) and Memory Protection Units (MPU), providing stronger security guarantees than purely software-based solutions with minimal hardware support. These schemes are commonly studied in resource-constrained IoT devices, which may limit their applicability to general-purpose systems. Although definitions vary slightly, RA is commonly viewed as a mechanism for verifying software integrity at a specific point in time, typically during boot or application loading. As a result, modifications introduced after attestation, such as runtime memory injections or code-reuse attacks, may remain undetected [4]. Runtime integrity verification (RIV) addresses this limitation by continuously monitoring software integrity during execution [10], which is particularly important for longrunning systems. C. Blockchain Supporting RA and RIV in distributed MAS requires tamper-resistant infrastructure that operates without a central authority and ensures attestation interactions remain secure, transparent, and immutable. Blockchain naturally satisfy these requirements. Originally introduced as the technology underlying Bitcoin [31], blockchain is a decentralized ledger replicated across nodes in a peer-to-peer network. The ledger consists of an ordered sequence of timestamped blocks that store transactions and arbitrary data. Each block references the cryptographic hash of its predecessor, creating a tamperresistant chain extending to the genesis block (block 0). New blocks are added through a consensus mechanism that ensures a consistent view of the ledger across nodes. Blockchain networks can be classified along two orthogonal dimensions: accessibility and consensus participation. Network accessibility may be public, where ledger data are openly accessible to any entity, or private, where access is restricted to authorized participants. Consensus participation may be permissionless, allowing any participant to validate transactions without prior authorization, or permissioned, restricting this role to approved entities. Public blockchains are typically permissionless and private blockchains permissioned,
3
though hybrid configurations exist. In D-MUTRA, we employ a private, permissioned blockchain in which smart contracts coordinate the attestation protocol in a decentralized manner. The immutable ledger maintains a tamper-resistant history of attestation results, enabling agents to make informed trust decisions before collaborating. III. M UTUAL R EMOTE ATTESTATION C HALLENGES IN M ULTI -AGENT S YSTEMS Existing RA schemes (reviewed in Sec. IX) establish trust in one direction only, with a single trusted verifier assessing the integrity of a remote device. In MAS, however, agents operate as peers and must verify each other’s software integrity before collaborating. This bidirectional trust model, where each participant acts as both prover and verifier, is referred to as mutual remote attestation (mutual RA). Moreover, integrity cannot be guaranteed at deployment time alone, as compromises may occur at any point during execution. Continuous RIV is therefore a necessary complement to mutual RA throughout each agent’s operational lifetime. We identify the following challenges to realize mutual RA in MAS: • C1 – Decentralized Verification. Traditional RA protocols rely on a single trusted verifier. In MAS, designating a central trusted authority is impractical, as it introduces a single point of failure vulnerable to denial-of-service (DoS) attacks and offers no guarantee the verifier itself has not been compromised. The challenge is twofold: selecting which agent acts as verifier for each attestation round, and ensuring that the selected agent is itself trustworthy at that time. • C2 – Auditable Trust History. Conventional RA bases trust decisions on the most recent attestation result provided by a designated verifier. A successful attestation confirms only that a device was in a trustworthy state at that specific point in time, with no record of prior compromises. Given the long-term operation of MAS agents, meaningful trust assessment requires a shared, tamper-resistant record of attestation outcomes accessible to all participants. • C3 – Hardware Assumptions. MAS agents are typically deployed on commodity hardware lacking dedicated security components such as TPMs, TEEs (e.g., SGX, TrustZone), or ROM. However, existing RA schemes largely assume such hardware and are designed for constrained IoT devices with static configurations, limiting their applicability to general-purpose MAS deployments. These limitations highlight the need for a hardwareindependent RA mechanism. • C4 – Workload Performance Impact. Continuous RIV requires each agent to measure its executable code at regular intervals. The measurement frequency determines the vulnerability window, i.e., the period during which a compromise may remain undetected, and affects application performance [14]. Higher frequencies reduce the window but increase computational overhead, while lower frequencies reduce overhead at the cost of a wider window. Balancing this trade-off between security and performance is a practical design challenge.
•
C5 – Ledger Storage Scalability. In blockchain-based attestation schemes, each verification is typically recorded as a transaction on the ledger. Because RIV generates measurements continuously across multiple agents, transaction volume increases with measurement frequency and system size. Preserving auditability while controlling ledger growth becomes difficult as the system scales. IV. T HE D-MUTRA F RAMEWORK
D-MUTRA addresses the challenges in Sec. III through three design decisions. First, to enable decentralized mutual RA and maintain an auditable trust history (C1, C2), the framework leverages a blockchain network and smart contract. Blockchain provides cryptographic integrity guarantees and an immutable record of attestation interactions, while the smart contract coordinates protocol execution transparently and assigns verifier responsibilities to the most recently verified agent. Second, to eliminate hardware dependencies (C3), attestation is implemented entirely in software, enabling deployment across heterogeneous platforms. Third, to bound the overhead of continuous RIV on protected workloads and the blockchain storage (C4, C5), the framework uses a configurable measurement interval to limit the computational load on each agent and a rolling hash mechanism to aggregate multiple measurements into a single transaction submission, decoupling blockchain growth from measurement frequency. The following subsections describe the D-MUTRA system architecture (Sec. IV-A) and operational workflows (Sec. IV-B). A. System Architecture Fig. 1 presents the D-MUTRA architecture, comprising four components: the MAS agents, untrusted entities undergoing mutual integrity verification; the MAS orchestrator, which manages agent deployment and configuration; Security-asa-Service (SECaaS), which prepares agents for attestation and provides reference measurements at runtime; and the blockchain network, which coordinates the protocol and maintains a tamper-resistant, auditable record of all outcomes. MAS Agents. Each agent (lower part of Fig. 1) consists of its native application and a lightweight attestation sidecar process that runs alongside it. The sidecar enables each agent to prove its own integrity and verify that of its peers, supporting mutual RA through three modules: the prover, the verifier, and the blockchain client. The prover computes integrity measurements and submits them to the smart contract. At startup, it hashes the executable code of both the application and sidecar to establish a trusted baseline, then repeats this measurement periodically to detect runtime modifications. Two configurable parameters govern this process. The sidecar sleep period (SSP) specifies the interval between successive measurements, setting the tradeoff between the vulnerability window and the computational overhead imposed on the agent. To limit the frequency of attestation transactions submitted to the blockchain, consecutive measurements are aggregated into a rolling hash before submission. The iteration queue size (IterQ) defines the number of measurements included in each aggregated submission.
4
MAS Orchestrator
Agent App Attestation Sidecar
Security-as-a-Service (SECaaS) Wrapper
Database
Blockchain Client
Pre-deployment Runtime
Fallback Verifier
Oracle
Reference measurements
Private Blockchain Network Timestamp Transactions
Timestamp Transactions
Timestamp Transactions
Block 0
Block n-1
Block n
Immutable Ledger
Node
Node Attestation Smart Contract
Node
Node
Multi-Agent System
Integrity measurements / Verification results Agent A
measure integrity Agent App
Blockchain Client Verifier Prover Attestation Sidecar
Agent B
measure integrity Agent App
Blockchain Client Verifier Prover Attestation Sidecar
Agent N
. . . measure integrity Agent App
Blockchain Client Verifier Prover Attestation Sidecar
Fig. 1. D-MUTRA architecture supporting mutual remote attestation in MAS.
The verifier validates the integrity of other agents. When selected by the smart contract, it retrieves the prover’s measurement and the corresponding SECaaS reference, reconstructs the expected rolling hash, compares it with the submitted value, and records the verification result on the blockchain. The blockchain client provides a lightweight interface between the agent and the blockchain. To minimize overhead, particularly on resource-constrained edge devices, agents do not host blockchain nodes or participate in the consensus protocol. Instead, the client signs and submits transactions on behalf of the agent and forwards smart contract events to the prover and verifier. Notably, the sidecar interacts with the rest of the system exclusively through blockchain transactions, keeping it decoupled from the core agent application. Blockchain Network. D-MUTRA targets MAS deployments operating within a single administrative domain, such as industrial multi-robot systems and IIoT infrastructures. In these environments, the attestation protocol must restrict participation to authorized entities while supporting low-latency processing for timely detection of compromised agents. To meet these requirements, we employ a private and permissioned blockchain that provides controlled participation and predictable, low-latency transaction processing. The network (center of Fig. 1) comprises distributed nodes that maintain the shared ledger, order and validate transactions through a consensus protocol, and execute smart contract logic deterministically. These nodes operate independently of agent workloads and may be deployed on dedicated infrastructure within or outside the MAS environment. Every transaction is cryptographically signed, timestamped, and permanently recorded. At the core of the network, the attestation smart contract autonomously coordinates the attestation protocol. It receives measurements from provers, selects the most recently attested agent as the verifier, grants it access to the SECaaS reference measurement, and records the verification result on the ledger, thereby maintaining a sequential chain of trust. Security-as-a-Service (SECaaS). SECaaS (upper-right of
Fig. 1) supports D-MUTRA before deployment and runtime phases. Before deployment, the wrapper generates an attestation sidecar, computes a reference measurement by hashing the combined application and sidecar code, and creates a unique blockchain key pair per agent. These artifacts are stored in a secure database accessible only to the oracle, which supplies reference measurements to the smart contract, and the fallback verifier, which performs verification when no peer agent is available. At runtime, the oracle monitors the smart contract for attestation requests, retrieves the corresponding reference measurement, and submits it to the blockchain while restricting access to the verifier selected for that round. If no eligible peer agent is available, the fallback verifier performs the attestation by comparing the agent’s measurement with the stored reference and submitting the result to the smart contract. MAS orchestrator. The MAS orchestrator (upper-left of Fig. 1) manages agent provisioning and deployment. It submits each agent application to the SECaaS wrapper to obtain an attestation-ready image, deploys each agent together with its sidecar, and configures SSP and IterQ according to the deployment requirements. B. Operational Workflows D-MUTRA operates as an evolving chain of trust. In each attestation round, an agent proves its integrity to the most recently attested peer, which serves as its verifier. Upon successful attestation, the agent assumes the verifier role for the next round. This process is realized through three workflows: pre-deployment, which prepares agents for attestation and registers them with the smart contract; initial attestation, which establishes the initial trust anchor for newly deployed agents; and continuous attestation, which maintains trust through ongoing integrity verification. Pre-deployment. This phase is executed offline by the MAS orchestrator and only needs to be done once. For each agent, the orchestrator submits the application to SECaaS, which generates an attestation sidecar, computes a reference integrity measurement href , and creates a unique blockchain address and private key. The private key enables the agent to sign transactions, while the blockchain address serves as its public identifier. The reference measurement and blockchain address are stored in the SECaaS database, and the address is registered with the smart contract to authorize the agent to submit attestation transactions. Initial Attestation. When a newly deployed agent starts up, it immediately performs its initial attestation. This process follows the same procedure as continuous attestation (described below) except that the prover submits a single measurement rather than a hash computed from successive measurements (i.e., a rolling hash), and SECaaS acts as the fallback verifier. Continuous Attestation. Once initial attestation succeeds, each agent participates in continuous attestation throughout its operational lifetime. Fig. 2 illustrates a representative round, with agent A as the prover and agent B, the most recently verified agent, as the verifier. At each SSP interval, agent A (sidecar process) collects an integrity measurement and updates a rolling hash (step 1). After IterQ measurements,
5
Attestation Smart Contract
Agent A (Prover) loop 1
opt 2
Agent B
SECaaS
(Verifier)
(Oracle)
[every SSP] Collect measurement & Update RollHash (hA) [measurements accumulated = IterQ] Submit hA & IterQ 3
4
6
Store hA, IterQ & Select Agent B as verifier Notify new attestation Submit reference measurement (hAref) Store hAref (restricted to current verifier)
Evidence ready 7 Query attestation evidence 8 hA, hAref & IterQ 9 Submit verification result 10 alt Update Agent A 11 to trusted & Set [result = true] as next verifier [result = false] 12 Update Agent A to untrusted
5
Verify RollHash (hAref, IterQ) = hA
Attestation closed 13
Fig. 2. Continuous attestation workflow.
it submits the rolling hash, hA and IterQ to the smart contract (step 2). The smart contract stores the submitted data, assigns agent B as verifier, and emits an event announcing a new attestation round (steps 3–4). SECaaS retrieves the corresponding reference measurement href A from its database and submits it to the smart contract (steps 5–6). It is important to note that access to the reference measurement is restricted to the designated verifier, and the identities of both the prover and verifier remain hidden from all other agents until the attestation round is completed. Agent B is then notified that the verification evidence is ready (step 7). It retrieves hA , href A , and IterQ (step 8), reconstructs the expected rolling hash, compares it with hA , and submits the verification result to the smart contract (steps 9–10). On success, agent A is recorded as trusted and set as the verifier for the next round (step 11); on failure, it is recorded as untrusted and excluded from verifier selection until a future attestation succeeds (step 12). Finally, the smart contract broadcasts an attestation closed event (step 13), disclosing the blockchain addresses of the prover and verifier, the attestation outcome, and timestamp. This on-chain record enables agents to query peer trust status and full attestation history before collaboration. V. S ECURITY A NALYSIS This section presents the adversary model assumed by DMUTRA and analyzes its resilience against the considered threat classes. A. Adversary Model We consider an adversary with access to the network environment in which agents operate, capable of observing
communications and targeting both agents and the attestation process. The common threat model in the MAS security and RA literature identifies three principal threat classes [2], [15], [16]: i) software tampering, where the adversary modifies an agent’s code or injects malicious instructions to alter runtime behavior; ii) impersonation, where an adversary operates under a false identity to influence attestation outcomes; and iii) denial-of-service (DoS), where the adversary targets the entities responsible for verification—particularly verifier agents and SECaaS—to disrupt the completion of integrity checks. Physical attacks on the underlying hardware and attacks against the blockchain consensus mechanism are considered out of scope. B. Security Analysis i) Software Tampering. D-MUTRA addresses software tampering through the use of RA and RIV. RA establishes a trusted baseline at deployment by verifying agent integrity before admission, while RIV maintains that baseline during execution. At each SSP interval, the prover measures the application and sidecar executables and incorporates the results into a rolling hash submitted to the smart contract. The designated verifier compares the fresh measurement against the SECaaS reference and records the result on-chain. Any mismatch marks the agent as untrusted and excludes it from verifier selection, detecting runtime modifications that RA alone cannot capture. Verifier trustworthiness is reinforced through rotation: the most recently attested agent is selected as verifier each round, minimizing the time elapsed since its last integrity check. ii) Impersonation. Agent identity rests on two layers. Before deployment, SECaaS provisions each agent with a blockchain key pair, which must be registered in the smart contract before participation. At runtime, each transaction is validated by the blockchain against the sender’s signature and by the smart contract against the registered address set. Identity is further coupled with integrity. The reference measurement covers both application and sidecar binaries and is bound to the agent’s blockchain address in the SECaaS database. Impersonation therefore requires simultaneously compromising the private key and replicating the exact software state of the target agent. Network-layer attacks such as ARP spoofing or IP spoofing are not applicable, since agents interact exclusively through blockchain transactions. iii) Denial-of-Service (DoS). All attestation interactions are mediated through the smart contract, eliminating the direct communication channels that conventional RA schemes expose to DoS attacks. Verifier and prover identities are disclosed only when attestation closes, preventing targeted attacks on specific verifiers. Every interaction requires a signed transaction from a registered address, blocking unauthorized participation. When no eligible verifier agent is available, the SECaaS fallback verifier ensures continuity of the protocol. VI. E XPERIMENTAL E VALUATION A. Experimental Setup To evaluate D-MUTRA, we designed a swarm robotics scenario based on multi-robot formation control, a representative
6
Fallback Verifier
Blockchain Client
Database
Wrapper
Oracle
Ethereum Private Network Node 1
Node 3 Attestation.sol
VM-01
Node 2
MAS Orchestrator
VM-02 Docker API
Robot Simulator
Node 4
Trajectory to Global Goal
JSON-RPC
Robotic Agent Robot App Formation Controller Odometry Publisher Mobility Drivers
Shared PID namespace
Blockchain network. The private blockchain is built on Hyperledger Besu1 , an open-source framework for enterprise-grade blockchains based on the Ethereum ecosystem. The network consists of four validator nodes using the QBFT (Quorum Byzantine Fault Tolerance) consensus, which tolerates up to one-third (1/3) malicious validators and provides fast block finality. The consensus is configured with a 2 s block period, corresponding to the average time to validate transactions, include them in a block, and append the block to the blockchain. This configuration is widely adopted in private Ethereum networks with small validator sets, as it balances transaction-confirmation latency and throughput [33]. The smart contract (Attestation.sol), coded using the Solidity programming language, realizes the attestation protocol described in Sec. IV-B and is deployed on this network. Agents and SECaaS interact with the contract through Web3-compatible JSON-RPC endpoints exposed by the validator nodes. • MAS agents. Each agent consists of two containers sharing a PID namespace. The robot application runs on Robot Operating System 2 (ROS 2) and controls a simulated TurtleBot32 mobile robot executing the formationcontrol task. Its functionality is implemented through a set of ROS 2 nodes (software modules) written in C++, including: an odometry publisher that estimates and broadcasts robot position; a formation controller that combines local and peer odometry data to compute velocity commands for maintaining the desired geometric formation; and mobility drivers that execute the motion commands. The sidecar, implemented in Go, operates independently of the application and includes prover and verifier modules connected to the blockchain through a go-ethereum3 client. The prover accesses the robot
•
SECaaS
JSON-RPC
MAS application widely studied in the literature [32]. The scenario models an industrial inspection task where robots follow predefined trajectories while maintaining a geometric formation to maximize area coverage. To support distributed control, robots periodically exchange position information. A compromised robot may inject falsified position updates, leading to incorrect control actions that disrupt the formation and degrade mission performance. D-MUTRA enables the early detection and isolation of compromised robots through continuous software attestation. The experimental testbed (Fig. 3) consists of two virtual machines (VMs) and one bare-metal server. VM-01 runs the SECaaS and the MAS orchestrator, while VM-02 hosts a private blockchain network, each provisioned with 4 vCPUs and 4 GB of RAM. Robotic agents run in simulation on the bare-metal server, equipped with an Intel Core Ultra 9 275HX CPU (24 cores, up to 6.5 GHz), 64 GB of RAM, and an NVIDIA RTX 5080 GPU. The testbed follows a cloudnative design where all components run as Docker containers, including:
Attestation Sidecar Blockchain Client Prover Verifier
Bare-metal Server
Fig. 3. Swarm robotics experimental testbed and scenario.
process through the /proc4 filesystem, extracts the executable code section, computes a SHA-256 measurement over the application and sidecar binaries, and submits it to the smart contract. The verifier listens to contract events and, when selected, compares fresh and reference measurements before recording the result on-chain. 5 • Robot simulator. The Gazebo simulator provides a shared backend for all agents, handling physics simulation, sensor data generation, and robot state updates. • SECaaS. SECaaS hosts five coordinated services that prepare agents for attestation at pre-deployment and support the protocol at runtime. The wrapper exposes a REST API through which the MAS orchestrator submits robot binaries and receives the corresponding sidecar binaries. For each agent, it parses the robot binary in ELF (Executable and Linkable Format) using pyelftools6 , generates the sidecar, computes a SHA-256 reference measurement over both binaries, and creates a blockchain key pair. Reference data are stored in a PostgreSQL7 database. At runtime, the oracle and fallback verifier interact with the blockchain via web3.py8 library. • MAS orchestrator. A Python-based orchestrator coordinates sidecar preparation via SECaaS and manages agent lifecycle operations (creation, modification, deletion) in the container infrastructure. The testbed is designed to emulate a real-world deployment of physical robots and distributed infrastructure for the trusted components of D-MUTRA (i.e., the MAS orchestrator, SECaaS, and the blockchain network). The robot application stack and attestation sidecar are identical to those deployed on physical hardware, while only the robot dynamics and environment sensing are abstracted by the simulator. Moreover, the co-location of blockchain nodes on a single VM does not introduce artificial performance advantages because the consensus block period (2 s) dominates attestation latency and is several orders of magnitude longer than the millisecond4 https://docs.kernel.org/filesystems/proc.html 5 https://gazebosim.org
1 https://besu.hyperledger.org
6 https://github.com/eliben/pyelftools
2 https://github.com/ROBOTIS-GIT/turtlebot3 simulations
7 https://www.postgresql.org
3 https://geth.ethereum.org
8 https://web3py.readthedocs.io
7
scale network delays typical between physical nodes in onpremises deployments. Therefore, distributing the blockchain across separate hosts or replacing simulated robots with physical ones would produce equivalent performance results.
B. Evaluation Methodology We evaluate D-MUTRA along two dimensions: performance and scalability under normal operation, and security resilience under a runtime tampering attack. Performance and scalability. We assess the two phases described in Sec. IV-B: initial attestation and continuous attestation. In the initial phase, each robot performs a single attestation immediately after deployment, with SECaaS acting as the fallback verifier. In the continuous phase, robots periodically submit integrity measurements as provers and, when selected by the smart contract, verify other robots, with SECaaS serving as oracle for reference measurements. Experiments are conducted with swarm sizes of N ∈ {4, . . . , 64} concurrently attesting robots, using 20 independent runs per configuration. Continuous attestation experiments run for 2 min. Unless otherwise specified, the sidecar sleep period (SSP), i.e., the interval between consecutive measurements, is set to 10 s, and the iteration queue size (IterQ), i.e., the number of consecutive measurements aggregated into a rolling hash before submission, is set to 1. Please note that each attestation cycle comprises three sequential on-chain transactions (prover submission, oracle response, and verifier result). Since each transaction must be confirmed in a separate block before the next can proceed, and the blockchain is configured with a 2 s block period, the minimum theoretical attestation latency is 3 × 2 s = 6 s. Therefore, the SSP is set to 10 s to provide sufficient timing margin and ensure that each attestation cycle completes before the next measurement is generated.
Security resilience. We evaluate system resilience using a four-robot swarm in a square formation executing a straightline trajectory. Three scenarios are considered. In the baseline, no attack is present. In the unmitigated scenario, NOP instructions are injected into the .text segment of one robot, corrupting its formation controller to produce a constant angular velocity of 2.5 rad/s with zero linear velocity. As a result, the robot spins in place without forward motion. Because robots make control decisions based on odometry from their peers, the failure propagates through the swarm and prevents mission completion. This scenario measures the impact of the attack over a 300 s interval. In the mitigated scenario, the same attack is launched with D-MUTRA enabled. The compromised robot is detected and excluded from the formation control loop, after which the remaining three robots reconfigure into a triangular formation and complete the mission. This scenario evaluates the effectiveness of timely attack detection through attestation. Resilience is quantified using the following metrics: • Tampering detection time. Time between runtime tampering and on-chain recording of the corresponding verification failure. • Swarm formation degradation. Total formation error accumulated during the compromise window, defined as the interval from attack injection to attack detection (mitigated case) or mission failure (unmitigated case). At each timestep, formation error is computed as the mean Euclidean distance between each robot and its assigned formation position relative to the swarm centroid, capturing how distorted the formation shape is at that instant. Ground-truth robot poses are obtained from the Gazebo physics engine. The cumulative formation error is the sum of these per-timestep errors over the compromise window. VII. R ESULTS
•
A. Performance and Scalability Results
9 https://docs.docker.com/reference/api/engine
Attestation cycle time. Fig. 4 shows the attestation cycle time as a function of the number of robots (N ) for both initial (top) and continuous (bottom) attestation. Each bar breaks down into four contributions: SHA-256 digest computation at the prover (green), reference measurement retrieval and on-chain submission by the SECaaS oracle (orange), digest verification at the verifier (blue), and blockchain confirmation time (purple), which is the combined waiting time for all transactions in the cycle to be validated and recorded on the blockchain. The inset reports the first three contributions at millisecond resolution. For initial attestation, the mean cycle time increases from 2.7 s at N = 4 to 6.5 s at N = 64, a 2.4× increase despite a 16× increase in swarm size. The standard deviation also increases with N , reaching ±2.0 s at N = 64. This is because SECaaS serves as the sole verifier for all robots and processes requests sequentially, introducing queueing delays as N grows. Blockchain confirmation dominates latency at 96–98% across all N . This result is expected because each initial attestation requires two sequential transactions (the prover’s measurement and the SECaaS verification result), each awaiting at least one block period (2 s) for confirmation. As shown in the inset,
Attestation cycle time. Time to complete a single attestation cycle from the prover’s perspective, from the start of SHA-256 digest computation until reception of the on-chain event confirming attestation completion. Timestamps are collected at transaction submission and event reception points in the prover, verifier, and SECaaS. • Sidecar resource consumption. CPU (vCPUs) and memory (active working set, MB) usage of the sidecar container. Both metrics are sampled at 1 s intervals via the Docker Engine API9 , which isolates sidecar computational overhead from other host processes. • Robot message interval. Interval between consecutive odometry messages published by the attested robot application, measured by an independent subscriber ROS 2 node. A baseline is established with the sidecar disabled, then measurements are repeated under decreasing SSP values to assess the impact of high-frequency attestation on application timing. • Blockchain storage growth rate. Growth rate of the blockchain measured at a single node for different swarm sizes and IterQ values.
8
100
6 4 2 0
25
2
8
16
32
0.15 0.10 0.05 0.00
64
4
75
16
32
40 20 0
64
4
8
16
32
64
Number of robots (N)
Fig. 5. CPU and RAM usage of the sidecar (per robot) and SECaaS during continuous attestation for different swarm sizes (N ). CPU usage is reported in vCPUs (1 vCPU = 1 logical core).
50 25 0
8
60
Number of robots (N)
Robot sidecar 4
8
16
32
64
Number of robots (N)
Fig. 4. Attestation cycle time as a function of the number of robots (N ), for initial (top) and continuous (bottom) attestation, decomposed into its main latency components. Bars indicate the mean across robots and runs, while error bars denote the standard deviation.
SHA-256 computation remains stable at 13–17 ms, while the SECaaS contribution increases slightly from 85 ms to 97 ms. For continuous attestation, the mean cycle time increases from 4.6 s at N = 4 to 7.1 s at N = 64. The higher baseline compared with initial attestation is due to an additional transaction in which the SECaaS oracle submits the reference measurement, bringing the total to three sequential confirmations per cycle. Despite this, the variance remains low, with a standard deviation below 0.22 s for all N . This is because verification is distributed among robots, eliminating the bottleneck associated with a single verifier. The inset further shows that the non-blockchain contributions remain stable: SHA-256 within 13–17 ms, oracle processing within 60–68 ms, and peer verification within 12–19 ms. Resource consumption. Fig. 5 shows the CPU and memory usage of the sidecar (per robot) and SECaaS during continuous attestation. Sidecar CPU remains stable between 0.017 and 0.022 vCPU across swarm sizes ranging from N = 4 to N = 64, while memory stays within 65–70 MB. These results indicate negligible scaling overhead and confirm that the sidecar imposes a lightweight, per-robot cost that is effectively independent of N . SECaaS CPU usage, on the other hand, increases moderately from 0.054 vCPU at N = 4 to 0.230 vCPU at N = 64, reflecting its role as the oracle that serves an increasing number of robots requiring reference measurements. Nevertheless, it remains below 1 vCPU (i.e., one logical core) even at the largest scale. Despite their different roles, both components show similar memory footprints, since memory usage is dominated by the overhead of each runtime environment (Go for the sidecar, Python for SECaaS) rather than by attestation activity itself. Fig. 6 further illustrates the temporal behavior of CPU utilization during a representative run. Both components exhibit periodic bursts of activity every 10 seconds, corresponding to the configured SSP. Notably, The SECaaS CPU peaks are delayed by a few seconds relative to the sidecar, consistent
CPU (vCPUs)
4
Number of robots (N)
0.20
SECaaS
Attestation cycle
0.2 0.1 0.0
0
10
20
30
40
50
60
70
Time (s)
80
90
100 110 120
Fig. 6. CPU usage of the sidecar (per robot) and SECaaS over time. 1.0 0.95
0.8
ECDF
6
4
0.25
100
Time (ms)
Time (s)
50
0
Continuous Attestation
0
75
SECaaS 80
RAM usage (MB)
Initial Attestation Time (ms)
Time (s)
8
Robot sidecar
Verification Blockchain confirmation
CPU usage (vCPUs)
SHA-256 computation Oracle retrieval
0.90 0.85
0.6 0.4 0.2 0.0
No attestation SSP = 10 s SSP = 5 s SSP = 1 s SSP = 0.01 s
0.80 34.16
34.24
34.32
33.50 33.75 34.00 34.25 34.50 34.75 35.00 35.25
Robot message inter-arrival time (ms)
Fig. 7. ECDF of message inter-arrival times for the robot application under high-frequency sidecar sleep period (SSP) values.
with the sequential execution flow: the oracle processes each request only after the prover’s transaction is confirmed onchain. Between attestation cycles, both components return to low steady-state utilization, confirming that resource consumption is event-driven. Robot message interval. Fig. 7 shows the empirical cumulative distribution of message inter-arrival times for the attested robot application under different SSP configurations. The median remains constant at 34.0 ms across all settings. Even under the most frequent measurement interval (SSP = 10 ms), the 99th percentile increases by only 0.34 ms compared to the baseline without attestation. These results indicate that the attestation sidecar introduces no measurable performance overhead on the robot application. Blockchain storage growth. Fig. 8 shows the storage growth rate of the blockchain as a function of N for different IterQ values. With IterQ = 1, each integrity measurement is submitted as a separate transaction, producing the highest growth rate. As N increases from 4 to 64, the growth rate rises from 0.58 KB/s to 2.88 KB/s, a 5× increase. Increasing
2.0 1.5 1.0 0.5 0.0
4
8
16
32
64
Number of robots (N)
Fig. 8. Growth rate of blockchain during continuous attestation for different number of robots (N ) and iteration queue sizes (IterQ). The dashed line indicates the growth rate without attestation activity.
Robots 1, 2, 4
Robot 3 orientation
Formation outline
Robot 3
Swarm centroid
Goal
2 0 −2 −4 2 0 −2 −4
Attack injection
2 0 −2 −4
Attack injection
Attack detected: Robot 3 isolated
0
Swarm trajectories. Fig. 9 illustrates the trajectories executed by the four robots under the three experimental conditions. In the baseline case (top), all robots maintain the square formation and successfully reach the goal. Under the unmitigated attack (middle), Robot 3 begins spinning immediately after attack injection, as indicated by its circular trajectory and orientation markers. Because the remaining robots rely on its falsified odometry, the formation becomes unstable and the swarm reaches only 32.6% of the target distance. With D-MUTRA enabled (bottom), the compromise is detected, Robot 3 is excluded, and the three healthy robots reconfigure into a triangular formation. The swarm then completes the mission despite the attack. Formation error over time. Fig. 10 shows the instantaneous swarm formation error, i.e., the mean deviation of each active robot from its target position relative to the swarm centroid, over time following attack injection. Under both attack conditions, the error rises to 175–200 mm, approximately 25× the baseline noise level of ∼7 mm (dashed line), as the manipulated velocity commands from robot 3 progressively distort the swarm geometry. At 16 s, the attack on robot 3 is detected, and the healthy robots reconfigure from a four-robot square to a three-robot triangle. This causes a transient error peak of 1.26 m because the error is evaluated against the new target positions immediately after robot 3 is excluded, before the remaining robots reach their updated locations. The error then decreases as the controllers drive the robots toward the triangle geometry, stabilizing at approximately 60 mm. This residual remains above baseline because the triangle formation has wider spacing between robots. Without mitigation, the error remains near 0.2 m for the rest of the experiment. Tampering detection time and cumulative formation error. Fig. 11 shows the effect of SSP on tampering detection time and cumulative formation error during the compromise
20
30
40
50
60
Fig. 9. Robot trajectories during the formation-control task under normal operation (top), with an undetected attack (middle), and with the attack detected by D-MUTRA and the compromised robot isolated (bottom).
Swarm Formation Error (m)
B. Security Resilience Results
10
X (m)
1.4 No attack (baseline) Unmitigated Mitigated
1.2 1.0 0.8
Attack detected: compromised robot isolated
0.6 0.4 0.2 0.0
0
5
10
15
20
25
30
Time since attack injection (s) Fig. 10. Swarm formation error over time from attack injection, without and with D-MUTRA enabled. The dashed line indicates the error level under normal operation. 35 70
Time to Detection (s)
IterQ reduces blockchain growth by aggregating consecutive measurements into a single rolling hash before submission. At N = 64, IterQ = 4 reduces the growth rate to 1.00 KB/s, a 2.9× reduction relative to IterQ = 1. With IterQ = 8, the growth rate remains nearly constant across all evaluated N , and reaches 0.67 KB/s at N = 64, remaining close to the idle baseline of 0.42 KB/s measured without attestation activity.
30
60
25
50
20
40
15
30 20
10
10
5
0
60
30
20
10
5
Cum. Formation Error (m·s)
IterQ = 1 IterQ = 2 IterQ = 4 IterQ = 8 Idle
2.5
Mitigated Unmitigated Baseline Y (m) Y (m) Y (m)
Growth rate (KB/s)
9
0
SSP (s) Fig. 11. Effect of SSP on tampering detection time (left axis) and cumulative formation error during the compromise window (right axis).
window. Detection time decreases monotonically with SSP, approximating SSP plus a fixed offset of about 5.6 s. This offset corresponds to the time the blockchain takes to validate the sequence of three transactions involved in a continuous
10
attestation round and to record its outcome, as shown earlier in Fig. 4. At SSP = 60 s, the mean detection time is 65.6 s, while at SSP = 5 s it reduces to 9.6 s. Cumulative formation damage decreases proportionally, from 12.51 m·s to 1.69 m·s over the same range, confirming that shorter attestation intervals directly limit mission degradation.
VIII. D ISCUSSION The goal of D-MUTRA is to provide an attestation framework that enables distributed software agents to continuously prove their integrity and verify that of their peers throughout their operational lifetime. It employs a software-based attestation protocol coordinated by a blockchain smart contract, eliminating the need for dedicated security hardware or centralized verifiers. By combining RA with continuous RIV, the framework ensures integrity both at deployment and during runtime. Experimental results demonstrate the feasibility of D-MUTRA, showing that agents can successfully attest one another, detect malicious modifications, and scale to large deployments with negligible overhead on protected applications. The evaluation also reveals the costs of this design. Blockchain integration is the primary source of latency, as the protocol relies on multiple transactions that must be propagated, processed, and confirmed before attestation completes. This overhead reflects the cost of implementing attestation on a distributed ledger, where all interactions are recorded as auditable, tamper-resistant transactions. It is worth noting that the average time between two attestations in existing RA schemes is at least 5–10 minutes in the worst cases [19]. Consequently, the latency introduced by blockchain communication remains practical for many deployment scenarios. From a security perspective, attestation latency defines the vulnerability window, i.e., the interval during which a compromise may remain undetected. In D-MUTRA, this window is determined by the sum of the SSP and the blockchain delay. Its acceptable duration depends on the target application and can be adapted via the SSP. For instance, in the swarm robotics use case evaluated in our experiments, short windows are preferable since compromised agents can rapidly propagate falsified data that degrades mission performance. In contrast, less timesensitive applications such as IIoT monitoring can tolerate longer detection intervals since the effects of manipulated data typically accumulate gradually. IterQ introduces an additional trade-off between detection responsiveness and blockchain storage overhead. Aggregating IterQ consecutive measurements into a single rolling hash before submission reduces the number of transactions recorded on-chain. However, each aggregation step delays the publication of attestation evidence by one SSP interval, extending the vulnerability window. For long-term deployments where participating blockchain nodes have limited storage, ledger growth can be further mitigated using established techniques such as state pruning, which removes historical transaction data while preserving the integrity and auditability of the ledger state [34].
A. Limitations and Future Work RIV introduces a Time-of-Check to Time-of-Use (TOCTTOU) gap. During the interval between consecutive measurements, an attacker can modify the executable, run malicious code, and restore the original binary. The rolling hash mechanism partially mitigates this by requiring the binary to be restored before each individual measurement. Nevertheless, more sophisticated attacks remain possible. In a page reconstruction attack, for example, malicious code executes outside the measured memory region while an unmodified replica is maintained in DRAM. A detection gap also exists at agent startup since the blockchain-based attestation process introduces a delay (3–8 s in our experiments) before the initial integrity verdict is established. During this interval, a compromised workload may perform malicious actions before tampering detection. Finally, SECaaS introduces a residual trust dependency on the oracle. If the oracle is unavailable, attestation cannot proceed. If it is compromised, an attacker could manipulate reference measurements and undermine the entire attestation process. Future work will focus on addressing these limitations in three directions. First, we will distribute the SECaaS backend across multiple independent nodes to eliminate the single point of failure and reduce trust assumptions. Second, we will explore anchoring reference measurements directly on-chain at deployment time, thereby removing reliance on an off-chain oracle. Third, we will investigate synchronized and ephemeral measurement techniques to reduce the TOCTTOU window and strengthen runtime integrity guarantees at the prover level. IX. R ELATED WORK A. Collective Remote Attestation Collective remote attestation extends single-device verification to networks of devices, enabling scalable integrity verification across multiple peers. Existing schemes either rely on a centralized trusted verifier or distribute verification responsibilities among participating devices. Centralized verifier model. SEDA [5] organizes provers in a tree topology where attestation evidence propagates upward and is validated by a root verifier. SANA [6] improves on this using Optimistic Aggregate Signatures (OAS) to compress evidence from many provers into a compact proof without trusting intermediate relay nodes. DARPA [7] extends the threat model to physical attacks, detecting compromised devices by monitoring periodic heartbeat exchanges and flagging devices that go offline for a detectable period. RADIS [8] applies this model to distributed IoT services rather than individual devices. Each service attests the control-flow of the service it invokes at runtime, and a single verifier validates the resulting hash chain against a database of legitimate paths computed offline. Despite their differences, all FOUR schemes rely on a single trusted verifier, creating a single point of failure vulnerable to DoS attacks. Distributed verifier model. To remove the dependency on a central verifier, several schemes distribute verification responsibility across participating devices. PASTA [15] enables
11
TABLE I C OMPARISON OF REMOTE ATTESTATION SCHEMES , INCLUDING COLLECTIVE AND BLOCKCHAIN - BASED APPROACHES , AGAINST D-MUTRA. Blockchain Role†
Scheme
Platform
Integrity Measurement
SEDA [5] SANA [6] DARPA [7] PASTA [15] DIAT [16] RADIS [8] ScaRR [9] Kucab et al. [10]
Embedded Embedded Embedded Embedded Embedded Embedded General-purpose General-purpose
Firmware, load-time Firmware, load-time Firmware, load-time Firmware, load-time Control-flow, runtime Control-flow, runtime Control-flow, runtime Control-flow, runtime
Javaid et al. [11] BARRETT [12] DAN [13] PERMANENT [17] LegIoT [18] zRA [19] SCRAPS [20] PONTIS [21]
Embedded Embedded Embedded Embedded Embedded Embedded Embedded General-purpose
Firmware, load-time Firmware, load-time Firmware, load-time Firmware, load-time Firmware, load-time Firmware, load-time Firmware, load-time Enclave image, load-time
Designated authority Designated authority Designated authority Device itself Peer devices Any participant Proxy smart contract Any participant
D-MUTRA
General-purpose
Process memory, runtime
Last-attested peer
Verifier
Bidirectional Trust
Trust Anchor‡
Collective Remote Attestation Designated authority Designated authority Designated authority Peer devices Peer devices Designated authority Designated authority Designated authority
— — — — — — — —
× × × × × × × ×
ROM + MPU ROM + MPU ROM + MPU ROM + MPU TrustZone None (TrustZone opt.) Kernel (SW) SGX + CET
Record only Record only Record only Record only Record only Verify & record Verify & record Verify & record
× × × × × × × ×
PUF ROM TPM ROM + RTC ROM + MPU / TrustZone / TPM ROM + MPU None (TrustZone opt.) SGX / TrustZone
Coordinate & record
✓
Kernel (SW)
Blockchain-based Remote Attestation
† Blockchain Role: Record only — the blockchain stores attestation results; verification is performed off-chain. Verify & record — the blockchain verifies or
distributes attestation evidence. Coordinate & record — the blockchain elects verifiers, distributes evidence, and records outcomes. ‡ Trust Anchor: the component protecting attestation code and cryptographic keys on the prover side.
provers to jointly produce attestation tokens via a Schnorrbased multisignature scheme, embedding integrity proofs for all participants into a compact token that any device can verify independently. DIAT [16] targets autonomous systems, where each device verifies the control-flow integrity of a collaborating peer before accepting its data at runtime. Although these schemes remove the centralized verifier, they require pre-established cryptographic relationships and fixed network topologies with direct connectivity between provers and verifiers. Such assumptions are difficult to satisfy in dynamic environments where devices may join or leave without prior coordination. Attestation of general-purpose systems. Most collective attestation schemes target embedded devices with static firmware and predictable memory layouts, while few address general-purpose systems running complex software stacks. ScaRR [9] provides runtime control-flow attestation for cloud systems via LLVM instrumentation, partitioning execution into sub-paths and verifying them incrementally. Using the Linux kernel as a software trust anchor, it achieves throughput of up to 2 million control-flow events per second. However, compiletime instrumentation introduces runtime overhead, and the design relies on a single verifier. Kucab et al. [10] combine load-time attestation via Intel SGX with runtime control-flow integrity enforced by Intel CET, avoiding instrumentation with minimal overhead. However, the approach depends on vendorspecific hardware (SGX and CET) and does not support decentralized or mutual verification. Overall, existing collective attestation schemes adopt a unidirectional trust model in which only the verifier evaluates the prover. Moreover, while some schemes extend attestation to runtime, they rely either on dedicated security hardware or compile-time instrumentation, limiting their applicability across heterogeneous hardware platforms.
B. Blockchain-based Remote Attestation Blockchain technology has been explored in RA as a secure infrastructure for recording verification outcomes and enabling decentralized interactions between provers and verifiers. Existing schemes differ in how actively the blockchain participates in the attestation process. Blockchain as record only. Several schemes use the blockchain solely as an immutable ledger to store attestation results, while verification is performed off-chain by a designated trusted party. Javaid et al. [11] anchor device identities to Physical Unclonable Functions (PUFs) and store reference measurements on-chain, while a designated verifier challenges provers directly and evaluates responses locally. The blockchain serves only as a data repository, the scheme requires specialized PUF hardware, and provers remain vulnerable to DoS attacks because any entity can issue challenges directly without authorization. BARRETT [12] mitigates this by requiring attestation requests to be submitted as Ethereum transactions, where each request incurs a gas fee that makes flooding attacks economically prohibitive. Nevertheless, evidence is still evaluated off-chain by a trusted third party. DAN [13] distributes attestation records across organizations using a permissioned blockchain built on Hyperledger Fabric and a consortium of verifiers. While this improves auditability, DAN still relies on TPM hardware on every device and assumes the trustworthiness of the verifier consortium. PERMANENT [17] adopts a self-attestation model in which each device measures its integrity at randomized intervals triggered by a hardware timer and publishes signed results to a permissioned blockchain. Other devices assess trustworthiness by querying on-chain history and computing a weighted trust score. However, integrity is self-declared rather than independently verified, and every device must operate as a full blockchain node, imposing significant computational overhead. LegIoT [18] maintains a graph of trust relationships
12
among devices, allowing existing attestation results to be reused across the network and reducing redundant verifications. Attestation is carried out by peer devices, and the blockchain records the resulting trust associations rather than performing verification itself. Blockchain as active participant. zRA [19], SCRAPS [20], and PONTIS [21] use the blockchain to coordinate or verify attestation evidence. zRA introduces a non-interactive attestation protocol based on zkSNARK proofs, enabling any party to independently verify a device’s integrity from its onchain proof without prior knowledge or a designated verifier. However, integrity measurement remains limited to static firmware, and proof generation introduces non-trivial overhead on the constrained hardware that zRA targets. SCRAPS delegates verification to a smart contract that evaluates attestation evidence submitted by publishers on behalf of subscribers. This eliminates the need for a trusted verifier and scales to large IoT networks, but retains a unidirectional trust model in which only publishers are attested, while subscribers are never verified. PONTIS targets general-purpose servers with heterogeneous TEE hardware, using a blockchain-based identity registry to verify TEE instances across different hardware platforms. However, attestation is limited to the enclave image at instantiation time, and every participant requires vendorspecific TEE hardware. Table I summarizes and compares the characteristics of existing RA schemes with those of D-MUTRA. The comparison shows that D-MUTRA is the only solution that supports mutual runtime RA on general-purpose platforms without hardware dependencies. It achieves this through a blockchain-coordinated, software-based attestation protocol in which agents continuously measure their runtime integrity while mutually verifying that of their peers. X. C ONCLUSIONS This paper presents D-MUTRA, a novel blockchain-based framework for mutual remote attestation in multi-agent systems. D-MUTRA enables distributed agents (software applications) to continuously measure their integrity at runtime while verifying that of their peers, acting as both prover and verifier in the attestation protocol. It operates entirely in software, requiring no modifications to protected applications and no security hardware. The framework integrates two components: a Security-as-a-Service backend that prepares agents before deployment with lightweight measurement and verification capabilities, and a blockchain-based smart contract that coordinates the attestation protocol in a decentralized, auditable manner. By designating the most recently attested agent as the next verifier, the contract maintains a dynamic root of trust and reduces the period during which a compromised agent could assume that role. To the best of our knowledge, D-MUTRA is the first framework to support mutual runtime remote attestation using blockchain technology. We implemented a proof-of-concept on a private Ethereum blockchain and evaluated in a swarm robotics scenario. Results show that agents can continuously attest one another, detect malicious modifications, and scale efficiently to large multi-
agent deployments while imposing negligible overhead on protected applications. These findings confirm that mutual remote attestation provides a practical foundation for establishing and maintaining trust in distributed environments. ACKNOWLEDGMENT This work was supported in part by the European Union’s Horizon Europe research and innovation programme through the NATWORK project under Grant Agreement No. 101139285, which funded the design, development, evolution, and security analysis of D-MUTRA carried out by Solidshield. The testbed implementation and experimental validation were further supported by the 6GINSPIRE project (PID2022-137329OB-C42), funded by MCIN/AEI/10.13039/501100011033, and by the EURO-3C project, funded by the European Union’s Horizon Europe research and innovation programme under Grant Agreement No. 101297599. Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of all EURO-3C consortium parties nor those of the European Union (granting authority). Neither of them can be held responsible for them. R EFERENCES [1] A. Dorri, S. S. Kanhere, and R. Jurdak, “Multi-Agent Systems: A Survey,” IEEE Access, vol. 6, pp. 28 573–28 593, 2018. [2] R. Owoputi and S. Ray, “Security of multi-agent cyber-physical systems: A survey,” IEEE Access, vol. 10, pp. 121 465–121 479, 2022. [3] G. Coker et al., “Principles of remote attestation,” Int. J. Information Security, vol. 10, no. 2, pp. 63–81, 2011. [4] T. Abera et al., “C-FLAT: Control-Flow Attestation for Embedded Systems Software,” in Proc. of the 2016 ACM SIGSAC Conf. on Computer and Commun. Security, 2016, pp. 743–754. [5] N. Asokan et al., “Seda: Scalable embedded device attestation,” in Proc. of the 22nd ACM SIGSAC Conf. on Computer and Commun. Security, 2015, pp. 964–975. [6] M. Ambrosin, M. Conti, A. Ibrahim, G. Neven, A.-R. Sadeghi, and M. Schunter, “SANA: secure and scalable aggregate network attestation,” in Proc. of the 2016 ACM SIGSAC Conf. on Computer and Commun. Security, 2016, pp. 731–742. [7] A. Ibrahim, A.-R. Sadeghi, G. Tsudik, and S. Zeitouni, “DARPA: Device Attestation Resilient to Physical Attacks,” in Proc. of the 9th ACM Conf. on Security & Privacy in Wireless and Mobile Networks, 2016, pp. 171– 182. [8] M. Conti, E. Dushku, and L. V. Mancini, “RADIS: Remote attestation of distributed IoT services,” in 2019 Sixth Int. Conf. on Software Defined Systems (SDS), 2019, pp. 25–32. [9] F. Toffalini, E. Losiouk, A. Biondo, J. Zhou, and M. Conti, “ScaRR: Scalable Runtime Remote Attestation for Complex Systems,” in 22nd Int. Symp. on Research in Attacks, Intrusions and Defenses (RAID 2019), 2019, pp. 121–134. [10] M. Kucab, P. Boryło, and P. Chołda, “Hardware-assisted static and runtime attestation for cloud deployments,” IEEE Trans. on Cloud Computing, vol. 11, no. 4, pp. 3750–3765, 2023. [11] U. Javaid, M. N. Aman, and B. Sikdar, “Defining trust in IoT environments via distributed remote attestation using blockchain,” in Proc. of the 21st Int. Symp. on Theory, Algorithmic Foundations, and Protocol Design for Mobile Networks and Mobile Computing, 2020, pp. 321–326. [12] M. Bampatsikos, C. Ntantogian, C. Xenakis, and S. C. Thomopoulos, “BARRETT BlockchAin Regulated REmote aTTestation,” in IEEE/WIC/ACM Int. Conf. on Web Intelligence - Companion Volume, 2019, pp. 256–262. [13] I. R. Jenkins and S. W. Smith, “Distributed IoT Attestation via Blockchain,” in 2020 20th IEEE/ACM Int. Symp. on Cluster, Cloud and Internet Computing (CCGRID), 2020, pp. 798–801. [14] M. Lacoste and V. Lefebvre, “Trusted Execution Environments for Telecoms: Strengths, Weaknesses, Opportunities, and Threats,” IEEE Security & Privacy, vol. 21, no. 3, pp. 37–46, 2023.
13
[15] F. Kohnhäuser, N. Büscher, and S. Katzenbeisser, “A practical attestation protocol for autonomous embedded systems,” in 2019 IEEE European Symp. on Security and Privacy (EuroS&P), 2019, pp. 263–278. [16] T. Abera et al., “DIAT: Data Integrity Attestation for Resilient Collaboration of Autonomous Systems.” in NDSS, 2019. [17] S. F. J. J. Ankergård, E. Dushku, and N. Dragoni, “PERMANENT: Publicly Verifiable Remote Attestation for Internet of Things Through Blockchain,” in Int. Symp. on Foundations and Practice of Security, 2021, pp. 218–234. [18] J. Neureither, A. Dmitrienko, D. Koisser, F. Brasser, and A.-R. Sadeghi, “LegIoT: Ledgered trust management platform for IoT,” in European Symp. on Research in Computer Security, 2020, pp. 377–396. [19] S. Ebrahimi and P. Hassanizadeh, “From interaction to independence: zkSNARKs for transparent and non-interactive remote attestation,” Cryptology ePrint Archive, Paper 2024/1068, 2024. [Online]. Available: https://eprint.iacr.org/2024/1068 [20] L. Petzi, A. E. B. Yahya, A. Dmitrienko, G. Tsudik, T. Prantl, and S. Kounev, “SCRAPS: Scalable collective remote attestation for Pub-Sub IoT networks with untrusted proxy verifier,” in 31st USENIX Security Symp. (USENIX Security 22), 2022, pp. 3485–3501. [21] J. Li et al., “Pontis: A decentralized framework for unifying remote attestation and enabling interoperability between heterogeneous TEEs,” Information Processing & Management, vol. 63, no. 5, p. 104652, 2026. [22] R. Sailer, X. Zhang, T. Jaeger, and L. Van Doorn, “Design and implementation of a TCG-based integrity measurement architecture.” in USENIX Security Symp., vol. 13, no. 2004, 2004, pp. 223–238. [23] S. Zeitouni, G. Dessouky, O. Arias, D. Sullivan, A. Ibrahim, Y. Jin, and A.-R. Sadeghi, “ATRIUM: Runtime attestation resilient under memory attacks,” in 2017 IEEE/ACM Int. Conf. on Computer-Aided Design (ICCAD), 2017, pp. 384–391. [24] W. Xu, X. Zhang, H. Hu, G.-J. Ahn, and J.-P. Seifert, “Remote Attestation with Domain-Based Integrity Model and Policy Analysis,” IEEE Trans. on Dependable and Secure Computing, vol. 9, no. 3, pp. 429–442, 2012. [25] S. Johnson, V. Scarlata, C. Rozas, E. Brickell, F. Mckeen et al., “Intel software guard extensions: EPID provisioning and attestation services,” White Paper, vol. 1, no. 1-10, p. 119, 2016. [26] J. Yiu, “ARMv8-M architecture technical overview,” ARM white paper, 2015. [27] A. Seshadri, M. Luk, E. Shi, A. Perrig, L. van Doorn, and P. Khosla, “Pioneer: verifying code integrity and enforcing untampered code execution on legacy systems,” in Proc. of the 20th ACM Symp. on Operating Systems Principles, 2005, pp. 1–16. [28] A. Seshadri, A. Perrig, L. Van Doorn, and P. Khosla, “SWATT: softWarebased attestation for embedded devices,” in IEEE Symp. on Security and Privacy, 2004. Proc. 2004, 2004, pp. 272–282. [29] I. D. O. Nunes, K. Eldefrawy, N. Rattanavipanon, M. Steiner, and G. Tsudik, “VRASED: A verified Hardware/Software Co-Design for remote attestation,” in 28th USENIX Security Symp. (USENIX Security 19), 2019, pp. 1429–1446. [30] K. Eldefrawy, G. Tsudik, A. Francillon, and D. Perito, “Smart: secure and minimal architecture for (establishing dynamic) root of trust.” in NDSS, vol. 12, 2012, pp. 1–15. [31] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Decentralized Business Review, 2008. [32] M. Schranz, M. Umlauft, M. Sende, and W. Elmenreich, “Swarm Robotic Behaviors and Current Applications,” Frontiers in Robotics and AI, vol. 7, p. 36, 2020. [33] C. Fan, C. Lin, H. Khazaei, and P. Musilek, “Performance Analysis of Hyperledger Besu in Private Blockchain,” in 2022 IEEE Int. Conf. on Decentralized Applications and Infrastructures (DAPPS), 2022, pp. 64–73. [34] E. Palm, O. Schelén, and U. Bodin, “Selective Blockchain Transaction Pruning and State Derivability,” in 2018 Crypto Valley Conf. on Blockchain Technology (CVCBT), 2018, pp. 31–40.
Adam Zahir received his M.Sc. in 2024, and is a Ph.D. student at Universidad Carlos III de Madrid (UC3M). Vincent Lefebvre received his M.Sc. in 1988, and is the CEO of sarl TAGES SOLIDSHIELD. Mark Angoustures received his Ph.D. in 2018, and is the CTO at sarl TAGES SOLIDSHIELD. Milan Groshev received his M.Sc. in 2016 and Ph.D. in 2022, and is a postdoctoral researcher at IE University.
Carlos J. Bernardos received his M.Sc. in 2003 and Ph.D. in 2006, and is a Professor at UC3M.