Grid Security

Introduction
A Grid is a system that:
1) Coordinates resources that are not subject to centralized control …
(A Grid integrates and coordinates resources and users that live within different control domains—for example, the user’s desktop vs. central computing; different administrative units of the same company; or different companies; and addresses the issues of security, policy, payment, membership, and so forth that arise in these settings. Otherwise, we are dealing with a local management system.)
2) … using standard, open, general-purpose protocols and interfaces
(A Grid is built from multi-purpose protocols and interfaces that address such fundamental issues as authentication, authorization, resource discovery, and resource access. As I discuss further below, it is important that these protocols and interfaces be standard and open. Otherwise, we are dealing with an application specific system.)
3) … to deliver nontrivial qualities of service.
(A Grid allows its constituent resources to be used in a coordinated fashion to deliver various qualities of service, relating for example to response time, throughput, availability, and security, and/or co-allocation of multiple resource types to meet complex user demands, so that the utility of the combined system is significantly greater than that of the sum of its parts.)
So far the grid has lacked real standardization, many different companies are beginning to utilize grids, but run into problems when trying to link these proprietary grids together.
Grid Security Requirements
The broad area of security within grids can be broken down into five main areas. These areas can then be examined in turn with their specific requirements established. The five main areas of security:
Authentication
People sometimes get confused between the terms authentication and authorization. Authentication is to ascertain whether a person is bona fide. Authorization is to decide whether they are allowed to perform some given action. Below are a short list of issues relating to authentication:
Provision for Mutual Authentication
An authorized person is trusted to use a service. An unauthorized person is not trusted to use a service. You cannot ascertain authorization until the person in question is authenticated unequivocally as that person and not an impostor. It is also necessary for a person to ascertain that a service is the one they are looking for and not an impostor posing as that service, before handing over potentially important material. Therefore the need for mutual authentication provision is vitally important within any grid software.
Third Parties
Many grids make use of third party Certification Authorities (CA’s) to enable mutual authentication. A CA is used to validate people who apply for certificates for use in mutual authentication. They ensure that a person is bona fide before handing them a certificate. That certificate is signed by the CA to state which CA issued it. Therefore in the mutual authentication process it is a trusted third party that is in effect vouching for who a person is.
Use of Proxies
A proxy is a temporary credential used to make use of services without the need for a user to individually authorize each request. They are an important component of the mutual authentication process .
Ambiguity
One of the benefits of Virtual Organizations (VO’s) is their mobility; the geographical proximity of users is not important. Members of the same VO may communicate via different grids entirely (potentially using different software). This leads to the need for different grids to inter-communicate; this task is hindered by ambiguity in grid software design. Grid security is potentially a major source of ambiguity due to the variety of security models in use by different grids.
Authorization
Authorization mechanisms deal with issues beyond that of authentication, as authentication only proves who you are.
Access to services
Access should be limited to those with permission to do so.
Access to hardware / Software / Data
Access should only be authorized to restricted actions on a machine. Users should not have free rein over other people’s resources. For example, access to a certain piece of software or dataset may be allowed, but access to other resident software may need to be restricted.
User Interaction
Users should only be able to communicate with a recognized service through a specified interface for the purposes of authorization / authentication and data transmission.
Confidentiality
Issues with confidentiality are more complex in that the requirements are less easily defined. Most of the issues in this area are concerned with what it is acceptable for a given individual to see.
Communications
Transmissions between parties should be secured to allow the transport of sensitive or private data and / or programs.
Multi-level services
In the case of multi-level services agreed information flows must be set out before a servicem is utilized, to take into account what information if any should be passed on of a users identity and / or information about them to subsequent sub services.
Secure Areas
Users should have a secure area from which to run programs. Data should not be accessible to others from outside nor should the program be able to affect other processes running on a machine outside of that area. (Sandbox approach)
Integrity
Issues with integrity concentrate on what prevents subversion of a system if someone did get in. They also deal with recovery from damage done either intentionally or unintentionally.
Mobility
The grid requires a security mechanism which allows users to move their activities between machines without extensive problems relating to setup and use of other machines, whilst maintaining the same degree of authentication, authorization and integrity within the grid itself.
Standardization
In order to ensure that different systems using potentially modified security mechanisms maintain the integrity of the grid it is essential that the core expectations of what the security mechanisms can and cannot do, be made clear. The easiest way to ensure this is by standardizing grid security as far is as feasible.
Management Control
Some form of centralized security model should exist for VO’s to allow for the addition / removal / and alteration of user privileges without the need for excessive manipulation of the underlying setup of the system. In many systems built in expiry of ID has been used to control revocation etc.

Dynamicity
Many of the possible uses for future grids within VO’s and companies depend on a rapid deployment strategy, which requires a security mechanism which can be easily installed and maintained with a modular approach allowing it to be adapted to specific circumstances. There is also a general design consideration to make the compulsory security model as minimal and expandable as possible to avoid contradictory or restrictive structures within the core architecture.

General Model of Globus

Public Key Cryptography
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 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.
Digital Signatures
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.
Certificates
A central concept in GSI(Grid Security Infrastructure) 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.
Mutual Authentication
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. The 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.
Confidential Communication
By default, the GSI does not establish confidential (encrypted) communication between parties. Once mutual authentication is performed, the GSI gets out of the way so that communication can occur without the overhead of constant encryption and decryption.
The 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 the 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. The 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.

Securing Private Keys
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 pass phrase). To use the GSI, the user must enter the pass phrase required to decrypt the file containing their private key.
We have also prototyped the use of cryptographic smartcards in conjunction with the GSI. This allows users to store their private key on a smartcard rather than in a filesystem, making it still more difficult for others to gain access to the key.
Delegation and Single Sign-On
The GSI provides a delegation capability: an extension of the standard SSL protocol which reduces the number of times the user must enter his pass phrase. 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 pass phrase can be avoided by creating a proxy.
A proxy consists of a new certificate (with a new public key in it) and a new private key. 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.
Note that the 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 Project is actively working with the Grid Forum and the IETF to establish proxies as a standard extension to TLS so that GSI proxies may be used with other TLS software.

Extended Security Model For Grid
Assumptions:
1. Widespread grid adoption within companies of large / medium size.
2. Business outsourcing of tasks to specialist companies to simplify increasing maintenance and running costs. eg:     Storage ,Software Access ,Dataset Access ,Hardware Access
3.The majority of business grid users will utilize such services, but will be largely unaware of their own company utilizing excess cycles on their office machines to cut costs; effectively hosting some services of its own (potentially for export as services themselves).
Once those assumptions have been taken into account it is possible to see how the grid might look if it were to continue using its current security model in the future. One of the biggest problems is that of scalability. Now we show first attempt to control the scalability problem and then a generally workable approach. We assumes that the existing mechanisms of public key infrastructures and X.509 certificates will continue to remain the core of the model. One solution to this task would be to introduce the concept of group certificates, where everyone in the company used the same certificate. This method would at first look quite workable; unfortunately problems emerge when one considers the security implications of such a development. It weakens the PKI because it is by its very design a one to one mechanism. Issues with stolen copies, revocation of existing copies etc make this approach infeasible.
A possible solution
What is really needed is to reduce the amount of work the service has to do to establish authorization, without doing so by looking up the actual person However the traditional view of people being given roles does not work very well in the grid either. The main issues are that it is very difficult to give people meaningful roles, and people understand different things by those roles. These systems also tend to lose the security granularity to the stage where it is difficult to determine who uses a system if you need to. They do however make authorization much simpler as you are only checking whether a certain role can use a service. Therefore what is actually needed is the flexibility of a role based system, but with the potential to hold the same amount of information as the current systems. This is a somewhat daunting task as at first it would appear that the two methods are in direct opposition to each other. However it is possible to augment the two successfully, as described below:
Role Augmented X.509 Authorization (RAXA)
In order to make this security model as simple as possible. Basically Globus(general grid infrastructure(model)) uses X.509 certificates for authentication and authorization purposes. One of the problems with this approach is related to the way in which authorization occurs. The existing Globus security model only authorizes individuals to use machines, rather than groups of people. As the X.509 protocol is virtually standardized and well accepted this document wisely does not alter its operation in any way. It does however add to the authentication and authorization process an extra piece of evidence besides the X.509 certificate itself. This evidence is held within a separate file that accompanies the certificate. This approach avoids the need to re-engineer the existing X.509 format to add any extra fields. This proposal assumes a user may wish to have more than one “role” relating to them in the file. In its present form this information cannot be used as a validation mechanism due to its lack of credibility. Meaning anybody could write the entire accompanying file or alter it, or lie about their role in the company; therefore it is clear that individual users could not be trusted to write their own entries for security reasons. Thus a user could request an entry from a trusted centralized authority at each company / VO, which could in turn write the entry itself and send it to the user (after checking on the users request). However this still poses the problem that the user could change the entry when they receive it. In order to secure the individual entries from tampering and to prove who created them a type of digital signature can be created.
**Role entry consists of Name of organization, Unique identifier from X.509 certificate, Date Issued, Date of Expiry