2020 7th International Conference on Internet of Things: Systems, Management and Security (IOTSMS) | 978-0-7381-2460-5/20/$31.00 ©2020 IEEE | DOI: 10.1109/IOTSMS52051.2020.9340231
Security and Privacy of Medical Internet of Things Devices for
Smart Homes
Paige Harvey1 , Otily Toutsop1 , Kevin Kornegay1 , Excel Alale2 , and Don Reaves3 ,
1 Department
of Electrical and Computer Engineering, Morgan State University, Baltimore, MD 21251 USA
Department of Electrical and Computer Engineering, University of Maryland, College Park, MD 20742 USA
3 Frederick Douglas High School, 2301 Gwynns Falls Pkwy, Baltimore, MD 21217
pahar9@morgan.edu, ottou1@morgan.edu, kevin.kornegay@morgan.edu, ealale@terpmail.umd.edu, doreaves@gmail.com
2
Abstract: The Internet of Things, IoT, provides various applications in the health and care sector, enhancing assisted living, and
the ability to remotely monitor patients in hospitals, at homes, and in care facilities [1]. Additionally, many patients who require
constant health monitoring prefer the comfort of home monitoring to hospital environments [2]. Therefore, with the increased
interest in smart home configurations and the need for Medical IoT, MIoT, device development, we may witness a rise in in-home
smart healthcare set-ups. In this paper, we present a Ph.D. research proposing an improve architecture for ensuring security and
privacy of smart medical devices in smart home environments.
Index Terms—Home Automation, Healthcare, Internet of Things, Internet of Medical Things, Medical IoT, Privacy, Smart Homes,
Security
I. T HE C ORE P ROBLEM OF P H D R ESEARCH
S the adoption of IoT expands, two emerging areas
that have gained recent attraction are smart homes and
healthcare. The interconnectivity of smart medical technologies in smart home environments may present several benefits,
including Remote Patient Monitoring, RPM, or telehealth,
which allows patients to use smart medical technologies
along with mobile devices to capture vitals, real-time, before
getting transmitted to medical healthcare professionals, HCP,
for further evaluation, and overall healthcare cost reduction
through limiting hospital visits for every medical-related inquiry. Unfortunately, the increasing number of smart home
devices installed on home networks makes them an attractive
target for hackers [1].Additionally, not every home automation
or MIoT, also known as the Internet of Medical Things,
IoMT, device owner adheres to proper internet and networking
etiquette when installing appliances in the home. Therefore,
several of the risks that must be assumed by users, as well
as manufacturers, include: malicious actors discovering the
brand and dosages of medications prescribed, the time patients
might leave and arrive home from work, which devices do
patients rely on for medical purposes, and the email accounts
that are associated with the sensitive data, just to name a
few. However, the biggest challenge is the interoperability
of devices, which can lead to a network being exposed to
new security vulnerabilities and additional risk [3]. Therefore,
throughout this research, we seek to evaluate heterogeneous
devices, manufacturers, and communication protocols to determine a capable system architecture that will allow users
to maintain the integrity of their device’s behavior and the
optimal security and privacy levels associated with patient
data.
In [4], the STRIDE method is utilized to provide security
and privacy recommendations for various IoT applications, in-
A
cluding smart homes and healthcare. The acronym for STRIDE
can be found below:
•
•
•
•
•
•
Spoofing – a potential attacker pretending to be the user
of the application or system
Tampering – modification of systems and/or resources
that are not supposed to be modified
Repudiation – claiming that nothing will interfere with
the system, regardless of whether there is an interference
present
Information Disclosure – exposing information to people
who do not have the authorization to view that information
Denial of Service – attacks that deter a system from
providing services by causing it to crash or significantly
degrade performance.
Elevated Privileges – malicious users increasing their
privileges on a system
Using STRIDE as a basis, Microsoft’s threat modeling approach was also leveraged to identify perceived threats as well
as provided further recommendations for ensuring security and
privacy concerns are addressed for various scenarios.
In essence, a threat model is a system that recognizes,
classifies, organizes, and rates threats based on a thorough
analysis of an organization’s architecture, helps execute an
organized way to deal with security business impact, and
aids in describing the attack surface of edge devices. The
threats that have been identified for both smart homes and
healthcare include: data collection and control issues, hacking
of smart home devices to gain access to the home and
resources, and manipulation or hacking of devices to obtain
health records or disrupt service. Ultimately, the authors of this
work suggest a security and privacy by design approach for
IoT device development and routine monitoring of networks
for suspicious behavior as well as segregation of user-level
and administrative privileges in smart homes. In the following
paragraphs, we will discuss related work. In [5], the authors
Authorized licensed use limited to: Carleton University. Downloaded on June 19,2021 at 21:51:22 UTC from IEEE Xplore. Restrictions apply.
address privacy awareness through proposing a system model
that centers around assessing user preferences for data collection, storage, analysis, and delivery, resulting in the subsequent
anonymization and obfuscation of specified patient-sensitive
parameters before being sent to designated institutions.
In [2], the authors explore a smart intensive care unit, ICU,
scenario to propose a system architecture that reduces the
cost associated with healthcare and improves real-time patient
monitoring using sensors. Leveraging ICU bedside monitors,
Microsoft’s XBOX KinectTM sensors, for monitoring patient
vitals and movement, and an additional sensor board to detect
environmental factors, gathering information about the indoor
environment, were evaluated. With the implementation of
various servers and databases, a user-friendly interface was
developed to allow doctors and nurses to stay informed with
and implement preventative measures when necessary.
In [6], the authors present a system architecture that addresses data acquisition and transmission, cloud processing,
and analytics for RPM and healthcare cost reduction. Additionally, in this approach, machine learning techniques were
introduced along with various sensors, bio-markers, and health
records to further aid with analysis and visualization towards
disease detection.
In [7], the authors introduce Syndrome, their proposed
framework that addresses hardware security concerns for
MIoT devices. This work leverages threat modeling and IDS
to tackle malware activity detection and operating system, OS,
interrupts through real-time MIoT monitoring. In [8], the authors propose an end-to-end solution for RPM, including data
and video monitoring, notification of abnormal conditions, and
control of smart appliances. Additional contributions of this
work include interoperability of various IoT sensors and ease
of access, and a cross-platform user experience.
The remainder of this paper is structured as followed. In
section II, we discuss research challenges, section III, the main
ideas are outlined, section IV, the proposed research plan is
introduced, and section V, expected results are presented.
II. RESEARCH CHALLENGES
Our current research objectives have yielded several questions, otherwise referred to as research challenges; they are as
follows:
• How do we ensure device interoperability, the security of
various communication protocols after configuration (i.e.,
Bluetooth, WiFi, Zig-Bee)?
• Will authorized voice-activated devices pose an additional
threat to medical devices if they are interconnected?
• How do we defend against unauthorized attempts to
access networked devices?
• How can we reassure consumers of smart medical technologies, as well as smart home users, that their personal
data will not be mishandled?
• What additional threats, if any, might be posed to this
architecture as well connected MIoT devices and data
if non-medical related home automation devices and
systems become infected (i.e. home router, refrigerator,
door lock)?
III. EXPLANATION OF THE MAIN IDEAS
This research’s primary motivation is to protect individuals
who rely on smart medical devices for daily use and various
health concerns and are interested in introducing these devices
onto their home network. In table I, the related work presented
in section I are compared to the main ideas presented below:
• Privacy for Home Users – Unauthorized personnel should
not be granted access to or know that the medical devices
that exist on the network or the patients who utilize them.
• Security of Personal Data – Ensuring unauthorized personnel will not have access to patient sensitive information ranging from medical record numbers to email
addresses, physical traits, or genetic make-up.
• Prevent Modification of Patient Data – If unauthorized
personnel can view patient sensitive information (i.e.,
test results, medication, etc.), notify authorized users, and
perform checks to ensure data integrity.
• Cyber Resilience – In the event of a cyber-attack, device
functionality should not be affected.
• Installing Secure Updates – When the manufacturer of
a product performs routine updates, the device(s) should
not be rendered vulnerable to attacks or data breaches.
• Decommissioning – Once a device is removed from the
ecosystem or taken outside of the home, the device, data,
and configurations should reset to reduce attackers from
accessing or stealing data.
IV. PROPOSED RESEARCH PLAN
A. Threat Modeling and Intrusion Detection
It is evident by the literature searches in table 1, that
existing architectures already tackle security and privacy for
the MIoT area extensively. However, few architectures may be
adaptable for smart home environments as they do not address
the main ideas and research questions henceforth presented
in this work. Thus, in this phase of our research, we will
develop a small-scale testbed, depicted in figure 1, to further
evaluate said concepts by implementing and evaluating threat
modeling effectiveness. The Raspberry Pi and the WiFi Dongle
will serve as a wireless access point or gateway on which the
healthcare set-up will rely upon, and devices will be granted
internet access and monitored without disrupting the entire
home network. The Raspberry Pi will also host the database to
collect and store patient-sensitive data for visualization, using
an external touch screen. Additionally, an Echo Dot will have
access to the database, reporting the most recent readings for
home users audibly. In this ecosystem, we will be exploiting
two commercial MIoT devices, the Smart Glucose Monitoring
System and the Smart No-Touch Forehead Thermometer, as
well as the AD8232 ECG Module and a Smart Switch.
Additionally, while the concept of Intrusion Detection Systems, IDS, is not entirely novel and several applications
currently exist, collecting and analyzing IoMT datasets on
networks also that consist of home automation devices is
one contribution of this work. Stemming from this network
configuration and data capture, we will perform various cyberrelated attacks to assess the impact of interconnected devices
and resources. In this set-up, we will evaluate a scenario in
Authorized licensed use limited to: Carleton University. Downloaded on June 19,2021 at 21:51:22 UTC from IEEE Xplore. Restrictions apply.
TABLE I
COMPARISONS OF RELATED WORKS BASED ON THE MAIN IDEAS
for consumer safety, as the modification of devices or data
may lead to adverse health effects, including end of life for
end-users. As evident in ”Security and Privacy Issues with IoT
in Healthcare” and as early as 2015, a researcher was able to
successfully administer a lethal drug dosage via an infusion
pump, further emphasizing the dangers of device misusage and
medical malpractice.
Beginning with the Smart Glucose Monitoring System and
the Thermometer, we will examine several scenarios, two of
which focus on the glucose meter and are depicted in figures
2 and 3, with the primary objectives being:
•
Fig. 1. Small Scale Testbed Network Configuration
which a patient is interested in sending their sensitive medical
information and device data readings to their HCP. Thus,
interference with the network by malicious personnel may look
like the following.
•
•
•
User(s) credentials being compromised,
Home automation and/or medical devices or services
being unavailable, modified, or disrupted,
Incorrect readings, which may lead to a misdiagnosis or
even death
The first item from above poses a serious concern for
consumers who use the same access credentials across multiple
platforms and devices. Once an attacker has the credentials,
they may have access to everything, including banking, medical record number, etc. However, the second item has the
potential to affect both smart home users and MIoT device
holders as the confidentiality, integrity, and availability are all
called into question. The final item presents the greatest risk
•
Attacking the Bluetooth protocol to disrupt the devices’
typical behavior and
Exploiting web-based applications associated with smart
devices and exposes additional threats by allowing attackers to export data readings, as a PDF, CSV, or Excel
spreadsheet, as well as transmitting the data over the
internet.
Next, utilizing the AD8232 ECG Module, we will develop
our own medical IoT device to become better acquainted with
the role manufacturers play in the development or lifecycle of
a product, from specifying the communication protocol(s) [9],
[10] [11] to managing data, and installing updates. Exploring
the manufacture’s role offers several benefits, including incorporating security and privacy in the design phase. Additionally,
this step will allow us to investigate the behavioral patterns of
various and interconnected communication protocols.
Lastly, we will evaluate the issues that may arise for
devices that require power from an external outlet, non-battery
operated. In this case, we will assume the patient will be using
a smart switch to supply power to said devices. If a malicious
person interferes with this device, connected technologies’
performance may also be rendered vulnerable to attacks. Thus,
Authorized licensed use limited to: Carleton University. Downloaded on June 19,2021 at 21:51:22 UTC from IEEE Xplore. Restrictions apply.
Fig. 2. Man-in-the-Middle (MitM) Attack Scenario
Fig. 3. Social Engineering Attack Scenario
the final solution must also be able to detect and defend against
attacks aimed towards the smart home’s interconnectivity as
well.
B. Full-Scale System Framework
Bringing IoT into the healthcare sector will raise complications because these organizations are dealing with networks
outside of the secure networks they have created. Having a
medical device connected to a home network, cellular signals,
and public WiFi, and feeding data back to a hospital’s network
presents another critical area for weaknesses [4]. Therefore, in
this work, we will consider only the smart home user’s impact,
not the entire system.
In our approach, we consider a fully automated smart home,
and we will isolate the smart medical devices on the network
using a wireless access point as a gateway, same as in the
first phase. We will profile the connected MIoT devices and
collect data using a secure database and server, respectively.
Here we will also be interested in developing a graphical
user interface, GUI, to create user profiles and assess user
preferences to incorporate with data management strategies.
Our architecture is depicted in figure 4, and in the following
sections, we will further discuss the considerations for each
of the core concepts.
1) Notification Center - The notification center will be
an available feature via the client-side application; if
a STRIDE event occurs, the following alarms will be
presented:
• Cyber Incident Response – This alarm will be triggered if a malicious actor aims to access the network
remotely via bypassing the isolated gateway, providing incorrect user login credentials, interacting with
the Alexa voice assistant, or attempting to view or
manipulate the secure database. When the alarm is
sounded, the secure database will encrypt the last
trusted instance for data collected before removing
itself from the network and critical systems will
be taken offline until the malicious person or code
is removed from critical systems as well as the
network.
• Physical Incident Response – This alarm will be
triggered when there is a physical event in which
a device has been altered, removed, or further tampered with physically. If the device is removed from
the network, all previous data will remain on the
device server; however the devices themselves will
be factory reset in order to prevent data breaches.
However, if the devices have instead been tampered
with, a report will be generated for the end-user
and the last saved data will be saved on the device
server; no further data will be considered until the
device has returned to normal functionality.
2) Medical IoT Device Server –This server will be responsible for profiling and hosting the connected smart medical devices. Here we address access control, a method
for effectively monitoring the access of resources and
prevention of unauthorized flow of information [12].
3) Secure Database – In our approach, we will be addressing the security preferences of home users as well as
users of smart medical devices, thus the secure database
will be in charge of the following:
• Data Storage – data collected at the IoT Device
server will be assessed using privacy awareness
preferences before being sent the secure database
for storage
• Data Visualization – the data collected on the secure
database will be sent to the touch screen, via the
application, to visualize patient vitals
• Audible Data – the Echo Dot voice assistant will
also have access to the secure database with limitedread-only access; this will allow for recent data to
be heard audibly at the designated user’s request
4) Trusted Server – This server will be the centralized
server responsible for performing secure handshakes
between the device manufacturer, hospital staff, and their
respective systems and services. This server will also be
responsible for ensuring the information is what is says
it is, as it is coming from a trusted source.
In this design, we recommend doctors allocate a designated
computer(s) to host the software and communicate with patients. Additionally, since human error is also a great concern
Authorized licensed use limited to: Carleton University. Downloaded on June 19,2021 at 21:51:22 UTC from IEEE Xplore. Restrictions apply.
Fig. 4. Proposed Large Scale Network Configuration
for IoT devices, doctors will only be allowed limited access to
view patient sensitive data, monitor vitals, as well as provide
medication recommendations; not supply medication dosages
or operate machinery. On the user’s end, once the doctor
provides recommendations, they may review and either accept
or decline recommended medications and dosages as well as
other treatments before being disseminated to users.
The medical physician will then receive a report of recommendations that were accepted or ignored by users. Manufactures of IoT devices will also be granted limited access
to the network configuration to provide updates securely and
only their specific networked device. The trusted server will
be in charge of verifying and validating the updates provided
by manufacturers, alerting users of the bugs being fixed and
the critical systems that may be affected during the update.
V. EXPECTED RESULTS
Ultimately, manufacturers of smart medical devices should
adopt a security-by-design and privacy-by-design method for
the development of their devices [4]. However, many of the
devices on the shelves today do not adhere to this standard;
thus, what is to be said for consumers who have already
purchased smart medical devices, especially users who intend
to utilize their devices in smart home ecosystems? At the
completion of this research, we expect to provide a secure
system architecture independent of whether or not a device
has been designed with security and privacy in mind, which
will reassure consumers of smart medical devices as well as
smart home users. The completed solution will address privacy
awareness concerns for MIoT devices and provide securelimited access for manufacturers to supply secure updates and
medical professionals to monitor patient vitals and provide
health recommendations remotely for smart home users.
ACKNOWLEDGMENT
This work was supported by the Center for Reverse Engineering and Assured Microelectronics (CREAM) research lab
at Morgan State University. We would also like to thank Myles
Wright-Walker as well as the reviewers for their additional
insight.
R EFERENCES
[1] A. J. Brush, J. Albrecht, and R. Miller, “Smart homes,”
IEEE Pervasive Computing, vol. 19, no. 2, pp. 69–73, 2020,
doi:10.1109/MPRV.2020.2977739, accessed = 2019-08-31.
[2] I. Chiuchisan, H. Costin, and O. Geman, “Adopting the internet of things
technologies in health care systems,” in 2014 International Conference
and Exposition on Electrical and Power Engineering (EPE), 2014, pp.
532–535, doi:10.1109/ICEPE.2014.6969965, accessed = 2019-08-31.
[3] A. Chacko and T. Hayajneh, “Security and privacy issues with iot
in healthcare,” EAI Endorsed Transactions on Pervasive Health and
Technology, vol. 4, no. 14, 2018, accessed = 2019-08-31.
[4] A. Seeam, O. S. Ogbeh, S. Guness, and X. Bellekens, “Threat modeling
and security issues for the internet of things,” in 2019 Conference on
Next Generation Computing Applications (NextComp). IEEE, 2019, pp.
1–8, doi:10.110/NEXTCOMP.2019.8883642 accessed = 2020-07-20.
[5] I. Psychoula, L. Chen, and O. Amft, “Privacy risk awareness in wearables and the internet of things,” IEEE Pervasive Computing, vol. 19,
no. 3, pp. 60–66, 2020, doi:10.1109/MPRV.2020.2997616 accessed =
2020-08-20.
[6] M. Hassanalieragh, A. Page, T. Soyata, G. Sharma, M. Aktas, G. Mateos,
B. Kantarci, and S. Andreescu, “Health monitoring and management
using internet-of-things (iot) sensing with cloud-based processing: Opportunities and challenges,” in 2015 IEEE International Conference on
Services Computing, 2015, pp. 285–292, accessed = 2019-08-28.
[7] N. Sehatbakhsh, M. Alam, A. Nazari, A. Zajic, and M. Prvulovic,
“Syndrome: Spectral analysis for anomaly detection on medical iot
and embedded devices,” in 2018 IEEE International Symposium on
Hardware Oriented Security and Trust (HOST), 2018, pp. 1–8, accessed
= 2019-08-30.
[8] H. Moustafa, E. M. Schooler, G. Shen, and S. Kamath, “Remote
monitoring and medical devices control in ehealth,” in 2016 IEEE
12th International Conference on Wireless and Mobile Computing,
Networking and Communications (WiMob), 2016, pp. 1–8, accessed =
2019-08-31.
Authorized licensed use limited to: Carleton University. Downloaded on June 19,2021 at 21:51:22 UTC from IEEE Xplore. Restrictions apply.
[9] S. Shebi Ahammed and B. C. Pillai, “Design of wi-fi based mobile
electrocardiogram monitoring system on concerto platform,” Procedia
Engineering, vol. 64, pp. 65 – 73, 2013, international Conference
on Design and Manufacturing (IConDM2013), accessed = 2020-0902. [Online]. Available: http://www.sciencedirect.com/science/article/
pii/S1877705813015919
[10] A. AKBULUT, “Implementation of zigbee (ieee 802.15. 4) based
wireless ecg measurement system,” Uluslararası Mühendislik
Araştırma ve Geliştirme Dergisi, vol. 9, no. 3, pp. 43–53, 2017,
doi:10.29137/umagd.360670 accessed = 2020-09-02.
[11] H. Yang and J. Chai, “The study and design of a wireless ecg monitoring
system,” Biomedical Instrumentation & Technology, vol. 46, no. 5, pp.
395–399, 2012, doi:10.2345/0899-8205-46.5.395 accessed = 2020-0902.
[12] J. Qiu, Z. Tian, C. Du, Q. Zuo, S. Su, and B. Fang, “A survey on access
control in the age of internet of things,” IEEE Internet of Things Journal,
vol. 7, no. 6, pp. 4682–4696, 2020, doi10.1109/JIOT.2020.2969326
accessed = 2020-09-02.
Authorized licensed use limited to: Carleton University. Downloaded on June 19,2021 at 21:51:22 UTC from IEEE Xplore. Restrictions apply.