AUTHENTICATION OF PROFESSIONALS IN THE RTS E-HEALTH

SYSTEM

Andr´e Z´uquete

IEETA / Univ. of Aveiro, Campus Univ. de Santiago, 3810-193 Aveiro, Portugal

Helder Gomes

IEETA / ESTGA / Univ. of Aveiro, Campus Univ. de Santiago, 3810-193 Aveiro, Portugal

Jo˜ao Paulo Silva Cunha

IEETA / Univ. of Aveiro, Campus Univ. de Santiago, 3810-193 Aveiro, Portugal

Keywords:

e-Health, authentication, public key certiﬁcates, PKI, smartcards, SSL/TLS, roles, RBAC.

Abstract:

This paper describes the design and implementation of a PKI-based e-Health authentication architecture. This

architecture was developed to authenticate e-Health Professionals accessing RTS (Rede Telem´atica da Sa´ude),

a regional platform for sharing clinical data among a set of afﬁliated health institutions. The architecture had

to accommodate speciﬁc RTS requirements, namely the security of Professionals’ credentials, the mobility of

Professionals, and the scalability to accommodate new health institutions. The adopted solution uses short

lived certiﬁcates and cross-certiﬁcation agreements between RTS and e-Health institutions for authenticating

Professionals accessing the RTS. These certiﬁcates carry as well the Professional’s role at their home institu-

tion for role-based authorization. Trust agreements between health institutions and RTS are necessary in order

to make the certiﬁcates recognized by the RTS. As a proof of concept, a prototype was implemented with

Windows technology. The presented authentication architecture is intended to be applied to other medical

telematic systems.

1 INTRODUCTION

RTS (Rede Telem´atica da Sa´ude (?; ?)) is a regional

health information network (RHIN) providing an ag-

gregated view of clinical records provided by a set of

afﬁliated health institutions (HIs). Each HI uses its

own system to produce and manage clinical records,

which can be browsed and presented in different ways

by RTS. The goal of RTS is not to replace the systems

used by the afﬁliated HIs, but to provide a mediated,

global viewof patient’sclinical records independently

of the HIs holding their records.

RTS provides Portals for accessing clinical

records. Two Portals were foreseen: the Patients Por-

tal and the Professionals Portal. The ﬁrst is to be used

by Patients to communicate with their family doctor

and other health system issues such as renovation of

prescription and schedule appointments. The second

is to be used by healthcare Professionals for accessing

clinical records required for their normal, daily work.

The RTS Professionals’ Portal is a web server ac-

cessible through RIS (Rede Inform´atica da Sa´ude

), a

nation-wide, private network, interconnecting all HIs,

including the ones afﬁliated with RTS. Profession-

als access data provided by RTS using a normal web

browser running on a computer connected to the RIS.

This paper describes an authentication architec-

ture providing strong authentication for Professionals

accessing the Professionals’ Portal. Strong authen-

tication is provided by using a two-factor approach:

possession of a security token and knowledge of a se-

cret. For the security token we chose a smartcard.

Smart cards are tamperproof devices with security-

related computing capabilities which are very conve-

nient for running computations using private keys of

asymmetric key pairs.

This paper is organised as follows. Section 2

overviews the authentication architecture and some

RTS requirements. Section 3 presents some design

goals. Section ?? presents the proposed authentica-

Health Computer Network

uquete A., Gomes H. and Paulo Silva Cunha J. (2008).

AUTHENTICATION OF PROFESSIONALS IN THE RTS E-HEALTH SYSTEM.

In Proceedings of the First International Conference on Health Informatics, pages 72-80

 SciTePress

tion architecture. Section ?? presents some related

work. Section ?? presents our prototype implemen-

tation. Section ?? evaluates the architecture and the

implementation. Section ?? concludes the paper.

2 OVERVIEW

This paper describes an authentication architecture

providing strong authentication for Professionals ac-

cessing the Professionals’ Portal. Strong authenti-

cation is highly recommended in this case, as Pro-

fessionals can access sensitive data — the patients’

health records. The architecture allows Professionals

to roam between computers of their HI or other HIs.

Our authentication architecture had also to deal

with authorization issues. In fact, the RTS Portal uses

a role-based access control (RBAC) policy for deriv-

ing the Professionals’ authorizations to access clinical

data. Therefore, each time a Professional accesses the

RTS Portal, the later must learn a role that the former

may legitimately play for deriving authorisations.

The proposed architecture uses public key cryp-

tography as the basis for its operation. Each Profes-

sional is given a smartcard for storing and using per-

sonal credentials for accessing the RTS Portal. The

Professionals’ authentication process uses a facility

provided by web browsers, the SSL/TLS client au-

thentication with asymmetric keys and X.509 public

key certiﬁcates (PKCs), to prove the authenticity of

the Professional to the RTS Portal (?; ?).

Furthermore, the PKCs used by Professionals in

the SSL authentication process provide extra informa-

tion to the RTS Portal, besides the identity of the Pro-

fessionals, such as the HIs they are afﬁliated to and

the role they are playing. As a Professional may play

several roles simultaneously (e.g. Doctor and Chief

Doctor), the PKC must contain all the roles we can

play, being up to the RTS Portal to chose the role to

play, from the possible ones, in each session.

Since a Professional’s PKC carries roles the owner

can play, a mechanism must be provided to deal with

role changes. A possibility was to use certiﬁcation

revocation for outdating given roles. However, revo-

cation validation requires online communication be-

tween the PKC validator and the PKC issuer, which

may not be possible or convenient. Furthermore,

some roles are very short in time, for example, va-

cation substitutions, and these dynamics can be more

easily managed by short lived certiﬁcates than by Cer-

tiﬁcate Revocation Lists (CRL).

Alternatively, we chose to used short-term validity

periods for Professionals’ PKCs, as in (?). This way,

Professionals’ PKC get automatically invalid after a

short period of time after their issuing and Profession-

als must apply for new ones. A simple and secure en-

rolment process was also conceived for getting new

PKCs.

The public key infrastructure (PKI) for managing

Professionals’ credentials for accessing RTS uses a

ﬂexible, scalable grassroot approach. Each HI and the

RTS have their own PKI, including root and issuing

certiﬁcation authorities (CA). The issuing CA of each

HI is responsible for issuing RTS credentials for local

Professionals. The issuing CA of RTS is responsible

for issuing credentials for the RTS Portal. The valida-

tion of certiﬁcates issued by separate PKIs is enabled

by cross-certiﬁcation agreements. This means that the

RTS Portal will only be able to validate Professionals’

credentials issued by HI CAs cross-certiﬁed by RTS;

other people, including Professionals from other HIs,

cannot be authenticated by the RTS Portal, therefore

cannot access protected clinical data.

In this paper we mainly describe our architecture

for using smartcards for authenticating Professionals

and the RTS Portal when interacting with each other

and for providing Professionals’ roles to RTS. How-

ever, the architecture was designed taking into consid-

eration future enhancements and synergies, such as:

• Enable Professionals to use the same smartcard

for producing signed data as input for health in-

formation systems.

• Enable Professionals to give signed consents re-

garding accesses to the clinical data.

• Adoption of a similar authentication model for

authenticating Patients, possibly using the new,

smartcard-enabled Citizens Card.

• Usage of PKIs deployed for managing smartcards

to generate credentials for mutual authentication

within secure communications between hosts or

servers used in the RTS and in HIs (e.g. with

IPSec or SSL/TLS (?; ?)).

• Usage of PKI deployed in each HI for managing

the local authentication of Professionals access-

ing local services (e.g. secure wireless network

access).

3 DESIGN GOALS

A set of design goals were deﬁned at start. Those

goals derived both from RTS requirements and from

previous experiences with informatics services in

healthcare environments.

The ﬁrst goal was Professionals’ mobility. The

authentication architecture should not restrict the mo-

bility of Professionals; at the end it could be possi-

ble to use any computer, belonging to the RIS, to ac-

cess RTS services. Naturally, this goal depends on

software and hardware installed in client computers

accessing Professionals’ authentication tokens. Nev-

ertheless, we tried to facilitate the widespread use of

those tokens by using common hardware (e.g. USB

ports) and free software packages (e.g. software pack-

ages already provided by operating system vendors).

The second goal was to be pragmatic regarding

the implementation of a PKI for managing asymmet-

ric keys and PKCs. Nation-wide PKIs do not exist

for this purpose. And, though they could be advanta-

geous, they are also difﬁcult to deploy and to manage.

Thus, we chose to start from a sort of minimalist, ad-

hoc scenario, with no global PKI on top of the RTS

and all the HIs, but instead with isolated, standalone

PKIs on each entity, RTS and HI.

The third goal was RTS independency regarding

the management of personnel in afﬁliated HIs. Each

HI is an independent organization, with its own Pro-

fessionals, human resources management department

and some kind of directory service to store the Pro-

fessionals’ information. Independent of RTS, they

will continue to manage their Professionals because

of their own, internal systems. It thus makes sense

to reuse HI Professionals information and let each HI

to manage the access of its own Professionals to the

RTS. This way, we avoid replication of information

and a centralized enrolment of Professionals in RTS.

The fourth goal was to minimize communica-

tion overheads related to the authentication of Profes-

sionals and fetching/validation of role membership.

Namely, we tried not to use on RTS any online ser-

vices from HIs to deal with details regarding the iden-

tiﬁcation, authentication and role membership of Pro-

fessionals. Since Professionals’ information is man-

aged solely by their home HI (our previous goal), this

means that Professionals’ identiﬁcation and authenti-

cation credentials should convey RTS as much infor-

mation as possible, to avoid contacting online services

at Professionals’ home HIs.

The ﬁfth and ﬁnal goal was browser compatibility.

To avoid the requirement of using a speciﬁc browser,

no client-side active code (ActiveX and Java Applets)

is used in RTS. Therefore, we could not use any spe-

cial code for managing the authentication of Profes-

sionals using a browser to access RTS. In other words,

the authentication mechanism using a two factor ap-

proach should be already available within the basic

functionality of all browsers. As we will see, although

the basic functionality exists in all popular browsers

(support of SSL client-side authentication), the exact

mechanisms and policies used to handle such support

are different and raise some problems.

4 AUTHENTICATION

ARCHITECTURE

The authentication architecture is resumed in Fig-

ure ??. The Professional uses a web browser to access

the web server that implements the RTS Portal, and

uses an SSL secure channel for protecting the com-

munication from eavesdropping. Furthermore, mu-

tual authentication is required in the establishment of

the SSL secure session, thus the browser authenticates

the RTS Portal and the RTS Portal authenticates the

Professional using the browser. Similarly, the Profes-

sional uses a web browser a mutually authenticated

SSL session to access the HI Issuing CA web server

for requesting fresh RTS credentials.

4.1 The Professionals’ Smartcard

A Professional’s smartcard carries two types of asym-

metric key pair and corresponding PKCs. One type

we call RTS credentials, which are to be used to

authenticate himself when accessing the RTS Portal.

The other type we call HI credentials, which are to

be used to authenticate himself when accessing his HI

issuing CA for getting new RTS credentials.

Smartcards are initialised and provided by HIs to

their own Professionals. At start they only carry the

HI credentials. When required, the owner uses them

for requiring RTS credentials. These credentials can

then be used to access the RTS Portal.

RTS credentials are short lived, lasting for one or

a few days. The RTS Portal doesn’t use remote HI

services for checking for their validity. Instead, it as-

sumes that a Professional’s role revocation will natu-

rally be enforced by not being able to get a new RTS

credential including the revocated role. On the con-

trary, HI credentials are long lived, because they are

used for long periods of time for getting new RTS cre-

dentials.

4.2 Professional Authentication

The Professional authentication is requested by the

SSL server-side of web servers and conducted by the

SSL client-side running on browsers. The SSL client-

side authentication uses the Professional’s smartcard

for his authentication. The browser is conﬁgured to

use smartcard services and when client-side authen-

tication is required it will prompt the Professional

for the right credentials, including the ones inside the

smartcard, he intends to use. The Professional chose

Figure 1: Overview of the authentication architecture for HI Professionals whiling to access the RTS Portal.

the right pair of asymmetric keys from the smartcard,

and the PKC of the public key, and the browser uses

them to provide client-side authentication.

This client-side approach is the same for access-

ing the RTS Portal or the HI Issuing CA. It is up to

the Professional to choose the right set of credentials,

from the smartcard, to get authenticated. And in all

cases it needs to introduce a PIN to unblock the smart

card for producing digital signatures required by the

SSL authentication protocol.

The web servers used by the RTS Portal and the

HI Issuing CA perform the following actions: (i) vali-

date the PKC chose and presented by the Professional,

(ii) use the certiﬁed public key to validate the SSL

secure channel establishment and (iii) enable the ser-

vice, RTS or CA, to access the Professional’s PKC.

The RTS learns from the PKC the Professional’s iden-

tity, his home HI and his roles; the CA learns only the

Professional’s identity.

4.3 Role Assignment and Selection

The roles of each Professional are embedded in the

PKC of his RTS credentials. These roles are stored

in extension ﬁelds, namely the Extended Key Usage

(EKU) ﬁeld. Each role was given a numerical tag, an

ASN.1 Object IDentiﬁer, reserved at IANA

for RTS.

Each time a Professional requests RTS creden-

tials, he gets, after proper authentication at the HI Is-

suing CA, a new PKC with the current roles he can

play. This PKC is communicated to the RTS web

server during SSL authentication and, if successful,

the PKC is made available for consulting by the RTS

Portal during the SSL session. This way, when a Pro-

fessional initiates an SSL-protected session with the

RTS Portal, it can easily learn the set of roles the Pro-

fessional can play and prompt the Professional for se-

lecting the right role for the current session.

4.4 Trust Relationships

Each entity, RTS and HI, uses an independent PKI for

managing RTS and HI authentication credentials used

by Professionals. The RTS is not meant to serve as a

CA for all HIs; it only deploys a PKI mainly for man-

aging its own certiﬁcates. HI certiﬁcation hierarchies

may be isolated or integrated in wider hierarchies pro-

viding large-scale validation of certiﬁcates. For the

RTS that is irrelevant, all it requires is an Issuing CA

for issuing RTS credentials for local HI Professionals.

http://www.iana.org

Since RTS and HI certiﬁcation hierarchies are iso-

lated from each other at the beginning, some mecha-

nism is required to enable the RTS Portal to validate

Professionals’ RTS credentials, issued by HIs. Sim-

ilarly, some mechanism is required to enable profes-

sionals to validate the credentials of the RTS Portal,

issued by RTS. This mechanism is cross-certiﬁcation.

When an HI gets afﬁliated to the RTS, the RTS Issu-

ing CA issues a certiﬁcate for the public key of that

HI Issuing CA. With this certiﬁcate, the RTS is able

to validate all the PKCs of RTS credentials issued for

the Professionals of that HI. Similarly, the HI Issuing

CA issues a certiﬁcate for the RTS Issuing CA, en-

abling local Professionals to validate the credentials

of the RTS Portal.

4.5 Validation of Certiﬁcates

With this cross-certiﬁcation in place, the validating

of certiﬁcates’ certiﬁcation chains works as follows.

The RTS Portal trusts only on the (self-signed) certiﬁ-

cate of the RTS Root CA. Similarly, the Professional

trusts only on the (self-signed) certiﬁcate of his HI

Root CA. Since certiﬁcate chain validations progress

recursively until ﬁnding an error or a trusted certiﬁ-

cate, the validation chains are the following:

Validator

Professional RTS Portal

validation

sequence

RTS Portal

RTS Issuing CA

Professional

HI Issuing CA

ւ ւ

RTS Issuing CA

HI Issuing CA

RTS Issuing CA

ւ ւ

HI Issuing CA

HI Root CA

RTS Issuing CA

RTS Root CA

ւ ւ

HI Root CA

RTS Root CA

where

represents the PKC of X issued by Y.

Besides cross-certiﬁcation for certiﬁcate chain

validation, trust relationships between the RTS, HIs

and their Professionals must be complemented by

common certiﬁcation procedures. Namely, all HIs af-

ﬁliated to the RTS should follow similar procedures

for issuing RTS credentials. For instance, smartcards

with HI credentials should be initialised by HIs and

personally delivered to Professionals.

4.6 Validity of Authentication

Credentials

The authentication credentials stored inside a Profes-

sional’s smartcard are the HI credentials and the RTS

credentials. The ﬁrst ones are used to establish an au-

thenticated session to get the second ones.

HI credentials are to be used frequently, for in-

stance, once per day or once for a couple of days, to

fetch new RTS credentials. Therefore, they should

have long validity periods and CRLs must be pub-

lished to prevent unwanted use of them after a given

instant. For instance, if a Professional moves from

one HI to another one, his smartcard from the former

HI must be returned and a CRL should be issued to

invalidate the public key of the HI credentials inside

the smartcard. Note, however, that CRL issuing and

validation are all executed within the same HI, and

not by external clients.

RTS credentials are valid only during short peri-

ods of time, one or two days. Therefore, no CRLs are

used to validate them, since the error window is too

narrow to allow a Professional to play a role he is no

longer allowed to. Consequently, by default the HI Is-

suing CA doesn’t publish CRLs for RTS certiﬁcates.

In special cases, such as disciplinary processes

and legal inquiries, it should be possible for the HIs to

provide to the RTS Portal, just in time, a list of RTS

certiﬁcates that should no longer be accepted while in

validity period. But since such cases should be rare, it

is preferable to deal them as the exception to the gen-

eral rule above stated: no CRLs exist and are checked

for RTS certiﬁcates.

All the certiﬁcates used in both HI and RTS cre-

dentials do not need to be published by Issuing CAs.

In fact, these certiﬁcates are used solely in the con-

text of SSL mutual authentication, and are communi-

cated to the interacting peers within the SSL protocol.

Therefore, they need not be published in some public

directory System, as other certiﬁcates do, because no

one needs them for other purposes.

5 RELATED WORK

The following e-Health Systems were analysed:

HYGEIAnet and MedCom/Sundhed.dk.

5.1 Hygeyanet

HYGEIAnet is the RHIN of Crete, Greece. It was de-

veloped by the Institute of Computer Science (ICS)

of Foundation for Research and Technology – Hel-

las (FORTH) to provide an integrated environmentfor

delivery of health care services in Crete Island (?; ?).

Similarly to RTS, HYGEIAnet is formed by sev-

eral HIs, namely Hospitals and Primary Care Units,

each with its own health data, information services

and human resources. HYGEIAnet operates above

these independent healthcare units, providing an in-

frastructure for sharing clinical information. Also, the

Integrated Electronic Health Record (I-EHR) is a key

element as it aggregates the patient health information

in all participating healthcare units.

The trust and security frameworks are imple-

mented in HYGEIAnet with VPNs, SSL, smartcards,

PKI, security certiﬁcates and digital signatures. A Re-

gional certiﬁcation authority issues the certiﬁcates for

users and applications. These certiﬁcates can be used

to authentication and digital signing of documents and

in case of user certiﬁcates they can be stored in smart-

cards (?)

Authentication is a centralized process in

HYGEIAnet. All applications and services are

registered in the Health Resource Service (HRS)

and issued a unique ID. Each HYGEIAnet user also

must register in HRS to be able to use HYGEIAnet

services, and a unique user name and password is

provided. The username and password are com-

municated to an authentication server (AS) and a

certiﬁcate is issued from the regional CA.

In terms of authorization it follows a decentral-

ized approach, where each individual service main-

tains and manages roles (groups) and role based per-

missions. The user must be assigned to the proper role

in each service he is to have access.

When accessing a service, the user is authenti-

cated through the Authentication Service and gets his

individual access rights validated through the individ-

ual service.

The RTS and HYGEIAnet approaches for authen-

tication differ: HYGEIAnet has a centralised manage-

ment of resources (users and services), with certiﬁ-

cates issued by a regional CA, and requires an online

AS for user authentication. On the contrary, RTS has

a decentralized management of resources, reusing the

management services belonging to the afﬁliated HIs,

with certiﬁcates issued by HI CAs for their own users

and services and not requiring any online user authen-

tication service to be used by RTS.

5.2 The Health Portal (Sundhed.dk)

and the Health Data Network of

Denmark (MedCom)

MedCom is the National Health Data Network of

Denmark. It is working since 1994, and it connects

more than 2000 Hospitals, Pharmacies, General Prac-

titioners (GPs) and Specialists. It started has a VAN

network exchanging EDIFACT messages (?). In 2004

it started the process of migration to the Internet and

EDIFACT messages were translated into XML mes-

sages. Today, both message formats are used (?).

Network security is implemented at three lev-

els (?; ?).

At the ﬁrst level are VPN connections connecting

healthcare networks to a central hub in a star topology.

This solution allows the reuse of Internet connections

that all the health care units already have.

At a second level there is an agreement system

that controls the data ﬂows from and to any of the lo-

cal healthcare networks. When a connection between

two healthcare networks is needed, a previous access

to the agreement system is required to establish the

connection between the two networks.

The third level of security is user authentication,

made locally through his username and password, or

his asymmetric key pair and PKC.

The Health Portal started in December 2003. It

works on top of the Health Data Network and reuses

its infrastructure and services. Unlike the Health Data

Network, that only provides services for Profession-

als, the Health Portal provides services for both Citi-

zens and Professionals (?).

User authentication, for both Citizens and Profes-

sionals, is made using OCES certiﬁcates

issued by

the national PKI that can be used in several national

public services. Professionals can use several OCES

certiﬁcates: (i) Administrativedigital signature for re-

gion, hospital or GP, (ii) health professional’s digital

signature based on personal identiﬁer and (iii) autho-

rization for treating patients (?).

Comparing with RTS, the Danish system exten-

sively uses asymmetric keys and PKCs, beneﬁting

from a nation-wide PKI. However, many of the Dan-

ish system security requirements, such as Profession-

als’ digital signatures, are currently not required by

RTS, since it is not used for entering signed data into

the health information system. We believe, however,

that our architecture can evolve, but keeping its basic

structure, for provide security services similar to the

ones provided by Danish system. Furthermore, our

PKI may coexist with a national-wide PKI encom-

passing all HIs, though not necessarily using it.

OCES certiﬁcate: Public Certiﬁcate for Electronic Ser-

vice

6 PROTOTYPE

IMPLEMENTATION

As a proof of concept, a prototype of the authenti-

cation architecture was implemented. The prototype

extensively used available products for Windows op-

erating systems, because of its dominance in the com-

puter desktops of the HI currently afﬁliated to RTS.

The prototype included an RTS service, with a

two-level PKI and a web Server (Professionals’ Por-

tal), one HI instance, with a two level PKI, an Ac-

tive Directory Server and one registered Professional

(one smartcard). CAs were implemented with Win-

dows Certiﬁcation Services available in Windows

2003 Server Enterprise Edition. When installed in

Enterprise mode, this CA interacts with AD to ob-

tain user information for certiﬁcate issuing, and uses

certiﬁcate templates, stored in AD and subject to AD

access control rules, for certiﬁcate issuance manage-

ment.

The key aspects to test in the prototype were (i)

the impact of different middleware software in smart-

card deployment, (ii) the deployment of an HI PKI for

the management of RTS credentials for local Profes-

sionals, and (iii) the use of short lived RTS credentials

to access RTS services.

6.1 Smartcard Deployment

Since smartcards are portable devices, in theory they

may be used to authenticate Professionals accessing

the RTS from different computers. However, this re-

quires some software installed in those computers: (i)

the card reader driver and (ii) middleware to ﬁll the

gap between applications and smartcard services.

There are different trends in this speciﬁc middle-

ware area. Windows applications, such as the Internet

Explorer browser, use the CryptoAPI (CAPI), which

can use several Cryptographic Service Providers

(CSP) for interacting with different smartcards. An-

other approach is to use PKCS#11 (?), a standard

interface for cryptographic tokens. This interface is

used by Netscape and Firefox browsers.

Since middleware modules are usually speciﬁc for

smartcard manufacturers and some manufacturers im-

pose limits on the number of computers were they

can be installed or do not provide similar modules for

all operating systems, the following approaches were

foreseen: (i) the use of smartcards with native support

from the operating system, (ii) the use of open source

software or free binaries and (iii) the use of non-free

software providing support for multiple smartcards.

In our prototype we used only Windows XP sys-

tems for the Professional computers and two smart-

card tokens: Rainbow iKey 3000 and Schlumberger

Cyberﬂex e-gate 32k. None of them was natively sup-

ported by Windows. Also we were not able to get an

open source solution (openSC/CSP#11) working re-

liably. For the non-free solution we used SafeSign

Standard 2.0.3 software, and both smartcards worked

properly after their ﬁrst initialization was made by

SafeSign. If this ﬁrst initialization is not made by Safe

Sign, chances are that smartcards are not recognized,

has it happened with Cyberﬂex Card.

After low-level initialization (e.g. personaliza-

tion), smartcards were incepted with the Professional

HI credentials, allowing the owner to enrolment for

RTS certiﬁcates. The HI credentials cannot be re-

newed and the smartcard becomes useless when the

HI certiﬁcate validation period expires.

6.2 HI PKI Deployment

The HI PKI was implemented with an ofﬂineRoot CA

and an online Issuer CA. The latter interfaces with an

AD and with an IIS 6.0 server with a web interface for

certiﬁcate enrolment, CRL Distribution Point (CDP)

and Authority Information Access (AIA) functionali-

ties.

Some groups were deﬁned in AD, one for each

identiﬁed professional role, and Professionals as-

signed to them. They provide access control for cer-

tiﬁcate enrolment.

Certiﬁcates issued by the Issuing CA are tailored

using certiﬁcate templates. These templates allow the

deﬁnition of certiﬁcate characteristics and access con-

trol rules. Certiﬁcate templates were created, one for

each professional role that only differ in the speciﬁca-

tion of certiﬁcate extensions and certiﬁcate security.

An application policy was deﬁned for each Profes-

sional role, to be included in RTS certiﬁcates issued

for the role; application policies are simple ASN.1

OIDs used by RTS after reservation at IANA. The ap-

plication policy OID is stored in the certiﬁcate EKU

(Extended Key Usage) ﬁeld. Also a certiﬁcate tem-

plate was deﬁned for the HI certiﬁcate, with an appli-

cation policy for RTS certiﬁcate renewal.

Note that RTS certiﬁcates should contain all the

current roles of a Professional, and not only one.

However, that is simply not possible with certiﬁcate

templates and access control rules. Therefore, in the

prototype a Professional may have several RTS cre-

dentials, one for each role, and chose the proper one

when starting a session with the RTS Portal.

The customization of Windows certiﬁcate tem-

plates has also some limitations. Namely, certiﬁcate

templates do not allow for validity periods shorter

Now Gemalto, after being Axalto

than two days. This may be problematic if two days

is considered a large risk window for RTS credentials.

But in our opinion two days is perfectly reasonable.

The Issuer CAs also issues cross-certiﬁcates for

the public key of the RTS Issuing CA. Name con-

straints were used to deﬁne the name space for the ac-

cepted certiﬁcates. Certiﬁcate (issuance) constraints

and application constraints were not used because

they are not interpreted by browsers, since they re-

quire some application context (?).

A web interface, adapted from the Microsoft Cer-

tiﬁcate Services web interface, was deployed for en-

rolment for RTS certiﬁcates. After the Professional

authentication using its HI credentials, RTS certiﬁ-

cates are immediately issued and installed in the Pro-

fessional’s smartcard. Both Internet Explorer and

Netscape can be used for RTS credential renewal.

6.3 Usage of RTS Credentials for

Accessing the RTS Portal

The validation of Professionals’ RTS credentials by

the RTS Portal, an IIS 6.0 web server, was performed

at two different levels. At the IIS level, validation

follows SSL rules and certiﬁcation chains. At the ap-

plication level, validation includes checking RTS OID

values placed in EKU ﬁeld of the received RTS cer-

tiﬁcate. The Portal only initiates a session with a Pro-

fessional if his certiﬁcate is considered valid at both

levels.

Finally, Professional can use both Internet Ex-

plorer and Mozilla Firefox to access the RTS Portal.

Tests were made in order to determine if the num-

ber PKCs from the HI PKI hierarchy in the smartcard

could be reduced, but due to different approaches be-

tween browsers for building and validation of certiﬁ-

cate chain, we conclude that all certiﬁcates must be

present in order to allow both browsers to be used.

7 EVALUATION

In this section we evaluate the architecture and im-

plementation of our authentication system taking into

consideration the design goals presented in Section 3.

Concerning the ﬁrst goal, a pragmatic PKI im-

plementation, it was achieved, since no speciﬁc,

large-scale PKI is required. On the contrary, the

PKI is build on top of independent PKIs and cross-

certiﬁcation agreements. Trust relationships between

RTS and afﬁliated HIs are reﬂected in such cross-

certiﬁcation and on common policies for issuing RTS

certiﬁcates for Professionals.

Concerning the second goal, Professionals’ mo-

bility, smartcards embedded in USB tokens are the

most promising solution nowadays but still raise some

problems. For instance, they (still) cannot be used

with PDAs and smartphones. Furthermore, and more

problematic, the usage of smartcards in USB-enabled

computers still raises the problem of software instal-

lation for dealing with them. As we saw in Section ??,

it is not simple to ﬁnd a ubiquitous, free solution

for the middleware required by different applications

(browsers) to interact with many smartcards.

Concerning the third goal, leaving RTS out of the

management of Professionals working at the HIs, it

was totally attained. The RTS Portal only requires

Professionals to have a valid certiﬁcate issued by their

HI and containing a set of role on it. HIs have full

control on the management of local Professionals and

their role, enabling RTS access by issuing RTS certiﬁ-

cates with the proper contents, namely Professional

identity, HI afﬁliation and possible roles.

The fourth goal, to minimize communication

overheads between RTS and HIs for authenticating

Professionals and getting their role, was also fully at-

tained. The RTS Portal, by itself, is capable of authen-

ticating Professionals just by validating their certiﬁ-

cate, without checking CRLs remotely, and capable

of learning their role also from the certiﬁcate. No on-

line communication between RTS and HIs is required

in this process.

The ﬁfth and ﬁnal goal was browser compatibil-

ity. In this case we must say that it may be difﬁcult

to provide the same set of functionalities with all the

browsers, because of the differences between the ex-

isting middleware solutions for bridging the gap be-

tween applications and smartcards (CAPI, PKCS#11,

etc.). Furthermore, some smartcard management ac-

tivities, such as garbage collection of useless creden-

tials inside the smartcard, may require the deploy-

ment of active code for running within Professionals’

browsers.

8 CONCLUSIONS

In this paper we described the design and imple-

mentation of an authentication architecture for Pro-

fessionals working within the RTS e-Health environ-

ment. Since Professionals access RTS services using

a browser and an RTS Portal, the authentication of

Professionals was mapped on top of SSL client-side

authentication. The credentials used in this authen-

tication are provided by their HIs and formed by a

private key and a short-lived X.509 PKC, both stored

inside a smartcard. The short lifetime of these certiﬁ-

cates allows issuing CAs to simplify their PKI: they

are not published and they are not listed in CRLs.

The key characteristics of the authentication ar-

chitecture are (i) the use of smartcards for strong

authentication, to store Professional credentials and

to improve their mobility, (ii) the use of short-lived

RTS certiﬁcates carrying Professional identiﬁcation

and roles for authentication on the RTS Portal and au-

thorization of operations required to the RTS, (iii) the

use of “normal”-lived HI certiﬁcates for Professional

enrolment for RTS certiﬁcates, (iv) a PKI where the

RTS and each HI run their own, private PKI with

(v) cross-certiﬁcation for the establishment of trust

relations required to validate Professionals creden-

tials and RTS credentials within SSL sessions. This

authentication architecture is highly scalable and is

prepared to be applied to other medical telematic

projects such as the Brain Imaging Network Grid

(BING) (?) and the Grid-Enabled REpoSitories for

medicine (GERESmed), two medical networks now

under development an IEETA/University of Aveiro.

A prototype was implemented as proof of con-

cept and based exclusively in technology provided

by Windows systems or developed for Windows sys-

tems. Regarding the browsers used by Professionals,

we tested two of the most popular ones also on Win-

dows systems: Internet Explorer and Mozilla Firefox.

The major source of problems that we found for

implementing the prototype was the use and manage-

ment of smart cards by Professionals’ systems and

browsers. The variety of middleware existing for

managing smart cards and the different approaches

followed by different applications (browsers) regard-

ing the middleware make it very hard to provide a

clean, ubiquitous interface for Professionals. Further-

more, this is a critical issue in the deployment of this

authentication architecture along many different sys-

tems and computers.

ACKNOWLEDGEMENTS

This work was ﬁnanced by the Aveiro Digital Pro-

gramme 2003-2006 of the Portugal Digital Initia-

tive, through the POSI programme of the Portuguese

Government, and by the FCT (Portuguese R&D

agency) through the programs INGrid 2007 (grant

GRID/GRI/81819/2006) and FEDER.

REFERENCES

Cunha, J. P. (2007). RTS Network: Improving Re-

gional Health Services through Clinical Telematic

Web-based Communication System. In eHealth Con-

ference 2007, Berlin, Germany.

Cunha, J. P. S., Cruz, I., Oliveira, I., Pereira, A. S., Costa,

C. T., Oliveira, A. M., and Pereira, A. (2006). The

RTS Project: Promoting secure and effective clinical

telematic communication within the Aveiro region. In

eHealth 2006 High Level Conference, Malaga, Spain.

Cunha, J. P. S., Oliveira, I., Fernandes, J. M., Campilho,

A., Castelo-Branco, M., Sousa, N., and Pereira, A. S.

(2007). BING: The Portuguese Brain Imaging Net-

work GRID. In IberGRID 2007, pages 268–276, San-

tiago de Compostela, Spain.

Dierks, T. and Rescorla, E. (2006). The TLS Protocol Ver-

sion 1.1. RFC 4346, IETF.

Housley, R., Ford, W., Polk, W., and Solo, D. (1999). In-

ternet X.509 Public Key Infrastructure Certiﬁcate and

CRL Proﬁle. RFC 2459, IETF.

ISO 9735 (1988). Electronic data interchange for ad-

ministration, commerce and transport (EDIFACT).

http://www.iso.org

Katehakis, D. G., Sfakianakis, S. G., Anthoulakis, D., Kav-

lentakis, G., Tzelepis, T. Z., Orphanoudakis, S. C., and

Tsiknakis, M. (2005). A Holistic Approach for the

Delivery of the Integrated Electronic Health Record

within a Regional Health Information Network. Tech-

nical Report 350 (FORTH-ICS/ TR-350), Foundation

for Research and Technology - Hellas, Institute of

Computer Science, Heraklion, Crete, Greece.

Kent, S. and Atkinson, R. (1998). Security Architecture for

the Internet Protocol. RFC 2401, IETF.

Lloyd, S. (2001). CA-CA Interoperability. PKI Forum.

MedCom IV (2003). MedCom – the Danish Healthcare

Data Network. MedCom IV, Status Plans and Projects.

http://www.medcom.dk/dwn396

Pedersen, C. D. (2005). An baltic healthcare network and

interoperability challenges. Cisco eHealth think tank

meeting.

PKCS#11 (2004). PKCS #11 v2.20: Cryptographic Token

Interface Standard. RSALaboratories.

Ribeiro, C., Silva, F., and Z´uquete, A. (2004). A Roaming

Authentication Solution for WiFi using IPSec VPNs

with Client Certiﬁcates. In TERENA Networking Con-

ference 2004, Rhodes, Greece.

Rossing, N. (2005). The Health Portal (www.sundhed.dk)

And The Health Data Network Of Denmark. Execu-

tive Summary of Presentaion in eHealth Athens 2005.

http://www.ehealthathens2005.gr

Sundhed.dk (2006). The Danish eHealth experi-

ence: One Portal for Citizens and Professionals.

http://dialog.sundhed.dk

Tsiknakis, M., Katehakis, D. G., Sfakianakis, S., Kavlen-

takis, G., and Orphanoudakis, S. C. (2005). An Ar-

chitecture for Regional Health Information Networks

Addressing Issues of Modularity and Interoperability.

Journal of Telecommunications and Information Tech-

nology (JTIT), 4:26–39.

Voss, H., Heimly, V., and Sj¨ogren, L. H. (2005). The

Baltic ehealth Network – taking secure, Internet-based

healthcare networks to the next level. Norwegian Cen-

tre for Informatics in Health and Social Care.