Digital Cash
This project is based on the protocol number 4, described in [SCHN96],
p. 142. Please pick up this handout. Basically this protocol
implements an electronic cash system, in which the digital cash cannot
be copied or reused more than once and the privacy of the customer's
identity is guaranteed.
Implementation:
The system allows money transaction between three parties: Customer,
Merchant and Bank. The electronic cash (ecash) used during these
transactions is a document which contains:
- the amount of the transaction involved
- a uniqueness string number
- identity strings which contain the identity of the customer (this
information remains secret unless the customer tries to use the ecash
illicitly more than once);
- bank's signature (before the customer can use the ecash) The
services provided for each party is described as follows:
Customer
- generates N orders for each money order the customer wants to
make and assigns a different random uniqueness string number for each of
the N ecash money orders
- implements the secret splitting and bit commitment protocols used
to generate the identity strings that describe the customer's name,
address and any other piece of identifying information that the bank
wants to see.
- implements a blind signature protocol for all N money orders
- automatically complies to reveal the half of the identity string
chosen by the merchant
Merchant
- verification of the legitimacy of the bank's signature
- random generator of the selector string, which determines the
half of the identity string the customer is required to reveal
Bank
- random choice of 1 out of N money orders sent by the customer to
remain unopened
- an algorithm that certifies that all the N-1 money orders have
been filled with valid information
- a procedure to certify that the orders received from merchants
have not been used previously and storage of the uniqueness string and
identity strings of the orders in a database file
- Appropriate measures against reuse of the ecash
The following excerpt from [SCHN96], p. 142 describes the anonymous
digital cash protocol. It is recommended that you read the chapter
for more discussion and background.
Protocol #4
- Alice prepares n
anonymous money orders for a given amount. Each of the money
orders contains a different random uniqueness string X, one long enough
to make the chance of two being identical negligible. On each
money order, there are also n
pairs of identity bit strings, I1, I2, ... In.
(yes, that's n different pairs
on each check.) Each of
these pairs is generated as follows: Alice creates a string that gives
her name, address, and any other piece of identifying information that
the bank wants to see. Then, she splits it into two pieces using
the secret splitting protocol (see Section 3.6). Then, she commits
to each piece using a bit commitment protocol
- Alice blinds all n money
order, using a blind signature protocol. She gives them all to the
bank.
- The bank asks Alice to unblind n-1
of the money orders at random and confirms that they are all well
formed. The bank checks the amount, the uniqueness string, and
asks Alice to reveal all of the identity strings.
- If the bank is satisfied that Alice did not make any attempts to
cheat, it signs the one remaining blinded money order. The bank
hands the blinded money order back to Alice and deducts the amount from
her account.
- Alice unblinds the money order and spends it with a merchant.
- The merchant verifies the bank's signature to make sure the money
order is legitimate.
- The merchant asks Alice to randomly reveal either the left half
or the right half of each identity string on the money order. In
effect, the merchant gives Alice a random n-bit selector string
b1, b2, ... bn. Alice opens
either the left half or right half of Ii, depending on whether bi
is a 0 or a 1.
- Alice complies.
- The merchant takes the money order to the bank.
- The bank verifies its signature and checks its database to make
sure a money order with the same uniquenes string has not been
previously deposited. If it hasn't, the bank credits the amount to
the merchant's account. The bank records the uniqueness string and
all of the identity information in a database.
- If the uniqueness string is in the database, the bank refuses to
accept the money order. Then, it compares the identity string on
the money order with the one stored in the database. If it is the
same, the bank knows that the merchant copied the money order. If
it is different, the bank knows that the person who bought the money
order copied it. Since the second merchant who accepted the money
order handed Alice a different selector string than did the first
merchant, the bank finds a bit position where one merchant had Alice
open the left half and the other merchant had Alice open the right hald.
The bank XORs the two halves together to reveal Alice's identity.
The system should be implemented using your choice of C, C++, or Java.
(and maybe Microsoft .NET, we're thinking about it) It will
consist of 3 independant programs that communicate over the network
using an XML based protocol. One of these programs simulates the
bank. One program simulates a merchant. The remaining
program simulates the user, and interfaces with the user either as a
traditional GUI program, or as a web server serving HTML pages.
Of course, all communications should be secured using SSL.
Resources
Please visit the resources page
References
[SCHN96] Applied Cryptography,
Bruce Schneier, John Wiley and Sons, New-York, 1996.
An interesting article about the use of digital cash in France: http://www.cnn.com/2003/TECH/ptech/02/08/cash.smart.ap/index.html