1. Cryptography in e-Business Guest Lecture, November 13, 2006, Olin College Steven R. Gordon Prof. of Info Tech Management Babson College

2. Agenda  Simple protocols –Logging in: MS-CHAP  PKI Protocols –About PKI –Secure Email –Secure Web Transactions: SSL

3. Logging In With MS-CHAP A Simple Application

4. MS-CHAP Challenge-Response Authentication Protocol 2. Verifier sends Challenge Message Challenge Applicant (Client) Verifier (Server) 1. Verifier creates Challenge Message Note: Both the client and the server know the client’s password. Source: Panko: Corporate Computer and Network Security by Raymond Panko, Prentice-Hall, 2005.

5. MS-CHAP Challenge-Response Authentication Protocol 3. Applicant creates a Response Message: (a)Adds password to Challenge Message (b) Hashes the resultant bit string (c) The hash is the Response Message ChallengePassword Response Hashing (Not Encryption) Source: Panko: Corporate Computer and Network Security by Raymond Panko, Prentice-Hall, 2005.

6. MS-CHAP Challenge-Response Authentication Protocol 4. Applicant sends Response Message without encryption Transmitted Response Source: Panko: Corporate Computer and Network Security by Raymond Panko, Prentice-Hall, 2005.

7. MS-CHAP Challenge-Response Authentication Protocol ChallengePassword Expected Response Hashing 5. Verifier adds password to the Challenge Message it sent. Hashes the combination. This is the expected Response Message. Source: Panko: Corporate Computer and Network Security by Raymond Panko, Prentice-Hall, 2005.

8. MS-CHAP Challenge-Response Authentication Protocol Expected ResponseTransmitted Response =? 6. If the two Response Messages are equal, the applicant knows the password and is authenticated. Sever logs Client in. Note that only hashing is involved. There is no encryption. Source: Panko: Corporate Computer and Network Security by Raymond Panko, Prentice-Hall, 2005.

9. Advantages of MS-CHAP  The password never gets transmitted  Eve can see the challenge and response  Eve cannot learn the password  Eve cannot respond to the challenge

10. Problems With MS-CHAP?

11. Solutions to Key Distribution Problem  A selects a key and physically delivers it to B.  Trusted third party key distribution center selects a key and physically delivers it to A and B.  If A and B already share a key, it can be used to distribute a new key.  If A and B already share keys with key distribution center, it can distribute a new key.  Or …

12. Public Key Encryption  Each user gets a pair of keys –1 private; 1 public  Public key is shared with the world and used for encryption  Private key is kept private and used for decryption  There is no way to determine the private key from knowledge of the public key  There is no need to exchange keys secretly

13. Public Key Encryption Alice creates message Bob’s public keyBob’s private key Bob reads message Encrypted message Eve cannot read intercepted message because Eve does not have Bob’s private key

14. Authentication  How does Bob know that message came from Alice?  Everyone knows Bob’s public key  Solution: –Alice signs the message

15. Authentication: Signing a Message  Alice hashes the message  She encrypts the hash, date, and time with her private key and appends it to message (signature)  Then entire message is encrypted with Bob’s public key

16. How Does Bob Know Message is From Alice?  Bob decrypts the message and reads the signature  Tries to decrypt the signature with Alice’s public key –OK: Must be Alice -- only she has the corresponding private key –Not OK: Sent by someone else

17. Non-Repudiation  Alice cannot repudiate message  Signature is hers  Signature hash matches document  Nobody else could have sent it and Bob could not have made it up

18. Integrity  Nobody can intercept the message, modify it, and resend  If so, hash would be incorrect

19. Potential Problems with Public Key Cryptography  Too hard to keep track of all partners’ public keys  What if partner wants to change public key (perhaps private key was compromised)?  Cannot trust sender to send you their public key, because they could be imposter  Solution is Public Key Infrastructure

20. Solution -- Digital Certificate  What is it? –Document signed with the private key of a well known third party (certificate issuer)  What does it contain –Name and public key of certificate owner –Serial number, expiration date –Other info on rights and privileges of owner –Name of certificate issuer

21. Public Key Infrastructure Analog to Physical World Physical  Signatures/Seal  Envelope  ID (passport/license)  Notary/Bank PKI  Digital Signature  Encryption  Digital certificate  Certificate authority

22. Certificate Authority (CA)  The CA is a trusted and known authority for issuing digital certificates  Examples: –VerisignVerisign –ThawteThawte –InstantSSLInstantSSL

23. How Does Bob Know Alice’s Certificate is Valid?  It is “signed” by a recognized certificate authority  It identifies Alice and her public key

24. Key Management Issues  Who generates the key pairs? –Should the CA have access to everyone’s private key? –If the CA doesn’t have a copy of the private key, how does it know that it has the right public key

25. Key Management Issues  Should the CA need to see physical proof of identity before issuing a certificate? –If not, how can CA avoid being fooled? –If so, how can CA have adequate geographical coverage?

26. Key Management  What if a company wanted multiple keys for its different subsidiaries, departments, and/or servers? –Should it be allowed to generate new keys and sub-certificates?

27. Key Management  Where and how should private keys be stored?  How can a certificate be revoked?  How is a certificate renewed?

28. PKI Components and Relationships Source: PGP Corporation webcast, “PGP Education Series -- Is PKI Relevant?”, viewed on 3/18/04.

29. PKI Components  Need to add Certificate Revocation List –Usually maintained by CA –Periodically downloaded to CA’s cross- certificate partners

30. Hierarchical Trust Relationships  Trust users if you trust the root CA  Trust based on brand  Example: Verisign Source: http://www.pgpi.org/doc/pgpintro/http://www.pgpi.org/doc/pgpintro/

31. Network Trust Relationships  There is no root authority  Based on who knows who  Assumes six degrees of separation  Example: PGP

32. PKI Standards Leave (too many?) Options  X.509 Version 3 Certificate –Version, Validity period, Serial Number –Issuer identifier (could be domain name, email, or directory name) and signature –Subject identifier (same options), public key, and algorithms used for encryption –Optional identifiers for issuer and subject –Optional extensions –CA’s digital signature

33. Examples of Optional X.509 Certificate Extensions  List of allowed uses (such as only for email)  Certificate policies  Subject directory attributes  CRL distribution points  Additional signers

34. PKI Application: Secure Email

35. Obtain a Free Personal Digital Certificate  Go to ComodoComodo  Fill out form selecting defaults  Accept

36. Pick Up and Install Digital Certificate  Within a few minutes, you’ll receive email with your collection password  Click on Collect and Install Certificate  If you are using Outlook –Follow the instructions to pick up and install your digital  Otherwise, do not continue until you have Outlook installed and configured

37. Configure Outlook to Use Your Certificate  In Outlook, select Tools/Options/Security  Click the “Settings” button in the Encrypted e- mail section  Click the “Choose” button to select your certificate for signing and encryption  Check “Send these certificates with signed messages”  Click OK, Apply, and OK

38. Sign An E-Mail Message  Create an email message to yourself  Click Options/Security Settings/Add Digital Signature  Send the message

39. Check Your Digital Signature  Note “secure message” icon in your inbox next to incoming message  Open message. Note security icon in upper right corner  Click on the security icon

40. Click on Details

41. Click on Signer then View Details

42. Click on View Certificate Explore: Issuer Statement Trust tab Certification Path tab

43. Now click on Details tab Click on any of the fields, including Public key, to see certificate details.

44. Close the Message  Click OK and Close and Close to return to the message view  Close the message

45. Optional: Configure Outlook to Always Use Your Certificate  Select Tools/Options/Security  Check “Add digital signature …”  Click Apply and OK

46. Adding Encryption  Create a new message to yourself  Select Options/Security Settings/Encrypt  Try to send the message. What happens?  You can only send encrypted messages to people whose public keys are published

47. Publish Your Public Key  Select Tools/Options/Security  Select “Publish to GAL…” –Outlook confirms you are publishing your key to the global address list –Click on OK –Click on OK again to close Security window

48. Test Your Encryption  Send yourself a message  Note encryption icon next to message in inbox  Click on blue lock icon in upper right corner

49. Details are available for the Encryption Layer. If message is signed, details will also be available for the signer.

50. Your Certificate is Known to IE  Select Tools/ Internet Options/ Content  Click Certificates  Highlight your Comodo certificate  Click on View

51. PKI Applications: Secure Web Transactions With SSL  Works below the application layer  Creates a secure channel between a client and server  Can be used to secure a “session”

52. SSL Protocol Simplified Source: http://www.rdcormia.com/COIN56/presentations/Security.ppthttp://www.rdcormia.com/COIN56/presentations/Security.ppt

53. SSL Pros and Cons  Server authentication  Client authentication  Integrity  Confidentiality  Establishes “session”  Can be used by any application  No support for non- repudiation  No encryption of IP or TCP headers Pros Cons

54. How HTTP Uses SSL  HTTP invokes SSL if URL starts with https://  Browsers display a lock when in the status area when SSL is in use

55. Contact Information Prof. Steven Gordon eMail: gordon@babson.edugordon@babson.edu Tel: 781-239-4571 Web: http://faculty.babson.edu/gordonhttp://faculty.babson.edu/gordon