1

SECURITY VULNERABILITIES IN MOBILE HEALTH APPLICATIONS

A THESIS

Presented to the University Honors Program

California State University, Long Beach

In Partial Fulfillment

of the Requirements for the

University Honors Program Certificate

Michael Black

Spring 2018

2

I, THE UNDERSIGNED MEMBER OF THE COMMITTEE,

HAVE APPROVED THIS THESIS

SECURITY VULNERABILITIES IN MOBILE HEALTH APPLICATIONS

BY

Michael Black

______________________________________________________________________________

Mehrdad Aliasgari, Ph.D. (Thesis Advisor) Computer Science

California State University, Long Beach

Spring 2018

3

ABSTRACT

SECURITY VULNERABILITIES IN MOBILE HEALTH APPLICATIONS

By

Michael Black

May 2016

With the growth of mobile health applications, it is imperative to make sure the users'

health records and their privacy are safeguarded properly. In this work, we analyze twenty five

mobile health applications for security vulnerabilities. Each of these applications is downloadable

from the Google Play Store, has a medical tag, requests permission for full network access, and

connects to a medical device. We focused on network security and authentication vulnerabilities,

various Man in the Middle attacks, and HIPAA noncompliance. The results of our security and

privacy tests indicate that each application suffers from security and/or privacy vulnerabilities. We

shared our findings with the respective developers of the applications.

4

TABLE OF CONTENTS Page LIST OF TABLES 5 LIST OF FIGURES 6 CHAPTER 1. INTRODUCTION 7 2. RELATED WORK 9 3. BACKGROUND 11 TLS Protocol 11 Tools 12 HIPAA 14 4. ENVIRONMENT 15 Applications 15 Setup 15 Searching for HIPAA Compliance 17 Ethics 18 5. OBSERVATIONS 19 SSL Labs Results 19 Fiddler Results 20 HIPAA Compliance 22 6. CONCLUSION 26 APPENDIX 28 REFERENCES 32

5

LIST OF TABLES TABLE Page 1. Tested Applications 15 2. SSL Labs Results - Grades 29 3. SSL Labs Results - TLS Version 29 4. SSL Labs Results - Key Exchange 29 5. SSL Labs Results - Cipher Suites 29 6. SSL Labs Results - HSTS 30 7. Fiddler Results 31

6

LIST OF FIGURES FIGURE Page 1. Android Fiddler Environment Setup 16 2. Searching for HIPAA Compliance - Initial Email 30 3. Searching for HIPAA Compliance - Follow Up 30 4. Fiddler Results - PHI Breakdown 30 5. Fiddler Results - MitM Revealed Information 21 6. HIPAA Compliance and Acknowledgement 24

7

CHAPTER 1

INTRODUCTION

Mobile health (mHealth) applications are an ever-expanding frontier in today's use of

technology. They allow a user to record health data, contact their doctor, and connect to medical

devices from the convenience of a smartphone. In fact, a 2015 study (Krebs, 2015) showed that

fifty-eight percent of Americans use mHealth applications. However, a major concern is user

privacy loss and its implications in case of a data breach with such mHealth applications

(“Notice of Data,” 2018).

It is, therefore, vital for developers of such applications to safeguard user data and define

preventive security measures. Additionally, the data transmitted and stored by an mHealth app

may be considered protected health information (PHI). PHI is protected by the Healthcare

Insurance Portability and Accountability Act (HIPAA), and requires additional security

measures.

In this work we examine the security and privacy protection mechanisms of twenty-five

mHealth applications. We identify security vulnerabilities in data transmission, unencrypted data

revealed by a Man in the Middle (MitM) attack, and HIPAA noncompliance in privacy

measures. We observed that every examined mHealth app suffered from some vulnerabilities one

way or the other. We urge developers and users to be cognizant of such security and privacy

pitfalls as over half of Americans' health data could be at risk of being compromised.

8

In what follows we provide a brief survey of previous work in this area. We then give a

background on the security protocols, tools we used for our experiments, and HIPAA

obligations. We next provide an overview of our testing environment and setup. Finally, we

report and analyze our observations and give a conclusion on our findings.

9

CHAPTER 2

RELATED WORK

There are previous works that have looked at the security of mHealth technologies. As

noted by Arora et. al. (2014), however, there is a sparsity in the research literature in this area

despite rapid growth of this technology. A major concern for mHealth is the secure transfer of

sensitive data, and Arora et. al. propose that the solution relies heavily on the insights of general

computer security. Arora et. al. concluded that at a minimum the HIPAA standards for

encryption (“The HIPAA Privacy,” 2018) should be upheld in mHealth technologies. They also

proposed that sensitive information should in some cases be replaced by non revealing code

words in the event that the data is intercepted by an MitM attack. Furthermore, they encouraged

two factor authentication for patient logins and consistent auditing of security systems.

Islam et. al. (2015) reiterated the need for a base in general computer security concerns for

mHealth applications including confidentiality, integrity, authentication, and availability. They

additionally reported requirements in the freshness of data so that an adversary cannot replay

messages, non repudiation so that a message cannot be denied in sending, authorization for nodes

across the network, resiliency, fault tolerance, and self-healing in the case of failures.

There have also been studies done on the security of general mobile applications. Lawrence

(2017) found that eighty percent of the top two-hundred most downloaded mobile applications

have the ability to opt out of using HTTPS. Onwuzurike et. al. tested mobile applications for TLS

10

configuration and found that forty-eight of the top one-hundred most downloaded Android

applications had insecure configurations.

Some mHealth applications can connect to sensors and devices. Bandyopadhyay et. al.

(2011) found that in addition to personal information, devices can also store and transmit a user’s

physical location and movement in real time. Halperin et. al. (2008) surveyed data related to

medical devices in particular could reveal a patient’s diagnosis, treatment history, allergies, and

medications.

11

CHAPTER 3

BACKGROUND

In this section we introduce the TLS protocol, tools we utilized for our experiments,

and HIPAA.

TLS protocol

Transport Layer Security (TLS) is an Internet protocol that provides data integrity and

privacy (Rouse 2016) between two communicating nodes. It was preceded by the Secure Sockets

Layer (SSL) and the two acronyms are often used interchangeably. TLS is more secure than SSL

due to its addition of authentication to messages and improved algorithms for cipher suites. Each

TLS connection between nodes starts with an HTTP handshake (Kemmerer, 2015). The nodes

agree on which cipher suite will be used during this handshake and thereafter encrypt their

correspondences with that cipher suite.

A cipher suite is a set of methods used for encrypting data sent between two nodes

(Villanueva, 2015). Cipher suites are used by TLS and SSL protocols and usually include a key

exchange algorithm, an authentication algorithm, a bulk encryption algorithm for encrypting the

message data, and a Message Authentication Code (MAC) algorithm for checking the authenticity

of a message.

Servers configured to use TLS can enable Strict Transport Security (HSTS). HSTS is a

protocol that protects against HTTP Downgrade Attacks (Ndegwa, 2018). Adversaries use these

attacks to force a server to communicate using HTTP, allowing the attacker to view data in plain

12

text. HSTS only allows a server to communicate with a client when using HTTPS to ensure that

the channel is encrypted.

There are known vulnerabilities that proper TLS configuration protects against. Three of

these vulnerabilities emerged during our experiments. They are OpenSSL Padding Oracle

vulnerability, RC4 insecurity, and using common Diffie-Hellman primes.

The OpenSSL Padding Oracle vulnerability is made possible by the use of padding in block

ciphers (Barnett, 2014). Here, a block can be thought of a chunk of information. Encrypted

messages need to be be padded with extra characters if the message does not take up the complete

space of a multiple of blocks. A Padding Oracle is a program that helps expose whether or not the

used padding is acceptable. An adversary can use this oracle to reverse engineer bytes of a message

by tampering with the content and observing whether or not the padding is valid.

RC4 is a cipher that has been observed to be insecure due to several vulnerabilities and

using this cipher weakens a server’s implementation of TLS (“RC4,” 2017).

Using common primes is insecure when using Diffie-Hellman key exchange (DH)

(TLS/SSL, 2016). DH is a method of exchanging keys between a client and a server so that their

communication can be encrypted. This exchange uses an algorithm that relies on very large prime

numbers. Using common prime numbers for this algorithm gives an adversary the ability to use a

lookup table or make feasible computations in order to decrypt messages and view them in plain

text.

Tools

13

Wireshark, SSL Labs, and Fiddler are tools that we used for our experiments. In this section

we give a brief overview of these tools.

Wireshark

Wireshark is a tool used to capture packets and analyze the use of Internet protocols

(“About Wireshark,” 2018). Packets are units of data that collectively make up a message between

two nodes (“What is a Packet,” 2000). We used Wireshark to examine the HTTP requests made

by each app. It gave us information about which servers an application makes API calls to.

SSL Labs

SSL Labs is a website that tests a server’s certificate and configuration to determine the

server’s TLS security grade (Ristic, 2018). It also gives information regarding the security of a

server’s protocol support, key exchange, and cipher strength. SSL Labs provides a detailed

description of handshake simulations using different platforms including Android, Chrome, and

Firefox. Additionally, it tests a server for various known vulnerabilities, including OpenSSL

Padding Oracle vulnerability (Barnett, 2014), RC4 insecurity (“RC4,” 2017), and using common

Diffie-Hellman primes (“TLS/SSL,” 2016).

Fiddler

Fiddler is a web debugging proxy (“Telerik,” 2018). A proxy is a middleman between two

communicating nodes that is used to filter or observe the nodes’ messages (“What is a Proxy,”

2018). A reverse proxy is a proxy that forwards resources to server nodes from client nodes (Ellrod,

2010). We used Fiddler as a reverse proxy to perform MitM attacks on the applications. An MitM

attack is one in which an adversary intercepts messages of a node before forwarding them to the

14

intended receiver. An adversary can either eavesdrop on the messages as a passive adversary or

modify the messages as an active adversary.

HIPAA

HIPAA defines PHI as any information that is "created or received by a health care

provider, health plan, public health authority, employer, life insurer, school or university" or

"relates to the past, present, or future physical or mental health or condition of any individual"

(“HIPAA Protected,” 2018). HIPAA is designed to secure PHI by addressing audit control (the

ability for a user to read and modify their data), unique user identification, automatic logoff,

encryption and decryption, auditing, authentication, data storage of PHI, transmission security, and

notifications of security breaches.

Failure to comply with HIPAA standards when dealing with PHI can result in a fine

(“HIPAA Violation,” 2017). Unknowingly violating HIPAA results in a $100 minimum fine,

reasonably violating HIPAA results in a $1,000 minimum fine, and willingly neglecting to comply

with HIPAA results in a $10,000 fine. These fines apply to each individual violation and have

annual maximums of $1,500,000 that can be reached if multiple violations are obtained.

15

CHAPTER 4

ENVIRONMENT

The following section gives insight into our environment. We specify the applications we

tested, our environment setup, searching for HIPAA compliance, and ethics.

Applications

Table 1 shows the twenty-five applications that we tested. Each of these applications was

downloaded from the Google Play store and had to have either a medical or healthcare tag.

Additionally, each of the applications had to request full network access and have the ability to

connect to a medical device.

TABLE 1. Tested Applications

Setup

Our testing environment included a Lenovo Yoga laptop running Kali Linux Rolling and a

Samsung Galaxy S-6 running Android 7.0 (Nougat). The latter was used for providing Wifi to a

Pineapple Tetra auditing system that the laptop used to analyze packets using Wireshark. SSL Labs

16

was accessed on the laptop and used to test for TLS configurations. Fiddler was also accessed on

the laptop and configured as a reverse proxy. The phone used as a host for the applications was a

Samsung Galaxy S-5 running Android 6.0 (Marshmallow).

We used Wireshark to discover which server an application makes API calls to. We then

entered the domain name of the server into SSL Labs. This provided us with information about the

server's configuration, including TLS version, whether or not the server’s certificate is trusted, and

the preferred cipher suites. This domain name was discovered by using the IP’s in HTTP requests

made by the application observed in Wireshark.

FIGURE 1: Android Fiddler Environment Setup

17

We configured Fiddler as a reverse proxy by following the instructions listed on the Fiddler

website. We then installed a Fiddler root certificate on the Android device used for testing the

mobile applications. Fiddler forwarded messages between the Android device and the wifi router.

We were able to decrypt all packets transmitted to or from the phone in a Man in the Middle Attack

with the root certificate installed on the smartphone. Refer to Figure 1 for step by step instructions.

Searching for HIPAA Compliance

HIPAA requires that all application developers provide confidentiality, integrity, and

availability when processing a user's PHI. Additionally, these developers must protect their users

from reasonably anticipated threats. HIPAA also explicitly addresses the need for a developer to

encrypt users' PHI (“Summary,” 2018). We kept these requirements in mind when testing the

applications. We determined that if a mobile app is obligated to be HIPAA compliant, then that

app must also be responsible for implementing the mechanisms specified by HIPAA.

Searching for HIPAA compliance was first performed by reading through each

application’s terms and agreements, websites, and Google Play Store descriptions. In the spring of

2018, all development teams for the applications were emailed with an inquiry regarding general

HIPAA compliance questions. These same development teams were sent a follow up email with

more specific HIPAA compliance questions regardless of whether or not they had responded to

the initial email. Not all teams replied. Refer to Figure 2 and Figure 3 in the appendix for more

information.

Ethics

18

All analysis was done under a just and moral ethical obligation. All user info was generated

using fake data, including a dummy email address, name, and password. The host phone on which

the applications were analyzed is owned by us and at no point was any application code tampered

with in any way. No devices other than the host phone were analyzed when using Wireshark and

Fiddler.

All testing of the mobile applications was completed in the fall of 2017. This paper was

written in the spring of 2018 and any changes in applications and finding since the fall 2017 tests

will be explicitly mentioned.

In May of 2018 we notified the respective application developers of our findings. An email

was sent to these teams with a copy of this paper.

19

CHAPTER 5

OBSERVATIONS

Our observations can be broken down into three categories. The first category is the

results of the app servers’ TLS configuration, and it includes the topics of TLS version, key

exchange, cipher suites, and HSTS. The second category is the results of using Fiddler, and it

focuses on unencrypted sensitive data using a Man in the Middle attack and determining which

applications may be subject to HIPAA compliance. The third and final category focuses on the

applications’ accountability to the terms of HIPAA.

SSL Labs Results

One of the twenty-five mobile applications (Heart Rate Monitor) makes no API calls to a

server. Three of the applications (Gluco-Smart, MyVitals, Missi Remote Health) made API calls

to a server with an untrusted certificate, giving them a T rating. Only four of the applications

(Health2Sync, MedM Health, Mob ECG, and SaniQ Asthma) received the ideal grade of A+. The

remaining applications were given poor grades from SSL Labs, ranging from B to F ratings, as

seen in Table 2 in the Appendix.

Only one application (PeriCoach) made API calls to a server that supported TLS 1.3.

Twenty-four of the application servers supported TLS 1.2. Only one application server (Air Smart

Spirometer) refrained from supporting TLS 1.1. Only two application servers (Air Smart

Spirometer and Walgreens Connect) refrained from supporting TLS 1.0. None of the application

servers supported SSL 3 nor SSL 2. Refer to Table 3 in the appendix for more information.

20

Only three of the applications used a 4096 bit RSA key while twenty-one of the

applications used a 2048 bit RSA key. Twenty-four applications used SHA256 with RSA for their

signing algorithm. Refer to Table 4 in the appendix for more information. There are arguments for

using one length over the other due to the uneven ratio between key size increase versus security

increase (Di Mauro, 2015). It is expected that 2048 bit RSA keys will be obsolete by 2030

(Villanueva, 2017).

Four of the applications communicated with servers that had no preference on the order of

accepted cipher suites. This is potentially dangerous because an adversary could force the server

to use a weak cipher suite. Only one of the applications (MedM Health) used no weak cipher suites.

Refer to Table 5 in the appendix for more information.

Only three of the application servers (MedM Health, MobECG, SaniQ Asthma) supported

HSTS. One of the applications (TACTIO HEALTH) had the ability to support HSTS but had this

feature disabled. The remaining applications did not support HSTS. Table 6 in the appendix

records these results.

Fiddler results

Five applications (iHealth MyVitals, MedM Health, MobECG, Valedo, Heart Rate

Monitor) were unaffected by a Man in the Middle attack using Fiddler. The remaining twenty

applications revealed some user information in plain text. Twelve of the applications revealed the

patient’s password, sixteen revealed the patient’s name, and eighteen revealed the patient’s email.

Every application that revealed the user’s password in plain text also revealed the user’s email. An

adversary would have access to other user data if the user provides the same email and password

combination for other services such as social media accounts.

21

Eight applications revealed the patient’s weight, eight revealed the patient’s height, eight

revealed the patient’s birthday, and nine revealed the patient’s gender. Three of the applications

reveal information regarding whether or not the patient can speak English, whether or not the

patient is a U.S. citizen, and the ethnicity of the user. Four of the applications revealed the user's

address. Twelve of the applications also revealed protected health information, making these

applications subject HIPAA compliance. This information could be used by an adversary to answer

security questions for a user’s account or to aid in identity theft. Figure 5 visualizes the above

information. Table 7 in the appendix gives the specific information that each application revealed.

FIGURE 5: Fiddler Results - MitM Revealed Information

Twelve of the applications revealed PHI. Six of these applications revealed the user’s

measurements including glucose and blood sugar levels. Two applications revealed the user’s

medical history. Six of the applications revealed identification of the user’s clinicians. Three of

22

the applications revealed the user’s prescriptions. Three of the applications revealed the user’s

conditions, including whether or not the user was pregnant, had epilepsy, or had seizures. Three

of the applications revealed information about the user’s medical devices including device types

and its location. For more information, refer to Figure 4 and Table 7.

We know that all applications that revealed PHI are expected to be HIPAA compliant and

could be subject to HIPAA infractions. An adversary could use a victim's PHI to aid in hacking,

social engineering, or bribery. Additionally, an adversary could use the location of a user's medical

device to find the location of the user them self.

HIPAA Compliance

Only two of the applications (TACTIO HEALTH, Walgreens Connect) mentioned whether

or not the application was HIPAA compliant in the terms and conditions located within the app.

An email was sent to each of the applications’ development teams inquiring on the

acknowledgement of HIPAA compliance. The template for this email and its follow up can be

found in the appendix under Figure 2 and Figure 3.

The TACTIO HEALTH terms and conditions mentions that the application is HIPAA

Compliant in section 3.1.1, but does not clarify the steps that the development team has taken to

ensure that this is so.

Walgreens’ terms and conditions state that the company and all of its affiliates are HIPAA

compliant. It also discusses the situations in which Walgreens can share your PHI with other

HIPAA compliant entities. Walgreens’ terms and conditions does not discuss how it is HIPAA

compliant.

The Glooko support team replied to our emails with a link to a white paper discussing their

HIPAA compliance policy for the Cornerstones4Care - diabetes app. In it it stated that Glooko

23

provides reasonable access control, unique user identification, automatic logoff, and uses end to

end encryption with AES 256 to satisfy the security of health related data transmission. It continued

to clarify that Glooko audits its application. The white paper also mentions Glooko’s policies on

secure data storage of PHI and notification of data breaches.

MedM’s support team replied to notify us that they are not required to be compliant because

they only connect the user to services that handle PHI, but that they do implement most of the

HIPAA requirements and explicitly mentioned how they do so.

MySugr declined to respond, but directed us to their terms of use page. MySugr collects

personal information, including type of diabetes, blood glucose level, and insulin levels as stated

in these terms, but does not make any mention of HIPAA. MySugr does encrypt user data and

allows a user to access this data.

Qardio responded to our initial email assuring us that their app uses encryption. Qardio did

not respond to our follow up email with more specific questions concerned with how the

application demonstrates HIPAA compliance.

The Empatica development team responsible for the Alert and Mate applications responded

to our emails to notify us that they would respond to us at a later data but have not yet responded.

A representative from UDI Check responded to our emails notifying us that the application doesn't

record user data and is therefore not responsible for HIPAA compliance. The remaining

applications that have not been mentioned did not respond to our emails.

FIGURE 6: HIPAA Compliance and Acknowledgement

24

Only one application (Cornerstones4Care) responded to our emails and clearly defined how

the application handles each of the specifications outlined in Figure 3. Three more applications

(TACTIO HEALTH, Walgreens Connect, Qardio) responded to our emails claiming to be HIPAA

compliant, but not elaborating on how this is achieved. The remaining applications that revealed

PHI in a MitM attack did not respond to our emails.

The remaining thirteen applications are possibly not obligated to be HIPAA compliant. The

first of these (Heart Rate Monitor) did not make any API calls to a server and did not appear to

transmit or store any PHI. Two of these applications (MedM, UDI Check) responded to our emails

and explained why they are not expected to be HIPAA compliant. The ten others did not respond

to our emails, giving us no way to rule for or against these applications being HIPAA compliant

and whether or not they are obligated to be. Figure 6 above provides a visual representation of this

information.

25

CHAPTER 6

CONCLUSION

We found that twenty-one of the twenty-five applications have unideal SSL

configurations, twelve revealed passwords when using a MitM attack, and at least twelve

26

applications are obligated to be HIPAA compliant. Of the twenty-five applications, only one was

completely transparent in how it is HIPAA compliant, and only two explicitly mention HIPAA

in their terms and agreements in the application itself. Only seven of the application development

teams responded to our emails concerning HIPAA compliance. There was not a single

application that achieved an A+ SSL Labs rating, did not reveal a user’s password under a MitM

attack, and was transparent in HIPAA compliance simultaneously. We therefore conclude that

some mHealth applications suffer from well known security vulnerabilities and do not specify

measures taken to prevent them.

We shared these findings and the rest of our paper with the developers of the mHealth

applications we tested. We strongly suggest that mHealth developers be more aware of TLS

security for servers, encryption for user passwords and PHI, and HIPAA compliance where it is

necessary. There are online tutorials for properly configuring server protocols, salting and hashing

tactics for passwords, encryption techniques for PHI, and explanatory articles for the HIPAA law.

Additionally, we suggest that developers consistency audit their team. We recommend that

applications liable for HIPAA compliance enforce audits in particular because Section 164.312(b)

of the act requires it. We also suggest like Arora et. al. (2014) that some data is transmitted aliased

as code words to alleviate the consequences of a MitM attack. Finally, we suggest that users of

mHealth applications be aware of the security threats and to research an app before they use it.

There are some limitations to our study and we would like to expand on this subject in

future work. Surveying a larger pool of test apps would be sure to provide us with more accurate

information regarding the security vulnerabilities of mHealth apps. We were able to focus on

security in transmission of data in this study but not in data storage. Researching how PHI is stored

in mHealth servers could give us a more complete understanding of the vulnerabilities involved.

27

We would also like to study the vulnerabilities of sensors and hardware devices that connect to

mHealth apps.

28

APPENDIX

29

TABLE 2: SSL Labs Results - Grades TABLE 3:

SSL Labs Results - TLS Version

TABLE 4: SSL Labs Results - Key Exchange TABLE 5: SSL Labs Results - Cipher

Suites

30

TABLE 6: SSL Labs Results - HSTS FIGURE 2:

Searching for HIPAA Compliance - Initial

Email

31

FIGURE 4: Fiddler Results - PHI Breakdown

FIGURE 3: Searching for HIPAA Compliance -

Follow Up

32

TABLE 7: Fiddler Results

33

REFERENCES

REFERENCES

34

About Wireshark (2018). Wireshark. Retrieved from https://www.wireshark.org/

Arora, S., Yttri, J., & Nilsen, W. (2014). Privacy and Security in Mobile Health (mHealth) Research. Alcohol Research : Current Reviews, 36.1, 143–151. Retrieved from https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4432854/

Bandyopadhyay, D., & Sen, J. (2011). Internet of Things: Applications and Challenges in Technology and Standardization. Retrieved from https://link.springer.com/article/10.1007/s11277-011-0288-5

Barnett, B. (2014). CBC Padding Oracle Attacks Simplified - Key Concepts and Pitfalls. The Grymoire. Retrieved from https://grymoire.wordpress.com/2014/12/05/cbc-padding- oracle-attacks-simplified-key-concepts-and-pitfalls/

Di Mauro, A. (2015). The Big Debate, 2048 vs. 4096, Yubico’s Position. Yubico. Retrieved from https://www.yubico.com/2015/02/big-debate-2048-4096-yubicos-stand/

Ellrod, C. (2010). Reverse vs. Forward Proxy. Citrix. Retrieved from https://www.citrix.com/blogs/2010/10/04/reverse-vs-forward-proxy/

Halperin, D., Heydt-Benjamin, T.S., Fu, K., Kohno, T., Maisel, W.H. (2008). Security and Privacy for Implantable Medical Devices. IEEE Computer Society 7, 1. Retrieved from https://spqr.eecs.umich.edu/papers/b1kohFINAL2.pdf

HIPAA Violations and Enforcement. (2017). American Medical Association. Retrieved from https://www.ama-assn.org/practice-management/hipaa-violations-enforcement

The HIPAA Privacy Rule. (2018) HHS. Retrieved from https://www.hhs.gov/hipaa/for-

professionals/privacy/index.html

HIPAA ‘Protected Health Information’: What Does PHI Include? (2018). HIPAA. Retrieved from https://www.hipaa.com/hipaa-protected-health-information-what-does-phi-include/ Islam, S.M.R., Kwak, D., Kabir, H., Hossain, M., & Kwak, K. (2015) The Internet of Things for

Health Care: A Comprehensive Survey. IEEE Access 3, 678-708. Retrieved from https://www.semanticscholar.org/paper/The-Internet-of-Things-for-Health-Care%3A-A- Survey-Islam-Kwak/54a245a4e6bebdbba7d363fd490c439f7ad86b16

Villanueva, J.C. (2017). Should We Start Using 4096 bit RSA keys? JScape. Retrieved from http://www.jscape.com/blog/should-i-start-using-4096-bit-rsa-keys

35

Kemmerer, C. (2015). The SSL/TLS Handshake: an Overview. SSL. Retrieved from https://www.ssl.com/article/ssl-tls-handshake-overview/ Krebs, P., & Duncan, D.T. (2015). Health App Use Among US Mobile Phone Owners: A

National Survey. JMIR mHealth and uHealth 3.4, 101. Retrieved from https://www.ncbi.nlm.nih.gov/pubmed/26537656

Lawrence, B. (2018). 5 vital tips for developing HIPAA compliant mobile apps: A checklist. NowSecure. Retrieved from https://www.nowsecure.com/blog/2017/03/23/5-vital-tips- developing-hipaa-compliant-mobile-apps-checklist/

Ndegwa, A. (2018) What is HSTS? Stack Path. Retrieved from https://blog.stackpath.com/glossary/hsts/

Notice of Data Event: Primary Health Care Inc. (2018). Cision. Retrieved from https://www.prnewswire.com/news-releases/notice-of-data-event-primary-

health-care-inc-300615413.html Onwuzurike, L. & De Cistofaro, E. (2015). Danger is My Middle Name: Experimenting with

SSL Vulnerabilities in Android Apps. London: University College. Retrieved from https://dl.acm.org/citation.cfm?id=2766522

RC4 Encryption Algorithm. (2017). Vocal. Retrieved from https://www.vocal.com/cryptography/rc4-encryption-algoritm/

Ristic, I. (2018). About SSL Labs. Qualys SSL Labs. Retrieved from https://www.ssllabs.com/

Rouse, M. (2016). Transport Layer Security (TLS). Search Security. Tech Target. Retrieved from https://searchsecurity.techtarget.com/definition/Transport-Layer-Security-TLS Summary of the HIPAA Security Rule. (2018). HHS. Retrieved from

https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html Telerik Fiddler. (2018). Telerik. Retrieved from https://www.telerik.com/fiddler

TLS/SSL Server is Using Commonly Used Prime Numbers. (2016). Rapid 7. Retrieved from https://www.rapid7.com/db/vulnerabilities/tls-dh-primes

36

Villanueva, J. (2015). An Introduction to Cipher Suites. JScape. Retrieved from http://www.jscape.com/blog/cipher-suites What is a packet? (2000). How Stuff Works. Retrieved from

https://computer.howstuffworks.com/question525.htm

What is a Proxy Server? (2018). Indiana University Knowledge Base. Retrieved from https://kb.iu.edu/d/ahoo