Table of Contents
GSI uses public key cryptography (also known as asymmetric cryptography) as the basis for its functionality. Many of the terms and concepts used in this description of GSI come from its use of public key cryptography.
For a good overview of GSI contained in the Web Services-based components of GT4, see Globus Toolkit Version 4 Grid Security Infrastructure: A Standards Perspective.
A reference for detailed information about public key cryptography is available in the book Handbook of Applied Cryptography , by A. Menezes, P. van Oorschot, and S. Vanstone, CRC Press, 1996. Chapter 8 of this book deals exclusively with public key cryptography.
The primary motivations behind GSI are:
- The need for secure communication (authenticated and perhaps confidential) between elements of a computational Grid.
- The need to support security across organizational boundaries, thus prohibiting a centrally-managed security system.
- The need to support "single sign-on" for users of the Grid, including delegation of credentials for computations that involve multiple resources and/or sites.
The most important thing to know about public key cryptography is that, unlike earlier cryptographic systems, it relies not on a single key (a password or a secret "code"), but on two keys. These keys are numbers that are mathematically related in such a way that if either key is used to encrypt a message, the other key must be used to decrypt it. Also important is the fact that it is next to impossible (with our current knowledge of mathematics and available computing power) to obtain the second key from the first one and/or any messages encoded with the first key.
By making one of the keys available publicly (a public key) and keeping the other key private (a private key), a person can prove that he or she holds the private key simply by encrypting a message. If the message can be decrypted using the public key, the person must have used the private key to encrypt the message.
Important: It is critical that private keys be kept private! Anyone who knows the private key can easily impersonate the owner.
Using public key cryptography, it is possible to digitally "sign" a piece of information. Signing information essentially means assuring a recipient of the information that the information hasn't been tampered with since it left your hands.
To sign a piece of information, first compute a mathematical hash of the information. (A hash is a condensed version of the information. The algorithm used to compute this hash must be known to the recipient of the information, but it isn't a secret.) Using your private key, encrypt the hash, and attach it to the message. Make sure that the recipient has your public key.
To verify that your signed message is authentic, the recipient of the message will compute the hash of the message using the same hashing algorithm you used, and will then decrypt the encrypted hash that you attached to the message. If the newly-computed hash and the decrypted hash match, then it proves that you signed the message and that the message has not been changed since you signed it.
A central concept in GSI authentication is the certificate. Every user and service on the Grid is identified via a certificate, which contains information vital to identifying and authenticating the user or service.
A GSI certificate includes four primary pieces of information:
- A subject name, which identifies the person or object that the certificate represents.
- The public key belonging to the subject.
- The identity of a Certificate Authority (CA) that has signed the certificate to certify that the public key and the identity both belong to the subject.
- The digital signature of the named CA.
Note that a third party (a CA) is used to certify the link between the public key and the subject in the certificate. In order to trust the certificate and its contents, the CA's certificate must be trusted. The link between the CA and its certificate must be established via some non-cryptographic means, or else the system is not trustworthy.
GSI certificates are encoded in the X.509 certificate format, a standard data format for certificates established by the Internet Engineering Task Force (IETF). These certificates can be shared with other public key-based software, including commercial web browsers from Microsoft and Netscape.
If two parties have certificates, and if both parties trust the CAs that signed each other's certificates, then the two parties can prove to each other that they are who they say they are. This is known as mutual authentication. GSI uses the Secure Sockets Layer (SSL) for its mutual authentication protocol, which is described below. (SSL is also known by a new, IETF standard name: Transport Layer Security, or TLS.)
Before mutual authentication can occur, the parties involved must first trust the CAs that signed each other's certificates. In practice, this means that they must have copies of the CAs' certificates--which contain the CAs' public keys--and that they must trust that these certificates really belong to the CAs.
To mutually authenticate, the first person (A) establishes a connection to the second person (B).
To start the authentication process, A gives B his certificate.
The certificate tells B who A is claiming to be (the identity), what A's public key is, and what CA is being used to certify the certificate.
B will first make sure that the certificate is valid by checking the CA's digital signature to make sure that the CA actually signed the certificate and that the certificate hasn't been tampered with. (This is where B must trust the CA that signed A's certificate.)
Once B has checked out A's certificate, B must make sure that A really is the person identified in the certificate.
B generates a random message and sends it to A, asking A to encrypt it.
A encrypts the message using his private key, and sends it back to B.
B decrypts the message using A's public key.
If this results in the original random message, then B knows that A is who he says he is.
Now that B trusts A's identity, the same operation must happen in reverse.
B sends A her certificate, A validates the certificate and sends a challenge message to be encrypted.
B encrypts the message and sends it back to A, and A decrypts it and compares it with the original.
If it matches, then A knows that B is who she says she is.
At this point, A and B have established a connection to each other and are certain that they know each others' identities.
By default, GSI does not establish confidential (encrypted) communication between parties. Once mutual authentication is performed, GSI gets out of the way so that communication can occur without the overhead of constant encryption and decryption.
GSI can easily be used to establish a shared key for encryption if confidential communication is desired. Recently relaxed United States export laws now allow us to include encrypted communication as a standard optional feature of GSI.
A related security feature is communication integrity. Integrity means that an eavesdropper may be able to read communication between two parties but is not able to modify the communication in any way. GSI provides communication integrity by default. (It can be turned off if desired). Communication integrity introduces some overhead in communication, but not as large an overhead as encryption.
The core GSI software provided by the Globus Toolkit expects the user's private key to be stored in a file in the local computer's storage. To prevent other users of the computer from stealing the private key, the file that contains the key is encrypted via a password (also known as a passphrase). To use GSI, the user must enter the passphrase required to decrypt the file containing their private key.
We have also prototyped the use of cryptographic smartcards in conjunction with GSI. This allows users to store their private key on a smartcard rather than in a file system, making it still more difficult for others to gain access to the key.
GSI provides a delegation capability: an extension of the standard SSL protocol which reduces the number of times the user must enter his passphrase. If a Grid computation requires that several Grid resources be used (each requiring mutual authentication), or if there is a need to have agents (local or remote) requesting services on behalf of a user, the need to re-enter the user's passphrase can be avoided by creating a proxy.
A proxy consists of a new certificate and a private key. The key pair that is used for the proxy, i.e. the public key embedded in the certificate and the private key, may either be regenerated for each proxy or obtained by other means. The new certificate contains the owner's identity, modified slightly to indicate that it is a proxy. The new certificate is signed by the owner, rather than a CA. (See diagram below.) The certificate also includes a time notation after which the proxy should no longer be accepted by others. Proxies have limited lifetimes.
The proxy's private key must be kept secure, but because the proxy isn't valid for very long, it doesn't have to kept quite as secure as the owner's private key. It is thus possible to store the proxy's private key in a local storage system without being encrypted, as long as the permissions on the file prevent anyone else from looking at them easily. Once a proxy is created and stored, the user can use the proxy certificate and private key for mutual authentication without entering a password.
When proxies are used, the mutual authentication process differs slightly. The remote party receives not only the proxy's certificate (signed by the owner), but also the owner's certificate. During mutual authentication, the owner's public key (obtained from her certificate) is used to validate the signature on the proxy certificate. The CA's public key is then used to validate the signature on the owner's certificate. This establishes a chain of trust from the CA to the proxy through the owner.
GSI, and software based on it (notably the Globus Toolkit, GSI-SSH, and GridFTP), is currently the only software which supports the delegation extensions to TLS (a.k.a. SSL). The Globus Alliance has worked in the GGF and the IETF to standardize this extension in the form of Proxy Certificates (RFC 3820) [http://www.ietf.org/rfc/rfc3820.txt].
- Certificate Authority ( CA )
An entity that issues certificates.
- CA Certificate
The CA's certificate. This certificate is used to verify signature on certificates issued by the CA. GSI typically stores a given CA certificate in
/etc/grid-security/certificates/, where <hash> is the hash code of the CA identity.
- CA Signing Policy
The CA signing policy is used to place constraints on the information you trust a given CA to bind to public keys. Specifically it constrains the identities a CA is trusted to assert in a certificate. In GSI the signing policy for a given CA can typically be found in
/etc/grid-security/certificates/, where <hash> is the hash code of the CA identity. For more information see [add link].
A public key and information about the certificate owner bound together by the digital signature of a CA. In the case of a CA certificate the certificate is self signed, i.e. it was signed using its own private key.
- Certificate Revocation List (CRL)
A list of revoked certificates generated by the CA that originally issued them. When using GSI this list is typically found in
/etc/grid-security/certificates/, where <hash> is the hash code of the CA identity.
- certificate subject
A identifier for the certificate owner, e.g. "/DC=org/DC=doegrids/OU=People/CN=John Doe 123456". The subject is part of the information the CA binds to a public key when creating a certificate.
The combination of a certificate and the matching private key.
- GAA Configuration File
A file that configures the Generic Authorization and Access control GAA libraries. When using GSI this file is typically found in
- grid map file
A file containing entries mapping certificate subjects to local user names. This file can also serve as a access control list for GSI enabled services and is typically found in
/etc/grid-security/grid-mapfile. For more information see the Gridmap file.
- grid security directory
The directory containing GSI configuration files such as the GSI authorization callout configuration and GAA configuration files. Typically this directory is
/etc/grid-security. For more information see Grid security directory.
- GSI authorization callout configuration file
A file that configures authorization callouts to be used for mapping and authorization in GSI enabled services. When using GSI this file is typically found in
- host certificate
An EEC belonging to a host. When using GSI this certificate is typically stored in
/etc/grid-security/hostcert.pem. For more information on possible host certificate locations see the Credentials.
- host credentials
The combination of a host certificate and its corresponding private key..
- private key
The private part of a key pair. Depending on the type of certificate the key corresponds to it may typically be found in
$HOME/.globus/userkey.pem(for user certificates),
/etc/grid-security/hostkey.pem(for host certificates) or
/etc/grid-security/(for service certificates). For more information on possible private key locations see the Credentials
- proxy certificate
A short lived certificate issued using a EEC. A proxy certificate typically has the same effective subject as the EEC that issued it and can thus be used in its stead. GSI uses proxy certificates for single sign on and delegation of rights to other entities.
For more information about types of proxy certificates and their compatibility in different versions of GT, see http://dev.globus.org/wiki/Security/ProxyCertTypes.
- proxy credentials
The combination of a proxy certificate and its corresponding private key. GSI typically stores proxy credentials in
/tmp/x509up_u, where <uid> is the user id of the proxy owner.
- public key
The public part of a key pair used for cryptographic operations (e.g. signing, encrypting).
- service certificate
A EEC for a specific service (e.g. FTP or LDAP). When using GSI this certificate is typically stored in
/etc/grid-security/. For more information on possible service certificate locations see the Credentials.
- service credentials
The combination of a service certificate and its corresponding private key.
- transport-level security
Uses transport-level security (TLS) mechanisms.
- trusted CAs directory
The directory containing the CA certificates and signing policy files of the CAs trusted by GSI. Typically this directory is
/etc/grid-security/certificates. For more information see Grid security directory.
- user certificate
A EEC belonging to a user. When using GSI this certificate is typically stored in
$HOME/.globus/usercert.pem. For more information on possible user certificate locations see Credentials.
- user credentials
The combination of a user certificate and its corresponding private key.