SSL and TLS provide secure communication over the internet using encryption. SSL uses public key encryption to establish a secure connection and exchange keys to encrypt data sent between a client and server. It defines sessions which allow parameters like encryption algorithms to be shared for multiple connections. TLS is an updated version of SSL that uses similar record and handshake protocols. SET is an open standard that uses digital certificates and dual signatures to securely conduct credit card transactions over the internet between cardholders, merchants, issuers and payment gateways.

1. WEB Security

2. Outline Web Security Considerations Secure Socket Layer (SSL) and Transport Layer Security (TLS) Secure Electronic Transaction (SET) Recommended Reading and WEB Sites

3. Web Security Considerations WWW is Client server application over Internet and TCP/IP intranets Web is vulnerable to attacks on web servers over the Internet The WEB is visible outlet for corporates Web servers are easy to configure and manage. Complex software hide many security flaws. Subverted servers will provide access to intranet systems Users are not aware of the risks.

4. Security facilities in the TCP/IP protocol stack

5. SSL and TLS SSL was originated by Netscape TLS working group was formed within IETF First version of TLS can be viewed as an SSLv3.1

6. SSL Make use of TCP Provide reliable end to end secure communication Two layers of protocols Higher layer Handshake change cipher spec Alert Lower layer Record

7. SSL Architecture

8. SSL connection A logical client/server link A peer-to-peer connection with two network nodes. Transient. Every connection associated with one session.

9. SSL session An association between a client and a server Defines a set of parameters such as algorithms used, session number etc. An SSL session is created by the Handshake Protocol that allows parameters to be shared among the connections made between the server and the client Sessions are used to avoid negotiation of new parameters for each connection. A single session is shared among multiple SSL connections between the client and the server. In theory, it may also be possible that multiple sessions are shared by a single connection, but this feature is not used in practice.

10. SSL session The concepts of a SSL session and connection involve several parameters that are used for SSL-enabled communication between the client and the server. During the negotiations of the handshake protocol, the encryption methods are established and a series of parameters of the Session State are subsequently used within the session.

11. SSL session state A session state is defined by the following parameters: session identifier: this is an identifier generated by the server to identify a session with a chosen client, Peer certificate: X.509 certificate of the peer, compression method: a method used to compress data prior to encryption, CipherSpec: specifies the bulk data encryption algorithm (for example DES) and the hash algorithm (for example MD5) used during the session, Master secret: 48-byte data being a secret shared between the client and server “ is resumable”: this is a flag indicating whether the session can be used to initiate new connections.

12. SSL connection state The SSL connection state is defined by the following parameters: Server and client random: random data generated by both the client and server for each connection, Server write MAC secret: the secret key used for data written by the server, Client write MAC secret: the secret used for data written by the client, Server write key: the bulk cipher key for data encrypted by the server and decrypted by the client, Client write key: the bulk cipher key for data encrypted by the client and decrypted by the server, Initialisation vectors: for CBC mode of block cipher Sequence number: sequence numbers maintained separately by the server for messages transmitted and received during the data session.

13. Record protocol Services provided Confidentiality Encryption of payloads using shared secret key obtained from handshake protocol Message Integrity MAC using shared secret key obtained from handshake protocol

14. SSL Record Protocol Operation

15. SSL Record Format

16. Change cipher spec protocol Payload of record protocol Consist of single message Single byte value = 1 Purpose of message Cause copy of pending state to current state Updates cipher suite to be used on the current connection

17. Alert protocol Conveys SSL alerts to peer Payload of record Consists of two bytes 1 st byte : warning or fatal 2 nd byte: code for specific alerts

18. SSL Record Protocol Payload

19. Handshake Protocol The most complex part of SSL. Allows the server and client to authenticate each other. Negotiate encryption, MAC algorithm and cryptographic keys. Used before any application data are transmitted.

20. handshake protocol phases 1 st phase Establish security capabilities 2 nd phase Server authentication and key exchange 3 rd phase Client authentication and key exchange 4 th phase finish

21. Handshake Protocol Action

22. Full handshake

23. Re-establish old session

24. Cryptographic computations Shared master secret : 48 byte Creation in 2 stages Pre-master secret exchanged RSA Diffie Hellman Master secret calculated at both ends Use of master secret at client end Client write MAC secret Client write key Client write IV Use of master secret at client end Server write MAC secret Server write key Client write IV

25. Transport Layer Security The same record format as the SSL record format. Defined in RFC 2246. Similar to SSLv3. Differences in the: version number (3.1) message authentication code (HMAC, TLScomressed.version) pseudorandom function ( different from SSL) alert codes ( more in TSL) cipher suites ( fortezza dropped) client certificate types ( fortezza schemes not included) certificate_verify and finished message ( calculation different) cryptographic computations ( different from SSL) Padding ( any amount for total length = Xblock length upto max 255 bytes )

27. Master secret in SSL Master secret = MD5(pre_master_secret||SHA(“A”||pre_master_secret||ClientHello.random||serverHello.random))|| MD5(pre_master_secret||SHA(“BB”||pre_master_secret||ClientHello.random||serverHello.random))|| MD5(pre_master_secret||SHA(“CCC”||pre_master_secret||ClientHello.random||serverHello.random))||

28. Key block in SSL Key block = MD5(master_secret||SHA(“A”||master_secret||serverHello.random||ClientHello.random))|| MD5(master_secret||SHA(“BB”||pre_master_secret|| serverHello.random||ClientHello.random))|| MD5(master_secret||SHA(“CCC”||pre_master_secret|| serverHello.random||ClientHello.random))||…..

29. Master secret and Key block in TLS Master secret = PRF(pre_master_secret, “master secret”, ClientHello.random||serverHello.random) Key block = PRF(master_secret, “key expansion”, Security Parameters.server_random||SecurityParameters.client_random) PRF(secret,label,seed) = P_MD5(S1,label||seed)XOR P_SHA-1(S2,label||seed)

30. Secure Electronic Transactions An open encryption and security specification. Protect credit card transaction on the Internet . Companies involved: MasterCard, Visa, IBM, Microsoft, Netscape, RSA, Terisa and Verisign Not a payment system. Set of security protocols and formats.

31. SET Services Provides a secure communication channel in a transaction. Provides tust by the use of X.509v3 digital certificates. Ensures privacy.

32. SET Overview Key Features of SET: Confidentiality of information Integrity of data Cardholder account authentication Merchant authentication

33. SET Participants

34. SET participants Cardholder: authorised holder of credit card issued by issuer. Interacts with merchants over internet Merchant : Seller of goods over internet Issuer : Bank which issues credit card to card holder. Acquirer : Fin institution which has an account with a merchant, processes card authorisation and payments. Payment gateway: Interfaces between SET and Payment network CA: Issues X.509 certificates to All players

35. Sequence of events for transactions The customer opens an account. The customer receives a certificate. Merchants have their own certificates. The customer places an order. The merchant is verified. The order and payment are sent. The merchant request payment authorization. The merchant confirm the order. The merchant provides the goods or service. The merchant requests payments.

36. Dual Signature

37. Payment processing Cardholder sends Purchase Request

38. Payment processing Merchant Verifies Customer Purchase Request

39. Payment processing Payment Request: Initiate request Initiate response Purchase request Purchase response Payment Authorization: Authorization Request Authorization Response Payment Capture: Capture Request Capture Response

40. Payment Request Initiate request from card holder Request certificates to merchant Incl: Brand of cc, ID req/resp, nonce Initiate response by merchant Response signed by Kr of merchant Incl: Cust nonce, new nonce, trans ID, merchant’s signature certificate, payment gateways key exchange certificate Cardholder verifies merchant and gateway’s certificates Generates OI- ref to order PI – card number, value etc

41. Payment Request Purchase request by card holder Forwarded to payment gateway Incl: EKs[PI+Dual sig+OIMD], EKUch[Ks] To merchant OI+dual sig+PIMD, CH certificate Purchase response by merchant Incl: Trans ID, response block with order ack signed by merchant using Kr, merchant’s signature certificate Card holder Verifies merchant’s signature on response block

42. Payment Authorization Authorization Request to payment gateway from merchant forwarded PI+dual sig+OIMD+EKUch[Ks] Generated Auth block: EKms[SignKrm[Trans ID]] EKUpg[EKms] Certificates Card holder signature key, merchant signature key and merchant key exchange certificates Payment gateway Verifies all certificates, obtains EKms, decrypts auth block, verifies merchant’s sign, verifies dual sign, verifies trans ID, requests and receives an auth from issuer Authorisation response by payment gateway to merchant Auth block: EKpgs[SignKrpg[authorisation]] EKUm[EKpgs] Capture token info: EKpgs[SignKrpg[capture token]] Certificate Gateway’s signature key certifixcate

43. Payment capture Capture Request by merchant to payment gateway Capture req block Amount+Trand ID+token signed and encrypted by merchant This is verified by payment gateway. Req issuer to release payment Capture Response by payment gateway to merchant confirmation of payment

44. Recommended Reading and WEB sites Drew, G. Using SET for Secure Electronic Commerce . Prentice Hall, 1999 Garfinkel, S., and Spafford, G. Web Security & Commerce. O’Reilly and Associates, 1997 MasterCard SET site Visa Electronic Commerce Site SETCo (documents and glossary of terms)