Access-rule certificates for secure distributed healthcare applications ...

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

Access-rule certificates for secure distributed healthcare applications over the Internet I.K. Mavridis, C.K. Georgiadis and G.I. Pangalos HEALTH INFORMATICS J 2002; 8; 127 The online version of this article can be found at: http://jhi.sagepub.com/cgi/content/abstract/8/3/127

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 February 6, 2008 © 2002 SAGE Publications. All rights reserved. Not for commercial use or unauthorized distribution.

03 Mavridis (bc/d)

28/11/02

10:47 am

Page 127

Access-rule certificates for secure distributed healthcare applications over the Internet I. Mavridis, C. Georgiadis and G. Pangalos

Access control in medical information systems distributed over the Internet is an important issue directly related to the protection of patients’ privacy. It is therefore essential to satisfy the increasing demand for exploiting Internet mechanisms in order to achieve a secure health information network. This can only be done, however, if it can be guaranteed that appropriate measures have been taken to preserve a satisfactory level of security for the information concerned. Recent efforts in this direction rely on public-key cryptography and digital certificates. Identity certificates are suitable for identification and authentication purposes. In addition, attribute certificates are another type of certificate particularly suitable for authorization purposes. In order to fully exploit digital certificates to protect distributed healthcare applications over the Internet, we propose the use of a third type of certificate, called access-rule certificates, which are useful for the enforcement of global access-control mechanisms between different organizations. In this paper, we present the structure of those three types of certificate, as well as the access-control procedures when using them; we describe the architecture of the proposed system whose purpose is to explore the use of certificates for the implementation of a suitable security policy for healthcare environments. Keywords Computer security, medical database security, distributed access control I. Mavridis, C. Georgiadis and G. Pangalos Informatics Laboratory Computers Division Faculty of Technology Aristotle University of Thessaloniki 54006 Thessaloniki, Greece. Email: [email protected], [email protected], [email protected]

INTRODUCTION The increased mobility of patient populations and changes in the structure of healthcare information systems have resulted in a

patient’s computerized medical information being accumulated in a variety of locations. Today’s healthcare environments use clinical electronic records usually containing data that are shared between source systems involved in healthcare distributed applications, in order to provide information to internal users as well as external requests, payers, and so on. Data may be accessed via remote workstations and complex networks supporting one or more organizations, and potentially within a national information infrastructure [1]. The Internet provides unprecedented opportunities for interaction and data sharing among doctors, patients, researchers and healthcare establishments (HCEs). After years of struggling with the limitations of proprietary technologies, health services organizations have finally obtained the means of establishing a more ubiquitous and seamless system. Internet technologies therefore offer an attractive infrastructure for efficient communications of medical information at regional or even worldwide level. However, the advantages provided by the Internet come with a significantly greater element of risk to the confidentiality and integrity of information. Because the Internet’s underlying protocols were not designed with security in mind, the main objective has been to optimize information sharing and interoperability [2]. On the other hand, to attract and retain users, a Healthcare Information System (HIS) must be trusted. Security has therefore become a major concern for healthcare applications. The consequences of unauthorized disclosure or alteration of information may seriously affect a patient’s health, social standing or employment prospects [3]. The increased risk in this case does not come so much from the transmission of the information through the network, as we suppose that strong encryption algorithms can be used sufficiently: it is caused by the huge number of users requiring access and the difficulty in evaluating their clearance as well as the trustworthiness of their sites. Access control in medical information systems distributed over the Internet is an important issue directly related to the protection of patients’ privacy. To enable secure information exchange of sensitive data in an unsecured environment, such as the public Internet, a blend of technology and administrative processes of publickey cryptography and digital certificates is used. A public-key infrastructure (PKI) supports the issue and management of digital certificates suitable for identification and authentication purposes. In addition, the emerging complementary privilege management infrastructure (PMI) can provide another type of certificate that is particularly suitable for authorization purposes.

Health Informatics Journal (2002) 8, 127-137 © SAGE Publications Ltd, 2002.


03 Mavridis (bc/d)

128

28/11/02

10:47 am

Page 128

Health Informatics Journal

The general problem that is addressed in this paper is the use of certificates for widely distributed medical database systems to enforce a specific access-control policy in a flexible and automated fashion, in order to enable the sharing of sensitive personal and patient data in an open network within the healthcare community generally. Distributed healthcare systems that are geographically dispersed over wide-area networks to support data sharing in restricted collaborations give rise to a range of requirements for distributed control of access. Among other things, administration of such resources needs to be handled by an automated authorization infrastructure so that management of data availability and enforcement of access rules can be carried out automatically. Therefore, in order to fully exploit digital certificates to protect healthcare applications over the Internet, there is a need for a suitable security policy with appropriate structure, compatibility with the PKI and PMI environments [4], and the ability to be propagated within distributed systems that spread over different healthcare institutions. Such a security policy is the already-known DIMEDAC (Distributed Medical Database Access Control) security policy, which has the required structure and been proved to be particularly suitable in healthcare environments.

INTERNET ACCESS-CONTROL ISSUES The appropriate use of the Internet considerably increases the opportunity to use advanced information technology for communication among healthcare providers, patients and researchers. Nevertheless, for the Internet to become a trusted vehicle for exchanging medical data, there are a number of security issues that must be resolved. The fact that the underlying Internet protocols allow information to pass through intermediate computers introduces several vulnerabilities, such as monitoring, penetration, tampering, masquerading, subversion (of correct operation) and denial of service. Many sensitive personal and medical communications over the Internet require obvious safety measures that address the above threats. Fortunately, some well-established techniques and standards, collectively known as publickey cryptography (PKC), make it reasonably simple to take such precautions. PKC and related techniques provide encryption and decryption, tamper detection, source authentication and non-repudiation. PKC is the basis

for the development of public-key infrastructures, which are a means of enabling secure information exchange over the Internet. Healthcare institutions are increasingly interested in sharing and licensing access to information resources in the networked environment. At the same time, the pressures to make ever more information accessible via the Internet must be balanced with the enforcement of appropriate measures to provide individual privacy and reliability. Satisfactory resolution of security issues is a critical step in building trust among HIS users and the public at large [5]. Trust in HCEs over the Internet can undoubtedly be facilitated by using public-key certificates. Indeed, the establishment of recognizable and meaningful public-key certificate infrastructures for Internet-wide use has for a long time been considered a critical step in the successful establishment of a secure e-health environment. To control use of a networked resource, access-management systems make use of authentication and authorization services. Authentication is the process of ascertaining the identity of a networked user. There are a large number of techniques that may be used to authenticate a user, like passwords, biometrics techniques, smart cards and certificates. An identity has attributes associated with it. These may be demographic in nature, or they may keep permissions to use resources. Attributes are not static elements: they may change over time. Authorization is the process of determining whether an identity (plus a set of attributes related to that identity) is permitted to access a resource [6]. Authentication and authorization decisions can be made at different points, by different organizations. Traditionally application-level credentials (user ID or password) have been used intensively. More suitable in network environments, however, are the credentials which are built into protocol mechanisms, such as the use of certificates with HyperText Transfer Protocol (HTTP) and Secure Socket Layer (SSL) Internet protocols. Certificate-based credentials offer a number of advantages [6]. From the user’s perspective, they facilitate access, minimize redundant authentication interactions and provide a single sign-on, user-friendly view of the available resources. From the administrator’s viewpoint, the certificate-based approach does not require a vast amount of ongoing maintenance. Certificate-based access management provides authentication strength, making all parties feel confident and secure. It is suitable for fine-grained access control and guarantees user privacy and confidentiality. It is capable of providing user

© SAGE Publications Ltd, 2002.


03 Mavridis (bc/d)

28/11/02

10:47 am

Page 129

Access-rule certificates for secure distributed healthcare

accountability so that, if improper use is discovered, the administrator knows where to begin investigating.

IDENTITY CERTIFICATES FOR AUTHENTICATION Encryption and decryption address the problem of monitoring. However, encryption and decryption do not by themselves address the problems of tampering and masquerading. Tamper detection relies on a mathematical function called a one-way hash (also called a message digest). The encrypted hash of the data, along with other information, such as the name of the hashing algorithm, is known as a digital signature. The importance of a digital signature is comparable to the significance of a handwritten signature. Once one has signed some data, it is hard to refuse doing so later if the private key has not been compromised. This quality of digital signatures provides a high degree of integrity and non-repudiation services. Confirming the identity of the signer, however, also requires some way of confirming that the public key really belongs to a particular person or other entity. Digital identification documents called identity certificates (ICs) address the issue of masquerading. An identity certificate is an electronic document used to recognize an individual, a server or some other entity, and to connect that identity with a public key. As with a credit card, a passport or any other commonly used personal ID, a certificate provides generally recognized proof of a person’s identity. To get a passport, one typically applies to a government agency, which verifies identity, address and other information before issuing the passport. Typically, an X.509 identity certificate [7] is issued by a central authority that enjoys widespread trust within the user community, and quite possibly has to operate under tightly controlled and monitored terms and conditions. Certificate authorities (CAs) are entities that validate identities and issue certificates. An identity certificate issued by a CA binds a particular public key to the name of the entity the certificate identifies (such as the name of a doctor). Certificates help avoid the use of forged public keys for impersonation. Only the public key certified by the certificate will work with the corresponding private key possessed by the entity identified by the certificate. In addition to a public key, a certificate always includes the name of the entity it identifies, an expiration date, the name of the CA that issued the certificate and other information [7]. Most

129

importantly, a certificate always includes the digital signature of the issuing CA. The CA’s digital signature allows the certificate to be used as a ‘letter of introduction’ for users who trust the CA but don’t know the entity identified by the certificate. The structure of a X.509 identity certificate is shown in Figure 1.

ATTRIBUTE CERTIFICATES FOR AUTHORIZATION Recent research and development efforts have resulted in a second kind of digital certificate, known as the attribute certificates [8][9][10]. An attribute certificate (AC) is a data structure comparable to an IC. Still, there is a major difference: an AC contains no public key. It contains attributes that specify access-control information associated with the AC holder (like group membership, role, security clearance, and so on). Attribute certificates are able to support and implement a significant part of the authorization process. The basic idea is that not all access-control decisions are identitybased. Role-based, rule-based and rank-based access-control decisions require additional information. For example, information about a user’s current role (e.g. physician) or a client’s ability to pay may be more valuable than the client’s identity for a resource access. In an AC, attributes also need to be protected, in a fashion similar to an IC. ACs provide the required protection because they are simply digitally signed sets of attributes. Attribute authorities (AAs) are the authorities or entities trusted by one or more users to

• • • • • • • • • •

version certificate serial number signature algorithm ID issuer name validity period subject name subject public-key info issuer unique ID subject unique ID extensions

Signature

Fig. 1 Identity certificate



03 Mavridis (bc/d)

130

28/11/02

10:47 am

Page 130


create and sign attribute certificates [8]. Just like CAs, AAs are responsible for their certificates throughout their lifetime, not only for issuing them. The structure of an AC is shown in Figure 2. The AC format allows any non-identitybased authorization information to be bound to an IC by including, in a digitally signed data structure, a reference (linkage) back to one specific IC. The attributes field gives information about the AC holder. When the AC is used for authorization this will often contain a set of privileges. The attributes field contains a sequence of attributes. Each attribute may contain a set of values. For a given AC, each attribute type in the sequence must be unique. That is, only one instance of each attribute can occur in a single AC, but each instance can be multi-valued and must contain at least one attribute [8]. When making an access-control decision based on an AC, an access-control decision function may need to ensure that the appropriate AC holder is the entity that has requested access. One way in which the linkage between the request and the AC can be

• •

version holder

•

base certificate ID entity name object digest info issuer

• • • •

issuer name base certificate ID object digest info signature algorithm ID certificate serial number validity period attributes attribute type

values

Signature

Fig. 2 Attribute certificate

achieved is if the AC has a reference to an IC for the requester and that IC has been used to authenticate the access request. While AC time/validity requirements allow both long-lived and short-lived ACs, typical validity periods for ACs might be measured in hours, as opposed to months and years for ICs [8]. Moreover, short validity periods allow ACs to be useful without a revocation mechanism. This approach allows access permissions to be changed in a relatively receptive way.

ENFORCING A COMMON ACCESS-CONTROL POLICY Traditionally, authorization policies have been expressed and managed in a relatively centralized manner: one person or organization administers and enforces the access-control requirements. In large distributed systems, however, centralized administration of access rights is a very difficult task. In many cases, policy control has to be decentralized. In distributed computing environments, as in the healthcare ones, there may be multiple, independent and geographically spread entities (individuals, organizations, institutes, notaries, etc.) with authority to control access to their local resources. Each of these parties is responsible for defining access rules for the protected resources and brings its own set of concerns. Therefore, access-control systems might allow administrative authority for a specified subset of objects to be delegated by the central security administrator to other security administrators. For example, authority to administer objects in a particular region can be granted to the regional security administrator. Control over the regional administrators can be centrally administered, but they can have considerable autonomy within their regions. This process of delegation can be repeated within each region to set up sub-regions and so on [11]. In such a context, global and local accesscontrol mechanisms could be used for large, distributed healthcare systems. As proposed in [12], global roles could be authorized with global permissions to access an Intranet’s resources based on different local roles in different servers (sites). This assumption, however, introduces lack of flexibility (for example, regarding the granularity used when defining the permission sets) and similar behaviour of the access-control system on local and remote access requests. Our proposal is to define separately each subject and its permission set to access remotely any defined object of the system.



03 Mavridis (bc/d)

28/11/02

10:47 am

Page 131


This approach creates the need for appropriate security policies for distributed healthcare environments that are based on the enforcement of a minimum common definition and distribution of the particular accesscontrol mechanisms and rules, which may include specific role hierarchies, clearance levels or a core of access rights. In the Internet environment, such control information could be stored in special purpose servers, known as security servers. In addition, to secure, transmit and use it we propose the use of a third type of certificate to operate as digitally signed statements for the enforcement of a common access-control policy. What follows is a description of a paradigm using the three types of digital certificate to protect distributed healthcare applications over the Internet. The security policy used is our already-known DIMEDAC security policy, which conforms to the above requirements and has also been proved to be particularly suitable in healthcare environments. An important characteristic of the DIMEDAC security policy is that it enables policy enforcement within large-scale distributed systems that spread on different healthcare institutions, which are operating in multi-level administrative domains and under the principles and regulations of a common high-level security policy. The corresponding sets of global entities and authorization rules are defined according to a particular methodology. As a result, DIMEDAC provides an adequate level of protection for global objects that are accessed by global subjects in a predefined manner.

DIMEDAC: A SECURITY POLICY FOR DISTRIBUTED HEALTHCARE ENVIRONMENTS The DIMEDAC security policy provides a differentiated role-based authorization mechanism for accessing medical records, depending on the particular need-to-know requirements of users that form the user location. Furthermore, it supports both the mandatory and discretionary approaches, as it has been already demonstrated in [13][14][15], in order to apply a satisfactory security policy for access control in medical database systems, able to preserve the availability, integrity and confidentiality of the overall system [16]. The following are some major characteristics of the DIMEDAC security policy, which are particularly useful for distributed access control through digital certificates.

131

Location control In large HCEs, there is a significant turnover of staff as doctors, nurses and research students undertake rotations in each of the different departments and clinics. User identification and authorization becomes burdensome in such situations. In distributed medical database systems, especially, it is often critical to control the location from which users’ access requests are coming. A user location can be viewed as dependent on the following parameters: ●

●

●

site, which could be a workstation (including the hardware, software and network connection) from which a user logs into the system. It can be of any size or computational power and connected by either cable or wireless administrative domain, which is a part of an organization where a unique administration policy is in effect [17]. Possible types of administrative domain in medical applications might be (in generalization order): clinic, department, hospital, national, international (such as European Union). Administrative domains may include other administrative domains and/or groups of sites living space, which differentiates dynamically the need-to-know requirements of users in order to accomplish their tasks. The need-to-know requirements of users such as doctors are strongly dependent on the specific patients they take care of. There is therefore a need for fine-grained access privileges that must be given to them in order to access the medical records of their patients. The patient identification code could be used as a global location parameter (for example, the patient charged to the doctor who is trying to access remotely the database), given that a unique code identification system is in effect.

Access-control mechanisms The access-control mechanisms of the DIMEDAC security policy consist of hypernode hierarchies for user roles, datasets and user locations respectively, as well as sets of user location-dependent authorization rules. Hyper-node-hierarchies (HNHs) are used as normal role hierarchies [18] for permission inheritance, as well as for derivation of security labels (consisting of a security level and a set of categories), due to the two types of connections used between nodes [19]. An example of a HNH is shown in Figure 3.



03 Mavridis (bc/d)

132

28/11/02

10:47 am

Page 132


A

Level 5

B

C

D E

F

G I

J

Level 3

H

Level 2 L

K

Level 4

Where:

L

Level 1

is a hyper node is a dummy node is a branch is a link

Fig. 3 Hyper-node-hierarchy (HNH)

The mechanism of HNH is used to construct the appropriate user role, dataset and user location hierarchies for a particular application: ●

●

●

the user-role hierarchy (URH) consists of nodes that represent the user roles in the specific organization, placed at their corresponding classification levels. The number of levels in URH is predefined depending on the granularity of the control needed the dataset hierarchy (DSH) consists of nodes that represent the datasets of the application, placed at their corresponding sensitivity levels. The number of levels in DSH is also predefined the user-location hierarchy (ULH) is a means of representing the organizational structure of the healthcare establishments involved in the application.

For access-control purposes in widely distributed information systems with multi-level administrative domains, we propose the use of global and local user roles, datasets and user locations. As a result, the activation of a global user role forms the ability of the user to access a number of datasets in another remote site. However, this fact means that every local security administrator may be able to decide about the authorization of subjects of its administrative domain on objects of other domains. It is obvious there is a need for a limit to the penetration that other administrators can do in the access control policy of each administrative domain [20]. The privileges of a given user role must therefore be reduced when acting remotely. This can be accomplished by eliminating the global user role permissions set to access the database remotely, based on user locations. To achieve

this a third dimension, concerning the user location, is introduced in the classical access matrix. The resulting access matrix is called three-dimension access matrix (3DAM) and can be implemented as multiple access matrices, one for each possible user location. The entries of 3DAM are authorization rules that can be expressed with a quadruple {UR, UL, DS, AM}. Such an authorization rule means that a user role UR in a user location UL has the authority to access a dataset DS with an access-mode AM. In the DIMEDAC security policy, datasets are defined as data views (for instance, by using the SELECT statement of the Structured Query Language or SQL). Using views in database relational models results in a viewbased protection [21]. A significant advantage of this definition is the use of a flexible granularity for the definition of objects to be protected. It is therefore easy to introduce detailed specifications of specific items such as fields, as well as more general declarations for groups of datasets (e.g. tables) in order to save storage space.

Propagation of the access-control policy According to the DIMEDAC security policy, each individual subject (global or local user role), as well as its permission set to access remotely any defined object (global or local dataset) of the system from any defined location, are explicitly defined. The huge amount of control data to be defined can be dramatically reduced by exploiting the inheritance in the already presented three types of hierarchies. To do this in the context of a multi-level hierarchy of administrative domains, a specific method for the definition of the DIMEDAC access control mechanisms has already been proposed in [16]. This method results in a combination of local and global access-control policies, which remain compatible between different organizations without sacrificing the flexibility to further define inner components and to assign more specific authorization rules. According to this methodology, the following actions should be accomplished for the definition of the access-control mechanisms (URH, DSH, ULH and 3DAM) in each administrative domain: ●

●

inheritance of mechanisms from the ancestor (upper level) administrative domain refinement of those mechanisms in order to meet the specific local needs of the particular administrative domain.



03 Mavridis (bc/d)

28/11/02

10:47 am

Page 133


• • •

AN EXAMPLE CERTIFICATEBASED IMPLEMENTATION USING THE DIMEDAC SECURITY POLICY

133

version destination issuer issuer name base certificate ID object digest info

In the proposed system, we intend to fully implement the DIMEDAC security policy by using different kinds of digital certificates. Besides the two commonly used types of certificate (identity and attribute certificates), we propose a third type that is called access-rule certificate (RC). The proposed operational architecture is then implemented in three different phases.

• • • •

● ●

user role: presents the user role, whose permissions are going to be altered dataset: presents the dataset regarding the given alteration

validity period 3DAM

role

Policy propagation: access-rule certificates

1. 3DAM: A sequence of four items that constitute a quadruple and express an authorization rule:

certificate serial number

User

•

The process of inheriting the access-control mechanisms between different levels of administrative domains is accomplished by using a third type of certificate, called AccessRule Certificate (RC). The inherited mechanisms are stored in special security servers, which in turn provide certification services to the administrative domains of lower levels. The local base of control data in every security server is updated (new entries of URH, DSH, ULH and 3DAM) by accepting and validating new access-rule certificates (according to the ‘push’ model) from security servers of upper levels, which act as access-rule authorities (RA). In a fashion similar to an AA and a CA, an RA is an authority entity trusted by one or more organizations to create and sign accessrule certificates. An access-rule certificate is a data structure comparable to that of identity and attribute certificates. It is a digitally signed document and enables policy-responsible parties to remotely and securely create and distribute access-control mechanisms and rules to authorize access to the global objects of the distributed database system. The structure of an access-rule certificate is shown in Figure 4. The format of access-control data contained in a RC depends on the overall security policy that is in force. According to the DIMEDAC policy mechanisms, an RC must encode entries relative with at least one of the following types of control data:

signature algorithm ID

•

Dataset

User

Access

location

mode

HNH HNH

node

node

parent

connection

type

name

type

node

type

Policy entities short-name

value

Signature

Fig. 4 The proposed access-rule certificate

● ●

user location: presents the valid user location access mode: presents the access mode, in other words the permitted action that the UR can exercise on the DS from the UL location.

2. HNH: the mechanism of HNH is used to construct the appropriate user role, dataset and user location hierarchies. All the three types of HNH hierarchies use the same format of stored data. An additional element is needed in order to specify which hierarchy is going to be updated. More precisely, an HNH entry in a RC must encode: ● ●

● ● ●

HNH type: URH, ULH or DSH node name: the short-name of the particular user role, user location or dataset node type: hyper or dummy parent node: the short-name of the ancestor node in the hierarchy connection type: branch or link.

3. Policy entities: for saving of disk storage, especially in the case of dataset definitions, we use short names for the policy entities used. More precisely, a policy entity may encode:



03 Mavridis (bc/d)

134

28/11/02

10:47 am

Page 134

Health Informatics Journal ● ●

short-name: the short-name of a user role, dataset or user location value: the description of the previously mentioned short-name field. Especially for datasets, the description includes a SQL statement (SELECT) that defines a particular view of the relational schema.

The distribution of access-rule certificates is performed according to the ‘push’ model, which involves the RA supplying the RCs directly to the security server (Figure 5). Having already distributed the appropriate RCs, the authentication and authorization process is performed as described below.

Definition of security credentials Initially, every user obtains his identity certificate. The procedure for the issuance of a user’s IC (Figure 6) is as follows: Step 1. The user places his identity certificate request to the local certificate authority (CA) along with his personal data that are needed for authentication purposes. Step 2. The local CA authenticates the user against the presented personal data, generates the identity certificate and issues it to the user.

Steps 1 and 2 are accomplished rarely, as an identity certificate typically has a lifetime of one or more years. When a user initiates a new session, he must first identify and authenticate himself by using his identity certificate. Then he activates a subset of user roles and locations, which form a session-dependent user profile that is recorded in a set of short-lived attribute certificates. The issuance of the user’s ACs is described in more detail as follows (Figure 6). Step 3. When the user initiates a new session, he must first identify and authenticate himself, during a SSL session with the local application server, by using his IC and his password. The validated IC of the user is then used for subsequent remote identification and authentication processes. Then the user activates a subset of user roles (URs) from a set of initially assigned roles which are needed to accomplish his specific task. The site of the user is assigned as the initial set of user locations (ULs). The set of user locations is then enriched, depending on the responsibility or authority of the roles activated by the user. EU

Greece

Hospital 1

Hospital 2

France

Italy

Sweden

Hospital 3

Access-Rule Authority (RCs issuer)

global RC issuance

URH, DSH, ULH, 3DAM Upper Administrative Domain

policy generator

URH

DSH

ULH

3DAM

Security Server

Local site (e.g. Department 1)

Fig. 5 Policy propagation © SAGE Publications Ltd, 2002.


03 Mavridis (bc/d)

28/11/02

10:47 am

Page 135


135

Fig. 6 Security credentials acquirement

During the upgrade process of the user location set, all the relative administrative domains are included, as well as the living space parameters of the user task (for example, the IDs of the patients that are charged to the user). The user’s identity along with the sets of activated user roles and assigned user locations form a session-dependent user profile. Step 4. The resultant user profile is included in the attribute certificate request, which is then submitted to the local AA. The issued attribute certificate encodes the following user profile data as the values of the attributes field: ●

●

UR set: the set of user roles that has been activated by the particular user UL set: the set of user locations that has been assigned to the particular user.

Step 5. The AA authenticates the information included in the user profile, sets the attribute certificate and issues it to the user. The issued AC is then used in subsequent access requests during the same session. An attribute certificate is session-dependent and is valid only during the current session. In the real world, this requirement can be satisfied effectively by using shortlived certificates with a lifetime of few hours.

PROCESSING OF ACCESS REQUESTS In a subsequent user request to access medical data at any particular site of the Intranet, an access decision-making process takes place based on the combination of the identity and the attribute certificates of the user. More specifically (Figure 7): Step 1. The user using his browser pushes to the application server of a different (remote) site his identity and attribute certificates, along with his particular access request. Step 2. The remote application server validates the identity certificate and then identifies and authenticates the user. It then validates and extracts the role (URs) and location (ULs) information from the set of attribute certificates of the user. After a filtering process, a new user profile to be used in the remote site is derived containing the final sets of activated roles (URs) and assigned locations (ULs). This user profile could be stored in the remote application server to be updated on the arrival of new attribute certificates. The new profile and the access request of the user are then forwarded (pushed) to the security server of the remote site. Step 3. The security server contains the access-control mechanisms as well as the policy engine for the



03 Mavridis (bc/d)

136

28/11/02

10:47 am

Page 136


(1) access-request, IC, ACs Application Server user identity info

Security Server (2) access-request, URs, ULs

roles and

policy

locations info

engine (3) access control decision (p/d)

URH 3DAM

(4) access-request

DSH ULH

Database User (Browser)

Server (6) HTML results

(5) data results

Remote site

Fig. 7 Access medical data

implementation of the DIMEDAC security policy at the remote site. Based on them, a decision-making process is performed. The final access control decision has the form of a simple ‘permitted’ or ‘denied’. Step 4. The access decision is returned to the remote application server. Then, in the case of a permitted access request of the user, it is forwarded to the remote database server. Step 5. The database engine performs the user access request and the data results are returned to the application server. Step 6. The application server forms the data results in HTML format and sends them back to the user in the form of Web pages.

CONCLUSIONS The use of certificate-based access management seems to be the best way of providing sufficient access control in distributed healthcare applications over the Internet. This can be achieved by the proposed use of the three types of digital certificate for the implementation of a suitable security policy, for example the DIMEDAC security policy. In particular, the identity certificates are identity-based, longlived digital certificates with revocation mechanisms and are used for user identification and authentication. On the other hand, the emerging attribute certificates are proposed to be short-lived certificates without revocation mechanisms and to be used to pass user role and location-based access-control information. Finally, we introduce the use of a third type of certificate to distribute in a

secure way the access-control mechanisms, in the context of a common security policy between different organizations that participate in multi-level administrative domains. The access-rule certificates are proposed to be long-lived certificates with revocation mechanisms that carry data useful to update the access-control databases of local security servers. The described system architecture covers the distribution of access-control mechanisms, the obtaining of user credentials and the processing of remote user access requests.

REFERENCES [1] The Computer-Based Patient Record Institute. Description of the computer-based patient record (CPR) and computer-based patient record system. Prepared by the CPRI Work Group on CPR Description (WDES). http://www.cpri.org/resource/docs/hldd. html May 1995. [2] Ahuja V. Secure commerce on the internet. AP Professional Press, 1997. [3] Grimson J, Grimson W, Hasselbring W. The SI challenge in health care. Communications of the ACM 2000; 43(6). [4] Mavridis I, Georgiadis C, Pangalos G, Khair M. Using digital certificates for access control in clinical intranet applications. Proceedings of the fifth World Congress on the Internet in Medicine (MEDNET 2000). Brussels, November 2000. [5] HealthKey project. http://www.healthkey.org September 2000. [6] Lynch C. White paper on authentication and access management issues in cross-organizational use of networked information resources. Coalition for Networked Information, revised discussion draft, 1998. [7] Netscape Center. Security basics. http://www.netscape. com/security/basics/index.html October 2000. [8] Farrel S, Housley R. An internet attribute certificate profile for authorization. IETF Group, Internet draft: draft.ietf.pkix. ac509prof-03.txt; work in progress. http://www.ietf.org/shadow. html May 2000. [9] Linn J, Nyström M. Attribute certification: an enabling technology for delegation and role-based controls in distributed environments. Proceedings of the fourth ACM Workshop on RBAC, Fairfax VA, USA, October 1999. [10] Arsenault A, Turner S. Internet X.509 public key infrastructure – PXIX roadmap. IETF Group, Internet draft:



03 Mavridis (bc/d)

28/11/02

10:47 am

Page 137

Access-rule certificates for secure distributed healthcare draft.ietf.pkix.roadmap-05.txt. Work in progress. http://www. ietf.org/shadow.html March 2000. [11] Sandhu R, Samarati P. Authentication, access control, and intrusion detection. The Computer Science and Engineering Handbook, 1997. [12] Tari Z, Chan S. A role-based access control for intranet security. IEEE Internet Computing September-October 1997: 24-34. [13] Mavridis I. Information system and database system security issues in mobile computing environments. PhD dissertation, Aristotle University of Thessaloniki, Greece, 2000. [14] Pangalos G, Gritzalis D, Khair M, Bozios L. Improving the security of medical database systems, information security – the next decade. (eds) J. Eloff and S. Von Solms. Chapman and Hall, 1995. [15] Pangalos G, Khair M, Bozios L. An integrated secure design of a medical database system. MEDINFO’95. The eighth World Congress on Medical Informatics, Vancouver, Canada, 1995.

137

[16] Mavridis I, Pangalos G, Khair M, Bozios L. Defining access control mechanisms for privacy protection in distributed medical databases. Proceedings of IFIP Working Conference on User Identification and Privacy Protection, Stockholm, Sweden, 1999. [17] Yialelis N. Domain-based security for distributed object systems. PhD dissertation, Imperial College of Science, London (UK), 1996. [18] Sandhu R. Role-based access control. Advances in Computers 1998; 46. [19] Mavridis I, Pangalos G, Khair M. eMEDAC: Role-based access control supporting discretionary and mandatory features. Proceedings of 13th IFIP WG 11.3 Working Conference on Database Security, Seattle, USA, 1999. [20] Ceri S, Pelagatti G. Distributed Databases: principles and systems. New York: McGraw-Hill, 1985. [21] Pernul G. Database security. Advances in Computers 1994; 38.



Access-rule certificates for secure distributed healthcare applications ...

Access-rule certificates for secure distributed healthcare applications ...

Suggest Documents

Secure dissemination of electronic healthcare records in distributed ...

Distributed Cognition in Healthcare

Secure Biometric Cryptosystem for Distributed ... - IDC Technologies

Distributed Coalition Formation Games for Secure Wireless ...

secure framework for implementing distributed ...

Secure Delegation for Distributed Object Environments - CiteSeerX

Minimizing Latency for Secure Distributed Computing - arXiv

Distributed Key Generation for Secure Encrypted Deduplication

Advancing Assurance for Secure Distributed ... - CiteSeerX

secure distributed key management for wireless ...

Partitioning Columns For Secure Distributed Databases - CiteSeerX

Distributed Algorithms for Secure Multipath Routing

Secure Delegation for Distributed Object Environments - CiteSeerX

A distributed approach for secure M2M communications

Secure web applications?

Navigating Provenance Information for Distributed Healthcare ...

Privacy Enforcement for Distributed Healthcare Queries

Privacy Enforcement for Distributed Healthcare Queries

Certificates

Secure Spread-Spectrum Watermarking for Telemedicine Applications

Secure Code Generation for Web Applications - CiteSeerX

Secure Workstation for Special Applications | SpringerLink

Secure Middleware for Defence Applications - Semantic Scholar

secure distributed auction infrastructure