A SECURITY ARCHITECTURE FOR ACCESSING HEALTH

RECORDS ON MOBILE PHONES

Alexandra Dmitrienko, Zecir Hadzic, Hans L

ohr, Marcel Winandy

Horst G

ortz Institute for IT Security, Ruhr-University Bochum, Bochum, Germany

Ahmad-Reza Sadeghi

Fraunhofer-Institut SIT Darmstadt, Technische Universit

at Darmstadt, Darmstadt, Germany

Keywords:

Health records, Mobile computing, Smartphone, Security architecture, Trusted computing.

Abstract:

Using mobile phones to access healthcare data is an upcoming application scenario of increasing importance

in the near future. However, important aspects to consider in this context are the high security and privacy

requirements for sensitive medical data. Current mobile phones using standard operating systems and software

cannot offer appropriate protection for sensitive data, although the hardware platform often offers dedicated

security features. Malicious software (malware) like Trojan horses on the mobile phone could gain unautho-

rized access to sensitive medical data.

In this paper, we propose a complete security framework to protect medical data (such as electronic health

records) and authentication credentials that are used to access e-health servers. Derived from a generic archi-

tecture that can be used for PCs, we introduce a security architecture speciﬁcally for mobile phones, based

on existing hardware security extensions. We describe security building blocks, including trusted hardware

features, a security kernel providing isolated application environments as well as a secure graphical user in-

terface, and a trusted wallet (TruWallet) for secure authentication to e-health servers. Moreover, we present

a prototype implementation of the trusted wallet on a current smartphone: the Nokia N900. Based on our

architecture, health care professionals can safely and securely process medical data on their mobile phones

without the risk of disclosing sensitive information as compared to commodity mobile operating systems.

1 INTRODUCTION

The usage of mobile phones as multi-purpose assis-

tant device in healthcare has been proposed in several

application scenarios. Its usefulness is derived from

its mobility and ﬂexibility, i.e., today’s smartphones

offer appropriate computing and storage capacity al-

lowing the realization of various applications that can

be used basically from everywhere. For instance,

healthcare professionals can use a mobile phones to

download and share electronic health records of their

patients (Benelli and Pozzebon, 2010). In other sce-

narios, patients use their mobile phones to provide

personal health data, e.g., taken from additional bio-

sensors, to a medical information and diagnosis sys-

tem (Han et al., 2008).

While smartphones are very ﬂexible and cost-

efﬁcient computing devices, they generally do not off-

er sufﬁcient security mechanisms to protect the data

they operate on. This is mainly due to the ar-

chitectural shortcomings of their operating systems,

which are derived from the same (security) architec-

ture as desktop operating systems. Typical examples

are Google Android (Android Open Source Project,

2010), Apple iOS (Apple Inc., 2010), Symbian (Sym-

bian Foundation Community, 2010), and Windows

Mobile (Microsoft, 2010). Although, some of them

provide more sophisticated security mechanisms than

their desktop counterparts, e.g., application-oriented

access control in Android (Google Android, 2010),

they still suffer from fundamental security problems

due to their large code base and complexity, lack-

ing of strong isolation of applications (secure execu-

tion) and insufﬁcient protection of stored data (secure

storage). Recent attacks on smartphones demonstrate

their vulnerability (Iozzo and Weinmann, 2010; Ven-

Dmitrienko A., Hadzic Z., Löhr H., Winandy M. and Sadeghi A..

A SECURITY ARCHITECTURE FOR ACCESSING HEALTH RECORDS ON MOBILE PHONES.

DOI: 10.5220/0003171100870096

In Proceedings of the International Conference on Health Informatics (HEALTHINF-2011), pages 87-96

ISBN: 978-989-8425-34-8

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

non, 2010; Aggarwal and Vennon, 2010). But the se-

cure operation of a mobile phone is an important as-

pect when a user is working with security and privacy-

sensitive data such as personal health records on the

device.

Especially in healthcare telematics infrastructures,

the end-user systems of health professionals have

been identiﬁed as an insecure and less speciﬁed com-

ponent (Sunyaev et al., 2010). Malware on the user’s

computing platform could steal passwords that are

used to access healthcare information systems, ma-

nipulate data such as medical prescriptions, or eaves-

drop on and copy private data such as personal health

records. While the connection of stationary desk-

top systems to the healthcare telematics may be pro-

tected by additional secure hardware network compo-

nents like, e.g., special ﬁrewalls and gateway routers,

the situation gets worse when mobile phones are

used. Due to their mobility and changing connectivity

(wireless LAN or GSM network), mobile phones may

usually only use Virtual Private Network (VPN) tech-

nology to secure the connection. But the necessary

credentials, like user passwords and VPN keys, are

not sufﬁciently protected against malware on the de-

vice, and, hence, could be accessed by unauthorized

parties.

However, modern smartphone hardware offers ad-

vanced security functionality, which are embedded in

their processors, but generally not used by the main-

stream mobile operating systems. For instance, ARM

TrustZone (Tiago Alves, 2004) and Texas Instru-

ments M-Shield (Azema and Fayad, 2008) offer se-

cure boot

functionality, secure storage and secure ex-

ecution environments for security-critical functions,

which are isolated based on hardware mechanism

from other processes running on the phone.

On the other hand, previous works on secure oper-

ating systems, e.g., (Fraim, 1983; Karger et al., 1990),

have shown how to achieve strong isolation for se-

cure execution and to have less complexity for the

trusted computing base, i.e., the code that all security

relies upon. The concept of a security kernel (An-

derson, 1972) incorporates all relevant functionality

needed to enforce the security into a kernel that is

isolated and protected from tampering by other soft-

ware and small enough to be veriﬁable for its cor-

rectness and security. While earlier systems suffered

mostly from poor performance in those days, recent

CPU hardware technology, especially their virtualiza-

tion support, and the development of efﬁcient micro-

kernel software architectures (Liedtke, 1995) allow

Secure boot means that a system terminates the boot

process in case the integrity check of a component to be

loaded fails.

for the realization of security kernels with low perfor-

mance overhead while maintaining compatibility to

existing applications. For example, Turaya (EMSCB

Project Consortium, 2008) and the OpenTC security

architecture (The OpenTC Project Consortium, 2009)

are research efforts that take advantage of these tech-

nologies to develop a security kernel on modern CPU

hardware.

Contribution. In this paper, we propose a security

architecture for accessing e-health services on mobile

phones. We present the combination of efﬁcient so-

lutions that current technology can offer on mobile

phones for the secure handling of accessing and pro-

cessing of security-sensitive data such as electronic

health records. In particular, we propose (i) a security

framework to create a secure runtime environment for

medical applications, and (ii) speciﬁc tools that pro-

tect the authentication of users and their mobile de-

vices to e-health servers.

In our security framework, we combine the con-

cept of a security kernel with hardware security fea-

tures of modern mobile phone processors. On top of

this layer, we use isolated execution compartments to

separate applications that process medical data (e.g.,

an EHR viewer) and applications that process non-

medical data (e.g., the telephony application or an or-

dinary web browser).

As a secure authentication tool, we propose a

trusted wallet service that protects the user’s lo-

gin credentials and performs the authentication to e-

health (or other) servers on behalf of the user. This

tool protects the users from being tricked into enter-

ing their credentials in malicious applications or faked

web sites, and takes advantage of the underlying se-

curity framework to protect the credentials from ma-

licious software potentially running on the phone. We

present a new implementation of this wallet for mo-

bile phones based on the Nokia N900 platform.

Compared to commodity mobile phone operating

systems, our approach provides a secure environment

against software attacks like malware. The usage of

security-critical data like patients health records is ef-

fectively isolated from other software running on the

phone, and secret data like login credentials to health-

care information systems is protected by the advanced

hardware security features.

In the following, we describe the usage and ad-

versary scenario we consider (Section 2). Then, we

present our security architecture (Section 3): ﬁrst

from a generic perspective, which can be used on

all platforms, followed by its instantiation on mobile

phone platforms. In Section 4, we describe how our

architecture can be implemented and we present our

HEALTHINF 2011 - International Conference on Health Informatics

Mobile TruWallet prototype. Finally, we conclude in

Section 5.

2 PROBLEM SCENARIO

We consider a scenario in which electronic health

records (EHRs) of patients are stored on a local

server of a healthcare provider, e.g., in a hospital.

Health care professionals, like doctors and nurses,

are equipped with mobile computing devices (smart-

phones) on which they can create, edit, and view

EHRs. The EHRs are stored on the e-health server,

and the smartphones communicate with the server via

wireless network connections. For instance, the ac-

cess of medical data can be realized with web-based

applications, using standard web browser software on

mobile devices. Figure 1 depicts the scenario we con-

sider.

Figure 1: Use Case and Adversary Model.

Since EHRs are very security-sensitive private

data, and in most countries protected under strong pri-

vacy laws, unauthorized access to these data must be

prevented. An adversary may try to eavesdrop or ma-

nipulate the sensitive data. As mentioned before, end-

user devices are typically the least speciﬁed and least

secured devices in healthcare infrastructures. Hence,

an adversary would most likely try to attack the mo-

bile phone and its communication connection to the

server in order to illegitimately access medical data.

Studies like (Vouyioukas et al., 2008) have ana-

lyzed how to secure the data transfer, i.e., via encryp-

tion (for conﬁdentiality), digital signatures (for in-

tegrity and authenticity), and user authentication (for

legitimacy of access). However, the protection of the

critical cryptographic keys that are needed for those

mechanisms is not addressed appropriately. Hence,

an attacker who gains access to these keys can cir-

cumvent any other protection mechanism.

Therefore, in this paper we concentrate on an ad-

versary model in which the attacker targets the mobile

computing device of health care professionals in order

to obtain the secret login credentials or keys that are

needed to access the EHR server. Once the adversary

has access to these credentials, he can download or

modify all medical data from the server to which the

credentials allow access to. To achieve this goal, the

adversary can follow two strategies:

• Direct Access. The adversary tries to directly ac-

cess the sensitive data or keys. He could try to ma-

nipulate software running on the phone to access

the data, or he could steal the device and try to

access the data. The former could be achieved by

letting the users install malicious software (mal-

ware, such as trojan horses) without their notice,

e.g., when they browse to a website containing

malicious code that exploits a vulnerability of the

phone’s software to install the malware. Doctors

may use their phones also for other tasks and they

may want to download additional applications to

run them on the phone, which could create the

vulnerability for such an attack.

• Indirect Access. The adversary tries to trick

the users to enter their passwords into a faked

EHR viewer application. The faked application

looks like the real one, but instead of logging into

the server, it sends the passwords to the adver-

sary. The faked application could be installed on

the phone in the same way as malware described

above.

The problem with a commodity mobile phone op-

erating system (OS) is that it cannot provide a sufﬁ-

cient level of protection for the applications or stored

credentials. A mobile phone OS that is directly de-

rived from a desktop OS (e.g., Linux or Windows)

has limited protection capabilities, i.e., simple process

isolation and access control. However, malicious ap-

plications can modify or eavesdrop data of other ap-

plications since they are running with the same user

privileges as other applications.

A more advanced OS, e.g., like

SELinux (Loscocco and Smalley, 2001), can

enforce mandatory access rules, which provide a

stronger isolation of different applications from each

other. For instance, a text editor could only edit

text ﬁles, whereas an audio application could not

modify text ﬁles. The application of such a system

in a mobile e-health scenario has been shown earlier

(Agreiter et al., 2007). However, SELinux is a very

complex system with security policies that are hard to

conﬁgure correctly even for moderately complicated

scenarios. Moreover, due to a relatively large code

base, it is infeasible to perform a comprehensive

formal (or even semi-formal) veriﬁcation of the cor-

rectness and security of SELinux. Another example

is Android (Google Android, 2010), which provides

a similar application-oriented access control, i.e., it

deﬁnes for each application different access rules

and privileges — in contrast to user-oriented access

A SECURITY ARCHITECTURE FOR ACCESSING HEALTH RECORDS ON MOBILE PHONES

control as in normal Linux and Windows, where all

programs of one user share the same access rights.

Nevertheless, even advanced mobile phone OS’s

still suffer from ineffective protection against unau-

thorized modiﬁcations of programs or even modiﬁ-

cations of the OS itself. An adversary could install

on the user’s phone additional (faked) programs or

replace existing programs. The user has seldom a

chance to notice the modiﬁcation, and critical data

like credentials could be transferred to the adversary.

3 WALLET ARCHITECTURE

3.1 General Idea

Our security architecture aims to protect against the

attacks described above. To counter direct access at-

tacks, our architecture is based on a security kernel

that isolates different applications, supports secure

boot, and provides secure storage. Hence, authenti-

cation data is stored encrypted, and can only be ac-

cessed by the legitimate application (TruWallet) when

the correct (unmodiﬁed) system has been booted.

Our wallet architecture aims to prevent indirect at-

tacks by letting the wallet handle all authentication

procedures. During a normal authentication, users do

not enter passwords (this is automatically done by the

wallet), hence they cannot accidentally disclose them

towards a fake application that tries to spoof the look

and feel of the legitimate EHR viewer or another ap-

plication trusted by the user.

Figure 2: General idea of TruWallet.

Our wallet-based security architecture provides

two levels of protection (cf. Figure 2):

1. Protection of Authentication Data. TruWal-

let protects the user’s credentials (username and

password) against unauthorized access. This ap-

proach is generic, and can be used also for other

scenarios (e.g., web applications like eBay or

Amazon). Indeed, TruWallet can be used simul-

taneously by different applications, yet it only au-

thenticates each application to the server where it

has been registered as legitimate application be-

fore.

2. Protection of Medical Data. An isolated EHR

viewer (which can be a special-purpose browser)

is used to view EHRs. This viewer cannot be mod-

iﬁed because a ﬁxed program image is executed,

which is measured by the security kernel by com-

puting a cryptographic hash and compared to a

known-good reference value. This ensures that

all modiﬁcations of the EHR viewer can be de-

tected. In case a browser is used as EHR viewer,

this browser is only allowed to contact the EHR

server and cannot connect to other sites.

3.2 System Model

Our system model for TruWallet consists of several

parties (see Figure 3): A user interacts with a com-

puting platform through a secure graphical user inter-

face secure GUI. An EHR viewer is used to render

content that it gets from the wallet, which is acting

as a proxy. The wallet obtains the requested content

from the server, blinds security-sensitive ﬁelds (e.g.,

password) on the pages presented to the browser, and

ﬁlls in login credentials when logging into the sys-

tem. For this, TruWallet has to handle two different

SSL sessions: one between wallet and EHR viewer,

and one between wallet and server. The secure GUI

controls the input/output devices and multiplexes the

screen output of the EHR viewer and of the wallet.

Moreover, it always indicates the name of the appli-

cation the user is currently interacting with via a re-

served area on the screen, hence providing a trusted

path between user and application. Moreover, our

architecture includes a compartment for non-medical

data and applications. This compartment is strictly

separated from the EHR viewer and can be used for

arbitrary applications.

3.3 Generic Wallet-based e-Health

Architecture

The generic TruWallet architecture is based on a

security kernel, which is a small trusted software

layer, providing trusted services and isolated com-

partments. Thus, the security kernel ensures runtime

security of the system. Compartments contain arbi-

trary software, e.g., a complete legacy operating sys-

tem (Linux in our case), and may communicate only

via well-deﬁned interfaces. In particular, a malicious

compartment cannot read arbitrary memory of other

compartments. In our solution, EHR viewer, non-

medical applications and wallet run in different com-

partments, and we assume that arbitrary software (in-

cluding malware like Trojan horses and viruses) may

be running in the non-medical compartment. There-

HEALTHINF 2011 - International Conference on Health Informatics

fore, the security of our solution is based on trusted

components (wallet and EHR viewer) that are exe-

cuted in separated compartments, isolated from un-

trusted software that might be running simultaneously

on the same platform.

In an earlier work (Gajek et al., 2009), we have

demonstrated the feasibility of the wallet architecture

on a PC platform. In the PC-based implementation,

the compartmentalization was realized by using the

isolation property of virtual machines combined with

the resource sharing control of an underlying micro-

kernel. The wallet compartment is trusted, which is

motivated by the fact that the complexity of the wal-

let is much lower than that of an EHR viewer or

a compartment containing several different applica-

tions. Moreover, users cannot install arbitrary soft-

ware (which may be malicious or ﬂawed) in the wal-

let compartment, but they may install arbitrary view-

ers or other tools into other compartments. To pre-

vent unauthorized access by other users to the plat-

form and, hence, the sensitive data, the security ker-

nel requires an overall user authentication (e.g., a user

password) to login into the whole system. In this way,

the credentials stored by the wallet are bound to the

corresponding user.

Trusted Computing Support. Trusted Computing

(TC) hardware and TC-enabled software is used to

provide authenticated boot, i.e., based on a “chain

of trust”, the integrity of the software stack including

the Trusted Computing Base (TCB) can be veriﬁed

later, e.g., before access to cryptographic keys is al-

lowed. An alternative to authenticated boot which is

usually used on for mobile platforms is secure boot:

In this case, the system’s integrity state is compared

to reference values and can be started only if it has not

been modiﬁed.

Moreover, TC hardware can be used

for secure storage, i.e., encryption keys protected by

the hardware can only be used if load-time integrity

of the system is maintained. Thus, the credentials

stored by the wallet are bound to the TCB to prevent

an adversary from gaining access to the data by re-

placing software (e.g., booting a different OS). On the

PC platform (Gajek et al., 2009) we used a Trusted

Platform Module (TPM) version 1.2 (Trusted Com-

puting Group, 2009) as TC hardware for TruWallet.

In fact the security kernel has to provide comprehen-

sive user access control as in typical operating systems, in-

cluding system login and screen lock functionality, in order

to prevent unauthorized access to the wallet. However, the

details of those mechanisms are out of scope of this paper.

Of course, it is important that these reference values

are stored in a secure location, e.g., protected by security

hardware, to avoid manipulations.

The TPM is a dedicated security chip that provides –

among other features – cryptographic operations (e.g.,

key generation, encryption, digital signatures), sup-

port for authenticated boot, and the possibility to bind

cryptographic keys to the load-time integrity state of

the system.

Figure 3: Generic TruWallet Architecture.

3.4 Mobile TruWallet

To implement our security architecture for mobile e-

health scenarios, several building blocks for mobile

environments are required:

• Trusted hardware for mobile platforms which sup-

ports features to protect cryptographic keys and

verify the system integrity;

• a secure hypervisor layer for mobile platforms to

provide isolated execution environments for ap-

plications;

• a security kernel with a secure GUI for mobile

platforms to provide a trusted path between the

user and applications, and with secure storage for

applications;

• a trusted wallet (TruWallet) to handle authentica-

tion and protect the user’s credentials.

In the following, we brieﬂy introduce the ﬁrst

three building blocks, before we focus in more detail

on the implementation of a trusted wallet on a mobile

phone in the next section.

Trusted Hardware for Mobile Platforms. The ar-

chitecture of TruWallet relies of trusted hardware for

performing security critical operations. To instantiate

TruWallet architecture on a mobile phone, we have

to use mobile hardware security extensions instead of

a TPM (which is not available on current phones).

On mobile platforms, general-purpose secure hard-

ware such as M-Shield (Azema and Fayad, 2008) and

TrustZone (Alves and Felton, 2004) is available. In

this paper, we focus on M-Shield, because this hard-

ware extension is available in some current mobile

A SECURITY ARCHITECTURE FOR ACCESSING HEALTH RECORDS ON MOBILE PHONES

phones, including Nokia N900 (which we used for our

prototype).

M-Shield provides a small amount of dedicated

on-chip ROM and RAM as well as one-time pro-

grammable memory for device keys which are acces-

sible only in a special execution mode of the main

CPU – the Trusted Execution Environment (TrEE).

A secure state machine (SSM) guarantees secure

switching between both processor modes, thus the

TrEE and normal execution environment are isolated

from each other. M-Shield enables the TrEE on a de-

vice with the following features: (i) isolated secure

code execution; (ii) secure boot; (iii) hardware-based

secure storage.

Secure Hypervisor for Mobile Devices. Several

microkernels for mobile and embedded devices have

been implemented, for instance the commercially

available L4 microkernels OKL4 (Open Kernel Labs,

2010) and PikeOS P4 (Brygier et al., 2009). These

microkernels provide isolation between user space ap-

plications, just like their counterparts on other plat-

forms (e.g., on PCs). Therefore, they can be used for

a secure hypervisor layer for a security kernel on mo-

bile phones. In particular, the seL4 microkernel has

been formally veriﬁed for correctness (Klein et al.,

2009), hence taking an important step towards build-

ing a formally veriﬁable security kernel on top of a

microkernel.

Security Kernel with Secure GUI for Mobile De-

vices. The Turaya Trusted Mobile Desktop (Sel-

horst et al., 2010) implements a security kernel with

a secure user interface for mobile devices. Its TCB

consists of a hypervisor layer and a trusted software

layer. The hypervisor layer is implemented on top

of an L4 microkernel, which has been ported to the

Nokia N900 mobile phone. The Trusted Software

Layer contains a number of security services, such as

a secure graphical user interface (called TrustedGUI),

a virtual private network (VPN) client, and a ﬁle en-

cryption service.

4 WALLET PROTOTYPE ON

NOKIA N900

In order to demonstrate the feasibility of running a

trusted wallet on a mobile phone, we have imple-

mented Mobile TruWallet, a mobile version of trusted

wallet, on a Nokia N900 device.

4.1 Mobile TruWallet Architecture

Instead of realizing the full implementation of a se-

curity kernel, for which we refer to the works of

(Brygier et al., 2009; Klein et al., 2009; Selhorst

et al., 2010), we have implemented the wallet on

Maemo (Maemo, 2010), which is based on Linux and

provides standard operating system process isolation

and discretionary access control.

Figure 4: Mobile TruWallet Architecture.

The architecture of Mobile TruWallet we have im-

plemented is depicted in Figure 4. As it can be seen,

TruWallet resides on the operating system side, but

also operates on secrets at the same time, e.g., main-

tains a TLS channel to the web-server and also per-

forms authentication with the user passwords. How-

ever, our generic architecture assumes that TruWal-

let is isolated from the rest of the system. This as-

sumption is reasonable to some extend in the con-

text of existing operating systems for Nokia mobile

phones: Symbian OS and Maemo. Their platform se-

curity enables, with different degrees, process isola-

tion. The microkernel-based Symbian OS provides

process execution isolation and enforces control on

inter-process communication via a capability mecha-

nism, while Maemo’s security model is based on Dis-

cretionary Access Control (DAC) which enforces se-

curity by process ownership.

We achieved process isolation on Maemo by cre-

ating a Mobile TruWallet process under a unique

UserID and deﬁning restrictive access rights to that

UserID. Note that for this prototype, we rely on the

standard Unix/Linux discretionary access control se-

curity framework, and there is always the threat that

an administrator (root account) with the super-user

access rights is compromised. However, we imple-

mented the wallet as if it was running on a security

kernel. This approach allows us to concentrate on

the wallet-speciﬁc aspects for the prototype (i.e., per-

formance, user interface, compatibility to the mobile

HEALTHINF 2011 - International Conference on Health Informatics

web browser and web sites, etc.). In a later stage, the

wallet can be easily adapted to a security kernel sys-

tem like the L4-based one on N900 (Selhorst et al.,

2010).

Nokia N900 device is based on M-Shield secure

hardware. We utilize M-Shield functionality for the

secure boot, and we also implement secure storage

functionality on the top of M-Shield.

Only authenticated programs, so-called protected

applications (PAs), can be executed within the TrEE

of M-Shield. However, protected applications have

to be authorized, i.e., certiﬁed, by the device’s M-

Shield stakeholder, most likely the device manufac-

turer. As we have not been able to get the PA certi-

ﬁed by the device manufacturer, we use a different ap-

proach: We reuse the general purpose APIs available

for M-Shield TrEE. This approach allows third par-

ties to leverage the TrEE. For instance, the On-board

Credentials platform (ObC) (Kostiainen et al., 2009)

provides the means to develop programs for the TrEE

without the involvement of the manufacturer. In our

implementation, we build the secure storage function-

ality of Mobile TruWallet on top of ObC.

4.2 ObC Architecture

Figure 5 illustrates the ObC architecture. The core

component of the ObC platform – which resides in

the dedicated RAM and can be executed in secure en-

vironment – is an interpreter. The interpreter pro-

vides a virtualized environment where “credential

programs”, i.e., scripts developed by third parties,

can be executed. The credential programs are writ-

ten using (a subset of) Lua scripting language (Lua,

2010) or in assembler. When a credential program is

executed, the interpreter isolates it from secrets that

are stored within the TrEE and from the execution of

other credential programs.

The interpreter makes use of a Crypto Library

which provides an interface for commonly used cryp-

tographic primitives. It provides a sealing/unsealing

function for ObC programs, which can be used to

protect secret data stored persistently outside the se-

cure environment. Sealed data is encrypted with a key

which is protected by the TrEE, and the ObC platform

controls the usage of this key. A device-speciﬁc sym-

metric key called ObC platform key (OPK) is used for

the sealing/unsealing functionality.

Credential Manager is a mediator between OS

side applications and components that reside within

the TrEE. It provides an API for third-party devel-

oped applications. Using the API the applications can

execute credential programs, and create and use new

asymmetric keys. The credential manager maintains

a database, in which credentials and credential pro-

grams are stored in a cryptographically sealed way.

Figure 5: On-board Credential architecture.

A more detailed description of the ObC architec-

ture can be found in (Kostiainen et al., 2009; Kosti-

ainen et al., 2010).

4.3 Implementation

In our prototype, the wallet is implemented in the

C programming language, contains about 2600 lines

of code, and runs as separate process with a unique

UserID. For the SSL/TLS proxy, we use Paros (Paros,

2010), which is an open-source implementation in

Java, and it executes as a process with the same

UserID as the wallet. We deﬁne restrictive access

rights on this UserID so that other processes cannot

access the data or code of the wallet.

Accessing Health Records. The wallet uses the

libxml library to parse web sites and web forms in

order to search for password ﬁelds. Whenever it ﬁnds

such ﬁelds, these forms are put into a cache and are

disabled before they are shown in the web browser.

This prevents the user from accidentally typing pass-

words into a potentially malicious or faked web site.

Instead users just provide their user name and sim-

ply click the submit or login button in the mobile web

browser.

Hence, when doctors want to access a health

record from the e-health server, they simply open the

EHR viewer browser on the phone and click the lo-

gin button. The wallet replaces then automatically

the disabled password ﬁeld with the actual password

of the doctor’s account on the e-health server. This

process runs transparently, so the doctor just sees the

EHR viewer application, and when the login is com-

pleted he can access the health records on the server.

A SECURITY ARCHITECTURE FOR ACCESSING HEALTH RECORDS ON MOBILE PHONES

Registration. Before doctors can use the wallet to

to register their account in the wallet on the phone.

Therefore, the wallet also looks for registration forms.

When the user tries to access a website with the

browser for the ﬁrst time, the wallet asks the user

for an existing password or it can create a new one.

Figure 6 shows a corresponding screenshot where the

wallet dialog pops up after the user opened a website

(with a login ﬁeld) in the browser for the ﬁrst time.

Figure 6: Screenshot of Mobile TruWallet when registering

an existing password.

Once the password has been provided (or newly

created), the wallet stores the credentials in a speciﬁc

ﬁle. During runtime, the access to this ﬁle is only

granted to the UserID of the wallet. Hence, other pro-

grams cannot read or modify the stored credentials.

When the device is going to be shut off, this ﬁle is

sealed using the ObC platform as mentioned before.

Figure 7: Screenshot of Mobile TruWallet showing stored

passwords.

Users can view a list of the stored accounts in

wallet, as the screenshot in Figure 7 shows. For

example, it shows a web-based e-mail account and

“ehealth.local”, which is our local EHR server in our

prototype. We realized the user interface based on the

Hildon GUI framework (Hildon Application Frame-

work, 2010) on Maemo.

Interoperability. We have tested our wallet imple-

mentation with several public websites, like web e-

mail services, eBay, Amazon, etc. Registration and

formance overhead for the user. Hence, it should

be easy to integrate web-based e-health services on

our platform. Special-purpose EHR viewers or other

medical applications can be supported as well as long

as they use SSL/TLS and web-based login proce-

dures. Other authentication protocols could also be

integrated, but may require some effort to adapt the

wallet.

5 CONCLUSIONS AND FUTURE

WORK

Mobile access to electronic medical data is an emerg-

ing application scenario with strong security and pri-

vacy requirements that is rapidly gaining practical im-

portance. Existing systems suffer from a lack of ap-

propriate protection for security- and privacy-critical

data and applications. Moreover, standard operating

systems do not use existing hardware security features

of mobile platforms to their full extent.

To enable secure mobile access to electronic

health records containing privacy-sensitive data, we

propose an e-health security architecture which pro-

tects the user’s authentication credentials as well as

the sensitive medical data. Our architecture is based

on commonly available trusted hardware components,

a security kernel, and a trusted wallet. In this pa-

per, we introduce our comprehensive security archi-

tecture, discuss security building blocks on mobile

phones, and present our implementation of Mobile

TruWallet on a commodity smartphone.

Since our Mobile TruWallet prototype demon-

strates the feasibility of the architecture on mobile

phones, future work includes the integration of all se-

curity building blocks (i.e., the use of hardware secu-

rity features, a security kernel consisting of a secure

hypervisor and a trusted software layer, and the Mo-

bile TruWallet authentication solution) into one sys-

tem.

ACKNOWLEDGEMENTS

This work was partially funded by the German fed-

eral state North Rhine-Westphalia and supported by

the European Regional Development Fund under the

project RUBTrust/MediTrust. Further, the author

Alexandra Dmitrienko was supported by the Erasmus

HEALTHINF 2011 - International Conference on Health Informatics

Mundus External Co-operation Window Programme

of the European Union.

REFERENCES

Aggarwal, M. and Vennon, T. (2010). Study of BlackBerry

proof-of-concept malicious applications. Technical

Report White paper, SMobile Global Threat Center.

Agreiter, B., Alam, M., Hafner, M., Seifert, J. P., and

Zhang, X. (2007). Model driven conﬁguration of

secure operating systems for mobile applications in

healthcare. In Proceedings of the 1st International

Workshop on Mode-Based Trustworthy Health Infor-

mation Systems.

Alves, T. and Felton, D. (2004). TrustZone: Integrated

hardware and software security. Technical report,

ARM.

Anderson, J. (1972). Computer security technology

planning study. Technical Report ESD-TR-73-51,

AFSC, Hanscom AFB, Bedford, MA. AD-758 206,

ESD/AFSC.

Android Open Source Project (2010). Project website.

http://www.android.com.

Apple Inc. (2010). iOS website. http://www.apple.com/

iphone/ios4.

Azema, J. and Fayad, G. (2008). M-Shield

mo-

bile security technology: making wireless se-

cure. Texas Instruments White Paper. fo-

cus.ti.com/pdfs/wtbu/ti mshield whitepaper.pdf.

Benelli, G. and Pozzebon, A. (2010). Near ﬁeld communi-

cation and health: Turning a mobile phone into an in-

teractive multipurpose assistant in healthcare scenar-

ios. In Biomedical Engineering Systems and Tech-

nologies, International Joint Conference, BIOSTEC

2009, Revised Selected Papers, volume 52 of Commu-

nications in Computer and Information Science, pages

356–368. Springer.

Brygier, J., Fuchsen, R., and Blasum, H. (2009). PikeOS:

Safe and secure virtualization in a separation micro-

kernel. Technical report, Sysgo.

EMSCB Project Consortium (2005–2008). The Euro-

pean Multilaterally Secure Computing Base (EM-

SCB) project. http://www.emscb.org.

Fraim, L. (1983). SCOMP: A solution to the multilevel

security problem. In IEEE Computer, pages 26–34.

Gajek, S., L

ohr, H., Sadeghi, A.-R., and Winandy, M.

(2009). TruWallet: Trustworthy and migratable

wallet-based web authentication. In The 2009 ACM

Workshop on Scalable Trusted Computing (STC’09),

pages 19–28. ACM.

Google Android (2010). Security and permissions.

http://developer.android.com/intl/de/guide/topics/

security/security.html.

Han, D., Park, S., and Lee, M. (2008). THE-MUSS: Mobile

u-health service system. In Biomedical Engineering

Systems and Technologies, International Joint Confer-

ence, BIOSTEC 2008, Revised Selected Papers, vol-

ume 25 of Communications in Computer and Infor-

mation Science, pages 377–389. Springer.

Hildon Application Framework (2010). Project website.

http://live.gnome.org/Hildon.

Iozzo, V. and Weinmann, R.-P. (2010).

Ralf-Philipp Weinmann & Vincenzo

Iozzo own the iPhone at PWN2OWN.

http://blog.zynamics.com/2010/03/24/ralf-philipp-

weinmann-vincenzo-iozzo-own-the-iphone-at-pwn2

own/.

Karger, P. A., Zurko, M. E., Bonin, D. W., Mason, A. H.,

and Kahn, C. E. (1990). A VMM security kernel

for the VAX architecture. In Proceedings of the

IEEE Symposium on Research in Security and Pri-

vacy, pages 2–19, Oakland, CA. IEEE Computer So-

ciety, Technical Committee on Security and Privacy,

IEEE Computer Society Press.

Klein, G., Elphinstone, K., Heiser, G., Andronick, J., Cock,

D., Derrin, P., Elkaduwe, D., Engelhardt, K., Kolan-

ski, R., Norrish, M., Sewell, T., Tuch, H., and Win-

wood, S. (2009). seL4: Formal veriﬁcation of an OS

kernel. In Proceedings of the 22nd ACM Symposium

on Operating Systems Principles, Big Sky, MT, USA.

ACM Press. To appear.

Kostiainen, K., Dmitrienko, A., Ekberg, J.-E., Sadeghi, A.-

R., and Asokan, N. (2010). Key attestation from

trusted execution environments. In TRUST 2010: Pro-

ceedings of the 3rd International Conference on Trust

and Trustworthy Computing, pages 30–46. Springer.

Kostiainen, K., Ekberg, J.-E., Asokan, N., and Rantala, A.

(2009). On-board credentials with open provisioning.

In ASIACCS ’09: Proceedings of the 4th International

Symposium on Information, Computer, and Commu-

nications Security, pages 104–115. ACM.

Liedtke, J. (1995). On microkernel construction. In Pro-

ceedings of the 15th ACM Symposium on Operating

Systems Principles (SOSP’95), Copper Mountain Re-

sort, Colorado. Appeared as ACM Operating Systems

Review 29.5.

Loscocco, P. and Smalley, S. (2001). Integrating ﬂexible

support for security policies into the Linux operating

system. In Proceedings of the FREENIX Track: 2001

USENIX Annual Technical Conference, pages 29–42.

USENIX Association.

Lua (2010). Project website. http://www.lua.org.

Maemo (2010). Project website. http://maemo.org.

Microsoft (2010). Windows mobile website. http://www.

microsoft.com/windowsmobile.

Open Kernel Labs (2010). OKL4 project website.

http://okl4.org.

Paros (2010). Project website. http://www.parosproxy.org.

Selhorst, M., St

uble, C., Feldmann, F., and Gnaida, U.

(2010). Towards a trusted mobile desktop. In Trust

and Trustworthy Computing (TRUST 2010), volume

6101 of LNCS, pages 78–94. Springer.

A SECURITY ARCHITECTURE FOR ACCESSING HEALTH RECORDS ON MOBILE PHONES

Sunyaev, A., Leimeister, J. M., and Krcmar, H. (2010).

Open security issues in german healthcare telemat-

ics. In HEALTHINF 2010 - Proceedings of the 3rd In-

ternational Conference on Health Informatics, pages

187–194. INSTICC.

Symbian Foundation Community (2010). Project website.

http://www.symbian.org.

The OpenTC Project Consortium (2005–2009). The

Open Trusted Computing (OpenTC) project.

http://www.opentc.net.

Tiago Alves, D. F. (2004). TrustZone: Integrated Hardware

and Software Security. http://www.arm.com/pdfs/TZ.

Trusted Computing Group (2009). TPM Main Speciﬁca-

tion. http://www.trustedcomputinggroup.org.

Vennon, T. (2010). Android malware. A study of known and

potential malware threats. Technical Report White pa-

per, SMobile Global Threat Center.

Vouyioukas, D., Kambourakis, G., Maglogiannis, I.,

Rouskas, A., Kolias, C., and Gritzalis, S. (2008). En-

abling the provision of secure web based m-health ser-

vices utilizing xml based security models. Security

and Communication Networks, 1(5):375–388.

HEALTHINF 2011 - International Conference on Health Informatics