IoT

IoT
Security Challenges
Chapter 8
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..
IoT
Security Challenges (
Con’t
Chapter 8
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 attack that may degrade their
service time or may cause a service disruption.
IoT
Security Requirements
Chapter 8
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
understand the communications that were exchanged prior to joining the network.
Mapping of
IoT
Domains
IoT
Cloud Domain
IoT
Sensing Domain
IoT
Fog Domain
IoT
Devices
IoT
Network
IoT
Services
Platform
IoT
Applications
Mapping of
IoT
Domains
IoT
Gateway
Server
IoT
Gateway
IoT
Gateway
Sensing
Domain
Server
Server
Cloud
Domain
Fog
Domain
Could Domain Attacks
Chapter 8
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
another server.
Could Domain Attacks
A. Hidden Channel Attacks
Chapter 8
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 conclude 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
within the cloud cluster the VM is hosted in.
Could Domain Attacks
A. Hidden Channel Attacks (
Con’t
Chapter 8
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.
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.
Could Domain Attacks
A. Hidden Channel Attacks (Con’t)
Chapter 8
Step3: Cross
VM Data Leakage:
Having placed a malicious VM on the same server as the target VM, the attacker 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.
Could Domain Attacks
A. Hidden Channel Countermeasures
Chapter 8
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.
Could Domain Attacks
A. Hidden Channel Countermeasures (
Con’t
Chapter 8
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.
Could Domain Attacks
Reading Assignment
Chapter 8
VM Migration Attacks
VM Escape Attacks
Insider Attacks
IoT
Layers
IoT
Devices
IoT
Network
IoT
Services Platform
IoT
Applications
Discovery
Application
&
Service Layer
Management
Communicati
on
Management
/ Delivery
Handing
Data and DB
Management
Device
Management
Group
Management
Network
Service
Exposure/Ser
vice Ex
Triggering
Security
Billing &
Accounting
Subscription
& Notification
Could Service
Integration
Planning
IoT
Gateway
IoT
Domains
IoT
Gateway
Server
IoT
Gateway
IoT
Gateway
Sensing
Domain
Server
Server
Cloud
Domain
Fog
Domain
IoT
Layers / Domains
IoT
Cloud Domain
IoT
Sensing Domain
IoT
Fog Domain
IoT
Devices
IoT
Network
IoT
Services
Platform
IoT
Applications
Sensing Domain
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
Sensing Domain Attacks and Countermeasures
Jamming Attacks
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.
Sensing Domain Attacks and Countermeasures
Jamming Attacks Preventive Techniques
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.
Sensing Domain Attacks and Countermeasures
Vampire Attacks (1/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.
Sensing Domain Attacks and Countermeasures
Vampire Attacks (2/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)
Sensing Domain Attacks and Countermeasures
Vampire Attacks (3/3)
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.
Sensing Layer Attacks and Countermeasures
Sinkhole Attack
Security attacks targeting the Sensing Layer
Jamming, Vampire, Selective Froward and Sinkhole Countermeasures
Attack
Target OSI
Layer
Vulnerability
Reason
Security Violation
Countermeasures
Jamming
Attack
Physical
Data
Link
Shared
wireless
channel
Availability
Frequency
Hopping
Spread
Spectrum
Directional
Antennas
Jamming
Detection
Techniques
Vampire
Attack
Data
Link
Network
Limited
battery
lifetime
Availability
Freshness
Rate
limitation
Drop
packets
with
a
source
route
that
contains
a
loop
Monitor
whether
or
not
the
forwarded
packets
are
making
progress
towards
their
destination
Selective
Forwarding
Attack
Network
Limited
transmission
capability
Availability
Increase
transmission
range
Path
Redundancy
Choose
certain
intermediate
objects
as
checkpoints
to
acknowledge
received
packets
Sinkhole
Attack
Network
Limited
transmission
capability
Confidentiality
Availability
Analyze
the
collected
routing
information
from
multiple
objects
Fog layer devices
Collect sensing data from a set of sensors / smart objects.
Perform limited operations: Data aggregation, data
preprocessing, data storage, limited analytic / reasoning
operations.
Forwards results to cloud layer.
Fog Layer is similar to cloud layer with key differences:
Location:
Fog devices may be
placed in areas with high
popular access
(with ability to respond quickly to changes an
provide location services)
Mobility:
Location of things (and their fog devices) may
change over time
Low Computing Capacity
comparing to DCs
Fog Domain Devices and Challenges
IoT
Cloud Domain
IoT
Sensing Domain
IoT
Fog Domain
IoT
Devices
IoT
Network
IoT
Services
Platform
IoT
Applications
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.
Fog Domain Attacks and Countermeasures
Backups
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.
Cloud Domain Potential Security Attacks
B. VM Migration Attacks (1/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.
Cloud Domain Potential Security Attacks
B. VM Migration Attacks (2/2)
Security Attacks on the Could Domain
Attack
Vulnerability
Reason
Security
Violation
Countermeasures
Hidden
Channel
Attack
Shared
hardware
components
(e
g
cache)
among
the
server’s
VMs
Confidentiality
Hard
Isolation
Cache
Flushing
Noisy
Data
Access
Time
Limiting
Cache
Switching
Rate
VM
Migration
attacks
VM Migration software bugs
VM Migration is performed without
authentication
Memory pages copied in clear
Confidentiality
Integrity
Availability
Server
authentication
encrypting
migrated
memory
pages
Theft
of
Service
Attack
Periodic
sampling
of
VMs’
used
resources
Availability
Non
Repudiation
Fine
grain
sampling
using
high
precision
clocks
Random
sampling
VM
Escape
Attack
Hypervisor
software
bugs
Confidentiality
Availability
Integrity
Add
an
isolation
layer
between
the
hypervisor
and
hardware
Insider
Attacks
Lack
of
trust
with
cloud
administrators
Confidentiality
Integrity
Homomorphic
Encryption
Secret
storage
through
data
chopping
and
permutation
based
on
a
secret
key
Link Layer
IEEE 802.15.4
Chapter 8
IEEE 802.15 Task Group 4 (TG4) developed solution for
Low data rate wireless
connectivity
Low complexity
Extended battery lifespan
Operate in an unlicensed, international frequency band.
Potential applications: toys, smart badges, remote controls and home
automation
short
range communication.
The standard operates over several frequency bands, which vary by region:
868
868.6 MHz
902
928 MHz
2400
2483.5 MHz
In China 314
316 MHz, 430
434 MHz and 779
787 MHz
In Japan 950
956 MHz
Transmission range varies from tens of meters up to 1 kilometer.
The protocol is fully acknowledged for transfer reliability.