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