Unit 4: IoT Protocols and Security

I. Orientation

The Internet of Things (IoT) connects physical objects, sensors, actuators, gateways, networks, cloud platforms, and users so that data can be sensed, exchanged, analyzed, and acted upon. IoT networking protocols provide the rules for this cooperation, while security mechanisms protect devices, data, identities, and physical processes.

• Interoperability: Devices from different manufacturers must exchange data using agreed formats and communication rules.
• Layered communication: IoT commonly uses sensing, link, network, transport, application, and security functions rather than one universal protocol.
• Resource constraints: Many devices have limited battery power, memory, processing capacity, and bandwidth.
• Machine-to-machine operation: Devices often communicate automatically without continuous human intervention.
• Security by design: Authentication, authorization, confidentiality, integrity, availability, and privacy must be considered throughout the system.
• Physical consequences: A network command may change a valve, motor, medical device, vehicle, or industrial process.

II. Requirement of protocols — Rules for reliable IoT communication

A protocol is a defined set of rules governing how data is formatted, transmitted, received, interpreted, and protected. IoT needs protocols because heterogeneous devices cannot communicate reliably through electrical or application assumptions alone.

A. Requirement of protocols

Protocols establish common behavior between devices, gateways, servers, and applications.

• Addressing: Each endpoint requires an identifier, such as an IPv6 address, MAC address, device ID, or application-level topic.
• Data representation: A temperature reading must include an agreed value and unit, such as 24.5 °C; formats may include JSON, CBOR, XML, or binary fields.
• Timing and sequencing: Sequence numbers, timestamps, and acknowledgements help detect lost, duplicated, or delayed messages.
• Error control: Checksums detect corruption, while retransmission or forward-error correction handles unreliable links.
• Flow control: A gateway can regulate transmission when a sensor sends faster than the cloud service can process.
• Interoperability: Standard protocols such as IPv6, TCP, UDP, HTTP, CoAP, MQTT, and Bluetooth Low Energy allow devices to work across vendors.
• Efficiency: CoAP over UDP can reduce overhead compared with HTTP over TCP, which matters for a battery-powered sensor.
• Security negotiation: Protocols can define authentication and encryption, such as TLS for TCP-based communication or DTLS for UDP-based communication.

B. Types of protocols

IoT protocols can be classified according to the layer or function they provide.

• Physical and data-link protocols: IEEE 802.15.4, Wi-Fi, Ethernet, Bluetooth Low Energy, Zigbee, and LoRaWAN define local transmission, framing, channel access, or low-power connectivity.
• Network protocols: IPv6 provides addressing and routing; 6LoWPAN compresses IPv6 headers so IPv6 packets can travel through low-power IEEE 802.15.4 networks.
• Transport protocols: TCP provides reliable, ordered byte streams; UDP provides lightweight datagrams without built-in delivery guarantees.
• Application protocols: MQTT uses publish/subscribe messaging; CoAP supports REST-like operations such as GET, POST, PUT, and DELETE; HTTP supports web-based request/response communication.
• Service-discovery protocols: mDNS, DNS-SD, and application registries help devices locate services such as a lighting controller or temperature feed.
• Security protocols: TLS, DTLS, IPsec, OSCORE, and IEEE 802.1X protect communication, depending on the layer and device capability.
• Selection principle: Protocol choice depends on range, data rate, latency, power budget, topology, reliability, and security requirements.

III. Cyber-physical systems — Computing connected to physical processes

A cyber-physical system (CPS) integrates computation, communication, sensing, and control with a physical environment. IoT is often the networking and data-collection foundation of a CPS, but CPS emphasizes feedback and physical consequences.

A. Cyber-physical systems

A CPS repeatedly observes a physical process, computes a decision, and applies an action through an actuator.

• Sensing: Sensors measure physical variables such as pressure, speed, vibration, temperature, or blood oxygen.
• Computation: An embedded controller or cloud service filters measurements and calculates a response.
• Communication: Networks carry sensor readings and control commands between the device, gateway, and controller.
• Actuation: An actuator changes the environment, for example by opening a valve or adjusting motor speed.
• Feedback loop: The basic sequence is:

physical process -> sensor -> controller -> actuator -> physical process

• Timing requirement: A vehicle braking controller may require millisecond-level response, whereas agricultural soil monitoring may tolerate minutes of delay.
• Safety requirement: A lost command to an industrial actuator should result in a defined fail-safe state rather than uncontrolled operation.
• Example: In a smart greenhouse, a humidity sensor reports 80%, the controller compares it with a 60% threshold, and a fan is activated until humidity falls.

IV. The role of authorization — Controlling permitted actions

Authorization determines what an authenticated identity is allowed to do. Authentication answers “Who are you?”; authorization answers “What may you access or control?” In IoT, authorization must cover devices, users, applications, services, and physical actions.

A. The role of authorization

Authorization limits operations according to identity, resource, action, context, and policy.

• Least privilege: A temperature sensor should publish readings but normally should not unlock a door or reconfigure a gateway.
• Access-control model: A policy can be expressed as:

Subject: maintenance-app
Resource: pump-07
Action: start
Condition: authenticated technician and approved time window
Decision: allow

• Role-based access control: Permissions are assigned to roles such as operator, technician, administrator, or guest.
• Attribute-based access control: Decisions use attributes including device type, location, time, network status, and emergency state.
• Capability-based control: A signed token can grant one narrowly defined operation, such as “open valve 3 for 10 seconds.”
• Command authorization: Reading a sensor and controlling an actuator should not automatically carry the same permission level.
• Delegation: A cloud service may be authorized to request data from a gateway without receiving unrestricted administrative access.
• Policy enforcement points: Gateways, brokers, APIs, and device firmware can enforce authorization before forwarding or executing a request.
• Revocation: A compromised device certificate, token, or employee account must be disabled promptly.
• Auditability: Logs should record subject, resource, action, timestamp, decision, and reason, such as technician-12 -> valve-3 -> close -> 14:32 -> allow.

V. Network broker communication — Coordinating distributed messaging

A network broker is an intermediary that receives messages from producers and delivers them to interested consumers. Broker-based communication separates devices from one another and is central to publish/subscribe IoT systems.

A. Network broker communication

Broker communication allows devices to exchange data without knowing the network address or implementation details of every recipient.

• Publisher: A device sends a message, such as a reading on factory/line1/temperature.
• Subscriber: An application registers interest in one or more topics and receives matching messages.
• Broker: The intermediary authenticates clients, receives publications, applies policies, and routes messages.
• Topic hierarchy: A topic such as building/2/floor/1/room/8/co2 organizes readings and supports selective subscriptions.
• Decoupling: Publishers and subscribers may operate independently; a sensor does not need to know whether one dashboard or fifty applications consume its data.
• Quality of Service: MQTT commonly defines QoS 0, 1, and 2:
  • QoS 0: At most once; fastest, but messages may be lost.
  • QoS 1: At least once; delivery is acknowledged, but duplicates are possible.
  • QoS 2: Exactly once; strongest delivery guarantee with greater overhead.
• Session handling: Persistent sessions, retained messages, and last-will messages help applications detect device disconnection or obtain the latest state.
• Security boundary: The broker should use TLS, client authentication, topic-level authorization, rate limits, and validation of message size and format.
• Failure consideration: A centralized broker can become a bottleneck or single point of failure, so clustering, replication, or local edge brokers may be required.

VI. Privacy issues in the Internet of Things — Protecting people and behavior

IoT privacy concerns arise because devices continuously collect information about people, locations, homes, workplaces, health, and routines. Even data that appears harmless can reveal sensitive behavior when combined over time.

A. Privacy issues in the Internet of Things

Privacy protection requires controlling collection, inference, use, sharing, retention, and deletion of IoT data.

• Continuous observation: A smart meter can reveal occupancy patterns through electricity readings sampled at regular intervals.
• Sensitive inference: A fitness tracker may disclose sleep habits, illness, exercise routines, or a person’s location even when those fields are not explicitly collected.
• Data minimization: Collect only what is necessary; a door sensor may need an open/closed state rather than a continuously recorded camera stream.
• Purpose limitation: Data collected for temperature control should not silently be reused for employee monitoring or targeted advertising.
• Consent and transparency: Users should understand what is collected, why it is collected, who receives it, and how long it is retained.
• Secure storage and transfer: Encryption in transit and at rest reduces exposure, while access logs reveal improper use.
• Identity protection: Pseudonymous device identifiers can reduce direct linkage to a person, but repeated location or timing patterns may still permit re-identification.
• Edge processing: Computing an occupancy result locally and sending only occupied = true reduces exposure of raw sensor data.
• Lifecycle risk: Forgotten devices, default passwords, unsupported firmware, and discarded storage media can expose historical data.
• Privacy-preserving analysis: Aggregation, noise addition, and differential privacy can reduce the disclosure of individual records while retaining useful statistics.

VII. Internet of Things-OAS application scenarios — Applying protocols to complete systems

IoT-OAS application scenarios can be understood as deployments in which connected objects provide data and services through an organized application architecture. Each scenario must connect sensing, communication, authorization, processing, and action.

A. Internet of Things-OAS application scenarios

Application scenarios show how protocol and security choices change according to physical context, data sensitivity, and response time.

• Smart home: Door sensors, thermostats, lights, and cameras communicate through Wi-Fi, Thread, Zigbee, BLE, MQTT, or Matter-related application models.
  • Security focus: A resident may read energy data, while only an authorized owner can unlock a door; local control should remain available if cloud connectivity fails.
• Healthcare monitoring: Wearable sensors send heart rate, glucose, or oxygen measurements to a phone, gateway, and clinical platform.
  • Security focus: Strong identity, encrypted transport, consent, audit logs, and strict authorization are required because health data is highly sensitive.
• Industrial automation: Vibration sensors, programmable controllers, motors, and safety systems exchange data across edge networks and brokers.
  • Security focus: Deterministic timing, network segmentation, command authorization, signed firmware, and fail-safe behavior are more important than merely maximizing throughput.
• Smart agriculture: Soil moisture, weather, irrigation valves, and farm dashboards form a distributed sensing and actuation system.
  • Protocol choice: Low-power wide-area communication is useful for remote sensors sending small readings over long distances; delayed delivery may be acceptable.
• Smart city: Parking sensors, traffic signals, environmental monitors, and public-service platforms share data across administrative boundaries.
  • Security focus: Broker policies must prevent one department or application from accessing unrelated citizens’ data or issuing unauthorized control commands.
• Connected transport: Vehicles and roadside units exchange position, warning, and traffic information.
  • Protocol choice: Low latency and availability may be prioritized over high data volume; messages require authentication because false warnings can create physical danger.
• Common architecture: A typical scenario contains:

sensor/actuator -> local network -> gateway or edge node
                -> broker/API -> analytics and user application

• Evaluation criteria: A sound IoT-OAS deployment is judged by interoperability, latency, energy consumption, scalability, resilience, authorization correctness, privacy protection, and safe physical behavior.
• Central principle: The protocol stack must match the application’s consequences: a lost room-temperature update is inconvenient, while an unauthorized industrial shutdown or medical command can be dangerous.