Chapter 8:

Internet of Things
Security and Privacy

Prof. Moussa Ayyash

26 October 2015
 Chapter 8

IoT Security Challenges

• Multiple Technologies: Each IoT technology (e.g. wireless sensor, RFID, cloud, virtualization)
has its own vulnerabilities. The chain of all of those technologies must be secured (IoT
application will be judged based on its weakest point).
• Multiple Verticals: The IoT paradigm will have numerous verticals. The security requirements of
each vertical are quite different from the remaining verticals.
• Scalability: 26.3 billion smart devices will be connected to the Internet by 2020. None of the
previously proposed centralized defensive frameworks can work anymore with the IoT paradigm,
where the focus must be switched to finding practical decentralized defensive security
mechanisms.
• High Availability (HA): HA refers to characteristic of a system that is continuously operational
for a desirably long period of time.
• It is typically measured relative to "100% operational" or "never failing." (five9s = available 99.999% of the
time in a given year) availability.
• Security plays a major rule in HA as network admin often hesitate to use needed threat-response
technology functions (e.g network discovery) for fear that such functions will take down critical systems.
Even a simple port scan causes some IoT devices to stop working, and the cost of downtime can far
exceed the cost of remediating all but the most severe incidents..
© 2017 Copyright . All rights reserved. 2
 Chapter 8

IoT Security Challenges (Con’t)

• Big Data: Each smart object is expected to be supplied by numerous sensors, where each
sensor generates huge streams of data over time. This makes it essential to come up with
efficient defensive mechanisms that can secure these large streams of data.
• Resource Limitations: The majority of IoT end devices have limited resource capabilities such
as CPU, memory, storage, battery and transmission range. This makes those devices a low-
hanging-fruit for Denial of Service (DoS) attacks where the attacker can easily overwhelm the
limited resource capabilities of those devices causing a service disruption..
• Remote Locations: In many IoT verticals (e.g. Smart Grid, Railways, Roadsides), IoT devices,
epically sensors, will be installed in unmanned locations that are difficult to reach. Attackers can
interfere with these devices without being seen. Cyber and physical security monitoring systems
must be installed in safeguarded location, operate in extreme environmental conditions, fit in
small spaces, and operate remotely for routine updates and maintenance avoiding delayed and
expensive visits by network technicians.
• Mobility: Smart objects are expected to change their location often in the IoT paradigm. This
adds extra difficulties when developing efficient defensive mechanisms in such dynamic
environments.
• Delay-Sensitive Service: The majority of IoT applications are expected to be delay-sensitive and
thus one should protect the different IoT components from any© 2017
attack that may degrade their
Copyright . All rights reserved. 3

service time or may cause a service disruption.

 Chapter 8

IoT Security Requirements

• Confidentiality: ensures that the exchanged messages can be understood only by the intended
entities.
• Integrity: ensures that the exchanged messages were not altered/tampered by a third party.
• Authentication: ensures that the entities involved in any operation are who they claim to be. A
masquerade attack or an impersonation attack usually targets this requirement where an entity
claims to be another identity.
• Availability: ensures that the service is not interrupted. Denial of Service attacks target this
requirement as they cause service disruption.
• Authorization: ensures that entities have the required control permissions to perform the
operation they request to perform.
• Freshness: ensures that the data is fresh. Replay attacks target this requirement where an old
message is replayed in order to return an entity into an old state.
• Non Repudiation: ensures that an entity can’t deny an action that it has performed.
• Forward Secrecy: ensures that when an object leaves the network, it will not understand the
communications that are exchanged after its departure.
• Backward Secrecy: ensures that any new object that joins ©the network will not be able to
2017 Copyright . All rights reserved. 4

understand the communications that were exchanged prior to joining the network.
Mapping of IoT Domains

IoT Applications
IoT Cloud Domain

IoT Services Platform

IoT Fog Domain
IoT Network

IoT Sensing Domain

IoT Devices

© 2017 Copyright . All rights reserved. 5

Mapping of IoT Domains
Server
Server Server

Cloud
Domain

Fog
Domain
IoT IoT IoT
Gateway Gateway Gateway

Sensing
Domain

© 2017 Copyright . All rights reserved. 6

 Chapter 8
Cloud Domain Attacks
• Cloud domain holds IoT applications (performing different
operations). Examples?
• Each IoT app is dedicated one or multiple VMs. Each VM
is assigned to one of the PMs/servers with certain amount
resources (CPU, memory, storage) to perform tasks.
• PMs in the cloud data center are virtualized allowing
multiple VMs to be assigned to the same server (as long
as the server has enough resource capacity to support the
resource requirements of each hosted VM).
• Each IoT application is hosted on a VM that has its own
operating system (OS).
• Hypervisor (Virtual Machine Manager)
 Monitors running VMs & manages how these VMs share the
server’s hardware.
 Provides the logical separation among VMs
 Separates each VM from the underlying hardware.
 Has a Migration Module that manages how to move a VM to
© 2017 Copyright . All rights reserved. 7
another server.
 Cloud Domain Attacks Chapter 8
A. Hidden Channel Attacks
• Although there is a logical separation among the VMs running on the same server, some hardware
components (e.g. cache) are shared = opportunities for data leakage across VMs on same PM.
• Three steps are followed by the attacker in order to leak information from a target VM.
Step1: Which VM to Target?
 Cloud data center is typically divided into multiple management units called clusters (large number of PMs). Each cluster
is located in a certain geographical location.
 Each cluster is divided into multiple zones.
 Clients have the choice to specify in which cluster their VM resides, they don’t have control on selecting the zone or the
server within the zone (decision is based on private scheduling algorithm)
 In order to know where a target VM resides, the attacker needs only to know the external IP address of that VM.
 The attacker can infer based on the VM’s external IP address on what cluster the VM resides, as cloud clusters are
usually placed in different geographical locations and have different IP addresses.
 To identify in what zone within the cluster the target VM resides, the attacker needs to know the target VM’s internal IP
address as the internal IP addresses for all VMs within the same zone have the same network prefix.
 In order to identify the VM’s internal IP address, the attacker rents a VM in the same cluster as the one where the VM
resides.
 The rented VM is then used to query the DNS server of the cloud cluster where the internal IP address of the target VM
can be fetched. By observing the internal IP address of the target VM in the DNS query, the attacker can tell what zone
© 2017 Copyright . All rights reserved. 8
within the cloud cluster the VM is hosted in.
Cloud Domain Attacks Chapter 8
A. Hidden Channel Attacks (Con’t)
Step2: Malicious VM Placement:
 having identified on what cluster and on what zone the target VM resides, the next step towards launching
an attack against the target VM is to place a malicious VM on the same server where the target VM
resides.
 In order to do that, the attacker rents a VM in the same cluster as the target VM. The cloud provider’s
scheduling algorithm places the rented VM on one of the servers within one of the cluster’s zones.
 The attacker performs a traceroute from the rented VM to the target VM where the routing path that
separates the rented VM and the target VM is identified.
 If the identified routing path shows multiple hops that separate the target VM and the rented VM, then the
attacker knows that the rented VM was not placed on the same server as the target VM.
 The attacker then releases the rented VM and requests a new one. The cloud provider’s scheduling
algorithm selects a server to host the requested VM. The attacker performs a traceroute from the new
rented VM to the target VM in order to know whether or not the target VM and the new rented VM reside on
the same server.
 The attacker continues releasing then renting new VMs and performing a traceroute until he/she identifies
that the cloud provider’s scheduling algorithm has placed the rented VM on the same server as the target
VM.

© 2017 Copyright . All rights reserved. 9

Cloud Domain Attacks Chapter 8
A. Hidden Channel Attacks (Con’t)
Step3: Cross-VM Data Leakage:
 Having placed a malicious VM on the same server as the target VM, the attacker now tries to learn
information about the target VM by exploiting the fact that although VMs are separated logically, they still
share parts of the server’s hardware, e.g. the instruction cache and the data cache.
 The attacker can now learn what lines of cache (data or instruction) the target VM has accessed recently.
This can be done as follows. When the shared cache is assigned to the malicious VM (under the control of the
attacker), the attacker fills the whole shared cache by dummy data. The malicious VM then yields the shared
cache to the target VM which performs some data access operations. The malicious VM sends an interrupt after
a short time from yielding the cache to the target VM asking to assess the cache so that the target VM yields the
cache for the malicious VM. Now the malicious VM probes the different lines of the cache asking to fetch the
dummy data that were previously filled in the cache.
 By observing the time it takes to access each chunk of the dummy data, the malicious VM can tell which
chunks of the dummy data where fetched from the cache and which chunks were fetched from memory as
they were replaced by data that was accessed by the target VM.
 This gives information to the malicious VM about what addresses the target VM has accessed recently.
Knowing what addresses the target VM accesses over time can help the malicious VM recover parts of the
security keys that the target VM is using.

© 2017 Copyright . All rights reserved. 10

 Chapter 8
Cloud Domain Attacks
A. Hidden Channel Countermeasures
• Hard Isolation solutions
1. Separate the cache dedicated for each VM through hardware or software.
2. Another way to achieve hard isolation is by assigning only one VM to each server. This
prevents data leakages across VMs but not a practical - leaves the servers underutilized.
3. Allow each cloud client specify a list of trusted cloud users (white list). Servers are only
shared the VMs belonging to the white list users.
4. New scheduling algorithms are needed to decide on what server each VM should be placed
such that the security constraints of each VM that are specified by the white and black lists
are met. A key limitation of this technique is that each VM must have a list of identified
untrusted VMs.
• Cache Flushing:
 Flushes the shared cache every time the allocation of the cache is switched from a VM to
another
 Downside: VMs running on the server will experience frequent performance degradation as
the shared cache will be emptied every time a switch from a VM to another occurs, which
increases the time needed to access and fetch data. © 2017 Copyright . All rights reserved. 11
 Chapter 8
Cloud Domain Attacks
A. Hidden Channel Countermeasures (Con’t)
• Noisy Data Access Time:
 Adds random noise to the amount of time needed to fetch data, which makes it hard to tell
whether or not the data was fetched from the cache or from the memory.
 By doing this, it becomes harder for a malicious VM to identify what segments of the cache
were populated by another VM that shares the same server.
 Of course this has a price as the fetched data gets delayed a little bit due to the noise
(variable time delay) that is added to the time needed to fetch the data.
• Limiting Cache Switching Rate:
 A mitigation technique to limit the amount of data that can be leaked across VMs can be
achieved by limiting how often the cache is switched from a VM to another.
 The idea here is that if the cache is not switched from a VM to another too soon, then the
VM that possesses the cache will modify the content of the cache a lot.
 This makes it hard for another VM to attain fine-grained knowledge of what data the
previous VM has accessed when probing the cache.

© 2017 Copyright . All rights reserved. 12

 Chapter 8
Cloud Domain Attacks
Reading Assignment

• VM Migration Attacks
• VM Escape Attacks
• Insider Attacks

© 2017 Copyright . All rights reserved. 13

IoT Domains
Server
Server Server

Cloud
Domain

Fog
Domain
IoT IoT IoT
Gateway Gateway Gateway

Sensing
Domain

© 2017 Copyright . All rights reserved. 14

IoT Layers / Domains
IoT Applications
IoT Cloud Domain

IoT Services Platform

IoT Fog Domain
IoT Network

IoT Sensing Domain

IoT Devices

© 2017 Copyright . All rights reserved. 15

Sensing Domain

© 2017 Copyright . All rights reserved. 16

 Sensing Domain Attacks and Countermeasures
Jamming Attacks
• Jamming the Receiver: Harmful user sends jamming signal
that interferes with legitimate signals. The interference
degrades the quality of the received signal causing errors. As
a result, the receiving end does not acknowledge the
reception of these damaged packets and waits for the sender
to retransmit.
• Jamming the Sender: Harmful user sends a jamming signal
that prevents the neighboring objects from transmitting their
packets as they sense the wireless channel to be busy.
• Other Attacks: Constant Jamming, Deceptive Jamming,
Reactive Jamming, Random Jamming

© 2017 Copyright . All rights reserved. 17

Sensing Domain Attacks and Countermeasures
Jamming Attacks Preventive Techniques

• Frequency Hopping: Sender & receiver switch from a frequency to

another in order to escape from possible jamming signals.
• Spread Spectrum: Uses hopping sequence that converts the narrow
band signal into a signal with a very wide band. This makes it harder for
harmful users to detect or jam the resulting signal.
• Directional Antennas: Less sensitivity to the noise coming from the
random directions
• Jamming Detection: Receiver can detect that it is a victim of a jamming
attack by collecting features such as “Received Signal Strength” and “Ratio
of corrupted received packets”. Advanced ML technique can then be used
to differentiate signals.

© 2017 Copyright . All rights reserved. 18

Sensing Domain Attacks and Countermeasures
Vampire Attacks (1/3)
• Vampire attack abuses the fact that the majority of IoT
objects have a limited battery lifetime
• A Harmful user misbehaves in a way that makes devices
consume extra amounts of power so that they run out of
battery earlier causing service disruption.
• The damage caused by this attack is usually measured
by the amount of extra energy that objects consume
compared to the normal case when no malicious
behavior exists.

© 2017 Copyright . All rights reserved. 19

 Sensing Domain Attacks and Countermeasures
Vampire Attacks (2/3)
• Denial of Sleep: Attacker can launch a Denial of Sleep attack which prevents
objects from switching to sleep by simply sending control signals that change
their duty-cycles keeping them active for longer durations.

• Flooding Attack: Attacker can flood the neighboring nodes with dummy
packets and request them to deliver those packets to the fog device, where
devices waste energy receiving and transmitting those dummy packets.

© 2017 Copyright . All rights reserved. 20

 Sensing Domain Attacks and Countermeasures
Vampire Attacks (3/3)
• Carrousel Attack: Attacker specifies routing paths
that include loops where same packet gets routed
back and fourth among the other objects wasting
their power (A sends to B and B sends to A).
• Stretch Attack: If the routing protocol supports
source routing, then a attacker can send the
packets that it is supposed to report to the fog
device through very long paths rather than the
direct and short ones (M selects longest path)

© 2017 Copyright . All rights reserved. 21

Sensing Layer Attacks and Countermeasures
Sinkhole Attack
• Attacker/malicious object (M) claims it has the shortest-path to the fog device
• This attracts all neighboring objects that don’t have the transmission capability to reach
the fog device to forward their packets to that malicious object (M) and count on that
object to deliver their packets.
• Now all the packets that are originating from the neighboring nodes pass by this
malicious node.
• This gives the malicious node the ability to look at the content of all the forwarded
packets if data is sent with no encryption.

© 2017 Copyright . All rights reserved. 22

 Security attacks targeting the Sensing Layer
Jamming, Vampire, Selective Froward and Sinkhole Countermeasures
Attack Target OSI Vulnerability Security Violation Countermeasures
Layer Reason
Jamming - Physical Shared wireless Availability - Frequency Hopping
Attack - Data Link channel - Spread Spectrum
- Directional Antennas
- Jamming Detection Techniques
Vampire - Data Link Limited battery - Availability - Rate limitation
Attack - Network lifetime - Freshness - Drop packets with a source route that contains a loop
- Monitor whether or not the forwarded packets are making
progress towards their destination

Selective- Network Limited - Availability - Increase transmission range

Forwarding transmission - Path Redundancy
Attack capability - Choose certain intermediate objects as checkpoints to
acknowledge received packets
Sinkhole Network Limited - Confidentiality - Analyze the collected routing information from multiple
Attack transmission - Availability objects
capability

© 2017 Copyright . All rights reserved. 23

 Fog Domain Devices and Challenges
• Fog layer devices
 Collect sensing data from a set of sensors / smart objects.
 Perform limited operations: Data aggregation, data IoT Applications
preprocessing, data storage, limited analytic / reasoning IoT Cloud Domain
operations.
IoT Services Platform
 Forwards results to cloud layer.
IoT Fog Domain
• Fog Layer is similar to cloud layer with key differences: IoT Network
 Location: Fog devices may be placed in areas with high
popular access (with ability to respond quickly to changes an IoT Sensing Domain
provide location services) IoT Devices
 Mobility: Location of things (and their fog devices) may
change over time
 Low Computing Capacity comparing to DCs

© 2017 Copyright . All rights reserved. 24

 Fog Domain Attacks and Countermeasures
• Authentication and Trust Issues: Unlike cloud data centers which are offered by well-known
companies, fog devices will be owned by multiple and less-known entities. Security concern (when
assigning a smart object to a fog device) is to authenticate the identity of the owner of the fog device.
• Higher Migration Security Risks: migrations from a fog device into another are carried over the
internet. Thus there is a higher probability that the migrated VMs get exposed to compromised network
• Higher vulnerability to DoS Attacks: Since fog devices have lower computing capacities this makes
them a low-hanging-fruit for DoS attacks
• Additional Security Threats due to Container Usage: Containers share not only the same hardware
but also the same operating system with the other containers that are hosted on the same fog device
• Location Privacy Issues: Each smart object will be connected to one of the fog devices that are close
to it. This means that the fog device can infer the location of all the connected smart objects.

© 2017 Copyright . All rights reserved. 25

Cloud Domain Potential Security Attacks
B. VM Migration Attacks (1/2)
• Control Plane Attacks:
• Migration Flooding: Attacker moves all the VMs that
are hosted on the hacked server to a victim server
that does not have enough resource capacity to host
all the moved VMs. This causes DoS of the victim
server as there won’t be enough resources.
• False Resource Advertising: Hacked server claims
that it has a large amount of free resources. This
attracts other servers to offload some of their VMs to
the hacked server. Attacker now breaks into offloaded
VMs.

© 2017 Copyright . All rights reserved. 26

Cloud Domain Potential Security Attacks
B. VM Migration Attacks (2/2)
• Data Plane Attacks:
• Sniffing Attack: attacker sniffs packets that are exchanged between the source & destination and
reads the migrated memory pages
• MIM Attack: attacker fabricates an ARP Reply packet similar to the one that is usually sent when
a VM moves from a server to another.
• Theft-of-Service Attack: malicious VM misbehaves in a way that makes the hypervisor assigns to
it more resources it needs (at the expense of the other VMs that share the same server). Victim
VMs get allocated less share of resources than what they should actually obtain, which in turn
degrades their performance.

© 2017 Copyright . All rights reserved. 27

 Security Attacks on the Cloud Domain
Attack Vulnerability Reason Security Violation Countermeasures

Hidden- Shared hardware components (e.g. cache) Confidentiality - Hard Isolation

Channel Attack among the server’s VMs - Cache Flushing
- Noisy Data Access Time
- Limiting Cache Switching Rate

VM Migration - VM Migration software bugs Confidentiality - Server authentication

attacks - VM Migration is performed without Integrity - encrypting migrated memory pages
authentication Availability
- Memory pages copied in clear

Theft-of- Periodic sampling of VMs’ used resources Availability - Fine-grain sampling using high precision clocks
Service Attack Non-Repudiation - Random sampling

VM Escape Hypervisor software bugs Confidentiality - Add an isolation layer between the hypervisor and hardware
Attack Availability
Integrity
Insider Attacks Lack of trust with cloud administrators Confidentiality - Homomorphic Encryption
Integrity - Secret storage through data chopping and permutation based
on a secret key

© 2017 Copyright . All rights reserved. 28