MQTT Security Fundamentals – MQTT Message Data Integrity
Welcome to the ninth part of the MQTT Security Fundamentals series. This weeks topics is Signing MQTT Messages. You will learn how digital signatures/MACs and checksums for MQTT messages work and what problem they solve. To get the most out of this blog post, we recommend to read the post about MQTT Payload encryption first.
Note: While technically not 100% correct, for the sake of discussion in this post, we’re using the word stamp as umbrella term for digital signatures, MACs and checksums.
How to check data integrity for MQTT messages?
If you have a MQTT system where untrusted MQTT clients or MQTT clients which you don’t control have access to your broker and your MQTT topics, checking data integrity of sent messages can be very important, especially if you don’t use TLS. With data integrity checks you make sure that no third party modified any contents of your MQTT messages.
In the MQTT context, PUBLISH packets can contain a digital signature/MAC/checksum of the contents of the packet. This calculated stamp is typically added to the payload (e.g. at the beginning of the payload). The receiver of the packet can verify the data integrity by recalculating/validating the stamp and so the client has the confidence that the message was not altered by some malicious third party.
Typically the following data is used as part of the stamp:
- The MQTT PUBLISH Payload
- The Topic of the MQTT PUBLISH packet
It’s recommended that the Quality of Service and the Message ID is not used for the calculation of the stamp, since Quality of Service downgrades can occur if the QoS of a subscription is smaller than the published QoS and Message IDs are different for the receiver and the sender of a packet. In these particular cases the signature would not be valid anymore. So it’s a good practice to only include the payload and the topic of the message.
Mechanisms for creating/validating stamps
There are three popular mechanisms for creating stamps:
- Checksum / Hash Algorithms (e.g. MD5, CRC, SHA1/2,…)
- MAC (e.g. HMAC, CBC-MAC,…)
- Digital Signatures
All of these mechanisms have their strengths and weaknesses. While the discussion about the strengths and weaknesses of these mechanisms are out of scope of this blog post, the following table gives a good overview of the guarantees the individual mechanisms promise:
Data Integrity: The recipient can make sure that the data was not modified (accidentally).
Authentication: The recipient can make sure that the message originates from a trusted sender, because only trusted parties have access to the key for creating and verifying the stamp.
Non-Repudiation: Only the sender of the message – who has access to the private key – is able to create the stamp. Other parties can verify the signature with the public key but they are not able to create the stamp themselves.
Using Checksums with MQTT
Checksum algorithms are typically very fast, even for large MQTT packets. It’s strongly recommended to use a MAC algorithm or Digital Signatures instead of Checksums if you don’t use TLS, though. Checksums can get altered with the MQTT packet, since the attacker only needs to know the checksum algorithm and can apply the algorithm after modifying the packet. There aren’t many good use cases for checksums in MQTT packets. If you have a good use case for checksums, let us know in the comments!
Using MACs with MQTT
Message Authentication Code Algorithms (like HMAC) are typically very fast compared to digital signatures and provide good security if the shared secret key was exchanged securely prior to the MQTT communication. HMAC calculates the MAC with a cryptographic Hash Function and a cryptographic key. Only senders which know the secret key can create a valid stamp. The disadvantage is, that all clients who are aware of the secret key can sign and verify, since the same key is involved for both processes.
HMACs work great with MQTT PUBLISH messages and can be used securely even if you don’t have TLS deployed. HMACs are pretty fast to calculate and don’t use much resources on constrained devices.
Using digital signatures with MQTT
Digital Signatures use public / private key cryptography. The sender signs the message with its private key and the receiver validates the stamp (signature) with the public key of the sending client. Only the private keys can create the signature and thus it’s not possible to fake the signature if an attacker did not obtain the private key.
As seen in the client certificate blog post, provisioning and revocation of public / private keys is a challenge and adds complexity to the system. Another challenge is, that in Publish / Subscribe Systems like MQTT, the receiver of a message typically is not aware of the identity of the sender, since the communication is decoupled via topics. If it’s guaranteed that only a specific client can publish to a specific topic (e.g. by authorization mechanisms), digital signatures may be a good (and secure!) fit, though.
Data integrity and encryption
In the last blog post we’ve seen how to encrypt messages with MQTT. Data integrity checks with stamps are a good addition to encrypting messages. Even if the attacker can decrypt the message (and encrypt it after modification), the integrity check will still fail if the message was altered. Especially if you are using MQTT without TLS, this gives an additional layer of security.
Data integrity checks and TLS
If TLS is deployed and proper authentication and authorization mechanisms are in place, data integrity checks don’t add much additional security. If you are using Digital Signatures with public / private key cryptography, the Non-Repudiation attribute may add additional security, especially if you are dealing with very sensitive data and command PUBLISH packets.
So that’s the end of part nine in our MQTT Security Fundamentals series. If you have any comments or suggestions, we would love to hear your feedback in the comments below!
If you want to be notified as soon as the next part is released, simply sign up for our newsletter below. This brings you fresh content about MQTT and HiveMQ once a week. If you prefer RSS, you can subscribe to our RSS feed here.