This article has been accepted for publication in a future issue of this journal, but has not been

fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2019.2941767, IEEE Internet of
Things Journal
1

SoftAuthZ: A Context-aware, Behaviour-based

Authorization Framework for Home IoT
Nirnay Ghosh, Saket Chandra, Vinay Sachidananda, and Yuval Elovici

Abstract—The smart home is one of the most prominent HomeKit3 , and Google’s Android Things4 . These platforms are
applications in the paradigm of the Internet of Things (IoT). energy efficient, connect heterogeneous devices and protocols,
While, it has added a level of comfort and convenience to our allows remote control and actuation, and also support third-
everyday life, at the same time, it brings a unique security
challenge of mitigating insider threats, posed by legitimate users. party application development.
Such threats primarily arise due to sharing of IoT devices and Although home IoT solutions have added a level of con-
the presence of complex social and trust relationships among venience and comfort to our everyday life, the world of
the users. The state-of-the-art home IoT platforms manage IoT has witnessed many sophisticated attacks over the years
access control by deploying various multi-factor authentication
due to devices insecure software-engineering practices [2],
mechanisms. Nevertheless, such hard-security measures are in-
adequate to thwart insider threats, and there is a growing need unexpected information flows [12] and inherent difficulties
to integrate user behaviour and environmental contexts to make of patching networked devices [13]. Thus, security is still
intelligent authorization decisions. In this paper, we propose a one of the major concerns for widespread adoption of home
novel context-sensitive and behaviour-based security framework, IoT solutions, which has been further established by a recent
called SoftAuthZ, that incorporates soft-security mechanisms,
release of 184 requirements by the Internet of Things Ar-
such as belief, confidence, etc., to support authorization decisions.
Our framework integrates multiple IoT environment-specific chitecture (IoT-A), where 52 requirements (roughly 30%) are
attributes, such as environmental context, nature of the device, relevant to security [10]. Thus, if glitches in home IoT security
requested capabilities (actions), users’ trust levels concerning implementation exist, the adversary can not only leverage them
the home environment, and variability in device access requests to compromise or disable the connected devices but can also
into a linear regression model, and computes confidence related
affect the physical safety and security of the home.
to access requests. Such confidence scores can be used by the
home IoT platform to make authorization decisions. Extensive Recently, researchers have discovered over-privileging of
analysis and simulation-based performance evaluation validate the companion smartphone applications and insecure infor-
the efficacy of our framework, demonstrating that it can classify mation flow between the devices and the applications as
users based on their device usages, and also achieve higher rates the two prominent security loopholes in home IoTs [8] [5].
of successful authorization.
Nevertheless, one cannot rule out the threat posed by an
Index Terms—Internet of Things, Smart home, Authorization, ‘insider attack’, which is a malicious attack perpetrated on
Insider threat, Soft security, Unalikeability, Environmental con- a network or computer system by a person with authorized
texts
system access. In [1], the authors discussed such threat and
defined two factors that stimulate it are: (i) a single home IoT
I. I NTRODUCTION device is shared among multiple users and (ii) complicated
social trust relationship exists among the users of a home IoT

I N recent years, the immense proliferation of the Internet

of Things (IoT) has led to the advent of a new paradigm in
home automation known as home IoT. It is one of the promis-
environment. Below we present a use case to motivate the
technical challenges in detecting insider attacks.
a) Motivating Example: The insider attack scenario gets
ing maneuvers of IoT which is making significant penetration depicted by a typical daily life use case, where the owner of
into the consumer market and has the potential to generate a home IoT environment needs to add a guest visiting his/her
a revenue of more than $69.5 million by the end of 20191 . place as one of the users and temporarily give accesses to
Some of the leading home IoT platforms which have emerged some IoT devices, purely based on mutual trust. The user gets
over last few years are Samsung’s SmartThings2 , Apple’s authenticated by the home IoT platform on presenting valid
credentials (e.g., token, PIN, password, etc.), thus enabling
N. Ghosh is with the Department of Computer Science and Technology,
IIEST Shibpur, Howrah 711103, WB, India, e-mail:[email protected]
him/her seamless access to the devices. However, if this user
S. Chandra and V. Sachidananda are with the iTrust Centre for Research turns out to be dishonest and has malicious intentions, s/he
in Cyber Security, Singapore University of Technology and Design (SUTD), can misuse the given accesses and attempt to cause security
Singapore 487372, e-mail: [email protected], [email protected]
Y. Elovici is with the Department of Software and Information Systems
or other operational hazards to the home IoT environment.
Engineering and Cyber-Security Research Center, Ben-Gurion University of Such anomalous behaviour or attack cannot be detected and
the Negev, Israel, email: [email protected] prevented by hard security mechanisms based on traditional
Copyright (c) 2019 IEEE. Personal use of this material is permitted.
However, permission to use this material for any other purposes must be
authentication and authorization, which we explain below.
obtained from the IEEE by sending a request to [email protected].
1 https://www.statista.com/outlook/279/100/smart-home/worldwide 3 https://www.apple.com/ios/home/
2 https://www.smartthings.com/ 4 https://developer.android.com/things

2327-4662 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2019.2941767, IEEE Internet of
Things Journal
2

Remote back-end clouds centrally manage the security in A. Contributions of this Paper
the state-of-the-art home IoT platforms. Home IoTs deploy As depicted in the motivating example, preventing insider
variants of two-factor authentication to enforce secure access attack is a non-trivial challenge as it needs tracking of request
of devices. We use the terminologies used in Samsung’s patterns of the users and eventually forecast future accesses
SmartThings to illustrate the two-factor mechanism: based on a behaviour-related metric. Traditionally, secured
access to a shared system is enforced by authentication and
• First factor: Home IoT owner uses a companion
authorization mechanisms. Authentication ensures validation
smartphone-based application (may or may not be third-
of the identity of the requester, while authorization guarantees
party-developed) to assign capabilities (privileges) on
legitimate access to the requested resource. Mitigation of
his/her device(s) for a user (requester) to whom s/he
insider threat does not need to consider authentication, as
intends to give access. Next, s/he sends the privilege
the perpetrator is an insider whose identity is already verified
information (first factor) to an authorization module of
and validated. In fact, mitigation measure is concerned with
the security server hosted in the cloud. On the other hand,
restricting anomalous/malicious usage of legitimate access
the server’s authentication module employs a capability-
rights using circumstantial evidence such as variability in
based access control (CapBAC) to issue token to the
past requests, environmental situation under which the request
requester on behalf of the device owner [15] [16]. The
is made, and so on. Therefore, the scope of this work is
token contains a multitude of information such as times-
to propose a novel authorization framework for home IoT,
tamp, identity, and access right information of potential
called SoftAuthZ, which is context-sensitive, behaviour-based
requester, a concept similar to OAuth 2.05 protocol.
and uses soft security mechanism (e.g., belief, confidence)
• Second factor: At the time of the actual device access
to thwart insider attacks. Our framework is generic, can
request, if the requester possesses a valid token, home
be integrated with existing token-based authorization as an
IoT platform further authenticates him/her using the same
additional security layer, and involves human interventions
smartphone app. In this step, the mode of authentication
only in setting the model parameters to adapt the home IoT
may be any one of password, or PIN, or fingerprint
platform’s risk tolerance attitude.
biometrics, or any other customized approach [1] [17],
We highlight the major contributions of the paper as follows:
constituting the second factor.
1) We model expected belief on a device access request
As evident, existing token-based authentication and autho- as a response variable in a weighted regression function
rization approach cannot prevent insider attacks as it neither consisting of two explanatory variables: belief on user’s
binds a requester to his/her past purported behaviours or past request patterns (weighed by his/her trust level)
actions, nor it predicts how the requester will behave between and the belief on context of the request (weighed by the
the time the token was issued and used. Authorization is done requested device’s accessibility).
strictly on the basis of the identity of the requester, validity 2) Next, we transform the expected belief to a measure
of the token issued for a particular session, and the predefined that captures the confidence on the request. The trans-
access policy. Either the requester’s token is accepted and the formation is achieved using the logit link function that
requested capabilities are granted, or the token is rejected and facilitates authorization decision making in the presence
the access is denied. Thus, there is no provision to determine of both normal and deceptive behaviours under varying
if any requester with valid a token and legitimate identity will contexts.
cause any security breach with the devices. It is imperative 3) We verified that the proposed approach successfully
to look beyond static policy-driven token-based access control classifies normal and anomalous behaviours, prevent
mechanisms to mitigate threats from malicious insiders. authorization of requests from anomalous users, and
On the contrary, addressing insider threat needs to consider authorizes more than 80% requests from normal users
the pervasive human behaviour, the environmental ‘contexts’ through simulation-based experiments on randomly syn-
under which the potential attack takes place, the extent of thesized access requests.
damage the given accesses can incur, and their interrelations. The rest of the paper is organized as follows. Section II
Hence, there is a need to incorporate soft security mechanisms reviews the existing works on authorization in home IoT
based on trust, risk, belief, confidence, etc., into the exist- environment and presents their limitations as far as addressing
ing home IoT security framework. The use of soft security insider attacks are concerned. Section III explains the system
mechanism renders adaptive feature to security models and and threat models of the proposed framework. In section IV,
makes them flexible, and its usage has already been seen we present the functional descriptions of different modules of
in a few works on IoT. In the TACIoT [14] model, access the SoftAuthZ framework for quantification of confidence on
control is assisted by trust values calculated upon factors like access requests in home IoT environment. Section V explains
quality of service (QoS), reputation and social relationships, the simulation environment and presents the experimental
and Tyche [9], a risk-based permission model, is developed for results. Finally, conclusions are drawn in Section VI.
home automation system.
II. R ELATED W ORKS
In this section, we review the authorization mechanisms
5 https://oauth.net/2/ currently implemented in commercial home IoT platforms, as

2327-4662 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2019.2941767, IEEE Internet of
Things Journal
3

well as the ones proposed by the research community. in participants desired access-control policies for different
capabilities within a single device, as well as based on
A. Proprietary/Commercial Home IoT Platforms who is using that capability. They identified capability, user
type, and context as the likely candidates to be included
As stated above, presently, the three most widely adopted for making an authorization decision. The SmartAuth frame-
proprietary/commercial home IoT solutions are Samsung’s work [5] performed consistency checks for the SmartThings
SmartThings, Apple’s HomeKit, and Google’s Android third-party apps in terms of their specified functionalities and
Things. The authorization mechanisms implemented in these the operations they perform. Such checks enable the user to
commercial solutions are as follows. generate and enforce security policies, thus ensuring secure
SmartThings: The SmartThings ecosystem consists of both cross-device, context-based, and automatic operations.
proprietary and third-party applications (SmartApps), and the Fernandes et al. [8] performed an in-depth static source code
IoT device handlers (SmartDevices). The authorization is analysis to detect problems of over-privileging in SmartThings
based on a capability model, where a capability on a device apps, which is mostly due to the coarse-grained nature of the
includes the commands (actions to be performed) and its capability model. As a result, the apps gain full access to
associated attributes (state/properties). The SmartApps, written devices even if they require limited accesses. Furthermore, the
in Groovy6 programming language, run either on cloud back- asynchronous communication between the SmartApps and the
end or on a controller device, called SmartHub. They need to devices is not protected, leading to the disclosure of sensitive
obtain permissions from the home IoT platform before using information (e.g., lock code). In [9], the authors performed
the capabilities offered by the SmartDevices [6]. The Smart- a user study to observe risk-asymmetry in device operations,
Things environment uses Kohsuke sandboxing technique7 to supported by the SmartThings platform. The over-privileged
isolate untrusted codes and allows only predefined method apps, getting access to mixed-risk operations, increases the
calls. Third-party developers are prevented from creating their potential attack surface many-folds. Thus, a risk-based per-
own classes or bundling external libraries, and once they mission model, called Tyche, has been proposed to group
publish a SmartApp or a SmartDevice handler, a private, operations of similar risk and enable users to decide if a
isolated datastore is assigned. particular app can access their devices.
HomeKit: HomeKit has recently opened its platform for inte- In [10], Lee et al. analyzed the SmartThings framework
gration of third-party applications. The apps have to explicitly to discover over-privileging (due to coarse-grained access
obtain user’s permissions to get access to their home IoT control) and a higher likelihood of Denial-of-Service attack
devices. It also uses the sandboxing technique to ensure that (due to lack of resource isolation). The paper proposed a
an app can access its own data only, stored in a unique home functionality-centric approach to manage IoT devices, called
directory, hosted on the platform. This directory is assigned FACT, which has two design goals, namely, to enforce the
randomly during the installation process of the application [6]. principle of least privilege and isolate the device functionality
Moreover, iOS system data is isolated from third-party apps, to enhance availability. ContexIoT [11], a context-based per-
and users have no privilege to modify them. Address Space mission system, was proposed to restore contextual integrity
Layout Randomization (ASLR) technique [7] is applied to in appified IoT platforms. The context information used here
prevent buffer overflow memory-based attacks. is at the inter-procedure control and data flow level and is
Android Things: Formerly known as Weave and Brillo, this obtained by identifying the fine-grained context for sensitive
framework uses a combination of Linux-based access control actions. Furthermore, it also provides an automatic app patch-
module, called SELinux (Secured Enhanced Linux), and sand- ing mechanism to convert unmodified commodity SmartApps
boxing technique to implement its authorization mechanism. to ContexIoT compatible SmartApps. Thus, it is clear from
The SELinux module enables the owner of an IoT device to the above literature review that no work in the literature has
assign different levels of access rights (read, write, execute) for focused on mitigating threats due to insider attacks in home
each user or a group of user. Again, as this platform is Linux- IoT environment.
based, sandboxing technique is applied with regards to UID In [18], authors propose an extension of the role-based
(User Id) and GID (Group Id) [6]. It ensures the separation of access control (RBAC) model by introducing contextual con-
information based on confidentiality and integrity requirements straints collected from the environment of the physical envi-
for each profile. ronment to make authorization decisions. The functionalities
It is evident from the above discussion that the commercial of IoT devices are modeled as web services which become
home IoT platforms have not yet focused on addressing the the target of the request. However, the authors have not
issues related to insider attacks. elaborated either the mapping of physical objects into one
or more web services or the mechanism by which contextual
B. Research Community information will be collected in real-time from the physical
environment. Jindou et al. [19] adopted a web of things (WoT)
In [1], the authors focused on re-envisioning home IoT
by the integration of RBAC with social network services
access control due to its multi-user device-sharing nature.
(SNS) such as Facebook. It enables owners to leverage existing
Through a survey, it was discovered that there are differences
user-profiles and social links to design customized access
6 http://groovy-lang.org/ policies for secure and trusted sharing of their devices. While
7 http://groovy-sandbox.kohsuke.org/ this integration characterizes high usability and user-driven

2327-4662 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2019.2941767, IEEE Internet of
Things Journal
4

features, it is tightly coupled with SNS and assumes its service

provider to be the default trusted third-party. In [20], the
authors propose a centralized access control decision facility
(ADF) to facilitate the RBAC policy decision of whether to
grant or reject the authorization requests for accessing WoT
resources. The ADF makes use of the reference monitor and
role parameterization to propose a conceptual structure of
RBAC/WoT access control domains and addresses the role
proliferation problem. However, no mechanism is proposed to
make RBAC supported by constrained devices.
Use of attribute-based access control (ABAC) in IoT has
been found in [21]. The authors propose an ABAC-based au-
thorization method for the perception layer of IoT. Requesting
the data based on user attribute certificates ensures fine-grained
access control. However, it requires complex management and
impedes its deployment to constrained devices. Consequently,
they only provide theoretical results of the proposed model.
As evident, RBAC and ABAC have technical limitations as
far as resource-limited and pervasive nature of IoT systems
is concerned. RBAC-based authorization is not suitable for
dynamic role assignment requirements of IoT access control
viz., sensor inputs, time of day, type and state of a de-
Fig. 1: System Model
vice, device-to-device connections, device-to-Internet access
and so on. XACML-based ABAC is highly complex and
not suitable for dynamic IoT-like environment as the policy (step 1 in Fig. 1).
needs to specify the nature of the device and the data being IoT Device: An IoT device dji is the j th item of ith device
accessed. Thus, hard security mechanisms based on traditional type (explained below). It is an equipment that can sense the
authentication and access control will fail to prevent misuse of physical environment, collect, store, and share the relevant data
capabilities (privileges) assigned to a legitimate but malicious with the other devices or a remote server. It is controlled,
insider. The limitations in the state-of-the-art motivate us configured, and shared among other users by its owner using
to propose a novel authorization framework based on soft the user-friendly interfaces of a smartphone-based companion
security mechanisms, such as trust, belief, etc., which makes app. We classify the devices in a home IoT into three or-
access control decisions by integrating requester’s past request dered classes reflecting their general accessibility to the users:
history, current contextual factors of the request, impact of General purpose  Controller  Safety and Security. The
misusing the requested capability, age of the requester, and actual value of device accessibility (δ) is subjective, but in
his trust relationship to the home IoT environment. this work we assume δgp = 3, δcon = 2, and δss = 1 for
General purpose, Controller, and Safety and Security device
types, respectively.
III. S YSTEM AND T HREAT M ODELS
In general, δ is high if the device is accessible to the
In this section, we present the system and threat models of majority of the users and changing its controls, configurations,
the proposed home IoT authorization framework. or settings is not a threat to the security of the home IoT
environment. Conversely, low δ ensures that the device access
A. System Model is restricted and its configuration or settings are not expected
Consider a home environment which consists of multiple to be changed by any user. Below we present the instances of
smart IoT devices viz., lights, plugs, lock, cameras, thermostat, devices which belong to these classes:
TV, cooking appliances, and so on (refer to Fig. 1). These 1) General purpose: This class includes mostly the reg-
devices are connected to the Internet via a proprietary back- ular use devices (viz., light, plug, thermostat, washing
end cloud platform that runs third-party applications. These machine, etc.), entertainment devices (viz., smart TV,
applications invoke device handlers to perform remote opera- music player, etc.), cooking devices (viz., cooker, smart
tions on the devices. The users of the home environment use a refrigerator, oven, microwave, etc.), and outdoor devices
companion app running on their smartphones for local control (viz., sprinkler, mower, etc.).
and configuration. These applications facilitate automation of 2) Controller: This class consists of the devices which
the home environment. are capable of sending control signals back and forth
Following are the important components of our system between the applications hosted on the cloud back-end
model: and other devices in the home IoT. Two most prominent
Owner: An owner O is a user who owns the devices in the examples are voice assistants and hub devices.
home IoT environment. For other users of the home IoT, the 3) Safety and Security: As the name suggests, this class
owner can set the scope of capabilities on different devices contains those devices which are used for surveillance

2327-4662 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2019.2941767, IEEE Internet of
Things Journal
5

and security purpose. Examples include lock, camera, the home IoT environment, the platform tends to have
doorbell, motion sensors, etc. lower confidence as the risk (of potential device misuse)
Capabilities: A capability or permission cki is defined as an perception magnifies.
action k (switching ON/OFF) that can be performed on a • Time of request (T ): It denotes the time at which the

particular device type i (general-purpose devices such as smart request is made. We consider two time windows for
bulb, thermostat, etc.). Summarizing the recent survey done device accesses, such as, conventional (6am to midnight)
on home IoT users [1], we consider the following capabilities and odd (otherwise). The belief weights assigned to the
compatible with our custom device types: time windows are T = 1 and T = 0, respectively.
• Availability of users around the requester (U ): Insider
• General purpose: ON/OFF, ADD/DELETE RULE
attacks in the home environment can take place in the
• Controller: ON/OFF, ADD/DELETE USER,
presence or absence of other users. Although subversion
ADD/DELETE DEVICE
of home IoT environment can take place in the presence
• Safety and Security: ON/OFF, ADD/DELETE RULE,
of users, however, in their complete absence, the plat-
VIEW LOG/STATE, DELETE LOG.
form experiences less confidence in actual usage of the
Requester: A requester rl is any user of the home IoT environ- requested capability. Thus, we assign weights U = 1 and
ment. We interchangeably use the terms ‘requester’ and ‘user’ U = 0, depending on if people are around or not.
in this paper. The user needs to obtain an access token from • Requester’s age (A): As the home IoT environment may
the remote cloud back-end server to initiate device access (step consist of users from multiple age groups, we classify
2). Furthermore, rl needs to attach this token with the request them into three ordered categories: Adult  Teenage
to access device dji , as allowed by owner O (step 4). The  Child. Like previously, we assign belief weights of
requester rl can access device if the server grants the access A = 3, A = 2, and A = 1 corresponding to an adult,
token, validates the request concerning the policies designed a teenager, and a child requester, respectively. Thus, a
by the owner, and also finds that the confidence on the request request to access the camera from a child (0-12 years
is above a threshold (step 9). A requesting user is liable to age group) or a teenage member (13-19 years age group)
have a trust level depending on his/her social relationship generates lesser confidence to the platform, than if an
with respect to the home environment. In this work, we adult requests it.
organize requesters into five hierarchical membership classes,
SoftAuthZ Framework: This is the proposed framework which
each having a predefined trust relationship score from the
can be either a part of the home IoT platform or implemented
viewpoint of the home IoT. We assign trust levels (τ ) 1-5
as a separate Web service to reduce the overhead. It can be
to such membership classes which are given as: Owner (5) 
invoked as a service by the authentication and authorization
Spouse (4)  Family (3)  Children (2)  Guest (1). Higher
server at the time of ascertaining confidence score of device
the membership level of the user, the more trusted it is to the
access requests to make the authorization decision (steps 5 and
home IoT platform.
7). The framework obtains various context information about
However, it is not guaranteed that a user belonging to a
the requester from the different trackers hosted in the cloud
higher trust level will never misuse the requested capabilities
platform (step 6b).
on devices. Depending on variability of historical requests,
It is clear that ‘request’ is the central aspect of our system
we classify the users into two profiles: normal and anomalous
model and it essentially constitutes the capability to be per-
(refer to Section III-B for details).
formed against a particular device. We define device request
Authentication and Authorization server: The authentication
(or request) as follows.
and authorization server is managed in the remote cloud
Definition 1: (request). A device request qm is defined as
platform. It enables the owner O to set predefined policies
a tuple hdji , cki i, where dji is device j of type i and cki is the
on device dji (step 1). Moreover, the server is responsible for
k th capability requested on device type i.
granting or denying both access token and access request to
Since the home IoT consists of multiple users with a plethora
the requester (steps 3 and 8).
of shared devices, we assume that while making an access
Context Tracker: The home IoT cloud platform also manages
request, the requester’s identity, his/her trust level, and the
the context tracker. After the platform receives a request, the
contextual factors should also be taken into consideration. We
tracker invokes system calls and location service to collect the
redefine a device access request as follows.
contextual information regarding the requester (step 6a). We
Definition 2: (Access request). An access request am is
used the survey done in [1] to determine the set of contextual
defined as a four-tuple hrlID , τ, X , qm i, where rlID is the
factors (X ) give below:
identity of a requesting user and τ is the requester’s trust level
• Location of the requester (L): Owing to pervasive nature (assigned by the home IoT owner), X is the set of contextual
of IoT devices, a requester can send an access request factors, and qm is the actual request on the device.
from inside the home, or from its premises (e.g., garden,
lawn, terrace, etc.), or outside the home. We classify the
requester’s location into three hierarchical classes: Home B. Threat Model
 Premise  Outside. Further, we assign belief weights We stated earlier that the devices in a home IoT environ-
to these classes as L = 3, L = 2, and L = 1, respectively. ment are shared among a closed group of users and we are
The intuition is if the request is coming from outside concerned with the security threats coming from the insiders,

2327-4662 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2019.2941767, IEEE Internet of
Things Journal
6

who are legitimate users belonging to different trust levels.

Insider attacks to sabotage a home IoT environment’s access
control may be motivated by several complex factors viz.,
curiosity, willful disobedience, envy due to an imbalance
in asymmetric power/rights, malicious intent to do physical
damage of property, and so on [1]. Thus, a potential malicious
requester does not need to launch any sophisticated attacks,
but only needs to acquire adequate access to compromise the
home IoT environment.
Following are the three possible threats posed to the de-
vices by legitimate but malicious requesters: (i) threat on
confidentiality: disclosure of the contents of the device to
unauthorized users, (ii) threats on integrity and availability:
misappropriation or deletion of contents from the device, or
making it unavailable, and (iii) physical threat: weakening the
safety and security best practices to cause physical harm (theft,
burglary, ransacking, etc.) to the home IoT environment.
Threat (i) is similar to the credential theft, which can be ex-
ercised through disclosure of personal data to the unauthorized
agents. Such a threat can be organized even if the perpetrator
has only the VIEW permission. On the contrary, threat (ii) Fig. 2: SoftAuthZ Framework: Modules & Control Flows
is materialized through misuses of ADD/DEL, ON/OFF priv-
ileges, which enable the malicious user to tamper or delete
device data or make the device completely unavailable. Threat and the requester from their identities, requester’s trust level,
(iii) is specific to home IoT environment, and it can be device’s accessibility, and the requested capability.
launched if safety and security devices are tainted. Membership & Trust Repository: This repository contains the
As we are analyzing the threats of potential insider attacks, membership classes and trust levels of the users in the home
it is necessary to track the device usage history of authorized IoT environment.
home IoT users. Among the various attributes that can be Device Repository: In this repository, the devices and their
considered as usage history, we use variability in request corresponding types (viz., Controller, General purpose, Safety
patterns as the metric to determine the likelihood of insider and Security) are maintained.
attacks. We term this as the unalikeability score (0 < µ < 1) Request Logs: It is also a repository from which the SoftAuthZ
of the requester and it gives a measure of diverseness in device framework can retrieve the historical request set specific to a
access requests [22] (details in Section IV-B2). The score can requester. The contents of this repository are imported from
be used to compute the overall confidence on a given access the home IoT platform.
request. Low µ implies that the user does not make different Requester Belief Model: The model computes the belief of the
requests more often and may belong to the normal profile. home IoT platform on a requester based on his/her historical
On the contrary, if µ is high, it means that the requester request (usage) patterns for a particular device type dj . We
more often attempts to access different devices with different quantify usage history in terms of the variability in requests
capabilities and under varying contexts. Such behaviour tends during past interactions.
to anomalous profile as frequent request variability magnifies Damage Evaluator: It consists of a set of impact rules (dis-
the risk perception of potential device misuse. cussed in Section IV-B3) and obtains the likelihood of oc-
currence of a capability for a given device type from the
IV. P ROPOSED S OFTAUTH Z F RAMEWORK home IoT platform. Using these, it estimates the expected
For estimating the confidence associated with a device damage (both in terms of information and physical losses)
access request, we propose the SoftAuthZ framework, which which a potential anomalous requester may cause by misusing
we envision as an additional security layer above the existing the allowed capability on the requested device.
token-based authorization method. Fig. 2 presents a schematic Context Favourability Evaluator: In this module, the contex-
representation and control flow of different modules of the tual factors (viz., time of the request, location of requester,
framework. This section presents a summary of the modules etc.) are integrated into a context favourability metric score.
constituting the proposed framework, and also discuss func- This is done by weighing each context by an ‘importance’
tional descriptions of the major ones. factors (provided by the home IoT platform) and taking their
sum.
Context Belief Model: This model integrates different con-
A. Modules of SoftAuthZ Framework textual information and the expected damage to be caused
Request Handler: This module accepts device access requests by abusing the requested capability to measure home IoT
from the authentication and authorization server (A & A) for platform’s belief on the contextual favorability of the request.
estimating its confidence. It extracts the types of the device Weighted Linear Regression: It computes a weighted sum of

2327-4662 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2019.2941767, IEEE Internet of
Things Journal
7

the beliefs on the requester’s historical request (usage) pattern

(weighed by his/her trust level), and that on the contextual
favorability of the device access request (weighed by device’s
accessibility).
Logit Function: It is used as a link function to transform the
belief value to the corresponding confidence in the interval
[−∞, +∞]. Such mapping enables the home IoT platform to
make authorization decisions.
Scaling Function: It is used to normalize the confidence score (a) Displacement Parameter: C1 (b) Growth Parameter: C2
in the interval [-1, +1].
Fig. 3: Parameters: Inverse Gompertz Function
B. Expected Belief on Device Access Request III-B), then it should negatively affect the platform’s belief.
As given by Definition 2, a device access request contains If s/he persists with making different requests in subsequent
information about the device type requested, the required interactions, then the belief must drop significantly, resulting
capability, the identity and trust level of the requester. Grant- in the revocation of further accesses.
ing access to a shared device involves a certain degree of We use the inverse gompertz function [3] to model the above
uncertainty as the threat of its misuse looms large. Thus, the nature of belief growth on the requester’s usage pattern. The
home IoT platform must develop a notion of belief that the inverse gompertz output non-linearly decreases from its upper
device will not be tainted if the current access request is asymptote to reach the lowest value and is reflective of decay
granted. We intuit that the magnitude of such belief for a given in the belief relationship in any multi-user environment [4].
device access request am potentially depends on two factors Thus, the higher is the unalikeability of subsequent requests
(explanatory variables): (i) the belief on the requester’s device over a given period; faster is the rate in the drop of belief.
usage history in terms of the requests made (bh ), and (ii) the The belief on any requester’s usage history is given as:
belief that the contexts (such as location, time, presence of −C2 ·µ

people in the vicinity, etc.) under which the current access bh = 1 − C0 · e−C1 ·e (2)
request has been made is favourable or not unusual (bx ). where the input µ gives unalikeability score (expressed in
We model the response variable, expected belief (Bam ), as a terms of percentage) generated from previous requests for any
weighted linear regression of the explanatory variables given requester. C0 is the upper asymptote to decide the maximum
by: value belief can attend (for our case C0 = 1), C1 is positive
Bam = τ · (bh ) + δ · (bx ) (1) constant which controls the displacement of maximum belief
Where, τ and δ are the coefficients to the explanatory variables score along the X-axis, and C2 adjusts the decay rate.
and termed as the requester’s trust level and device’s accessi- Fig. 3a illustrates the effect of parameter C1 on the initial
bility, respectively. If any requester with lower trust level is a value of the belief before the latter enters into the exponential
potential perpetrator, and the device s/he has requested is not decay phase. For a fixed decay rate (considered to be C2
of regular access, our model magnifies the threat perception = 0.45), this parameter acts as a discounting factor to the
resulting in low belief measure. This is comprehensible, as maximum belief score. The choice of its value depends upon
guest users (belonging to lower trust level), who are occasional if the home IoT platform is risk-seeking (corresponds to high
visitors to the home IoT environment, are not expected to C1 ) or risk-averse (corresponds to low C1 ).
taint rarely accessible devices (like lock, camera, etc.) under Parameter C2 is the growth parameter which controls the
unusual contexts (like odd hours, no one at home, etc). rate of decay of the belief scores, lower bounded by 0, as
1) Modeling Belief on Requester’s Usage History: The shown in Fig. 3b. We considered C1 = 10 to study the
expected belief in requester’s device usage needs to consider varying effects of the growth parameter. For higher values
the variability in past requests, quantified by the unalikeability of C2 , the belief score drops rapidly with relatively low
score (µ). Intuitively, lesser µ implies that the user is of unalikeability score. For a less-restrictive home IoT platform,
normal profile and it should generate higher belief bh . At the administrator can choose a smaller C2 . Such system
the same time, the home IoT platform should avoid the tolerates a more substantial degree of request variability before
‘cold-start’ problem by allowing the requested access to any the user belief drops significantly.
new but legitimate (access granted by the owner) requester. 2) Computation of the Unalikeability Score: As evident
For the new user, her/her unalikeability score µ is set to 0, from Definition 2, the access requests are of categorical data
which gets updated as new requests are made over time. With type and consists of multiple attributes viz., device type,
each incoming request, the framework computes its degree of capability, and contexts. Each of these attributes again has mul-
variability with the historical request set and uses the latter tiple categories and sub-categories, such as general purpose,
to re-compute the unalikeability score. Thus, the platform controller, and safety and security, under the device type
should tend to trust him/her by believing that s/he will not (refer to Section III-A). Owing to the categorical nature of
attempt to subvert the home IoT environment. However, during access requests, variability among them needs to focus on
subsequent interactions, if the requester is found to deviate ‘how often’ the attribute values differ, rather than by ‘how
significantly from previous access requests (defined in Section much’. Moreover, as our objective is to study the variability of

2327-4662 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2019.2941767, IEEE Internet of
Things Journal
8

requests made by a particular requester, static attributes, such TABLE I: Impact of Capabilities on Security Attributes
as his/her identity, trust level, and age, which are also part of No. Capability Device Type P C I A
the access request, are not considered. To this end, we adopt 1 ON/OFF General purpose 0 0 0 1
2 ON/OFF Controller 0 0 0 1
the principle given in [22] to compute the degree of variability 3 ON/OFF Safety and Security 1 1 0 1
in request patterns, termed as the coefficient of unalikeability 4 ADD/DEL RULE General purpose 0 0 1 0
(µ). Therefore, given a historical request set of size N for 5 ADD/DEL RULE Safety and Security 1 1 1 0
6 ADD/DEL USER Controller 0 1 1 0
any requester rl , we first compute the unalikeability score for
7 ADD/DEL DEVICE Controller 1 1 0 1
each of the request attributes in the set, and then combine them 8 VIEW LOG/STATE Safety and Security 0 1 0 0
to obtain the requester’s cumulative unalikeability score. The 9 DEL LOG Safety and Security 1 1 1 1
generalized form to compute the unalikeability score for the
v th attribute in rl ’s historical request set is as follows [22]: normalize the belief weights of the contexts in the interval [0,
X 1] and define:
µvrl = 1 − p2n (3)
n Fam = wL · L + wT · T + wU · U + wA · A (5)

where, pn is the proportion of requests having the nth category where, Fam is the context favourability related to the current
of that attribute, given as pn = gNn such that, gn is the number device access request am , and wL + wT + wU + wA = 1.0 are
of requests with the nth category, and N is the total number the coefficients for the aforementioned contexts, respectively.
of historical requests. For ease of understanding, we denote Apart from the favourability of the available contextual
the unalikeability score of device attribute as µdev
rl
information, the expected belief on the context, weighed by de-
Similarly, for the capability attribute, occurrences of ca- vice’s accessibility, needs to consider the impact of a requested
pabilities related to different requested device categories are capability on both physical as well as information security, the
individually considered, and the unalikeability score (µcap CIA tenets describe the latter: confidentiality, integrity, and
rl )
is computed using Eqn. (3). The unalikeability score for the availability. To quantify the damage that is expected to be
context attribute (µcon caused by misuse of the capabilities, we model their impacts
rl ) is computed considering the location,
time, and availability of users around the requester as the on various device types in terms of effects on four attributes:
categories. We discard the age from unalikeability computation physical (P), confidentiality (C), integrity (I), and availability
as it is a property of the requester and remains static during (A). Table I presents nine scenarios to illustrate the impacts of
consecutive request generation. Now, each of the three cate- misusing different capabilities, where 1 means the capability
gories (location, time, availability of users around) again has has an impact on the considered attribute, and 0 otherwise.
multiple sub-categories such as home, premise, outside for the As evident, the first scenario depicts ON/OFF capability
location category, conventional and odd for time category, and on general-purpose devices, abusing, which only affects the
so on. Thus, individual unalikeability scores for each category availability of that device. The sixth scenario shows ADD/DEL
is computed from the historical request set, and the mean is USER on controller devices which results in impacting the
taken to generate µcon confidentiality as well as the integrity of the home IoT
rl .
Finally, as given in Eqn.(4), we take a weighted sum of the environment. Similarly, the ninth scenario illustrates that if the
three unalikeability scores to obtain a cumulative score for DEL LOG capability is misused, it can affect all four security
requester rl : attributes of the environment.
For computing the confidence on a request, the SoftAuthZ
µrl = wdev · µdev cap con
am + wcap · µam + wcon · µam (4) framework needs to quantify the damage it (request) is ex-
pected to inflict (for the home IoT) through misuse of the
where, µrl is the cumulative unalikeability score for the allowed capability. The expected damage ∆ must combine the
requester rl based on historical request pattern, wdev , wcap , probability of occurrence of the corresponding capability from
and wcon are the importance factors attached to device type, the historical data and its impact on the security attributes of
capability, and context attributes respectively, such that wdev + the home IoT (as depicted in Table I). Thus, it is given as:
wcap + wcon = 1. It is to mentioned that the cumulative
unalikeability score gets updated with each new incoming ∆am = (P · ρki ) + (C · ρki ) + (I · ρki ) + (A · ρki ) (6)
requests, and is also given as input as a percentage score to where ρki is the probability of occurrence of requests involving
the inverse gompertz function to estimate the belief on the device type i and capability k.
requester’s device usage history. Intuitively, the belief in context should boost up with higher
3) Modeling Belief on Context: As mentioned in Section contextual favourability. However, rapid growth in belief is
III-A, we consider four contextual factors, viz., location of limited by the knowledge of the expected damage, ∆am
the requester (L), time of request (T ), availability of users associated with the requested capability. Lesser the ∆am ,
around the requester (U ), and the age of the requester (A), in the higher is the home IoT platform’s belief and vice-versa.
the proposed framework. To determine if the contexts are in Additionally, the belief likely to be gained also depends on
favour of the requested access or not, we need to quantify them the risk perception of the platform. To model this nonlinear
into a single metric score. The problem is modelled similar to a nature, we use the following function:
weighted regression approach where contexts are explanatory F
− ∆am
variables and their ‘favourability’ is the response variable. We bx = 1 − e a m (7)

2327-4662 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2019.2941767, IEEE Internet of
Things Journal
9

Here, ∆am controls the home IoT platform’s belief in the

present context. If both context favourability and expected
damage are high, the model reduces the threat of device misuse
by slowing down the belief growth.

Fig. 5: Confidence Score modeled by Logit Function

Fig. 5 shows the slope of the normalized confidence score

depending on the value of α. The lower value of α results
in lower confidence score and vice-versa. Thus, if the home
Fig. 4: Damage Factor: ∆ IoT platform is conservative about its devices’ usage, the
Fig. 4 shows the belief related to a context which a administrator needs to choose high α such that the requests get
potentially anomalous user can gain by misusing the requested accepted only if a significant confidence score gets generated.
capabilities. The damage factor ∆ controls the rate of growth Therefore, based on the distribution of the confidence
of the belief. Higher ∆ is reflective of a low-risk tolerance scores, the home IoT platform can adopt the following autho-
level and is suitable for conservative home IoT platforms. It rization policy to make decision regarding the current device
assigns lesser belief on the current request based on the given access request am :
contextual information. This may result in denying accesses to 
 Permit, iff Cam > 0
the IoT devices. However, for emergencies, the platform can Dam = (10)
increase the risk tolerance level (by setting a lower value of 
Deny, Otherwise
∆), thus enabling accesses to different devices (low or high
accessibility) for conditions corresponding to moderate context V. P ERFORMANCE E VALUATION
favourability. In this section, we evaluate the performance of the Soft-
AuthZ framework through validation of the confidence score
C. Modeling Confidence on Device Access Request generated by the framework. We developed a prototype of the
Eqn. (1) defines Bam as the expected belief on a device framework in Python and also simulated a realistic home IoT
access request am , made by requester rl . Now, given the environment. The details of the simulation environment are
degree of belief, the home IoT platform needs to perform given below.
a regression to determine if it is confident enough to grant
access or not. We model this as the confidence (C), and use the A. Simulation Environment
generalized linear models (GLM) for mapping. Particularly, As mentioned earlier, the devices in the home IoT environ-
we make use of the logit function to establish a link between ment belong to three hierarchical classes: General purpose
belief and confidence which is given below:
!  Controller  Safety and Security. For experiments, we
Bam normalize the accessibility values (δ) of different device types
Cam = ln (8)
1 − Bam within the interval [0, 1].
Where, Cam is the raw confidence corresponding to the belief In Section III-A, we discussed requester’s trust level, which
score Bam . It can be noted that Cam has value in the interval essentially quantifies his membership and privileges in a home
[−∞, +∞]. The logit function gives monotonically decreasing IoT environment. In usual practice, the higher the trust level,
weights to all Bam < 0.5, and monotonically increasing ones the greater is the scope to access different devices and vice-
to the rest. versa. For experiments, we assign integral trust levels from the
In order to give a bound to the confidence score, we use range 1-5 for each requester and normalize them within the
a scaling function which converts the raw Cam score into a interval [0, 1].
normalized score Cam ∈ [−1, +1], given as: Stemming from the absence of user-centric request data
in the area of securing home IoT environment, we generate
1 − e−α·|Cam | ,


 if Cam > 0 simulated requests to validate the efficacy of the proposed


 framework. The confidence scores for these requests will be
Cam = −(1 − e−α·|Cam | ), if Cam < 0 (9) generated by the SoftAuthZ framework and are classified as: (i)

low: if the confidence scores is in the range −1 < Cam ≤ 0;



0, if Cam = 0

and (ii) high: if the confidence score lies in 0 < Cam ≤ 1.
Here, 0 < α < 1 is the parameter to control the rate of growth In the following subsections, we present our approach of
of the confidence score in the interval [-1, +1]. simulating the data for the home IoT environment.

2327-4662 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2019.2941767, IEEE Internet of
Things Journal
10

1) Generation of Requester Data: In Section III-A, we

mentioned about five hierarchical membership classes (with
trust levels 1-5) for the requesters: Owner (5)  Spouse (4) 
Family (3)  Children (2)  Guest (1). Moreover, in Section
III-A, we defined the requesters’ behaviour in terms of the
variability in past requests by two types:
Normal requesters: The requests generated by this type of
users have low variability with unalikeability score in the range
of 0 ≤ µ < 0.5.
Anomalous requesters: Such requesters exhibit higher varia-
tion in device access requests and has unalikeability scores of
0.5 < µ ≤ 1. One motivation for such behaviour may be to
Fig. 6: Authorization Rate for Different Home IoT Users
misuse the device on which s/he has access.
We consider a predefined number of users for the home
IoT environment and assign each of them a trust level. We both normal and anomalous requesters. At the initial stage,
simulate requester’s behaviour class by generating a random all requesters start with maximum belief, but it is expected to
number in the interval [0, 1]. The generated number is the drop as the unalikeability score (µ) gradually increases with
requester’s unalikeability score µrl and based on its value, an increase in variability in requests over time. As defined in
we assign him/her to one of the above two types. Using this Eqn.(10), requests with confidence score Cam > 0 are granted
unalikeability score, the initial belief of each requester’s device and rest are denied. Thus, we define the authorization rate for
usage history is also computed using Eqn.(2). any requester as the ratio of the number of high confidence
2) Generation of User-specific Request Set: In this step, we requests to the total number of requests generated by him/her
generate simulated device access requests for each home IoT during the simulation period.
user. For any requester rl , we know earlier his/her membership Fig. 6 shows the average authorization rate for all requesters
class, trust level, as well as behavioural class based on the from both types, as observed over increasing simulation time.
unalikeability scores. We generate the first request of user rl ’s To remove randomness due to simulation, we run our simula-
request set by choosing random categories/sub-categories from tion program ten times at each instant and take the average.
the three attributes - device type, capability, and context. To de- As evident, the authorization rate for normal requesters is sig-
termine the degree of variability of the request to be generated nificantly higher compared to that of the other requester type,
at the next time instant, we generate another random number ν and is above 80%, implying that the framework authorizes
in the range [0, 1]. If ν > µrl , then the requester produces the requests having high confidence, and incidentally majority
same request. Otherwise, a new request is randomly generated, of such requests come from regular users. Nevertheless, the
and µrl is recomputed. The updated unalikeability score is value is still not very high as requests from users belonging
used for generating future access requests, and the process to different membership classes with varying trust levels
continues. Following this, we generate a historical request have been considered. On the contrary, anomalous requesters
set for a particular requester rl . We use this request data set end up with a very low authorization rate. Interestingly, the
to compute all ρki , which is the probability of occurrence of authorization rate for anomalous requesters drops further at
access requests involving device type i and capability k (see later stages of the simulation as their unalikeability scores
Eqn.(6)). increase over time, leading to diminished confidence scores.
Based on the historical request set, we generate rl ’s requests
during the simulation time. We follow the same mechanisms C. Behaviour-based User Classification
for generating requests, updating the unalikeability score,
and re-adjusting the belief in the requester’s device usage
history. Additionally, SoftAuthZ computes the corresponding
confidence score against each generated request. Finally, based
on the confidence score, the simulated requests are tagged
either low or high. The above process continues for all users
in the home IoT environment.
Unless otherwise specified, the values of the inverse Gom-
pertz parameters used for experiments are: C0 = 1, C1 = 10,
and C2 = 0.3, the value for the parameter to control the
growth of confidence score α = 0.6, the weights for attributes’
unalikeability wdev = wcap = wcon = 0.33, and the weights
for context favourability wL = wT = wU = wA = 0.25.

B. Authorization Rate
In Section V-A, we mentioned about the low and high
confidence classes, used to label the requests generated by Fig. 7: User Classification

2327-4662 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2019.2941767, IEEE Internet of
Things Journal
11

is substantially high compared to that of anomalous requester

type. It is worth noting that for the normal class, the ON/OFF
capability requested on safety and security device type gen-
erates the lowest confidence score. This is intuitive, as such
devices are concerned with the privacy as well as physical
(a) ON/OFF (b) ADD/DEL RULE and information security of the home IoT environment, and
ON/OFF is not desirable. Thus, SoftAuthZ not only ensures
that the home IoT platform prevents anomalous requesters
from giving device accesses but also recommends controlled
usage of some capabilities for normal users.
Figs. 8c and 8d depict the results for ADD/DEL USER
and ADD/DEL DEVICE capabilities related to the controller
device type. As evident, the confidence scores generated by
our framework on the requests made by anomalous requesters
(d) Controller: ADD/DEL DE-
(c) Controller: ADD/DEL USER VICE are very low, which enables the home IoT platform to make
secure authorization decisions. It can be noted that even for
normal users, the framework generates relatively low confi-
dence scores, and it is lower for the ADD/DEL DEVICE
capability compared to the other one. The reason is that both
these capabilities on the controller device type are sensitive.
If such capabilities are allowed indiscriminately, there is a
possibility of misuse resulting in physical and information
losses for the home IoT environment.
(e) Safety and Security: VIEW (f) Safety and Security: DEL Figs. 8e and 8f show our study on the effects of VIEW
LOG/STATE LOG
LOG/STATE and DEL LOG capabilities on the safety and
Fig. 8: Effect of Capabilities on Confidence Score security device type. SoftAuthZ generates very low confidence
on device access requests for anomalous requesters. It may
One of the significant challenges for the home IoT platform
enable the home IoT platform to prevent such users from
is to segregate normal and anomalous users to ensure fair
manipulating devices with very low accessibility, viz., locks,
authorization decision. Such classification requires observing
doorbell, cameras, etc. Furthermore, we observe that the
the requesters’ behaviours over time and then classify them
confidence in normal users’ request for DEL LOG is also
based on their belief scores.
very low compared to VIEW LOG/STATE. It is intuitive, as
Fig. 7 shows the average belief scores for 50 normal and 50
deleting the logs of surveillance devices is never recommended
anomalous requesters, evaluated after running the simulation
from the perspective of both security and privacy, and the
ten times for a fixed duration (100-time units) over the
home IoT platform is never sure of the actual motive of such
synthetically generated device access request set. The user
request. This entails our framework to assign lower confidence
IDs are grouped by their types for better comprehension. It
value on such device access requests.
is noteworthy that the platform’s belief on the majority of the
normal users are significantly higher than the anomalous ones,
whose scores drop to zero due to a higher degree variability VI. C ONCLUSION
in access requests. One or more anomalous requesters end up
Security from insider attacks in a home IoT environment
with relatively higher scores due to their intermittent good
is challenging due to the sharing of the devices and the
and misbehaving natures. However, low belief results in a
presence of complex social and trust relationships among
low confidence score for the device access requests that are
users. The state-of-the-art home IoT platform gives access
initiated at the current time instant. Thus, behaviour-based user
through various multi-factor authentication mechanisms, but it
classification facilitates authorization decision making.
is still uncertain of the actual usage of the devices. Thus, there
is a need for an additional authorization layer based on soft-
D. Effect of Capabilities on Confidence Score security factors such as belief, confidence, etc. In this paper,
In this section, we study the effects of different capabilities we propose a novel security framework, SoftAuthZ, which
on the confidence scores of the device access requests, which forms the genesis for such authorization layer. SoftAuthZ inte-
came from either normal or anomalous requesters. Fig. 8 de- grates multiple IoT environment-specific attributes viz., con-
picts the results generated by running the simulation program text, device type, requested capabilities, users’ trust levels, and
ten times each for the duration of the 100-time units. The variability of historical requests into a linear regression model
outcome of all the runs is averaged out to reduce randomness. to compute the confidence on the device access requests. Such
Figs. 8a and 8b show the variations of confidence scores a confidence score can be used by home IoT platform to make
for ON/OFF and ADD/DEL RULE capabilities for different the authorization decisions. A prototype implementation of the
device types under both behaviour profiles. In both the capa- framework has been done, and simulation-driven experiments
bilities, the degree of belief restored on the normal requesters are conducted for performance evaluation. Results illustrate

2327-4662 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/JIOT.2019.2941767, IEEE Internet of
Things Journal
12

that SoftAuthZ can classify different user behaviours and [20] E. Barka, S. S. Mathew, and Y. Atif. “Securing the Web of Things
achieves higher authorization rates for normal users. with Role-based Access Control”, Springer International Conference on
Codes, Cryptology, and Information Security, pp. 14-26, 2015.
As a part of the future work, we aim to implement a [21] N. Ye, Y. Zhu, R. C. Wang, R. Malekian, and L. Qiao-Min. “An Efficient
real, multi-user home IoT environment to gather user-centric Authentication and Access Control Scheme for Perception Layer of
request data and validate the proposed framework in terms of Internet of Things”, Applied Mathematics & Information Sciences, 8:4,
pp. 1617-1624, 2014.
detection of anomalous requests made by the insiders. [22] G. D. Kader and M. Perry. “Variability for Categorical Variables”,
Journal of Statistics Education, 15:2, 2007.
R EFERENCES
[1] W. He, M. Golla, R. Padhi, J. Ofek, M. Drmuth, E. Fernandes, and
B. Ur. “Rethinking Access Control and Authentication for the Home
Internet of Things (IoT)”. 27th USENIX Security Symposium (USENIX
Security 18), pp. 255-272, 2018.
[2] M. Antonakakis, T. April, M. Bailey, M. Bernhard, E. Bursztein, J.
Cochran, Z. Durumeric et al. “Understanding the Mirai Botnet”. 26th
USENIX Security Symposium (USENIX Security 17), pp. 1093-1110.
2017.
[3] B. Gompertz, “On the Nature of the Function Expressive of the Law
of Human Mortality, and on a New Mode of Determining the Value of
Life Contingencies”, Philosophical Transactions of the Royal Society of
London, 115, 513-583, 1825.
[4] H. Mousa, S. B. Mokhtar, O. Hasan, O. Younes, M. Hadhoud, and
L. Brunie, “Trust Management and Reputation Systems in Mobile
Participatory Sensing Applications: A survey”, Computer Networks
(Elsevier), 90, 49-73, 2015.
[5] Y. Tian, Z. Nan, L. Yueh-Hsun, W. XiaoFeng, B. Ur, X. Guo, and
T. Patrick. “Smartauth: User-centered Authorization for the Internet of
Things”. 26th USENIX Security Symposium (USENIX Security 17), pp.
361-378, 2017.
[6] M. Ammar, G. Russello, and B. Crispo. “Internet of Things: A Survey
on the Security of IoT Frameworks”. Journal of Information Security
and Applications (Elsevier), 38:8-27, 2018.
[7] K. Z. Snow, F. Monrose, L. Davi, A. Dmitrienko, C. Liebchen, and A.
Sadeghi. “Just-in-time Code Reuse: On the Effectiveness of Fine-grained
Address Space Layout Randomization”. IEEE Symposium on Security
and Privacy (S&P), pp. 574-588, 2013.
[8] E. Fernandes, J. Jung, and A. Prakash. “Security Analysis of Emerging
Smart Home Applications”. IEEE Symposium on Security and Privacy
(SP), pp. 636-654, 2016.
[9] A. Rahmati, E. Fernandes, K. Eykholt, and A. Prakash. “Tyche: A
Risk-Based Permission Model for Smart Homes”. IEEE Cybersecurity
Development (SecDev), pp. 29-36, 2018.
[10] S. Lee, J. Choi, J. Kim, B. Cho, S. Lee, H. Kim, and J. Kim.
“FACT: Functionality-centric Access Control System for IoT Program-
ming Frameworks.” ACM Symposium on Access Control Models and
Technologies (SACMAT), pp. 43-54, 2017.
[11] Y. J. Jia, Q. A. Chen, S. Wang, A. Rahmati, E. Fernandes, Z. M. Mao,
and A. Prakash. “ContexloT: Towards Providing Contextual Integrity to
Appified IoT Platforms.” NDSS Symposium, 2017.
[12] Q. Wang, W. U. Hassan, A. Bates, and C. Gunter. “Fear and Logging
in the Internet of Things”. NDSS Symposium, 2018.
[13] T. Yu, V. Sekar, S. Seshan, Y. Agarwal, and C. Xu. “Handling a Trillion
(Unfixable) Flaws on a Billion Devices: Rethinking Network Security for
the Internet-of-Things”. 14th ACM Workshop on Hot Topics in Networks,
2015.
[14] J. B. Bernabe, J. L. Hernandez-Ramos, and A. F. Skarmeta Gomez.
“TACIoT: Multidimensional Trust-aware Access Control System for the
Internet of Things”. Soft Computing 20(5), pp. 1763-1779, 2016.
[15] A. Ouaddah, H. Mousannif, A. A. Elkalam, and A. A. Ouahman.
“Access Control in the Internet of Things: Big Challenges and New
Opportunities”. Computer Networks, 112, pp. 237-262, 2017.
[16] J. L. Hernandez-Ramos, M. P. Pawlowski, A. J. Jara, A. F. Skarmeta,
and L. Ladid. “Toward a Lightweight Authentication and Authorization
Framework for Smart Objects.” IEEE Journal on Selected Areas in
Communications, 33:4, pp. 690-702, 2015.
[17] J. Bonneau, H. Cormac, P. C. Van Oorschot, and F. Stajano. “The Quest
to Replace Passwords: A Framework for Comparative Evaluation of Web
Authentication Schemes.” IEEE Symposium on Security and Privacy
(SP), pp. 553-567, 2012.
[18] G. Zhang and J. Tian. “An Extended Role based Access Control
Model for the Internet of Things”, IEEE International Conference on
Information, Networking and Automation (ICINA), 1, pp. V1-319, 2010.
[19] J. Jindou, Q. Xiaofeng, and C. Cheng. “Access Control Method for Web
of Things based on Role and SNS”, IEEE International Conference on
Computer and Information Technology, pp. 316-321, 2012.

2327-4662 (c) 2019 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.