💻 computer science

Quantifying the Security-Performance Trade-off in Constrained IoT: A Multi-Vector MQTT Attack Framework with Hybrid Defense-in-Depth Evaluation

This paper presents a reproducible experimental framework demonstrating that chaining physical HID intrusions with MQTT network attacks exposes critical security-performance trade-offs in constrained IoT devices, revealing that while TLS offers strong confidentiality, it incurs prohibitive latency and memory costs on legacy hardware, thereby motivating a novel Hybrid Defense-in-Depth architecture that prioritizes Access Control Lists for efficient, scalable protection.

Original authors: Thant Zin Moe, Julia Juremi, Manimegalai Rajenderan

Published 2026-06-27

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Thant Zin Moe, Julia Juremi, Manimegalai Rajenderan

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine your smart home or factory is like a busy office building. The MQTT protocol is the building's internal mail system. It's incredibly fast and efficient, designed to carry tiny notes (like "temperature is 72 degrees") between machines without clogging the hallways. However, by default, this mail system has no locks, no ID checks, and the letters are written in plain text. Anyone who walks into the building can read them, change them, or drop in fake letters.

This paper investigates a very specific, scary scenario: What happens if a bad guy physically plugs a device into a computer in your office, and then uses that to hack your smart devices over the network?

Here is the breakdown of their findings, using simple analogies:

1. The Attack: The "Bad USB" and the "Ghost Mailman"

The researchers set up a test lab with three types of devices:

The Attacker: A tiny computer (Raspberry Pi Pico) that looks like a USB drive but acts like a keyboard.
The Victim (Modern): A slightly smarter device (ESP8266) that can talk to the internet.
The Victim (Old): A very basic, old-school device (Arduino UNO) that is like a calculator with a Wi-Fi card.

The Attack Chain:

The Physical Plug-in: The attacker plugs their "Bad USB" into a computer. In just 2 or 3 seconds, it types commands so fast a human can't see it. It tells the computer to connect to the MQTT mail system.
The Network Hack: The attacker's device sends a fake message ("PICO ATTACK") to the mail system. Because the system has no locks, it accepts it.
The Result: The fake message is instantly read by the victim devices. The system is compromised.

The Finding: Without any security, the attack succeeds 100% of the time. It's like leaving your front door wide open and the mailman reading every letter you send.

2. The Three Security Solutions (and their costs)

The researchers tried three different ways to lock the door, but they found a major trade-off: Security vs. Speed.

Option A: Simple Passwords (The "Name Tag")

How it works: You require a username and password to send mail.
The Good: It stops people who don't have a password.
The Bad: The password is sent in plain text (like shouting your password across a crowded room). If a hacker watches the network, they can steal the password and use it later.
Speed: Very fast. No slowdown.

Option B: Access Control Lists (The "Guest List")

How it works: Even if you have a password, the system checks a list to see what you are allowed to do. The attacker is allowed to log in, but the system says, "No, you cannot send messages to this topic."
The Good: It completely stops the attacker from injecting fake messages.
The Bad: It doesn't hide the content of the messages (they are still readable if someone is eavesdropping).
Speed: Perfect. It adds almost zero delay. It's like a bouncer checking a list at the door; it doesn't slow down the line.

Option C: TLS Encryption (The "Armored Truck")

How it works: This wraps every message in a heavy, unbreakable steel box (encryption) and requires a digital ID card (certificate) to open it.
The Good: It is the gold standard. No one can read the messages, and no one can fake their ID.
The Bad: It is extremely heavy.
- On the Modern Device: It slowed the connection down by 1,133%. A message that used to take 0.15 seconds now takes nearly 2 seconds. In a factory where machines need to react in milliseconds, this delay causes the system to freeze.
- On the Old Device (Arduino): It caused a total crash. The old device only has a tiny amount of memory (like a small notepad). The "digital ID card" is too big to fit on the notepad. The device runs out of memory and dies.

3. The Big Discoveries (The "Aha!" Moments)

The paper proposes several new ideas based on these results:

The "Availability First" Rule: In the old days, security experts treated Confidentiality (hiding secrets), Integrity (not changing data), and Availability (keeping things running) as equals. This paper says: For tiny, old devices, Availability is king. If a security measure makes the device too slow or crashes it, it's a bad security measure, no matter how safe it makes the data. You can't have a secure system if the system isn't running.
The "Brownfield Gap": This is the gap between old, cheap hardware (like the Arduino) and modern security standards. You cannot simply "patch" old hardware to handle modern encryption; it's physically impossible because they don't have the brainpower or memory. It's like trying to put a Ferrari engine in a bicycle.
The "Air-Gap Paradox": The researchers found that even if you disconnect a network from the internet (an "air gap") to keep it safe, the devices still need to know the exact time to verify their security IDs. If the device's internal clock is wrong, the security system thinks the ID is expired and rejects it. So, to be secure, an isolated network actually needs a time-sync system, which creates a new dependency.
The "Delegated Trust" Solution: Since the old devices can't handle the heavy encryption, the paper suggests a Secure Edge Gateway.
- The Analogy: Imagine the old devices are children who can't carry heavy backpacks. The "Gateway" is a parent. The children carry a simple, lightweight note to the parent (using a simple secret code). The parent then carries the heavy, encrypted backpack to the outside world. The children stay safe and fast, while the parent handles the heavy security work.

Summary of Recommendations

The paper concludes that there is no "one size fits all" security for IoT.

For old, slow devices: Do not use heavy encryption (TLS) directly on the device. It will break them. Instead, use Access Control Lists (ACLs) to stop bad actors, and put a Secure Gateway in front of them to handle the heavy encryption for the outside world.
For real-time systems: Prioritize speed. If encryption slows the system down too much, it creates a safety hazard.

In short: Don't try to force a heavy suit of armor onto a paper doll. Use a smart strategy where the heavy lifting is done by a stronger guardian (the Gateway), while the small devices stay fast and functional.

Technical Summary: Quantifying the Security-Performance Trade-off in Constrained IoT

Problem Statement
The Message Queuing Telemetry Transport (MQTT) protocol is the standard for Machine-to-Machine (M2M) communication in the Internet of Things (IoT), yet its default configurations often lack encryption and authentication. While existing research addresses protocol-level vulnerabilities and physical-layer attacks (specifically Human Interface Device or HID attacks) as isolated domains, a critical gap exists: the lack of empirical understanding regarding chained, multi-vector threats. In this scenario, a physical HID intrusion (e.g., a "BadUSB" device) serves as the initial foothold to facilitate subsequent MQTT network compromise. Furthermore, the trade-off between implementing robust security measures (like Transport Layer Security) and maintaining operational viability on resource-constrained hardware (legacy 8-bit and modern 32-bit microcontrollers) remains insufficiently quantified.

Methodology
The authors employed a quantitative experimental methodology using a controlled, isolated testbed to evaluate a reproducible, two-stage attack chain and three distinct mitigation strategies.

Hardware Testbed: The setup included a Raspberry Pi Pico (RP2040) acting as the attacker (HID vector), an ESP8266 NodeMCU as a modern 32-bit victim node, and an Arduino UNO (ATmega328P) as a legacy 8-bit victim node. A host laptop ran the Mosquitto broker and forensic tools (Wireshark).
Attack Vector: The attack chain involved:
1. Stage 1 (Physical): The Raspberry Pi Pico emulated a USB HID keyboard upon connection, executing a fileless Python script to inject a malicious payload ("PICO ATTACK") into the network.
2. Stage 2 (Network): An ESP8266 rogue client subscribed to all topics using wildcards to eavesdrop and inject payloads.
Mitigation Strategies: Three scenarios were tested:
1. Baseline: No mitigation (anonymous access, plaintext).
2. Lightweight Mitigation: Simple username/password authentication and Access Control Lists (ACLs) restricting topic access by client identity.
3. Strong Mitigation: Transport Layer Security (TLS) v1.2 with RSA-2048 certificates and mutual authentication.
Metrics: The study measured Attack Success Rate (ASR), connection latency ( $T_{conn}$ ), detection latency, protocol overhead ratios, and hardware failure modes (specifically memory exhaustion).

Key Results
The experimental results highlighted a severe dichotomy between security strength and performance on constrained devices:

Baseline Vulnerability: The unmitigated system suffered a 100% Attack Success Rate, with payloads transmitted in plaintext.
ACL Effectiveness: Access Control Lists (ACLs) achieved a 100% reduction in unauthorized injection attacks with negligible latency impact (mean latency remained ~152 ms, comparable to the baseline). Crucially, ACLs maintained stability on both 32-bit and 8-bit hardware.
TLS Overhead: While TLS v1.2 successfully eliminated confidentiality threats (ASR for eavesdropping dropped to 0%), it imposed a 1,133% increase in connection latency on the ESP8266 (rising from ~151 ms to ~1,853 ms).
Hardware Failure: The legacy Arduino UNO (8-bit, 2KB SRAM) experienced categorical failure in every TLS trial due to memory exhaustion. The 2KB SRAM was insufficient to buffer the ~4KB X.509 certificate chain required for the handshake.
Energy and Scalability: Enabling TLS increased radio-active time by 12-fold, drastically reducing battery life estimates. Additionally, simultaneous reboots in a large fleet could trigger a "Handshake Storm," causing self-inflicted Denial of Service (DoS).

Theoretical Contributions and Proposed Models
Based on these empirical findings, the paper proposes several theoretical frameworks and architectural models:

Hierarchical CIA Model: The authors argue that for constrained IoT, the classical CIA triad (Confidentiality, Integrity, Availability) should not be treated as co-equal. Instead, Availability must be the primary engineering constraint. Security controls that degrade availability beyond operational thresholds (e.g., TLS latency breaking a control loop) must be rejected, regardless of confidentiality benefits.
The Brownfield Gap: The study empirically validates the structural incompatibility of legacy 8-bit microcontrollers with modern Public Key Infrastructure (PKI) standards. The paper notes that replacing 500 legacy sensors to achieve TLS compliance would cost significantly more than implementing a gateway-based solution.
The Air-Gap Paradox: The research identifies an overlooked dependency where cryptographic trust (X.509) relies on accurate time synchronization. In air-gapped networks without NTP access, devices default to incorrect hardware clock times, causing valid certificates to be rejected as expired ("Time Travel" failure).
Delegated Trust Model & Secure Edge Gateway: To bridge the Brownfield Gap, the authors propose a Secure Edge Gateway architecture. In this model, the constrained device authenticates the local gateway using a lightweight shared secret (HMAC-SHA256), while the gateway handles the heavy lifting of X.509 verification with external services. This allows legacy devices to participate in secure networks without hardware replacement.

Significance and Claims
The paper claims to provide the first empirical comparison of TLS overhead on both 32-bit and 8-bit platforms within a unified attack-defense framework. Its primary significance lies in demonstrating that there is no universal security policy for constrained IoT.

The authors conclude that while TLS is effective for confidentiality, it is operationally destructive for real-time control loops and legacy hardware. Consequently, they advocate for a Hybrid Defense-in-Depth Architecture: utilizing ACLs for internal network security to ensure low-latency and high availability, while reserving TLS for the perimeter (Edge Gateway-to-Cloud boundary) to satisfy regulatory compliance and protect data in transit. This approach offers a practical, cost-effective path for industrial IoT security architects to balance security requirements with the physical limitations of constrained devices.