The variety of devices on the Internet of Things (IoT) has almost exploded in recent years. Many household appliances or everyday objects have an IoT connection or can be integrated into a smart home system.

But how does the communication of IoT devices work and which protocols are used? This article is about IoT protocols, which are located in the application layer with a focus on MQTT and about securing the protocols, but not securing the infrastructure.

Message Queuing Telemetry Transport (MQTT)

The most well-known IoT communication protocol is currently Message Queuing Telemetry Transport (MQTT). This is a network protocol designed for machine-to-machine (M2M) communication. The client-server protocol is based on the publish-subscribe model. MQTT usually works via TCP. However, there are also variants of the protocol that work with UDP.

IoT Use-Case with MQTT

The client, in this case a Raspberry Pi with a room temperature sensor, sends sensor data to the server (MQTT broker). After the connection between client and server is established, data is sent on a predefined topic. This topic can be Office/Meetingroom/Temperature, for example. The use case could be that the office control subscribes to this topic and informs employees about the temperature shortly before their next meeting in the “meeting room”, thus giving them the opportunity for early ventilation.

MQTT is widely used in sensors and actuators, mobile phones, embedded systems or even full-fledged desktop computers. Ports 1883 and 8883 are reserved for MQTT. A great advantage of MQTT is the MQTT broker, which takes over important tasks from the often resource-poor client. This is also the reason for its widespread use in automation and control solutions.

The interaction works as follows: IoT devices send data, states or other information to the MQTT broker, which sends the received data to other devices and systems that have subscribed to the corresponding topic. This means that the IoT device only has to send the data to the MQTT broker, which saves a lot of complexity and performance.

MQTT Configuration Options

The MQTT protocol offers the following configuration options for Quality of Service (QoS), ensuring the arrival of a message:

The retain option in the broker enables messages to be saved and the last message of the topic to be delivered immediately in the case of a new subscription. When establishing a connection, it is possible to define what happens in the event of an interruption or complete termination of a connection, or which message should be sent to the subscribers in such a case.

Structure of an MQTT Packet

The protocol header is 2 bytes in size, the first byte contains the message type (4 bits) as well as specific flags depending on the message type, for example, in the case of a publish message, duplicate delivery (1 bit), quality of service (2 bits) and the retain flag (1 bit). The length of the remaining payload is noted in the second byte. This is followed by the variable part with the MQTT topic and the payload.

How do you secure MQTT?

MQTT can be encrypted and thus protected with the use of TLS at the transport layer, using port 8883 (secure-MQTT). The article Transport Layer Security explains the latest changes and shows the recommended TLS configuration. In addition, there is the option that the sender authenticates itself to the MQTT broker using an X.509 certificate.

MQTT itself has authentication through username and password. It must be noted that without the use of TLS, the transmission takes place in plain text and can thus be easily intercepted. In addition to the username and password, a client identifier can also be added to the connect message. This process first checks the username and password combination and then whether the client identifier sent with the message matches. There is an option for encryption of the payload, which should be considered if TLS cannot be used due to very low available hardware.

How does Authorisation work in MQTT?

The control is carried out on the MQTT broker, namely via so-called Topic Permissions. The following options are available:

• Permitted topics: Specific Topic, Wild card Topic
• Allowed operations: Publish, Subscribe, Both
• Allowed Quality of Service setting: 0, 1 ,2 or all

Constrained Application Protocol (CoAP)

CoAP is an IoT protocol that is best suited for nodes with few resources, i.e. low-power processors such as 8-bit microcontrollers with little RAM and ROM. The protocol is also designed for machine-to-machine (M2M) applications, whether on the same network or over the internet. Applications can be found in smart energy and building automation. CoAP works differently from MQTT in a request/response interaction model between endpoints.

The big advantages of CoAP are the simple conversion to HTTP, the support of multicast as well as the low overhead of the protocol and the simplicity for devices with very low resources. CoAP runs on most devices that support UDP.

How can you secure CoAP?

The CoAP protocol offers four different security models, most of which use Datagram Transport Layer Security (DTLS). DTLS is an encryption protocol for unreliable transport protocols such as UDP or SCTP. DTLS is based on TLS and provides similar security.

Security models of CoAP:

• NoSec: DTLS is deactivated here. This model has no security.
• PreSharedKey: DTLS is activated. A list of pre-shared keys is available. It states for each key with which nodes it can be used. The nodes must support AES cipher suites.
• RawPublicKey: DTLS is activated. Each node uses an asymmetric key pair without a certificate. The devices must support AES cipher suites and Elliptic Curve algorithms for key exchange.
• Certifacte: DTLS is activated, and the node uses an X.509 certificate. However, care must be taken that, for example, RSA is not used for resource-poor nodes.

Advanced Message Queuing Protocol (AMQP)

AMQP is an open standard that is an application-level binary network protocol for message-oriented middleware (MOM). AMQP is built on top of TCP. The AMQP protocol was created to support many different types of messages and communication patterns. It supports different message-delivery guarantees, which correspond to the Quality of Service of MQTT.

How can you secure AMQP?

AMQP can be encrypted with TLS, then port 5671 (amqps) is used. The client must validate the server’s certificate. Additional security is provided by authenticating the client by the server using the client certificate.

With the support of the Simple Authentication and Security Layer (SASL) framework, there is another option for authentication and negotiation of communication parameters. SASL offers many different mechanisms for authentication including OAuth 2.0 bearer tokens, Kerberos, NTLM, OTP and many more. Among these, there is also an “ANONYMOUS” variant, whereby this is an unauthenticated variant and should therefore not be supported.

Data Distribution Service (DDS)

DDS (Data Distribution Service) is an open standard that is ideal for real time systems. DDS provides broad support from the smallest devices to fast desktop computers and is designed to eliminate complicated network programming. DDS increases reliability, is simple and uses the publish-subscribe model. The DDS protocol is often used in aerospace, air traffic control, autonomous vehicles, medical devices, robots and other applications that require real-time data exchange.

Similar to the MQTT protocol, there are publishers who create topics and send samples. DDS distributes these samples to the subscribers of the respective topics.

DDS is also referred to as network middleware, which handles the addressing of messages and the serialisation and deserialisation of messages in cross-platform communication. DDS also manages authorisation and error handling if a message cannot be delivered. Quality of Service (QoS) can also be configured with DDS. DDS supports hot-swapping between redundant publishers, whereby a backup node steps in if the primary publisher fails.

How can you secure DDS?

Before the DDS security model existed, mainly TLS and DTLS were used to secure DDS, but this only worked with unicast.

The DDS security model, which was added later, is modular and allows different areas to be added as plug-ins. The following plug-ins are available in the security area:

• Authentication
• Access Control
• Cryptography
• Logging
• Data Tagging

The plug-ins Authentication, Access Control and Cryptography should be used in any case when using DDS. Depending on the area of application and purpose, the remaining plug-ins Logging and Data Tagging should also be used.

Conclusion

All protocols have their own strengths, so it is worth evaluating which feature is most important in your own environment. Depending on the application, this can be the real-time capability, the good use for low-resource devices or the simple development. Securing the IoT protocol used is important and should be done precisely and, if possible, tested before commissioning. Many of the IoT protocols presented can be secured with TLS, here it is important to use a secure TLS configuration.

About the Author

Ralph Meier completed an apprenticeship as an application developer, with a focus on web development with Java, at a major Swiss bank and then completed a Bachelor of Science in Computer Science UAS Zurich at the ZHAW School of Engineering. His primary task is doing security-related analysis of web applications and services. (ORCID 0000-0002-3997-8482)

Links

• https://datatracker.ietf.org/doc/html/rfc7252
• https://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html
• https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
• https://www.omg.org/spec/DDS/1.4