electronic commerce: payment protocols and fair exchange markus jakobsson, rsa labs dimacs tutorial...
Post on 22-Dec-2015
214 views
TRANSCRIPT
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:
USER
SHOP
BANK
numbersum
ok/not ok
numbersum
crimes possible
no anonymity
online bottleneck
The typical E-money transaction:
SHOP
BANK
can avoid crimes
anonymity possible
off-line possible
USER
withdrawal
spending
deposit(possiblyoff-line)
Blind signatures (Chaum)
ISSUER
Ic/pk
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
Bank
Eve
Dave
Cindy
Bob
Alice
Examples of this technique: Brands, Ferguson
Avoiding double-spending:
Two basic user-attacks that must be avoided:
$ $$
$$$
$$
$$
$ $
$
Forgery
$SHOP
SHOP
Overspending
(These are the minimal standard to prevent)
…..And three bank-attacks:
I McCarthy
TRACING
sooo…. you readMarxist material ?
BAD COP
INCRIMINATIONBANK
$
POF
EMBEZZLEMENT
….And four abuses of privacy:
$$
$
$
$
$
$
$
Pay tax? I have no income, sir!
TAX EVASIONMONEY LAUNDRY
$
$
$
SHOPFRONT
GrandCayman
BANK
SHOP
BLACKMAIL(user robbery)
Now please make a withdrawal
GULP!
BANK ROBBERY
$ $ $
GULP!
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 arenot publicly verifiable!(now the attacker can be given an invalid coin!)
YAO
Magic Ink SignaturesISSUER
Trace
ISSUER
MerchantConsumer
Trace
1. Issuing of credential
2. Use of credential
3. Deposit/report
Consumerrepresentative
access tokenspassports, group membershipgeneral certificationpayments, contract signing
What is a coin?
BANK
Bank &OMB.Man
coinserialNo.
coinserialNo.
Signing Ability
Good Withdrawals Good Withdrawals
coinserialNo.
with-drawalNo.
coinserialNo.
with-drawalNo.
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 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
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.
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
Peppercorn Scheme
999/1000
VOIDPEPPERCORN 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
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)
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 EncouragingCollaboration 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
attach payment token
check if the token is a winning ticket
if so, file claim
check token
if correct, deliver packet
submit reward claims
accountingandauditinginformation
debit/credit accounts
identifyirregularitieshonest
selfish
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
Shared
user key Ku
Protocol (2)Packet origination
Packet transmission
p, L, Uo , packet
level originator’s MACKu(p, L)
id
forward requestwait for acksendDid 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
• U forwarded (L, p, Uo, )• checks if f (, Ku) = 1• if so, stores claim (U1, U2, , L)
• all such claims sent to base station when “convenient”
Well…did I win?
receivedfrom
sentto
What is f ?
“Safe” approach: a one-way function
“Quick & Dirty” approach: check Hamming distance between 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!