Auditable, Anonymous Electronic Cash-Berkeley

http://www.cs.tau.ac.il/~amnon/Papers/ST.crypto99.pdf

Auditable, Anonymous Electronic Cash
(Extended Abstract)
Tomas Sander and Amnon Ta–Shma
International Computer Science Institute
1947 Center Street, Berkeley, CA 94704, USA
{sander,amnon}@icsi.berkeley.edu
Abstract. Most anonymous, electronic cash systems are signaturebased.
A side effect of this is that in these systems the bank has the
technical ability to issue unreported, valid money. It has been noticed in
the past that this may lead to a disaster if the secret key of the bank
is compromised. Furthermore, the above feature prevents any effective
monitoring of the system.
In this paper we build a fully anonymous, auditable system, by constructing
an electronic cash system that is signature-free, and where the
bank needs to have no secret at all. The security of the system relies
instead on the ability of the bank to maintain the integrity of a public
database. Our system takes a completely new direction for meeting the
above requirements, and, in particular, it is the first to do so without the
necessity of making individual transactions potentially traceable: payers
enjoy unconditional anonymity for their payment transactions. The
system is theoretically efficient but not yet practical.
Keywords: electronic cash, anonymity.
1 Introduction
Payment systems should be safe and sound. When we deposit money into a bank
we believe the bank will honor its commitments to us, and even though individual
banks may run into problems (e.g., because of bad investments they make) most
bank accounts are insured by national governments protecting consumers from
losses. In return the banking industry is highly regulated and monitored by
governmental agencies. There are at least two sides to this monitoring. One is to
ensure that transactions are executed correctly. The other is to check the financial
stability of the bank where it is verified that banks reasonably control their risks
in issuing credits and loans, investing their assets and their operational risks
(including insider crime) [32, 31]. This monitoring becomes even more critical
with electronic cash systems in which issuers can issue money themselves.
We call a system auditable if it allows to effectively control the money supply,
i.e. if there can not be valid money that is not known to the auditor (we later
give a more formal definition). An electronic cash system that has this property
and also has a complete report of transactions (which is ”standard” in monetary
systems) allows monitoring the same way the banking system is monitored
Michael Wiener (Ed.): CRYPTO’99, LNCS 1666, pp. 555–572, 1999.

c Springer-Verlag Berlin Heidelberg 1999
556 T. Sander, A. Ta–Shma
today. On the other hand, if this property is violated then monitoring may not
reflect the actual reality. We believe that even just for that reason auditability
is important and desirable. Unfortunately, not too much attention was given to
this property and there are many systems (e.g. [10]) which violate it. I.e., in
such systems the issuer can issue valid money that is not reported anywhere, and
thus such a system can be “technically” functioning correctly, and apparently
stable, while it is in fact insolvent.
Further abuses of anonymous systems exist. Some of these exploit another
bad property that may exist in an electronic cash system, and which we call
rigidity. We say a system is non-rigid if any withdrawn money (in a standard
or a non-standard withdrawal transaction) can be later invalidated (see a formal
definition in Section 4). We argue that auditable, non-rigid systems defend
against most of the major known attacks and abuses of anonymous electronic
cash systems. The challenge is to build a fully anonymous yet auditable and
non-rigid system. Previous solutions to the problem use electronic cash systems
with “escrow” agents that can revoke the anonymity of users or coins. Thus, they
compromise the anonymity feature. We take a completely different direction and
present a solution that gives users full statistical anonymity.
1.1 Our Solution
In our system there is no trustee and a users’ privacy can never be compromised.
Furthermore, our system is not signature based, and in fact it is “secret-free”;
there is no secret key the bank needs to hold (and therefore nothing that can
be stolen,e.g. by insiders!). Furthermore, in our system all relevant bank actions
are public and publicly verifiable, and the system is also fully auditable in the
same way banks are auditable today.
The security of the system relies on the ability of the bank to maintain the
integrity of a public database, and the auditability property follows from the
fact that all transactions (including issuing new coins) are made public and can
not be forged.
Our system also protects from blackmailing attacks against the bank; the
only way a blackmailer can force the bank to issue electronic coins that will
be accepted as valid payments is by forcing the bank to add some public data.
The bank (and the whole world) knows which data have been added during
the blackmailing, and as our system is also non-rigid the situation can be later
reversed. Furthermore, even if the bank is willing to follow all terms dictated by
blackmailers, there is no way for the bank to issue non-rigid coins. This leaves,
for example, kidnapers with the knowledge that once they free the hostage they
are left with worthless coins. Certainly also the bank knows that paying the
ransom can not lead to a release of the hostage. This loose/loose scenario will
strongly discourage both players to use this non–rigid system in blackmailing
scenarios. Our system also has the advantage that it can remain off line after a
blackmailing attack on the bank has occurred once the system has been updated.
On the conceptual level it is the first system that simultaneously guarantees
unconditional user anonymity together with strong protection against the black-
Auditable, Anonymous Electronic Cash 557
mailing and the bank robbery attack, in which the bank’s secret key for signing
coins is compromised. Recall that previous work addressed potential criminal
abuses of electronic cash systems mainly in the escrowed cash paradigm, where
each user transaction is made potentially traceable by Trustee(s). As Camenisch,
Piveteau and Stadler [17] put it, these type of systems “offer a compromise between
the legitimate need for privacy protection and an effective prevention of
misuse by criminals”. Our system defends against these attacks without doing
the “compromise” cited above, and this is achieved using a simple, straightforward
approach.
This raises the question whether other significant system abuses like money
laundering can be effectively prevented by still preserving unconditional user
anonymity. That the latter is possible was shown by the authors in [36] where
an amount–limited, strongly non–transferable payment system was suggested.
Amount–limitedness and non-transferability assure that a money launderer can
not obtain the large amounts of anonymous electronic cash that are typically
involved and needed in money laundering activities, neither by withdrawing them
from the bank, nor by buying them on a “black market” for anonymous electronic
cash. Using the techniques developed in [36] the current system can also be
made amount–limited and non-transferable. The combined system then strongly
defends against blackmailing, bank robbery and money–laundering abuses while
offering unconditional privacy for users in their transactions. We therefore believe
that the need for escrowed cash systems should be reexamined.
1.2 Organization of the Paper
In Section 2 we describe several attacks on electronic payment systems and
previous work in which they were defeated. In Section 3 we outline the ideas
underlying our electronic cash system and show how it differs conceptually from
previous systems offering anonymity that were blind signature based. In Section 4
we give a formal description of model and requirements for our system. In Section
5 we describe the building blocks which we use in the protocol. In Section 6 we
present the protocols of our auditable anonymous system and point in Section
7 to possible directions how the efficiency of the system can be improved.
2 Previous Work
We start by describing some major attacks on anonymous electronic cash systems:
Bank robbery attack: Jakobsson and Yung [26] describe an attack where the
secret key of the issuer is compromised and the thief starts counterfeiting money.
The attack is especially devastating if no one will be able to detect that there
is false money in the system until the amount of deposited money surpluses the
amount of withdrawn money. Obviously, by that time the whole market is flooded
with counterfeited money, and the system may collapse. The Group of Ten report
from 1996 [14] expresses “serious concern”: “one of the most significant threats
558 T. Sander, A. Ta–Shma
to an electronic money system would be the theft or compromising of the issuer’s
cryptographic keys by either an inside or an outside attacker.” In the 1998 report
[33] it is stated that “of direct concern to supervisory authorities is the risk of
criminals counterfeiting electronic money, which is heightened if banks fail to
incorporate adequate measures to detect and deter counterfeiting. A bank faces
operational risk from counterfeiting, as it may be liable for the amount of the
falsified electronic money balance.” It further states “Over the longer term, if
electronic money does grow to displace currency to a substantial degree, loss
of confidence in a scheme could conceivably have broader consequences for the
financial system and the economy.”
Money laundering attacks: There are many possible ways to abuse an anonymous
electronic cash system for money laundering (cf. e.g. [2]).
Blackmailing attack: Van Solms and Naccache [38] described a “perfect”
blackmailing scenario that exploits anonymity features of (blind) signature-based
electronic cash systems.
An auditor should not have to trust the issuer because an issuer can make
profits from unreported money in several ways, e.g. for offering not properly
backed credits or by assisting in money laundering activities (for documented
cases in which financial institutions indeed assisted in unlawful activities see e.g.
[1] and also [20]).
These types of attacks motivated a substantial amount of research started
in [13] and [16], where electronic cash with revocable anonymity (“escrowed
cash”) was suggested. In, e.g. [26, 28, 15, 19, 34, 18], several systems following this
approach have been described 1. These cash systems allow a Trustee(s) to revoke
the anonymity of each individual transaction. A typical revocability feature is
“coin tracing” where the coin withdrawn by a user during a particular withdrawal
session can be identified. This feature allows to defeat the blackmailing attack in
the case a private user is blackmailed (as he may later ask to trace and blacklist
the blackmailed coins).
Few systems of the ones mentioned above protect also against (the stronger)
blackmailing attacks on the bank: a blackmailer may force the bank to enter a
non–standard withdrawal protocol to withdraw coins (and thereby disable coin
tracing mechanisms) or extort the bank’s secret key. In the related bank robbery
attack the secret key of the bank is stolen. Only the systems in [26, 19, 34, 25]
prevent against these very strong latter attacks. Some of these systems require
a third party involvement at withdrawal time and some can not remain off-line
after such an attack had occurred.
1 It has been pointed out before in [28] that systems like the one described in [37]
are not vulnerable to several of these attacks as their security (for the bank) does
not critically rely on (blind) signature techniques. Although the system [37] offers
privacy to a certain extent it is not fully anonymous. We are not aware of a previous
description of an electronic cash system that achieves full anonymity but does not
rely on blind signatures techniques.
Auditable, Anonymous Electronic Cash 559
3 The Basic Idea
3.1 Stamps and Signatures
As stated above, whereas most previous systems offering anonymity are signaturebased
and the issuer gives (blinded) signatures to coins, ours is not. Our approach
and its difference to previous ones can be best understood by considering
the “membership in a list” problem. In this problem a bank holds a list of values
L = {x1,...,xk}, The elements in the list “correspond” to valid coins (and
will be hash values of their serial numbers). If x ∈ L there is a short proof of
membership, whereas if x 6∈ L it is infeasible to find such a proof, i.e. only when
a user has a valid coin he can give such a proof, else he can not.
Let us now focus on the membership problem. One possible solution is to
keep a public list of all values in L. However, such a solution requires the verifier
to be able to access a large file. Another solution is for the bank to sign each
value in L and to accept an element as belonging to L iff it carries a signature,
which from an abstract point of view is how systems like, e.g., [10] work. Now,
however, the security of the system relies on the secrecy of the secret key of the
bank and the system becomes potentially vulnerable to blackmailing attacks.
A third solution for the membership problem was suggested by Merkle [27]. In
Merkle’s solution, all values x1,...,xk are put into the leaves of a tree, and a
hash tree is formed over the leaves using a collision resistant function h (for
more details see Section 6). The root of the hash tree is made public, and the
assumption is that this data is authenticated and its integrity can be maintained.
A proof that x is in the list amounts to presenting a hash chain from x to the
root. The collision resistant property of h then guarantees that it is infeasible to
find a membership proof for an element x 6∈ L.
When the bank adds a value to the tree it “authenticates” or “stamps” the
value as being valid for payment. Stamping is very similar to signing: Anyone
who has access to the authenticated data (the root of the tree) can validate a
stamp (by checking the hash chain leading to the root) which is similar to the
public verification predicate in signature schemes. Also, it can be achieved that
it is infeasible to forge neither signatures nor stamps. The key difference, from
our perspective, between signatures and stamps, is that the secret/public key
pair required in a signature scheme is “replaced” with authenticated public data
(the root of the tree) which is exactly what we need for solving the bank robbery
attack, the blackmailing attack and achieving auditability. Although the security
requirements are different our system has technically some similarities to time
stamping protocols [24, 8, 3] that also made use of tree based methods.
Our protocol uses Merkle’s solution in a way that also allows to incorporate
full anonymity, detection of double spenders and full auditability. Other features
(as non-transferability and amount limitedness) can be easily added.
560 T. Sander, A. Ta–Shma
3.2 On the Update of Roots and Hash Chains
Let us say for the ease of explanation that a time frame lasts a minute, an hour
has two minutes, a day has two hours, a week has two days, etc. At the first
minute the bank creates a minute tree with all the coins issued at that minute on
its leaves. At the second minute another minute tree is formed. When the second
minute ends the two minute tress are combined into an hour tree by hashing the
two roots of the minute trees together. During the next hour a new hour tree is
used. When the second hour ends we combine the two hour trees to a day tree,
and a new day tree is formed, and so on. Altogether we have a forest. Let us say
that a root is alive if it is a root in the forest, i.e. it is the root of one of the last
hour,day,week etc tree. If our system is to cover one hundred real years, then
the system has to have about 5, 000, 000 roots (100 · 365 · 24 · 60 << 226 ) and
therefore 26 levels are necessary (with the bottom level covering minutes, the
level above it hours etc.). In particular, at any given minute there are at most
26 live roots.
Each merchant should hold a subset of the live roots. A merchant can choose
how often to update his list. If a merchant chooses to keep 20 live roots he needs
to update his list every 26 minutes, and he can not accept coins that were issued
in the last 26 minutes. He can choose to keep all 26 live roots (and therefore
accept all issued coins) but then he needs to update his list every minute.
When a user withdraws a coin the bank sends him a hash chain from his coin
to the root of the current tree, and each time the tree is combined with another
tree the bank updates the chain so that it leads to the root of the combined tree.
Altogether the bank sends the user 26 update messages. A payment transaction
begins with the merchant sending the user the set of all live roots he knows. The
user proves in a zero knowledge way that he knows a hash chain to one of the
roots in the set.
We point out the following:
– The updates are independent of the actual transaction that takes place and
the specific user. An update at the end of an hour should only contain the
values of the roots of the last two minutes, an update at the end of a day
should only contain the roots of the last two hours etc. As a result the
updates can be broadcasted to every system participant.
– Each merchant can choose how often he makes the updates. The only disadvantage
in making less updates is that coins that were issued within the
last uncovered period can not be accepted by the merchant.
– When a user tries to spend a coin to a merchant who does not accept coins
from the last k minutes, the only information the user reveals is that his coin
was not withdrawn during the last k minutes.
We believe that such a system might offer a flexible and practical solution
to anonymous off-line cash. We call the system off-line because if a merchant
chooses to be updated only once a day he can certainly do so. The users can
also spend their money without involving the bank. They suffer however from
the disadvantage that at least at the beginning they need to be updated often.
This can be improved if more recent roots are kept by the merchant.
Auditable, Anonymous Electronic Cash 561
3.3 On the Security of the System
A crucial property we need is that the integrity of the published root of the tree
is maintained. This can be achieved by publishing the root in the New York
Times, or mirroring it in many different places, as was already pointed out in
the original paper of Merkle.
Besides the authenticated data the bank keeps all sorts of data structures,
including, e.g., the tree itself, a data structure carrying the balance of each
account in the system, and more. It is clear that the bank can change these
data structures, and in fact this can be done even in the banking system of
today, where a bank can technically take all the money from one’s account. Such
accounting problems are well understood, and they are quite successfully dealt
with in the banking industry. We do not deal with them in our system.
In an off-line system a merchant needs to verify membership to L reliably,
i.e. he needs the correct roots. Criminals might establish a site that claims to
contain the necessary authenticated data, and try to trick merchants into accepting
a forged root. There are many different ways to address this problem, and
furthermore such an attack is detected by the bank as soon as a forged coin is
deposited. The bank can take a variety of steps immediately like shutting down
the false source of the root, raising an alert or redistributing the correct root.
The merchant can also set his own policy how to verify the authenticity of the
root, and thereby manage his risk.
4 System
We first describe our model:
The participants: Users, merchants, a bank and the auditor.
Infrastructure: We assume there is an authenticated way for the bank to
distribute the roots of its trees of issued coins.
Time: We assume that there are consecutive time frames denoted T1, T2,....
We call the basic time frame a ’minute’. Two minutes are grouped together to
an hour, two hours to a day and so forth.
Computing Power: All participants are probabilistic polynomial time players.
Trust Model: The network and the distribution channels are reliable and
anonymous. Users and merchants trust the bank not to steal their money 2. The
auditor does not trust the bank not to issue unreported money.
System Events: We focus on the following system events:
– A user opens an account.
– A user withdraws money at the bank.
– The bank updates and broadcasts the roots of the forest.
– A user pays a coin to a merchant.
– A merchant deposits a received coin at the bank.
2 By introducing receipts this trust requirement can be minimized using well known
techniques. In this work we focus on the auditability property.
562 T. Sander, A. Ta–Shma
– The bank invalidates funds that have been withdrawn before.
We have the following requirements for our system:
Unforgeability: It is infeasible for any coalition of participants in the system
excluding the bank to create an amount of payments accepted by the bank that
exceeds the amount of withdrawn coins.
Auditability: There is a file, accessible by the auditor, that is supposed
to describe all the events that have occurred in the system. In particular all
withdrawals are supposed to be reported there. A withdrawal record should at
least report who withdrew the money. We say c is a coin if it can be deposited,
or if it was already successfully deposited.
Definition 1. A system is auditable if there is a one to one correspondence
between all coins c and the withdrawal records.
We stress that we do not require that the one to one correspondence is known
to the auditor or anyone else. In fact, in a truly anonymous system it is not. All
we require is that such a correspondence exists. If the system is auditable, we
also say the system does not admit any unreported money.
Non-Rigidness We say a system is non–rigid if any coin that can be accepted
as a valid payment by the deposit protocol (and it does not matter
whether it was withdrawn in a standard or non–standard transaction) can be
invalidated.
Unconditional Payer Anonymity: A payer has unconditional anonymity,
if transcripts of withdrawals are statistically uncorrelated to transcripts of payments
and deposits.
We stress that at withdrawal time the user has to identify himself to the
bank, and the bank might record the withdrawn string z along with the identity
of its owner. Yet, as transcripts of withdrawals are statistically uncorrelated to
transcripts of payments and deposits, this does not give the bank any information
on how or to whom a withdrawn coin is spent.
5 Tools
Definition 2. We say a function f : A×B → C is one-way, if the probability a
polynomial time machine given a random c ∈ C can find (x, r) s.t. f(x, r) = c is
negligible. We say a function f : A×B → C is collision resistant, if the probability
a polynomial time machine can find (x, r) 6= (x0
, r0
) s.t. f(x, r) = f(x0
, r0
) is
negligible.
Definition 3. Let G be a domain of size p. We say a function g : [0..p − 1] ×
[0..p − 1] → G is concealing if for any [0..p − 1] the distribution g(x, [0..p − 1])
obtained by picking r ∈ [0..p−1] at random and computing g(x, r) is the uniform
distribution over G.
Auditable, Anonymous Electronic Cash 563
b_1=h(a_1,a_2) b_2=h(a_3,a_4)
a_1 a_4 a_2 a_3
R=h(b_1,b_2)
Fig. 1. A hash chain ((1, 0); a3; (a4, b1)).
Assuming DLog is hard for certain groups of prime order G (see [9]) oneway,
collision resistant and concealing functions exist and can be based on the
representation problem [9]. More specifically, if G is a group of prime order p, for
which DLOG is hard, and g1, g2 are chosen at random (so almost always they
are two distinct generators of G), then g : [0..p − 1] × [0..p − 1] → G defined by
g(x, y) = gx
1 gy
2 has these properties (see [9] Proposition 7 and Corollary 8, for
details).
5.1 Hash Chains and Hash Trees
Hash Chains. A hash chain of length 1 to a root R is a triplet (i1; x; y) s.t.
f(i1)(x, y) = R, where f(0)(x, y) = h(x, y) and f(1)(x, y) = h(y, x).
A chain of length d > 1 to a root R is a triplet ((i1,...,id); x; (y1,...,yd))
s.t. ((i1,...,id−1); f(id)
(x, yd); (y1,...,yd−1)) is a hash chain of length d−1. We
also say that the hash chain starts with the value x and leads to the root R. See
Figure 1.
Hash Trees. For a given domain D, and a known hash function h : D×D → D
a hash tree (T, val) consists of a balanced binary tree T, with vertices V , together
with a function val : V → D s.t. for any vertex v with two children v1 and v2,
val(v) = h(val(v1), val(v2)). The only operation that can be performed on a
hash tree is UP DAT E(leaf, w) where the leaf’s value is changed to w and the
values of the internal nodes from the leaf to the root are accordingly updated.
5.2 Non-interactive Zero Knowledge Arguments of Knowledge
under the Random Oracle Assumption
We will frequently use perfect zero knowledge arguments of knowledge (ZKA)
i.e., proofs that show that the prover knows a witness w to the predicate φ (i.e.
φ(w) = T rue). These proof are convincing if the prover is polynomially bounded,
and the proofs statistically do not reveal extra information. The notion of a proof
of knowledge is from [23, 5]. Under the discrete log assumption any NP predicate
has a perfect zero knowledge argument of knowledge ([11, 12, 22, 21], see also [29]
564 T. Sander, A. Ta–Shma
for zero knowledge arguments under weaker conditions and [4] for further details
on ZKA’s of knowledge).
We will need non-interactive perfect zero knowledge arguments (ZKA) of
knowledge. We make the random oracle assumption [6] that has been commonly
used in the design of electronic cash systems. Assuming the random oracle assumption,
and using the techniques of Bellare and Rogaway [6], the zero knowledge
argument of knowledge protocols can be made non-interactive (See [6] for
the treatment of the similar case of zero-knowledge proofs).
6 An Anonymous Auditable Electronic Cash System
We now build an auditable, electronic cash system that allows users to have
unconditional anonymity.
When Alice withdraws a coin, she chooses x and r (which she keeps secret)
and sends z = g(x, r) to the Bank. x should be thought of as the serial number
of the coin, r is a random number and g is concealing and collision resistant. The
bank adds the coin z to the public list of coins, yet only a person who knows a
pre-image (x, r) of z can use z for payment, and because g is one-way only Alice
can use the coin z. To make the system anonymous for Alice when she wants
to spend a coin z she proves with a zero knowledge argument that she knows
a pre-image (x, r) of some z that appears in the list of coins, without actually
specifying the value z. To prevent double–spending extra standard mechanisms
are added to the system.
As it turns out the most expensive part of the protocol is the zero knowledge
argument of membership where Alice has to prove she knows a coin z from the
public list of coins that has certain properties. A straight forward implementation
of this would require a proof that is polynomially long in the number of coins.
A better, and theoretically efficient, protocol for testing membership in a list
was suggested by Merkle [27] using hash trees, and our system builds upon this
solution. We now give a more formal description of the protocol.
6.1 The Protocol
Setup: During system setup bank and auditor (and possibly users) choose jointly
the following objects. Fq is a field of size q = poly(N) and N is an upper
bound on the number of coins the bank can issue. G is a group of prime order
p for which DLOG is hard, and |G| ≥ q3. Further an efficient 1-1 embedding
E : F3
q → [0..p−1] is chosen (e.g., by using binary representations of the elements
in Fq and concatenating them). g : [0..p−1]×[0..p−1] → G is a one-way, collision
resistant and concealing function.
D is a large domain, |D|≥|G|, and h : D ×D → D a collision resistant hash
function. An efficient 1-1 embedding F : G → D is chosen. The bank keeps a
hash tree T over D with N leaves. This hash tree is gradually built. There is no
need to initialize the tree.
Auditable, Anonymous Electronic Cash 565
Each merchant obtains a unique identifying identity, and we assume the existence
of a random oracle H : TIME × ID → Fq that maps time and an id
to a random element of Fq. We assume that each merchant can do at most one
transaction per time unit (this time unit can be chosen to be very short). Alternatively
the merchant has to add a serial number to each transaction occurring
at the same time unit and is not allowed to use the same serial number twice.
Account Opening: When Alice opens an account, Alice has to identify herself
to the bank, and the bank and Alice agree on a public identity PA ∈ Fq that
uniquely identifies Alice.
Withdrawal: Alice authenticates herself to the bank. Alice picks u1 ∈R Fq,
serial ∈R Fq and computes u2 = PA − u1 ∈ Fq and x = (u1, u2, serial) ∈ F3
q .
serial is the serial number of the coin and u1, u2 are used to encode Alice’s
identity. She also picks r ∈R [0..p − 1] and sends z = F(g(E(x), r)) ∈ D. to the
bank. She gives the bank a non-interactive zero knowledge argument that she
knows u1, u2, serial and r s.t. z = F(g(E(u1, u2, serial), r)) and u1 + u2 = PA,
i.e, that the coin is well formed. The bank also makes sure that the coin z has
not been withdrawn before. See Figure 2.
Fig. 2. Withdrawal
Alice Bank
u1 ∈R Fq , u2 = PA − u1 ∈ Fq
serial ∈R Fq, r ∈R [0..p − 1]
z = F(g(E(u1, u2, serial), r)) PA,z −→
Alice gives a non-interactive
ZKA that z is well formed
−→
In the zero knowledge argument Alice has to answer challenges. These challenges
are determined in the non-interactive ZKA protocol using the random
oracle H.
The bank then subtracts one dollar from Alice’s account, and updates one of
the unused leaves in the tree T to the value z (along with the required changes to
the values along the path from the leaf to the root). When the time frame ends
the bank takes a snapshot of the tree T and creates a version. After creating
the version the bank sends Alice the hash chain from z to the root of T, taken
from the hash tree T. Alice checks that she was given a hash chain from z to
the public root of the hash tree T.
Updates: Each minute a new minute tree is generated, and a version of it
is taken at the end of the minute. When two minute versions exist, they are
566 T. Sander, A. Ta–Shma
combined together to an ’hour’ tree, by hashing the two roots together. Similarly,
if two hour trees exist, they are combined together to a day tree and so forth.
At the end of each hour,day, week etc. a broadcast message is sent to all users
who withdrew a coin during that time period. The hour update, e.g., contains
the values of the two minute roots that were hashed together to give the hour
tree root. Merchants can follow their own updating policy.
Payment: Alice wants to make a payment with a coin
z = F(g(E(u1, u2, serial), r)) to a merchant M with identity mid. The protocol
starts with M sending Alice the set ROOT S of live roots he knows. A root is alive
if it is the root of the tree of the last minute, hour,day etc. Alice then sends the
merchant serial, time and the value v = u1 + cu2, where 1 6= c = H(time, mid).
She then proves to the merchant with a non-interactive ZKA that she knows
u1, u2, r, R and a hash chain ((i1,...,id); w; (y1,...,yd)) to R s.t.
– R ∈ ROOT S,
– w = F(g(E(u1, u2, serial), r)) and
– v = u1 + cu2.
The merchant verifies the correctness of the non-interactive ZKA. See Figure 3.
Fig. 3. Payment
Alice Merchant
ROOT S ←−
c = H(time, mid) ∈ Fq
v = u1 + cu2 ∈ Fq
time,v,serial −→
Alice gives non-interactive ZKA
that she knows a valid hash chain
with the above c, v, serial, ROOTS
−→
Deposit: The merchant transfers the payment transcript to the bank. The
bank checks that the merchant with identity mid has not earlier deposited a
payment transcript with this particular parameter time. The bank verifies that
the challenges are correct (i.e., they are H(time, mid)), that the set ROOT S in
the payment transcript consists of valid roots, and that the non-interactive ZKA
is correct. The bank then checks whether serial has already been spent before.
If not the bank credits the merchant’s account and records serial ∈ Fq as being
spent along with the values c ∈ Fq and v(= u1 + cu2) ∈ Fq.
If serial has been spent before the bank knows two different linear equations
v1 = u1 + c1u2 and v2 = u1 + c2u2. The bank solves the equations to obtain u1
and u2, and P = u1 + u2. The bank then finds the user with the public identity
P.
Auditable, Anonymous Electronic Cash 567
Invalidation of funds: The bank removes the coins that should be invalidated
from the forest and recomputes the corresponding roots and the hash chains for
each leaf in the forest. The bank distributes the updated snapshot of the forest
and sends the updated hash chains for each of the withdrawn coins in the forest
to the user who withdrew it.
6.2 Correctness
Theorem 1. Under the random oracle assumption, if DLOG is hard, and the
assumptions we made in the description of our model in Section 4 the electronic
cash system is statistically anonymous, unforgeable, auditable, non–rigid and
detects double spenders. The system is also efficient, and the time required from
all players at withdrawal, payment and deposit time is polynomial in the log of
the total number of coins N (i.e. the depth of the tree) and the security parameter
of the system. Each user receives logN messages per withdrawal.
Proof. Unforgeability: We prove that any spent coin must appear as a leaf in T.
To spend a coin Charlie needs to know a hash chain ((i1,...,id); w; (y1,...,yd))
to a root R of a valid tree T. Because h is collision resistant, and all the players
are polynomial, they can not find two different chains, with the same (i1,...,id)
leading to the same value. Hence, it follows that the hash chain Charlie knows
is exactly the path in T going down from the root according to (i1,...,id). In
particular w is a leaf of T.
Double Spending: If Charlie spends a coin z then this coin must have been
withdrawn before, as was shown in the proof of the unforgeability property, let’s
say by Alice. When Alice withdrew z she proved she knew u1, u2, serial and r
s.t. z = F(g(E(u1, u2, serial), r)) and u1 + u2 = PA. When Charlie spends the
coin he proves he knows a hash chain that starts at z, and u0
1, u0
2, serial0
, r0 s.t.
F(g(E(u1, u0
2, serial0
), r0
)) = z. As g is collision resistant and E and F are 1-1,
it follows that u0
1 = u1, u0
2 = u2 and serial0 = serial. In particular, any time
a coin z is spent, the serial number that is reported is always the same (the
serial number chosen at withdrawal time). In particular double spent coins can
be easily detected by observing the serial number.
When a coin is spent a challenge to u0
1 + cu0
2 is answered and answered
correctly (we have a non-interactive zero knowledge argument of correctness).
Furthermore, as we have seen above the u0
1, u0
2 are always the same and they
are identical to the u1, u2 chosen at withdrawal time. By the random oracle
assumption, the assumption that each merchant has a distinct ID and that he
can only do one transaction per time unit, no challenge is repeated twice. Hence if
the same coin is spent twice, we see the answers to different challenges and we can
easily solve the system of two equations to discover u1 and u2 and consequently
u1 + u2 = P which is the identity of the double spender.
Anonymity: The non-interactive zero knowledge arguments do not reveal any
information in an information theoretic sense about Alice’s inputs beyond the
fact that the coin is well formed (resp. the validity of the claim that is proved). We
568 T. Sander, A. Ta–Shma
would like to show that the information at withdrawal time (i.e. P and z) is statistically
independent of the information at deposit time (c, v = u1 + cu2, serial
and ROOT S). We first observe that even given u1, u2, c, serial and ROOT S the
value z = F(g(E(u1, u2, serial), r)) is uniform, because g is concealing. We are
left with P at withdrawal time and c, v = u1 + cu2, ROOT S at deposit time.
Since u2 = P −u1 we have v = cP + (1−c)u1. As u1 is uniformly distributed, so
is v. Also, c is a function of time and merchant id (which are public data) and
is independent of the coin.
The only possible information leakage can result from the subset ROOT S
the user uses. However, ROOT S covers all the time periods acceptable by the
merchant. Hence the deposit does not reveal more information then merely the
fact that some user paid a merchant M a coin that was proved to be valid
according to the update policy of the merchant. Thus, the system is anonymous.
Merchants who try to provide users with a manipulated list ROOT S can be
detected by the user (e.g., if he knows a valid root not in the list that should
be there) and will definitely be caught by the bank (or the auditor) when they
check the payment transcripts.
Auditability: We have already shown that if a polynomial time player can
spend a coin c then it must have appeared as a leaf in the tree. As all the leaves
in the tree are different, this shows that a one to one correspondence between
usable coins and leaves in the tree (and therefore withdrawals) exists.
Non–Rigidness: We have seen that a coin z is only usable for payment if z
appears as a leaf in the tree. Furthermore, the bank and the auditor know who
withdrew z. To invalidate z all the bank has to do is replace z with a NULL,
and update the tree, the hash chains and the roots as described in the system
event “invalidation of funds”.
Efficiency:
Withdrawal, Payment, Deposit: The dominating complexity stems from the
zero knowledge arguments. Each non-interactive ZKA of an NP statement takes
resources polynomial in the length of the NP statement. The way we described
the protocol, the user claims knowledge of a valid root, and a hash chain leading
to that root. Thus, the NP statement is of length O((log(N)+|ROOT S|) log(|D|),
(A root among all possible roots is a claim of length O(|ROOT S| log(|D|), and
a hash chain is a sequence of O(log(N)) elements each of length O(log(|D|))).
Thus, altogether the statement size is O(log2 N).
Updates and Invalidation: Whenever a minute, hour, day, year etc. ends, the
bank has to broadcast two root values to all the users who withdrew money
during that period. E.g., at the end of the year the bank has to update all
customers who withdrew money during that year. Minute updates are done
frequently but involve only few users, year updates happen only once a year but
involve many users. Each user will ultimately receive log N update messages each
containing two root values. We point out that the bank can avoid notifying the
users about year (and all infrequent) updates by simply publishing the two roots
in the New York Times or a similar medium. It should also be noted that once
Auditable, Anonymous Electronic Cash 569
a broadcasting technology becomes widely accessible, the complexity of updates
is only a constant.
Invalidation takes O(N) applications of the hash function to update the tree,
and messages should be sent to all users. Unlike regular updates this update involves
the whole tree (with O(N) data items) and can not be done by broadcast.
However, invalidation should not happen too often as mentioned above, and is
mainly used to deal with extreme cases where the bank surrendered to blackmailing.
7 Some Comments
Other protocols for testing membership in a list exist. In particular, the protocol
suggested by Benaloh and de Mare [7] using one-way accumulators, has the
property that it produces hash chains of length 1. The later protocol, however,
suffers from the disadvantage that the coalition of parties which generates the
one–way accumulator h knows a trapdoor for h. Employing the protocol in our
payment system will reduce the length of the zero knowledge proofs to a constant
independent of the number of withdrawn coins. However a person who knows the
trapdoor, can completely bypass the system’s security and pay with counterfeited
money. Thus, if an honest agency constructs h and then destroys the trapdoor
the system is safe. But at least during system setup the payment system is still
vulnerable to the bank robbery attack as the trapdoor may be compromised.
We consider this a serious disadvantage 3.
We leave open the question of designing a practically efficient system that
is both anonymous and auditable. We believe that by designing an appropriate
accumulator–like hash function and the efficient corresponding zero knowledge
proofs this should be possible. A first step in this direction was taken in [35],
where efficient accumulators without trapdoor are constructed.
Finally, we ask if there are conceptually different ways to design anonymous
payment systems which have the auditability property, and how existing anonymous
electronic payment systems can be transformed into auditable ones with
minimal performance overhead.
Acknowledgments
We would like to thank Moni Naor and Moti Yung for stimulating conversations
and Mike Just for a having pointed out a reference to us.
3 Benaloh and de Mare leave open whether one-way accumulators can be built without
using a trapdoor. Nyberg [30] builds such a system, with an accumulated hash of
length N log(N), where N is the number of items to be hashed. The large hash
length makes this protocol completely irrelevant to our case.
570 T. Sander, A. Ta–Shma
References
1. FATF-VII report on money laundering typologies. Financial Crimes Enforcement
Network Publications, August 1996. http://www.treas.gov/fincen/pubs.html.
2. Cyberpayments and money laundering. RAND, 1998.
http://www.rand.org/publications/MR/MR965/MR965.pdf/.
3. D. Bayer, S. Haber, and W. S. Stornetta. Improving the efficiency and reliability of
digital time-stamping. In R. M. Capocelli et al., editor, Sequences II: Methods in
Communication, Security and Computer Science, pages 329–334. SV , New York,
1992.
4. Bellare, Jakobsson, and Yung. Round-optimal zero-knowledge arguments based on
any one-way function. In EUROCRYPT: Advances in Cryptology: Proceedings of
EUROCRYPT, 1997.
5. M. Bellare and O. Goldreich. On defining proofs of knowledge. In Ernest F.
Brickell, editor, Advances in Cryptology—CRYPTO ’92, volume 740 of Lecture
Notes in Computer Science, pages 390–420. Springer-Verlag, 1993, 16–20 August
1992.
6. Mihir Bellare and Phillip Rogaway. Random oracles are practical: A pardigm for
designing efficient protocols. In Victoria Ashby, editor, 1st ACM Conference on
Computer and Communications Security, Fairfax, Virginia, November 1993. ACM
Press. also appeared as IBM RC 19619 (87000) 6/22/94.
7. J. Benaloh and M. de Mare. One-way accumulators: A decentralized alternative
to digital signatures. Lecture Notes in Computer Science, 765:274–??, 1994.
8. J. Benaloh and M. de Mare. Efficient broadcast time-stamping. Technical Report 1,
Clarkson University Department of Mathematics and Computer Sciences. August,
1991.
9. S. Brands. An efficient off-line electronic cash system based on the representation
problem. In 246. Centrum voor Wiskunde en Informatica (CWI), ISSN 0169-118X,
December 31 1993. AA (Department of Algorithmics and Architecture), CS-R9323,
URL=ftp://ftp.cwi.nl/pub/CWIreports/AA/CS-R9323.ps.Z.
10. S. Brands. Untraceable off-line cash in wallet with observers. In Douglas R. Stinson,
editor, Crypto 93, volume 773 of LNCS, pages 302–318. SV, 1993.
11. Brassard and Crepeau. Non-transitive transfer of confidence: A perfect zeroknowledge
interactive protocol for SAT and beyond. In FOCS: IEEE Symposium
on Foundations of Computer Science (FOCS), 1986.
12. G. Brassard, D. Chaum, and C. Cr´epeau. Minimum disclosure proofs of knowledge.
Journal of Computer and System Sciences, 37:156–189, 1988.
13. E. Brickell, P. Gemmell, and D. Kravitz. Trustee-based tracing extensions to
anonymous cash and the making of anonymous change. In Proceedings of the
Sixth Annual ACM-SIAM Symposium on Discrete Algorithms (SODA’95), pages
457–466. Sandia National Labs, January 1995.
14. Report by the Committee on Payment, Settlement Systems, and the Group of
Computer Experts of the central banks of the Group of Ten countries. Security
of electronic money. Publication of the Bank for International Settlements, Basle,
August 1996. http://www.bis.org/publ/index.htm.
15. J. Camenisch, U. Maurer, and M. Stadler. Digital payment systems with passive
anonymity-revoking trustees. Lecture Notes in Computer Science, 1146:33–, 1996.
16. J. Camenisch, J. Piveteau, and M. Stadler. Fair blind signatures. In L. Guilloy
and J-J. Quisquater, editors, EuroCrypt 95, LNCS, pages 209–219. SV, 1995.
Auditable, Anonymous Electronic Cash 571
17. J. Camenisch, J. Piveteau, and M. Stadler. An efficient fair payment system. In
Clifford Neuman, editor, 3rd ACM Conference on Computer and Communications
Security, pages 88–94, New Delhi, India, March 1996. ACM Press.
18. G. Davida, Y. Frankel, Y. Tsiounis, and Moti Yung. Anonymity control in E-cash
systems. In Rafael Hirschfeld, editor, Financial Cryptography: First International
Conference, FC ’97, volume 1318 of Lecture Notes in Computer Science, pages
1–16, Anguilla, British West Indies, 24–28 February 1997. Springer-Verlag.
19. E. Fujisaki and T. Okamoto. Practical escrow cash system. Lecture Notes in
Computer Science, 1189:33–??, 1997.
20. General Accounting Office (GAO). Private banking: Raul Salinas,
Citibank, and alleged money laundering. GAO/OSI-99-1, December 1998.
http://www.gao.gov/monthly.list/dec98/dec9811.htm.
21. O. Goldreich, S. Micali, and A. Wigderson. Proofs that yield nothing but their
validity or all languages in NP have zero-knowledge proof systems. Journal of the
ACM, 38(3):691–729, July 1991.
22. Oded Goldreich, Silvio Micali, and Avi Wigderson. How to prove all NP statements
in zero-knowledge and a methodology of cryptographic protocol design (extended
abstract). In A. M. Odlyzko, editor, Advances in Cryptology—CRYPTO ’86, volume
263 of Lecture Notes in Computer Science, pages 171–185. Springer-Verlag,
1987, 11–15 August 1986.
23. Shafi Goldwasser, Silvio Micali, and Charles Rackoff. The knowledge complexity of
interactive proof systems. SIAM Journal on Computing, 18(1):186–208, February
1989.
24. Stuart Haber and W. Scott Stornetta. How to time-stamp a digital document.
Journal of Cryptology, 3(2):99–111, 1991.
25. M. Jakobsson and J. Muller. Improved magic ink signatures using hints. In proceedings
of Financial Cryptography ‘99. Forthcoming volume in Lecture Notes in
Computer Science, 1999.
26. M. Jakobsson and M. Yung. Revokable and versatile electronic mony. In Clifford
Neuman, editor, 3rd ACM Conference on Computer and Communications Security,
pages 76–87, New Delhi, India, March 1996. ACM Press.
27. R. Merkle. Protocols for public key cryptosystems. In IEEE, editor, Proceedings
of the 1980 Symposium on Security and Privacy, April 14–16, 1980 Oakland, California,
1109 Spring Street, Suite 300, Silver Spring, MD 20910, USA, 1980. IEEE
Computer Society Press.
28. D. M’Raihi. Cost-effective payment schemes with privacy regulation. In
Kwangjo Kim and Tsutomu Matsumoto, editors, Advances in Cryptology—
ASIACRYPT ’96, volume 1163 of Lecture Notes in Computer Science, pages 266–
275, Kyongju, Korea, 3–7 November 1996. Springer-Verlag.
29. M. Naor, R. Ostrovsky, Venkatesan, and M. Yung. Perfect zero-knowledge arguments
for NP using any one-way permutation. Journal of Cryptology, 11, 1998.
30. K. Nyberg. Fast accumulated hashing. In Dieter Grollman, editor, Fast Software
Encryption: Third International Workshop, volume 1039 of Lecture Notes in Computer
Science, pages 83–87, Cambridge, UK, 21–23 February 1996. Springer-Verlag.
31. Report of the working party on electronic money of the Group of Ten countries.
Electronic money - consumer protection, law enforcement, supervisory and cross
border issues. Publication of the Bank for International Settlements, Basle, April
1997. http://www.bis.org/publ/index.htm.
32. Basle Committee on Banking Supervision. Core principles for effective banking supervision.
Publication of the Bank for International Settlements, Basle, September
1997. http://www.bis.org/publ/index.htm.
572 T. Sander, A. Ta–Shma
33. Basle Committee on Banking Supervision. Risk management for electronic banking
and electronic money activities. Publication of the Bank for International
Settlements, Basle, March 1998. http://www.bis.org/publ/index.htm.
34. H. Peterson and G. Poupard. Efficient scalable fair cash with off-line extortion
prevention. Lecture Notes in Computer Science, 1334:463–??, 1997.
35. T. Sander. Efficient accumulators without trapdoor. Manuscript, 1999.
36. T. Sander and A. Ta-Shma. Flow control: A new approach for anonymity control in
electronic cash systems. In proceedings of Financial Cryptography ‘99. Forthcoming
volume in Lecture Notes in Computer Science, 1999.
37. Daniel R. Simon. Anonymous communication and anonymous cash. In Neal
Koblitz, editor, Advances in Cryptology—CRYPTO ’96, volume 1109 of Lecture
Notes in Computer Science, pages 61–73. Springer-Verlag, 18–22 August 1996.
38. S. von Solms and D. Naccache. On blind signatures and perfect crimes. Computers
and Security, 11(6):581–583, October 1992.