Blockchain-Assisted Authentication, Authorization, and Audit for MQTT-Based Smart-City IoT

Abstract

Smart-city services increasingly rely on Internet of Things (IoT) deployments using lightweight Message Queuing Telemetry Transport (MQTT), yet weakly protected systems remain exposed to spoofing, unauthorized state changes, and limited accountability. This work evaluates blockchain and smart contracts as a complementary trust layer for MQTT-based smart-city IoT rather than as a replacement for transport-layer security. The proposed architecture provides owner-controlled device registration, per-sensor nonce management, replay-resistant Elliptic Curve Digital Signature Algorithm (ECDSA) authentication, authorization of state-changing operations, and tamper-evident event logging. MQTT confidentiality remains dependent on Transport Layer Security (TLS) or payload encryption. A prototype was implemented using ESP32 microcontrollers, a Raspberry Pi MQTT broker, Node-RED supervision, MongoDB storage, and Ethereum smart contracts deployed on Sepolia. The evaluation combines practical attack scenarios (unauthorized sensor modification, identity spoofing, and data manipulation) with measurements of blockchain latency, throughput, and gas consumption. Results show auditable nonce-bound signed updates, with mean transaction latency close to 12 s. Because the contract updates one sensor per transaction, costs are interpreted per confirmed write operation and scenario size. The findings position blockchain as an audit and policy-enforcement component for MQTT-based IoT.

1. Introduction

Smart cities are transforming urban environments through the combined use of the Internet of Things (IoT), automation, and pervasive connectivity [1]. This transformation also introduces significant cybersecurity challenges. The proliferation of sensors, gateways, and interconnected systems expands the attack surface and exposes urban services to risks that include data loss, unauthorized access, and manipulation of sensitive systems [2].

Among the messaging protocols used in IoT deployments, Message Queuing Telemetry Transport (MQTT) has become a de facto standard because of its low overhead and publish/subscribe efficiency. In its baseline configuration, however, MQTT does not itself provide end-to-end device identity, cryptographic message provenance, immutable auditability, or decentralized policy enforcement. Confidentiality and channel integrity are normally delegated to transport mechanisms such as Transport Layer Security (TLS). Weak credentials, permissive broker policies, or disabled TLS can therefore leave practical deployments exposed to interception, spoofing, unauthorized publication or subscription, and weak accountability. The problem addressed in this paper is not to replace TLS or payload encryption. Instead, the objective is to evaluate whether a blockchain-backed trust layer can complement MQTT by authenticating devices, authorizing security-relevant state changes, and recording accepted operations in a tamper-evident audit trail.

The proposed design introduces a per-sensor nonce at the beginning of the security workflow. Each registered sensor has an independent monotonically increasing nonce stored by the smart contract. Before a state-changing operation, the device obtains its current nonce and includes it in the message that it signs. The contract accepts the operation only if the signature is valid for the registered sensor address and the submitted operation is bound to the current nonce. After acceptance, the nonce is incremented. A previously captured signed operation therefore contains an obsolete nonce and cannot be accepted again. This mechanism gives the nonce a concrete operational role as the replay-control state associated with each sensor.

Blockchain technology and smart contracts provide a complementary trust layer that is aligned with the distributed and multi-stakeholder nature of urban IoT. A distributed ledger provides immutability, traceability, and non-repudiation, while smart contracts allow access-control and validation logic to be expressed in an auditable form [3,4]. Building on this observation, this paper integrates MQTT-based IoT with Ethereum smart contracts. The security workflow uses the Elliptic Curve Digital Signature Algorithm (ECDSA) to bind state-changing operations to registered device identities, while conventional MQTT protections remain responsible for channel confidentiality.

The main contributions of this work are the following:

(i)

A functional smart-city IoT testbed based on MQTT, comprising Espressif 32-bit (ESP32) sensor nodes, a Raspberry Pi running the Mosquitto broker, Node-RED for data-flow orchestration, and MongoDB for document-oriented persistence.

(ii)

An empirical security assessment that demonstrates concrete weaknesses of a weakly protected MQTT-based deployment, covering unauthorized modification of sensor state, device-identity spoofing, and manipulation of recorded data.

(iii)

A blockchain-assisted mitigation using Ethereum smart contracts that supports owner-controlled device registration, ECDSA signature verification, nonce-bound state updates, replay protection, and tamper-evident event logging.

(iv)

A monitoring and audit layer that raises real-time alerts when unexpected on-chain activity is detected, while explicitly leaving MQTT traffic confidentiality to conventional channel or payload protection mechanisms.

This study is guided by the following research questions (RQs):

RQ1

What security failures can an adversary induce in a weakly protected MQTT-based smart-city IoT deployment with respect to device identity, authorization of state changes, and integrity of recorded data?

RQ2

Can Ethereum smart contracts support device authentication and tamper-evident event logging for such deployments?

RQ3

To what extent does the proposed architecture improve authentication, authorization, integrity, and traceability against the evaluated attacks, and which security properties remain outside the blockchain layer?

RQ4

What latency, throughput, and gas-cost implications result from introducing the blockchain layer in the evaluated testbed?

The remainder of this paper is organized as follows. Section 2 reviews related work and compares alternative blockchain approaches. Section 3 presents the system architecture and security design. Section 4 describes the prototype implementation. Section 5 defines the attack scenarios, threat model, evaluation methodology, and countermeasures. Section 6 presents and discusses the results. Section 7 answers the research questions and outlines future work.

2. Related Work

This section reviews the security context of smart-city IoT, blockchain-based identity and access-control mechanisms, and prior work that combines blockchain with MQTT. It then compares public account-based blockchains with permissioned and directed-acyclic-graph alternatives and explains the experimental selection of Ethereum for the proposed prototype.

2.1. Smart-City IoT and MQTT Security

The application of IoT to urban environments has been studied extensively. Zanella et al. [1] describe architectures and services that interconnect heterogeneous urban devices and deliver data-driven services to citizens and operators. As these deployments scale, security and privacy become central concerns. Tawalbeh et al. [2] categorize IoT threats and candidate countermeasures and emphasize the constraints imposed by resource-limited devices. In smart-city environments, device density, heterogeneous technologies, multiple administrative domains, and the safety relevance of some services strengthen the need for lightweight but auditable security controls.

MQTT is attractive in this setting because it decouples publishers and subscribers and imposes limited communication overhead. Broker-side Access Control Lists (ACLs), credentials, and TLS can provide conventional access control and channel protection. These mechanisms are necessary, but they do not by themselves create an externally verifiable record of accepted state transitions. This distinction motivates the use of blockchain as a complementary authorization and audit layer rather than as an alternative to secure MQTT transport.

2.2. Blockchain-Based Identity, Access Control, and Device Management

Christidis and Devetsikiotis [3] describe how blockchains and smart contracts can support device coordination, access control, and auditable IoT interactions without relying on a single central authority. Wood [4] formalizes the Ethereum execution model and the programmable state transitions provided by the Ethereum Virtual Machine (EVM). Reyna et al. [5] survey blockchain and IoT integration and identify scalability, latency, resource constraints, and key management as recurring design challenges. Obaidat et al. [6] likewise emphasize consensus choice and the division between on-chain and off-chain data as important architectural trade-offs.

A substantial body of work applies these ideas to identity and authorization. Novo [7] proposes scalable blockchain-based access management that keeps constrained devices outside the consensus path. Fotiou et al. [8] design token-based access control mediated by Ethereum smart contracts, which is particularly relevant to publish/subscribe systems. Hammi et al. [9] introduce “Bubbles of Trust”, using smart contracts to group devices into trusted virtual zones and verify identity. Huh et al. [10] use Ethereum smart contracts for IoT device configuration and key management. Pal et al. [11] and Khan and Salah [12] review blockchain-based IoT access control and broader blockchain security approaches, respectively. Dorri et al. [13] provide an influential smart-home case study that addresses security and privacy for resource-constrained IoT devices.

Studies in Future Internet broaden this landscape beyond public Ethereum. Bouras et al. [14] propose a lightweight consortium–blockchain architecture for IoT identity registration, verification, and revocation. This permissioned approach gives participating organizations tighter control over membership and governance than a public blockchain, which can be advantageous in municipal deployments with known administrative stakeholders. The trade-off is that operation depends on the consortium’s governance and infrastructure, so the audit model is not independently public in the same way as a public test network. Gangwani et al. [15] use the IOTA Tangle, a directed acyclic graph (DAG) ledger, with Masked Authenticated Messaging for environmental sensor data. DAG-based systems are attractive for high-frequency IoT data because they avoid the conventional linear block structure, but their programming and trust model differ from the Solidity and EVM model used by the present prototype. Khanal et al. [16] combine a modified Elliptic Curve Integrated Encryption Scheme (ECIES) with hashing to protect IoT messages and access-policy privacy. Al Humaimeedy [17] combines Ethereum smart contracts with the InterPlanetary File System (IPFS) for digital-asset registration and auditing. Morsidi et al. [18] review sharding as a scalability mechanism and provide context for the latency and throughput limitations of on-chain IoT workflows.

2.3. MQTT-Specific Blockchain Protection

Blockchain-assisted MQTT security has also been studied directly. Buccafurri and Romolo [19] propose a blockchain-based One-Time Password (OTP) authentication scheme for constrained MQTT devices. Buccafurri et al. [20] extend the approach into an architecture in which Ethereum provides a second-factor, out-of-band authentication channel for local and remote MQTT devices. These studies demonstrate that a public ledger can anchor MQTT authentication while retaining the publish/subscribe communication model. However, their emphasis is on OTP-based authentication rather than on nonce-bound signatures for state-changing operations, and they do not report the same attack-driven physical-testbed evaluation used here.

The present work therefore follows a different integration path. An ECDSA key pair is held by the microcontroller, the Ethereum address derived from the public key is bound to an application-level sensor identifier, and each accepted update must be signed over a domain-bound payload containing the current per-sensor nonce. The evaluation is organized using the Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege (STRIDE) threat categories and concrete attack scenarios on an ESP32 and Raspberry Pi testbed.

2.4. Research Gap, Platform Comparison, and Positioning

The reviewed alternatives expose a practical design choice. Public Ethereum provides open verification, a mature Solidity/EVM development model, and direct support for programmable state transitions, but each state-changing transaction incurs gas and confirmation latency. Permissioned consortium platforms can provide strong organizational membership control and can avoid public-network fees, but they require explicit consortium governance, identity infrastructure, and operated validator or peer nodes. DAG-based platforms such as IOTA provide an alternative data structure that is attractive for IoT-oriented data exchange, but they do not provide the same Solidity/EVM execution environment used by the contract and tooling in this study. Ethereum Sepolia was therefore selected as an experimental platform because it permits public reproducibility without spending production Ether, supports the Solidity/EVM toolchain used by the prototype, and makes confirmed transactions and emitted events independently inspectable. This selection is an engineering choice for the prototype, not a claim that Ethereum is universally superior to permissioned or DAG-based alternatives.

Despite extensive prior work, comparatively few end-to-end prototypes combine a physical MQTT smart-city testbed, device-held signing keys, per-device replay state, on-chain identity binding, and an attack-driven evaluation under an explicit threat model.

Table 1. Representative blockchain-based IoT security approaches.

Work	Focus	BC/SC	IoT Proto.	Attack Eval.	Prototype
Zanella et al. [1]	IoT for smart cities (architecture)	No	—	No	Survey
Tawalbeh et al. [2]	IoT privacy and security (survey)	No	—	No	Survey
Christidis and Devetsikiotis [3]	Blockchain and smart contracts for IoT	Yes	—	No	No
Reyna et al. [5]	Blockchain and IoT integration (survey)	Yes	—	No	Survey
Novo [7]	Scalable access management for IoT	Yes	—	No	Yes
Fotiou et al. [8]	Token-based access control (publish/subscribe)	Yes	Pub/Sub	No	Yes
Hammi et al. [9]	Decentralized IoT authentication	Yes	—	No	Yes
Huh et al. [10]	Ethereum-based IoT device management	Yes	—	No	Yes
Pal et al. [11]	Blockchain for IoT access control (survey)	Yes	—	No	Survey
Khan and Salah [12]	IoT security and blockchain (survey)	Yes	—	No	Survey
Dorri et al. [13]	Blockchain for IoT security (smart home)	Yes	—	No	Yes
Bouras et al. [14]	Consortium–blockchain IoT identity management	Yes	—	No	Yes
Khanal et al. [16]	Blockchain and ECIES for IoT privacy	Yes	—	No	Yes
Gangwani et al. [15]	DAG ledger (IOTA) for IoT data security	Yes	—	No	Yes
Al-Humaimeedy [17]	Smart contracts and IPFS for digital assets	Yes	—	No	Yes
Morsidi et al. [18]	Blockchain sharding (scalability review)	Yes	—	No	Survey
Buccafurri and Romolo [19]	OTP authentication for MQTT	Yes	MQTT	No	Yes
Buccafurri et al. [20]	Ethereum second-factor authentication for MQTT	Yes	MQTT	No	Yes
This work	MQTT authentication and audit in smart cities (Ethereum, ESP32, and Raspberry Pi)	Yes	MQTT	Yes	Yes

positions the present work against representative studies. In the table, BC/SC means blockchain and/or smart contracts, IoT Proto. identifies the targeted IoT messaging protocol or model, and Attack Eval. denotes an empirical attack-based evaluation. The em dash in the IoT Proto. column indicates that the cited work does not target a specific IoT messaging protocol.

Conventional MQTT protections and the proposed ledger layer provide different, partly complementary guarantees.

Table 2. Security properties of the compared mechanisms.

Security Property	MQTT ACL	Mutual TLS	Signed Logs	Blockchain Layer
Device authentication	Yes	Yes	Partial	Yes
Authorization of state changes	Yes	Partial	No	Yes
Replay protection	Partial	Yes	Partial	Yes
Tamper-evident audit trail	No	No	Yes	Yes
Decentralized verification	No	No	No	Yes
On-chain traceability	No	No	No	Yes
MQTT confidentiality	No	Yes	No	No
Protection against compromised device keys	No	No	No	No

summarizes this boundary. An entry marked Partial means that the property can be supported only under additional assumptions or only for a subset of the workflow.

3. System Architecture and Security Design

This section describes the functional layers of the testbed and the security workflow that links a physical sensor identity to an authorized on-chain state change. It first presents the overall architecture, then specifies the MQTT and storage layer, the blockchain layer, the identity model, and the monitoring process.

3.1. Overview

The proposed system couples a conventional MQTT-based IoT deployment with an Ethereum smart-contract layer. The local IoT plane carries sensor and supervision traffic through the Mosquitto broker. Node-RED orchestrates the data flows, while MongoDB stores the off-chain sensor records. The blockchain plane is a distinct external trust layer reached through Hypertext Transfer Protocol Secure (HTTPS) and JavaScript Object Notation Remote Procedure Call (JSON-RPC). It provides owner-controlled registration, per-sensor nonce management, signature-based authentication, replay-resistant authorization of state-changing operations, and tamper-evident logging. It does not reside inside the MQTT broker and does not encrypt MQTT traffic.

Figure 1 makes the separation explicit. MongoDB is shown as the concrete document-oriented Not Only SQL (NoSQL) data store, while the Ethereum smart contract is positioned outside the broker and management plane.

3.2. IoT, MQTT, and Data-Storage Layer

The testbed uses two Espressif 32-bit (ESP32) microcontrollers [21]. One emulates a legitimate sensor, while the second is used to reproduce the evaluated adversarial behavior. A Raspberry Pi runs Mosquitto as the MQTT broker over the local Wi-Fi network. Node-RED [22] orchestrates subscriptions, publishing flows, supervision, and integration with the persistence layer.

The concrete document-oriented NoSQL database used in the testbed is MongoDB [23]. MongoDB was selected because the experimental sensor records are naturally represented as documents, the schema can evolve as additional sensor fields are introduced, and Node-RED can persist and query such records without requiring a fixed relational schema for each experimental variation. The database stores off-chain operational data for management and analysis. It is not treated as the tamper-evident audit source, because mutable database records can be altered by a privileged or compromised host. Accepted security-relevant state changes are therefore also represented by on-chain events.

3.3. Blockchain Layer and Smart Contracts

The security layer is implemented as a smart contract on the Ethereum Sepolia public test network. The contract registers legitimate sensor identities, validates signed state-changing requests, maintains replay-control state, and emits events for accepted operations. The broker host and monitoring components interact with Ethereum through JSON-RPC over HTTPS, while the ESP32 firmware submits signed raw transactions through the same interface.

Signature verification uses ECDSA and the Solidity/EVM primitive ecrecover. In this context, ecrecover is the EVM operation that recovers the Ethereum address associated with the public key that produced a signature over a given message hash from the signature components v, r, and s. The recovered address is compared with the address registered for the target sensor. The contract records events for accepted registrations, authentications, and state changes. Invalid updates revert in the evaluated contract logic, so a failed attempt is observable from the failed transaction receipt but does not leave a persistent event emitted by the reverted call.

3.4. Identity, Nonce Semantics, and Fresh Operations

Three identifiers must be distinguished. The sensor identifier is the application-level index used by the testbed to select one of the registered sensor records. The public key is the secp256k1 elliptic-curve verification key corresponding to the private key stored by the device. The Ethereum address is the 20-byte account identifier derived from that public key. The contract stores the Ethereum address, not the full public key, and binds it to the sensor identifier during owner-controlled enrollment. The device retains the private key and uses it to create ECDSA signatures.

Each sensor also has an independent sensorNonce. A fresh operation is defined here as a signed operation whose nonce exactly equals the current nonce stored by the contract for that sensor and whose signed domain also contains the intended sensor identifier, new value, Sepolia chain identifier, and deployed contract address. These fields prevent a valid signature from being reused for another sensor, another contract instance, or another chain. After an accepted operation, the contract increments the nonce. Consequently, the same signed payload is no longer fresh and a replay is rejected. This definition is used consistently in the evaluation in Section 5.

3.5. Monitoring and Audit

Node-RED and host-side monitoring components inspect transaction receipts and confirmed contract events. An accepted state change produces an event containing the sensor identifier, previous value, new value, nonce, and timestamp. These records provide the tamper-evident audit trail evaluated in this work. MongoDB continues to support flexible operational storage, but blockchain events are used when an independently verifiable history of accepted security-relevant changes is required.

4. Prototype Implementation

This section describes how the architecture was realized in the experimental testbed and replaces low-level source code in the main body with the security workflow that determines when functions are invoked. The complete English-named Solidity listing is provided in Appendix A, and the representative ESP32 firmware excerpt is provided in Appendix B.

The Raspberry Pi runs the Mosquitto MQTT broker and Node-RED management flows, while the two ESP32 devices communicate with the broker over local Wi-Fi. The smart contract was developed in Solidity with the Remix integrated development environment and evaluated on Ethereum Sepolia. Host-side tools use Web3.js and JSON-RPC, while the ESP32 submits signed raw transactions through HTTPS JSON-RPC. The exact deployment identifiers, transaction hashes, verification metadata, and experimental artifacts are intentionally not repeated in the manuscript. They are available through the archive identified in the Data Availability Statement.

For international accessibility, all function names, variables, events, and error messages reproduced in this manuscript use English terminology. Appendix A presents a functionally equivalent English-named representation of the experimental contract logic. The archived experimental artifacts preserve the exact source and deployment metadata used during the measurements.

The enrollment path is owner-controlled. The owner invokes registerSensor (sensorId, signerAddress), which binds the application-level sensor identifier to the Ethereum address derived from the device public key and initializes the corresponding nonce. The operational path begins when the device retrieves getNonce(sensorId). The device then constructs the same domain-bound message represented by buildOperationHash, signs it locally, and invokes updateSensorSigned. That function calls verifySensor, which uses ecrecover to recover the signer address. If the signer and nonce are valid, the contract updates the sensor state, increments the nonce, and emits SensorUpdated. Otherwise, the call reverts with the English error message Invalid signature and the sensor state remains unchanged.

Figure 2 summarizes the dependencies, objectives, and temporal order of these calls. The nonce must be read before signing because it is part of the signed payload, and it is incremented only after an accepted state change.

This implementation deliberately separates the MQTT supervision path from the blockchain state-change path. MQTT carries device and management messages between Node-RED, Mosquitto, and the ESP32 nodes. Security-relevant on-chain changes are submitted as signed Ethereum transactions. The blockchain layer therefore authenticates and records accepted sensor-state changes, but it does not encrypt MQTT payloads or, by itself, harden the Node-RED or Mosquitto management plane.

5. Security Evaluation

The evaluation is organized around three concrete attack scenarios. Defining the attacks first establishes what the adversary attempts to achieve before the STRIDE mapping and evaluation procedure are introduced. The section then maps the scenarios to the threat model, explains the experimental method, and states the security properties that the blockchain layer does and does not provide.

5.1. Attack Scenarios

The following scenarios were executed against the weakly protected baseline and then re-evaluated with the blockchain-assisted controls enabled.

A1: 

Unauthorized modification of sensor state: The adversary attempts to change the value associated with a sensor without being authorized as the registered sensor identity. With the proposed layer enabled, the update is accepted only when the submitted signature resolves to the Ethereum address registered for the target sensorId and the signed nonce equals the current per-sensor nonce. An invalid request reverts with Invalid signature, and the state remains unchanged.

A2: 

Device-identity spoofing: The adversary attempts to act as a legitimate sensor. The mitigation relies on the binding between the sensor identifier and its registered Ethereum address. Without the corresponding private key, the adversary cannot create a valid ECDSA signature for a fresh, domain-bound operation.

A3: 

Data manipulation: The adversary attempts to alter a sensor value or the history of accepted sensor-state changes. Accepted updates are committed to Ethereum and represented by SensorUpdated events containing the sensor identifier, previous value, new value, nonce, and timestamp. Under the ledger assumptions used in this work, confirmed records are tamper evident.

5.2. Threat Model and STRIDE Mapping

The assets to protect are the identity and authenticity of each IoT device, the authorization policy for state-changing operations, the integrity and provenance of accepted changes, the integrity of the audit trail, and the availability of the monitoring service. MQTT payload confidentiality is treated separately because it is a channel-protection property that the blockchain layer does not provide.

The adversary can introduce a rogue node, submit unauthorized transactions, attempt to impersonate a legitimate sensor, modify values before acceptance, and observe MQTT traffic when conventional protections are weak. The adversary seeks to change sensor state without authorization, spoof a device identity, manipulate recorded data, or repudiate an action. Attacks against Ethereum consensus, compromise of the trusted broker host, large-scale denial of service, physical or side-channel extraction of private keys, and cryptographic confidentiality of unprotected MQTT payloads are outside the evaluated scope.

The broker host and ESP32 firmware are trusted to submit the intended payload and signature. The Ethereum ledger is assumed to preserve the integrity of confirmed transactions and events, and each device private key is assumed to remain under control of the corresponding device during the evaluated scenarios. Enrollment is performed in a controlled setting and is restricted by the contract owner. The attack surface therefore includes the MQTT channel, the Node-RED and Mosquitto management plane, device firmware and key material, and the JSON-RPC path to Ethereum.

Table 3. STRIDE threats and associated scenarios.

STRIDE Category	Asset at Risk	Scenario
Spoofing	Device identity and authenticity	A2
Tampering	Sensor state and event-log integrity	A1, A3
Repudiation	Accountability of accepted operations	A1, A2, A3
Information disclosure	Confidentiality of MQTT traffic	Outside scope
Denial of service	Availability of services	Outside scope
Elevation of privilege	Authorization of state-changing operations	A1, A2

and 

Table 4. Mitigations mapped to STRIDE categories.

STRIDE Category	Mitigation or Scope Boundary
Spoofing	ECDSA verification against the registered Ethereum address rejects updates that are not signed by the enrolled device key.
Tampering	Nonce-bound, signature-gated calls protect accepted state changes, and confirmed updates are recorded in tamper-evident events.
Repudiation	Signed transactions and confirmed events provide evidence linking an accepted operation to the registered signer address and consumed nonce.
Information disclosure	Not provided by blockchain. MQTT confidentiality requires TLS, payload encryption, or equivalent channel protection.
Denial of service	Not evaluated as a blockchain-layer guarantee and left for future work.
Elevation of privilege	Owner-controlled enrollment limits identity registration, and only a fresh signature resolving to the registered address can authorize a state update.

split the STRIDE mapping into two views for readability. Table 3 identifies the affected asset and associated attack scenario. Table 4 lists the corresponding treatment or scope boundary.

5.3. Evaluation Methodology

After verifying normal baseline operation, scenarios A1, A2, and A3 were executed against the weakly protected deployment. The same security objectives were then re-evaluated with the blockchain controls enabled. The assessment records whether an unauthorized state update is accepted, whether a spoofed identity can update a registered sensor, whether a previously valid signature can be replayed, and whether accepted state changes remain traceable in the confirmed ledger history. The attack descriptions are intentionally limited to the level required to define and reproduce the assessment without providing unnecessary exploitation detail.

The replay test uses the definition of freshness introduced in Section 3. A captured signature is submitted after the corresponding sensor nonce has already been consumed. Because the contract now stores the next nonce, the old signed payload no longer matches the current replay-control state and cannot authorize a new state change.

5.4. Countermeasures and Residual Gaps

Scenario A1 is mitigated because updateSensorSigned calls verifySensor and accepts a new value only when ecrecover resolves the signature to the Ethereum address registered for the target sensor and the signed operation is fresh. Scenario A2 is mitigated by the same identity-binding and signature check. Replays are rejected by the per-sensor nonce. Scenario A3 is mitigated for accepted records because confirmed events provide a tamper-evident history of state transitions.

These controls do not protect a device whose private key has been compromised, do not provide MQTT payload confidentiality, and do not guarantee availability against network or service flooding.

Table 5. Security evaluation by attack scenario.

Scenario	Baseline Weakness	Property Assessed	Proposed-Layer Effect and Residual Gap
A1: Unauthorized modification	A rogue actor can attempt to change sensor state when accepted updates are not bound to a registered device identity.	Authorization, integrity, and auditability	A state change requires a valid signature for the registered address and current nonce. Private-key compromise and MQTT confidentiality remain external.
A2: Device-identity spoofing	A rogue device can claim a legitimate application-level sensor identity.	Authentication, provenance, and non-repudiation	Accepted updates require the corresponding device private key. Replays are rejected by the nonce. Key rotation and recovery are not implemented in the experimental contract.
A3: Data manipulation	Mutable local records can be altered after the fact and may be difficult to attribute.	Data integrity, traceability, and tamper evidence	Confirmed updates are represented by ledger events containing the sensor identifier, values, nonce, and timestamp. Off-chain data that never reaches the contract remains outside this guarantee.
Confidentiality boundary	Unprotected MQTT traffic can be observed in transit.	Confidentiality	Blockchain does not encrypt MQTT. TLS or payload encryption is required when secrecy is a requirement.

separates the observed baseline weakness from the property supported by the proposed layer and the remaining security boundary.

5.5. Security Properties Supported by the Proposed Layer

The proposed layer provides authentication and authorization for accepted on-chain state changes by requiring a valid ECDSA signature for the Ethereum address bound to the target sensor identifier. The current nonce, chain identifier, contract address, sensor identifier, and proposed value are included in the signed domain. This binding provides operation provenance and prevents a valid signature from being reused as a fresh request after its nonce has been consumed.

For accepted operations, emitted events provide a tamper-evident and independently verifiable audit trail. The guarantee applies to operations that reach and are confirmed by the contract. It does not establish confidentiality for MQTT payloads, prevent wireless jamming or blockchain congestion, or protect against a compromised device private key. A production deployment would also require role-based administration, revocation, key rotation, incident recovery, and hardware-backed key protection.

6. Results and Discussion

This section first reports the qualitative outcome of the attack scenarios and then defines the performance measurement boundary used for the quantitative evaluation. The final subsections interpret latency, throughput, gas expenditure, and the limitations of the experimental scale.

6.1. Qualitative Findings

The attack scenarios confirmed that a weakly protected MQTT-based deployment can be exposed to unauthorized state modification, spoofed device identities, and manipulation or repudiation of mutable local data. With the blockchain layer enabled, sensor-state changes were accepted only when the submitted signature resolved to the Ethereum address registered for the target sensor and the signed operation used the current nonce. Invalid authentication attempts reverted without changing contract state, while accepted changes produced confirmed, tamper-evident ledger events.

These observations answer the qualitative part of RQ1, RQ2, and RQ3. The blockchain layer strengthens authentication, authorization, replay resistance, traceability, and integrity of accepted state changes. It does not provide MQTT payload confidentiality and does not remove the need for TLS, broker ACLs, strong credentials, management-plane hardening, or secure device-key storage.

6.2. Performance Evaluation Methodology

The performance evaluation was carried out on the Ethereum Sepolia public test network. Each experimental configuration was executed ten independent times, and the values in

Table 6. Measured blockchain performance and gas expenditure.

Distinct Sensors	MQTT Nodes	Mean Latency (s)	Throughput (tx/min)	Gas Expenditure (Gwei)	Remarks
1	1	11.8	5.1	2577	Single-node baseline
5	1	12.1	4.9	2767	Stable per-transaction latency
10	1	12.4	4.8	2877	Scenario-level gas variation
1	5	11.9	5.1	12,875	Aggregate multi-node cost
5	5	12.2	4.9	13,845	Stable per-transaction latency
10	5	12.5	4.8	14,382	Confirmation-bound latency

are arithmetic means. The measured blockchain latency is the elapsed time from submission of a signed sensor-state transaction through HTTPS JSON-RPC until receipt of confirmation that the transaction has been included in the blockchain. It includes transaction submission and propagation, EVM contract execution, network validation, block inclusion, and receipt handling. It does not include the Node-RED to ESP32 MQTT supervision path, because that local exchange does not generate the measured blockchain transaction. Under the tested local-network conditions, its delay was on the order of milliseconds and was negligible relative to Sepolia confirmation time.

This consolidated measurement boundary avoids double-counting the same communication paths. The observed mean latency, from 11.8 to 12.5 s, should therefore be interpreted primarily as confirmation overhead of the evaluated blockchain-assisted implementation, not as an inherent MQTT delay. The approach is consequently suitable for authentication, authorization, audit, and accountability operations that can tolerate several seconds of confirmation latency, but not for sub-second closed-loop control. Exact public deployment identifiers and transaction hashes used to verify the measurements are provided through the archive identified in the Data Availability Statement rather than repeated in the main text.

The system throughput is computed as

$$\mathrm{Throughput}={\displaystyle \frac{N_{\mathrm{tx}}}{T_{\mathrm{total}}}},$$

(1)

where $N_{\mathrm{tx}}$ is the number of confirmed transactions and $T_{\mathrm{total}}$ is the total elapsed time. The result is expressed in transactions per minute (tx/min). Gas expenditure is computed as

$$C_{\mathrm{gas}}=G_{\mathrm{used}}\times p_{\mathrm{gas}},$$

(2)

where $G_{\mathrm{used}}$ is the gas consumed by contract execution and $p_{\mathrm{gas}}$ is the gas price reported by Sepolia at transaction submission time, expressed in Gwei per gas unit.

6.3. Quantitative Evaluation

The scenarios exercise 1, 5, and 10 distinct sensors with either 1 or 5 MQTT broker nodes. The contract in Appendix A updates one sensor per transaction. Reported latency is therefore the mean latency per confirmed write transaction, not the latency of a batched multi-sensor transaction. In the multi-node configuration, each node operates its own smart-contract instance. Because Sepolia follows the EVM gas-accounting model used by Ethereum, the gas measurements are useful for relative comparison within the evaluated design. Absolute production latency and fees can differ with network conditions and the chosen deployment layer. Table 6 reports the measured results.

Figure 3 plots mean latency and gas expenditure against the number of distinct sensors exercised in the scenario. Mean latency remains close to 12 s for both node configurations, which indicates that Sepolia confirmation time dominates the measured path. Throughput remains approximately five transactions per minute for the same reason. Because the contract updates only one sensor per call, the modest gas differences among the 1-, 5-, and 10-sensor scenarios are scenario-level and gas-price variations rather than evidence of a single transaction writing multiple sensors. The five-node configuration shows the expected aggregate cost increase because each node operates its own contract instance. These measurements provide the quantitative basis for RQ4.

6.4. Discussion and Limitations

The results support the feasibility of blockchain-assisted authorization and audit for small-scale smart-city IoT prototypes, but they should not be generalized to city-scale deployment without further evaluation. The Sepolia public test network provides reproducibility and EVM compatibility, but production networks can have different congestion, fee, and finality characteristics. A mean latency near 12 s is acceptable for asynchronous audit and authorization workflows but is too high for latency-sensitive control loops. Layer-2 execution, aggregation, or batching could reduce this limitation in future designs.

The experiments exercised at most ten sensors and five MQTT nodes on a low-latency local network. Wider-area and higher-density deployments remain to be evaluated. The experimental contract also uses basic owner-controlled enrollment and does not implement role-based administration, revocation, key rotation, or incident recovery. A production implementation should harden ECDSA validation, reject invalid enrollment addresses, and protect device private keys using a secure element or equivalent hardware-backed store. Finally, MQTT confidentiality and management-interface protection remain external requirements. The blockchain layer complements TLS, payload encryption, broker ACLs, strong credentials, rate limiting, and host-level security controls rather than replacing them.

7. Conclusions and Future Work

This work evaluated an Ethereum-based trust layer for authentication, authorization, replay control, and audit around MQTT-based smart-city IoT. The conclusions can be stated directly against the four research questions.

RQ1: 

In the evaluated weakly protected MQTT deployment, the adversarial scenarios demonstrated unauthorized attempts to modify sensor state, device-identity spoofing, and manipulation or repudiation risks for mutable records. The experiments therefore identify concrete failures in identity binding, authorization of state changes, and integrity or accountability of recorded data when complementary controls are absent.

RQ2: 

The prototype demonstrates that Ethereum smart contracts can support device authentication and tamper-evident event logging for the evaluated workflow. Owner-controlled registration binds a sensor identifier to an Ethereum address, ECDSA verification authenticates signed operations, and confirmed events provide an auditable record of accepted state changes.

RQ3: 

The proposed layer rejected state changes that lacked a valid signature for the registered device and prevented reuse of previously accepted signed operations through the per-sensor nonce. It also provided traceability for confirmed updates. These results support improved authentication, authorization, replay resistance, integrity, and auditability for accepted on-chain operations. They do not establish MQTT payload confidentiality, availability under denial-of-service conditions, protection after device-key compromise, or complete key-lifecycle governance.

RQ4: 

Mean confirmed transaction latency ranged from 11.8 to 12.5 s and measured throughput ranged from 4.8 to 5.1 transactions per minute. Gas expenditure ranged from 2577 to 2877 Gwei in the single-node configurations and from 12,875 to 14,382 Gwei in the five-node aggregate configurations. The dominant performance limitation was blockchain confirmation time, so the evaluated design is better suited to audit and authorization workflows than to real-time control loops.

The contribution is architectural and experimental rather than a new cryptographic primitive or blockchain protocol. It combines device-to-blockchain identity binding, ECDSA-based authorization, per-sensor nonce enforcement, and tamper-evident recording while retaining TLS and payload encryption as complementary mechanisms. Future work should evaluate larger deployments, role-based governance, revocation and key rotation, secure elements, Layer-2 or batched execution, richer device identities, and explicit TLS-enabled end-to-end experiments. These extensions are required before extrapolating the prototype to production-scale urban infrastructure.