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's 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.
Client Authentication
There are three ways that a Mosquitto broker can verify the identity of an MQTT client:
β’
Client ids
β’
Useranmes and passwords
β’
Client Certificates
Client ids
All MQTT Clients must provide a client id. When a client subcribes 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 settign 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.
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 settgins 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.
To create the passwords you will need to use the mosquitto_passwd utility that comes with the Mosquitto broker.
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 manange 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.
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.
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.
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 client like sensors. However simple alternatives like HMAC are avaliable see this hive security ariticle.
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.
