Keywords

1 Introduction

The MQTT (Message Queuing Telemetry Transport) protocol is becoming the main protocol behind pub-sub networks for the Internet of Things, that is, in networks implementing the publication-subscription paradigm. The MQTT protocol is an ISO standard (ISO/IEC PRF 20922) [2] and the 3.1 version became an OASIS specification in 2013 [3]. Basically, the MQTT protocol works as follows: publishers post messages to logical channels called topics; subscribers receive messages published to the topics to which they subscribed; the MQTT broker routes messages from publishers to subscribers.

The MQTT protocol supports very few security features. It includes a MQTT client identification mechanism and supports the basic login/password authentication scheme. Consequently, there have been several papers aiming at defining security solutions for the MQTT protocol or more generally for the pub-sub pattern. These papers address various issues like how to implement a security policy regulating publications and subscriptions [4,5,6], how to distribute the evaluation and the enforcement of the security policy at the edge of the IoT network [7, 8], how to distribute and synchronize the security policy between different pub-sub architectures [9] or how to protect the confidentiality of the messages from the broker or the pub-sub architecture itself [10, 11]. Although these issues are all very important, we noticed that none of these papers fully addressed the definition of a security model allowing to express security policies for regulating IoT messages. Some of the papers [5, 6] mention that they are using the ABAC (Attribute-Based Access Control) model [12] for expressing the security policy controlling publications and subscriptions. However, they do not go much into details and do not elaborate on the expressive power of the security policy. In this paper, we define a highly expressive ABAC model for regulating IoT messages in a MQTT network. We believe that the definition of such a security model (which does not contradict the solutions proposed by the aforementioned papers) has been missing in the literature related to security solutions for pub-sub architectures. Our model allows us to regulate not only publications or subscriptions but also distribution of messages by the broker to subscribers. Our model supports positive and negative authorizations and allows us to express various types of context-based policies, including policies based on the frequency of events. This paper is an extension of a short paper we previously published [1]. In [1], we could only draft our model. In this paper we give a complete definition, including the administration model. We also provide an extensive review of the literature on security models for IoT networks.

The remainder of this paper is organized as follows: In Sect. 2, we define our model. In Sect. 3, we present our security administration model. In Sect. 4, we sketch our secure MQTT broker prototype based on our model. In Sect. 5, we review related works before the conclusion in Sect. 6.

2 ABAC Model

Some papers [4, 5] mention that they are using the ABAC (Attribute-Based Access Control) model [11] for expressing the security policy controlling publications and subscriptions in a pub-sub network. However, these papers do not go much into details and do not elaborate on the expressive power of the security policy. Moreover, none of these papers address the security administration issue. Our aim in this paper is to define a security model which can be seen as a profile of the ABAC model for pub-sub networks based on MQTT. We first identify some requirements specific to IoT security policies. Then we make some assumptions on the IoT network and on some security aspects that we shall not cover. Finally, we devise our model starting from the requirements we identified.

2.1 Requirements

  • Our model should offer the possibility to regulate not only publications and subscriptions but also distribution of messages by the broker to subscribers. Controlling distribution of messages is essential to regulate the various flows of messages coming from the broker. Solely controlling subscriptions is too coarse grained to achieve that task.

  • Our model should allow for various types of dynamic and contextual authorization rules i.e. authorization rules whose outcome (permit ort deny) depend on some contextual conditions applying to the nodes, the messages (including the content of the messages) or the environment. In particular, authorization rules based on the frequency of events should be supported since controlling the rate at which a node may send or receive messages is important in many IoT applications.

2.2 Assumptions

  • For the sake of simplicity, we assume a pub-sub architecture with only one MQTT broker. Since we focus on the expressive power of the security policy, we do not investigate issues like distributing and synchronizing the security policy between different bridged brokers or evaluating the security policy at the edge of the network [7,8,9].

  • We assume the broker to be trusted i.e. we do not investigate solutions to protect the confidentiality of the messages from the broker [10, 11].

  • We do not investigate authentication techniques. We believe that standard authentication techniques can be used to authenticate both nodes and attributes.

  • Finally, we assume TLS/SSL is used at the transport layer between all nodes of the IoT network. Most existing MQTT servers support the use of TLS/SSL.

2.3 Language

We use first-order logic with equality to define our model, i.e. we define a logical language allowing us to represent nodes, attributes, events (like publications, subscriptions, messages distribution) and authorization rules. Note, however, that the reader who is not familiar with logic should be able to understand the main principles of our model since we translate in plain English each logical formula.

Although, we define our own logical language, we wish to make it clear that this paper is not about a new logic-based policy language. To specify our model, we could use XACML [13] (but it would be unreadable by a human), or an existing logical language like SecPAL [14]. However, we prefer defining our own language so that we can restrict ourselves to Horn clauses which can easily be read by a human and for which there exists efficient resolution methods.

Constants

Constants of our language are string expressions. They are node identifiers such as sensor1, user1 etc. or the special string broker referring to the MQTT broker.

Topics are defined by path expressions (written as strings) such as temperatures/sensor1. Several topics can be referenced by using wildcards # and +. For examples, temperatures/# addresses any topic having temperature as path root and home/+/temperatures addresses topics such as home/room1/temperature, home/room2/temperature etc. See [3] for more details about the use of wildcards in MQTT topics.

Note that, to lighten the notations, we omit the quotation marks for the strings.

Variables

Variables are written in capitalized letters like in Prolog. Our language includes the anonymous variable _ which means anything. If variable S contains a string value, then we assume this value can be referred to in a path expression. For example, if S contains the string sensor1 then temperatures/S represents the topic temperatures/sensor1.

In this paper, to distinguish variables from constants, we constrain ourselves to consider only constants written as strings of lowercase characters.

Predicates

Authorizations can be derived from a set of facts and from a set of logical rules . Set keeps track of registered nodes and events (publications, subscriptions and distributions) whereas set records the nodes hierarchy.

Set includes instances from the following node predicates:

Registering a node creates an instance of one of these node predicates (Table 1).

Table 1. Node predicates
Full size table
Table 2. Event predicates
Full size table

Set includes the following rules:

$$ node\left( N \right) \leftarrow broker\left( N \right) $$
(1)
$$ node\left( N \right) \leftarrow sensor\left( N \right) $$
(2)
$$ node\left( N \right) \leftarrow client\left( N \right) $$
(3)

These three rules can be used to derivate that the broker or a sensor or a client is also a node. These rules define a roles hierarchy that could be expanded according to the needs of the application.

Set also includes instances from the following event predicates:

Publishing a message creates an instance of the hasPublished/3 predicate. Subscribing to a topic creates an instance of the hasSubscribed/3 predicate. Delivering a message creates an instance of the hasDelivered/3 predicate. As we shall see in Sect. 2.3, recording these events allows us in particular to express security rules controlling the frequency of publishing/delivering messages.

As we said previously, topics are path expressions possibly written with wildcards. Therefore, set also includes instances from the following topic predicate (Table 3):

Table 3. Matching predicate
Full size table

For example, fact \( addresses\left( {temperature/*,temperature/sensor1} \right) \) belongs to . For the sake of simplicity, we do not give the logical rules allowing us to derive instances of the addresses/2 predicate.

Functions

Functions of our language represent attributes. They are either,

  • Functions applying to messages or

  • Functions for evaluating temporal conditions or any other contextual conditions.

Lists of functions in Tables 4 and 5 are not exhaustive and can be extended depending on the needs.

Table 4. Message attribute functions
Full size table
Table 5. Contextual functions
Full size table
Table 6. Actions
Full size table

2.4 Security Policy

Actions

We define the three compound terms to represent the following three actions:

Variables represent action parameters. Note that there is no QoS parameter for the deliver operation. This is because the QoS used by the broker to deliver a message to node N is the QoS chosen by node N when it subscribed to topic T. This means that if, in our security policy, we need to restrict the QoS used by the broker to deliver messages, then it should be done during the subscription step.

Contextual Authorization Rules

We consider positive authorizations and negative authorizations represented by the two following predicates (Table 7):

Table 7. Authorizations
Full size table

Variable A contains any of the three compound terms of Table 6. Note that if A is a deliver action then we assume that N cannot be different from broker.

The security policy regulates publish, subscribe and deliver operations. It consists of a set of authorization rules. Any authorization rule is an instance of one of the following rule templates:

$$ allow\left( {N,A} \right) \leftarrow conditions $$
(4)
$$ deny\left( {N,A} \right) \leftarrow conditions $$
(5)

Symbol conditions stands for a possibly empty conjunction of contextual conditions on nodes, topics, QoS, messages and the environment. Here are a few examples of authorization rules:

$$ \begin{array}{*{20}c} {deny \left( {sensor1,publish\left( {\_,alarms/sensor1,\_} \right)} \right)} \\ { \leftarrow time() > 8 \wedge time() < 20} \\ \end{array} $$
(6)

Rule 6 denies sensor1 to publish messages (whichever the QoS is), in topic alarms/sensor1 during day time.

$$ \begin{array}{*{20}c} {allow \left( {N,subscribe\left( {alarms/\# ,\_} \right)} \right)} \\ { \leftarrow guest\left( N \right)} \\ \end{array} $$
(7)

Rule 7 allows guest nodes to subscribe to the alarms hierarchy of topics. Here we assume guest/1 is a role predicate expanding the hierarchy defined in Sect. 2.2.

Regarding the delivering operation, we should first note that the normal MQTT behavior is to deliver messages from topic T to the nodes which subscribed to topic T.

This can be expressed by the following default policy rule:

$$ \begin{array}{*{20}c} {allow \left( {broker,deliver\left( {\_,T,N} \right)} \right)} \\ { \leftarrow hasSubscribed\left( {N,T,\_} \right)} \\ \end{array} $$
(8)

Rule 8 allows the broker to deliver any messages from topic T to the nodes which subscribed to topic T. However, this default policy can be overridden in some specific cases (see Sect. 2.4 for conflicts resolution between rules):

$$ \begin{array}{*{20}c} {deny \left( {broker,deliver\left( {M,alarms/\# ,N} \right)} \right)} \\ { \leftarrow guest\left( N \right) \wedge value\left( M \right) = 'failure'} \\ \end{array} $$
(9)

Rule 9 overrides rule 8 and denies the broker to deliver failure messages from the alarms hierarchy of topics to guest nodes. Rule 9 is an example of a content-based authorization rule.

In rules 7 and 9, there is a path expression referring to the set of topics alarms/#. Therefore, we need to include in set some rules to derive instances of predicates allow/2 and deny/2 addressing any subset of a set of topics expressed by means of wildcards:

$$ \begin{array}{*{20}c} {allow/deny \left( {N,publish\left( {M,T',Q} \right)} \right)} \\ { \leftarrow allow/deny\left( {N,publish\left( {M,T,Q} \right)} \right) \wedge addresses\left( {T,T^{\prime}} \right)} \\ \end{array} $$
(10)

Rule 10 says that if publication is allowed/denied for a set of topics T then publication is also allowed/denied for each subset T’ of T. We could write similar rules for the subscribe/3 and deliver/3 predicates.

For example, since addresses(alarms/#,alarms/sensor1) is true, then allow(subscribe(user1,alarms/sensor1,1)) can be derived from allow(subscribe(user1, alarms/#,1)).

Controlling the Frequency of Events

Our experience has shown us that in some applications being able to control the frequency of publications, subscriptions and messages distribution is important. Consider for example an online trading broker. An online trading broker is a pub-sub service where clients may send trade orders and receive various tips and hints related to the stock market. Assume that the online broker sells standard accounts and premium accounts. Premium account holders receive more hints and tips per day than standard account holders. Moreover, premium account holders can send more trading orders per day than standard account holders. In such a scenario, we would need to express authorization rules controlling the frequency of publications (e.g. trade orders) and the frequency of messages (e.g. hints and tips) delivered by the broker. Another obvious use of having authorization rules based on the frequency of publications would be to mitigate the effects of compromised sensors involved in DDOS attacks against the pub-sub architecture.

To define authorization rules allowing us to express conditions on the frequency of events, we define the following high-order predicate (Table 8):

Table 8. Frequency predicate
Full size table

Frequencies are always evaluated at the time the policy is evaluated. This explains why instances of the freq/3 predicates represent instant frequencies.

Variable E refers to any formula instance of the three event predicates hasPublished/3, hasSubscribed/3 and hasDelivered/3 defined in Sect. 2.2, with the last variable referring to the timestamp of the event always equal to the anonymous variable _.

Here are two examples of frequencies:

$$ freq\left( {hasPublished\left( {sensor1,alarms/sensor1,\_} \right),5,24} \right) $$
(11)

Formula 11 says that the instant frequency of publications made by sensor1 in topic alarms/sensor1 is 5 in the last 24 h.

$$ freq\left( {hasPublished\left( {\_,alarms/\# ,\_} \right),152,24} \right) $$
(12)

Formula 12 says that the instant frequency of publications (made by all sensors) in topics hierarchy alarms/# is 152 in the last 24 h.

Note that, by defining the high-order predicate freq/3, we are no longer in strict first-order logic. However, computing instances of the freq/3 predicate can easily be done by using some aggregate predicate which would be implemented in many inference engines. For example, the rule below is the SWI Prolog [15] definition of the freq/3 predicate for the hasPublished/3 predicate. It uses the Prolog built-in aggregate_all/3 predicate:

$$ \begin{array}{*{20}c} {freq \left( {hasPublished\left( {N,T,\_} \right),F,I)} \right)} \\ { \leftarrow aggregate\_all\left( {count,\left( {hasPublished\left( {N,T,D} \right) \wedge (time() - D) < I)} \right),F} \right)} \\ \end{array} $$
(13)

Basically, Prolog rule 13 counts the number of instances of the hasPublished/3 predicate referring to node N and topic T with a timestamp not older than I hours.

The following rules are examples of authorization rules regulating the frequency of publications and messages distribution:

$$ \begin{array}{*{20}c} {allow \left( {sensor1,publish\left( {\_,alarms/sensor1,\_} \right)} \right)} \\ { \leftarrow freq\left( {hasPublished\left( {sensor1,alarms/sensor1,\_} \right),F,24} \right) \wedge F < 5} \\ \end{array} $$
(14)

Rule 14 allows sensor1 to publish messages in topic alarms/sensor1 as long as it does not post more than 5 alert messages per 24 h.

$$ \begin{array}{*{20}c} {deny \left( {broker,deliver\left( {\_,alarms/sensor1,N} \right)} \right) \leftarrow guest\left( N \right)} \\ { \wedge freq\left( {hasDelivered\left( {alarms/sensor1,N,\_} \right),F,24} \right) \wedge F > 1} \\ \end{array} $$
(15)

Rule 15 denies the broker to deliver to guest nodes more than one alert message per 24 h from topic alarms/sensor1.

2.5 Conflict Resolution Policy

Since our authorization model allows for positive and negative authorizations, conflicts between rules may arise. For example, consider the following two rules:

$$ deny\left( {N,subscribe\left( {\_,\_} \right)} \right) \leftarrow sensor\left( N \right) $$
(16)
$$ allow\left( {N,subscribe\left( {N/\# ,\_} \right)} \right) \leftarrow sensor\left( N \right) $$
(17)

Rule 16 says that subscriptions are forbidden for sensors while rule 17 says that sensors can subscribe (at any QoS) to topic for which the path root corresponds to their identifier. Clearly these two rules conflict whenever a sensor subscribes to a topic for which the path root corresponds to the sensor identifier.

There are many possible solutions to solve conflicts between authorization rules. The XACML standard [13] enumerates several combining algorithms to solve conflicts between rules (deny overrides, permit overrides, first applicable overrides, permit unless deny, deny unless permit etc.). We can use any of these algorithms depending on our needs. Regarding the small example above, the permit overrides algorithm would allow a node subscribing to a topic for which the path root corresponds to the node identifier.

3 Security Administration Model

3.1 Principles

Definition of a security model must include the definition of a model for administering the security policy. To introduce our model, let us first consider the scheme depicted in Fig. 1.

Fig. 1.
figure 1

IoT network

Full size image

Sensors (S1 and S2) sends messages to Analytics through topic A. Monitor sends commands to sensors through topic B. Monitor owns sensors S1 and S2 and created topics A and B. This scenario suggests us that Monitor could be the administrator defining the security policy regulating messages going through channels A and B. Of course, this is not the only possible scenario. The IoT network could be more centralized; topics A and B could also be shared by other applications and sensors etc. Nevertheless, decentralizing the security administration should be possible even if the network contains only one broker. Moreover, to give flexibility, delegation of rights should also be supported.

In our model, security administration is topic-based. We state that there is at least one security administrator for each topic. A security administrator for a given topic T is responsible for defining the security policy regulating publications/subscriptions to topic T and distribution of messages from topic T. There is also one Root Administrator (RA) who can administrate the security policy for all topics.

More precisely, the RA can perform the following tasks:

  • Administrate (i.e. define the security policy for) all or some topics.

  • Grant to a node the admin privilege on a given topic (with possibly the right to transfer this right).

  • Revoke from a user the admin privilege on a topic.

Each administrator node which is admin for a given topic T can define the security policy for that topic T. If it has also been granted the right to transfer this right, then it may also grant to another node the right to administrate topic T. We believe this administration scheme is flexible enough to support various cases of application.

In the following sections we show how we extend our logical language to define our administration policy.

3.2 Constants

We define the following constant to represent the RA: root

3.3 Function

We define the following function which returns the topic addressed by an authorization rule R (instance of either template 4 or template 5) (Table 9).

Table 9. Topic function
Full size table

Recall that action A is represented by one of the compound term publish/3, subscribe/2 or deliver/3 defined in Table 6.

3.4 Predicate

We extend set with instances of the following event rights delegation predicate (Table 10):

Table 10. Rights delegation predicate
Full size table

Granting an admin right creates a new instance of this predicate. Revoking the right deletes the corresponding instance of this predicate. The grant option is similar to the grant option of the SQL grant statement [16].

3.5 Security Administration Policy

Let TA be an administrator node of topic T. Admin TA can add and delete authorization rules addressing topic T in the security policy . If admin TA holds the grant option on topic T, then it can also grant and revoke the admin rights on topic T to some others nodes.

Actions

We define four compound terms to represent the four following actions (Table 11):

Table 11. Security administration actions
Full size table

Note that the grant option cannot be granted nor revoked separately. The same principle applies in the SQL delegation scheme.

Security Administration Rules

The security administration policy is mandatory and consists of the five following administration rules:

$$ hasGranted\left( {root,\# ,root,true} \right) $$
(18)

Rule 18 says that the RA has granted to himself the admin option on the whole topics hierarchy with the admin option.

$$ \begin{array}{*{20}c} {allow \left( {N,ruleAdd\left( R \right)} \right)} \\ { \leftarrow hasGranted\left( {\_,T,N,\_} \right) \wedge addresses\left( {T,T^{\prime}} \right) \wedge topic\left( R \right) = T'} \\ \end{array} $$
(19)

Rule 19 says that if node N was granted the admin privilege on topic T, then it can add authorization rules referring to topic T (or to a subset of topics T if T represents a set of topics).

$$ \begin{array}{*{20}c} {allow \left( {N,ruleDel\left( R \right)} \right)} \\ { \leftarrow hasGranted\left( {\_,T,N,\_} \right) \wedge addresses\left( {T,T^{\prime}} \right) \wedge topic\left( R \right) = T'} \\ \end{array} $$
(20)

Rule 20 says that if node N was granted the admin privilege on topic T, then it can delete authorization rules referring to topic T (or to a subset of topics T if T represents a set of topics).

$$ \begin{array}{*{20}c} {allow \left( {N,grant\left( {T',\_,\_} \right)} \right)} \\ { \leftarrow hasGranted\left( {\_,T,N,true} \right) \wedge addresses\left( {T,T^{\prime}} \right)} \\ \end{array} $$
(21)

Rule 21 says that if node N was granted the admin privilege on topic T with the grant option then it can grant the admin option on topic T (or on a subset of topics T if T represents a set of topics).

$$ \begin{array}{*{20}c} {allow \left( {N,revoke\left( {T',N'} \right)} \right)} \\ { \leftarrow hasGranted\left( {N,T,N',\_} \right)} \\ \end{array} $$
(22)

Rule 22 says that if node N has granted to node N’ the admin privilege on topic T then it can revoke this privilege from node N’. In other words, only the node which transferred a privilege can revoke it. Moreover, as we said previously revoking an admin privilege deletes the corresponding instance of the hasGranted/4 predicate. Since the grantee N’ might also have transferred this right to some other nodes, revocation would also delete all the instances of hasGranted/4 corresponding to the delegation chain originating from N’. This mechanism is usually referred to as cascade revocation.

Finally, let us mention the following two points:

  • The combining algorithm enforced in is obviously deny unless permit [13], i.e. the default policy is deny. This default policy is overridden by rules 18 to 22.

  • If T represents a set of topics, then it is not possible to revoke the admin privilege for a subset of T. One would have to revoke the admin privilege for the set T and then grant again the admin privilege on a subset of T.

4 Prototype

4.1 Architecture

This paper is more about the model than the implementation. Nevertheless, we have implemented a proof-of-concept prototype depicted in Fig. 2. Our prototype is built according to the XACML architecture [13]. We use the EMQFootnote 1 MQTT broker written in Erlang/OTP for which we have developed the MQTTsec plugin acting as a Policy Enforcement Point (PEP). The Policy Information Point (PIP) contains OWL2 ontologies representing nodes, topics and events. The Policy Administration Point (PAP) contains a set of SWRL [17] rules representing the security policy. The MQTTsec manager, written as a Java Web Application, acts as a Policy Decision Point (PDP).

Fig. 2.
figure 2

MQTTsec broker prototype

Full size image

First, the PEP intercepts an event (publication, subscription or distribution of a message). It then submits the event to the PDP. The PDP loads the security policy from the PAP and queries the PIP to retrieve the necessary attribute values. Then it runs an OWL2 [18] inference engine which applies the conflict resolution policy and eventually issues a decision (allow/deny). Whether the request is authorized or not, it is always recorded in the PIP as a new instance of the event class of our ontology model. If the request has been authorized then the corresponding instance is tagged as allowed, denied otherwise. It should be noted that instances of the event predicates defined in Table 2 correspond to the allowed events recorded in the PIP. In our prototype, we also keep track of the denied requests for traceability purpose.

4.2 Proof Graphs

We should also mention that the inference engine can show the logical reasoning that led to the decision producing a proof graph of the decision. This feature can be very useful for debugging security policies, auditing, or devising new conflict resolution algorithms. Basically, it works as follows:

  • Policy rules and captured events (publication, subscription or message distribution) are represented in the OWL language.

  • The inference engine computes a list of possible authorization values and shows the derivation steps for each value.

  • If the list is empty, then the default policy is applied

  • If there are conflicting values in the list (at least one permit and one deny) then the conflict solver computes the final decision according to the predefined conflict resolution algorithm and shows the derivation steps.

  • Whether rejected or accepted, the event is timestamped and added to the PIP.

5 Related Works

As we already said, to our knowledge, there is no paper directly addressing the definition of a security policy model for IoT messages. Nevertheless, in this section we review security works related to pub-sub architectures and MQTT protocol.

In [4], the authors define the secKit tool integrated in the IOT network simulator developed as part of the FP7 iCore project [19]. This tool is used to define security policies protecting the data exchanged between the different components (virtual objects, composite virtual objects) which abstract the IoT network. secKit is based on a collection of models for modeling objects, data, time, roles, activities, interactions, risk, contexts, trust management and so on. It was implemented as a Mosquitto plugin [20]. Authorizations rules can be positive or negative and include obligations. Authorization rules are Event Condition Action (ECA) rules [21]. This formalism makes it possible to express contextual and dynamic authorizations but requires the implementation of an event manager capable of intercepting all events. Many aspects related to this tool are not clearly defined. Authors claim that the tool supports many features, but they do not elaborate on the features (expressive power, risks, trust management, obligations, conflicts resolution etc.). Therefore, it is very difficult to have a clear view of the model supported by secKit. Note also that the tool secKit seems to be abandoned. The source code of an alpha version can be downloaded from gitHub (https://github.com/iot-icore/iCore-security-toolkit) but has not been modified for 3 years.

In [5], the authors describe a NOS (NetwOrked Smart object) middleware, located between the objects and the MQTT client. NOS intercepts the messages intended to be published, normalizes them (i.e. extracts metadata) and according to a security policy implementing the ABAC model decides whether to grant the publication of the message. If the message is authorized, it is encrypted by means of a temporary key corresponding to the subject (topic) where the message is to be published. Once encrypted the message is published by the MQTT client. Customers wishing to subscribe to a topic, contact the NOS which according to the security policy will issue them or not the key to decipher the messages of the subject. This approach frees the MQTT broker from the evaluation and enforcement of the authorization policy. It requires, however, to set up a key management mechanism and offers a rather coarse level of granularity since the object of protection is not the message but the subject (thus including all the messages published in the subject). NOS has been implemented using the node.js platform and the objects transmit their messages via the http protocol. Currently NOS is not available for download. In [9], the same authors improve their architecture by proposing a solution to distribute and synchronize the security policies hosted by the NOS of several IoT networks. Their synchronization protocol uses the MQTT protocol.

In [6], the authors propose a solution to implement the ABAC model in a federation of IoT platforms. Their solution decouples the authorization process of the authentication process. An application first connects to an authorization manager to obtain a set of tokens. Each token represents an attribute of the application. Once in possession of its tokens the application that needs to access a resource turns to an authorization manager who will accept or reject access to the requested resource based on the tokens presented. If the application wants to access a resource belonging to a foreign IoT platform, then it must present its tokens to the authentication manager of the foreign platform to obtain foreign tokens. These foreign tokens are computed by means of a tokens conversion function (little information is given on this function in the article). Once in possession of the foreign tokens, the application can then turn to the foreign authorization manager who will accept or reject access. The authors suggest to implement the tokens either in the form of google macaroons [22] or in the form of JWT [23] tokens (Json Web Tokens).

In [24], the authors implement the RBAC model in a pub-sub network. They consider the privilege of logging in, the privileges of adding a topic and deleting it, and the privileges of publishing and subscribing. They define a solution to disseminate security policy [25] in a network of partially trusted brokers so that access control decisions are taken and enforced at the earliest. Their solution is implemented in the Hermès broker [26] using the http protocol.

In [27], the authors propose to adapt the OAuth protocol [28] to the case of an IoT network where resources are discovered and exposed according to the IETF standard [29]. The data (resources) produced by the sensors of the low power IoT network are transmitted to the gateway between the low power network and the IP network. This schema ignores the MQTT protocol, resources being logged and exposed at the gateway level. Within this gateway, an authorization server is installed. According to the OAuth protocol, a third-party application that wants to access a resource exposed by the gateway, (i) requests access delegation from the owner of the resource by asking him to authenticate, (ii) obtains an access token to the resource provided by the authorization server and (iii) presents the access token to the authorization server to access the resource. The authors do not mention any case study that could benefit from such a security architecture.

There is a general trend in the world of IoT which consists, for scaling purposes, of moving the processing and controls at the edge of the IoT network towards the objects themselves [30]. Thus, there are several approaches [7, 8] for moving security-related services and processes to end-of-network gateways or servers. In [7], the authors even use the concept of sticky policy [31] which implies that data owners encapsulate the policy protecting the data with the data itself.

There are several articles that deal with security issues in pub-sub networks, without specifically considering the MQTT protocol. In [10], the authors attempt to identify the security problems specific to this type of network. They are particularly interested in protecting the confidentiality of messages and subscriptions in case the pub-sub infrastructure is not trusted. They suggest some lines of research such as the use of numerical calculation on encrypted data [32, 33]. In order to protect the content of the messages and subscription schemes of the brokers, the authors in [11] propose a technique based on the encryption preserving the asymmetric scalar product [34].

In [35], the authors propose a model that implements the reliable distribution service, that is, the messages received by a client do not depend on the connection location, the network latency, or the possible points of network failure. These messages depend only on the customer’s subscription filter and her access rights, which are uniformly enforced throughout the pub-sub network.

6 Conclusion

In this paper, we have defined a model to express security policies for a pub-sub architecture consisting of a single MQTT broker. The most important contributions of our paper are the followings:

  • Our model allows us to regulate not only publications and subscriptions but also distribution of messages. To our knowledge, this feature has not been addressed in any other paper related to IoT security.

  • Our model is an interpretation of the ABAC model for the pub-sub architecture with some unique features like the possibility to control the frequency of events.

  • We have developed a prototype based on OWL2 and SWRL showing the feasibility of our approach.

Regarding future works, we are planning to investigate the following issues:

  • We will extend our model to the case of a pub-sub architecture consisting of several bridged brokers. In such a scenario, we might need to apply the solution presented in [9] to synchronize the security policy at every node of the pub-sub architecture.

  • We will also consider an IoT network consisting of a TCP/IP network hosting the pub-sub architecture coupled with a Low Power Wide Area Network (LPWAN) hosting the sensors. In such a scenario, we might also need to implement solutions proposed by others [7, 8] to move, for scaling purposes, the security controls at the various gateways between the TCP/IP network and the LPWAN network.

  • We are also planning to include the possibility to declare obligations in the security policy.

  • Finally, we will update and improve our prototype to turn it into a scalable secure broker engine