Introduction to MQTT Security Mechanisms

In this tutorial we look at how you can restrict access to a broker, and how you can protect your data using various security mechanisms.

It is important to note that these security mechanisms are initiated by the broker, and it is up to the client to comply with the mechanisms in place.

It is also important to realise that when planning security for your implementation that you must consider the capabilities of your MQTT clients as well as your broker.

This tutorial will use the free Open source Mosquitto broker, and the Paho Python MQTT client to illustrate these mechanisms.

This tutorial is split into tow sections. The first section is an overview of the mechanisms and the second covers example scenarios.

Section 1- Oveview

Client Authentication

There are three ways that a Mosquitto broker can verify the identity of an MQTT client:

• Client ids
• Usernames and passwords.
• Client Certificates

Client ids

All MQTT clients must provide a client id.

When a client subscribes to a topic/topics the client id links the topic to the client and to the TCP connection.

With persistent connections the broker remembers the client id and the subscribed topics.

When configuring an MQTT client you will need to assign a name/id to the client generally that name is unimportant as long as it is unique.

However the Mosquitto Broker allows you to impose client id prefix restrictions on the client name, and this provides some basic client security.

You could,for example, choose a prefix of C1- for your client ids and so a client with client id of C1-python1 would be allowed but a client with id of python2 would not be allowed.

You will find this setting in the security settings section of the mosquitto.conf file.

Username and Password

An MQTT broker can require a valid username and password from a client before a connection is permitted.

The username/password combination is transmitted in clear text and is not secure without some form of transport encryption.

However it does provide an easy way of restricting access to a broker and is probably the most common form of identification used.

The username used for authentication can also used in restricting access to topics.

On the Mosquitto broker you need to configure two settings for this to work. Again you will find these settings in the security section of the mosquitto.conf file.

They are allow_anonymous and password_file. To require username/password then allow_anonymous should be false and password_file should contain a valid passwords file.Example settings

allow_anonymous false
password_file c:\mosquitto\passwords.txt #Windows machine

To create the passwords you will need to use the mosquiito_passwd  utility that comes with the Mosquitto broker.

See  Exploring Username and Password Authentication – MQTT by example

x509 Client Certificates

This is the most secure method of client authentication but also the most difficult to implement because you will need to deploy and manage certificates on many clients.

This form of authentication is really only suited to a small number of clients that need a high level of security.

See SSL and SSL Certificates Explained

Restricting Access to topics

You can control which clients are able to subscribe and publish to topics.

The main control mechanism is the username. (note: password not required), but you can also use the client id.

Unless you are running an open broker then this type of restriction will be common. See Configuring and exploring Topic Restrictions on Mosquitto

Securing Data

To protect the contents of your MQTT messages you can use:

• TLS or SSL Security
• Payload encryption

TLS Security

TLS security or as it is more commonly known SSL security is the technology that is used on the web.

This security is part of the TCP/IP protocol and not MQTT.

TLS security will provide an encrypted pipe down which your MQTT messages can flow.

This will protect all parts of the MQTT message, and not just the message payload.

The problem with this is that it requires client support, and it is unlikely to available on simple clients.

There are three methods of doing this:

• Using Self generated certificates
• Using free commercial certificates (let’s encrypt)
• Using paid commercial certificates

Payload Encryption

This is done at the application level and not by the broker. This means that you can have encrypted data without having to configure the broker.

It also means that data is encrypted end to end and not just between the broker and the client.

MQTT is after all a messaging protocol.

However this type of encryption doesn’t protect passwords (if used) on the connection itself.

Because it doesn’t involve any broker configuration or support this is likely to be a very popular method of protecting data.

See Encrypting The MQTT Payload Python Example and SSL or Payload Encryption Discussion Post

Section 2- Example Scenarios

How authentication provides Security on MQTT networks

In order for a rogue client to monitor broker traffic in needs to connect to the broker in order to publish/subscribe to topics.

Requiring a username and password makes connecting to the MQTT broker more difficult.

How do ACLs Provide Security

In order for a rogue client to monitor broker traffic in needs not only to connect to the broker but also to  publish and subscribe to topics.

Restricting topic access using ACLs makes this more difficult.

How does SSL Provide Security

SSL provides protection by making it difficult for anyone with access to the network traffic to monitor MQTT traffic.

Monitoring network traffic could reveal user name and passwords and data on an MQTT connection if that connection doesn’t use SSL.

Network traffic monitoring is easier on Wireless networks than wired networks.

However wireless networks use SSL to protect the network traffic so the listening device must also be a trusted network device to monitor network traffic.

Connection to the Internet

Unless absolutely necessary the MQTT (mosquitto) broker should not be exposed to the Internet.

Internet connections should always use SSL were possible, and authentication (username/password or client certificates) as well as ACLs.

A Bridged broker should use a firewall and only allow connection to that IP address.

Access Examples.

The following are some theoretical scenarios and what configuration I would probably use in that scenario.

They are  open for discussion and i would be happy to receive feedback and also examples from your networks.

Scenario 1– Have 100 sensors sending data to a broker on a local network at regular intervals. The data isn’t confidential.

The sensor receives commands from a control station that controls the message rate of the sensors and other sensor parameters.

The control station is also located on the local network

Sensor security – SSL desirable, No authentication required or authenticate using common username/password. Publish ACL restrictions on sensor topics is desirable.

Control station security – SSL desirable, authentication desirable, ACL restrictions on control topic publish and receive is mandatory.

Scenario 2– Have 100 sensors sending data to a broker on a local network at regular intervals. The data isn’t confidential. There is no control data.

Sensor security – SSL not required, No authentication required or authenticate using common username/password. publish ACL restrictions on sensor topic  desirable.

Scenario 3 –Have industrial robot(s) sending data and receiving commands from a control station. The robot and control station are on a local network.

SSL on robot and control connections. Authentication required on robot and control connections. ACL restrictions on all topics.

Scenario 4- An alarm control system monitoring the alarms from several houses/offices/locations across the Internet.

SSL on all connections. Authentication required on all connections. ACL restrictions on all topics.

Scenario 5 –A alarm control system monitoring various Tasmota devices (switches,fire alarms etc) across the Internet. The Tasmota devices do not support SSL.

A control system is available locally and across the Internet.

Consider a local broker to connect the sensors with ACL restrictions on all topics.

Use SSL,authentication and topic restrictions for the control station connection to the local broker across the Internet and also for the local control station.

Firewall Restrictions

In addition to MQTT security restrictions I would also consider basic firewall restrictions on the local MQTT broker.

Common Questions and Answers

Q- Can I use TLS with payload encryption?

A- Yes.

Q- To implement payload encryption do I need certificates?

A- No. You can use shared keys which is easier to implement.

Q- How do I know if the message is genuine and hasn’t been changed?

A- Digital signatures are the best way of doing this but they rely on a public/private key infrastructure and are unlikely to be implemented on constrained clients like sensors. However simple alternatives like HMAC are available see this hive security article.

Summary

There are several mechanisms available for securing MQTT connections.

Security restrictions are enforced by the MQTT broker, and the client must be configured accordingly.

The level of security required depends on the type of data you are sending and whether you are using public or private networks.

When using MQTT for control then security is very important and should be considered carefully.

 Course Tutorials Home<<Prev….Next>>Using MQTT Over WebSockets 

Mosquitto Configuration Tutorials

• Configuring ACL Topic Restriction

Related Tutorials and Resources:

• MQTT Basics for Beginners
• SSL or Payload Encryption?
• Username and Password Authentication – MQTT by example
• Hive MQTT Security Fundamentals
• JWT based authentication (Google paper)