electronic payment systems 20-763 lecture 8 creditcard protocols: ssl,tls, set

20-763 ELECTRONIC PAYMENT SYSTEMS

FALL 2001

COPYRIGHT © 2001 MICHAEL I. SHAMOS

Electronic Payment Systems20-763

Lecture 8CreditCard Protocols:

SSL,TLS, SET


FALL 2001


Participants

•Issuing Bank •Issues card•Extends credit•Assumes risk of card•Cardholder reporting

Card Associations

Merchant•Merchant Bank (Acquirer)•Sets up merchant•Extends credit•Assumes risk of merchant•Funds merchant

Consumer

Processor Processor


FALL 2001


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


FALL 2001


Credit Card Protocols

• SSL 1 or 2 parties have private keys

• TLS (Transport Layer Security)– IETF version of SSL

• i KP (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 IMPORTANT.USAGE INCREASING

VERY SLOWACCEPTANCE


FALL 2001


Secure Sockets Layer (SSL) Handshake

if it has one

SOURCE: WEB SECURITY

SYMMETRIC

SYMMETRIC

ASYMMETRIC

ASYMMETRIC

SECURETRANSMISSION BEGINS HERE


FALL 2001


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


FALL 2001


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)


FALL 2001



HANDLES COMMUNICATIONWITH THE APPLICATION

ProtocolsINITIALIZES COMMUNCATIONBETWEEN CLIENT & SERVER

INITIALIZES SECURECOMMUNICATION

HANDLES DATACOMPRESSION

ERROR HANDLING


FALL 2001


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


FALL 2001


Cipher SuitesINITIAL (NULL) CIPHER SUITE

PUBLIC-KEYALGORITHM

SYMMETRICALGORITHM

HASHALGORITHM

CIPHER SUITE CODES USEDIN SSL MESSAGES

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 }


FALL 2001


SSL Handshake Messages

THE SSL PROTOCOLDEFINES VARIOUSMESSAGE TYPESEXCHANGED BETWEENCLIENT AND SERVER

INTERNET


FALL 2001


SSL Messages

OFFER CIPHER SUITEMENU TO SERVER

SELECT A CIPHER SUITE

SEND CERTIFICATE ANDCHAIN TO CA ROOT

CLIENT SIDE SERVER SIDE

SEND PUBLIC KEY TOENCRYPT SYMM KEY

SERVER NEGOTIATIONFINISHED

SEND ENCRYPTEDSYMMETRIC KEY

SOURCE: THOMAS, SSL AND TLS ESSENTIALS

ACTIVATEENCRYPTION

CLIENT PORTIONDONE

( SERVER CHECKS OPTIONS )

ACTIVATESERVERENCRYPTION

SERVER PORTIONDONE

( CLIENT CHECKS OPTIONS )

NOW THE PARTIES CAN USE SYMMETRIC ENCRYPTION


FALL 2001


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


FALL 2001


Forming the Master Secret


SERVER’S PUBLIC KEYIS SENT BY SERVER INServerKeyExchange

CLIENT GENERATES THEPREMASTER SECRET

ENCRYPTS WITH PUBLICKEY OF SERVER

CLIENT SENDS PREMASTERSECRET IN ClientKeyExchange

SENT BY CLIENTIN ClientHello

SENT BY SERVERIN ServerHello

MASTER SECRET IS 3 MD5HASHES CONCATENATEDTOGETHER = 384 BITS


FALL 2001


Forming the Key Material


JUST LIKE FORMINGTHE MASTER SECRET

EXCEPT THE MASTERSECRET IS USED HEREINSTEAD OF THEPREMASTER SECRET

. . .


FALL 2001


Obtaining Keys from the Key Material


SECRET VALUESINCLUDED IN MESSAGE

AUTHENTICATION CODES

INITIALIZATION VECTORSFOR DES CBC ENCRYPTION

SYMMETRIC KEYS


FALL 2001



Some payment services using SSL:

• Credit Card Network

• Secure-Bank.Com

• Web-Charge

• SecureTrans


FALL 2001


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)


FALL 2001


1. Customer•pays with card•card swiped•mag data read•(get signature)

5. Merchant•stores authorizations and sales conducted•captures sales (at end of day)•submits batch for funding

AuthorizationsBatch Settlement

2.Card Authorizationvia dial, lease line, satellite

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

6. Acquiring Bank / Processor•scans settlement file •verifies authorizations match captured data•prepares file for MC/VI•prepares funding file•records txs for reporting

4 . Issuing Bank / Processor•receives auth request•verifies available funds•places hold on funds

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

8. MC / VIdebit issuers /

credit acquirers9. Acquiring Bankfunds merchant


FALL 2001


Industry Update

Acquirer Market Share12%

7%

40%11%

5%

25%

Paymentech Nova First Data

NPC B of A All Others

Bank Issuer Market Share19%

19%

13%9%6%

34%

First USA Citigroup MBNAChase B of A All others

• Disintermediation of Bank issuers and acquirers• Consolidation of the industry


FALL 2001


Card EconomicsIssuing 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


FALL 2001


SET in Practice

SOURCE: http://www.software.ibm.com/commerce/payment/specsheetetill.html


FALL 2001


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


FALL 2001


SET in the Transaction Process

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

SET PROTOCOLFUNCTIONS:


FALL 2001


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 only processed once) f (f (x)) = f (x)

• Complex protocol. Over 600 pages of detail• Dual signatures


FALL 2001


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


FALL 2001


SET Supported Transactions

card holder registration

merchant registration

purchase request

payment authorization

payment capture

certificate query

purchase inquiry

purchase notification

sale transaction

authorization reversal

capture reversal

credit reversal


FALL 2001


SET Message Flow

Customer asks Merchantfor digital certificates

Merchant asks Customerfor purchase information

Merchant asks Acquirerfor authorization

[Merchant asks Acquirerto reverse authorization]

Merchant asks Acquirerto capture payment

Customer asks Merchantfor transaction status

SET messages come in pairs: Request followed by

Response

Appropriate cryptographyis applied to messagewrappers


FALL 2001


SET Payment Initialization

PInitReq: { RRPID, Language, LID_C, [LID_M], Chall_C, BrandID, BIN, [Thumbs]}

Card Brand(VISA, MC, etc.)

Bank ID #Customer’sLanguage

Request/Response Pair ID

Thumbnails (hashes) ofof certificates known to

Customer

Customer’s local ID

Merchant’s local ID

Customer’s challengesalt to Merchant’s

signature freshness

Purpose: Allow customer to get certificates from the Merchant


FALL 2001


Customer Processing of PInitRes

PInitRes:{ TransIDs,RRPID,Chall_C,Chall_M,PEThumb,[Thumbs] }


FALL 2001


Security Fields in Order Information

TRANSACTION IDs: CUSTOMER,MERCHANT, GLOBALLY UNIQUE

REQUEST/RESPONSE PAIR ID

CARDHOLDER’S CHALLENGE TOMERCHANT SIG FRESHNESS

MERCHANT’S CHALLENGE TOCARDHOLDER SIG FRESHNESS

HASH OF ORDER DATA

ORDER DATA SALT (TO GUARDAGAINST DICTIONARY ATTACKON ORDER DATA HASH!

DD(x) means data +a hash ofthe data per PKCS #7

SOURCE: SET STANDARD


FALL 2001


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.


FALL 2001


Root CA (SET Co)

Geo-Political CA (optional)(only for VISA)

Brand CA(MasterCard, Visa)

Merchant CA(Banesto)

Cardholder CA (Banesto)

Cardholder

Payment Gateway CA(MasterCard, Banesto in VISA)

Merchant Payment Gateway

SET Certificate Hierarchy

Hosted by

SOURCE: INZA.COM


FALL 2001


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


FALL 2001


QA&

electronic payment systems 20-763 lecture 8 creditcard protocols: ssl,tls, set

Documents