Check out the new USENIX Web site. next up previous
Next: Strongboxes for Electronic Commerce Up: Session V: Atomic Transactions Previous: Session V: Atomic Transactions

Anonymous Atomic Transactions

Jean Camp, Sandia National Laboratory; Michael Harkavy and J. D. Tygar, Carnegie Mellon University; Bennet Yee, University of California, San Diego

Jean Camp began by pointing out that money sent over open networks is subject both to attacks and cheating by untrusted parties, and to network failures. She then defined several terms: money atomicity, which means that money is conserved in the system; goods atomicity, which means money atomicity plus guaranteed delivery of goods; and certified delivery, which means goods atomicity plus proof of precisely what goods were delivered. This discussion refers strictly to information goods, not to physical goods.

Jean went on to define anonymity as meaning that the identity of the consumer is not revealed, and to note that previous anonymous transaction protocols were not atomic: after the purchase both the customer and the merchant have the token and may be racing to cash it.

Jean stated that she would offer a protocol which was both anonymous and atomic, and give a proof by example. Her assumptions were: secure communication channels that don't reveal the consumer's identity; blinded signatures (Chaum) that enable signing of unseen data so that signature verification can't be linked to the initial signature; and a transaction log of messages from the customer, the bank, the merchant, and the log itself, which is an agent recording to publicly readable, reliable storage.

This is a two-part protocol. First there is a withdrawal or exchange of the token via a blinded request to the bank, which the bank signs; then the customer unblinds the request to get the token. The token is itself a public key, which the customer can prove has value, like a single-use certificate. Second, there is a purchase. At the customer's request, the merchant sends to the customer the goods in encrypted form along with a contract with the price and description of the goods. The customer sends an approval to the bank, the bank sends an approval to the merchant, and the merchant sends the encryption key to the log, which makes it publicly available.

The log is the transaction coordinator, and issues either a global commitment of the transaction or a global abort. We assume that the merchant trusts the transaction log not to release the key without issuing a commitment, and that the consumer trusts the transaction log to publish the key in a timely manner. The bank and the transaction log could potentially be combined - separation helps to minimize how much each party needs to be trusted. The protocol is anonymous because each token is a public key that is not linked to the customer's identity.

Jean then discussed some possible variations. Reusable consumer keys would be more efficient, but less anonymous as they would allow the bank to link a series of transactions. Cryptographic timestamps in the log would help to reduce the risk of delay and minimize the damage if the log were compromised. Encrypting the log would get rid of observers. Two-sided certified delivery would allow the merchant to take the burden of proof.

Questions for future development include how to make the protocol more efficient and more scalable, and how to reason formally about anonymity. Policy issues relevant to this work include legal requirements on transaction sizes and aggregate data collection, and key escrow.

Dan Geer asked Jean to elaborate on how she sees the role of anonymity, and whether it is possible to achieve privacy through other means. Jean answered that it is possible to get privacy through policy mechanisms to some extent, but that this is subject to violation since you have to trust others to maintain your privacy. Jean was asked if any prototype of this system has been built, and replied that none had, nor had any analysis been done, and that public key systems are generally expensive. Doug Tygar then added that storage requirements would be quite large as they are for all digital cash systems which must keep log and bank records.


next up previous
Next: Strongboxes for Electronic Commerce Up: Session V: Atomic Transactions Previous: Session V: Atomic Transactions
Alma Whitten
1998-07-21