EE579T / CS525T Network Security 6: SSL and SET

1. EE579T / CS525TNetwork Security6: SSL and SET Prof. Richard A. Stanley

2. If IPSec is So Good... • Why do we need anything else? • One could also ask, if C++ is such a good programming language, why do we need Java? • SSL provides another choice for achieving security over insecure networks (e.g. Internet) • Where they are: • IPSec operates at the network level • SSL operates at the transport level • Other protocols operate at the application level

3. Network Level Security HTTP FTP SMTP TCP IP/IPSec

4. Transport Level Security HTTP FTP SMTP SSL / TLS TCP IP/(IPSec)

5. Application Level Security S/MIME PGP SET Kerberos SMTP HTTP UDP TCP IP/(IPSec)

6. What’s a Socket? • The name, Secure Sockets Layer, implies we are securing something called a socket. What is that? • Remember that IP applications separate themselves by listening on one or more of 64K possible ports (i.e. addresses) • A socket is a fully-specified IP address, e.g. 10.1.7.203:80 or 192.168.5.7:23

7. Well-Known Ports • Many common IP services operate on what are routinely called well-known ports • Port 80: HTTP • Ports 20, 21: FTP • Port 23: Telnet • Port 25: SMTP • Port 119: NNTP • SSL operates on Port 443

8. SSL Factoids • Developed by Netscape • Current version is SSLv3, dates to mid-90’s • Many efforts along the way to develop a multi-vendor approach, all of which have led to dead ends (i.e. Microsoft did not succeed in moving Netscape to their point of view)

9. SSL Provides • Confidentiality • Using symmetric key cryptography • Integrity • Using asymmetric key cryptography and hashing • Authenticity • Using digital signatures and certificates on server, and optionally, on client side

10. SSL Architecture • Two layers of protocols on top of TCP • Top level • SSL Handshake protocol • SSL ChangeCipherSpec protocol • SSL Alert protocol • SSL Record Protocol

11. SSL Architecture Overview SSL Handshake SSL Cipher Change Spec SSL Alert HTTP SSL Record Protocol TCP IP/(IPSec) NB: This diagram does not infer the order in which the protocols are applied.

12. Sessions and Connections • An SSL session is a client/server association • Created by Handshake protocol • Defined security parameters • An SSL connection is a transport that provides a service (e.g., HTTP) • Connections are transient • Many connections can exist within a single session

13. SSL Handshake Protocol • Most complex part of SSL • Starts when client connects to server • Sets up session protocols • Selects crypto system to be used • Authenticates client and server • Sets up basis for shared secret key, the MasterSecret

14. SSL Handshake Overview Server Client 1. Supported ciphers, random number 2. Cipher choice, certificate, random number Verify certificate, Generate PreMasterSecret 3. PreMasterSecret (encrypted in server’s public key) 4. Generate keys 4. Generate keys 5. HMAC over handshake messages sent 6. HMAC over handshake messages received

15. Key Generation Server random number Client random number PreMasterSecret Label information Key Generator MasterSecret SSL session keys

16. Client/Server Random Numbers • Consist of • 32-bit timestamp • 28-byte random number generated by secure RNG • So, 32 bytes long overall • These random numbers serve as nonces • Protect against replay attacks

17. PreMasterSecret • Key to setting up secure exchange • 48-byte random value, generated by client’s secure RNG • Sent to server encrypted with server’s public key (from certificate sent in Step 2) • Provides the secure basis for computing the MasterSecret

18. SSL-Supported Ciphers Block Ciphers Stream Ciphers

19. SSL Keys • The MasterSecret allows calculation of four symmetric keys, used as follows: • Authentication key for client to server data • Authentication key for server to client data • Encryption key for client to server data • Encryption key for server to client data • Use of symmetric keys in these areas allows for faster data transfer than asymmetric key

20. HMAC Revisited • Hashed Message Authentication Code is a recursive MAC • I.e., it is a hash of data that includes a hash • Both hash functions inputs padded by repeated instances of 5C hex (opad) or 36 hex (ipad) • Both the “internal” and “external” hash is computed using a secret key, developed from the MasterSecret

21. SSL ChangeCipherSpec • This protocol is used to change from one encryption algorithm to another • Called “strategies” in the RFC • To change ciphers, client and server negotiate a new CipherSpec and keys • Then send ChangeCipherSpec message, which triggers use of the new algorithm and keys • CipherSpec usually changed at end of SSL handshake, but can be done anytime

22. SSL Alert Protocol • Used to provide connection management • Involves messages such as\ • Digital certificate status • Handshake failure • MD failure • Two levels of alert • Warning: nonfatal problem • Fatal: immediately terminates session

23. SSL Record Protocol • Provides two SSL services: • Confidentiality • Using shared symmetric keys from MasterSecret • Message integrity • Using MAC generated using shared symmetric keys from MasterSecret • Also provides for message fragmentation and (optionally) compression (lossless)

24. SSL Overview • At a minimum, SSL authenticates the server to the client and establishes a secure data session (confidentiality + integrity) • This is what happens when the lock closes on your browser while you are eShopping • Careful--JavaScript can make the lock close! • Optionally, if the client has a certificate acceptable to the server, the session can be authenticated in both directions

25. SSL Versions • Current version is Version 3.0 • Version 2.0 was the first version to actually see commercial service • Contains many security flaws • Don’t use it unless absolutely necessary! • Current browsers all support SSL 3.0

26. How Do You Get It? • SSL comes pre-configured on modern browsers, which also have a large suite of root certificates • SSL must be enabled on the appropriate server during the server configuration process • Easy on IIS -- check boxes to select parameters • A completely different build for Apache

27. How Do You Know If You Have It? • SSL is identified by the mnemonics HTTPS, FTPS, SMTPS • Operates on port 443 rather than port 80 (used by HTTP) • When operating with an HTTP connection, the URL will begin https://... • Conversely, if SSL is enabled, it can be accessed by addressing https://...

28. After SSL: TLS • Transmission Level Security (TLS) is an IETF approach to creating a “non-vendor specific” SSL • TLS 1.0 is actually SSL v3.1, and the SSL handshake so identifies it • TLS uses a different suite of ciphers • TLS uses HMAC differently from SSL • Supported by all current browsers

29. Before SSL: S-HTTP • Before SSL was developed and fielded, another secure system was developed for signing and encrypting HTTP information • S-HTTP includes some features that SSL omits, such as having previously signed documents on a server • For all intents and purposes, S-HTTP is a dead-end protocol, not implemented in current browsers or other clients

30. SSL Summary • SSL provides a means for secure transport layer communications in TCP/IP networks • SSL is a commonly used protocol, developed by Netscape, but ubiquitously used in browsers, etc. • The key element of SSL is the handshake protocol

31. SET: Secure Electronic Transaction • Security specification to protect credit card transactions conducted over the Internet • Product of MasterCard and Visa call for proposals to develop such a standard • Differs from encryption standards so far discussed in its intent and implementation • Introduced the concept of a dual digital signature, which can have other uses

32. SET Services • Secure communications among all parties involved in a transaction • Authentication using X.509v3 certificates • Privacy, as only the information required by each party to the transaction is provided to that party • We will see some details of how this works later

33. Key Concepts • Order information (OI) and payment information (PI) are separate, but linked • Vendor needs order information to process the order, but does not need payment information • Vendor needs to be paid, but doesn’t need the details of the payment (e.g. credit card number) • Payor does not need order information, but needs to be able to link order to payment info to prevent fraud

34. SET Overview • Confidentiality of PI and OI • Integrity of all transmitted data • Authentication • Card user is legitimate user of card • Merchant is authorized to accept card • Independent of transport security • Independent of platform, O/S, etc. • Use well-reviewed cryptographic protocols

35. SET Cryptography • Confidentiality • DES • Data integrity • SHA-1 • Authentication • X.509v3 certificates, RSA digital signatures • No choices! This is a single application with a single purpose, not a GP protocol

36. The Players • Cardholder (the customer!) • Merchant (sells the goods or services) • Issuer (of the customer’s credit card) • Acquirer (has account with merchant, provides card authorization, EFT) • Payment gateway (processes merchant payment messages) • Certification Authority (CA)

37. Sequence of Events - 1 • Customer opens SET-capable account • Customer receives digital certificate • Merchant obtains certificates • Certificate for signing messages • Certificate for public key exchange • Payment gateway’s public key certificate • Customer places order

38. Sequence of Events - 2 • Merchant verified to customer • Order and payment info sent to merchant • Merchant requests payment authorization • Merchant confirms order • Merchant provides goods and services • Merchant requests payment

39. Dual Signature: Why? • Merchant needs to know customer can pay for the goods, but does not need to know the details of the payment information • Issuer of card needs to know payment information, but does not need to know the details of the order • The order and payment info must be linked to prevent fraud

40. Dual Signature Bank PI Hash PIMD En- crypt  Hash POMD Dual Sig. OIMD Customer’s public key Customer’s private key OI Hash Merchant

41. Now What? • Merchant can compute • Decrypt of dual signature • Hash of OI (because it has OI) = OIMD • Hash of OIMD concatenated with PIMD =POMD = decrypt of DS • If these are equal, OI and PI are linked • it is infeasible to create or modify either and maintain the linkage (hashing basics) • Bank can do the same with PI

42. Payment Processing • Customer initiates purchase request • Purchase information (PI) • Order information (OI) • Cardholder certificate • Merchant verifies cardholder certificate and dual signature, processes order • Merchant requests payment through gateway, gets authorization, completes order

43. SET Summary • SET provides a robust set of specialized protocols to facilitate Internet commerce • The unique feature of SET is the dual signature, which could be applied elsewhere • SET is not required to perform Internet commerce, and is not ubiquitous • SET does not deal with security or privacy of customer data once it is stored

44. Homework • Read Stallings, Chapter 9.1 • Do the following problems from Stallings, Chapter 7: • 7.1 • 7.2