The 3 Basic Concepts of MQTT Security

As IoT devices continue to proliferate, security becomes a major concern. When designing the network security for an IoT device, there are three basic concepts to keep in mind: identity, authentication and authorization.

Light bulbs, locks, thermostats and appliances are now designed with network connectivity in mind. One day soon, the majority of such once-isolated devices could become connected to home networks and to the greater internet.

For consumers, this means enhanced productivity, health, education and life. For entrepreneurs, this means new revenue streams and markets.

As the Internet of Things grows, however, each new connected product has the potential to become a target for hackers, from botnets to DDoS threats. For example, in October 2016, the largest DDoS attack ever was launched using an IoT botnet that was infected with the malware Mirai. Companies such as Netflix, Reddit and Twitter had their sites brought down because of this malicious attack.

Another example is the hackable cardiac device from St. Jude. According to CNN, “The FDA confirmed that the implantable cardiac devices have vulnerabilities that could allow a hacker to access the device.”

MQTT Security Fundamentals

When it comes to IoT network security there are three basic concepts to keep in mind: identity, authentication and authorization.

In each MQTT scenario, there is a client and a broker. A client can be anything ranging from a microcontroller to a server. Anything that makes a connection to a broker is considered a client.

A broker receives all messages and coordinates the publishing of messages to clients that are subscribed. The broker is responsible for persisting connections, as well as identifying and authorizing the transfer of data to MQTT clients. The MQTT connection is only between one client and a broker.

Identity

In order for a client to make a connection with a broker, it must initiate a request to connect. The MQTT protocol specifies that a client must report a client id when requesting a connection. Ideally, every client has a unique client identifier; most devices come equipped with a universal unique identifier (UUID) or a MAC address of the network device used to connect the client.

Once a broker receives a command from a client to connect, it determines if the client is eligible to connect if the message received contains a valid client id, username and password. It’s worth noting that a username and password are optional when requesting a connection to a broker.

Authentication With X.509

In addition to authentication with username and password, the MQTT protocol allows a device to authenticate with a X.509 certificate. X.509 is a digital certificate that uses a public key infrastructure to verify that a public key belongs to a client.

In order for your client to utilize X.509 authentication, it must implement TLS (Transport Layer Security) as its encryption method. TLS isn’t in the scope of this article, but for context, it’s worth noting that TLS encryption is the portion of your client stack that secures the communication channel for TCP/IP.

In the X.509 scenario, a certificate authority is introduced to verify the identity of a client. During the connection handshaking process, the client presents the broker with its certificate containing information such as its identity and public key. The broker then relays this certificate to the certificate authority for verification. Once verified, the broker can ensure that the client certificate is genuine and gain trust in the binding with the client name and public key. It’s worth noting that some MQTT brokers do not support the use of X.509 certificates.

X.509 certificates provide the added benefit of verifying the identity of MQTT clients as well as providing authentication at the transport level.

Authorization

When a client establishes a connection with the broker, it can perform two activities: publish and subscribe to topics. Topics are the main resource available to clients and require authorization/protection for a secure system – otherwise, without authorization, any client would have the ability to subscribe and publish to any topic available on the broker.

The most common types of authorization used are Role Based Access Controls (RBAC)and Access Control List (ACL).

In RBAC, a role provides a level of abstraction between a client and the main resource, i.e. topics in this case. Permissions are always associated with a certain role, allowing the broker to authorize the ability for a client to publish or subscribe to a certain topic.

ACL associates certain clients with a list of permissions. These permissions provide policies on what topics a client can subscribe/publish to.

Using ACL or RBAC a broker can be configured with topic permissions. During the run-time, the broker can determine allowed topics, allowed operations, and allowed quality of service. If a client attempts to perform an unauthorized operation, the broker can perform actions such as disconnecting from a client or acknowledging the client but preventing it from the publishing data to other clients that have subscribed to the same topic.

Authorization with Access Tokens

Access tokens provide an additional mechanism for scoping permissions for clients. By scoping the permissions of a client, you can prevent unauthorized access to read or write data that may have adverse effects on other client devices connected to your IoT infrastructure.

When publishing or subscribing, the broker needs to authorize the client. Token authorization allows for a client to claim what scope, or permissions, it has. Another way to provide authorization with a server is to provide a third-party source for the broker to look up authorizations associated with a client based on a token and unique id.

In order to connect to a broker with an access token, the client must send its access token with a connect message using the password field. In this case, additional identification can be provided with the username field as well. Before requesting a connection, the client must be provided with an access token and scope.

There are a variety of token services available. The most commonly used is OAuth 2.0. The client credential flow is modeled above where a client requests a token using credentials and is granted an access token.

Develop With Confidence and Foresight

While there are many more considerations when securing an IoT framework, this article provides three basic concepts as a starting point. Careful consideration of potential vulnerabilities is needed when assessing the scope of your IoT framework. Even then, there’s still the potential for future, yet-unknown vulnerabilities. While the security implications are vast, constructing a viable security framework can be the foundation for the execution of security in production environments.