Electronic Commerce: Payment Protocols and Fair Exchange

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

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

21. Micropayments Based on work by Micali and Rivest

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

44. 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!)

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

46. 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”)

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

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

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

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