A SECURITY ARCHITECTURE FOR ACCESSINGHEALTH RECORDS ON MOBILE PHONES

Alexandra Dmitrienko, Zecir Hadzic, Hans Lohr and Marcel WinandyHorst Gortz Institute for IT Security, Ruhr-University Bochum, Germany

{alexandra.dmitrienko, zecir.hadzic, hans.loehr, marcel.winandy}@trust.rub.de

Ahmad-Reza SadeghiFraunhofer-Institut SIT Darmstadt, Technische Universitat Darmstadt, Germany

ahmad.sadeghi@cased.de

Keywords: Health records, mobile computing, smartphone, security architecture, trusted computing.

Abstract: Using mobile phones to access healthcare data is an upcoming application scenario of increasingimportance in the near future. However, important aspects to consider in this context are the highsecurity and privacy requirements for sensitive medical data. Current mobile phones using standardoperating systems and software cannot offer appropriate protection for sensitive data, althoughthe hardware platform often offers dedicated security features. Malicious software (malware) likeTrojan horses on the mobile phone could gain unauthorized access to sensitive medical data.In this paper, we propose a complete security framework to protect medical data (such as electronichealth records) and authentication credentials that are used to access e-health servers. Derivedfrom a generic architecture that can be used for PCs, we introduce a security architecture specif-ically for mobile phones, based on existing hardware security extensions. We describe securitybuilding blocks, including trusted hardware features, a security kernel providing isolated applica-tion environments as well as a secure graphical user interface, and a trusted wallet (TruWallet) forsecure authentication to e-health servers. Moreover, we present a prototype implementation of thetrusted wallet on a current smartphone: the Nokia N900. Based on our architecture, health careprofessionals can safely and securely process medical data on their mobile phones without the riskof disclosing sensitive information as compared to commodity mobile operating systems.

1 INTRODUCTION

The usage of mobile phones as multi-purposeassistant device in healthcare has been proposedin several application scenarios. Its usefulness isderived from its mobility and flexibility, i.e., to-day’s smartphones offer appropriate computingand storage capacity allowing the realization ofvarious applications that can be used basicallyfrom everywhere. For instance, healthcare profes-sionals can use a mobile phones to download andshare electronic health records of their patients(Benelli and Pozzebon, 2010). In other scenar-ios, patients use their mobile phones to providepersonal health data, e.g., taken from additionalbio-sensors, to a medical information and diagno-sis system (Han et al., 2008).

While smartphones are very flexible and cost-

efficient computing devices, they generally do notoffer sufficient security mechanisms to protect thedata they operate on. This is mainly due to thearchitectural shortcomings of their operating sys-tems, which are derived from the same (secu-rity) architecture as desktop operating systems.Typical examples are Google Android (AndroidOpen Source Project, 2010), Apple iOS (AppleInc., 2010), Symbian (Symbian Foundation Com-munity, 2010), and Windows Mobile (Microsoft,2010). Although, some of them provide more so-phisticated security mechanisms than their desk-top counterparts, e.g., application-oriented accesscontrol in Android (Google Android, 2010), theystill suffer from fundamental security problemsdue to their large code base and complexity, lack-ing of strong isolation of applications (secure exe-cution) and insufficient protection of stored data

(secure storage). Recent attacks on smartphonesdemonstrate their vulnerability (Iozzo and Wein-mann, 2010; Vennon, 2010; Aggarwal and Ven-non, 2010). But the secure operation of a mobilephone is an important aspect when a user is work-ing with security and privacy-sensitive data suchas personal health records on the device.

Especially in healthcare telematics infrastruc-tures, the end-user systems of health professionalshave been identified as an insecure and less spec-ified component (Sunyaev et al., 2010). Malwareon the user’s computing platform could steal pass-words that are used to access healthcare informa-tion systems, manipulate data such as medicalprescriptions, or eavesdrop on and copy privatedata such as personal health records. While theconnection of stationary desktop systems to thehealthcare telematics may be protected by addi-tional secure hardware network components like,e.g., special firewalls and gateway routers, the sit-uation gets worse when mobile phones are used.Due to their mobility and changing connectivity(wireless LAN or GSM network), mobile phonesmay usually only use Virtual Private Network(VPN) technology to secure the connection. Butthe necessary credentials, like user passwords andVPN keys, are not sufficiently protected againstmalware on the device, and, hence, could be ac-cessed by unauthorized parties.

However, modern smartphone hardware offersadvanced security functionality, which are embed-ded in their processors, but generally not used bythe mainstream mobile operating systems. Forinstance, ARM TrustZone (Tiago Alves, 2004)and Texas Instruments M-Shield (Azema andFayad, 2008) offer secure boot1 functionality, se-cure storage and secure execution environmentsfor security-critical functions, which are isolatedbased on hardware mechanism from other pro-cesses running on the phone.

On the other hand, previous works on secureoperating systems, e.g., (Fraim, 1983; Kargeret al., 1990), have shown how to achieve strongisolation for secure execution and to have lesscomplexity for the trusted computing base, i.e.,the code that all security relies upon. The con-cept of a security kernel (Anderson, 1972) in-corporates all relevant functionality needed toenforce the security into a kernel that is iso-lated and protected from tampering by othersoftware and small enough to be verifiable for

1Secure boot means that a system terminates theboot process in case the integrity check of a compo-nent to be loaded fails.

its correctness and security. While earlier sys-tems suffered mostly from poor performance inthose days, recent CPU hardware technology, es-pecially their virtualization support, and the de-velopment of efficient microkernel software archi-tectures (Liedtke, 1995) allow for the realizationof security kernels with low performance over-head while maintaining compatibility to exist-ing applications. For example, Turaya (EMSCBProject Consortium, 2008) and the OpenTC se-curity architecture (The OpenTC Project Con-sortium, 2009) are research efforts that take ad-vantage of these technologies to develop a securitykernel on modern CPU hardware.

Contribution In this paper, we propose a se-curity architecture for accessing e-health serviceson mobile phones. We present the combinationof efficient solutions that current technology canoffer on mobile phones for the secure handling ofaccessing and processing of security-sensitive datasuch as electronic health records. In particular,we propose (i) a security framework to create asecure runtime environment for medical applica-tions, and (ii) specific tools that protect the au-thentication of users and their mobile devices toe-health servers.

In our security framework, we combine theconcept of a security kernel with hardware se-curity features of modern mobile phone proces-sors. On top of this layer, we use isolated ex-ecution compartments to separate applicationsthat process medical data (e.g., an EHR viewer)and applications that process non-medical data(e.g., the telephony application or an ordinaryweb browser).

As a secure authentication tool, we propose atrusted wallet service that protects the user’s lo-gin credentials and performs the authenticationto e-health (or other) servers on behalf of theuser. This tool protects the users from beingtricked into entering their credentials in maliciousapplications or faked web sites, and takes advan-tage of the underlying security framework to pro-tect the credentials from malicious software po-tentially running on the phone. We present a newimplementation of this wallet for mobile phonesbased on the Nokia N900 platform.

Compared to commodity mobile phone oper-ating systems, our approach provides a secure en-vironment against software attacks like malware.The usage of security-critical data like patientshealth records is effectively isolated from othersoftware running on the phone, and secret data

like login credentials to healthcare informationsystems is protected by the advanced hardwaresecurity features.

In the following, we describe the usage andadversary scenario we consider (Section 2). Then,we present our security architecture (Section 3):first from a generic perspective, which can be usedon all platforms, followed by its instantiation onmobile phone platforms. In Section 4, we describehow our architecture can be implemented and wepresent our Mobile TruWallet prototype. Finally,we conclude in Section 5.

2 PROBLEM SCENARIO

We consider a scenario in which electronichealth records (EHRs) of patients are stored ona local server of a healthcare provider, e.g., in ahospital. Health care professionals, like doctorsand nurses, are equipped with mobile computingdevices (smartphones) on which they can create,edit, and view EHRs. The EHRs are stored onthe e-health server, and the smartphones commu-nicate with the server via wireless network con-nections. For instance, the access of medical datacan be realized with web-based applications, us-ing standard web browser software on mobile de-vices. Figure 1 depicts the scenario we consider.

Figure 1: Use Case and Adversary Model

Since EHRs are very security-sensitive pri-vate data, and in most countries protected understrong privacy laws, unauthorized access to thesedata must be prevented. An adversary may tryto eavesdrop or manipulate the sensitive data. Asmentioned before, end-user devices are typicallythe least specified and least secured devices inhealthcare infrastructures. Hence, an adversarywould most likely try to attack the mobile phoneand its communication connection to the serverin order to illegitimately access medical data.

Studies like (Vouyioukas et al., 2008) have an-alyzed how to secure the data transfer, i.e., viaencryption (for confidentiality), digital signatures

(for integrity and authenticity), and user authen-tication (for legitimacy of access). However, theprotection of the critical cryptographic keys thatare needed for those mechanisms is not addressedappropriately. Hence, an attacker who gains ac-cess to these keys can circumvent any other pro-tection mechanism.

Therefore, in this paper we concentrate on anadversary model in which the attacker targets themobile computing device of health care profes-sionals in order to obtain the secret login creden-tials or keys that are needed to access the EHRserver. Once the adversary has access to thesecredentials, he can download or modify all medi-cal data from the server to which the credentialsallow access to. To achieve this goal, the adver-sary can follow two strategies:

• Direct Access: The adversary tries to directlyaccess the sensitive data or keys. He could tryto manipulate software running on the phoneto access the data, or he could steal the de-vice and try to access the data. The formercould be achieved by letting the users installmalicious software (malware, such as trojanhorses) without their notice, e.g., when theybrowse to a website containing malicious codethat exploits a vulnerability of the phone’ssoftware to install the malware. Doctors mayuse their phones also for other tasks and theymay want to download additional applicationsto run them on the phone, which could createthe vulnerability for such an attack.

• Indirect Access: The adversary tries to trickthe users to enter their passwords into a fakedEHR viewer application. The faked applica-tion looks like the real one, but instead of log-ging into the server, it sends the passwordsto the adversary. The faked application couldbe installed on the phone in the same way asmalware described above.

The problem with a commodity mobile phoneoperating system (OS) is that it cannot providea sufficient level of protection for the applicationsor stored credentials. A mobile phone OS that isdirectly derived from a desktop OS (e.g., Linuxor Windows) has limited protection capabilities,i.e., simple process isolation and access control.However, malicious applications can modify oreavesdrop data of other applications since theyare running with the same user privileges as otherapplications.

A more advanced OS, e.g., likeSELinux (Loscocco and Smalley, 2001), canenforce mandatory access rules, which provide a

stronger isolation of different applications fromeach other. For instance, a text editor could onlyedit text files, whereas an audio application couldnot modify text files. The application of such asystem in a mobile e-health scenario has beenshown earlier (Agreiter et al., 2007). However,SELinux is a very complex system with securitypolicies that are hard to configure correctly evenfor moderately complicated scenarios. Moreover,due to a relatively large code base, it is infeasibleto perform a comprehensive formal (or evensemi-formal) verification of the correctness andsecurity of SELinux. Another example is An-droid (Google Android, 2010), which provides asimilar application-oriented access control, i.e., itdefines for each application different access rulesand privileges — in contrast to user-orientedaccess control as in normal Linux and Windows,where all programs of one user share the sameaccess rights.

Nevertheless, even advanced mobile phoneOS’s still suffer from ineffective protection againstunauthorized modifications of programs or evenmodifications of the OS itself. An adversary couldinstall on the user’s phone additional (faked) pro-grams or replace existing programs. The user hasseldom a chance to notice the modification, andcritical data like credentials could be transferredto the adversary.

3 WALLET ARCHITECTURE

3.1 General Idea

Our security architecture aims to protect againstthe attacks described above. To counter directaccess attacks, our architecture is based on a se-curity kernel that isolates different applications,supports secure boot, and provides secure stor-age. Hence, authentication data is stored en-crypted, and can only be accessed by the legit-imate application (TruWallet) when the correct(unmodified) system has been booted.

Our wallet architecture aims to prevent indi-rect attacks by letting the wallet handle all au-thentication procedures. During a normal au-thentication, users do not enter passwords (thisis automatically done by the wallet), hence theycannot accidentally disclose them towards a fakeapplication that tries to spoof the look and feel ofthe legitimate EHR viewer or another applicationtrusted by the user.

Figure 2: General idea of TruWallet

Our wallet-based security architecture pro-vides two levels of protection (cf. Figure 2):

1. Protection of authentication data: TruWal-let protects the user’s credentials (usernameand password) against unauthorized access.This approach is generic, and can be used alsofor other scenarios (e.g., web applications likeeBay or Amazon). Indeed, TruWallet can beused simultaneously by different applications,yet it only authenticates each application tothe server where it has been registered as le-gitimate application before.

2. Protection of medical data: An isolatedEHR viewer (which can be a special-purposebrowser) is used to view EHRs. This viewercannot be modified because a fixed programimage is executed, which is measured by thesecurity kernel by computing a cryptographichash and compared to a known-good referencevalue. This ensures that all modifications ofthe EHR viewer can be detected. In case abrowser is used as EHR viewer, this browseris only allowed to contact the EHR server andcannot connect to other sites.

3.2 System model

Our system model for TruWallet consists of sev-eral parties (see Figure 3): A user interacts witha computing platform through a secure graphi-cal user interface secure GUI. An EHR vieweris used to render content that it gets from thewallet, which is acting as a proxy. The walletobtains the requested content from the server,blinds security-sensitive fields (e.g., password) onthe pages presented to the browser, and fills in lo-gin credentials when logging into the system. Forthis, TruWallet has to handle two different SSLsessions: one between wallet and EHR viewer,and one between wallet and server. The secureGUI controls the input/output devices and mul-tiplexes the screen output of the EHR viewer andof the wallet. Moreover, it always indicates thename of the application the user is currently in-

teracting with via a reserved area on the screen,hence providing a trusted path between user andapplication. Moreover, our architecture includesa compartment for non-medical data and appli-cations. This compartment is strictly separatedfrom the EHR viewer and can be used for arbi-trary applications.

3.3 Generic Wallet-Based e-HealthArchitecture

The generic TruWallet architecture is based on asecurity kernel, which is a small trusted softwarelayer, providing trusted services and isolated com-partments. Thus, the security kernel ensures run-time security of the system. Compartments con-tain arbitrary software, e.g., a complete legacyoperating system (Linux in our case), and maycommunicate only via well-defined interfaces. Inparticular, a malicious compartment cannot readarbitrary memory of other compartments. In oursolution, EHR viewer, non-medical applicationsand wallet run in different compartments, andwe assume that arbitrary software (including mal-ware like Trojan horses and viruses) may be run-ning in the non-medical compartment. Therefore,the security of our solution is based on trustedcomponents (wallet and EHR viewer) that are ex-ecuted in separated compartments, isolated fromuntrusted software that might be running simul-taneously on the same platform.

In an earlier work (Gajek et al., 2009), wehave demonstrated the feasibility of the wallet ar-chitecture on a PC platform. In the PC-basedimplementation, the compartmentalization wasrealized by using the isolation property of vir-tual machines combined with the resource sharingcontrol of an underlying microkernel. The wal-let compartment is trusted, which is motivatedby the fact that the complexity of the wallet ismuch lower than that of an EHR viewer or acompartment containing several different appli-cations. Moreover, users cannot install arbitrarysoftware (which may be malicious or flawed) inthe wallet compartment, but they may install ar-bitrary viewers or other tools into other compart-ments. To prevent unauthorized access by otherusers to the platform and, hence, the sensitivedata, the security kernel requires an overall userauthentication (e.g., a user password) to logininto the whole system. In this way, the credentialsstored by the wallet are bound to the correspond-ing user.2

2In fact the security kernel has to provide com-

Trusted Computing support. Trusted Com-puting (TC) hardware and TC-enabled softwareis used to provide authenticated boot, i.e., basedon a “chain of trust”, the integrity of the soft-ware stack including the Trusted Computing Base(TCB) can be verified later, e.g., before access tocryptographic keys is allowed. An alternative toauthenticated boot which is usually used on formobile platforms is secure boot : In this case, thesystem’s integrity state is compared to referencevalues and can be started only if it has not beenmodified.3 Moreover, TC hardware can be usedfor secure storage, i.e., encryption keys protectedby the hardware can only be used if load-time in-tegrity of the system is maintained. Thus, thecredentials stored by the wallet are bound to theTCB to prevent an adversary from gaining ac-cess to the data by replacing software (e.g., boot-ing a different OS). On the PC platform (Gajeket al., 2009) we used a Trusted Platform Module(TPM) version 1.2 (Trusted Computing Group,2009) as TC hardware for TruWallet. The TPMis a dedicated security chip that provides – amongother features – cryptographic operations (e.g.,key generation, encryption, digital signatures),support for authenticated boot, and the possibil-ity to bind cryptographic keys to the load-timeintegrity state of the system.

Figure 3: Generic TruWallet Architecture

3.4 Mobile TruWallet

To implement our security architecture for mo-bile e-health scenarios, several building blocks formobile environments are required:

prehensive user access control as in typical operatingsystems, including system login and screen lock func-tionality, in order to prevent unauthorized access tothe wallet. However, the details of those mechanismsare out of scope of this paper.

3Of course, it is important that these referencevalues are stored in a secure location, e.g., protectedby security hardware, to avoid manipulations.

• Trusted hardware for mobile platforms whichsupports features to protect cryptographickeys and verify the system integrity;

• a secure hypervisor layer for mobile platformsto provide isolated execution environments forapplications;

• a security kernel with a secure GUI for mo-bile platforms to provide a trusted path be-tween the user and applications, and with se-cure storage for applications;

• a trusted wallet (TruWallet) to handle au-thentication and protect the user’s creden-tials.

In the following, we briefly introduce the firstthree building blocks, before we focus in moredetail on the implementation of a trusted walleton a mobile phone in the next section.

Trusted hardware for mobile platforms.The architecture of TruWallet relies of trustedhardware for performing security critical opera-tions. To instantiate TruWallet architecture on amobile phone, we have to use mobile hardware se-curity extensions instead of a TPM (which is notavailable on current phones). On mobile plat-forms, general-purpose secure hardware such asM-Shield (Azema and Fayad, 2008) and Trust-Zone (Alves and Felton, 2004) is available. Inthis paper, we focus on M-Shield, because thishardware extension is available in some currentmobile phones, including Nokia N900 (which weused for our prototype).

M-Shield provides a small amount of dedi-cated on-chip ROM and RAM as well as one-timeprogrammable memory for device keys which areaccessible only in a special execution mode ofthe main CPU – the Trusted Execution Envi-ronment (TrEE). A secure state machine (SSM)guarantees secure switching between both proces-sor modes, thus the TrEE and normal executionenvironment are isolated from each other. M-Shield enables the TrEE on a device with thefollowing features: (i) isolated secure code execu-tion; (ii) secure boot; (iii) hardware-based securestorage.

Secure hypervisor for mobile devices.Several microkernels for mobile and embed-ded devices have been implemented, for in-stance the commercially available L4 microker-nels OKL4 (Open Kernel Labs, 2010) and PikeOSP4 (Brygier et al., 2009). These microkernelsprovide isolation between user space applications,

just like their counterparts on other platforms(e.g., on PCs). Therefore, they can be used for asecure hypervisor layer for a security kernel onmobile phones. In particular, the seL4 micro-kernel has been formally verified for correctness(Klein et al., 2009), hence taking an importantstep towards building a formally verifiable secu-rity kernel on top of a microkernel.

Security kernel with secure GUI for mobiledevices. The Turaya Trusted Mobile Desktop(Selhorst et al., 2010) implements a security ker-nel with a secure user interface for mobile de-vices. Its TCB consists of a hypervisor layer anda trusted software layer. The hypervisor layer isimplemented on top of an L4 microkernel, whichhas been ported to the Nokia N900 mobile phone.The Trusted Software Layer contains a number ofsecurity services, such as a secure graphical userinterface (called TrustedGUI), a virtual privatenetwork (VPN) client, and a file encryption ser-vice.

4 WALLET PROTOTYPE ONNOKIA N900

In order to demonstrate the feasibility of run-ning a trusted wallet on a mobile phone, we haveimplemented Mobile TruWallet, a mobile versionof trusted wallet, on a Nokia N900 device.

4.1 Mobile TruWallet Architecture

Instead of realizing the full implementation of asecurity kernel, for which we refer to the works of(Brygier et al., 2009; Klein et al., 2009; Selhorstet al., 2010), we have implemented the wallet onMaemo (Maemo, 2010), which is based on Linuxand provides standard operating system processisolation and discretionary access control.

The architecture of Mobile TruWallet we haveimplemented is depicted in Figure 4. As it canbe seen, TruWallet resides on the operating sys-tem side, but also operates on secrets at the sametime, e.g., maintains a TLS channel to the web-server and also performs authentication with theuser passwords. However, our generic architec-ture assumes that TruWallet is isolated from therest of the system. This assumption is reasonableto some extend in the context of existing oper-ating systems for Nokia mobile phones: SymbianOS and Maemo. Their platform security enables,

Figure 4: Mobile TruWallet Architecture

with different degrees, process isolation. Themicrokernel-based Symbian OS provides processexecution isolation and enforces control on inter-process communication via a capability mecha-nism, while Maemo’s security model is based onDiscretionary Access Control (DAC) which en-forces security by process ownership.

We achieved process isolation on Maemo bycreating a Mobile TruWallet process under aunique UserID and defining restrictive accessrights to that UserID. Note that for this proto-type, we rely on the standard Unix/Linux dis-cretionary access control security framework, andthere is always the threat that an administrator(root account) with the super-user access rightsis compromised. However, we implemented thewallet as if it was running on a security kernel.This approach allows us to concentrate on thewallet-specific aspects for the prototype (i.e., per-formance, user interface, compatibility to the mo-bile web browser and web sites, etc.). In a laterstage, the wallet can be easily adapted to a secu-rity kernel system like the L4-based one on N900(Selhorst et al., 2010).

Nokia N900 device is based on M-Shield securehardware. We utilize M-Shield functionality forthe secure boot, and we also implement securestorage functionality on the top of M-Shield.

Only authenticated programs, so-called pro-tected applications (PAs), can be executed withinthe TrEE of M-Shield. However, protected ap-plications have to be authorized, i.e., certified,by the device’s M-Shield stakeholder, most likelythe device manufacturer. As we have not beenable to get the PA certified by the device manu-facturer, we use a different approach: We reusethe general purpose APIs available for M-ShieldTrEE. This approach allows third parties to lever-

age the TrEE. For instance, the On-board Cre-dentials platform (ObC) (Kostiainen et al., 2009)provides the means to develop programs for theTrEE without the involvement of the manufac-turer. In our implementation, we build the securestorage functionality of Mobile TruWallet on topof ObC.

4.2 ObC Architecture

Figure 5 illustrates the ObC architecture. Thecore component of the ObC platform – whichresides in the dedicated RAM and can be exe-cuted in secure environment – is an interpreter.The interpreter provides a virtualized environ-ment where “credential programs”, i.e., scriptsdeveloped by third parties, can be executed. Thecredential programs are written using (a subsetof) Lua scripting language (Lua, 2010) or in as-sembler. When a credential program is executed,the interpreter isolates it from secrets that arestored within the TrEE and from the executionof other credential programs.

The interpreter makes use of a Crypto Li-brary which provides an interface for commonlyused cryptographic primitives. It provides a seal-ing/unsealing function for ObC programs, whichcan be used to protect secret data stored per-sistently outside the secure environment. Sealeddata is encrypted with a key which is protected bythe TrEE, and the ObC platform controls the us-age of this key. A device-specific symmetric keycalled ObC platform key (OPK) is used for thesealing/unsealing functionality.

Credential Manager is a mediator betweenOS side applications and components that residewithin the TrEE. It provides an API for third-party developed applications. Using the API theapplications can execute credential programs, andcreate and use new asymmetric keys. The cre-dential manager maintains a database, in whichcredentials and credential programs are stored ina cryptographically sealed way.

A more detailed description of the ObC archi-tecture can be found in (Kostiainen et al., 2009;Kostiainen et al., 2010).

4.3 Implementation

In our prototype, the wallet is implemented in theC programming language, contains about 2600lines of code, and runs as separate process with aunique UserID. For the SSL/TLS proxy, we useParos (Paros, 2010), which is an open-source im-

Figure 5: On-board Credential architecture

plementation in Java, and it executes as a processwith the same UserID as the wallet. We definerestrictive access rights on this UserID so thatother processes cannot access the data or code ofthe wallet.

Accessing Health Records. The wallet usesthe libxml library to parse web sites and webforms in order to search for password fields.Whenever it finds such fields, these forms areput into a cache and are disabled before they areshown in the web browser. This prevents the userfrom accidentally typing passwords into a poten-tially malicious or faked web site. Instead usersjust provide their user name and simply click thesubmit or login button in the mobile web browser.

Hence, when doctors want to access a healthrecord from the e-health server, they simply openthe EHR viewer browser on the phone and clickthe login button. The wallet replaces then au-tomatically the disabled password field with theactual password of the doctor’s account on the e-health server. This process runs transparently, sothe doctor just sees the EHR viewer application,and when the login is completed he can access thehealth records on the server.

Registration. Before doctors can use the wal-let to login to websites like the e-health server,they have to register their account in the walleton the phone. Therefore, the wallet also looks forregistration forms. When the user tries to accessa website with the browser for the first time, thewallet asks the user for an existing password orit can create a new one. Figure 6 shows a corre-sponding screenshot where the wallet dialog popsup after the user opened a website (with a loginfield) in the browser for the first time.

Once the password has been provided (or

Figure 6: Screenshot of Mobile TruWallet when reg-istering an existing password

newly created), the wallet stores the credentialsin a specific file. During runtime, the access tothis file is only granted to the UserID of the wal-let. Hence, other programs cannot read or modifythe stored credentials. When the device is goingto be shut off, this file is sealed using the ObCplatform as mentioned before.

Figure 7: Screenshot of Mobile TruWallet showingstored passwords

Users can view a list of the stored accounts inwallet, as the screenshot in Figure 7 shows. Forexample, it shows a web-based e-mail account and“ehealth.local”, which is our local EHR serverin our prototype. We realized the user interfacebased on the Hildon GUI framework (Hildon Ap-plication Framework, 2010) on Maemo.

Interoperability. We have tested our walletimplementation with several public websites, likeweb e-mail services, eBay, Amazon, etc. Regis-tration and login work transparently and with-out noticeable performance overhead for the user.Hence, it should be easy to integrate web-based e-health services on our platform. Special-purposeEHR viewers or other medical applications can besupported as well as long as they use SSL/TLSand web-based login procedures. Other authen-

tication protocols could also be integrated, butmay require some effort to adapt the wallet.

5 CONCLUSION AND FUTUREWORK

Mobile access to electronic medical data is anemerging application scenario with strong secu-rity and privacy requirements that is rapidly gain-ing practical importance. Existing systems sufferfrom a lack of appropriate protection for security-and privacy-critical data and applications. More-over, standard operating systems do not use ex-isting hardware security features of mobile plat-forms to their full extent.

To enable secure mobile access to electronichealth records containing privacy-sensitive data,we propose an e-health security architecturewhich protects the user’s authentication creden-tials as well as the sensitive medical data. Our ar-chitecture is based on commonly available trustedhardware components, a security kernel, and atrusted wallet. In this paper, we introduce ourcomprehensive security architecture, discuss se-curity building blocks on mobile phones, andpresent our implementation of Mobile TruWalleton a commodity smartphone.

Since our Mobile TruWallet prototype demon-strates the feasibility of the architecture on mo-bile phones, future work includes the integrationof all security building blocks (i.e., the use ofhardware security features, a security kernel con-sisting of a secure hypervisor and a trusted soft-ware layer, and the Mobile TruWallet authentica-tion solution) into one system.

ACKNOWLEDGMENTS

This work was partially funded by the Germanfederal state North Rhine-Westphalia and sup-ported by the European Regional DevelopmentFund under the project RUBTrust/MediTrust.Further, the author Alexandra Dmitrienko wassupported by the Erasmus Mundus External Co-operation Window Programme of the EuropeanUnion.

REFERENCES

Aggarwal, M. and Vennon, T. (2010). Study ofBlackBerry proof-of-concept malicious applica-

tions. Technical Report White paper, SMobileGlobal Threat Center.

Agreiter, B., Alam, M., Hafner, M., Seifert, J. P., andZhang, X. (2007). Model driven configuration ofsecure operating systems for mobile applicationsin healthcare. In Proceedings of the 1st Inter-national Workshop on Mode-Based TrustworthyHealth Information Systems.

Alves, T. and Felton, D. (2004). TrustZone: Inte-grated hardware and software security. Techni-cal report, ARM.

Anderson, J. (1972). Computer security technologyplanning study. Technical Report ESD-TR-73-51, AFSC, Hanscom AFB, Bedford, MA. AD-758 206, ESD/AFSC.

Android Open Source Project (2010). Project web-site. http://www.android.com.

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

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

mobile security technology: making wire-less secure. Texas Instruments White Pa-per. http://focus.ti.com/pdfs/wtbu/ti_mshield_whitepaper.pdf.

Benelli, G. and Pozzebon, A. (2010). Near fieldcommunication and health: Turning a mobilephone into an interactive multipurpose assistantin healthcare scenarios. In Biomedical Engi-neering Systems and Technologies, InternationalJoint Conference, BIOSTEC 2009, Revised Se-lected Papers, volume 52 of Communications inComputer and Information Science, pages 356–368. Springer.

Brygier, J., Fuchsen, R., and Blasum, H. (2009).PikeOS: Safe and secure virtualization in a sep-aration microkernel. Technical report, Sysgo.

EMSCB Project Consortium (2005–2008). The Eu-ropean Multilaterally Secure Computing Base(EMSCB) project. http://www.emscb.org.

Fraim, L. (1983). SCOMP: A solution to the mul-tilevel security problem. In IEEE Computer,pages 26–34.

Gajek, S., Lohr, H., Sadeghi, A.-R., and Winandy, M.(2009). TruWallet: Trustworthy and migratablewallet-based web authentication. In The 2009ACM Workshop on Scalable Trusted Computing(STC’09), pages 19–28. ACM.

Google Android (2010). Security and permis-sions. 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 BiomedicalEngineering Systems and Technologies, Interna-tional Joint Conference, BIOSTEC 2008, Re-vised Selected Papers, volume 25 of Communi-cations in Computer and Information Science,pages 377–389. Springer.

Hildon Application Framework (2010). Project web-site. http://live.gnome.org/Hildon.

Iozzo, V. and Weinmann, R.-P. (2010). Ralf-Philipp Weinmann & Vincenzo Iozzo ownthe iPhone at PWN2OWN. http://blog.zynamics.com/2010/03/24/ralf-philipp-weinmann-vincenzo-iozzo-own-the-iphone-at-pwn2own/.

Karger, P. A., Zurko, M. E., Bonin, D. W., Mason,A. H., and Kahn, C. E. (1990). A VMM secu-rity kernel for the VAX architecture. In Pro-ceedings of the IEEE Symposium on Research inSecurity and Privacy, pages 2–19, Oakland, CA.IEEE Computer Society, Technical Committeeon Security and Privacy, IEEE Computer Soci-ety Press.

Klein, G., Elphinstone, K., Heiser, G., Andronick,J., Cock, D., Derrin, P., Elkaduwe, D., Engel-hardt, K., Kolanski, R., Norrish, M., Sewell, T.,Tuch, H., and Winwood, S. (2009). seL4: For-mal verification of an OS kernel. In Proceedingsof the 22nd ACM Symposium on Operating Sys-tems Principles, Big Sky, MT, USA. ACM Press.To appear.

Kostiainen, K., Dmitrienko, A., Ekberg, J.-E.,Sadeghi, A.-R., and Asokan, N. (2010). Key at-testation from trusted execution environments.In TRUST 2010: Proceedings of the 3rd Inter-national Conference on Trust and TrustworthyComputing, pages 30–46. Springer.

Kostiainen, K., Ekberg, J.-E., Asokan, N., andRantala, A. (2009). On-board credentials withopen provisioning. In ASIACCS ’09: Proceed-ings of the 4th International Symposium on In-formation, Computer, and Communications Se-curity, pages 104–115. ACM.

Liedtke, J. (1995). On microkernel construction. InProceedings of the 15th ACM Symposium on Op-erating Systems Principles (SOSP’95), CopperMountain Resort, Colorado. Appeared as ACMOperating Systems Review 29.5.

Loscocco, P. and Smalley, S. (2001). Integratingflexible support for security policies into theLinux operating system. In Proceedings of theFREENIX Track: 2001 USENIX Annual Tech-nical Conference, pages 29–42. USENIX Associ-ation.

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., Stuble, C., Feldmann, F., and Gnaida,U. (2010). Towards a trusted mobile desktop.In Trust and Trustworthy Computing (TRUST2010), volume 6101 of LNCS, pages 78–94.Springer.

Sunyaev, A., Leimeister, J. M., and Krcmar, H.(2010). Open security issues in german health-care telematics. In HEALTHINF 2010 - Pro-ceedings of the 3rd International Conference onHealth Informatics, pages 187–194. INSTICC.

Symbian Foundation Community (2010). Projectwebsite. http://www.symbian.org.

The OpenTC Project Consortium (2005–2009). TheOpen Trusted Computing (OpenTC) project.http://www.opentc.net.

Tiago Alves, D. F. (2004). TrustZone: IntegratedHardware and Software Security. http://www.arm.com/pdfs/TZ%20Whitepaper.pdf.

Trusted Computing Group (2009). TPM Main Speci-fication. http://www.trustedcomputinggroup.org.

Vennon, T. (2010). Android malware. A study ofknown and potential malware threats. Techni-cal Report White paper, SMobile Global ThreatCenter.

Vouyioukas, D., Kambourakis, G., Maglogiannis, I.,Rouskas, A., Kolias, C., and Gritzalis, S. (2008).Enabling the provision of secure web based m-health services utilizing xml based security mod-els. Security and Communication Networks,1(5):375–388.