Towards a Unified Trust Framework for Detecting
IoT Device Attacks in Smart Homes
1 Hussein Alsheakh∗ and Shameek Bhattacharjee∗

Department of Computer Science, Western Michigan University, Kalamazoo, Michigan 49008, USA
Email: {hussein.s.alsheakh, shameek.bhattacharjee}@wmich.edu
Abstract—Trust in Smart Home (SH) Internet of Things (IoT)
technologies is a primary concern for consumers, which ispreventing the widespread adoption of smart home services.
Additionally, the variety of IoT devices and cyber attacks makeit hard to build a generic attack detection framework for smart
home IoT devices. In this paper, we present a roadmap towards
building a unified approach towards establishing trust scoresas an indicator of the security status of an IoT device ina smart home that works across multiple attacks and device
types/protocols. Specifically, we first introduce artificial reasoning
inspired evidence collection approach by introducing a small set
of factors that are affected significantly if a smart home IoT
device is under attack. Thereafter, we propose an explainable
trust scoring model that maps the device level evidence into
trust scores in a way that produces lower trust scores whendevices are under attack. Specifically, the trust model involves an
Augmented Bayesian Belief based Model embedded with novel
non-linear weighing functions; explicitly designed to account forthe severity of the attack, probabilistic discounting of parts of theevidence caused by benign changes, thus explaining our success.
For evaluation of the framework, we use two real datasets that
contain a variety of actual cyber-attacks and benign traffic fromseven different smart home IoT devices. Our evaluation seeks
to investigate the generality of our framework across multiple
datasets, with various classes of IoT devices and cyber attacks.
Index Terms—Internet-of-Things, Trust, Security, Smart Home,
Artificial Intelligence based Security, Machine Learning

I. I NTRODUCTION
Smart Homes are environments offering services to homeinhabitants via a network of communication-enabled IoT devices that contain embedded software. IoT devices communicate with each other/remote service providers and often makedecisions without human intervention. However, the concept ofa smart home is a cornerstone of smart connected communities.
Smart home exposes the most private and vulnerable of ourpersonal spaces to the internet, which is known to be vulnerable
to several classes of cyber-attacks [1].
Nonetheless, traditional cyber threats at best had economic
impacts on businesses and breaches of personal data at rest.
In contrast, in the evolving paradigm of smart home IoT,
the cyber attacks have an immediate civilian impact thatis riskier. Moreover, there are new IoT technology-specificsecurity challenges that need to be handled explicitly.
*Equal Contribution
1 Hussein Al-Shaekh is also affiliated to Al-Mustansiriah University as anteaching instructor

Since IoT devices have constrained memory and computational resources, strong on-device security solutions arebarely possible without significantly reducing their usability.
Additionally, there is a lack of vendor motivation to implement
security schemes in IoT products [2] due to cost versus utility
trade-offs, while other vendors do not implement too muchsecurity to improve latency and quality of service and reduce
costs [3]. For example, after analysis of smart home data,
researchers in [2], [3] found only one IoT device that uses
secure encrypted SMTP protocol, and only ’some’ IoT devices
use secure HTTP port (HTTPS 443), and most other IoT
devices are using insecure HTTP over port 80. We did not
find any device use the MQTT secure port 8883 [4]. Thereis a lack of standards in IoT protocols and port mappings thatmakes it hard to have an established rule or specification based
attack detection that is common to all IoT devices.
A. Challenges and Motivation
Prior work on IoT device attacks can be broadly classified
into the following categories network-level data flow [5] ,device-specific fingerprinting [6], attack specific [7], network
segmentation [8], localization approaches [9], IoT networkor device components classification [11], embedded security
architecture [12], or adopt known machine learning techniques
for anomaly detection [10]. Localization based approaches only
take care of physical proximity issue that is more related to authentication but does not detect attacks on already authenticateddevices. Similarly, network segmentation involves splitting
the smart home network channel to various sub-networks tomitigate the movement of attacks, but do not detect them
actively. Device-specific approaches do not scale due to thelarge heterogeneity of device types that can be found in smart
home IoT markets. Similarly, attack specific approaches needseparate solutions for each cyber attack. Therefore, the numberof solutions for providing a secure smart home increases.
Therefore, there is a need for a more unified solution that is
not attack or device-specific, but that which generalizes acrossmost attack types, devices, and services in smart home IoT.
B. Contributions of this WorkIn this paper, we propose a ‘unified’ approach towards
establishing trust scores as a reliable indicator of the security
status of IoT devices in a smart home. Our framework contains

a series of modules: (a) service level access rules, (b) evidencecollection via proposed unified factors, (c) trust scoring module. Specifically, our service access rule mechanism takes aservice-level view, establishing baseline access rules of authorized communication flows from IoT applications. Thereafter,
our evidence collection module proposes a unified set of novel
factors that are affected significantly if a smart home IoT
device is under attack while provisioning for benign changes in
network behavior. Such a body of evidence, carefully collected
over time, serve as inputs to the trust scoring module. Finally,
the trust scoring module maps the device-specific evidence(observations) into trust scores, such that it produces lower trustscores when devices are under attack. Specifically, we proposea Bayesian Belief based Model augmented with novel nonlinear weighing and activation functions, designed specificallyfor our problem. The weighing functions contain embeddingsof certain explainable factors and are designed such thatthe severity of the attack, probabilistic discounting of partsof the evidence caused by benign changes are appropriately
embedded in the scoring module; that explains our successunder attacks while preventing false alarms.
For the evaluation of our framework, we use two different
datasets containing various actual cyber attacks and benign
behaviors for various IoT device types. Our evaluation seeks
to investigate the generality of our framework across multiple
datasets, devices, and attacks, compared to existing solutions
that treat each of these aspects in silos. The remaining paper
is organized as follows: Section II system model, Section
III threat model, Section IV proposed framework, Section V,
experimental results, and conclusion.
II. S MART H OME I OT S YSTEM M ODELThis section introduces several pieces of network components that help us understand the smart home network architecture, as shown Fig. 1. Such components include (1) IoT devices(low computation devices), (2) non-IoT (high computation)
devices, (3) IoT hub devices, (4) smart home gateway (edge/fog
node), and the (5) cloud gateway (cloud node).
A. Device Types
A smart home (SH) contains various types of IP enabled
devices. It is important to differentiate between IoT devices
and non-IoT devices, as shown in Fig. 1. Based on thecomputational ability, an SH can have low computation power(IoT) and high computation power (non-IoT) IP devices.

Low computation IP Devices (IoT): An IoT device is an IPenabled device (e.g., smart camera) that has limited computational abilities compared to laptops/smartphones/tablets, andoffers a small set of services to the smart home (SH) owner(e.g., smart surveillance). Each IoT device has an API (orsimply app.), that enables it to offer corresponding SH services.
The service is offered to the SH owner when an IoT device’s
corresponding app. connects to specific servers (on the rest of
the internet/within the LAN) on which IoT service providers
host their services. Thus, there is a mapping between an IoT
device apps and services.
High computation IP devices (non-IoT): These are devices
that may host apps/APIs that allow the use of IoT services
offered by IoT devices. Examples of such high computation
IP devices include smartphones, tablets, laptops. These devices
typically install many apps and software on their OS. All othersensors and actuators that are not enabled by an IP address,
but collect data and perform actions, are not considered as IoT
devices. The security of such devices is beyond our scope.
Smart Home Gateway (SHG) and FIoT: Each smart home has
a gateway router (SHG), that connects the IoT devices tothe rest of the internet. This SHG supports services such as
Network Address Translation (NAT), Software Defined Networking (SDN), and can also host middleware services usinga Raspberry-Pi micro-controller. Our proposed trust model
is deployed on the smart home gateway router (SHG) as a
FIoT middleware. All smart home services are managed andcontrolled by the edge/Fog Internet of Things Middleware(FIoT) that is within the home network. Thus, FIoT will beable to monitor SH network activity originating from a given
smart home.
B. Smart Home Operations
Let each IoT device be denoted by i ∈ {1, 2, .., I}, where
I is the total number of IoT devices in the smart home. Each
such IoT device, provides a set of services with the help of one(or more) apps. The set of services is represented by the set
S (i) ∈ {1, · · · , k, · · · , K (i) }, and the set of apps is represented(i)by A(i) ∈ {1, · · · , j, · · · , Nj }, where k and j denote any(i)given service and an app respectively, while K (i) and Nj
are total number of services and apps offered by the i-th IoT
device, respectively. In most cases, IoT devices have a single
app that provides multiple services, but occasionally it might
contain multiple apps. Therefore, the set of services offered byIS
a home is
S (i) .
i=1

Figure 1: Smart Home Network Architecture

Scope of Our work: We make the following assumptions
for our work: 1). The use of a cellular network for any
communication directly from IoT devices is beyond the scopeof our work. We only consider the smart home network,
which communicates through the WiFi or wired LAN that is
managed and controlled by the FIoT middleware hosted on
SH Gateway. This paper only intends to detect misbehavior bysmart home IoT device applications connect via a smart home

WiFi network that uses a central gateway router. 2) Our scope
does not include the detection of the data leakage caused by
the non-IoT devices/applications of the smart homeowner.
III. T HREAT M ODELWe characterize the threat model by various attack types,
strengths, and strategies:
Direct Attacks: In the direct attack in SH, the attacker flood
victim that could be within/outside the SH network from acompromised IoT device. The direct attack types included in
our labeled attack dataset include well-known attacks such as
Fraggle, Ping flood, and TCP SYN [10], [15].
Reflection Attacks: the SH reflection attack, the attacker uses
a spoofed IP (SH IoT device IP) for attacking victims; in thisway, the attacker uses SH IoT devise as a weapon for targetingthe victim. Types of Reflection attacks include:(i) Custom Malware Campaigns: These are malicious campaigns, where software designed to disrupt IoT device operations, usually used to create a Distributed Denial of Service(DDoS) attack. In many instances, such malwares are known
to show movement and grow their attacks from one to more
SH IoT devices and services, taking down a large sectionof important network entities. In this work, our experiments
contain data from the malwares Hide and Seek, Muhstik, Torii,
the most advanced botnet malware, according to Avast security
researcher, that can attack many device architectures.
(ii) SMURF: it is a network attack where the attacker floods
the SH router with spoofed ICMP traffic via sending a request
to IoT devices with a spoofed source IP of the victim server.
Thus, the device will reply to the targeted victim IP. The
attacker’s goal is to disturb the victim’s server operations. Suchattack behavior is to use the SH IoT device as a weapon fortargeting victim servers and is relates to the number of packets
being sent per time interval.
(iii) SSDP reflection: it is a malware app running on smart
home IoT devices by using the Simple Service Discovery
Protocol (SSDP) used to discover IoT devices in SH. It alsouses Universal Plug-n-Play (UPnP) port forwarding to allow
a direct attack on IoT devices by an external attacker [15].
Mainly, the SSDP and UPnP port forwarding are conventionalin SH network because some IoT devices support peer to peer
applications. The adversary uses the SSDP protocol to discover
the devices and services in SH without explicit configuration
using SSDP vulnerabilities.
(iv) SNMP reflection: During an SNMP reflection attack, theadversary sends out a large number of SNMP queries with aspoofed IP address (of victim’s IP) to smart home IoT devices,that in turn reply to that victim IP instead of the attacker
IP. The attack volume grows as the number of compromised
smart home IoT devices (that continue to reply to the victim)
increases, the victim becomes crippled, due to the huge volumeof SNMP responses.
Co-Domain DDoS and Leakage: This kind of attack takes
advantage of the IP/port forwarding feature that is argued

as necessary to support QoS guarantees by ensuring server
availability and load balancing. Therefore, a designated server
may forward IoT device requests to other servers in thesame network/cloud domain or third party providers. In suchan instance, the IoT device gets a response/requests froma different server other than the typical server of the IoT
provider. Normally, such occurrences are less during benign
conditions; however, increased frequency and volume of such
events should indicate suspicion. This is because many servers
belonging to the business rivals/competitors/adversaries may be
co-located in the same network/cloud domain as the designatedserver for that service. Taking a completely conservative approach of treating every such instance as suspicious will either
increase false alarms, reducing the efficiency of IoT services.
Attack Strength Variation: IoT devices have a limited processing capability for network traffic. Therefore, if the reflection attack is too high in volume, the device may stop working
altogether. Intelligent attacks would like to keep compromised
devices still operational to allow launching attacks on othermachines. In such cases, the attacker may keep traffic rates
low because it wants to conceal the attack’s effect or if its realtarget is not the IoT service provider.
In another attack, the attacker may be willing to make theIoT device less or not functional, and thus keeps traffic rate
medium or high accordingly. Thus, traffic volumes, even forthe same attack type, vary according to the goals or motivationsof adversaries who are difficult to predict. To embed this, weparameterize the attack volume by varying attack strengths
in our simulated dataset. From the real dataset obtained
from [10], [19], we used three different attack strengths per
attack: (i) high attack traffic rate, which generates 100 packets
per second (pps), (ii) medium attack traffic rate, generate 10
pps, (iii) low attack traffic rate that generates 1 pps.
IV. P ROPOSED F RAMEWORKOur proposed framework will be deployed as a framework in
the FIoT, which inspects and manages data plane traffic flow (e.
g., recording source and destination IPs:port mappings) to/fromall SH IoT devices. Our framework has three main phases:(a) Access Control Policy Engine (b) Evidence Collection via
Unified Factors, (c) Trust Scoring Model.
The Access Control Policy engine sets baseline rules ofbenign access for the apps of each IoT device. Thereafter, basedon which parts of traffic flow attributes align with the service
level access control policy, we propose a set of unified factorsthat remain largely unaffected under legitimate benign changes
but show variations under attacks. These sets of factors produce
a set of features per device as a body of evidence that serves
as an input to our proposed trust scoring model. This evidencecollection phase partly uses the ACL to compare network traffic
attributes captured at the FIoT, although there are non-ACL
aspects of evidence collection. Our trust scoring model is an
artificial intelligence inspired approach that maps evidence into

trust scores, such that devices under attacks show lower scorescompared to when they are not attacked.
A. Service Access Rule Policy
Typically, an access control policy engine sets static anddynamic access rules (known as Access Control List (ACL))
for devices explicitly registered with the FIoT. The decision onwhether a device should have authorized access to a service iscontextually related to the functionality.
While IoT devices exhibit heterogeneity, the number ofservices they offer is limited. The Manufacturer Usage Description (MUD) is a novel IETF specification that offers
suggestions on the expected behavior of an IoT device contextually related to the services it offers. Specifically, the key
idea of the MUD is to return a list of acceptable or expected
destination DNS names and destination port numbers, which
identifies one or more designated servers for the corresponding
service that an IoT device should offer as well as ancillary
end-points it might communicate to. Although not a security
specification itself, MUD profiles can be used as a first step
towards protection.
Note that what is included in the MUD specification, andhow security engineers/administrators interpret the MUD specification for access control are deciding aspects for achievablesecurity level. In a previous work [10], the idea of the access
control list was synonymous with the MUD profile. Theiridea of the MUD profile was to include all communication
patterns observed in the benign dataset. However, our treatmentof access rules is different from previous work, since we
differentiate between MUD and access compliance.
Our FIoT uses the DNS lookup to resolve the domain namein the MUD to the IP address of the servers that are supposed tooffer the services. Thus, MUD can be used to point all IPs andport no.s. that should be offering services or communicatingwith that IoT device. Now, this most commonly includes the
IoT service provider and the hardware vendor. For specific IoT
devices like smart cameras and home assistants, they connect
to a lot of different servers other than the service provider, andthere the volume of packets exchanged is important. Hence,
our ACL design goal is to manage a table that sets baselinebenign access rules of each IoT device i’s app/firmware j boththe client-side (Source devices) and server (Destination) side
based on the above awareness.
1) Client Side: When an IoT device is first introduced in
SH, it has to be registered with the FIoT as an authenticateddevice. The Source IP, Source MAC, and Source Port Number
is first added to the ACL. In this way, FIoT makes sure that
all active data flows at-least do not directly come from outside
the network and are registered IoT devices based on their IP
and MAC addresses.
2) Service Side: To find a mapping between IoT devices
and their corresponding designated server’s (that provide its
service) destination port numbers, destination IPs, and DNS

names, our FIoT queries the MUD server that returns a portbased list that specifies those DNS names, and ports andthat should be typically accessed by a given service offeredby an IoT device. The MUD URLs are updated via various
IoT providers and manufacturers. While not all manufacturers
subscribe to the MUD specification, it is becoming common
over time, and thus will become a practical approach. The
information added to the ACL includes Destination Port No.,
Destination IP, Service ID, Service Type, as shown in Fig. 2.
Note that we only put the designated IoT service provider
server as a whitelist entry. Everything else is subject to different
levels of suspicion as detailed in the factors for evidencecollection. The reason for doing this is given below:
From studies of datasets, we found gray areas in IoT devices
such smart cameras (that use STUN protocol) or IoT home assistants, which need to access random unauthenticated serversthat may or may not be servers in the same cloud domain, as
the IoT provider. Making them part of ACL may cause missed
detection of attacks. Additionally, we have found several cases
where IP and port forwarding causes the response to arrive
from a different server than the one listed on the MUD profile.
Thus, using the MUD directly as ACL will increase false
alarms. Additionally, packets are exchanged for maintenanceor monitoring purposes between the hardware manufacturer
and device, but such an occurrence is ‘infrequent’.
Our view of a service based ACL includes the following:
Each IoT device has a list of authorized IPs (corresponding
to servers that provide services related to that IoT device) for
each app(s) hosted by that device. For example, the services of
IoT device i is provided by using two apps j1 and j2 services
app, where both j1 and j2 allowed to have a conversation with
only specific devices and servers using IPs of these devices aspresented in Fig 2. The app/firmware is present in the form ofdestination IP:port entry.

Figure 2: Smart Home access control policy
B. Evidence Collection Mechanism
A communication (packet exchange) not matching the ACL
does not automatically mean an attack and requires further
checks that we incorporate in our evidential model. Typically,
anything that does not match with an ACL is denied or deemedsuspicious, thus increasing false alarm rates, decreasing usability. Our interpretation of service level access control is notstrictly binary due to the observed variations in IoT behaviors.
Similarly, interaction confirming the access control list does
not necessarily imply no attacks, which we also incorporate in
our evidential model. The above awareness is central to ourdesign of unified set of factors. From here, we will refer to thepacket exchange via the FIoT as an interaction.
Intuitively, the body of evidence should point towards degrees of positive, negative, possibly suspicious interactions
based on the body of evidence. The goal is to find (i) a methodology for labeling the interactions; (ii) corresponding mathematical representations of these factors (known as features)that captures the effects of attacks in a numerically quantifiableway. Thus, features form the mathematically tractable evidence
that is driven by our proposed set of factors.
We propose the following set of factors: (1) Service Access
Uncertainty (2) Cumulative Volume of Uncertain Accesses (3)Service Access Violation (4) Access Violation Diversity. Below
we describe each of these factors.

Figure 3: Evidence Collection
1) Service Access Uncertainty: Packet flows originatingfrom a device not matching the destination IP and Ports in the
ACL may or may not be necessarily due to an attack. Hence,an intelligent framework should not blindly label this event asa negative interaction. Not matching flows can be attributed tobenign ‘events’ in smart home IoT operations, such as:(1) Hardware Vendor checks: Packets are sent from IoT
devices to servers that belong to their third-party vendors formonitoring purposes (such as estimating the remaining life ofa device, etc.). (2) IP and port Forwarding: Sometimes, traffic
is redirected to a different IP or Port than the designated one in
the MUD, to guarantee quality of services (QoS) issues (e.g.,
too many requests concurrently can be forwarded) or in caseof server maintenance/upgrades/downtimes. In such cases, theincoming response to an IoT device comes from a different
server but is usually within the same network/cloud domain as
the authorized server in the ACL. (3) use of STUN servers for
smart cameras and video streaming services: From our studyof smart home IoT datasets and previous literature, we foundmost cameras use the UDP port 3478 for communicating withvarious servers on a peer to peer mode to allow seamless accessto smart surveillance from anywhere. Such servers cannot belearned and included from the MUD profile.
However, the above, if treated as a match in the ACL canallow adversaries to create cyber attacks on servers within thesame cloud domain, third party vendors, or those that hoststreaming. This gives the intuition that we should treat themas between a match and mismatch(i.e., uncertain). Therefore,
we believe that once a packet exchange does not match thebaseline ACL, we first check if it might be due to any of theabove three reasons by the following procedure (summarized
in Fig. 3).
Our FIoT queries an IP lookup service Info-Sniper [24],that provides meta information for any IP recorded in the
network traffic. This information includes: (i) Name of the
Owner/Provider (ii) Geolocation (iii) DNS name (iv) Time
Zone. Therefore, packets sent to a given destination IP ischecked by our FIoT to ascertain whether the Name of the
Owner and other attributes match with (1) any of the third
party vendor/manufacturer of the IoT device, (2) whether they
are within the same cloud/network domain name, or (3) use
the STUN protocol’s UDP port (if the device offers streaming
video services). To conclude, if a packet exchange does notmatch the access control list, the FIoT checks for the abovementioned possibilities using the context information queried
from the Info-Sniper lookup service. If there is a match, welabel this packet flow as ‘uncertain.’ If not, then we wouldlabel this packet exchange as a violation. Mathematically, we
denote an uncertain packet exchange for services as U (i) (s).
Number of Uncertain Packets Per Time Window: Therefore,
the corresponding feature that we keep track is the total
number of uncertain packet exchanges for a given device i
within a time window T , denoted asXηu(i) (T ) =U (i) (s)(1)T2) Cumulative Volume of Uncertain Accesses: One important fact about the events that cause uncertainty is thatwhen they are due to benign behavior, the packet volume
is low. Uncertain exchanges can be allowed a benefit of the
doubt (discounted) while calculating the trust scores of adevice. However, beyond a certain volume of total uncertain
exchanges, this situation should be viewed as suspicious, owing
to the infrequent pattern of such occurrences. This aspect islater embedded using an uncertainty weight function, which isa function of the total uncertain packet volume.
Cumulative Sum of Uncertain in a Time frame: At eachtime window, we keep a cumulative sum of uncertain
interactions over a sliding frame of previous F time windows.
µu (T ) =TX

ηu(i) (T )

(2)

T −F

3) Service Access Violation: The next factor for evidencecollection for potential malicious activity is the service accessviolation. The main idea is that if an interaction from an IoT
device does not match the authorized access control list entries
and can neither be reasoned as uncertain, then this event of(i)
access is treated as a violation represented as (Vj ), i.e., theviolation of app j that runs inside the device i.
Number of Violation Packets Per Time Window: In fact, forthat time window, T , the FIoT middleware calculates the total
number of access violation of K services by all the apps j1 to(i)
jn running on IoT device (Vj ).

ηv(i) (T ) =

X

(i)

Vj

(3)

T

4) Access Violation Diversity: The Access Violation Diversity wd represents the extent of the cross-section of services/servers being affected by a set of violations. Suppose
if one device is trying only to access one service ten times,
whereas another device is trying to access ten different unauthorized services, within the same time window T , the second
scenario is far more serious from a security perspective. Thus,
Access Violation Diversity is an important feature to determine
how the attacker is trying to grow its attack impact andcompromise more resources.
(i)The
Number of Unique Services with violations ηvs (T ):number of unique services that experienced violations
recorded for a given IoT device i in a time window T .
Mathematically, it is represented by the following:(i)ηvs(T ) =

K
X

where,I(i, s) =1,
0,

Di + 1f (θi |Di ) = PKi=1 Di + K

I(i, s)(4)

If i violated service s
Otherwise(5)

From the network traffic analysis of attacks (in a crossvalidation set), we found common links between different attacks. Once our rule of matches, violation, and uncertainty are
in place, most real IoT cyberattacks either registers violation
with increased packet volumes, or an abnormal increase in the
cumulative volume of packet exchange to uncertain destinations, as well as the relative volume of uncertain interactions.
In Fig 4, we show a summary of the observed relationshipbetween different types of reflection and direct attacks, andthe factors we put forward, which succinctly explains why ourfactors work in terms of building the appropriate evidence.

(6)

Where K is the total number of mutually exclusive categories in the evidence state space, i is the i-th category, andDi is the frequency of occurrences of the i-th event in the data.
Degrees of Disbelief and Uncertainty Using the result in
Eqn. 6, we apply the known derivation provided in [21], tofind the degrees of disbelief and uncertainty as:
(i)

s=1



violation, or an uncertain interaction can be calculated using
posterior beliefs calculated using Bayesian inference where thedata is a multinomial distribution of the number of matches,mismatches, and uncertainty.
Previous studies [20] have shown that for multinomiallydistributed data Di with a non-informative prior, the posterior probability belief θi is given by the mean of Dirichlet
distribution as the following:d(i) =

nv + 1
N (i) + 3(i)u(i) =

nu + 1
N (i) + 3

(7)

Embedding Access Violation Diversity: However, in Eqn. 7,
the d(i) only indicates the proportion of violations to the total
number of accesses. It does not provide any idea on the attack
scale or surface over which this proportion of violation wasrecorded. If the same proportion of violation is recorded froma unique number of devices, this is a more severe attack than
the same proportion of violation targeting only one device.
Therefore, we need to add weight to the d(i) , which embeds
the importance of how many unique devices were involved in
the observed proportion of violations. This is similar to neurallearning approach. The question is what functional form should
describe this behavior. We use a modified softplus function
scaled between zero and one, by the following Eqn.
τv(i) = log(aeηvs + 1)

(8)

where 0 < τv < ∞. The above Eqn. is a modified softplus
function, with an augmented parameter a, which controls boththe steepness of the function and the initial bias (y-intercept) of
τv when ηvs = 0. Finally, we scale this to an interval between 0
and 1, giving the final equation for the weight of the violation.
wd = 1 − e−|τv |Figure 4: Attack and Factor Mapping
C. Trust Scoring Model
Note that comparison of packet exchanges with ACL has
only three mutually exclusive outcomes, viz., matching, violation, and uncertain interaction. Notice that access violation
diversity and volume of uncertainty are not mutually exclusive
to violations and uncertain, so we ignore them for now. Basedon the evidence and the past evidence (if available), it is wellknown that the posterior probability of observing a matching,(9)

Thus the combined disbelief mass wd .d(i) . The product indicates heightened suspicion that cyber attack is more serious, if
the surface is larger.
Embedding Cumulative Uncertain Volume: The intuition
behind the design of the weighing function of the raw, uncertain
probability mass is that the suspicion increases as more numberof uncertain interactions emerge. However, up to a certain
number of uncertain interactions should be discounted.
wu =1(1 + Ab .e−Bb µu )1/ν

(10)

1

0.8

wu

0.9

Wd

D. Parameter Learning

Stationary phase

1

0.95

0.85

0.6
Exponential phase

0.8

0.4

0.75

0.2
Lag phase

0

0.7
0

5

10

15

0

Number of Unique Outgoing IPs(a) Disbelief Weight

20 40 60 80 100 120 140 160
Cumulative Uncertain Volume(b) Uncertainty Weight

Figure 5: Functional Forms of wd and wu
where Ab > 0 is the initial bias, 0 < Bb < 1 is the growth rate
parameter, 0 < ν < 1 is the displacement parameter. The lagphase in wu discounts the effect of the u, if the total cumulative
volume in the current frame is low indicating a benign scenario.
The parameter selection process is discussed later.
Expected Belief Score We envision trust score is a ‘complement of total disbelief,’ which includes the weighted violation
and weighted uncertainty masses that should contribute todisbelief. This is mathematically represented as the following:
T R(i) = 1 − wd .d − wu .u(11)

Plugging in wd , d, wu , u into Eqn. 11, we get T Ri . Now weknow that in logistic regression, the response variable is linked
to the independent variable via a non-gaussian distribution andtherefore needs a link function. The typical link function fora binary response variable (trusted or not trusted). Typically,
when the response is a binary, the following logit link function
is an appropriate link function that is given by:E(i)

T R(i)= log
1 − T R(i)!
(12)

The Eqn. 12, facilitates trust scores that are linearly separable by a threshold that helps in classification between trusted
or non-trusted devices. The T R(i) is in the interval between+∞ and −∞ that is scaled to the final trust score using 13.
The final trust score F Ri is scaled from the real value planeto an interval between [-1,+1] by the following equation, tomaintain convention of trust metrics representation:

F R(i) =

!

i

−|E
|


+ 1−e
,







!
i

− 1 − e−|E | ,









0,

if E (i) > 0

if E (i) < 0
if E

(i)

(13)

=0

The supervised approach is feasible if there is the availabilityof labeled datasets of attacks and no attacks. In such cases, thetraining set and cross-validation sets can be used to observe
the difference in trust scores of the two classes. The crossvalidation set includes a set of attack samples as well.

For optimal parameter selection of the trust model, one needs
to decide on an appropriate loss/error function. In this case,our loss function e is the square difference of the sum ofcompromised device trust scores and the sum trust scores ofhonest device set, which will improve the classification. The
goal is to maximize
the e which defined as:P(i)
P
F R(i) 2
benign F R− attack
(14)
e=
H
M
s.t.

Ab > 0;0 < Bb < 1;

0 < ν < 1;a>0

where H and M are numbers of devices used in the crossvalidation process from the benign and attack sets, in our case,
H and M are equal since we have for each device an instance ofthe benign in the training and instance of the attack in the crossvalidation set. The solution of Eqn. 14, can be done throughtwo alternatives: (a) Grid Search Approach (b) A Gradient
Descent based Approach. A gradient descent approach is morecomputationally efficient for finding the optimal parameterswhen the number of parameters is large, and the search spacein each parameter is huge.
However, for the gradient descent approach to be applicable,
the error/loss function needs to be convex, which is difficult
to guarantee. In our problem, the number of parameters is less(i.e., 4), and two out of them have a limited search space.
Hence, for simplicity, we use a brute force grid search method
to find the parameter values that maximize the error function.
Thus, we get an approximate optimal parameter selection.
Our definition can be easily extended to gradient descent by
taking a negative logarithm of the above error function (whichis concave). However, the resulting approximate convex function may need further processing to ensure the differentiability
and existence of global minima. For this work, we have ignored
the gradient descent based approach because the scale of our
optimization problem has been made drastically smaller than
the traditional ML techniques (via the set of unified factors),
which have a large parameter set.
After the optimal parameters have been identified, we map
the trust scores for a device for the benign and a small portionof the attacked dataset (cross-validation set). We then use an
SVM to find the optimal separation between these labels oftrust scores for all devices belonging to the UNSW dataset.
The learned threshold Γ serves as a classifier in the test set.
V. E XPERIMENTAL R ESULTS
Here we present the experimental results of our scoringmodel. First, we provide a dataset description followed by thetrust scoring observations for each device.
A. Dataset Description
For validating our model, we use devices from two different
datasets: (1) UNSW Smart Home IoT dataset [10] and the (2)CTU Apostemat IoT-23 dataset [22].

Table I: Mapping IoT devices with attacks
Attack types
Hide& Seek
Muhstik
Torri
SNMP
SSDP
TCP SYN (R)
Smurf
TCP SYN (D)
Fraggle
DDoS

Echo
Hue
S.Camera
UNSW UNSW UNSW

iHome Somfy
UNSW CTU

Echo
CTU
X

Hue
CTU
X

X
X
X
X
X
X
X
X

X

X
X
X
X
X

X

B. Experimental Set Up
We use Wireshark to parse the raw .pcap traffic files into
CSV files and partition them to 10, 2, and 3 days of training,cross-validation, and testing sets. We create the ACL table flow
rules based on MUD profiles. In this paper, we calculate all
factors and features based on packets per second that we derivefrom the data as well as the flow directions. More details on
this can be found [10]. However, how we interpret the MUD for
the ACL and factor mapping is done differently than [10], as
explained earlier, which explains better accuracy in our method.
In all the figures, we show a continuous evolution of trust
by retrofitting the parameters across the whole duration of thedataset, to give a sense of how the real-time evolution of trust
values happen as soon as there is some incidence of attack.
C. UNSW Dataset Results
Figs. 6a, 6b, 6c, 6d respectively correspond to results fromthe UNSW dataset, that shows the evolution of trust values for
Amazon Echo, Phillips Hue Bulb, iHome Smart Plug, Samsung
Smart Camera IoT devices. In each of these figures, both the instantaneous raw trust values per time window F R(i) (T ) (dotted

1

1

Philps Hue FR
Philps Hue CWMA

Amazon Echo CWMA

0.8

Attack Begin

Amazon Echo FR

Attacked Days
Attack statrs

0.4

Ttust Value

Ttust Value

0.6

0.2
0
-0.2

Attacked Days

0.5

0

No Attacked Days

No Attacked Days

-0.4
-0.6

0

50

100

150

200

250

-0.5

300

0

50

100

Time Interval (Hour)(a) Amazon Echo

250

300

(b) Philips Hue Bulb
Samsung Camera CTU CWMA
Samsung Camera FR CWMA

0.8

Attack Starts

Attacked
Days

0
Not Attacked Days

Ttust Value

0.6
Attacked Days

Attack Starts

0.4
0.2
0

-0.5

No Attacked Days

-0.2
-1

200

1

iHome CWMA
iHome FR

0.5

150Time Interval (Hour)1

Ttust Value

The UNSW dataset contains a set of IoT and non-IoT devices and also MUD profiles. We select benign data of 10 days
and attacked data of 5 days from four IoT devices (Amazon
Echo, Phillips Hue Bulb, iHome Smart Plug, Samsung Camera)
for showing performance. Our device selection is based on
the attacked devices mentioned in previous work on [10] tocompare performance. The attack dataset had contained: (i)direct attack (viz., TCP SYN (referred to as TCP SYN (D)in the table), and Fraggle) (ii) reflection attack (viz., SNMP,
SSDP, DDoS, TCP SYN (referred as TCP SYN (R) in thetable) Samsung Smart Camera, and iHome Plug. Out of thefive days, two days were used as a cross-validation set, andthe rest of the three days was our testing set.
We also used labeled benign and attacked database for real
network traffic obtained from CTU Avast [22]. We used thesecond dataset to prove the generality of our framework. We
chose two devices Somfy Smart Door Lock and Amazon Echo,that contain reflective DDoS attacks through malwares; Torri,
Hide and Seek, and Muhstik. In Table I we present a mapping
showing the implemented attacks launched against IoT devices
in the labs of both UNSW and CTU datasets.

-0.4
0

50

100

150

200

Time Interval (Hour)(c) iHome Smart Plug

250

0

50

100

150

200

250

300

Time Interval (Hour)(d) Samsung Smart Camera

Figure 6: UNSW Dataset: Trust Values over Timeblue lines) and the cumulative weighted moving average overthe instantaneous trust values(solid orange lines) are shown.
Additionally, each result has two regions; no attack days andattack days. Our three days of the testing set corresponds to theattacked days. To give a sense of how quickly our framework
responds to the incidence of attacks, we created an augmented
dataset with the ten days of benign set appended just before thethree days of the test set (containing attacks). We then applied
our model with the learned parameter. Below we describe thespecifics of observations for each device in the UNSW dataset.
1) Amazon Echo: Amazon Echo device from UNSW contains Fraggle and ARP spoof attacks, as reported by [10].
Fig. 6a, shows that our framework produces reduced trust
values in the attacked dataset compared to the benign dataset,prove that the FR value reflects the attack behavior.
2) UNSW Philips Hue Bulb: The Phillips Hue Bulb IoT
device from UNSW contains attacks such as SSDP and SNMP
reflection, Smurf, TCP SYN flood as reported by [10].
Fig. 6b, shows that trust values drop after the attacked dataset
starts performing malicious activity. Here the attack volume
is targeted to those within the cloud domain of the provider,and the attack volume is lower. Therefore the drop in the trust
value is not as strong as in Amazon Echo. The start and stop
times of each attack type are not labeled in the dataset, which
proves that our method need not know such attack specifics
for detection.
3) UNSW iHome Smart Plug: The iHome Smart Plug IoT
device from UNSW, contain a DDoS attack launched after an
ARP poisoning exploit [10]. Fig. 6c clearly shows the reductionin the trust value during the attack days, although the time ittakes to start decreasing is much higher than the other devices.
This is because the attack volume is at times lower than the
benign total volume, as revealed from the data traces.
4) UNSW Samsung Smart Camera: The Samsung Smart
Camera IoT device from UNSW contains attacks such as TCP
SYN, Fraggle, SMURF etc. and reported by [10]. Congruent
to previous observations Fig. 6d, the progression of decrease1

1
Philps Hue CTU CWMA
Philps Hue CTU FR

AttackedDays

CTU AmazonEcho CWMA
Attack Starts

AttackedDays

0.5

CTU AmazonEcho FR

Ttust Value

Trust Value

0.5

0Attack starts

0

ACKNOWLEDGMENT

No Attacked Days

-0.5

-0.5
No Attacked Days

-1

0

10

20

30

40

50

60

70

-1

80

0

10

20

Time Interval (Hour)(a) Amazon Echo CTU

40

50

60

70

80

(b) Philips Hue Bulb CTU
1

CTU Hue FR
CTU Hue CWMA

AttackDays

0.8

Trust Value FR

0.8

Attack Starts

Ttust Value

30

Time Interval (Hour)

1

0.6
0.4
0.2
0

0.6
0.4

No Attack

0.2
0

Attacked

-0.2
-0.4
-0.6

No Attack Days

-0.8

-0.2

0

10

20

30

40

50

60

70

Time Interval (Hour)(c) Somfy Smart Door Lock80

in a smart home gateway. Through this work, we showed that it
is possible to move towards the unified treatment of detecting
cyber attacks on smart home IoT devices.

-1
Hue UNSW

iHome UNSW

Echo UNSW

Somfy CTU S.Camera UNSWHue CTU

Echo CTU

IoT Devices from UNSW and CTU(d) Steady State Trust Values

Figure 7: CTU Dataset: trust values overtime
in trust values is rapid after the attack days start showing that
our method can detect the attack behavior.
D. Proving Performance Generality over CTU dataset
The CTU dataset contains 69 hours of benign data for all
devices and 4 to 7 hours of attacked data depending on thedevice type. The attacks belonged to custom malware campaigns such as Hide Seek, Torri, and Muhstik, and the device
mapping with the malware are shown in Table I. Here there isno cross-validation; we apply our model and parameters fromthe UNSW dataset to evaluate the generality of the method.
1) Time Evolving Trust Values: Fig. 7a, shows the drop intrust values for an amazon echo device from the CTU datasetwith a Hide and Seek attack, within an hour of the start of an
attack. The Fig. 7b shows similar observations for a Phillips
Hue bulb containing Muhstik malware attack.
Fig. 7c, shows a new IoT device type not found in the
UNSW dataset. However, our model still detects attacks on thisdevice, which did not feature in either the training or parameterselection process. We can observe from Fig. 7c that regardlessof this, our framework is still able to detect this attack, although
the time to detection is larger compared to the other devices.
2) Steady State Trust Values: The Fig. 7d, shows a steadystate trust value difference between the no attacked days andattacked days that compares different device final trust value
at the end of the benign and the attacked test set and how far
it is from the threshold Γ = 0.02 obtained by SVM over the
cross-validation set. As we can see, although the trust values
during attack stages vary across devices, all of them have trust
values below the learned threshold when their network traffic
flow data was captured from the attacked dataset.
C ONCLUSION AND F UTURE W ORK
Vulnerable IoT devices increase the risks of attacking smart
homes and unauthorized leakage. We believe that security andprivacy services in IoT systems can be optimized by our fog
trust scoring model deployed as a part of the FIoT middlewareThis work is partially supported by NSF grants SATC2030611 and OAC-2017289.
R EFERENCES[1] R. Xu, Q. Zeng, L. Zhu, H. Chi, X. Du and M. Guizani, ”Privacy Leakage in
Smart Homes and Its Mitigation: IFTTT as a Case Study,” IEEE Access, Vol. 7,
pp. 63457-63471, 2019.
[2] “Security: The Vital Element Of The Internet Of Things,” CISCO, Mar. 2015.
https://www.cisco.com/c/dam/en us/solutions/trends/iot/vital-element.pdf[3] Pymnts, “Wyze Smart Device Co Leaks 2.4M Customers’ Data,” PYMNTS.com,
30-Dec-2019. [Online]. Available: https://www.pymnts.com/news/security-andrisk/2019/wyze-smart-device-co-leaks-2-4m-customers-data/.
[4] A. Sivanathan, H. Gharakheili, F. Loi, A. Radford, C. Wijenayake, A. Vishwanathand V. Sivaraman, ”Classifying IoT Devices in Smart Environments Using Network
Traffic Characteristics”, IEEE Trans. on Mobile Computing, Aug, 2019.
[5] Y. Amar, H. Haddadi, R. Mortier, A. Brown, J. Colley, A. Crabtree, “An Analysis
of Home IoT Network Traffic and Behaviour” arXiv:1803.05368, 2018.
[6] D. Lo, C. Cho, C. Tan, R. Li, “Identifying unique devices through wirelessfingerprinting” ACM WiSec, pp. 46-55, 2008.
[7] M. Lyu, D. Sherratt, A. Sivanathan, H. Gharakheili, A. Radford, V. Sivaraman.
“Quantifying the reflective DDoS attack capability of household IoT devices” ACM
WiSec, pp. 46–51, 2017.
[8] M. Nobakht, C. Russell, W. Hu and A. Seneviratne, “IoT-NetSec: Policy-BasedIoT Network Security Using OpenFlow” IEEE PerCom Workshops, pp. 955-960,
2019.
[9] C. Bradley, S. El-Tawab and M. H. Heydari, “Security analysis of an IoT systemused for indoor localization in healthcare facilities,” 2018 Systems and Information
Engineering Design Symposium (SIEDS), Charlottesville, VA, 2018, pp. 147-152.
[10] A. Hamza, H. Habibi Gharakheili, T. Benson, V. Sivaraman, “Detecting VolumetricAttacks on IoT Devices via SDN-Based Monitoring of MUD Activity”, ACM SOSR,
USA, Apr 2019.
[11] O. Alrawi, C. Lever, M. Antonakakis and F. Monrose, “SoK: Security Evaluation ofHome-Based IoT Deployments,” IEEE Symposium on Security and Privacy (SP),pp. 1362-1380, 2019.
[12] S. Keoh, S. Kumar, and H. Tschofenig, “Securing the internet of things: A
standardization perspective,”IEEE Internet of Things Journal, Vol. 1, no. 3, pp.
265-275, June 2014.
[13] A. Sivanathan, D. Sherratt, H. H. Gharakheili, A. Radford, C. Wijenayake, A.
Vishwanath, V. Sivaraman, “Characterizing and classifying IoT traffic in smart cities
and campuses,” IEEE INFOCOM Workshops, pp. 559-564, 2017.
[14] D. Kumar, R. Paccagnella, P. Murley, E. Hennenfent, J. Mason, A. Bates, and M.
Bailey, “Skill squatting attacks on amazon Alexa,” USENIX Security Symposium,
pp. 33–47, 2018.
[15] [Online] Available at: https://www.cloudflare.com/learning/ddos/what-is-a-ddosattack/ [Accessed 24 February 2020].
[16] L. Desmond, C. Yuan, T. Pheng, R. Lee, “Identifying unique devices throughwireless fingerprinting”, ACM WiSec, New York, NY, USA, pp. 46-55, 2008.
[17] V. Sivaraman, H. H. Gharakheili, A. Vishwanath, R. Boreli, and O. Mehani,“Network-Level Security and Privacy Control for Smart- Home IoT Devices,” IEEE
WiMoB Workshops (IoT-CT), Oct 2015.
[18] T. Yu, V. Sekar, S. Sheshan, Y. Agarwal, and C. Xu, “Handling a Trillion (Unfixable)
Flaws on a Billion Devices: Rethinking Network Security for the Internet-ofThings,” in ACM HotNets, Nov 2015.
[19] V. Sivaraman, H. H. Gharakheili, A. Vishwanath, R. Boreli and O. Mehani,”Network-level security and privacy control for smart-home IoT devices,” IEEE
WiMob pp. 163-167, 2015.
[20] S. Bhattacharjee, M. Chatterjee, ”Trust based channel preference in cognitive radio
networks under collaborative selfish attacks,” IEEE PIMRC, pp. 1502-1507, 2014.
[21] A. Jøsang, R. Ismail, C. Boyd, A survey of trust and reputation systems for online
service provision, Decision Support Systems, Vol. 43(2), pp. 618-644, 2007.
[22] A. Parmisano, S. Garcia, M. Erquiaga, ’IoT-23 Dataset: A labeled dataset of
Malware and Benign IoT Traffic.’, Avast-AIC laboratory, Stratosphere IPS, Czech
Technical University (CTU), Prague, Czech Republic, 2019.
[23] “NAT Traversal for IP Video Surveillance Application,” Mistral Solutions. [Online]. Available: https://www.mistralsolutions.com/articles/nat-traversal-ip-videosurveillance-application/.
[24] [Online]. Available: https://infosniper.net/.