Towards a Formal IoT Security Model

Abstract

The heterogeneity of Internet of Things (IoT) systems has so far prevented the definition of adequate standards, hence making it difficult to compare meaningfully the security degree of diverse architectural choices. This task can be nonetheless achieved with formal methodologies. However, the dedicated IoT literature shows no evidence of a universal model allowing the security evaluation of any arbitrary system. Based on these considerations, we propose a new model that aims at being global and all-encompassing. Our model can be used to fairly analyse the security level of different IoT systems and compare them in a significant way. It is designed to be adaptive with realistic definitions of the adversary’s (1) actions of interacting with IoT systems; (2) capabilities of accessing the data generated by and exchanged in IoT systems with established rules; and (3) objectives of attacking IoT systems according to the four recognised security properties of confidentiality, integrity, availability and soundness. Such a design enables the straightforward characterization of new adversaries. It further helps in providing a fine-grained security evaluation of IoT systems by either accurately describing attacks against the analysed systems or formally proving their guaranteed level of security.

1. Introduction

In the domain of computer science and symmetry, the development of new types of sensors and actuators supported by network connectivity is shaping the concept of the Internet of Things (IoT). This technology is completely changing the users’ approach and use of the cyber-space. It breaks down the barriers between our physical daily world and the digital reality, enabling new services and paving the way towards a full digital inclusion. IoT can support a variety of applications and services in diverse domains such as healthcare, home automation, security, and vehicles. These services are built on dynamic heterogeneous architectures, based on the symbiosis of various elements (i.e., sensors, connections, and applications) with different criticalness levels.

The novelty, heterogeneity, and complexity of such systems involve however a broad and unexplored attack surface that might lead to serious consequences for the users as well as for the companies. For instance, the study of [1] demonstrated that a malicious entity is able to switch on or off the smart bulbs of an IP-based light system, or even to brick them. This can bring unexpected electrical consumption peaks in highly populated areas. A more critical incident is the IoT-based Mirai botnet that launched a DDoS attack against Dyn, a major DNS provider, and caused a significant breakdown of many famous web services, such as Twitter, GitHub, PayPal, Amazon, Netflix, and Spotify. Additionally, IoT systems often generate opaque and huge flows of information. This, combined with the shift of the control paradigm of the devices from local to virtual and/or remote, implies new security concerns for the users such as leakage, theft, or undesired use of sensitive data.

In order to mitigate those risks, defining consolidated standards and performing deep analysis on the security level of IoT architectures becomes a necessity. A step towards this goal consists in building a well-established formal security model that could be used as a tool to make fair analyses, comparisons and security proofs of different types of IoT systems. Lots of papers related to the security in IoT systems have been published recently. Yet they present models that are usually threat-based oriented (i.e., validating the resistance of a system to a finite set of known attacks), strongly linked to very specific application scenarios, or focused on the devices as individual entities rather than as a complete system. In particular, the threat-based model of [2] is the closest reference related to formal security frameworks in the IoT field. However, it does not allow to formally prove security properties of an IoT system. Looking from the Internet protocols perspective, some automated tools have been proposed to validate their security and applications [3,4]. Existing solutions based on attack graphs [5] and similar approaches [6] require the prior knowledge of attacks’ vectors. Yet, to the best our knowledge, literature in this domain with focus on IoT is very limited [2,7]. For instance in [7], authors introduce a dedicated model for analysing smart meters systems. Regarding RFID technology, many cryptographic security models related to privacy already exist, as depicted in the survey [8]. Especially, the model presented in [9] is able to compare RFID systems appropriately, considering various system architectures. To cover this gap, we propose a formal model for evaluating whether or not fundamental security primitives are provided by IoT solutions. Additionally, our model aims to be all-encompassing, meaning that it is able to compare the security performances amongst different IoT systems. Thus, access control models for IoT such as [10,11,12,13,14] are out of the scope of this work as they are considered as complementary security services. However, we are planning to extend our model for checking access control models for IoT in a future work.

Our main contribution is the proposal of a new model that expands the RFID privacy model of [9] to the security properties of the IoT world. First, we provide a clear description of an IoT system and its composition (devices, a backend system and users). We adapt the formal definitions of the RFID building blocks regarding the initialisation procedure and protocol(s) given in [9] to IoT systems. We generalise the definition issued in [9] of the potential adversaries so that their attacks can be carried out on IoT systems, while maintaining the same notion of adversary class representing the adversary’s capabilities during an attack. Finally, we define the attacks objectives by the means of unique experiments that formalise the four well-known security properties of confidentiality, integrity, availability, and soundness. As our model aims at being lightweight and easily usable, we additionally demonstrate its practicality with the security analysis of two different IoT systems.

The rest of the paper is organised as follows. Section 2 overviews the general architecture of an IoT system and Section 3 introduces a formalization for it. Section 4 specifies the actions an adversary can perform, and the data she can obtain from these interactions. The security properties of the model are formalised in Section 5. The security analyses of two real-life IoT systems are provided in Section 6 and Section 7. Finally, Section 8 concludes the paper and presents the future research.

2. Overview of IoT Systems

An IoT system is the interconnection among physical objects with cyber services. Without loss of generality, it is composed of three main entities: IoT devices, a backend system with which the IoT devices interact with, and users that handle the devices and/or interact with the backend system. We provide a high level description of these three elements below.

2.1. IoT Devices

Currently there is not a common definition for an IoT device, thus we assume that an IoT device can be either a sensor or a hub. A sensor is usually a device with a small processing capacity that performs various measurements or detects patterns (e.g., thermometer, motion sensor, or camera). It is supported by a firmware for its operations, although some sensors in the market run lightweight versions of well-known operating systems. Due to the sensor’s limited capabilities, a hub is usually needed to provide additional services to the sensor, such as data storage or Internet connectivity. Sometimes, a sensor and a hub can coexist in one single device.

2.2. Backend System

Most of IoT systems nowadays have a backend system to support and enhance the provided services. Its purpose is twofold. First, it enhances the devices’ capabilities by supporting extra features and services, such as additional storage or advanced user interface with more configurable options. Secondly, it provides to the user continuous communication with the IoT system. In fact, the backend system can be seen as a cloud service. Such a service is usually accessible through a website, where the user has to first authenticate in order to get access. Such access can also be obtained through a mobile application that, in general, automatically detects if the access to the backend is needed or not, depending on the user’s location.

2.3. Users

They can interact with IoT devices and manage the system through different platforms such as PCs, smartphones, or tablets. Depending on the system used, local and/or remote interactions with the IoT system are provided. For instance, in case of remote management, all the information is forwarded to the hub through the cloud service, while, if the user is acting from the same network where the hub is installed, the traffic is routed directly to it and thus no Internet access is needed.

All these entities communicate together using different protocols depending on the choices of the devices’ manufacturers. The most popular ones are Zigbee, Z-wave, Wi-Fi. Some IoT systems can also involve devices that support low range communications such as RFID, NFC, or Bluetooth.

3. Formalisation of IoT Systems

In order to analyse IoT systems from a security perspective, we introduce a model that will formalise our analysis. In particular, we describe the building blocks of an IoT system, namely the initialisation procedures to set up a system and the protocol(s) executed by the entities of the system, and the IoT data sets that can be extracted from these building blocks (namely transcripts and snapshots). All the definitions of these notions are built on those of [9].

3.1. Initialization Procedures

An IoT system is setup by a procedure InitSystem that (a) generates the public and private values of the system depending on a security parameter $\lambda$; and (b) initialises the backend.

To allow a dynamic generation of IoT devices, a procedure CreateDevice is defined and called aside of InitSystem. IoT devices can potentially be setup with unique data and must consequently be registered in the system to be recognized afterwards. This action is not necessarily performed when the IoT device is created, and thus requires the definition of an independent procedure RegisterDevice. For instance, the physical action of a user may be involved, such as pressing a button on the hub.

The three procedures determine each entity’s initial internal state, which is the data stored in each entity’s memory. The backend internal state may furthermore contain the system database.

An example of such initialisation procedures is the Simple Service Discovery Protocol (SSDP) [15], which is supported by many IoT manufacturers. It enables the transparent configuration of IoT devices in a plug-and-play mode that requires minimum user interactions.

3.2. Protocols

The behaviours and interactions of the system entities are described through protocols. Each of them determines the actions (e.g., computation, random generation), interleaved by transitions, that the entities have to perform to reach a given objective.

For instance, a protocol can be a communication protocol where a sensor sends to the hub the real-time measured temperature of a room. Or a protocol can simply be the process of a camera which starts recording when it detects movements in its surroundings.

3.3. Transcripts

The subset of actions performed by an entity $\mathcal{X}$ during a protocol execution is called algorithm. During an algorithm execution, $\mathcal{X}$ may exchange several data related to its IoT nature with the external world, typically with other involved entities. This external view of an algorithm execution forms a data set called transcript. It can be enriched by auxiliary information extracted from the activation of transitions, e.g., the reception/emission time of a message or its recipient/issuer.

Transcripts are indexed with a counter incremented each time $\mathcal{X}$ engages in a new algorithm execution. ${\pi }_{\mathcal{X},\mathrm{P}\mathrm{ROT}}^i$ denotes the transcript of the $i^{\mathrm{th}}$ execution of $\mathcal{X}$’s algorithm related to a protocol Prot.

3.4. Snapshots

Each algorithm execution may further modify the entity internal state. It is possible to capture the information contained in an entity internal state at a given time (e.g., retrieving the IoT data stored on a sensor by tampering it). Each capture defines a data set called snapshot.

Snapshots are also incrementally indexed, and ${\epsilon }_{\mathcal{X}}^i$ denotes the $i^{\mathrm{th}}$ snapshot of $\mathcal{X}$’s internal state.

4. IoT Adversary

To analyse the security level of an IoT system, we introduce the notion of adversary, i.e., a malicious entity whose final objective is to attack the system. We adapt the adversary model introduced in [9], originally defined for RFID systems, to the IoT context.

In order to define an appropriate adversary, we need to use the notion of oracles and selectors. An oracle is a tool used by an adversary to simulate the interactions of an IoT system and collect data. A selector is a tool used by an adversary to access the collected data. We also need to specify the restrictions that can be applied to the use of the oracles and selectors by the adversary when she plays/interacts with the system in order to attack it. Finally, the combination of oracles, selectors and restrictions permits the definition of all the potential adversary classes that might attack an IoT system.

4.1. Oracles

The following oracles can be carried out on an already initialised IoT system. They are divided in three families, according to their functions.

(i)

Oracles that dynamically add IoT devices to the system.

• ${\mathcal{O}}^{\mathrm{C}\mathrm{REATE}\mathrm{D}\mathrm{EVICE}}\left(\right)\to \mathcal{X}$: executes the CreateDevice procedure, and returns the label $\mathcal{X}$.
• ${\mathcal{O}}^{\mathrm{R}\mathrm{EGISTER}\mathrm{D}\mathrm{EVICE}}\left(\mathcal{X}\right)\to \varnothing$: executes the RegisterDevice procedure on the device $\mathcal{X}$.
  • When the system is just initialised, there is no IoT device yet defined, only the backend and the public and private values of the system. Consequently, the two previous oracles are used to add devices to the analysed system.

(ii)

Oracles that completely or partly execute a protocol.

• ${\mathcal{O}}^{\mathrm{E}\mathrm{XECUTE}}(\mathrm{P}\mathrm{ROT},{\mathcal{X}}_1,\cdots ,{\mathcal{X}}_{\alpha })\to ({\pi }_{{\mathcal{X}}_1,\mathrm{P}\mathrm{ROT}}^{i_1},\cdots ,{\pi }_{{\mathcal{X}}_{\alpha },\mathrm{P}\mathrm{ROT}}^{i_{\alpha }})$: executes the protocol Prot between the entities $({\mathcal{X}}_1,\cdots ,{\mathcal{X}}_{\alpha })$, fills up and outputs their transcripts $({\pi }_{{\mathcal{X}}_1,\mathrm{P}\mathrm{ROT}}^{i_1},\cdots ,{\pi }_{{\mathcal{X}}_{\alpha },\mathrm{P}\mathrm{ROT}}^{i_{\alpha }})$.
  • This oracle reduces the adversary’s capabilities to an eavesdropper, while the two following ones allow the splitting up of the previous oracle, and can be used to represent an active adversary that controls all the steps and transitions of a protocol execution.
• ${\mathcal{O}}^{\mathrm{L}\mathrm{AUNCH}}(\mathrm{P}\mathrm{ROT},\mathcal{X})\to {\pi }_{\mathcal{X},\mathrm{P}\mathrm{ROT}}^i$: makes $\mathcal{X}$ launch a new execution of the protocol Prot, fills up and outputs the transcript ${\pi }_{\mathcal{X},\mathrm{P}\mathrm{ROT}}^i$ when all the actions related to the oracle query are performed.  
• ${\mathcal{O}}^{\mathrm{S}\mathrm{END}}(\mathrm{P}\mathrm{ROT},\mathcal{X},m)\to {\pi }_{\mathcal{X},\mathrm{P}\mathrm{ROT}}^i$: sends a message m to $\mathcal{X}$, fills up and outputs the transcript ${\pi }_{\mathcal{X},\mathrm{P}\mathrm{ROT}}^i$ when all the actions related to the oracle query are performed.

(iii)

Oracle that captures information on the system.

• ${\mathcal{O}}^{\mathrm{C}\mathrm{ORRUPT}}\left(\mathcal{X}\right)\to {\epsilon }_{\mathcal{X}}^i$: outputs the $i^{\mathrm{th}}$ snapshot ${\epsilon }_{\mathcal{X}}^i$ of $\mathcal{X}$’s internal state.

This oracle formalises a powerful capability that can be given to an adversary, by making her able to corrupt a device and to capture all the information contained in the device at a given time.

4.2. Selectors

With the oracles, the adversary collects transcripts and snapshots. The selectors allow her to read the different information contained in these data sets. There is no exhaustive list of the information that is created/used/shared in an IoT system. This section simply presents the most common ones.

Given a selector s, $\pi .\mathsf{s}$ (resp. $\epsilon .\mathsf{s}$) denotes the information accessible through s contained in the transcript $\pi$ (resp. the snapshot $\epsilon$).

(i)

Selectors related to transcripts.

• msg: ability to extract the messages sent over the communication channels.
• result: ability to extract the result of the protocol (e.g., success or failure).
• timer: ability to extract the execution time of a device.

(ii)

Selectors related to snapshots.

• eeprom: ability to extract the EEPROM memory of a device at a given time.
• ram: ability to extract the RAM memory of a device at a given time.

4.3. Restrictions

Some restrictions can be applied to the use of the oracles when the adversary plays with the system. For instance, one restriction forces the use of ${\mathcal{O}}^{\mathrm{R}\mathrm{EGISTER}\mathrm{D}\mathrm{EVICE}}$:

• Reg: all the devices must be registered.

Some restrictions on the use of ${\mathcal{O}}^{\mathrm{C}\mathrm{ORRUPT}}$ can also be applied:

• NonCorrSensor: no sensor can be corrupted;
• NonCorrHub: no hub can be corrupted.

Restrictions related to the selectors and entities can also be applied:

• Device: the selectors can only be called on transcripts performed by IoT devices, i.e., sensors and hubs;
• Internet: the selectors can only be called on transcripts performed by entities having Internet connection.

4.4. Adversary Classes

All the different oracles, selectors and restrictions allow to explicitly define the adversary’s capabilities during the game (called experiment in what follows) performed with the targeted IoT system to attack it. This is done with the concept of adversary class.

Definition 1

(Adversary class [9]). An adversary class P is defined by three sets O, S, R, and is denoted by the 3-tuple $(O,S,R)$, where:

• O is the set of available oracles;
• S is the set of available selectors;
• R is the set of restrictions regarding the use of the available oracles, selectors, and entities during the experiment.

Several classical adversary classes against IoT system can be defined. The goal is not to provide an exhaustive list, but to highlight the most intuitive ones. For instance, a security model for IoT systems should at least consider two types of adversary, internal and external, that can act maliciously either on a passive or an active way depending on their goal.

On the one hand, the first category consists of $\mathsf{INSIDER}$ adversaries that are located in the close range of an IoT system (e.g., inside a smart home); such adversaries can interact directly with every legitimate device in their surroundings. $\mathsf{EAVESDROPPER}$ adversaries are $\mathsf{INSIDER}$ with limited capabilities (as explained in [9], the adversary classes can be (partially) ordered. For instance, an $\mathsf{INSIDER}$ adversary is stronger than an $\mathsf{EAVESDROPPER}$ one): they can only listen to communications between the legitimate devices. On the other hand, $\mathsf{EXTERNAL}$ adversaries do not have physical access to the devices; they can only interact with the devices having an Internet connection (e.g., hub or backend system). These three categories of adversaries can be formally defined by the following classes. In order to lighten the notations, let us denote ${\mathcal{O}}_{\mathrm{basic}}=\{{\mathcal{O}}^{\mathrm{C}\mathrm{REATE}\mathrm{D}\mathrm{EVICE}},{\mathcal{O}}^{\mathrm{R}\mathrm{EGISTER}\mathrm{D}\mathrm{EVICE}},{\mathcal{O}}^{\mathrm{E}\mathrm{XECUTE}}\}$ the set of basic oracles.

• $\mathsf{EAVESDROPPER}=({\mathcal{O}}_{\mathrm{basic}},\{\mathsf{msg},\mathsf{result}\},\{\mathtt{Reg},\mathtt{Device}\})$.
• $\mathsf{INSIDER}=({\mathcal{O}}_{\mathrm{basic}}\cup \{{\mathcal{O}}^{\mathrm{L}\mathrm{AUNCH}},{\mathcal{O}}^{\mathrm{S}\mathrm{END}}\},\{\mathsf{msg},\mathsf{result}\},\{\mathtt{Reg},\mathtt{Device}\})$.
• $\mathsf{EXTERNAL}=({\mathcal{O}}_{\mathrm{basic}}\cup \{{\mathcal{O}}^{\mathrm{L}\mathrm{AUNCH}},{\mathcal{O}}^{\mathrm{S}\mathrm{END}}\},\{\mathsf{msg},\mathsf{result}\},\{\mathtt{Reg},\mathtt{Internet}\})$.

As a simple but concrete example, an $\mathsf{EAVESDROPPER}$ adversary can use the oracles ${\mathcal{O}}^{\mathrm{C}\mathrm{REATE}\mathrm{D}\mathrm{EVICE}}$, ${\mathcal{O}}^{\mathrm{R}\mathrm{EGISTER}\mathrm{D}\mathrm{EVICE}}$, ${\mathcal{O}}^{\mathrm{E}\mathrm{XECUTE}}$, the selectors msg and result, all with the restrictions Reg and Device.

5. Security Properties

After the formalisation of IoT systems and the definition of the potential adversary classes, we define here attack objectives through four security properties, each one linked to a specific experiment. In fact, an experiment formally represents the game performed by an adversary to undermine the related security property expected by an IoT system. In order to clearly understand the experiments and their corresponding security properties, some notations must be specified as follows.

• $\mathcal{S}$ is an IoT system of global security parameter $\lambda$.
• $ϵ(.)$ is a negligible function.
• ${\mathcal{A}}_P$ is the adversary $\mathcal{A}$ belonging to the class P playing an experiment $\mathit{Exp}$.
• $\mathcal{C}$ is the challenger, i.e., the honest entity that determines a kind of riddle that must be answered by ${\mathcal{A}}_P$ at the end of $\mathit{Exp}$.

The goal of ${\mathcal{A}}_P$ is to win $\mathit{Exp}$ with non-negligible probability, in comparison to a dumb adversary who is considered to always perform random interactions during the experiment.

5.1. Confidentiality

This notion is linked to attacks aiming at retrieving confidential information. An example of such a situation is a hospital using IoT for medical follow-up. The system is composed of (1) a centralized backend containing the medical data of all the patients; (2) IoT wristbands that are worn by the patients during their stay at the hospital; and (3) IoT tablets that scan the wristbands and provide to the doctors the medical data related to the corresponding patients. In this example, an adversary may want to retrieve the medical data of the patients wearing an IoT wristband. The confidentiality experiment is described in Figure 1.

The confidentiality property is thus as follows.

Definition 2.

Confidentiality: An IoT system $\mathcal{S}$ is said to be P-confidential for a specific set CI of confidential information if:

$$\forall {\mathcal{A}}_P\in P:\mathrm{Pr}\left({\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_P}^{\mathrm{Confident}}\left(\lambda \right)succeeds\right)\le ϵ\left(\lambda \right).$$

5.2. Integrity

This notion is linked to attacks aiming at modifying (e.g., adding, changing or removing) part of the critical information contained in a system. Following the hospital example, an adversary may want to erase data of some patients, preventing them of being treated. The integrity experiment is described in Figure 2.

The integrity property is thus as follows.

Definition 3.

Integrity: An IoT system $\mathcal{S}$ is said to be a P-integrity system for a specific set CRI of critical information if:

$$\forall {\mathcal{A}}_P\in P:\mathrm{Pr}\left({\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_P}^{\mathrm{Integrity}}\left(\lambda \right)succeeds\right)\le ϵ\left(\lambda \right).$$

5.3. Availability

This notion is linked to Denial of Service (DoS) attacks. In the hospital example, an adversary may want to prohibit the IoT tablets to communicate with the rest of the system, thus blocking the doctors to do their job and jeopardizing the patients’ health. The availability experiment is described in Figure 3.

The availability property is thus as follows.

Definition 4.

Availability: An IoT system $\mathcal{S}$ is said to be P-available if:

$$\forall {\mathcal{A}}_P\in P:\mathrm{Pr}\left({\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_P}^{\mathrm{Avail}}\left(\lambda \right)succeeds\right)\le ϵ\left(\lambda \right).$$

5.4. Soundness

This notion is linked to impersonation attacks. In the hospital example, an adversary may want to insert a fake wristband that would be accepted as a legitimate IoT device of the system, in order to be treated free of charge by the hospital. The soundness experiment is described in Figure 4.

The soundness property is thus as follows.

Definition 5.

Soundness: An IoT system $\mathcal{S}$ is said to be P-sound if:

$$\forall {\mathcal{A}}_P\in P:\mathrm{Pr}\left({\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_P}^{\mathrm{Sound}}\left(\lambda \right)succeeds\right)\le ϵ\left(\lambda \right).$$

6. Formalising Security Attacks

The model allows a precise evaluation of the security level of IoT systems. In order to highlight this fact, we use it to analyse the four security properties of an IoT smart home system based on smart light bulbs. This technology consists of a number of light bulbs (i.e., IoT sensors), a dedicated hub to which the sensors connect to, a backend service that can communicate with the hub over the Internet, and a mobile application that enables the user to control the lights both from a local network or via the Internet.

Let us consider the case in which a user would like to control the smart home’s light bulbs using his smartphone, while he is either outside or inside the home. To do so, he must firstly successfully complete the Pairing protocol (as illustrated in Figure 5) between his smartphone and the hub in order to have remote access to the related sensors.

Once his smartphone is paired, the user can launch the corresponding mobile application and send commands to the light bulbs either from the inside through the hub (as depicted in Figure 6), or from the outside via the cloud service that acts as a relay between the smartphone and the hub. This scenario is exploited what follows to analyse the security level of this smart home system $\mathcal{S}$.

6.1. Confidentiality

An adversary can try to retrieve some confidential information about $\mathcal{S}$, e.g., the unique identifier ${\mathsf{ID}}_{\mathcal{P}}$ that is attributed by the hub to the smartphone during the Pairing protocol. To do so, she only needs to eavesdrop the Pairing protocol (Figure 5) to retrieve this confidential information, since this identifier is sent in cleartext from the hub to the smartphone. To formalise this attack, let us consider the $\mathsf{EAVESDROPPER}$ class. The attack performed by ${\mathcal{A}}_{\mathsf{EAVESDROPPER}}$ on $\mathcal{S}$ during ${\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_{\mathsf{EAVESDROPPER}}}^{\mathrm{Confident}}\left(\lambda \right)$ is as follows.

• The challenger $\mathcal{C}$ runs InitSystem $\left(1^{\lambda }\right)$.
• $\mathcal{C}$ defines the set of confidential information CI={$\mathsf{ID}$ of all the devices of $\mathcal{S}$}.
• ${\mathcal{A}}_{\mathsf{EAVESDROPPER}}$ interacts with $\mathcal{S}$ with the following steps.
  • She calls:

    -

    $2\times {\mathcal{O}}^{\mathrm{C}\mathrm{REATE}\mathrm{D}\mathrm{EVICE}}\left(\right)$

    and obtains the labels $\mathcal{H}$ (for the hub) and $\mathcal{P}$ (for the user’s smartphone).
  • To register the two devices within $\mathcal{S}$, she calls:

    -

    ${\mathcal{O}}^{\mathrm{R}\mathrm{EGISTER}\mathrm{D}\mathrm{EVICE}}\left(\mathcal{H}\right)$;

    -

    ${\mathcal{O}}^{\mathrm{R}\mathrm{EGISTER}\mathrm{D}\mathrm{EVICE}}\left(\mathcal{P}\right)$.

  • To eavesdrop a Pairing protocol execution between $\mathcal{H}$ and $\mathcal{P}$, she calls:

    -

    ${\mathcal{O}}^{\mathrm{E}\mathrm{XECUTE}}(\mathrm{P}\mathrm{AIRING},\mathcal{H},\mathcal{P})$.

  • She thus collects the transcripts:

    -

    ${\pi }_{\mathcal{H},\mathrm{P}\mathrm{AIRING}}^1$;

    -

    ${\pi }_{\mathcal{P},\mathrm{P}\mathrm{AIRING}}^1$.

  • She retrieves the value of ${\mathsf{ID}}_{\mathcal{P}}$ with the call:

    -

    ${\pi }_{\mathcal{P},\mathrm{P}\mathrm{AIRING}}^1.\mathsf{msg}=(\mathcal{P},\mathrm{NoAccess},{\mathsf{ID}}_{\mathcal{P}})$.

• ${\mathcal{A}}_{\mathsf{EAVESDROPPER}}$ outputs the information I=(${\mathsf{ID}}_{\mathcal{P}}$).

Consequently, this ${\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_{\mathsf{EAVESDROPPER}}}^{\mathrm{Confident}}\left(\lambda \right)$ succeeds as I is part of CI. $\mathcal{S}$ does not provide $\mathsf{EAVESDROPPER}$-confidentiality when CI={$\mathsf{ID}$ of all the devices of $\mathcal{S}$}.

6.2. Integrity

An adversary can try to modify the status of a light bulb without the knowledge of the user, and thus desynchronise this information in $\mathcal{S}$. To do so, she must be active and perform a man-in-the-middle attack to prevent the command message to be received by the light bulb. To formalise this attack, let us consider the $\mathsf{INSIDER}$ class. The attack performed by ${\mathcal{A}}_{\mathsf{INSIDER}}$ on $\mathcal{S}$ during ${\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_{\mathsf{INSIDER}}}^{\mathrm{Integrity}}\left(\lambda \right)$ is as follows.

• The challenger $\mathcal{C}$ runs InitSystem $\left(1^{\lambda }\right)$.
• $\mathcal{C}$ defines the set of critical information CRI={status $\mathrm{S}\mathrm{TAT}$ of all the light bulbs of $\mathcal{S}$}.
• ${\mathcal{A}}_{\mathsf{INSIDER}}$ interacts with $\mathcal{S}$ with the following steps.
  • As the previous attack, she calls:

    -

    $2\times {\mathcal{O}}^{\mathrm{C}\mathrm{REATE}\mathrm{D}\mathrm{EVICE}}\left(\right)$;

    -

    ${\mathcal{O}}^{\mathrm{R}\mathrm{EGISTER}\mathrm{D}\mathrm{EVICE}}\left(\mathcal{H}\right)$;

    -

    ${\mathcal{O}}^{\mathrm{R}\mathrm{EGISTER}\mathrm{D}\mathrm{EVICE}}\left(\mathcal{P}\right)$;

    -

    ${\mathcal{O}}^{\mathrm{E}\mathrm{XECUTE}}(\mathrm{P}\mathrm{AIRING},\mathcal{H},\mathcal{P})$.

  • To start a new Send_Cmd protocol execution with $\mathcal{P}$ for turning ON a light bulb $\mathcal{L}$, she calls:

    -

    ${\mathcal{O}}^{\mathrm{L}\mathrm{AUNCH}}(\mathrm{S}\mathrm{END}\_\mathrm{C}\mathrm{MD},\mathcal{P})$.

  • She thus collects the transcript:

    -

    ${\pi }_{\mathcal{P},\mathrm{S}\mathrm{END}\_\mathrm{C}\mathrm{MD}}^1$.

  • She retrieves the values sent by $\mathcal{P}$ with the call:

    -

    ${\pi }_{\mathcal{P},\mathrm{S}\mathrm{END}\_\mathrm{C}\mathrm{MD}}^1.\mathsf{msg}=({\mathsf{ID}}_{\mathcal{P}},{\mathsf{ID}}_{\mathcal{L}},\mathrm{C}\mathrm{MD})$, where $\mathrm{C}\mathrm{MD}=\left\{\mathrm{light}\mathrm{ON}\right\}$.

  • She forwards this message to $\mathcal{H}$ with the call:

    -

    ${\mathcal{O}}^{\mathrm{S}\mathrm{END}}(\mathrm{S}\mathrm{END}\_\mathrm{C}\mathrm{MD},\mathcal{H},$$({\mathsf{ID}}_{\mathcal{P}},{\mathsf{ID}}_{\mathcal{L}},\left\{\mathrm{light}\mathrm{ON}\right\}))$.

    • $\mathcal{H}$ forwards the command to the light bulb $\mathcal{L}$.
  • At that moment, ${\mathcal{A}}_{\mathsf{INSIDER}}$ “intercepts” the message: in the model, this action is represented by the fact that ${\mathcal{A}}_{\mathsf{INSIDER}}$ does not send any message to the light bulb $\mathcal{L}$, which thus remains OFF.
  • But, to make $\mathcal{H}$ believe that $\mathcal{L}$ received its message and answered positively to it, she calls:

    -

    ${\mathcal{O}}^{\mathrm{S}\mathrm{END}}(\mathrm{S}\mathrm{END}\_\mathrm{C}\mathrm{MD},\mathcal{H},({\mathsf{ID}}_{\mathcal{L}},\mathrm{S}{\mathrm{TAT}}_{\mathcal{L}}))$ with $\mathrm{S}{\mathrm{TAT}}_{\mathcal{L}}=\left\{\mathrm{ON}\right\}$.

    • $\mathcal{H}$ thus records that $\mathrm{S}{\mathrm{TAT}}_{\mathcal{L}}=\left\{\mathrm{ON}\right\}$, even though it is not true on $\mathcal{L}$’s side.
  • Finally, to make also $\mathcal{P}$ believe that everything went well and that $\mathcal{L}$ is turned ON, she calls:

    -

    ${\mathcal{O}}^{\mathrm{S}\mathrm{END}}(\mathrm{S}\mathrm{END}\_\mathrm{C}\mathrm{MD},\mathcal{P},({\mathsf{ID}}_{\mathcal{P}},{\mathsf{ID}}_{\mathcal{L}},\mathrm{S}{\mathrm{TAT}}_{\mathcal{L}}))$.

    • $\mathcal{P}$ also records that $\mathrm{S}{\mathrm{TAT}}_{\mathcal{L}}=\left\{\mathrm{ON}\right\}$.

Consequently, this ${\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_{\mathsf{INSIDER}}}^{\mathrm{Integrity}}\left(\lambda \right)$ succeeds since the status $\mathrm{S}{\mathrm{TAT}}_{\mathcal{L}}$ of the light bulb $\mathcal{L}$, i.e., part of the CRI={$\mathrm{S}\mathrm{TAT}$ of all the light bulbs of $\mathcal{S}$}, has been modified by ${\mathcal{A}}_{\mathsf{INSIDER}}$. $\mathcal{S}$ does not provide $\mathsf{INSIDER}$-integrity.

6.3. Availability

An adversary can try to perform a Denial of Service (DoS) attack in order to make the system unavailable anymore. She can thus use different techniques that might cause a DoS on the system by targeting any of its components (i.e., the hub, the sensors, or the cloud service). Here, we focus on the hub’s robustness to deal with low rate DoS. To do so, the adversary simply sends numerous requests to the hub. To formalise this attack, let us again consider the $\mathsf{INSIDER}$ class. The attack performed by ${\mathcal{A}}_{\mathsf{INSIDER}}$ on $\mathcal{S}$ during ${\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_{\mathsf{INSIDER}}}^{\mathrm{Avail}}\left(\lambda \right)$ is as follows.

• The challenger $\mathcal{C}$ runs InitSystem $\left(1^{\lambda }\right)$.
• ${\mathcal{A}}_{\mathsf{INSIDER}}$ interacts with $\mathcal{S}$ with the following steps.
  • As the first attack, she calls:

    -

    $2\times {\mathcal{O}}^{\mathrm{C}\mathrm{REATE}\mathrm{D}\mathrm{EVICE}}\left(\right)$;

    -

    ${\mathcal{O}}^{\mathrm{R}\mathrm{EGISTER}\mathrm{D}\mathrm{EVICE}}\left(\mathcal{H}\right)$;

    -

    ${\mathcal{O}}^{\mathrm{R}\mathrm{EGISTER}\mathrm{D}\mathrm{EVICE}}\left(\mathcal{P}\right)$;

    -

    ${\mathcal{O}}^{\mathrm{E}\mathrm{XECUTE}}(\mathrm{P}\mathrm{AIRING},\mathcal{H},\mathcal{P})$.

  • To start a new Send_Cmd protocol execution with the hub $\mathcal{H}$ and directly send the first message to it, she calls a certain amount X of times:

    -

    ${\mathcal{O}}^{\mathrm{S}\mathrm{END}}(\mathrm{S}\mathrm{END}\_\mathrm{C}\mathrm{MD},\mathcal{H},(\mathit{rnd},{\mathsf{ID}}_{\mathcal{L}},\mathrm{C}\mathrm{MD}))$, where $\mathit{rnd}$ is a random value replacing ${\mathsf{ID}}_{\mathcal{P}}$.

    • Of course, these messages are not accepted by the hub $\mathcal{H}$.
• ${\mathcal{A}}_{\mathsf{INSIDER}}$ designates the hub $\mathcal{H}$ and calls:

  -

  ${\mathcal{O}}^{\mathrm{E}\mathrm{XECUTE}}(\mathrm{S}\mathrm{END}\_\mathrm{C}\mathrm{MD},\mathcal{P},\mathcal{H},\mathcal{L})$.

  • The hub $\mathcal{H}$ is unable to perform correctly the protocol execution.

Consequently, this ${\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_{\mathsf{INSIDER}}}^{\mathrm{Avail}}\left(\lambda \right)$ succeeds as ${\mathcal{A}}_{\mathsf{INSIDER}}$ has been able to prevent the hub to work properly again within the system. Note that the same attack could have been formalised with an $\mathsf{EXTERNAL}$ adversary. Thus, $\mathcal{S}$ does not provide neither $\mathsf{INSIDER}$-availability nor $\mathsf{EXTERNAL}$-availability.

6.4. Soundness

An adversary can try to impersonate a legitimate user in order to send illegitimate/undesired commands to the light bulbs. To do so, she simply performs a replay attack: she reuses a previous command eavesdropped between the legitimate user’s smartphone and the hub. To formalise this attack, let us again consider the $\mathsf{INSIDER}$ class. The attack performed by ${\mathcal{A}}_{\mathsf{INSIDER}}$ on $\mathcal{S}$ during ${\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_{\mathsf{INSIDER}}}^{\mathrm{Sound}}\left(\lambda \right)$ is as follows.

• The challenger $\mathcal{C}$ runs InitSystem $\left(1^{\lambda }\right)$.
• ${\mathcal{A}}_{\mathsf{INSIDER}}$ interacts with $\mathcal{S}$ with the following steps.
  • As the first attack, she calls:

    -

    $2\times {\mathcal{O}}^{\mathrm{C}\mathrm{REATE}\mathrm{D}\mathrm{EVICE}}\left(\right)$;

    -

    ${\mathcal{O}}^{\mathrm{R}\mathrm{EGISTER}\mathrm{D}\mathrm{EVICE}}\left(\mathcal{H}\right)$;

    -

    ${\mathcal{O}}^{\mathrm{R}\mathrm{EGISTER}\mathrm{D}\mathrm{EVICE}}\left(\mathcal{P}\right)$;

    -

    ${\mathcal{O}}^{\mathrm{E}\mathrm{XECUTE}}(\mathrm{P}\mathrm{AIRING},\mathcal{H},\mathcal{P})$.

  • To eavesdrop a Send_Cmd protocol execution between $\mathcal{P}$, $\mathcal{H}$ and $\mathcal{L}$, she calls:

    -

    ${\mathcal{O}}^{\mathrm{E}\mathrm{XECUTE}}(\mathrm{S}\mathrm{END}\_\mathrm{C}\mathrm{MD},\mathcal{P},\mathcal{H},\mathcal{L})$.

  • She thus collects the transcripts:

    -

    ${\pi }_{\mathcal{P},\mathrm{S}\mathrm{END}\_\mathrm{C}\mathrm{MD}}^1$;

    -

    ${\pi }_{\mathcal{H},\mathrm{S}\mathrm{END}\_\mathrm{C}\mathrm{MD}}^1$;

    -

    ${\pi }_{\mathcal{L},\mathrm{S}\mathrm{END}\_\mathrm{C}\mathrm{MD}}^1$.

  • She retrieves all the values send by the legitimate smartphone $\mathcal{P}$ with the call:

    -

    ${\pi }_{\mathcal{P},\mathrm{S}\mathrm{END}\_\mathrm{C}\mathrm{MD}}^1.\mathsf{msg}=({\mathsf{ID}}_{\mathcal{P}},{\mathsf{ID}}_{\mathcal{L}},\mathrm{C}\mathrm{MD},\mathrm{S}{\mathrm{TAT}}_{\mathcal{L}})$.

  • To start a new Send_Cmd protocol execution with $\mathcal{H}$ and directly send the first message to it, she calls:

    -

    ${\mathcal{O}}^{\mathrm{S}\mathrm{END}}(\mathrm{S}\mathrm{END}\_\mathrm{C}\mathrm{MD},\mathcal{H},({\mathsf{ID}}_{\mathcal{P}},{\mathsf{ID}}_{\mathcal{L}},\mathrm{C}\mathrm{MD}))$.

    • $\mathcal{H}$ will accept this message as a legitimate one, and thus will forward to the bulb $\mathcal{L}$ the command sent by ${\mathcal{A}}_{\mathsf{INSIDER}}$.

Consequently, this ${\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_{\mathsf{INSIDER}}}^{\mathrm{Sound}}\left(\lambda \right)$ succeeds as ${\mathcal{A}}_{\mathsf{INSIDER}}$ has been considered as a legitimate IoT device (namely a smartphone) by the hub $\mathcal{H}$. $\mathcal{S}$ does not provide $\mathsf{INSIDER}$-soundness.

Though this type of attacks assumes that the adversary acts as an $\mathsf{INSIDER}$ of $\mathcal{S}$’s network, it might also be performed by eavesdropping similar requests between the smartphone and the cloud service. This might consequently introduce a vulnerability in $\mathcal{S}$’s architecture if the adversary can reach $\mathcal{S}$’s router from the outside world.

7. Formalising Security Proof

In this section, we analyse the confidentiality level of a smart thermostat system very similar to the one with smart light bulbs. It also has a Pairing and a Send_Cmd protocols, as depicted in Figure 7 and Figure 8. The main difference is that all the devices of the system are able to compute a PRF (Pseudo-Random Function) in order to exchange encrypted data.

Theorem 1.

The smart thermostat system $\mathcal{S}$ is $INSIDER$-confidential, for $CI=\left\{IDofallthe\mathit{devices}of\mathcal{S}\right\}$.

Proof. 

We use the game technique as described by Shoup in [16] (only modifications of the original experiment are specified in the games: unspecified queries stay unchanged) to prove the confidentiality of the smart thermostat system $\mathcal{S}$ against $\mathsf{INSIDER}$ adversaries. First, we assume that the key exchange protocol used at the beginning of the Pairing protocol is secure against man-in-the-middle attacks (for instance, this is not the case for the original well-known Diffie-Hellman protocol).

Game 0:

This game corresponds to the confidentiality experiment ${\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_{\mathsf{INSIDER}}}^{\mathrm{Confident}}\left(\lambda \right)$ performed by the adversary ${\mathcal{A}}_{\mathsf{INSIDER}}$ on $\mathcal{S}$ of security parameter $\lambda$. Let CI={$\mathsf{ID}$ of all the devices of $\mathcal{S}$}. Let $S_0$ denote the event “I is (part of) CI” in Game 0. Thus, we have that $\mathrm{Pr}\left(S_0\right)=\mathrm{Pr}\left({\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_{\mathsf{INSIDER}}}^{\mathrm{Confident}}\left(\lambda \right)\mathrm{succeeds}\right)$.

Let us assume that ${\mathcal{A}}_{\mathsf{INSIDER}}$ performs q${\mathcal{O}}^{\mathrm{S}\mathrm{END}}$ queries to the hub during the Pairing protocol. These ${\mathcal{O}}^{\mathrm{S}\mathrm{END}}$ queries are called “encryption queries” in the sequel of the proof. From Game 0, we introduce q transitions games as follows.

Game i:

This is the same game as Game $(i-1)$ except that one additional encryption query has been replaced as defined below:

• the $i^{\mathrm{th}}$ first encryption queries are such that $F={\mathsf{ID}}_{\mathcal{P}}\oplus \mathrm{PRF}(n,n_{\mathcal{H}}),$ where $n{\in }_R{\{0,1\}}^{{\lambda }_{\mathsf{k}}}$ and ${\lambda }_{\mathsf{k}}$ is the output size of the key ${\mathsf{k}}_{\mathcal{P}}$, and thus F is the result of the fixed value ${\mathsf{ID}}_{\mathcal{P}}$ XORed with a pure PRF (i.e., used only with random values);
• the $(q-i)$ next encryption queries are such that $F={\mathsf{ID}}_{\mathcal{P}}\oplus \mathrm{PRF}({\mathsf{k}}_{\mathcal{P}},n_{\mathcal{H}}),$ where F is the result of the fixed value ${\mathsf{ID}}_{\mathcal{P}}$ XORed with a keyed PRF (i.e., used with the secret key ${\mathsf{k}}_{\mathcal{P}}$).

Let $S_i$ denote the event “I is (part of) CI” in Game i, and $\mathrm{Pr}\left(S_i\right)$ denote its success probability.

Game $(i-1)$ to Game i (for $1\le i\le q$) only differ from one encryption query. As stated by Shoup in [16], the probability to distinguish a keyed PRF from a pure PRF is called the PRF advantage ${\mathrm{Adv}}_{\mathcal{S}}^{\mathrm{PRF}}$ and is negligible. This implies:

$$\forall i\mathrm{s}.\mathrm{t}.1\le i\le q:|\mathrm{Pr}\left(S_{i-1}\right)-\mathrm{Pr}\left(S_i\right)|={\mathrm{Adv}}_{\mathcal{S}}^{\mathrm{PRF}}\le ϵ\left(\lambda \right).$$

At the end of these q steps, the following game is obtained.

Game q:

This is the game where all the q encryption queries during the Pairing protocol have been replaced by $F={\mathsf{ID}}_{\mathcal{P}}\oplus \mathrm{PRF}(n,n_{\mathcal{H}}),$. Let $S_q$ denote the event “I is (part of) CI” in Game q, and $\mathrm{Pr}\left(S_q\right)$ denote its success probability.

From Game q, the same reasoning can be applied for the Send_Cmd protocol. Let thus assume that ${\mathcal{A}}_{\mathsf{INSIDER}}$ performs $q^{\prime }$ encryption queries to the devices of $\mathcal{S}$. This also implies:

$$\forall j\mathrm{s}.\mathrm{t}.1\le j\le q^{\prime }:|\mathrm{Pr}\left(S_{q+j-1}\right)-\mathrm{Pr}\left(S_{q+j}\right)|={\mathrm{Adv}}_{\mathcal{S}}^{\mathrm{PRF}}\le ϵ\left(\lambda \right).$$

Game $(q+q^{\prime })$:

This is the final game of this proof, where all the $q^{\prime }$ encryption queries during the Send_Cmd protocol have been replaced by a pure PRF. Let $S_{\mathrm{final}}$ denote the event “I is (part of) CI” in Game $(q+q^{\prime })$, and $\mathrm{Pr}\left(S_{\mathrm{final}}\right)$ denote its success probability. Since ${\mathcal{A}}_{\mathsf{INSIDER}}$ is unable to recover any $\mathsf{ID}$ from a pure PRF, she can only try to output a random value I: therefore $\mathrm{Pr}\left(S_{\mathrm{final}}\right)\le ϵ\left(\lambda \right)$.

From all the transitions, the conclusion is that:

$$\begin{array}{ccc}\hfill \mathrm{Pr}\left({\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_{\mathsf{INSIDER}}}^{\mathrm{Confident}}\left(\lambda \right)\mathrm{succeeds}\right)& =\hfill & \mathrm{Pr}\left(S_0\right)-\mathrm{Pr}\left(S_1\right)+\mathrm{Pr}\left(S_1\right)-\dots -\mathrm{Pr}\left(S_q\right)\hfill \\ & & +\mathrm{Pr}\left(S_q\right)-\dots -\mathrm{Pr}\left(S_{\mathrm{final}}\right)+\mathrm{Pr}\left(S_{\mathrm{final}}\right)\hfill \\ & \le \hfill & \mathrm{Pr}\left(S_{\mathrm{final}}\right)+\sum _{i=0}^{q-1}\left|\mathrm{Pr}\left(S_i\right)-\mathrm{Pr}\left(S_{i+1}\right)\right|\hfill \\ & & +\sum _{j=0}^{q^{\prime }-1}\left|\mathrm{Pr}\left(S_{q+j}\right)-\mathrm{Pr}\left(S_{q+j+1}\right)\right|\hfill \\ & \le \hfill & \mathrm{Pr}\left(S_{\mathrm{final}}\right)+(q+q^{\prime }).{\mathrm{Adv}}_{\mathcal{S}}^{\mathrm{PRF}}\le ϵ\left(\lambda \right).\hfill \end{array}$$

 □

Consequently, this ${\mathit{Exp}}_{\mathcal{S},{\mathcal{A}}_{\mathsf{INSIDER}}}^{\mathrm{Confident}}\left(\lambda \right)$ succeeds with negligible probability. This proves Theorem 1: the smart thermostat system $\mathcal{S}$ described in this section provides $\mathsf{INSIDER}$-confidentiality when $\mathrm{CI}=\left\{\mathsf{ID}\mathrm{of}\mathrm{all}\mathrm{the}\mathrm{devices}\mathrm{of}\mathcal{S}\right\}$.

8. Conclusions and Future Research

In this paper, we proposed a new model able to analyse the security properties of IoT systems. The model is composed of (1) the formalisation of IoT systems; (2) the definition of the potential adversary classes based on oracles, selectors, and restrictions that are inspired from real-life examples of IoT attacks; and (3) the definition of four well-established security properties (confidentiality, integrity, availability, soundness).

The purpose of our model is twofold: it can be used either to accurately describe attacks against IoT systems, or to formally prove the security level guaranteed by IoT systems. Formal proofs are a tremendous support to identify the critical elements of an IoT system. In particular, they help in highlighting the vulnerabilities and weakest links, and thus assist the IoT designers in building better and more secure systems. They can be used during the design phase in order to set the security targets of the implementation. Then, when the security tests are performed, the results can be verified against the initial claims and, depending on the outcome, adjustments may be performed in the initial design of the system. Since formal proofs guarantee a certain security level, they form a universal security evaluation able to compare fairly different IoT systems. Our model could consequently also assist in building an IoT certification framework.

Inheriting the positive specificities of the RFID privacy model [9], our model also provides extensibility and granularity in the analyses. The extensibility is brought with the possibility to add new features to the model (i.e., new oracles, selectors, restrictions), and the granularity is given with the practicability to define as many potential adversaries as possible.

Nonetheless, such features of extensibility and granularity might bring some limitations and intricacy in the security analysis. First, our model is designed to allow the definition of any adversary class. This can add some difficulties in ordering the strength of the adversaries, thus rendering troublesome to compare the security level of different IoT systems. Secondly, in order to entitle an irrefutable security level to an IoT system, our model should be used to provide one formal proof for a given adversary class P and one attack for the consecutive stronger adversary class. This should prove that the analysed IoT system ensures the given P security level (e.g., P-confidentiality). In practice, this can be complex to put in place since the extensibility and granularity of our model allows the finding and introduction of new adversary classes that might be inserted between supposedly consecutive classes.

In the near future, we are planning to extend our model to support access control mechanisms formalisation and proofs in IoT systems, covering secure data access requirements as already identified in other related works [14].