Credit Card

Protocols
 Outline
• Credit card participants (7)
• Secure Sockets Layer (SSL)
– security with public keys
• Secure Electronic Transactions (SET)
– authentication with certificates
• 3-D Secure
– authentication without certificates
• Fraud
• Online card reading
 Participants

Processor Processor

Card
Association

Merchant
• Issuing Bank Consumer • Merchant Bank (Acquirer)
• Issues card • Sets up merchant
• Extends credit • Extends credit
• Assumes risk of card • Assumes risk of merchant
• Cardholder reporting • Funds merchant
 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
 Credit Card Protocols
• SSL 1 or 2 parties have private keys
VERY IMPORTANT.
• TLS (Transport Layer Security) USAGE INCREASING
– IETF version of SSL

• i KP (IBM) i parties have private keys

• SEPP (Secure Encryption Payment Protocol)
– MasterCard, IBM, Netscape based on 3KP OBSOLETE
• STT (Secure Transaction Technology)
– VISA, Microsoft

• SET (Secure Electronic Transactions) VERY SLOW

ACCEPTANCE; DEAD
– MasterCard, VISA all parties have certificates
RAPID
• 3-D Secure real-time authentication EXPANSION
 SSL (Secure Sockets Layer) Concept
PURPOSE: ALLOW A USER WITHOUT A CERTIFICATE TO SEND
SECRET INFORMATION (A CREDIT CARD NUMBER) EFFICIENTLY

Merchant
Non-Internet (telephone) line
Credit Card
Secure Acquirer
“tunnel”
through the • Consumer must
Internet trust merchant with
card Acquirer
• Similar to ordinary notifies
phone order
Internet Issuer
• High transaction
costs

Credit Card
Consumer Issuer bills Consumer Issuer

SOURCE: MARVIN SIRBU

 SSL Overview
• Client has no certificate
• Merchant has a certificate, therefore public
and private keys
• Merchant sends its certificate; client now MERCHANT
CLIENT SERVER
has merchant’s public key
• Client can send encrypted data to merchant
• Merchant can’t send encrypted data to
client
• BRILLIANT IDEA: client creates a
symmetric key, sends it to merchant
• Now both can communicate secretly and
fast

SOURCE: CARL SMIGIELSKI

 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 user optional (not authenticated)
• Uses enveloping: public-key encryption used to
exchange symmetric keys
• SSL Handshake Protocol
– Negotiates symmetric encryption protocol
• SSL Record Protocol
– Packs/unpacks records, performs encryption/decryption
 SSL Handshake MERCHANT
CLIENT SERVER

Client and Server Hello

Client now Certificate Merchant’s

has server’s digital
public key Contains server’s public key certificate

Generate Client Key Exchange Decrypt

pre-master Pre-master secret encrypted
pre-master
secret with server’s public key secret

Derive ChangeCipherSpec Derive

session key session key
from from
pre-master Finished pre-master
secret secret

SOURCE: CARL SMIGIELSKI

 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
 Cipher Suites
SSL_NULL_WITH_NULL_NULL = { 0, 0 } INITIAL (NULL) CIPHER SUITE

PUBLIC-KEY SYMMETRIC HASH

ALGORITHM ALGORITHM ALGORITHM

SSL_RSA_WITH_NULL_MD5 = { 0, 1 } CIPHER SUITE CODES USED

IN SSL MESSAGES
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 }
 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)
 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
 Forming the Master Secret
SERVER’S PUBLIC KEY
IS SENT BY SERVER IN
ServerKeyExchange

CLIENT GENERATES THE

PREMASTER SECRET
SENT BY SERVER
ENCRYPTS WITH PUBLIC IN ServerHello
KEY OF SERVER
SENT BY CLIENT
CLIENT SENDS PREMASTER IN ClientHello
SECRET IN ClientKeyExchange

MASTER SECRET IS 3 MD5

HASHES CONCATENATED
TOGETHER = 384 BITS

SOURCE: THOMAS, SSL AND TLS ESSENTIALS

 Forming the Key Material

JUST LIKE FORMING

THE MASTER SECRET

EXCEPT THE MASTER ...

SECRET IS USED HERE
INSTEAD OF THE
PREMASTER SECRET

SOURCE: THOMAS, SSL AND TLS ESSENTIALS

Obtaining Keys from the Key Material

SECRET VALUES SYMMETRIC KEYS INITIALIZATION VECTORS

INCLUDED IN MESSAGE FOR DES CBC ENCRYPTION
AUTHENTICATION CODES

SOURCE: THOMAS, SSL AND TLS ESSENTIALS

 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
• Browsers understand both SSL and TLS
• Goals
– Separate record and handshaking protocols
– Extensibility (add new cipher suites easily)
– Efficiency (minimize network activity)
 Secure Electronic Transactions (SET)
• Merchant doesn’t see card #
Secure • Uses Internet to reach acquirer
“tunnel” • High transaction cost
through the
Internet

Internet
Credit Card
Acquirer

Credit Card
Issuer
Consumer Issuer bills Consumer

SOURCE: MARVIN SIRBU, CMU

Parties in SET

SOURCE: WILLIAM STALLINGS

 SET Flow
cardholder merchant
order info + payment instruction MERCHANT
CERT
ack + services

CARD-
Internet payment info, authorization capture capture
HOLDER authorization response + request response
CERT request capture token + token
AT PURCHASE AT END OF DAY

es sing
ro c payment
tion p
GATEWAY
ri z a CERT
autho ro cessin
g gateway
re p
captu

payment network
money transfer
issuer acquirer
(cardholder’s bank) (merchant’s bank)
 SET Message Flow

Non-SET Financial Network Non-SET

Payment
Card Issuer
Gateway

9. 5. Auth. Request
Payment Capture 6. Auth.
10. Response
Payment Capture
Request Response
SET
1.
7.
3. Init
Inquiry
Request
PurchaseRequest
Request
Card 2. Init Response
Response Merchant
8.
4. Inquiry
Purchase Response
Holder
SET

SOURCE: HUTTER/STEPHAN
 Dual Signature
• Links two messages intended for different recipients
SENDER’S
PRIVATE KEY
data1 hash

hash sign
DUAL
SIGNATURE
data2 hash

RECIPIENT 1 RECIPIENT 2
RECEIVES: RECEIVES:

data1 data2

HASH OF HASH OF
DATA 2 DATA 1
DUAL
SIGNATURE
 Using the Dual Signature

PI Hash Bank

PIMD

ôô Hash POMD En- Dual Sig.

crypt
OIMD
Customer’s
public key

Customer’s
private key
OI Hash

Merchant

SOURCE: RICHARD STANLEY

Cardholder Purchase Request

SOURCE: HENRIC JOHNSON

 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 (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
 SET Security
• Digital envelopes, nonces
• 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
 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
 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?
• Visa used to list all SET-enabled merchants on its website. No
more.
 eCashPad
• Convert a “Card Not Present” transaction into
“Card Present”

• Installed in guest rooms at Arizona Holiday Inn

 3-D Secure
• Idea: authenticate user without a certificate
• Requires the user to answer a challenge in real-time
• Challenge comes from the issuing bank, not the
merchant
• Issuing bank confirms user identity to merchant
 3-D (3-Domain) Model

Internet
Merchant
Cardholder
eMerchant Server
Wallet Server

Issuer Acquirer

Payment
Association
Issuer Domain Interoperability Domain Acquirer Domain

SOURCE: MASTERCARD
 3-D Secure Process Flow

1. Card and order data

SSL
Merchant

Cardholder 2. Determine
issuer
MPI
SSL Merchant Plug-In
3. Check user
participation Global 5. Verify user
Directory participation

SSL
Issuer 4. Verify user
participation Payment Gateway

ACS Acquirer
Access Control Server

SOURCE: MASTERCARD
 3-D Secure Process Flow

10. Payer Authentication Response

Merchant
SSL
Cardholder

7. Payer Authentication Request MPI

8. Cardholder Authentication
9.Payer Authentication Response
11. Normal Transaction

Global
Directory
Issuer
Payment Gateway

12. Normal Authorization Process

ACS Acquirer

SOURCE: MASTERCARD
 3-D Secure (1)
1. Customer enters details at
merchant site Active Merchant Merchant
Customer 3-D Secure
Acquirer Plug-in
Merchant Plug-in

2. Merchant Plug-in checks card issuer

participation with VISA directory

3. VISA directory checks card

participation with issuer Visa
Directory

3-D Secure
Access Control Payment
Server Visanet Gateway
Issuer Acquirer
SOURCE: KMIS
 3-D Secure (2)
6. Merchant Plug-in redirects
customer’s browser to issuer’s Access
Control Server with transaction details Active Merchant Merchant
Customer 3-D Secure
Acquirer Plug-in
Merchant Plug-in

5. Location of issuer’s Access Control

Server sent to Merchant Plug-in

4. Issuer confirms card

participation Visa
Directory

3-D Secure
Access Control Payment
Server Visanet Gateway
Issuer Acquirer
SOURCE: KMIS
 3-D Secure (3)
Active Merchant Merchant
Customer 3-D Secure
Acquirer Plug-in
Merchant Plug-in

7. Issuer’s Access Control

Server requests username
and password from customer

8. Customer presents
password into issuer system Visa
Directory
9. Issuer’s Access Control
Server validates password,
signs response and redirects
customer to Merchant Plug-in

3-D Secure
Access Control Payment
Server Visanet Gateway
Issuer Acquirer
SOURCE: KMIS
 3-D Secure (4)
14. Merchant confirms transaction
and issues receipt to customer Active Merchant Merchant
Customer 3-D Secure
Acquirer Plug-in
Merchant Plug-in

13. Acquirer
sends transaction
response back to
merchant
10. Merchant
Visa submits normal
Directory transaction to
acquirer

11. Acquirer sends authorization requests to issuer

3-D Secure via Visanet
Access Control Payment
Server Visanet Gateway
Issuer 12. Issuer sends authorization response to acquire Acquirer
via Visanet
 Major Ideas
• Credit cards are used because of convenience
• But the processing cost is high
• 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
• SET uses dual signatures
• 3-D Secure provides authentication without certificates
Q&A
 SSL (Secure Sockets Layer)

INITIALIZES SECURE ERROR HANDLING

COMMUNICATION

HANDLES COMMUNICATION
WITH THE APPLICATION

Protocols
INITIALIZES COMMUNCATION
BETWEEN CLIENT & SERVER
HANDLES DATA
COMPRESSION
 SSL Handshake Messages
CLIENT SIDE SERVER SIDE
OFFER CIPHER SUITE SELECT A CIPHER SUITE
MENU TO SERVER
SEND CERTIFICATE AND
CHAIN TO CA ROOT

SEND PUBLIC KEY TO

ENCRYPT SYMM KEY

SEND ENCRYPTED SERVER NEGOTIATION

SYMMETRIC KEY FINISHED

ACTIVATE
ENCRYPTION
CLIENT PORTION ( SERVER CHECKS OPTIONS )
DONE
ACTIVATESERVER
ENCRYPTION
( CLIENT CHECKS OPTIONS ) SERVER PORTION
DONE
NOW THE PARTIES CAN USE SYMMETRIC ENCRYPTION

SOURCE: THOMAS, SSL AND TLS ESSENTIALS

 High Risk Merchants
Product Services Method of Sale
Illegal goods Investment opportunities Outbound telemarketing

Book and record club Travel agency Inbound teleservices

Pawn shop Dating/escort service Door to door sales

Vitamins Limousine/taxi service Future services

Computer software Bail/bond payments Out of home sales

Stamp/coin stores Massage parlors Nonpermanent locations

Auto rental/leasing Employment Flea markets/no store

services agencies/collection front
services
Water purification Timeshare/audio text pay Use of third party for
per call product, sales, or delivery
Secure Electronic Transactions (SET)
3-D Secure

SOURCE: VISA
 3-D Secure Transaction Flow
Cardholder visits merchant site 2 Merchant Plug-in queries
1 and selects “Buy” Directory for account
participation
MERCHANT
Cardholder

Merchant
Plug-in

Directory
Issuer 3 Directory
response
5
Access
Control indicates
Merchant verifies the signature
4 Server CH is/not and sends an Authorization
enrolled Request with selected
Authentication
Issuer prompts for password (and chip card History authentication data (ECI and
insertion), validates password (and Server CAVV) to the Acquirer
cryptogram), calculates CAVV, digitally
signs response to Merchant, sends copy to
Authentication History Server
ISSUER
Visa Acquirer
Net Payment
Processor
8
Acquirer formats
Issuer verifies CAVV (or 7 6 message with ECI
interrogates VisaNet and CAVV
codes), authorizes the VisaNet verifies CAVV, forwards to Issuer
transaction, sends
response to the Acquirer
 3. SPA Applet requests
SPA (1)
authentication information
from the user 1. SPA Applet detects SPA-enabled
merchant page
Customer Merchant
SPA Applet Acquirer Plug-in
2. SPA Applet reads information from
merchant’s websites

4. SPA Applet sends

authentication and
transaction information
to issuer’s SPA Server

5. Issuer SPA Server

sends authentication
token back to SPA
Applet

SPA Payment
Server Banknet Gateway
Issuer Acquirer
SOURCE: KMIS
 SPA (2)
6. SPA Applet embeds the authentication token in the
merchant’s site and optionally fills the online form
Customer Merchant
SPA Applet 11. Merchant confirms transaction and Acquirer Plug-in
issues receipt to customer

7. Merchant sends
authorization request
and authentication
token to acquirer

10. Acquirer sends

transaction response
back to merchant
8. Acquirer sends authorization request and
authentication token to issuer via Banknet
SPA Payment
Server Banknet Gateway
Issuer 9. Issuer sends authorization response to acquirer
Acquirer
 Using Dual Signatures
• Alice wants to send Message 1 to Bob and Message 2 to Carol
• Message 1 is order info; Message 2 is payment info
• Alice encrypts Message 1 with Bob’s public key; Message 2 with
Carol’s public key
• Both Bob and Carol must be convinced that the messages are
linked and unaltered
• Alice sends { PKBOB(Message 1), PKCAROL (Message 2), DualSig}
to both Bob and Carol
• Bob hashes PKBOB(Message 1), concatenates with PKCAROL
(Message 2), and hashes again to give the dual hash
• Bob decrypts the dual signature with Alice’s public key
• If the new hash and the decrypted signature match, all is OK
 Dual Signatures on Plaintext
• Alice wants to send Message 1 to Bob and Message 2 to Carol in
plaintext
• Bob can’t see Message 2; Carol can’t see Message 1
• Both Bob and Carol must be convinced that the messages are
linked and unaltered
• Alice sends Bob { Message 1, Digest 2, Dual Signature}
• Bob hashes Message 1, concatenates with Digest2 and hashes
• Bob decrypts the dual signature with Alice’s public key
• If the new hash and the decrypted signature match, all is OK
• Now Bob can send Carol Digest 2 and ask if she got the
message corresponding to it!
• (Carol got { Message 2, Digest 1, Dual Signature} )
 SET in Practice

SOURCE: http://www.software.ibm.com/commerce/payment/specsheetetill.html
 MasterCard Banknet
• Closed TCP/IP network
• Payment authorization in 130 milliseconds avg.
• Capacity: 2.5M transactions/hour, 700/second
• Busiest day: 36M authorizations, 40M debits
• 210 countries (more than SWIFT!)
• 25,000 issuing banks
• 650 service delivery points
– 13 global hubs
– 32 country hubs

SOURCE: MASTERCARD
END.