Unit 4: IoT Protocols and Security - Subjective Questions

Communication protocols are essential in IoT because they provide rules for exchanging data between heterogeneous devices, networks, and applications. Their major requirements include:

• Interoperability: Devices from different manufacturers must communicate correctly.
• Resource efficiency: Many IoT devices have limited processing power, memory, storage, and battery capacity.
• Scalability: The protocol should support a small deployment as well as millions of connected devices.
• Reliability: Data should be delivered accurately, even when networks are unstable.
• Low latency: Applications such as industrial automation and healthcare may require rapid communication.
• Security: Protocols must support authentication, authorization, confidentiality, and integrity.
• Energy efficiency: Communication should minimize transmissions and reduce battery consumption.
• Quality of service: The protocol should handle different priorities, bandwidth requirements, and delivery guarantees.

Thus, IoT protocols enable efficient, secure, and standardized communication among constrained devices and cloud services.

An effective IoT networking protocol should possess the following characteristics:

• Lightweight operation: It should require minimal memory, computation, and control overhead.
• Support for constrained networks: It should work with low bandwidth, unreliable links, and devices with limited energy.
• Addressing capability: Every device should be uniquely identifiable within the network.
• Interoperability: It should support communication across different platforms and vendors.
• Scalability: The protocol must continue to work efficiently as the number of devices increases.
• Security mechanisms: It should protect data and devices using encryption, authentication, and access control.
• Flexible communication models: It may support device-to-device, device-to-cloud, publish-subscribe, or request-response communication.
• Reliability and fault tolerance: It should provide mechanisms for retransmission, error handling, and recovery.
• Low power consumption: Communication operations should be optimized to extend battery life.

These characteristics make a protocol suitable for diverse IoT applications and operating environments.

IoT protocols can be classified according to the communication layer or purpose they serve:

• Physical and data-link protocols: These provide local wireless or wired connectivity. Examples include Bluetooth Low Energy, Zigbee, Z-Wave, Wi-Fi, LoRaWAN, and IEEE 802.15.4.
• Network and adaptation protocols: These provide addressing and routing. Examples include IPv6, 6LoWPAN, RPL, and IPv4.
• Transport protocols: These provide end-to-end data delivery. TCP offers reliable connection-oriented communication, while UDP provides lightweight connectionless communication.
• Application-layer protocols: These define how application data is exchanged. Examples include MQTT, CoAP, HTTP, AMQP, and DDS.
• Security protocols: These protect communication and identity. Examples include TLS, DTLS, IPsec, OAuth, and certificate-based authentication.

The protocol selected depends on factors such as range, bandwidth, energy consumption, latency, reliability, security, and application requirements.

MQTT is appropriate when many devices publish data to subscribers through a broker. CoAP is designed for constrained devices and supports REST-like operations with small messages. HTTP provides broad web compatibility but normally involves greater overhead. The choice depends on the application architecture, network conditions, and device limitations.

TCP and UDP are transport-layer protocols with different operating characteristics.

• TCP: It is connection-oriented and establishes a session before transferring data. It provides sequencing, acknowledgements, retransmission, congestion control, and reliable delivery. However, these features create additional overhead and may increase energy consumption and latency.
• UDP: It is connectionless and sends datagrams without establishing a session. It has a smaller header, lower latency, and lower processing overhead, but it does not inherently guarantee delivery, ordering, or duplicate prevention.

UDP is often more suitable for constrained IoT applications because IoT devices may have limited memory, battery capacity, and bandwidth. Protocols such as CoAP use UDP and add only the reliability features required by the application. However, TCP remains appropriate for applications requiring reliable delivery, such as MQTT communication with a broker or large data transfers.

A cyber-physical system, or CPS, integrates computational elements with physical processes. Sensors observe the physical environment, software processes the collected information, and actuators influence the physical environment.

The main components are:

• Physical process: The real-world system being monitored or controlled.
• Sensors: Devices that measure temperature, pressure, motion, location, or other conditions.
• Embedded computing: Hardware and software that process sensor data.
• Communication network: A wired or wireless system that transfers data.
• Analytics or control system: Logic that interprets data and makes decisions.
• Actuators: Devices that perform actions such as switching, moving, heating, or cooling.
• Human or cloud interface: A system for monitoring, configuration, and long-term analysis.

For example, in a smart irrigation system, soil-moisture sensors send readings to a controller. The controller compares the readings with a required moisture level and activates a water pump when the soil is too dry. Feedback from the sensors enables continuous and automatic control.

A cyber-physical IoT system commonly operates through a feedback loop:

1. Sensing: Sensors measure the state of a physical process.
2. Data transmission: The measurements are sent through a communication network.
3. Processing: An embedded controller, edge platform, or cloud service analyzes the data.
4. Decision-making: Control logic determines the required action.
5. Actuation: An actuator changes the physical process.
6. Feedback: Sensors measure the new state and send updated information.

Communication delay affects the quality and safety of this loop. Excessive delay can cause:

• Slow response to changing physical conditions.
• Incorrect decisions based on outdated sensor data.
• Oscillation or instability in control systems.
• Missed safety events in industrial or medical applications.
• Reduced efficiency because actions occur later than required.

To reduce these effects, designers may use edge computing, priority-based traffic, local fallback control, time synchronization, and protocols that provide suitable latency and reliability.

Authentication verifies the identity of an entity, while authorization determines what an authenticated entity is allowed to do.

For example, a smart-meter device may authenticate itself using a digital certificate. After successful authentication, an authorization policy may permit it to upload meter readings but prevent it from changing firmware or accessing another customer account.

Both functions are necessary. Authentication without authorization may allow a valid device excessive privileges, while authorization without reliable authentication cannot correctly identify the requester.

Authorization limits the actions that users, devices, applications, and services can perform after their identities have been verified. Its role includes:

• Protecting device functions: It can prevent ordinary users from changing firmware, disabling security, or modifying control settings.
• Restricting data access: It ensures that users access only the sensor data relevant to their responsibilities.
• Enforcing least privilege: Each entity receives only the permissions required for its task.
• Supporting isolation: Devices, tenants, and applications can be separated from one another.
• Controlling commands: Safety-critical commands can require stronger roles or multiple approvals.
• Supporting accountability: Authorization decisions can be logged for auditing.
• Handling changing conditions: Permissions can be revoked when a device is compromised or a user leaves an organization.

Common implementation methods include role-based access control, attribute-based access control, capability tokens, access-control lists, and policy engines. Effective authorization reduces the impact of compromised accounts and devices.

Least privilege means granting an entity only the minimum permissions required to complete its legitimate task, for the shortest practical period.

In an IoT network, this principle can be applied by:

• Allowing a temperature sensor to publish readings but not issue actuator commands.
• Allowing a gateway to forward data without permitting unrestricted administrative access.
• Separating permissions for monitoring, configuration, maintenance, and firmware updates.
• Restricting a device to specific topics, endpoints, or resources.
• Using short-lived tokens and regularly reviewing permissions.
• Requiring stronger authorization for safety-critical operations.
• Isolating devices through network segmentation and separate security policies.

Least privilege limits the damage caused by stolen credentials, vulnerable firmware, or compromised devices. It should be combined with authentication, encryption, logging, and continuous monitoring.

In broker-based communication, devices do not communicate directly with every other device. Instead, they connect to a central or distributed broker that receives, filters, and forwards messages.

The MQTT publish-subscribe process works as follows:

• A device establishes a connection with the broker.
• A publisher sends a message to a named topic, such as building/room1/temperature.
• A subscriber registers interest in one or more topics.
• The broker forwards messages to all authorized subscribers of the relevant topic.
• The broker may manage quality of service, retained messages, session state, and access permissions.

This model provides loose coupling, because publishers do not need to know subscriber identities or locations. It also supports scalability, asynchronous communication, and efficient one-to-many delivery. However, the broker becomes a critical component and must be secured, monitored, and made fault tolerant.

Advantages of broker-based communication include:

• Loose coupling: Publishers and subscribers can operate independently.
• Scalability: One message can be distributed to many subscribers efficiently.
• Simplified device design: Devices do not need to maintain connections with every peer.
• Asynchronous operation: Publishers can send data without waiting for an immediate response.
• Centralized management: Authentication, authorization, logging, filtering, and routing can be managed at the broker.
• Protocol translation: A broker or gateway can connect devices using different protocols.

Limitations include:

• Single point of failure: A failed broker may interrupt communication.
• Bottleneck risk: High message volumes can overload the broker.
• Security concentration: A compromised broker may expose large amounts of data.
• Additional latency: Messages may take longer because they pass through an intermediary.
• Operational cost: Brokers require deployment, monitoring, scaling, and maintenance.

Redundant brokers, clustering, access policies, encryption, and local fallback mechanisms can reduce these limitations.

MQTT defines three quality-of-service levels that control message delivery reliability:

• QoS 0: At most once: The message is delivered without acknowledgement. It has the lowest overhead and is suitable when occasional data loss is acceptable.
• QoS 1: At least once: The receiver acknowledges the message, and the sender retransmits if necessary. Delivery is ensured, but duplicate messages may occur.
• QoS 2: Exactly once: A multi-step handshake prevents duplicate delivery. It provides the highest assurance but requires more packets, processing, storage, and energy.

The correct level depends on application requirements. Periodic environmental readings may use QoS 0, while important alerts may use QoS 1. Financial, safety, or command operations may require QoS 2, although application-level idempotence and duplicate handling should still be considered.

IoT devices continuously collect information about people, locations, behavior, health, homes, and workplaces. Major privacy issues include:

• Excessive data collection: Devices may collect more information than necessary for the stated purpose.
• Lack of informed consent: Users may not understand what is collected, why it is collected, or with whom it is shared.
• Continuous monitoring: Always-on sensors can reveal routines, movements, relationships, and private activities.
• Unauthorized access: Weak passwords or insecure interfaces can expose personal data.
• Secondary use: Data collected for one purpose may later be used for advertising, profiling, or surveillance.
• Insecure data storage: Cloud databases and backups may be breached.
• Third-party sharing: Manufacturers, service providers, and analytics companies may exchange user data.
• Poor data deletion: Data may remain available after a user requests removal.
• Re-identification: Anonymous datasets may be combined with other information to identify individuals.

Privacy protection requires data minimization, transparency, consent, encryption, access control, retention limits, and strong governance.

Three important privacy-preserving practices are:

• Data minimization: Collect only the data necessary for a clearly defined purpose. For example, a lighting system may need motion detection but not a continuous audio recording.
• Anonymization: Remove or transform identifying information so that individuals cannot reasonably be identified. Because datasets can sometimes be combined to re-identify users, anonymization must be evaluated carefully.
• User consent: Inform users about the data collected, its purpose, storage period, and recipients. Consent should be specific, understandable, voluntary, and capable of being withdrawn where appropriate.

These practices should be supported by:

• Purpose limitation and restricted secondary use.
• Encryption during transmission and storage.
• Configurable privacy settings.
• Access and correction mechanisms.
• Defined retention and deletion policies.
• Audits and compliance monitoring.

Together, they reduce exposure and give users greater control over their personal information.

IoT protocols and networks may face several security threats:

• Eavesdropping: Attackers capture unencrypted messages and obtain sensitive information.
• Message modification: Data is changed while in transit, affecting decisions or records.
• Replay attacks: Previously valid messages are captured and transmitted again to trigger unauthorized actions.
• Device impersonation: An attacker pretends to be a trusted device or user.
• Denial of service: Network resources or device functions are overwhelmed, preventing legitimate operation.
• Man-in-the-middle attacks: An attacker intercepts and potentially alters communication between two parties.
• Unauthorized access: Weak credentials or insecure interfaces allow attackers to control devices.
• Malware and botnets: Compromised devices may be used to attack other systems.
• Firmware attacks: Malicious or altered firmware can establish persistent control.
• Broker compromise: An attacker controlling a broker can observe, suppress, or inject messages.

Countermeasures include secure boot, timely updates, strong authentication, encryption, authorization, network segmentation, monitoring, and secure protocol configuration.

IoT security relies on three related protections:

• Confidentiality through encryption: Encryption converts readable data into ciphertext so that unauthorized parties cannot understand it. TLS is commonly used with TCP, while DTLS provides similar protection for UDP-based communication.
• Integrity protection: Message authentication codes, authenticated encryption, and digital signatures help detect whether data has been changed or forged.
• Authentication: Certificates, pre-shared keys, or secure device credentials verify the identity of communicating entities.
• Key management: Keys must be generated securely, distributed safely, stored in protected hardware or memory, rotated when necessary, and revoked when compromised.
• Replay protection: Nonces, sequence numbers, timestamps, or session identifiers prevent old messages from being accepted as new commands.

Security mechanisms must be designed for constrained devices. Excessive computational or communication overhead can reduce battery life, so lightweight authenticated encryption and efficient credential management are often appropriate.

The appropriate model depends on latency, connectivity, energy, privacy, processing, and reliability requirements. Critical control functions are often kept locally, while long-term analytics and fleet management may use cloud services.

IoT-OAS can be understood as an IoT-oriented application and services context in which connected objects collect data, communicate through networks, and provide automated or monitored services. Representative scenarios include:

• Smart homes: Sensors and appliances exchange data for lighting, energy, security, and comfort. Privacy and authorization are essential because the system observes household behavior.
• Smart healthcare: Wearable and medical devices transmit patient data. Confidentiality, integrity, availability, and strict access control are critical.
• Smart agriculture: Soil, weather, and crop sensors communicate with irrigation and control systems. Low-power protocols and reliable operation are important.
• Industrial IoT: Machines and controllers exchange status and control messages. Low latency, deterministic behavior, safety, and network segmentation are required.
• Smart cities: Traffic, parking, waste, and environmental sensors share data across large deployments. Scalability and secure broker communication are significant.
• Connected transportation: Vehicles and infrastructure exchange time-sensitive information. Authentication, integrity, and resilience against disruption are necessary.

Each scenario requires a protocol architecture tailored to its data rate, range, latency, energy, privacy, and security needs.

A secure smart-building architecture may contain the following layers:

• Sensor and actuator layer: Use low-power technologies such as IEEE 802.15.4, Zigbee, or Bluetooth Low Energy for room sensors and control devices.
• Network layer: Use IPv6 with 6LoWPAN where IP connectivity is required. RPL can support routing in low-power and lossy networks.
• Gateway layer: Deploy a gateway to aggregate data, translate protocols, perform local filtering, and continue basic control during Internet outages.
• Application layer: Use MQTT for event and telemetry distribution through a broker, or CoAP for constrained request-response interactions.
• Cloud and management layer: Provide dashboards, analytics, device inventory, and secure firmware management.
• Security layer: Use device identity credentials, mutual authentication, TLS or DTLS, authorization policies, topic restrictions, secure boot, signed updates, and audit logs.

Local control should handle safety and low-latency functions. Cloud services should be used for reporting and long-term analysis. Network segmentation should separate building controls from guest and office networks.