Security Architecture and Protocols for Secure MQTT-SN

Message Queuing Telemetry Transport (MQTT) is a de facto standard for various Internet of Things (IoT) and industrial IoT applications. The data produced by a publisher are delivered to several subscribers via an MQTT broker. However, the MQTT standard lacks security-related functionalities, such as mutual authentication, access control, control message security, and end-to-end security. According to a recent report, many security threats and flaws associated with MQTT have been identified worldwide. This paper proposes security architecture and protocols to bootstrap MQTT security in the wireless sensor network. Security bootstrapping for MQTT includes security credential generation and distribution; registration protocol for joining MQTT entities such as publishers, subscribers, and brokers to the security controller; and rekeying protocol for group membership management. Special attention is given to the end-to-end security between the publishers and subscribers because the data from the publishers should not be corrupted by, and exposed to, the compromised broker. Both security analysis and performance evaluation show that our proposed security architecture and protocols for secure MQTT can be a viable solution to enhance MQTT security.


I. INTRODUCTION
Machine-to machine (M2M) protocols are key technology that significantly contribute to the fast development of Internet of Things (IoT) and industrial IoT (IIoT). Of the various existing M2M protocols, the most prevalent ones include constrained application protocol (CoAP) [1] on the client-server model and message queuing telemetry transport (MQTT) [2] on the publish-subscribe model. M2M technology based on CoAP or MQTT is found in various sectors [3][4][5][6][7], such as manufacturing, public administration, environment, building automation, and healthcare. CoAP provides a direct channel between a client and a server for data/command delivery, while MQTT provides an indirect channel (via a broker) between the publishers (producing data) and subscribers (consuming data). In MQTT, when receiving the data produced by publishers, the broker classifies them by topics and sends them to the subscribers who subscribe to the topics.
The associate editor coordinating the review of this manuscript and approving it for publication was Kok-Lim Alvin Yau .
In particular, MQTT-SN (sensor network) [8] is optimized for the resource-constrained devices with limited processing and storage resources, so that the MQTT-SN header and payload structures are simple and short in length relative to MQTT.
Even though MQTT has become an OASIS standard, it lacks basic security-related functionalities such as access control, mutual authentication, and control message security. The only security functionality supported by the MQTT standard is unilateral authentication based on the pre-shared password. However, as no secure channel is provided between each device (publisher/subscriber) and the MQTT broker, various security issues [9], [10] have recently been raised. To address them, current implementations for MQTT [11]- [13] support transport layer security (TLS) to create a secure channel between each device and the MQTT broker. However, TLS does not provide fine-grained access control.
In this study, we investigate an adversarial model: adversaries might compromise the MQTT broker, which has not been considered in the previous works on the MQTT-SN security. Under such an adversarial model, the end-to-end security between the publisher and the subscriber should be required. Associated with end-to-end security, two security models for the MQTT broker are defined: malicious broker model and honest-but-curious broker model. The broker on both models can intercept the data exchanged between the publisher and subscriber, while the broker can additionally deviate from the normal MQTT-SN execution on the malicious broker model. As sensitive information is stored in the MQTT broker along with the security credentials of both publishers and subscribers, a security framework for a variety of secure MQTT-SN applications is indispensable, particularly when the MQTT-SN service is provided using the MQTT broker owned by the third-party operator, The contribution of this paper is as follows: first, having two security models for the MQTT broker in mind, we design a security architecture for MQTT-SN, which is a fundamental security framework to support both fine-grained access control and the end-to-end security. Second, we introduce the concept of topic certificate to establish a direct secure channel between a publisher and a set of subscribers, based on which the end-to-end security can be attained. Third, a couple of security protocols are designed to embed the basic securityrelated functionalities (such as mutual authentication and the control message security) into the standard MQTT-SN control messages, without depending on the TLS. Further, we identified various DoS attacks that can be suppressed by providing the control message security. Fourth, considering that the subscribers are group members interested in a certain topic, the rekeying mechanism is designed to revoke subscribers from the group whenever a group membership is changed. Finally, for performance evaluation, we have implemented our security mechanism proposed for MQTT-SN on the Contiki OS and Cooja simulator. It is shown that our proposed security mechanism added for secure MQTT-SN does not induce a big overhead to hinder a normal MQTT-SN execution.
In Section II, several security issues related to MQTT-SN, as well as previous works, are reviewed. The security architecture and protocols for MQTT-SN are introduced in Section III and IV, and the rekeying mechanism for topic membership change is proposed in Section V. Security analysis and performance evaluation are given in Sections VI and VII, respectively.

II. MQTT-SN SECURITY AND RELATED WORK A. MQTT-SN AND SECURITY REQUIREMENTS
Each publisher can publish their data on a topic to the MQTT broker that maintains a prescribed set of topics (Topic 1 , Topic 2 . . .). Subsequently, it publishes it to any subscriber subscribing to the topic as shown in Fig. 1. There are many MQTT-SN control messages such as connect, publish, subscribe, and pingreq for both publication and subscription, and the connection establishment and maintenance.
There are several security issues to be addressed for secure MQTT-SN: mutual authentication, access control, control message security, and end-to-end security. First, a mutual authentication between a device (publisher/subscriber) and a broker should be performed when the device attempts to connect with the broker. Additional to device authentication, broker authentication is indispensable because the device might be lured into a bogus broker.
Second, as each device can publish and subscribe on a prescribed set of topics, fine-grained access control should be enforced for each device. Even if the device is successfully authenticated to the broker, its attempt to publish/subscribe to the topics that are not authorized should be blocked. Hence, it is required for the broker to maintain a type of access control list (ACL) or to query the privilege of the device to the external server.
Third, the confidentiality and integrity of the data sent through the publish control message should be guaranteed. Depending on the security requirement of the application, the confidentiality service can be optional. Hence, two security associations should be established between the publisher and the broker, the subscriber and the broker, which means that the encrypted data sent from the publisher are decrypted and re-encrypted before being forwarded to the subscriber.
Fourth, each of the MQTT-SN control messages contains several control fields to handle the normal MQTT-SN publish-subscribe operations. When an adversary maliciously modifies some of them, an abnormal MQTT-SN operation can be induced, resulting in various DoS attacks. A couple of examples are given in Section VI.B.
Finally, if the broker is compromised, the data stored inside it can be revealed to an adversary. Furthermore, the security credentials shared with the devices can be exposed to the adversary. Hence, if the end-to-end security between the publishers and subscribers can be attained, the effect of attacking the broker can be minimized.

B. PREVIOUS STUDIES ON MQTT-SN SECURITY
Most of the previous studies on MQTT/MQTT-SN security focused on MQTT security, where both the publishers and subscribers were assumed not to be resource-constrained. They can be categorized as follows.
First, an intuitive solution is to apply TLS to secure the communication channel between the clients and the broker. VOLUME 8, 2020 As the resource-constrained devices publishing the topic data cannot connect directly with the broker when TLS is applied, an intermediate node can be positioned between them [15], [16]. Namely, the intermediate node collects the sensing data from the resource-constrained devices. However, no security mechanisms have been suggested to secure the interface between the resource-constrained nodes and the intermediate node.
Second, as TLS is a general-purpose security protocol comprising several stages, it is not efficient for a specific application protocol such as MQTT. Depending on a password-based authenticated key exchange protocol, called AugPAKE [17], two schemes, AugMQTT [18] and MQTT-Auth [19], have been proposed for securing the topic data from an unauthorized eavesdropper. Two session keys are established by executing AugPAKE between a publisher and a broker: a broker and a subscriber. Thus, the broker should decrypt the encrypted data sent from the publisher, and then re-encrypt and send it to the subscriber, which means that the topic data are stored unencrypted on the broker side. Furthermore, they are not suitable for MQTT-SN because of their heavy computational load and message exchanges.
Third, considering the constrained property of MQTT-SN, a couple of schemes [20], [21] using the lightweight cryptography has been proposed for mutual authentication between a device and a broker, and for authenticating the topic data. Assuming each device and a broker obtain the other's elliptic curve public key beforehand, a session key can be derived between them for securing the subsequent publish messages [20]. On the other hand, [21] has proposed a hashbased authentication scheme for the end-to-end integrity of the topic data. Given a range of possible values for a certain topic data (e.g. temperature) from a publisher, the publisher computes a HMAC-value based on the topic data and a symmetric key shared with the subscribers. When receiving it, the subscriber computes all the possible HMAC-values and compares them with it to find the topic data value. However, it is vulnerable to the replay attack.
Finally, for establishing an end-to-end security between the publishers and subscribers, several security mechanisms [22], [23] have been proposed based on attribute-based encryption (ABE) [24], where the publisher encrypts data based on a set of conditions in terms of the access policy, and subsequently, the subscribers can decrypt the ciphertext if it satisfies the access policy. On the other hand, [25] has proposed a security mechanism, assuming that the MQTT-SN gateway is positioned between the publisher and the broker. Based on the pre-shared secret key for end-to-end security between the publisher and the subscriber, the topic data is encrypted and authenticated using the AEAD (Authenticated Encryption with Associated Data)-CHACHA 20-POLY1305.

A. NETWORK/SERVICE MODEL AND DESIGN PRINCIPLES
We adopt the network/service model of Fig. 2 consisting of several application service providers (ASPs) and broker service providers (BSPs). Each ASP installs its own publishers and subscribers to a variety of customers such as homes, utility companies, or factories. On the other hand, there are two types of BSPs: the one is a private BSP such that it is owned by a specific ASP. The other is a third-party BSP with which each ASP makes a contract for MQTT broker service. In this paper, a third-party BSP is assumed to be employed by the ASP.
For our proposed security architecture, each ASP maintains an entity, ''MQTT Security Management Server (MSMS)'', which comprises two components: access controller (AC) and certificate authority (CA). The CA issues both device certificate and topic certificate to each resourceconstrained device (publisher/subscriber), while the AC defines and enforces a fine-grained access control for devices. The MSMS coordinates with the devices and the broker at each stage shown in Fig. 3 for security bootstrapping.
During the ''Initialization'' stage, the device certificate is generated and installed into each device including the broker. Based on it, both mutual authentication and session key exchange can be performed between each device and the broker for a secure MQTT-SN. The ''Registration'' stage is for distributing the access control list (ACL) to the broker (Broker Registration) and the topic certificate to each device (Device Registration). Then, the ''Secure MQTT-SN'' stage starts for secure publication and subscription, which will be detailed in Section IV. When the topic membership change occurs among a set of subscribers authorized to access a specific topic, both the topic key update and ACL update are performed during the ''ReKeying'' stage, which will be also more detailed in Section V.
Let P = {P 1 , P 2 , . . . } and S = {S 1 , S 2 , . . . } be sets of authorized publishers and subscribers, respectively, and T = {Topic 1 , Topic 2 , . . . } be a set of valid topic names to be enrolled at the broker. The AC prepares the access control list (ACL) according to its pre-determined access policy.
Definition 1 (Access Control List (ACL)): Let P(Topic t ) ⊆ P and S(Topic t ) ⊆ S be sets of publishers and subscribers authorized to access Topic t . Then, ACL = {ACL t | Topic t ∈ T }, where ACL t = {Topic t , P(Topic t ), S(Topic t )}.
For example, ACL 2 = {Topic 2 , P(Topic 2 ) = {P 1 }, S(Topic 2 ) = {S 1 , S 2 }} denotes that the data published on Topic 2 by P 1 are delivered to S 1 and S 2 , as shown in Fig. 4.  During the Broker Registration stage, the AC passes ACL = {ACL t | Topic t ∈ T } to the broker, based on which the broker can enforce fine-grained access control. Hence, P x cannot publish its data on Topic t if P x / ∈ P(Topic t ), while S y cannot subscribe to Topic t if S y / ∈ S(Topic t ). In this paper, it is assumed that each publisher can publish its data to only one topic name, while each subscriber can subscribe to more than one topic names. However, more than one publisher can publish their data to a single topic name. It is also assumed that |P(Topic t )| |S(Topic t )|. Considering the application scenario such as industrial automation systems, they are the reasonable assumptions.
Assumption: Let T (P i ) ⊆ T and T (S j ) ⊆ T be sets of topic names, which P i and S j can access, respectively. Then, Table 1 shows the notations used throughout this paper.

B. INITIALIZATION FOR DEVICE CERTIFICATE ISSUANCE
A lifecycle of the resource-constrained devices comprises the following stages (manufacturing/deployment/operational).
During the deployment stage, the security credentials for the publishers, subscribers, and the broker are installed into them. The security credential for each device consists of both device certificate and topic certificate, each of which is for the device identification and end-to-end security, respectively, when the secure MQTT-SN is initiated. Both certificates are constructed based on the Elliptic Curve Qu-Vanstone (ECQV) certificate [26], [27], which is particularly well-suited for application environments where resources such as bandwidth, computing power, and storage are limited. It is much smaller (tens of bytes) than the X.509 certificate.
Definition 2 (EC Domain Parameters (p, a, b, G n)): An elliptic curve E(F p ) over a finite field F p , where p is a prime, is a set of points satisfying y 2 ≡ x 3 + ax +b (mod p). The EC-domain parameters are denoted by (p, a, b, G, n), where n is a large prime divisor of the order of the curve E(F p ) and G is a base-point generator with the order of n.
As shown in Procedure 1, the AC performs an ECQVcertificate-issuance protocol with the CA on behalf of X (= P i , S j , Broker(B)), as a result of which a device certificate of X (Cert X ) and the device-private-key (d X ) are generated.
Procedure 1 (Device Certificate Issuance): on input (X ) call genDeviceCert (·) / * defined in Appendix 1 * / output (d X , Cert X ) Suppose a pair of the private and public keys of the CA are given: An ECQV certificate comprises a device's identity and some reconstruction public data, which together with the CA's public key are used to reconstruct the device-public-key. That is, the devicepublic-key is not explicitly contained in the implicit certificate Cert X . The device-public-key of X can be computed by any entity, starting from D CA and Cert X , as in Procedure 2.

C. REGISTRATION FOR TOPIC CERTIFICATE ISSUANCE
A topic certificate for each Topic t ∈ T is defined for attaining end-to-end security between P(Topic t ) and S(Topic t ). The AC also performs another ECQV-certificate-issuance protocol with the CA on behalf of X (= P i , S j ), as shown in Procedure 3 whose basic framework is the same as that shown in Procedure1. The only difference between them is that Topic t is used as input instead of X . Especially, the topic certificate for Topic t should be updated whenever a change in the topic membership for Topic t occurs (l = 0, 1, 2, . . . ), where l = 0 denotes an initial topic certificate issuance.
Topic t ], the topic-public-key of Topic t can also be computed, using genPub(D CA , Cert t , and the associated topic-private-key and topic-publickey are d t ] to P(Topic t ) and S(Topic t ), respectively, the AC performs a Device Registration protocol with each of them. On the other hand, the AC also performs a Broker Registration protocol with the broker to distribute the ACL. As shown in Procedure 4, the Device/Broker Registration is for the AC to deliver the topic certificate securely to X = (P i / S j ), together with where IP B and Port B denote the broker's IP address and port number, respectively.
For each Topic t ∈ T (when l= 0), send Info B ] to each X ∈ S(Topic t ). As a concrete example, Fig. 5-(B) shows the result of the registration.
Both Device and Broker Registration protocols are performed only once to create an initial security association between X = (P i / S j /B) and the AC. Both protocols can be protected with the datagram TLS (DTLS) [28]. Among the several security modes supported by DTLS, the PSK mode is the most efficient, so the device certificates can be employed to derive the PSK, as shown in Appendix 4.

IV. PROPOSED SECURE MQTT-SN PROTOCOL
The original MQTT-SN protocol introduced in Section II.A is modified to embed the security features: mutual authentication, access control, control message security, and end-to-end security for the topic data, without employing the TLS/DTLS.

A. OUTER SECURE CHANNEL FOR MQTT-SN CONTROL MESSAGES
After Initialization and Registration stages, each publisher (X = P i )/subscriber (X = S j ) creates an outer secure channel with the broker (B) through exchanging both connect and connack control messages, as in Fig. 6. Namely, an authenticated key exchange (Fig. 7) is performed for mutual authentication and session key derivation. Procedure 5 shows how the session key (SK X ) can be derived based on Elliptic Curve Diffie-Hellman (ECDH) key agreement. Then, subsequent control messages can be securely exchanged through the outer secure channel.
Procedure 5 (Session Key Derivation): A session key SK X is generated to create an outer secure channel between X (= P i /S j ) and B: given and TS X is a timestamp value generated by X . In Fig. 7, the connect control message protected with MIC(SK X ) is sent to the broker, where ''. . . '' denotes the original message fields of standard connect control message and MIC(SK X ) denotes a message integrity code computed with SK X for all preceding fields in the message. When receiving it, the broker also derives the session key SK X and verifies if TS X is fresh (TS X > TS X * ) and MIC(SK X ) is valid. TS X * is a previous timestamp value generated by X , which is maintained by the broker. If the verification is successful, a session state for X is created at the broker and the broker responds with the connack control message protected with MIC(SK X ). The successful verification of MIC(SK X ) by X means the outer secure channel between them is created. From now on, the MQTT-SN control messages such as publish, subscribe, and pingreq can be securely exchanged.

B. INNER SECURE CHANNEL FOR END-TO-END SECURITY
Suppose P i publishes data on Topic t , which will be delivered to S j ∈ S(Topic t ) via the broker (B). For the end-to-end security between the publisher and subscriber, the date should be encrypted.
Definition 3 (End-to-End Security): The data to be published should be exposed only to the authorized subscribers. So, even the broker should not be accessible to the data. The source authentication should be also provided such that each authorized subscriber can verify which authorized publisher generates the data.
A topic key is defined to encrypt the data symmetrically, which can be derived from the topic certificate and the device certificate of the authorized publisher. It can be derived as in Procedure 6.
Procedure 6 (Topic Key Derivation): A topic key is defined for the end-to-end security between a publisher P i ∈ P(Topic t ) and a group of subscribers S(Topic t ).
t ] maintained by P i and S(Topic t ), respectively, The topic key for Topic t is also derived based on Elliptic Curve Diffie-Hellman (ECDH) key agreement: For example, as shown in Fig. 8, both P 1 and P 2 can publish a data on Topic 9 , while S 3 , S 4 , and S 5 can subscribe to Topic 9 and receive the data. Hence, the publishers know the topic certificate Cert  1 ) is employed to secure the data on Topic 9 published by P 1 . On the other hand, the data on Topic 9 published by P 2 is secured by the topic key K for P i , Cert i , TS i , and (data)K (1) it , which means that an inner VOLUME 8, 2020 secure channel in Fig. 6 is created for ''data'' to be delivered from P i to S j ∈ S(Topic t ).
When receiving the publish control message, the broker first checks if P i ∈ P(Topic t ) based on ACL t = (Topic t , P(Topic t ), S(Topic t )), and verifies if MIC(SK i ) is valid. If both verifications are successful, the broker stores secured_data until it is requested by the subscribers in S(Topic t ). Then, the broker sends the publish control message to S j ∈ S(Topic t ).
publish (Topic t , secured_data, . . . , MIC(SK j )) After checking MIC(SK j ), each subscriber in S(Topic t ) derives the topic key K (1) it using d (1) t and D i = genPub(D CA , Cert i , P i ), based on which MIC(K (1) it ) can be verified and ''data'' can be obtained.

V. REKEYING PROTOCOL FOR TOPIC MEMBERSHIP CHANGE
A. TOPIC CERTIFICATE, TOPIC KEY, AND TOPIC MEMBERSHIP ACL = {ACL t | Topic t ∈ T }, where ACL t = (Topic t , P(Topic t ), S(Topic t )), is managed by the AC and passed to the broker. Whenever a topic membership change in S(Topic t ) occurs, namely from S(Topic t ) to S * (Topic t ), the AC updates ACL t and notifies the broker about it. Furthermore, the topic key derived from the topic's private and public keys are updated. As the topic-private-key is shared among S(Topic t ), the AC generates and distributes a new topic-private-key to each subscriber in S * (Topic t ). In addition, a new topic-publickey (topic certificate) is also distributed to each publisher in P(Topic t ).  Figure 9 shows an example rekeying protocol when a subscriber no longer subscribes to a topic. Suppose ACL 9 = (Topic 9 , P(Topic 9 ) = {P 1 , P 2 }, S(Topic 9 ) = {S 3 , S 4 , S 5 }), namely the data published on Topic 9 by P 1 and P 2 are delivered to S 3 , S 4 , and S 5 . The AC generates a topic certificate Cert (0) 9 and the topic-private-key d (0) 9 for Topic 9 for the first time (l = 0), as in 0 of Fig. 9. Then, {Topic 9 , Cert (0) 9 } is sent to P 1 and P 2 , while {Topic 9 , d (0) 9 } is sent to S 3 , S 4 , and S 5 during the Device Registration stage. Suppose S 5 leaves from a group of subscribers S(Topic 9 ). Then, the AC generates a new topic certificate Cert (1) 9 and the associated topic-private-key d (1) 9 , which should be securely delivered to {P 1 , P 2 } and S * (Topic 9 ) = {S 3 , S 4 }, respectively, as in of Fig. 9.

B. REKEYING TOPIC CERTIFICATE AND TOPIC-PRIVATE KEY
To update the topic-public-key for Topic 9 from D (0) 9 to D (1) 9 , the AC multicasts (P i ⇐ AC) an updateReq message to each P i in P(Topic 9 ), as in Protocol 1. To guarantee the integrity of the multicast message, a group key is defined.
Definition 4 (Group Key For Multicast Message): A group key(GK t ) is defined for each Topic t ∈ T to secure the updateReq message sent from the AC. It should be shared in advance among the publishers in P(Topic t ). For this purpose, [Topic t , Cert (1) t , Info B , GK t ] is sent to each X ∈ P(Topic t ) during the Device Registration in Procedure 4.
When receiving it, each P i checks if MIC(GK 9 ) is valid, where GK 9 is a group key shared among P(Topic 9 ). If the verification is successful, each P i responds with an updateRsp message protected with MIC(PSK i ) and derives D (1) 9 = genPub(D CA , Cert (1) 9 , Topic 9 ), where PSK i has been derived to secure the Device Registration of Procedure 4. The AC should keep multicasting the updateReq message until it receives the updateRsp messages from all publishers in P(Topic 9 ). It will be shown in Section VII that the number of multicast retransmissions under an unreliable UDP communication is not high even when the number of publishers in P(Topic 9 ) is large.
9 , MIC(GK 9 )) P i → AC: updateRsp (Cert (1) 9 , MIC(PSK i )) To update the topic-private-key for Topic 9 from d (0) 9 to d (1) 9 , the AC sends it in unicast to each subscriber S j in S * (Topic 9 ) = {S 3 , S 4 }, as in Protocol2. To secure the update protocol, a secure channel is created between the AC and S j based on DTLS with the PSK mode, where the PSK is PSK j derived to secure the Device Registration of Procedure 4. As it is assumed that |P(Topic t )| |S(Topic t )| in Section III.A, it is feasible for the AC to establish a separate DTLS session with each subscriber in S * (Topic 9 ).

VI. SECURITY ANALYSIS AND DISCUSSIONS A. ADVERSARIAL MODEL FOR SECURE MQTT-SN
In addition to devices (publishers/subscribers) and MQTT broker, the MSMS (AC/CA) is an entity that also interacts with them, and it is introduced for the proposed security architecture and associated protocols. However, as the MSMS is only involved with the (device/topic) certificate issuance and update operations, it does not participate in the proposed Secure MQTT-SN protocol.
An adversarial model for the proposed Secure MQTT-SN is based on the following assumptions: it is assumed that the adversary can control the communication path between the devices and the broker. It is also assumed that the MSMS is not compromised. However, the device might be compromised, such that it can also attempt to forge other device certificates based on its device certificate. Especially, the device leaving from a group of subscribers subscribing to a specific topic can attempt to access the topic data.
Considering that the broker might be compromised, two adversarial models for the broker are defined: honest-butcurious broker and a malicious broker. The broker on both models can intercept the data exchanged between the publisher and subscriber, while the broker can additionally deviate from the normal MQTT-SN execution on the malicious broke r model, which will be more detailed in Section VI.D.

B. DOS ATTACK AND COUNTERMEASURE
If the integrity of each MQTT control message is not guaranteed, various DoS attacks can be mounted against the MQTT publication and subscription protocols. As examples in this subsection, ''keep alive'' timer and ''topic name/topic identifier'' of MQTT are investigated to explain a possible DoS attack that can be mounted if the integrity of connect and subscribe control messages is not guaranteed.
First, even if a 2-byte ''keep alive'' timer field is not shown in the connect control message as in Fig. 7, it is the maximum time interval, measured in seconds, permitted to elapse between the point at which the device finishes transmitting one MQTT control message and that at which it starts sending the next. It is the responsibility of the device to ensure that the interval between MQTT control messages being sent does not exceed the ''keep alive'' value. In the absence of sending any other MQTT control message, the device must send a pingreq control message before the ''keep alive'' value expires. Suppose that the ''keep alive'' timer field of the connect control message is set to 30, which means that the device should send a pingreq control message if no messages are exchanged between the device and the broker within 30 s. When the ''keep alive'' timer value is maliciously modified from 30 to 0, a connection between them is never established.
Second, subscribe and suback control messages contain a topic name Topic t and a topic identifier Tid t , respectively, for using a compact 2-byte topic identifier instead of a long human-readable topic name. For example, if Tid t corresponding to Topic t (device A 's temperature) is changed to Tid * t corresponding to Topic * t (device B 's temperature), the subscriber happens to receive the wrong data from the unintended publisher.

C. SECURITY OF DEVICE AND TOPIC CERTIFICATES
The proposed device and topic certificates are constructed based on the ECQV certificate, and the basic security of the ECQV certificate has been given in [14]. As these certificates are securely generated between the CA and AC inside MSMS, the certificates (Cert X , Cert (1) t ) and the implicit signatures (w X , w (1) t ) in Appendix 1 and 3 are not exposed even to the authorized devices.
However, when issuing a device certificate Cert X (X = P i , S j , B), both AC and CA should use a distinct random number (r X , r AC ) for each device certificate. Otherwise, the private key of CA, d CA , can be exposed if more than two devices collide. Suppose d 1 , d 2 , and d 3 are the device-private-keys of S 1 , S 2 , and S 3 , respectively, such that d j = d CA + r CA · H (Cert j ||S j )+ r j · H (Cert j ||S j ) for j = 1, 2, 3. If r CA is fixed and r 1 = r 2 = r 3 , then they can derive d CA from the above equations. This restriction also holds when the topic certificate is generated. Furthermore, it is not feasible for an adversary, or even X (= P i , S j , B), to derive a new device certificate (Cert X , X * ) from its own device certificate (Cert X , X ), namely to replace X by X * , without changing Cert X and d x . Hence, the adversary cannot disguise another entity. We show this in Proposition 1.
Proposition 1: Similarly, it is also infeasible to derive a new topic certificate (Cert (1) t , Topic * t ) from a given topic certificate (Cert (1) t , Topic t ), namely, to replace Topic t by Topic * t , without changing Cert (1) t and d (1) t . Its proof is omitted because it is the same as that of Proposition 1.

D. HONEST-BUT CURIOUS AND MALICIOUS BROKER
In this subsection, two security models for the broker are defined: an honest-but-curious broker and a malicious broker. The honest-but-curious broker behaves normally according to the MQTT protocol but attempts to acquire the topic data for its own purpose. In this case, it is enough for P i and S j ∈ S(Topic t ) to generate and process secured_data = [P i , Cert i , TS i , (data)K (1) it , MIC(K (1) it )], respectively, to attain endto-end security. As the only information the broker maintains is {(d B , Cert B , D CA ), ACL}, where ACL t = (Topic t , P(Topic t ), S(Topic t )), the broker cannot derive data from secured_data.
Meanwhile, the malicious broker is completely controlled by an adversary such that it deviates from the normal execution of the MQTT protocol and behaves according to the adversary's command. Hence, in addition to acquiring the topic data, the broker can override the original ACL and relay the topic data from a specific publisher to a specific group of subscribers for its own purpose. In this case, a minor modification to our security mechanism proposed in Section IV is required to attain end-to-end security. Proposition 2 shows the justification of such a modification.
Proposition 2: Under the malicious broker model, secured_data for Topic T generated by P i / ∈ P(Topic T ) can be maliciously delivered to, and accepted by, S(Topic T ).
Proof: Given a topic private/public key pair (d (1) T , D T ) for Topic T and a device private/public key pair (d I , D I ) of P I , if P I ∈ P(Topic T ), then P I can generate secured_data iT )] generated by P i cannot be delivered to S(Topic T ) due to the ACL, where K T · D i ) and D (1) T is a public information. However, under the malicious broker model, secured_data generated by P i can be delivered to S(Topic T ). When receiving it, S J ∈ S(Topic T ) derives K T · D i ) from {P i , Cert i } and obtains data from secured_data. A main reason it is feasible is that S J cannot check whether P i is authorized to publish the topic data for Topic T .
As shown in Proposition 2, it is necessary for S J to determine if P i is eligible to publish such topic data. Procedure 1 in Section III.B and Appendix 1 show how to generate the device certificate of P i . It is modified as follows: given Hence, to generate the device-public-key, ''P i || Topic t '' should be used instead of ''P i '': namely, D i = genPub(D CA , Cert i , P i || Topic t ). Through such a modification, secured_data = [P i , Cert i , TS i , (data)K (1) iT , MIC(K (1) iT )] generated by P i cannot be accepted by S J ∈ S(Topic T ), because ∼ K

E. FINE-GRAINED ACCESS CONTROL FOR TOPIC DATA
As shown in the previous subsection, it is not feasible for any authenticated publisher P i / ∈ P(Topic T ) to publish a topic data for Topic T , even under the malicious broker model. Meanwhile, any subscriber S k / ∈ S(Topic t ) cannot have access to secured_data from P i for S(Topic t ) either, because the broker does not send it to S k . Moreover, under the malicious broker model, it cannot be decrypted by S k because the topic key K (1) it is not derivable by S k . Furthermore, if a subscriber S j is revoked for Topic t , secured_data for S(Topic t ) is no longer accessible to S j , as shown in Proposition 3.
Proposition 3: Once a subscriber S j is revoked for Topic t , secured_data for S(Topic t ) is no longer accessible. (Proof in Appendix 5)

VII. PERFORMANCE EVALUATION A. NETWORK TOPOLOGY AND MQTT-SN MESSAGE STRUCTURE
MQTT-SN is implemented within the wireless sensor network. The IETF prescribes a wireless sensor network as a low-power wireless personal area network (LoWPAN), and IEEE 802.15.4 [29] is a de facto standard for MAC/PHY layer of the LoWPAN. Meanwhile, 6LoWPAN [30] resolves an asymmetry between the LoWPAN and IPv6 Internet's processing capabilities so that the resource-constrained devices for sensing and actuation on LoWPAN can connect with the IPv6 Internet hosts through the 6LoWPAN border router (6LBR). Figure 10 shows the deployment of several MQTT-SN components in LoWPAN.  It is assumed that the LoWPAN is a static wireless sensor network and that the MQTT-SN client corresponds to the class 1/2 node [33]. For performance analysis and comparison, we have implemented the Secure Publication protocol based on the Contiki OS and the Cooja simulator. Figure 11 shows an MQTT-SN (control) message structure adapted to include our proposed security functionality, which is encapsulated with several headers (IEEE 802.15.4 header/trailer, IPv6 header, and UDP header). The MQTT-SN message comprises an MQTT-SN header and an MQTT-SN payload, where the MQTT-SN payload comprises various fields depending on the control message type (connect, connack, publish, puback, . . . ). The ''Security Fields'' in the dotted grey-colored box are added for our proposed security mechanism.
When an IPv6 packet with the MQTT-SN message travels within the LoWPAN, it is fragmented if an IEEE 802.15.4 frame is longer than 127 bytes, which induces severe latency in processing the IPv6 packet. However, when both IPHC and NHC compressions [31] are applied, the IPv6 header can be reduced from 40-byte up to 7-byte, and the UDP header can be reduced from 8-byte up to 2-byte so that more space can be reserved for the MQTT-SN payload for application without fragmentation. The secu- it )] require 20-byte, 8-byte, 16-byte, and 72-byte, respectively, assuming secp160r1 [32] for {Cert i / Cert j }, 8-byte P i (=ClientID), 8-byte TS i , and AES-CTR-128 for encryption of 16-byte data and AES-CBC-MAC-128 for MIC. Hence, our proposed security mechanism does not induce fragmentation. Table 2 shows the number of cryptographic operations for each of the six MQTT-SN control messages during the Secure Publication protocol. EC denotes an EC scalar multiplication for ECDH computation or EC public key computation genPub(·). HMAC denotes HMAC-SHA-1 for key derivation kdf(·), while CBC denotes AES-CBC-MAC-128 for MIC computation. AES denotes AES-CTR-128 for symmetric encryption. One advantage of AES over lightweight cryptographic ciphers such as PRESENT or HIGHT is that the state-ofthe-art motes (e.g. TI cc2538) support the hardware implementation of AES/SHA/ECC and the Cooja simulator also provides the mote type of cc2538. Although HMAC based on SHA is slower than CBC-MAC, HMAC-SHA-1 is used for the key derivation function recommended by NIST Special Publication 800-56C Revision 2 (Recommendation for Key-Derivation Methods in Key-Establishment Schemes).

B. CRYPTOGRAPHIC OPERATIONS FOR SECURE MQTT-SN
During the Secure Publication protocol, connect, connack, register, and regack control messages are exchanged only once. However, both publish and puback control messages are exchanged multiple times until the connection between the publisher and the broker terminates. Especially, EC and HMAC of publish control message are computed only once, even though multiple publish control messages are sent to the broker. Table 3 shows the average execution times (for 10 runs) of the cryptographic primitives employed for the secure MQTT-SN messages, where the message length and key length are set to 20 bytes and 16 bytes, respectively.

C. PERFORMANCE OF SECURE PUBLICATION PROTOCOL
In this subsection, the performance analysis on the proposed Secure Publication protocol, together with a comparison with that of the standard MQTT-SN, is given. As shown in Fig. 6, once the connection is established between a publisher and a broker, one or more datasets on a topic can be sent to the broker until its connection is terminated.
Even though the initial cryptographic computations for creating the security associations among the publisher, broker, and subscriber are introduced, the average computation burden per publish message decreases as the number of publish control messages increases. The power consumption for processing a series of MQTT-SN control messages (connect/connack/register/regack/publish/puback) is estimated using the Cooja's Powertrace. After both connection and registration phases are finished, the publish control messages are kept sending every 5 seconds. The result of estimation for the standard MQTT-SN and the proposed MQTT-SN is shown in Fig. 12, which is the overall energy consumption for the LoWPAN management, MQTT-SN message transmission/reception as well as the security-related operations.
Due to the security-related functionalities added to the proposed MQTT-SN, the overall energy consumption of the proposed one is relatively higher than that of the standard one. Especially in case of the proposed MQTT-SN, a high energy-consumption (dotted, red-colored box in Fig. 12-(b)) is indispensable since the initial ECC operations are required for preparing the connect control message. However, it is required only once during an entire MQTT-SN session. Since each publisher (sensor mote) also participates in the routing protocol (RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks) on the LoWPAN, the RPL control packets are regularly exchanged with one or more adjacent sensor motes. As shown in dotted, green-colored circles of Fig. 12, the energy consumption for processing the RPL  control packets is relatively higher than that of the securityrelated operations of the proposed MQTT-SN.
To estimate the cryptographic cost added to the proposed MQTT-SN, the cumulative energy consumption for preparing the connect/register/publish control messages including the initial ECC operations is compared in Fig. 13. The publish messages are sent every 5 seconds, and the energy consumption for pingreq and RPL control messages are not added to the cumulative energy consumption.

D. RELIABLE MULTICAST OVER INRELIABLE UDP
During the Topic-public-key update in Protocol 1, both updateReq and updateRsp messages are exchanged between several publishers in P(Topic t ) and the AC. A single updateReq message is sent in multicast to the publishers, while the updateRsp message from each publisher is sent in unicast to the AC. As both messages are sent over unreliable UDP, a reliability mechanism (a simple stop-and-wait retransmission) on the application level is required: namely, the AC keeps retransmitting the multicast updateReq message until the updateRsp messages are received from all publishers in P(Topic t ). Figure 14 shows two state transition diagrams of the publisher's and AC's behavior for our proposed retransmission mechanism. It is assumed that the AC has a list of publishers belonging to a multicast group P(Topic t ). After sending a multicast updateReq message, the AC enters a Wait state. Whenever receiving a unicast updateRsp message (Rcv_Rsp), it still remains in the Wait state and marks the source address of the message on the publisher list. If the sender of the received updateRsp message is the last one (Rcv_All_Rsp) on the publisher list, it enters a Done state and terminates the Topic-public-key update protocol.
However, if the AC does not receive all messages from all publishers within a pre-defined time interval (Timeout), it enters a ReTx state and retransmits the multicast updateReq message (Send_Req). Each publisher's behavior for the Topic public-key update protocol is shown in Fig. 14-(b). When receiving a multicast updateReq message (Rcv_Req), the publisher enters an Rsp state and sends a unicast updateRsp message. After sending it, the publisher returns to the Wait state. To see the effect of the packet loss on the retransmission mechanism, the packet loss is simulated as in Procedure 7:

Procedure 7 (Packet Loss Simulation):
Let ρ be a packet loss rate. rand ← random(·). If ρ < (rand mod 100)/100, then Send-Rsp. For example, when ρ = 0.3 and rand = 2312, the publisher does not send the updateRsp message and returns to the Wait state, because ρ (= 0.3) ≥ 0.12. If no more multicast updateReq message is received within a pre-defined time interval (Timeout), the publisher enters a Done state and terminates the Topic-public-key update protocol.
To evaluate the performance of the retransmission protocol, we implement the retransmission mechanism on the Contiki OS and Cooja simulator. The number (M ) of transmissions from the AC is computed as the size (s) of the multicast group increases for various packet loss rates (ρ = 0.05, 0.10, 0.15, 0.20, and 0.25), as shown in Fig. 15. We simulated the retransmission mechanism 100 times for each case. The topology of the LoWPAN consisting of several publishers is shown in Fig. 16. As expected, the number of transmissions increases with the number of publishers and packet loss rate. In the case of ρ = 0.25, the average number of transmissions is 3.39 for s = 30, 3.87 for s = 40, and 3.96 for s = 50. Considering that a wireless network with ρ = 0.25 is a very poor environment, our proposed Topic Public-Key Update protocol, which requires retransmission, does not degrade the overall performance and can be endured because it is executed only when the topic membership is changed. Table 4 shows comparisons with the previous works in terms of the security requirements and the cryptographic operations to establish a security association between an MQTT-SN client and a broker.

VIII. COMPARISONS WITH PREVIOUS WORKS
The confidentiality of the topic data is the basic security requirement of the MQTT-SN, so that it is supported by the previous schemes including ours.
Mutual authentication between an MQTT-SN client and a broker is supported in [18], [19] and in our proposed scheme. Unilateral authentication is not sufficient, as a man-in-themiddle attack can be mounted between them.
Control message security means the integrity protection of control fields in the MQTT-SN control messages (such as connect, publish, and pingreq messages). Without supporting it, a variety of DoS attacks can be mounted as mentioned in Section VI.B.
Since each MQTT-SN client can publish and subscribe to a prescribed set of topics, fine-grained access control for each MQTT-SN client should be enforced. Even if the MQTT-SN client is successfully authenticated to the broker, its attempt to publish/subscribe to non-authorized topics should be blocked. It can be supported by [19] and our proposed scheme.
To support end-to-end security between a publisher and a subscriber, a security association should be established between them in advance. In the case of [25], there was no mention of how to establish it. On the other hand, the security association between them can be established when the published message is sent to the MQTT-SN subscriber via the broker in the proposed scheme. ABE schemes [22,23] are not suitable for resource-constrained devices as the cryptographic overhead of the pairing operation increases rapidly as the number of attributes increases, as shown in [34].
The malicious broker deviates from the normal MQTT-SN execution and behaves according to the adversary's command. The broker can therefore override the original ACL and relay the topic data from a specific publisher to a specific group of subscribers for its own purpose. Our proposed scheme is resilient to such a malicious broker.
During the secure MQTT-SN phase in Fig. 2, it is desirable for the MQTT-SN client to avoid communicating with the external server because such interaction causes additional delay [15], [16], [21].
When the topic membership changes, it is necessary to perform the rekeying protocol even though it is a burden to the resource-constrained IoT-devices. However, considering home, utility companies, and factory IoT applications, there is no frequent change in topic-membership change except for the replacement of the broken and compromised devices. Unlike the previous schemes, our proposed scheme supports the rekeying protocol.
Since the security requirements of each of the previous works are different, there is no meaningful impact on the performance comparison between them. The cryptographic operations required for the MQTT-SN client to establish a security association with the broker (or directly encrypt the topic data) are enumerated in Table 4.
For performance comparison, we attempted to use as close as possible to the real (or virtual) devices employed in each of the previous schemes, as they were not used by simulators such as Cooja. In Table 5, PC, Edge, and Mote denote Ubuntu desktop, Raspberry Pi, and Cooja mote, respectively, where each cryptographic operation was implemented to compare the execution time.
In the case of TLS, the broker performs both key derivation and MIC computation on the PC, while the MQTT-SN client performs the certificate verification, RSA encryption, and MIC computation. On the other hand, both the broker and the MQTT-SN client perform cryptographic operations on the identical platform, namely ABE on the PC, E2E on the Edge, and the proposed one on the Mote.

IX. CONCLUDING REMARKS
MQTT-SN is a de facto standard for various IoT applications. However, motivated by the fact that MQTT-SN has several security issues to be addressed, we proposed a security architecture for secure MQTT-SN and several associated security mechanisms, through which mutual authentication, access control, data security, control message security, and endto-end security can be supported. Especially, based on two security models for the broker, malicious broker and honestbut-curious broker, the necessity of establishing end-to-end security between the publishers and subscribers was also investigated. Both device and topic certificates constructed using the ECQV certificate could establish a framework to provide end-to-end security, as well as fine-grained access control, for the devices. Both security analysis and performance evaluation showed that our proposed security architecture and mechanisms for secure MQTT-SN can be a viable solution to enhance MQTT-SN security.