Access Controls for IoT Networks

Abstract

The message queuing telemetry transport (MQTT) protocol is becoming the main protocol for the internet of things (IoT). In this paper, we define a highly expressive attribute-based access control (ABAC) security model for the MQTT protocol. Our model allows us to regulate not only publications and subscriptions, but also distribution of messages to subscribers. We can express various types of contextual security rules (temporal security rules, content-based security rules, rules based on the frequency of events, etc.).

Introduction

The Message Queuing Telemetry Transport (MQTT) 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) [1] and the 3.1 version became an OASIS specification in 2013 [2]. 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; and 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 [3,4,5], how to distribute the evaluation and the enforcement of the security policy at the edge of the IoT network [6, 7], how to distribute and synchronize the security policy between different pub-sub architectures [8], or how to protect the confidentiality of the messages from the broker or the pub-sub architecture itself [9, 10]. 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 [4, 5] mention that they are using the ABAC (Attribute-Based Access Control) model [11] 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 an 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 two papers we previously published [12, 13]. In this paper, we give a more complete definition of our security model, including the security policy administration model. We also present a new version of our prototype of access control enforcement system. The prototype we sketched in [12, 13] was based on SWRL and OWL2. Although it showed the feasibility of our approach, it proved to be inefficient in term of performance. The prototype we present in this paper is based on RDF [14] and SHACL [15] and the experiments we conduct show that it is efficient and scalable. Finally, in this paper, we also update our review of the literature on security models for IoT networks.

The remainder of this paper is organized as follows: in “ABAC Model”, we define our model. In “Security Administration Model”, we present our security administration model. In “Prototype”, we present our secure MQTT broker prototype based on our model and we study its performance. In “Related Works”, we review related works before the conclusion in “Conclusion”.

ABAC Model

Some papers [4, 5] mention that they are using the attribute-based access control (ABAC) 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.

Requirements

• Our model should offer the possibility to regulate not only publications and subscriptions to topics 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.

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 [6,7,8].

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

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

• Finally, we assume that 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.

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 (such as publications, subscriptions, and message 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 [16] (but it would be unreadable by a human), or an existing logical language like SecPAL [17]. 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 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 [2] 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 that 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 ${\varvec{\fancyscript{F}}}$ and from a set of logical rules ${\varvec{\fancyscript{R}}}$. Set ${\varvec{\fancyscript{F}}}$ keeps track of registered nodes and events (publications, subscriptions and distributions), whereas set ${\varvec{\fancyscript{R}}}$ records the nodes hierarchy (Table 1).

Table 1 Node predicates

Set ${\varvec{\fancyscript{F}}}$ includes instances from the following node predicates:

Registering a node creates an instance of one of these node predicates.

Set ${\varvec{\fancyscript{R}}}$ includes the following rules:

$$node\left( N \right) \leftarrow bro\ker \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 ${\varvec{\fancyscript{F}}}$ also includes instances from the following event predicates (Table 2):

Table 2 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 “Language”, 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 ${\varvec{\fancyscript{F}}}$ also includes instances from the following topic predicate (Table 3):

Table 3 Matching predicate

For example, fact $addresses\left( {temperature/*,temperature/sensor1} \right)$ belongs to ${\varvec{\fancyscript{F}}}$. 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

Table 5 Contextual functions

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:

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 (Table 7).

Table 6 Actions

Table 7 Authorizations

The security policy ${\varvec{\fancyscript{P}}}$ 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 daytime:

$$\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 alarm hierarchy of topics. Here we assume guest/1 is a role predicate expanding the hierarchy defined in “Assumptions”.

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 “Security Policy” 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 alarm 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 ${\varvec{\fancyscript{P}}}$ 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}l} {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

Frequencies are always evaluated at the time that 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 “Assumptions”, 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 using some aggregate predicate which would be implemented in many inference engines. For example, the rule below is the SWI Prolog [18] definition of the freq/3 predicate for the hasPublished/3 predicate. It uses the Prolog built-in aggregate_all/3 predicate:

$$\begin{array}{*{20}l} {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}l} {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}l} {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.

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 [16] 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.

Security Administration Model

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, as depicted in Fig. 1.

Fig. 1

IoT network

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. 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 another user 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 admin for a given topic T can define the security policy for that topic T. If s/he has also been granted the right to transfer this right, then s/he may also grant to another node the right to administrate topic T. We believe that 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.

Constants

We define the following constant to represent the RA: root

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

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

Predicate

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

Table 10 Rights’ delegation predicate

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 [19].

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 ${\varvec{\fancyscript{P}}}$. 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 other nodes.

Actions

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

Table 11 Security administration actions

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 ${\varvec{\fancyscript{a}}}$ 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 topic hierarchy with the admin option:

$$\begin{array}{*{20}l} {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}l} {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}l} {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}l} {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 ${\varvec{\fancyscript{a}}}$ is obviously deny unless permit [16], i.e., the default policy is deny. This default policy is overridden by rules 18–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.

Prototype

In [12, 13], we describe a first proof-of-concept prototype. This first prototype is based on (i) OWL2 ontologies for representing nodes, topics and events, (ii) SWRL [20] rules for representing the security policy, and (iii) an OWL2 [21] inference engine for computing a security decision (allow/deny). However, this approach has proved to be inefficient in terms of performance. In this paper, we present a new prototype based on RDF [14] and SHACL [15] (“Architecture”) and we evaluate its performance (“Performance Analysis”).

Architecture

The implantation of our security model relies on the W3C Resource Description Framework (RDF 1.1) Model [22]. We use RDF as a logical model to formally represent the security policy and its processing. We also use RDF as a physical model, since each identifiable object (node, topic, event, security rule, etc.) is represented as a resource. In other words, RDF statements describe resources, contextual information, events occurring in the system, and the security policy. We use an inference engine to compute security decisions. Each security decision and the proof graph which has led to the decision are automatically added to our contextual database for further processing. As a general principle, any event occurring within our access control enforcement system is monitored and saved into the contextual database. Recording events such as publication/subscription requests, security decisions, processing errors, etc. is not only important for traceability purpose, but also allows us to refer to these events in dynamic contextual access control rules.

Recently, the W3C has proposed the Shapes Constraint Language (SHACL) recommendation [15] as a solution to define and validate constraints on RDF graphs by means of SHACL shapes. SHACL has also been extended with a rule mechanism [23], where conditions can even include SPARQL queries [24]. Therefore, we can translate any security rule defined with our model into an SHACL shape/rule. Instead of processing security rules with a generic rule reasoner as we did in our first prototype [12, 13], we now translate our security rules into SHACL shapes/rules. We apply that these SHACL shapes/rules to RDF publication/subscription requests to produce security decisions. Processing SHACL shapes/rules has proved to be much more efficient than processing SWRL rules and ontologies with a generic rule reasoner.

Our access control enforcement system is built according to the XACML architecture [16], that is, it has a Policy Enforcement Point (PEP), a Policy Decision Point, a Policy Information Point (PIP—contextual database), and a Policy Administration Point (PAP). Figure 2 depicts the general workflow of our prototype. RDF security rules are first translated into SHACL shapes/rules. Any MQTT request is intercepted by the PEP, which has been implemented as a proxy between end points and the MQTT broker. The PEP submits to the PDP the RDF request. The PDP uses knowledge from the PIP and applies the SHACL rules on the request to compute a decision together with the RDF proof graph which has led to the decision. Decision and proof graph are returned to the PEP and saved into the PIP.

Fig. 2

Access control engine workflow

Our prototype is written in Java 9. It is based on the Apache Jena Framework [25] to store and manipulate RDF data. SHACL validation is done using TopBraid [26] which is an open source plugin for Jena. Our prototype provides the user with a REST API to manage the PIP, the policies, and the request/response workflow

Performance Analysis

We analyze the transmission time of messages, i.e., the time taken by a published message to reach a subscriber. We compare the transmission time in a configuration, where the security policy is enabled and the requests intercepted by the PEP with a configuration, where the clients are directly connected to the server with no security enforcement. We conduct our tests on a desktop PC equipped with an i764bit Quad Core CPU and 16Gbit of RAM. The broker is Mosquitto 1.6.0 which is an MQTT v3.1.1 broker. The clients (publishers and subscribers) are implemented in python and rely on the Paho-mqtt1.4.0 libraries. Paho-mqtt implements versions 3.1 and 3.1.1 of the MQTT protocol.

Our experiment configuration is inspired from a similar work presented in [27]. It is the following:

• The subject tree is generated randomly, so that each node has between 0 and 5 children. The maximum height of the tree is 5. From the topic tree, a list of possible topics for subscription and publication is generated. Similarly, a list of possible topic filters is created.

• Each subscriber issues a single subscription on a topic generated randomly in the subject tree, with a random quality of service between 0 and 2.

• Each publisher posts one message on a randomly generated topic. The payload of the message contains the identifier of the publisher, the topic, a timestamp corresponding to the time of emission, and a random quality of service.

• The security policy is randomly generated. It contains 100 rules. Each rule contains:

  • A priority between 0 and 5

  • An action: (publish or subscribe)

  • A target: (a random topic or a set of topics)

  • A decision: (allow or deny)

• Clients are all generated at the same time. Upon receipt of a message by a subscriber, the timestamp corresponding to the time of emission is retrieved from the payload and subtracted to the reception time to compute the transmission time.

• We consider a set of experiments for scenarios composed of 50, 100, 250, 500, 750, and 1000 subscribers each including 1000 publishers (see Table 12)?

  Table 12 Configuration scenarios

Results of our measurements are shown in Fig. 3. Figure 3 shows that the difference between the average transmission time of one request with the PEP and the average transmission time of one request without the PEP is constant and approximately equal to 100 ms, regardless of the scenario. This shows that our prototype is scalable and that our approach is very promising. In a similar work presented in [27], the authors developed a prototype, where the average transmission time increased linearly with the number of subscribers.

Fig. 3

Average transmission time per scenario

The difference of 100 ms mainly consists of,

• the time required to process the event by the PEP,

• the time required to process the request by the PDP,

• the transmission times between the PDP and the PEP.

We separately measured the average time to process the request by the PDP and we found out that it is constant and approximately equal to 55 ms.

Our prototype can still be optimized. For instance, we are planning to use web sockets instead of the REST API. This should improve transmission times between the PEP and the PDP.

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.

This paper which resembles the most to our approach is [27]. Like us, the authors consider that the protection object is the message. Therefore, they also regulate the distribution of messages by the broker. They use the ABAC model, although they do not define, as we do, an ABAC profile for IoT applications. They consider two types of security policies: the security policy expressed by administrators regulating the right to publish/receive messages and the security policy expressed by users in terms of preferences. They do not mention rights delegation. Their Policy Enforcement Point (PEP) is implemented as a proxy between the MQTT broker and the nodes. Having in mind the performances, they manage the security policy within a key value datastore (Redis²). However, they do not say much on the Policy Decision Point (PDP) and on analyzing the security policy using a reasoning engine. Moreover, Redis does not allow for complex queries and does not seem to be the right choice for storing highly expressive contextual policies. Finally, our prototype has shown better performance than their prototype (see “Performance Analysis”).

In [3], the authors define the secKit tool integrated in the IOT network simulator developed as part of the FP7 iCore project [28]. 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 [29]. Authorizations rules can be positive or negative and include obligations. Authorization rules are Event Condition Action (ECA) rules [30]. 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 4 years.

In [4], the authors describe a NetwOrked Smart object(NOS) 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 [8], 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 [5], 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 token 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 [31] or in the form of JWT [32] tokens (Json Web Tokens).

In [33], 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 [34] 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 [35] using the http protocol.

In [36], the authors propose to adapt the OAuth protocol [37] to the case of an IoT network, where resources are discovered and exposed according to the IETF standard [38]. 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, (1) requests access delegation from the owner of the resource by asking him to authenticate, (2) obtains an access token to the resource provided by the authorization server and (3) 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.

In [39], the authors present above all a method of authorization using Elliptical Curve Cryptography (ECC). However, they also implement an authorization scheme using capabilities. Capabilities are tokens distributed to users holding the access rights of the users to the data produced by the network. Very little is said about the expressive power of the security policy and interaction of their scheme with the MQTT protocol is unclear.

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 [40]. Thus, there are several approaches [6, 7] for moving security-related services and processes to end-of-network gateways or servers. In [6], the authors even use the concept of sticky policy [41] 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 [9], 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 [42, 43]. To protect the content of the messages and subscription schemes of the brokers, the authors in [10] propose a technique based on the encryption preserving the asymmetric scalar product [44].

In [45], 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.

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 except [27].

• 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 scalable prototype based on RDF and SHACL.

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 [8] 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 [6, 7] 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.