1 / 85

Grid Security Services

Grid Security Services. Tiziana.Ferrari@cnaf.infn.it INFN – CNAF Corso di Laurea specialistica in Informatica Anno Acc. 2004/2005 Slide sources : Grid Security Infrastructure Tutorial, Von Welch, Uni. Of Chicago and ANL; Grid Security Infrastructure , The Globus Project and R.Buyya;

yahto
Download Presentation

Grid Security Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Grid Security Services Tiziana.Ferrari@cnaf.infn.it INFN – CNAF Corso di Laurea specialistica in Informatica Anno Acc. 2004/2005 Slide sources: Grid Security Infrastructure Tutorial, Von Welch, Uni. Of Chicago and ANL; Grid Security Infrastructure, The Globus Project and R.Buyya; Security Mechanisms – Tutorial, the European DataGrid Team, Torino, Dic 2002 Grid Security, Laura Pearlman, USC Information Sciences Institute and Globus Team Security, Antonia Ghiselli, Corso di Sistemi Distribuiti, A/A 2003-2004 Grid Security Services

  2. Outline • PART I: Introduction • PART II: Privacy, Integrity and Authentication • PART III: Secure Socket Layer (SSL) • PART IV: Grid Security Infrastructure • PART V: Authorization • References Grid Security Services

  3. PART IIntroduction Grid Security Services

  4. Security Needs • Confidentiality (privacy) • a third party cannot understand the communication • Integrity • data is not modified during communication • Non-repudiation • the sender cannot claim he didn’t send the data • Authentication • establish the identity of an entity (user, process, host, service, ...) • Authorization • establish the rights of the entity Grid Security Services

  5. Privacy • Only the sender and the receiver should be able to understand the conversation. If someone eavesdrops on the communication, the eavesdropper should be unable to make any sense out of it. This is generally achieved by encryption/decryption algorithms. • Example: imagine we want to transmit the message "INVOKE METHOD ADD", and we want to make sure that, if a third party intercepts that message (e.g. using a network sniffer), they won't be able to understand that message. We could use a trivial encryption algorithm which simply changes each letter for the next one in the alphabet. The encrypted message would be "JOWPLFANFUIPEABEE" (let's suppose 'A' comes after the whitespace character). On the other hand, the receiving end would know the decryption algorithm beforehand (change each letter for the previous one in the alphabet) and would therefore be able to understand the message. Of course, this method is trivial, and encryption algorithms nowadays are much more sophisticated. Grid Security Services

  6. Integrity • The receiving end must be able to know for sure that the message he is receiving is exactly the one that the transmitting end sent him. • Traditional encryption algorithms don't protect against these kind of attacks. For example, consider the simple algorithm we've just seen. If a third party used a network sniffer to change the encrypted message to "JAMJAMJAMJAMJAMJA", the receiving end would apply the decryption algorithm and think the message is "I LI LI LI LI LI ". • Although the malicious third party might have no idea what the message contains, he is nonetheless able to modify it (this is relatively easy to do with certain network sniffing tools). This confuses the receiving end, which would think there has been an error in the communication. • Public-key encryption algorithmsdo protect against this kind of attacks (the receiving end has a way of knowing if the message it received is, in fact, the one the transmitting end sent and, therefore, not modified). Grid Security Services

  7. Authentication and Authorization • We should be protected from malicious users who try to impersonate one of the parties in the secure conversation. Again, this is relatively easy to do with some network sniffing tools. However, modern encryption algorithms also protect against this kind of attacks. • Authorization refers to mechanisms that decide when a user is authorized to perform a certain task. Authorization is related to authentication because we generally need to make sure that a user is who he claims to be (authentication) before we can make a decision on whether he can (or cannot) perform a certain task (authorization). Grid Security Services

  8. PART II(a) Privacy Grid Security Services

  9. Cryptography (1/2) • Cryptography is "the art of writing in secret characters". • Most modern algorithms are key-based. • A key-based algorithm uses an encryption key to encrypt the message. This means that the encrypted message is generated using not only the message, but also using a 'key': • The receiver can then use a decryption key to decrypt the message. Again, this means that the decryption algorithm doesn't rely only on the encrypted message. It also needs a 'key': • Some algorithms use the same key to encrypt and decrypt, and some do not. • It is absolutely necessary to have the decryption key to recover the original message. • Keys are at least 128 bits long. Grid Security Services

  10. K1 K2 Encryption Decryption M C M Cryptography (2/2) • Mathematical tool that provides some important building blocks for the implementation of a security infrastructure • Terminology • Plaintext: M • If the algorithm operates on the plaintex one bit (or byte) at a time it is called stream cipher, if itoperates on blocks of bits, it is called block cipher. • Cyphertext: C • Encryption with key K1: E K1(M) = C • Decryption with key K2: D K2(C) = M • Algorithms • Symmetric: K1 = K2 • Public Key (asymmetric): K1 ≠ K2 Grid Security Services

  11. A B ciao 3$r 3$r ciao A B ciao 3$r 3$r ciao Symmetric Algorithms • The same key is used for encryption and decryption • Benefits: • Fast • Easy to implement • Drawbacks: • how to distribute the keys? • they only guarantee privacy (integrity and authentication would have the be done some other way). • the number of keys is O(n2) • Examples: • DES • 3DES • Rijndael (AES) • Blowfish Grid Security Services

  12. Example (symmetric algorithms) • Message to encrypt: 1 2 3 4 5 6 5 4 3 2 1 • Key is "4232". To encrypt the message, we'll repeat the key as many times as necessary to 'cover' the whole message: • 1 2 3 4 5 6 5 4 3 2 1 4 2 3 2 4 2 3 2 4 2 3 The encrypted message is created by adding both numbers: • 1 2 3 4 5 6 5 4 3 2 1 + 4 2 3 2 4 2 3 2 4 2 3 ------------------------- 5 4 6 6 9 8 8 6 7 4 4 We can decrypt following the inverse process: Repeating the key as many time as necessary to cover the message, and then subtract the key character by character: • 5 4 6 6 9 8 8 6 7 4 4 – 4 2 3 2 4 2 3 2 4 2 3 ------------------------- 1 2 3 4 5 6 5 4 3 2 1 Original message Encrypted message Decrypted message Grid Security Services

  13. Asymmetric algorithms • Asymmetric algorithms: a different key is used to encrypt and decrypt the message. Grid Security Services

  14. Public Key Cryptography (1/3) • In public-key cryptography, the two keys are called the private key and the public key • Private key: This key must be know only by its owner. • Public key: This key is known to everyone (it is public) • Relation between both keys: What one key encrypts, the other one decrypts, and vice versa. That means that if you encrypt something with my public key (which you would know, because it's public), I would need my private key to decrypt the message. Grid Security Services

  15. A B ciao 3$r 3$r ciao A B ciao cy7 cy7 ciao public Public Key Cryptography (2/3) • Every user has two keys: one private and one public: • it is practically impossible to derive the private key from the public one; • a message encrypted by one key can be decripted only by the other one. • the sender cyphers using the public key of the receiver; • the receiver decripts using his private key; • if someone wants to receive an encrypted message, the sender only needs to know the receiver's public key • Examples: • Diffie-Helmann (1977) • RSA (1978) A’s keys B’s keys public private private Grid Security Services

  16. Public Key Cryptography (3/3) • Benefits • unlike symmetric algorithms, public-key systems can guarantee privacy, integrity and authentication. The basic communication seen above only guarantees privacy. We will shortly see how integrity and authentication fit into public-key systems. • publishing the public key in no way compromises the key • the number of keys is O(n) • very hard to compute the private key from the public key (which is the one everyone knows). In fact, some algorithms need several months (and even years) of constant computation to obtain the private key from the public key. • Drawbacks • not as fast as symmetric algorithms: keys are 512 bits (insecure) to 2048 bits Grid Security Services

  17. PART II(b) Message Integrity Grid Security Services

  18. Digital Signatures: Integrity in Public-Key Systems (1/2) • Digital signature: a piece of data which is attached to a message and which can be used to find out if the message was tampered with during the conversation (e.g. through the intervention of a malicious user) • The digital signature for a message is generated in two steps: • 1) Amessage digest is generated. A message digest is a 'summary' of the message we are going to transmit, and has two important properties: (1) It is always smaller than the message itself and (2) Even the slightest change in the message produces a different digest. The message digest is generated using a set of hashing algorithms. • 2) The message digest is encrypted using the sender's private key. The resulting encrypted message digest is the digital signature. • The digital signature is attached to the message, and sent to the receiver. • The receiver then does the following: • Using the sender's public key, decrypts the digital signature to obtain the message digest generated by the sender. • Uses the same message digest algorithm used by the sender to generate a message digest of the received message. • Compares both message digests (the one sent by the sender as a digital signature, and the one generated by the receiver). Grid Security Services

  19. Digital Signatures: Integrity in Public-Key Systems (2/2) • If they are not exactly the same, • the message has been tampered with by a third party. We can be sure that the digital signature was sent by the sender (and not by a malicious user) because only the sender's public key can decrypt the digital signature (which was encrypted by the sender's private key; remember that what one key encrypts, the other one decrypts, and vice versa). • If decrypting using the public key renders a faulty message digest, this means that either the message or the message digest are not exactly what the sender sent. Grid Security Services

  20. One-Way Hash Functions • Functions (H) that given as input a variable-length message (M) produce as output a string of fixed length (h) • the length of h must be at least 128 bits (to avoid birthday attacks) • given M, it must be easy to calculate H(M) = h • given h, it must be difficult to calculateM = H-1(h) • given M, it must be difficult to find M’ such that H(M) = H(M’) • Examples: • SNEFRU: hash of 128 or 256 bits; • MD4/MD5: hash of 128 bits; • SHA (Standard FIPS): hash of 160 bits. Grid Security Services

  21. Example (1/2) Grid Security Services

  22. Example (2/2) • INTEGRITY • Using public-key cryptography in this manner ensures integrity, because we have a way of knowing if the message we received is exactly what was sent by the sender. • PRIVACY • The above example guarantees only integrity. The message itself is sent unencrypted. (Note: in some cases we might not be interested in keeping the data private, we simply want to make sure it isn't tampered with. To add privacy to this conversation, we would simply need to encrypt the message). • AUTHORIZATION • The above example does guarantee, to a certain extent, the authenticity of the sender. Since only the sender's public key can decrypt the digital signature (encrypted with the sender's private key). • However, the only thing this guarantees is that whoever sent the message has the private key corresponding to the public key we used to decrypt the digital signature. Although this public key might have been advertised as belonging to the sender, how can we be absolutely certain? Maybe the sender isn't really who he claims to be, but just someone impersonating the sender. • Some security scenarios might consider that the 'weak authentication' shown in the previous example is sufficient. However, other scenarios might require that there is absolutely no doubt about a user's identity. This is achieved with digital certificates. Grid Security Services

  23. PART II(c) Authentication Grid Security Services

  24. Authentication in public-key systems • A’s digital signature is safe if: • A’s private key is not compromised • B knows A’s public key • But: how can B be sure that A’s public key is really A’s public key and not someone else’s? • A third party guarantees the correspondence between public key and owner’s identity, by signing a document which contains the owner’s identity and his public key (Digital Certificate) • Both A and B must trust this third party • Two models: • PGP: “web of trust” • X.509: hierarchical organization Grid Security Services

  25. PGP “web of trust” D B F C E A • F knows D and E, who knows A and C, who knows A and B. • F is reasonably sure that the key from Ais really fromA. Grid Security Services

  26. Digital signature • A digital certificate is a digital document that certifies that a certain public key is owned by a particular user. • This document is signed by a third party called the certificate authority (or CA). • Of course, the certificate is encoded in a digital format and is signed by a third party (the certificate authority) which does not itself take place in the secure conversation. • The signature is actually a digital signature generated with the CA's private key. Therefore, we can verify the integrity of the certificate using the CA's public key. • If you digitally sign your message with your private key, and send the receiver a copy of your certificate, he can know for sure that the message was sent by you (because only your public key can decrypt the digital signature and the certificate assures that the public key the receiver uses is yours and no one else's) Grid Security Services

  27. Trust • The CA that signs the certificate needs to be trusted. • There are no specific algorithms to decide when a CA is trustworthy, each specific user has to decide whether to trust or don't trust a CA. • The public-key system generally has a list of 'trusted CAs', which includes the digital certificates of those trusted CAs (each of these certificates, in turn, include the CA's public key, so that the digital signatures can be verified). • Some CAs are so well known that they are included by default in many public-key systems (for example, web browsers usually include VeriSign and GlobalSign certificates, because many websites use certificates issued by those companies to authenticate themselves to web browsers). • Other CAs can be added to the 'trusted list'. For example, if a local department sets up a CA, and it is trusted, then it can be added to the list. Grid Security Services

  28. X.509 Certificates (1/2) • The “third party” is called Certification Authority (CA). • An X.509 Certificate contains: • Subject: identity of the owner (It is encoded as a distinguished name); • Time of validity; • Subject’s public key: owner’s public key, this includes not only the key itself, but information such as the algorithm used to generate the public key • Issuer's Subject: CA's distinguished name; • Info on the Certification Authority; • Digital signature of the CA: the certificate includes a digital signature of all the information in the certificate. This digital signature is generated using the CA's private key. To verify the digital signature, we need the CA's public key (which can be found in the CA's certificate). Grid Security Services

  29. X.509 Certificates (2/2) • Certificates are published in a directory (e.g. LDAP or WWW) managed by the CA • CA’s periodically publish a list of compromised certificates • Certificate Revocation Lists (CRL): • The CA issues CRLs, listing certificates that they’ve granted and later revoked. • CRL format is standardized and can be parsed by software. • Relying parties use their discretion in deciding how often to check CRLs. • Online Certificate Status Protocol (OCSP): • the CA runs an OCSP server, which relying parties can query for certificate status. Grid Security Services

  30. Distinguished names • Names in X.509 certificates are not encoded simply as 'common names', such as “Mario Rossi", or "Certificate Authority XYZ", or "Systems Administrator". They are encoded as distinguished names, which are a comma-separated list of name-value pairs. For example, the following could be my distinguished name: • O=University of Pisa, OU=Department of Software Engineering, CN=Mario Rossi • A distinguished name can have several different attributes, and the most common are the following: • O: Organization • OU: Organizational Unit • CN: Common Name (generally, the user's name) • C: Country Grid Security Services

  31. CA Hierarchies (1/3) • Who signs the CA's certificate? Another CA! • This allows for hierarchies of CAs to be created. • Although a CA is not explicitly trusted (because it's not in the user’s list), it may happen that the higher-level CA that signed its certificate is trusted. This makes the lower-level CA trustworthy. Leaf of hierarchy Root of hierarchy Grid Security Services

  32. CA Hierarchies (2/3) • The user’s certificate is signed by Certificate Authority FOO. • Certificate Authority FOO's certificate is, in turn, signed by Certificate Authority BAR. Finally, BAR's certificate is signed by itself. • If you receive the user’s certificate, and don't explicitly trust CA FOO (the issuer of the user’s certificate), this doesn't automatically mean the user’s certificate isn't trustworthy. You might check to see if CA FOO's certificate was issued by a CA you do trust. If it turns out that CA BAR is in your 'trusted list', then that means that my certificate is trustworthy. • The higher-level CA (BAR) has signed its own certificate. This is not uncommon, and is called a self-signed certificate. A CA with a self-signed certificate is called a root CA, because there's 'no one above it'. To trust a certificate signed by this CA, it must necessarily be in the list of trusted CAs. Grid Security Services

  33. Authentication: Validating an X.509 Certificate (3/3) • Build a certificate chain • May be short: • CA1: a “trust anchor”, an already-known and trusted CA cert • an end entity certificate signed by CA1. • May be longer: • CA1: a “trust anchor”, an already-known and trusted CA cert • CA2: a CA cert signed by CA1 … N. CAN: A CA cert signed by CAN-1 N+1. EEC:An end-entity cert signed by CAN • Validate each certificate in the chain • Check signatures, validity times, etc. Grid Security Services

  34. Requesting a Certificate Public key • To request a certificate a user starts by generating a key pair (public and private) • The user then signs their own public key to form what is called a Certificate Request In particular, in case of Globus: • The programgrid-cert-request is used to create a public/private key pair and unsigned certificate in ~/.globus/: • Certificate request file: usercert_request.pem: unsigned certificate request file • Private key: userkey.pem, encrypted private key file, readable only by the owner • Mailusercert_request.pem to ca@globus.org • Receive a Globus-signed certificate Place in ~/.globus/usercert.pem • Other organizations may use their own CA Private key Sign Certificate Request Public Key Grid Security Services

  35. Registration Authority (RA) • The user then takes the certificate to a Registration Authority (RA) • A RA’s responsibility is to verify the user’s name • The user’s name needs to be unique within the scope of a CA • Often the RA coexists with the CA and is not apparent to the user Registration Authority Certificate Request Public Key State of Illinois ID Grid Security Services

  36. Name Issuer Public Key Signature Certificate Issuance • The CA then takes the identity from the RA and the public key from the certificate request • It then creates, signs and issues a certificate for the user Certificate Request Public Key Registration Authority Name CA Grid Security Services

  37. Files for Server Authentication • /etc/grid-security • hostcert.pem: certificate used by the server in mutual authentication • hostkey.pem: private key corresponding to the server’s certificate (read-only by root) • grid-mapfile: maps grid subject names to local user accounts • /etc/grid-security/certificates • CA certificates: CA certificates that are trusted when validating certificates, and thus needn’t be verified • ca-signing-policy.conf: defines the subject names that can be signed by each CA Grid Security Services

  38. Files for User Authentication • $HOME/.globus • usercert.pem: User’s certificate (subject name, public key, CA signature) • userkey.pem: User’s private key (encrypted using the user’s pass phrase) • /tmp • Proxy file(s): Temporary file(s) containing unencrypted proxy private key and certificate (readable only by user’s account) Grid Security Services

  39. Secure Services • A simple authenitcation mechanism can be based on the mapping between the distinguished names of the authorized Grid users to local credentials (for example, usernames in a Unix system). • This simple approach is for example used by the gatekeeper (Globus), which is responsible of • performing mutual authentication by means of files in /etc/grid-security • mapping the certificate subjects (they are distinguished names) to local users via the gridmap file. • gridmap file example: # Distinguished name Local username # /O=INFNGrid/O=INFN/OU=CNAF/CN=Tiziana Ferrari tferrari "/C=US/O=Globus/O=NPACI/OU=SDSC/CN=Richard Frost” frost "/C=US/O=Globus/O=USC/OU=ISI/CN=Carl Kesselman” u14543 "/C=US/O=Globus/O=ANL/OU=MCS/CN=Ian Foster” itf Grid Security Services

  40. jobmanager key key services map cert cert Gatekeeper: Secure Job Submission 1. Exchange certificates, authenticate, delegate 2. Check gridmap file 3. Lookup service 4. Run service program (e.g. jobmanager) 4. 2. 3. 1. client gatekeeper Grid Security Services

  41. PART IIISecurity Sockets Layer (SSL) Grid Security Services

  42. Overview • SSL is a protocol that involves two entities: a client and a server. It allows: • Server authentication to one client • Client authentication to one server • a couple client/server to establish an encrypted connection • The SSL protocol specification is by Netscape • It is based on TCP/IP and can be used by application-layer protocols such as: • HyperText Transport Protocol (HTTP) • Lightweight Directory Access Protocol (LDAP) • Internet Messaging Acces Protocol (IMAP) • Grid Security Infrastructure (GSI, see following slides) • Etc. Grid Security Services

  43. SSL features • The specification includes two protocol definitions: • SSL Record Protocol: • guarantees data integrity • Based on symmetric cryptography (e.g. DES, RC4, etc.): Keys are generated uniquely for each connection because public-key encryption is computationally expensive, systems such as SSL/TLS use symmetric cryptography (using a new, randomly-generated session key) for most operations. They use public-key encryption only for authentication and key exchange during session initiation. • SSL Handshake Protocol • It uses the SSL Record Protocol for integrity • Allows the client and server to authenticate to each other • Authentication is based on public key cryptography (e.g. RSA, DSS etc.) • Allows the client and server to negotiate the encryption algorithm (cypher) used for authentication • SSL Alert Protocol Grid Security Services

  44. SSL Records and Alert Protocols • SSL Records: this protocol provides a common format to frame all Alert, ChangeCipherSpec, Handshake, and application protocol messages. • SSL records consist of: • encapsulated data, • digital signature (Hashed-based message authentication code (HMAC) message digest MD5), • message type, • version, • length. • SSL records are 8 bytes long. Because the record length is fixed, encrypted messages sometimes include padding and pad length in the frame • SSL Alert Protocol: handles any questionable packets. If either the server or client detects an error, it sends an alert containing the error. There are three types of alert messages: warning, critical, and fatal. Based on the alert message received, the session can be restricted (warning, critical) or terminated (fatal). Grid Security Services

  45. SSL Handshake Protocol Steps: • Client sends ClientHello message. • Server acknowledges with ServerHello message • Server sends its certificate • Optional: Server requests client's certificate • Optional: Client sends its certificate • Client sends ClientKeyExhcange message • Client sends Certificate Verify message • Both send ChangeCipherSpec messages • Both send Finished messages Grid Security Services

  46. Transport Layer Security (TLS) vs SSL • Originally developed by Netscape Communications to allow secure access of a browser to a Web server, Secure Sockets Layer (SSL) has become the accepted standard for Web security . • SSLv3 now supports more security algorithms than SSLv2 . • TLS is defined in the IETF RFC 2246 • TLS is based b SSl version 3.0 Protocol Specification • However, TLS v 1.0 and SSL 3.0 do not interoperate Grid Security Services

  47. PART IVGrid Security Infrastructure Grid Security Services

  48. Problem statement • Since a grid implies crossing organizational boundaries, resources are going to be accessed by a lot of different organizations. This poses a lot of challenges: • Only certain organizations can access our resources, and that we're completely sure that those organizations are really who they claim to be. In other words, we have to make sure that everyone in my grid application is properly authenticated. • Suppose organization A asks B to perform a certain task. B, on the other hand, realizes that the task should be delegated to organization C. However, let's suppose C only trusts A (and not B). Should C turn down the request because it comes from B, or accept it since the 'original' requestor is A? • Depending on my application, I may also be interested in assuring data integrity and privacy, although in a grid application this is generally not as important as authentication. Grid Security Services

  49. Grid Security Infrastructure (GSI) based on PKI GSI: Proxies and delegation (GSI Extensions) for secure single sign-on Proxies and Delegation Transport-level security SSL/TLS PKI (CAs and Certificates) Message-level security WS-Security, XML-Encryption, XML-Signature, etc PKI: Public Key Infrastructure, SSL: Secure Socket Layer TLS: Transport Layer Security Grid Security Services

  50. GSI • Grid Security Infrastructure (or GSI) is a complete public-key system offering programmers the following three features: • Mutual authentication through digital certificates • Single sign-on • Credential delegation • GSI is composed of a set of command-line tools to manage certificates, and a set of Java classes to easily integrate security into our grid Services. • It is based on standard technologies, such as: • Transport-Level Security: Transport Layer Security protocol – TLS (formerly Secure Socket Layer - SSL) and • Message-Level Security: secure Web Services specifications (XML-Signature, XML-Encryption, etc.) Grid Security Services

More Related