Future Generation Computer Systems 82 (2018) 422–439

Contents lists available at ScienceDirect

Future Generation Computer Systems

journal homepage: www.elsevier.com/locate/fgcs

An Internet of Things-based health prescription assistant and its

security system design
Mahmud Hossain a , S.M. Riazul Islam b, *, Farman Ali c , Kyung-Sup Kwak c , Ragib Hasan a
a
SECuRE and Trustworthy computing Lab, Department of Computer Science, University of Alabama at Birmingham, AL, USA
b
Department of Computer Science and Engineering, Sejong University, South Korea
c
School of Information and Communication Engineering, Inha University, South Korea

highlights

• A theoretical framework for an IoT-based health prescription assistant is proposed.

• A security system that ensures user authentication and protected access is designed.
• The details of security components, authorization model, and operational model are given.
• A prototype of the proposed security system has been implemented.
• Experimental results that validates the efficiency of the proposed system are provided.

article info a b s t r a c t
Article history: Today, telemedicine has a great reputation because of its capacity to provide quality healthcare services to
Received 29 June 2017 remote locations. To achieve its purposes, telemedicine utilizes a number of wireless technologies as well
Received in revised form 30 October 2017 as the Internet of Things (IoT). The IoT is redefining the capacity of telemedicine in terms of improved and
Accepted 12 November 2017
seamless healthcare services. In this regard, this paper contributes to the set of features of telemedicine
Available online 2 December 2017
by proposing a model for an IoT-based health prescription assistant (HPA), which helps each patient to
Keywords: follow the doctors recommendations properly. This paper also designs a security system that ensures user
Internet of things authentication and protected access to resources and services. The security system authenticates a user
Healthcare based on the OpenID standard. An access control mechanism is implemented to prevent unauthorized
Health assistant access to medical devices. Once the authentication is successful, the user is issued an authorization ticket,
Telemedicine which this paper calls a security access token (SAT). The SAT contains a set of privileges that grants the user
Security system access to medical IoT devices and their services and/or resources. The SAT is cryptographically protected
to guard against forgery. A medical IoT device verifies the SAT prior to serving a request, and thus, ensures
protected access. A prototype of the proposed system has been implemented to experimentally analyze
and compare the resource efficiency of different SAT verification approaches in terms of a number of
performance metrics, including computation and communication overhead.
© 2017 Elsevier B.V. All rights reserved.

1. Introduction and perform accordingly. The sensed data can be processed by a

In the past decade, the Internet of things (IoT) has become a
megatrend in next-generation technologies by offering advanced
connectivity to each uniquely identifiable smart device or thing [1].
An IoT-based system provides an intelligent framework with sens-
ing capability, contextual awareness, and device autonomy. IoT
devices embedded with sensors and actuators perceive their sur-
roundings, intelligent enough to understand the collected data,
* Corresponding author.
E-mail addresses: mahmud@uab.edu (M. Hossain), riaz@sejong.ac.kr
(S.M.R. Islam), farmankanju@gmail.com (F. Ali), kskwak@inha.ac.kr (K. Kwak),
ragib@uab.edu (R. Hasan).
smart device itself or in a cloud. An IoT device can take decision
autonomously based on the sensed data or communicate to us.
Every day, hundreds of such physical things are getting con-
nected to the Internet to share local information to cyberspace [2].
A recent research anticipates, every year, on an average, around
one million new IoT devices will be deployed to different applica-
tion domains [3]. In this regard, the IoT has gained a fair share of
attention from researchers, developers, and industries, and thus,
many different service applications have been proposed and devel-
oped. These proposed IoT-based applications can be categorized in
many different ways (for example, applications for smart cities, for
security, emergency services, and healthcare systems, etc.). Islam

https://doi.org/10.1016/j.future.2017.11.020
0167-739X/© 2017 Elsevier B.V. All rights reserved.
 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439
et al. [4] introduced various IoT-based application scenarios, where
mobile notifications are displayed on a TV screen, different colors
of room lighting are applied for emergency recognition, and a
health prescription assistant (HPA) is provided. For more profound
understanding of the IoT and its application domains, interested
readers are referred elsewhere [5–7].
Eventually, the IoT can be thought of as a growing network of
physical objects or entities that feature an IP address for Internet
connectivity, and the correspondence that happens between pairs
of such objects and other Internet-enabled gadgets and frame-
works. Introducing automation is feasible in nearly every field,
since the IoT comes with a set of benefits, including advanced con-
nectivity that goes beyond machine-to-machine scenarios [8]. One
of the main criteria of the IoT is enabling services provided by any
network on the World Wide Web to its intended end users and/or
things [4]. This feature of the IoT allows the offering of timely, high-
quality telemedicine and healthcare services to patients via remote
assistance. For example, in the concept of telemedicine, a medical
practitioner provides his/her patient with medical services from a
distance. The patient might be located in a remote place (the coun-
tryside, a ship on the ocean, or even in an aircraft). There are many
places on this planet, particularly in developing countries, where
access to healthcare services is restricted by distance and a poor
transportation infrastructure. However, in some places, healthcare
services are inadequate. In such places, the opportunities and
possibilities of distributing medical services by telemedicine can
be accelerated by mobilizing the potential of the IoT [1].
Consequently, the IoT could give rise to numerous medical
applications, including remote health monitoring. For example,
based on the patients health data, a healthcare service provider
can make a much better diagnosis of the patients condition and
can recommend the best possible treatment and early interven-
tion [9]. Consistency in home treatment and medication by the
healthcare service provider is another potentially critical applica-
tion. Hence, different healthcare devices, sensors, and diagnostic
and imaging gadgets can be seen as smart objects constituting a
pivotal part of the IoT. Thus, the technology of wearable sensors
has accelerated the development of new applications and services
used in remote healthcare systems, such as controlling patients
health conditions, through content service applications and by
providing treatment according to the updates [10]. Consequently,
IoT-based medical services are expected to decrease costs, to build
personal satisfaction, and to improve the client’s experience. From
the medical service providers point of view, the IoT could diminish
device downtime through remote procurement. Integration of the
IoT into the aforementioned healthcare systems enables a further
increase in intelligence and interoperability [11], which will result
in expansion of the IoT at an exponential rate.
In a nutshell, IoT-based healthcare [12] is a promising technol-
ogy that brings many advantageous applications to reduce costs,
increase quality of life, and improve the efficiency of healthcare
services, providing easy and correct action, on time.
However, in the healthcare system, devices and applications
are expected to deal with important private information, includ-
ing personal healthcare data. Furthermore, such smart devices
will be connected to worldwide information networks for access
anytime and anywhere. Subsequently, the IoT healthcare domain
may become a target. The personal data collected from resource-
constrained wearable sensors are thus vulnerable to privacy con-
cerns [13,14]. Additionally, unauthorized access to the medical
devices can jeopardize patients lives [15–20]. Therefore, misuse of
healthcare sensors and actuators or privacy concerns with patients
medical records may restrict people to utilize IoT-based healthcare
applications. In this regard, this paper proposes a model for an IoT-
based HPA and designs of a security system to protect unautho-
rized access to the proposed framework.
423
Contributions. The contributions of this paper are as follows:
1. We propose a theoretical framework for an IoT-based HPA
and present a detailed architectural model for the HPA.
2. We highlight the operation and benefits of the HPA.
3. We design a security system that ensures user authentica-
tion and protected access to electronic medical records and
medical sensors and actuators.
4. We provide the details of security components, authoriza-
tion model, operational model, and security access token
(SAT) verification.
5. We implement a prototype of the proposed system using IoT
devices powered by Contiki operating system.
6. We provide the performance evaluations in terms of var-
ious metrics, including communication and computation
latency, request completion time, and energy consumption.
Organization. The rest of this paper is organized as follows. Related
work and motivation are presented in Section 2. A background on
access-control schemes in IoT is provided in Section 3. In Section 4,
the proposed HPA is presented. Section 5 provides the proposed
security system. The experiment and evaluations are presented in
Section 6. A comparative discussion on proposed and existing au-
thorization schemes is presented in Section 7. Finally, we conclude
this article in Section 8.
2. Related work and motivation
The advances in cloud and ubiquitous computing, smart sensors
and actuators, and IoT Big data and analytics have made remote
monitoring of patients more feasible. Recently, several research
works on wireless healthcare have been proposed, which aimed
at continuous patient monitoring in closed environments, such as
home, office, ambulance, and hospital, as well as in open environ-
ments such as athlete health monitoring.
2.1. Insecure IoT-based healthcare
An implementation of autonomous wireless body area network
for enabling IoT connected healthcare applications was proposed
in [21]. The authors in [22] provided a Cloud-IoT based sensing
service for health monitoring. The research work [23] presented
an intelligent healthcare framework based on IoT technology to
provide ubiquitous healthcare to person during his/her workout
sessions. To provide an efficient diagnosis, Lomotey et al. [24]
proposed a data acquisition architecture for wearable devices. Ali
et al. [25] proposed a healthcare system that analyzes physiological
information of patients and suggests diabetes-specific prescrip-
tion. We-care [26] proposed an IoT-based healthcare system for
elderly people. iDoctor [27] provided a personalized and profes-
sionalized medical recommendations based on hybrid matrix fac-
torization. A facial recognition system that enables doctors and
caregivers to constantly monitor patients’ feelings remotely and
take appropriate action as required was presented in [28]. The arti-
cle [29] provided an energy-aware cyber–physical therapy system,
which incorporates smart things and devices in both the physical
and cyber world for therapy sensing. The authors in [30] proposed
a smart health care framework for monitoring Parkinson’s disease
in smart cities. Sood et al. [31] designed an IoT and fog based
healthcare system to provide a remote diagnosis of Chikungunya
virus based on a user’s health symptoms and surrounding environ-
mental conditions. A healthcare monitoring system using radio-
frequency identification (RFID) was proposed in [32]. The authors
in [33] designed an IoT-aware architecture for smart healthcare
coaching systems. An information acquisition model to enable
424 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439
real-time data processing and decision making in the telemedicine
was provided in [34].
The above-mentioned research works enable automatic patient
monitoring and provide potential quality of the healthcare without
compromising with the patient’s comfort. The primary focus of all
these projects is to achieve a higher degree of efficiency, reliability,
and cost-effectiveness of their systems. Although some of these
articles mentioned the security issues with electronic medical
records and wearable sensors, none of them embedded security
solutions with their telehealth systems.
2.2. Security constraints in IoT-based healthcare
Security schemes designed for conventional digital systems to
achieve authentication, authorization, and secure communication
cannot be applied directly to IoT healthcare systems due to the
resource constraints and distributed architecture of these sys-
tems. The medical IoT devices have limited processing power and
memory. Thus, conventional cryptographic techniques that require
heavy computations are infeasible. Additionally, these devices op-
erate in a low power and lossy network with limited communi-
cation bandwidth, and are located at the edge of a network, such
as home, hospital, and office. Therefore, it is infeasible to utilize
conventional secure protocols primarily designed for centralized
architecture in distributed IoT healthcare systems. Furthermore,
the IoT healthcare applications require real-time monitoring. How-
ever, the resource-intensive security operations may limit medical
sensors and actuators from publishing real-time updates on health
conditions.
2.3. Limitations and problem formulation
Although there are some researches on lightweight authenti-
cation and secure communications for IoT-based healthcare sys-
tems [35–40], little attention has been paid to authorization. There
are a few healthcare frameworks that adopted Role-based Access
Control [41] and Attribute-based Access Control models [42] to
ensure the privacy of the electronic medical records stored in a
central entity. However, these proposed frameworks lack security
scheme to protect medical devices, which operate in a distributed
system, from unauthorized accesses. The lack of an authorization
scheme for medical devices can be life-threatening for a patient.
For example, an authorized access to the IoT-enabled Pacemaker
implanted in a patient’s chest will enable an adversary to regulate
the beating of the heart maliciously. In another scenario, an ad-
versary can change the drug dosage for a diabetic patient gaining
access to the electronic insulin pump attached to his/her body.
2.4. Proposed solution
In light of the aforementioned security gaps in the exist-
ing smart healthcare applications, we propose an IoT-enabled
and secure health prescription assistant framework. We integrate
OpenID standard [43] to the HPA for user authentication. To
mitigate unauthorized access related risks, we adopt Attributed-
based Access Control (ABAC) model for protected access to elec-
tronic medical records stored in the Cloud, and propose a Dele-
gated Context-ware Capability-based Access Control (DCCapBAC)
scheme for ensuring protected access to medical sensors and ac-
tuators operate in the edge of the networks. DCCapBAC enables
medical devices to expose their services in a protected way. DC-
CapBAC unburden resource-limited medical sensors and actuators
from computation intensive cryptographic operations by delegat-
ing them to a smart Gateway (e.g., border router) [44–46] co-
located with the medical devices. DCCapBAC also reduces commu-
nication and memory overhead involved in making an authoriza-
tion decision for a request. Thus, real-time updates on a patient’s
physical conditions get published to caregivers. This also enables
medical sensors receiving caregivers’ instructions immediately.
3. Background: Access control in IoT
To better understand the DCCapBAC scheme proposed in this
article, we provide a brief overview of the authorization models
used in IoT-based systems.
Access Control List (ACL): The ACL is one of the most common au-
thorization model [47,48]. Access rights (AR) are centrally specified
in the ACLs as right = <prov ider , action> and assigned to clients
as a tuple <client , right >. ACLs can be adopted achieving autho-
rization in a centralized system with a small number of clients
and providers. However, it becomes a complex task to manage and
deploy ACLs with the increasing number of IoT devices.
Role-based Access Control (RBAC): This model [49] proposes an
additional layer to manage access rights in a flexible way . RBAC
eliminates direct assignments of rights to clients. Instead, it defines
a set of roles, assigns rights to the roles as <role, right >, and then
assigns roles to the clients requesting access as <client , role>.
RBAC minimizes the effort to managing rules. However, the scal-
ability of the RBAC models becomes a challenge when it requires
to assign roles to a large number of IoT devices and their users.
Attribute-based Access Control (ABAC): This model [50] provides
a mechanism for managing huge number of rules – rights, roles,
and clients assignment. ABAC enables the use of a combination of
various attributes of a requested client such as location, temper-
ature, time of day, and so on, to generate dynamic access polices.
Thus, ABAC reduces the number of static access control rules and
makes RBAC feasible for a large number clients and providers.
The ACL, RBAC, and ABAC share a common problem which
is centralization. In these models, a central entity is responsible
for making authorization decisions including combining attributes
and enforcing policies. This entity has to be always online to pro-
vide an authorization decision for every request made by clients.
However, the centralized decision making property of these mod-
els may not provide good scalability in the distributed IoT envi-
ronments. Another major drawback of these models is that they
only consider service clients as a human user. As a result, these
approaches cannot be applied to the scenarios where medical
devices communicate with each other such as sensor-to-sensor or
sensor-to-actuator interactions.
Capability-based Access Control (CapBAC): The CapBAC models,
that were proposed for distributed systems a long time ago in the
literature [51–53], can be suitable for the IoT. The CapBAC approach
offers flexibility that can meet the requirements of various IoT
architectures. CapBAC maps access rights to a client’s capability
token. The token is signed by a central party and issued to the
client. Thus, it is cryptographically protected and cannot be forged.
Most recently, CapBAC models for IoT systems have been proposed
in several research works [54–60]. These models can be classified
into three categories based on the approach they follow verify-
ing a capability token, such as centralized, distributed, and semi-
distributed.
In the centralized approaches [54–56], an IoT device com-
municates with an intermediate party different than the issuing
one to validate the correctness of a capability token every time
a client makes a request. An IoT device validates the token by
itself in the distributed approach [57,58]. In the semi-distributed
approach [59,60], a gateway communicates with the intermediate
party on behalf of the IoT device for token validation.
However, in our proposed DCCapBAC approach, the validation
task is delegated to the gateway. The gateway intercepts an in-
coming request and makes an authorization decision (permit or
deny) for a medical device without any communication with the
intermediate party. The details of the DCCapBAC is presented in
Section 5.4.3.
 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439 425

Fig. 1. A conceptual diagram of the HPA.

Fig. 2. The detailed organization of the HPA.

4. Health prescription assistant (HPA)

device; instead, it is a service running on a virtual (e.g., Amazon
4.1. Basic concept of the HPA Elastic Compute Cloud1 ) or physical machine. The specification of
the machine, such as the number of CPUs, storage, memory, etc.,
Fig. 1 conceptualizes the functional space of the HPA within may vary based on the total number of clients and medical devices
the IoT cloud. In this proposed concept, required interactions associated with the HPA system. Moreover, on-demand resource
occur between smart objects/things, such as the patients home, scaling techniques can be utilized to upgrade the specification of
medical equipment, and/or body-worn biosensors that constitute the machine on the fly for balancing loads.
a body area network (BAN). Connections among these units can
Security Servers: The role of the security servers is to ensure
be considered a subnetwork of the network spanned by the HPA,
protected access to medical records, sensors, and actuators. The
while logistics between the health clinic and respective healthcare
security servers implement three types of services – authenti-
service professionals creates another subnetwork for internal com-
cation, authorization, and auditing. The authentication service is
munications. The HPA coordinates both subnetworks and various
responsible for identity verification. The authorization service pro-
databases (DBs) and utilizes a health computing server to help
tects medical records and devices from unauthorized accesses.
patients follow the doctors recommendations.
The details of the authentication and authorization services are
provided in Section 5. The auditing service logs various interactions
4.2. IoT elements and organization
(authorized and unauthorized) among the HPA components. Later,
these logs can be analyzed to investigate any malicious activities.
It is obvious that a doctors office, a doctors prescriptions, vari-
Additionally, reporting and alerting services, such as Elastalert,2
ous concerned databases, a patients personal smartphone, a smart
X-Pack3 can be integrated to the auditing service for real-time
medicine box, food items preserved at home and in the refrig-
notifications on unauthorized access or intrusion detection. Note
erator, as well as relevant smart home elements, such as the air
that, the details of the process to collect, store, and maintain the
conditioner, automatic locks and security systems, the room hu-
integrity of the logs are beyond the scope of this article.
midity control system, etc., all form an IoT network. The following
subsection will briefly describe the functions of each component The Patient and the Smart Medicine Box: The patient carries a
constituting the HPA (see Fig. 2). body-patch containing different biosensors with appropriate elec-
trodes, which forms a body area network. The body-patch sen-
The HPA Gateway: The gateway plays a vital role in delivering
sors and implanted biochips communicate with a sensor-attached
services of interest accessed by the HPA. The gateway monitors
medicine pack by using short-range communications technology,
and controls authorized healthcare personnel who interact with
such as an IPv6-based low-power wireless BAN (6LoWBAN) [61],
the HPA. It identifies authorized healthcare professionals and the
ZigBee [62], or Bluetooth low energy (BLE) [63]. Hence, the
patient through their smart devices. The gateway communicates to
medicine pack interacts with sensor-coated smart pills that are
the Security Servers for ensuring protected access to patients’ med-
included in the medicine pack as a set, whereas the medicine
ical records. Based on the doctors recommendations, any suspected
packs sensor is nothing but a radio frequency identification (RFID)
diseases, and the hospitals accessibility, the gateway generates
chip, and the pills sensor is a special kind of coating material with
database access reports and delivers them to the health computing
a sensing ability. The medicine pack is contained in a specially
server for service preparation. In addition, the gateway records
designed smart medicine box. A central sensor inside the smart
each and every activity, for example, opening a new session, pre-
medicine box keeps a record of each medicine pack and the pills.
scribing medicine, suggesting dietary requirements, or recording
For example, when the patient tears open part of the medicine
the patients waiting time after a particular service was requested
pack to take a particular pill, this is sensed by the medicine pack
of the associated healthcare personnel with the respective times-
tamps. Furthermore, the gateway performs an array of on-demand
tasks (for example, terminating a particular connection in case of 1 https://aws.amazon.com/ec2/.
emergency, or upon reception of proper commands from the HPA). 2 https://github.com/Yelp/elastalert.
Note that, the HPA gateway is not a traditional network gateway 3 https://www.elastic.co/guide/en/x-pack/current/xpack-alerting.html.
426 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439
and reported to the medicine box for subsequent processing and
references. The medicine box communicates with both the patients
body-patch sensor network and the Internet, and thus, become a
vital part of the IoT-based HPA. Eventually, the HPA can address
each and every pill individually, per the patients requirements.
Moreover, the aggregated data from the patient BAN will be stored
and processed on the health cloud computing server for further
need.
Health Databases: The HPA can access several databases to assist
the patient in a number of ways. The database may contain a
stack of some representative DBs, including a food and nutrition
DB, measured physiological biomarker DBs, and disease-specific
tips DBs. The food and nutrition DB provides an extensive list
of foods with their nutrition facts in a structured form so the
HPA can automatically process the data and determine further
actions according to the aggregated data. This DB can supply the
system with information about how a particular food affects the
patients health, which makes it easier to select a healthy diet,
whereas the disease-specific tips DB provides advice, archived
experiences from other patients, as well as information about
medications. These databases might be offered by third parties
who provide business-to-business services. In that case, the DB
service providers and the HPA must agree on a standard protocol
to communicate with each other in order to establish system
compatibility. The types and numbers of various DBs integrated
with the HPA depend upon the respective authority of the hospital
providing healthcare services.
Computing and the Control Server: The health cloud computing
and control server is basically responsible for the core computing
and decision making requested from time to time by the HPA. As
mentioned earlier, the aggregated data will be conveyed to the
health cloud computing and control server for storage, processing,
analyzing, and visualization. The control server is the central hub
of the HPA. It monitors and controls the clients installed at various
points, including any clients in the doctors devices and the patients
devices. It also aggregates the events reported by various edges
of the HPA system (e.g., sensors, the patient, health professionals,
and DBs) and prepares the structured commands to be sent to the
computing server. The computing server analyses the commands
received from the control server and sends the respective edges
the results. Unlike the control server, which must be owned by
each hospital, the computing server might be supplied by a third
party. Furthermore, visualization is an important research area in
the science [64], and thus, it is a vital requirement for systems
like the HPA, where the measured biosensor information must
be in a form in which the doctor can read it and understand the
impact of the specific event on the patients health condition. In
the literature, several approaches [65,66] enable visualization of
the data in various forms.
The Smart Home: The HPA communicates with a smart-home
system to give the patient more suitable and comfortable living
conditions, including room temperature, adequate lightning, and
proper humidity. In some cases, the HPA requires special designs
of smart-home elements. For example, it needs a specially designed
refrigerator to keep track of preserved food items. The refrigerator
consists of several chambers, and each chamber contains several
cells. The chambers and cells are equipped with sensors. These
sensors can communicate with the main RFID of the refrigerator,
which communicates with the smart-home server and connects to
the Internet. Also, if the control server provides access, the smart
home and the patients systems can directly communicate with
each other for a specific session.
The Smart Gateway: A smart gateway is a resource-rich device
placed at the edge of a network. The gateway has four different
planes: communication plane, aggregation plane, decision plane,
and security-enforcement plane. The communication plane en-
ables interactions between multi-protocol devices and networks.
It allows communication between the HPA and the smart objects
located in a smart-home or medical sensors attached to a patient.
Smart objects and wearable sensors communicate among them-
selves through the smart gateway as well. The aggregation plane
complies data from medical sensors and publishes them to the
Cloud HPA services. The decision plane is intelligent enough to
process sensor data, to learn health condition, and to make decision
locally. The security-enforcement plane protects smart nodes from
unauthorized accesses. The planes of the smart gateway can be
implemented using the 6LoWPAN border-routers manufactured
by Intel [67] and Weptech [68].
4.3. Operation and benefits
4.3.1. HPA operation
Step 1: The HPA is installed with an appropriate interface for
doctors in the doctors smart device. Step 2: The HPA is installed
with an appropriate interface for patients in the patients smart
device. Step 3: Both doctor and patient agree to use the HPA service
for the intended purpose and enable the HPA service accordingly.
Step 4: The doctor provides a digitized prescription to the system
through the HPA. Step 5: The doctor and patient touch their smart
devices for a mutual permission through near field communication
(NFC), and the HPA starts working. In case of a remote consultation,
both the doctor and the patient implement a message-passing
protocol and input codes to complete the mutual permission.
4.4. Benefits of an HPA
Since the HPA can act as a reminder, the patient never forgets
to take medicines and follow a proper diet. The HPA detects any
adverse drug reaction through the use of an array of sensors, and
can report those issues to the doctor and healthcare providers.
Owing to mutual understanding and interactions between the HPA
and the medicine box, the HPA protects the patient from taking
the wrong medicine by mistake. Thus, with the help of relevant
databases and based on the doctors recommendations, as well as
the detected diseases, the HPA can recommend appropriate recipes
for the patients health from the food available in the refrigera-
tor. Moreover, the HPA also interacts with the smart-home sys-
tem where the patient resides by setting the ideal environmental
temperature and humidity for the patients needs. The system is
considered robust and reliable against unauthorized access due
to the presence of the gateway. The gateway can be configured
with appropriate authorization so the HPA can safely coordinate
databases, the health cloud computing and control server, and the
health clinics.
5. Security system
5.1. Security components
This section presents an overview of the security components
for the proposed prescription assistant system (see Fig. 3). Note
that the security system follows the OpenID standard [43] to au-
thenticate users.
Identity Provider: An identity provider (IdP) provides identifiers
for users (e.g., physicians, patients, employees, etc.) who interact
with the IoT health assistant. The IdP also confirms with the IHA
that an identifier presented by a user is known. Additionally, the
IdP provides other information, such as address, date of birth,
gender, etc., about the user, which is known to the provider.
For example, the IHA system allows users to register/login with
 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439
Fig. 3. Security components.
Google, Twitter, or Facebook credentials. The IdP issues a secret
certificate (SCert) to the verified user, which is later verified by the
authentication authority to grant access to the IHA.
Registration Authority: Users need to register to interact with
the IHA system. The registration authority (RA) takes care of user
registration. The RA operates in two modes: direct mode and
relay mode. In direct mode, a user provides personal information
(e.g., name, date of birth, social security number, credit card in-
formation, etc.) to the RA. The RA verifies the information and
confirms user registration. In relay mode, the RA allows users
to register with the help of a third-party IdP, such as Google or
Twitter. The user permits the RA to contact the IdP to retrieve the
user’s information. After successful registration, a user profile is
created and kept in the user profile database. Each user is assigned
with a unique user identity (UID).
Authentication authority: The authentication authority provides
a login service to users. The authentication authority interacts with
an Idp to determine a user’s authenticity. The authentication au-
thority verifies the SCert, which is issued by the IdP, to authenticate
a user.
Authorization authority: The authorization authority ensures
protected access to the IoT medical services. The authorization au-
thority maintains access policies, user roles, an access control list,
etc., and provides interfaces to manage them. The authorization
authority issues a service access token (SAT) to an authenticated
user, generating the SAT according to the roles and policies defined
for the user. An IoT medical service verifies the user’s SAT to grant
access to the service.
IoT Service provider: The IoT service provider (IoTSP) provides
two types of medical services: in-device medical services and cloud
medical services. In-device medical services (IdMS) are offered by
IoT medical devices. The IdMSs are local IoT services; for example,
a smart pulse oximeter attached to a patient’s body offers services
to retrieve the patient’s oxygen saturation (O2 ) level in the blood,
either directly (i.e., a physician connects to the device to retrieve
the level) or remotely (i.e., via the cloud medical service). A user
can subscribe to a service to receive notifications and/or events. For
example, the pulse oximeter publishes the O2 level periodically.
427
Fig. 4. Components of the authorization model. RAC = Role Attribute Constraint,
PAC = Permission Attributed Constraint, and OPAC = Operation Attribute Con-
straint.
On the other hand, a cloud medical service (CMS) is hosted in
the cloud and allows remote access by the local IdMSs. The CMS
maintains a repository of device profiles. It also has a repository
containing subscription information about the IdMSs, i.e., which
user is subscribed to which services and with what configurations
and settings. The CMS provides interfaces to create and manage
subscriptions and/or access rules for the IdMSs. For example, a
user can create rules to receive notifications when the O2 level falls
below a certain threshold.
5.2. Authorization model
The proposed model implements context-aware capability-
based access control (CCapBAC) [54] to provide protected access
to the IoT services and resources. The ability of a user to access
the resources and/or services is assigned according to the policies
defined for the roles of the user. For example, Alice, Bob, and Char-
lie are registered in the IHA system, assigned to the roles of nurse,
physician, and senior physician, respectively. Rules are defined in
such a way that the nurse can only issue commands (e.g., GET,
POST, etc.) to a certain set of medical IoT devices, such as a body
temperature sensor (e.g., thermometer), blood pressure sensor,
glucose sensor, insulin pump, etc. On the other hand, a physician
has more capabilities than a nurse. Bob has all the capabilities of
Alice, but Bob has additional rights to issue commands to sensitive
medical IoT nodes, such as an EEG, an ECG, a vision sensor, a hearing
sensor, etc. However, Bob lacks some of the capabilities granted
to Charlie, as senior physician. Charlie has access to implanted IoT
nodes (e.g., an IoT-enabled pacemaker implanted in the patients
body) and can prescribe medicine in an emergency or critical
situation by issuing a command to the smart medicine box (e.g., the
pill bottle).
5.2.1. Components definition
Fig. 4 shows the components of the CCapBAC model. Details on
the components are as follows:
Subject (Sub): Subjects are the consumers of local and cloud IoT
services. A subject can be a person, computer, smartphone, soft-
ware agent, and so on. Each subject is assigned with a unique id. A
subject set (SubS) is defined as follows:
SubS = {Sub1 , Sub2 , Sub3 , . . . , Subn−1 , Subn } (n ∈ N)
Role (R): A role defines the functions of a subject. Each subject
is assigned with a role, such as patient, physician, nurse, system
administrator, or security manager. A role is a group of subjects
428 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439
in the system, and each role has its own access rights to a set of
services. The set of roles (RSet) is defined as follows:
RSet = {R1 , R2 , R3 , . . . , Rn−1 , Rm }
Ri = {Subi1 , Subi2 , Subi3 , . . . , Subij−1 , Subij }
Here m, j ∈ N, 1 ≤ i ≤ m, and Sij ∈ SubS
Operation (OP): Operations, such as GET, POST, DELETE, and PUT,
are sent to the services. For example, a user performs a read
operation to a service by issuing a GET request. A set of operation
is defined as follows.
OP = {GET , POST , DELETE , PUT , . . .}
Service (S): Services are offered by medical IoT devices. Each
service consists of a set of resources (res), such as configuration
files and sensor data sorted in a database or on-device memory. A
service receives a users request and complies with it. The request is
verified by the Access Control Logic (ACLogic) engine as described
in Section 5.4.2 before being fulfilled. A set of service (SS) and
resource (RS) are defined as follows:
RS = {res1 , res2 , res3 , . . . , resq−1 , resq }
SS = {S1 , S2 , S3 , . . . , St −1 , St }
Si = {resi1 , resi2 , resi3 , . . . , resij−1 , resij }
Here q, t , j ∈ N, 1 ≤ i ≤ t, and resij ∈ RS
Permission (P): A permission is an approval of a particular mode
of operation for one or more services in the system. Permissions
enable the holder of the permission to perform some action in
the system. For example, a nurse has permission to retrieve the
thermometer reading, however she cannot issue a command to
the pill bottle. A set of permission (PS) is defined using operation
assignments (OA) as follows:
PS = {P1 , P2 , P3 , . . . , Pt −1 , Pt }
Pi = {OAi1 , OAi2 , OAi3 , . . . , OAiq−1 , OAiq }
OAij = Si × OPi
Here, t , q ∈ N, 1 ≤ i ≤ t, OPi ⊂ OP, and Si ∈ SS
Attribute constraint: There are different types of attributes, such
as user attributes, role attributes, and medical device attributes,
which can be used during policy assignment: user assignment,
permission assignment, and operation assignment. For example,
the age/work experience of a user may be considered during user
assignment: assigning a role to the user. Or perhaps a physician
must have 15 years of experience to be assigned to a senior physi-
cian role. Similarly, the properties of a role, such as the size of
the group or the functions of a group, can be considered during
permission assignment. For example, at least one person should
be assigned to the senior physician role, or no two nurses should
have access to the same medical devices of a patient: access to
such services is mutually exclusive. Furthermore, device properties
like memory, communications interface, or energy source (e.g.,
battery-driven) can determine operation assignment. For example,
a medical IoT node with read-only memory must not be accessed
for POST actions. An attribute set is defined as follows:
AT = {at1 , at2 , at3 , . . . , atn−1 , ctn } (n ∈ N)
Each element of the attribute set represents an attribute type
(at). An attribute element (AE) is expressed as a triple AE =
{ati , name, v alue}, ati ∈ AT . For example, (dev ice, memory, 16MB)
expresses the capacity of the memory, (patient , age, 45) expresses
the age of the patient, and the size of a group is expressed as
(role, size, 15). An attribute constraint (AC ) is expressed by a com-
bination of attribute elements. The combination is achieved with
the conjunction, disjunction, and negation operations of the at-
tribute elements. To further understand the expression of the at-
tribute constraint, consider the following example. Suppose there
is a security rule such that ‘‘All physicians from the cardiology
department can check the status of a pacemaker’’. This rule can be
represented as:
AT = {Role, Department , Dev ice}
AC = ∀Role.Physician ∩ ∀Department .Cardiology
∩ ∀Dev ice.Pacemaker
Context constraint: Context is used to characterize the situation
of an entity. An entity can be a person, place, or object that is
considered relevant to the interaction between a user and a med-
ical IoT service. Different types of context, such as time, space,
object status, etc., can be used during the policy evaluation phase to
determine whether to allow/deny a request [69]. For example, it is
possible for a users request to be rejected if the request originates
from a certain location. A request can also be rejected if it was
performed earlier, or if issued after a certain time of day. Moreover,
a request can be rejected based on a medical devices current status,
such as the operating mode (e.g., it is in energy-saving mode). In
all these cases, a user has the right to invoke services or access
resources; however, the request might not be accepted because the
conditions in the context information were not satisfied. A context
set is defined as follows:
CT = {ct1 , ct2 , ct3 , . . . , ctn−1 , ctn } (n ∈ N)
Each element of the context set represents a context type
(ct). Each context element (CE) is expressed as a triple CE =
{cti , name, v alue}, cti ∈ CT . For example, (dev ice, mode, energy-
sav ing) expresses the operating mode of the device, and
(physician, location, coordinate(33.5o , 86.8o )) expresses a location
context. For instance, one can consider a security rule like ’’Any
request originating from a hospital should be served, regardless of
the time of the day and the operating mode of the device’’. Such a
context constraint can be expressed as follows:
CT = {Time, Location, Dev ice)
CC = ∀Location.Hospital ∩ ∀Time.Hour
∩ ∀Dev ice.OperatingMode
5.2.2. Components relationship
UA, PA, and OA stand for user assignment, permission assign-
ment, and operation assignment, respectively.
UA ⊆ U × R : User assignment is a many-to-many mapping
between users and roles. Each user must be assigned with a role.
One user can belong to multiple groups, since a user may have
multiple roles.
PA ⊆ P × R : Permission assignment is a many-to-many mapping
between permissions and roles. To access resources, each role is
assigned with certain permissions.
OA ⊆ OP × S : Operation assignment is a many-to-many mapping
between operations and services. Each service is assigned with a
certain number of operations.
RAA ⊆ R × AT : Role attribute assignment (RAA) is a many-
to-many relation between roles and attribute types. Each role is
specified with appropriate attributes by a security administrator.
PAA ⊆ P × AT : Permission attribute assignment (PAA) is a many-
to-many relation between permissions and attribute types. A set
of attributes is first defined, and then appropriate attributes are
assigned to the permissions by a security administrator.
OPAA ⊆ OP × AT : Operation attribute assignment (OPAA) is a
many-to-many relation between operations and attribute types. A
security administrator assigns a set of attributes to the operations.
 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439 429

Fig. 5. An example policy for nurse and physician. A physician inherits the privileges
of a Nurse.

Fig. 7. Authentication and SAT generation.

Fig. 6. Creation of capability token from defined policies.

5.2.3. Policy
Policy determines the capabilities of the users. Each policy con-
tains a subset of the permission assignment and operation assign-
ment, but does not contain a user assignment: users information
is not included in the policy. Policies are defined for roles, and
roles are mapped to users. Therefore, the capabilities of a user
correspond to polices defining his/her roles. Policies are defined
and stored in the policy database in the authorization service. Fig. 5
shows an example of access control policy encoded in Extensible
Access Control Markup Language (XACML) [70].
A capability token, which this paper designates as a security
access token, is created from these policies and issued to a user.
Unlike policy encoding, capability tokens are signed and encoded
in Java Script Object Notation (JSON) [71]. A user sends a request to
a medical IoT, and attaches the capability token with the request.
The medical device checks the requesters access rights by verifying
the token, and then applies context constraints to allow or deny the
request (see Fig. 6).
5.3. Operational model
This section presents the operation model of the proposed
security architecture (see Fig. 7).
5.3.1. Authentication phase
Step 1: A user sends a login request to the authentication
authority. The authentication authority allows the user to select an
IdP. The authentication authority redirects the user to the selected
IdP service. Step 2: The IdP service asks for the user’s credentials
such as email address and password. The user provides the creden-
tials. The IdP verifies the credentials and issues a Secret Certificate
(SCert) to the user.
Fig. 8. SAT generation process.
5.3.2. Service access ticket (SAT) generation phase
Step 1: The user provides the SCert to the Authentication Au-
thority and requests for a Service Access Ticket (SAT). Step 2:
Authentication Authority validates the SCert by checking the IdP’s
signature which is attached to the SCert. Next, the Authentication
Authority retrieves the UID of the User. Step 3: The Authentication
Authority provides the UID to the Authorization Authority, and re-
quests to generate a new SAT for the user. Step 4: As shown in Fig. 8,
The authorization service first checks that the user has not been
blacklisted. Next, it retrieves the role of the user in the system. After
that, it obtains the policies, permissions, and context constraints
defined for the role. Finally, the SAT creation service generates
a signed SAT using the retrieved information (see Algorithm 1).
Step 5: The authentication authority receives the issued SAT from
the authorization authority, and forwards the SAT to the user. The
user is required to present the SAT to an IoT device to access
resources and services offered by that smart device. The IoT device
verifies the SAT as described in the following section and grants
access.
430 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439

Algorithm 1: Generate Security Access Token

1 function GenerateSAT (userID);
Input : User ID (userID)
Output: Signed SAT
2 if userID in revocationList then
3 return NULL ;
4 else
5 SAT ←− new SATInstance() ;
6 SAT.add(userID) ;
7 role ←− getRole(userID);
8 policies ←− getPolicyXACML(role);
9 for policy in policies do
10 for permission in policy do
11 /*
12 * MSN = Medical Sensor Node
13 * Add permission for MSN
14 */
15 SAT.addResources(permissin.MSN);
16 SAT.addActions(permissin.MSN.Action);
17 /*
18 * EMR = Electronic Medical Record
19 * Add permission for EMR
20 */
21 SAT.addResources(permissin.EMR);
22 SAT.addResources(permissin.EMR.Action);
23 end
24 end
25 for res in SAT.Resources do
26 cc ←− getContextConstraint(res) ;
27 SAT.add(cc) ;
28 end
29 return Sign(SAT,PrivateKey) ;
30 end

5.4. SAT verification Fig. 9. SAT JSON envelope.

5.4.1. SAT content format

A SAT is encoded in the JSON format. Fig. 9 shows the content
of a SAT. Here, we present the details of a SAT envelope.
Identifier (ID): This is the identifier of the SAT. The issuer gener-
ates a unique random number and assigns it to the ID field. No two
SATs have the same ID.
Issue Instant (II): This is the time, in UTC format, at which the SAT
was issued.
Issuer (IS): This is the identifier of the SAT issuer. It could be an
issuer domain name.
Signature (SIG): This represents the signature of the issuer. The
issuer hashes the SAT and signs with its public key. It prevents
forgery of the issued SAT.
Public Key (IPK): This is the public key of the issuer. The IPK is used
to verify the SIG field.
Resource (RES): This is a universal resource identifier that is used
to uniquely locate a service and resource offered by a medical IoT
device.
Access Right (AR): The AR represents a set of actions (ACT) that the
issuer granted to the user.
Obligation (OB): This has two fields. Not Before (NB) represents
the time before which the token must not be accepted, whereas
Not After (NA) represents the time after which the token must not
be accepted.
Context (CT): This field defines a set of context information that is
used as input to verify context constraints during the SAT evalua-
tion process.
Condition Script Length (CSL): The length of the condition script
in bytes.
Condition Script (CS): A set of conditions and context constraints
are defined and then written as a condition script. A condition
script is essentially a list of instructions embedded with each SAT.
The instructions describe how to evaluate the parameters of a JSON
envelope. The instructions are written in a Forth-like scripting
language.
Forth is an imperative, stack-based computer programming
language that is not Turing-complete. A condition script that is
written in such a language provides the flexibility to change the
parameters of what is needed to accept or deny an incoming
request. Operating systems [72,73] designed for IoT devices are
lightweight. Such a lightweight operating system does not support
dynamic software update, since they lack the security module(s)
to accept and integrate new codes or libraries. However, a script
written in a Forth-like language is easy to update, unlike typical
programs written in C, C++, Python, or Java. Upgrading these pro-
grams requires updating all, or a portion of, the executable code,
 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439
which is complex and expensive, especially for a large number of
medical IoT devices.
5.4.2. SAT verification process
A SAT is verified by a verification process named ACLogic engine
which executes the condition script embedded in the SAT. The
ACLogic engine makes a permit or deny decision according to the
execution result. The ACLogic engine ensures that a request meets
the constraints defined for the requester. The ACLogic engine uses
a data structure called a stack. A SAT is valid if nothing in the
condition script triggers failure and the top stack item is true
(non-zero). A stack is a very simple data structure, which can be
visualized as a stack of cards. A stack allows two operations: push
and pop. Push adds an item on top of the stack. Pop removes the
top item from the stack. When the script execution ends, the stack
should be left with the value TRUE. The ACLogic engine returns
a permit decision if it finds a TRUE value in the stack; otherwise,
it returns a deny decision. To further understand the concept, an
execution of the script is presented as follows:
Condition Script = SIG SPK DECRYPT HASH EQUALVERIFY NB TIME
GRATER_THAN NA TIME LESS_THAN OPERATION_MODE FORALL
BATTERY_STATUS FORALL LOCATION FORALL
The execution of the above condition script is divided into
three parts. Part 1 (see Fig. 10(a)) shows signature verification
steps. The signature verification script is: SIG SPK DECRYPT HASH
EQUALVERIFY. The value of the SIG field is first decrypted with the
issuer’s public keys (SPK); note that, the issuer’s private key is SSK.
Next, the HASH operation generates a hash of the JSON envelope
(SAT packet). The hash value is then matched with the decrypted
SIG value. Here, it is assumed that the SIG values was computed as
SIG = EncryptSSK (Hash(SAT)). If both of the values are found equal
then the SAT has not been forged or tamper with, otherwise the
SAT has been forged.
Part 2 (Fig. 10(b)) shows the verification of the obligation fields.
The script to verify obligations is: NB TIME GRATER_THAN NA
TIME LESS_THAN. The ACLogic engine checks that the current time
(TIME) is greater than (GRATER_THAN) the value of the NB field.
Similarly, The ACLogic also verifies that value of the NA field is less
than (LESS_THAN) the current time (TIME).
Part 3 (Fig. 10(c)) shows the verification of the context con-
straints, and the verification script is: OPERATION_MODE FORALL
BATTERY_STATUS FORALL LOCATION FORALL. According to the script,
the request should be served regardless (FORALL) of the opera-
tional mode and battery status of a medical IoT device, as well as
the location of the user. The FORALL operation ignores the value of
the OperatingMode, BatteryStatus, and Location by removing the
corresponding element from the stack top.
The execution of the condition script is successful, if the stack
top is left with a TRUE value, which means all the conditions and
constraints of the script have been satisfied. Any value other than
TRUE on the stack top indicates, that at least one condition or
constraint was not satisfied.
5.4.3. SAT verification approach
We propose a delegation-based SAT verification approach for
resource-constrained medical devices and their networks (see
Fig. 11). In this approach, a smart gateway, co-located with the
personal area network, performs the SAT verification process on
account of the medical devices. As described in the early part of this
paper, the smart-gateway is a resource-rich entity as compared
to the health devices. The gateway is embedded with the ACLogic
engine and is configured such that it can authorize an incoming
service access request in two steps. In the first step, the gateway
validates the SAT attached to the access request. In the subsequent
431
step, based on the SAT validation outcome (e.g., accept or reject), it
either forwards the request to the requested medical device or re-
jects the request without sending it to the requested device. Thus,
the proposed scheme unburdens resource-limited devices from
compute-intensive operations and reduces storage and memory
requirements for concerned cryptographic hardware or software.
This approach also enables medical devices to serve a real-time
request. The gateway is located closer to the medical devices as
compared to a Cloud authorization server used in the centralized,
semi-distributed, and distributed approaches (see Fig. 12). As such,
the delegation of the SAT verification task to the gateway, instead
of delegating the task to the Cloud, results in a faster processing
of a request. In the following section, we provide the experimen-
tal evaluation of the proposed delegation-based SAT verification
method.
6. Experiment and evaluation
We analyzed and compared the resource efficiency of our pro-
posed delegation-based SAT verification approach (see Fig. 11)
with the distributed SAT verification approach (see Fig. 12(c)). We
provided the performance analysis in terms of energy consump-
tion, computation cost, and communication overhead. Centralized
(see Fig. 12(a)) and semi-distributed (see Fig. 12(b)) approaches
were not considered for experimental evaluation since they are
not suitable for medical IoT systems. In these approaches, a device
located on the edge of the network has to communicate with a
central entity to retrieve authorization decision. Such a communi-
cation has a considerable delay that limits medical sensor serving
a real-time request.
6.1. Experimental setup
The experimental setup and network architecture are shown in
Figs. 13 and 14, respectively. Table 1 presents the details of the
specifications of the experimental devices and network interfaces.
An RE-Mote [74] IoT device performed as a service provider. A
Raspberry Pi model-3 [75] computer was used as a gateway device
to bridge IPv4 and IPv6 networks. The Raspberry Pi device was also
used as a delegation server that performed the SAT verification
process for a constrained device in the delegation-based approach.
A Nexus 4 smart phone and another RE-Mote were used as service
clients. The RE-Motes were operating in a 6LoWPAN network [61].
The 6LoWPAN network enables end-to-end communications over
an IEEE 802.15.4 link [76].
6.2. Prototype implementation
We implemented the ACLogic engine using C language for the
distributed approach. The C-based ACLogic engine was running on
constrained medical IoT (mIoTs) devices powered by popular IoT
operating system Contiki [77]. We also implemented Constrained
Application Protocol (CoAP) [78] servers that were running on
service-provider medical IoT devices (mIoTs). Furthermore, CoAP
client applications were developed for the service-clients, such as
mIoT and smartphone. The client devices consumed the medical
services provided by the service devices. The clients and providers
communicated to each other over user datagram protocol (UDP)
protocol. We ported Relic [79] library to Contiki for performing
cryptographic operations, such as signature verification, message
authentication code (MAC) computation, and AES encryption and
decryption. We also ported Powertrace library [80] to Contiki to
measure energy consumptions of the cryptographic operations and
end-to-end communications.
In the delegation-based approach, the ACLogic engine was
implemented using Java language. The Java-based engine was
432 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439

(a) Part (1/3): Signature verification. (b) Part (2/3): Obligation verification.

(c) Part (3/3): Context constraint verification.

Fig. 10. SAT verification process.

running on the Raspberry Pi computer powered by Ubuntu op-
erating system. The computer was also running a CoAP server
(delegation server) that was implemented using Californium li-
brary [81]. The delegation server provided the SAT verification
service. Note that Java Security framework has been utilized to
implement cryptographic operations of the ACLogic engine.
6.3. Experimental scenarios
We simulated the use-cases of HPA in our experimental scenar-
ios. The HPA can have four use-cases – (a) a physician accessing
electronic medical records (EMR) stored in the HPA databases; (b)
a physician accessing a wearable medical senor remotely through
 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439
Fig. 11. Proposed delegation-based approach.
(a) Centralized approach.
(b) Semi-distributed approach.
(c) Distributed approach.
Fig. 12. Contemporary SAT verification approaches.
the HPA Gateway to retrieve real-time health conditions; (c) a
caregiver accessing a medical sensor locally through the Smart
Gateway; (d) a smart device (medical sensors, actuators, or home
appliances) accessing medical sensors or actuators through the
Smart Gateway in the local network. In use-case a, the Security
Servers located in the Cloud (see Fig. 2) ensure protected access
to the EMR. However, in the local network, the Smart Gateway
ensures authorized access to the medical sensors and actuators
by employing DCCapBAC (use-case b, c, and d). We divided the
433
Fig. 13. Experimental Setup. DS = Delegation Server.
Fig. 14. Experimental network.
Table 1
Experimental Devices’ Specifications.
User (Smartphone) as a Service Client
Hardware → Nexus-4 smart phone. 1.5 GHz Dual CPU, 2 GB RAM, and
16 GB storage, and WiFi network interface
Software → Operating System: Android 4.4.
Runtime: JVM
Responsibility → Service client device
Gateway Device
Hardware → Raspberry Pi Model 3. 1.2 GHz Quad CPU, 1 GB RAM,
16 GB storage, and WiFi and IEEE 802.15.4 dual network interface
Software → Operating System: Ubuntu 16.10.
Runtime: JVM
Responsibility → 6LowPAN border router and Delegation server
Medical IoT Device (Provider or Client)
Device → RE Mote
Hardware → 16 MHz CPU, 8 KB RAM, 40 KB ROM, and IEEE 802.15.4
radio interface
Software → Operating System: Contiki 3.1.
Runtime: C
Responsibility → Medical service provider device and service client
device
use-case b, c, and d into two categories. We denoted use-case b and
c as user-to-device (U2D) interaction and use-case d as device-to-
device (D2D) interaction.
In the experimental scenarios, we considered U2D and D2D
interactions both for delegation-based and distributed SAT vali-
dation approaches. The details of the interactions are shown in
Figs. 15 & 16. In the U2D interaction, the Smartphone sends a
request to the mIoT service-provider. The request is routed through
the Raspberry Pi gateway (see Fig. 15). In the D2D interaction, the
mIoT service-client either sends a request directly to the mIoT
service-provider (see Fig. 16(a)) or the request is routed to the
service-provider through the gateway (see Fig. 16b).
In the distributed approach, the service-provider RE-Mote re-
ceived a SAT from a user and then performed the SAT verification
434 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439

(a) Distributed approach.

(a) Distributed approach.

(b) Delegation-based approach.

Fig. 16. Device to Device interactions. MAC = Message Authentication Code. PSK =
Pre-Shared Key. N = Nonce.

(b) Delegation-based approach.

Fig. 15. User to Device interactions. MAC = Message Authentication Code. PSK =
Pre-Shared Key. N = Nonce.

scheme (see Figs. 15(a) and 16(a)). However, in the delegation- Fig. 17. IEEE 802.15.4 Frame [82].
based approach, the verification task was offloaded to the Rasp-
berry Pi delegation server (see Figs. 15(b) and 16(b)).
For simplicity, we adopted pre-shared key based authentica-
tion. However, devices can use public key based schemes, such as
certificates, for authentication and to establish a shared key. As
shown in Figs. 15 & 16, communicating peers authenticate each
other using a pre-shared key. A client device selects a Nonce (N),
computes a Message Authentication Code (MAC) of the nonce using
a pre-shared key (PSK) as MACPSK (N), and sends them to a service
device. The service device verifies the MACPSK (N) and authenti-
cates the client device. The service device processes the request
only after a successful authentication. To achieve confidentiality,
the client device can encrypt the SAT using the PSK as EncPSK (SAT)
and send the encrypted SAT to the service device.

6.4. Experimental result

Here, first, we provide the rationale for preferring the proposed
delegation-based approach to the distributed approach using a nu-
merical interpretation. Next, we present the experimental results
and performance evaluation of the delegation-based approach in
terms of communication delay, computation overhead, request
completion time, and energy consumption.
The Maximum Transmission Unit (MTU) of the IEEE 802.15.4
link is 54 bytes [82] as shown in Fig. 17. The MTU is reduced to
23 bytes if security at Link-Layer is enabled. Medical devices use
UDP as the transport layer protocol over the IEEE 802.15.4 link.
However, UDP does not support packet fragmentation. Therefore,
6LoWPAN protocol stack implements an adaptation layer (see
Fig. 18) to fragment and reassemble a packet that does not fit
the link’s MTU. The minimal size of a SAT containing authoriza-
tion details for a single service, as shown in Fig. 9, is 360 bytes.
Therefore, a SAT is sent in multiple fragments. The number of
fragment increases if the size of a SAT is increased (↑Size(SAT) −→
↑Fragment Number). Additionally, the size of a SAT increases as
more service-authorization details are added to it (↑Service Count
−→ ↑Size(SAT)).
We provided a correlation between service count and size of a
SAT in Fig. 19. From the graph, we can observe that the number
Fig. 18. Internet Stack Vs. 6LoWPAN Stack [82].
of packet fragments for a SAT increased with the increase in the
size of a SAT. We can also notice that the size of a SAT issued to a
service client increased linearly as the client is given access to more
number of services. This is because more authorization details
were added to the SAT. However, the more the number of packet
fragments the more the packet processing delay and energy con-
sumption. Therefore, we avoid computation and communication
overhead associated with packet fragmentation and reassembly by
offloading the SAT verification to the Delegation Server.
Request Delivery Delay (RDD): The RDD is defined as the time re-
quires to deliver a request from a client to a provider. The delivery
time for a request that does not fit the MTU of the IEEE 802.15.4 link
was computed as the summation of the time needs to fragment a
packet, that contains a SAT as the application payload, at the client,
the time requires for the fragments traveling to the provider, and
the time to reassemble the fragments by the provider. In the D2D
interaction (see Fig. 15), a packet is fragmented at the mIoT client
device and reassembled at the mIoT service provider. However, the
 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439
Fig. 19. Correlation between service count and packet fragmentation.
Fig. 20. Comparison of RDD for distributed and delegation approaches used in user-
to-device interactions.
Fig. 21. Comparison of RDD for distributed and delegation approaches used in
device-to-device interactions.
Gateway fragments a packet before sending it to the IEEE 802.15.4
link in the U2D interaction (see Fig. 16).
We found the RDDs for U2D and D2D interactions as shown
in Figs. 20 and 21. From the graphs, we can see that the
RDD in delegation-based approach is significantly less than in
the distributed approach. In the delegation-based approach (see
Figs. 15(b) & 16(b)), the Delegation Server authenticated the client
device using a pre-shared key (PSK). After that, the Delegation
Server and service provider authenticated each other using an-
other pre-shared key (PSK′ ). The size of the authentication payload
was 32 Bytes (16 Bytes MAC and 16 Bytes Nonce). This 32 Bytes
payload fit the MTU and was sent in a single packet. However,
in the distributed approach (see Figs. 15(a) & 16(a)), a SAT was
sent in multiple packet fragments. These fragments traveled to the
service device which the device had to receive and reassemble. As
a result, the RDD was much higher in distributed approach than in
delegation-based approach.
Runtime Performance: We measured the execution time for SAT
verification and MAC computation at the service device. The SAT
verification is essentially the execution of the condition script as
shown in Fig. 10. The verification process comprises of crypto-
graphic operations for an issuer’s signature verification, such as
AES encryption and SHA-1 hash computation, and a client’s capa-
bility validation. We used Relic library [79] to perform the cryp-
tographic operations. Additionally, we adopted modified Chaskey
435
Fig. 22. Comparison of runtime performance of distributed and delegation ap-
proaches used in user/device-to-device interactions.
MAC scheme [83], which is designed for MSP430 16 MHz IoT
devices, to compute a MAC. We used Contiki’s Clock library [84]
to record the execution time. We measured the execution time as
shown in Algorithm 2, and then presented the results in Fig. 22. The
runtime for delegation-based (RTdel ) and distributed approaches
(RTdis ) were computed as RTdel = ExecutionTime (MACPSK′ (N))
and RTdis = ExecutionTime (AES + SHA-1 + Capability Verifica-
tion). From Fig. 22, we can observe the runtime in delegation-
based approach is much less than in the distributed approach.
This is because the service device did not perform capability and
signature verification operations. The delegation-based approach
unburdened the service device from these computation inten-
sive operations by delegating them to the Delegation Server. The
service device only computed a lightweight MAC to verify the
MACPSK ′ (Nonce) as shown in Step 4 of Figs. 15(a) & 16(a).
Algorithm 2: Runtime Estimation
1: startTime ←− clock_time ()
2: Operation (P) | P ⊂ {AES, SHA-1, MAC, Capability Verify}
3: endTime ←− clock_time ()
endTime−startTime
4: elapsedTime ←− CLOCK_SECOND
Request Completion Time (RCT): An RCT is the total time required
to serve a request. We calculated an RCT as the summation of
request delivery delay, runtime, and response delivery delay. The
RCTs for distributed and delegation-based approaches are pre-
sented in Figs. 23 and 24. From Fig. 23, we can see that the time to
serve a user’s request is about three times faster in the delegation-
based approach than that of the distributed approach. We can
also observe, from Fig. 24, that the distributed approach could
reduce the request complication time by a factor of two. To this
end, we can conclude from Fig. 25 that if the delegation-based
approach is followed then the combined latency of communication
and computation in D2D and U2D interactions can be reduced, on
an average, by 100% and 250%, respectively.
Analysis of Energy Cost: We measured the amount of energy
consumed by the radio frequency (RF) transceiver for sending and
receiving packets and by the CPU for performing cryptographic
operations and fragments reassembly. We recorded the energy
consumption at the service device. We provided the operating
voltage (3.6 volts) and currents (CPU 2400 mA, radio transmit 21
mA and radio listen 23 mA) of RE-Mote as inputs to the Powertrace
library [80] and recorded the energy consumption for crypto-
graphic operations and receiving and transmitting packets. The
Powertrace library uses Contiki’s energy APIs [85] to measure the
power consumption of CPU and radio transceiver. The code snippet
for measuring energy consumption is shown in Algorithm 3. An
analysis and comparison of the energy cost for the delegation-
based and distributed approaches are presented in Fig. 26. From
the graph, we can see that the communication energy consump-
tion increases linearly in the distributed approach; however, it
436 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439
Fig. 23. Analysis of completion time for user-to-device interactions. Dis = Dis-
tributed approach. Del = Delegation-based approach.
Fig. 24. Analysis of completion time for device-to-device interactions. Dis =
Distributed approach. Del = Delegation-based approach.
Fig. 25. % of completion time reduction in the Delegation-based approach.
remains almost constant in the delegation-based approach. In the
distributed approach, the RF transceiver receives multiple packets
fragments of a SAT, and the total number of fragments increases
as the size of a SAT increases. Therefore, as shown in the graph,
the higher the number of service to which a client (user or device)
has access to, the higher the communication energy consumption
for that client in the distributed approach. On the other hand,
in the delegation-based approach, the Delegation Server and the
service mIoT exchanged a fixed sized authentication payload (32
Bytes) that does not exceed link’s MTU. Therefore, the energy
consumption by the RF transceiver is constant regardless of the size
of a SAT.
From Fig. 26, we can also observe that the CPU energy consump-
tion increases as the size of a SAT increases for the distributed
approach. This is because the CPU of the service device had to
process more fragments as the size of a SAT increased. The device
also verified the signature attached to the SAT. The CPU energy
Algorithm 3: Energy Consumption Estimation
1: previousRX ←− energest_type(ENERGEST_TYPE_LISTEN)
2: previousTX ←− energest_type(ENERGEST_TYPE_TX)
3: previousCPU ←− energest_type(ENERGEST_TYPE_CPU)
4: Operation (P) | P ⊂ {AES, SHA-1, MAC, Cap. Verify, Comm.}
5: presentRX ←− energest_type(ENERGEST_TYPE_LISTEN)
6: presentTX ←− energest_type(ENERGEST_TYPE_TX)
7: presentCPU ←− energest_type(ENERGEST_TYPE_CPU)
8: consumedPowerRX ←− presentRX - previousRx
9: consumedPowerTX ←− presentTX - previousTx
10: consumedPowerCPU ←− presentCPU - previousCPU
Fig. 26. Analysis of energy consumption for user/device-to-device interactions.
Dis=Distributed approach. Del=Delegation-based approach.
consumption is higher for verifying a signature for a larger size SAT
than a smaller size SAT. It requires more CPU cycles to compute the
hash (SHA-1) of the larger size SAT. The delegation-based approach
eliminates the signature and capability verification tasks from a
service mIoT; thus, it reduces computational energy consumption.
The mIoT only performs a MAC verification operation for a fixed
sized Nonce that consumes ∼6 mj energy only.
Finally, we can conclude that the delegation-based approach is
more energy efficient than the distributed approach as shown in
Fig. 26. Therefore, the delegation-based approach is appropriate
even for heavy resource constrained medical IoT devices that are
most of the time battery driven.
7. Proposed DCCapBAC vs. existing CapBAC
In this section, we present a comparative discussion between
proposed DCCapBAC and existing CapBAC models.
As shown in Figs. 12(a) and 12(b), both in the centralized
[54–56] and semi-distributed approach [59,60] the ACLogic is im-
plemented by an external entity, such as a central authorization
server, located in the Cloud. In the centralized approach, an IoT
device communicates to the server to validate a SAT every time the
device receives a request. The Authorization server verifies the SAT
and sends the authorization decision to the requested device di-
rectly. In contrast, a gateway device redirects an incoming request
to the external server for the SAT verification. The authorization
decision is sent to the requested device through the gateway. The
mIoT device accepts or rejects a request according to the received
result. However, such communications with the central entity are
inappropriate for the battery-driven medical sensors and actuators
with limited resources. Additionally, these devices operate in a
network with limited bandwidth (e.g., an IEEE 802.15.4 radio link
with 250 kbps data rate). As a result, the interactions with the cloud
entity takes much of the time that requires processing the request.
 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439
Hence, a medical device cannot serve a request immediately, if cen-
tralized and semi-distributed approaches are applied to medical
IoT systems.
To minimize the communication overheads of centralized and
semi-distributed approaches, the distributed approach [57,58]
embeds the ACLogic engine with the medical IoT devices (see
Fig. 12(c)). Upon receiving a request, a mIoT device executes the
ACLogic engine to verify the SAT attached to the request. However,
the medical devices are so resource constrained that they cannot
afford the processing cost of the ACLogic execution, such as sig-
nature verification and capability validation, and storage require-
ments for cryptographic materials, such as keys and certificates
stored on-device memories (RAM and ROM) [86].
The distributed approach provides better scalability over semi-
distributed and centralized approaches. However, they are not
suitable for resource-limited medical sensors due to computation
intensive SAT verification operations. Moreover, it is a complex
procedure to update the authorization policies embedded with the
medical devices. In contrast, managing authorization policies are
simple in the semi-distributed and centralized procedures. How-
ever, they do not scale well for a large number of medical IoT de-
vices. Furthermore, semi-distributed and centralized approaches
serve a request much slower than distributed approach. A request
has to reach to a Cloud Authorization service before it reaches a
medical device.
It is clear from the above discussion that, neither of the existing
CapBAC approaches can achieve the low communication overhead,
inexpensive computation, and load scalability requirements as a
whole demanded by medical IoT systems. However, our proposed
DCCapBAC model resolved these issues by integrating ABAC model
with the CapBAC model. Like the ABAC model, the DCCapBAC
manages authorization policies for a large number of clients and
medical devices while it ensures authorized access to medical
devices that operate on the edge of the network to the same
degree as of the CapBAC model. Thus, although the roles, rules,
and policies are specified using XACML and stored in a central
entity, we eliminate the interaction between the central entity
and a medical device (centralized approach) or a gateway (semi-
distributed approach). Moreover, since SATs are generated dynam-
ically from the XACML policies and issued to clients, the proposed
model does not need to explicitly manage the capabilities of the
clients, unlike conventional CapBAC schemes. Furthermore, in the
proposed model, we let the resource-limited medical sensors leave
from a set of SAT validation tasks, including the issuer’s signature
verification, certificate validation, and SAT revocation list checking
by delegating these computation intensive operations to the smart
gateway co-located with the medical sensors and actuators in the
distributed medical IoT networks.
8. Conclusion
This paper proposes a theoretical framework for an IoT-based
health prescription assistant that helps a patient to properly fol-
low his/her doctors recommendations. Also, a security system is
designed so that each user of this health assistant gets protected
access to the resources and services of interest. For deeper in-
sight into the architectural framework of the proposed security
system, the paper provides an overview of the security compo-
nents, including the identity provider, the registration authority,
and the IoT service provider. The paper demonstrates that pro-
tected access to IoT services and resources can be achieved by
adopting a context-aware capability-based access control model.
Furthermore, this paper shows how operation of said authorization
model can be performed in a two-phase process consisting of
an authentication phase and a SAT-generation phase. In order to
437
understand the SAT-verification process, this paper presents exe-
cution of a condition script. A prototype-based experiment is con-
ducted to validate the different SAT verification schemes. Based the
experimental results, the paper shows how the delegation-based
SAT verification approach outperforms the distributed approach
in terms of both communication and computation latency. Also,
the paper uncovered that the delegation-based SAT verification
approach is more appropriate for heavy resource constrained med-
ical IoT devices, since this approach is found more energy efficient
than the distributed approach. In sum, the proposed model of the
health prescription assistant and the suggested security system are
expected to be useful to researchers and developers working in the
area of the IoT and wireless health.
Acknowledgments
This work was supported in part by ‘The Cross-Ministry Giga
KOREA Project’ grant from the Ministry of Science and ICT, Korea
GK17P0100, in part by Sejong University Faculty Research Fund
20170139, and in part by the National Science Foundation CAREER
Award CNS-1351038.
References
[1] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, M. Ayyash, Internet of
things: A survey on enabling technologies, protocols, and applications, IEEE
Commun. Surveys Tutor. 17 (4) (2015) 2347–2376.
[2] www.gartner.com, The Internet of Things will transform the Data Center, http:
//www.gartner.com/newsroom/id/2684616, 2014.
[3] www.idc.com, Finding success in the new IoT ecosystem: Market to reach
$3.04 trillion and 30 billion connected things in 2020, http://www.idc.com/
getdoc.jsp?containerId=prUS25237214, 2014.
[4] S.R. Islam, M.N. Uddin, K.S. Kwak, The IoT: Exciting possibilities for bettering
lives: Special application scenarios, IEEE Consumer Electron. Mag. 5 (2) (2016)
49–57.
[5] J. Holler, V. Tsiatsis, C. Mulligan, S. Avesand, S. Karnouskos, D. Boyle, From
Machine-to-Machine to the Internet of Things: Introduction to A New Age of
Intelligence, Academic Press, 2014.
[6] L. Tan, N. Wang, Future internet: The internet of things, in: 3rd International
Conference on Advanced Computer Theory and Engineering, ICACTE, Vol. 5,
IEEE, 2010 pp. V5–376.
[7] D. Guinard, V. Trifa, E. Wilde, A resource oriented architecture for the web of
things, in: Internet of Things (IOT), 2010, IEEE, 2010, pp. 1–8.
[8] A. Aijaz, A.H. Aghvami, Cognitive machine-to-machine communications for
Internet-of-Things: A protocol stack perspective, IEEE Internet Things J. 2 (2)
(2015) 103–112.
[9] M. Hassanalieragh, A. Page, T. Soyata, G. Sharma, M. Aktas, G. Mateos, B.
Kantarci, S. Andreescu, Health monitoring and management using Internet-
of-Things (IoT) sensing with cloud-based processing: Opportunities and chal-
lenges, in: IEEE International Conference on Services Computing, SCC, IEEE,
2015, pp. 285–292.
[10] C.O. Rolim, F.L. Koch, C.B. Westphall, J. Werner, A. Fracalossi, G.S. Salvador,
A cloud computing solution for patient’s data collection in health care insti-
tutions, in: Second International Conference on eHealth, Telemedicine, and
Social Medicine, IEEE, 2010, pp. 95–99.
[11] L. Catarinucci, D. De Donno, L. Mainetti, L. Palano, L. Patrono, M.L. Stefanizzi,
L. Tarricone, An iot-aware architecture for smart healthcare systems, IEEE
Internet of Things J. 2 (6) (2015) 515–526.
[12] S.R. Islam, D. Kwak, M.H. Kabir, M. Hossain, K.-S. Kwak, The internet of things
for health care: A comprehensive survey, IEEE Access 3 (2015) 678–708.
[13] K. Saleem, Z. Tan, W. Buchanan, Security for cyber-physical systems in health-
care, in: Health 4.0: How Virtualization and Big Data are Revolutionizing
Healthcare, Springer, 2017, pp. 233–251.
[14] C. Camara, P. Peris-Lopez, J.E. Tapiador, Security and privacy issues in im-
plantable medical devices: A comprehensive survey, J. Biomed. Inform. 55
(2015) 272–289.
[15] T. Webb, S. Dayal, Building the wall: Addressing cybersecurity risks in medical
devices in the USA and Australia, Comput. Law Security Rev. (2017).
[16] M. Khera, Think like a hacker: Insights on the latest attack vectors (and security
controls) for medical device applications, J. Diabetes Sci. Technol. 11 (2) (2017)
207–212.
[17] J. Sametinger, J. Rozenblit, R. Lysecky, P. Ott, Security challenges for medical
devices, Commun. ACM 58 (4) (2015) 74–82.
438 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439
[18] K. Fu, J. Blum, Controlling for cybersecurity risks of medical device software,
Biomed. Instrum. Technol. 48 (s1) (2014) 38–41.
[19] J. Radcliffe, Hacking medical devices for fun and insulin: Breaking the human
SCADA system, in: Black Hat Conference presentation slides, 2011.
[20] B. Farahani, F. Firouzi, V. Chang, M. Badaroglu, N. Constant, K. Mankodiya,
Towards fog-driven IoT eHealth: Promises and challenges of IoT in medicine
and healthcare, Future Gener. Comput. Syst. 78 (2017) 659–676.
[21] T. Wu, F. Wu, J.-M. Redouté, M.R. Yuce, An autonomous wireless body area
network implementation towards IoT connected healthcare applications, IEEE
Access 5 (2017) 11413–11422.
[22] G. Neagu, Ş. Preda, A. Stanciu, V. Florian, A Cloud-IoT based sensing service
for health monitoring, in: E-Health and Bioengineering Conference, EHB, IEEE,
2017, pp. 53–56.
[23] M. Bhatia, S.K. Sood, A comprehensive health assessment framework to fa-
cilitate IoT-assisted smart workouts: A predictive healthcare perspective,
Comput. Ind. 92 (2017) 50–66.
[24] R.K. Lomotey, J. Pry, S. Sriramoju, E. Kaku, R. Deters, Wearable IoT data
architecture, in: IEEE World Congress on Services (SERVICES), IEEE, 2017,
pp. 44–50.
[25] F. Ali, P. Khan, D. Kwak, S.R. Islam, N. Ullah, S.-j. Yoo, K. Kwak, Type-2 Fuzzy
Ontology–aided Recommendation Systems for IoT–based Healthcare, Comput.
Commun. (2017).
[26] S. Pinto, J. Cabral, T. Gomes, We-care: An IoT-based health care system for
elderly people, in: IEEE International Conference on Industrial Technology,
ICIT, IEEE, 2017, pp. 1378–1383.
[27] Y. Zhang, M. Chen, D. Huang, D. Wu, Y. Li, iDoctor: Personalized and profession-
alized medical recommendations based on hybrid matrix factorization, Future
Gener. Comput. Syst. 66 (2017) 30–35.
[28] G. Muhammad, M. Alsulaiman, S.U. Amin, A. Ghoneim, M.F. Alhamid, A facial-
expression monitoring system for improved healthcare in smart cities, IEEE
Access 5 (2017) 10871–10881.
[29] M.S. Hossain, M.A. Rahman, G. Muhammad, Towards energy-aware cloud-
oriented cyber-physical therapy system, Future Gener. Comput. Syst. (2017).
[30] M. Alhussein, Monitoring parkinsons disease in smart cities, IEEE Access
(2017).
[31] S.K. Sood, I. Mahajan, Wearable iot sensor based healthcare system for identi-
fying and controlling chikungunya virus, Comput. Ind. 91 (2017) 33–44.
[32] S.F. Khan, Health care monitoring system in internet of things (iot) by using
rfid, in: International Conference on Industrial Technology and Management,
ICITM, IEEE, 2017, pp. 198–204.
[33] A. Amato, A. Coronato, An iot-aware architecture for smart healthcare coaching
systems, in: Advanced Information Networking and Applications, AINA, 2017
IEEE 31st International Conference on, IEEE, 2017, pp. 1027–1034.
[34] E. Guillén, J. Sánchez, L.R. López, IoT protocol model on healthcare monitoring,
in: VII Latin American Congress on Biomedical Engineering CLAIB, Springer,
2017, pp. 193–196.
[35] C. Doukas, I. Maglogiannis, V. Koufi, F. Malamateniou, G. Vassilacopoulos,
Enabling data protection through PKI encryption in IoT m-Health devices,
in: 12th International Conference on Bioinformatics & Bioengineering, BIBE,
IEEE, 2012, pp. 25–29.
[36] T. Kumar, A. Braeken, M. Liyanage, M. Ylianttila, Identity privacy preserving
biometric based authentication scheme for naked healthcare environment,
in: Communications, ICC, 2017 IEEE International Conference on, IEEE, 2017,
pp. 1–7.
[37] C.T.G. Manogaran, M. Priyan, Centralized fog computing security platform for
iot and cloud in healthcare system, Exploring the Convergence of Big Data and
the Internet of Things (2017) 141.
[38] R. Tso, A. Alelaiwi, S.M.M. Rahman, M.-E. Wu, M.S. Hossain, Privacy-preserving
data communication through secure multi-party computation in healthcare
sensor cloud, J. Signal Process. Syst. 89 (1) (2017) 51–59.
[39] M. Khan, M.T. Jilani, M.K. Khan, M.B. Ahmed, A security framework for wireless
body area network based smart healthcare system, in: International Confer-
ence for Young Researchers in Informatics, Mathematics and Engineering,
CEUR–WS Press, 2017, pp. 80–85.
[40] F. Rahman, M.Z.A. Bhuiyan, S.I. Ahamed, A privacy preserving framework for
RFID based healthcare systems, Future Gener. Comput. Syst. 72 (2017) 339–
352.
[41] A. Yavari, A.S. Panah, D. Georgakopoulos, P.P. Jayaraman, R. van Schyndel,
Scalable role-based data disclosure control for the internet of things, in: 37th
International Conference on Distributed Computing Systems, ICDCS, IEEE,
2017, pp. 2226–2233.
[42] S. Sicari, A. Rizzardi, L. Grieco, G. Piro, A. Coen-Porisini, A policy enforcement
framework for internet of things applications in the smart health, Smart Health
(2017).
[43] D. Recordon, D. Reed, OpenID 2.0: A platform for user-centric identity man-
agement, in: Proceedings of the second ACM workshop on Digital identity
management, ACM, 2006, pp. 11–16.
[44] A. Glória, F. Cercas, N. Souto, Design and implementation of an iot gateway to
create smart environments, Procedia Comput. Sci. 109 (2017) 568–575.
[45] A.-M. Rahmani, N.K. Thanigaivelan, T.N. Gia, J. Granados, B. Negash, P. Liljeberg,
H. Tenhunen, Smart e-health gateway: bringing intelligence to internet-of-
things based ubiquitous healthcare systems, in: 12th Annual IEEE Consumer
Communications and Networking Conference, CCNC, IEEE, 2015, pp. 826–834.
[46] W. Shen, Y. Xu, D. Xie, T. Zhang, A. Johansson, Smart border routers for
ehealthcare wireless sensor networks, in: 7th International Conference on
Wireless Communications, Networking and Mobile Computing, WiCOM, IEEE,
2011, pp. 1–4.
[47] J. Qian, S. Hinrichs, K. Nahrstedt, ACLA: A framework for access control list
(ACL) analysis and optimization, in: Communications and Multimedia Security
Issues of the New Century, Springer, 2001, pp. 197–211.
[48] V. Grout, J.N. Davies, A simplified method for optimising sequentially pro-
cessed access control lists, in: Sixth Advanced International Conference on
Telecommunications, AICT, IEEE, 2010, pp. 347–352.
[49] X. Jin, R. Sandhu, R. Krishnan, RABAC: Role-centric attribute-based access
control, Comput. Netw. Security (2012) 84–96.
[50] D. Servos, S.L. Osborn, Current research and open problems in attribute-based
access control, ACM Computing Surveys (CSUR) 49 (4) (2017) 65.
[51] L. Snyder, Formal models of capability-based protection systems, IEEE Trans.
Comput. C–30 (3) (1981) 172–181.
[52] S.J. Mullender, A.S. Tanenbaum, The design of a capability-based distributed
operating system, Comput. J. 29 (4) (1986) 289–299.
[53] Landau, Charles, Security in a secure capability-based system, Oper. Syst. Rev.
(1989) 2–4.
[54] S. Gusmeroli, S. Piccione, D. Rotondi, A capability-based security approach to
manage access control in the Internet of Things, Math. Comput. Modelling
(2013).
[55] L. Seitz, G. Selander, C. Gehrmann, Authorization framework for the Internet-
of-Things, in: WowMoM, IEEE, 2013, pp. 1–6.
[56] P.P. Pereira, J. Eliasson, J. Delsing, An authentication and access control
framework for CoAP-based Internet of Things, in: IECON, IEEE, 2014, pp. 5293–
5299.
[57] J.L. Hernández-Ramos, A.J. Jara, L. Marın, A.F. Skarmeta, Distributed capability-
based access control for the Internet of Things, JISIS (2013).
[58] P.N. Mahalle, B. Anggorojati, N.R. Prasad, R. Prasad, Identity authentication
and capability based access control (IACAC) for the Internet of Things, J. Cyber
Security Mob. (2013).
[59] S. Cirani, M. Picone, P. Gonizzi, L. Veltri, G. Ferrari, IoT-OAS: An OAuth-based
authorization service architecture for secure services in IoT scenarios, J. Sen-
sors (2015).
[60] S. Gerdes, O. Bergmann, C. Bormann, Delegated CoAP authentication and
authorization framework (DCAF), ETF Internet Draft, 2014.
[61] C.P.P. Schumacher, N. Kushalnagar, G. Montenegro, IPv6 over low-power wire-
less personal area networks (6LoWPANs): Overview, assumptions, problem
statement, and goals, RFC 4919 (2007).
[62] H. Qin, Y. Wang, W. Zhang, ZigBee-Assisted WiFi transmission for multi-
interface mobile devices, in: MobiQuitous, Vol. 104, Springer, 2011, pp. 248–
259.
[63] K.-H. Chang, Bluetooth: A viable solution for IoT?[Industry Perspectives], IEEE
Wireless Commun. 21 (6) (2014) 6–7.
[64] E.R. Tufte, G.M. Schmieg, The visual display of quantitative information, Amer.
J. Phys. 53 (11) (1985) 1117–1118.
[65] S.O. Torres, H. Eicher-Miller, C. Boushey, D. Ebert, R. Maciejewski, Applied
visual analytics for exploring the national health and nutrition examination
survey, in: 45th Hawaii International Conference on ystem Science, HICSS,
IEEE, 2012, pp. 1855–1863.
[66] C.G. Healey, Choosing effective colours for data visualization, in: Seventh Int.
Conference on Visualization, IEEE, 1996, pp. 263–270.
[67] Intel, Intel IoT Gateway, https://www.intel.com/content/www/us/en/embedd
ed/solutions/iot-gateway/overview.html, accessed on May 4, 2017, 2017..
[68] Weptech, Weptech 6lowpan gateway, https://www.weptech.de/en/6lowpan/
gateway-saker.html, accessed on June 6, 2017, 2017.
[69] G. Zhang, J. Tian, An extended role based access control model for the inter-
net of things, in: Proceeding of the International Conference on Information
Networking and Automation, ICINA, Vol. 1, IEEE, 2010 pp. V1–319.
[70] OASIS, XACML v3.0 Administration and Delegation Profile Version 1.0, http:
//www.oasis-open.org, 2009.
[71] T. Bray, The javascript object notation (JSON) data interchange format, RFC
7159, http://tools.ietf.org/html/rfc7159.html, 2014.
[72] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo, D. Gay,
J. Hill, M. Welsh, E. Brewer, et al., Tinyos: An operating system for sensor
networks, in: Ambient Intelligence, Springer, 2005, pp. 115–148.
[73] A. Dunkels, B. Grönvall, T. Voigt, Contiki-a lightweight and flexible operating
system for tiny networked sensors, in: Proceeding of the International Confer-
ence on Local Computer Networks, IEEE, 2004, pp. 455–462.
[74] Re-Mote, Z1 6LoWPAN IoT Device, 2017, http://zolertia.io/z1.
[75] R. Pi, A Tiny and low cost smart device, https://www.raspberrypi.org/, https:
//www.raspberrypi.org/products/raspberry-pi-3-model-b/, accessed on May
18, 2017, 2016.
 M. Hossain et al. / Future Generation Computer Systems 82 (2018) 422–439 439

[76] A.F. Molisch, K. Balakrishnan, C.-C. Chong, S. Emami, A. Fort, J. Karedal, J. Farman Ali received the B.S. degree in Computer Engi-
Kunisch, H. Schantz, U. Schuster, K. Siwiak, IEEE 802.15.4a channel model-final neering from the University of Peshawar, Pakistan in 2011
report, IEEE P802 15 (04) (2004) 0662. and the M.S. degree in Computer Science from Gyeongsang
[77] Contiki, Contiki OS: An open source operating system for the Internet of Things, National University, South Korea in 2014. From 2015, he is
http://www.contiki-os.org/, 2016. studying at the Department of Information and Communi-
[78] Z. Shelby, K. Hartke, C. Bormann, The constrained application protocol (CoAP), cation Engineering at Inha University, South Korea doing
RFC, IETF (2014). the Ph.D. degree. His current research interests include
[79] Relic, An Efficient Library for Cryptography, https://github.com/relic-toolkit, Opinion Mining, Ontology, Fuzzy logic, Artificial Intelli-
2017. gence, and Machine Learning.
[80] Powertrace A power measuring library for contiki iot devices, https://github.
com/sonhan/contiki, https://github.com/KineticBattery/Powertrace, accessed
on June 20, 2017 2017.
[81] Californium, A Java-based CoAP Server, https://eclipse.org/californium/, 2017.
[82] G. Montenegro, N. Kushalnagar, J. Hui, D. Culler, Transmission of IPv6 packets
over IEEE 802.15. 4 networks, IETF, RFC 4944, 2007.
Kyung-Sup Kwak received the Ph.D. degree from the Uni-
[83] G. Lee, H. Seo, T. Park, H. Kim, Optimized implementation of chaskey MAC on
versity of California at San Diego in 1988. From 1988 to
16-bit MSP430, in: Ninth International Conference on Ubiquitous and Future
1989, he was with Hughes Network Systems, San Diego,
Networks, ICUFN, IEEE, 2017, pp. 904–909.
CA, USA. From 1989 to 1990, he was with the IBM Net-
[84] Contiki, Contiki clock library, http://www.eistec.se/docs/contiki/a02184.html,
work Analysis Center, Research Triangle Park, NC, USA.
accessed on May 8, 2017, 2017.
Since then, he has been with the School of Information
[85] Contiki, Contiki apis for measuring energy consumption, http://contiki.source
and Communication Engineering, Inha University, South
forge.net/docs/2.6/a00452_source.html, 2017..
Korea, as a Professor, where he had been the Dean of the
[86] M.M. Hossain, M. Fotouhi, R. Hasan, Towards an analysis of security issues,
Graduate School of Information Technology and Telecom-
challenges, and open problems in the internet of things, in: IEEE World
munications from 2001 to 2002. He has been the Director
Congress on Services, 2015, pp. 21–28.
of the UWB Wireless Communications Research Center
(formerly Key National IT Research Center), South Korea, since 2003. In 2006, he
served as the President of Korean Institute of Communication Sciences, and in 2009,
the President of Korea Institute of Intelligent Transport Systems. In 2008, he had
Mahmud Hossain received the B.S. degree in Computer
been selected for Inha Fellow Professor and now for Inha Hanlim Fellow Professor.
Science and Engineering from Bangladesh University of
Dr. Kwak published more than 200 peer-reviewed journal papers and served as
Science and Technology, Bangladesh in 2009. He is cur-
TPC/Track chairs/organizing chairs for several IEEE related conferences. His research
rently pursuing his Ph.D. degree at the Secure and Trust-
interests include wireless communications, UWB systems, sensor networks, WBAN,
worthy Computing Lab, University of Alabama at Birming-
and nano communications. He was a recipient of the number of awards, including
ham, USA. Before that, he served Samsung R&D Institute
the Engineering College Achievement Award from Inha University, the LG Paper
Bangladesh (SRBD) as a Lead Engineer at the Dept. of
Award, the Motorola Paper Award, the Haedong Prize of research, and various
Solution Lab for the period June 2010 to August 2014. His
government awards from the Ministry of ICT, the President, and the Prime Minister
research interests include security and privacy of Internet
of Korea, for his excellent research performances.
of Things, embedded systems, and mobile and cloud com-
puting.

S.M. Riazul Islam received the B.S. and M.S. degrees
in Applied Physics and Electronics from University of
Dhaka, Bangladesh in 2003, and 2005, respectively and
the Ph.D. degree in Information and Communication En-
gineering from Inha University, South Korea in 2012. He
has been working at Sejong University, south Korea as
an Assistant Professor at the Department of Computer
Science and Engineering since March 2017. From 2014
to 2017, he worked at Inha University, South Korea as a
Research Professor at the UWB Wireless Communications
Research Center. Dr. Islam was with the University of
Dhaka, Bangladesh as an Assistant Professor and Lecturer at the Dept. of Electrical
and Electronic Engineering (formerly Dept. of Applied Physics, Electronics & Com-
munication Engineering) for the period September 2005 to March 2014. In 2014,
he worked at the Samsung R&D Institute Bangladesh (SRBD) as a Chief Engineer
at the Dept. of Solution Lab for six months. His research interests include wireless
communications, signal processing for communications, and enabling technologies
for 5G and beyond.
Ragib Hasan, is an Associate Professor at the Department
of Computer and Information Sciences at the University of
Alabama at Birmingham. Prior to joining UAB, He received
his Ph.D. and M.S. in Computer Science from the Uni-
versity of Illinois at Urbana Champaign in October, 2009,
and December, 2005, respectively, and was an NSF/CRA
Computing Innovation Fellow post-doc at the Department
of Computer Science, Johns Hopkins University. Hasan has
received multiple awards in his career, including the 2014
NSF CAREER Award, 2013 Google RISE Award, and 2009
NSF Computing Innovation Fellowship.