chris olston, cs294-7, spring 19991 atomicity in electronic commerce j. d. tygar -- ucb presented by...
TRANSCRIPT
Chris Olston, cs294-7, Spring 1999
1
Atomicity in Electronic Commerce
J. D. Tygar -- UCB
presented by Chris Olston
Chris Olston, cs294-7, Spring 1999
2
Outline of Paper
• Motivation
• Levels of Atomicity
• Releated E-Commerce Issues
• Overview of Non-Atomic Protocols
• Presentation of NetBill by Tygar et al.
• Open Problems to be Solved
Chris Olston, cs294-7, Spring 1999
3
Motivation
• A lot of interest in E-Commerce– “Easy” to match customers with goods/services– Cut costs by eliminating humans from
transaction processing– Both merchants and customers win
• However, current protocols not atomic– None meet all 3 levels of atomicity proposed in
paper
Chris Olston, cs294-7, Spring 1999
4
What is atomicity?
• A transaction is an ordered set of state-changing actions– Eg: customerAcct -= $5, merchantAcct += $5
• Atomicity = “all or nothing”– Either all actions complete (commit) or none occur
(abort)– DBMS’s typically implement atomicity by undoing
all actions (aborting the transaction) if one or more actions cannot complete
Chris Olston, cs294-7, Spring 1999
5
What if no atomicity?
• Transaction might partially complete
• This can cause disastrous inconsistencies– Ex: customerAcct -= $5, merchantAcct += $5
• What if we crash after the first action and don’t undo its effects?
• Customer account debited but merchant never gets the money. The money is effectively lost.
Chris Olston, cs294-7, Spring 1999
6
3 Levels of atomicity in e-commerce
• Money atomicity– Transfer of funds is atomic
• Example on previous slide cannot happen
• Goods atomicity– <pay for goods, receive goods> is atomic
• Certified delivery atomicity– Can prove exactly what goods were delivered
• money a. goods a. certified delivery
Chris Olston, cs294-7, Spring 1999
7
Goods atomicity
• Superset of money atomicity
• <pay for goods, receive goods> is atomic– Either I pay and I get the goods or I don’t pay
and I don’t get the goods
• Real world analogy– Cash-on-delivery
• You get the goods exactly when you pay the delivery person
Chris Olston, cs294-7, Spring 1999
8
Certified delivery atomicity
• Superset of goods atomicity
• Can prove exactly what goods were delivered and where– If you get the wrong goods, can complain to an
authority and prove that you got the wrong stuff
• “Real world” analogy *– Cash-on-delivery where trusted third-party
witnesses transaction and records goods xfered
Chris Olston, cs294-7, Spring 1999
9
Related e-commerce issues
• Paper addresses some other important issues– Anonymity
• Some customers want anonymity, but is it legal?
– Merchant security *• Can’t necessarily trust the merchant
– Eg, merchant can misuse your credit card number
– Want microtransactions (eg, < $1) *• Credit-card transactions have too much overhead• Want to batch transactions (verify $, delay deposit)
Chris Olston, cs294-7, Spring 1999
10
Outline Reminder
• Motivation
• Levels of Atomicity
• Releated E-Commerce Issues
• Overview of Non-Atomic Protocols
• Presentation of NetBill by Tygar et al.
• Open Problems to be Solved
Chris Olston, cs294-7, Spring 1999
11
Anonymous Digital Cash (“Digicash”)
– Tries to provide anonymity at the expense of money-atomicity
• Customer anonymously sends “money token” to merchant and waits for goods. However, customer doesn’t know whether merchant got the token. Should customer delete the token or re-send it?
• But, anonymity can break in communications failure
– Digicash guarantees none of the properties described in the paper except merchant security
• They filed for Chapter 11 :)
Chris Olston, cs294-7, Spring 1999
12
First Virtual
– Your money stays in the bank (no “tokens”)– Uses an email confirmation to guarantee money
atomicity (two-phase commit)• Server sends commit/abort even if after crashing *
– No goods atomicity• Customer can receive goods without paying
– I guess the merchant can’t check whether the customer has sufficient funds before sending it (the paper didn’t specify)
• They are no longer in the e-commerce business :)
Chris Olston, cs294-7, Spring 1999
13
Secure Socket Layer (SSL)
– Sets up secure channel to transfer cc number– Money atomicity since cc transactions are
money-atomic– No merchant security!
• Same as transmitting credit-card over secure phone line. You have to make sure you trust the merchant.
– No microtransactions or anonymity– No goods atomicity
Chris Olston, cs294-7, Spring 1999
14
STT/SEPP/iKP
– A bunch of secure credit-card based protocols– Customer digitally signs for purchase request
plus price– Merchant prepares the same– Bank compares the two. If prices match,
commits transaction.• Guarantees money atomicity via cc transactions
• Guarantees merchant security! (prevents fraud)
– No goods atomicity or microtransactions
Chris Olston, cs294-7, Spring 1999
15
Summary of non-atomic e-commerce protocols
moneyatomicity
goodsatomicity
certifieddelivery
Anonym-ity
merchantsecurity
micro-transacts
Digi-cash
tries X
FirstVirtual
X X
SSL X
STT/SEPP/iKP
X X
Chris Olston, cs294-7, Spring 1999
16
NetBill
• Guarantees 5/6 properties– Certified delivery
• (includes money & goods atomicity)– (Only goods atomicity if the goods are in electronic form)
– Merchant security– Microtransactions– But limited anonymity (via pseudonym server)
• Anonymous to merchant but not to NetBill
Chris Olston, cs294-7, Spring 1999
17
NetBill Protocol
– A) Customer requests price from merchant– B) Merchant makes offer to customer– C) Customer tells merchant “I accept offer”– D) Merchant sends goods to customer
encrypted with key K– E) Customer sends signed Electronic Purchase
Order (EPO) to merchant• EPO contains <price, cryptographic checksum for
encrypted goods, time-out>
Chris Olston, cs294-7, Spring 1999
18
NetBill Protocol, cont.– F) Merchant countersigns EPO, signs K, sends both
to NetBill server– G) NetBill server commits transaction
• Verify signatures & makes sure cust. has enough $
• Make sure customer’s time-out has not expired
• If all OK, transfers funds from customer to merchant
• Stores K and checksum of goods
• Sends signed receipt to merchant
– H) Merchant forwards receipt to customer– I) Customer now has K and can decrypt goods
Chris Olston, cs294-7, Spring 1999
19
NetBill Analysis
• Money atomicity– All transfers done locally by NetBill server
• Goods atomicity– If failure before NetBill commits, no problem– If failure after NetBill commits, customer can
get K from NetBill server later to decrypt goods
• Certified delivery– NetBill has checksum to confirm cust. claims
Chris Olston, cs294-7, Spring 1999
20
NetBill Analysis, cont.
• Merchant security– Customer’s price must match merchant’s price
• Microtransactions *– Since not using credit-card infrastructure, low
overhead per transaction makes microtransactions feasible
• Limited anonymity via pseudonym server– Anonymous to merchant, not to NetBill
Chris Olston, cs294-7, Spring 1999
21
Open Problems
• Is it possible to provide money atomicity without a trusted third-party central server?– Special tamper-proof hardware is one proposal
• Your computer has a “bank coprocessor” that maintains your bank balance
• If you try to meddle with the coprocessor, it erases all data
– If no special HW, can ease central server bottleneck by running NetBill on a D-DBMS
Chris Olston, cs294-7, Spring 1999
22
More Open Problems(the paper lists many more)
• Can you have both atomicity and anonymity– NetBill has strong atomicity but not anonymity
– Digicash has (in theory) the opposite
– Are they mutually exclusive?
• Can some of these properties be decoupled?– Eg, Can you separate atomicity from security?
• What are the minimum number of messages needed for each property?