PKI-Based Authentication Mechanisms in Grid Systems - IEEE Xplore

PKI-Based Authentication Mechanisms in Grid Systems Shushan Zhao, Akshai Aggarwal and Robert D. Kent School of Computer Science University of Windsor, Canada Email: {shushanz,akshaia,rkent}@uwindsor.ca

Abstract Grids have emerged as the basic infrastructure for high performance distributed computing and data collaborations. Although they depict an attractive new world of computing, security is the biggest barrier against wide adoption of Grids. Authentication is the basis of security in Grids. GSI uses X.509 PKI and proxy certificates as authentication foundation, and uses gateway for mapping certificates between different authentication mechanisms. In this article, we review PKI and PKI-based authentication mechanisms used in grid systems. These mechanisms are insufficient or problematic under some circumstances. We study and analyze some prominent challenges or problems: compatibility across different PKIs, proxy certificate revocation, security weakness, and authentication in ad hoc grids. For each of them, we introduce possible solutions, and analyze state-ofthe-art technologies and ongoing researches that indicate the direction of future work on this topic.

1 Introduction Grids have emerged as the basic infrastructure for high performance distributed computing and data collaborations. Though grids appear to provide a promising approach for future of massive computing, the biggest barrier against wide adoption of grids is security. Authentication is an essential part of security in grid system. Authentication means the verification of the identity of an entity in a communication session. In general, authentication is achieved through the presentation of some token that cannot be forged. These tokens, sometimes referred to as credentials, include passwords, biometrics and digital signatures etc. The need for secure authentication has been a major issue ever since the networks of computers came into being. Authentication is important for authorization because the user identity is a parameter in most access control (authorization) solutions. It is also important for confidentiality because only if users are properly authenticated, will

International Conference on Networking, Architecture, and Storage (NAS 2007) 0-7695-2927-5/07 $25.00 © 2007

access to confidential information be authorized. Finally, authentication is crucial for accountability, because user’s identity is an important part of security events logged in the audit trail [19]. In grids, authentication is more important because a VO in grids usually spans multiple domains, and the successful execution of a submitted job depends heavily on the trust and cooperation among a host of entities in different domains. Also in grids, resources and processes, in addition to users, need to be authenticated. Grids choose Public Key Infrastructure (PKI) as essential authentication mechanism because its features such as portability, scalability and interoperability, satisfy the requirements of grids. PKI provides a secure and reliable way to authenticate an entity through public-key certificates (PKC). A PKC contains the name of the certificate holder and the holder’s public key, as well as the digital signature of a Certification Authority (CA) for authentication. The grid communities use PKCs to authenticate entities with some expansion of traditional PKIs, which seems successful so far. Nevertheless, with rapid evolution, the grid communities have found areas where further work is required in PKI-based authentication systems. For example, interconnection among different domains of a global grid or among different grids, support for ad hoc grids and single sign-on facility for users of a large grid are issues of active research today. In this paper, we study and analyze problems or challenges of PKI-based grid authentication mechanisms. We introduce some possible solutions in development. The rest of this paper is organized as follows. Section 2 briefly reviews the PKI-based authentication architecture in GSI. Section 3 presents existing or coming challenges and ongoing researches on PKI-based grid authentication mechanisms. Section 4 summarizes the paper.

2 Overview of Authentication in GSI A grid security system has to recognize the fact that individual sites have their own local security policies and methods to enforce it. Joining a grid does not force a site to radi-

cally change its security policies already in place, but rather to make them inter-operable with the general grid policy. The Grid Security Infrastructure (GSI), an Open Grid Services Architecture (OGSA)-based grid security architecture and the security kernel of the Globus Toolkit, provides a set of security protocols for achieving mutual entity authentication between a user (actually a user’s proxy which is a client-side computing platform) and resource providers. Entity authentication in the GSI protocols involves straightforward applications of the standard SSL Authentication Protocol (SAP) suite. These standard applications achieve quick deployment and ease of use. As a result, the grid security protocols in the GSI are two-party mutual authentication techniques. Each party has a public-key based cryptographic credential in the formulation of a certificate under the standard public-key authentication infrastructure. GSI uses X.509 proxy certificates (PCs) to provide X.509 PKCs to globally identify individuals and solve two (related) problems in grids [42]: Single sign-on and Delegation. Like PKCs, PCs bind a unique public key to a Subject Name. Unlike PKCs, the issuer of PC is identified by a PKC or another PC rather than a CA certificate. Hence, PCs can be created on the fly without requiring any intervention from conventional CAs. Using its private key, the peer generates a PC with a limited lifetime. The newly generated PC and its private key are maintained within the local file system. For all subsequent grid interactions, the peer authenticates itself using the PC rather than its PKC. Since the private key associated with the PC is protected by the local file system permissions rather than encrypting it, no manual response is required by the peer. Further, since the PC has a short lifetime, it is typically permissible to protect it in a less secure manner than the long-term private key. Using PKI requires each user to hold a private key as their cryptographic credential. This can be a demanding requirement for many users without a secure computing platform in their locality. MyProxy Server is created to manage user credentials. It is a widely deployed online credential repository for grid and runs on a dedicated and secured host. Rather than storing a user’s X.509 credentials (certificate and private key) on user’s own machine, the user can store them in a MyProxy repository and retrieve a temporary proxy credential (the combination of a PC and its corresponding private key) from the MyProxy repository when needed. MyProxy is particularly valuable in that it ameliorates some of the problems associated with a PKI, essentially making a PKI easier to use and manage. GSI uses gateways to translate between X.509-based identity credentials and other mechanisms. For example, KX.509 is a protocol mapping trust (identity tokens) between Kerberos and X.509. The KX.509 provides a mechanism for obtaining X.509 identity certificates based on a Kerberos domain log-in identity [12, 27].


3 Challenges and Ongoing Researches As is mentioned in section 2, GSI uses X.509 PKI to authenticate users. However, to expand this model to general grids, there are still some challenges or problems to address.

3.1 Compatibility between Different PKIs Nowadays, there are many grids evolving, some private and some public, with local or global scope. Some are dedicated to a specific scientific problem and some cater to a wide range of problems for its users. While the commercial world is mainly concentrating on creating a grid for a single enterprise, the research world is setting up, testing and deploying large collaborative grid infrastructures. At the time the first grid infrastructures appeared towards the end of the 1990s, not many organizations were able to provide fully operational PKIs. This forced grid communities to setup their own PKI – X.509 PKI. The vision of a global grid requires a dynamic federation of certifying authorities. But the current grid architectures have not been able to achieve it. One reason is that the infrastructures are formulated in a fragmented way by specialized working groups; another reason is previous grid visions such as those from the Globus team are too high level or too specific to work for today’s scientific collaboration scenarios, with insufficient attention to business trust. As a result, it is not possible today for different organizations running different grid infrastructures to support even static federation, and it is hard for domains to interact and federate resources even if they run their respective grid infrastructures with the same technologies [2]. As to compatibility with other PKIs, X.509 PKI model entails building a parallel trust infrastructure alongside the existing, well-established one. This requires re-engineering business infrastructure with an entirely new security architecture. One technical issue – the certificate path validation – needs to be tackled for X.509 to be compatible with other PKIs 1 . In the traditional X.509 model, the default value in the traditional certificates is not asserted to prevent users from issuing certificates, that is, acting as a CA. This model is used by the well-known OpenSSL library which is at the heart of most grid middleware and PKI software. As a result of this model, OpenSSL library does not support PC validation, and GSI needed to implement its own specific certificate path validation. To support PCs on a grid, the software used in other PKIs, e.g. SSL/TLS, needs to be changed accordingly. 1 The designers of X.509 PC state this issue this way: “SSL/TLS requires no protocol changes to support authentication using a PC. An SSL/TLS implementation requires only minor changes to support PC path validation, and to retrieve the authenticated subject of the signing EEC instead of the subject of the PC for authorization purposes.”[42].

Moreover, grid processes are based on mutual trust, which is hard to achieve if the number of parties grows without control. At the same time, there are many parallel infrastructures providing the same services but to different communities in the world. Only after reviewing each other’s Certificate Policy (CP) and confirming that they both offer equivalent or conformant trust and verification processes and liability, can two CAs establish trust [8]. Several organizations and projects aim to address this issue. The TERENA Academic CA Repository (TACAR) project [40] attempts to solve the cross-domain use of PKIs within the academic community by providing a central point for gathering and verifying root-CA certificates, revocation lists and policies. Federated Identity of Liberty Alliance aims to address interoperability issue and enables organizations to share trusted identities across the boundaries that separate them [7]. The Certificate Authority Operations (CAOPS) Working Group of Global Grid Forum (GGF) is developing operational procedures and guidelines that facilitate the use of X.509 and other technologies for cross grid Authentication. The GGF has developed a Certificate Policy Model to be used by sites and Virtual Organizations that will deploy a CA [17]. The International Grid Trust Federation (IGTF) is to foster harmonization and synchronization of policies to allow for a global trust relationship to be established for grid authentication. IGTF has proposed several profiles to facilitate the inter-grid authentication [20]. There are three cross-CA trust models that can be considered for a grid system consisting of multiple PKIs [31, 21]: • Hierarchical: The root or top-level CA (TLCA) sits at the top of the hierarchy: it directly certificates subordinate CAs, which, in turn, provide certification services to their users or to other sub-CAs. The problems of this model are: the entire PKI need to be reconstituted if a single trust point (the root CA) is compromised; the root CA is hard to set up for various reasons; legacy PKIs can be difficult to incorporate. In addition, in practice initially most of the software used in Internet hard-coded CA certificates. Later the ability to add new CAs to the hardcoded initial set was crafted into the software, leading to the result of a flat hierarchy. • Cross-certification or Mesh CA: There is no subordination: two CAs cross-certify each other if they mutually agree to trust each other’s certificates as if they had been issued by themselves. Its problem is in the ceritificate path – with further cross-certification, reparenting, subordination of one CA to another, revocation and re-issuance/replacement, multiple certificate paths exist. Certificate paths can contain loops, and certificate semantics can change on different iterations through the loop. • Bridge: A Bridge CA (BCA) is the compromise of the


hierarchical CA and the mesh CA. It acts as a facilitator to interconnect other CAs, and interconnects individual CAs, hierarchical or cross-certified PKIs. A BCA establishes P2P trust relationship with different CAs and mitigates political issues between them. With this model, each member needs only to maintain a single cross-certification with the BCA and then it is automatically able to build certification paths across all branches. The problem is that the BCA is needed as a super-root, and PKI root has a different semantics than a bridge root. For cross-grid authentication, BCA is most widely used among the three models. Leng et al propose their approach to construct a BCA in a production grid [29]. They consider the following as key issues to address to employ BCA for PKI interoperability: • Establishment of the Policy Management Authority whose responsibility includes: verifying BCA Certificate Policy, auditing CA Assurance Level, performing Policy Mapping, exchanging format between BCAs, etc. • Establishment of the BCA CP: Before BCA issues a cross certificate to its member CA, this CA has to be audited by BCA. The assurance level of this CA’s certificate has to be determined via BCA CP. ANSI X9.79 and IETF RFC 2527 provide guidelines for CP. • BCA technical template that deals with the technical details for CA-CA interoperability, including: the cryptographic algorithms specification, certificate formats, certificate extension fields and interoperability, border directory service, and certificate path validation, etc. • CA auditing system: CA must operate according to the assurance level acclaimed by its Certificate Practice Statement (CPS). Besides the afore-mentioned BCA model, some new BCA models have been proposed. Li et al [30] proposed a new modified BCA model. The main idea is that several PKI domains form a virtual domain, the new virtual domain trust each other by cross-certification process. A domain can either issue a certificate to BCA, or to other domain’s CAs. The authors claim that this approach simplifies the certification path process, shortens the certificate chain, and thus, in path validation phase, it will cost less time to verify the certificate chain.

3.2 Certificate Revocation A user’s private key can be lost or compromised. So there must be a way to revoke that PKC. The certificate

revocation problem has been around since the PKCs were used. A number of techniques have been proposed to address this problem. The oldest and most widely used revocation method is to publish a Certificate Revocation List (CRL). In order to verify a signature, the relying party needs to fetch from a repository both the whole chain of certificates up to the trusted root and the available revocation data about the certificates. CRLs can grow up to considerable dimensions due to design choices or certificate profiling, or the encoding of application-specific or the inclusion of frequently changing data into certificates [31]. However, the updates of CRLs are not in real time, and the long intervals between CRL distributions often result in stale revocation information (“time granularity problem”). CRLs are expensive to distribute, and are vulnerable to simple Denial of Service (DoS) attacks. CRL requests may come at about the same time (“CRL request implosion”). Many solutions have been proposed to decreases a CRL’s size or to improve the performance of the CRL distribution systems. Segment CRLs are based on urgency of revocation. Stagger CRLs over-issue CRLs so that multiple overlapping CRLs may exist simultaneously [9]. Delta CRL distributes a list of the certificates revoked since the last CRL was distributed, and modifies a main CRL [10]. CRL Distribution Points divide revocation list in a domain to multiple CRLs, so that each CRL is smaller than before [25]. The Certificate Revocation Tree [26] keeps a list of ranges of serial numbers that are good or bad. Windowed Certificate Revocation reduces the size of a CRL due to the revocation window [35]. None of these solutions completely solves all the aforementioned CRL problems. Instead of CRL, another approach is to use online certificate status protocols, including OCSP and similar ones, to query the validity of the certificate. Instead of downloading the entire CRL file, the relying party only requests a response for specified certificates. Certificate status verification is a computationally expensive operation, as the response from the CA must be digitally signed. It requires a validation server to be always online. To minimize its computation and transmission overhead, Micali [36] proposes NOVOMODO to use one-way hash function to transmit the certificate status in a short value. Centralized NOVOMODO and a few similar schemes make use of a third party who queries and obtains users’ certificate status before the certificate can be used. There are several drawbacks of a third-party query [18]: First, since third party queries can come from anywhere and concern any client, every certificate server in the system must be able to ascertain the certificate status of every client in the system. Secondly, third party queries multiply the query processing costs of the CA and/or its servers. Thirdly, nonclient queries are undesirable from a business model per-


spective. Finally, there is a security consideration: if the CA must respond to queries from nonclients, it becomes more susceptible to DoS attacks. To protect against congestion, delays, and denial of service, Micali suggests to use Distributed NOVOMODO that spreads the load of answering validity queries to “un-trusted responders”. Some researchers propose implicit certification to ease the certificate revocation problem. Shamir [38] proposes Identity-based Encryption. Yet in this scheme, a Private Key Generator (PKG) can decrypt messages intended for its clients, and a compromised PKG will let the attacker learn all the clients’ private keys(“key escrow” problem). Also, the PKG has to communicate the private keys to its clients over secure channels to thwart eavesdroppers. Another cryptosystem Certificate-based Encryption (CBE) proposed by Gentry [18] eliminates the problem of key escrow by using double encryption. However, this model requires the CA to be an online entity in order to answer status queries. Further, such a CA setup becomes attractive targets for attackers and susceptible to DoS attacks. Also, the CA is necessitated to take part in multiple revocation queries from various acceptors, even for the same certificate. This increases the processing and transmission costs [39]. Another schme implementing implicit certification is to use the Security Mediator (SEM) system, in which the administrator revokes the ability of the key holder (mediator) to use a private key, instead of (or in addition to) revoking the certificate attesting to the corresponding public key. If a private key operation cannot take place after the binding has been revoked, then a relying party does not need to check the revocation status [5]. In grid environment, a few of these techniques have been implemented and applied. GSI provides only a little support for revocation capabilities for long-term certificates and no support for revoking compromised user proxies [39]. However a hierarchical infrastructure spanned by a tree with the root CA, as in X.509, will attract hackers. The resulting problem with X.509 is that it cannot tolerate even one penetration: each node is a single point of failure [6]. Theoretically, PCs can be revoked using the same mechanisms as normal EECs, since they can be uniquely identified in the same manner. In practice, no efficient methods are available for revoking a compromised PC, although PCs are widely used in grid operations. The main reason is that X.509 certificates were intended to have validity on their own, without real-time verification. Thus, people trust in and rely on the limited lifetime of a PC, and tend to use the pattern of issuing short-lived PCs and re-issuing new ones to continue the job afterwards. However, this pattern has several problems. First, frequent re-issuance of PCs is a CPU intensive operation that may place a significant burden on heavily loaded issuers. Second, it has a window of vulnerability equal to its lifetime, which is unacceptable for most

security-critical applications [46]. A PC is less strongly protected than an EEC, and can be obtained by breaking the file system or by phishing attacks [1]. For a stolen PC, it is inappropriate to revoke the EEC on the basis of which the PC was issued. In GSI, the default lifetime of a PC is 12 hours. If there is no method to revoke a PC, the attacker will have enough time to commit malicious actions. RFC3820 [42] specifies the use of Certificate Revocation List. This method has the “time granularity problem”. Sundaram et al [39] implemented SEM system to revoke PCs. In their system, each VO has a SEM . The CAs generate a set of simple 2-by-2 threshold keys, and communicate to the intended recipients (a user and a resource provider respectively). After this initial key distribution, the client (user or resource provider) and its SEM has to co-operate by using their respective half-keys to complete any signature or decryption operations. If a PC is revoked, the corresponding SEM refuses to exercise its half key. NOVOMODO approach is used for PC status query. However several barriers hinder this scheme from practical use: First, cooperation of CAs are required. This may not be easy to implement for normal grid users. Secondly, while each VO has a SEM which plays an indispensable role in signing PCs and decrypting every message sent to the VO, the SEM is difficult to replicate; thus the SEM tends to be overloaded and be the target of DoS attacks. Thirdly, a client and its SEM each holds its own half long-lived private key permanently. This is against the usage pattern of MyProxy, in which nobody holds its own long-lived private key, but each one only holds a short-lived PC and private key. Since MyProxy is integrated in GT4.0 and is widely used in many organizations, SEM system cannot be applied to those organizations. A latest work in [45] presents a practical PC revocation scheme based on MyProxy server, which is light-weight and can be integrated into Globus architecture with little modification.

3.3 Distributed Authentication in Ad Hoc Grids An ad hoc grid is a logical community formed spontaneously by cooperating heterogenous computing nodes, without a preconfigured fixed infrastructure and with only minimal administrative requirements. The main goal of an ad hoc grid is to provide computing resources on demand to every participant [3]. SETI@home is an example of an ad hoc grid in use [28]. The important differences between ad hoc grids and traditional grids can be summarized in Table 1 [15, 44]. The most essential characteristic in ad hoc grids is the lack of a central authentication authority who assigns a unique grid identity to each entity by which a set of authorization privileges and so on can be specified. Instead, an ad hoc grid has control independence ability to manage its security and


Administration Members Nodes relationship Service availability

Traditional Grids dedicated administrators dedicated nodes trust pre-established with CA guaranteed with high availability

Ad Hoc Grids autonomous fashion frequently changing unknown to each other dynamically contributed by nodes

Table 1. Differences between ad hoc grids and traditional grids

usage policies in the absence of a central controller. Because of its structural independence, peers in an ad hoc grid cannot rely on external support for crucial security enforcement services. Thus, the centralized administrative services in traditional grids that are responsible for membership, access, and usage control on grid resources are segregated to be hosted on every participating peer. Every entity in an ad hoc grid is responsible for maintaining and securing itself. Due to the special requirements for security system in ad hoc grids, the authentication mechanism is different. K. Amin et al propose an authentication model in their ad hoc grid security infrastructure on the basis of GSI to support structure independence and control independence [4]. In this model, every peer bears the exclusive responsibility for and control of the services contributed by it. Every peer in an ad hoc grid is uniquely identified by an identity. Following the GSI model, a peer identity is represented as an X.509 PKC signed S by a CA. The essence of this mechanism is: Let Ix = nk=1 icxk be a set of identities established by a peer x, where icxk denotes Sm the peer identity ix issued by the CA ck . Let Cx = j=1 cj be the set of CAs trusted by peer x. A mutually authenticated transaction is permitted between ad hoc peers x and y, if and only if ∃icxa ∈ Ix and ∃icyb ∈ Iy such that ca ∈ Cy and cb ∈ Cx [4]; or in other words, there exists a CA who issues a certificate to x and is trusted by y, and a CA who issues a certificate to y and is trusted by x. As for CA service, since no complete trust can be placed on an entity in an ad hoc grid, CA service should not be hosted on a single entity or a fixed group of entities. Instead, the service should be provided by several distributed nodes that collectively provide CA functionality and thus alleviate the reliance on any single node in the grid. The main solution for distributed CA is “threshold” cryptography which was proposed in the area of Mobile Ad Hoc Networks (MANETs) long ago [47]. The private and public key of CA are distributed to n servers, each server holding a share. To provide the signing service, threshold cryptography algorithm is used – if k out of n partial signature are collected, they can jointly perform the operation correctly.

Vanrenen et al [43] improve security and high-availability of this model for use in peer-to-peer (P2P) networks 2 . More techniques from MANETs and P2P networks can be studied and adapted to facilitate authentication for untrusted nodes in ad hoc grids. But since ad hoc grids are at a higher layer than MANETs, and make heavy use of X.509 PKCs, some techniques suitable for MANETs, such as identity-based authentication and symmetric-key-based authentication are not suitable for ad hoc grids. On the other hand, ad hoc grids have more available resources than MANETs, such as synchronization system, higher communication and computational capability, more stable connections, etc. Making use of these advantages on top of suitable MANETs authentication mechanisms may produce a good authentication mechanism for ad hoc grids.

3.4 Security Weakness Some security weakness issues in the PKI-based authentication mechanisms, especially in the widely used Globus toolkit, have been pointed out. In this section we look at two examples of this type of issues, yet the solutions may apply to many other issues. 3.4.1 Unilateral-authentication and Password Exposure MyProxy is a certificate repository for securely storing user credentials. Security of MyProxy server is ensured by using SSL/TLS secured channel and pass phrase authentication, and can be enhanced via a one-time password such as through a SecureID card [6]. SSL/TLS uses a X.509 PKC to bind a multicomponent meaningful Distinguished Name (DN) to a public key. The certificate is signed by a CA with its private key. The authentication of the PKC holder is done using the SSL/TLS handshake protocol to prove its knowledge of the private key associated with the public key in the certificate – sending it a challenge that is to be encrypted with its private key and verifying the response with its public key. When MyProxy server presents a X.509 certificate to the connecting entity as an authentication token, the entity challenges the server and verifies its identity. Once the server has been verified, the user sends his password through the SSL/TLS secure channel. From then on, all actions performed as a result of requests coming from 2 The private key is firstly split into two halves: d held by the user and u dSEM held by Security Mediators (SEMs). dSEM is stored on a primary island, and further split into k shares. The k shares are then sent to k islands securely that are chosen randomly to mitigate denial of service risks like network partition. So dSEM is stored both on the primary islands and on k back-up islands. If the primary island is compromised, the dSEM can be restored from k shares. In this case, the dSEM is updated using strong forward security which ensures that the use of the private key in previous or future sessions is still secure, and the primary island is also changed to another entity.


that channel are assumed to be done by the entity named by the DN in the certificate [11, 1]. M. Abdalla et al [1] point out that this approach provides a false sense of security because the privacy of the user’s password can be stolen if the server is actually impersonated (phishing attack). The password can be exposed to an adversary when the user accepts a bogus server certificate, which usually takes just a single mouse click. Anything protected through the password could get compromised. Using a one-time password in place of the fixed password as suggested by [6] does not help in this case, since the bogus server could turn around and use this one-time password to impersonate the user. They propose a technique – Simple Open Key Exchange (SOKE) – that ties the user’s authentication to the SSL/TLS secure channel to alleviate this problem. Loosely speaking, the SOKE ciphersuites are unauthenticated Diffie-Hellman ciphersuites in which the client’s Diffie-Hellman ephemeral public value is encrypted using a simple mask generation function. A hash value is calculated based on the password. The mask is simply a constant value raised to the power of the hash. The SOKETLS ciphersuites offer a message flow in which the user identity and password need only be supplied if one of these ciphersuites has actually been negotiated in the SSL/TLS handshake. There are other standard protocols such as PGP [16] and SPKI [13] that can be used to create a secure and authenticated connection using only a public key to identify the requestor. The major difference between these methods and SSL/TLS is that in the formers the public key of the user must be known by the target host by some secure method, and if a local name is needed it must be assigned to the private key by some out-of-band procedure. In the case of X.509 certificates, both the public key and the distinguished name are included in the certificate, and are presented to the user directly [23]. These are alternatives to authenticate repository server and clients, but they also need revision to be adopted in grids. 3.4.2 Storage of User’s Secret Credentials In the GSI, a user requests a resource using a PC. A proxy credential can be obtained from MyProxy server, and is simply stored in the file system of the platform protected under the access control of the operating system. The obvious danger of leaving a private key in the file space is mitigated by stipulating a short lifetime for the PC. Upon expiration, a new PC must be re-issued. The drawback of this pattern is discussed in Subsection 3.2. Secure storage of both longlived and short-lived credentials is a big challenge. Trusted Computing (TC) and Trusted Platform Module (TPM) can be used to strengthen the protection of the PC and private key. TPM is a tamper-resistant hardware mod-

ule for conformed operation and secure storage. It is designed to perform computations which cannot be subverted by the platform owner, including the system administrator. These computations include some public key cryptographic operations (decryption and digital signature generation using a private key in the TPM), platform system status measurement, and secure storage, protecting them from external software attack and physical theft. Examples of TPMs on the market are IBM 4758 and later 4764 secure coprocessors [24]. Microsoft has TCG Software Stack (TSS) to support TPM in its Next-Generation Secure Computing Base (NGSCB) [37]. The Trusted Computing Group (TCG) (former name Trusted Computing Platform Alliance (TCPA)) designed a TPM hardware. In this system, a small chip, added to a commodity motherboard, witnesses platform configuration via a set of platform configuration registers (PCRs) and releases or uses credentials (such as RSA private keys) only when the PCRs have appropriate values [41].The Enforcer is a Linux Security Module designed to interact with TCPA hardware. In essence, a system using TPM and Enforcer works in this way to ensure no tampering of the file system: When the system is booted, the Enforcer uses the TPM to check if critical system components have changed. If not, then the Enforcer retrieves its key from the TPM and mounts the encrypted loopback filesystem. As files are opened, the Enforcer performs a run-time integrity check on the file against its security policy. If a mismatch occurs indicating that someone has tampered with a file, the Enforcer will unmount the loopback filesystem and panic the kernel [14]. With a TC platform containing a tamper-resistant TPM, it is natural to store a user’s cryptographic credential in the TPM, or under an encryption chain controlled by the TPM. In TC, each user of a platform can generate many copies of private keys with their matching public keys being certified in the standard X.509 PKI. A TPM can be configured to hold keys in a “non-migration” mode which will never reveal any private key (up to the tamper-resistance level for which a TPM is designed ). Keys can also be configured as “migratable” wherein key material can be explored with the owner’s consent. Even if a platform is under the control of an attacker, the attacker cannot retrieve any information stored in the TPM. Thus, in a TC enhanced grid security setting, the protection of user secret key credentials can be substantially improved [32]. Secure Hardware Enhanced MyProxy (SHEMP) is a project aiming to increase security of MyProxy key management by use of TC to increase assurance of ordinary desktops. In this system, the grid community’s MyProxy server provides a foundation for authentication using temporary key pairs, and OASIS eXtensible Access Control Markup Language (XACML) provides a standard way of expressing policies. SHEMP combines these tools to pro-


duce a way for users to employ proxy key pairs for signatures and encryption as well, limited by predefined policies geared toward the trustworthiness of the client platform [33]. In addition, using this technology, a VO can select one entity as a group manager and let it play the role of a group CA that issues certificates to the group members. The group policy enforcement is then achieved [32, 34]. Although TC and TPM technology seems promising to improve system security, there are still many challenges to overcome to use it in grids, e.g. the management of large number of environments to be certified in a grid, integration of significant components of GSI, etc. [32].

4 Discussion and Conclusions We have discussed state-of-the-art grid authentication mechanisms, challenges and problems, possible solutions and ongoing researches on these issues. We envision a lot of work to do to improve the PKI-based authentication mechanisms, to make grids compatible to the current Internet world, and popularly acceptable and usable to common users. We also notice that some researchers are arguing that the use of PKIs may be totally abandoned. They think the scalability of PKIs is limited in a distributed open system such as grid, because they often depend on either a centralized verifying authority or ad hoc recommendation-based authorization. They suggest a new method, called soft security, in which much more malleable, robust, and scalable security methods are based on aspects of social control [22]. We, however, think that soft security requires a great deal of further work before it can be considered for use. Researchers have yet to build a rigorous theoretical foundation and secure protocols. We believe that PKI-based mechanisms will still be the mainstream for authentication in grids in the near future; with more and more researchers joining the work on improvement of PKIs, PKI could be successful to propel the wide popularization of grids.

References [1] M. Abdalla, E. Bresson, O. Chevassut, B. Moller, and D. Pointcheval. Provably Secure Password-Based Authentication in TLS. In ACM ASIACCS ’06, pages 35–45, 2006. [2] M. Ahsant, M. Surridge, T. A. Leonard, A. Krishna, and O.Mulmo. Dynamic trust federation in grids. In The 4th International Conference on Trust Management, 2006. [3] K. Amin, G. von Laszewski, and A. Mikler. Toward an architecture for ad hoc grids. In ADCOM 2004, 2004. [4] K. Amin, G. von Laszewski, M. Sosonkin, A. Mikler, and M. Hategan. Ad hoc grid security infrastructure. In The 6th IEEE/ACM International Workshop on Grid Computing, pages 69–76, 2005. [5] D. Boneh, X. Ding, and G. Tsudik. Fine-grained control of security capabilities. ACM Trans. Inter. Tech., 4(1):60–82, 2004.

[6] J. Burruss, T. Fredian, and M. Thompson. Security on the US fusion grid. In 5th IAEA TM on Control, Data Acquisition, and Remote Participation for Fusion Research, pages 1949–1955, 2006. [7] S. Cantor and J. Kemp. Liberty ID-FF Protocols and Schema Specification. At http://www.projectliberty. org/specs, 2004. [8] S. Chokhani, W. Ford, R. Sabett, C. Merrill, and S. Wu. Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, 2003. [9] D. Cooper. A model of certificate revocation. In IEEE 15th Annual ACSAC, pages 256–264, 1999. [10] D. Cooper. A More Efficient Use of Delta-CRLs. In IEEE Symposium on Security and Privacy, pages 199–202, 2000. [11] T. Dierks and C. Allen. RFC 2246: The TLS protocol version 1, Jan. 1999. [12] W. Doster, M. Watts, and D. Hyde. The KX.509 protocol. Technical Report 01-2, University of Michigan, February 2001. [13] C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, and T. Ylonen. RFC2693: SPKI Certificate Theory, 1999. [14] Enforcer Group. Enforcer Homepage. At http:// enforcer.sourceforge.net/, 2006. [15] T. Friese, M. Smith, and B. Freisleben. Hot service deployment in an ad hoc grid environment. In ACM ICSOC ’04, pages 75–83, New York, NY, USA, 2004. [16] S. Garfinkel. PGP: Pretty Good Privacy. O’Reilly, USA, 1994. [17] T. J. Genovese and M. Helm. Grid PKI Disclosure Statement. At http://caops.es.net/Documents/ LastCALL/gridpds.pdf, 2003. [18] C. Gentry. Certificate-Based Encryption and the Certificate Revocation Problem. Advances in Cryptology CEUROCRYPT,Springer, 2003. [19] D. Gollmann. Computer security. John Wiley & Sons, Inc., New York, NY, USA, 1999. [20] D. Groep. International grid trust federation(v1.0). At http://eugridpma.org/igtf/, 2005. [21] P. Gutmann. How to Build a PKI That Works. In 3rd Annual PKI R&D workshop. Springer, 2004. [22] H. Hexmoor, S. Wilson, and S. Bhattaram. A theoretical inter-organizational trust-based security model. Knowl. Eng. Rev., 21(2):127–161, 2006. [23] M. Humphrey, M. Thompson, and K. Jackson. Security for grids. In Proceedings of the IEEE, pages 644–652, 2005. [24] IBM. Research for Advancing Trusted Computing. At http://domino.watson.ibm.com/ comm/research.nsf/pages/r.security. innovation.html, 2007. [25] International Telecommunication Union. ITU-T Recommendation X.509, 1997. [26] P. Kocher. On certificate revocation and validation. Financial Cryptography ,Springer-Verlag, 1465:172–177, 1998. [27] O. Kornievskaia, P. Honeyman, B. Doster, and K. Coffman. Kerberized credential translation: A solution to web access control. In 10th Usenix Security Symposium, pages 235– 250, 2001. [28] E. Korpela, D. Werthimer, D. Anderson, J. Cobb, and M. Lebofsky. SETI@home-Massively Distributed Computing for SETI. IEEE MultiMedia, 3(1):78–83, 1996.


[29] J. Leng and D. Xie. A novel approach to kernel construction of china bridge CA. In 11th Pacific Rim International Symposium on Dependable Computing, pages 258–268. IEEE Computer Society, 2005. [30] M. Li, Y. Ren, Z. Wang, J. Xie, and H. Yao;. A New Modified Bridge Certification Authority PKI Trust Model. In 1st International Symposium on Pervasive Computing and Applications, pages 23–26. IEEE Computer Society, 2006. [31] A. Lioy, M. Marian, N. Moltchanova, and M. Pala. PKI past, present and future. International Journal of Information Security, Springer Berlin, pages 18–29, 2006. [32] W. Mao, H. Jin, and A. Martin. Innovations for grid security from trusted computing. In International Symposium on Grid Computing, 2005. [33] J. Marchesini and S. Smith. Shemp: Secure hardware enhanced myproxy. Technical Report 05-532, Dartmouth College, February 2005. [34] J. Marchesini, S. Smith, O. Wild, and J. Barsamian. Opensource applications of TCPA hardware. In 20th ACSAC, 2004. [35] P. McDaniel and S. Jamin. Windowed Certificate Revocation. In INFOCOM 2000, 2000. [36] S. Micali. NOVOMODO: Scable Certificate Validation And Simplified PKI Management. In 1st Annual PKI Research Workshop, 2002. [37] MicroSoft. Next-Generation Secure Computing Base(NGSCB). At http://www.microsoft. com/resources/ngscb/, 2007. [38] A. Shamir. Identity-Based Cryptosystems and Signature Schemes. Crypto 1984, Springer-Verlag, pages 47–53, 1985. [39] B. Sundaram and B. Chapman. Addressing credential revocation in grid environments. In The 6th IEEE/ACM International Workshop on Grid Computing, pages 3–17, 2005. [40] TACAR Group. TERENA Academic CA Repository. At http://www.tacar.org/, 2006. [41] TCPA Group. Trusted Computing Platform Alliance. At http://www.trustedcomputinggroup.org, 2006. [42] S. Tuecke, V. Welch, D. Engert, L. Perlman, and M. Thompson. RFC3820: Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile, 2004. [43] G. Vanrenen, S. Smith, and J. Marchesini. Distributing Security-mediated PKI. International Journal of Information Security, Springer, pages 3–17, 2006. [44] G. von Laszewski, J. Gawor, C. J. Pena, and I. Foster. Infogram: A peer-to-peer information and job submission service. In 11th Symposium on High Performance Distributed Computing, pages 33–42, 2002. [45] S. Zhao, A. Aggarwal, and R. D. Kent. Proxy certificate revocation in grid and a practical implementation framework. In Proc. 8th ACIS/IEEE SNPD, 2007. [46] P. Zheng. Tradeoffs in certificate revocation schemes. ACM SIGCOMM Comput. Commun. Rev., 33(2):103–112, 2003. [47] L. Zhou and Z. J. Haas. Securing ad hoc networks. IEEE Network, 13(6):24–30, 1999.