1. Chris Olston, cs294-7, Spring 19991 Atomicity in Electronic Commerce J. D. Tygar -- UCB presented by Chris Olston

2. Chris Olston, cs294-7, Spring 19992 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

3. Chris Olston, cs294-7, Spring 19993 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

4. Chris Olston, cs294-7, Spring 19994 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

5. Chris Olston, cs294-7, Spring 19995 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.

6. Chris Olston, cs294-7, Spring 19996 3 Levels of atomicity in e- commerce Money atomicity –Transfer of funds is atomic Example on previous slide cannot happen Goods atomicity – is atomic Certified delivery atomicity –Can prove exactly what goods were delivered money a.  goods a.  certified delivery

7. Chris Olston, cs294-7, Spring 19997 Goods atomicity Superset of money atomicity 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

8. Chris Olston, cs294-7, Spring 19998 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

9. Chris Olston, cs294-7, Spring 19999 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)

10. Chris Olston, cs294-7, Spring 199910 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

11. Chris Olston, cs294-7, Spring 199911 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 :)

12. Chris Olston, cs294-7, Spring 199912 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 :)

13. Chris Olston, cs294-7, Spring 199913 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

14. Chris Olston, cs294-7, Spring 199914 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

15. Chris Olston, cs294-7, Spring 199915 Summary of non-atomic e-commerce protocols

16. Chris Olston, cs294-7, Spring 199916 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

17. Chris Olston, cs294-7, Spring 199917 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

18. Chris Olston, cs294-7, Spring 199918 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

19. Chris Olston, cs294-7, Spring 199919 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

20. Chris Olston, cs294-7, Spring 199920 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

21. Chris Olston, cs294-7, Spring 199921 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

22. Chris Olston, cs294-7, Spring 199922 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?