1361  IoT Security Architecture and Attack Surfaces

1361.1 Learning Objectives

By the end of this chapter, you should be able to:

  • Describe security architecture layers in IoT systems (device, network, cloud)
  • Identify common IoT attack surfaces and vulnerabilities
  • Apply defense-in-depth strategies to IoT deployments
  • Understand attack trees and security maturity models
  • Implement layered security controls at each architectural level

1361.2 Defense-in-Depth Layers

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#fff', 'fontSize': '11px'}}}%%
flowchart TB
    subgraph L1["Layer 1: Physical Security"]
        P1["Tamper-resistant enclosure"]
        P2["Secure boot ROM"]
        P3["Physical access controls"]
    end

    subgraph L2["Layer 2: Network Security"]
        N1["Firewall/Segmentation"]
        N2["TLS/DTLS encryption"]
        N3["VPN tunnels"]
    end

    subgraph L3["Layer 3: Device Security"]
        D1["Authentication (PKI)"]
        D2["Secure firmware updates"]
        D3["Access control lists"]
    end

    subgraph L4["Layer 4: Application Security"]
        A1["Input validation"]
        A2["Secure APIs"]
        A3["Data encryption at rest"]
    end

    subgraph L5["Layer 5: Monitoring"]
        M1["Intrusion detection"]
        M2["Audit logging"]
        M3["Anomaly detection"]
    end

    L1 --> L2 --> L3 --> L4 --> L5

    ATK["πŸ”΄ Attacker"] -.->|"Must breach<br/>ALL layers"| L1

    style L1 fill:#2C3E50,stroke:#16A085,color:#fff
    style L2 fill:#16A085,stroke:#2C3E50,color:#fff
    style L3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style L4 fill:#7F8C8D,stroke:#2C3E50,color:#fff
    style L5 fill:#9B59B6,stroke:#2C3E50,color:#fff
    style ATK fill:#E74C3C,stroke:#2C3E50,color:#fff

Figure 1361.1: Defense-in-depth showing five security layers that attackers must breach sequentially - failure of one layer does not compromise the system

1361.3 IoT Attack Tree

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#E74C3C', 'lineColor': '#E74C3C', 'secondaryColor': '#E67E22', 'tertiaryColor': '#fff', 'fontSize': '11px'}}}%%
flowchart TD
    GOAL["🎯 GOAL: Compromise<br/>IoT Device"] --> V1["Physical Access"]
    GOAL --> V2["Network Attack"]
    GOAL --> V3["Software Exploit"]
    GOAL --> V4["Supply Chain"]

    V1 --> V1A["JTAG/Debug ports<br/>open"]
    V1 --> V1B["Extract firmware<br/>from flash"]
    V1 --> V1C["Side-channel<br/>analysis"]

    V2 --> V2A["Default credentials<br/>(OWASP #2)"]
    V2 --> V2B["Unencrypted<br/>traffic sniffing"]
    V2 --> V2C["Man-in-the-middle<br/>attack"]

    V3 --> V3A["Buffer overflow"]
    V3 --> V3B["Command injection"]
    V3 --> V3C["Outdated libraries<br/>(no patches)"]

    V4 --> V4A["Malicious firmware<br/>at factory"]
    V4 --> V4B["Compromised<br/>update server"]

    style GOAL fill:#E74C3C,stroke:#2C3E50,color:#fff
    style V1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style V2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style V3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style V4 fill:#E67E22,stroke:#2C3E50,color:#fff

Figure 1361.2: IoT attack tree showing common vulnerability paths: physical access (debug ports, firmware extraction), network attacks (default credentials, unencrypted traffic), software exploits (buffer overflow, injection), and supply chain attacks

1361.4 Security Maturity Model

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#fff', 'fontSize': '12px'}}}%%
graph LR
    subgraph Level1["Level 1: Initial"]
        L1A["❌ Default passwords"]
        L1B["❌ No encryption"]
        L1C["❌ No updates"]
    end

    subgraph Level2["Level 2: Basic"]
        L2A["βœ“ Unique passwords"]
        L2B["βœ“ TLS enabled"]
        L2C["βœ“ Manual updates"]
    end

    subgraph Level3["Level 3: Managed"]
        L3A["βœ“ PKI certificates"]
        L3B["βœ“ Secure boot"]
        L3C["βœ“ OTA updates"]
    end

    subgraph Level4["Level 4: Optimized"]
        L4A["βœ“ Zero-trust"]
        L4B["βœ“ HSM/TPM"]
        L4C["βœ“ Bug bounty"]
    end

    Level1 -->|"Immediate<br/>action needed"| Level2
    Level2 -->|"6-12 months"| Level3
    Level3 -->|"12-24 months"| Level4

    style Level1 fill:#E74C3C,stroke:#2C3E50
    style Level2 fill:#E67E22,stroke:#2C3E50
    style Level3 fill:#16A085,stroke:#2C3E50
    style Level4 fill:#27AE60,stroke:#2C3E50

Figure 1361.3: Security maturity progression from initial (insecure defaults) through basic (unique passwords, encryption) to managed (PKI, secure boot) and optimized (zero-trust, hardware security modules)

1361.5 Interactive Security Quiz

Test your understanding of security and privacy concepts with instant feedback.

NoteIoT Security Fundamentals Quiz

\({q1_feedback}\){q2_feedback} \({q3_feedback}\){q4_feedback}

1361.6 Knowledge Check

Test your understanding of security and privacy concepts.

Question 9: A company implements β€œsecurity by design” for a new IoT thermostat. On first boot, what should happen to align with secure-by-default principles?

πŸ’‘ Explanation: Secure-by-default means devices ship with secure configurations requiring NO user action to be secure. Forcing password creation before operation prevents the device from ever being accessible with default credentials. Option A (default password) violates secure-by-default. Option B (all features enabled, HTTP) violates principle of least privilege and secure transport. Option D (debug ports) violates production hardening requirements. The correct approach: refuse to operate until security baseline is met.

1361.7 The CIA Triad

⏱️ ~10 min | ⭐ Foundational | πŸ“‹ P11.C01.U03

The foundational security principles are Confidentiality, Integrity, and Availability (CIA):

%% fig-alt: "CIA Triad diagram showing three security pillars. Confidentiality ensures only authorized data access through encryption and access controls to prevent eavesdropping and data breaches. Integrity ensures data has not been tampered with using digital signatures and HMAC hashing to prevent tampering and replay attacks. Availability ensures systems work when needed through redundancy and rate limiting to prevent DDoS attacks and system failures."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '14px'}}}%%
graph TD
    CIA[CIA Triad<br/>Security Pillars]

    C[πŸ”’ Confidentiality<br/>Data Secrecy]
    I[βœ… Integrity<br/>Data Accuracy]
    A[⚑ Availability<br/>System Uptime]

    CIA --> C
    CIA --> I
    CIA --> A

    C --> C1[Only authorized<br/>access to data]
    C --> C2[Encryption<br/>Access Controls]
    C --> C3[Prevent:<br/>Eavesdropping<br/>Data Breaches]

    I --> I1[Data hasn't<br/>been tampered]
    I --> I2[Digital Signatures<br/>HMAC/Hashing]
    I --> I3[Prevent:<br/>Tampering<br/>Replay Attacks]

    A --> A1[Systems work<br/>when needed]
    A --> A2[Redundancy<br/>Rate Limiting]
    A --> A3[Prevent:<br/>DDoS Attacks<br/>System Failures]

    style CIA fill:#2C3E50,stroke:#16A085,color:#fff,stroke-width:3px
    style C fill:#16A085,stroke:#2C3E50,color:#fff
    style I fill:#16A085,stroke:#2C3E50,color:#fff
    style A fill:#16A085,stroke:#2C3E50,color:#fff
    style C1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style C2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style C3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style I1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style I2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style I3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style A1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style A2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style A3 fill:#E67E22,stroke:#2C3E50,color:#fff

Figure 1361.4: CIA Triad diagram showing three security pillars

1361.7.1 Confidentiality

Definition: Ensuring information is accessible only to authorized parties.

IoT Examples: - Smart home camera footage should not be publicly accessible - Health data from wearables remains private - Industrial sensor data protected from competitors

Threats: - Eavesdropping on unencrypted Wi-Fi/Bluetooth - Man-in-the-middle attacks - Data breaches

Countermeasures:

// Example: AES-128 encryption for sensor data
#include <AES.h>

AES aes;
byte key[] = {0x2b, 0x7e, 0x15, 0x16, /* ... 16 bytes ... */};
byte plaintext[] = "Temperature: 22.5";
byte ciphertext[16];

void setup() {
  aes.set_key(key, 128);
  aes.encrypt(plaintext, ciphertext);
  // Transmit ciphertext instead of plaintext
}

1361.7.2 Integrity

Definition: Ensuring information has not been altered or tampered with.

IoT Examples: - Firmware updates are authentic and unmodified - Sensor readings haven’t been manipulated - Command messages from authorized source

Threats: - Firmware injection - Data tampering - Replay attacks

Countermeasures:

// Example: HMAC for message integrity
#include <SHA256.h>

byte message[] = "temperature=22.5";
byte secret[] = "shared_secret_key";
byte hmac[32];

void verifyIntegrity() {
  SHA256 sha256;
  sha256.resetHMAC(secret, sizeof(secret));
  sha256.update(message, sizeof(message));
  sha256.finalizeHMAC(secret, sizeof(secret), hmac, sizeof(hmac));

  // Compare received HMAC with calculated HMAC
  // If match β†’ integrity verified
}

1361.7.3 Availability

Definition: Ensuring systems and data are accessible when needed.

IoT Examples: - Smart locks always respond to unlock commands - Medical devices remain operational - Industrial sensors provide continuous monitoring

Threats: - DDoS attacks (Mirai botnet) - Physical destruction - Power/battery depletion attacks

Countermeasures:

// Example: Rate limiting to prevent DoS
unsigned long lastRequest = 0;
const int MIN_REQUEST_INTERVAL = 1000;  // 1 second

void handleRequest() {
  if (millis() - lastRequest < MIN_REQUEST_INTERVAL) {
    // Reject: Too many requests
    return;
  }

  lastRequest = millis();
  // Process legitimate request
}

1361.8 Videos

Case study examining how data collection and analysis can compromise user privacy, with lessons applicable to IoT data practices and consent management.

Explore how blockchain technology provides decentralized security and trust mechanisms for IoT networks, including device authentication and data integrity.

NoteCore Cybersecurity Concepts for IoT
Cybersecurity Basics for IoT
From slides β€” foundational security concepts contextualized for IoT systems.
NoteThreats, Privacy, and Risk
Threats, Privacy, and Risk in IoT
From slides β€” overview of privacy threats, risk trade-offs, and mitigations.

1361.8.1 Extended Security Properties for IoT

Beyond CIA, IoT systems require:

Property Description IoT Example
Authentication Verify identity of users/devices Device certificates, 2FA
Authorization Control what authenticated entities can do Role-based access control
Non-repudiation Prevent denial of actions Digital signatures, audit logs
Accountability Track who did what and when Logging, blockchain ledgers
Privacy Protect personal information Data anonymization, consent

Question 3: An industrial sensor sends temperature readings over the network. An attacker intercepts packets and modifies β€œ22.5Β°C” to β€œ125Β°C”, triggering emergency shutdowns. Which CIA triad property is violated?

πŸ’‘ Explanation: This is a classic integrity violationβ€”the data was tampered with during transmission. While the shutdown affects availability (secondary impact) and the attacker may have intercepted the data (confidentiality concern), the PRIMARY violation is integrity. Countermeasures include HMAC signatures or digital signatures to detect tampering. Note that authentication isn’t part of CIAβ€”it’s a separate security property that helps ensure integrity.

1361.9 IoT Security Architecture Layers

⏱️ ~12 min | ⭐⭐ Intermediate | πŸ“‹ P11.C01.U04

IoT security must be addressed at every layer:

%% fig-alt: "Three-layer IoT security architecture showing Layer 3 Cloud/Application (cloud platforms, databases, web dashboards) with security controls for API authentication and SQL injection prevention; Layer 2 Network/Communication (Wi-Fi, Bluetooth, cellular, LoRa, Zigbee) with TLS/DTLS encryption and certificate validation; and Layer 1 Perception/Device (sensors, actuators, embedded devices) with secure boot and physical tampering protection. Arrows flow from cloud layer down through network layer to device layer."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '13px'}}}%%
graph TB
    subgraph LAYER3["Layer 3: Cloud/Application Layer"]
    L3C[Cloud Platforms<br/>Databases<br/>Web Dashboards]
    L3S[Security:<br/>API Authentication<br/>SQL Injection Prevention<br/>Secure Storage<br/>Access Controls]
    end

    subgraph LAYER2["Layer 2: Network/Communication Layer"]
    L2C[Wi-Fi, Bluetooth<br/>Cellular, LoRa<br/>Zigbee]
    L2S[Security:<br/>TLS/DTLS Encryption<br/>Certificate Validation<br/>MITM Prevention<br/>Replay Protection]
    end

    subgraph LAYER1["Layer 1: Perception/Device Layer"]
    L1C[Sensors, Actuators<br/>Embedded Devices]
    L1S[Security:<br/>Secure Boot<br/>Physical Tampering Protection<br/>Debug Port Hardening<br/>Side-Channel Protection]
    end

    LAYER3 --> LAYER2
    LAYER2 --> LAYER1

    style L3C fill:#2C3E50,stroke:#16A085,color:#fff
    style L3S fill:#E67E22,stroke:#2C3E50,color:#fff
    style L2C fill:#2C3E50,stroke:#16A085,color:#fff
    style L2S fill:#E67E22,stroke:#2C3E50,color:#fff
    style L1C fill:#2C3E50,stroke:#16A085,color:#fff
    style L1S fill:#E67E22,stroke:#2C3E50,color:#fff

Figure 1361.5: Three-layer IoT security architecture showing Layer 3 Cloud/Application (cloud platforms, databases, web dashboards) with security controls for API…

1361.9.1 Layer 1: Perception/Device Layer

Components: Sensors, actuators, embedded devices

Security Concerns: - Physical tampering and theft - Side-channel attacks (power analysis) - Lack of secure boot - Debug ports left enabled

Countermeasures:

// Secure boot verification
#include <esp_secure_boot.h>

void setup() {
  if (esp_secure_boot_enabled()) {
    Serial.println("Secure boot ENABLED");
    // Firmware signature verified before execution
  } else {
    Serial.println("WARNING: Secure boot DISABLED");
  }
}

// Hardware root of trust
#include <esp_efuse.h>

void checkDeviceKey() {
  uint8_t mac[6];
  esp_efuse_mac_get_default(mac);
  // Use hardware-unique MAC as device identity
}

1361.9.2 Layer 2: Network/Communication Layer

Components: Wi-Fi, Bluetooth, Cellular, LoRa, Zigbee

Security Concerns: - Unencrypted communications - Weak authentication protocols - Man-in-the-middle attacks - Replay attacks

Countermeasures:

// TLS/SSL for MQTT over Wi-Fi
#include <Wi-FiClientSecure.h>
#include <PubSubClient.h>

Wi-FiClientSecure espClient;
PubSubClient client(espClient);

// Load CA certificate
const char* ca_cert = \
"-----BEGIN CERTIFICATE-----\n" \
"MIIDrzCCApegAwIBAgIQCDvgVpBCRrGhdWrJWZHHSjANBgkqhkiG9...\n" \
"-----END CERTIFICATE-----\n";

void setup() {
  espClient.setCACert(ca_cert);  // Verify server identity
  client.setServer("mqtt.example.com", 8883);  // Port 8883 = MQTT over TLS
}

1361.9.3 Layer 3: Cloud/Application Layer

Components: Cloud platforms, databases, web dashboards

Security Concerns: - Weak API authentication - SQL injection, XSS attacks - Insecure data storage - Inadequate access controls

Countermeasures:

# Secure API with JWT authentication
from flask import Flask, request, jsonify
import jwt
import datetime

app = Flask(__name__)
SECRET_KEY = "your-secret-key"

@app.route('/api/sensor-data', methods=['POST'])
def receive_data():
    # Verify JWT token
    token = request.headers.get('Authorization')

    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=['HS256'])
        device_id = payload['device_id']

        # Validate and store data
        data = request.json
        # ... sanitize inputs, prevent injection ...

        return jsonify({"status": "success"}), 200

    except jwt.InvalidTokenError:
        return jsonify({"error": "Invalid token"}), 401

1361.10 Common IoT Attack Surfaces

⏱️ ~15 min | ⭐⭐ Intermediate | πŸ“‹ P11.C01.U05

1361.10.1 Device Firmware and Software

%% fig-alt: "IoT attack surfaces diagram showing five main attack vectors: 1) Firmware/Software with hardcoded credentials, buffer overflows, outdated libraries, and no code signing; 2) Network Communication with unencrypted protocols, weak Wi-Fi passwords, and no certificate validation; 3) Web/Mobile Apps with weak password policies, no rate limiting, exposed APIs, and XSS vulnerabilities; 4) Cloud Infrastructure with misconfigured buckets, weak database credentials, and no encryption at rest; 5) Supply Chain with compromised components, fake devices, chip backdoors, and untrusted libraries."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#E67E22', 'fontSize': '13px'}}}%%
graph LR
    AS[IoT Attack Surfaces]

    AS --> A1[1. Firmware/Software]
    AS --> A2[2. Network Communication]
    AS --> A3[3. Web/Mobile Apps]
    AS --> A4[4. Cloud Infrastructure]
    AS --> A5[5. Supply Chain]

    A1 --> V1[Hardcoded Credentials<br/>Buffer Overflows<br/>Outdated Libraries<br/>No Code Signing]
    A2 --> V2[Unencrypted Protocols<br/>Weak Wi-Fi Passwords<br/>No Certificate Validation]
    A3 --> V3[Weak Password Policies<br/>No Rate Limiting<br/>Exposed APIs<br/>XSS Vulnerabilities]
    A4 --> V4[Misconfigured Buckets<br/>Weak DB Credentials<br/>No Encryption at Rest]
    A5 --> V5[Compromised Components<br/>Fake Devices<br/>Chip Backdoors<br/>Untrusted Libraries]

    style AS fill:#2C3E50,stroke:#16A085,color:#fff,stroke-width:3px
    style A1 fill:#16A085,stroke:#2C3E50,color:#fff
    style A2 fill:#16A085,stroke:#2C3E50,color:#fff
    style A3 fill:#16A085,stroke:#2C3E50,color:#fff
    style A4 fill:#16A085,stroke:#2C3E50,color:#fff
    style A5 fill:#16A085,stroke:#2C3E50,color:#fff
    style V1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style V2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style V3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style V4 fill:#E67E22,stroke:#2C3E50,color:#fff
    style V5 fill:#E67E22,stroke:#2C3E50,color:#fff

Figure 1361.6: IoT attack surfaces diagram showing five main attack vectors: 1) Firmware/Software with hardcoded credentials, buffer overflows, outdated libraries…

Vulnerabilities: - Hardcoded credentials - Buffer overflows - Outdated libraries - No code signing

Example:

// VULNERABLE CODE - Buffer overflow
char username[32];
strcpy(username, user_input);  // No bounds checking!

// SECURE CODE
strncpy(username, user_input, sizeof(username) - 1);
username[sizeof(username) - 1] = '\0';

1361.10.2 Network Communication

Vulnerabilities: - Unencrypted protocols (HTTP, MQTT without TLS) - Weak Wi-Fi passwords (WEP, short WPA2) - No certificate validation

Attack Example: Man-in-the-Middle

Device ──[plain text]──> Attacker ──[plain text]──> Cloud
         "temp=22.5"     [intercept]     "temp=99.9" (modified!)

Defense:

// Always use encrypted protocols
// ❌ BAD: http://api.server.com/data
// βœ… GOOD: https://api.server.com/data

// ❌ BAD: mqtt://broker:1883
// βœ… GOOD: mqtts://broker:8883 with certificate validation

1361.10.3 Web/Mobile Applications

Vulnerabilities: - Weak password policies - No rate limiting - Exposed APIs without authentication - Cross-site scripting (XSS)

Example: Insecure Direct Object Reference

GET /api/camera/feed?deviceId=12345
// Attacker changes: deviceId=12346 β†’ Access someone else's camera!

// Fix: Verify ownership
if (deviceOwner != currentUser) {
    return 403 Forbidden;
}

1361.10.4 Cloud Infrastructure

Vulnerabilities: - Misconfigured S3 buckets (public access) - Weak database credentials - No encryption at rest - Inadequate logging

1361.10.5 Supply Chain

Vulnerabilities: - Compromised components - Fake devices - Backdoors in chips/firmware - Untrusted third-party libraries

1361.11 Standards and Certification Reference

1361.12 What’s Next

Continue your security learning journey:

Recommended next: Security Frameworks β†’