03. IoT Protocols & Communication Security

IoT devices communicate over various specialized protocols designed for low bandwidth and low power consumption. Securing these protocols is critical to prevent eavesdropping, data manipulation, and unauthorized device control.

📡 Common IoT Protocols

1. MQTT (Message Queuing Telemetry Transport)

• Architecture: Publish/Subscribe model. Devices (Clients) publish messages to topics on a central server (Broker). Other devices subscribe to those topics.
• Security Risks: By default, MQTT operates in plaintext (Port 1883) without authentication. Attackers can connect to the broker, subscribe to # (wildcard for all topics), and read all traffic, or publish malicious commands (e.g., cmd/door/open).
• Defenses:
  • Use MQTTS (MQTT over TLS) on Port 8883.
  • Require Client Authentication (Username/Password or X.509 Client Certificates).
  • Implement Topic Access Control Lists (ACLs).

2. CoAP (Constrained Application Protocol)

• Architecture: Client/Server model over UDP, designed as a lightweight alternative to HTTP for constrained devices.
• Security Risks: Subject to UDP spoofing and amplification DDoS attacks. Plaintext transmission.
• Defenses: Use DTLS (Datagram Transport Layer Security) for encryption and authentication.

3. BLE (Bluetooth Low Energy)

• Architecture: Uses Generic Attribute Profile (GATT) with characteristics and services to exchange short bursts of data (e.g., fitness trackers, smart locks).
• Security Risks: Sniffing, Man-in-the-Middle (if weak pairing mechanisms like "Just Works" are used).
• Defenses: Use "Secure Connections" (OOB or Numeric Comparison pairing), encrypt characteristics, and implement application-layer encryption.

4. Zigbee

• Architecture: Mesh networking protocol used for home automation.
• Security Risks: The network key is sometimes transmitted in the clear during device pairing (joining). If an attacker sniffs the joining process, they can decrypt all network traffic.
• Defenses: Perform pairing only in physically secure environments, use pre-configured trust center link keys.

---

💻 Code Example: Secure vs. Vulnerable MQTT Client

Let's look at how an IoT device might connect to an MQTT broker using Python and the paho-mqtt library.

❌ Vulnerable Implementation (Plaintext, No Auth)

This code connects over plaintext port 1883. An attacker sniffing the network can read the telemetry data or intercept the connection.

import paho.mqtt.client as mqtt

# Vulnerable: No authentication, plaintext communication
BROKER = "mqtt.vulnerable-iot.local"
PORT = 1883
TOPIC = "home/livingroom/temperature"

def on_connect(client, userdata, flags, rc):
    print(f"Connected with result code {rc}")
    client.publish(TOPIC, "22.5", qos=1)

client = mqtt.Client(client_id="Sensor_1234")
client.on_connect = on_connect

# Connect insecurely
client.connect(BROKER, PORT, 60)
client.loop_forever()

✅ Secure Implementation (TLS & Authentication)

This code uses MQTTS (Port 8883), enforces TLS certificate validation, and uses a username and password for authentication.

import paho.mqtt.client as mqtt
import ssl

# Secure: TLS Encryption and Authentication
BROKER = "mqtt.secure-iot.local"
PORT = 8883
TOPIC = "home/livingroom/temperature"
USERNAME = "device_sensor_01"
PASSWORD = "SuperSecretPassword123!"

def on_connect(client, userdata, flags, rc):
    if rc == 0:
        print("Connected securely to MQTT Broker!")
        client.publish(TOPIC, "22.5", qos=1)
    else:
        print(f"Connection failed with code {rc}")

client = mqtt.Client(client_id="Sensor_01_Secure")

# 1. Set Authentication
client.username_pw_set(USERNAME, PASSWORD)

# 2. Configure TLS / SSL Context
# Ensure the broker's CA certificate is verified to prevent MitM
client.tls_set(ca_certs="/etc/ssl/certs/ca-certificates.crt", 
               tls_version=ssl.PROTOCOL_TLSv1_2)
client.tls_insecure_set(False) # Strictly enforce certificate validation

client.on_connect = on_connect

# Connect securely
client.connect(BROKER, PORT, 60)
client.loop_forever()

🔐 Implementing X.509 Client Certificates (Best Practice)

For enterprise IoT, rather than using passwords (which can be brute-forced or hardcoded), use mTLS (Mutual TLS). Each device gets its own unique certificate signed by the company's PKI.

# Instead of username_pw_set, use client certificates:
client.tls_set(ca_certs="ca.crt",
               certfile="device_sensor_01.crt",
               keyfile="device_sensor_01.key",
               tls_version=ssl.PROTOCOL_TLSv1_2)

Using mTLS ensures that even if an attacker guesses a password, they cannot connect without stealing the physical private key from the device's secure element.