CmpE 476 Spring 2 003 Notes on SSL and SET

1. CmpE 476 Spring 2003Notes on SSL and SET Dr. M. Ufuk Caglayan Department of Computer Engineering Bogazici University, Istanbul caglayan@boun.edu.tr Spring, 2003

2. SSL (Secure Socket Layer) - 1 • Properties • By Netscape, currently Version 3, open, widely used in point-to-point safe transfer of information, such as a credit card number • Architecture : two layers • Record Protocol over TCP and Handshake, Change Cipher Spec, Alert protocols over Record Protocol. HTTP uses Record Protocol

3. SSL - 2 • SSL connection • Peer to peer, transient,associated with one session • SSL session • Between client and server, by handshake protocol • Defines a set of cryptographic security parameters which can be shared among multiple connections • To avoid expensive negotiation new security parameters

4. SSL - 3 • Session state • Id, X509v3 certificate of the peer, compression algorithm, cipher spec (encryption, hash and all their parameters), master secret (48 bytes), resumability for new connections • Connection state • Server/client random numbers, write MAC keys, write keys for conventional encryption, CBC mode IV, 64 bit sequence numbers

5. SSL - 4 • SSL Record Protocol • Fragment application data into 16384 byte blocks • Compress fragment (null in v3) • Add MAC, which is slight variation of HMAC • Encrypt fragment plus MAC. IDEA, RC2-40, RC4-40, RC4-128, DES, DES-40, 3DES support • Append 5 byte SSL record header : Content type, SSL major/minor versions, data length

6. SSL - 5 • SSL Change Cipher Spec Protocol • To copy the pending state of connection to current state so that new cipher suite is active • SSL Alert Protocol • To convey alert messages (warning, fatal types) • SSL Handshake Protocol • Server/client authenticate each other, negotiate an encryption and a MAC algorithm and their keys

7. SSL - 6 • SSL Handshake Protocol (contn’d) • The most complicated part, 13 msg’s in 4 phases • Phase 1 : Establish security capabilities : Client_Hello including SSL version, nonce (32 bit timestamp+28byte random#), session id, cipher suite (in decreasing order of key exchange and conventional encryption algorithm preference plus algorithm parameters). Server_Hello similar.

8. SSL - 7 • SSL Handshake Protocol (contn’d) • Phase 2 : Server Authentication & Key ExchangeCertificate, server _key_ exchange, certificate request, server_hello_done messages from server to client • Phase 3 : Client Authentication & Key ExchangeCertificate, client _key_ exchange, certificate verify messages from client to server

9. SSL - 8 • SSL Handshake Protocol (contn’d) • Phase 4 : Finishchange_cipher_spec and finish messages from client to server and change_cipher_spec and finish messages from server to client • The idea here in 4 phases is to assure identities, agree on key exchange algorithm, exchange keys exchange nonces to prevent replays and agree on conventional encryption and hash algorithms.

10. SSL vs TLS • TLS : Transport Layer Security • Internet Society IETF standardization initiative to produce Internet standard version of SSL • TLS Version 3.1 is SSL Version 3 with minor modifications • TLS uses HMAC, SSL uses an earlier version of HMAC (concatenation vs XOR’ing of padded bytes with secret key), additional alert codes

11. Secure Electronic Transaction SET - 1 • An open encryption and security spec, mainly for credit card transactions • Initiated by MasterCard and VISA, many companies involved in its creation • Version 1, Feb. 1996 • SET is not a payment system, complex spec in 3 books, 971pp (SSL 63pp, TLS 71pp)

12. SET - 2 • SET participants • Card holder, Merchant, (Card) Issuer, Acquirer (Merchant’s Bank), Payment Gateway, Certification Authority (CA) • Sequence of Events in using SET • Customer opens credit card account with issuer • Customer receives a X.509v3 certificate • Merchants opens account with acquirer

13. SET - 2 • Sequence of Events (contn’d) • Merchant gets X.509v3 certificates for its two public keys, one for signing messages, one for key exchange. Also merchant should have the copy of the certificate of payment gateway. • Customer places an order. • Merchant returns the order with its certificate. Customer verifies the id of merchant.

14. SET - 3 • Sequence of Events (contn’d) • Customer sends Order and Payment Information (OI & PI) to merchant together with customer certificate. Merchant verifies customer. Merchant cannot see/change PI Concept of Dual Signature for OI and PI • Merchant requests authorization from payment gateway/acquirer and gets authorization

15. SET - 4 • Sequence of Events (contn’d) • Merchant sends confirmation of the order to customer, then ships the goods or provides the service to customer • Merchant requests payment to payment gateway • All events encrypted and signed and certified

16. SET - 5 • Dual Signature : An important innovation • SHA-1 hash of PI is concatenated with SHA-1 hash of OI. SHA-1 hash of two hashes is RSA signed by customer KR (DS). • Merchant gets OI, hash of PI, DS and by using customer KU can verify DS without seeing PI • Bank gets PI, hash of PI, DS and by using customer KU can verify DS without seeing OI.

17. SET - 6 • Has strong cryptography, • Transactions result in many SET messages, • Difficult for individual cardholders to get X.509v3 certificatesTherefore, SET is expensive to use and it will probably be used only for large amount transactions, i.e. organizational macro payments.