E-Payment

1. E-Payment ECT 582 Robin Burke

2. Outline • Schedule changes • Characteristics • Select protocols

3. Characteristics of payment systems • Security / Privacy • Convenience • Cost • Overhead • Interoperability

4. 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?

5. Cost • Fixed cost • cost to adopt the technology • Transaction cost • cost per transaction • Float • accrual of accumulated interest • Risk • possible financial loss to buyer / seller

6. 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

7. 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

8. Overhead • Scalability • transactions / users • Delay • how long does the transaction take? • Hardware / software requirements

9. Examples • Cash • Check • Credit card • Online credit card • Mondex • PayPal • Digital wallet

10. Framework • Players • who is involved • Processes • what is the protocol • Properties • costs • risks • etc

11. Cash • Players • buyer / seller (Bob & Susie) • Process • secure document • fixed amount • physical exchange

12. Cash properties • anonymity • exchangable • low cost • repudiable, without receipt step • low tech • monetary • untraceable

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. SET cont'd

23. 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

24. 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

25. 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

26. 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

27. 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"

28. 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

29. 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

30. 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

31. Characteristics • Anonymous • Two-way • Non-traceable • Respendable • Forgery • cryptographic problem

32. 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

33. 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

34. 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

35. 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

36. 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

37. Double spending

38. eCash viability • Untraceability + anonymity + virtuality • many opportunities for crime • governments hate it • DigiCash • founder Chaum • went bankrupt • some patents will expire soon

39. 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

40. Why? • information not portable • single machine • information too portable • third party • insufficient trust in client software

41. 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

42. Homework #5 • Protocol design • Tax uploading problem

43. Next week • Internet security • Firewalls