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. The typical credit-card transaction: USER SHOP BANK number sum ok/ not ok number sum crimes possible no anonymity online bottleneck

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

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

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

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

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

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

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

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

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

13. WE NEED REVOKABILITY OF PRIVACY Description of Offense

14. What is a bank robbery? GULP! Give me your secret key? 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. Magic Ink Signatures ISSUER Trace

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

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

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

21. Micropayments Based on work by Micali and Rivestwork

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)Rivest & Shamir Emphasis on reducing public-key operations by using hash-chains instead (created starting from x n ): x 0 x 1 x 2 x 3 … x n User digitally signs “root” x 0 of hash chain and releases x i for i -th payment to merchantreleases One hash-chain per user-merchant session: merchants returns last x i and signed root x 0 -- receives i cents

27. Electronic Lottery Tickets as Micropayments Rivest ’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 of payment is 1 cent. Bank sees only 1 out of every 1000 payments.

28. The “Peppercorn” Proposal 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” Micali & Rivest

29. Peppercorn Scheme 999/1000 VOID 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 1/1000 $10

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 scheme is user-fair if user never need pay more than he would if all payments were non-probabilistic checks for 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 Encouraging Collaboration in Multi-Hop Cellular Networks Markus Jakobsson 1 Jean- Pierre Hubaux 2 Levente Buttyán 2

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 1.Technique to determine how to route packets (may be based on size of reward, remaining battery life, how busy a node is, etc.) 2.Technique to allow base stations to verify payments, drop packets with invalid payments (nodes won’t have to do this – makes their life easier) 3.Technique for aggregation of payments (to minimize logs and requirements on storage and communication) 4.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. The solution in a nutshell attach paymen t token check if the token is a winning ticket if so, file claim check token if correct, deliver packet submit reward claims accounting and auditing information debit/credit accounts identify irregularities honest selfish

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) Setup Connectivity graph Shared user key K u (U i, d i, L i ) user distance level id to BS required Shared user key K u

48. Protocol (2) Packet origination Packet transmission p, L, U o,  packet level originator’s MAC Ku (p, L) id forward request wait for ack send Did I win? to next user U i with sufficient level L i (<L)

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

50. Reward claim U forwarded (L, p, U o,  ) checks if f ( , K u ) = 1 if so, stores claim (U 1, U 2, , L) all such claims sent to base station when “convenient” Well … did I win? received from sent to

51. What is f ? “Safe” approach: a one-way function “Quick & Dirty” approach: check Hamming distance between  and K u (Note that claims leak key information - be careful!)

52. Accounting and Auditing Debit based on number of packets received by base stations Credit based on number of accepted claims Give credit both to claimant and his neighbors! –stimulates forwarding even for losing tickets –increases granularity Check for “irregularities” (punish offenders!)

53. Some footprints left by cheaters Selective acceptance – higher frequency as claimant then “sending neighbor” (of other’s claims) Packet dropping – higher claimant frequency than sending neighbors for packets the base stations never received Ticket sniffing – higher claimant frequency than sending and receiving neighbor frequencies Crediting a friend – impossible geography? Also: trust needed between cheaters (know the secret key of the other – can “call for free” then!) Greedy ticket collection – impossible geography, too long paths (too many claimants) unrealistic (statistical) transmission rate/time unit for offenders. If one cheater is nailed, consider his frequent neighbors!