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.
• What is a fair exchange, and how can we
obtain it?
• Some micro-payment schemes
• A micro-payment scheme for routing
The typical credit-card transaction:
number
sum
USER
SHOP
number
sum
crimes possible
no anonymity
online bottleneck
ok/
not ok
BANK
“Plain” signatures:
ISSUER
Contract/
public
key
Consumer
Contract/
public
key
I
no anonymity
The typical E-money transaction:
BANK
withdrawal
USER
spending
can avoid crimes
anonymity possible
off-line possible
deposit
(possibly
off-line)
SHOP
Blind signatures (Chaum)
ISSUER
c/
pk
I
c/
pk I
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
ANONYMOUS E-Money:
m
BANK
(m,s)
s
m
ok/
not ok
s
(m,s)
SHOP
We want
this off-line
Avoiding double-spending:
Eve
Dave
Cindy
Bob
Alice
Bank
Examples of this technique: Brands, Ferguson
Two basic user-attacks that must be
avoided:
$
$
$
Forgery
SHOP
Overspending
SHOP
(These are the minimal standard to prevent)
…..And three bank-attacks:
sooo…. you read
Marxist material ?
I
McCarthy
BAD
COP
TRACING
BANK
POF
INCRIMINATION
EMBEZZLEMENT
….And four abuses of privacy:
Pay tax? I have
no income, sir!
BANK
$
$
SHOP
TAX EVASION
SHOP
FRONT
$
MONEY LAUNDRY
GULP!
BLACKMAIL(user robbery)
BANK ROBBERY
WE NEED
Description
of
Offense
REVOKABILITY OF PRIVACY
What is a bank robbery?
Give me your
secret key?
GULP!
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!
YAO
We need signatures that are
not publicly verifiable!
(now the attacker can be
given an invalid coin!)
Magic Ink Signatures
ISSUER
Trace
Consumer
representative
ISSUER
3. Deposit/report
1. Issuing of
credential
Consumer
2. Use
of credential
access tokens
passports, group membership
general certification
payments, contract signing
Merchant
What is a coin?
BANK
coin
serial
No.
Good Withdrawals
coin
serial
Signing Ability No.
Bank &
OMB.Man
withdrawal
No.
Good Withdrawals
coin
serial
No.
withdrawal
No.
Fair exchange
• Trusted third party
• Ripping
• Bit-by-bit
• Offline trusted third party (optimistic)
– FR97, ABSW98
Micropayments
Based on work by Micali and Rivest
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
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!
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…)
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
PayWord (Rivest & Shamir)
• Emphasis on reducing public-key
operations by using hash-chains
instead (created starting from xn):
x0 x1 x 2 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
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.
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”
Peppercorn Scheme
1/1000
PEPPERCORN FAIRNESS:
• User, merchant and bank cannot cheat
• Fair to user always (never overcharged)
• Fair to merchant and bank on average
$10
999/1000
VOID
Enable 1000 Transactions
at Cost of 1
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)
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
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.
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)
A Micro-Payment Scheme Encouraging
Collaboration in Multi-Hop Cellular Networks
Markus Jakobsson1
Jean- Pierre Hubaux2
Levente Buttyán2
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
Model
Asymmetric multi-hop cellular:
– multi-hop up-stream
– single-hop down-stream
Energy consumption of the mobiles is still
reduced
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)
Approach
Introduce benefit for collaboration
… without strong security assumptions
… and without large overhead
Idea
Attach micropayments to packets
… allowing collaborators to get paid
… while avoiding and detecting various
attacks
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)
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
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
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!)
The solution in a nutshell
check if the
token is a
winning ticket
attach
paymen
t token
check token
if correct,
deliver packet
if so, file claim
accounting
and
auditing
information
selfish
submit
reward
claims
debit/credit accounts
honest
identify
irregularities
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”)
Protocol (1)
Setup
Connectivity graph
Shared
user key Ku
(Ui, di, Li)
user distance level
id
to BS required
Protocol (2)
p, L, Uo , m
Packet origination
packet
level originator’s MACKu(p, L)
id
Packet transmission
forward request
wait for ack
send
Did I win?
to next user Ui with
sufficient level Li (<L)
Protocol (3)
Network processing
MAC correct?
(otherwise drop)
Send towards
destination
Collect auditing
information
(send in batches)
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)
received
from
sent
to
• all such claims sent to base station when
“convenient”
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!)
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!)
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!