Unit 1: Protection and Security for Grid Computing

1. Unit 1: Protection and Security for Grid Computing

2. Protection and security overview We will cover a lot of things, including • Basic concepts of cryptography • Authentication in context of Grid • Authorization in context of Grid • For both of these the focus is on what happens in a distributed environment, not on a particular OS We will not cover in lecture several things that are covered in the handouts • read these for your own enrichment • quizzes will emphasize the material covered in lecture – be sure to read the assigned outside reading material!

3. Some lecture slides in part from Cryptography and Network Security Third Edition by William Stallings Lecture slides by Lawrie Brown Corresponds to handout [Nutt, Chapter 14, section 14.4]

4. Cryptography • Basic idea: convert clear text (also called plain text – the original message) to ciphertext (the encrypted message) ciphertext = encrypt(plaintext, KE) plaintext = decrypt(ciphertext, KC) • Can either make the encryption process hidden, so that an intruder cannot know it • Or, can use a known technique and use a hidden key

5. Secret-Key Cryptography • traditional secret/single key cryptography uses one key • shared by both sender and receiver • if this key is disclosed communications are compromised • also is symmetric, parties are equal • hence does not protect sender from receiver forging a message & claiming is sent by sender

6. Simple Secret-Key Example • P = “abra” which has the binary representation: 0x61627261, or • 01100001011000100011100101100001 Choose a random string of bits as the key • 10011101010010001111010101011100 Can use a simple XOR of the binary to get C • 11111100001010101000011100111101 To get P back, use the same algorithm and key! The most popular secret key encryption today is DES.

7. Public-Key Cryptography • probably most significant advance in the 3000 year history of cryptography • uses two keys – a public & a private key • asymmetric since parties are not equal • uses clever application of number theoretic concepts to function • complements rather than replaces secret key cryptography

8. Public-Key Cryptography • public-key/two-key/asymmetric cryptography involves the use of two keys: • a public-key, which may be known by anybody, and can be used to encrypt messages, and verify signatures • a private-key, known only to the recipient, used to decrypt messages, and sign (create) signatures • is asymmetric because • those who encrypt messages or verify signatures cannot decrypt messages or create signatures

9. Public-Key Cryptography

10. Why Public-Key Cryptography? • developed to address two key issues: • key distribution – how to have secure communications in general without having to trust a KDC with your key • digital signatures – how to verify a message comes intact from the claimed sender • public invention due to Whitfield Diffie & Martin Hellman at Stanford Univ. in 1976 • known earlier in classified community

11. Public-Key Characteristics • Public-Key algorithms rely on two keys with the characteristics that it is: • computationally infeasible to find decryption key knowing only algorithm & encryption key • computationally easy to en/decrypt messages when the relevant (en/decrypt) key is known • either of the two related keys can be used for encryption, with the other used for decryption (in some schemes)

12. Sending a message with double encryption

13. Public-Key Applications • can classify uses into 3 categories: • encryption/decryption (provide secrecy) • key exchange (of secret session keys) • Session keys can be used in a session between a client and a server to encrypt network messages. • They expire at the end of the session – the short life span makes them difficult to break • digital signatures (provide authentication)

14. SSL: An example of key exchange using public/private keys • SSL (Secure Socket Layer) and TLS (Transport Layer Security) use public/private keys to exchange a secret key used during a session • The SSL handshake consists of several steps, as follows: Step 1: The client contacts the server and sends SSL version number, a random number X, and some additional information

15. SSL Handshake Step 2: The server sends the client the SSL version number, random number Y, and its public key (packaged into a certificate) Step 3: The client verifies that the server is who is says it is by examining the certificate (more on this in a bit) Step 4: The client creates a “premaster secret” using X, Y, and other information. It encrypts the secret using the server’s public key.

16. SSL Handshake Step 5: If the server has requested authentication, the client sends its own certificate and the premaster secret to the server Step 6: The server authenticates the client by examining the client’s certificate, uses its private key to decrypt the premaster secret, then uses it to generate the master secret. The client also generates the master secret.

17. SSL Handshake Step 7: Both the client and the server use the master secret to generate the session secret key Steps 8 (9): The client (server) sends a message to the server (client) telling it that it will use the secret key. It sends a second message encrypted with the secret key.

18. SSL Handshake Step 10: The handshake is complete and the SSL session has begun. Read http://developer.netscape.com/docs/manuals/security/sslin/index.html for a description about the SSL handshake.

19. Digital Signatures Use a combination of a message digest (hash) and public key encryption to be able to guarantee that a message was sent by who claimed to send it Step 1: I create a message digest of the message Step 2: encrypt the message digest with my private key (that only I know). This is my digital signature

20. Digital Signatures Step 3: Append the message with my digital signature and send the message in the open network Step 4: Anyone with my public key can decrypt the signature, apply the hash function to get the hash, then compare the hash with the decrypted signature to see if they are the same See http://www.youdzone.com/signature.html

21. How secure is public key encryption? • like private key schemes brute force exhaustive search attack is always theoretically possible • but keys used are too large (>512bits) • security relies on a large enough difference in difficulty between easy (en/decrypt) and hard (cryptanalyse) problems • more generally the hard problem is known, its just made too hard to do in practise • requires the use of very large numbers • hence is slow compared to private key schemes

22. RSA – the most commonly used Public Key encryption algorithm • by Rivest, Shamir & Adleman of MIT in 1977 • best known & widely used public-key scheme • based on exponentiation in a finite (Galois) field over integers modulo a prime • nb. exponentiation takes O((log n)3) operations (easy) • uses large integers (eg. 1024 bits) • security due to cost of factoring large numbers • nb. factorization takes O(e log n log log n) operations (hard)

23. Distribution of Public Keys • Can be considered as using one of: • Public announcement • Publicly available directory • Public-key authority • Public-key certificates

24. Public Announcement – a bad distribution technique! • users distribute public keys to recipients or broadcast to community at large • eg. append PGP keys to email messages or post to news groups or email list • major weakness is forgery • Anyone can create a key claiming to be someone else and broadcast it • Until forgery is discovered can masquerade as claimed user

25. Recall the Digital Signature Application • What if my enemy Doug wants to fool you into thinking that I sent a message? • Doug might send you a public key that he claims is mine (and keep the matching private key to himself). • If you believe that the public key Doug sent is mine, then Doug could sign a message with the private key and pretend to be me. • How can you be sure that the public key you receive is mine?

26. Public Key Distribution Using a Publicly Available Directory • can obtain greater security by registering keys with a public directory • directory must be trusted with properties: • contains {name,public-key} entries • participants register securely with directory • participants can replace key at any time • directory is periodically published • directory can be accessed electronically • still vulnerable to tampering or forgery

27. Public Key Distribution Using a Public-Key Authority • improve security by tightening control over distribution of keys from directory • has properties of directory • and requires users to know public key for the directory • then users interact with directory to obtain any desired public key securely • does require real-time access to directory when keys are needed

28. Public-Key Authority

29. Public Key Distribution Using Public-Key Certificates • certificates allow key exchange without real-time access to public-key authority • a certificate binds identity to public key • usually with other info such as period of validity, rights of use etc • with all contents signed by a trusted Public-Key or Certificate Authority (CA) • can be verified by anyone who knows the public-key authority’s public-key

30. Public-Key Certificates

31. Public Key Certificates • IF you trust the Certificate Authority • AND you are confident that the KUauth key that you have is really the public key of the Certificate Authority • THEN, you can decrypt the certificate with confidence to obtain the public key of the sender Read http://docs.sun.com/source/816-6154-10/contents.htm section starting with Certificates and Authentication

32. Public Key Distribution Using Public-Key Certificates • The problem is really an authentication problem – do you believe that the sender of the certificate is who it says it is? Next, a short diversion on authentication (section 14.1 and 14.2 from [Nutt]) and then we will talk about X.509, a standard for public-key certificates.

33. Authentication and Authorization A user is authenticated when you are sure that the user is who he/she claims to be (e.g., that user logs in to an account with a password). A user is authorized to use a resource if he/she is allowed to have access to it. • Authorization always implies authentication. • Cryptography may be used to encode information so that only an authorized user can access it • Authorized users may be given a key/password or other mechanism for accessing information

34. Authentication and Authorization Many distributed systems do not separate the step of authentication and the step of authorization to use a resource – if you can authenticate to a resource, then you can use it. • Authentication, authorization, and cryptography are protection mechanisms • A security policy is a specification that determines how the protection mechanism should be used.

35. Authentication Authentication in the real world is hard because you have to trust the authenticator • Most common approach is a userid and password • A second common approach is certificate-based authentication

36. Userids and password • Consider a login prompt: login% gshrub There is no such user login% • A different login prompt behavior: login% gshrub password% ****** authentication failed login% • The second version is more secure because it reveals less information to a potential intruder • FYI, see the distribution of passwords in [Nutt, 578]

37. Authentication in the Network • Example of a program that executes without authenticating – a worm • Morris’s Internet Worm is an infamous breach of security in the 1980’s

38. X.509 Certificates • A standard for digital certificates developed by the International Telecommunications Union (ITU) • Is used for SSL/TLS certificates