1 / 53

Electronic Commerce: Payment Protocols and Fair Exchange

Electronic Commerce: Payment Protocols and Fair Exchange. Markus Jakobsson, RSA Labs www.markus-jakobsson.com. DIMACS Tutorial on Applied Cryptography and Network Security. Contents of this talk:. Principles of some signature-based payment schemes.

everettt
Download Presentation

Electronic Commerce: Payment Protocols and Fair Exchange

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. Electronic Commerce: Payment Protocols and Fair Exchange Markus Jakobsson, RSA Labs www.markus-jakobsson.com DIMACS Tutorial on Applied Cryptography and Network Security

  2. Contents of this talk: • Principles of some signature-based payment schemes. • What is a fair exchange, and how can we obtain it? • Some micro-payment schemes • A micro-payment scheme for routing

  3. USER SHOP BANK The typical credit-card transaction: number sum number sum crimes possible no anonymity online bottleneck ok/ not ok

  4. Contract/ public key Contract/ public key ISSUER “Plain” signatures: I no anonymity Consumer

  5. USER SHOP BANK The typical E-money transaction: withdrawal deposit (possibly off-line) spending can avoid crimes anonymity possible off-line possible

  6. c/ pk I I c/ pk ISSUER Blind signatures (Chaum)

  7. Blind RSA Signatures • Normal signature on message m: s=m1/3 modulo N • Blind signature generation: Receiver: Signer: m’=m r3 mod N s’=m’1/3 mod N s=s’ / r mod N

  8. m SHOP s BANK ANONYMOUS E-Money: m (m,s) s ok/ not ok We want this off-line (m,s)

  9. Avoiding double-spending: Eve Dave Cindy Bob Alice Bank Examples of this technique: Brands, Ferguson

  10. $ $ $ $ $ $ $ $ $ $ $ $ $ Forgery SHOP SHOP $ Two basic user-attacks that must be avoided: Overspending (These are the minimal standard to prevent)

  11. sooo…. you read Marxist material ? I McCarthy hehe now come with me hehe BAD COP TRACING $ BANK POF INCRIMINATION EMBEZZLEMENT …..And three bank-attacks:

  12. Pay tax? I have no income, sir! $ $ $ $ $ $ Grand Cayman $ $ $ $ $ SHOP TAX EVASION MONEY LAUNDRY Now please make a withdrawal SHOP FRONT $ $ $ GULP! BANK GULP! BLACKMAIL(user robbery) BANK ROBBERY ….And four abuses of privacy:

  13. Description of Offense WE NEED REVOKABILITY OF PRIVACY

  14. Give me your secret key? GULP! What is a bank robbery? Or (more sophisticated) as a multiparty calculation with secret inputs (YAO [FOCS 86]) How do we avoid it? It must be impossible to obtain a blinded signature! We need signatures that are not publicly verifiable! (now the attacker can be given an invalid coin!) YAO

  15. ISSUER Magic Ink Signatures Trace

  16. ISSUER Trace Consumer representative 3. Deposit/report 1. Issuing of credential Merchant Consumer 2. Use of credential access tokens passports, group membership general certification payments, contract signing

  17. BANK with- drawal No. with- drawal No. coin serial No. coin serial No. Bank & OMB.Man What is a coin? Good Withdrawals Good Withdrawals coin serial No. Signing Ability

  18. Fair exchange • Trusted third party • Ripping • Bit-by-bit • Offline trusted third party (optimistic) • FR97, ABSW98

  19. Micropayments Based on work by Micali and Rivest

  20. The need for small payments • “Pay-per-click” purchases on Web: • Streaming music and video • Information services • Mobile commerce ($20G by 2005) • Geographically based info services • Gaming • Small “real world” purchases • Infrastructure accounting: • Paying for bandwidth

  21. Digital cash not for micropayments • No aggregation: every coin spent is returned to the PSP/bank. • This costs e.g. 25 cents per transaction just to process – very inefficient!

  22. What is a “micropayment”? • A payment small enough that processing it is relatively costly. Note: processing one credit-card payment costs about 25¢ • A payment in the range 0.1¢ to $10. • Processing cost is the key issue for micropayment schemes. (There are of course other issues common to all payment schemes…)

  23. Level of Aggregation • To reduce processing costs, many small micropayments should be aggregated into fewer macropayments. • Possible levels of aggregation: • No aggregation: PSP sees every payment • Session-level aggregation: aggregate all payments in one user/merchant session • Global aggregation: Payments can be aggregated across users and merchants

  24. PayWord (Rivest & Shamir) • Emphasis on reducing public-key operations by using hash-chains instead (created starting from xn): x0 x1 x2 x3 … xn • User digitally signs “root” x0 of hash chain and releases xi for i -th payment to merchant • One hash-chain per user-merchant session: merchants returns last xi and signed root x0 -- receives i cents

  25. Electronic Lottery Tickets as MicropaymentsRivest ’97, also see Wheeler ’96, Lipton and Ostrovsky ’98 • Merchant gives user hash value y = h(x) • User writes Merchant check: “This check is worth $10 if three low-order digits of h-1(y) are 756.” (Signed by user, with certificate from PSP.) • Merchant “wins” $10 with probability 1/1000. Expected value ofpayment is 1 cent. • Bank sees only 1 out of every 1000 payments.

  26. The “Peppercorn” Proposal Micali & Rivest • Under English law, one peppercorn is the smallest amount that can be paid in consideration for value received. • Peppercorn scheme is an improvement of basic lottery ticket scheme, making it: • Non-interactive • Fair to user: user never “overcharged”

  27. 999/1000 1/1000 $10 VOID Peppercorn Scheme PEPPERCORN FAIRNESS: • User, merchant and bank cannot cheat • Fair to user always (never overcharged) • Fair to merchant and bank on average Enable 1000 Transactions at Cost of 1

  28. User Fairness: No “Overcharging” • With basic scheme, unlucky user might have to pay $20 for his first 2 cents of probabilistic payments! • We say payment schemeis user-fair if user neverneed pay more than he would if all payments werenon-probabilistic checksfor exactly expected value (e.g. 1 cent)

  29. Achieving User-Fairness • Assume for the moment that all payments are for exactly one cent. • Require user to sequence number his payments: 1, 2, … • When merchant turns in winning payment with sequence number N PSP charges user N – (last N seen) cents User charged three cents for

  30. User-Fairness (continued) • Note that merchant is still paid $10 for each winning payment, while user is charged by difference between sequence numbers seen by PSP. • Users severely penalized for using duplicate sequence numbers. If user’s payments win too often, he is converted to basic probabilistic scheme. PSP can manage risk.

  31. Peppercorn Benefits • Processing costs reduced by 100x-1000x • Reduced bandwidth, storage, and computation • Increased scalability and throughput • Bank off-line • Remote locations, vending, parking meters • Non-interactive payments • Payments via e-mail/SMS from buyer to seller • User-Privacy (a lot of it, for free)

  32. A Micro-Payment Scheme EncouragingCollaboration in Multi-Hop Cellular Networks Markus Jakobsson1 Jean- Pierre Hubaux2 Levente Buttyán2

  33. Multi-hop cellular • Advantages • reduced energy consumption • reduced interference • number of base stations can be reduced coverage of the network can be increased • ad hoc networking

  34. Model Asymmetric multi-hop cellular: • multi-hop up-stream • single-hop down-stream Energy consumption of the mobiles is still reduced

  35. Problem statement While all mobile nodes stand to benefit from such a scheme, a cheater could benefit even more by being served without serving others (selfish behavior)

  36. Approach Introduce benefit for collaboration … without strong security assumptions … and without large overhead

  37. Idea Attach micropayments to packets … allowing collaborators to get paid … while avoiding and detecting various attacks

  38. A New Twist Traditional approach for (micro) payments: “one transaction – one payee – one payment” New approach: “one transaction (packet) – several payees – several payments” Note: • the payer (sender) does not always know who the payees are (i.e., who is on the route) • … he may not even know the number of payees (length of the route)

  39. Contributions • Technique to determine how to route packets (may be based on size of reward, remaining battery life, how busy a node is, etc.) • Technique to allow base stations to verify payments, drop packets with invalid payments (nodes won’t have to do this – makes their life easier) • Technique for aggregation of payments (to minimize logs and requirements on storage and communication) • Auditing process to detect misbehavior

  40. Related work (1) • (Buchegger, Le Boudec) Reputation-based collaboration vulnerability due to “flattering collusions” • (Zhong et al) Sprite: Reputation w/o tamperproofness not lightweight, only works for “dense” networks • (Nisan, Ronen) General treatment of collaboration • (Buttyan, Hubaux) Tamperproofness & micro-payments strong assumptions, vulnerable to collusions • (Marti et al.) Watchdog and path rater does not discourage misbehavior

  41. Related work (2) • (Rivest) Aggregation using probabilistic payments not applied to routing/collaboration “This is a $256 payment iff the preimage to your hash value y ends in 00000000” • (Micali, Rivest) Prob. payments with deterministic debits bank deals with variance, not for routing/collaboration • payee obtains lottery tickets • payer pays per serial number (used consecutively) • bank watches for deposits with duplicate serial numbers (this means cheating!)

  42. check if the token is a winning ticket if so, file claim check token if correct, deliver packet attach payment token accounting and auditing information selfish debit/credit accounts identify irregularities submit reward claims honest The solution in a nutshell

  43. Potential attacks • Selective acceptance (“winning tickets only, please”) • Packet dropping (“I’ll take this, oops”) • Ticket sniffing (“any winning tickets drifting by?”) • Crediting a friend (“you will win this one!”) • Greedy ticket collection (“let’s all pool tickets”) • Tampering with claims (“I’ll zap your reward claim”) • Reward level tampering (“promise big, keep small”)

  44. Protocol (1) Shared user key Ku Shared user key Ku Setup (Ui, di, Li) user distance level id to BS required Connectivity graph

  45. Protocol (2) p, L, Uo , m packet level originator’s MACKu(p, L) id Packet origination forward request wait for ack send Did I win? Packet transmission to next user Ui with sufficient level Li (<L)

  46. Protocol (3) Network processing MAC correct? (otherwise drop) Send towards destination Collect auditing information (send in batches)

  47. Reward claim Well… did I win? • U forwarded (L, p, Uo, m) • checks if f (m, Ku) = 1 • if so, stores claim (U1, U2, m, L) • all such claims sent to base station when “convenient” received from sent to

More Related