Security Specification and Implementation for Mobile e-Health Services

Security Specification and Implementation for Mobile e-Health Services Ramon Martí, Jaime Delgado, Xavier Perramon Universitat Pompeu Fabra (UPF), Barcelona, Spain {ramon.marti, jaime.delgado, xavier.perramon}@upf.edu

Abstract Different IT applications require different Security Services. We have been working in the area of ehealth applications in a mobile environment, and we have needed to integrate specific Security Services. The paper presents those Security Services for Mobile e-Health Services and how we have implemented them. First, the different security threats specially oriented to the e-health applications are described, like patients’ data eavesdropping and manipulation. Afterwards, the different security mechanisms to address these specific security threats are described, e.g. data confidentiality and integrity, together with the restrictions of dynamic IP addresses. Following, the specification of security services requirements and the implementation possibilities to address them in the Mobile e-Health Services are described. As an example of security services integrated into an ehealth system, the paper includes the description of the mobile e-health service MobiHealth, an application developed under the MobiHealth Project, co-funded by the European Commission (IST-200136006), focused on the security services added to it.

In a digital society, one of the services that will contribute to improve the citizens’ quality of life is electronic healthcare, or e-health. A further step is the use of mobile communication technologies to provide the so-called m-health service: mobile e-health service. Depending on the severity of their diseases, patients will not need to stay at hospitals, but they will be able to lead a normal life while their medical data are being monitored by healthcare professionals. In this context, data protection and security is a key aspect in order to increase users’ acceptance of these new technologies, given the highly sensitive nature of

2. A Mobile e-Health System Architecture Mobile e-Health Systems provide medical staff (doctors and nurses at a hospital or healthcare centre) with real-time remote access to patients’ health data. This section gives an overview of an architecture for Mobile e-Health Services, including the description of all the components and the communications between them. Figure 1 presents the components of this mobile e-health architecture and the communication interactions between them, which are described in the following subsections. Wired/ Wireless Sens or Actu ator

Mobile Telephony

Mobile Communic. Operator

Front-End

1. Introduction

personal health data to be transmitted to and from mobile terminals. We present in this paper an architecture for an mhealth system, based on the concept of a BAN (Body Area Network) linked via mobile telephony with a hospital or a healthcare centre. Then we focus on the security services that must be provided by this mhealth system and how to implement them.

mobile terminal

Internet / LAN

e-Health Server

End-User Application Internet / LAN

Body Area Network

Fig. 1. Overview of a mobile e-health service

2.1. Mobile e-Health Application Components According to this architecture, an m-health system consists of a BAN (Body Area Network) linked to a hospital or healthcare centre via mobile telephony. The concept of Body Area Network is a specialization of Personal Area Network that has recently been

introduced in the literature [1][2][3]. For our purposes, the BAN is a network of sensors (e.g. a pulse meter or a glucose meter) and/or actuators (e.g. an insulin pump) attached to the patient’s body, and interconnected in a star topology to a hub or concentrator, where all data are collected. This interconnection can be through wires, but also through short-range wireless techniques, such as IEEE 802.15.1/Bluetooth or the more recently developed IEEE 802.15.4/ZigBee [4]. The hub is a device directly connected to a mobile communications terminal, typically a cellular phone, through which data can be transmitted virtually anywhere using Internet protocols, and in particular to the hospital or healthcare centre where the patient is being monitored. In this architecture, a mobile e-health service is composed of the following components: - Sensor: A device, such as a photoelectric cell, that receives and responds to a signal or stimulus. Sensors in the BAN can measure pulse, blood pressure, oxygen level, glucose level, etc. - Actuator: A device responsible for actuating a mechanical device, such as one connected to a computer by a sensor link. In an e-health system, an actuator can be an insulin pump for patients with diabetes. - Front-End: Hub for all the sensors and actuators in the BAN. It records all the data from all the sensors and actuators, and can send them to the mobile terminal. - Mobile terminal: A Mobile Phone or, alternatively, some device with mobile communication capabilities, e.g. a PDA. - Body Area Network (BAN): Patients network, composed of Sensors, Actuators, a Front-End and a Mobile terminal. - Mobile communications Operator: Network operator with wireless telephony access to Internet. - e-Health Server (e-HS): Main server, where medical data is received and distributed. It can be installed in the mobile communications service provider, or at the Hospital. - End-User Application (EUA): Computers in the Hospital (or Healthcare centre), used to access the information from the Sensors and Actuators and to send new configuration parameters to the BAN, through the access to the e-HS. It can be either a main server in the Hospital, that accesses the e-HS data and stores them in the already existing patients database, or authorized employees user computers, that access

the e-HS stored information, both from inside or outside the Hospital.

2.2. Mobile Communication

e-Health

Application

Different communication interactions exist in a mobile e-health service. These communications can be done in two ways: from the BAN to the End-User Application, but also from the End-User Application to the BAN. The following hop-to-hop interactions are considered: - Sensor ↔ Front-End: Wired communication, or wireless e.g. Bluetooth. - Actuator ↔ Front-End: Wired communication, or wireless e.g. Bluetooth. - Front-End ↔ Mobile terminal: Wired communication, or wireless e.g. Bluetooth. - Mobile terminal ↔ Network Operator: TCP/IP communication through mobile telephony. - Network Operator ↔ e-Health Server: TCP/IP communication. This communication is through local LAN, when the e-HS is in the same location as the Network Operator, or through Internet when it is in a different location. - e-Health Server ↔ End-User Application: Remote access of the client to the e-HS data. The access is through application layer protocol and application data, and the communication through TCP/IP in Internet or LAN. The communication path between the Mobile terminal and the e-Health Server is used to transport application data through application layer protocols.

3. Security Threats in e-Health Mobile Personal Area Network Communications A mobile e-health service, like all information technology systems, is subject to different kinds of security threats. We will not consider here threats of environmental origin (fire, etc.) or accidental ones (user errors, software malfunction, etc.). The deliberate threats that we will consider can be categorized into 4 groups: - threats to confidentiality, - threats to integrity, - threats to authenticity (including nonrepudiation), - threats to system performance (availability, reliability and accountability).

3.1. Threats to Confidentiality By exploiting threats to confidentiality an attacker may gain access to private information. The attack consists in eavesdropping the communication links, without interfering with the transmissions, or in inspecting data stored in the system. The main type of information that can be maliciously accessed in a mobile e-health service is patient’s health data, either while generated and transmitted by the sensors or when stored in the servers. The following components of a mobile e-health service communications architecture may be subject to confidentiality threats: - Communication between sensor or actuator and front-end, especially when a mobile link is used. - Communication between front-end and mobile terminal. - Communication between mobile terminal and the network operator. - Communication within the operator’s network. - Communication between the network operator and e-Health Server. - Data storage in the e-Health Server (or in other components where sensitive data may be temporarily or permanently stored). - Communication between e-Health Server and End-user application. The safeguards to protect against these threats are based on symmetric cryptography: encrypted communication protocols at the various levels of the communication (Bluetooth encrypted link, HTTPS, etc.) and encrypted storage.

3.2. Threats to Integrity By exploiting threats to integrity an attacker may alter the information exchanges within a mobile ehealth service. The attack consists in interfering with the transmissions, so that the recipient gets data which are different from those sent by the originator, or in modifying data stored in the system. The type of information that is subject to these threats is the same as in the threats to confidentiality. Even if the information is protected against eavesdropping by means of encryption, the attacker may blindly modify this encrypted information. The results that the recipient will obtain when decrypting these data are unknown to the attacker, but it is certain that they will be different from the original data.

The components of a mobile e-health service architecture that may be subject to integrity threats are the same as for confidentiality threats. The safeguards to protect against threats to integrity are based on redundancy codes (Message Integrity Codes or MIC) added to the data.

3.3. Threats to Authenticity By exploiting threats to authenticity an attacker may counterfeit false data and deceive the recipient into believing that they come from a different originator (which the recipient takes as the authentic originator). The attack consists in forging the part of the data where the originator is identified (usually in the headers). These threats apply both to entity identity and to data origin. The following components of the mobile e-health service architecture may be subject to authenticity threats: - Sensors or actuators. - Front-end. - Mobile terminal. - e-Health Server. - End-user application. The safeguards to protect against threats to authenticity are based on shared secrets (Message Authenticity Codes or MAC) or, if authentication before a third party is needed, on asymmetric cryptography. Repudiation is a variant of this type of attacks that consists in denying authorship or the contents of data previously sent. The safeguards applied to Authenticity also protect against Repudiation.

3.4. Threats to System Performance The following aspects of system performance are in general subject to these threats: - Availability: system accessibility and usability upon demand by an authorized entity. - Reliability: consistent behavior and results as intended. - Accountability: traceability of actions carried out by an entity. The general types of attacks that exploit these threats are denial of service attacks.

Safeguards to protect against these threats exist for certain specific attacks. In general, however, a solution may be difficult or costly to deploy.

4. Security Mechanisms Mobile e-Health Services

Services

for

Different security mechanisms are used to provide the security services that are required for data: Confidentiality, Integrity, Authentication, Non Repudiation and Access control. Those security mechanisms can be added to the different communication layers, providing different security features depending on the layer where security is included. In a mobile e-health service, communications security includes protection of communications between the components of the application, in all the communication layers of the stack: - Data link layer: Bluetooth security, Zigbee security, GPRS/UMTS security, etc. - Network layer: IPsec [6], etc. - Transport layer: SSL/TLS [7][8], HTTPS [9] etc. - Application layer: Data encryption, signature, etc.

4.1. Data Link Layer Security Security in the Data Link Layer provides hop-tohop protection (encryption and authentication), with no user or application authentication. Security provided by Bluetooth, Zigbee or the public mobile telephony network, in each case, is an example of Data Link Layer protection.

4.2. Network Layer Security Security in the Network Layer provides node-tonode protection (encryption and authentication), with no user or application authentication. The node-tonode protection in the network layer can be hop-tohop protection or end-to-end protection. For the Network Layer protection, IPsec is an example, which can be used between systems using static IP addresses.

4.3. Transport Layer Security Security in the Transport Layer provides an end-toend protection. It provides application-to-application protection, and it can also include user authentication. SSL/TLS or HTTPS are examples of Transport Layer security.

4.4. Application Layer Security Security in the Application Layer provides application to application and application-user to application-user protection, including user (sender and receiver) authentication. Application Layer security is provided through the encryption (symmetric or asymmetric) or/and signature of the data sent through the communications stack. SMIME or user-invoked cryptographic functions (e.g. OpenSSL) are examples of tools that can be used to encrypt and sign data for the Application Layer security.

5. Dynamic IP Address Restrictions Before entering into the requirements for mobile ehealth service security, some issues related to Dynamic IP address of some of the components of the system have to be taken into account for the implementation.

5.1. Dynamic IP Address Restrictions in Mobile e-Health Service Components One important issue in the final implementation of mobile e-health service security, apart from the security requirements, is the use of Dynamic IP address for two of the components of the application: - Mobile terminal: The address is provided dynamically by the network operator. - End-User Application: If it is the Hospital server, it will probably have static IP address, but if it is a Hospital employee accessing from outside the hospital it may have dynamic IP address, provided by the ISP.

5.2. Dynamic IP Address Restrictions in Mobile e-Health Protocols The use of dynamic IP address has different implications in the security protocols, which must be taken into account in the specification of the security for a mobile e-health service. - IPsec provides communications security with data encryption and node authentication, based on node addresses. IPsec is not suitable for providing communications security from components with dynamic IP address. Then, IPsec is not suitable to provide security to the mobile terminal ↔ e-HS communication, or to the e-HS ↔ EUA communication.

- SSL and HTTPS provide data transport-level security to communications requiring data encryption and user authentication, based on server node address. SSL and HTTPS are suitable for providing communications security from components with dynamic IP address. Then, it is suitable for mobile terminal ↔ e-HS or e-HS ↔ EUA security. - Current mobile communication technologies and Bluetooth are suitable for communications requiring data encryption and terminal authentication.

6. Mobile e-Health Services Security Requirements Specification and Implementation In a mobile e-health service different security requirements related to the Architecture, the System components and the Communications have to be taken into account [5]. The following general security services are defined to avoid security threats: Confidentiality, Integrity, Authentication, Non-repudiation, Access control, Data storage security and Time stamping. The security services requirements to be addressed by a mobile ehealth service, and how they can be implemented are presented in the following subsections.

6.1. Confidentiality Confidentiality protects data to be (almost) impossible to interpret for a non-authorized user during communication or storage. These are the confidentiality requirements to be addressed by a mobile e-health service: Data transmitted between the BAN sensors/actuators and the mobile terminal must not be read by unauthorized persons. For those sensors connected to the mobile terminal through mobile Bluetooth, the encryption methods built into the Bluetooth communications allow for the fulfillment of this requirement. For those sensors with wired connection to the terminal, for the purposes of the BAN it can be assumed that this requirement is already satisfied. Data transmitted externally to or from the BAN must not be read by unauthorized persons. This requirement can be satisfied in a mobile ehealth service Security by the use of Transport layer security (like SSL/TLS) for the external communications in the BAN. With the secure

transport protocol, both ends of the communication, client and server, agree on an encryption key to be used in the packets they will exchange. In the negotiation of this encryption key, public key cryptography is used, so that an intruder will be unable to discover which key is being used for encrypting the packets. The public key cryptography techniques used with Transport layer security usually require that at least the server authenticates itself by means of an X.509 certificate, issued by a Certification Authority (CA) trusted by the client. In a mobile e-health service Security Architecture, the mobile terminal acts as a client. The communication to the server makes use of different links (mobile telephony network, e-HS, Internet, etc.), and each of these may provide its own security mechanisms at the data link layer. On top of these link layer security mechanisms, the use of Transport layer security protects the communication all the way from the BAN to the server. Data transmitted externally to or from the e-Health Server must not be read by unauthorized persons. With regard to the link between the e-Health Server and the final client at the hospital, the Security Architecture can also make use of Transport layer security (like SSL/TLS). The same server certificate can be used in this case. Therefore the confidentiality service is also provided for this link. Traffic characteristics of the transmissions to or from the BAN (how many data are sent, how often, from where to where, etc.) must be concealed so that non-authorized observers cannot infer information about the patient. Hiding traffic characteristics or, as it is usually known, “traffic confidentiality”, can be provided to a certain extent by the Transport layer security (like SSL/TLS). Source and destination addresses cannot be concealed at the transport layer (it would be necessary to use a secure network layer protocol like IPsec), but length and frequency of packets can be concealed by periodically sending packets with “dummy” information, that will be encrypted and will not be distinguishable from real packets to an intruder.

6.2. Integrity Integrity protects data against non-authorized modification, insertion, reordering or destruction

during communication or storage. The following are the integrity requirements to be addressed: Data transmitted between the BAN sensors/actuators and the mobile terminal must not be modified by unauthorized persons. Data transmitted externally to or from the BAN must not be modified by unauthorized persons. Data transmitted externally to or from the e-Health Server must not be modified by unauthorized persons. For integrity, the same considerations as for Confidentiality apply, since the security protocols provide Confidentiality and Integrity at the same time.

6.3. Authentication Authentication provides the way to corroborate identity of the entities, sender and receiver, implied in the data creation or communication (entity authentication). It can also provide authentication of the data (data authentication). The following are the authentication requirements to be addressed: It must be possible to verify that data collected from the sensors were genuinely produced by the sensors and not forged nor tampered with. For those sensors connected to the mobile terminal via Bluetooth, the authentication methods built into the Bluetooth communications allow for the fulfillment of this requirement. For sensors with wired connection to the mobile terminal, for the purposes of a BAN it can be assumed that this requirement is already satisfied. It must be possible to verify that data transmitted from the BAN were sent by the authentic BAN worn by the authentic patient. In the Transport layer security protocols (like SSL/TLS) it is usually the server who authenticates itself to the client, but it is also possible to use client authentication. For this requirement, the X.509 certificate assigned to each patient's mobile terminal can be used for the terminal authentication in the initial Transport layer security negotiation. Additional client authentication can be optional, since mobile terminal authentication can be enough in most of the cases. Client authentication can also be implemented through the use of a user X.509 certificate (instead of or in addition to the BAN certificate) to encrypt the data, with private key access restricted by the use of a password or PIN.

It must be possible to verify that data received by the BAN from the e-Health Server were sent by the authentic originator. This requirement is satisfied by Transport layer security protocols (like SSL/TLS), where the server authenticates itself during the connection negotiation phase. This is closely bound to requirement above: authentication and confidentiality are achieved by the agreement of an encryption key using public key cryptography techniques. It must be possible to verify that data transmitted from the End-User Application were sent by an allowed user. Users must authenticate themselves to the e-HS. An X.509 certificate mechanism through a Transport layer security protocol can be enough. It must be possible to verify that data received by the End-User Application from the e-Health Server were sent by the authentic originator. From the point of view of the EUA, authentication is carried forward by the e-HS. Now, the e-HS must authenticate itself before the EUA through a secure transport protocol (like SSL/TLS), possibly using the same server certificate. The EUA then trusts the e-HS, which must have authenticated satisfactorily the mobile terminal.

6.4. Non-Repudiation Non-Repudiation protects against unilateral or mutual data repudiation. The following is the nonrepudiation requirement to be addressed: It must not be possible for a data sender to repudiate the transmission of these data. By satisfying the Authentication requirements, the main non-repudiation requirements are also satisfied.

6.5. Access Control Access control protects the system and resources against unauthorized use. The following are the access control requirements to be addressed: It must not be possible for unauthorized users to access the BAN. It must not be possible for unauthorized users to access the e-Health Server.

An access control mechanism must be used by authorized Patients and Nurses to access the BAN and authorized Nurses and Doctors to access the e-HS. This mechanism can be, e.g., through an X.509 certificate in the Secure transport layer, or even through a simple password or PIN.

6.6. Data Storage Security Data storage security protects the stored data against unauthorized use. Depending on the security level desired for every type of application, it may be necessary to fulfill some of the following requirements: Data collected from the sensors must never be stored locally in the BAN. The Security Architecture allows for direct data transmission from the BAN to the server. If this is not a security requirement for a particular scenario, data can optionally be stored in the BAN for subsequent transmission. Therefore, the Security Architecture supports both options. Data collected from the sensors must not be stored locally in the BAN, except for temporary storage for later transmission while network connection is off. This service may be required for mobile telephony out-of-coverage temporary situations. Then it is necessary to use secure temporary storage: once the data are transmitted, all track must be completely and securely removed from the BAN. This requirement must be addressed by the BAN Operating System, since it is not related to communications security.

The following is the time stamping requirement to be addressed: It must be possible to unforgeably determine at what time data were originated. If there is a need to associate a time with each piece of data, authenticated timestamps have to be included in the exchanged packets.

7. Example of Security Services in a Mobile e-Health Application: MobiHealth This section describes the MobiHealth [10] system and the security services in it, as an example of the security services of a mobile e-health service. It includes the description of its architecture, its components and the communications between them. The mobile e-health service MobiHealth is an application developed under the MobiHealth Project, co-funded by the European Commission (IST-200136006). The main goal of this project is the development of an m-health service based on new generation mobile telephony: the so-called 2.5G (GPRS: General Packet Radio Service) and the forthcoming 3G (UMTS: Universal Mobile Telecommunications System).

7.1. MobiHealth Architecture Figure 2 presents the main components of the MobiHealth system and the communication interactions between them, which are described in the following subsections. GPRS|UMTS BT|ZB

A log of data transmitted externally to or from the BAN must be kept locally. This requirement must be satisfied by a module of the secure communications, integrated with the BAN Operating System.

6.7. Time Stamping

Sens or Actu ator

GPRS / UMTS Operator

Front-End

A log of data collected from the sensors must be stored in the BAN. This is the opposite of the previous two requirements. The security of this storage is also a matter of the BAN Operating System as it is not related to communications security.

MBU

Back-End System Wireless Service Broker

Surrogate Host

Internet / LAN

BANData Repository

End-User Application

Internet / LAN

Body Area Network

Fig. 2. Overview of the MobiHealth System

7.2. MobiHealth Components The MobiHealth architecture is largely based on the m-health architecture presented in the previous sections, with some adaptations: the mobile terminal is called the Mobile Base Unit (MBU) in MobiHealth, and a new component is introduced, the Wireless

Service Broker (WSB), as detailed below. These are the specific components of the MobiHealth system: - Mobile Base Unit (MBU): It corresponds to the Mobile Terminal. - Back-End System (BEsys): It corresponds the eHealth Server. It is a system composed of a Wireless Service Broker, a Surrogate Host and a BANData Repository. BEsys are installed in some GPRS/UMTS service providers, and some Hospitals. - Wireless Service Broker (WSB): Authenticates and authorizes mobile terminals. - Surrogate Host (SH): Main server, where mobile sensor and actuator objects are “surrogated” inside the wired Internet, and where medical data is received. - BANData Repository (BDR): A process that acts as a client to the Surrogate Host (it is a Jini service user of the mobile terminal service provider). In addition, the BDR writes the medical data (i.e. measurements) to persistent storage.

7.3. MobiHealth Communication The MobiHealth communication is also based on the m-health architecture presented previously, and taking into account the adaptation in the architecture. Different communication interactions exist in MobiHealth. These communications can be done in two ways: from the BAN to the EUA, but also from the EUA to the BAN. The communication path between the MBU and the BESys is used to transport application data through application layer protocols.

7.4. MobiHealth Summary

Security

Implementation

Taking into account the different issues related to the security and to the MobiHealth requirements and architecture, the following security options were integrated. - Bluetooth | Zigbee security for encrypted and authenticated data transmission between the FrontEnd and the MBU. - HTTPS with user and server X.509 certificates for encrypted and authenticated data transmission between the MBU and the WSB. - HTTPS with user and server X.509 certificates for encrypted and authenticated data transmission between the WSB and the SH, if they are on different systems. - RMI (Remote Method Invocation) security (SSL|IPsec) for the BDR access to the SH data, when both are in different systems.

- HTTPS security for the EUA access to the BDR data. - No data storage in the “disk”, but some data storage for buffering, for the Front-End, MBU, GPRS/UMTS Operator, WSB and EUA (for employees computers). - Secure data storage, with confidentiality and user access authentication, for the BDR and EUA (for Hospital Workstation with patients Database).

7.5. Advantages and Disadvantages The Security in the MobiHealth system presents the following advantages: - Use of standard user-oriented security mechanisms. - No use of IPsec host-oriented security. - All communications and data from the mobile terminal to the Surrogate Host are secured through authentication and encryption, independently of the underlying network. The main disadvantage is the following: - Since security services are added, there is an increase in the traffic volume, which may represent a penalty in system performance. However, according to measurements that we have carried out, the decrease in throughput is relatively small (around 6%).

8. Conclusions This paper presents the security services required for Mobile e-Health Services. The introduction of security in these applications will enhance the quality of the service in the form of increased trust and acceptance from the users of m-health services, which will add to the social and economical advantages of mobile healthcare for an important number of citizens. All potential users of the healthcare system, i.e. every individual, can benefit from the improvement in quality of life that m-health represents. The MobiHealth project has also been presented as an example. The main technical objective of this project has been to prove the feasibility and the advantages of using 2.5G-3G mobile telephony in a specific area of application, namely m-health. But it also has other side benefits, one of which has been the implementation of the security services that we have presented in this paper, to enhance the quality of the service.

9. References [1] Thomas Zimmerman. “Personal area networks (PAN): Near-field intra-body communication”. IBM Systems Journal, 35:609-618, 1996. [2] Val Jones, Richard Bults, Dimitri Konstantas, Pieter AM Vierhout. “Healthcare PANs: Personal Area Networks for trauma care and home care”. Fourth International Symposium on Mobile Personal Multimedia Communications (WPMC), Aalborg, Denmark, 2001.

[5] Ramon Martí, Jaime Delgado. “Security in a Wireless Mobile Health Care System”. MobEA (Emerging Applications for Wireless and Mobile Access) Workshop collocated with WWW2003 conference, Budapest, Hungary, 2003 (http://www.research.att.com/~rjana/Marti-Delgado.pdf) [6] RFC 2401, “Security Architecture for the Internet Protocol” S. Kent, R. Atkinson, November 1998. [7] SSL3, “The SSL 3.0 Protocol”, A. Frier, P. Karlton, and P. Kocher, Netscape Communications Corp., November 18, 1996.

[3] Karen van Dam, Steve Pitchers, Mike Barnard. “From PAN to BAN: Why Body Area Networks?” Proceedings of the Mobile World Research Forum (WWRF) Second Meeting, Helsinki, Finland, 2001.

[8] RFC2246, “The TLS Protocol Version 1.0”. T. Dierks, C. Allen. January 1999.

[4] IEEE mobile standards web http://standards.ieee.org/mobile/overview.html#802.15

[10] MobiHealth website: http://www.mobihealth.org/

page:

[9] RFC 2818, “HTTP Over TLS”, Rescorla, E., May 2000.