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
The typical credit-card transaction
number sum
number sum
crimes possible no anonymity online bottleneck
ok/ not ok
4
Plain signatures
I
no anonymity
Consumer
5
The typical E-money transaction
withdrawal
deposit (possibly off-line)
spending
can avoid crimes anonymity possible off-line
possible
6
Blind signatures (Chaum)
7
Blind RSA Signatures

• Normal signature on message m
• sm1/3 modulo N
• Blind signature generation
• Receiver Signer
• mm r3 mod N
• sm1/3 mod N
• ss / r mod N

8
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
Two basic user-attacks that must be avoided
Overspending
(These are the minimal standard to prevent)
11
..And three bank-attacks
12
.And four abuses of privacy
13
WE NEED
REVOKABILITY OF PRIVACY
14
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
Magic Ink Signatures
Trace
16
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
What is a coin?
Good Withdrawals
Good Withdrawals
coin serial No.
Signing Ability
18
(No Transcript)
19
Fair exchange

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

20
(No Transcript)
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
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 users 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)

34
(No Transcript)
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

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 wont 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
46
Potential attacks

• Selective acceptance (winning tickets only,
  please)
• Packet dropping (Ill take this, oops)
• Ticket sniffing (any winning tickets drifting
  by?)
• Crediting a friend (you will win this one!)
• Greedy ticket collection (lets all pool
  tickets)
• Tampering with claims (Ill 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 originators
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 (ltL)
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
51
What is f ?

• Safe approach a one-way function
• Quick Dirty approach check Hamming distance
  between m and Ku
• (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 others
  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!