MQTT Security Fundamentals: MQTT Payload Encryption

mqttsecurityfundamentals_part8

Welcome to the eight part of the MQTT Security Fundamentals series. The topic for this post is MQTT Payload encryption. You will learn how payload encryption can be applied to MQTT and how this application-level encryption adds an additional layer of security in untrusted MQTT environments.

MQTT Payload encryption?

MQTT Payload encryption is the encryption of application specific data (typically the MQTT PUBLISH packet payload or the CONNECT LWT payload ) on the application level. This approach allows End-to-End encryption for application data even for untrusted environments. While the message metadata like the MQTT Topic (Read more about topics in this post) 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 needed to encode the encrypted message (which is – technically speaking – usually a raw byte array after encryption) to an textual representation, like base64. This is important if you need to save additional bandwidth, text encodings are typically more bloated than the raw byte representation.

publish_packet_encrypted

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!) in order to route the MQTT message to the subscribers.

Usually MQTT payload encryption is only applied to MQTT PUBLISH packets. If you are willing to go the extra mile and write a custom broker plugin which can decrypt the encrypted data on the broker side, then you could e.g. also encrypt the following data on the client side:

  • 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 e.g. routing and quality of service handling, the application data itself stays encrypted and the broker has no way to look into the encrypted data. Only trusted clients have access to the key to decrypting the data again.

payload-enc-end-to-end

If an attacker gets access to a MQTT packet (e.g. if you don’t have authentication and authorization set up properly or you don’t use TLS), the attacker can’t decrypt the data if she doesn’t get access to the key for decrypting the data.

E2E encryption is broker implementation independent 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 (like the MQTTDashboard), you can protect your application data from suspicious eyes and MQTT clients.

Client-to-Broker

A Client-to-Broker approach makes sure that the payload of the message is encrypted in the communication between one client and the broker. The broker is able to decrypt the message before distributing the message, so all subscribers receive the original, unencrypted message. This may be a good alternative if you can’t use TLS and 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!) The trusted subscribers are connected via a secure channel (TLS) and thus they are allowed to receive the data in plain text.

payload-enc-client-broker

This approach needs a broker plugin which decrypts the messages on-the-fly.

Encryption mechanisms

For encrypting data, there are two popular mechanisms: Asymmetric encryption and Symmetric Encryption.

Asymmetric encryption (Public / Private Key encryption)

Asymmetric encryption means, that there are two keys needed: One (public) key for encrypting data and one (private) key for decrypting data. Once data is encrypted with the public key, it’s not possible to retrieve the original message with that 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 (which have access to the private key) and there are many publishers (which are possibly untrusted). The public key is not a secret and everyone is allowed to encrypt messages with that key. The important thing is, that only trusted clients can decrypt the message again.

When using this approach, it is a best practice that each MQTT topic gets its own public / private key pair.

Symmetric encryption

Symmetric encryption is a cryptographic approach where it’s possible to encrypt and decrypt a message with the same key (which may be a password). If you have a trusted MQTT environment, this approach might work very well for you. Symmetric encryption tends to be easier to implement (and the provisioning process is typically easier) than asymmetric encryption.

It’s recommended that each MQTT topic gets its own key (password), so 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 no TLS can be used.
  • Adds another layer of security for topics which are used for delivering confidental information

Disadvantages:

  • Encryption / decryption can be resource intensive on constrained devices
  • A secure provisioning of the keys to the MQTT clients must be implemented.
  • Doesn’t prevent from 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, so both mechanisms can be used in conjunction without problems. MQTT Payload encryption does only solve the problem of protecting application messages from eavesdroppers or untrusted MQTT clients (if no authenticaton mechanism is in place). An attacker could still replay the message or modify parts of the message (like the topic) if you don’t have a secure communication channel over TLS.

When to use payload encryption?

MQTT Payload encryption is very well suited if you can’t use TLS but still don’t want to send you application data in plaintext. This gives 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, bear in mind, that encryption and decryption can use lots of processing power, so make sure to choose an algorithm which gives you good speed and good security.

We hope you enjoyed the eight part of the MQTT Security Fundamentals, if you want to get notified as soon as we publish the next post, you can subscribe to our newsletter or RSS feed. You think we have missed some important information? Please tell us, we are always open to questions and suggestions.

0 comments

  1. Phil says:

    I’ve implemented this on some embedded devices with AES which works pretty well. keeps message sizes small and its fairly quick to process. I also added a rolling key and session key into the payload to prevent replay attacks making every message unique.

Leave a Reply

Your email address will not be published. Required fields are marked *