In a recent article, we introduced the Publish-Subscribe messaging pattern along with a discussion of the top 6 areas to consider when building a threat model for an implementation of this technology. In this post, we focus on securing Publish-Subscribe systems within the Internet of Things (IoT) and the relevant common protocols.

IoT environments require participating devices be able to discover and talk to each other, and operate more autonomously. The Publish-Subscribe messaging pattern is one of the communication models considered as a solution to message dissemination and delivery. This pattern provides features such as loose coupling, simple communications, and reusability that make it a suitable choice for facilitating machine-to-machine correspondence. As a result, several publish-subscribe patterns and protocols such as AMQP and MQTT have been promoted for the Internet of Things (IoT). Although many of these protocols offer recognized security mechanisms, IoT poses new risks and protection challenges to information systems. Such challenges include authenticating and provisioning devices, securing device-cloud connections, and protecting data in storage and during processing.

Device provisioning and authentication

While publisher and subscriber devices are in the field and operating as a part of an IoT network, the systems should be able to properly identify and provision them. Devices can introduce themselves to an identity management component using a device ID embedded within a hardware trust module, or an existing fixed ID such as a MAC address or other serial number. However, it is challenging to modify either IDs if necessary. Therefore, using logical device IDs are more practical, and makes the device ID association possible at deployment time.

Due to the loose coupling nature of publish-subscribe networks, clients (thin nodes) only communicate with a broker which handles identification and authentication. Some publish-subscribe protocols support mutual authentication by TLS (using a certificate/private key) or Simple Authentication and Security Layer (SASL) mechanisms. Figure 1 illustrates how AMQP containers (In the latest version of AMQP, an AMQP container can act as both the client and the server) mutually authenticate each other via a SASL server.

Figure 1: Example of an AMQP System Using SASL

It should be noted that clients’ capabilities must be considered when choosing a suitable authentication mechanism. Stronger mechanisms may involve a significant amount of cryptographic calculation overhead that cannot be supported by resource-constrained devices.

Secure connectivity

The durability of the transmitted data is an crucial consideration for a messaging network in an IoT system. Most of the publish-subscribe protocols provide message caching and delivery acknowledgments to maintain message durability based on the importance of the message (e.g., telemetry data vs. command messages).

Assuming connected clients can handle transport layer encryption, an IoT system can use a publish-subscribe protocol that is compatible with TLS. While the intensive CPU utilization for TLS operations might be a problem for resource-constrained client devices ,it is usually insignificant for resource-rich brokers. Moreover, the cyclical nature of IoT communications (e.g. dormant devices waking up to send messages every several minutes) increases the number of TLS re-initializations. Methods such as session resumption make the reconnection process faster by easing subsequent handshake procedures. Figure 2 shows different ways AMQP offers TLS.

Figure 2: TLS in AMQP

Otherwise, many IoT solutions assume a trusted local environment in which nodes can connect to a resource-rich local hub that can establish secure channels to the outside world. To protect against unwanted inbound connections, only the devices initiate connections. Figure 3 illustrates an example topology of this solution.

Figure 3: Trusted local connections to constrained devices

Secure data at rest and during processing

In a publish-subscribe system, data is stored in three different conditions:

Raw data that is output from a sensor or processor and stored inside a publisher Persistent messages, or messages delivered to a broker but not delivered to all subscribers Messages delivered to a subscriber but not consumed yet, or are being processed

Publish-subscribe protocols usually do not specify requirements for protecting messages at rest. Therefore, local cache encryption should happen in the application layer. Client applications must employ the underlying OS and framework’s APIs to securely encrypt and store messages. Other than messages, authentication and encryption keys must be securely stored in a hardware trust module or an encrypted software safe whose keys can only be used for cryptographic calculations and cannot be extracted. In an IoT network, scattered devices in the field are prone to scanning and tampering (physical interference).

Since the broker is a central hub which stores and routes all messages, it should provide a robust authorization management mechanism to restrict access to topics and message queues.

Protocol Comparison: HTTP/1, AMQP, MQTT

HTTP follows the request-response message passing model in which the clients should be aware of the address of all other clients to communicate directly . On the other hand, AMQP and MQTT are publish-subscribe protocols which decouple the sender and the receiver through a broker.

. On the other hand, AMQP and MQTT are publish-subscribe protocols which the sender and the receiver through a broker. Unlike AMQP and MQTT, HTTP does not support server push ; rather, devices should poll the server for updates. Despite the fact that server push capability lowers latency, it enables devices to receive inbound connection requests, which can be abused if there are not enough network boundary protections in place.

; rather, devices should poll the server for updates. Despite the fact that server push capability lowers latency, it enables devices to receive inbound connection requests, which can be abused if there are not enough network boundary protections in place. HTTP and AMQP nodes can communicate over WebSockets , while MQTT standard uses port 8883 (which may be problematic where non-HTTP ports are closed).

, while MQTT standard uses port 8883 (which may be problematic where non-HTTP ports are closed). HTTP and MQTT have more compact libraries than AMQP. Therefore, they are more efficient for resource-constrained devices with less than 1MB memory. As such, adding a security layer might be more practical.

than AMQP. Therefore, they are more efficient for resource-constrained devices with less than 1MB memory. As such, adding a security layer might be more practical. MQTT and AMQP have binary payloads, which makes the packet size significantly smaller than HTTP. As a result, it not only makes communicating with power and resource-constrained devices easier, but it also leaves some room for cryptographic signatures, hashes, checksum values, etc.

In an IoT ecosystem, where many devices with limited storage and functional capabilities, a resource-rich publish/subscribe broker acts as a shock absorber for the incoming data streams. It can gather, buffer, and deliver telemetry messages properly in the event of data spikes caused by the swarms of connected devices. Moreover, recognized publish/subscribe protocols and frameworks provide standard mechanisms for securing messages in transit and at rest. IoT system designers have to consider the unique characteristics of their IoT application (e.g., the size of the network, nature of the connections, devices’ capabilities, operation environment, etc.) for choosing the proper protocol, and implementing the appropriate authentication, authorization, and encryption methods.

References

OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0, http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html MQTT Version 3.1.1 — OASIS Standard, http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html The Transport Layer Security (TLS) Protocol Version 1.2, https://tools.ietf.org/html/rfc5246 Simple Authentication and Security Layer (SASL), https://tools.ietf.org/html/rfc4422

Authored by:

Amir Pourafshar, Application Security Researcher