chris olston, cs294-7, spring 19991 atomicity in electronic commerce j. d. tygar -- ucb presented by...

Chris Olston, cs294-7, Spring 1999

1

Atomicity in Electronic Commerce

J. D. Tygar -- UCB

presented by Chris Olston


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


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


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


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.


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


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


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


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)


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


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 :)


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 :)


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


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


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


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


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>


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


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


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


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


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 19991 atomicity in electronic commerce j. d. tygar -- ucb presented by...

Documents

chris olston slide

atomicity customer

paper slide

certified delivery slide

wrong goods

previous slide

records goods xfered

delivery person slide