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 specifically 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 flexibility, 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 flexible and cost-
efficient computing devices, they generally do not off-
er sufficient 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 insufficient protection of stored data (secure
storage). Recent attacks on smartphones demonstrate
their vulnerability (Iozzo and Weinmann, 2010; Ven-
87
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
Copyright
c
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 identified as an insecure and less specified 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 firewalls 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 sufficiently 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
1
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 verifiable 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 efficient micro-
kernel software architectures (Liedtke, 1995) allow
1
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 efficient 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) specific 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): first
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
88
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 specified 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 confidentiality), 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 suffi-
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 files, whereas an audio application could not
modify text files. 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
configure 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) verification 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
defines for each application different access rules
and privileges in contrast to user-oriented access
A SECURITY ARCHITECTURE FOR ACCESSING HEALTH RECORDS ON MOBILE PHONES
89
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 modifications of programs or even modifi-
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 modification, 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 (unmodified) 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-
ified because a fixed 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 modifications 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 fields (e.g.,
password) on the pages presented to the browser, and
fills 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-defined 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
90
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 flawed) 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.
2
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 verified
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 modified.
3
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.
2
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.
3
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 briefly introduce the first
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
91
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 verified for correctness (Klein et al.,
2009), hence taking an important step towards build-
ing a formally verifiable 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 file 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 defining 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-specific aspects for the prototype (i.e., per-
formance, user interface, compatibility to the mobile
HEALTHINF 2011 - International Conference on Health Informatics
92
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., certified, by the device’s M-
Shield stakeholder, most likely the device manufac-
turer. As we have not been able to get the PA certi-
fied 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-specific 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 define 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 fields. Whenever it finds
such fields, 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 field 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
93
Registration. Before doctors can use the wallet to
login to websites like the e-health server, they have
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 first 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 field) in the browser for the first 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 specific
file. During runtime, the access to this file 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 file 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
login work transparently and without noticeable per-
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
94
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 configuration 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
TM
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 field 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 verification 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 flexible
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
95
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 Specifica-
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
96