1 / 43

E-Payment

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

cleta
Download Presentation

E-Payment

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related