A Study in Electronic Commerce: Specification

Cornell University
Computer Science Department
Masters of Engineering Project
Spring 1998

Han-Yang Lo
Sanjeev Topiwala
Joyce Wang
with assistance from Keith Sollers

Under the supervision of: Professor Fred B. Schneider
last modified: Monday, 4/27/98

Introduction
Overview of System
Properties of System
Assumptions
High Level Functional Specification

Setup

Bank

Merchant

Client

Communication Protocols

Client -- Bank

Client -- Merchant

Merchant -- Bank

Features

Bank Server

Merchant Server

Consumer Client

Algorithms

Coins

Programming Languages and Platform Support
Demonstration of System
Notes
References

Introduction

The growth of the Internet has created a whole new marketing and sales paradigm. Merchants can sell practically anything over the Internet at any time. They can reach audiences far beyond their physical locations and can sell at cheaper prices. On the flip side consumers appreciate the convenience and ease of shopping from home. They also like the varied product selection and discount prices. The Internet brings together these advantages for both merchants and consumers. For this reason, the Internet is believed to be where the future of commerce lies.

However, at the current time, consumers must generally use credit cards or checking accounts to make purchases. Although these methods are safe and secure, they do not provide the anonymity and untraceability of cash. As the number of financial transactions over the network grows, consumers will demand a form of secure electronic cash to protect their privacy. This is where V-óa$h steps in. V-óa$h is a secure, anonymous, and untraceable system that allows consumers to make purchases over the Internet. They can be confident that their purchases occur as if they were spending cash at the mall.

Overview of System

The system consists of three main components: a bank server, a merchant server, and a consumer client. Each of these components communicates with each other over secure channels.

Anonymity means that the merchant does not know who the consumer is. Untraceability means that the bank cannot find out where the money came from. To this end, when the client (Alice) wants to withdraw some cash, she generates coins, blinds them and sends them to the bank for authentication. The bank signs these coins with its key, and sends them back to Alice. Then Alice unblinds the coins. Thus Alice withdraws money from her account at the bank, which is authenticated by the bank and usable, but the bank does not know the serial number of the coin.

Now when Alice is shopping online at Bob’s, she can spend the money by sending the coins to Bob, the merchant. Bob, in turn sends the coins to the bank for on-line validation, to confirm that the coins are valid and have not been spent already. After getting the confirmation, Bob completes the transaction with Alice by giving her the merchandise she has purchased.

At the high-level, this scheme is motivated from the implementation described in David Chaum's Scientific American paper (see references), along with several discussions obtained on the internet by other groups attempting to explain/implement an electronic cash system. Many low-level details were obtained by group consensus during the design process.

Properties of System

1. Anonymous and untraceable purchases.
2. Detection of double spending.
3. Authentication of all parties.
4. Audit through logs. (see above "logging functionality")
5. Authorization of transactions through bank.

Assumptions

1. Client and Merchant have accounts at the same bank
2. Average transaction is around $20¹
3. Communication channels are secure using standard encryption algorithms
4. Software binary executable is secure

High Level Functional Specification

Setup

Setup functionality is limited:

• Databases for key management are beyond the scope of this project. The "databases" are implemented as a file, thus are not scaleable. 4/23/98
• The electronic registration for both the merchant and consumer are not implemented as part of the specifications. It would probably be issued as a separate disk to the users. 4/23/98
• There is a testing utility for the bank to generate user and merchant public/private key pairs.

Bank

1. Bank creates a database of client/merchant V-óa$h accounts
2. Bank creates a database for storing serial numbers of spent coins.

Merchant

Assumption 1

1. Merchant requests software
   • Software includes a built-in public/private key pair
   • Keypair is encrypted using a 10 digit PIN: see Bank Setup, #3 (may not be implemented by 4/27/98)
   • PIN is sent to the merchant through the mail (or can be given to the merchant at the bank), like the PIN for ATM cards
2. Merchant installs the software
   • Fills out electronic registration which includes account number and merchant public key (see above "electronic registration")
   • Sends information encrypted using the bank’s public key
3. Bank receives and decrypts the information (see above "electronic registration")
4. Bank sends a set of "challenge" questions (see above "electronic registration")
   • Signed with the bank’s private key
   • Encrypted with the received public key
5. Merchant answers the challenges (see above "electronic registration")
   • Decrypts the message
   • Verifies that the challenges came from the bank
   • Signs the challenge reply with the merchant’s private key
   • Encrypts the signed reply with the bank’s public key
6. Bank verifies merchant responses (see above "electronic registration")
   • Associates the merchant, account number, public key in database
7. Merchant designs web page
   • List of merchandise
   • Displays merchant’s public key
   • High level instructions
   • Demo Merchant page

Client

Assumption 1

1. Client requests software
   • Software includes a built-in public/private key pair
   • Keypair is encrypted using a 10 digit PIN: see Bank Setup, #3 (may not be implemented by 4/27/98)
   • PIN is sent to the client through the mail (or can be given to the client at the bank), like the PIN for ATM cards
2. Client installs the software
   • Fills out electronic registration which includes account number and client public key (see above "electronic registration")
   • Sends information encrypted using the bank’s private key
3. Bank receives and decrypts the information (see above "electronic registration")
4. Bank sends a set of "challenge" questions (see above "electronic registration")
   • Signed with the bank’s private key
   • Encrypted with the received public key
5. Client answers the challenges (see above "electronic registration")
   • Decrypts the message
   • Verifies that the challenges came from the bank
   • Signs the challenge reply with the client’s private key
   • Encrypts the signed reply with the bank’s public key
6. Bank verifies client responses (see above "electronic registration")
   • Associates the client, account number, public key in database

Communication Protocols

Logging functionality has now been integrated and testing. There will be no automatic recovery of data (manual recovery from logs). 4/26/98

All communication protocols have Assumption 3

Client -- Bank

1. Client initiates connection with the bank
   1. Client sends a symmetric key
      • encrypted with the bank’s public key
   2. Bank decrypts the message with its private key
   3. Bank acknowledges the session key by returning the session key
      • signed by the bank’s private key
      • encrypted using the session key
2. Client sends:
   1. account number encrypted with symmetric key and
   2. symmetric key signed with the client private key
   3. this entire packet encrypted with the symmetric key
3. All messages from this point are encrypted using the session key
4. To withdraw money:
   1. Client sends a message requesting withdrawal amount
   2. Bank checks the account
      • If there is enough money in the account
      • If the client hasn’t gone over the maximum daily withdrawal limit
   3. If the request is invalid:
      • the bank sends an ERROR message and disconnects
   4. Otherwise, the request is valid, and the bank sends an acknowledgement
   5. The client software generates and blinds the serial numbers for the appropriate number of coins and sends them to the bank
   6. The bank signs these coins with a specific private key for each coin denomination, and sends the signed, blinded coins back to the client
   7. The bank keeps a copy of these signed blinded coins until it receives a confirmation of receipt from the consumer(not implemented)
   8. The client software receives the coins:
      • unblinds the coins
      • verifies the bank signature (makes sure it returns the original serial number)
      • acknowledges receipt of coins, and sends receipt to bank
   9. Bank debits the client’s account upon receipt of acknowledgment
   10. If the bank does not receive an acknowledgment, bank resends coins upon client request (assumption that this will not happen. Resend implementation partially coded, but not integrated or tested. ... does not exist in the current applications. 4/23/98)
5. To deposit coins:
   1. The client sends the bank the serial numbers of the coins to be deposited
   2. The bank validates the coins:
      • verifies that the coins were signed by the bank
      • checks the coins against the spent coin database to prevent "double spending"
   3. If the coins are valid, the bank credits the client’s account
      • Clients should not have any invalid coins
      • To correct a mistake, clients must contact the bank -- verification using logfiles. (see above "logging functionality")
   4. Bank sends a receipt to the client
   5. Client stores the receipt
6. To get change:
   1. The client deposits the largest denomination coin
   2. The client withdraws an amount equal to that denomination
      • The client software automatically creates the necessary number of serial numbers
      • This withdrawal does not count toward the maximum daily withdrawal