A Lightweight, End-to-End Encrypted Data Pipeline for IIoT: An AES-GCM Implementation for ESP32, MQTT, and Raspberry Pi

Abstract

Industrial Internet of Things (IIoT) deployments increasingly rely on low-cost microcontrollers and single-board computers to stream operational telemetry for monitoring, control, and predictive maintenance, yet the canonical “TLS-to-broker” model does not protect message content from a compromised or curious MQTT broker. This study therefore designs and implements a practical, application-layer end-to-end (E2E) encryption pipeline spanning an ESP32 data client (C++/mbedTLS), an untrusted MQTT broker, and a Raspberry Pi gateway (Python/PyCryptodome) using AES-256-GCM with Additional Authenticated Data (AAD). Sensor measurements are serialized as compact JSON, encrypted and authenticated on the ESP32, framed into a binary record, Base64-encoded for MQTT payload carriage, and verified/decrypted only at the gateway. Experiments on ESP32-WROOM-32 and Raspberry Pi 4 show an average ESP32 packet-preparation latency of 41.754 ms (JSON 1.0 ms; AES-GCM 29.5 ms; Base64 11.2 ms), robust rejection of ciphertext tampering and unauthorized devices via MAC verification and whitelist checks, and 99.72% decrypt-and-store success over a one-hour run (718/720 messages). These results indicate that commodity IIoT hardware can support practical and replicable E2E confidentiality and integrity without sacrificing operational throughput, while eliminating the MQTT broker as a de facto man-in-the-middle.

1. Introduction

Industry 4.0 has accelerated the deployment of connected sensors and actuators across energy communities, buildings, transportation, and manufacturing sites, where publish/subscribe messaging and edge processing enable responsive, data-driven operations and cyber-physical control loops [1,2,3,4,5,6,7]. Representative implementations include demand-response testbeds for smart communities [1], low-cost embedded smart-city platforms [2], privacy-oriented open IoT infrastructures for research and industry [3], Raspberry Pi gateways bridging legacy equipment to dashboards [4], residential HVAC retrofits relying on Wi-Fi and MQTT [5], MQTT-based interaction frameworks in robotics [6], and smart-home monitoring stacks that adopt transport-layer security [7]. Across such deployments, operational measurements may reveal equipment states, occupancy patterns, energy usage, safety-critical alarms, or protected industrial processes, making confidentiality and integrity essential rather than optional.

1.1. MQTT in IIoT: Operational Constraints and Security Limitations

MQTT is attractive for IIoT because it is lightweight, decouples publishers and subscribers, and supports QoS policies that can trade bandwidth for delivery guarantees. However, the broker is structurally central: it terminates sessions, enforces topic routing, can persist retained messages, and often hosts plugins, monitoring, and logging. This centrality is also the primary security challenge in practice. Empirical studies show that broker performance and resilience degrade under malformed traffic and SYN-flooding, and that higher QoS levels can amplify processing and transmission overheads on constrained broker hardware such as Raspberry Pi [8,9,10]. Even in benign conditions, transport-layer configuration matters: cipher negotiation, TLS versions, and handshake behavior measurably affect bandwidth and latency for constrained clients and brokers [11]. In recent V2X-oriented experiments, TLS-enhanced MQTT on IoT devices exhibited non-trivial CPU and energy costs during handshake, with performance varying by cipher suite (e.g., ChaCha20-Poly1305 sometimes outperforming AES-GCM in wireless scenarios) [12]. These findings motivate a distinction that is often blurred in deployments: while TLS protects the channel between client and broker, it does not prevent the broker itself from seeing or modifying plaintext because the broker is the endpoint of the TLS session.

This “TLS-to-broker” model is frequently acceptable when the broker operator is fully trusted, but it is misaligned with common Industry 4.0 realities in which brokers run in shared infrastructure, are managed by third parties, or are exposed to insider threats. Multiple application domains demonstrate valuable defense-in-depth with TLS and authenticated telemetry flows [13,14,15,16,17,18], yet those architectures continue to rely on the broker as a trusted intermediary for message content. In such settings, the broker becomes a “man-in-the-middle by design”: it is positioned to inspect, log, or tamper with measurements even if the network transport is encrypted. Consequently, practical E2E protection must be enforced at the application layer so that only endpoints can interpret and authenticate telemetry.

1.2. Related Work: Lightweight Cryptography and Application-Layer Protection

A substantial literature evaluates cryptographic choices and their resource impact on embedded devices. Comparative analyses show that algorithm selection affects latency, payload expansion, and power consumption across ESP-class microcontrollers and Raspberry Pi-class gateways [19]. Lightweight authenticated encryption approaches, including ASCON, can outperform AES-GCM on certain embedded platforms or workloads [20,21], whereas AES variants tailored for constrained devices may improve execution time or implementation characteristics on microcontrollers [22]. In IoMT/IoT authentication frameworks, symmetric primitives are often favored because of their lower compute and energy cost compared with public-key alternatives [23]. Domain-specific studies also report that lightweight ciphers (e.g., SPECK) may reduce execution time relative to AES in constrained GSM/MQTT environments, although algorithm choice must also consider standardization, interoperability, and threat models [24].

Beyond classical symmetric cryptography, post-quantum cryptographic mechanisms have been explored for future resilience. Measurements show that lattice-based KEMs can be expensive for low-end MCUs, particularly due to memory and vector arithmetic demands [25], while Raspberry Pi-class devices can host several PQC primitives within sub-100 ms operations in some implementations [26]. Hybrid IoMT designs combining TinyML with post-quantum cryptography demonstrate feasibility primarily at gateway or network levels rather than on the smallest sensor nodes [27]. Hybrid and composite cryptosystems have also been proposed for strengthening IoT and 5G/B5G security at higher performance tiers [28]. In parallel, chaos-augmented designs have been studied in robotic and vehicular contexts, including ASCON-based constructions [29,30]. Numerous application-layer or on-device encryption approaches exist for specific domains, such as chaos-based image encryption on Raspberry Pi [15], LoRa image security schemes [31], DNA-computing stream ciphers over MQTT [32], and on-sensor stream-cipher encryption to protect smart-city measurements directly on constrained sensors [33]. These works reinforce a key design principle: protecting the payload object can be more robust than protecting only the transport channel, particularly under broker compromise.

Practical security building blocks on commodity hardware are similarly well documented. Educational security laboratories pair ESP32 platforms with cryptographic stacks such as mbedTLS and hardware add-ons [34]; device managers implement symmetric encryption and integrity checks for payloads and updates on ESP32 [35]; and ECC-backed authentication devices for multiprotocol environments report sub-second signing and verification on embedded platforms [36]. Commercial development boards also integrate secure elements to protect credentials and assist with secure onboarding [37]. Across predictive maintenance, agriculture, safety, and healthcare telemetry, MQTT remains a common spine for transporting time-series data to gateways and analytics platforms [38,39,40,41,42,43,44,45], including ESP32-CAM security alarms [46], public-safety and emergency response systems [17], fleet telemetry and control [18], secure vehicle voice chat using MQTT/CoAP [47], and HL7/MQTT medical image monitoring [48]. Edge gateways consolidate protocol mediation, storage, and local control [49], while device identity and provenance mechanisms can incorporate PUFs and blockchain [50]. Lightweight encryption and authentication continue to evolve via block-cipher designs [51], SRAM-PUF mutual authentication [52], cloud registration approaches [53], sensing pipelines with AI [54], and PUF-tied keyed hashing [55], highlighting a diverse design space for secure IIoT architectures.

1.3. Research Gap and Contributions

Within this landscape, a practical gap remains. Many systems secure transport links or propose novel ciphers, yet relatively few deliver a complete, reproducible, and benchmarked application-layer E2E pipeline that explicitly treats the MQTT broker as untrusted, particularly on a heterogeneous implementation stack where encryption is exec uted on an ESP32 (C++/mbedTLS) and decryption/authorization on a Raspberry Pi gateway (Python/PyCryptodome). Prior work provides important measurements of broker resilience, TLS overhead, or algorithm performance [8,9,10,11,12,19,20,21,22,23,24], but it less often combines (i) a concrete E2E framing protocol; (ii) explicit endpoint authorization bound to authenticated metadata; and (iii) microcontroller-side latency measurements together with adversarial validation (tamper rejection) and operational reliability in an integrated pipeline.

This paper addresses that gap by specifying, implementing, and experimentally evaluating a practical E2E encrypted IIoT data path using AES-256-GCM with associated data to provide confidentiality and integrity end-to-end while treating the broker purely as a relay. The core contributions are as follows. First, we define a compact AES-GCM framing format and reference implementation that is interoperable across a constrained ESP32 publisher and a Python gateway, enabling broker-agnostic E2E protection on commodity hardware. Second, we introduce device-level authorization bound to AAD and validate integrity under ciphertext tampering, demonstrating that modifications by a broker or network adversary are detected and rejected. Third, we provide reproducible microcontroller-side timing measurements for serialization, encryption, and encoding, and we evaluate end-to-end reliability under sustained encrypted acquisition. Finally, we explicitly document a threat model, nonce/key management considerations, and limitations to clarify which attacks are mitigated and which require complementary controls.

Encryption is not a substitute for monitoring and intrusion detection; rather, it should be layered with anomaly detection and IDS mechanisms that can operate at gateways or network boundaries. Recent work on adversarially robust IoT intrusion detection highlights this complementary role, especially against evasion attacks that target ML-based IDS deployments [56].

2. Materials and Methods

2.1. System Architecture

The pipeline comprised three roles. The Data Client (ESP32-WROOM-32) sampled local sensor values, serialized them as compact JSON, performed AES-GCM encryption at the application layer, and published a Base64-encoded frame to an MQTT topic over Wi-Fi. The Message Broker handled publish/subscribe delivery but was explicitly considered untrusted with respect to plaintext; transport-layer protections (e.g., TLS) were treated as optional defense-in-depth rather than a trust anchor. The Gateway Server (Raspberry Pi 4) subscribed to the topic, verified device authorization via a whitelist bound to the Additional Authenticated Data (AAD), authenticated and decrypted packets, and stored accepted measurements (e.g., in InfluxDB) for downstream analytics [4,24].

Figure 1 illustrates the proposed architecture and data flow, emphasizing that encryption and authentication occur only at the endpoints.

Because the broker is assumed untrusted, the system is designed so that compromise of the broker yields only ciphertext and authenticated metadata, not plaintext measurements. The gateway serves as the first trusted termination point for measurement content and is the appropriate location for storage, access control, and optional anomaly detection modules [49].

2.2. Hardware and Software Stack

We implemented the client on an ESP32-WROOM-32 development board, which provides sufficient compute for authenticated encryption under typical IIoT rates while maintaining a small energy and memory footprint [23,36]. A DHT22/AM2302-class sensor served as a representative low-rate telemetry source [57]. The gateway ran on a Raspberry Pi 4, representative of low-cost edge servers used in IIoT deployments [1,4,12]. MQTT connectivity used Eclipse Paho clients; the broker was Eclipse Mosquitto. The client used mbedTLS (C/C++) for AES-GCM and Base64; the gateway used PyCryptodome (Python) for AES-GCM and paho-mqtt for messaging. An optional time-series backend (InfluxDB) and visualization stack may be used for persistence and dashboarding, consistent with open IIoT platform patterns [3,24,38].

2.3. Secure Data Protocol Design

2.3.1. Plaintext Payload and AAD

The plaintext payload was serialized as compact JSON with fields such as device_id, ts (timestamp), and a measurement bundle (e.g., voltage, current, temperature, humidity). The device_id string and a fixed protocol version were used as Additional Authenticated Data (AAD) so that critical metadata remains visible for routing and authorization but is cryptographically bound to the ciphertext. This prevents an adversary from selectively altering device identifiers or protocol markers without triggering authentication failure.

2.3.2. Cryptographic Parameters and Design Rationale

Keys were 256-bit pre-shared keys (PSKs) provisioned out-of-band for prototype simplicity; symmetric keys are computationally efficient on constrained nodes relative to more complex asymmetric mechanisms [23]. We selected a 12-byte nonce and 16-byte tag consistent with standard AES-GCM practice, balancing performance and integrity strength. The 12-byte nonce enables efficient GCM processing, while a 16-byte tag provides strong message authenticity against forgery under standard threat assumptions. AAD is used to bind metadata to ciphertext without expanding the encrypted payload, and it enables explicit device authorization at the gateway.

A compact binary frame was Base64-encoded for MQTT transport to improve interoperability with common broker tooling and message inspection utilities; Base64 incurs overhead but provides reliable ASCII carriage and simplifies debugging. In bandwidth-critical deployments, the binary frame can be transmitted directly as a binary MQTT payload, avoiding Base64 overhead at the cost of reduced human readability.

2.3.3. Encryption Frame on ESP32 (C++/mbedTLS)

On the ESP32, the client generated a fresh nonce per message and executed mbedtls_gcm_crypt_and_tag to encrypt the plaintext and generate the tag in one pass. The client then constructed a compact frame:

[Version|Nonce (12 B)|Tag (16 B)|Ciphertext (N B)]

The frame was Base64-encoded and published as the MQTT payload. The design is endpoint-only: the broker sees only Base64 ciphertext and cannot reconstruct plaintext or modify the encrypted content without detection.

2.3.4. Decryption Frame on Raspberry Pi (Python/PyCryptodome)

On the Raspberry Pi gateway, the subscriber decoded Base64, parsed the fixed-width header to recover version, nonce, and tag, and then initialized AES.new(key, AES.MODE_GCM, nonce = nonce) in PyCryptodome. The gateway provided the same AAD and executed cipher.decrypt_and_verify(ciphertext, tag). Successful verification yielded authenticated plaintext JSON, which was parsed, authorized against a device_id whitelist, and written to storage. Failures at MAC verification or authorization produced structured logs and dropped the packet without side effects.

2.3.5. Nonce Management, Reboot Behavior, and Replay Considerations

The security of AES-GCM depends critically on nonce uniqueness per key. In our prototype, a new nonce is generated per message using the device’s cryptographic randomness at runtime, and the gateway rejects messages failing authentication. For long-lived deployments, additional engineering controls are recommended to further reduce the risk of nonce reuse after reboot, counter wrap-around, or firmware update events. A robust approach is to generate a boot-unique prefix at startup and concatenate it with a monotonic counter, persisting the counter in non-volatile storage; this provides deterministic uniqueness across resets. Replay defenses can additionally be implemented by incorporating a sequence number or timestamp into the authenticated plaintext and maintaining a per-device acceptance window at the gateway. These considerations are discussed further in Section 4 to clarify operational assumptions and limitations.

2.4. Experimental Design

We assume an adversary who can observe network traffic, compromise or operate the MQTT broker, and attempt message injection, tampering, or replay. Under this model, the broker may log or modify payloads, and a network attacker may perform man-in-the-middle manipulation of MQTT traffic. We also consider denial-of-service conditions such as broker flooding and malformed MQTT traffic, which are observed to degrade MQTT infrastructure in practice [8,9,10]. The primary security goals are: confidentiality of measurements against broker/network observers; integrity and authenticity of measurements so that tampering is detected; and device authorization so that only registered devices may write to storage.

The threat model necessarily includes assumptions. In particular, endpoint compromise is difficult to prevent by cryptography alone. This work does not claim to “prove” the ESP32 is trusted; rather, it treats the endpoint firmware and secret key material as part of the trusted computing base. Physical compromise, key extraction, and side-channel attacks (timing, power, EM) are acknowledged as important risks but are outside the scope of the presented evaluation. Practical mitigations include secure boot and flash encryption on ESP-class devices, disabling debug interfaces, using secure elements for credential protection [37], and hardware-bound identity mechanisms such as PUF-based designs [50,52,55]. These mitigations complement—but do not replace—E2E cryptography.

2.5. Experimental Design and Benchmark Scenarios

Four evaluations were conducted to validate feasibility and operational impact. First, computational overhead on the ESP32 was quantified by timing JSON serialization, AES-GCM encryption + tagging, and Base64 encoding across 1000 iterations using microsecond-resolution timers, reporting average, minimum, and maximum latencies and the mean packet-preparation cost. Second, security and integrity were validated by inducing ciphertext tampering (single-byte flips) and device authorization violations (non-whitelisted device_id), confirming that the gateway rejected such packets with explicit MAC-failure and authorization-failure logs. Third, end-to-end throughput and reliability were assessed by running a one-hour test at one message every five seconds (720 total), recording the number of successfully decrypted and stored messages to compute packet success rate. Fourth, the system behavior was qualitatively assessed under typical broker conditions to ensure that encryption did not destabilize the MQTT publish/subscribe pipeline.

Figure 2 summarizes the overall implementation workflow of the proposed end-to-end encrypted IIoT pipeline, from system scoping and firmware development to broker deployment, gateway processing, and end-to-end validation.

The benchmark scope is intentionally focused: a single ESP32 board, a single gateway, a low-rate sensor payload, and a single message rate in the long-run test. These constraints are made explicit to avoid overgeneralization, and Section 4 discusses expected scaling behavior and additional experiments needed to quantify performance across higher message rates, varying payload sizes, and multiple concurrent publishers.

3. Results

3.1. ESP32 Packet-Preparation Latency

Packet-preparation latency on the ESP32 was characterized by instrumenting three code regions—JSON serialization, AES-GCM encryption and tag generation, and Base64 encoding—over 1000 consecutive messages. The measured overall mean latency was 41.754 ms per packet.

Table 1. ESP32 packet-preparation latency (1000-packet run).

Component	Avg Latency (ms)	Min (ms)	Max (ms)
JSON serialization	1.0	0.8	1.2
AES-GCM encrypt + tag	29.5	27.0	32.0
Base64 encoding	11.2	10.0	13.0
Total (measured)	41.754

summarizes the component costs: JSON serialization contributed 1.0 ms on average (0.8–1.2 ms), AES-GCM encryption and authentication dominated at 29.5 ms on average (27.0–32.0 ms), and Base64 encoding added 11.2 ms on average (10.0–13.0 ms). The sum of component means (41.7 ms) closely matches the measured end-to-end mean, with the small residual attributable to measurement overhead and timing granularity.

At the operating regime used in the one-hour reliability test—one message every five seconds—the preparation latency consumes approximately 0.84% of the duty cycle (41.754 ms of 5000 ms), leaving substantial headroom for sensing, networking, and application logic. Because the encryption/encoding operations are per-message and do not depend on the number of prior packets, increasing the loop length from 1000 to 5000 iterations is not expected to increase per-packet mean latency; rather, it primarily improves the stability of the estimated mean and variability. These findings align with broader evidence that symmetric authenticated encryption remains practical on ESP-class devices relative to more complex asymmetric or post-quantum alternatives at the sensor tier [19,23,25,26,27].

3.2. Security and Integrity Validation

The correctness of AES-GCM confidentiality and integrity protection, together with device-whitelisting, was validated by exercising three scenarios against the Raspberry Pi gateway while capturing representative log output (

Table 2. Representative gateway logs under valid, tampered, and unauthorized cases (with English gloss).

Scenario	Example Log Line
Valid message	2025-11-14 14:22:11,184—INFO—[ESP32_Dala_Meter_001989] зaпиcь в InfluxDB—OK (write to InfluxDB—OK)
Tampered frame	2025-11-14 14:22:16,321—ERROR—Oшибкa pacшиφpoвки/вaлидaции кaдpa: AES-GCM decrypt/verify failed: MAC check failed (decrypt/verify failed: MAC check failed)
Unauthorized device	2025-11-14 14:22:21,907—WARNING—Device ‘ESP32_Test_9999’ нe в devices.txt—cooбщeниe пpoигнopиpoвaнo. (device not in whitelist—message ignored)

). For a valid message from a whitelisted device, the gateway decoded Base64, verified the AES-GCM tag with the configured AAD, parsed authenticated plaintext JSON, and wrote measurements to InfluxDB. For the ciphertext-tampering scenario, an intercepted payload was decoded, a single byte was altered in the ciphertext segment, and the modified frame was republished. The gateway rejected the tampered message, reporting a MAC verification failure. This demonstrates that the broker (or any network attacker) cannot modify payload bytes without detection, directly addressing the broker-tampering concern.

In the unauthorized-device scenario, a syntactically valid AES-GCM frame was generated with a device_id absent from the local whitelist. Even if cryptographic verification succeeds, the gateway enforces authorization policy by rejecting unregistered devices, thereby preventing silent data injection into storage without administrative enrollment.

3.3. End-to-End Throughput and Reliability

End-to-end reliability was assessed by sending one encrypted message every five seconds for one hour, yielding an expected total of 720 messages. Gateway logs and InfluxDB records showed that 718 messages were successfully decrypted and stored, corresponding to a packet success rate of 99.72% (

Table 3. End-to-end reliability during a 1 h encrypted acquisition test.

Metric	Value
Total messages sent	720
Successfully stored	718
Packet success rate (%)	99.72

). Two messages were not committed to storage over the one-hour window. Because no cryptographic verification failures were observed during the soak test, these losses are consistent with transient network or broker/gateway processing conditions rather than integrity failures; nonetheless, the experiment did not instrument root-cause telemetry such as broker queue depth or Wi-Fi RSSI at the moment of loss.

From an operational perspective, loss of 2 packets in 720 at this sampling rate is unlikely to affect typical monitoring workloads, particularly for slowly varying process variables. For applications requiring stronger delivery guarantees, reliability can be further improved through MQTT QoS policies, persistent sessions, and application-level acknowledgements or retransmission strategies, as discussed in Section 4.

4. Discussion

4.1. Practical Contribution Beyond TLS-Only MQTT

The results substantiate that application-layer E2E encryption based on AES-GCM is compatible with real-time telemetry on commodity IIoT hardware. The ESP32 packet-preparation latency of 41.754 ms is modest relative to the 5 s sampling interval used in the long-run test, and it is comparable to or smaller than the overheads already tolerated in TLS-secured MQTT deployments, where handshake, cipher-suite selection, and wireless conditions can introduce tens to hundreds of milliseconds of latency and non-trivial CPU/energy costs [11,12]. The key difference is architectural: TLS protects the client-to-broker channel, whereas the proposed approach protects message content end-to-end and remains secure even if the broker is compromised or operated by an untrusted party. This distinction is particularly important when broker resilience and security are known to be stress points in practice, including under malformed traffic or denial-of-service conditions [8,9,10].

4.2. Comparison with Lightweight AEAD and Object-Security Approaches

The literature highlights multiple candidate strategies for protecting IoT payloads. Some approaches rely on transport security and broker hardening, while others adopt application-layer encryption tailored to domain constraints [13,14,15,16,31,32,33]. Our design falls into the latter category, using a widely supported AEAD primitive (AES-GCM) to maximize interoperability across embedded C/C++ stacks and Python gateway environments.

To clarify how AES-GCM relates to other lightweight approaches,

Table 4. Qualitative comparison of candidate payload-protection approaches for constrained IIoT.

Approach	Typical Strengths	Typical Constraints	Example Works
AES-GCM (application-layer AEAD)	Mature standard; strong integrity; broad library support across C/C++ and Python; interoperable framing	Requires strict nonce uniqueness; performance may be heavier than some lightweight AEADs	This work; algorithm evaluations in [19,22]
ASCON/lightweight AEAD	Designed for lightweight profiles; can outperform AES-GCM on some embedded targets	Not always available in standard embedded stacks; interoperability/tooling less uniform	[20,21,29,30]
TLS-secured MQTT (channel security)	Strong channel protection; operationally familiar	Broker still sees plaintext; handshake/CPU/energy overhead can be significant; broker compromise remains critical	[11,12,13,14,15,16,17,18]
Domain-specific stream ciphers/specialized payload encryption	Can be lightweight and on-sensor; payload protected independent of channel	Often domain-specific; may reduce interoperability; still needs key/nonce discipline	[32,33]

provides a focused qualitative comparison grounded in the cited literature. ASCON-based solutions, including chaos-augmented variants, can offer attractive performance profiles on some constrained platforms [20,21,29,30]. TLS evaluations also underscore that cipher-suite choice (e.g., ChaCha20-Poly1305 vs. AES-GCM) can matter in wireless settings [12]. Stream-cipher approaches implemented directly on sensors can reduce overhead in some traffic patterns and simplify on-device integration [33]. In the present work, AES-GCM was selected because it provides standardized AEAD security, has mature implementations, and can be deployed consistently across ESP32 and Raspberry Pi using widely adopted libraries.

This comparison motivates an interpretation of the present results as a practical baseline. Rather than claiming AES-GCM is always optimal, the contribution is to demonstrate that a standardized AEAD can be implemented end-to-end on commodity hardware with explicit measurements and adversarial validation, and that the pipeline can serve as a reference for future evaluations of ASCON or other AEAD candidates in the same architecture.

4.3. Security Beyond Broker Compromise: Replay, DoS, and Side Channels

While the primary motivation is broker compromise, IIoT deployments face broader threats. Message replay and injection are natural concerns in publish/subscribe systems. AES-GCM integrity ensures that payload modifications are detected, as validated by the MAC failure behavior in Table 2; however, replay protection requires an additional policy layer, typically via sequence numbers or timestamps authenticated in the payload. Because the plaintext JSON includes a timestamp ts, gateway-side replay defenses can be implemented as a per-device acceptance window without exposing plaintext to the broker. Denial-of-service threats remain relevant even with E2E encryption because availability is not guaranteed by cryptography. Broker-level stress under malformed traffic and flooding has been observed experimentally [8,9,10], reinforcing the need for operational controls such as rate limiting, topic ACLs, and monitoring.

Timing, power, or EM leakage can threaten key material on constrained endpoints. This work does not attempt side-channel resistance validation, and it assumes the endpoint key is not extracted. Mitigations in realistic deployments include secure boot and flash encryption, disabling debug interfaces, using secure elements for key storage [37], and adopting hardware-bound identity and authentication approaches (e.g., PUF-based schemes) [50,52,55]. These measures help address the risk that a compromised device could leak keys and thereby undermine E2E encryption.

4.4. Key Management, Provisioning, Rotation, and Revocation at Scale

The prototype uses pre-shared 256-bit keys provisioned out-of-band to emphasize a simple and replicable baseline. This approach is common in small deployments, but it becomes limiting for large fleets because it complicates secure onboarding, key rotation, and revocation. Multiple directions are suggested by the literature: ECC-based authentication devices demonstrate practical signing and verification on embedded targets [36]; secure elements provide protected key storage and facilitate secure cloud onboarding workflows [37]; and PUF-based approaches can bind device identity to hardware characteristics and reduce exposure of long-term secrets [50,52,55]. Cloud registration workflows for IoT boards have also been explored [53]. In a production IIoT fleet, these mechanisms can be combined with gateway-enforced policies (whitelists, device revocation lists, per-device keys) to ensure that compromise of one endpoint does not imply compromise of all devices.

4.5. Complementary Defenses: IDS and Anomaly Detection

E2E encryption protects confidentiality and integrity of measurements in transit and through untrusted brokers, but it does not detect malicious behavior from already-authorized devices or adversaries who exploit vulnerabilities in endpoints. Therefore, encryption should be treated as one layer in a broader architecture that can include gateway-level anomaly detection and IDS. TinyML-based approaches on edge devices demonstrate the feasibility of local inference for authentication or anomaly detection under constrained resources [58]. Such edge deployments commonly rely on Wi-Fi-based embedded hardware platforms in practical smart-home and IIoT settings, reinforcing the relevance of the low-cost ESP-class substrate considered in this work [59]. Recent work specifically addressing evasion attacks against IoT-based IDS emphasizes that detection systems must also be robust to adversarial manipulation and may require adaptive defenses [56]. This supports a layered security posture: E2E encryption prevents broker and network tampering, while IDS and analytics help detect compromised endpoints and operational anomalies.

4.6. Limitations and Future Work

This study intentionally focuses on a practical baseline with a single ESP32 and Raspberry Pi pair, a low-rate sensor payload, and one sustained message rate (5 s interval) over a one-hour test. Additional experiments across different payload sizes, sampling intervals, and multiple concurrent clients are needed to quantify scalability and broker contention effects, especially at higher QoS levels where broker overhead can increase [8,9,10]. The latency measurements report average/min/max; future work should log full distributions, compute standard deviations and confidence intervals, and incorporate energy or CPU utilization measurements to strengthen cross-paper comparability, particularly when contrasting AES-GCM with lightweight AEAD alternatives such as ASCON [20,21]. Finally, the key provisioning method is simplified (PSK), and nonce management is discussed but not exhaustively stress-tested under long-term reboot/counter edge cases. Addressing secure provisioning, rotation, and revocation at scale—potentially via secure elements, ECC, or PUF-bound identities—remains an important direction for deployment-grade systems [36,52,55].

5. Conclusions

This work presented a practical, end-to-end encrypted data pipeline for Industrial IoT built from widely available components: an ESP32 client implemented in C++ with mbedTLS, an untrusted MQTT broker, and a Raspberry Pi gateway implemented in Python using PyCryptodome. The protocol employs AES-256-GCM with associated data to protect confidentiality, integrity, and authenticity at the application layer, treating the broker purely as a relay. Experimental results show that the ESP32 can prepare encrypted packets in 41.754 ms on average, with AES-GCM accounting for the dominant share of this latency, while JSON serialization and Base64 encoding remain smaller contributors. Functional tests demonstrate that tampered frames are reliably rejected with explicit MAC failure logs and that unauthorized devices are blocked by whitelist-based authorization. A one-hour soak test at one message every five seconds achieved a packet success rate of 99.72%, indicating that the system can sustain reliable encrypted acquisition on commodity hardware.

The central conclusion is that application-layer E2E encryption is technically and operationally feasible in typical IIoT monitoring regimes and meaningfully strengthens MQTT architectures by eliminating trust in the broker for message content. Limitations include the narrow benchmark scope (single device pair, one sustained sampling rate, short duration) and simplified key provisioning. Future work should expand scalability testing (payload sizes, message intervals, multiple clients), quantify energy/CPU impact, and integrate stronger fleet key management using secure elements, ECC, or PUF-bound identities.