IOT Lab (CE-705) - Unit 5 Short Notes

5.1 IoT Security & Privacy in Practice

Core Concept: Security must be integrated at device, network, and cloud layers (Defense-in-Depth). IoT expands the attack surface.

5.1.1 Threat Modeling for IoT Systems

• Device Layer: Physical tampering, firmware extraction, side-channel attacks.

• Network Layer: Eavesdropping, message spoofing, DoS attacks on broker/gateway.

• Cloud/Application Layer: API exploitation, data leakage, unauthorized access to device shadows.

• Method: STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) applied to IoT components.

5.1.2 Secure Device Onboarding & Identity

• Goal: Unique, immutable device identity.

• Mechanisms:

  • PKI & Certificates: X.509 certificates for mutual TLS (mTLS) authentication. Certificate Authority (CA) signs device certs.

  • Hardware Roots of Trust: TPM (Trusted Platform Module) or Secure Element (SE) stores private keys securely, prevents extraction.

  • Just-Works vs. Certified Provisioning: Simpler (less secure) vs. certificate-based onboarding.

5.1.3 Implementing Secure Communication

• TLS/DTLS: Provides confidentiality, integrity, authentication.

  • TLS: For TCP-based protocols (HTTPS, MQTT over TLS).

  • DTLS: For UDP-based protocols (CoAP). Handles packet loss/reordering.

• MQTT over TLS (MQTTS): Standard port 8883. Broker and client certificates validate each other.

• Challenge: Constrained devices have limited CPU/RAM for full TLS handshake. Use pre-shared keys (PSK) or lightweight cipher suites.

5.1.4 Data Privacy & Anonymization

• Techniques:

  • Aggregation: Send aggregated data (e.g., hourly average) instead of raw streams.

  • Generalization: Replace precise GPS coordinates with region/location type.

  • Pseudonymization: Replace device ID with a rotating session identifier.

  • Differential Privacy: Add statistical noise to datasets before analysis to prevent re-identification.

5.1.5 Lab: Securing MQTT Broker & Client Auth

• Steps:

  1. Generate CA, broker certificate, and client certificate (using openssl).

  2. Configure MQTT broker (e.g., Mosquitto) to require client certificates (require_certificate true).

  3. Configure client (ESP32/Arduino) with client certificate & key. Connect using mqtts://.

  4. Test: Unauthorized client (without cert) must fail connection.

5.2 Cloud IoT Platforms & Serverless Integration

Core Concept: Cloud platforms provide scalable device management, data ingestion, and serverless compute to build IoT applications without managing servers.

5.2.1 Comparative Study: Major Platforms

5.2.2 Device Shadow / Digital Twin Concepts

• Definition: A JSON document in the cloud that stores the desired and reported state of a device, even when the device is offline.

• Components:

  • desired: App wants device to be (e.g., {"led": "ON"}).

  • reported: Device's actual state (e.g., {"led": "ON", "temp": 25.5}).

  • delta: Difference between desired and reported, sent to device to sync.

• Use Case: Set device state reliably despite network interruptions.

5.2.3 Rules Engine & Data Routing

• Function: Acts as a serverless message broker. Ingests device data (MQTT topic) and routes it to cloud services based on SQL-like rules.

• Example Rule (AWS):

  
  SELECT * FROM 'sensors/temperature'
  
  WHERE temperature > 30
  
  

  Action: INSERT INTO a Lambda function, an S3 bucket, or a DynamoDB table.

5.2.4 Serverless Backend Architecture

• Flow: Device -> IoT Hub/Core -> Rules Engine -> Trigger -> Serverless Function (Lambda/Azure Function) -> Database/Notification.

• Benefit: Auto-scaling, pay-per-execution, no infrastructure management.

5.2.5 Lab: End-to-End Data Pipeline

1. Device: ESP32 publishes {"temp": 28.5} to MQTT topic lab/sensor1.

2. Cloud: AWS IoT Core rule on topic lab/sensor1 triggers a Lambda function.

3. Function: Python code parses JSON, checks threshold, writes to DynamoDB table.

4. Verify: Check DynamoDB table for new item.

5.3 Edge Computing & Fog Node Implementation

Core Concept: Move computation and data storage closer to the data source (the "edge") to reduce latency, bandwidth use, and enhance privacy.

5.3.1 Edge vs. Cloud Trade-offs

5.3.2 Edge Frameworks

• AWS Greengrass: Deploy Lambda functions (Python, Node.js, Java) or containers to edge devices (Raspberry Pi). Uses local MQTT broker.

• Azure IoT Edge: Deploy IoT Edge modules (Docker containers) to devices. Modules can be Azure services (Stream Analytics, Functions) or custom code.

• EdgeX Foundry: Hardware-agnostic, vendor-neutral platform. Provides microservices for device services, data, security.

5.3.3 Deploying & Managing Functions/Containers

• Process:

  1. Build function/container image locally.

  2. Push to cloud registry (ECR, ACR, GCR).

  3. Deploy from cloud console/CLI to target edge device group.

  4. Edge runtime (Greengrass Core, IoT Edge Agent) pulls and runs the module.

• Management: Update deployment group; changes propagate to all edge devices.

5.3.4 Local Data Filtering & Pre-processing

• Examples:

  • Filter: Only send data if value changes by >5%.

  • Aggregate: Compute 1-minute average, send average.

  • Transform: Convert raw ADC value to calibrated temperature.

  • Inference: Run a TinyML model (e.g., TensorFlow Lite) on-device to detect anomalies; only send alerts.

5.3.5 Lab: Deploy ML Inference on Raspberry Pi

1. Train a simple model (e.g., sklearn for vibration anomaly detection).

2. Convert to TensorFlow Lite (.tflite) format.

3. Write Python script using tflite_runtime to run inference on Pi.

4. Package script as a Docker container or AWS Greengrass Lambda component.

5. Deploy to Pi. Publish inference result ("normal"/"anomaly") to local MQTT topic.

5.4 Data Analytics & Visualization for IoT

Core Concept: Handle high-volume, time-stamped sensor data efficiently and present insights.

5.4.1 Time-Series Databases (TSDB)

• Why TSDB? Optimized for time-indexed data: fast writes, time-range queries, compression, downsampling.

• Options:

  • InfluxDB: Purpose-built TSDB. Uses "measurements", "tags" (indexed), "fields" (values). Query language: Flux or InfluxQL.

  • TimescaleDB: PostgreSQL extension. Uses standard SQL with time-series optimizations. Easier if already know SQL.

  • AWS Timestream: Serverless, fully managed. Separates hot (memory) and cold (SSD) storage.

5.4.2 Stream Processing Concepts

• Windowed Aggregations: Compute metrics over sliding/tumbling time windows (e.g., 5-min avg temperature).

  
  -- Example (TimescaleDB/PostgreSQL)
  
  SELECT time_bucket('5 minutes', timestamp) AS bucket,
  
         AVG(temperature)
  
  FROM sensor_readings
  
  GROUP BY bucket;
  
  

• Anomaly Detection: Simple: threshold-based. Advanced: statistical (Z-score), ML-based (Isolation Forest) on streaming data.

5.4.3 Dashboarding Tools

• Grafana: Industry standard for TSDB visualization. Connects to InfluxDB, Prometheus, TimescaleDB, etc. Rich panel library, alerting.

• AWS QuickSight: ML-powered BI service. Connects to many AWS sources (Timestream, S3). Serverless.

• Node-RED Dashboard: Simple UI for Node-RED flows. Good for quick prototyping.

5.4.4 Basic Predictive Analytics

• Linear Regression: Fit line y = mx + c to sensor trend (e.g., temperature rising over time). Predict future value.

• Tooling: Use scikit-learn in a serverless function (Lambda) that runs periodically on historical data from TSDB.

5.4.5 Lab: Real-Time Monitoring Dashboard

1. Pipeline: Device -> AWS IoT Core -> Rule -> InfluxDB (on EC2 or managed).

2. Dashboard: Install Grafana. Add InfluxDB as data source.

3. Create Panels:

   • Time Series Graph: Plot temperature vs time.

   • Stat Panel: Show current humidity.

   • Alert: Set threshold (e.g., temp > 40°C) -> send notification.

5.5 Advanced IoT Application Domains (Case Study Labs)

5.5.1 Smart Agriculture

• Sensors: Soil moisture sensor, DHT22 (temp/humidity), rain sensor.

• Cloud Logic: Compare soil moisture with threshold. Fetch weather API (OpenWeatherMap) for rain forecast.

• Control: If moisture < threshold AND forecast != "rain" -> Activate water pump via relay for N seconds.

• Key Integration: External API call from cloud function + device control via desired shadow.

5.5.2 Industrial IoT (IIoT): Predictive Maintenance

• Sensor: Vibration sensor (ADXL345) on motor.

• Data: Sample vibration magnitude at high frequency (e.g., 100Hz).

• Edge Processing: On Raspberry Pi, compute RMS (Root Mean Square) of vibration over 1-second windows.

• Cloud Analytics: Stream RMS values to cloud. Use simple threshold or trend analysis (increasing RMS = bearing wear). Trigger maintenance alert.

5.5.3 Smart Home Automation (Complex Rules)

• Sensors: PIR motion, light sensor, temperature sensor, door contact.

• Context-Aware Rule:

  IF (motion == detected) AND (light_level < 50 lux) AND (time between 6PM-6AM) THEN turn_on(light, 5_min).

• Implementation: Use Node-RED or AWS IoT Rules Engine with multiple topic subscriptions and stateful logic (context).

5.5.4 Asset Tracking with Geofencing

• Hardware: GPS module (NEO-6M) + GSM module (SIM800L) on device.

• Flow: Device reads GPS -> Publishes {lat, lon, device_id} to MQTT.

• Cloud Logic: Cloud function receives location. Checks if point is inside predefined geofence (polygon). If outside, triggers SMS/email alert via Twilio/SNS.

• Geofence Check: Ray-casting algorithm or use geospatial library (e.g., shapely in Python).

5.6 IoT Project Management & Prototyping

5.6.1 System Architecture Diagrams

• Layered Diagram: Device Layer -> Gateway/Edge Layer -> Cloud Platform -> Application Layer.

• Data Flow Diagram: Shows movement of data (sensor -> MQTT -> Rules -> DB -> Dashboard) and control flow (app -> Cloud -> Device Shadow -> Device).

5.6.2 Bill of Materials (BOM) & Component Selection

• BOM Table: Item | Part Number | Quantity | Supplier | Cost.

• Selection Criteria:

  • Power: Battery vs. mains? Current draw.

  • Connectivity: WiFi, BLE, Cellular (NB-IoT, 4G), LoRaWAN? Coverage needed.

  • Environment: IP rating, temperature range.

  • Cost vs. Performance: MCU (ESP32 vs. STM32), sensor accuracy.

5.6.3 Prototyping vs. Production (DFM)

• Prototype: Breadboard, off-the-shelf modules (NodeMCU, sensor shields). Fast, flexible, expensive per unit.

• Production: Custom PCB design. Component sourcing (preferred distributors), footprint standardization. Consider assembly (through-hole vs. SMD), testing (JTAG, boundary scan).

• Key DFM: Minimize part count, use standard component sizes, avoid hand-soldering.

5.6.4 Documentation & Version Control

• Hardware: Schematic (KiCad/Eagle), PCB layout, BOM. Store in Git (use git-lfs for large files).

• Firmware: Code (PlatformIO/Arduino IDE). Use semantic versioning (v1.0.0).

• Cloud: Infrastructure-as-Code (IaC). Use AWS CloudFormation or Terraform to define IoT resources (things, policies, rules). This is version-controlled, repeatable deployment.

• Project Docs: README with setup, architecture diagram, API specs.

5.7 Future Trends & Ethics

5.7.1 IoT & AI/ML: TinyML

• Concept: Run ML models directly on microcontrollers ( Cortex-M, ESP32).

• Tools: TensorFlow Lite for Microcontrollers (TFLite Micro), PyTorch Mobile.

• Use Cases: Keyword spotting, sensor-based anomaly detection, predictive maintenance on edge.

• Benefit: Zero latency, privacy, no bandwidth cost.

5.7.2 IoT in 5G/6G Networks

• 5G Features for IoT:

  • URLLC (Ultra-Reliable Low-Latency Comm): For autonomous vehicles, robotics.

  • mMTC (Massive Machine-Type Comm): For massive sensor deployments (1M devices/km²).

  • Network Slicing: Create virtual, isolated networks with different QoS for different IoT applications on same physical infrastructure.

5.7.3 Sustainability & Green IoT

• Energy Harvesting: Power devices from ambient sources (solar, vibration, RF, thermal).

• Low-Power Design: Deep sleep modes, low-power MCUs (ARM Cortex-M0+), efficient protocols (BLE 5, LoRa).

• Circular Economy: Design for disassembly, use recycled materials, take-back programs.

5.7.4 Ethical Implications

• Surveillance: Pervasive sensing in public/private spaces. Need for data minimization.

• Data Ownership: Who owns data from a smart fridge? User? Manufacturer?

• Algorithmic Bias: If an IoT health device is trained on non-diverse data, it may perform poorly for certain groups.

• Right to Repair: Proprietary firmware/hardware preventing users from fixing their own devices.

Exam Tip: For Unit 5, expect scenario-based questions requiring you to choose the right cloud service, design a secure architecture, or select an edge vs. cloud processing strategy. Be prepared to draw simple architecture diagrams for a given application (e.g., smart agriculture). Security and trade-offs (edge/cloud) are highly likely topics.