E-Payment
ECT 582
Robin Burke
Outline
Schedule changes
 Characteristics
 Select protocols

Characteristics of payment
systems
Security / Privacy
 Convenience
 Cost
 Overhead
 Interoperability

Security / Privacy





Anonymous
 seller or buyer authentication required?
Non-repudiation
 secure receipt generated?
Security
 against theft?
 against forgery?
 against double-spending?
Privacy
 properties of transaction hidden from involved parties
Fail-safe
 is money lost / created in system failure?
Cost

Fixed cost


Transaction cost


cost per transaction
Float


cost to adopt the technology
accrual of accumulated interest
Risk

possible financial loss to buyer / seller
Convenience

Complexity


Two-way


does one or both parties need a special account established
in advance?
Respendability


no need for connection to third-party during transaction
Account


peer to peer payment possible
Off-line


number of steps to complete transaction
no intermediate steps between receiving and spending
Portable

not location-dependent
Interoperability

Exchangeable


Transferable


can be subdivided into smaller units
Hardware independent


can be transferred from individual to
individual
Divisible


one type of currency for another
no special hardware required
Monetary value

built-in value
Overhead

Scalability


Delay


transactions / users
how long does the transaction take?
Hardware / software requirements
Examples
Cash
 Check
 Credit card
 Online credit card
 Mondex
 PayPal
 Digital wallet

Framework

Players


Processes


who is involved
what is the protocol
Properties
costs
 risks
 etc

Cash

Players


buyer / seller (Bob & Susie)
Process
secure document
 fixed amount
 physical exchange

Cash properties
anonymity
 exchangable
 low cost
 repudiable, without receipt step
 low tech
 monetary
 untraceable

Check

Players




Bob, Susie
Bob's bank BK, Susie's bank SK
Verification service V
Process






physical exchange
secure document with biometric ID
Susie may verify with V before accepting
Susie deposits with SK
SK settles with BK via ACH
Bob's account at BK debited
Check properties

Accounts required




Traceable
Non-anonymous
Medium cost



Bob and Susie
10-20¢
Risk to seller if verification not in place
Non-transferable (in theory)

biometric authentication
PayPal

Players


Bob, Susie, PayPal
Setup

Bob needs a PayPal account
• linked to a bank account or credit card

Process


Bob uses the PayPal application to send
money using Susie's email address
Susie can access her funds by creating a
PayPal account linked to her email address
Characteristics




Low transaction cost
Re-spendable
On-line only
Viral


recipient must get an account to get paid
Traceable, non-anonymous


must be "backed"
by a credit card or bank account
Credit card

Players




Bob, Susie, SK (acquirer)
Card issuer BC
Transaction processor T
Setup



Susie must have card processing account
SK leases POS hardware and network
access
Bob must have credit card
Credit card cont'd

Presentation



Authorization





Bob presents card or
Bob presents card number plus other information
Susie contacts SK with card info
SK contacts T
T contacts BC
BC can accept, deny, etc.
Capture

Transaction is committed
•



Authorization steps happen again with capture flag
card balance debited
Settlement


goods accepted
BC transfers money to SK
Billing


BC sends Bob a monthly bill
Bob pays BC
Credit card cont'd
non-anonymous
 non-transferable
 security weak esp. CNP

designed to thwart simple theft
 off-line = low security

not interoperable
 low cost / low risk for buyer


BC absorbs fraud risk
Online credit card


same as before except
weak buyer authentication






physical card never present
physical signature never present
security reduced from biometric to data
weak seller authentication
major fraud opportunity
SSL protects only passive attacks on IP
traffic
SET


Same players as credit card
Central idea

Susie only needs to know that she will get
paid
• Bob's card number not essential


BC only needs to know enough to validate
the transaction
Segment the transaction
• Part for Susie
• Part for BC
SET cont'd
SET cont'd

Process







Susie and BC have public keys
Bob encrypts and signs an order O to Susie
Bob encrypts and signs payment information
P to BC
P is sent through the acquirer to BC
BC decrypts and validates the transaction
Sends Susie verification and transaction id
Susie presents transaction id to acquirer for
settlement
SET cont'd

Properties





authentication of seller
non-disclosure of credit card #
non-disclosure of order details
enhanced privacy
hardware / software requirement
• electronic wallet

Slow adoption of SET



requires PKI (hierarchical)
requires client-side software
incompatible wallet implementations
Mondex

Players


Bob, Susie
Setup



Bob and Susie both have Mondex smart cards
Bob has downloaded cash tokens to his Mondex card
Bob or Susie has a Mondex terminal
• money exchange device

Process






connect cards to terminal
enter respective PINs
cards authenticate each other's certificates
Susie's card generates signed purchase request
Bob's card acknowledges request and deletes stored
tokens
Susie's card adds tokens
Mondex cont'd

Characteristics

limited maximum storage
• reduces danger of money laundering

some buyer risk
• stolen card is lost cash




respendable
two-way
convenient
dependent on secure hardware
• risky assumption
Secure hardware

Private key stored in device



Similar to private key token for PKI BUT


key used to authenticate as "real" Mondex
device
key used to encrypt memory contents
owner has incentive to break in
How to build



packaging
internal consistency checks
"reset on fault"
Attacks against secure
hardware

Problem


physics of device cannot be hidden
Attackers can

etch new circuitry
• remove deletion step
• alter encryption algorithm

monitor encryption to capture secret key
• power consumption
• timing
• bus probe
Should we worry?

Question


where does "expected payoff" > "investment
to break"
Answer

if Mondex becomes widespread
• chip tampering = printing money

Attackers



Class I – capable outsider
Class II – knowledgeable insider
Class III – determined organization
eCash

Players


Bob, Susie
Setup


Bob and Susie have eCash accounts and
eCash software or smart card
Bob loads secure "coins" to wallet
• a coin = a $$ amount, an id and a digital signature

Process


Bob transfers coins to Susie
Susie deposits in account
Characteristics
Anonymous
 Two-way
 Non-traceable
 Respendable
 Forgery


cryptographic problem
Anonymity


Coin only has bank's identifier
Bank doesn't know



who originally withdrew it
whose hands it has passed through
Problem

double spending
• bank can detect but is Susie or Bob at fault

withdrawal
• when coins are given to Bob, ids could be
recorded
Blind signature


Problem
 sign a document without looking at it
Solution
 multiple message by a factor M*F
 sign M*F creating M*F + S
 factor out F leaving M + S/F
• for certain algorithms S/F is the correct signature for M

Bob can
 create a message = "$1"
 blind it
 have bank sign it
 deduct $1 from Bob's account
 create coin
Cut and choose


Bob could also
 create a message = "$100"
 blind it
 tell the bank it says "$1"
 have bank sign it
Solution
 Bob creates n messages
 Bank examines n-1 at random
 if they all say "$1"
• then the bank signs

we pick n to be as large as necessary for security
• may depend on size of transaction
Double spending
What if Bob spends the same coins
twice?
 What if Susie deposits the same coins
twice?
 Bank can detect

same id deposited twice
 can't distinguish

Conditional anonymity

Bob encrypts self-identifying information in
the coin


When spending



bank can verify just like $ amount
Bob discloses 50% of the key used to
decrypt personal info
if he spends twice, his identity becomes
known to the bank
A similar device can be used to protect
against double deposits
Double spending
eCash viability

Untraceability + anonymity + virtuality
many opportunities for crime
 governments hate it


DigiCash
founder Chaum
 went bankrupt
 some patents will expire soon

Digital wallet


The cure-all that wasn't
eWallet


Java Wallet


discontinued
MS Passport


out of business
no longer includes credit card info
W3C digital wallet initiative

discontinued
Why?

information not portable


information too portable


single machine
third party
insufficient trust in client software
Conclusion


Very few e-payment success stories
Credit cards



approximately 1.8 billion in fraud on-line in
2002
still the dominant mechanism
Reasons

convenience
• already in use

low buyer risk
Homework #5
Protocol design
 Tax uploading problem

Next week
Internet security
 Firewalls
