Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:04
Robert Hettinga (rah@shipwright.com)
Wed, 20 Jan 1999 07:36:05 -0500
I converted his attached .rtf file into ascii and appended it below, as well.
Cheers,
Robert Hettinga
--- begin forwarded text
Reply-To: "Victor Dostov" <vd@mailbox.alkor.ru>
From: "Victor Dostov" <vd@mailbox.alkor.ru>
To: <Undisclosed-Recipient:@ns.alkor.ru;;>
Subject: report on Russian electronic cash system PayCash
Date: Wed, 20 Jan 1999 13:52:01 +0300
Dear colleague
I represent a Russian project for payment system over Internet PayCash.
The system is based on electronic cash technology similar to one underlying
Chaum's eCash but using different, as we hope more efficient, technique for
coin signing and storing. The system is under patent pending. Legally,
it is under registration of Russian Central Bank.
Currently we support Russian demo-version on www.paycash.ru. Our plan is to
release English version in March and simultaneously start a commercial
run.
We discuss our system widely in Russian technological and bank communities
but definitely lack contacts with western analysts. We are interested in
your opinion, suggestions or proposals. You may find attached our report on
the system.
If you find it interesting, please, let me know. I'll keep you informed on
system development.
If the things are out of your interests, just drop me a line.
Best regards
Dr. Victor Dostov
Alkor Holding group of companies
-------------------------------------------------
Current account is
vd@mailbox.alkor.ru
Provider-independent account is
gray_cat@geocities.com
--------------
Internet payment system PayCash
Ildar M. Khamitov
Alkorsoft & Bank Tavrichesky
St.-Petersburg, Russia
Alexander L. Smirnov
Alkorsoft & Steklov Mathematical Institute
St.-Petersburg, Russia
This is a draft of report containing description of a new payment system
PayCash (www.paycash.ru) that was developed by the Russian Company
Alkorsoft in co-operation with the Tavrichesky bank (St.-Petersburg). The
PayCash system is designed to provide prompt and effective anonymous
payment transactions over the Internet ranging from micro- to
business-to-business payments.
Keywords: payment system, electronic cash, privacy, anonymity, trade systems.
Contact: vd@mailbox.alkor.ru
The Internet does not still provide any well-established methods of
payments that could fully satisfy all needs of a rising wave of electronic
commerce. However at the present time most of payments in the Internet are
made by means of credit cards. Credit card payments have a number of
disadvantages, including, for example, a narrow range of amounts of
possible payments, low protection and safety, full absence of payer's
anonymity, relative slowness. Besides the credit cards are not in
widespread use in some countries, e.g. in Russia. These disadvantages may
serve as the grounds for supposing that the Internet users need alternative
payment systems. We have developed our own Internet payment system and
named it PayCash. It would be convenient to describe this system by showing
the chain of arguments that have led us to the concept embodied in the
PayCash system.
It would be natural to begin with stating general requirements to a
promising payment system which could fill the niche in the sphere of
Internet payments not occupied by the card systems and compete with them in
some cases. The promising Internet payment system must provide:
* high protection and safety;
* high anonymity of the parties;
* wide range of amounts down to several cents;
* equality of the sellers and buyers, thus encouraging new sellers;
* high speed of payment transactions stimulating spontaneous buyers (less
than 10 seconds).
We rejected those payment systems in which protection of bank's interests
substantially depends on the "honesty" of client's software and hardware.
Evidently, client's software in such a system must operate on a specialized
tamperproof hardware, e.g. on a special chip card computer. In our opinion,
protection of bank secrets by trusted devices accessible for malicious
examination outside the bank is hardly reliable, especially as compared
with the reliability of modern cryptographic methods. A criminal breaking
into one such device may be disastrous for the whole system. A clear
example of a payment system depending on the "honesty" of clients' software
and hardware is the Mondex card system.
Those payment systems that do not depend on the "honesty" of client's
software and hardware can be divided into two groups. The first group
includes the hardware systems in which the client's software operates on a
specialized computer intended for use only within the framework of the
payment system, e.g. on a chip card computer. The second group includes the
software only systems in which client's software is just one of the
applications the user runs on a general-purpose computer. Evidently, there
is no fundamental difference between these groups of payment systems, even
though in practical applications some systems of these groups may have
advantages over others. For example, the software only systems are easier
to modify and add new services, while the hardware systems are free from
risks relating to viruses and "Trojan horses". At the present time most of
hardware systems have a primitive client software with a scant operating
functionality, since they are oriented to the chip card computers of low
power. Taking into account the high pace of computer miniaturization as
well as the pace of growth of their power, one may expect that in the
nearest future a matchbox-sized computer will be able to run a rather
sophisticated client software. As we decided to develop a software only
payment system, the further discussion will relate to the software only
systems.
One of the client anonymity methods provides for the bank to open anonymous
accounts associated with a certain public key. Generally speaking, there is
nothing the bank needs to know about the client except his or her public
key which is used to verify signature on client's orders. Even though the
bank cannot provide some services for an anonymous client, e.g. lend money
without security, an anonymous client is very convenient for the bank since
there is no need to spend resources on checking the client's background.
Therefore, overhead expenses on an anonymous client are much lower than on
a non-anonymous client (at least, until digital identities come into wide
use). We think that in order to be cheap a mass payment system must be
anonymous.
Another client anonymity method provides for the payer to effect payment by
transferring bearer digital money certificates to the payee, which
certificates the payer first obtains from the bank using a blind signature
technology. The blind signature technology allows to break the link between
the certificate and the account from which money was withdrawn. Thus, the
payments become untraceable. However there is a specific double-spending
problem in this payment method since digital certificates are easily
duplicated. There are two approaches to the solution of this problem and
the payment systems are classified as on-line and off-line ones according
to the adopted approach.
An on-line payment system is the one in which the moment of receipt of
payment by the payee is the moment of successful authorization of payment
by the bank, i.e., the moment of recognizing the presented certificates by
the bank. Thus, in the on-line payment system the payee has to apply to the
bank for confirmation of each payment. The bank in its turn has to run a
list of used certificates in order to check the incoming certificates
against it.
An off-line payment system is the one in which the moment of receiving the
payment by the payee is the moment of successful verification by the payee
of the certificates provided by the payer as payment. This means that the
payee, e.g. a seller, need not apply to the bank at the moment of payment -
all it has to do is to present all the received certificates to the bank,
e.g. at the end of the working day. In this case seller's operation is less
dependent on the bank's Internet accessibility and all parties save on time
of establishing numerous repetitive Internet connections. The bank is
obliged to credit seller's account with the amount corresponding to correct
digital certificates. The bank must identify reused certificates and deal
with double-spenders for itself. There is a number of clever techniques of
blind issuance of digital money certificates and subsequent transfer of
them in the payment transaction, such that the identity of the payer is
revealed in case he/she reuses their money certificates. Compared to the
on-line systems, the off-line payment systems are noticeably more
complicated, require more resources, and their protocols are more
interactive. However the principal reason for which we chose to develop the
on-line system is that in the off-line system the client cannot be
anonymous when receiving money certificates from the bank.
As the starting point for building the on-line payment system, let us
consider the system proposed by Chaum [1]. The following data are the money
certificate (coin of denomination i in currency c) in this system:
Coinc, i = {c, i, x, gc,i-1(f(P))},
where x is the client-chosen "random" element of a large set M, Ÿ: M(M( is
an easy-to-calculate publicly-known mapping that is hardly invertible for
all participants in the payment system (except, perhaps, the bank), gc,i:
M(M( are easy-to-calculate publicly-known bijection mappings that are
independent of each other and Ÿ and are hardly invertible for all
participants of the payment system except the bank. The gc,i-1 is the bank
signature mapping corresponding to the denomination i in the currency c.
For definiteness, we assume that M=M(=(Z/mZ)* where m is some composite
whose factorization is known only to the bank and gc,i(x) = xEc,i are the
functions of raising to the appropriate power. The bank may blindly produce
the described coins for the client. The payer makes payment by transferring
to the payee a set of coins whose sum of denominations is equal to the
amount of payment. The payee forwards the received coins to the bank for
authorization. The bank makes sure that the submitted coins are not on the
list of used coins, then puts them into this list, credits seller's account
with the amount of payment and informs the seller of the success. The
payments in this system are unconditionally untraceable. Now we shall point
out some disadvantages of Chaum's system.
>From the theoretical point of view a substantial disadvantage of Chaum's
system is that the payer and the bank have to trust each other. The bank
can misappropriate the coin presented by the payer, claiming that it has
already been presented before. In his turn, a double-spender can claim that
the coin was not reused and the bank just wants to steal it. The payee also
has to be trusted if the coins are transferred to him openly. It should be
pointed out that this disadvantage is a fundamental property of the bearer
certificates rather than a specific property of Chaum's coins. The bearer
certificates do not carry any secret of the bearer by means of which he
could prove his rights to the certificate.
The main field of application of the payment system is electronic commerce.
To settle conflicts within a trading system, any payment transaction must
be linked to the corresponding merchandise transaction so that the payer
would be able to prove the fact of payment as well as its purpose. Insofar
as Chaum's system provides no internal means of integration with a trading
system, in addition to the Wallet (payment system client) the payer must
also have a Buyer (trading system client) specific for this trading system
that will tie the payment transaction to the merchandise transaction.
Sooner or later the list of used coins in Chaum's coin system will become
too large to keep and operate on-line. Besides, the time of searching for
coins in this list grows with the list, even though logarithmically.
Therefore, to keep the list within the acceptable limits, the bank must
limit the period of coins validity. In this case the used coins whose
validity period of which has elapsed may be removed from the list. The
expired and not used coins may be redeemed in some off-line procedure. A
too short validity period of coins does not make the payment system more
attractive for consumers. At the same time the list of used coins grows the
faster the wider is the range (and discreteness) of possible payments,
because a wide range requires many denominations of coins. Consequently,
widening the range of possible payments leads to growing the average number
of coins in a payment. The increase in the average number of coins in a
payment increases proportionally to the time of searching for coins in the
list of used coins. A steady progress in the field of computer equipment is
gradually making this problem less serious. Besides, Chaum [2] proposed an
ingenious method for a blind return of change by the bank that allows one
coin in a payment.
Let us make the following change in Chaum's coin system. For each planned
coin, the client generates a random pair (S,P( of private and public keys
according to some signature system, for instance RSA. Let us designate the
corresponding signing and verifying functions by SignP(·) and VerifyP(·, ·)
so that VerifyP(X, Y) = True if and only if Y = SignP(X). The coin that the
client generates in cooperation with the bank consists of the following
data:
Coinc, i(P) = {c, i, P, gc,i-1(f(P))},
i.e., a random open key is now used instead of the random serial number.
However the client now makes payment by transferring an extended coin to
the payee:
{Order, Y, Coinc, i(P)}, (ext)
where Y = SignP(Order), and the Order is a unique description of payment
containing, in particular, the number of the account to which the money
should be credited. The format of the description is not substantial for
the general consideration. The bank authorizes the payment only if the coin
with the given P is not on the list of used coins and
VerifyP(Order, Y) = True. (ver)
In case of successful authorization the bank enters the coin (ext) into the
list of used coins, credits the appropriate amount to payee's account and
sends the signed receipts that include the Order, to the payer and payee.
The above modification relieves the bank and the payer of the necessity to
trust each other. Indeed, the bank cannot misappropriate the coin because
it is unable to produce the coin extension data satisfying the relation
(ver). In its turn, the bank defends itself from being accused of
misappropriation of the coin by demonstrating the coin extension data
satisfying the relation (ver).
The above modification allows to connect easily the payment system with
practically any trading system: it is sufficient to include in the Order
the hash of the contract describing the terms of the deal. In this case the
receipt with the bank's signature will link the payment and contract. The
contents of the contract will be unknown to the bank.
>From the theoretical point of view replacing an arbitrary random serial
number by an arbitrary random public key enhances security of the coin.
Indeed, suppose a counterfeiter managed to invert the protector function f,
then to spend the brand-new coin he needs to resolve a hard problem of
finding a private key corresponding to coin's public key.
During payment, the payer has to sign the Order as many times as many coins
are included in the payment. Since payment may include tens of coins and
producing the signature is a rather time-consuming operation, the above
scheme may work unacceptably slowly. The situation can be noticeably
improved by using Chaum's method of blind return of change. In this case a
small number of coins, e.g. only one, may participate in each payment.
PayCash System
A user of the PayCash system carries out his transactions by using the data
that we refer to as a payment book. The structure of the payment book is
PayBook(c, P, N) = {c, N, P, gc-N(f(P))},
where P, f, and g have the same meaning as above, and gc-N(X) =
gc-1(gc-1(...gc-1(X)...)). The solvency of the book is determined by the
payment book disposition which is a "small" non-negative number N. The
currency symbol c will be subsequently omitted for brevity. The necessary
condition for the triple {N, P, A} to be a payment book is
f(P) = gN(A). (check)
This condition may be easily verified by any participants of the system
including the owner of the book himself. Thus, the payment book differs
from Chaum's coin in that a random public key is used instead of a random
series number and the value is encoded not via the "nominal value", but via
the power of signing mapping.
It is obvious that the client can generate an empty payment book, i.e., the
book with zero disposition PayBook(P, 0) = {0, P, f(P)}. Moreover, the
client having a payment book PayBook(P, N) can generate all possible books
with the same P but lower dispositions
PayBook(P, 0), PayBook(P, 1),..., PayBook(P, N-1).
On the other hand, it seems quite plausible that reducing the disposition
of the book is the only feasible way for the client to generate payment
books with non-zero dispositions without assistance of the bank. In fact,
to generate independently a payment book with the disposition N>0 from the
very beginning, the client must satisfy the equation (check) where he is in
control of A, N, and, to some extent P. Since he is not able to invert
either f or gN for all N>0, he cannot solve the equation (check) in case
when two of three parameters A, N, or P are fixed. It seems that the
hypothetical methods of generating a payment book, which involve fixation
of only one variable or none of them are even more complicated because the
f and g functions are "independent". The client is not also able to
increase by his own the disposition of a non-empty payment book that he has
not derived from the book by reducing its disposition, because in this case
he must satisfy the equation
A=g(N(A'),
where he controls A' and the sum (N>0 (just the sum that he wants to add to
his book), the parameter A=g-N(f(P)) being fixed.
The client can increase solvency of his payment book, i.e., increase its
disposition, only in co-operation with the bank. To add the sum N2 to the
payment book PayBook(P, N1), the client sends the blinded data B to the
bank. In the simplest modification of Chaum's method the blinded data B
have the form
B = gN3(r) g-N1(f(P)),
where r is a random element of the set M, and N3(N2. In exchange for the
sum N2 the bank sends the client the signature C = g-N2(B), from which the
client extracts the desired part of the book PayBook(P, N1+N2):
C/gN3-N2(r) = g-N1-N2(f(P)).
The considered scheme may also use other variants of the blind RSA
signature, for instance Chaum's unanticipated signature [3] or the
signature described in the Supplement. Note that the bank receives no
information on the disposition of the book involved.
The unblinded payment books are presented to the bank during payment
transactions. The bank maintains the list of all public keys P
corresponding to the valid payment books, i.e. the books satisfying the
relation (check) that have ever been demonstrated to the bank. Together
with each key P bank also stores some other data which we refer to as a
virtual account. Among other things, the virtual account contains the
exposition of the virtual account that is equal to the largest disposition
of the payment book with the fixed P that has been exposed to the bank in
the payment transactions. In addition, the virtual account contains the sum
of all payments performed by using the corresponding book. The list of
virtual accounts is an analogue of the list of the spent coins in Chaum's
coin system.
Now let us consider the payment transaction. Assume that the payer has the
payment book PayBook(P, N). In general, the payer sends the payee, as the
payment, the following data:
{Order, Y, PayBook(P, n)},
where n( N, and Y and Order are defined as above. The payee forwards these
data to the bank that in its turn authorizes the payment as follows:
1. The bank verifies the necessary condition (check) for validity of the
payment book involved. If the necessary condition is not met or n=0, the
payment is not authorized.
2. The bank searches for a virtual account corresponding to P. If the
account is not found, i.e., the payment book with that P has never been
presented, the bank creates it and sets the exposition of the virtual
account equal to n and the expenses equal to zero.
3. If the exposition of virtual account is less than n, the bank sets it
equal to n.
4. The bank verifies the payment. If the equation (ver) is not satisfied,
the payment is not authorized.
5. If the expenses of virtual account together with the current payment do
not exceed n, the sum of the payment is added to the expenses of the
virtual account, and the payment is authorized.
In case the authorization is successful, the bank credits payee's account
with an adequate sum and sends the payer and payee the signed receipts
containing Order.
If the payer is sure that the exposition of virtual account corresponding
to the payment book PayBook(P, N) is sufficient for the projected payment
(for instance, the previous bank receipt has informed him on the virtual
account exposition), he may send as a payment a reduced set of data
{Order, Y, P}.
In this case the authorization procedure needs apparent modifications.
Note that the payment sum does not need to be a multiple of the withdrawal
unit g-1(f(P)), but may actually take arbitrary values. For instance, one
may be constrained to withdraw from their account to the book only a whole
number of cents and nevertheless be able to pay 2.718 cents.
Evidently, the bank can easily link all payments made from the same payment
book via a common virtual account. Let us consider the problem of
linkability of payments made from different payment books. Taken alone, the
blind signature techniques does not necessarily ensure that the account
from which the money was withdrawn cannot be linked to the virtual account
corresponding to the payment book. For instance, the payment book owner
Internet address may give rise to such a link, this being a common problem
for all payment systems which take care of user anonymity. Another source
of the linkability may be the total amount of money withdrawn to the
payment book. However, this factor may be substantially eliminated due to
the facts that payment book may withdraw money from different accounts and
also that during the payment transaction the payment book owner does not
expose to the bank disposition N of the payment book PayBook(P,N). In
addition, it is easy to build in the PayCash payment system a slightly
modified technique for the Chaum's blind change return using which one can
restructure the dispositions the payment books and, in particular, to
transfer the residual sum from the unneeded payment book to a new one.
Contrary to the Chaum's system, the size of the database for certificates
which have been used in transactions (i.e., for the virtual accounts in the
PayCash system bank) allows the price regulation. What this means is since
the bank charges for registration of each virtual account and thus each
database component is paid, its database for virtual accounts is protected
from overfilling. If registration of a virtual account costs not much
relatively to the monthly expenses of an average user (for instance, a
dollar), than, on the one hand, such payments would not be very hard to a
user, and, on the other hand, the user who is very anxious for his privacy
would be able to ensure relatively cheaply the absence of association
between the portions of his payments.
[1] D. Chaum, Security without identification: transaction systems to make
big brother obsolete, Comm. ACM 28, 10 (October 1985).
[2] D. Chaum, Returned value blind signature systems, U.S. Patent
4,949,380, 14 Aug 1990.
[3] D. Chaum, Blind Unanticipated Signature Systems, U.S. Patent 4,759,064,
19 Jul 1988.
8
--- end forwarded text
-----------------
Robert A. Hettinga <mailto: rah@philodox.com>
Philodox Financial Technology Evangelism <http://www.philodox.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:04