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 e-health
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 e-health 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-2001-36006), focused on the security
services added to it.
1. Introduction
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
personal health data to be transmitted to and from
mobile terminals.
Proceedings of the 2004 IEEE International Conference on e-Technology, e-Commerce and e-Service (EEE’04)
0-7695-2073-1/04 $20.00 © 2004 IEEE
We present in this paper an architecture for an m-
health 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 m-health
system and how to implement them.
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.
Mobile
Telephony
Wired/
Wireless
Sens
Mobile
Front-End
or e-Health End-User
Communic.
Server Application
Actu Operator
ator
Internet /
mobile
Internet /
LAN
LAN
terminal
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 e-Health Application
Communication
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
Proceedings of the 2004 IEEE International Conference on e-Technology, e-Commerce and e-Service (EEE’04)
0-7695-2073-1/04 $20.00 © 2004 IEEE
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 non-repudiation),
- 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 e-health
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).
Proceedings of the 2004 IEEE International Conference on e-Technology, e-Commerce and e-Service (EEE’04)
0-7695-2073-1/04 $20.00 © 2004 IEEE
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 Services for Mobile
e-Health Services
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-to-hop
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-to-node
protection (encryption and authentication), with no user
or application authentication. The node-to-node
protection in the network layer can be hop-to-hop
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-to-
end 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 e-
health service security, some issues related to Dynamic
Proceedings of the 2004 IEEE International Conference on e-Technology, e-Commerce and e-Service (EEE’04)
0-7695-2073-1/04 $20.00 © 2004 IEEE
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 e-
health 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 e-health
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.
Proceedings of the 2004 IEEE International Conference on e-Technology, e-Commerce and e-Service (EEE’04)
0-7695-2073-1/04 $20.00 © 2004 IEEE
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,
Proceedings of the 2004 IEEE International Conference on e-Technology, e-Commerce and e-Service (EEE’04)
0-7695-2073-1/04 $20.00 © 2004 IEEE
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 non-repudiation
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 BT|ZB
GPRS|UMTS Back-End
System

securely removed from the BAN. This requirement must Sens

GPRS / Wireless

Front-End
Surrogate BANData
be addressed by the BAN Operating System, since it is or

Actu
UMTS
Operator
Service
Broker
Host Repository
End-User
Application

not related to communications security. ator

Internet /
Internet /
LAN
LAN
MBU

A log of data collected from the sensors must be

stored in the BAN. Body Area
Network

This is the opposite of the previous two requirements.

Fig. 2. Overview of the MobiHealth System
The security of this storage is also a matter of the BAN
Operating System as it is not related to communications
security.
7.2. MobiHealth Components

The MobiHealth architecture is largely based on the

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
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-2001-36006). 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
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 e-
Health 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.

Figure 2 presents the main components of the 7.4. MobiHealth Security Implementation
MobiHealth system and the communication interactions Summary
between them, which are described in the following
subsections. Taking into account the different issues related to the
security and to the MobiHealth requirements and

Proceedings of the 2004 IEEE International Conference on e-Technology, e-Commerce and e-Service (EEE’04)
0-7695-2073-1/04 $20.00 © 2004 IEEE
 architecture, the following security options were
integrated.
- Bluetooth | Zigbee security for encrypted and
authenticated data transmission between the Front-End
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
Proceedings of the 2004 IEEE International Conference on e-Technology, e-Commerce and e-Service (EEE’04)
0-7695-2073-1/04 $20.00 © 2004 IEEE
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.
[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.
[4] IEEE mobile standards web page:
http://standards.ieee.org/mobile/overview.html#802.15
[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.
[8] RFC2246, “The TLS Protocol Version 1.0”. T. Dierks, C.
Allen. January 1999.
[9] RFC 2818, “HTTP Over TLS”, Rescorla, E., May 2000.
[10] MobiHealth website: http://www.mobihealth.org/