A Hybrid IoT Security Model of MQTT and UMA

IoT applications are promising for future daily activities; therefore, the number 
of IoT connected devices is expected to reach billions in the coming few years. 
However, IoT has different application frameworks. Furthermore, IoT 
applications require higher security standards. In this work, an IoT 
application framework is presented with a security embedded structure using the 
integration between message queue telemetry transport (MQTT) and user-managed access (UMA). The 
performance analysis of the model is presented. Comparing the model with existing 
models and different design structures shows that the model presented in this 
work is promising for a functioning IoT design model with security. The 
security in the model is a built-in feature in its structure. The model is 
built on recommended frameworks; therefore, it is ready for integration with 
other web standards for data sharing, which will help in making IoT applications integrated from different 
developing parties.


Introduction
Over the past few years, one of the remarkable emerging technologies is the Internet of Things (IoT). It has vast varieties of possible applications, with a wide range of requirements in terms of security and performance. Several networking protocols are designed with performance in mind, then security is added later.
Thus, security is often considered a burden and an overhead to the original protocol. The original non-secure protocol requires less communication and encryption overhead. Moreover, an IoT environment mainly consists of constrained devices, with limited resources and capabilities, which makes perfor-mance vital for the environment.
There is an essential need for a protocol that distributes the load and decentralizes security in order to have a scaleable IoT environment and satisfy the performance and security requirements at the same time.
One of the widely accepted IoT protocols is Message Queuing Telemetry Transport (MQTT). MQTT is an ISO standard (ISO/IEC PRF 20922) [1]. It is a lightweight, publish-subscribe network protocol that transports messages between devices. MQTT typically runs over TCP/IP. It is designed for connections with remote locations where a "small code footprint" is required or the network bandwidth is limited.
MQTT does not provide security by itself. Therefore, there have been some improvements to MQTT to improve its security; however, the overhead remains a critical issue in an environment with constrained devices. On the other hand, User-Managed Access (UMA) provides security.
User-Managed Access (UMA) is an OAuth-based access management protocol standard. Version 1.0 of the standard was approved by the Kantara Initiative on March 23, 2015 [2].
OAuth is an open standard for access delegation, commonly used as a way for Internet users and applications to grant websites or applications access to their information on other websites. It leaves the power with the owner to control authorization. It provides privacy and consent implications for web applications and the Internet of Things (IoT).
The purpose of this work is to enhance IoT security by integrating non-centralized authentication and at the same time maintaining an acceptable level of performance given that most Internet devices are constrained and has limited computation capabilities.
In the rest of this paper, we present some related work (Section 2), then the background of MQTT and UMA in Section 3. Then in Section 4, we propose a hybrid model by mapping MQTT and UMA. In Section 5, by simulation, we evaluate the proposed secure MQTT/UMA hybrid system. Then the simulation experiment results are presented, discussed and analyzed in Section 6; finally, a conclusion and final remarks are summarized, and some future research directions are presented.

Related Work
Internet of Things deployment remains a major challenge; hence, many have suggested using the cloud as a platform for the Internet of Things [3]. It has also been suggested that IoT sensors can be integrated into the cloud [4]; moreover, the business model can be built around providing Sensing as a Service module (SenaaS) [5]. Neven Nikolov and Ognyan Nakov have suggested using MQTTS and SSL/SSH encryption for IoT device [6]. Such a scheme can be effective; however, the performance impact on IoT should be further investigated. Others have also proposed some enhancements to MQTT by using Attribute-Based En- information-centric networking [12]. They have elaborated on the importance of the fog layer, as a practical and gap filler layer in any deployment of the IoT/Cloud environment.
Alhazmi and Aloufi have shown how deploying IoT devices using fog computing has an evident performance advantage over using cloud [13]. Moreover, in [14]

MQTT Protocol
There are different IoT protocols, such as MQTT and CoAP. While CoAP is highly competitive with MQTT. CoAP has a mechanism of exploration and observation; however, MQTT is much simpler to implement and much more popular [16] [17] [18]. As shown in Figure 1, MQTT consists of clients and a broker. The central part is the broker, the broker manages messages and transactions between clients. Clients are either a subscriber or a publisher. The payload of messages transmitted between clients contains data, mainly a subject and its value. The publisher sends messages to the broker when it has an update message or a periodic message. The broker sends the messages to the subscribers of a specific subject.

UMA Protocol
OAuth2 is an open protocol to allow secure authorization of application without   The resource owner controls resource access by clients. The client is operated by a requesting party. Resources are hosted by a resource server. An authorization server has roles defined by the resource owner to access resources. For example, a resource owner can grant access to an application for one-time access to a resource following some roles defined by the owner and managed by the authorization server.
There are three phases of the UMA of resources as shown in Figure 3, which are protection, authorization and access [19]. Figure 3 shows the transaction of the three phases. In phase one, the resource owner is managing resources at the resource server ("A"). The resource owner controls the authorization server ("C"), which provides the resources with protection API (B).
The protection API require a protection API token (PAT) to access a resource.
In phase two, the authorization phase, the client gets access to a set of resources in the resource server after being authorized by the authorization server.
The authorization API is using an authorization API token (AAT) to get a requesting party token (RPT) ("D").
Finally, in phase three, the client accesses a resource in the resource server using an RPT ("E").  It gets the resource, then the client connects to the AS to get grant access and finally the client can get the resource from the RS. This transaction is updated from the original one since the UMA model is updated and the client has no direct connection with the RO [20].
The UMA model has different APIs and tokens to be used. Table 2 shows the list of APIs used, tokens, the issuer and the user of the tokens. Using the protection API, a Protection API Token (PAT) is issued by the AS to the RS to access the protection API. The RS is then issued using the RPT to protect a specific resource for a specific owner.
An Authorization API Token (AAT) is issued by the AS using the Authorization API when the RP contacts the AS with a well-formatted request as recommended by UMA [19].
The RP will use the token to contact the Authorization API again to get a Requesting Party Token (RPT), which is the token that the RP is working to grant based on ATT. Figure 5 shows the detailed UMA transaction [21] [22]. The RO logs in to the RS to share a R. Then, the RS connects with the AS to get a PAT for the R. The AS replies with a PAT with the R, RS and RO information. After that, when the client (RP) requests access to the R at the RS, the client requires the access credentials. For this reason, the client is communicating with the AS to get the RPT and AAT for the specific R. Before the access permission, the AS set the access permissions rules. Finally, the client gets the R with a valid RPT. The UMA data should be exchanged in JSON format [21].

MQTT/UMA Hybrid Model
The proposed model is a system composed of two known systems, which are the UMA and MQTT. In the following sections, the model is developed. The first step is to do a mapping between the functions of the MQTT and UMA protocols. Then, in the next step, the model is proposed. The proposed model considers both the functionality of MQTT and UMA to provide the features of both protocols. Therefore, the model extends the area of application of UMA to reach IoT devices that works with MQTT protocols.
The model proposed should increase the security level of small to large scale IoT application in smart city or smart building applications.

UMA and MQTT Mapping
The model requires mapping between the functionality of both UMA and MQTT to work as one system.
This section shows the mapping of the function of both protocols, UMA and MQTT.    S2/RP gets the messages from the fog layer, which is expected to provide more connectivity in availability and connection speed compared to the first mode as well as more security enhancement with UMA model.

The MQTT/UMA Hybrid Model
MB2 is in the fog layer, which is connected directly with MB1. The model can be extended by having the MB2 connected to more than one MB1. Furthermore, each MB1 could be using one or more methods for connectivity to the fog layer.
The fog layer provides more performance and security of the high Quality of Service (QoS) required of a large-scale application [23]. One of the expected benefits of using the fog cloud is to decrease the response time between the subscribers and publishers.
The publishers notify the broker for any updates and the broker notifies the subscribers. The broker also has the log of each publisher in case it is needed by subscribers or for more statistical computations, such as the average value of a specific publisher or timing values, such as the last time a specific publisher updated its value.

Model Evaluation
In this section, we describe the evaluation methodology, which consists of four parts: the simulation setup, the simulation presentation; the results and discussion are presented afterward. Communications and Network

System Initial Configuration
This section shows the results and discussion of the simulation experiments of the IoT model shown earlier in Section 4.2.
While P1 is in direct connection to MB1/P2/RO, there is no direct connection between MB1/P2/RO and S2/RP. S2/RP gets the published topic from S1/MB2/RS, which is well established in security and performance in the fog layer.
MB1/P2/RO is expected to be a private property node in a home or a building at a security level that should not establish connection with general connections, such as RPs. Also, S1/MB2/RS is assumed to be connected with MB1/P2/RO with normal Internet connection.
This is an increase in security without added security overhead for MB1/ P2/RO messages. Effectively, the gained security overhead for messages is added to messages between S1/MB2/RS and MB1/P2/RO and between S1/MB2/RS and S2/RP.
In Section 3.2, Figure 5 shows the detailed UMA transactions to add security for general systems.

Evaluating the Model
The model evaluation is done through simulation of the MQTT/UMA hybrid system. To configure the simulation model, the system is configured as follows.
The wireless connection with any entity in the fog layer is 120 Mbps, assumed by a ping to the MQTT broker at test.mosquitto.org, and also tested by Jaloudi [24].
MB1/P2/RO can get from 10 -100 Mbps over 802.11 g protocol or wired connection. Therefore, MB1/P2/RO can connect with several IoT devices at once, with a high data rate from IoT. However, the sending rate of each IoT device is much lower, allowing the broker to receive data from several IoT devices. Each IoT device is equipped with Zigbee, using an IEEE 802.15.4 antenna, with a rate of 250 kbps and the maximum message size is 127 bytes, according to the Zigbee Specification [25]. As a result, the transmission time of one message is about 4 ms.
Fog servers are assumed to be equipped with powerful nodes, such as Intel Xeon W-3275M @ 2.50GHz. In the fog server, the mean time required to access a database at the S1/MB1/RS is 13 ms. The mean time required to query the database is about 10 ms. The mean processing time at the S1/MB2/RS, AS, and client is 10 ms. IoT devices represented by $P1$ are publishing data with the Poisson arrival process.
A ping between two servers in Europe, assumed to be servers in the fog layer, requires between 3 ms and 100 ms, depending on the location of the fog servers.
In this work, it is assumed that the fog server is in the same area, such as a country. Therefore, the assumed time is about 3 ms to exchange a message between two fog servers. The tested ping between two fog servers in different areas, like the US and Europe, is about 200 ms. From the simulation experiments, the arrival rate of data from each of the IoT devices is 127 bytes per second, which is one reading of a subject data keeping the data size minimal to avoid fragmentation. Table 4 shows the transaction time between the different nodes of the model, and the processing time at each node. Table 4 is the conclusion of the configuration of the model. The table is used to configure the simulation. Processing time at the IoT device is defined by T P1 . The table symbols are shown in Figure 8.
The transmission time between IoT device P1 and MQTT Broker MB1/P2/RO is defined by T P1xMB1/P2/RO . The same applies to other transactions. The symbols shown in Table 3 and Table 4 are as follows: P1 is the IoT devices. MB1 is the first broker connected directly with P1 and connected with the S1 node. as the subscriber. MB1 shares the node with P2 and RO. The model is mutually inclusive between the two-broker system of MB1 and MB2. P2 is the publisher of the second broker system. As mentioned, P2 share the node with MB1 and RO.
MB2 is the second broker and share the node with S1 and RS. MB2 connects to S2 through the Client. S2 shares its node with RP.
Equation (1) shows that 1207 ms is required for protection and authorization.
For initial access, Equation (2) shows that 164 ms is required. Equation (3) shows the time of initial publishing is 1147 ms. For subsequent publishing, the time required is 578 ms as shown by Equation (4).
The following equations are also used in the evaluation: L W λ = (10) where L is the average number of messages in the system. L q is average number of messaged in the queue of MQTT broker. W is the average service time of a messege in the system. W q is the average service time of a message in a MQTT broker. Ρ is the utilization of the system. λ is the arrival time.μ is the service rate. In Figure 7, the function Access (R, RPT) is invoked only when the client initiates the request; otherwise, the published message reaches to the RP as a subscriber to the subject. Equation (5) shows the subscriber transaction time is 92 ms.

Results
The system is M/M/1 queuing model with exponential distribution of inter-arrival time and service time. The system is tested with a mean inter-arrival time between 588 ms and 640 ms. The mean service rate is mu = 1/587, which is the time required for publishing.
The system utilization is computed by Equation (6) and shown in Figure 9.
Mean waiting number to be served is computed by Equation (7) and shown in Figure 10.
Mean waiting time is computed by Equation (8) and shown in Figure 11.
Mean waiting number verses mean waiting time is shown in Figure 12, they show a linear relationship indicating that they grow at the same rate.
Mean waiting time in the system is computed by Equation (9) and shown in Figure 13.
Mean waiting number in the system is computed by Equation (10) and shown in Figure 14. The proportion of time the server is idle is computed by Equation (11) and shown in Figure 15.

Discussion
As the experiments in Sections 5.2 and the results are shown in 6.1 the overhead created between UMA and MQTT is the main critical overhead by the mode. Any IoT device is not connected to the world unless connected to a broker or a type of protocol that allows the IoT device to send and receive data. However, the accessibility of IoT devices is expected to be quite high; therefore, UMA provides high scaleability for IoT device to publish its data to the wide range of users or RP. RP could be another IoT device.
Nowadays with the expected future and developing project of smart cities and buildings, IoT devices are expected to send a very large amount of data as (i.e. Big Data). Also, the integration of plug and play is a must future for IoT. Now, UMA will establish protocols as well as MQTT. Adding the two models should be done without sacrificing performance.
If there is a trade-off, the system administrator and project developer can discuss the QoS of any model of expected growing IoT projects.
For MQTT, the model is added to UMA to add the subscriber functionality.
The model shown in Figure 6; has mainly S1 and MB2 added to the RS and S2 added to RP. Effectively, P1, MB1 and P2 are not considered an overhead since it is external processing overhead to the UMA protocol. Therefore, the overhead is with S1, MB2 and S2. When the data are received from P1 to MB1, the data are published to S1. S1 is represented by MB2, which is represented by RS. The integration between MB2 and RS is done by considering any newly published data received by MB2 as a request received by an RP which is registered as a subscriber for a specific topic. Hence, the time required to get a message about a new topic is less than the time required for a request by RP, Client, S2/RP/xClient, ClientxS1/MB2.RS and S1/MB2/RS = 346 compared to the time required for the publishing as mentioned earlier by Equation (4). The time required is only 26% of the time required if the functionality is done by UMA only. Consequently, the performance gain is 74% with MQTT for the publishing function of a new topic.

Conclusion
IoT environment is promising for future applications in different domains, such as smart cities or the sensing as a service (SenaaS) model of business. When an IoT application works it is expected that the number of devices grows exponentially as well as the size of data. Security is required to secure access to the data sources; hence, data need to be protected without compromising performance.
Therefore, an integrated security layer is required. In this work, the UMA secu-rity protocol is used to add security with the well-known IoT application protocol MQTT. There are different IoT application protocols; however, MQTT is the most popular for implementation simplicity. This work has shown how to integrate MQTT and UMA in one fast performance and secure model. The integration is maintained by mapping the functionality of both protocols. Performance comparison has shown that there is performance gain for different functionalities; mainly, the publishing function which is the main function of any IoT device. The model has successfully connected isolated IoT devices to the publishing network without compromising security. Moreover, data are published and accessed without accessing the source of the data. Therefore, this hybrid model presented shows a viable potential for secure high-performance Internet of Things.