Overview
In 1999, the term "Internet of Things" (IoTs) first appeared in a presentation of Kevin Ashton [1] Also within this year, Neil Gershenfeld was speaking about similar defi- nition from the MIT Media Lab in his book "When Things Start to Think" [2] 1999 can be considered as a big year for IoTs Nearly twenty years have passed, now IoTs systems are so familiar in our daily life The number of IoTs devices increases rapidly every year and is forecast to grow to almost 31 billion worldwide in 2020 [3] The appearance of IoTs changes the ways in which individuals and organizations interact with the physical world and communicate among themselves For example, the inter- action with home equipment, automotive, mobile devices and industrial machines will be not the same as before In all aspects of modern life, i.e learning, traffic, health care, working , applying IoT technology helps to improve the quality of services and increase satisfaction of users Its greatest benefit comes from highly heterogeneous in- terconnected devices and systems, covering every shape, size, and functionality As shown in Figure 1.1, researcher estimated that around 75.4 billions of devices will be connected to the Internet by 2025 [4] These objects in the IoT have capabilities of communicating and interacting with each other to exchange their data, providing monitoring of the environment around to enable and giving responses to changes in the system’s environment Such capabilities are promising in totally changing human lifestyle, making it safer, more convenient and comfortable This motivation has at- tracted and encouraged many researchers to participate in designing and inventing novel solutions and applications for the IoT.
Figure 1.1: The global market of IoT devices estimations by years.
With this growth of IoTs, security becomes a survival problem In fact, Gartner
’s 2016 IoT Backbone Survey showed that 32% of Information Technology leaders cited security as a top barrier to IoT success [5] In order to keep the IoT the system safe, the authentication process between IoT devices must be well-controlled How- ever, IoTs environment also has its own constraints which make it different from other systems: the uncontrolled environment, the heterogeneity, the need for scalability, as well as the constrained resource [6] As a result, the authentication protocol in IoT must be lightweight and flexible Gartner reports that 20% of organizations suffer at least one IoT security attack in the last three years [7] Prior technology trends, e.g., cloud computing and big data, seem to have quite similar security requirements with the IoT Nonetheless, the IoT unique nature introduces new challenges to security re- quirements, which are much different from previous technology trends For example, big data solutions are not required to deal with an uncontrolled environment and con- strained resources, while cloud computing hardly deals with the mobility of devices and physical accessibility of sensors [8].
The security requirements for IoT systems depend on their domains of appli- cations They include the needs of confidentiality, integrity, and authenticity Among those, authenticity is the major requirement for the IoT [9], which provides the proof that a connection is established with an authenticated entity Authentication is an im- portant factor in which each connected object’s identity is required to be verified before they can securely communicate as well as access various IoT resources Be- sides, privacy is considered to be one of the most dominant challenges in the IoT [10].
Highly interconnected objects in the IoT produce a huge amount of transmitted data. These data may contain different kinds of information directly involved users’ daily lives through their devices so that IoT applications can provide corresponding ser- vices The involvement of users’ behaviors, preferences as well as private data has raised the concern about the risk of leakage of privacy, which becomes a huge obsta- cle when putting IoT applications into use For such reasons, effective and efficient authentication protocols to protect users’ private information are essential to provide the security of every IoT system.
Device to Device (D2D) connection is a part of IoTs One of the most popular standards for Device to Device connection is Bluetooth To adapt with the expansion of IoTs, The Bluetooth Special Interest Group (SIG) introduced Bluetooth Low En- ergy (also called Bluetooth Smart or BLE) BLE started as part of the Bluetooth 4.0 Core Specification IoT applications can rely on BLE for local connection between smart phones and resource constrained peripherals since this standard is designed to be low cost, robust and especially energy-efficient In 2016, Bluetooth SIG releasesBluetooth 5.0 with 4x range, 2x speed and 8x broadcasting message capacity compar- ing with Bluetooth 4.0 [11] The enhancements of Bluetooth 5.0 aim to increase the functionality of Bluetooth for the IoTs, hence, it can be used in smart home automa- tion, enterprise, and industrial markets.
Contributions
Scientific contributions
• The thesis contributes a new authentication mechanism for IoTs devices which uses BLE as connection method due to its above advantages.
• Experiments are condcuted on real devices (Raspberry Pi 3 Model B+) and per- form evaluation with BLE.
• The proposed protocol also preserves the privacy of participants thanks to BLE security features.
Practical contributions
• This research contributes a new authentication solution that can be used for low- powered devices, which only need to have BLE hardware, with limited compu- tational capabilities, especially in the IoT environment.
• The research also raises and addresses not only the security but also the privacy aspects of devices in the IoT.
Research scope
In fact, IoT has a very large context that includes many different kinds of systems. Therefore, in the scope of this thesis, I mainly focus on the devices which supports BLE features So from now on anytime a device mentioned in this thesis, should have BLE by default The research also only focuses on one of the most essential of IoTs is D2D authentication as described in Figure 1.2 I will use a party as the scenario, hence, the proposed protocol can be called Party-Crasher protocol The objects in this protocol are generalized into only three entities:
• Device 1 or Party Crasher:The device wants to join the group or the party.
• Device 2 or Party Owner:The device acting as Party owner, who know all party participants and be trusted by them This device can directly communicate with all participant devices and with trusted by them.
• Group of Devices 3 or Party Participant: These devices can give their individual judgment for the uninvited guest The judgment can be not the same in different party.
The advantages of this model are all the computations handled by different de- vices, so no device gets overloaded and consumes just few energy.
Thesis outline
The rest of the thesis is organized as follows:
Figure 1.2: The network architecure considered in the scope of this thesis.
• Chapter 2 provides the backgrounds including a thorough study about the IoT and the cryptographic materials that will be used in later chapters.
• Chapter 3 outlines some related works that have been presented in the same field of authentication solutions.
• Chapter 4is where I propose the authentication protocol to be used for the IoT devices which support BLE.
• Chapter 5 explains my proposal about the software, hardware and framework APIs in case we implement this protocol.
• Chapter 6presents the security analysis where I prove the correctness as well as the security of the newly proposed protocol.
• Chapter 7 is the performance analysis in which I will analyze the efficiency of resource consumption of the proposed protocol compared with the base scheme.
• Chapter 8 concludes the work in this thesis, discusses and re-emphasizes the contributions as well as proposes the future works.
Internet of Things overview
IoT properties
Unlike traditional systems such as enterprise applications, cloud computing or BigData, IoT systems are uniquely identified by several properties These properties also raise the challenges that we need to deal with when working in the field Related IoT research [8] identified four distinguishing properties of IoT in terms of security and privacy challenges, which are: the uncontrolled environment, the heterogeneity, the need for scalability and the resource constraints of IoT devices.
• Uncontrolled environment: The uncontrolled environment of IoT is caused by the main fact that things can travel to unreliable surroundings possibly without supervision In other words, this property composes three sub-properties which are: mobility, physical accessibility and trust.
• Mobility: Connectivity in networks of IoT systems are not expected to be stable or always available.
• Physical accessibility: More often than not, sensors in IoT remains unprotected and can be publicly accessed by outsiders, e.g., traffic control cameras and weather sensors.
• Trust: It is unlikely to achieve a priori trusted relationships for the huge number of devices and users Therefore, it is essential to have mechanisms that automat- ically validate and manage the trust of things, services and users in IoT systems.
• Heterogeneity: IoT has to integrate a wide range of devices from many differ- ent manufacturers so their version compatibility and interoperability need to be guaranteed.
• Scalability: The vast amount of IoT interconnected things requires highly scal- able protocols.
• Resource Constraints:A large proportion of involved devices in the IoT has low energy power and computational capability Therefore, proposed solutions re- quiring complex computations and high energy consumption cannot be applied to the IoT in practice.
Public key cryptography
Public-key encryption
With public-key encryption, each public key is published and its corresponding pri- vate key of an entity is kept secret Data that are encrypted with the public key can only be decrypted with its private key as shown in Figure 2.2 As we can see, this scheme allows anyone with the public key encrypt the data and only the person who owns the corresponding private key can decrypt and read the content of the original data Public-key encryption nevertheless requires more processing than symmetric- key encryption, thus may not be suitable for encrypting a large amount of data One approach to address this weakness is to use the public-key scheme to encrypt and send symmetric keys only These symmetric keys later can be used to encrypt the actual exchange data This approach is used by the SSL/TLS protocols.
Figure 2.2: Encryption/Decryption in Public-key cryptosystems.
Compared with symmetric-key encryption, public-key encryption requires more processing and may not be feasible for encrypting and decrypting large amounts of data However, it is possible to use public-key encryption to send a symmetric key,which can then be used to encrypt additional data This is the approach used by theSSL/TLS protocols.
Public-key digital signature
A public-key scheme also allows encrypting its data with a private key and using the corresponding public to decrypt those data It is possible to use a private key for encryption and the corresponding public key for decryption This is a technique for digitally signing data Instead of encrypting the data itself, this technique is to create a one-way hash of the data, then use the private key to encrypt the hash The encrypted hash, along with other information such as the hashing algorithm, is known as a digital signature [18].
Figure 2.3: Using a Digital Signature to Validate Data Integrity
Figure 2.3 describes the use of a digital signature to validate data integrity The original data along with its signature are transferred from a sender to a recipient The digital signature is generated by first creating a one-way hashed data from the orig- inal data After that, this hashed data are encrypted using the sender’s private key. When the recipient receives these two items (the original data and its digital signa- ture), he/she validates the data integrity by decrypting the digital signature using the claimed-to-be sender with its public key then applying the same one-hash algorithm.
If the final hash operation results in the identical hashes, the validity of the data can be confirmed.
Bluetooth Low Energy
Overview
Bluetooth Low Energy is a personal local network technology that is designed and sold by Bluetooth Special Interest Group (Bluetooth SIG) It is aimed at applications in the fields of medical and health care, sports and fitness, beacon, security, family entertainment and so on Especially in the fields of industry and building automation, Bluetooth Low Energy has very low energy consumption and extensive wireless net- working features, so Bluetooth Low Energy has a vast market From Bluetooth 4.0, Bluetooth Low Energy (BLE) protocols are supported Bluetooth 4.0 is also known as Bluetooth Smart, Bluetooth Smart Ready and Bluetooth Low Energy Most wear- able devices and smartphones are supporting Bluetooth 4.0 and 5.0 Bluetooth Smart devices are peripheral devices like speakers, headphones, fitness trackers, smart pens, medical devices and so on These devices get resource constraints and limited amount of battery They are suitable for simple calculation According to the Bluetooth LowEnergy Core Specification, there are two roles defined (GAPRoles) when the Blue- tooth Low Energy connection is established The node that initiates the connection defined as the Central device and the node that is connected to by the central is de- fined as the peripheral device They often have paired hosts (or centrals) and require periodic connection to it, like during data transfer These peripheral are also able to maintain the pairing despite long sleep periods between active modes to prevent a sec- ond device from pairing Our smart phones and laptop are considered as BluetoothSmart Ready devices They have powerful processor and can control peripheral de- vices via Bluetooth connection Bluetooth Smart Ready can also exchange data with old Bluetooth 2.0 or 3.0 device With 4x range, 2x speed and 8x broadcasting message capacity comparing with Bluetooth 4.0, the enhancements of Bluetooth 5.0 aims to increase the functionality of Bluetooth for the IoT.
Network topology
Central and Peripheral in other phases of BLE can be called as Master and Slave.BLE device can operate either in master or slave role A master can manage multiple simultaneous connections with a number of slave devices, but a slave can only be con- nected to a single master Differently from classic BT, discovery is done so that slave advertises on one or several of the three designated advertisement channels Master scans these channels in order to discover slaves After discovery, data transmission happens in the form of connection events in which the master and the slave wake up in synchronous mode to exchange frames Both devices sleep the rest of time.
To best meet the wireless connectivity needs of a diverse developer population, Blue- tooth technology supports multiple topology options From simple point-to-point con- nections for streaming audio between a smartphone and speaker, to broadcast connec- tions that enable way-finding services in an airport, to mesh connections that support large-scale building automation, Bluetooth supports multiple topology options to best meet the unique wireless connectivity needs of a diverse, global developer population.
In overview, the network topology of BLE can be shown as Figure 2.4 We have three kinds of topology: Point To Point, Star and Mesh
Among these three kinds, connection between only two devices is the easiest and traditional one.
Star topology is the second in the three kinds of network structures It consists of one central node and several peripheral nodes Each peripheral node can only communi- cate with the central node and cannot communicate directly with the other peripheral nodes Peripheral nodes can communicate indirectly through forwarding by the cen- tral node.
In mesh networks, each device is connected to one or more of the other devices.There is no clear role definition that parallels central/peripheral A typical real mesh topology (such as Zigbee or Thread)consists of one coordinator, several routers and several end devices Routers can communicate with other nodes because the Mesh
Figure 2.4: BLE network topology protocol defines the routing rules Mesh is considered the most flexible network and it can provide a larger network coverage area At the same time, Mesh has a strong fault-tolerant ability If a router crashes in the network, information can still be auto- matically transmitted along other routing path On the other hand, mesh networks use complex network protocols that require a lot from the hardware and software that is used Also, the Mesh networks typically consume more power than other networks, and the data latency is both higher and more unpredictable since the number of jumps between peer devices is not fixed.
Bluetooth Mesh is a mesh network protocol based on “message flooding” using the Bluetooth Low Energy Broadcaster and Observer GAP roles This protocol is quite complicated and is not considered power and latency efficient compared to star networks Bluetooth Low Energy manufacturers are still researching and developing their Bluetooth Low Energy mesh solutions at this time.
So as we can see in Mesh model, we can expand the connecting area and add more devices easily However, it also increases the communication cost The Mesh model is strongly supported from BLE 5.0 and very popular in the current IoTs con- nections.
Security features
The BLE security model includes five security features:
1 Pairing: the process for creating shared secret keys.
2 Bonding: storing the keys created during pairing so they can be used later.
3 Device authentication: verification of stored keys.
5 Message integrity: protection against data alteration.
The Security Manager is responsible for:
3 Generating hashes and short term keys.
I take advantages of BLE security features in my proposed protocol:
1 Key generation in Bluetooth with low energy is performed by the Host on each low energy device independent of any other.
2 Encryption in Bluetooth with low energy uses AES-CCM cryptography.
3 In some circumstances where the communication channel is not encrypted, the device could still have a method to maintain and ensure the data authentication. This is accomplished by signing the data with a Connection Signature Resolving Key (CSRK).
In BLE, security-related tasks happened and are decided beforehand in pairing pro- cess There are four different pairing methods:
1 Numeric Comparison: both devices display the same six digit value on their re- spective screens or LCD displays, then users have to check whether they match and confirm with device This is not to prevent a man-in-the-middle (MITM) attack, but rather to identify the devices to each other.
2 Just Works: this is for headless devices, which means those devices do not haveGraphic User Interface or even the screen Technically, it is the same as NumericComparison, but the six-digit value is set to all zeros Just Works method is clearly the most popular one, however, there is no MITM protection with Just Works.
3 Passkey Entry With Passkey Entry, a six-digit value is displayed on one device, and this is entered into the other device.
4 Out Of Band: A communication method outside of the Bluetooth communication channel is not used, but the information is still secured The distance between two connected devices are very short in this case.
In our protocol, considering that we would like to propose a general approach and many Bluetooth Smart devices will not have screen, we will use Just Works.
BAN-logic
BAN-logic overview
Burrows–Abadi–Needham logic, or BAN-logic, was introduced by Burrows, Abadi and Needham in 1990 In this work, they provided a logic of authentication, which is in fact a set of rules for defining and analyzing authentication exchange protocols The study of BAN-logic came from the need of an ability to make protocols assumptions explicit and then transform them with deduction rules to come to further conclusions. Such logics of authentication like BAN-logic bring many benefits [19]:
• Correctness: The logic of authentication can provide the proof of whether a pro- tocol meets its security goals or not.
• Efficiency: The logic of authentication can improve the efficiency of a protocol by eliminating redundant messages which do not contribute to the achievement of the security goals.
• Applicability: The logic of authentication provides the formal clarifications on a protocol’s assumptions in order to judge its applicability in practice.
BAN-logic aims to answer the following questions:
• What conclusions does this protocol achieve?
• Which assumptions needed for this protocol?
• Does this protocol have unnecessary actions, which can be left out without weak- ening the security?
• Can anything be sent plain (without being encrypted) but still not weakening the security?
The BAN logic makes it possible to reason in a simple way over cryptographic protocols in a formal way It can be used in the design of a cryptographic protocol because the use of a formal language in the design process can exclude faults.
Notations
• P ⇒ X: P has jurisdiction overX, which means P has completely control over the formulaX.
• P |∼ X:P once said X The principalP at some time sent a message including the statementX.
• #(X): The formula X is fresh, that is,X has not been sent in a message at any time before the current run of the protocol.
• P ← → K Q: P andQ share a secret keyK P and Qcan use K to communicate to each other and it is only known to them.
• 7−→ K B: P hasK as a public key The corresponding secret key (the inverse ofK, denotedK − 1 ) will never be discovered by any other principal.
• A ( − X + B − : The formula X is a secret known only to P and Q, and possibly to principals trusted by them Only P andQ may useX to prove their identities to one another.
• h X i Y: This representsX combined with the formulaY; it is intended thatY be a secret, and that its presence prove the identity of whoever utters h X i Y.
Typical protocol goals
A protocol that establishes a session key k for A and B typically has the goal that at the end of a successful run it can be proved that:
To show that A and B know that the other agent knows about the key, the fol- lowing statement should also hold:
• The message meaning rule for shared key:
• The message meaning rule for public key:
• The message meaning rule for shared secret:
P |≡ P ← → k Q in which withXthe necessary elements for a key is meant.
Protocol analysis with BAN-logic
There are three main stages to the analysis of a protocol using BAN logic.
• Step 1:The first step is to express the assumptions and goals as formulas (also known as statements) in symbolic notations so that the logic can proceed from a known state so as to be able to ascertain whether the goals are in fact reached.
• Step 2:The second stage is to transform the protocol steps also into formulas in symbolic notation.
• Step 3: Lastly, a set of deduction rules called postulates are applied The postu- lates should lead from the assumptions, via intermediate formulas, to the authen- tication goals.
Criteria of Authentication schemes
Security in IoT is a popular research aspect of these recent years, especially when IoT is growing really fast and becoming an important part of our daily life In the paper of M El-hajj et al published in 2019 [20], they stated that the main IoT se- curity concerns include: authentication, authorization, integrity, confidentiality, non- repudiation, availability, and privacy In this paper, we focus on the authentication. About the taxonomy of IoT Authentication Schemes, we would have six main criteria:
(a) Token-based Authentication: Authenticates a user/device based on an iden- tification token created by a server such as OAuth2 protocol [21, 22] or open
(b) Non-Token based authentication: Involves the use of the credentials when there is a need to exchange data (e.g., TLS/DTLS [24, 25]).
2 Using Authentication factors: Identity or/and Context.
(a) Identity: An information kept by one devices and distinguishing it from an- other, is used to authenticate itself [26, 27].
(b) Context: can be behavioral (gait, voice ) or physical (fingerprint, iris ) [28]
3 Using Authentication procedure: One-way authentication, Two-way authentica- tion and Three-way authentication.
(a) One-way authentication: In scenario of two devices need to communicate with each other, only one party will authenticate itself to the other one, while the other one is still unauthenticated.
(b) Two-way authentication: It is also called mutual authentication, in which both devices authenticate each other, this is the most common way.
(c) Three-way authentication: When there is a central authority authenticates the two parties and support them mutually authenticating themselves.
4 Using Authentication architecture: Distributed or Centralized.
(a) Distributed: Using a distributed straight authentication method between the communicating parties.
(b) Centralized: Using a centralized server or a trusted third party to distribute and manage the credentials used for authentication Whether centralized or distributed, the authentication scheme architecture can be:
(c) Hierarchical: Using a multi-level architecture to deal with the authentication procedure.
(d) Flat: No hierarchical architecture is used.
5 IoT layer: We have perception layer, network layer and application layer.
6 Hardware-based: The authentication process might require the use of physical characteristics of the hardware or the hardware itself, so we have Implicit hardware- based and Explicit hardware-based.
(a) Implicit hardware-based: Using hardware features such as Physical Unclon- able Function (PUF) [29] or True Random Number Generator (TRNG) [30]. (b) Explicit hardware-based: Some authentication schemes are based on the use of a Trusted Platform Module (TPM) [31].
My protocol is an example of using multi-authentication criteria I use identity such as Device Bluetooth MAC address, location, time and encounter history of participants as our factors I also provide a distributed authentication scheme cause I do not need centralized server.
Existing authentication frameworks
The idea of Quorum based secure authentication is quite similar to the idea of my proposed protocol A quorum is defined as a minimum number of users in a group necessary to achieve a successful transaction (in this case authentication) Quorum is the fundamental of blockchain Quorum based authentication protocol are sometimes referred as Consensus Protocols or m-of-n quorum authentication There were some similar authentication protocols based on this idea applying on transaction: [32] and[33] The Quorum based secure authentication is the fundamental of block chain,however, it is too heavy to apply into the IoTs enviroment We also have "Project things" of Mozilla [34], which is an open framework for connecting your devices to the web described as Figture 3.1 The main idea of the "Project things" is proving framework using Raspberry Pi 3 as Gateway to control smart home devices via Web- site, work with Zigbee vs Z-Wave standards via their USB dongles For Zigbee andZ-Wave, both are mesh networks – this just means signals can hop from gadget to gadget round the home and each device or sensor does not need to connect to Wi-Fi.Therefore, we need a central hub which connects to the internet, and Raspberry Pi 3 will be the gateway/ Central control hub to control the Zigbee/ Z-Wave devices I also use Raspberry Pi 3 in my proposed protocol, however, I refer not to have any central control hub to connect to the internet and we do not need to connect to cloud in theParty-Crasher protocol.
Previous work
My proposed framework is an application based on BLE framework to utilize the advantages of BLE technology, which is inspired by the the research result of [35], [36] and [37] for IoTs devices for resource constrain and privacy preserving idea. This work can also be considered as a further development for [38] To have better understanding about my proposed protocol, I will briefly present about the work of [36] and [38].
In [36], we proposed an authentication protocol which includes three entities: device 1, device 2 and gateway as Figure 3.2.
This authentication model also included three phase but did different things:
• Phase 1: Registration This is the very first step for every device when joining the system Its purpose is to register a device’s identity with the server At the end of this phase when the server completes calculating and storing its authentica- tion data, the device will be responded with a secure cookies data used for later authentication phases.
• Phase 2: Authentication between the servers and device The authentication pro- cess happens before devices can start their connections with the rest of the net- work, which is firstly between them and the servers In this phase, the device presents its credentials, i.e its cookies data, to the server The server then veri- fies those credentials of the devices to know if it is allowed to connect Simulta- neously, the device also needs to be guaranteed that it is actually connecting to the true server That is why by the end of this phase valid devices and the server should be mutually authenticated by each other and their common session keys will be created.
• Phase 3: Authentication between two devices As communications among de- vices happen more often than between them and the servers in IoT systems, they also need to be mutually authenticated by each other before making communica- tions The goal of this phase is similar to the second phase, that is, their identities are verified, and common session keys are created for later securing the messages
Figure 3.2: Three entities authentication protocol [36] exchanged.
In my thesis, I will just deep dive into the final phase: Authentication between two devices and eliminate the existing of gateway to make it become more flexible and suitable for IoTs devices.
In this chapter, the proposed protocol will be described in detail Firstly, I will explain the senario that we will need to apply my proposed authentication scheme Then, I will describe clearly every step in the authentication process.
Senario
To understand better about the protocol, we need to have the scenarios where we will apply it We will use party as a specific context to begin with Imagining you, as Party-Crasher, suddenly discover that there is an interesting party happening near your place, then you would like to join it The party may last 6 hours, you are late but you do not want to miss any excited events in the party Since you are not invited, you suppose not to be able to join the party and watch its events in the party timeline. You are also not allowed to join party chat group, but you need to keep track with previous party activities to join the conversations How can you get permission for these activities? You need to prove that you are able to join this party You can be considered to join this party if you know most of participants of the party (more than 50%), and they give positive feedback about you or you received special permission of Party-Owner.If you have one of the requirements, you would be provided permis- sion to see party timeline, join chat groups and communicate in the party.
The second scenario is supposing you are a member of the development team, so you are allowed to join team technical discussion meeting However, by some mis- take, you did not receive the invitation from meeting organizer Since you are not invited, you suppose not to be able to join the meeting and follow its previous discus- sions and decisions You are not allowed to discuss in the conference chat room You need to prove that you are able to join this meeting You can be considered to join this meeting if you are teammate of team members and you get permission from team leader In that case, you would be provided permission to see previous discussions, join chat groups and express opinions during the meeting.
From the above scenarios, we assume that to apply this protocol, the event must have the below features:
1 There is a person in the event acting as the Event owner, who know all event participants and be trusted by them.
2 Event participants can give their individual judgment for the uninvited guest The judgment can be not the same in different party.
3 All information related to event is shared on the web pages, or server that only people who connect to the Local network can see and update, which can be referred as a transient secret.
4 All event members will have at least one device which supports Bluetooth low energy.
5 This event happens in a closed sPCe, which only nearby devices can connect with each other.
Proposed protocol
We need to identify the below problems:
• How to discover neighborhood devices continuously? We need a protocol which supports Continuous neighbor discovery.
• How to send data between near devices without using much energy? We needBluetooth low energy (BLE) technology, a technology that is famous for its en- ergy saving features and very popular in our daily life for now.
Figure 4.1: Detailed proposed authentication protocol
To answer the above questions, I suggest the protocol stack as 4.1.
My authentication protocol will be built on top of Continuous neighbor dis- covery service and BLE hardware We can discover all the nearby devices without wasting a lot of energy by using BLE which already supports Continuous neighbor discovery service and are famous for its energy-saving features Not only that, BLE also has other features like:
All these abilities of BLE are really suitable for my protocol My work is an im- provement of Just Works Bluetooth method Every step of my protocol can be seen as Figure 4.2.
PC will send request to PO that he would like to join the party, and he is a good friend with PPs PO will need to verify this information before he can accept PC ’s re- quest Hence, PO will forward the message from PC to the PPs that PC says he knows for verification If most of PPs (more than 50%) replies to PO he knows and trusts
PC, PO will request to pair with PP, in order to ensure the safety for communication
Figure 4.3: Party-Crasher protocol overview
Figure 4.4: Detailded proposed authentication protocol channel between him and PC After pairing, PO will share party secret to PC, which may be a Wi-Fi access key, so PC can truly join the party The Figure 4.3 summarizes the authentication process For the calculation steps, I describe them in Figure 4.4. Detailed communication steps are explained as follow:
PC will made a scan about devices inside the party If he knows most of devices, which means he has paired with them before and stored their key in his database,
PC will advertise his join request to PO To prove he is friend with any PP, he needs to compute a messageM and encrypt it by his BLE link key This message afterward will be used to validate his identity For each message PC exchanges with PO, he will send his BLE Mac AddressID P C , PP BLE MAC addressID P P ,current system time T and a message M 1 Message M 1 will be calculated by hashing the combination ofID P C , ID P O ,ID P P and T, then encrypted by BLE
Figure 4.5: Same link key in PC and PP link key of PP and PC with AES cryptography.
M 1 = Enc LK 1 (H(ID P C | ID P O | ID P P | T ))(1)
LK 1 : BLE link key of PP and PC Based on BLE protocol, as we can see in Figure 4.5, paired devices share a common link key The number ofM message
PP will need to calculate depends on how many PP he knows in the party.
After receiving PC ’s request, PO will need the help from PPs to decide whether he can trust PC The connection between PO and PP is considered as safe and encrypted by BLE cause they are paired devices At first, PO will check if he and
PC are in the same time frame A 10 minutes different time range is acceptable.
If time is validated, PC will contact PPs to confirm about PC For each PP, PO will send PC’s Mac AddressID P C , PO’s Mac AddressID P O , PO current system timeT 0 andM 1 message sent by PC for that PP To not burden the network, PO will set TIMEOUT about 180 second until he receives response from PP Over TIMEOUT, PO will reject connection request from PC and authentication pro- cess is terminated.
Each PP also performs time check at the first step After that, he will check whether PC is nearby by scanning all discoverable BLE devices at the area at that moment If both conditions are satisfied, PP will verify the M 1 from PC by using his BLE Link key with PC In order to verify the time, 10 minutes different is acceptable TheM 2 andM 3 will be computed afterward with below formulas:
(4.2) Then message from PC will be decrypted by link key stored in PP.
M 3 = Dec LK 2 ((ID P C | ID P O | ID P P | T 00 ))(3) Since the Link key is the same between PP and PC if they are friends,M 2 is ex- pected to be equal M 3 By this result PP will reply "Friend" or "Not Friend" to
PO This response will be encrypted by BLE connection and be considered as
PO will set TIMEOUT about 180 second until he receives response from each
PP Over TIMEOUT, PO will act as he receive "Not Friend" message from PP.
If most of PP confirms he is "Not Friend" with PC, PO will reject PC ’s request.
On the other hand, PO will accept to pair with PC and they can exchange data securely Hence, PO can give PC the party secret, which is now exchanged in a secure channel, i.e the Wi-Fi key Cause we use BLE framework, the communi- cation between PC and PP are supposed to be safe since they are protected by security methods apply in BLE.
To summarize, in this chapter, I described about my proposed protocol: why
I decided to choose BLE as a solution for authentication framework, authentication flow and each authentication steps The correctness of this protocol will be formally presented in Section 6.1 Besides, I also measure its power consumption and execution time in Section 7.
System implementation and proposed framework
I had a set up of 3 Raspberry Pi 3 Model B and a Asus laptop 3 Raspberry Pi boards are set up as Figure 5.1 and we establish an secure shell connection from our Asus laptop to them to control Below is some description about hardware and software information regarding to our experiment.
Hardware
Raspberry Pi 3 Model B+ Asus Laptop.
Library information
- https://pypi.org/project/PyBluez/
- https://pypi.org/project/pycrypto/
Below buitlin libraries in python 2.7
Figure 5.1: Raspberry Pi boards set up
OS information
Raspberry Pi boards are installed to boot up with fresh Raspbian Stretch Lite OS version 2018-06-27.
Description
All devices are configured to be able to use all features of BLE We made a simple implementation for our proposed protocol using BLE RFCOMM protocol with 4 de- vices, representing 3 elements of this Protocol: PC, PP and PO D1 is PC, D2 is PO and D3 is PP We have 1 D1, 1 D2 and 2 D3 The assumptions here are:
1 D1 and D2 do not know each other.
2 Each D3 is a closed friend of both D1 and D2.
3 If the devices have been authenticated before, their BLE devices have been al- ready paired and exchanged data, so the connection between them is considered as safe via BLE standard.
4 When 2 BLE devices have been paired, they will have the same link key in the database.
1 Class NewDevice1:#Support following functions for PC:
(a) Send request to join to D2
Function interface: def DeviceRequestJoin(id2)
(b) Create Message, send to D2 so D2 can forward to D3 for help This message is encrypted by D1 and D3 link key.
If D3 knows D1, D2 will authenticate with D1.
Output: True/ False (result of D1 and D2 authentication).
Function interface: def DeviceAuthenticate(id3, message) (c) Running function:
2 Class NewDevice2:#Support following functions for PO:
Output: Message created by D1, ID D1, ID D3, time of authentication. Function interface: def ReceiveJoinRequest(id1)
(b) In case D2 does not know D1, and need support from D3, D2 need to for- ward D1 message to D3.
Input: Message created by D1, ID D1, ID D3, time of authentication.
Output: True/ False (depend on relationship between D1 and D3).
Function interface: def ForwardJoinRequest(id3, id1, m, t)
3 Class NewDevice3:#Support following functions for PP:
Function interface: def DeviceConnect(id2) (b) Get D1 data from D2.
Output: message created by D1, D1 ID
Input: message created by D1, D1 ID.
Output True/ False (depend on relationship between D1 and D3). Function interface: def SupportAuthenticate(id1, m)
We also have supporting functions which are shared between all devices:
Function interface: def hashMessage(message) (b) Encrypt message
Input: Message, key, padding character
Function interface: def encryptMessage(privateMsg, encodedSecretKey, paddingCharacter)
Input: Encoded message, key, padding character.
Function interface: def decryptMessage(encodedEncryptedMsg, encodedSecretKey, paddingCharacter) (d) Get Bluetooth link key This key will exist if 2 devices paired with each other before.
Input: device self Bluetooth MAC address and partner Bluetooth MAC ad- dress.
Function interface: def getLinkKey(selfAddr, devAddr)
(e) Check if a device is nearby.
Input: MAC address of device which we need to check.
Function interface: def checkNearbyDev(devAddr)
(f) Verify time whether it is acceptable (10 minutes should be fine.)
Input: sending time, receiving time.
Function interface: def verifyTime(devTime, receivedTime)
Experiment
We set up our experiment to have 3 type of devices here:
1 Asus laptop, works as PO.
2 Raspberry Pi 3 Model B+, works as PC.
3 Raspberry Pi 3 Model B+, works as PP.
1 Beginning stages: As I stated earlier, PC is supposed to know PP and PO knows
PP PC does not know PO but wants to authenticate with it as Figure 5.3 We have 3 devices displayed as follow:
2 Running stage: PC send request to authenticate with PO with support from PP as Figure 5.4.
4 Final stage: complete authentication process PO is paired with PC and can see information of PC Now we will see link key inside PO and PC This link key will be used to generate key for each communication between PO and PC in the future as Figure 5.5
In this chapter, I prove that the proposed authentication protocol is secure and resilient to different attacks by conducting a thorough security analysis of the scheme My work includes a formal security analysis with Burrows-Abadi-Needham Logic (BAN- logic) as well as an informal analysis to prove the resilience of the proposed scheme to different popular attacks.
Formal analysis
I now present a formal analysis of my proposed protocol with the BAN-logic [17]. BAN-logic has been widely known and applied to formally prove the correctness of mutual authentication and key agreement protocols Hence, the goal for this analysis is to prove the proposed scheme can successfully achieve the mutual authentication and session key agreement between participants All the BAN-logic notations and rules should be referred to Section 2.4 In short, PO needs to believe that PP believes it and PC share the same understanding about relationship (i.e PC and PP have the same long term key).
(1) From the fact that PC generatesN 1 we get:
(2) Cause this N 1 is generated by time as we clarified in the protocol, we can derive:
(3) From the fact that PO generatesN 2 we get:
(4) Cause this N 2 is generated by time as we clarified in the protocol, we can derive:
(5) We applyA 13 toS 2 to derive:
(7) As the description of the protocol, PO will forward this N 1 to PP, and this message will add the time of PO to createN 2 From that, we can derive:
Due toA 7 andA 8 , we have as below:
Because of the fact that in BLE, if two devices have paired with each other in the past, they will share the same link key Hence, PP should be able to decrypt the
N 1 message of PP In case PP decrypts theN 1 message successfully, we can derive:
Due toS 11 andA 9 we have:
Informal analysis
Security Attributes
• Mutual authentication:As shown in my proposed protocol, each device is able to authenticate the identity of the other Therefore, the mutual authentication is achieved with this scheme.
• Confidentiality: Confidentiality refers to the cipher algorithm and key agree- ment, and confidentiality of private device data These demands are successfully fulfilled in the proposed protocol At the end of Phase 3, two devices agree on a common session key for securing their further conversations Despite private data of devices being used during the authentication phase, the protocol still guarantees the confidentiality of such data with the use of time for each run and final wrappers with hash functions This way even if an attacker capture the data while being transmitted, it can neither re-use nor derive the actual secret session keys wrapped inside.
• Perfect forward/backward secrecy:In our proposed protocol, each session is com- puted from current time generated at each device and hash function Hence, the key shares random and not the same for different sessions These properties help us avoid attackers from guessing keys of other sessions when they have one Also,they cannot use this key to decrypt messages of different sessions in neither the past nor the future, which proves our scheme is able to provide the perfect for- ward/backward secrecy property.
Security analysis
Our protocol is implemented by using BLE connection, so we can utilize the BLE se- curity features BLE 4.2 devices are fully backwards compatible with BLE 4.0 and 4.1 devices, this means that 4.2 devices can perform the exact same pairing pro- cess as 4.0 and 4.1 devices However, BLE 4.2 are also capable of creating what are known as LE Secure Connections Instead of using a TK and STK, LE Secure Connections use a single Long Term Key (LTK) to encrypt the connection This LTK is exchanged/generated using Elliptic Curve Diffie Hellman public key cryptography which offers significantly stronger security compared to the original BLE key ex- change protocol In LE Secure Connections, both phase one and phase three of the pairing process are exactly the same as they are in LE Legacy connections Thus, the only differences occur during phase two of the pairing process The way phase two works in LE Secure Connections is as follows Both devices generate an ECDH public-private key pair The two devices will then exchange their public keys and then start computing the Diffie-Hellman key One of the pairing methods is then used to authenticate the connection Once the connection is authenticated, the LTK is gener- ated and the connection is encrypted.
AES-CCM is used in Bluetooth LE to provide confidentiality as well as per-packet authentication and integrity Because the LTK is used as input for the encryption key, successful encryption setup provides implicit authentication Similarly, data signing using Identity Resolving Key(IRK) provides implicit authentication that the remote device holds the correct Connection Signature Resolving Key(CSRK).
Key generation in Bluetooth with low energy is performed by the Host on each low energy device independent of any other When using Bluetooth LE Secure Connec- tions, the following keys are exchanged between master and slave:
- Connection Signature Resolving Key for Authentication of unencrypted data: CSRK is an 128-bit key used to sign data and verify signatures on the receiving device.
- Identity Resolving Key for Device Identity and Privacy: In LE Secure Connections, the public/private key pair is generated in the Host and a Secure Connection Key is generated by combining contributions from each device involved in pairing IRK is a 128-bit key used to generate and resolve random address.
Encryption in Bluetooth with low energy uses AES-CCM cryptography, which is also known as Counter with CBC-MAC, is a mode of operation for cryptographic block ciphers This is an authenticated encryption algorithm that provides both confiden- tiality and authentication.
Bluetooth with its low energy features supports the ability to send authenticated data over an unencrypted transport between two devices with a trusted relationship This means that in some circumstances where the communication channel is not encrypted, the device could still have a method to maintain and ensure the data authentication. This is accomplished by signing the data with a CSRK The sending devices place a signature after the Protocol Data Unit (PDU) The receiving device verifies the signature and, if the signature is verified, the Data PDU is assumed to come from the trusted source The signature is composed of a Message Authentication Code generated by the signing algorithm and a counter, which is used to protect against a replay attack This counter is increased on each signed Data PDU sent.
BLE provides feature that reduces the chance of an attacker to track a device over a long period by often changing an advertising device’s address Only the devices that have been authenticated before can resolve the real Bluetooth MAC address (or we can call ID here) of devices thanks to the IRK If the advertising device was previously discovered and has returned to an advertising state, the device can only be identifiable by trusted devices in future connections without going through discovery procedure again The IRK stored in the trusted device will solve the problem of maintaining pri- vacy while saving discovery computational load and connection time The advertising devices IRK together with other keys was sent to the master device during initial bond- ing The a master device then can use the IRK to identify the advertiser as a trusted de- vice.
Briefly, I presented the BAN Logic as formal analysis and also security informal analysis in this chapter to prove that my proposed authentication scheme is correct and safe to use The newly protocol has all necessary security attributes such as mutual authentication, confidentiality and perfect forward/backward secrecy and achieved all the goals of BAN Logic.
In this chapter, I will analyze the performance of the proposed protocol in 2 phases:communication between devices and Authentication message calculation.
Communication
In the research [39], the scientist did a comparison between energy consumption be- tween BLE and ZigBee 802.15.4 using the Monsoon Power Monitor The two frame- work are two the most popular for IoTs now.
In BLE, two of the lowest layers of BLE stack are Physical (PHY) and the Link Layer (LL) PHY takes care of transmitting and receiving bits The Link Layer provides medium access, connection establishment, error control, and flow control The upper layers are Logical Link Control and Adaptation Protocol (L2CAP), Generic Attribute protocol (GATT), and Generic Access Profile (GAP) L2CAP is able to multiplex the data channels from the above layers and provides fragmentation and reassembly for large data packets Similar to classic Bluetooth (BT), BLE uses adaptive frequency hopping spread spectrum to access the shared channel However, the number of hops is 43 and the channel width is 2MHz as opposed to 79 hops and 1MHz channel width in classic BT BLE device can operate either in master or slave role A master can man- age multiple simultaneous connections with a number of slave devices, but a slave can only be connected to a single master Therefore, a BLE network topology is a star Dif- ferently from classic BT, discovery is done so that slave advertises on one or several of the three designated advertisement channels Master scans these channels in order to
Table 7.1: Power consumption and duration of each phase of BLE.
Phase Power draw (V DD = 3V ) Duration
1 wakeup & pre-processing P wu = 15mW D wu = 1ms
2 RX P rx = 66mW D rx = 8às/B
3 IFS P if s = 45mW D if s = 150às
4 TX P tx = 84mW D tx = 8às/B
5 post-processing P mcu = 24mW D mcu = 1.4ms
Table 7.2: consumption and duration of each phase of Zigbee.
Phase Power draw (V DD = 3V ) Duration
1 wakeup P wu = 20mW D wu = 0.5ms
2 pre-processing P mcu1 = 24mW D mcu1 = 1/3.5ms
3 CSMA/CA P ca = 72mW D ca = 0.62ms
4 RX-TX switch P rxtx = 54mW D rxtx = 0.4ms
5 TX P rx = 90mW D rx = 32às/B
6 RX P tx = 72mW D rxtx = 0.4ms
7 post-processing P mcu2 = 24mA D mcu2 = 1.4ms discover slaves After discovery, data transmission happens in the form of connection events in which the master and the slave wake up in synchrony to exchange frames. Both devices sleep the rest of time.
On the other hand, ZigBee protocol stack consist of PHY and MAC layers specified in the 802.15.4 standard and a set of layers above which are specified by the Zig- Bee alliance Our comparative measurements focus on the two lowest layers which is why we do not detail the higher layers further The channel access in 802.15.4 is CSMA/CA as opposed to the frequency hopping of BLE The over the air data rate is only 250kbit/s compared to 1Mbit/s of BLE In ZigBee terminology, a network can consist of end devices, routers, and coordinators End devices are typically most re- source constrained and coordinators have the most capacity End devices can connect to routers or coordinators which can connect to each other The resulting topologies can be star or peer-to-peer In the non-beacon mode, an end device can transmit when- ever it desires and the router/coordinator should listen to the medium for any incoming transmissions.
The power consumption and data transfer duration between BLE and Zigbee in dif- ferent stages can be found in Table 7.1 and 7.2
These results show that BLE indeed consumes extremely little energy and has a very attractive ratio of energy per bit transmitted.
Table 7.3: The energy used by two devices for their mutual authentication
Device Operation Energy cost (mJ) Times
Authentication Message Calculation
In my enhanced protocol for mutual authentication between devices, the main oper- ations used by each device are hashing and encryption/decryption using symmetric session keys The hash function uses SHA-1 with the output length of 128 bits En- crypting/decrypting messages with session keys is supposed to use AES with key size also of 128-bit According to the experiment results in [40], SHA-1 consumes 0.057 mJ per its operation Meanwhile, encryption and decryption with AES need only 0.009 mJ per operation with 128-bit data [41] Then we can calculate the energy that each device need to use this protocol as Table 7.3.
Cause PO does not need to perform any calculation, all it has to do is forward the message to PPs, the power consumption for PO is 0 While PC and PP only perform one hash and one encrypt/decrypt, each device spends just 0.066 mJ for this protocol as below formula:
Energy(mJ ) = P owerConsumption1Hash ∗ T imesP erf orming 1Hash +
P owerConsumption1Encryption/Descryption ∗ T imesP erf orming1Encrypt/Descrypt
Regarding to calculation time, I did measure with Raspberry Pi 3 Model B+. This protocol only takes PP 214 às and PC 232 às to complete creating M 1 and decryptingM 2 as we can see in Figure 7.1 and Figure 7.2.
In conclusion, in Section 7 I measured and calculated the power consumption and execution time of my proposed protocol I also compared BLE and another frame- work that is ZigBee 802.15.4 to prove that BLE indeed takes much little energy and has a very attractive ratio of energy per bit transmitted and very promising to use inIoTs environment.
Recently, the Internet of Things (IoT) has emerged as one of the building blocks of future digital industrial technologies The ability of interconnecting heterogeneous devices generating and exchanging a huge amount of data has opened an new era in which many advanced services that greatly enhances our life quality are now provided. Along with its huge open opportunities, it is also coming with different challenges, in which security issues are especially getting more and more attention The connectivity nature of IoT devices introduces the urgent needs of secure communication between entities in IoT systems by authenticating their identities with the other parties That is when the authentication protocol solutions come to play to address this issue In fact, authentication is not something new but a necessary component of any system The transmitted data between devices during such authentication may contain different kinds of information directly involved users’ private daily behaviors and preferences. The risk of exposing such data makes it uncomfortable for users to try the solutions without the privacy-preserving guaranteed On the other hand, the IoT with its unique characteristics make it challenging to apply traditional security solutions, especially the resource-constraints of a large proportion of devices in the IoT.
To summarize, the contributions of this thesis can be listed as below:
1 Proposing a new authentication protocol which is based on the state-of-the-artBLE framework This protocol utilizes many of BLE low-energy features, and improves its security by extra lightweight formulas The overall idea of the au- thentication scheme is quite similar to Quorum based secure authentication, but the calculation is quite simple so it does not take much energy of performing devices.
2 Proving the proposed authentication schemes’ correctness is proven using a for- mal analysis with BAN-logic in order to show that the mutual authentication and session key agreement between participants can be achieved securely and pro- viding additional analysis on their resilience to different kinds of popular attacks while preserving devices’ privacy.
3 Conducting Performance analysis including computational and communication analysis to confirm the efficiency of the proposed protocol The main weakness of the research is that I did not implement it on big number of devices and mea- sure the latency and noise in that case.
4 Suggesting the framework and API to implement my newly protocol on real hard- ware In my experiment, I used Raspberry Pi 3 Model B+.
5 Last but not list, publicizing three articles regarding to the authentication scheme presented in prestigious conferences and journal All of those manuscripts can be referred in Appendix.
In this thesis, I mostly use the Star model of BLE, however, in future works, we can have an improved protocol which uses Mesh model Another suggestion for further research on the issue of privacy protection in the protocol to improve the security level of the proposed scheme can be carried out Since most of (lightweight) IoT devices nowadays have sensors to detect changes in the real world, the information they contain may accordingly be sensitive and should not be exposed The association of the authentication process and a variety of privacy protection demands in the real- world applications (e.g., [42], [43], [44], [45]) are possibilities to extend the security capabilities of the protocol, especially with resource-constrained IoT devices On this account, what data can be shared between two devices after completing authenticating is an interesting problem of great interest that should be further studied.
List of published papers/journals during the Master course:
1 Thao L.P Nguyen, Tran Khanh Dang, Tran Tri Dang, Ai Thao Nguyen Thi ”A Three-Way Energy Efficient Authentication Protocol Using Bluetooth Low Energy.” International Conference on Future Data and Security Engineering Springer, Cham, 2020.
2 Tran Khanh Dang, Chau D.M Pham, Thao L.P Nguyen ”A pragmatic elliptic curve cryptography-based extension for energy-efficient device-to-device communi- cations in smart cities.” Sustainable Cities and Society, Volume 56, 2020.
3 Pham, Chau DM, Thao L.P Nguyen, and Tran Khanh Dang ”Resource-ConstrainedIoT Authentication Protocol: An ECC-Based Hybrid Scheme for Device-to-Server and Device-to-Device Communications.” International Conference on Future Data and Security Engineering Springer, Cham, 2019.
Publicized articles will be listed here.
Contents lists available at ScienceDirect
Sustainable Cities and Society journal homepage: www.elsevier.com/locate/scs
A pragmatic elliptic curve cryptography-based extension for energy-e ffi cient device-to-device communications in smart cities
Tran Khanh Dang*, Chau D.M Pham, Thao L.P Nguyen
Ho Chi Minh City University of Technology, VNU-HCM, 268 Ly Thuong Kiet Street, District 10, Viet Nam
The rise of Smart Cities with underlying adoptions of technologies like the IoT and Cloud Computing has made the integration between them a promising field with different challenges including security Authentication is one of the foremost attempts to address these issues Allowing direct device-to-device rather than only device-to- service communications can introduce several benefits like high data transmission rate and reliable commu- nications even when the central clouds fail However, the resource constraint nature of IoT devices makes it more difficult to develop secure protocols that can provide a sustainable deployment in practice This article proposes an authentication scheme extension providing secure control from resourceful cloud servers to devices while also enabling the direct secure communications between them The scheme is designed to use ECC and low-cost operations to provide efficient resource and energy consumption The protocol correctness is proven by using a formal security analysis with BAN-logic Detailed analysis is presented to show its resilience to common attacks A performance analysis is also given to show the scheme's practical value as it only consumes at most
29 mJ on each device in addition to the amount required by the original protocol.
The Internet of Things (IoT), which was first introduced by Ashton
(2009) in 1999, has opened new opportunities for the research com- munity to study its wide variety of aspects Single-function embedded devices have been developed into smart things, such as smartphones, laptops, coffee machines, refrigerators, Google Home, Apple watches, etc In other words, any device can be integrated into the IoT by equipping it with an Internet connection, sensor and/or actuators, so they can recognize changes in their surroundings for corresponding activities (Yu, Wang, & Zhou, 2010; Zhou & Zhang, 2011) These de- vices collect environmental information of their surroundings and send it to some central data servers where it is processed, manipulated, transformed and used to perform multiple tasks (Hao & Helo, 2017) In the end, governments, organizations, and individuals enjoy these ben- efits of IoT Applications of the IoT are available in many aspects of life thanks to its adoption by a wide range of industries (IoT Applications,
2019) Nowadays, Smart Home, Smart University and even Smart City are not new de fi nitions New IoT products are introduced almost every day for all the aspects of our modern life The number of IoT devices has now been more than 1 billion (IHS, 2020a) IHS forecasted the IoT market would reach 75.4 billion of devices by 2025 (IHS, 2020b).
Being considered as the future of the Internet, IoT development comes with urgent requirements about the provision of security and privacy as the number of deployed IoT devices rapidly increases In