# Towards a Formal IoT Security Model

^{*}

^{†}

## Abstract

**:**

## 1. Introduction

## 2. Overview of IoT Systems

#### 2.1. IoT Devices

#### 2.2. Backend System

#### 2.3. Users

## 3. Formalisation of IoT Systems

#### 3.1. Initialization Procedures

#### 3.2. Protocols

#### 3.3. Transcripts

#### 3.4. Snapshots

## 4. IoT Adversary

#### 4.1. Oracles

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

#### 4.2. Selectors

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

`Reg`: all the devices must be registered.

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

`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

**Definition**

**1**

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

- $\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}\})$.

`Reg`and

`Device`.

## 5. Security Properties

- $\mathcal{S}$ is an IoT system of global security parameter $\lambda $.
- $\u03f5(.)$ 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}$.

#### 5.1. Confidentiality

**Definition**

**2.**

#### 5.2. Integrity

**Definition**

**3.**

#### 5.3. Availability

**Definition**

**4.**

#### 5.4. Soundness

**Definition**

**5.**

## 6. Formalising Security Attacks

#### 6.1. Confidentiality

- 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\phantom{\rule{3.33333pt}{0ex}}\times \phantom{\rule{3.33333pt}{0ex}}{\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}}$).

#### 6.2. Integrity

- 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\phantom{\rule{3.33333pt}{0ex}}\times \phantom{\rule{3.33333pt}{0ex}}{\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}\phantom{\rule{4.pt}{0ex}}\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}\phantom{\rule{4.pt}{0ex}}\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\}$.

#### 6.3. Availability

- 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\phantom{\rule{3.33333pt}{0ex}}\times \phantom{\rule{3.33333pt}{0ex}}{\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.

#### 6.4. Soundness

- 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\phantom{\rule{3.33333pt}{0ex}}\times \phantom{\rule{3.33333pt}{0ex}}{\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}}$.

## 7. Formalising Security Proof

**Theorem**

**1.**

**Proof.**

- 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)\phantom{\rule{4.pt}{0ex}}\mathrm{succeeds}\right)$.

- 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}}$).

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

- 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 \u03f5\left(\lambda \right)$.

## 8. Conclusions and Future Research

## Author Contributions

## Funding

## Conflicts of Interest

## References

- Ronen, E.; Shamir, A.; Weingarten, A.O.; O’Flynn, C. IoT Goes Nuclear: Creating a ZigBee Chain Reaction. In Proceedings of the IEEE Symposium on Security and Privacy—SP 2017, San José, CA, USA, 22–26 May 2017; pp. 195–212. [Google Scholar]
- Mohsin, M.; Anwar, Z.; Husari, G.; Al-Shaer, E.; Rahman, M.A. IoTSAT: A Formal Framework for Security Analysis of the Internet of Things (IoT). In Proceedings of the Conference on Communications and Network Security—CNS 2016, Philadelphia, PA, USA, 17–19 October 2016; pp. 180–188. [Google Scholar]
- Armando, A.; Basin, D.A.; Boichut, Y.; Chevalier, Y.; Compagna, L.; Cuéllar, J.; Drielsma, P.H.; Héam, P.C.; Kouchnarenko, O.; Mantovani, J.; et al. The AVISPA Tool for the Automated Validation of Internet Security Protocols and Applications. In Proceedings of the International Conference on Computer Aided Verification—CAV 2005, Edinburgh, Scotland, UK, 6–10 July 2005; pp. 281–285. [Google Scholar]
- Cremers, C.J.F. The Scyther Tool: Verification, Falsification, and Analysis of Security Protocols. In Proceedings of the International Conference on Computer Aided Verification—CAV 2008, Princeton, NJ, USA, 7–14 July 2008; pp. 414–418. [Google Scholar]
- Jha, S.; Sheyner, O.; Wing, J. Two Formal Analyses of Attack Graphs. In Proceedings of the IEEE Computer Security Foundations Workshop—CSFW-15, Cape Breton, NS, Canada, 24–26 June 2002; pp. 49–63. [Google Scholar]
- Mauw, S.; Oostdijk, M. Foundations of Attack Trees. In Proceedings of the 8th International Conference on Information Security and Cryptology—ICISC 2005, Seoul, Korea, 1–2 December 2005; Volume 3935, pp. 186–198. [Google Scholar]
- Tabrizi, F.M.; Pattabiraman, K. Formal Security Analysis of Smart Embedded Systems. In Proceedings of the 32nd Annual Conference on Computer Security Applications—ACSAC 2016, Los Angeles, CA, USA, 5–9 December 2016; pp. 1–15. [Google Scholar]
- Coisel, I.; Martin, T. Untangling RFID Privacy Models. J. Comput. Networks Commun.
**2013**, 2013, 710275. [Google Scholar] [CrossRef] [Green Version] - Avoine, G.; Coisel, I.; Martin, T. Untraceability Model for RFID. IEEE Trans. Mob. Comput.
**2014**, 13, 2397–2405. [Google Scholar] [CrossRef] - Kayes, A.S.M.; Han, J.; Colman, A.; Islam, M.S. RelBOSS: A Relationship-Aware Access Control Framework for Software Services. In On The Move to Meaningful Internet Systems—OTM 2014; Springer: Berlin/Heidelberg, Germany, 2014; pp. 258–276. [Google Scholar]
- Kayes, A.S.M.; Rahayu, W.; Dillon, T.S.; Chang, E. Accessing Data from Multiple Sources Through Context-Aware Access Control. In Proceedings of the 17th IEEE International Conference On Trust, Security And Privacy in Computing and Communications/12th IEEE International Conference On Big Data Science And Engineering—TrustCom/BigDataSE, New York, NY, USA, 1–3 August 2018; pp. 551–559. [Google Scholar]
- Kayes, A.S.M.; Rahayu, W.; Dillon, T.S. Critical Situation Management Utilizing IoT-Based Data Resources through Dynamic Contextual Role Modeling and Activation. Computing
**2019**, 101, 743–772. [Google Scholar] [CrossRef] - Tu, D.Q.; Kayes, A.S.M.; Rahayu, W.; Nguyen, K. ISDI: A New Window-Based Framework for Integrating IoT Streaming Data from Multiple Sources. In Proceedings of the Advanced Information Networking and Applications—AINA 2019, Matsue, Japan, 27–29 March 2019; Volume 926, pp. 498–511. [Google Scholar]
- Kayes, A.S.M.; Kalaria, R.; Sarker, I.H.; Islam, M.S.; Watters, P.A.; Ng, A.; Hammoudeh, M.; Badsha, S.; Kumara, I. A Survey of Context-Aware Access Control Mechanisms for Cloud and Fog Networks: Taxonomy and Open Research Issues. Sensors
**2020**, 20, 9. [Google Scholar] [CrossRef] [PubMed] - UPnP Forum. UPnP™ Device Architecture 1.1; Technical Report; UPnP: Beaverton, OR, USA, 2008. [Google Scholar]
- Shoup, V. Sequences of Games: A Tool for Taming Complexity in Security Proofs; Cryptology ePrint Archive, Report 2004/332; IACR: Las Vegas, NV, USA, 2004. [Google Scholar]

© 2020 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Martin, T.; Geneiatakis, D.; Kounelis, I.; Kerckhof, S.; Nai Fovino, I.
Towards a Formal IoT Security Model. *Symmetry* **2020**, *12*, 1305.
https://doi.org/10.3390/sym12081305

**AMA Style**

Martin T, Geneiatakis D, Kounelis I, Kerckhof S, Nai Fovino I.
Towards a Formal IoT Security Model. *Symmetry*. 2020; 12(8):1305.
https://doi.org/10.3390/sym12081305

**Chicago/Turabian Style**

Martin, Tania, Dimitrios Geneiatakis, Ioannis Kounelis, Stéphanie Kerckhof, and Igor Nai Fovino.
2020. "Towards a Formal IoT Security Model" *Symmetry* 12, no. 8: 1305.
https://doi.org/10.3390/sym12081305