An authentication architecture for healthcare information systems

Health Informatics Journal http://jhi.sagepub.com

An authentication architecture for healthcare information systems C. Chousiadis, I. Marvridis and G. Pangalos HEALTH INFORMATICS J 2002; 8; 199 The online version of this article can be found at: http://jhi.sagepub.com/cgi/content/abstract/8/4/199

Published by: http://www.sagepublications.com

Additional services and information for Health Informatics Journal can be found at: Email Alerts: http://jhi.sagepub.com/cgi/alerts Subscriptions: http://jhi.sagepub.com/subscriptions Reprints: http://www.sagepub.com/journalsReprints.nav Permissions: http://www.sagepub.com/journalsPermissions.nav

Downloaded from http://jhi.sagepub.com at PENNSYLVANIA STATE UNIV on April 14, 2008 © 2002 SAGE Publications. All rights reserved. Not for commercial use or unauthorized distribution.

06Chousiadis (bc/dk)

12/2/02

9:33 AM

Page 199

An authentication architecture for healthcare information systems C. Chousiadis, I. K. Mavridis and G. I. Pangalos

The medical community is moving towards an environment where automated patient medical records and electronically interconnected healthcare facilities are prevalent. The primary reason is that the electronic healthcare record, coupled with the electronic networking of hospitals, can provide healthcare organizations with more efficient, seamless service, resulting in higher quality care and reduced costs. The information contained in electronic records is an important and valuable asset of a healthcare organization. Thus, it needs to be protected to ensure its confidentiality, integrity and availability. A critical point in security is to set up efficient and flexible access control policies and procedures for protecting information. However, user authentication remains a prerequisite for really secure information services especially in distributed systems. In this paper, an authentication architecture for healthcare environments is presented. The proposed authentication architecture is based on a particular authentication protocol, which exploits the benefits of symmetric and asymmetric cryptography in order to provide a simple and selfconfident authentication system. Keywords Communication security, authentication architecture, security protocols, encryption, authentication

INTRODUCTION C. Chousiadis I. K. Mavridis G. I. Pangalos Informatics Laboratory Computers Division Faculty of Technology Aristotle University Thessaloniki 54006, Greece Emails: [email protected] [email protected] [email protected] Correspondence to: Costas Chousiadis

Healthcare organizations face security threats from a wide range of sources and are vulnerable to attacks such as those from computer viruses, hacking and denial of service. Information security provided by technical means is not sufficient and needs to be supported by policies and procedures. Security policies are the foundation and the bottom line of information security in a healthcare organization;

Health Informatics Journal (2002) 8, 199-204 © SAGE Publications Ltd, 2002.

a well-written and implemented policy contains sufficient information on what must be done to protect the organization’s data. According to the Health Insurance Portability and Accountability Act [1] and ISO 1779 [2], which is based upon BS7799, authentication mechanisms are defined as part of the security policy that a healthcare information system should follow. The distributed nature of the healthcare delivery system suggests the need for authentication mechanisms that are not location or machine dependent. That is, the technology used to assure the identity of a specific user must offer the flexibility to allow that user to gain access to information from remote locations. System specifications should make provisions to allow authorized users multiple points of access using a standard mobile identification credential [3]. In this paper, we propose an authentication architecture for healthcare information systems and an underlying authentication protocol that exploits the benefits of using modern cryptographic techniques [4]. The architecture focuses on the authentication of users who request access to the resources of a healthcare information system through the fixed network or the Web.

SECURITY CHARACTERISTICS OF HEALTHCARE INFORMATION SYSTEMS Healthcare information systems (HIS) are characterized by the need to support specific requirements for the protection of personal and medical patient data usually stored in distributed database systems due to the increased mobility of the patient populations. As a result, a patient’s computerized medical information is accumulated in a variety of locations and it may be accessed via remote workstations and complex networks supporting one or more organizations [5]. A critical point concerning the security of healthcare information systems is the assurance of patient privacy by restricting access to the medical record (especially sensitive information) to authorized users only. This concern becomes more and more important in distributed environments. However, the increased risk in this case does not come so much from transmitting the information through the network, where strong encryption algorithms can be used sufficiently, but from the huge number of users requiring access and the difficulty in verifying their identity and evaluating their clearance to do so. Security of HIS requires the use of special security policies that are able to preserve all three security components at the same time:



200

12/2/02

9:33 AM

Page 200

Health Informatics Journal

confidentiality, integrity and availability [6]. An efficient access-control system must ensure that legitimate users of a computer system cannot access system resources (stored data, software etc.) unless they have been authorized to do so [7]. However, the quality of the protection provided by an access control system depends mainly on the underlying authentication infrastructure being in use. Authentication is the process where a user establishes a right to an identity: in reality, the right to use a name. There are a large number of techniques that may be used to authenticate a user, for example passwords, biometric techniques, smart cards and certificates. Recent efforts to provide authentication mechanisms in distributed applications rely on public-key cryptography and digital certificates.

AUTHENTICATION REQUIREMENTS IN HEALTHCARE ENVIRONMENTS An authentication infrastructure for healthcare environments must include a number of measures and services to preserve security in respect to specific requirements. As stated in [8], among other things an authentication infrastructure must ●

● ●

●

●

include the use of trustworthy systems and products which are protected against modification demonstrate the reliability necessary for providing certification services ensure the operation of a prompt and secure directory and a secure and immediate revocation service verify by appropriate means in accordance with national law, the identity and, if applicable, any specific attributes of the person to which a qualified certificate is issued record all relevant information concerning a qualified certificate for an appropriate period of time, in particular to provide evidence of certification for legal purposes.

Another crucial aspect of an authentication architecture is the use of a proper secure authentication transmission protocol. The selection of a proper authentication protocol is a key aspect concerning the security of the transmitted data and the authentication of the communicating entities. Thus, the development of an authentication protocol, which requires all the advantages of the state-of-theart technologies (architectural components, e.g. identity certificates) covers a significant part of this paper. Consequently, in our © SAGE Publications Ltd, 2002.

approach we defined a different implementation of the conventional certification services provided in a public-key infrastructure (PKI) for all the 10 reasons stated in [9]. In summary, [9] argues that the problems of the PKI exist because of the use of the low level of identification and because of the terms Registration and Certification ‘Authorities’. For example, why is a CA an ‘authority’? Why trust the CA? What about the security of the server of the CA? How can we be sure that the personal data that someone sends electronically to the RA is the true one? And so on. Furthermore, according to Microsoft, someone posing as a Microsoft employee tricked VeriSign [10], which issued him a valid certificate, but with invalid personal information. Hence, we propose to use the PKI technology but instal it locally, meaning that a department within the healthcare organization is actually the authority that identifies the users and issues identity certificates. We also developed a different implementation of PKI, as illustrated in the following sections. The authentication architecture which is proposed in this paper is based on a specific underlying authentication protocol presented below.

THE UNDERLYING AUTHENTICATION PROTOCOL The proposed Healthcare Authentication Protocol (HAP) has been designed according to the authentication requirements of healthcare information systems. A representation of the authentication protocol is depicted in the UML collaboration diagram shown in Fig. 1 [11]. HAP is a two-way mutual authentication protocol, in contrast to the three-way protocols used in common for such a purpose [12]. As a result, it is fast enough in contrast to three-way protocols, a characteristic that is very useful not only in fixed but especially in wireless communication systems. More specifically, in Fig. 1 we used the following symbols: ● ●

● ● ●

M1 and M2 stand for messages 1 and 2 respectively Text1 and Text2 are text messages that could include a ‘user hello’ and ‘server hello’ respectively EAK1 and ESK3 denotes encipherment with AK1 and SK3 respectively. SMK UC stands for user’s certificate signed by the master key VerUC means the result of verifying the



12/2/02

9:33 AM

Page 201

An authentication architecture for healthcare information systems

201

Asymmetric key 1

Fig. 1 Graphical representation of the authentication protocol

● ●

integrity and authenticity of user’s certificate (a Boolean value) AS is the name of the authentication server NA, NB are nonces, which are used for freshness checking.

During the process of mutual authentication, each party holds the following keys: ●

●

User: symmetric master key (MK), symmetric key 3 (SK3), asymmetric key 1 (AK1) Authentication server: symmetric master key (MK), asymmetric key 2 (AK2).

Keys AK1 and AK2 belong to the same pair of RSA that are generated and stored in the user’s smart card.

The asymmetric key 1 (AK1) is used to encipher the user’s certificate, as well as other types of data that are used by the authentication protocol that is described in subsequent sections. The encipherment of the user’s certificate takes place in the smart card of the user. The AK1 is stored in the user’s smart card and of course it is not shared.

Asymmetric key 2 The asymmetric key 2 (AK2) is used to decipher the data received at the server’s side. These data have been enciphered at the user’s side before they sent. The AK2 is stored in a secure place in the server’s hard disk and it is not shared.

Symmetric key 3 The symmetric key 3 (SK3) is a symmetric key, which is shared between the user and the server. Its lifetime is session-dependent and it is generated in the mobile device by using the master key. We use session keys in order to protect the system’s basic keys (that is, the master and asymmetric keys). The less that we use the basic keys the better the protection of the keys.

TYPES OF KEY USED The encryption process is applied on the data exchanged between a client (user) and a server (e.g. an authentication server). All the four types of key are involved in this process, as described in the following paragraphs.

Master key The Master Key (MK) is a symmetric key that is shared between the server and the client. On the client’s side it is stored into the smart card of the particular user and cannot be extracted in any way. It is also stored in a secured place on the server’s hard disk. The MK is used for digitally signing with an appropriate hashing algorithm the digital certificate of the user in order to preserve integrity and authenticity of the data that compose the X.509 formatted (except the public key) certificate. The signing process must take place within the smart card of the user by exploiting the processing power of the card’s microprocessor for maximum security. Using symmetric encryption for signing purposes (and not asymmetric as is usual) saves processing power. As a result the process is fast enough, given the weak microprocessors that are so far used in smart cards. © SAGE Publications Ltd, 2002.

THE AUTHENTICATION PROCESS The authentication process includes two different ways of exchanging data: from client to server and vice versa. However, an initial phase includes the generation of the SK1 session key.

Generate the session key User generates key 3, which will be used as a session key. The master key is used in order to generate the symmetric key 3 as stated above.

Client to server User sends a Hello message followed by the encrypted certificate (signed with master key) and the encrypted session key (SK3). For the above encryptions RSA-AK1 is used. The message ends with a ‘Finished’ statement. The certificate of the user is signed at the client’s side with the MK. Subsequently, the user’s certificate along with other data-like nonces, which are required by the authentication protocol, is enciphered using the AK1. On the



202

12/2/02

9:33 AM

Page 202


other side, the server receives the encrypted message and uses AK2 to decrypt it and the MK to verify the integrity and authenticity of the user’s certificate with an appropriate hashing algorithm.

Indeed:

Server to client

●

Server decrypts the message with asymmetric key 2 (AK2) (the second RSA key), verifies the certificate (master key) and checks the revocation list, if the certificate is not revoked then the server sends a verification message and a ‘Finished’ statement. An application request by the user is now expected or else the connection breaks. The server uses only the session key SK3 to encrypt any subsequent message to be sent to the client.

PROTOCOL VALIDATION The validation of the protocol is crucial in order to prove its security. A well-known method for security protocol’s verification is BAN logic. The following verification has been performed according to BAN logic [12] [13].

At the client side After the completion of an authentication process according to the proposed protocol, the user wants to be sure that: ● ● ● ●

M2 was sent by the AS M2 is fresh M2 was intended for user The AS generated M2 after the completion of M1.

Indeed: ● ● ●

●

The encryption by using the AK1 proves it It is fresh since because of the inclusion of the nonces NA and NB It was intended for the user since it contains the verification of its certificate encrypted with the session key Again the session key proves that M2 generated after the completion of M1.

At the server side After the completion of the protocol the server wants to be sure that: ● ● ● ● © SAGE Publications Ltd, 2002.

M1 was sent by the user M1 is fresh M1 was intended for user The user generated M1.

●

●

●

The inclusion of the encrypted and signed certificate proves that the user sent the message It is fresh since because of the inclusion of the nonces NA The inclusion of the authentication server’s name proves that the message was intended for it After the decryption and verification of the certificate it is proven that the User generated the M1.

THE PROPOSED AUTHENTICATION ARCHITECTURE The proposed authentication architecture exploits the benefits of state of the art security technologies available today, like PK1, smart cards and strong encryption techniques. A public-key infrastructure (PK1) supports the issuance and management of digital certificates suitable for identification and authentication purposes. Smart cards, on the other hand, represent the latest and more secure storing token that an identity could carry with it and use in order to identify itself. Strong encryption is a must today since a great part of the implementation of security of distributed computer systems relies on it. In the proposed authentication architecture, all users are treated as ‘mobile users’. A mobile user is working either outside the fixed network using a mobile host or inside the fixed network using a fixed or mobile host. The proposed authentication architecture consists of two phases: ● ●

Phase 1: user registration Phase 2: mutual authentication.

Phase 1: User registration In the proposed authentication architecture the presence of a PK1 either embedded in the healthcare information system or securely connected to it is assumed. The healthcare Certification Authority must also be able to physically identify users. A user visits a registration service (RS) and provides the required proofs of personal information in order to apply for a digital certificate (X.509). Subsequently, the RS office passes the personal information of the user to the certification service (CS) offices. The CS office generates a smart card containing the identity certificate of the user, the master key and one of the asymmetric pair of keys. The smart card



12/2/02

9:33 AM

Page 203

An authentication architecture for healthcare information systems

is forwarded to the end service (ES) office and is physically given to the user along with the PIN number of the card. The user again provides proofs of identity in order to obtain the smart card. The registration process is shown in the UML diagram of Fig. 2.

Fig. 2 User registration

Phase 2: Mutual authentication In order for the user to authenticate himself to the authentication server (AS) of the healthcare information system, the CS sends the user’s MK (for signature verification) and the AK2 (for decryption of the initial protocol’s message) to the AS where it is stored in a secure place.

203

without using server-side certificates and signing verification on the client side. Another aspect that could be considered as an advantage is that the encryption of the data is processed within the smart card [14] providing an extra security measure, considering that since the communication channel may be encrypted, the vulnerable areas, from the attacker’s point of view, are the terminals e.g. desktop terminal or mobile devices. So, with this measure we guarantee the safety in terms of integrity of the certificate and confidentiality of the exchanged messages. We keep the computation processes at a stage that today’s smart card technology can very easily handle and also with good time performance. Moreover, the certificate is transmitted encrypted by using the asymmetric key just once. Finally, the authentication architecture and particularly the secure communication protocol that we propose are protected from the well-known ‘Man in the middle attack’ due to the lack of any kind of key exchange between client and server, as happens with the Diffie–Hellman key exchange method. The authentication protocol is quite fast in processing (e.g. two-way handshake instead of three-way usually used). Hence, it is suitable for both fixed or wireless communication systems.

ADVANTAGES The proposed authentication architecture does not make use of the classical public-key infrastructure (PKI). As a consequence, the vulnerabilities of PK1 are avoided, since client–server certificates are not used as in the conventional PK1 and the authority of the RS office is proven. Moreover, we choose to avoid in general the use of ‘CA certificates’ because it is easy to have impersonation problems. Since we physically obtain our certificate there is no better proof of the integrity of certification service. Furthermore, there is no need for the CA to sign the user certificate since the certificate does not travel along the Internet. Hence, there is no problem with the integrity and the origin of the certificate. In addition, by not using signed certificates we again earn time and process power in contrast with other security protocols that require the user to verify the validity of the server’s certificate, like SSL/TLS. The asymmetric cryptography is used in a different way, as is already mentioned, so that there is no need for the user to obtain any kind of certificate from the server side for authentication purposes during the handshake protocol. Moreover, mutual authentication is achieved © SAGE Publications Ltd, 2002.

CONCLUSION Security is an important issue in healthcare environments where large amounts of highly sensitive personal data are processed. It is therefore important that the security requirements for availability, integrity and confidentiality are taken into account as main design objectives when designing a distributed healthcare information system. In this paper, an authentication architecture that provides the appropriate mechanisms and guidelines to exploit particular technologies in establishing authentication system for specific environments (e.g. the healthcare one) is proposed. The authentication architecture fits the needs of healthcare environments, as well as any other environment wherein actual user authentication (interorganizational communication) is required. Furthermore, an authentication protocol that is based on the above concepts has been presented, and its functionality verified. The authors are currently working on the implementation of the proposed infrastructure and the underlying authentication protocol.



204

12/2/02

9:33 AM

Page 204


REFERENCES [1] Sato M M. HIPAA security policy developments: a collaborative approach, 2001. http://www.sans.org/infosecFAQ/ policy/HIPAA_policy.html [2] ISO 17799. http://www.network-and-it-security-policies. com/iso17799.htm [3] The national healthkey collaborative. Securing the exchange and use of electronic health information to improve the nation’s health. A summary report to the community, September 2001. http://www.healthkey.org [4] Stallings W. Cryptography and network security: principal and practices. 2nd edn. Prentice Hall, 1995. [5] Mavridis I, Pangalos G, Khair M, Bozios L. Defining access control mechanisms for privacy protection in distributed medical databases. In: Proceedings of IFIP Working Conference on User Identification and Privacy Protection, Stockholm, June 1999. [6] Pangalos G, Khair M. Design of a secure medical database systems, in IFIP/SEC’96, 12th International Information Security Conference, 1996.

© SAGE Publications Ltd, 2002.

[7] Castano S, Fugini M, Martella G, Samarati P. Database security. Addison Wesley, 1994. [8] Pangalos G, Mavridis I, Ilioudis C, Georgiadis C. Developing a public-key infrastructure for a secure regional e-health environment. Methods of Information on Medicine: Special issue on Regional Health Information Networks and Telematics applications in a user friendly information society. 40: Forthcoming. [9] Ellison C, Schneier B. Ten risks of PK1: what you’re not being told about Public Key Infrastructure 2000; XVI (1): 1-7. [10] http://news.cnet.com, 2001. [11] UML. Unified Modelling Language Notation Guide version 1.1, Rational Software Corporation, September 1997, http: //www.rational.com/uml [12] Ciechanowicz C. Network Security-IS3, MSc in Information Security Course Notes, Information Security Group, 1999. [13] Burrows M, Abadi M, Needham R. A logic of authentication, 1999. http://www.research.digital.com/SRC/personal/ Martin_Abadi/Papers/src39-revised.ps [14] http://www.gemplus.com, 2001.
