E-Payment
ECT 582
Robin Burke
Outline
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 costcost to adopt the technology
Transaction costcost per transaction
Floataccrual of accumulated interest
Riskpossible financial loss to buyer / seller
Convenience
Complexity number of steps to complete transaction
Two-way peer to peer payment possible
Off-line no need for connection to third-party during transaction
Account does one or both parties need a special account established
in advance? Respendability
no intermediate steps between receiving and spending Portable
not location-dependent
Interoperability
Exchangeable one type of currency for another
Transferable can be transferred from individual to
individual Divisible
can be subdivided into smaller units Hardware independent
no special hardware required Monetary value
built-in value
Overhead
Scalabilitytransactions / users
Delayhow long does the transaction take?
Hardware / software requirements
Examples
Cash Check Credit card Online credit card Mondex PayPal Digital wallet
Framework
Playerswho is involved
Processeswhat is the protocol
Propertiescostsrisksetc
Cash
Playersbuyer / seller (Bob & Susie)
Processsecure documentfixed amountphysical exchange
Cash properties
anonymity divisibility 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 Bob and Susie
Traceable Non-anonymous Medium cost
10-20¢ Risk to seller if verification not in place Non-transferable (in theory)
biometric authentication
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 Bob presents card or Bob presents card number plus other information
Authorization Susie contacts SK with card info SK contacts T T contacts BC BC can accept, deny, etc.
Capture Transaction is committed
• goods accepted Authorization steps happen again with capture flag card balance debited
Settlement 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. NSP
designed to thwart simple theftoff-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 key used to authenticate as "real" Mondex
device key used to encrypt memory contents
Similar to private key token for PKI BUT 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 detectsame id deposited twicecan't distinguish
Conditional anonymity
Bob encrypts self-identifying information in the coin bank can verify just like $ amount
When spending 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 + virtualitymany opportunities for crimegovernments hate it
DigiCashfounder Chaumwent bankruptsome patents will expire soon
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 Respendable On-line only Viral
recipient must get an account to get paid
Traceable, non-anonymous
Digital wallet
The cure-all that wasn't eWallet
out of business Java Wallet
discontinued MS Passport
no longer includes credit card info W3C digital wallet initiative
discontinued
Why?
information not portablesingle machine
information too portablethird 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