Bachelor Degree Project Internet of things security in ...1239105/FULLTEXT01.pdf · production. The report found that the lack of standardisation has lead to errors that could be

Author: Michael JohanssonSupervisor: Jesper AnderssonExternal supervisor: JonasWennerbergSemester: VT 2018Subject: Computer Science

Bachelor Degree Project

Internet of things security inhealthcare- A test-suite and standard review

Abstract

Internet of things is getting more and more popular in healthcare as it comes withbenefits that help with efficiency in saving lives and reduce its cost, but it alsopresents a new attack vector for an attacker to steal or manipulate information sentbetween them. This report will focus on three properties in the definition of security,confidentiality, integrity and access control. The report will look into what chal-lenges there is in healthcare IoT today through a literature review and from thosechallenges look into what could minimise these challenges before a device gets intoproduction. The report found that the lack of standardisation has lead to errors thatcould be easily prevented by following a guideline of tests as those from the Eu-ropean Union Agency for Network and Information Security [1], or by running apenetration test with the tools brought up in the report on the device to see what vul-nerabilities are present.

Keywords: Internet of Things, Healthcare, Security, Privacy, Penetration test-ing

i

Acknowledgement

I would like to thank Combitech and my external supervisor Jonas Wennerberg for thechance and all the help during this project. I would also like to thank my supervisor fromLinnaeus university Jesper Andersson, and all of my other teachers that helped me instudies especially Ola Flygt and Jonas Lundberg. I would also want to thank my girlfriendJenny, for pushing me and all the help I have received during this project. Lastly, I wantto thank all of my friends at Linnaeus University, my new found friends at Combitech andalso my family back home in Varberg.

ii

Contents

List of Figures v

List of Tables vi

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Problem formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.6 Scope/Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.7 Target group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.8 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Method 42.1 Problem identification & motivation . . . . . . . . . . . . . . . . . . . . 42.2 Objectives of a solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Design & development . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4 Demonstration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.6 Reliability and Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.7 Ethical considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Technical framework 63.1 Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.1 Information Security . . . . . . . . . . . . . . . . . . . . . . . . 63.1.2 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.3 Relationship between security and privacy . . . . . . . . . . . . . 7

3.2 Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 Electronic Health Records & Personal Health Record . . . . . . . . . . . 103.4 eHealth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.5 Penetration test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Literature review result 124.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3 Access control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 How can these challenges be detected/prevented 145.1 Detect/prevent issues through Standards/Guidelines . . . . . . . . . . . . 15

5.1.1 Confidentiality challenges . . . . . . . . . . . . . . . . . . . . . 155.1.2 Integrity challenges . . . . . . . . . . . . . . . . . . . . . . . . . 165.1.3 Access control challenges . . . . . . . . . . . . . . . . . . . . . 17

5.2 Detect/prevent issues through Protocols . . . . . . . . . . . . . . . . . . 185.2.1 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2.3 Transport Layer Security . . . . . . . . . . . . . . . . . . . . . . 19

iii

5.2.4 Datagram Transport Layer Security . . . . . . . . . . . . . . . . 205.2.5 AllJoyn SecurityTM . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.3 Detect/prevent issues with Penetration Testing Tools . . . . . . . . . . . . 215.3.1 Confidentiality vulnerabilities . . . . . . . . . . . . . . . . . . . 215.3.2 Integrity vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . 225.3.3 Access control vulnerabilities . . . . . . . . . . . . . . . . . . . 22

6 Penetration test suite 236.1 Aircrack-ng suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.2 Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.3 Bluetooth arsenal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.4 KillerBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.5 Metasploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.6 Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.7 Ettercap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.8 SSLsplit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.9 Mimikatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.10 Burp suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.11 SQLmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.12 OpenVAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.13 Social-Engineer Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.14 Hashcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.15 Eclipse MosquittoTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7 Discussion 29

8 Conclusion and Future work 32

References 33

A Appendix AA.1 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA.2 IoT communication technologies . . . . . . . . . . . . . . . . . . . . . . BA.3 Inclusion - Exclusion results . . . . . . . . . . . . . . . . . . . . . . . . D

iv

List of Figures3.1 Security properties based on the extended C-I-A triad. . . . . . . . . . . . 73.2 Some of the domains where IoT could be applicable. . . . . . . . . . . . 93.3 Overview of the three different test types. . . . . . . . . . . . . . . . . . 124.1 Literature result, show the flow from database to which reports that was

included by the Inclusion-exclusion criteria. . . . . . . . . . . . . . . . . 124.2 Ishikawa cause and effect diagram over the general confidentiality challenge 134.3 Ishikawa cause and effect diagram over the general integrity challenge . . 144.4 Ishikawa cause and effect diagram over the general access control challenge 14

v

List of Tables1.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.1 Different states of information . . . . . . . . . . . . . . . . . . . . . . . 63.2 Definitions of security properties . . . . . . . . . . . . . . . . . . . . . . 73.3 Steps to minimize the risk of privacy loss . . . . . . . . . . . . . . . . . 85.1 Some of the IoT protocols that have security features . . . . . . . . . . . 185.2 The Bluetooth security model including the description of the security

features mentioned in Core specification 5.0 . . . . . . . . . . . . . . . . 195.3 AllJoyn compared to TLS from Allseen Summit 2015 . . . . . . . . . . . 21

vi

1 IntroductionThis section will introduce the reader to the research done in this thesis. It will also givethe reader some necessary background information that will help the reader understandthe rest of the thesis fully.

1.1 BackgroundInternet of Things (IoT) and connected devices is the next hot thing to implement intoexisting industries. IoT is a way to connect devices to the internet so they can share infor-mation collected by the device itself, or sensors connected to it. IoT has opened oppor-tunities for devices to send information to a central spot for monitoring and comparison.These opportunities make IoT perfect for healthcare, as it lacks real-time monitoring andeasy comparison of Big data.

Some examples of use cases where IoT could improve healthcare are interconnectinghospitals to have them help each other with diagnoses and research. Having automateddata processing such as a device sending alarms to a doctor when a patient goes undersome threshold on a monitoring device. Automating journalling by connect measuringdevices and connect its output directly to the patient’s journal.

However, before we can see a large-scale implementation of IoT in healthcare, weneed reliable and standardised methods to be able to send this private information securelythrough the internet.

Securely is defined by the classical definition confidentiality, integrity and availability(CIA Triad) where information is secured when it prevents unauthorised access, protectsthe data from unapproved changes and against unwilling destruction. We will also inthis report use the extended security definition from ISO 7498-24, which adds two morerequirements, Authentication and non-repudiation [2].

In the report, we have chosen to focus on confidentiality, integrity and access control(a subsection in the Authentication requirement, that will control that only authenticatedsystem/users could access protected assets) as the domain-scope and will exclude theother requirements.

1.2 Related workWassnaa AL-mawee does similar work in the master thesis Privacy and Security Issues inIoT Healthcare Applications for the Disabled Users a Survey [3]. The difference betweenour theses is that we will focus more on the general healthcare domain. Our report willtake up some of the same challenges that Wassnaa AL-mawee thesis brings up. However,as her thesis is from 2012, the IoT market has changed, and some of her issues have beenfixed in iterations of protocols.

This thesis will also look more into how standards and on how we could use thesestandards and tools to detect/prevent the security and privacy issues.

1.3 Problem formulation1. What are domain-specific security challenges in confidentiality, integrity and access

control for devices in healthcare?

2. How can we detect and prevent these security challenges?

1

1.4 MotivationWealthier countries have good healthcare, but the effectiveness and affordability are low.The first problem is that a person may need to go far to get medical care. The patient thenmeets a doctor who diagnoses his or her problems through the doctor’s and hospital’sknowledge, which may lead to incorrect diagnoses. IoT can solve these problems intwo parts; a sick person can meet a doctor at a distance through an IoT gadget, and IoTgadgets can link hospitals to gather and share information so that all hospitals have thesame information [4, 5].

The second main issue is that healthcare, in general, is expensive and ineffective.IoT has solved this in other industries by introducing simple information gathering fromsensors and devices and removing the manual work to get out and process this informa-tion. By having automatic information gathering and in some cases automatic processing,adding IoT in healthcare will gain effectiveness and reduced costs [4, 5].

While these new these new technologies are evolving the healthcare domain to becomemore effective in saving lives they also include new attack vectors. While including thisattack vector into other industries is an acceptable risk, including it with security issuesin the healthcare domain could risk patients lives.

1.5 Objectives

O1 Decide which security properties are of most interest in the area ofIoT in healthcare

O2 Make a literature review on IoT challenges in the domainO3 Make a literature review on Confidentiality, Integrity and Access con-

trol in the domainO4 Collect material to use in the literature review on detection and pre-

vention methods for the domain challengesO5 Review penetration test tools to find tools that could be used to detect

issues.O6 Create a Penetration test-suite for domain specific challenges

Table 1.1: Objectives

1.6 Scope/LimitationThis result of this report will focus on the healthcare domain of IoT. Some challengeswill occur in different domains as well, but as the challenges are critical for the securityand privacy of healthcare data, we will include them in this report as well. The scopefor data transmission will be inside the device and to another processing/storing device inthe proximity of the sensor device, so we will not check data transmitted to or from theinternet.

For the literature review, we have limited the search to two databases, ACM and IEEE.The search query used is the same for both databases, see Appendix A.3.

1.7 Target groupThis report is done as a bachelor thesis in computer science and target other studentsstudying the same thing. The second target groups are developers and manufacturers

2

of IoT devices, especially those who develop IoT devices that are going to be used inhealthcare. This as the report could be used as a guide on what to check and what tools touse for testing before sending out a product into production.

1.8 OutlineSection 2 will give the reader information on by which scientific methods that have beenused for answering the research questions. Section 3 gives the reader the technical knowl-edge that is needed to understand the results given in the next coming sections. In section4 the report goes through the result of the literature review and shows what challengeswere found in section 4. In section 5 the report will answer the question on how thechallenges could be detected and prevented through different kind of methods. We thenpresent our penetration test tool suite in section 6 with a small description about each tool.Section 7 includes the discussion about the results found and example scenarios in whichthis report could be used as a guide. Lastly, section 8 will include the conclusion andfuture work opportunities.

3

2 MethodThis section is meant to inform the reader about what scientific methods we are using. Itwill give the reader a detailed overview of how we use these methods to come up with theresult. The design science research process [6] inspires the method used for this report.

2.1 Problem identification & motivationInternet of things have getting headlines the recent years of being insecure and oftenrushed out to production, this as these devices improve the efficiency of the environmentit is placed in. Healthcare is one of these environments that benefit from the use of IoTand machine-to-machine communication, but when systems are added, they add an attackvector for an attacker. Adding an attack vector into other industries could be acceptable,in healthcare an attack vector could risk patients lives.

This report will look into the security challenges IoT devices have in three propertiesof the extended C-I-A triad that is explained in section 3, and from these challenges, thereport will try to find solutions for them.

2.2 Objectives of a solutionThe objectives of the report are to find security challenges in IoT devices that are in thehealthcare domain and to show how these challenges could be solved. The report willfollow the objectives shown in table 1.1.

2.3 Design & developmentFor finding the domain-specific challenges, we will conduct a structured literature reviewof research papers and other scientific reports. We will go through scientific reports fromdatabases provided by the university with the inclusion-exclusion criteria of our specificdomain and our three focus areas. These inclusion-exclusion criteria will be matched, firstin search terms and headings of the reports, then do a deeper match in the abstract of thereport. This work will be followed and documented as suggested in Barbara Kitchenhamreport [7] on how to gather relevant literature.

For finding detection and prevention methods for the challenges above, we will surveythe ENISA’s Baseline security recommendations for IoT - in the context of Critical Infor-mation Infrastructures [1] and The Open Web Application Security Project’s(OWASP)Strategic Principles For Securing The Internet Of Things [8]. Through these reports wewill see how implementing these recommendations and standard will prevent all or someof our challenges from the first problem.

For detection of the challenges, we will do a review of penetration test tools that couldhelp detect some or all of the problems above. For this, I will focus on open source toolsinside the Kali Linux distribution with an extension of specific IoT security tools not inthe standard Kali installation.

2.4 DemonstrationThe report demonstrates the result of case studies about what detection and preventionmethods that can be used to solve the challenges found in problem one, this by using twoguideline reports and the use of penetration test tools.

4

2.5 EvaluationThe report evaluates the result by demonstration and argumentation. The report argumentsthe result and shows its usages via demonstrated scenarios in section 7.

2.6 Reliability and ValidityThe results in this report are based on findings in peer-reviewed reports from known andrespected databases and this be valid, but as IoT is a quick ageing technology, this couldchange any results found in this report in the future. The findings are also documentedhow it was collected in Appendix A.3 and could be used to find the same reports. Theresult for research question two is found by reviewing tools used in the industry andguidelines from two reputable agencies/communities, and these guidelines could also bechanged in the future for the same reason that the IoT market is changing quickly.

2.7 Ethical considerationsSome tools mentioned in this report could be used with unethical intents through the useof malicious exploits or payload. These intents are not the meaning of the report; instead,we use these tools for research purposes and for securing systems by testing. Be sureto have written permissions from the system owner before using any of the tools in annetwork that is not owned by the tester, and report vulnerabilities in a responsible way.

5

3 Technical frameworkThis section will give the reader some general knowledge of the technical terms and tech-nologies mentioned in this report. It will also give the reader more in-depth informationin some of the areas around the report and why this report brings them up.

3.1 InformationThe report uses the definition for Information from the ISO 27000:2018 standard [9].This definition is as follows: "Information is an asset that, like other important businessassets, is essential to an organization’s business and, consequently, needs to be suitablyprotected. Information can be stored in many forms, including: digital form (e.g. datafiles stored on electronic or optical media), material form (e.g. on paper), as well asunrepresented information in the form of knowledge of the employees. Information canbe transmitted by various means including: courier, electronic or verbal communication.Whatever form information takes, or the means by which it is transmitted, it always needsappropriate protection."

This definition talks most about the business perspective of information but a personshealth information should ha at least the same importance and protection as any businessasset, but this definition applies to all information.

Information could be in three different states, see table 3.1.

InformationAt rest

Information stored in a database in the cloudbackend or in the device themselves.

In transitInformation sent of exchanged through thenetwork between two or more IoT elements.

In useInformation used by an application, service, orIoT element in general.

Table 3.1: Different states of information [1]

So when continuing to read the report, if the word information comes up as in thenext section this is what we mean by information, an asset in any form that holds somedata/knowledge about the surrounding domain.

3.1.1 Information Security

The ISO 27000:2018 standard has a definition of information security: "Information se-curity ensures the confidentiality, availability and integrity of information. Informationsecurity involves the application and management of appropriate controls that involvesconsideration of a wide range of threats, with the aim of ensuring sustained business suc-cess and continuity, and minimizing consequences of information security incidents." [9]

Security could also be defined by some properties, Pfleeger [2] has these defined asshown in figure 3.1 and defined in table 3.2. These properties are often called the C-I-ATriad which includes the left properties in figure 3.1, Confidentiality, Integrity and Avail-ability. However, those three is often not enough in today’s communication networks, SoISO 7498-2 [2] adds two extra properties named, Authentication and Non-repudiation.

While confidentiality and access control looks similar in Table 3.2 and could use samemethods(encryption) to preserve its property, they are different. Often to achieve confi-dentiality encryption is used to keep the information safe, here one part of access control

6

Confidentiality

integrity

Availability

SecurityAuthentication

Non-repudiation

Figure 3.1: Security properties based on the extended C-I-A triad.

Property Description

ConfidentialityThe ability of a system to ensure that an assetis viewed only by authorized parties.

IntegrityThe ability of a system to ensure that an assetis modified only by authorized parties.

AvailabilityThe ability of a system to ensure that an assetcan be used by any authorized parties.

AuthenticationThe ability of a system to confirm the identityof a sender.

Access controlThe ability of a system to ensure that access toprotected information is only accessible byauthenticated parties with permission.

Non-repudiationThe ability of a system to confirm that a sendercannot convincingly deny having sentsomething.

Table 3.2: Definitions of security properties [2].

is who has access to the encryption/decryption key and from this ensures who can accessthe information. So while confidentiality protects the information from unauthorised par-ties, access control protects the means of reading the information by authenticating theasset. So even if the asset has the keys to decrypt the information it still needs to verifythat it has permission to do so.

3.1.2 Privacy

The book Security in Computing [2] we can find the definition about privacy: "Privacyis the right to control who knows certain aspects about you, your communications, andyour activities." [2], or as they say for short "Privacy is controlled disclosure" [2].

Individuals tend to have different views on what information that is sensitive enoughto break the individual’s privacy, but if health information gets public, it tends to be theworst kind of privacy breach [2]. As the report is focusing on healthcare, privacy is asignificant part. We would like to control which people can access our health records andwhich can see how often we have been to the doctor.

From the books by Pfleeger [2] and by Hubaux [10], we get some tools or steps tohelp prevent privacy loss. See these steps in table 3.3.

3.1.3 Relationship between security and privacy

While security and privacy are looked upon as two different and separate properties inthis report, we cant have one without having at least some of the other. Security is seen

7

Tool Description

Data minimisation

Disclose only the necessary information for the specifictask or party.

Example: Don’t disclose crime records to a nurse whichtreat the individual for a broken leg.

Data anonymisation

Replace identifying information with anonymous codesthat could not be traced back to an individual.

Example: Use record numbers instead of saving socialsecurity numbers. Where the record number only trace tothe performed action.

Pseudonymity

Replace identifying information with unique codes thatcould link to an individual in another database.

Example: Replacing social security numbers with IDswhich link to the social security number in anotherdatabase.

Untraceability

It should be difficult to based on two or more data setstrace it back to the same individual.

Example: Information about two procedures should not beable to be linked back to one individual.

Unlinkability

It should be difficult to based on two items or individualsto trace it to one specific action.

Example: Information about two individuals should not beable to be traced to see if both did the same procedure.

Table 3.3: Steps to minimize the risk of privacy loss [2, 10]

as the tools to keep information private, while privacy is the tools for a user to havecontrol over their information, or as Rebecca Herold says in her article [11], "...you mustimplement security to ensure privacy. You must use security to obtain privacy. Security isa process. . . privacy is a consequence.".

We can point the relationship to the confidentiality property as security is the tools tokeep information private, and private information is only private as long as confidentialityis provided.

3.2 Internet of ThingsThe Internet Society (ISOC) has reported an overview of the Internet of things (IoT). Thisreport brings up their definition of Internet of Things as "The term Internet of Things gen-erally refers to scenarios where network connectivity and computing capability extends toobjects, sensors and everyday items not normally considered computers, allowing thesedevices to generate, exchange and consume data with minimal human intervention. Thereis, however, no single, universal definition." [12]

As mentioned above there is no universal definition between the larger groups that de-velop standards like Institute of Electrical and Electronics Engineers (IEEE) and Internet

8

IoT applicabledomains

Healthcare

Smart Home

Transportation

Education

Vehicles

Stores

Industry

Agriculture

Figure 3.2: Some of the domains where IoT could be applicable.

Engineering Task Force (IETF), but they have come up with similar concepts [12]. Thisconcept is that an IoT device is an object that has been extended with networking andcomputing capabilities. These capabilities are then used to generate or exchange data thatcan be used later for analysis. One big thing that makes IoT devices effective is the abil-ity to have machine-to-machine communication(M2M) which deviates from the standardhuman-to-human communication.

M2M communication lets machines generate, exchange and make decisions basedon information from another machine, and this makes it so the devices could automaterepetitive/time-consuming tasks. One example of machine-to-machine communication isRFID chip/reader, where the reader communicates with the chip to locate where the chipis located. One can then put the chip on a device like an ECG machine, which a nurse canthen locate through various equipment(such as smartphones, computers or tablets).

Machine-to-machine communication as evolved from RFID to IP-based communica-tion. This change of communication standard has made it so smarter devices could com-municate in an automated function. One example of this is medical devices that measureblood-pressure/oxygen/glucose to automatically send this information to another devicefor computation/storage. These automated functions have removed the way nurses hadto manually enter the measured values into an individual’s medical chart, and also so thedoctor could read the values from a distance in real-time.

While IoT devices are joining the IP-space we still have the problem with IPv4 ad-dresses being depleted [13] so most of the IoT communication technologies is using theversion 6 of the IP protocol or other protocols. The most common technologies that haveenabled IP machine-to-machine communication can be found in Figure 1.1 in AppendixA.2.

Other IoT devices in healthcare are, remote monitoring systems [14] to check how apatients health from a remote location. Remote configuration of devices, for example, aninsulin pump that gathers and transfers data to the user or caregiver so configuration couldbe checked and changed if needed. A regular stationary medical device like a Magneticradiation imaging (MRI) machine that has been extended with network capabilities is also

9

an IoT device.

3.3 Electronic Health Records & Personal Health RecordThe non-profit organisation Healthcare Information and Management Systems Society(HIMSS)that focus on getting better healthcare through information and technology defines Elec-tronic health records(EHR) as follows: "The Electronic Health Record (EHR) is a longi-tudinal electronic record of patient health information generated by one or more encoun-ters in any care delivery setting. Included in this information are patient demographics,progress notes, problems, medications, vital signs, past medical history, immunizations,laboratory data and radiology reports. The EHR automates and streamlines the clini-cian’s workflow. The EHR has the ability to generate a complete record of a clinicalpatient encounter - as well as supporting other care-related activities directly or indi-rectly via interface - including evidence-based decision support, quality management,and outcomes reporting." [15]

So Electronic health records are health information gathered in any care delivery set-ting. The setting for the report is the one where an IoT device collects any health infor-mation and where and how it sends this information to the caregiver.

While the Electronic Health Records are managed and provided by healthcare providersand regulated by law, individual manage their own Personal Health Records(PHR).

Personal health records are defined as follows: "The personal health record (PHR)is an electronic, universally available, lifelong resource of health information needed byindividuals to make health decisions. Individuals own and manage the information in thePHR, which comes from healthcare providers and the individual. The PHR is maintainedin a secure and private environment, with the individual determining rights of access. ThePHR is separate from and does not replace the legal record of any provider." [16].

So while an EHR only store health information from the individual when it has beenin a care delivery setting, PHR contains information both from an EHR and informationmanually inserted by the individual. Information that could be useful for an individual toinclude in a PHR is family medical history, allergic reactions to medication and informa-tion from an IoT device that is not uploaded into an EHR.

This is the kind of information that IoT devices work with and as EHR and PHR areprivate information that should not be made public by any means, so these IoT devices.

3.4 eHealtheHealth or e-health is the term used when health-information or health-resources is sent,stored or created through the use of electronics. The focus of this report is the electroniccommunication in and from a device, and also the health information stored on the device[17].

eHealth is an essential part of the current healthcare where hospitals can share EHRs,and other information about an individual, and also the ways healthcare could be given ondistance through the internet [18]. One significant requirement for eHealth to work andbe trusted is that all information is handled in a information secure and private manner.

3.5 Penetration testOne way to test the security of a system or application is to do a penetration test, and thistest is used to evaluate all of the properties that were brought up in the security table 3.1.

10

But not only information security but all security features from information to physicalsecurity so that a penetration test will look into all of the security aspects of a system,even human errors and hardware protection.

The company Core Security [19] had this great definition of what a penetration test isand what its used for: "A penetration test, or pen-test, is an attempt to evaluate the securityof an IT infrastructure by safely trying to exploit vulnerabilities. These vulnerabilitiesmay exist in operating systems, services and application flaws, improper configurationsor risky end-user behavior. Such assessments are also useful in validating the efficacy ofdefensive mechanisms, as well as, end-user adherence to security policies." [19]

"Penetration tests are typically performed using manual or automated technologies tosystematically compromise servers, endpoints, web applications, wireless networks, net-work devices, mobile devices and other potential points of exposure. Once vulnerabilitieshave been successfully exploited on a particular system, testers may attempt to use thecompromised system to launch subsequent exploits at other internal resources – specif-ically by trying to incrementally achieve higher levels of security clearance and deeperaccess to electronic assets and information via privilege escalation." [19]

"Information about any security vulnerabilities successfully exploited through pene-tration testing is typically aggregated and presented to IT and network system managersto help those professionals make strategic conclusions and prioritize related remediationefforts. The fundamental purpose of penetration testing is to measure the feasibility ofsystems or end-user compromise and evaluate any related consequences such incidentsmay have on the involved resources or operations." [19]

As the definition above states, a penetration test is a way to find vulnerabilities in anasset before someone with malicious intentions finds it. These tests are often ordered froma third-party company that specialises in penetration testing and could be in different sizesor scopes. Most common companies orders penetration test for only one application orone system, but could also be that the company wants the test their whole infrastructure.

There are different types of penetration test [20]. They are called Black box, Grey boxand White box and is defined by how much information the penetration tester gets aboutthe system in beforehand. A black box test is when the tester gets no information at allabout the system he is about to test. This test is the most real-life like as this is often thecase when an attacker comes from the outside [20].

A White box test is where the tester gets all information from the asset owner. Thistype of test is best when the hiring company wants the tester to have a good look, with alimited time frame. The chance of missing some part of the system is also minimal as thetester gets everything [20].

The Gray box is as it sounds a mix of the two types above. The tester gets enoughinformation to get into the system but not the system/source code. With this, the tester canfocus on testing the internals of a system and keep external reconnaissance to a minimal.With some insight into the system, the tester can also focus on the more severe parts andfind those vulnerabilities that hide further in the code. However, as in black box testing,we get the part where under a time limit the tester could miss parts of the system [20].

An overview of these three test types is presented in Figure 3.3.

11

Black boxAdvantages:

Accurate result of whata real attackerwould achieve.Can be applied to everyasset, system orinfrastructure. 

Disadvantages:Reconnaissance of thesystem will take longer.Might miss parts of thesystem.

White boxAdvantages:

Full access toinformation about thesystem. Less chance to misssomething.

Disadvantages:Easy to focus on thewrong thing when yousee the whole picture.

Grey boxAdvantages:

Only somereconnaissanceneeded.Almost the sameaccurate result as ablack box. higher probability to findthe more seriousvulnerabilities.

Disadvantages:Time limit may still leaveparts of the system

Figure 3.3: Overview of the three different test types.

4 Literature review resultWe concluded a literature review over two scientific report databases to find challengesfor IoT devices in the healthcare domain. In Figure 4.1 we can see the result as of howmany reports that moved on from the database search to the final selection of those whopassed the Inclusion-exclusion criteria.

These are then the reports that we will find the challenges found in the section below.

ACM14

IEEE36

Abstractevaluation

50

Rejected reports19

Full-textevaluation

31

Articles rejectedbased on full-text reading

18

Final selection13

Figure 4.1: Literature result, show the flow from database to which reports that was in-cluded by the Inclusion-exclusion criteria.

The challenges for IoT devices in Healthcare systems can be the same as IoT devicesin other domains, while we focus on the healthcare domain we will include problemsthat are common in general IoT if they pose a threat to the security and privacy thatthe healthcare sector demands. The bullet lists are specific challenges found in scientificreports through the literature review. The figures 4.2, 4.3 and 4.4 shows the general causesof the challenges through the use of Ishikawa diagrams, where the effect is the challengein the big arrow and the causes are what points to it.

12

4.1 Confidentiality• Battery driven devices that have hardware limitations on which encryption stan-

dards they could use [21–26].

• Data stored from an IoT device is not always encrypted. Even if the transmissionof data is encrypted, we can get out unencrypted data from the internal database[22, 23].

• Data or configurations on IoT devices can link data to one specific user [23,27,28].

Figure 4.2: Ishikawa cause and effect diagram over the general confidentiality challenge[21–31].

4.2 Integrity• If there is communication through some insecure media, then the information is vul-

nerable to Man in The Middle attacks where an attack could falsify the informationreceived in both ends [14, 21–23, 25, 28, 32].

• Devices do not have any message verification, such as hash values or digital signa-tures. Both from the server or from the client [14, 30, 32].

• No verification check on firmware updates [21, 25, 28].

4.3 Access control• Sensors and other wearable devices lack access control to the information gathered

by it [21, 25, 30].

• Access control to EHR/PHR needs to by fine-grained as doctors and caregiversshould be able to get different data, as well as they can change from day to day[22, 25, 30].

13

Figure 4.3: Ishikawa cause and effect diagram over the general integrity challenge [14,21–23, 25, 26, 28, 30, 32].

• As data is often saved/processed on another device, that devices need to have thesame access control as the sensor. Often these devices are shared between personalwith a simple pin or password [22, 23].

• Doctors and caregivers often bring their devices into the IoT network; this couldlead to unauthorised access if the device gets stolen and there is insufficient accesscontrol to the data [22, 23].

Figure 4.4: Ishikawa cause and effect diagram over the general access control challenge[21–23, 25, 29–32].

5 How can these challenges be detected/preventedThe report will look into in how the challenges found in section 4 could be detected andprevented. The report starts by looking into how guidelines from OWASP [8] and TheEuropean Union Agency for Network and Information Security (ENISA) [1] could help

14

prevent or detect the challenges. Then the report is continuing by checking IoT protocolsand what security features these have, and if those could be used to identify and preventany of the challenges. Lastly, in this section, the report will look into if Penetration testingcould be used to help developers or manufacturers to remove the challenges by showinghow they could be exploited.

5.1 Detect/prevent issues through Standards/GuidelinesIn this section, we will see if there is a standard/guideline that could help detect or preventany of the challenges found in section 4. There is no common standard for IoT devices,not in healthcare or in general, and from this manufactures and developers need to decideby themselves on what security measures they implement and how. The lack of standardsand short development process have made the IoT devices more prone to have securityissues [1].

Since there are no set standards to follow the focus of this sections will be to see iffollowing guidelines mentioned in ENISA [1] and OWASP IoT security Guidance [8].These guidelines are broad and do not specify exactly what that could be done to preventan issue. The report will take the broad description and will not go more in-depth in whatexactly is needed.

ENISA lists their suggestions for good practices through a list structure. They startwith GP for good practice and then an abbreviation as Technical Measures (TM), Policies(PS), Organisational, People and Process measures (OP) ending with a number [1] . Thereport will call the good practices with this list item when referred.

OWASP list their suggestions based on I followed by a number. They also list inwhat process this should be thought of. These processes are Manufacturer, Developer andConsumer guidelines. For this report, we refer to the earlier process if the guideline ispresent in more than one.

5.1.1 Confidentiality challenges

1. Battery driven devices that have hardware limitations on which encryption stan-dards they could use. [21–26].

ENISA: GP-PS-04, GP-TM-36 and GP-TM-37, takes up some of this. GP-PS-04 states that power conservation should not compromise security. GP-TM-36 brings up that IoT devices should build around being compatible withlightweight encryption methods. GP-TM-37 takes up scalable key manage-ment schemes as a way to lower the battery cost of key generation.

OWASP: None of the proposed guidelines takes up power as an issue, but Manu-facturer I4 takes up that lack of Transport Encryption. The I4 guideline is thatboth information sent from or inside the device should be encrypted, it alsostates that recommended and accepted encryptions practices should be usedinstead of developing their own.

2. Data stored from an IoT device is not always encrypted. Even if the transmissionof data is encrypted, we can get out unencrypted data from the internal database[22, 23].

ENISA: GP-TM-34 states that the IoT devices should have proper and effectivecryptography for both information in transit and in rest. This through a selec-tion of standard and strong encryption algorithms.

15

OWASP: Manufacturer and developer guidance I5: Privacy concerns states thatencryption should protect collected data in both rest and transit.

3. Data or configurations on IoT devices can link data to one specific user [23,27,28].

ENISA: GP-PS-08/09 Privacy by design, is the guideline that focuses on privacy.GP-TM-32 states that a data storage should be encrypted in case of devicedisassembly. GP-TM-12 also states that systems should minimise the datacollected and retained, and this could be a way not to store data that couldtrace back to an individual.

OWASP: Manufacturer and developer guidance I5: Privacy concerns states thatcollection of data from the user should be kept to a minimum, and also thatinformation gathered should be de-identified or anonymised.

5.1.2 Integrity challenges

1. If there is communication through some insecure media, then the information is vul-nerable to Man in The Middle attacks where an attack could falsify the informationreceived in both ends [14, 21–23, 25, 28, 32]

ENISA: GP-TM-38 and GP-TM-42 both talk about security for information intransit. GP-TM-38 used encryption methods such as hash algorithms, to keepdata safe and verified in a CIA triad way, minimising networks attacks asa man-in-the-middle though message/client/server verification. GP-TM-42states that data received should not be blindly trusted, and that there shouldrequire validation of both the data and the device when a new access pointjoins the network.

OWASP: This could also be solved by Manufacturer and developer I4: Lack ofTransport Encryption. By implementing recommended and accepted encryp-tion standards for information in transit makes the information unreadableeven if it goes through an insecure media.None of the guidelines from OWASP brings up message verification, but withthe use of proper encryption standard, there should be some signature or cer-tificate.

2. Devices do not have any message verification, such as hash values or digital signa-tures. Both from the server or from the client [14, 30, 32].

ENISA: GP-TM-41 states that authenticity of data both where is created and re-ceived should be guaranteed. It states that data should be signed everytime thedata is not in transit.

OWASP: None of the guidelines from OWASP takes up message verification.

3. No verification check on firmware updates [21, 25, 28].

ENISA: GP-TM-18 states that the firmware should be secure in all states of itslifetime. Both in the server, over the air and then at the device before and afterthe update. This security should be from encryption, digital signatures andcertificate chains.

16

OWASP: Manufacturer and developer I9: Insecure Software/Firmware takes upthat any updates should be signed and verified before installing it on the de-vice.

5.1.3 Access control challenges

1. Sensors and other wearable devices lack access control to the information gatheredby it [21, 25, 30].

ENISA: GP-TM-29 and GP-TM-30 brings up the importance of security policiesand to have different levels of access control depending on what level of se-curity is needed. GP-TM-32 states that data at rest in a device should beencrypted and access controlled.

OWASP: Manufacturer and developer I2: Insufficient Authentication/Authorizationstates that strong passwords should be required, and implementing two-factorauthentication. Both Manufacturer and Developers should also make sure thatdefault passwords could be changed.

2. Access control to EHR/PHR needs to by fine-grained as doctors and caregiversshould be able to get different data, as well as they can change from day to day[22, 25, 30].

ENISA: GP-TM-27 states that permissions to information or systems should belimited, this by implementing fine-grained access control. This access controlshould also follow the principle of least privilege.

OWASP: Manufacturer and developer I2: Insufficient Authentication/Authorizationhas the guideline to segregated and use multi-user environments and also usea role-based separation for what authentication/authorisation a user need toaccess specific information.

3. As data is often saved/processed on another device, that devices need to have thesame access control as the sensor. Often these devices are shared between personalwith a simple pin or password [22, 23].

ENISA: There is no focused Good practice for this, but GP-TM-29 brings up se-curity policies, and that could be a good broad practice to use for this reason.

OWASP: I2: Insufficient Authentication/Authorization is focused on the authenti-cation for one device, so no guidelines take up on how to connect authentica-tion between multiple devices.

4. Doctors and caregivers often bring their devices into the IoT network; this couldlead to unauthorised access if the device gets stolen and there is insufficient accesscontrol to the data [22, 23].

ENISA: There is no Bring your own device policy in the Good practices but likethe one above GP-TM-29 should cover BYOD policies. GP-TM-23 states thatauthentication mechanisms must be strong and use Two-factor authentication,and from this, we believe that BYOD should have this recruitment as well.

17

OWASP: Bring your own device is not mentioned in the guidelines, but any deviceconnected to IoT systems should use the same encryption, password and two-factor authentication that other devices are following.

From the results found in the two guidelines, we could see that not all but many of thechallenges exists in the guidelines as problems as well. We do not get any steps to followon how to implement these guidelines, but it could be used as a checklist for test purpose,to see that a device complies before sending it out to production.

While both of the organisations take up great and helpful properties that make a de-vice more secure, ENISA is a European Union organisation and from that be more valid.ENISA’s report [1] base on information surveyed from stakeholders and experts point ofview, so we can expect that the report is close to the real world problems.

OWASP, on the other hand, is an open community where also here experts can givetheir point of view, but it will be more open and broad definitions.

Based on this the report recommends the ENISA baseline recommendations whendeveloping or manufacturing a new IoT device, especial in the healthcare domain whichis a critical information infrastructure.

5.2 Detect/prevent issues through ProtocolsTo mitigate some of the challenges found in section 4 there are IoT protocols that havesecurity features built in or that could be enabled. The report will bring up some ofthese protocols that could protect the information in transit. When any IoT device sendsinformation out for itself, it often uses some wireless technology. In this report, we willlook at Bluetooth and Wi-fi. We will also check some of the more popular IoT applicationprotocols and see what security features they have.

TCP/IP layer Protocol Security featureApplication MQTT TLSApplication CoAP DTLSApplication AMQP TLSApplication AllJoyn AllJoyn SecurityTM

Physical/Data-Link Wi-Fi WPA2Physical/Data-Link Bluetooth Pairing, Bonding

Table 5.1: Some of the IoT protocols that have security features

5.2.1 Wi-Fi

Wi-Fi has a security protocol named Wi-Fi Protected Access II (WPA2) Which is thesuccessor of WEP and WPA. WPA2 is a protocol that lets clients/devices connect securelyto a Wi-Fi access point. WPA2 is using a secure encryption standard named AdvancedEncryption Standard(AES) [33] and uses a Four-way handshake method to let the clientand access point to agree on session keys for just that connection. WPA2 also have twoauthentication modes, WPA2-Personal and WPA2-Enterprise. Personal uses a Pre-sharedkey which is a password; Enterprise uses an authentication server inside the network.The authentication server can then authenticate a client via a certificate or just a plainusername and password [2].

18

While WPA2 has weaknesses as the use of weak Pre-shared keys, Man-in-the-middleattacks [2] and the latest one KRACK [34], WPA2 is still a must use in any Wi-Fi networkand especially networks that handle critical information.

5.2.2 Bluetooth

Bluetooth has five security features, pairing, bonding, device authentication, encryptionand message integrity [35].

Security feature Description

PairingThe process for creating one or more shared secretkeys

BondingThe act of storing the keys created during pairing foruse in subsequent connections in order to form atrusted device pair

Device authentication Verification that the two devices have the same keysEncryption Message confidentialityMessage integrity Protects against message forgeries

Table 5.2: The Bluetooth security model including the description of the security featuresmentioned in Core specification 5.0 [35].

In the later versions of Bluetooth that are in use today the pairing method is called Se-cure Simple Pairing and has passive and active eavesdropping protection. Passive eaves-dropping is when an attacker records the traffic and then tries to decrypt it. Secure Sim-ple Pairing protects against this by using the Federal Information Processing StandardsPublications (FIPS) approved public-key cryptography P-256 Elliptic Curve Diffie Hell-man [35].

Active eavesdropping (Man-in-The-Middle) is when an attacker puts a device in themiddle of two user devices. In this case, the first user device thinks it sends the infor-mation to the second device, but in reality, it sends it to the attacker device which thenrelays it to the second user device. Through a Man-in-The-Middle attack, the attacker canfalsify the information the first or second device receives. Secure Simple Pairing protectsagainst this in two ways, Passkey entry or numerical comparison. Passkey is when theuser needs to enter a key shown on the second device into the first device, and a numericalcomparison is when the user needs to compare and approve a number sequences shownon both devices [35].

For encryption, Bluetooth uses AES [33] with CCM(Counter with CBC-MAC) Mode.This Encryption algorithm gives both confidentiality and message authentication(via CBC-MAC) [36].

5.2.3 Transport Layer Security

Transport layer security or TLS for short is a transport layer protocol to secure commu-nication sent over the internet. It runs on top of a reliable transport layer like TCP, andwith the help of symmetric and asymmetric encryption, it keeps the information privateand secure.

TLS has two layers, TLS record protocol and the TLS handshake protocol. The recordprotocol handles the confidentiality and integrity by using symmetric cryptosystems like

19

AES. It also handles message integrity with the help of secure hash functions as HMAC-SHA256/384 [37].

The second layer is TLS handshake which is using asymmetric cryptosystems likeRSA to authenticate both client and server or only one of them. RFC 5246 states that theTLS handshake does the steps in the list below to establish a TLS connection [37]:

• Exchange hello messages to agree on algorithms, exchange random values, andcheck for session resumption.

• Exchange the necessary cryptographic parameters to allow the client and server toagree on a premaster secret.

• Exchange certificates and cryptographic information to allow the client and serverto authenticate themselves.

• Generate a master secret from the premaster secret and exchanged random values.

• Provide security parameters to the record layer.

• Allow the client and server to verify that their peer has calculated the same securityparameters and that the handshake occurred without tampering by an attacker.

While TLS makes communication secure and private, it drains much power as it hasto establish a session each time a device wants to talk to another device/server. Theextra power consumption makes it impractical for some devices which rely on batteriesto function, as small IoT devices. For devices with no power limitations, TLS could be aperfect way of securing application data sent through the internet.

5.2.4 Datagram Transport Layer Security

While TLS needs a reliable transport protocol like TCP, the increasing number of us-ages for datagram traffic drives up the need for a security protocol as TLS for datagrams.Datagram Transport Layer Security (DTLS) is made to be as similar to TLS as possible toreduce new technologies and to be able to run without significant changes to infrastruc-ture/codebase [38].

DTLS have a Record layer similar to TLS, but DTLS have added a sequence numberto keep track of packet ordering. It uses the same encryption standards as TLS, AES andHMAC [38].

DTLS handshake layer follows the same message format as TLS with some changes.DTLS using a retransmission timer that makes sure that none verified packages are re-sent. DTLS also use a Cookie( HMAC(Secret, Client-IP, Client-Parameters)) with theClientHello message that starts the DTLS communication. This cookie is used for clientauthentication and Denial of service protection [38].

IoT devices often use Datagram transport when latency is essential, like real-timemeasuring equipment in healthcare or live video from security cameras. DTLS will givethose devices a way to secure the information over datagrams without giving up the la-tency requirement by changing a reliable transport layer.

20

AllJoyn TLSFixed ciphersuite Negotiate ciphersuiteOne set of curve parameters NegotiatedOne certificate signaturealgorithm, params.

Flexible. RSA signatures are most common

No protocol extensions Well-defined extension mech.New, less security review Highly scrutinizedStatic relationships withfewer peers

Variable duration, diverse peers

Typically a local PKI Typically global PKI (web)Mutual auth. always Typically server auth. onlyRenegotiation used a lot Less use of renegotiation

Table 5.3: AllJoyn compared to TLS from Allseen Summit 2015 [39].

5.2.5 AllJoyn SecurityTM

The AllJoyn protocol uses security features similar to TLS, and require a reliable transportlayer protocol as TCP. AllJoyn has made a comparison between TLS and AllJoynTMinslides from Allseen summit 2015 [39]. This comparison can be found in table 5.3.

AllJoyn have these security features, as its goal is to have a robust standard protectionthat all AllJoyn apps could use. It also tries to keep things simple and remove batteryintense features as the negotiation about what ciphersuite to use, but also stay close to thecore protocol TLS. By running IoT devices with AllJoyn manufacturers and developer getbuilt-in security with similar security as TLS added to an existing protocol as MQTT, butwith less implementation.

5.3 Detect/prevent issues with Penetration Testing ToolsPenetration tests are often conducted to detect vulnerabilities inside an existing system.While the two sections above states what manufactures and developers should conductbefore releasing a product/software, this section will bring up how we can exploit a systemin unintended ways to get out unauthorised information.

For this, we can use tools, developed by individuals in the security community orcompanies. These tools are focused on finding one vulnerability or focused on one type oftechnology. It can also be a swiss army knife that handles a lot of different technologies.This section of the report will cover the most common tools for finding and exploitingour challenges in section 4, while the next section will build a tool suite with some ofthe essential tools needed to pen-test a healthcare IoT device and describe them in moredetail.

This section takes into consideration that the penetration tester has access to net-works/systems/devices that are needed for a tool to work. Section 6 will do a morein-depth description into the tools.

5.3.1 Confidentiality vulnerabilities

Confidentiality vulnerabilities often start with the insufficient use of encryption; this couldbe that the system uses insecure encryption standards, a weak password or that the systemuses no encryption at all.

21

If we are on the same wireless network as the device, we can use the applicationWireshark to listen to all traffic going through the network. If this traffic is not protectedin transit, we will see the information send as cleartext; This is also the case if we knowthe WPA2 key for the network, as Wireshark can decrypt WPA2 traffic automatically byinserting the key and capturing the handshake. So even if the traffic is encrypted viaWPA2 with a weak/know key we can decrypt and read it.

There is the same problem with information at rest. If the information is stored on ahard drive that is not encrypted securely (no/weak encryption), we can either remove thehard drive and read it from another device or make a copy of the information. Both ofthese options need physical access to the device.

5.3.2 Integrity vulnerabilities

Integrity vulnerabilities are when an unauthorised user changes information. These vul-nerabilities can be done over a network with the use of Man-in-The-Middle attacks, sometools to execute such attack are Etthercap, SSL split and Burp suite. With a client runningthese tools between a user and a server we can read or change information sent betweenthem. If we can sit between critical services in healthcare, we can harm patients who relyon devices giving the correct information back to caregivers.

Another way of exploiting the integrity of information is to change it at rest, so thedevice gives out false output. The output can be manipulated by changing configurationfiles or changing the firmware. Configuration files can be a file with any content; examplesare JSON, XML, INI or other plain text files. These configuration files could be changedwith a simple text editor if the attacker knows what to change and have rights to changethat file. Protection against this is to harden the root user and remove the permissions forany other user. One example of configuration exploitation is if an attacker could changethe firewall settings to allow connections from the outside.

Firmware is low-level software that provides hardware-specific configurations on howthe hardware should work. If we as an attacker can change this, we can change sensorsor other hardware to function in another way then intended. One example of this is tochange how much insulin an insulin-pump should deliver at a particular stage. For this,we have tools like Binwalk, Firmware-Mod-Kit (FMK) or Firmware Analysis Toolkit(FAT). Firmware attacks can be both over a network interface or a physical interface. Theinteresting network attack here works as the device is looking for updates over-the-airwe can pretend to be the update server and make the device install our firmware. Codesigning and firmware verification/encryption are ways to prevent this attack.

5.3.3 Access control vulnerabilities

Access control vulnerabilities are most often the case of inadequate security policies andweak authentication methods. Access control exploits are when an attacker can accessinformation that he lacks permissions to read. Attackers could use weak passwords orsocial engineering attacks to get control of an authenticated user credentials and log in asthat user.

The tools for doing this is Hashcat/oclHashcat, L0phtCrack and the Social-EngineerToolkit. Hashcat and L0phtCrack are tools to crack passwords and can use many differentpassword attacks like brute force, Rainbow tables and dictionary to break common orweak password with ease.

The Social-Engineer Toolkit gets out the credentials another way, and it tries to makethe user give the attacker its credentials without knowing. It tries to attack the human side

22

in a user and make them unintentionally give out private information. Examples on thisare Spear-Phishing emails sent to executives to make them enter their credentials in a fakelogin page that the attacker owns.

By getting a user’s credentials from either of the ways above, we could use themto change personal records or read sensitive information and from this break the accesscontrol systems that exist on the device/system.

6 Penetration test suiteIn this section, the report will present tools used in our penetration test suite that gathersindividual tools into a directory of focused tools; this will be a guideline for developersand security testers for securing IoT devices. The report will focus on open source toolsand tools that are used by security professionals, as this will make the tools accessiblethrough Github [40] and the Linux distribution Kali Linux [41]. These tools are madeby the security community and regularly updated to keep them up to date with the risingflow of vulnerabilities. These platforms are also a way for researchers to include theirnew/better tools to the rest of community in a simple way.

The IoT market and the security community around IoT is entirely new, and thereis few IoT specific penetration test tools and no specific tools for IoT devices in health-care. So the tools presented in this report are common tools used for communication,applications and hardware that IoT device are using.

The following tools are ordered in no particular order.

6.1 Aircrack-ng suite [42]The Aircrack-ng suite is a collection of tools to test the security in a Wi-Fi network. Ithas tools for monitoring, attacking, cracking and testing.

• Monitoring is used to capture raw packets that could be sent to another tool foranalysis or decryption.

• Attacking is used to attack access-points or clients actively; this can be done withreplay attacks, setting up a fake access-point or use packet injection techniques.

• The testing tools are used to check Wi-Fi cards, drivers and version numbers.

• Cracking tools to crack the deprecated protocol WEP as well as WPA 1 and 2 Pre-shared key. To crack the WPA pre-shared key, we need to capture a WPA handshakethat happens when a client is connecting to an access point.

If we can use any of these tools to crack or access the pre-shared key, we can thengain unauthorised access to the network and listen to the information sent over it. We canthen also use other tools to run more advanced exploits or spoof attacks.

To run any of the Aircrack tools we need a Wi-Fi card and compatible drivers to beable to inject packets and set the card to monitor mode. Monitor mode is when the cardis listening to all traffic in the air, and as of this, we can capture all the traffic. When wehave the Wi-Fi card in monitor mode, we can capture the needed WPA handshake. As theWPA handshake happen only when a client is connecting to the access point, we can waitor disconnect a device to force it to redo the handshake sequence.

23

When we then have captured a handshake, we can start cracking the pre-shared key.For this, we use a brute-force or a dictionary attack with the help of the Central processingunit(CPU). As this tool is using the CPU, brute-force can only we effectively used if thekey is shorter than eight characters. For longer keys, we can use other tools that use thepower of Graphics processing unit’s(GPU).

6.2 Wireshark [43]Wireshark is a network protocol analyser that captures traffic sent through the network. Itdoes deep inspection on almost all protocols that could be run on a network.

If the traffic is unencrypted we can use Wireshark to just read out the information forthe captured data, but Wireshark also has decryption support for some protocols, for ex-ample, TLS, WPA2 and IPsec. So if we use Aircrack to gain the WPA2 key of a network,we can then use Wireshark to automatically decrypt the captured traffic, both offline andin real-time. Same with TLS if we know the secrets and capture the handshakes.

With specific hardware, Wireshark could also be used to capture Bluetooth traffic anddissect some of the layers.

So when we get into a network, Wireshark should be our go to tool to see what is goingon in the network, what devices are talking to whom and to see what protocols there areto exploit. Without any application encryption we can read any eHealth information sentthrough the network, which is a major security and privacy issue.

6.3 Bluetooth arsenal [44]Bluetooth arsenal is a collection of Bluetooth attacking tools that could be used to exploitknown vulnerabilities in Bluetooth protocols. As Bluetooth is used by low level IoTdevices to communicate information to higher power devices, this is important attackvector to look into securing. Gaining access to the Bluetooth traffic could led to privateinformation disclosure and information manipulation.

These tools require specific hardware to be able to sniff and inject Bluetooth packetspassively. Ubertooth [45] is one device that could do this.

One attack in this collection is a python software that uses the BlueBorne vulnerabilityto take control over a Bluetooth device. Armis Labs found and disclosed BlueBorne witha whitepaper in 2017 [46]. BlueBorne is removed in patches to Android, but can stillbe present in IoT devices that are limited to run a specific system or devices that areunpatched.

The collection also has a tool called CrackLE that using a flaw in the Bluetooth LEpairing process that let the program quickly brute-force the Temporary key that can thenbe used to get the Long Term Key that is used to encrypt data between two paired device.

6.4 KillerBee [47]KillerBee is a framework of tools that simplify attacking ZigBee and other IEEE 802.15.4networks. KillerBee can attack these network with sniffing packets of the air and injectionpackets into said networks. This attack will let us capture and decode Zigbee packets andget out the eHealth information sent or inject our falsified packets.

This framework needs specific hardware as Bluetooth attacks, see the REQUIREDHARDWARE section in reference [47].

24

6.5 Metasploit [48]Metasploit is the world’s most used penetration testing framework. It is a collection oftools built by the security community and the company Rapid7. Metasploit builds onmodules, where a module is a standalone code that extends the functionality of Metasploitto focus on one specific vulnerability or system. A module can be an exploit, auxiliary ora post-exploitation module.

An exploit module is a program focused on a specific vulnerability on a system or ap-plication; this is exploits like buffer overflows, code injection or web application exploits.An auxiliary module is a program that does not actively gain access to the system; this canbe programs like scanners and fuzzers that tries to get out credentials or other informationfrom a system. A post-exploitation module is a program that we run after we have accessto a system, to gain higher access or to get a persistent foothold in the system that couldhandle a restart.

Metasploit also have pre-configured scripts and payloads that could be included intoexploits to use a specific vulnerability to gain for example a shell on the system or havethe system redirect the user to some malicious site.

6.6 Nmap [49]Nmap is a network scanner that is used for discovery and security testing. Nmap is usingraw IP packets to see which host is running in the network, what application a host isrunning and accepting communication to, what Operating system a host is running andlastly what firewall or packet filtering is in use on the network.

Nmap could be used to list what ports that are open on a system and what kind ofapplication that are running on that port. If that application or version is vulnerable, wecould exploit it with Metasploit to gain access to the IoT device.

6.7 Ettercap [50]Ettercap is a collection of tools for Man-in-The-Middle attacks. It works both for passiveand active attacks for many protocols like HTTPS, FTP, SSH, NFS, SNMP and more. Et-tercap works in four different modes, IP-based, MAC-based, ARP-based and PubilcARP-based. These are ways to fool a system to think it communicates with another host.Ettercap could collect passwords of most of the clear text protocols like FTP, Telnet andHTTP. It can also hijack DNS requests to point a client to another server than intended.

With Ettercap we could make an IoT device think it talks to a trusted server and fromthis get out private information or other critical information. As IoT devices could belimited in power or performance, often the device never authenticates the server, so ifwe can spoof the IP/MAC/ARP of the server, we could make it think that the attackercomputer is the intended server.

6.8 SSLsplit [51]SSLsplit is a tool that attacks SSL/TLS encrypted networks through a man-in-the-middleattack. SSLsplit works with network address translation interception and terminates theTLS in the attacker’s computer and then creates a TLS session to redirect the message tothe original destination.

25

SSLsplit supports all types of TLS both over IPv4 and IPv6. For TLS and HTTPSthat needs certificates, SSLsplit signs forged certificates on the fly to spoof the originaldestination that the client device is trying to connect to.

If we can run this between an IoT device and a server that communicates via TCP withTLS, we could eavesdrop on this information with little to no indications that someone islistening.

6.9 Mimikatz [52]Mimikatz is a tool used to extract passwords, hashes, Pin codes and Kerberos ticketsfrom memory in a windows machine. Mimikatz can also perform different authenticationattacks as the pass-the-hash attack that uses the NTLM hash of a users password insteadof the real password.

Having Mimikatz running on a device that authenticates to other devices or handlesauthentication to devices behind it could lead to the attacker getting credentials to patientdatabases or other private information as journals.

6.10 Burp suite [53]Burp Suite is a platform to test the security of web applications. It can automatically scanthe application for known vulnerabilities like SQL injections, OS command injectionsand XXS attacks. It also crawls the web application to follow every link to see if it canfind login/admin pages. It can also enumerate URL’s to try to find pages without links onanother page.

Burp can also work as a man-in-the-middle browser proxy that could catch trafficgoing from the browser to a web server. With this, we could catch input and change it intransit before it reaches the web server and in this case get out information that we are notsupposed to get. Burp has automated payloads for this proxy that could be used to fuzzcredentials(username and password, cookies or session tokens) or parameters like userID.

Burp is also extensible, so an attacker could make plugins to work specifically to oneapplication or use a Metasploit exploit or payload and use Burp to execute it into the webapplication.

IoT devices often have a web interface or application to show the information capturedby it. Through the use of Burp, we could exploit that web interface to give out informationthat we as an attacker should not be able to see, by either attacking the database with SQLinjections or gaining access to admin credentials.

6.11 SQLmap [54]The SQLmap tools provide an automated process for detecting and exploiting SQL in-jection vulnerabilities. SQLmap has full support for most database systems; this includesMySQL, SQLite, PostgreSQL and more.

The tool has automatic features to enumerate users, password hashes and tables/columnsand also to search for common used tables names as user, pass or other strings that couldbe interesting for the specific application. This feature could be useful for the healthcaredomain to correlate database tables with names like patientID, Doctor, Nurse or Diag-nose.

The tool also has automatic ways of gaining access to the underlying operating systemby using something called out-of-band SQL injection attacks. From this we could gain

26

access to not only the database system/information but the whole server, that can then beused for other attacks or exploiting other devices.

6.12 OpenVAS [55]OpenVAS is a vulnerability scanner framework that uses feeds of Network vulnerabilityTests that are made by the community. The feeds are tests that look for known vulnera-bilities in applications and services running in the network.

OpenVAS can scan anything from one host to a whole IP-range and checks each ofthe hosts for its entire database of Network Vulnerabilities test.

If we as an attacker gets into a network could OpenVAS be used to explore the sur-rounding network host and see if we could find other vulnerable devices. For example,OpenVAS can check for outdated Linux versions that unpatched IoT devices often use.OpenVAS will then give us a report with results and what kind of vulnerabilities could beused against a particular device.

6.13 Social-Engineer Toolkit [56]The Social-Engineer Toolkit is a toolkit that will let an attacker set up Social-Engineeringattacks in minutes. Social-Engineering is when the tester attacks the human side in a vic-tim, where we try to have the victim give us private information by trying to impersonatesomeone from the victim’s bank, the victims boss or other trusted contacts in the victim’slife.

This toolkit could be used to create copies of known websites to lure the victim towrite in its credentials, emails that look like the company/bank/PostNord to have thevictim click on a malicious link.

An attacker could use this tool to impersonate as a doctor to have a victim disclosea patient’s PHR/EHR or other private information. So we include this tool so the readercould spread this knowledge to others and remember not blindly to trust emails, SMS orweb pages.

6.14 Hashcat [57]Hashcat is an advanced password cracking software. Access control is only as strongas the authentication method used, and for IoT devices or in general this authenticationmethod is a password or a PIN code. Doctors, nurses or other healthcare employees areoften in a rush or in an emergency that could risk a patients life, so the authenticationmethods for the devices used in this setting is often weak, short or easy to remember andfrom this easily crackable.

With Hashcat we can use GPU’s or other hardware accelerators to try to break pass-words, PIN-codes or hashes. Many of the tools above this has been able to collect pass-words hashes, and with Hashcat we could break these to get out the password in cleartext, and then use it to log in.

Hashcat can use different attack types to break hashes, but the most common ones arebrute-force, Mask attack and the dictionary attack. Brute-force is when Hashcat is testingevery combination of a key. The mask attack is when Hashcat test every combinationwith some extra knowledge as the length of the key or the starting letter and more. Thedictionary attack is when the attacker gives Hashcat a list of known password or phrasesthat Hashcat then use to match hashes.

27

6.15 Eclipse MosquittoTM [58]MQTT is a protocol that enables Machine-to-Machine communication and is often usedin IoT devices. MQTT works in a publish/subscriber model where publishers push outmessages and subscribers receive them. As publishers push out messages to all of thesubscribers, we can use the Eclipse Mosquitto client to act as a subscriber.

If we could connect to a publisher without subscriber authentication, we can listen into every message that the publisher sends.

For example, If medical IoT devices that message something from a patient and thensend that information out via MQTT to its subscribers. If we then are on the network andsubscribe to these feeds, we also get this information from the IoT devices.

28

7 DiscussionThe purpose of this report was to find what the main confidentiality, integrity and accesscontrol challenges are in the healthcare domain of internet of things, and how implement-ing guidelines and standards in an early part of development could help minimise them.

The answers to these problems were found through a literature review of researchpapers found in two databases and the use of inclusion-exclusion criteria. The used papersand the result of the literature review can be found in Appendix A.3. From these papers,we found that the challenges that were most present in each of the reports are the onesmentioned in section 4. The result for this first problem seems to be similar to whatWassnaa AL-mawee found in her master thesis [3] even though it was written in 2012. Aswe both found similar problems shows that the same security issues for IoT is still presenttoday and further implies the need for standardisation.

When we then had the answer to the first of our research problems we looked into twowell-known guidelines as there is no fixed standardisation yet. We check two guidelines,one from the open community OWASP and one from ENISA. While both of the guidelineswere broad in their descriptions they still give advice, lines to follow and tests in themanufacturing and development faces of IoT products. ENISA [1] gave good advicebased on their survey on the industry, which also gave real scenarios that we could drawparallels to what we found in the scientific reports.

The Penetration testing section takes up how most of the challenges that we foundcould be detected and exploited. The result from this section is more of a way to show howa penetration test could help developers and manufacturers to see what type of damagethese security issues can cause, and from that give them more reasons to take the securityseriously, most importantly in the healthcare domain.

As IoT is entirely new in the security community and healthcare, there is no specificexploit/tools for the healthcare domain, but there are tools for more general IoT devicesthat are using the same protocols like the ones in healthcare. So the result should be thesame even if the IoT device is made for healthcare, even though this device should havehigher security demands.

From the knowledge we gained through the process above, we specified some pen-etration testing tools that are extra important to use when we look at IoT security. Wecombined these tools into a test suite which should be run by any security tester or devel-oper of an IoT device for the healthcare domain and make sure the device is not vulnerableto any of the things this report brings up.

In the following section we present two attack scenarios and how the report and toolscould help a developer reduces the risk of attack.

29

Scenario one: Vulnerable application leads to the device used in a bot-net.

Company Y-medical has released a new EKG measuring device, and this device has anHTTP server running so the caregiver can access the information through a browser. TheHTTP server is accessible through the internet via an HTTPS session with TLS, so theinformation is encrypted and secure.

Sadly the HTTP server Y-medical used is old and outdated and is only used as their de-velopment staff is most used to this version and it works well with other application on thedevice. This particular version is vulnerable to a Remote Code Execution attack(exampleCVE-2017-5638 [59]), which lets the attacker run commands on the server through theuse of crafted messages to the server.

This vulnerability lets the attacker run commands to make the server connect to theattacker’s machine through a reverse shell [60] to bypass any firewall rules the devicehave. Trough this shell the attacker can then run other exploits to gain administrativeprivileges to download malicious programs or scripts that make the server connect to acommand and control server which is used to control the botnet.

What the company Y-medical could have done before shipping this product was touse tools like OpenVAS in section 6 to see if their product is vulnerable to anything that isalready known to the community. OpenVAS uses this Common Vulnerabilities and Expo-sure(CVE) [61] database to scan the device and report if any application running on it hasa known vulnerability. If Y-medical has shipped the device to production, this could be acostly vulnerability as they might need to update more than just the HTTP server, and ifthis could not be done through a over-the-air firmware update the hospitals IT techniciansneed to do a manual update.

Scenario two: Changed Firmware leads to harm to the patient.

The company Diabetes Corp have launched a new insulin pump that uses a patented al-gorithm to calculate how much insulin to give the patient at which glucose values. Thedevice is configured and updated through the hospital’s Wi-Fi network so every time thedevice comes in contact with the hospital’s network, it looks for updates. WPA2 securityprotects the information sent through the networks, but the attacker has already crackedthe WPA2 protection through the use of a dictionary attack using Hashcat and Aircrackin section 6, as the doctors often forget the password to the network they have used apassword as HospitalX2018. With the use of that password, the attacker could decryptand see all the traffic going on in the network.

The attacker sees that when an insulin pump is joining the network, it then asks whatIP address the updating server is using, and after that, the updating server answers if it hasan update or not. This information is not encrypted, and both the server and the client isnot using any verification. The attacker sees this information and downloads and createsits falsified firmware that changes the voltage the device is sending to the pump, makingit so that the patient is getting much more insulin than it needs.

The attacker is then using a Man-in-The-Middle attack (Example could be found insection 6) to fool the insulin pump devices to think that the attacker machine is the updat-ing server. The attacker machine then sends out that it has a new update and as the deviceis not verifying the server it trusts the firmware and updates the device. Which then leadsto excess insulin which will harm the patient and could lead to death.

For this scenario Diabetes Corp and the hospital have made errors in the handling of

30

the device. The hospital, through the weak password for the production and updatingnetwork. However, mainly the Diabetes Corp by running the updating server traffic un-encrypted, no client/server verification and no digital signature to verify that the firmwareupdate was from the company.

The hospital could have used the Aircrack or Hashcat tool to test their security and seethat their Wi-Fi was vulnerable to such attacks. They should also enforce a better securitypolicy as stated in the ENISA [1] report and not allow any weak password for any device.

The Company should have followed the guidelines presented in this and ENISA’s [1]report and from that they would have noticed and fixed all of the problems that led tothe changed firmware. Some examples are that ENISA guideline GP-TM-42 says thatinformation sent from an application should be secured in transit, this would have made itso that the attacker could not see what information that is sent between the device and theupdate server and made it harder to understand that it was a firmware update. GP-TM-18also focus on just firmware, and that should be secure in all stages in its lifetime throughthe use of encryption, digital signatures and certificate chains.

31

8 Conclusion and Future workThere are still serious security issues presented in IoT devices produced today and willbe for a time forward. The healthcare domain is no different, and with all the private andcritical information systems that are present in this domain, there is a big need for stan-dardisation and security controls. While there are new and more vulnerabilities comingeach day, there is also more and easier tools to use to find and in an automated processclose any holes the vulnerabilities opens up. This report could be used in the industry toexpand the knowledge at the development and manufacturing side, but as well to use asa guide on how an IT technician could find and close security vulnerabilities inside hisnetwork. We also show this with the scenarios in section 7 and how they could have beenstopped by implementing the guidelines or by using the test suite.

Future work based on this report could be to compare the IoT domain from this domaintoday to that domain which has a standard implemented, as to see if the standards havemade the domain more secure. This report can also be applied on to a device in practiceand see that the challenges are removed by following the guidelines and test the devicewith the test suite. There is also more properties in the extended C-I-A triad that has otherchallenges, and how they compare to the challenges brought up in this report.

32

References[1] European Union Agency For Network And Information Security (Enisa), “Baseline

Security Recommendations for IoT - in the context of Critical Informationinfrastructures,” nov 2017. [Online]. Available: https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot

[2] C. P. Pfleeger, S. L. Pfleeger, and J. Margulies, Security in computing, 5th ed. Pear-son Education, 2015.

[3] W. AL-mawee, “Privacy and security issues in IoT healthcare applicationsfor the disabled users a survey,” Master’s Theses, 2012. [Online]. Available:https://scholarworks.wmich.edu/masters_theses/651

[4] B. Farahani, F. Firouzi, V. Chang, M. Badaroglu, N. Constant, and K. Mankodiya,“Towards fog-driven IoT ehealth: Promises and challenges of iot in medicineand healthcare,” Future Generation Computer Systems, vol. 78, pp. 659–676, 2018. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0167739X17307677

[5] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internet of things(iot): A vision, architectural elements, and future directions,” Future GenerationComputer Systems, vol. 29, no. 7, pp. 1645–1660, 2013, including Special sections:Cyber-enabled Distributed Computing for Ubiquitous Cloud and Network Services& Cloud Computing and Scientific Applications — Big Data, Scalable Analytics,and Beyond. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0167739X13000241

[6] K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A design scienceresearch methodology for information systems research,” Journal of ManagementInformation Systems, vol. 24, no. 3, pp. 45–77, 2007. [Online]. Available:http://www.tandfonline.com/doi/full/10.2753/MIS0742-1222240302

[7] B. Kitchenham, “Procedures for performing systematic reviews,” Technical ReportTR/SE-0401, Department of Computer Science, Keele University and National ICT,Australia Ltd, pp. 1–26, 2004.

[8] OWASP.org, “iot security guidance,” 2017, [Accessed: May. 23, 2018]. [Online].Available: https://www.owasp.org/index.php/IoT_Security_Guidance

[9] ISO/IEC 27000:2018, Information technology – Security techniques – Informationsecurity management systems – Overview and vocabulary, 5th ed. InternationalOrganization for Standardization, 2018. [Online]. Available: https://www.iso.org/standard/73906.html

[10] J.-P. Hubaux and L. Buttyán, Security and cooperation in wireless networks, 1st ed.Cambridge University Press, 2008.

[11] R. Herold, “What is the difference between security and privacy?” CSI July 2002Alert newsletter, p. 3.

33

[12] K. Rose, S. Eldridge, and L. Chapin, “The internet of things: An overview,understanding the issues and challenges of a more connected world,” pp. 5–17,2015. [Online]. Available: https://cdn.prod.internetsociety.org/wp-content/uploads/2017/08/ISOC-IoT-Overview-20151221-en.pdf

[13] Icann.org, available pool of unallocated ipv4 internet addresses now com-pletely emptied, 2011. [Online]. Available: https://www.icann.org/en/system/files/press-materials/release-03feb11-en.pdf

[14] A. Rghioui, A. L’aarje, F. Elouaai, and M. Bouhorma, “The internet of things forhealthcare monitoring: Security review and proposed solution,” in 2014 Third IEEEInternational Colloquium in Information Science and Technology (CIST), Oct 2014,pp. 384–389.

[15] HIMSS.org, “Electronic Health Records,” 2018, [Accessed: May. 22, 2018].[Online]. Available: http://www.himss.org/library/ehr

[16] Ahima.org, “Role of the personal health record in the ehr (2010 update),” 2010,[Accessed: May. 22, 2018]. [Online]. Available: http://library.ahima.org/doc?oid=103209

[17] Who.int, “who | e-health,” 2015, [Accessed: May. 22, 2018]. [Online].Available: https://web.archive.org/web/20151224110111/http://www.who.int/trade/glossary/story021/en/

[18] Kry.se, “Läkarbesök i mobilen.” 2018, [Accessed: May. 23, 2018]. [Online].Available: https://kry.se/

[19] “Penetration Testing for IT Infrastructure,” 2017. [Online]. Available: https://www.coresecurity.com/penetration-testing

[20] “The Types of Penetration Testing,” 2016. [Online]. Available: http://resources.infosecinstitute.com/the-types-of-penetration-testing/

[21] A. Mohan, “Cyber security for personal medical devices internet of things,” in 2014IEEE International Conference on Distributed Computing in Sensor Systems, May2014, pp. 372–374.

[22] S. Alasmari and M. Anwar, “Security & privacy challenges in iot-based healthcloud,” in 2016 International Conference on Computational Science and Compu-tational Intelligence (CSCI), Dec 2016, pp. 198–201.

[23] M. Omoogun, P. Seeam, V. Ramsurrun, X. Bellekens, and A. Seeam, “When ehealthmeets the internet of things: Pervasive security and privacy challenges,” in 2017 In-ternational Conference on Cyber Security And Protection Of Digital Services (CyberSecurity), June 2017, pp. 1–7.

[24] S. Dahiya and M. K. Bohra, “Element-key table based complex key generation(e-ckg) for iot based health care networks,” in Proceedings of the 10thInternational Conference on Security of Information and Networks, ser. SIN’17. New York, NY, USA: ACM, 2017, pp. 59–64. [Online]. Available:http://doi.acm.org/10.1145/3136825.3136885

34

[25] L. Wu, X. Du, M. Guizani, and A. Mohamed, “Access control schemes for im-plantable medical devices: A survey,” IEEE Internet of Things Journal, vol. 4, no. 5,pp. 1272–1283, Oct 2017.

[26] R. Yan, T. Xu, and M. Potkonjak, “Data integrity attacks and defenses for intel labsensor network,” in 2015 IEEE 2nd World Forum on Internet of Things (WF-IoT),Dec 2015, pp. 721–726.

[27] M. El-hajj, M. Chamoun, A. Fadlallah, and A. Serhrouchni, “Analysis of authentica-tion techniques in internet of things (iot),” in 2017 1st Cyber Security in NetworkingConference (CSNet), Oct 2017, pp. 1–3.

[28] P. Rughoobur and L. Nagowah, “A lightweight replay attack detection frameworkfor battery depended iot devices designed for healthcare,” in 2017 InternationalConference on Infocom Technologies and Unmanned Systems (Trends and FutureDirections) (ICTUS), Dec 2017, pp. 811–817.

[29] R. Tahir, H. Tahir, A. Sajjad, and K. McDonald-Maier, “A secure cloud frameworkfor icmetric based iot health devices,” in Proceedings of the Second InternationalConference on Internet of Things, Data and Cloud Computing, ser. ICC ’17.New York, NY, USA: ACM, 2017, pp. 171:1–171:10. [Online]. Available:http://doi.acm.org/10.1145/3018896.3056788

[30] M. A. Sahi, H. Abbas, K. Saleem, X. Yang, A. Derhab, M. A. Orgun, W. Iqbal,I. Rashid, and A. Yaseen, “Privacy preservation in e-healthcare environments: Stateof the art and future directions,” IEEE Access, vol. 6, pp. 464–478, 2018.

[31] A. B. Pawar and S. Ghumbre, “A survey on iot applications, security challenges andcounter measures,” in 2016 International Conference on Computing, Analytics andSecurity Trends (CAST), Dec 2016, pp. 294–299.

[32] P. Gope and T. Hwang, “Bsn-care: A secure iot-based modern healthcare systemusing body sensor network,” IEEE Sensors Journal, vol. 16, no. 5, pp. 1368–1376,March 2016.

[33] Nist.gov, “advanced encryption standard (aes),” 2001, [Accessed: May. 24, 2018].[Online]. Available: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf

[34] M. Vanhoef, “KRACK Attacks: Breaking WPA2,” 2017, [Accessed: May. 26,2018]. [Online]. Available: https://www.krackattacks.com/

[35] bluetooth core specification v5.0, 2nd ed. Bluetooth SIG, 2016. [Online].Available: https://www.bluetooth.com/specifications/bluetooth-core-specification

[36] M. Dworkin, “Recommendation for block cipher modes of operation: Theccm mode for authentication and confidentiality,” 2004. [Online]. Available:https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf

[37] IETF.org, “rfc 5246 - the transport layer security (tls) protocol version 1.2,” 2008,[Accessed: May. 23, 2018]. [Online]. Available: https://tools.ietf.org/html/rfc5246

[38] ——, “rfc 6347 - datagram transport layer security version 1.2,” 2012, [Accessed:May. 23, 2018]. [Online]. Available: https://tools.ietf.org/html/rfc6347

35

[39] G. Zaverucha, “Cryptography in alljoyn,” 2015, [Accessed: May. 24, 2018].[Online]. Available: https://events.static.linuxfound.org/sites/events/files/slides/Cryptography-in-AllJoyn-gregz-2015-Summit%20-%20Copy.pdf

[40] Github.com, “build software better, together,” 2018, [Accessed: May. 26, 2018].[Online]. Available: https://github.com/

[41] Kali.org, “kali linux,” 2018, [Accessed: May. 25, 2018]. [Online]. Available:https://www.kali.org/

[42] Aircrack-ng, “aircrack-ng/aircrack-ng,” 2018, [Accessed: May. 26, 2018]. [Online].Available: https://github.com/aircrack-ng/aircrack-ng

[43] Wireshark.org, “wireshark · go deep.” 2018, [Accessed: May. 26, 2018]. [Online].Available: https://www.wireshark.org/

[44] [email protected], “0x90/bluetooth-arsenal,” 2018, [Accessed: May. 26, 2018].[Online]. Available: https://github.com/0x90/bluetooth-arsenal

[45] Hakshop.com, “ubertooth one,” 2018, [Accessed: May. 26, 2018]. [Online].Available: https://hakshop.com/products/ubertooth-one

[46] Armis.com, “blueborne information from the research team - armis labs,” 2017,[Accessed: May. 25, 2018]. [Online]. Available: https://www.armis.com/blueborne/

[47] Riverloopsec@Github, “riverloopsec/killerbee,” 2018, [Accessed: May. 27, 2018].[Online]. Available: https://github.com/riverloopsec/killerbee

[48] Rapid7.com, “rapid7/metasploit-framework,” 2018, [Accessed: May. 26, 2018].[Online]. Available: https://github.com/rapid7/metasploit-framework

[49] Nmap.org, “nmap: the network mapper - free security scanner,” 2018, [Accessed:May. 26, 2018]. [Online]. Available: https://nmap.org/

[50] Ettercap, “ettercap/ettercap,” 2018, [Accessed: May. 26, 2018]. [Online]. Available:https://github.com/Ettercap/ettercap

[51] roe.ch, “sslstrip | penetration testing tools,” 2014, [Accessed: May. 26, 2018].[Online]. Available: https://tools.kali.org/information-gathering/sslstrip

[52] Gentilkiwi@Github, “gentilkiwi/mimikatz,” 2018, [Accessed: May. 26, 2018].[Online]. Available: https://github.com/gentilkiwi/mimikatz

[53] Portswigger.net, “burp suite scanner | portswigger,” 2018, [Accessed: May. 26,2018]. [Online]. Available: https://portswigger.net/burp/

[54] SQLmap.org, “sqlmapproject/sqlmap,” 2018, [Accessed: May. 26, 2018]. [Online].Available: https://github.com/sqlmapproject/sqlmap

[55] Openvas.org, “openvas - openvas - open vulnerability assessment system,” 2018,[Accessed: May. 26, 2018]. [Online]. Available: http://www.openvas.org/

[56] Trustedsec.com, “set | penetration testing tools,” 2014, [Accessed: May. 26, 2018].[Online]. Available: https://tools.kali.org/information-gathering/set

36

[57] Hashcat, “hashcat/hashcat,” 2018, [Accessed: May. 26, 2018]. [Online]. Available:https://github.com/hashcat/hashcat

[58] Mosquitto.org, “eclipse mosquitto,” 2018, [Accessed: May. 26, 2018]. [Online].Available: https://mosquitto.org/

[59] NIST.gov, “nvd - cve-2017-5638,” 2017, [Accessed: May. 27, 2018]. [Online].Available: https://nvd.nist.gov/vuln/detail/CVE-2017-5638

[60] R. Hammer, Reverse Shells Enable Attackers To Operate From Your Network.SANS, 2018. [Online]. Available: https://www.sans.edu/student-files/presentations/LVReverseShell.pdf

[61] Mitre.org, “cve -common vulnerabilities and exposures (cve),” 2018, [Accessed:May. 27, 2018]. [Online]. Available: https://cve.mitre.org/

37

A Appendix

A.1 Acronyms

Acronyms

CPU Central processing unit

GPU Graphics processing unit

IoT Internet of Things

MAC Message Authentication Code

HMAC Hash-based Message Authentication Code

SHA Secure Hash Algorithm

AES Advanced Encryption Standard

RFC Request For Comments

IEEE Institute of Electrical and Electronics Engineers

ACM Association for Computing Machinery

ISO International Organization for Standardization

NIST National Institute of Standards and Technology

OWASP The Open Web Application Security Project

ENISA European Union Agency for Network and Information Security

HIMSS Healthcare Information and Management Systems Society

Acronyms used in the report

A

A.2 IoT communication technologies

Name Communication technology Range

ZigBee

• Based on IEEE 802.15.4 forshort-range communication.• Works in the 2.4 GHz frequencyrange and focuses on deliveringlow data rates with low powerconsumption.• Wireless Personal Area Network.

10-100m

Bluetooth LowEnergy (Bluetooth4.0)

• Based on IEEE 802.15.1.• Works in the 2.4 GHz frequencyrange and focuses on low powercommunication.• Wireless Personal Area Network.

>100 m

Near-fieldcommunication(NFC)

• Based on RFID standardISO/IEC 14443, Defined inISO/IEC 18092 and 21481.• Works in the 13.56 MHz range.• Wireless Personal Area Network.

<20 cm

Radio-frequencyidentification(RFID)

• Standard ISO/IEC 14443,18000-x.• Works in the 13.56 MHz range(Standard ISO/IEC 18000-3 mostused in healthcare).• Wireless Personal Area Network.

10 cm-1 m

IPv6 overLow-PowerWireless PersonalArea Networks(6LoWPAN)

• RFC 4944. Based on IEEE802.15.4.• Works in the 2.4 GHz frequencyrange.• Wireless Personal Area Network

10-100m

Light-fidelity(Li-Fi)

• IEEE 802.15.7 standard.• Works in the visible lightspectrum.• Wireless Personal Area Network.

Direct line ofsight or bouncedof a reflectivesurface.

Wi-Fi

• Based on IEEE 802.11 standards.• Works in the 2.4 GHz or 5 GHzfrequency range.• Local Area Network.

>10m

LoRa

• Patented and developed byCycleo of Grenoble.• Works in 868 MHz (Europe)made for very long low-poweredcommunication• Low-Power Wide-Area Network.

2 km - 22 km

B

LTE-Advanced

• 3GPP standard.• Works in 800,900 MHz,1.8,1.9/2.1, 2.5 GHz (Europe),Cellular technique.• Metropolitan Area Network

Depends on thefrequency band.(Sweden 900MHz <11 km)

Ethernet

• IEEE 802.3 standard.• Wired.• Local Area Network,Metropolitan Area Network, Widearea network.

<100 m (Twistedpair)<100 km (Opticalfiber)

Most used technologies used to enable IoT, and small description of them.

C

A.3 Inclusion - Exclusion results

Inclusion-Exclusion documentmj223gn Thesis

Inclusion-Exclusion criteriaThe article/book need to match our search queries, in Meta text, keywords or in the ab-stract. The publishing date for the reports should be between 2014 - 2018 present (Febru-ary 22, 2018), this to focus the scope for the newest information. The selection is made intwo runs, first only the abstract is matched against the criteria. Secondly, the reports thatpassed the first run, we match the full-text.

Search queriesMust include: Internet of Things + security + Healthcare Must include one: Confiden-tiality, Integrity, access control Published between: 2014 - 2018 present (February 22,2018)

D

Searched The ACM Full-Text Collection, February 24, 2018

Title Author(s) URL Inclusion

1 Low-Cost Standard Public KeyCryptography Services for WirelessIoT Systems

Muslum Ozgur Ozmen and AttilaA. Yavuz

http://doi.acm.org/10.1145/3139937.3139940

Yes

2 Cloud-Fog Interoperability in IoT-enabled Healthcare Solutions

Redowan Mahmud and FernandoLuiz Koch and Rajkumar Buyya

http://doi.acm.org/10.1145/3154273.3154347

No

3 A Secure Cloud Framework for IC-Metric Based IoT Health Devices

Ruhma Tahir and Hasan Tahir andAli Sajjad and Klaus McDonald-Maier

http://doi.acm.org/10.1145/3018896.3056788

Yes

4 SmartHealth-NDNoT: Named DataNetwork of Things for HealthcareServices

Divya Saxena and Vaskar Ray-choudhury and Nalluri SriMahathi

http://doi.acm.org/10.1145/2757290.2757300

Yes

5 Internet of Things Patterns Lukas Reinfurt and Uwe Breiten-bücher and Michael Falkenthal andFrank Leymann and Andreas Riegg

http://doi.acm.org/10.1145/3011784.3011789

Yes

6 Mitigating Poisoning Attacks onMachine Learning Models: A DataProvenance Based Approach

Nathalie Baracaldo and BryantChen and Heiko Ludwig and Jae-hoon Amir Safavi

http://doi.acm.org/10.1145/3128572.3140450

No

7 A New Secure Model for the Use ofCloud Computing in Big Data Ana-lytics

Habiba Chaoui and Ibtissam Mak-doun

http://doi.acm.org/10.1145/3018896.3018913

Yes

8 A Novel Authentication Protocolfor Micropayment with WearableDevices

Alexander Yohan and Nai-Wei Loand Vincentius Randy and Shih-JenChen and Ming-Yuan Hsu

http://doi.acm.org/10.1145/2857546.2857565

No

9 Internet-of-Medical-Things Niraj K. Jha http://doi.acm.org/10.1145/3060403.3066861

No

E

10 IoT Security Challenges and WaysForward

Marcel Medwed http://doi.acm.org/10.1145/2995289.2995298

No

11 User-centric, Embedded Vision-based Human Monitoring: A Con-cept and a Healthcare Use Case

Tahir Nawaz and Bernhard Rinnerand James Ferryman

http://doi.acm.org/10.1145/2967413.2967422

Yes

12 Element-key Table Based ComplexKey Generation (E-CKG) for IoTBased healthcare Networks

Shailja Dahiya and Manoj KumarBohra

http://doi.acm.org/10.1145/3136825.3136885

Yes

13 Keynote: Research Challenges andOpportunities in IoT Security

Elisa Bertino http://doi.acm.org/10.1145/3139531.3139535

No

14 A Secure Sum Protocol and ItsApplication to Privacy-preservingMulti-party Analytics

Shagufta Mehnaz and GowthamBellala and Elisa Bertino

http://doi.acm.org/10.1145/3078861.3078869

No

Out of 14 articles from ACM, I have included 7 based on abstract and keyword screening.

F

Searched IEEE explore, February 25, 2018

Title Author(s) URL Inclusion

15 Federated system-to-service au-thentication and authorizationcombining PUFs and tokens

M. Beltrán; M. Calvo; S. González http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8016157

Yes

16 BSN-Care: A Secure IoT-BasedModern Healthcare System UsingBody Sensor Network

P. Gope; T. Hwang http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7332745

Yes

17 A Novel Authentication andKey Agreement Protocol forInternet of Things Based Resource-Constrained Body Area Sensors

M. A. Iqbal; M. Bayoumi http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7592744

Yes

18 Privacy Preservation in e-Healthcare Environments: State ofthe Art and Future Directions

M. A. Sahi; H. Abbas; K. Saleem;X. Yang; A. Derhab; M. A. Orgun;W. Iqbal; I. Rashid; A. Yaseen

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8089328

Yes

19 Data integrity attacks and defensesfor Intel lab sensor network

R. Yan; T. Xu; M. Potkonjak http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7389143

Yes

20 Securing the Communicationsin a WoT/WebRTC-based SmartHealthcare Architecture

S. E. Jaouhari; A. Bouabdallah; J.M. Bonnin; T. Lemlouma

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8121804

Yes

21 Enhanced BSN-Care: Cryptanaly-sis of BSN-Care and proposal ofimproved authentication system

S. G. Yoo; F. Castro De La Gruz http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8066076

Yes

22 A lightweight replay attack de-tection framework for battery de-pended IoT devices designed forhealthcare

P. Rughoobur; L. Nagowah http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8286118

Yes

G

23 An IoT Data CommunicationFramework for Authenticity andIntegrity

X. Li; H. Wang; Y. Yu; C. Qian http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7946871

No

24 Analysis of authentication tech-niques in Internet of Things (IoT)

M. El-hajj; M. Chamoun; A. Fad-lallah; A. Serhrouchni

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8242006

Yes

25 BPMN Security Extensions forHealthcare Process

K. S. Sang; B. Zhou http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7363392

Yes

26 When eHealth meets the internet ofthings: Pervasive security and pri-vacy challenges

M. Omoogun; P. Seeam; V. Ram-surrun; X. Bellekens; A. Seeam

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8074857

Yes

27 A Secure IoT-Based HealthcareSystem With Body Sensor Net-works

K. H. Yeh http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7779108

No

28 A survey on IoT applications, se-curity challenges and counter mea-sures

A. B. Pawar; S. Ghumbre http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7914983

Yes

29 The Internet of Things for health-care monitoring: Security reviewand proposed solution

A. Rghioui; A. L’aarje; F. Elouaai;M. Bouhorma

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7016651

Yes

30 Development of Unique Identity forE-Health Sensor Node in EHEARTPasswordless Authentication Proto-col

N. H. Kamarudin; Y. M. Yussoff; N.Marbukhari; M. Samad; H. Hashim

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8109341

Yes

31 Security & Privacy Challenges inIoT-Based Health Cloud

S. Alasmari; M. Anwar http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7881337

Yes

H

32 A PHY-Aided Secure IoT Health-care System with Collaboration ofSocial Networks

P. Hao; X. Wang http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8288341

No

33 Privacy Is Healthy K. Caine http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7676202

Yes

34 Mobile Health (m-Health) Systemin the Context of IoT

S. H. Almotiri; M. A. Khan; M. A.Alghamdi

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7592698

Yes

35 Multi-authority attribute-based ac-cess control scheme in mHealthcloud with unbounded attribute uni-verse and decryption outsourcing

Q. Li; H. Zhu http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8171106

No

36 Using Attribute-Based Access Con-trol for Remote Healthcare Moni-toring

I. Ray; B. Alangot; S. Nair; K.Achuthan

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7939154

Yes

37 A secure patient information trans-fer method through delegated au-thorization

J. Park; S. Je; S. Jung; S. Jung http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7763434

No

38 A pragmatic approach to solvingIoT interoperability and securityproblems in an eHealth context

R. Giaffreda; L. Capra; F. Antonelli http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7845452

Yes

39 IoT-based E-health system security:A vision archictecture elements andfuture directions

G. S. Tamizharasi; H. P. Sultanah;B. Balamurugan

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8212747

No

40 The Effect of the Internet of Things(IoT) on Education Business Model

M. Bagheri; S. H. Movahed http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7907501

No

I

41 Multi-Level Privacy-PreservingAccess Control as a Service forPersonal Healthcare Monitoring

U. Salama; L. Yao; X. Wang; H. Y.Paik; A. Beheshti

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8029854

Yes

42 A virtual PHR authorization system M. Poulymenopoulou; F. Mala-mateniou; G. Vassilacopoulos

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=6864307

No

43 A smart-phone based privacy-preserving security framework forIoT devices

M. Togan; B. C. Chifor; I. Florea;G. Gugulea

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8166453

No

44 Cyber Security for Personal Medi-cal Devices Internet of Things

A. Mohan http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=6846193

Yes

45 Access Control Schemes for Im-plantable Medical Devices: A Sur-vey

L. Wu; X. Du; M. Guizani; A. Mo-hamed

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7933942

Yes

46 Review of Ethereum: Smart homecase study

Y. N. Aung; T. Tantidham http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8257877

No

47 Design of a High-Performance Sys-tem for Secure Image Communica-tion in the Internet of Things

E. Kougianos; S. P. Mohanty; G.Coelho; U. Albalawi; P. Sundar-avadivel

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7434569

No

48 Scalable Role-Based Data Disclo-sure Control for the Internet ofThings

A. Yavari; A. S. Panah; D. Geor-gakopoulos; P. P. Jayaraman; R. v.Schyndel

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7980174

No

49 M2M service platforms and devicemanagement

I. Danila; R. Dobrescu; D. Popescu;R. Marcu; L. Ichim

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7133674

Yes

J

50 World of Empowered IoT Users S. H. Hashemi; F. Faghri; P.Rausch; R. H. Campbell

http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7471347

Yes

Out of 36 articles from IEEE i have included 24 based on abstract and keyword screening.

K

Full text analysisWhile going through the included articles from the above inclusion-exclusion criteria, wefill out this table with comments and a decision. This time I will go through the full textof the article to see if the criteria also match in the full text. 31 articles are going throughto this full-text analysis.

Here we will use the row number of the above table for each report while having alarger comment area to write a small summary of each article and why we included it ornot.

Inclusion? Why?1 No The report is about solving the issue with energy-heavy en-

cryption standards that are not meant for battery-powereddevices as IoT by using other methods and standards.

3 Yes This report has an excellent chapter about the threats againstwearable IoT devices. However, no research on other so-lution then ICMetric is mentioned. http://doi.acm.org/10.1145/3018896.3056788

4 No This report has an excellent introduction for reference gath-ering, but the rest of the report is just research or suggestionon how an NDN(Named Data network) could help with thedepletion of IPv4 IP address.

5 No Goes through different patterns of IoT and how to build IoTnetworks. It even has some security in the report but nothingspecific on healthcare or our other three keywords.

7 No Not focused on IoT, even if a large part of IoT is Big Data.Have a useful table on how to get confidentiality and in-tegrity but for Big Data.

11 No A little focus on the security and privacy but only focus onvideo capture and how this could help healthcare if we canhave devices that detect people falling for example.

12 Yes The report has a useful introduction which talks about con-fidentiality security over the internet but focuses on how tocreate proper encryption keys. Reference material. http://doi.acm.org/10.1145/3136825.3136885

15 No The report points out a solution for authentication based onPUF (Physical Unclonable Functions) and two tokens. Notsomething for our thesis.

16 Yes This report handles security in Body sensor networks.Talking about CodeBlue a Harvard study on Body sen-sor networks. http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7332745&tag=1

17 No Focus on its protocol to make the transport more secure.Don’t talk why it is insecure and also focus on encryptionand how we need to move to asymmetric encryption(RSAfor example).

L

18 Yes Have a lot of excellent references and talks a lot aboutthe problem of e-healthcare. Has many references thatneed "snowballing" look into this after this full-textanalysis. http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8089328

19 Yes Useful information about integrity and how wecan attack/defend against integrity attacks. Alsogood references in the introduction and relevantwork.http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7389143

20 No While being a good read, the report is too focused on We-bRTC. Have some section about CoAP and DTLS as wellbut not enough information for our report.

21 No This report is just an analysis of report 16 to show the errorsin that report. Good to know that the nr 16 reports protocolhas flaws but not useful for our report.

22 Yes The report has useful information in the introduction andliterature review parts. However, the rest of the report isabout their implementation and how it secures transmis-sions. http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8286118

24 Yes Good short paper on authentication techniquesthat are out there in the research world. http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8242006

25 No The report is about a security extension the authors havewritten to the healthcare design process.

26 Yes The last part of the report brings up security and pri-vacy aspects of IoT devices. It also takes up threats asa chapter describing the most common threats. This re-port can be a good start for the challenges chapter in ourreport. http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=8074857

28 Yes This report has looked through other reports andsurveyed them together. So with this report, weget an overview of what implementing these pro-tocols can do for solving some of the problems.http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7914983

29 Yes Takes up where in healthcare IoT devices could be lo-cated and what they do. Some useful reference for ourintroduction. This report takes up some security aspectsas well. http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7016651

30 No No real security information, some small stuff about vulner-abilities but nothing for our report.

M

31 Yes Useful information about HIPAA, EPHI and what prob-lems there is with using the cloud in healthcare.Takes up which security issues HIPAA has recog-nised. http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7881337

33 No No technical aspects and most about privacy with no corre-lation to security in the devices.

34 No Focus on HIPAA compliance. No real security aspect morethan the introduction where it refers to other reports.

36 No There is no general information about access control and itschallenges. Focus on Role-based access control (RBAC),NIST Next generation access control (NGAC) and their H-plane design.

38 No Gives a useful link to UNCAP (Ubiquitous iNteroperableCare for Ageing People) which can hold more informa-tion. Else the report has nothing on security or any pro-tocol/hardware challenges.

41 No This report also proposes their model to handle access con-trol in the healthcare environment. However, No informa-tion about our specific challenges.

44 Yes Excellent report for our thesis. Shows threats toIoT in healthcare, what challenges there is on solv-ing these threats and some solutions to the chal-lenges. http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=6846193

45 Yes Much useful information. Have a section with se-curity incidents. Focused on the USA but canbe regulations that could be in Europe as well.Need to do a close look at the regulations in-side EU. http://ieeexplore.ieee.org.proxy.lnu.se/stamp/stamp.jsp?arnumber=7933942

49 No Useful information about why we need M2M standards inthe future. Don’t talk anything about the security require-ments so not that interesting for our thesis.

50 No Takes up the healthcare domain but is not focused on it.Same information on EHR as other reports and this reportalso propose their on design to secure IoT communication.

From the 31 articles that went through the abstract criteria there is 13 in the full textanalysis that was matched for an inclusion. These 13 will follow and be used in the thesis.

N