Grid security seminar mohit modi
Upcoming SlideShare
Loading in...5
×
 

Grid security seminar mohit modi

on

  • 200 views

Grid Computing

Grid Computing

Statistics

Views

Total Views
200
Views on SlideShare
200
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Grid security seminar mohit modi Grid security seminar mohit modi Document Transcript

  • Visvesvaraya National Institute Of Technology Computer Science And Engineering Seminar Report Grid Security Presented By: Mohit Modi (BT08CSE043) Project Supervisor: O.G.Kakde
  • AbstractA Computational Grid is a collection of heterogeneous computers and resources spread across multipleadministrative domains with the intent of providing users easy access to these resources. There are manyways to access the resources of a Computational Grid, each with unique security requirements andimplications for both the resource user and the resource provider. A comprehensive set of Grid usagescenarios is analyzed with regard to security requirements such as authentication, authorization,integrity, and confidentiality. Here we examines the major security requirements of modern grids thengoes on to focus on the X.509 certificates used within it .The main value of these scenarios and theassociated security discussions is to provide a library of situations against which an application designercan match, thereby facilitating security-aware application use and development from the initial stages ofthe application design and invocation. A broader goal of these scenarios is to increase the awareness ofsecurity issues in Grid Computing.IntroductionA 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 differentcompanies; and addresses the issues of security, policy, payment, membership, and so forth that arise in thesesettings. 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 asauthentication, authorization, resource discovery, and resource access. As I discuss further below, it is importantthat these protocols and interfaces be standard and open. Otherwise, we are dealing with an application specificsystem.)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 multipleresource types to meet complex user demands, so that the utility of the combined system is significantly greaterthan that of the sum of its parts.)So far the grid has lacked real standardization, many different companies are beginning to utilize grids, but runinto problems when trying to link these proprietary grids together.General Model of Grid Security(Globus)Public Key CryptographyThe most important thing to know about public key cryptography is that, unlike earlier cryptographic systems, itrelies not on a single key (a password or a secret "code"), but on two keys. These keys are numbers that aremathematically related in such a way that if either key is used to encrypt a message, the other key must be used todecrypt it. Also important is the fact that it is next to impossible (with our current knowledge of mathematics andavailable computing power) to obtain the second key from the first one and/or any messages encoded with the firstkey. By making one of the keys available publicly (a public key) and keeping the other key private , a person canprove that he or she holds the private key simply by encrypting a message. If the message can be decrypted usingthe 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 easilyimpersonate the owner.Digital SignaturesUsing public key cryptography, it is possible to digitally "sign" a piece of information. Signing informationessentially means assuring a recipient of the information that the information hasnt been tampered with since itleft your hands.To sign a piece of information, first compute a mathematical hash of the information. (A hash is a condensedversion of the information. The algorithm used to compute this hash must be known to the recipient of theinformation, but it isnt a secret.) Using your private key, encrypt the hash, and attach it to the message. Make surethat 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 messageusing the same hashing algorithm you used, and will then decrypt the encrypted hash that you attached to themessage. If the newly-computed hash and the decrypted hash match, then it proves that you signed the messageand that the message has not been changed since you signed it.CertificatesA central concept in GSI(Grid Security Infrastructure) authentication is the certificate. Every user and service onthe Grid is identified via a certificate, which contains information vital to identifying and authenticating the useror 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. Inorder to trust the certificate and its contents, the CAs certificate must be trusted. The link between the CA and itscertificate 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 bythe Internet Engineering Task Force (IETF). These certificates can be shared with other public key-basedsoftware, including commercial web browsers from Microsoft and Netscape.Mutual AuthenticationIf two parties have certificates, and if both parties trust the CAs that signed each others certificates, then the twoparties can prove to each other that they are who they say they are. This is known as mutual authentication. TheGSI uses the Secure Sockets Layer (SSL) for its mutual authentication protocol, which is described below. (SSL isalso known by a new, IETF standard name: Transport Layer Security, or TLS.) Before mutual authentication canoccur, the parties involved must first trust the CAs that signed each others certificates. In practice, this means thatthey must have copies of the CAs certificates--which contain the CAs public keys--and that they must trust thatthese certificates really belong to the CAs.To mutually authenticate, the first person (A) establishes a connection to the second person (B). To start theauthentication process, A gives B his certificate. The certificate tells B who A is claiming to be (the identity), whatAs public key is, and what CA is being used to certify the certificate. B will first make sure that the certificate isvalid by checking the CAs digital signature to make sure that the CA actually signed the certificate and that thecertificate hasnt been tampered with. (This is where B must trust the CA that signed As certificate.)
  • Once B has checked out As certificate, B must make sure that A really is the person identified in the certificate. Bgenerates 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 As 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 As identity, the same operation must happen in reverse. B sends A her certificate, A validatesthe certificate and sends a challenge message to be encrypted. B encrypts the message and sends it back to A, and Adecrypts 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 othersidentities.Confidential CommunicationBy default, the GSI does not establish confidential (encrypted) communication between parties. Once mutualauthentication is performed, the GSI gets out of the way so that communication can occur without the overhead ofconstant 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 standardoptional feature of the GSI.A related security feature is communication integrity. Integrity means that an eavesdropper may be able to readcommunication between two parties but is not able to modify the communication in any way. The GSI providescommunication integrity by default. (It can be turned off if desired). Communication integrity introduces someoverhead in communication, but not as large an overhead as encryption.Securing Private KeysThe core GSI software provided by the Globus Toolkit expects the users private key to be stored in a file in thelocal computers storage. To prevent other users of the computer from stealing the private key, the file thatcontains the key is encrypted via a password (also known as a pass phrase). To use the GSI, the user must enter thepass phrase required to decrypt the file containing their private key. We have also prototyped the use ofcryptographic smartcards in conjunction with the GSI. This allows users to store their private key on a smartcardrather than in a filesystem, making it still more difficult for others to gain access to the key.Delegation and Single Sign-OnThe GSI provides a delegation capability: an extension of the standard SSL protocol which reduces the number oftimes the user must enter his pass phrase. If a Grid computation requires that several Grid resources be used (eachrequiring mutual authentication), or if there is a need to have agents (local or remote) requesting services on behalfof a user, the need to re-enter the users 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 certificatecontains the owners identity, modified slightly to indicate that it is a proxy. The new certificate is signed by theowner, rather than a CA. (See diagram below.) The certificate also includes a time notation after which the proxyshould no longer be accepted by others. Proxies have limited lifetimes.The proxys private key must be kept secure, but because the proxy isnt valid for very long, it doesnt have to keptquite as secure as the owners private key. It is thus possible to store the proxys private key in a local storagesystem without being encrypted, as long as the permissions on the file prevent anyone else from looking at themeasily. Once a proxy is created and stored, the user can use the proxy certificate and private key for mutualauthentication without entering a password.
  • When proxies are used, the mutual authentication process differs slightly. The remote party receives not only theproxys certificate (signed by the owner), but also the owners certificate. During mutual authentication, theowners public key (obtained from her certificate) is used to validate the signature on the proxy certificate. TheCAs public key is then used to validate the signature on the owners certificate. This establishes a chain of trustfrom 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 theonly software which supports the delegation extensions to TLS (a.k.a. SSL). The Globus Project is actively workingwith the Grid Forum and the IETF to establish proxies as a standard extension to TLS so that GSI proxies may beused with other TLS software.Problems with Globus securityScalabilityThe Globus Security Infrastructure (GSI) makes extensive use of X.509 certificates, they have been found to besufficiently secure for the small scale implementations so far. However the scalability of such a system is very poorfor the receiving machine. The current grid authorization mechanisms is almost wholly concentrated on the use ofAccess Control Lists (ACL’s) holding details of every individual who is authorized to use a system.CA TrustVery careful consideration has to be given to which CA to sign up with and which to accept certificates from. Ifyour computer knows to trust a certain CA it will trust all the certificates that are issued from it that turn outvalid. Globus runs its own test CA for use in development of the toolkit. There are however many reasons why thisCA is not suitable for use in real business. The Globus test CA merely checks that the certificate requests domainmatches that of the email the request was sent from. It also checks the presence of any existing certificates for thatmachine. This level of security would be extremely inadequate for most types of grid system.Proxy CertificatesWhen a proxy certificate is generated the PEM phrase authorizes a certificate generator to sign a new temporarycertificate (self certified) which uses the original certificate as verification. ie you can prove the original certificatesowner signed the proxy by entering the PEM phrase. This leaves a dilemma, a new public / private key set isgenerated for use while the proxy is active. The new private key cannot be secured by a user PEM phrase becausethat was the whole point of the proxy in the first place! Globus will not secure proxy certificates by itself. By this itis meant that the private key used is not encrypted. The machine it resides on represents the main line of defenceagainst them being altered or stolen by outside forces. The reasoning behind this being that the certificate itself isonly temporary and uses a different private key from the original permanent certificate anyway; however the riskis not necessarily negligible as a user can make a proxy certificate valid for as long as they wish.
  • Extended Security Model For GridAssumptions:� Widespread grid adoption within companies of large / medium size.� Business outsourcing of tasks to specialist companies to simplify increasing maintenance and running costs. eg:Storage ,Software Access ,Dataset Access ,Hardware Access� The majority of business grid users will utilize such services, but will be largely unaware of their own companyutilizing excess cycles on their office machines to cut costs; effectively hosting some services of its own (potentiallyfor 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 tocontinue using its current security model in the future. One of the biggest problems is that of scalability. Now weshow first attempt to control the scalability problem and then a generally workable approach. We assumes that theexisting mechanisms of public key infrastructures and X.509 certificates will continue to remain the core of themodel. One solution to this task would be to introduce the concept of group certificates, where everyone in thecompany used the same certificate. This method would at first look quite workable; unfortunately problemsemerge when one considers the security implications of such a development. It weakens the PKI because it is by itsvery design a one to one mechanism. Issues with stolen copies, revocation of existing copies etc make this approachinfeasible.A possible solutionWhat is really needed is to reduce the amount of work the service has to do to establish authorization, withoutdoing so by looking up the actual person However the traditional view of people being given roles does not workvery well in the grid either. The main issues are that it is very difficult to give people meaningful roles, and peopleunderstand different things by those roles. These systems also tend to lose the security granularity to the stagewhere it is difficult to determine who uses a system if you need to. They do however make authorization muchsimpler as you are only checking whether a certain role can use a service. Therefore what is actually needed is theflexibility of a role based system, but with the potential to hold the same amount of information as the currentsystems. This is a somewhat daunting task as at first it would appear that the two methods are in direct oppositionto 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 isrelated to the way in which authorization occurs. The existing Globus security model only authorizes individuals touse machines, rather than groups of people. As the X.509 protocol is virtually standardized and well accepted thisdocument wisely does not alter its operation in any way. It does however add to the authentication andauthorization process an extra piece of evidence besides the X.509 certificate itself. This evidence is held within aseparate file that accompanies the certificate. This approach avoids the need to re-engineer the existing X.509format to add any extra fields. This proposal assumes a user may wish to have more than one “role” relating tothem in the file. In its present form this information cannot be used as a validation mechanism due to its lack ofcredibility. Meaning anybody could write the entire accompanying file or alter it, or lie about their role in thecompany; therefore it is clear that individual users could not be trusted to write their own entries for securityreasons. Thus a user could request an entry from a trusted centralized authority at each company / VO, whichcould in turn write the entry itself and send it to the user (after checking on the users request). However this stillposes the problem that the user could change the entry when they receive it. In order to secure the individualentries 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 ofExpiry
  • ConclusionIn conclusion it is easy to see that the requirements of grid computing are complex, and in order to encompass newabilities and even a new interface paradigm, a number of changes are inevitable. This report highlights inparticular issues relating to Globus, and the use of the X.509 certificate model for authentication purposes. Thisreport also put forward a new form of Role based Action Control (RBAC)in the form of the RAXA extensionproposal. Given the complexities of grid computing it is possible that RBAC mechanisms may play a part in thefuture of grid computing in order to streamline access rights. However a considerable amount of work would berequired in the area to determine what level of integration with existing mechanisms is feasible.