CmpE 476 Spring 2003 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_at_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 (contnd)
• The most complicated part, 13 msgs in 4 phases
• Phase 1 Establish security capabilities
  Client_Hello including SSL version, nonce (32
  bit timestamp28byte 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 (contnd)
• 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 (contnd)
• 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 XORing 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
  (Merchants 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 (contnd)
• 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 (contnd)
• 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 (contnd)
• 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.