Figure 1. Baseline
requirements of a Hospital Information System
|
http://www.spinellis.gr/pubs/jrnl/1999-MedInf-Euromed/html/euromed.html This is an HTML rendering of a working paper draft that led to a publication. The publication should always be cited in preference to this draft using the following reference:
|
S. Gritzalis a,b, J. Iliadis b, D. Gritzalis c, D. Spinellisb, S. Katsikasb
a Department
of Informatics, Technological Educational Institute (TEI) of Athens
Ag. Spiridonos St., Aegaleo GR-12243, Greece,
e-mail: sgritz@aegean.gr
b Department
of Information & Communication Systems,University of the Aegean,
Research Unit, 30 Voulgaroktonou St., Athens,
GR-11472, Greece
e-mail: (jiliad, dspin, ska)@aegean.gr
c Department
of Informatics, Athens University of Economics & Business
(AUEB)
76 Patission St., Athens GR-10434, Greece,
email: dgrit@aueb.gr
Abstract: The EUROMED-ETS
pilot system offers a number of security functionalities using
off-the-shelf available products, in order to protect Web-based
medical applications. The basic concept used by the proposed security
architecture is the Trusted Third Party (TTP). A TTP is used in
order to generate, distribute and revoke digital certificates
to medical practitioners and healthcare organisations that wish
communicate securely. Digital certificates and digital signatures
are used to provide peer and data origin authentication and access
control. The paper demonstrates how TTPs can be used effectively
in order to develop medical applications that run securely over
the World Wide Web.
Keywords: Trusted Third
Parties, Security, Cryptography, Digital Signatures
Computerised information systems allow us to store and handle vast amount of data. The scenery of these systems is rapidly changing because of the massive use of data communications. As a consequence, the number of users that have access to data networks is increasing rapidly. This development has its parallel in the medical sector, where systems are used to store various kinds of patient information and where advanced imaging equipment can directly be coupled to databases that store the images in digitised form.
Figure 1 exemplifies four generic requirements of a healthcare/hospital information system [1]. Such an information system can, nowadays, be used to remotely provide patients with a number of healthcare services. In this case, information and communication technologies are the technological means for the realisation of telemedicine. In other words, telemedicine is the interactive audio-visual communication between healthcare providers and their patients or other healthcare providers regardless of geographical distance.
Several research activities refer to telemedicine. EUROMED is such a project, with the objective to exploit, combine and support high performance computing networking activities, in order to enhance and standardise visualisation techniques to be used in medical applications over Europe. The project utilises the World Wide Web (WWW) as a navigational medium to remotely access multimedia medical information. It is based on interlinked HTML pages which allow authorised users to access medical data, input them to Java applications invoked from other pages and archive the results by updating links to the old pages.
Three hierarchical infrastructures have been created in the course of the project [2]:
Figure 1. Baseline
requirements of a Hospital Information System
Moreover, the Web aims to provide its user a pool of human knowledge for sharing information and ideas. Web is a distributed hypertext-based information system and includes a body of software and a set of protocols and conventions that allow Internet users to access data through the use of a Graphical User Interface. The Web's hypertext and multimedia techniques make it easy for any user to roam, browse and contribute. From a designer point of view, the Web is based on a client-server model. It consists of a set of servers, known as Web servers, which receive one request at a time and respond to that request without preserving state information, and a set of clients, known as Web browsers, which make requests based on user input and present results. Several efforts have been undertaken to address security in the Web, although the primary focus has been at the application level. These efforts have addressed the issue of protecting the privacy, accuracy and authenticity of transactions conducted over the Internet [4,5].
Undoubtedly, any system that is based entirely on the Web for its functions is vulnerable to serious security threats. The most important threats, which we had to deal with in order to establish a secure medical environment, are briefly presented below.
The EUROMED-ETS project aimed at effectively facing the security threats existing in such an environment. In detail, the requirements which have been proposed by the EUROMED project can be considered as the baseline requirements for any modern distributed medical application and information systems. These requirements are the following [2]:
In the context of providing measures like digital signatures in
order to prove authenticity and integrity of data, and encryption
in order to provide confidentiality, technical, Organisational,
medical and ethical aspects have been considered. However, the
first level of security was to protect the access to the personal
homepage related to every patient.
Most of the security problems mentioned before can be solved by applying cryptographic methods. There are two general forms of key-based cryptographic algorithms:
The main advantage offered by public key cryptosystems lies with the fact that it is more scaleable to very large systems, it has more flexible means of authentication, it can support digital signatures and it enables non-repudiation enforcement to verify the transmission or receipt of a given transaction. However, public-key algorithms make the key management process easier, but the need for entities to make their public key widely known poses new problems. At first, new mechanisms to implement publication of these keys could be developed, for the mechanisms commonly used are insecure themselves. Web pages, white pages directories, finger files and Domain Name System are mechanisms commonly used or considered at a first stage. However, it is not possible merely to store a public key in these mechanisms, as the key itself could be modified and the whole process could cause an integrity violation at a user's public key.
The assurance scheme is rapidly improved and can become fully acceptable when it is based on the use of a public-key certificate. It is an information package which includes the user's identity, the user's public key, and it is digitally signed by a trustworthy entity, which is known as the Trusted Third Party (TTP). TTP is described as "…an impartial organisation delivering business confidence, through commercial an technical security features, to an electronic transaction. It supplies technically and legally reliable means of carrying out, facilitating, producing independent evidence about and/or arbitrating on an electronic transaction. Its services are provided and underwritten by technical, legal, financial and/or structural means" [6]. When this scheme is applied to a security infrastructure based on public key techniques, the TTP is widely known as Certification Authority (CA). A CA is made public and certifies that the key is valid for a certain period of time.
When a community of users grows, a single CA may become overloaded because of the big number of certificates it has to manage. Furthermore, each company from the private or public sector, wants to control the way its users generate public keys, and the validity period of the certificates. This causes the creation of various CAs, everyone of which may have a different security policy. This situation introduces an extra problem of Trust Models. In the case of multiple CAs, should the entities that trust different CAs wish to communicate, then the CAs should have organised a way to certify each other, in such a way that there be an acceptable level of trust between them.
There are several possibilities how this type of trust can be realised [7]:
The major TTP functionalities are briefly presented in the sequel.
In Figure 2, the security-relevant functional decomposition at
the highest level is demonstrated [13]. The decomposition is focused
in the area between the transaction support functions and the
TTP functions themselves. Any entity involved in the transaction
process makes use of the IT system functions offered for secure
transaction support.
Figure 2. A
generic model for secure transaction support from TTP services
Secure transaction support functions in the IT system are decomposed
into an Unsecured Support Component and a Secure TTP Infrastructure.
Another component composes their services into the required secure
transaction support functions. This must itself be secure because
it includes at least one interface with the transacting parties,
which must not misrepresent the IT encoding of the transaction.
But it may handle other security functions all controlled by the
respective transacting parties.
3.3. TTP functions and software
Every user who wishes to communicate with an entity in a specific networking group must register with the appropriate CA. This includes the insertion of the user's identification data in the Directory and the issuance of a certificate for that entity from the CA.
The initialisation of a secure communication session is being established with the exchange of information pertinent to the selected cryptographic algorithms that will be used, the exchange of the authentication keys of the communicating entities and the creation and exchange of a random encryption key, valid only for that session.
Authentication comprises the actions that have to be performed in order to verify the identity of an entity. Once this is verified, a certificate is issued for that entity.
Key Personalisation is the process of associating a keypair to the registered name of an entity. The keypair is created by the user and the public part of it is communicated to the CA. If the transmitted key does not belong to another entity, then the CA certifies that it belongs to that entity by signing it and thus creating the digital certificate of that entity.
The naming of the entities is performed in accordance with the X.500 [14] specifications in order to provide the means to identify these entities, without depending on the various identification methods used inside the organisations that these entities belong to.
Certificates are signed using the 1024 bit CA's private key. CAs send the issued certificates to the Directory and keep a backup copy at a local repository. The certificate is transferred to the user by means of e-mail; the user may also download the certificate from a specific URL he is informed of, when the certificate is issued.
Detailed audit records are kept. Every action performed by one of the modules, the TTP is comprised of, is recorded.
The Directory acts as a distributed repository of identification and authentication information, such as the user certificates; it is an implementation of the Lightweight Directory Access Protocol (LDAP) protocol [15]. Servers consult the Directory in order to retrieve the latest version of the CRL and identification data for a user that is trying to access them. The communication with the Directory is taking place with LDAP over Secure Socket Layer (SSL) [16].
Certificate Revocation Lists (CRL) are lists that contain the certificates that have been revoked. They include information, such as the CRL issuer's identifier, the serial numbers of the revoked certificates and the date each certificate was revoked. The CRL is signed by the CA, using its private key. The CRL is published in the Directory, so everyone may access it.
Security data, such as certificates or CRLs, are always time-stamped.
However, this need did not arise for the medical data. Should
this be considered necessary in any case, timestamps, signed with
the signature of the entity that transmits the data, can be affixed
to that data.
4. Implementing TTP services for healthcare over the Web
The research work performed in the course of the EUROMED-ETS project (the project aiming at enhancing security functionalities to the EUROMED framework) has led the authors to the conclusion that a framework for securing Web-based medical applications can be developed by establishing Trusted Third Parties and exploiting the services provided by them.
In our case, the target of trust was achieved through a hierarchy of CAs. In this model each CA is certified by another CA at a higher level, thus achieving a hierarchy of trust. Each certificate is validated by traversing through the signature chain, verifying each certificate up to the root. On the other hand, TTPs compose a security scheme which, due to their open architecture and their interoperability with many applications operating on the Web environment, can provide solutions to the security threats that a Web-based medical application may have to confront with. During the pilot implementation of the EUROMED-ETS project, the TTP security scheme was composed of the following modules [2]:
Figure 3. TTP infrastructure
Appropriate measures have been developed to deal with the security threats previously described. Each measure is mapped to the pertinent TTP functions, where applicable, and to actions that need to be taken by the end-entities.
End-entities task(s): Encryption using shared session keys (SSL).
TTP function(s): None.
End-entities task(s): At the client side, the generation of the pre-master key with a cryptographically secure random algorithm (SSL).
TTP function(s): None.
End-entities task(s): The client sends the encrypted pre-master key, using the receiver's public RSA key. The receiving entity's public RSA key must be known prior to transmission. That key is part of the receiving entity's certificate information.
TTP function(s): Certification, Key Management, Key Distribution, Directory.
End-entities task(s): The messages which are transmitted with MAC hashes, are using the transmitting entity's private RSA key. Receiving entity must verify the authenticity and the integrity of these messages.
TTP function(s): Certification, Key Management, Key Distribution, Directory.
End-entities task(s): outside the scope of EUROMED-ETS activities.
TTP function(s): None.
End-entities task(s): Each entity authenticates itself by sending to the peer a signed message containing its X.509v3 certificate. Entities may choose to verify authenticity of certificates either against a local certificate database or against the Directory.
TTP function(s): Key generation, Key personalisation, Key uniqueness, Certification, Key Management, Directory.
End-entities task(s): Use of password information for access to private key only; avoidance of password transmission.
TTP function(s): None.
End-entities task(s): Access control, using authenticated peer identity, against a local rule base.
TTP function(s): None.
End-entities task(s): Authentication, logging.
TTP function(s): Certification, Key Management, Directory.
End-entities task(s): Protection, tamperproof-hardware key storage.
TTP function(s): Key Generation and Initialisation, Key Management.
End-entities task(s): Reporting of compromised private keys.
TTP function(s): Certification, Certificate Revocation, CRL Maintenance, Directory.
From the above, it becomes apparent that not only the TTP, but
the end-entity functionality is crucial in the design and implementation
of the necessary measures against Web threats.
For illustration purposes, an examination of a session example at the technical level is described. Assume that a Physician P, using a Client machine C, wants to connect to Server S of Hospital H to obtain the patient record of the hospital Guest G. A TTP provides the Certification Authority CA and Registration Authority RA services.
If P is not a registered user in the TTP scheme he must register and obtain a certificate from a CA. These steps will allow him to be authenticated by the Server S, grant him the rights he may have as a Physician and communicate securely with S. S must be certified by one of the CAs too.
The technical details of the registration and certification process for P at the EUROMED-ETS pilot is the following :
The above procedure is transparent to P. He only knows that he has directed his browser to S and requested for the patient record of G, which he has taken.
The exact steps of the SSL handshake (step 9), where both parties (Server S and Physician P) possess valid certificates and have to be authenticated by each other in order to commence secure communication on application level. The SSL handshake protocol is responsible for selecting the ciphers that will be used, the authentication of the client and server and for the creation and secure submission of the pre-master key which will be used for the creation of two session keys and two MAC keys that will be used. Since HTTP operates over the SSL protocol, every HTTP transfer will take place on a higher level than the one we will describe here and thus will be secure.
At this point, the handshake is complete and the C and S may begin
to exchange securely application layer data. The two symmetric
keys that will be used for the bulk encryption have been created
from the server and the client using the pre-master key, according
to the SSL process. Furthermore, the pre-master key has been used
to create the two MAC keys.
The cornerstone of the security scheme presented in this paper
is the use of digital signatures. The legal recognition of the
digital signature concept is now emerging in a number of European
Union Member States [20], as well as in other countries (e.g.
US, Canada, etc.) and it is expected to be completed in the next
few years. Furthermore, the medical data that is transferred through
the Web is protected by the European Convention on Human Rights,
[21] and by the Recommendation on the Protection of Medical Data
[22]. In addition, and in the case of European union, TTPs functionalities
and operation must meet the requirements set for by the EU Data
Protection Directive.
TTP services and functions have been implemented and provided. The public and private keys used in authentication were RSA keys of 1024 bits (CA signing key) and 512 bits for the Server and user keys. The encryption algorithm used was RC4/40 [23]. The MAC algorithm used was MD5 [24]. Speed loss in transferring data due to encryption is inevitable. However, the level of speed loss that has been observed was not obstructing the provision of TTP services. Should the volume of transactions provoke an increase in the level of speed loss, there are several alternatives to be considered (e.g. hardware-based encryption, server load-balancing).
The security scheme presented in this paper is based on open specifications (HTTP, LDAP, SSL v3, X.509v3, PKCS7) and therefore provides interoperability with most of the clients and servers operating in the Web-environment. Moreover, for the software that was used (Web Servers, Directory Servers, Certificate Servers), interoperable versions exist for a variety of operating systems, such as Microsoft Windows NT, Solaris and Linux.
The infrastructure required from a client in order to access medical applications securely is merely a Web browser, an Internet connection and a registration to the Certificate Authority. The internal organisation of the Directory is a matter that should concern the implementors of each different medical application. It should be noted that human interference is required in certain steps of the operation of a TTP, such as the issuance or the revocation of a certificate, before it's expiration.
The quality of services provided by a TTP depends on the existence of a Help Desk and the implementation and use of standard procedures for the TTP operation. Administrators were available at any time in order to provide assistance in using the services provided by the TTP. Another factor that contributed to the quality of services provided was the availability of documentation to the end-users and the automation of several procedures pertinent to the services these users were requesting. The distributed nature of the Directory, which was used as a repository for identification and authentication information, rendered this TTP Security Architecture expandable. The addition of new users, Servers or administrators in the Security Architecture has proven to be an easy task that can be partially automated. In order to exploit the security services of a TTP, implementing them would not be enough; the medical personnel that will use these services has to be convinced of their necessity and eager to familiarise themselves with using them.
A TTP site has to invest on hardware equipment (Servers), software
modules for the TTP and an Internet connection through a leased
line at least of 512 Kbps. The end-users need only their standard
computer equipment, plus a dialup or leased line connection to
the Internet and a Web browser. The medical organisations that
will deploy healthcare applications and provide related services
to healthcare professionals and patients should also be equipped
with the necessary hardware (Server), software modules (Web Server
and medical application) and an Internet connection through a
leased line of at least 512 Kbps. As far as the TTPs and the medical
sites are concerned, the cost of upgrading the hardware equipment,
when needed, and the cost of training their personnel in the use
and administration of the TTP, should be also considered.
Trusted Third Party services based on SSL provide a viable solution for deploying secure medical applications over the Web, allowing patients and healthcare providers to communicate securely. Should a healthcare institution decide to adopt the TTP solution as a security service provider, wide-scale tests should be performed before the deployment of medical services. The objective of these tests must be to identify and provide solutions for problems that may arise in a wide-scale deployment of healthcare services. Problems that may emerge include the organisation of the security provisions and the definition and implementation of access control lists, depending on the needs of the medical organisations, healthcare professionals and patients that will use the aforementioned medical services.
The United States export policy restricts export of cryptography technologies to countries outside the United States. This obstacle is currently being surpassed as encryption modules, delivering strong encryption, are already emerging in the European market. The open architecture that characterises Trusted Third Party solutions renders them capable of incorporating these new modules, and thus augment the level of security they provide.
The proposed TTP-based security architecture provides the means to secure transactions over the Web. However, one should consider the fact that the security scheme applied in this case is capable of securing other Internet transactions as well, such as Java-based transactions, e-mail exchange, telnet and ftp sessions. The Java security scheme is evolving in order to take advantage of the security provisions of digital signatures. The use of TTPs and digital signatures has already been incorporated in the security scheme applied in e-mail transactions through S/MIME and research is currently performed for securing the telnet and ftp sessions by exploiting the services provided by TTPs and digital signatures.
In conclusion, TTPs can be considered as security solution carriers
for most of the Internet services, and particularly for Web-based
medical applications. This potential of the TTPs may also provide
security solutions in other communication platforms, such as in
X.400.
[1] Smeets, B., Johansson, T. (1997) Secure Storage and Retrieval in Medical Information Systems (Lund: Lund University Press)
[2] Spinellis, D., Gritzalis, S., Iliadis, J., Gritzalis, D., Katsikas, S., et al. (1997) Trusted Third Party Services for Healthcare in Europe, DGXIII/INFOSEC Project 20820 EUROMED-ETS final deliverable
[3] International Standards Organisation ISO/TC97 7498-2 (1988) Information Processing Systems - OSI Reference Manual Part 2: Security Architecture (Geneva: ISO)
[4] Gritzalis, S., Spinellis, D. (1997) Addressing Threats and Security Issues in World Wide Web Technology, in Proceedings of the 3rd IFIP International Conference on Communications and Multimedia Security, (S.Katsikas Ed.) 33-46 (London: Chapman & Hall)
[5] Meyer, K., Schaeffer, S., Baker, D. (1995) Addressing Threats in World Wide Web Technology, in Proceedings of the 11th IEEE Annual Computer Security Applications Conference, 123-132 (Los Alamitos: IEEE)
[6] Brown, A., Gray, G., Lambert, O., Muller, P., Castell, S., Balouet, V., (1993) User Requirements for TTP services, DGXIII/INFOSEC Project S2101 S01 deliverable
[7] Rensburg, A., Solms, B. (1997) A Comparison of Schemes for Certification Authorities, Proceedings of the IFIP SEC'97 International Information Security Conference, 222-240 (London: Chapman & Hall)
[8] Zimmermann, P. (1995) PGP Source Code and Internals (Cambridge: MIT Press)
[9] Millen, J., Neuman, C., Schiller, J., Saltzer, J. (1987) Kerberos Authentication and Authorization system, Project Athena Technical Plan, Section E.2.1 (MA: MIT Press)
[10] Kent, S. (1993) Privacy Enhancement for Internet Electronic Mail: Part 2: Certificate Based Key Management, Request For Comments RFC 1422
[11] TESTFIT - TTP & Electronic Signature Trial for Inter-modal Transport (1995) DGXIII/INFOSEC Project S2303, Final deliverable
[12] MasterCard, Visa (1996) Secure Electronic Transaction Specification, Book1: Business Description
[13] Muller, P. (1993) Functional Model of Trusted Third Party Services, DGXIII/INFOSEC Project S2101 S03 deliverable
[14] CCITT (1988) Recommendations X.500-X.521, Data Communication Networks Directory (Geneva: CCITT)
[15] Yeong, W., Howes, T., Kille, S. (1995) Lightweight Directory Access Protocol, University of Michigan, ISODE Consortium, Request For Comments RFC 1777
[16] Freier, A., Karlton, P., Kocher, P. (1996) http://home.netscape.com/newsref/std/SSL.html
[17] Michigan University Research Team (1997) http://Web.umich.edu/~dirsvcs/ldap/
[18] CCITT Blue Book (1988), Recommendation X.509 and ISO 9594-8, Information Processing Systems - OSI - The Directory Authentication Framework (Geneva: CCITT)
[19] RSA Data Security Inc. (1995) S/MIME Implementation Guide, Interoperability Profile, Ver.1. (Massachusetts: RSA Inc.)
[20] European Commission COM(97)503 (1997) Ensuring Security and Trust in Electronic Communication: Towards a European Framework for Digital Signatures and Encryption (Brussels: DG XIII)
[21] Council of Europe (1981) Convention for the Protection of individuals with regard to automatic processing of personal data, Convention No. 108 (Strasbourg: CoE)
[22] Council of Europe Recommendation R(97)5 (1997) On the Protection of Medical Data (Strasbourg: CoE)
[23] Rivest, R. (1992) The RC4 Encryption Algorithm, RSA Data Security, Inc. (Massachusetts: RSA Inc.)
[24] Rivest, R., Dusse, S. (1992) The MD5 Message-Digest Algorithm, Request For Comments RFC 1321