Chapter 8:
Internet of Things
Security and Privacy
Prof. Ammar Rayes
26 October 2015
2021 Copyright, All Right Reserved.
Chapter 7
Services Platform Functions (Chapter 7 Review)
API Manager
Platform Discovery & Communication
Manager Registration Manager
Data Firmware Topology
Manager Manager Manager
Group Billing & Subscription &
Manager Accounting Notification
Element Manager: Configuration, Fault, Performance and Security
Chapter 8
IoT Security Challenges
• Multiple Technologies: Each IoT technology—such as wireless sensors, RFID, cloud platforms, and
virtualization—has its own unique set of vulnerabilities. To secure an IoT application, the entire
technology chain must be protected, as the system is only as secure as its weakest link.
• Multiple Verticals: The IoT ecosystem spans a wide range of verticals (e.g., healthcare, industrial,
transportation, agriculture), each with distinct security requirements. A one-size-fits-all approach to IoT
security is ineffective; solutions must be tailored to the specific needs of each vertical.
• Scalability: With an estimated 30+ billion smart devices expected to be connected to the Internet,
traditional centralized security frameworks are no longer viable. The sheer scale of the IoT landscape
necessitates practical, decentralized defensive mechanisms that can scale with the growing number of
devices.
• High Availability (HA): HA refers to a system’s ability to remain operational for a prolonged period
without interruption. It is typically measured against a theoretical 100% uptime, with “five nines”
(99.999%) availability equating to just over 5 minutes of downtime per year.
• Security is a critical factor in maintaining HA. Network administrators often hesitate to activate
necessary threat-response features (e.g., network discovery or scanning) due to concerns that these
actions could inadvertently disrupt essential systems. In fact, even a basic port scan has been known to
cause some IoT devices to crash. The cost of downtime in such scenarios can significantly outweigh the
cost of mitigating most security threats.
Chapter 8
IoT Security Challenges (Con’t)
▪ Big Data: Each smart object is typically equipped with numerous sensors, each generating continuous streams of
data. Over time, these streams accumulate into massive volumes of data. This makes it critical to develop
efficient and scalable security mechanisms that can protect large-scale data flows in real-time.
▪ Resource Limitations: Most IoT end devices have limited computational and energy resources—including
constrained CPU power, memory, storage, battery life, and transmission range. These limitations make them
prime targets for Denial of Service (DoS) attacks, where an attacker can easily exhaust their resources, causing
device failure or service disruption.
▪ Remote Locations: In many IoT verticals (e.g., smart grids, railways, roadside infrastructure), devices—especially
sensors—are deployed in unmanned, remote, and hard-to-reach locations. This allows attackers to tamper with
devices without detection. To ensure security, cyber and physical monitoring systems must be:
▪ Installed in protected enclosures
▪ Capable of withstanding harsh environmental conditions
▪ Compact and remotely manageable
▪ Designed to allow routine software updates and diagnostics without costly technician site visits
▪ Mobility: In many IoT scenarios, smart objects are mobile—they frequently change location. This dynamic
behavior poses additional challenges to the design and deployment of security mechanisms, which must adapt to
changing network topologies and device associations in real time.
▪ Delay-Sensitive Services: A large portion of IoT applications—such as healthcare, autonomous vehicles, and
industrial control—are delay-sensitive. Any attack that degrades response time or causes disruption can have
critical consequences. Therefore, latency-aware security solutions are essential to maintain service continuity and
performance.
Chapter 8
IoT Security Requirements
1. Confidentiality: Ensures that exchanged messages can only be understood by the intended entities or machines.
Unauthorized parties should not be able to read or infer the contents of the communication.
2. Integrity: Ensures that messages have not been altered or tampered with by a third party during transmission. It guarantees
the trustworthiness of the message content.
3. Authentication: Verifies the identities of entities involved in any operation, ensuring they are who they claim to be. Attacks
such as masquerading or impersonation typically target this requirement by attempting to assume the identity of a legitimate
entity.
4. Availability: Ensures that the system or service remains accessible and operational when needed. Denial of Service (DoS)
attacks aim to compromise this requirement by disrupting normal service functionality.
Example: A system with 99.99% availability would experience approximately 52.56 minutes of downtime per year:
• 365×24×60=525,600 minutes/year525,600×0.0001=52.56 minutes/year
• 365×24×60=525,600 minutes/year525,600×0.0001=52.56 minutes/year
5. Authorization: Ensures that authenticated entities have the appropriate permissions to perform specific operations. It
governs access control to resources and actions.
6. Freshness: Ensures that data is recent and not reused from previous sessions. Replay attacks exploit this requirement by
resending old messages to manipulate the system into reverting to a previous state.
7. Non-repudiation: Guarantees that an entity cannot deny having performed a particular action or communication. This is
critical in scenarios like digital transactions or logging of system events.
8. Forward Secrecy: Ensures that if an entity leaves the network, it cannot access or decipher communications that occur after
its departure.
9. Backward Secrecy: Ensures that when a new entity joins the network, it cannot access or decipher communications that
took place before its inclusion.
Mapping of IoT Domains
IoT Applications
IoT Cloud Domain
IoT Services Platform
IoT Fog Domain
IoT Network
IoT Sensing Domain
IoT Devices
Mapping of IoT Domains
Server
Server Server
Cloud
Domain
Fog
Domain
IoT IoT IoT
Gateway Gateway Gateway
Sensing
Domain
Chapter 8
Could 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
another server.
Could Domain Attacks Chapter 8
A. Hidden Channel Attacks
• Although there is a logical separation among 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.
Chapter 8
Could Domain Attacks
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.
➢ 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 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 tries to learn info
about the target VM
➢ The attacker can now learn what lines of cache (data or instruction) the target VM has accessed
recently. i.e.
o When shared cache is assigned to attacker VM, s/he fills the shared cache by dummy data.
o 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.
o Now the malicious VM probes the cache 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.
Chapter 8
Could Domain Attacks
A. Hidden Channel Countermeasures
• Hard Isolation solutions
➢ Separate the cache dedicated for each VM through hardware or software.
➢ 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.
➢ 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.
➢ 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.
Chapter 8
Could 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.
Chapter 8
Could Domain Attacks
Reading Assignment
• VM Migration Attacks
• VM Escape Attacks
• Insider Attacks
• Hidden Channel Attack (Covered in the slides)
IoT Layers
IoT Applications
Communicati
Application & on
Data and DB Device Group
Discovery Service Layer Management Management Management Management
Management / Delivery
Handing
IoT Services Platform Network
Service
Exposure/Ser
vice Ex-
Security
Billing &
Accounting
Subscription
& Notification
Could Service
Integration
Planning
Triggering
IoT Network
IoT Gateway
[Link]
IoT Devices
IoT Domains
Server
Server Server
Cloud
Domain
Fog
Domain
IoT IoT IoT
Gateway Gateway Gateway
Sensing
Domain
IoT Layers / Domains
IoT Applications
IoT Cloud Domain
IoT Services Platform
IoT Fog Domain
IoT Network
IoT Sensing Domain
IoT Devices
Sensing Domain
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
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.
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.
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.
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 the 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 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.
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
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
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.
Backups
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.
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.
Security Attacks on the Could 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
Chapter 8
Link Layer
IEEE 802.15.4
• 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.