Abstract:This research studies methods for enhancing the security of the Message Queuing Telemetry Transport (MQTT) protocol and proposes a security reinforcement framework for MQTT protocol. First, the risks faced by the MQTT protocol are analyzed, extracting four security requirements: authentication, authorization, data transmission protection, and trustworthiness of the broker; secondly, the principles and applications of five schemes are described: Transport Layer Security (TLS), Augmented Password Authenticated Key Exchange, topic encryption, attribute encryption, and proxy re-encryption; finally, a comparison of the intuitive implementation costs and pros and cons of the above schemes is provided, based on which a security reinforcement framework for the MQTT protocol is presented.This research is applicable not only to the MQTT protocol and other IoT protocols’ security reinforcement but also has certain enlightening significance for data sharing in cloud environments and blockchain scenarios.
2. MQTT Protocol Security Reinforcement Solutions
2.1. TLS
2.2. Augmented Password Authenticated Key Exchange Protocol
2.3. Topic-Based Encryption Scheme
3. MQTT Protocol Security Reinforcement Framework
3.1. Comparison and Summary
3.2. Framework
In recent years, the Internet of Things (IoT) has developed rapidly, and as its application scope expands, the security threats faced by IoT are gradually showing characteristics of large scale, diversity, and high frequency. According to monitoring data from the National Computer Network Emergency Response Technical Team/Coordination Center, in July 2022 alone, 471,158 IoT malicious samples were captured, and 55,163 IP addresses of IoT malware were discovered, with 2,021 active Command and Control (C&C) server addresses found, mainly distributed in the United States (33.6%), China (8.5%), Russia (6.7%), and other countries. Among them, 680 C&C servers from the United States controlled 373,080 devices within China. Therefore, the security threats faced by IoT cannot be ignored.
The Message Queuing Telemetry Transport (MQTT) protocol is a lightweight publish/subscribe messaging transport protocol designed for constrained devices and low-bandwidth, high-latency, or unreliable networks. The first version of this protocol was released by IBM in 1999, and version v3.1.1 became a standard of the Organization for the Advancement of Structured Information Standards (OASIS) in 2014, with the latest version being MQTT v5.0.
The MQTT protocol is very suitable for remote connections that require small code footprint or where network bandwidth is very precious. These features also make this protocol an ideal choice for emerging machine-to-machine (M2M) or IoT world connected devices, as well as mobile applications with very high bandwidth and battery power. Common application scenarios for the MQTT protocol include large-scale sensor network data collection, smart home interconnection, and mobile real-time messaging.
1
MQTT Protocol Introduction and Security Requirement Analysis
1.1. Introduction to MQTT Protocol
In the MQTT protocol, there are only two roles: Client and MQTT Broker, as well as a key concept: Topic.
Client: A program or device that uses MQTT and has the capability to send and receive messages. Clients cannot communicate directly with each other; all clients must connect to the broker, and all communications between them must pass through the broker.
Broker: The server for MQTT, which acts as an intermediary, primarily implementing topic management, message reception, message routing, and message storage.
Topic: A label attached to application messages that can be subscribed to by clients. When a client publishes a message, it specifies the topic to which the message belongs, and the broker pushes this message to all clients subscribed to that topic.
As can be seen, MQTT communication is a standard asynchronous communication model where each client is in a peer relationship.
As shown in Figure 1, the MQTT message consists of a fixed header, variable header, and payload, comprising three parts. The fixed header is mandatory and has a length of 2 bytes; the variable header and payload are optional, with the payload supporting a maximum of 256 MB of data.
Figure 1 MQTT Protocol Message Data Format
The first byte of the MQTT message has its first four bits representing the MQTT control message type, with 0 and 15 reserved, and the remaining 14 control message types defined as shown in Table 1. The communication model of the MQTT protocol is shown in Figure 2. Clients use subscribe (SUB) to subscribe topics from the broker, and publish (PUB) messages between the broker and clients.
Table 1 MQTT Message Types
Figure 2 MQTT Protocol Communication Model
1.2. MQTT Protocol Security Analysis
The security risks faced by the MQTT protocol are primarily due to security flaws in authentication, authorization, data transmission, and the trustworthiness of the broker, which correspond to its security requirements.
1.2.1 Authentication
The CONNECT message in the MQTT protocol provides an optional authentication method using username (UserName) + password (PassWord). The UserName field is a string, while the PassWord field is binary, supporting a maximum length of 65,535 bytes. This authentication method is simple, and the password is transmitted in plaintext. In addition, if no authentication mechanism is set, an unlimited number of clients can connect to the broker, causing significant connection pressure on the broker.
1.2.2 Authorization
The MQTT protocol specifies a hierarchical division of topics and defines two special characters “#” and “/”, which enable subscribers to subscribe to that topic without knowing it, while the MQTT protocol itself does not provide any access control-related instructions.
1.2.3 Data Transmission
The data in the MQTT protocol is transmitted in plaintext, posing risks to confidentiality and integrity during data transmission.
1.2.4 Trustworthiness of the Broker
The broker is the core of the entire MQTT protocol; all data sent between clients is stored at the broker. If the broker is untrustworthy, then the entire MQTT communication network lacks security.
2
MQTT Protocol Security Reinforcement Solutions
2.1. TLS
The Transport Layer Security (TLS) protocol is the preferred secure communication solution for most MQTT protocol users and is the most widely used MQTT security solution in the industry. This solution addresses authentication and data security issues at the transport layer, but it has the following drawbacks:
(1) TLS consumes CPU and hardware storage, which can be a significant burden for resource-constrained IoT devices.
(2) All encrypted data must be decrypted at the broker before being re-encrypted for the recipient, resulting in a significant computational overhead. Additionally, the broker is the performance bottleneck of the entire communication network and faces trustworthiness issues.
(3) The state of nodes in IoT devices changes rapidly, making the management of node security credentials challenging.
2.2. Augmented Password Authenticated Key Exchange Protocol
Compared to the TLS protocol, which requires a large number of bytes for authentication and key negotiation, the Augmented Password Authenticated Key Exchange (AugPAKE) protocol utilizes passwords to achieve mutual authentication of clients when accessing the broker, while negotiating the symmetric key used in subsequent communications based on D-H (Diffie-Hellman) key exchange (generally an AES key).
2.2.1 Overview of AugPAKE Protocol
Let p and q be two large prime numbers, where q is a factor of (p-1)/2, and each factor of (p-1)/2 is a prime number comparable in size to q. Use the integer group modulo p to represent the q-order multiplicative subgroup on the finite field GF(p),
Let
be the generator of subgroup G, i.e.,
The AugPAKE protocol can be implemented in group G. Table 2 provides the symbol description involved in the AugPAKE protocol.
Table 2 Symbol Description
During initialization, the user U calculates
where w’ is the valid password, and sends W to S as the registration password to S.
The protocol execution flow is shown in Figure 3.
Figure 3 AugPAKE Protocol Flow
The specific execution process of the AugPAKE protocol is described as follows:
(1) User U selects a random number x from
calculates the DH public value
and sends (U,X) to the server S.
(2) If S receives X equal to 0,1,1 mod p, then S terminates the protocol. Otherwise, S selects a random number y from
calculates
where
S sends (S,Y) to U.
(3) If the Y received by U equals 0,1,1 mod p, then U terminates the protocol. Otherwise, U calculates
where
U calculates the authentication code
U sends
to S.
(4) If the
received by S does not equal
then S terminates the protocol. Otherwise, S generates a verification code
and sends it to U. The server generates a session key
(5) If the 
received by U does not equal
then terminate the protocol. Otherwise, U generates a session key
At this point, U and S have completed mutual authentication based on the password and generated the session key SK for subsequent encrypted messages.
2.2.2 MQTT Based on AugPAKE
Assuming that the sending client ClientA and the receiving client ClientB have established session keys SKa and SKb with the broker through the AugPAKE protocol. Figure 4 illustrates the MQTT communication process based on the AugPAKE protocol.
Figure 4 MQTT Based on AugPAKE
The MQTT communication process based on the AugPAKE protocol is as follows:
(1) ClientA uses SKa to encrypt the message to be published under the topic and sends the ciphertext to the broker.
(2) The broker decrypts the message using SKa, then encrypts the plaintext message using the session keys of all clients subscribed to that topic, pushing the ciphertext to the receiving client, such as re-encrypting the message using the shared SKb with ClientB.
(3) ClientB decrypts the message using SKb.
In summary, AugPAKE can be considered a lightweight TLS, and it can also be replaced by other authentication key exchange protocols.
2.3. Topic-Based Encryption Scheme
Since MQTT message pushing is topic-related, it is intuitive to consider encrypting messages based on topics. Compared to TLS and AugPAKE schemes, the topic-based encryption scheme can avoid decrypting and re-encrypting ciphertext messages at the broker.
2.3.1 Asymmetric Topic Key Distribution and Message Encryption/Decryption
In 2016, Mektoubi et al. proposed a topic-based encryption scheme. This scheme requires a supporting public key infrastructure to generate certificates for clients and topics, and manually publicize the topic certificates and their corresponding private keys to authenticated clients for secure message transmission.
The process for a new client joining a topic to request a topic certificate is shown in Figure 5, and the process for the first request for a topic private key is shown in Figure 6. Figures 5 and 6 omit the forwarding process of the broker.
Figure 5 New Client Requests Topic Certificate
Figure 6 First Request for Topic Private Key
The specific process for a new client joining a topic to request a topic certificate is described as follows:
(1) When a new client Client1 wants to encrypt a message, it first needs to request the topic’s certificate by publishing a Request Topic message.
(2) A subscribed client Client2 listens to the request, checks if it has the topic’s certificate, and if it does, returns a Response Topic message containing the topic’s certificate.
(3) Client1 receives the topic certificate and verifies its validity (e.g., CA signature).
The specific process for the first request for a topic private key is as follows:
(1) When first decrypting a message, Client1 needs to request the topic’s private key by sending a Request Privatekey message, which contains Client1’s certificate encrypted with the topic certificate’s public key.
(2) A subscribed client Client3 listens to the request, checks if the topic private key is available. If available, it decrypts Client1’s certificate using the topic’s private key.
(3) Client3 verifies the validity of Client1’s certificate and encrypts the topic’s private key using Client1’s certificate public key, constructing and returning a Response Privatekey message.
(4) After Client1 receives the Response Privatekey message, it decrypts it using its corresponding private key to obtain the topic’s private key.
Thus, Mektoubi et al.’s scheme completes the distribution of topic certificates and private keys, allowing Client1 to encrypt and decrypt MQTT communication messages. In fact, session encryption can also be achieved using digital envelope technology, as shown in Figure 7.
Figure 7 Topic-Based Encryption of MQTT – Digital Envelope
The process of implementing topic-based encryption using a digital envelope is as follows:
(1) The sending client Client1 generates a session key key, encrypts a message under a certain topic using key.
(2) Client1 encrypts key using the public key of the topic certificate and writes the ciphertext of key into the MQTT payload.
(3) Client1 sends the message to the broker, which then pushes it to all clients subscribed to the relevant topic, such as Client4.
(4) Client4 first decrypts key using the topic’s private key, then decrypts the message using key.
2.3.2 Symmetric Topic Key Distribution and Message Encryption/Decryption
A corresponding topic key (symmetric key) is generated for different topics, and the topic key is obtained when the client subscribes to the topic, using the topic key to encrypt all messages under that topic.
Figure 8 illustrates the client registration process. During client registration, it must submit its encryption public key, certificate, identity, etc., for the distribution of the topic key. The generation and distribution process of the topic key is shown in Figure 9.
Figure 8 Client Registration
Figure 9 Topic Key Generation and Distribution
The specific process for generating and distributing topic keys is described as follows:
(1) The broker generates a topic key for each topic, which can be derived using a key derivation algorithm based on the topic hierarchy.
(2) When clients subscribe to a topic, they securely obtain the topic key from the broker, which can be encrypted using the public key, certificate, identity, etc., submitted by the client.
The topic-based encryption process is illustrated in Figure 10.
Figure 10 Topic-Based Encryption
The specific description of the topic-based encryption process is as follows:
(1) The sending client Client1 encrypts the message to be published under the topic using the topic key;
(2) The broker pushes the ciphertext message to all clients subscribed to that topic;
(3) The receiving client receives the ciphertext message and decrypts it using the corresponding topic key.
Since the topic key is pre-generated, the broker needs to maintain as many topic keys as there are topics. When the topic key is derived hierarchically, the broker can maintain only the top-level key, generating it in real-time when needed to reduce the amount of key storage.
2.4. Attribute-Based Encryption Scheme
Compared to traditional public key cryptographic algorithms, Attribute-Based Encryption (ABE) can better meet one-to-many communication scenarios while allowing for fine-grained control over data access, making it very suitable for the MQTT protocol’s subscription-push mechanism. A typical secure MQTT communication solution based on attribute encryption is the Secure Message Queuing Telemetry Transport (SMQTT).
2.4.1 Overview of Attribute Encryption
Attributes refer to the properties possessed by an object, such as gender, age, education, etc., which make up the attribute set of that object. An access policy (referred to as policy) is a logical expression composed of attributes and their relationships, generally represented in tree structure. If the attribute set makes the logical expression of the policy true, it is said that the attributes match the policy, allowing the user to perform related operations.
In attribute-based encryption, depending on whether the designer embeds the attribute set and policy into the user’s private key or ciphertext, it can be divided into Key Policy-Attribute-Based Encryption (KP-ABE) and Ciphertext Policy Attribute-Based Encryption (CP-ABE), both of which are equivalent.
In KP-ABE, the access policy is generated by the server and serves as input for generating user private keys. When the message publisher encrypts the message, it must use the attribute set to generate a ciphertext index. During decryption, the ciphertext index must meet the key access policy for the user to decrypt correctly. Since the access policy is determined by the server, this scheme is suitable for static scenarios such as pay-per-view.
In CP-ABE, the access policy is generated by the message publisher, serving as input during message encryption to generate the ciphertext index. The generation of user private keys requires inputting user attributes, and only users whose attributes meet the ciphertext access policy can decrypt correctly. In this scheme, data owners can set policies to decide which attributes can access the ciphertext, generally applied to data encryption storage and fine-grained sharing in public clouds.
2.4.2 MQTT Combined with Attribute Encryption
In literature [5], considering users’ fine-grained access control over published messages, a CP-ABE encryption method is adopted. Taking into account the adaptation to the MQTT subscription-push mechanism and combining the idea of topic-based encryption, this paper adopts the KP-ABE encryption method to generate access policies for users subscribed to different topics.
The initialization process of KP-ABE is illustrated in Figure 11.
Figure 11 KP-ABE Initialization
The specific description of the KP-ABE initialization process is as follows:
(1)
provides attributes, certificates, and other information to the broker for registration.
(2) The broker generates the Main Secret Key (MSK), public parameters (PK), and publicly provides the attribute set of all users.
(3) The broker generates access policies based on different topics according to subscribed users and uses them as input to generate user private keys.
(4) The broker securely returns the relevant private key set to it (e.g., using the public key in the certificate for encryption).
(5) For each subscribed topic, the user has a corresponding private key. The KP-ABE encryption and decryption process is illustrated in Figure 12.
Figure 12 KP-ABE Encryption and Decryption
The specific description of the KP-ABE encryption and decryption process is as follows:
(1) The message publisher 
uses the public parameters PK and the encrypted attribute set (the topic to which the message belongs) to encrypt the message to be published and pushes the ciphertext message to the broker.
(2) The broker pushes the message to clients subscribed to the relevant topic.
(3) A client
receives the message, verifies whether the ciphertext attributes meet the access policy of the key it owns, and if they do, decrypts the message using the corresponding private key. This process can also be realized using digital envelope technology.
2.5. Proxy Re-Encryption Technology
Proxy Re-Encryption (PRE) technology allows the ciphertext encrypted with the sender’s public key to be transformed into ciphertext that can be decrypted by the receiver’s private key without decrypting at the broker, which effectively addresses the trustworthiness issue of the broker in MQTT.
2.5.1 Overview of Proxy Re-Encryption Technology
The proxy re-encryption system model is illustrated in Figure 13.
Figure 13 Proxy Re-Encryption System Model
The specific process of proxy re-encryption is as follows:
(1) At initialization, each communication client must request its own encryption public-private key pair (PK, SK) from the Key Generation Center (KGC).
(2) KGC uses the sender client’s private key
and the receiver’s public key
as input to generate the proxy re-encryption key
and securely transmits it to the proxy server.
(3) The sender encrypts the plaintext message m using its public key
to obtain ciphertext
and uploads it to the proxy server.
(4) The proxy server uses the re-encryption key
to re-encrypt the ciphertext
and sends it to the receiver.
(5) The receiver uses its private key
to decrypt
to obtain the plaintext message m.
In conventional PRE schemes, the number of re-encryptions by the proxy is proportional to the number of recipients, consuming significant network resources, and the sender cannot perform fine-grained control over the re-encryption objects in the cloud.
2.5.2 MQTT Based on Proxy Re-Encryption Technology
Literature [6] presents a solution for achieving end-to-end data security transmission between publishers and subscribers in MQTT communication based on proxy re-encryption technology, as shown in Figure 14. In this solution, the KGC matches the registered attributes (publish/subscribe) of devices with topics, pre-generating re-encryption keys for each pair of publisher-subscriber peers and securely sending the generated re-encryption keys to the broker.
Figure 14 MQTT Based on Proxy Re-Encryption
At initialization, clients must apply to KGC for their own encryption public-private key pairs and signing public-private keys, used for distributing session keys and signing messages. Among them, the signing public key serves as the unique identity of the client, while the actual key for encrypting messages is the session key.
The specific implementation process of MQTT based on proxy re-encryption technology is as follows:
(1) The sending client
generates a session key key, encrypts it using its encryption public key PKEnci to obtain ciphertextCkeyi.
(2)
uses its signing private key
to sign the message to be published, obtaining
and encrypts using key
(3)
the ciphertext message, Ckeyi, and its unique identity UUIDi (signing public key) to the broker.
(4) The broker queries which clients subscribed to the topic of that message and uses the corresponding re-encryption key
to re-encrypt
to obtain the session key ciphertext
and sends it to the receiver.
(5) The broker uses keyi to re-encrypt session key ciphertext 1, obtaining session key ciphertext 2.
(6) The broker pushes the ciphertext message, Ckeyj, and sender UUIDi to the corresponding receiving client
(7)
first uses its private key SKDecj to decrypt Ckeyj to obtain the session key key, and then uses key to decrypt the message to obtain
(8)
validates the effectiveness of UUIDi.
3
MQTT Protocol Security Reinforcement Framework
3.1. Comparison and Summary
Consider an MQTT communication network with 1 message sender and n message subscribers. Let E represent encryption, D represent decryption, and T represent key distribution/key transfer protection (decrypting and encrypting the key once constitutes a complete T). This paper uses the number of operations occurring in the above to intuitively measure the overhead of each scheme, with the comparison results shown in Table 3.
As shown in Table 3, the TLS protocol is a mature network layer security communication solution and is transparent to the application layer MQTT protocol; however, the traditional TLS protocol incurs significant overhead when applied in IoT environments. Although the AugPAKE protocol reduces the overhead of the authentication process to some extent, once authentication is complete, the data transmission protection methods of scheme 1 and scheme 2 are identical.
The last three schemes in Table 3 complete the authentication process in advance, and only clients that have been authenticated can obtain the message decryption key to decrypt the message.
Table 3 Comparison of Five Schemes
In the topic-based encryption scheme, Mektoubi et al.’s scheme is based on asymmetric algorithms, requiring the distribution of private keys, and the efficiency of asymmetric encryption and decryption is not high. This paper presents a topic encryption and key derivation based on symmetric algorithms, maintaining the amount of keys not more than that of Mektoubi et al.’s scheme, while achieving higher encryption and decryption efficiency.
Attribute-based encryption can effectively implement one-to-many data distribution and control access to data, which is the greatest advantage of scheme 4 compared to other schemes. This paper presents an attribute encryption scheme based on KP-ABE, which, compared to the CP-ABE recommended in literature [4], although it cannot be controlled by data owners over data access, is more suitable for the MQTT protocol’s subscription-push mechanism, yet its essence is still to control access to the topic key.
Scheme 5 has the advantage over other schemes that the proxy re-encryption technology can effectively solve the trustworthiness issue of the broker. The key for encrypting the message is generated by the data owner, and the broker cannot access the plaintext data. However, scheme 5 remains a one-to-one solution, requiring different re-encryption keys for sharing with different users.
3.2. Framework
Based on the analysis above, the MQTT protocol security reinforcement framework is illustrated in Figure 15.
Figure 15 MQTT Protocol Security Reinforcement Framework
A secure protocol requires support from underlying cryptographic algorithms and infrastructure. All public key encryption-based schemes can be transformed into symmetric encryption schemes using digital envelope technology. Therefore, for the encryption of the messages themselves, lightweight block cipher algorithms suitable for embedded devices should be primarily used, such as the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) lightweight block cipher standards: PRESENT, CLEFIA[8], and LEA[9]. The working modes of block ciphers can adopt Galois Counter Mode (GCM) or Counter with CBC-MAC (CCM) to achieve both confidentiality and integrity of communication data simultaneously.
Public key cryptographic algorithms are mainly used for key distribution. Elliptic Curve Cryptography (ECC) algorithms are lighter than RSA and other algorithms, while Identity-Based Encryption (IBE), Attribute-Based Encryption (ABE), and Proxy Re-Encryption (PRE) encryption schemes are mostly constructed based on bilinear mapping of ECC. To provide management of public key cryptographic algorithms and functions such as identity authentication, CA and KGC cryptographic services must be used.
The traditional TLS protocol is too burdensome for IoT devices. Lightweight TLS protocols designed for embedded devices have emerged, such as literature [10] using certificate-free public key cryptography to reduce the overhead during authentication, and literature [11] proposing lightweight SSL frameworks from aspects like algorithms and key updates, along with embedded open-source SSLv3 protocol stacks designed for small applications and devices, such as MatrixSSL.
Given the centralized, subscription mechanism of the MQTT protocol and one-to-many communication characteristics, the choice of application method should be comprehensively determined based on specific business needs and security focus points. Generally, a lightweight TLS protocol is sufficient at the network layer. Other lightweight password authentication key exchange protocols can also be applied, including AugPAKE, as well as symmetric password-authenticated key exchange protocols (SPAKE), Katz, Ostrovsky, and the KOY protocol proposed by Yung.
For scenarios equipped only with traditional cryptographic capabilities, such as Public Key Infrastructure/Certificate Authority (PKI/CA) and Identity-Based Cryptography (IBC), topic-based encryption can be rapidly implemented. For scenarios requiring data sharing and fine-grained permission control, KP-ABE can meet the needs. For scenarios with high user privacy requirements, proxy re-encryption technology is the most appropriate. However, the non-traditional cryptographic systems mentioned above also have significant drawbacks, such as computational complexity and unfriendliness to resource-constrained devices.
4
Conclusion
This paper researches and compares security reinforcement methods for the MQTT protocol and proposes a general security reinforcement framework for the MQTT protocol. This framework is not only applicable to the MQTT protocol but also has certain enlightening significance for the security reinforcement of other IoT protocols and for privacy data sharing in cloud environments and blockchain distributed scenarios.
Reference Format
Reference Format: Zhang Shiyi, Zhu Haojie, Huang Minghao, et al. Research on Security Reinforcement of MQTT Protocol [J]. Communication Technology, 2022, 55(12): 1626-1635.
Business Cooperation | Reprint | Media Communication | Council Services
Please contact: 15710013727 (WeChat same number)
“Information Security and Communication Confidentiality” Magazine Submission
Contact number: 13391516229 (WeChat same number)
Email: [email protected]
“Communication Technology” Magazine Submission
Contact number: 15198220331 (WeChat same number)
Email: [email protected]