1 / 36

Electronic Payment Systems 20-763 Lecture 8 CreditCard Protocols: SSL,TLS, SET

Electronic Payment Systems 20-763 Lecture 8 CreditCard Protocols: SSL,TLS, SET. Participants. Processor. Processor. Card Associations. Merchant. Consumer. Merchant Bank (Acquirer) Sets up merchant Extends credit Assumes risk of merchant Funds merchant. Issuing Bank Issues card

janina
Download Presentation

Electronic Payment Systems 20-763 Lecture 8 CreditCard Protocols: SSL,TLS, SET

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Electronic Payment Systems20-763Lecture 8CreditCard Protocols:SSL,TLS, SET

  2. Participants Processor Processor Card Associations Merchant Consumer • Merchant Bank (Acquirer) • Sets up merchant • Extends credit • Assumes risk of merchant • Funds merchant • Issuing Bank • Issues card • Extends credit • Assumes risk of card • Cardholder reporting

  3. Credit Cards on the Internet • Problem: communicate credit card and purchasing data securely to gain consumer trust • Authentication of buyer and merchant • Confidential transmissions • Systems vary by • type of public-key encryption • type of symmetric encryption • message digest algorithm • number of parties having private keys • number of parties having certificates

  4. Credit Card Protocols VERY IMPORTANT. USAGE INCREASING • SSL 1 or 2 parties have private keys • TLS (Transport Layer Security) • IETF version of SSL • iKP (IBM) i parties have private keys • SEPP (Secure Encryption Payment Protocol) • MasterCard, IBM, Netscape based on 3KP • STT (Secure Transaction Technology) • VISA, Microsoft • SET (Secure Electronic Transactions) • MasterCard, VISA all parties have certificates OBSOLETE VERY SLOW ACCEPTANCE

  5. Secure Sockets Layer (SSL) Handshake SYMMETRIC if it has one ASYMMETRIC ASYMMETRIC SYMMETRIC SOURCE: WEB SECURITY SECURETRANSMISSION BEGINS HERE

  6. SSL (Secure Sockets Layer) • NOT a payment protocol -- can be used for any secure communications, like credit card numbers • SSL is a secure data exchange protocol providing • Privacy between two Internet applications • Authentication of server (authentication of browser optional) • Uses enveloping: RSA used to exchange DES keys • SSL Handshake Protocol • Negotiates symmetric encryption protocol, authenticates • SSL Record Protocol • Packs/unpacks records, performs encryption/decryption • Does not provide non-repudiation

  7. Secure Sockets Layer (SSL) • Layered on top of TCP/IP but below the application layer. (Requires reliable transport to operate.) • SSL is increasing in importance for Internet security • Invented by Phil Karlton (CMU Ph.D.) and others at Netscape • View protocol (63 pages)

  8. SSL (Secure Sockets Layer) ERROR HANDLING INITIALIZES SECURE COMMUNICATION HANDLES COMMUNICATION WITH THE APPLICATION Protocols INITIALIZES COMMUNCATION BETWEEN CLIENT & SERVER HANDLES DATA COMPRESSION

  9. Cipher Suite • For public-key, symmetric encryption and certificate verification we need • public-key algorithm • symmetric encryption algorithm • message digest (hash) algorithm • This collection is called a cipher suite • SSL supports many different suites • Client and server must decide on which one to use • The client offers a choice; the server picks one

  10. Cipher Suites SSL_NULL_WITH_NULL_NULL = { 0, 0 } SSL_RSA_WITH_NULL_MD5 = { 0, 1 } SSL_RSA_WITH_NULL_SHA = { 0, 2 } SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0, 3 } SSL_RSA_WITH_RC4_128_MD5 = { 0, 4 } SSL_RSA_WITH_RC4_128_SHA = { 0, 5 } SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0, 6 } SSL_RSA_WITH_IDEA_CBC_SHA = { 0, 7 } SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0, 8 } SSL_RSA_WITH_DES_CBC_SHA = { 0, 9 } SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0, 10 } INITIAL (NULL) CIPHER SUITE HASH ALGORITHM PUBLIC-KEY ALGORITHM SYMMETRIC ALGORITHM CIPHER SUITE CODES USED IN SSL MESSAGES

  11. INTERNET SSL Handshake Messages THE SSL PROTOCOL DEFINES VARIOUSMESSAGE TYPES EXCHANGED BETWEEN CLIENT AND SERVER

  12. SSL Messages SERVER SIDE CLIENT SIDE OFFER CIPHER SUITE MENU TO SERVER SELECT A CIPHER SUITE SEND CERTIFICATE AND CHAIN TO CA ROOT SEND PUBLIC KEY TO ENCRYPT SYMM KEY SERVER NEGOTIATION FINISHED SEND ENCRYPTED SYMMETRIC KEY ACTIVATE ENCRYPTION ( SERVER CHECKS OPTIONS ) CLIENT PORTION DONE ACTIVATESERVER ENCRYPTION ( CLIENT CHECKS OPTIONS ) SERVER PORTION DONE NOW THE PARTIES CAN USE SYMMETRIC ENCRYPTION SOURCE: THOMAS, SSL AND TLS ESSENTIALS

  13. SSL Encryption • Premaster secret • Created by client; used to “seed” calculation of encryption parameters • Very simple: 2 bytes of SSL version + 46 random bytes • Sent encrypted to server using server’s public key • Master secret • Generated by both parties from premaster secret and random values generated by both client and server • Key material • Generated from the master secret and shared random values • Encryption keys • Extracted from the key material

  14. Forming the Master Secret SERVER’S PUBLIC KEY IS SENT BY SERVER IN ServerKeyExchange CLIENT GENERATES THE PREMASTER SECRET ENCRYPTS WITH PUBLIC KEY OF SERVER CLIENT SENDS PREMASTER SECRET IN ClientKeyExchange SENT BY SERVER IN ServerHello SENT BY CLIENT IN ClientHello MASTER SECRET IS 3 MD5 HASHES CONCATENATED TOGETHER = 384 BITS SOURCE: THOMAS, SSL AND TLS ESSENTIALS

  15. Forming the Key Material JUST LIKE FORMINGTHE MASTER SECRET EXCEPT THE MASTER SECRET IS USED HERE INSTEAD OF THE PREMASTER SECRET . . . SOURCE: THOMAS, SSL AND TLS ESSENTIALS

  16. Obtaining Keys from the Key Material SECRET VALUES INCLUDED IN MESSAGE AUTHENTICATION CODES SYMMETRIC KEYS INITIALIZATION VECTORS FOR DES CBC ENCRYPTION SOURCE: THOMAS, SSL AND TLS ESSENTIALS

  17. SSL (Secure Sockets Layer) Some payment services using SSL: • Credit Card Network • Secure-Bank.Com • Web-Charge • SecureTrans

  18. TLS (Transport Layer Security) • SSL is so important it was adopted by the Internet Engineering Task Force (IETF) • TLS Protocol 1.0 (RFC 2246) • TLS is very similar to SSL but they do not interoperate • Goals • Separate record and handshaking protocols • Extensibility (add new cipher suites easily) • Efficiency (minimize network activity)

  19. 3 . Acquiring Bank’s Processor • direct connections to MC /VI • obtains authorization from Issuer • returns response to merchant • five digit number that must be stored • 4 . Issuing Bank / Processor • receives auth request • verifies available funds • places hold on funds 2.Card Authorization via dial, lease line, satellite 8. MC / VI debit issuers / credit acquirers 9. Acquiring Bank funds merchant Authorizations Batch Settlement • 6. Acquiring Bank / Processor • scans settlement file • verifies authorizations match captured data • prepares file for MC/VI • prepares funding file • records txs for reporting • 7. Issuing Bank / Processor • receives settlement file from MC / VI • funds MC / VI • matches txs to auths • post txs to cardholder • records transactions for reporting • 5. Merchant • stores authorizations and sales conducted • captures sales (at end of day) • submits batch for funding • 1. Customer • pays with card • card swiped • mag data read • (get signature)

  20. Industry Update Acquirer Market Share Bank Issuer Market Share 12% 19% 25% 7% 34% 5% 19% 11% 6% 40% 9% 13% Paymentech Nova First Data First USA Citigroup MBNA NPC B of A All Others Chase B of A All others • Disintermediation of Bank issuers and acquirers • Consolidation of the industry

  21. Issuing Bank Revenue interest on revolving balances interchange fee income on card purchases Expenses cost of carrying asset transactors vs. revolvers cardholder reporting, chargeback processing, customer service marketing fees / dues acquisition costs fraud - lost/stolen cards bankruptcy Acquiring Bank Revenue transaction fees charged merchants net of interchange expense earnings on deposits Expenses processing fees for authorization, settlement, funding, chargebacks, customer service marketing fees / dues acquisition costs credit / fraud risk bankruptcy Card Economics

  22. SET in Practice SOURCE: http://www.software.ibm.com/commerce/payment/specsheetetill.html

  23. SET Objectives • Confidentiality of payment and order information • Encryption • Integrity of all data (digital signatures) • Authentication of cardholder & account (certificates) • Authentication of merchant (certificates) • No reliance on secure transport protocols (uses TCP/IP) • Interoperability between SET software and network • Standardized message formats • SET is a payment protocol • Messages relate to various steps in a credit card transaction

  24. SET in the Transaction Process SET PROTOCOL FUNCTIONS: 1. Browsing 2. Product selection 3. Customer order entry 4. Selection of payment mechanism 5. Customer sends order and payment instructions 6. Merchant requests payment authorization 7. Merchant sends order confirmation 8. Merchant ships goods 9. Merchant requests payment from bank

  25. SET Security • Digital envelopes, nonces, salt • Two public-private key pairs for each party • One for digital signatures; one for key exchange messages • 160-bit message digests • Statistically globally unique IDs (XIDs) • Certificates (5 kinds) • Cardholder, Merchant, Acquirer, Issuer, Payment Gateway • Hardware cryptographic modules (for high security) • Idempotency (message can be received many times but is onlyprocessed once) f(f(x)) = f(x) • Complex protocol. Over 600 pages of detail • Dual signatures

  26. SET Process Steps (Simplified) 1. Merchant sends invoice and unique transaction ID (XID) 2. Merchant sends merchant certificate and bank certificate (encrypted with CA’s private key) 3. Customer decrypts certificates, obtains public keys 4. Customer generates order information (OI) and payment info (PI) encrypted with different session keys and dual-signed 5. Merchant sends payment request to bank encrypted with bank- merchant session key, PI, digest of OI and merchant’s certificate 6. Bank verifies that the XID matches the one in the PI 7. Bank sends authorization request to issuing bank via card network 8. Bank sends approval to merchant 9. Merchant sends acknowledgement to customer

  27. SET Supported Transactions • purchase notification • sale transaction • authorization reversal • capture reversal • credit reversal • card holder registration • merchant registration • purchase request • payment authorization • payment capture • certificate query • purchase inquiry

  28. Customer asks Merchant for digital certificates Merchant asks Customer for purchase information Merchant asks Acquirer for authorization [Merchant asks Acquirer to reverse authorization] Customer asks Merchant for transaction status Merchant asks Acquirer to capture payment SET Message Flow SET messages come in pairs: Request followed by Response Appropriate cryptography is applied to message wrappers

  29. SET Payment Initialization Purpose: Allow customer to get certificates from the Merchant Customer’s Language Card Brand (VISA, MC, etc.) Bank ID # PInitReq: { RRPID, Language, LID_C, [LID_M], Chall_C, BrandID, BIN, [Thumbs]} Request/Response Pair ID Customer’s local ID Customer’s challenge salt to Merchant’s signature freshness Thumbnails (hashes) of of certificates known to Customer Merchant’s local ID

  30. Customer Processing of PInitRes PInitRes: { TransIDs, RRPID, Chall_C, Chall_M, PEThumb, [Thumbs] }

  31. Customer Processing of PInitRes PInitRes: { TransIDs, RRPID, Chall_C, Chall_M, PEThumb, [Thumbs] }

  32. Security Fields in Order Information TRANSACTION IDs: CUSTOMER, MERCHANT, GLOBALLY UNIQUE REQUEST/RESPONSE PAIR ID CARDHOLDER’S CHALLENGE TO MERCHANT SIG FRESHNESS HASH OF ORDER DATA ORDER DATA SALT (TO GUARD AGAINST DICTIONARY ATTACK ON ORDER DATA HASH! MERCHANT’S CHALLENGE TO CARDHOLDER SIG FRESHNESS DD(x) means data +a hash of the data per PKCS #7 SOURCE:SET STANDARD

  33. SET Overhead Simple purchase transaction: • Four messages between merchant and customer • Two messages between merchant and payment gateway • 6 digital signatures • 9 RSA encryption/decryption cycles • 4 DES encryption/decryption cycles • 4 certificate verifications Scaling: • Multiple servers need copies of all certificates • Compaq sells SET software equipped for 5,000,000 certificates • NO ONE USES SET. WHY? • Check # of SET-enabled Visa Merchants in the U.S.

  34. Root CA (SET Co) Brand CA (MasterCard, Visa) Geo-Political CA (optional) (only for VISA) Cardholder CA (Banesto) Merchant CA (Banesto) Payment Gateway CA (MasterCard, Banesto in VISA) Payment Gateway Cardholder Merchant SET Certificate Hierarchy Hosted by SOURCE: INZA.COM

  35. Major Ideas • SSL, TLS are secure message protocols, not payment protocols • SSL requires the vendor to have a certificate • SSL is secure against breaking of any one form of encryption • SET is a payment protocol • SET requires all parties to have certificates

  36. Q A &

More Related