IoT security, privacy and application case studies notes — Unit 5

IoT security is fundamentally harder than standard IT security. A compromised laptop might result in stolen data; a compromised IoT medical implant or autonomous vehicle can result in kinetic damage and loss of life.

⇒1.1 The Mirai Botnet

In 2016, the Mirai botnet infected hundreds of thousands of cheap IoT devices (primarily internet-connected webcams and home routers) that had been shipped with default, unchangeable passwords (like admin/admin). The attackers harnessed these devices to launch massive Distributed Denial of Service (DDoS) attacks, temporarily taking down large sections of the global internet (including Twitter, Netflix, and CNN). This event permanently altered how the industry views IoT security.

Several factors make securing IoT devices exceptionally difficult:

• Computational Constraints: Strong encryption (like RSA) requires significant CPU power and RAM. Many 8-bit microcontrollers cannot physically execute these algorithms without draining their batteries or crashing.
• Physical Access: Unlike a server locked in a secure data center, IoT devices (like smart meters or environmental sensors) are deployed in public spaces. Attackers can physically steal them, extract the flash memory, and reverse-engineer the firmware or extract hardcoded cryptographic keys.
• Longevity and Patching: A smartphone is replaced every 3 years. A smart water meter is expected to sit in a wall for 15 years. Providing Over-The-Air (OTA) security updates for a device that is asleep 99% of the time, over a flaky network connection, is a massive engineering challenge.

Security cannot be an afterthought ('bolt-on security'). It must be engineered into the hardware and software from day one.

⇒3.1 Hardware Root of Trust

Modern IoT devices include a dedicated crypto-chip (like a TPM or Secure Element). This hardware securely generates and stores private keys. The main MCU can ask the crypto-chip to sign a message, but it can never read the private key itself. Even if an attacker steals the device and dumps the MCU memory, the key remains safe.

⇒3.2 Mutual Authentication

It is not enough for the device to trust the cloud server (via standard HTTPS/TLS). The cloud must verify the identity of the device to prevent rogue nodes from injecting fake data. This is achieved using X.509 client certificates burned into the device at the factory.

A Smart Home represents a highly localized, consumer-grade IoT deployment.

⇒4.1 Architecture

Devices (smart bulbs, door locks, thermostats) form a Local Area Network. Because Wi-Fi is too power-hungry for battery-operated locks, they use Zigbee or BLE. These connect to a central Smart Home Hub (the Edge Gateway). The Hub translates Zigbee signals into TCP/IP and communicates with the Cloud.

⇒4.2 Challenges

Interoperability is the main hurdle. Devices from different manufacturers use different proprietary protocols. Emerging standards like 'Matter' (backed by Apple, Google, and Amazon) aim to create a unified application layer so a Google Assistant can natively control an Apple-certified smart lock over a thread network.

A Smart City deployment scales IoT to municipal levels, focusing on efficiency and public safety.

⇒5.1 Architecture

Inductive loops under the asphalt or camera sensors at intersections monitor traffic flow. Because latency is somewhat critical (adjusting light timing to clear a sudden jam), processing is done at Fog nodes located in roadside cabinets. Long-term data (daily traffic patterns) is forwarded to the municipal cloud over high-speed fiber or 5G to train city-wide predictive models.

⇒5.2 Challenges

Privacy is a major concern. Cameras analyzing traffic must perform processing at the Edge to extract metadata (e.g., '10 cars passed') and immediately delete the raw video footage to avoid creating a massive, hackable surveillance state of license plates and pedestrian faces.

Precision agriculture uses IoT to optimize crop yields and reduce water/chemical usage.

⇒6.1 Architecture

Moisture, NPK (Nitrogen, Phosphorus, Potassium), and temperature sensors are deployed across thousands of acres. Because there is no Wi-Fi or cellular coverage in remote fields, these sensors use LoRaWAN to transmit tiny packets of data to a central solar-powered gateway located on a silo. The gateway uses a satellite uplink to send data to the cloud. The cloud platform correlates this sensor data with external weather forecasts to actuate local drone-based irrigation systems.

⇒6.2 Challenges

Extreme power constraints. Sensors must run for 3-5 years on a single battery, buried in soil, surviving extreme temperature variations and physical damage from tractors.

The final unit ties the theory into reality and addresses the most pressing issue in modern IoT deployment.

• The Security Constraints: Be able to articulate exactly why standard IT security (like deploying an antivirus or updating software weekly) fails on an IoT node. Discuss CPU limits, battery limits, and physical access.
• Case Studies: Examiners frequently ask for a complete architectural design for a specific scenario (e.g., 'Design an IoT system for a Smart Hospital'). You must be able to specify the Sensors used, the Communication Protocol (e.g., BLE to a gateway), the Edge processing required, and the Cloud analytics purpose.
• Privacy: Understand the difference between Security (preventing hacking) and Privacy (managing who has legal access to user data generated by sensors).