Atomicity in Electronic Commerce

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 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? Chris Olston, cs294-7, Spring 1999