Design of a cross-platform mobile application for sharing self-collected health data securely with health services

(1)

Design of a cross-platform mobile application for sharing self-collected health data securely with health services

Joakim K ˚arstad Tran

Master’s thesis in Software Engineering at

Department of Computing, Mathematics and Physics, Bergen University College

Department of Informatics, University of Bergen

June 2019

(2)

Abstract

There is a need for sharing and integrating patients’ self-collected health data with electronic health records used by clinicians.

A cross-platform mobile application has been developed in order to meet this need.

It shares health data securely and is compatible with the Norwegian Centre for E-health Research’s FullFlow architecture.

The application’s design and its components are studied in order to find out which technologies are suited for this type of application to ensure usability, integration with the Norwegian healthcare infrastructure, and confidentiality and integrity of health data.

(3)

Acknowledgements

First, I want to thank my supervisors, P˚al Ellingsen, and Alain Giordanengo for all the time they have spent guiding me. Both have been invaluable in the development phase and writing process.

Thanks to Astrid Grøttland and Eirik ˚Asand at the Norwegian Center for E-health Research for their cooperation and for including me in meetings pertaining to the FullFlow project.

I also want to thank Anders Steen Nilsen for including me in the process of finishing his master thesis and for helping me get started with mine.

(4)

List of Figures

1.1 Mobile threats [76] . . . 3

1.2 Kjernejournal gathers health information from several sources . . . 6

1.3 Simplified data flow. . . 7

1.4 Visual report of glucose data . . . 7

3.1 OpenID Connect Protocol Overview [81] . . . 18

3.2 Code authorization flow with PKCE . . . 19

3.3 PGP encryption [52] . . . 21

3.4 Observation example . . . 23

3.5 Observation example with an extra field . . . 23

4.1 Architecture . . . 30

4.2 Sending data to Helsenorge . . . 33

5.1 Median encryption run time, debugger attached . . . 41

5.2 Median run time, native encryption . . . 42

5.3 Median run time, native and JavaScript encryption . . . 42

5.4 Median decryption run time . . . 43

5.5 Median run time, retrieve observation internals (iPhone 6) . . . 43

5.6 Median run time, retrieve observation internals (LG K10) . . . 44

5.7 Median run time, retrieve observation for different argument types . . . . 45

5.8 Median run time, insert observations . . . 46

5.9 Same message encrypted twice . . . 55

(7)

List of Tables

2.1 Persisting patient data scenario (S1) . . . 12

2.2 Authentication scenario (S2) . . . 13

2.3 Sending patient data scenario (S3) . . . 13

3.1 Database comparison . . . 24

5.1 React native type conversion . . . 45

5.2 LG K10 run time (ms) . . . 46

5.3 iPhone 6 run time (ms) . . . 47

5.4 Authentication response times . . . 48

5.5 LG K10 response time on sending data . . . 49

5.6 LG K10 response time on retrieving data . . . 49

5.7 iPhone 6 response time on sending data . . . 50

5.8 iPhone 6 response time on retrieving data . . . 50

5.9 Scenario tests . . . 51

5.10 Key verification test results on Android . . . 54

5.11 Key verification test results on iOS . . . 54

(8)

Chapter 1 Introduction

The use of mobile health applications and wearable monitoring devices is increasing [1].

Analyzing patients’ self-collected data such as blood sugar, pulse, and physical activity can identify troublesome patterns such as elevated heart rate and blood sugar levels [94].

The Electronic health record (EHR) has become an important tool for clinicians, and it is predicted that there will be a greater need for integration of patient collected data and EHRs [80]. This can be beneficial for patients with chronic illnesses such as diabetes. EHR based clinical support systems have been shown to improve glucose and blood pressure control in diabetes patients [91]. By sharing self-collected data, patients can provide valuable information to these systems, and health care providers can be alerted if necessary. In addition, involving patients in their healthcare motivates them to follow health care recommendations better, leading to improved health outcomes [94].

While the benefits of sharing patient gathered data are clear, there are security and interoperability challenges that must be met. Due to the sensitive nature of health- related data, it is vital to keep it secure so that the privacy of patients can be protected [75]. Mobile applications that share health-related data must protect it in two areas [59]:

1. In storage

• On the mobile device

• In the cloud

2. Over the communication channel

• Between sensors and the app

• Between the app and the cloud

(9)

In addition, there should be transparency. Patients should know which data is collected and who it is shared with [61]. Most mobile health applications are exposing patient gathered data by failing to address security and privacy guidelines and regulation such as the General Data Protection Regulation (GDPR). An analysis of 20 popular health apps revealed that only half of them always transmitted sensitive health-related data over HTTPS [92]. Even when HTTPS was used, 30% had an insecure implementation of SSL. Static code analysis suggested that 85% of the apps may have stored sensitive data unencrypted. In addition, many apps share patient data with third parties without explicit consent.

Another issue is interoperability, which depends on the use of consistent standards so that the syntactic and semantic information of health data can be understood by the different systems involved in handling it. Unfortunately, widespread interoperability in health care systems has not been achieved [57]. Although there are many applications for managing health data, most are proprietary and follow different standards [55]. Because of this, it can be difficult to integrate data with health care systems.

1.1 Background

This section starts with an introduction to cloud computing and mobile security. This will give an overview of some of the challenges related to sharing self-collected health data securely. Then, we provide some context by introducing concrete examples of related systems that are planned to be or already are part of the Norwegian health care infrastructure. Finally, the problem description and research questions are presented.

1.1.1 Mobile cloud computing

The primary goal of mobile cloud computing is to give a better experience to users who have devices with limited computational power, storage, and battery capacity [96].

Although mobile devices have limited resources compared to desktop computers, they have improved rapidly over the years [71]. While cloud computing may not be necessary in all cases, it can certainly enhance the capabilities of apps on mobile devices.

For applications where mobile devices can handle computation and storage requirements, a more significant benefit is perhaps availability. Storing data in the cloud improves availability across devices. If data is to be shared and synchronized between various systems, they will not have to be directly linked to a mobile device that may not be online at all times. As an added boon, data in the cloud can be used as a backup in the event that a mobile device is stolen or broken.

That being said, the use of cloud computing can threaten security because data is transmitted over the internet [78]. In addition, data stored in the cloud can be vulnerable because of a greater attack surface. Despite this, there is research indicating that

(10)

mobile cloud computing used in health care can be both secure and efficient [62] [82]

[83].

1.1.2 Risks in mobile security

Mobile devices are used for social networking, shopping, emailing, banking, healthcare services and more [76]. While corporate devices may have restrictions that improve security, the number of personal smartphones that handle critical and sensitive corporate data has been increasing. Sensitive information can be found in SMS messages, photos, and applications. This makes personal mobile devices prime targets for attackers.

Figure 1.1: Mobile threats [76]

Mobile devices and computers have many common threats like web browser exploitation, OS vulnerability, and social engineering. Some of them, such as device loss or theft, and compromised devices become more prominent on mobile devices.

• Loss/theft of devices: Owners of mobile devices carry them wherever they go.

While the portability is convenient, mobile devices are easily lost or stolen. A third of consumers in Canada and the U.S have had their phone lost or stolen [99].

(11)

• Data interception and tampering: Mobile devices typically communicate wire- lessly, and many use public Wi-Fi hot spots that can be spoofed [67]. This makes mobile devices especially susceptible to data interception and tampering of data transmitted over the internet.

• Malware: Malicious software can be written for the purpose of collecting user information, sending premium-rate SMS messages, credential theft, and ransom [66]. The increasing amount of malware attacks makes this a serious threat.

• Compromised devices: Normally, iOS users cannot install 3rd party applications [72]. Android users may want to remove vendor-installed software or enhance the OS of their phones. Rooting an Android device or jailbreaking an iOS device solves these issues by giving its owner superuser privileges, but the same also goes for attackers. Compromised devices open for more powerful attacks by removing standard security mechanisms or allowing attackers to bypass them.

• Web browser exploitation and OS vulnerability: Mobile applications may use web technologies, thereby inheriting weaknesses such as cross-site scripting, SQL in- jection, and session fixation. While mobile operating systems provide security features, some of them have to be implemented by developers, which is something that can lead to issues if done incorrectly.

• Social engineering: Attackers may impersonate a trusted party or assume a role of authority in order to fool users into downloading malware or sharing sensitive information. For example, an attacker claiming to be working for the IT department of a user’s organization can send an email asking for their passwords.

Another threat is vulnerable applications. It is closely related to some of the other threats that are listed because they target applications with insufficient security. Devel- opers must take care to secure their apps, but there are many pitfalls. The Open Web Application Security Project (OWASP) lists the top 10 risks that mobile developers have to handle [50].

1. Improper platform usage: Misuse of security features such as TouchID, the Key- chain, platform permissions and general violation of best practices can be exploited.

2. Insecure data storage: When developers do not encrypt data and assume that the file system is inaccessible to attackers, they expose data stored on the phone.

3. Insecure communication: Even if applications use HTTPS for secure communication, poor implementations can lead to leaked information.

4. Insecure authentication: Applications can fail to properly authenticate by using backend APIs that accept anonymous requests, using weak password policies, or by lacking other means of identifying users.

(12)

5. Insufficient cryptography: Even when cryptography is used, improper implementation can make it easy to break. Hardcoding cryptographic keys, relying on obfuscation and using custom algorithms are all examples of cryptography done incorrectly.

6. Insecure authorization: It is often not enough to just authenticate. All access to protected resources should be restricted unless users have been identified, and then authorized by checking whether or not they have the permissions that are required.

7. Client code quality: Missing or insufficient input validation can lead to buffer overflows and memory leaks.

8. Code tampering: Client-side applications such as mobile apps run in environments that are not under control of the developers. Attackers can modify the code of an application on their device in order to cheat in video games. They can also use social engineering to trick others into installing modified apps with malicious code that extracts sensitive information.

9. Reverse engineering: Bad practices such as hard coding secrets and relying on obfuscation can be exploited by attackers who reverse engineer applications, allowing them to inspect the code. It can also be used to find out what code to modify with code tampering.

10. Extraneous functionality: Developers may write code that is not suited for pro- duction, and only meant for assisting the development of an application. Exam- ples include hidden administrator interfaces, backdoors that bypass authentication, passwords in comments and debug configurations that output log files.

1.1.3 Helsenorge

Helsenorge is a web portal for health services in Norway. It is a public service run by the Norwegian Directorate of eHealth (NDE), which is a subordinate institution of the Norwegian Ministry of Health and Care Services. Helsenorge governs a patient’s kjernejournal (core journal) which is in strict compliance with Norwegian health and privacy regulations [27]. The kjernejournal gathers health data from several sources such as hospitals and national registers. Patients can view and add information like medical history and next of kin.

(13)

Figure 1.2: Kjernejournal gathers health information from several sources

The kjernejournal functions as personal cloud storage that is independent of any health care provider, and enables medical workers across different organizations to quickly access patient data that is not stored in their EHR. The portal also provides general health advice and information about patients’ rights.

1.1.4 Full Flow

Norwegian EHRs do not currently support integration of patient gathered data, and while EHR suppliers are working on it [26], most of them lack semantic interoperability.

In order to remedy this situation, the Norwegian Centre for E-Health Research initiated the project ”FullFlow of Health Data Between Patients and Health Care Systems”, or FullFlow for short. Partners include universities such as UiT The Arctic University of Norway and Aalborg University as well as EHR providers such as Infodoc and Dips.

The goal of the project is to increase the knowledge of how secure technological solutions can contribute to better communication between patients and health services.

FullFlow is investigating the medical and financial impacts of full flow between patients, primary health care EHRs and secondary health care EHRs [7].

(14)

Figure 1.3: Simplified data flow.

Figure 1.3 illustrates a simplified data flow that is part of FullFlow’s planned architecture. To gather health data, the patient uses a personal health device (PHD), such as a glucose meter that measures the concentration of glucose in the blood. The data is collected in application hosting devices (AHD) such as smartphones, tablets, or laptops.

The AHDs have an application that sends patient data to Helsenorge.

FullFlow pulls data from Helsenorge and processes it, creating visual representations of health data that highlight important information, as seen in Figure 1.4. Medical workers can then request to access the data from their EHR.

Figure 1.4: Visual report of glucose data

(15)

Before a medical worker can access the data, the patient must grant permission by logging into Helsenorge with ID-Porten, which is used for authentication against public services in Norway.

FullFlow is using diabetes as a use case and cooperates with doctors and diabetes patients. The patients use Diabetes Diary, a proprietary Android application that collects self-gathered health data. Diabetes Share Live is used to share the data with clinicians.

1.2 Problem Description

There is clearly a need for a way of sharing patient gathered health data with clinicians.

The FullFlow project already has the applications Diabetes Diary and Diabetes Share Live, which can do this, but they are not secure. In addition, they are not interoperable with clinical systems due to proprietary data models. Also, because they are Android only, patients with iOS devices are missing out.

Therefore, we have addressed these issues by developing a cross-platform mobile application with focus on security. The application will support FullFlow by sharing self-collected health data from diabetes patients. In order to make it interoperable with health care systems, we use Fast Healthcare Interoperability Resources (FHIR), a standard format for sharing health data. We also conform to Norwegian health and privacy regulations.

Preserving the confidentiality and integrity of health data is a priority, but the application should also provide good user experience. Even if patients know that the app can benefit their health, they are less likely to use it if they find it inefficient or unintuitive.

By focusing on usability in addition to privacy, the app secures not only patients’ data, but their health as well.

1.3 Research questions

• Main question: Which technologies are suited for the development of a secure, cross-platform mobile application for managing and sharing health data?

R1: How can the application preserve the confidentiality and integrity of health data?

R2: How can one integrate this app into the Norwegian healthcare infrastructure?

R3: How can one ensure usability?

The three research questions are all related to the main question. To answer these questions, we will review different technologies in order to assess their suitability. In addition to supporting the functional requirements captured by various scenarios, the

(16)

technologies should secure the application (R1) and facilitate integration with other systems (R2) without discouraging patients from using the app (R3).

1.4 Thesis Outline

The Introduction provides context by introducing important concepts and systems. It also presents the problem description and research questions. Theoretical Background starts off by giving an overview of related work. Then, the methods used to gather results and answer the research questions are discussed. This will allow the one to evaluate the validity and reliability of the work that is presented in the following chapters. In Technologies we describe, compare, and evaluate technologies used in the application.

This will give the reader some insight into why certain technologies are suitable for the application. InDesign and Implementation, we explain how the application solves problems introduced in the first chapter. The high-level architecture, flow of the application, and individual components are also described. In Analysis and Assessment, we evaluate the application in line with the methodology described in the second chapter. The Conclusion sums up the thesis and relates the analysis and assessment to the research questions.

(17)

Chapter 2 Theorethical Background

This chapter begins with a summary of related work that describes other attempts to solve the problem of sharing and integrating self-collected health data. The methodology section will then explain why certain methods have been used to gather and analyze results.

2.1 Related Work

According to Kumar et al. [80], there are not many who have successfully integrated patient gathered glucose data with EHRs, and the existing solutions require custom interfaces, which limits replication. Their paper concludes that it is possible to integrate patient gathered data with EHRs by using existing technologies.

A continuous glucose monitor from Dexcom gathers data and sends it to a smartphone application developed by the same company. An application that directly accesses the database used by an EHR is also used on the mobile device. Both of these applications are compatible with Apple’s HealthKit, which enables health data interoperability.

The only new software developed was web-based visualization integrated into the EHR.

The authors found that the solution ”enabled secure communication, timely access to information, and enhanced interpretation of large volumes of patient device data”. It also resulted in better health outcomes for several patients as insulin doses were corrected after analyzing health data.

A drawback of this solution is that the application that accesses the EHR database is provided by that specific EHR. Because of this coupling, if one wants to share patient data with different EHRs, the patient would need several such applications. Another drawback is that the solution can only be used with iPhones, as HealthKit is not available for other smartphones.

(18)

The Mobiguide project aims to develop a decision-support system that can be used by patients through their smartphone [94]. The patients wear sensors that monitor and transmit data to the system so that it can provide recommendations regarding actions that should be taken. These recommendations are shared with medical workers.

The system integrates patient gathered data with a personal health record (PHR), and EHR. However, rather than sending patient data to EHRs so that medical workers can access it, data is sent from EHRs to the PHR so that the data can be used for making recommendations.

A major challenge was interoperability. Mobiguide used openEHR, which aims to provide universal interoperability between all forms of electronic health data. It was found that ”the use of post-coordinated terms was necessary in order to capture detailed semantics of concepts used (e.g., after lunch (postprandial) blood glucose measurement) and in some cases, certain semantics could not be provided even by post-coordination”.

However, it seems like this was only an issue when dealing with data not usually found in EHRs.

Infodoc Plenario is an EHR that can be customized to fit the needs of general prac- titioners, health clinics, and specialists like eye doctors and dermatologists [49]. It relies on an on-site server, but this is being phased out as modules are replaced by cloud services.

Infodoc is a partner in the FullFlow project, and they have worked on integrating FullFlow in Infodoc Plenario with the help of a master student [90]. A message queue which is planned to come from Helsenorge is used to retrieve self-collected health data.

Because the data comes in the form of HTML files, the open source browser Chromium is embedded in Infodoc Plenario and used to present the patient data.

2.2 Methodology

This thesis is a case study that investigates how one can develop a secure cross-platform mobile application that shares self-collected health data that will be integrated with EHRs. By building a prototype, we have gathered quantitative data from both the development process and testing of the application, which has given a better understanding of how such an application should be developed (RQ1, RQ2). Quantitative data consists of results from performance tests, which answer RQ3.

Scenarios that capture the core requirements of the application are used for several purposes. Overall, they serve as a focal point and provide structure to both the thesis itself and the work it is based on. This unifies the development and analysis of the application. The scenarios help us identify important elements and make the argu- ments of the thesis more coherent. The result is a thesis in which background, design, implementation, analysis, and assessment all complement each other.

(19)

2.2.1 Functional Requirements

The requirements of the application were defined in cooperation with representatives from the Norwegian Centre for E-Health Research, who is overseeing the FullFlow project. It was decided that the application should have two main functional requirements. 1) collect patient data. 2) send patient data to a server. As the requirements became more understood, they grew more fine-grained:

1. Collect patient data 2. Persist patient data 3. Authenticate patient 4. Share patient data

Because FullFlow is focusing on health data from diabetes patients at the moment, the mobile application must be able to handle this type of data. Specifically, the app handles blood glucose measurements in the FHIR format.

The collection of patient gathered health data was deemed out of scope because of time constraints. The rest of the requirements were used as scenarios.

Situation

A patient has health data collected from a PHD such as a glucometer.

The patient is able to import the data into the application, either automatically by integrating the app and PHD, or by entering it manually.

Actors Patient

Goals

The patient wants to have access to his health data at all times, even when offline. He also wants to minimize the risk of losing data that has not yet been shared with the cloud. Therefore, the patient wants the application to persist his health data after importing it. This must be done securely.

Events 1. A patient imports health data.

2. The app stores encrypted health data.

Table 2.1: Persisting patient data scenario (S1)

(20)

Situation

When the Helsenorge server receives patient data from the app, it must store it in the correct kjernejournal. The data itself does not contain enough information for Helsenorge to determine the identity of the patient who sent it.

Actors Patient

Goals The server has to find out which patient the data belongs to, and verify that it was the patient in question who sent the data.

Events

1. Before data is shared, the app prompts authentication.

2. The patient enters credentials.

3. The app receives a patient identifier.

4. The app sends the identifier to the Helsenorge server.

5. The Helsenorge server verifies the authenticity of the identifier and uses it to find out which kjernejournal to store the patient data in.

Table 2.2: Authentication scenario (S2)

Situation A patient has health data on the app and wants to store it in the cloud and share it with clinicians.

Actors Patient

Goals The patient uploads data securely to Helsenorge Events

1. The app retrieves stored patient data that will be shared.

2. The patient authenticates.

3. The app encrypts data.

4. The app sends the patient data to Helsenorge.

Table 2.3: Sending patient data scenario (S3)

The scenarios assisted development in several ways. First off, they described the functionalities clearly, so that all stakeholders were on the same page. Further, they served as subjects of discussion, which aided the discovery of more detailed requirements, and helped us validate our understanding of the domain when in discussion with representatives from the FullFlow project. In addition, they assisted in the development of the architecture, as it was constructed by figuring out which components would be needed to support the scenarios. By splitting the high-level requirements of the application into distinct scenarios, we were able to build the app part by part. After each component had been developed, we validated its design by assessing whether or not it fulfilled the goals of the corresponding scenario.

An agile development process was used to develop the app. First, a high-level architecture containing key components and data flow was sketched. Then, the main technologies, the cross-platform framework, and the database were chosen to fit the

(21)

architecture and requirements of the application. Each core component, such as persistence, encryption, and authentication was then developed one by one with its own development cycle consisting of analysis, design, implementation, and testing.

2.2.2 Security

In addition to the functional requirements, a key aspect of the application is security.

One can not be certain that a non-trivial system is completely secure, as one would have to imagine and account for an infinite amount of possibilities for compromising it. It is, however, possible to gain confidence by means of thorough testing and analysis. There are several approaches that can be used.

Threat modeling is a structured approach that starts off by identifying threats. The threats are then categorized and prioritized before countermeasures are determined. This approach involves looking at the system from the point of view of an attacker as one identifies entry points that can be used to gain access to assets. By doing so, one can uncover architectural weaknesses such as missing authentication in parts of the system accessible to unauthorized users. The threats and attackers described are based on a threat model for mHealth apps [79].

Threats:

T1. Unauthorized learning of health data: Someone gets unauthorized access to health- related data.

T2. Tampering with health data: Attacker modifies data that is stored or transmitted.

T3. Reporting invalid health data: App reports wrong information

Together, the three points cover threats to confidentiality (T1) and integrity (T2), and by extension, privacy (T1) and safety (T2, T3). We will assume that T2 leads to T3.

T3 by itself can be influenced by bugs in the app or patients who do not want to report their actual health data. This is out of scope for the thesis, so T3 will only be considered in relation to T2.

Attackers :

A1. Eavesdropper: Captures unprotected network traffic.

A2. Active attacker on the network: Deletes, modifies and redirects data sent over networks. Also attempts to authenticate by brute force.

A3. Man in the middle: Impersonates other actors on the network by taking advantage of improper SSL implementations. The attacker will then be able to read data encrypted with HTTPS in cleartext

(22)

A4. Malware developer: Injects malware into the mobile device and uses it to gain access to data from other apps and send it over the internet.

A5. Third parties: If a third party cloud service is used to store health data, it could be exposed.

A6. Attacker with physical access to smartphone: Can extract unprotected data stored on the mobile device.

A7. The user: Can unknowingly put his own health data at risk. The app can be used in ways the developer did not foresee. The user could follow bad practices such as using short common passwords. Powerful, but potentially dangerous features available for advanced users can be misused without the user being aware of the consequences.

The following attackers are not as relevant as the others, and will not be addressed:

1. App developer: May make mistakes that leak information or include malicious code that violates the user’s privacy

2. App show owners: Users may not want others to know that they are using a health app. App show owners could potentially expose users through public app reviews.

While mistakes done by the app developer is a concern, this is something that will be addressed implicitly by testing the application. It does not need to be referenced like the other attackers. Dealing with app show owners is outside the scope of this thesis.

The list of threats and attackers have been used to justify design choices throughout the thesis. The threat model is also used in conjunction with the scenarios in order create and classify test cases for penetration testing, which involves taking the role of an attacker, and trying out different attacks on a running system. This gives an overview of how well the app deals with different issues and makes it clear that potential threats to the scenarios have been considered.

2.2.3 Performance

Performance testing has been used for assessing the user experience of the application.

Research suggests that it is important to gather quantitative data when measuring the quality of experience [60]. User satisfaction can be assessed by recording it for known levels of performance and comparing these levels to the performance of a concrete application.

There are several things that can be measured when testing the performance of a mobile application. Execution time, memory usage and battery usage are parameters that often give useful values for performance assessment [64].

(23)

All of these parameters are relevant, but we have focused on execution time. Com- pared to the other factors, this will give a higher degree of validity because it directly impacts response time. This is an aspect of performance for which research has given concrete numbers that we can use in order to measure quality the of experience [86].

Based on this, we can set a response time limits for actions taken by a user, and find out how much data the application can handle before reaching them. The results of the performance tests can, therefore, be used to determine how often patient data should be sent from the application for the user experience to be satisfactory. If the frequency is high enough, the inconvenience of having to authenticate too often may outweigh patients’ perceived health benefits.

The three scenarios that capture the core functionality of the app rely primarily on database operations, cryptography, and authentication, so these tasks are performed often and will have the most impact on the performance of the application.

The performance of relevant tasks was tested by isolating functions like database insertion and encryption, and measuring their run times multiple times with different amounts of blood glucose measurements in the FHIR format. Real devices were used, and all other applications were closed during testing. Functions were executed with amounts of health data varying from one day to one week’s worth of blood glucose measurements. In order to estimate the amount of health data collected in a day, an expert at the Norwegian Centre of E-Health Research was consulted. Real health data collected from diabetes patients involved in the FullFlow project was used.

(24)

Chapter 3 Technologies

This chapter describes the technologies that have been used for developing the app as well as the motivation for using them. The technologies support the requirements specified in previous chapters. Together, they enable cross-platform development with authentication, as well as secure data storage and transmission of data in a standardized format. A selection of databases for S1 are compared and evaluated. The authentication technologies OIDC, ID-Porten, and IdentityServer4 support S2. The encryption standard OpenPGP is used in S3. Finally, we describe different cross-platform frameworks that can potentially support all three scenarios and choose a suitable one. Basic concepts related to the technologies, such as symmetric/asymmetric cryptography and authentication schemes are also explained.

3.1 OpenID Connect

OpenID Connect (OIDC) is an authentication and authorization protocol [30]. We use it because it is compatible with ID-Porten, which will be used for authentication (S2). An alternative to OIDC is Security Assertion Markup Language (SAML), which is an XML oriented framework for exchanging authentication and authorization information [31].

SAML is an older technology specifically designed for web browsers, and it has limited support for mobile devices [87]. In contrast, OIDC was developed after smartphones had become prevalent, and it is designed to work with mobile devices.

There are four parties in OIDC:

1. End User (U), a human participant who wishes to authenticate.

2. User Agent (UA), typically a web browser used by the end user to enter and transmit credentials to the OP.

3. OpenID Connect Provider (OP), a server capable of authenticating the end user.

(25)

4. Relaying Party (RP), a client application that requires authentication from the end user.

Figure 3.1: OpenID Connect Protocol Overview [81]

In our case, the mobile application (RP) needs the patient (U) to authenticate with ID-Porten (OP) using a web browser (UA).

OIDC specifies several ”authentication flows”, but they share the same main steps.

The RP sends a request to the OP (1). The end user then authenticates via the user agent (2), and the RP is given an access token by the OP (3). With the access token, the RP can request and receive information about the authenticated user (4, 5).

3.2 ID-Porten

ID-porten is an authentication solution operated by the Agency for Public Management and eGovernment (Difi). It used for authentication with public services such as the Norwegian Tax Administration and Helsenorge. ID-Porten allows users to log in with two-factor authentication on mobile devices.

There are other alternatives for authentication, but the FullFlow architecture specifies that patients have to authenticate with ID-Porten. Therefore, our application has to support it.

ID-Porten is useful for several reasons. It is user-friendly because most Norwegians already have an electronic ID, which is essentially a user account for ID-Porten. A consequence of this is that patients will not have to create new user accounts. This

(26)

will cause them to suffer less from password fatigue, which can cause users to forget passwords and resort to reusing them as a coping mechanism (A7) [56].

Users in our application can be mapped to patients in Helsenorge’s system by looking at the electronic ID because we both use ID-Porten as our OIDC-Provider. If this had not been the case, the patient would have to enter his social security number or something equivalent in order to be identified as a Norwegian citizen. This would make the system more vulnerable to identity theft, as Helsenorge would have to trust that the user entered his own social security number. Lastly, because ID-Porten is used for important services such as banking, it has high requirements for security and is thoroughly tested.

ID-Porten supports SAML and OIDC. For mobile applications, the authorization code flow is used with Proof Key of Code Exchange (PKCE).

Figure 3.2: Code authorization flow with PKCE

In this scheme, the application generates a code verifier, and hashes it, creating a code challenge which is sent with an authorization code request. When requesting a token, the code verifier is sent so that the OpenID provider can hash it and verify that the token request came from the same client that sent the authorization code request.

This prevents other applications on the mobile device from stealing tokens because only the app that sent the initial request has the code verifier.

(27)

3.3 IdentityServer4

IdentityServer4 is an open source OpenID Connect and OAuth 2.0 framework for ASP.NET Core 2. It is used as a stand-in for ID-Porten. Integration with ID-Porten requires rela- tively extensive planning in cooperation with Difi, and they did not want to do this for just a prototype. Because ID-Porten and IdentityServer4 both use the OIDC protocol one only has to do a few minor changes on the client in order to integrate with ID-Porten when that time comes.

There are many OIDC implementations [28]. IdentityServer4 was used for another part of the FullFlow project with success [90]. It also allowed development with ASP.NET Core and deployment on Microsoft Azure, which was helpful for testing because it automatically set up HTTPS with a proper certificate. If we had used another OIDC implementation, we would have to get a signed certificate from a certificate authority. This requires ownership of a registered domain, which we did not have.

3.4 FHIR

Fast Healthcare Interoperability Resources (FHIR) is a standard for exchange of healthcare information. It is based on ”Resources”, which are representations of healthcare entities such as patients, measurements, and appointments. Resources can be repre- sented in JavaScript Object Notation (JSON) or Extensible Markup Language (XML).

FHIR’s intended scope is broad. It’s meant to be used globally in many different architectures and scenarios. Because of this, it is infeasible to explicitly include every thinkable property for each resource in the specification, so FHIR supports extensibility.

Extensions are optional properties of resources. The way they are structured has an impact on how FHIR data is stored in a database.

FHIR is recommended by The Norwegian Directorate of eHealth [29]. The standard is used in FullFlow, so the app must also use it in order to be compatible with the FullFlow architecture.

3.5 OpenPGP

In order to defend against man in the middle attackers (A3), we use end-to-end encryption. OpenPGP is a non-proprietary encryption standard commonly used for emails [51]. It based on the Pretty Good Privacy (PGP) software. OpenPGP provides authentication, confidentiality, and integrity for messages with the help of digital signatures and encryption [24]. The standard combines two forms of cryptography.

• Symmetric cryptography: A shared key is used for both encryption and decryption.

(28)

• Asymmetric cryptography: Every participant has a key pair consisting of a public key and a private key. A message encrypted with the private key can only be decrypted with the public key. Messages encrypted with the public key can only be decrypted with the private key. As the names suggest, private keys are kept secret, while public keys are shared.

If Alice wants to send a message to Bob that only he can read, she can encrypt it with Bob’s public key. Because only Bob has his private key, no one else can decrypt the message. Symmetric encryption is more efficient than asymmetric encryption, so Alice will actually encrypt the message with a symmetric key. The symmetric key is normally much smaller than the message and will be encrypted with Alice’s private key. Both the encrypted message and the symmetric key is sent to Bob. He can then use Alice’s public key to decrypt the symmetric key, which in turn will be used to decrypt the message.

Figure 3.3: PGP encryption [52]

(29)

If Bob wants to make sure that a message is sent from Alice, she can sign it by hashing and encrypting it with her private key. She can then attach the signature to the message and send it. Bob can then decrypt the signature with Alice’s public key and compare it to the hash of the message. If an attacker modifies the message, the two hashes will not match. An attacker will also not be able to forge a signature without Alice’s private key.

3.6 Databases

A database is needed for persisting data securely (S1). This section starts with a description of requirements for the database, which will ensure that it is secure, compliant with Norwegian regulations, and suitable for storing health data. Different databases are then compared, and one of them is selected.

3.6.1 Requirements

1. Compatible with mobile applications 2. Document store

3. Local

4. Supports encryption

FHIR is a specification that has a lot of optional fields, which is something that needs to be taken into consideration when choosing a database. The Observation resource, for example, can have 21 fields, but only two of them are required [3]. The FHIR specification also supports extensions, which allows anyone to extend FHIR with new resources [2]. We essentially have objects of the same class with varying and unpredictable properties. In order to solve this in a relational database, one would have to use the entity property value (EAV) model, which is an anti-pattern than can lower performance [77].

The solution is to use document stores, a class of non-relational databases (NoSQL) that store data as documents encoded in JSON, XML, or BSON (Binary JSON) [95].

Encoding documents in JSON is convenient because it is one of the supported formats of FHIR. A document is comparable to a row in a relational database where the number of columns can vary. For example, two documents representing observations could be:

(30)

Figure 3.4: Observation example

Figure 3.5: Observation example with an extra field

The first observation contains only ”resourceType” and the two required ”status”

and ”code” fields, while the second also includes the optional ”issued” field. The first observation would have a null value for the ”issued” field in a relational database, but in a document database, the ”column” does not need to be present if there is no value for it because the database is schema-less. There is no rule saying that you need an ”issued”

column, or conversely, that you cannot have one. Without a schema that constrains what can be stored, one can simply add any JSON object to the database. Conse- quently, document databases are useful for storing irregular data that would require a lot of null values in a relational database [85] [88].

(31)

Flexibility and scalability are the two biggest reasons people have started using NoSQL databases in favor of the traditional RDBMS [85]. Relational databases scale vertically by adding more processors, memory, and storage to a single server where the database is located. NoSQL databases are typically cloud-based and scale horizontally by adding more servers.

Because of this, we have to choose and use NoSQL databases carefully. There are strict Norwegian regulations regarding the storage of health data outside of the country [47]. If the database is cloud-based, one should make sure that the data does not cross any borders. The safest option is to go for a database that only stores data locally on the mobile device. This will protect against A5. In addition, it will enable one to know exactly where the data is located at all times, and how it is secured.

The database also has to support encryption in order to protect its contents from A4 and A6.

3.6.2 Comparison

There are many non-relational databases other than the ones presented here. Examples are BerkeleyDB, Realm, and SQLite. However, this discussion is limited to document stores for mobile applications. PouchDB has a plugin for encryption, but its depen- dencies are only available in a browser/Node environment, so it is not compatible with certain cross-platform mobile frameworks. MongoDB Mobile does not support encryption out of the box, but requires you to implement it yourself. Amazon DynamoDB and Microsoft Azure Cosmos DB are cloud-based only.

Database Mobile Document store Local Encrypted

Couchbase Lite 3 3 3 3

PouchDB 3 3 3 3/ 7¹

MongoDB Mobile 3 3 3 7

Amazon DynamoDB 3 3 7 3

Microsoft Azure Cosmos DB 3 3 7 3

Table 3.1: Database comparison

Couchbase Lite was chosen because it is the only database that fulfills all the requirements on React Native, the cross-platform mobile framework that was selected for the application.

1PouchDB’s encryption is only compatible with web and hybrid applications

(32)

3.7 Cross platform frameworks

It is desirable to make the application available to as many patients as possible. A cross-platform approach was chosen because it allows one to create an application for both Android and iOS without developing on two completely separate code bases, thus reducing development time.

This section compares a selection of cross-platform mobile frameworks. The scenarios in chapter 2 were used for identifying important requirements that the framework had to support. Ease of use and was also considered because it allows one to spend more time on constructive work, which should lead to better results.

There are four types of cross-platform applications: web, hybrid, interpreted and cross-compiled [53]. Web applications run on a browser and hybrid applications run in a web container, limiting native capabilities and performance. This is not the case for interpreted and cross-compiled apps, which are rendered with native components. These two approaches are more suitable for standalone applications where data is processed on the mobile device rather than a server. While we have a client-server architecture, the app may have to process large amounts of data, so interpreted or cross-compiled frameworks are preferred.

3.7.1 Requirements

Primary

• Good support for cryptography and FHIR: Cryptography is used in all scenarios.

FHIR is handled in S1 and S3.

• Access to native APIs or option to write native code: If native features or libraries are not available for the framework out of the box, one should be able to develop native modules to ensure that the app will fulfill all requirements.

Secondary

• Good performance: It is important that the framework facilitates good performance, and by extension, satisfactory usability. However, performance can be sacrificed if necessary in order to fulfill the primary requirements.

• Good documentation and/or support from the developer community: Saves time and reduces the risk of not being able to figure out how to solve problems.

• Ease of development: Less time spent fighting the framework leads to more time for constructive work.

(33)

3.7.2 Comparison

This section compares the most popular cross-platform frameworks [48] [46]. All of them support native code to some extent. Popular does not necessarily mean good, but it is desirable to have a large developer community. This will lead to more results when searching for solutions to issues, as more people will be discussing it. This reduces the time spent troubleshooting and minimizes the risk of not being able to solve problems.

Xamarin

Xamarin is owned by Microsoft. It uses a shared C# codebase and has two versions.

The first is Xamarin Native which includes Xamarin iOS and Xamarin Android, where business logic, data access, and network communication are shared, but UI is coded natively in different codebases. The second is Xamarin Forms, where UI is also shared.

Xamarin supports iOS, Android and Windows Phone.

Pros:

• Access to .NET libraries

• A good amount of code reuse with Xamarin Forms.

• Xamarin Native is cross-compiled and Xamarin Forms is interpreted.

Cons:

• Difficult to integrate custom native Android and iOS components.

• Rated as the second most dreaded cross-platform mobile framework in Stack Over- flow’s 2019 survey.

React Native

React Native is developed by Facebook. It uses the React JavaScript library for building native user interfaces. React Native supports iOS and Android.

Pros:

• React Native was rated the second most loved cross-platform mobile framework in Stack Overflow’s 2019 survey.

• Hot reloading

• Interpreted

(34)

Cons:

• Certain components are specific to each platform, so some code must be written twice

• Can be difficult to get started with if you are unfamiliar with the React ecosystem Ionic

Ionic uses Javascript, HTML, and CSS. It is wrapped in a web browser and uses plugins to connect to native APIs. Ionic is best suited for applications that do not use a lot of native features. Supports iOS, Android, Windows Phone and BlackBerry.

Pros:

• A good amount of code reuse

• Supports more than just Android, iOS and Windows Phone.

Cons:

• Hybrid.

• Lacking libraries for secure storage

3.7.3 Comparison

We have not tested all of these frameworks, so parts of this comparison are based on the general impression gained by browsing a variety of blogs, official documentation, and discussion sites. Because some of the information about factors such as ease of development is based on anecdotal evidence, the comparison may not be completely accurate.

Xamarin Forms Xamarin Native React Native Ionic

Crytography support ? ? ? ? ? ? ?? ?

FHIR support ? ? ? ? ? ? ?? ??

Support for relevant databases ? ? ? ? ? ? ? ??

Code reuse ? ? ? ?? ?? ? ? ?

Performance ?? ? ? ? ? ? ? ?

Ease of development ? ? ? ? ? ? ? ?

Supported Platforms ? ? ? ? ? ? ?? ? ? ?

Both Xamarin and Ionic have clear weaknesses. Xamarin is difficult to work with, and Ionic has bad performance as well as poor support for cryptographic libraries. A

(35)

good reason to select Ionic would be that it is fully compatible with PouchDB but the weaknesses of the framework are too great to overlook. The general consensus seems to be that Xamarin is buggy and difficult to work with. The opposite is true for React Native. In the end, React Native was chosen for its ease of development, which keeps the development time short.

Initially, it was thought that React Native had equally good support for cryptographic libraries as Xamarin. When we found out that the cross-platform OpenPGP libraries for React Native were lacking, we were so far into development that it was too late to reconsider frameworks. A drawback of using React Native with Couchbase Lite is that JavaScript is not a supported language for the database, so it has to be implemented in Swift for iOS and Java for Android. Xamarin has a C# library for Couchbase Lite, which better facilitates cross-platform development. The application initially used Realm as the database, so this was not considered when choosing the framework. It was later discovered that Realm was unsuitable as the requirements of the application became better understood. It is possible that Xamarin would have been chosen if this had been known beforehand.

(36)

Chapter 4 Design and Implementation

This chapter presents the design and implementation of the application. The main components are described first. Libraries used by the components are named, and alternatives are discussed. This is followed by an overview of 12 steps, starting with patients collecting data and ending with clinicians accessing it. Then a detailed sequence diagram reveals more of the implementation. References to scenarios, threats, and attackers are used to explain the reasoning behind the design.

4.1 Architecture

The architecture contains three main components: 1) a cross-platform mobile hosting app, used for collecting and centralizing self-collected health data from multiple PHDs and AHDs, 2) an OIDC provider (ID-Porten) for authenticating patients and 3) a server application for analyzing and displaying the data.

Patients interact with the application by directly entering data or through external PHDs or third-party apps, such as Diabetes Diary. In addition, patients use the app to authenticate with ID-Porten. On the other side, clinicians interact with the Helsenorge server in order to consult the data collected by the patients

(37)

Figure 4.1: Architecture

The app contains multiple modules divided into two categories: cross-platform and native. The cross-platform module contains the code shared between all platforms while the native module consists of the custom implementation for each different platform.

The native module contains two sub-modules: Persistence and Encrypter. Persis- tence focuses on securely storing and retrieving FHIR artifacts representing medical data in the application (S1). We rely on Couchbase Lite for these actions. CouchBase Lite’s encryption deals with attackers A4 and A6 who threaten T1 and T2. There is no cross- platform Couchbase Lite library for React Native, so it was implemented natively in two separate codebases. One for Android, and one for iOS. The password of the database is encrypted in Keychain for iOS and Keystore for Android using react-native-keychain [39]. There are other options such as rn-secure-storage[41], but react-native-keychain has options for biometry, which could be useful in the future. react-native-securerandom [40] is used for generating the password.

The Encrypter is an essential component for S3 that encrypts patient data using OpenPGP, thereby preserving confidentiality and integrity by dealing with A1, A2, and A3. A practical solution would be to use an existing OpenPGP library for React-Native.

React-Native-OpenPGP[25] was tested, but it has a bug which makes it impossible to use a debugger on a React-Native application. It is also much slower than native encryption, as one can see in the performance tests in chapter 5. We opted to implement encryption natively because of this.

In Android, OpenPGP is implemented with Spongy Castle [17], a repackage of Bouncy Castle [13] for Android. The alternative to Bouncy Castle is OpenKeychain API [15], which works by connecting to a remote service. This is not ideal because it requires significant changes to our architecture. In iOS, encryption is implemented with ObjectivePGP, which has undergone a complete security audit from Cure53 [14].

Swift-PGP was considered, but it does not support encryption yet [18].

(38)

PGP implementations may support different algorithms. We use RSA with 2048-bit keys for asymmetric encryption, AES with 256-bit keys for symmetric encryption with CFB mode, and SHA-1 for making Modification Detection Codes (MDC). ZLIB is used for compression on iOS, while ZIP is utilized on Android.

The cross-platform module contains 3 sub-modules: receiver, sender, and authenticator. The purpose of the Receiver is to import health data into the app.

The Sender is a central component that is responsible for all the events of S3. It retrieves patient data from the database and utilizes the security features provided by the Authenticator and Encrypter so that it can send data securely.

The Authenticator which uses the OIDC protocol to authenticate users takes care of S2, which is needed for stopping A2 from threatening T2. It communicates with ID-Porten, which allows the app and the Helsenorge server to verify the identity of a user.

The Authenticator uses AppAuth, an SDK that implements the authorization code flow with PKCE. Appauth is implemented natively, but we consider it cross-platform because we do not have to write the native code ourselves in order to use it. This is because we use a React-Native bridge, which maps cross-platform code to native code that already exists.

Other alternatives arereact-native-oidc-client [20] andreact-native-oidc [19]. react- native-oidc-client’s documentation does not specify how to configure the library for iOS, and it does not mention PKCE support. react-native-oidc lacks options that are useful for development such as allowing/disallowing insecure HTTP requests and specifying token and authorization endpoint separately.

The data sharing process contains 12 steps. The first steps involve S1 and start with data collection. Our app provides two different ways for collecting the data: either by 1) manually registering the data using the application as an AHD directly, or by 2) extracting/receiving data from third-party AHDs or apps. In Figure 4.1, we illustrate the second possibility by collecting the data via the Diabetes Diary app (1-2). In the third step, the collected data is stored in an encrypted database (3).

The next steps occur after sharing of patient data has been initiated, and cover S2 and parts of S3. First, the Sender module retrieves data from the encrypted database (4). Then the patient must authenticate (5). The app opens a browser and a login page provided by ID-Porten appears (6). When the patient has entered his credentials, ID-Porten sends an access token to the app, which can be presented to the Helsenorge server as evidence that the data it receives originates from the authenticated patient(7).

The final steps describe the remaining events of S3. Before data is sent, it must be encrypted. The sender uses the Encrypter module to encrypt the patient data and access token with OpenPGP (8). The data is sent over HTTPS, but with OpenPGP’s end to end encryption, only the Helsenorge server can decrypt it even if the security

(39)

provided by HTTPS is compromised.

The Helsenorge server has a simple REST API with two endpoints. Our implementation runs on a Java EE server. This enabled us to reuse the OpenPGP Java code written for Android. The first endpoint is used by the app to get the information necessary to encrypt data, while the other is used to deliver it (9). When the server receives data, it is first decrypted (10). Then, as part of S2, the Helsenorge server asks ID-Porten to determine whether or not the app’s access token is valid (11). If it is the data is analyzed, and medical workers can access it through an EHR (12). HTTPS is used in all steps that make use of the internet in order to protect against A1, A2 and A3.

When persisted locally, patient data is vulnerable to attackers A4 and A6. Even though there are security mechanisms in place to protect the application’s database, it is more secure to send data directly to the Helsenorge server without storing it locally.

It is recommended to not store sensitive data locally [93]. More traditional client server architectures have been proposed [69] where data is not stored locally, but retrieved from the server when needed.

there are evidently more secure designs than the one we are proposing, but they can come at the cost of convenience and loss of data. When data is only stored on a server, issues will occur when an internet connection is not available. Even though the patient owns the data according to Norwegian health regulations, he will not be able to access it.

Sending patient data can also be hindered. Data can be buffered in memory, but it will be lost if the application somehow closes. If health data contains critical information such as dangerously high blood sugar levels, health personnel will not be made aware of this through the FullFlow system. This can have serious consequences for a patient’s health.

Gejibo [68] makes use of the Android Keystore to protect the database key as we do, but it is also protected by a password. The use of a password with sufficient entropy will strengthen security in cases where an advanced attacker attempts to bypass security mechanisms by rooting, but this is inconvenient for the user, [63]. Protecting data with a strong password is no guarantee either, as an attacker can obtain the password with a key logger or social engineering. The patient must already authenticate with ID-Porten.

Adding another barrier will make the application cumbersome to use. Patients may not want to use the app at all if the user experience is lacking. Thus, they will not benefit from the full flow of health data between patients and healthcare systems.

Although it is cumbersome for users to enter a password, other solutions could be considered in the future. With biometrics, one can simply scan the user’s fingerprint or eye. Not all devices support biometry, but the number is rising [65], so this will become more relevant in the future. It is also possible for the patient to authenticate with ID- Porten and derive a key with a secret from the Helsenorge server. One has to make tradeoffs between security and other requirements such as performance, availability, and

(40)

usability. The most secure system is not necessarily the best one.

4.1.1 Detailed communication

Figure 4.2: Sending data to Helsenorge

Figure 4.2 shows communication between the app, patient, ID-Porten, and Helsenorge when health data is sent successfully. The app needs two things in order to send data to the Helsenorge server. An access token and a public key for encrypting an OpenPGP

(41)

message. The patient starts by authenticating with ID-Porten, and the app receives an access token. The app will then ask Helsenorge for a public key and a signature that is used to verify the key. When this has been done, the access token and patient data is encrypted with the public key so that only Helsenorge, who has the corresponding private key, can decrypt the message. Helsenorge decrypts the message and asks ID- Porten whether or not the access token is valid. Then, the access token is used to identify the patient so that the data can be stored in the correct kjernejournal. The flow is interrupted if the patient enters incorrect credentials, signature verification fails, decryption fails, or if the access token is invalid.

(42)

Chapter 5 Analysis and Assessment

This chapter begins by examining potential security threats. Issues with technologies and libraries are also discussed. The second part of the chapter presents the results and interpretations of the performance tests. Finally, we go over a number of scenario tests that have been used in attempts to find vulnerabilities.

5.1 Encryption of data on the device

The first time the application is opened, a 64 byte array is generated by a cryptograph- ically secure random number generator. The array is converted to a string and used as the database password. As with all other secrets on the device, the key itself must also be encrypted. One can use a password to generate a key, but this is inconvenient for the user. Fortunately. Android and iOS provide encrypted storage, Keychain for iOS and Keystore for Android, that uses a key derived from hardware [22][21]. The security of the database, and by extension, Keychain and Keystore, is essential for S1 because it protects the app against A4 and A6.

An attack that requires root privileges has been found on the Android Keystore, but is limited to software-based implementations [97]. This can be an issue for some users, as not all Android devices support hardware binding. Keystores that are backed hardware-backed are not affected.

Cooijmans T. et al. [63] found that Keystore provides device binding, but not app binding on Android devices with versions 4.1.2 (Jelly Bean) - 4.4.2 (KitKat). This means that keys cannot be exported from the device, but they can be used by A4 or A6 attackers with root access. The latest Android version is 9 (Pie) [36]. Android’s Keystore has received updates on every version starting from version 6 (Marshmallow) up until the latest version [37]. react-native-keychain only supports Keystore on devices with version 6 or higher. This amounts to 75% of all Android devices [38]. The vulnerabilities were reported to Google, so one can assume that the issues in version 4 were fixed in version

(43)

6, but further research should be done in order to confirm this.

The security of iOS’s Keychain depends on its configuration. There are four main

”accessibility values” which specify when the data in the Keychain can be accessed [4].

In order from most to least restrictive they are:

• AccessibleWhenPasscodeSet: The data in the Keychain can only be accessed when the device is unlocked. Only available if a passcode is set on the device

• AccessibleWhenUnlocked: The data in the Keychain item can be accessed only while the device is unlocked by the user

• AccessibleAfterFirstUnlock: The data in the keychain item cannot be accessed after a restart until the device has been unlocked once by the user

• AccessibleAlways: The data in the Keychain item can always be accessed regardless of whether the device is locked

The three last accessibility values have ”ThisDeviceOnly” counterparts, which pre- vent items in the Keystore from migrating to a new device. This means that data in the Keystore will be lost when restoring from a backup of a different device. [5]

A weakness that can compromise Keychain-protected data has been found in the Keychain on iOS 6 and lower [74]. It requires the device to be jailbroken, and the minimum supported iOS version that React Native supports is iOS 9 [6], but it is still useful to look at the recommendations for protecting against the attack [73]. In order to ensure that the iOS keychain is secure, two requirements must be met:

• The items must be protected with an accessibility value that requires the device to be unlocked for items in the Keychain to be made accessible.

• A passcode that consists of at least 6 alphanumeric symbols is used

In practice, this means that AccessibleAlways should not be chosen as the accessibility value. For maximum security, AccessibleWhenPasscodeSetThisDeviceOnly should be chosen, but this in itself is not good enough to ensure that data in the Keystore is protected if the device is jailbroken because the user may not use a sufficiently strong passcode. Whether or not the device is protected by a passcode is up to the user, but AccessibleWhenPasscodeSetThisDeviceOnly was chosen in order to protect against A7.

If a passcode is not used, the application should inform the user that this must be done in order to secure his data. An option to set the accessibility value to AccessibleWhenUn- lockedThisDeviceOnly may be considered if patients are willing to take the risk. Even though AccessibleWhenPasscodeSetThisDeviceOnly is the default value, the Keystore has been configured to use this accessibility value explicitly in case the default value

Design of a cross-platform mobile application for sharing self-collected health data securely with health services