← All 50 books
Book 37 of 50 · Free
IoT Security Basics
2,829 words · 17 chapters · illustrated
IoT Security Basics
Book 37 of 50 — AstolixGen Learning Series For researcher and publication students
About This Book
Insecure IoT devices have taken down DNS providers (Mirai, 2016), spied through cameras, and poisoned industrial processes. Security is not a feature you add later — in IoT it's a system property spanning hardware, firmware, network, and cloud. This book builds the full threat model: device hardening, secure boot, TLS on constrained devices, MQTT/CoAP security, updates, and privacy. You'll learn to evaluate IoT security experimentally and write the threat-model sections reviewers expect.
Learning objectives: - Build a threat model for an IoT system (assets, attackers, vectors) - Harden devices: secure boot, unique credentials, minimal attack surface - Deploy TLS/mTLS on constrained hardware with measured costs - Secure MQTT/CoAP ingestion (auth, ACLs, payload signing) - Design secure firmware update (OTA) pipelines - Handle keys, certificates, and revocation at fleet scale - Evaluate security experimentally and write it up
Chapter 1: Why IoT Security Fails — The Hall of Shame
Mirai (2016): a worm that enslaved 600,000+ cameras/DVRs using 60 factory default passwords, then DDoSed Dyn (taking down Twitter, Netflix, GitHub). Root cause: default credentials + Telnet open. Stuxnet (2010): sabotaged centrifuges via USB and stolen certificates — the industrial IoT nightmare. Countless cameras: Shodan-indexed devices with no password, streaming homes to the internet.
The pattern: manufacturers optimize for cost and time-to-market; security is invisible to buyers until catastrophe. Default passwords, unencrypted protocols, no update mechanism, debug interfaces left open. As a researcher, your job is to measure these failures, propose fixes, and quantify the costs — the community needs evidence, not just warnings.
Example: A 2023 scan of a university campus found 41 MQTT brokers, 6 with anonymous access, 2 publishing building-control topics. The remediation (TLS + ACLs, one weekend) became a case-study paper.
For your research: Measurement studies of real-world IoT insecurity (scans, with proper authorization and ethics) are high-impact. Always get permission; unauthorized scanning is illegal in many jurisdictions.
Key takeaway: Default creds, cleartext protocols, no updates — measure real failures, propose measured fixes.
Chapter 2: Threat Modeling — Assets, Attackers, Vectors
A threat model names: assets (sensor data integrity? device control? user privacy? safety?), attackers (curious neighbor? botnet herder? nation-state? — be realistic about capability), vectors (network, physical access, supply chain, cloud APIs), and impact (what's the worst case?).
Use STRIDE per component: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. For each data flow in your architecture diagram, ask all six. This systematic pass is what separates a security section from hand-waving.
Example threat model (farm irrigation): Assets: water control (over-irrigation wastes $), sensor data integrity. Attackers: prankster neighbor (low skill), botnet (automated). Vectors: Wi-Fi (weak password?), MQTT broker (anonymous?), physical (valve tampering). Worst case: attacker opens all valves for a week → $2,000 water bill + crop loss. Mitigations follow directly: WPA3, broker TLS+ACLs, valve command authentication, flow-meter anomaly alerts.
For your research: A threat-model table (component × STRIDE × mitigation) is an expected artifact in IoT security papers. Reviewers check completeness.
Key takeaway: Assets → attackers → vectors → STRIDE per flow → mitigations. Tabulate it.
Chapter 3: Device Hardening — Boot, Credentials, Surface
Secure boot: the device verifies firmware signatures at startup (chain of trust from immutable ROM). Without it, anyone with physical access owns the device permanently. Unique credentials: per-device passwords/certificates provisioned at manufacture — no defaults, ever. Minimal attack surface: disable Telnet/SSH/debug UART in production; close unused ports; the device should expose exactly its function and nothing else.
Physical security: assume attackers touch the device. Disable JTAG/SWD or require authentication; encrypt sensitive flash contents; consider tamper-evident enclosures for high-value targets. Perfect physical security is impossible — design so a captured device yields minimal fleet-wide secrets (unique keys per device, no master passwords in firmware).
Example: A sensor fleet audit: 3 findings — shared MQTT password in all firmware (one leak = fleet compromise), debug UART active (firmware dump in 5 min), no secure boot. Fixes: per-device certificates, UART disabled in prod builds, secure boot enabled. Cost: 2 engineer-weeks + $0.30/unit for provisioning.
For your research: Firmware-analysis studies (extracting firmware, finding hardcoded secrets) are classic publishable work — with proper legal/ethical boundaries (your own devices or authorized targets).
Key takeaway: Secure boot + unique credentials + minimal surface + no fleet-wide secrets.
Chapter 4: Cryptography on Constrained Devices
What fits on an MCU: AES-128 (encryption, ~µs on Cortex-M with hardware accel), SHA-256/HMAC (integrity), ECC P-256 (signatures/key exchange — RSA-2048 is too heavy for most MCUs), ChaCha20-Poly1305 (where AES hardware is absent). TLS 1.2/1.3 with ECC cipher suites runs on ESP32-class devices; on Cortex-M4 it's possible (mbedTLS) but handshake-heavy.
Key management is harder than algorithms: where are keys stored (secure element like ATECC608A vs flash — the former resists extraction), how are they provisioned (factory injection), rotated, and revoked? A perfect cipher with a leaked key is worthless.
Example measurements (ESP32, mbedTLS): TLS 1.2 ECDHE handshake: 1.8 s, 42 mJ; session resumption: 0.3 s, 8 mJ. Lesson: use session resumption/tickets for frequent reconnects — the handshake, not the record encryption, is the cost.
For your research: Crypto-cost measurements on your target MCU (handshake time/energy, throughput) are standard, expected, citable results. Compare suites; report with/without hardware acceleration.
Key takeaway: ECC + AES-GCM/ChaCha20 fit MCUs; the handshake dominates cost — measure it, use resumption.
Chapter 5: Securing MQTT and CoAP
MQTT: TLS on port 8883 (never 1883 in production), per-device credentials or client certificates, topic ACLs (least privilege per device — Book 31), payload signing (HMAC) for integrity even if the broker is compromised, and broker hardening (no anonymous, updated version). CoAP: DTLS for transport security; OSCORE (RFC 8613) for object-level security that survives proxies — important because CoAP often traverses translating gateways where DTLS terminates.
End-to-end vs hop-by-hop: TLS protects device→broker, but the broker sees plaintext. If the broker is untrusted (or just defense-in-depth), add payload-level encryption (AES-GCM with per-device keys) so the broker routes opaque blobs.
Example: Medical sensor deployment: mTLS (client certificates) to the broker + AES-GCM payload encryption with keys in a secure element + topic ACLs. Broker compromise reveals nothing; device compromise affects one device. The layered design was the paper's core contribution.
For your research: Compare "TLS only" vs "TLS + payload encryption" on overhead and threat coverage — a clean, useful evaluation.
Key takeaway: TLS + per-device auth + ACLs + payload signing/HMAC; consider end-to-end encryption past the broker.
Chapter 6: Secure Firmware Updates (OTA)
An IoT device without secure updates is a future botnet member. Requirements: signed images (ECC signature verified by bootloader), version anti-rollback (monotonic version counter — don't let attackers reinstall old vulnerable firmware), encrypted transport (TLS), atomic install (A/B partitions — failed update boots the old image, never bricks), and update authorization (only your signing key's images install).
The update server is critical infrastructure: compromise it and you own the fleet. Sign offline (air-gapped key), publish signatures + images, devices verify. Monitor update success rates — a fleet stuck on old firmware is a vulnerability inventory.
Example: A/B partitioned ESP32 fleet: update downloads to partition B, verifies signature, boots B, confirms health, marks stable. A bad update rolled back automatically on 12 of 200 devices (brownout during flash) — zero bricks, full telemetry on the failure.
For your research: OTA security analyses (evaluating real vendors' update mechanisms against the requirements list) are impactful — several CVEs and papers came from exactly this.
Key takeaway: Signed + anti-rollback + A/B + offline signing keys; monitor fleet update state.
Chapter 7: Keys, Certificates, and PKI at Fleet Scale
Fleet PKI: an offline root CA, an online intermediate CA for issuance, per-device certificates provisioned at manufacture (or via EST enrollment on first boot), and a revocation story (CRL or OCSP — or short-lived certificates that expire instead of being revoked, simpler for IoT).
Provisioning is the operational crux: injecting unique keys in the factory without leaking them (HSM-backed provisioning stations, audited). EST (RFC 7030) and CMP automate enrollment; for smaller fleets, pre-provisioned certificates on secure elements are simpler.
Example: 10,000-sensor PKI: offline root, intermediate on HSM, per-device ECC certs in ATECC608A at manufacture, 5-year validity, revocation via denylist pushed in firmware updates. Provisioning added 11 seconds per unit on the line — measured and reported.
For your research: PKI-for-IoT experience reports (costs, pitfalls, measured overhead) are rare and valuable — practitioners cite them.
Key takeaway: Offline root, per-device certs, a revocation story, measured provisioning cost.
Chapter 8: Privacy — Data Minimization and Beyond
IoT privacy principles: minimize (collect only what's needed — a temperature sensor doesn't need a microphone), process locally (TinyML/edge filtering keeps raw data on-device), limit retention (delete raw when aggregates suffice), anonymize for research (but know that sensor traces can re-identify — 4 spatio-temporal points identify 95% of individuals in mobility data; treat "anonymized" claims skeptically).
Regulatory: GDPR (EU), and sectoral rules (health data). For research: ethics approval, informed consent, data management plans, and the right to erasure — design these in, not on.
Example: An occupancy study used PIR + CO₂ (no cameras, no microphones) by design — the privacy-preserving sensor choice was a stated contribution, and ethics approval took 2 weeks instead of 6 months.
For your research: A privacy analysis section (what's collected, why, alternatives considered, retention, anonymization limits) is increasingly required — write it before reviewers ask.
Key takeaway: Minimize, localize, limit retention; treat anonymization claims skeptically; bake in ethics.
Chapter 9: Network Segmentation and Monitoring
Segment IoT devices from everything else: separate VLAN/SSID, firewall rules (devices talk only to the broker, never the internet or each other), and for critical systems, data diodes or unidirectional gateways. Monitor: baseline normal traffic per device (a temperature sensor sending 10 KB/day that suddenly sends 10 MB is compromised — alert on it), IDS signatures for IoT malware (Mirai variants have known patterns), and broker-side anomaly detection (impossible travel for device certs, topic-access violations).
Example: A campus IoT VLAN: 300 devices, allowlist firewall (broker:8883 only), NetFlow anomaly alerts. Detected a compromised camera within 20 minutes via traffic spike — contained by VLAN isolation before it scanned the LAN.
For your research: Network-behavior baselining papers (what's normal per device class, detection rates for injected attacks) are solid applied-security contributions.
Key takeaway: Segment (VLAN, allowlists), baseline per-device traffic, alert on deviation.
Chapter 10: Evaluating IoT Security — Methods That Convince
Security evaluations that convince: threat-model coverage (every STRIDE item addressed or explicitly accepted as residual risk), penetration testing (documented methodology, scope, findings, fixes — your own systems), fuzzing (parsers, protocol handlers — report crashes found and fixed), formal-ish verification where feasible (model-check critical state machines), and cost measurement (security overhead in latency/energy/memory — always quantify).
Red-team honestly: hire or role-play an attacker with defined capabilities; report what they achieved. "We could not break X in Y hours with Z capabilities" is a meaningful (if bounded) claim.
Example: A smart-lock evaluation: threat model → firmware extraction (found hardcoded key — fixed) → protocol fuzzing (2 crashes — fixed) → relay-attack test (vulnerable — added distance bounding discussion as limitation). Published with all findings including the unfixed limitation — credibility through honesty.
For your research: Publish negative results and residual risks. Security papers that claim perfect security are not believed; papers with honest limitations are.
Key takeaway: Threat coverage + pentest + fuzzing + measured costs + honest residual risks = convincing security evaluation.
Chapter 11: Standards and Frameworks
Know the landscape: NISTIR 8259 (IoT device cybersecurity baseline), ETSI EN 303 645 (consumer IoT security — now effectively mandatory in the EU/UK), NIST SP 800-213 (federal IoT guidance), OWASP IoT Top 10 (practical checklist), IEC 62443 (industrial). Map your system against one: "compliant with ETSI EN 303 645 provisions 5.1–5.13 except X (justified)" is a strong compliance statement.
Example: A consumer sensor product mapped to ETSI EN 303 645: 12/13 provisions met; the exception (no automatic updates for a battery device with 10-year life) justified with a compensating control (signed manual updates + vulnerability monitoring). The mapping table was an appendix reviewers praised.
For your research: Standards-mapping appendices turn engineering work into auditable contributions.
Key takeaway: Map to NISTIR 8259 / ETSI 303 645; justify every exception.
Chapter 12: Your IoT Security Study — From Audit to Paper
Template:
- Target: Your own system (or authorized) — define scope.
- Threat model: Assets, attackers, STRIDE table.
- Method: Chosen evaluations (pentest, fuzzing, measurements) with methodology.
- Findings: Categorized by severity, each with evidence.
- Fixes: Implemented mitigations with measured costs.
- Residual risks: Honestly stated.
- Standards mapping: Against ETSI/NIST baseline.
- Artifact: Configs, test harnesses (sanitized), measurement data.
- Writing: IEEE format; findings tables with severity; costs quantified.
Ethics/legal: only test authorized systems; disclose vulnerabilities responsibly (vendor notification, coordinated disclosure timelines) before publishing.
For your research: Responsible disclosure + published analysis is the gold standard — it protects users and builds your reputation.
Key takeaway: Scope → threat model → evaluation → findings → fixes → residual risks → disclosure = the security paper pipeline.
Learning Dashboard
| # | Chapter | Core idea | Research use |
|---|---|---|---|
| 1 | Failures | Mirai pattern | Authorized measurement studies |
| 2 | Threat modeling | STRIDE per flow | Expected artifact table |
| 3 | Hardening | Secure boot, unique creds | Firmware-analysis papers |
| 4 | Crypto on MCU | ECC, handshake costs | Suite cost measurements |
| 5 | MQTT/CoAP sec | mTLS, ACLs, payload enc | Layered-design evaluations |
| 6 | OTA | Signed, anti-rollback, A/B | Vendor-mechanism analyses |
| 7 | Fleet PKI | Offline root, provisioning | Experience reports |
| 8 | Privacy | Minimize, localize | Required privacy sections |
| 9 | Segmentation | VLANs, baselines | Detection-rate studies |
| 10 | Evaluation | Pentest, fuzz, honest limits | Convincing security claims |
| 11 | Standards | NISTIR 8259, ETSI 303 645 | Mapping appendices |
| 12 | Study template | Audit → paper pipeline | Disclosure ethics |
References
[1] R. Roman, P. Najera, and J. Lopez, "Securing the Internet of Things," Computer, vol. 44, no. 9, pp. 51–58, 2011. [2] R. Roman, J. Zhou, and J. Lopez, "On the features and challenges of security and privacy in distributed Internet of Things," Computer Networks, vol. 57, no. 10, pp. 2266–2279, 2013. [3] M. Antonakakis et al., "Understanding the Mirai Botnet," in Proc. 26th USENIX Security Symposium, 2017. [4] N. Neshenko, E. Bou-Harb, J. Crichigno, G. Kaddoum, and N. Ghani, "Demystifying IoT Security: An Exhaustive Survey on IoT Vulnerabilities and a First Empirical Look on Internet-Scale IoT Exploitations," IEEE Communications Surveys & Tutorials, vol. 21, no. 3, 2019. [5] ETSI, "ETSI EN 303 645 V2.1.1: Cyber Security for Consumer Internet of Things," 2020. [6] NIST, "NISTIR 8259A: IoT Device Cybersecurity Capability Core Baseline," 2020. [7] A. Banks and R. Gupta, "MQTT Version 3.1.1," OASIS Standard, Oct. 2014. [8] Z. Shelby, K. Hartke, and C. Bormann, "The Constrained Application Protocol (CoAP)," RFC 7252, 2014. [9] G. Selander et al., "Object Security for Constrained RESTful Environments (OSCORE)," RFC 8613, 2019. [10] H. B. McMahan et al., "Communication-Efficient Learning of Deep Networks from Decentralized Data," in Proc. 20th AISTATS, 2017. (for federated privacy context)
Glossary
- Threat model — structured description of assets, attackers, vectors
- STRIDE — Spoofing, Tampering, Repudiation, Info disclosure, DoS, Elevation
- Secure boot — verified firmware startup chain
- mTLS — mutual TLS; both sides authenticate
- ACL — access control list
- HMAC — keyed hash for integrity/authentication
- OTA — over-the-air firmware update
- Anti-rollback — preventing downgrade to vulnerable firmware
- PKI — public key infrastructure
- Secure element — tamper-resistant key storage chip
- VLAN — virtual LAN for network segmentation
Practice Exercises
- Build a STRIDE table for a smart door lock (4 components × 6 threats, with mitigations).
- Why are default passwords a fleet-wide vulnerability? What replaces them?
- Compare RSA-2048 and ECC P-256 for an MCU: which fits and why? What do you measure?
- Design topic ACLs for a 3-tier system (sensors, gateway, dashboard). Show least privilege.
- Explain why TLS alone doesn't protect against a compromised broker. What's the fix?
- List the five OTA requirements and what breaks if each is missing.
- Sketch a fleet PKI: root, intermediate, provisioning, revocation. Where's the HSM?
- Your occupancy study uses cameras. Redesign it for privacy — what changes, what do you lose?
- Write firewall allowlist rules for an IoT VLAN with one MQTT broker.
- Draft the findings table (severity, evidence, fix, residual risk) for an audit of your own project.
End of Book 37. Next: Book 38 — From Prototype to Product: IoT Deployment.