Electronic Payment Systems 20-763 Lecture 8 CreditCard Protocols: SSL,TLS, SET
description
Transcript of 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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Secure Sockets Layer (SSL) Handshake
if it has one
SOURCE: WEB SECURITY
SYMMETRIC
SYMMETRIC
ASYMMETRIC
ASYMMETRIC
SECURETRANSMISSION BEGINS HERE
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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)
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
SSL (Secure Sockets Layer)
HANDLES COMMUNICATIONWITH THE APPLICATION
ProtocolsINITIALIZES COMMUNCATIONBETWEEN CLIENT & SERVER
INITIALIZES SECURECOMMUNICATION
HANDLES DATACOMPRESSION
ERROR HANDLING
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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 }
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
SSL Handshake Messages
THE SSL PROTOCOLDEFINES VARIOUSMESSAGE TYPESEXCHANGED BETWEENCLIENT AND SERVER
INTERNET
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Forming the Master Secret
SOURCE: THOMAS, SSL AND TLS ESSENTIALS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Forming the Key Material
SOURCE: THOMAS, SSL AND TLS ESSENTIALS
JUST LIKE FORMINGTHE MASTER SECRET
EXCEPT THE MASTERSECRET IS USED HEREINSTEAD OF THEPREMASTER SECRET
. . .
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Obtaining Keys from the Key Material
SOURCE: THOMAS, SSL AND TLS ESSENTIALS
SECRET VALUESINCLUDED IN MESSAGE
AUTHENTICATION CODES
INITIALIZATION VECTORSFOR DES CBC ENCRYPTION
SYMMETRIC KEYS
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
SSL (Secure Sockets Layer)
Some payment services using SSL:
• Credit Card Network
• Secure-Bank.Com
• Web-Charge
• SecureTrans
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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)
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
SET in Practice
SOURCE: http://www.software.ibm.com/commerce/payment/specsheetetill.html
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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:
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Customer Processing of PInitRes
PInitRes:{ TransIDs,RRPID,Chall_C,Chall_M,PEThumb,[Thumbs] }
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
Customer Processing of PInitRes
PInitRes:{ TransIDs,RRPID,Chall_C,Chall_M,PEThumb,[Thumbs] }
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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.
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
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
20-763 ELECTRONIC PAYMENT SYSTEMS
FALL 2001
COPYRIGHT © 2001 MICHAEL I. SHAMOS
QA&