Payload Encryption - MQTT Security Fundamentals
Welcome to the MQTT Security Fundamentals series. In this blog, we will discuss MQTT Payload encryption. You will learn how payload encryption can be applied to the MQTT protocol and how this application-level encryption adds an additional layer of security in untrusted MQTT environments.
What is MQTT Payload Encryption?
MQTT Payload encryption is the encryption of application-specific data on the application level (typically, the MQTT PUBLISH packet payload or the CONNECT LWT payload). This approach allows end-to-end encryption of application data even on untrusted environments. While the message metadata such as the MQTT Topic stays intact, the payload of the message gets encrypted. This type of encryption is not defined in the MQTT specification and is completely application specific.
Since MQTT payloads are always binary, it’s not necessary to encode the encrypted message to a textual representation such as base64 (technically speaking, the message is usually a raw byte array after encryption). If you need to save additional bandwidth, this is an important point. Text encodings are typically more bloated than the raw byte representation.
All MQTT PUBLISH metadata stays intact and only the payload of the message is encrypted. This ensures, that there is no custom mechanism needed on the broker side for decrypting the data (in fact, you may want to prevent the broker to do that if you’re using encryption!).
Usually, MQTT payload encryption is only applied to MQTT PUBLISH packets. It is also possible to implement a custom broker plugin for decryption so that the following data on the client side can be encrypted:
PUBLISH topics
CONNECT username/password
SUBSCRIBE topics
UNSUBSCRIBE topics
Our recommendation is to stick with LWT and PUBLISH payload encryption.
Encryption Scenarios
End-to-End (E2E) Encryption
This approach ensures that the encrypted data stays encrypted all the time. While the MQTT broker uses the unencrypted packet metadata for routing and quality of service handling, the application data itself stays encrypted and the broker cannot read the encrypted data. Only trusted clients have access to the decryption key of the data.
If an attacker gets access to an MQTT packet (for example, due to improperly set up authentication and authorization or missing TLS), the attacker can’t decrypt the data without the decryption key
E2E encryption is independent of the broker implementation and can be applied to any topic by any MQTT client. If you can’t use authentication and authorization mechanisms or you are using a public broker such as the MQTTDashboard, E2E encryption can protect your application data from malicious usages.
Client-to-Broker
A client-to-broker approach ensures that the payload of the message is encrypted in the communication between the client and the broker. The broker is able to decrypt the message before distributing it, so all subscribers receive the unencrypted message. This may be a good alternative if TLS is not an option and you want to protect important data from eavesdroppers on the publishing side. (Please read our post about TLS to make sure you understand the risks of not using TLS!) Trusted subscribers are connected via a secure channel (TLS) and are allowed to receive the data in plain text.
This approach needs a broker plugin which decrypts the messages on-the-fly.
Encryption Mechanisms
There are two popular mechanisms for encrypting data: Asymmetric encryption and Symmetric encryption.
Asymmetric Encryption (Public/Private Key Encryption)
Asymmetric encryption requires two keys: One (public) key for encrypting data and one (private) key for decrypting data. Once data is encrypted with the public key, it is not possible to retrieve the original message with the public key. Only the private key can decrypt the data.
For MQTT payload encryption, this approach is perfect if you only have a few trusted subscribers that have access to the private key and you have many publishers that are possibly untrusted. The public key is not a secret and everyone is allowed to encrypt messages with that key. The important part is that only trusted clients can decrypt the message again using the private key.
When you use this approach, the best practice is that each MQTT topic gets its own public/private key pair.
Symmetric Encryption
In this cryptographic approach, it’s possible to encrypt and decrypt a message with the same key (which can be a password). If you have a trusted MQTT environment, this approach can work very well for you. Symmetric encryption tends to be easier to implement than asymmetric encryption and the provisioning process is usually easier as well.
The best practice is to assign each MQTT topic its own key (password) so that if a password for a topic is lost, messages on other topics can’t get decrypted by attackers.
Advantages/Disadvantages of Payload Encryption
Advantages:
A completely secure end-to-end encryption of application data can be achieved.
Works well on constrained devices where TLS is not possible.
Adds another layer of security for topics that deliver confidental information.
Disadvantages:
Encryption/decryption can be resource-intensive on constrained devices.
Secure provisioning of the keys to the MQTT clients must be implemented.
These methods do not prevent man-in-the-middle attacks and replay attacks.
TLS vs. MQTT Payload Encryption
TLS provides security on the network layer, MQTT payload encryption provides security on the application layer. Both mechanisms can be used in conjunction without a problem. MQTT payload encryption solves the problem of protecting application messages from malicious listeners or untrusted MQTT clients (if no authentication mechanism is in place). If you don’t have a secure communication channel over TLS, an attacker can still replay the message or modify parts of the message (for example, the topic).
When to Use Payload Encryption?
MQTT Payload encryption is a good solution if you can’t use TLS but still don’t want to send your application data in plain text. Payload encryption provides an additional layer of security since all your application data is secured. While payload encryption may be a good fit for constrained devices which can’t use TLS, keep in mind that encryption and decryption can use a lot of processing power. Make sure that you choose an algorithm that gives you good speed and good security.
We hope you are enjoying the MQTT Security Fundamentals. To get notified as soon as we publish the next post, subscribe to our newsletter or RSS feed. If you think that we should add information, please tell us. We appreciate your questions and suggestions.
Do watch our webinar discussing IoT security issues and how MQTT can actually mitigate security vulnerabilities in IoT and IIoT infrastructures.
HiveMQ Team
The HiveMQ team loves writing about MQTT, Sparkplug, Industrial IoT, protocols, how to deploy our platform, and more. We focus on industries ranging from energy, to transportation and logistics, to automotive manufacturing. Our experts are here to help, contact us with any questions.
