Atomic TransactionsCS523 - Spring 2006 - Brian

Schmidt

Different Domains

• On single CPU• Multiprocessor Applications• Database Systems• Electronic Commerce

Types of Transactions

• Money for Electronic Goods• Money for non-Electronic Goods• Money for Transferred goods• Money changing Accounts• + auctions• + time contraints

[Subr]

Types of Money

• Account Transfer• Credit Card• PayPal• Token Money

Beyond Databases

• Not just responsibility to carry out action robust against failures

• Must include non-repudiation through verifiable transaction atomicity in presence of malicious failures

• Repudiation is the refusal to acknowledge or pay a debt

[Tang]

Required and Desired Properties

• Required– Security– Atomicity

• Desired– Privacy– Anonymity– Low Overhead

[Subr]

Threats

• Merchant not delivering product• Merchant over or double charging• Customer denying receipt of

product• Customer not fulfilling payment• 3rd party replay of transaction• Privacy violation of customer by

tracking purchases

Specifications : VMT

• Verifiable Message Transmision– If the receiver receives the message

m, it can not deny the receipt of m, or the content of m

– If the sender transmits a message m to the receiver and the receiver receives it, the sender cannot deny the sending of m or the content of m.

[Tang]

Specifications : AC

• Atomic Commitment– All non-faulty participants that decide reach

the same decision.– If any participant decides commit, then all

participants have voted YES.– If all participants vote YES and no failure

occurs, then all participants decide Commit.– Each participant decides at most once (that

is, a decision is irreversible). [Tang]

Specifications : VAC

• Verifiable atomic commitment– The interactions (communications) and the

contents of the interactions among all participants are verifiable (by a third party) if necessary.

– If a participant receives a message with which some monetary value is associated, the transaction in which the participant is involved will be committed eventually (even though the participant may abort the transaction unilaterally).

[Tang]

Example Protocol

• Based on Public-Private Key encryption

• Claims to meet all required and desired properties(security, atomicity, privacy, anonymity, low overhead)

• From [Subr]

Notations

• A stands for the customer, Alice, with public key a and private key 1/a.

• B stands for the merchant, Bob, with public key b and private key 1/b.

• T stands for the third party, Tom, with public key t and private key 1/t.

• E and e are encryption keys with corresponding decryption keys 1/E and 1/e.

[Subr]

Notations cont…

• X => Y [message content]1/x stands for X sends “message content” to Y signed with X’s private key.

• X => Y [message content]y/x stands for X sends “message content” to Y signed with X’s private key and secured with Y’s public key.

[Subr]

a Protocol

1. B => everybody [product description, price]1/b

2. A => B [[product description, price]1/b, a, [price]1/a, paymente]b

3. B => A [[paymente]1/a, b, [productE]1/b]a

4. A => B [[productE]1/b, a, [1/e]1/a]b

5. B => A [[1/e]1/a, b, [1/E]1/b]a[Subr]

Discussion

• Credit cards, customer authentication, third party support…

More on Privacy

• IP Addresses• Email• Reuse of public keys

[Camp]

References• [Tang] L. Tang, “Verifiable Transaction Atomicity for

Electronic Payment Protocols,” Proceeding of the 16th ICDCS – IEEE ’96, pp. 261-269.

• [Subr] S. Subramanian and M. Singhal, “Protocols for Secure, Atomic Transaction Execution in Electronic Commerce,” Dept. of Computer and Information Science, Ohio State University, 1997.

• [Camp] L. Jean Camp, “An Atomicity-Generating Protocol for Anonymous Currencies,” IEEE Transactions on Software Engineering, Vol. 27 No. 3, March 2001.