Towards a Formal IoT Security Model

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.


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 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.

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.

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.

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

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 λ; 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.

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.

Transcripts
The subset of actions performed by an entity X during a protocol execution is called algorithm. During an algorithm execution, 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 X engages in a new algorithm execution. π i X ,PROT denotes the transcript of the i th execution of X 's algorithm related to a protocol PROT.

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 ε i X denotes the i th snapshot of X 's internal state.

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.

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.

•
O CREATEDEVICE () → X : executes the CREATEDEVICE procedure, and returns the label X . • O REGISTERDEVICE (X ) → ∅: executes the REGISTERDEVICE procedure on the device 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.
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.
• O LAUNCH (PROT, X ) → π i X ,PROT : makes X launch a new execution of the protocol PROT, fills up and outputs the transcript π i X ,PROT when all the actions related to the oracle query are performed.
: sends a message m to X , fills up and outputs the transcript π i X ,PROT when all the actions related to the oracle query are performed.
(iii) Oracle that captures information on the system.
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.

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, π.s (resp. ε.s) denotes the information accessible through s contained in the transcript π (resp. the snapshot ε).
(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.

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 O REGISTERDEVICE : • Reg: all the devices must be registered.
Some restrictions on the use of O CORRUPT 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.

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 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. EAVESDROPPER adversaries are INSIDER with limited capabilities (as explained in [9], the adversary classes can be (partially) ordered. For instance, an INSIDER adversary is stronger than an EAVESDROPPER one): they can only listen to communications between the legitimate devices. On the other hand, 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 As a simple but concrete example, an EAVESDROPPER adversary can use the oracles O CREATEDEVICE , O REGISTERDEVICE , O EXECUTE , the selectors msg and result, all with the restrictions Reg and Device.

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.

•
S is an IoT system of global security parameter λ.
A P is the adversary A belonging to the class P playing an experiment Exp. • C is the challenger, i.e., the honest entity that determines a kind of riddle that must be answered by A P at the end of Exp.
The goal of A P is to win Exp with non-negligible probability, in comparison to a dumb adversary who is considered to always perform random interactions during the experiment.

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.
C defines the set of confidential information CI. 3. A P interacts with the system S, limited by her class P. 4. A P outputs some information I. The confidentiality property is thus as follows.

Definition 2.
Confidentiality: An IoT system S is said to be P-confidential for a specific set CI of confidential information if:

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 S is said to be a P-integrity system for a specific set CRI of critical information if: ∀A P ∈ P : Pr Exp Integrity S,A P (λ) succeeds ≤ (λ).

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.
A P interacts with the system S, limited by her class P. 3. A P designates a specific IoT device D, and makes it interact with S.
Exp Avail S,A P (λ) succeeds if D is no longer working within S. The availability property is thus as follows.
Definition 4. Availability: An IoT system S is said to be P-available if: ∀A P ∈ P : Pr Exp Avail S,A P (λ) succeeds ≤ (λ).

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.
A P interacts with the system S, limited by her class P.
Exp Sound S,A P (λ) succeeds if A P is considered as a legitimate IoT device of S. The soundness property is thus as follows.

Definition 5.
Soundness: An IoT system S is said to be P-sound if: ∀A P ∈ P : Pr Exp Sound S,A P (λ) succeeds ≤ (λ).

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 S. Figure 6. SEND_CMD protocol from inside (smart light bulbs system).

Confidentiality
An adversary can try to retrieve some confidential information about S, e.g., the unique identifier ID 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 EAVESDROPPER class. The attack performed by A EAVESDROPPER on S during Exp Confident S,A EAVESDROPPER (λ) is as follows.
1. The challenger C runs INITSYSTEM(1 λ ). 2. C defines the set of confidential information CI={ID of all the devices of S}. 3. A EAVESDROPPER interacts with S with the following steps.

•
She calls: and obtains the labels H (for the hub) and P (for the user's smartphone).

•
To register the two devices within S, she calls: To eavesdrop a PAIRING protocol execution between H and P, she calls: She thus collects the transcripts: She retrieves the value of ID P with the call: π 1 P,PAIRING .msg = (P, NoAccess, ID P ). 4. A EAVESDROPPER outputs the information I=(ID P ).

Consequently, this Exp Confident
S,A EAVESDROPPER (λ) succeeds as I is part of CI. S does not provide EAVESDROPPER-confidentiality when CI={ID of all the devices of S}.

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 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 INSIDER class. The attack performed by A INSIDER on S during Exp Integrity S,A INSIDER (λ) is as follows.
1. The challenger C runs INITSYSTEM(1 λ ). 2. C defines the set of critical information CRI={status STAT of all the light bulbs of S}. 3. A INSIDER interacts with S with the following steps.

•
As the previous attack, she calls: To start a new SEND_CMD protocol execution with P for turning ON a light bulb L, she calls: She thus collects the transcript: She retrieves the values sent by P with the call: H thus records that STAT L = {ON}, even though it is not true on L's side.

•
Finally, to make also P believe that everything went well and that L is turned ON, she calls: -O SEND (SEND_CMD, P, (ID P , ID L , STAT L )).
P also records that STAT L = {ON}.

Consequently, this Exp
Integrity S,A INSIDER (λ) succeeds since the status STAT L of the light bulb L, i.e., part of the CRI={STAT of all the light bulbs of S}, has been modified by A INSIDER . S does not provide INSIDER-integrity.

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 INSIDER class. The attack performed by A INSIDER on S during Exp Avail S,A INSIDER (λ) is as follows.

2.
A INSIDER interacts with S with the following steps.
• As the first attack, she calls: To start a new SEND_CMD protocol execution with the hub H and directly send the first message to it, she calls a certain amount X of times: where rnd is a random value replacing ID P .
Of course, these messages are not accepted by the hub H. The hub H is unable to perform correctly the protocol execution.
Consequently, this Exp Avail S,A INSIDER (λ) succeeds as A 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 EXTERNAL adversary. Thus, S does not provide neither INSIDER-availability nor EXTERNAL-availability.

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 INSIDER class. The attack performed by A INSIDER on S during Exp Sound S,A INSIDER (λ) is as follows.
1. The challenger C runs INITSYSTEM(1 λ ). 2. A INSIDER interacts with S with the following steps.
• As the first attack, she calls: To eavesdrop a SEND_CMD protocol execution between P, H and L, she calls: She thus collects the transcripts: She retrieves all the values send by the legitimate smartphone P with the call: π 1 P,SEND_CMD .msg = (ID P , ID L , CMD, STAT L ). • To start a new SEND_CMD protocol execution with H and directly send the first message to it, she calls: H will accept this message as a legitimate one, and thus will forward to the bulb L the command sent by A INSIDER .
Consequently, this Exp Sound S,A INSIDER (λ) succeeds as A INSIDER has been considered as a legitimate IoT device (namely a smartphone) by the hub H. S does not provide INSIDER-soundness.
Though this type of attacks assumes that the adversary acts as an INSIDER of 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 S's architecture if the adversary can reach S's router from the outside world.

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 Figures 7 and 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.
• Register ID P Figure 7. PAIRING protocol (smart thermostat system). 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 S against 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 Exp Confident S,A INSIDER (λ) performed by the adversary A INSIDER on S of security parameter λ. Let CI={ID of all the devices of S}. Let S 0 denote the event "I is (part of) CI" in Game 0. Thus, we have that Pr(S 0 ) = Pr(Exp Confident S,A INSIDER (λ) succeeds).
Let us assume that A INSIDER performs q O SEND queries to the hub during the PAIRING protocol. These O SEND 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 th first encryption queries are such that F = ID P ⊕ PRF(n, n H ), where n ∈ R {0, 1} λ k and λ k is the output size of the key k P , and thus F is the result of the fixed value ID P XORed with a pure PRF (i.e., used only with random values); • the (q − i) next encryption queries are such that F = ID P ⊕ PRF(k P , n H ), where F is the result of the fixed value ID P XORed with a keyed PRF (i.e., used with the secret key k P ).
Let S i denote the event "I is (part of) CI" in Game i, and Pr(S i ) denote its success probability.
Game (i − 1) to Game i (for 1 ≤ i ≤ 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 Adv PRF S and is negligible. This implies: 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 = ID P ⊕ PRF(n, n H ),. Let S q denote the event "I is (part of) CI" in Game q, and Pr(S q ) denote its success probability.
From Game q, the same reasoning can be applied for the SEND_CMD protocol. Let thus assume that A INSIDER performs q encryption queries to the devices of S. This also implies: Game (q + q ): This is the final game of this proof, where all the q encryption queries during the SEND_CMD protocol have been replaced by a pure PRF. Let S final denote the event "I is (part of) CI" in Game (q + q ), and Pr(S final ) denote its success probability. Since A INSIDER is unable to recover any ID from a pure PRF, she can only try to output a random value I: therefore Pr(S final ) ≤ (λ).
From all the transitions, the conclusion is that: Consequently, this Exp Confident S,A INSIDER (λ) succeeds with negligible probability. This proves Theorem 1: the smart thermostat system S described in this section provides INSIDER-confidentiality when CI = {ID of all the devices of S}.

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