HAL Id: hal-01337410https://hal.archives-ouvertes.fr/hal-01337410

Submitted on 25 Jun 2016

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

Formal Analysis of E-Cash ProtocolsJannik Dreier, Ali Kassem, Pascal Lafourcade

To cite this version:Jannik Dreier, Ali Kassem, Pascal Lafourcade. Formal Analysis of E-Cash Protocols. 12th Inter-national Conference on Security and Cryptography (SECRYPT 2015), Jul 2015, Colmar, France.�10.5220/0005544500650075�. �hal-01337410�

Formal Analysis of E-Cash Protocols∗

Jannik Dreier1, Ali Kassem2 Pascal Lafourcade31Institute of Information Security, Department of Computer Science, ETH Zurich, Switzerland

2 University Grenoble Alpes, VERIMAG, Grenoble, France3University Clermont Auvergne, LIMOS, France

Keywords:E-Cash, Formal Analysis, Double Spending, Exculpability, Privacy, Applied π-Calculus, ProVerif.

Abstract:Electronic cash (e-cash) aims at achieving client privacy at payment, similar to real cash. Severalsecurity protocols have been proposed to ensure privacy in e-cash, as well as the necessary unforgeryproperties. In this paper, we propose a formal framework to define, analyze, and verify securityproperties of e-cash systems. To this end, we model e-cash systems in the applied π-calculus,and we define two client privacy properties and three properties to prevent forgery. Finally, weapply our definitions to an e-cash protocol from the literature proposed by Chaum et al., whichhas two variants and a real implementation based on it. Using ProVerif, we demonstrate that ourframework is suitable for an automated analysis of this protocol.

1 Introduction

Although current banking and electronic pay-ment systems such as credit cards or, e.g., Pay-Pal allow clients to transfer money around theworld in a fraction of a second, they do not fullyensure the clients’ privacy. In such systems, notransaction can be made in a completely anony-mous way, since the bank or the payment providerknows the details of the clients’ transactions. Byanalyzing a client payments for, e.g., transporta-tions, hotels, restaurants, movies, clothes, and soon, the payment provider can typically deducethe client’s whereabouts, and much informationabout his lifestyle.

Physical cash provides better privacy: thepayments are difficult to trace as there is nocentral authority that monitors all transactions,in contrast to most electronic payment systems.This property is the inspiration for “untraceable”e-cash systems. The first such e-cash systempreserving the client’s anonymity was presentedby David Chaum in 1983 (Cha83): a client canwithdraw a coin anonymously from his bank andspend it with a seller. The seller can then depositthe coin at the bank, who will credit his account.

∗This research was conducted with the support ofthe “Digital trust” Chair from the University of Au-vergne Foundation.

In this protocol coins are non-transferable, i.e.,the seller cannot spend a received coin again, buthas to deposit it at the bank. If he wants tospend a coin in another shop, he has to withdrawa new coin from his account, similar to the usualpayment using cheques. In contrast, there areprotocols where coins are also transferable, i.e.,coins do not need to be deposited directly aftereach spend, but can be used again, e.g., (OO89;CGT08).

To be secure, an e-cash protocol should notonly ensure the client’s privacy, but must also en-sure that a client cannot forge coins which werenot issued by the bank. Moreover, it must pro-tect against double spending – otherwise a clientcould try to use the same coin multiple times.This can be achieved by using on-line payments,i.e., a seller has to contact the bank at paymentbefore accepting the coin, however it is an expen-sive solution. An alternative solution, which isusually used to support off-line payments (i.e., aseller can accept the payment without contactingthe bank), is revealing the client’s identity if hespent a coin twice. Finally, exculpability ensuresthat an attacker cannot forge a double spend, andhence incorrectly blame an honest client for dou-ble spending.

In the literature, many e-cash protocols havebeen proposed (Cha83; CFN90; Dam90; DC94;

Cre94; Bra94; AF96; KO01; FHY13). For ex-ample, Abe et al. (AF96) introduced a schemebased on partial blind signature, which allows thesigner (the bank) to include certain informationin the blind signature of the coin, for example theexpiration date or the value of the coin. Kim etal. (KO01) propose an e-cash system that sup-ports coin refund and assigns them a value, basedagain on partial blind signature.

At the same time, many attacks have beenfound against various existing e-cash protocols:for example Pfitzmann et al. (PW91; PSW95)break the anonymity of (Dam90; DC94; Cre94).Cheng et al. (CYS05) show that Brand’s proto-col (Bra94) allows a client to spend a coin morethan once without being identified. Aboud etal. (AA14) show that (FHY13) cannot ensurethe anonymity and unlinkability properties thatwere claimed.

These numerous attacks triggered some firstwork on formal analysis of e-cash protocolsin the computational (CG08) and symbolicworld (LCPD07; SK14). Canard et al. (CG08)provide formal definitions for various privacy andunforgeability properties in the computationalworld, but only with manual proofs as theirframework is difficult to automate. In contrast,Luo et al. (LCPD07) and Thandar et al. (SK14)both rely on automatic tools (AVISPA2 andProVerif (Bla01), respectively). Yet, they onlyconsider a fraction of the essential security prop-erties, and for some properties Thandar et al. onlyperform a manual analysis. Moreover, much oftheir reasoning is targeted on their respective casestudies, and cannot easily be transferred to otherprotocols.

Contributions: This paper fills the gaps ofprevious formal verification work. Inspiredby other domains such as e-voting (BHM08;DKR09; DLL12), e-auctions (DLL13), and e-exams (DGK+14), we propose a more generalformalization for non-transferable e-cash proto-cols in the applied π-calculus (AF01). Our def-initions are amenable to automatic verificationusing ProVerif (Bla01), and cover all crucial pri-vacy and unforgery properties: Weak Anonymity,Strong Anonymity, Unforgeability, Double Spend-ing Identification, and Exculpability. Finally, wevalidate our approach by analyzing the on-lineprotocol proposed by Chaum et al. (Cha83),as well as, a real implementation based on

2www.avispa-project.org

it (Sch97). We also analyze the off-line variantof this e-cash system (CFN90).

Outline: In Section 2, we model e-cash proto-cols in the applied pi-calculus. Then, we spec-ify the security properties in Section 3. We vali-date our framework by analyzing the on-line andoff-line e-cash systems by Chaum et al. (Cha83;CFN90), and the implementation based on theon-line protocol (Sch97) in Section 4. In Sec-tion 5, we discuss our results and outline futurework.

2 Modeling E-cash Protocols

We model e-cash protocols in the applied π-calculus, a process calculus designed for the verifi-cation of cryptographic protocols. We refer to theoriginal paper (AF01) for a detailed descriptionof its syntax and semantics.

In the applied π-calculus, we have a Dolev-Yaostyle attacker (DY83), which has a complete con-trol to the network, except the private channels.He can eavesdrop, remove, substitute, duplicateand delay messages that the parties are sendingto one another, and even insert messages of hischoice on the public channels.

Parties other than the attacker can be eitherhonest or corrupted. Honest parties follow theprotocol’s specification, do not reveal their secretdata (e.g., account numbers, keys etc.) to the at-tacker, and do not take malicious actions such asdouble spending a coin or generating fake trans-actions. Honest parties are modeled as processesin the applied π-calculus. These processes canexchange messages on public or private channels,create fresh random values and perform tests andcryptographic operations, which are modeled asfunctions on terms with respect to an equationaltheory describing their properties.

Corrupted parties are those that collude withthe attacker by revealing their secret data to him,taking orders from him, and also making mali-cious actions. We model corrupted parties as inDefinition 15 from (DKR09): if the process P isan honest party, then the process P c is its cor-rupted version. This is a variant of P whichshares with the attacker channels ch1 and ch2.Through ch1, P c sends all its inputs and freshlygenerated names (but not other channel names).From ch2, P c receives messages that can influenceits behavior.

2

An e-cash system involves the following par-ties: the client C who has an account at the bank,the seller S who accepts electronic coins, and thebank B, which certifies the electronic coins. E-cash protocols typically run in three phases:

1. Withdrawal: the client withdraws an elec-tronic coin from the bank, which debits theclient’s account.

2. Payment: the client spends the coin by exe-cuting a transaction with a seller.

3. Deposit: the seller deposits the transactionat the bank, which credits the seller’s account.

In addition to these three main phases, some sys-tems allow the clients

(a) to return coins directly to the bank withoutusing them in a payment, for instance in caseof expiration, or to re-distribute the coins de-nominations, and

(b) to restore coins that have been lost, for in-stance due to a hard disk crash.

As these functionalities are not implemented byall protocols, our model does not require them.Moreover, we assume that the coins are neithertransferable nor divisible.

We define an e-cash protocol as a tuple ofprocesses each representing the role of a certainparty.

Definition 1 (E-cash protocol). An e-cashprotocol is a tuple (B,S,C, n), where B is theprocess executed by the bank, S is the process ex-ecuted by the sellers, C is the process executed bythe clients, and n is the set of the private channelnames used by the protocol.

To reason about privacy properties we use runsof the protocol, called e-cash instances.

Definition 2 (E-cash instance). Given an e-cash protocol, an e-cash instance is a closed plainprocess:

CP =νn′.(B|Sσids1 | . . . |Sσidsl |(Cσidc1σc11σids11 | . . . |Cσidc1σc1p1σids1p1 )|

...

|(Cσidckσck1σidsk1

| . . . |Cσidckσckpkσidskpk

))

where n′ is the set of all restricted names whichincludes the set of the protocol’s private channelsn; B is the process executed by the bank; Sσidsi isthe process executed by the seller whose identity isspecified by the substitution σidsi ; Cσidciσcijσidsij

is the process executed by the client whose identityis specified by the substitution σidci , and whichspends the coin identified by the substitution σcijto pay the seller with the identity specified by thesubstitution σidsij . Note that idci can spend picoins.

To improve the readability of our definitions,we introduce the notation of context CPI [ ]to denote the process CP with “holes” forall processes executed by the parties whoseidentities are included in the set I. For ex-ample, to enumerate all the sessions executedby the Client idc1 without repeating theentire e-cash instance, we can rewrite CP asCP{idc1}[Cσidc1σc11σids11 | . . . |Cσidc1σc1p1σids1p1 ].

Finally, we use the notation Cw to denote aclient that withdraws a coin, but does not spendit in a payment: Cw is a variant of the process Cthat halts at the end of withdrawal phase, i.e.,where the code corresponding to the paymentphase is removed.

3 Security Properties

We define three properties related to forgery:Unforgeability, Double Spending Identification,and Exculpability. Moreover, we formalize twoprivacy properties: Weak Anonymity and StrongAnonymity.

3.1 Forgery-Related Properties

In an e-cash protocol a client must not be able tocreate a coin without involving the bank, result-ing in a fake coin, or to double spend a valid coinhe withdrew from the Bank. This is ensured byUnforgeability, which says that the clients cannotspend more coins than they withdrew.

To define unforgeability we use the followingtwo events:

• withdraw(c): is an event emitted when thecoin c is withdrawn. This event is placed in-side the bank process just after the bank out-puts the coin’s certificate (e.g., a signature onthe coin).

• spend(c): is an event emitted when the coin cis spent. This event is placed inside the sellerprocess just after he receives and accepts thecoin.

Events are annotations that mark importantsteps in the protocol execution, but do otherwisenot change the behavior of processes.

3

Definition 3 (Unforgeability) An e-cash pro-tocol ensures Unforgeability if, for every e-cash instance CP, each occurrence of the eventspend(c) is preceded by a distinct occurrence ofthe event withdraw(c) on every execution trace.

If a fake coin is successfully spent, the event spendwill be emitted without any matching event with-draw, violating the property. Similarly, in thecase of a successful double spending the eventspend will be emitted twice, but these eventsare preceded by only one occurrence of the eventwithdraw.

In the rest of the paper, we illustrate all ournotions with the ”real cash” system (mainly coinsand banknotes) as a running example. We hopethat it helps the reader to understand the prop-erties but also to feel the difference between realcash and e-cash systems.

Example 1 (Real cash) In real cash, unforge-ability is ensured by physical measures that makeforging or copying coins and banknotes difficult,for example by adding serial numbers, using spe-cial paper, ultraviolet ink, holograms and so on.

Since a malicious client might be interested tocreate fake coins or double spend a coin, it is par-ticularly interesting to study Unforgeability withan honest bank and corrupted clients. A partiallycorrupted seller, which e.g., gives some informa-tion to the attacker but still emits the event spendcorrectly, could also be considered to check if aseller colluding with the client and the attackercan results in a coin forging. Note that if theseller is totally corrupted then Unforgeability willbe trivially violated, since a corrupted seller cansimply emit the event spend for a forged coin,although there was no transaction.

In case of double spending, the bank shouldbe able to identify the responsible client. This isensured by Double Spending Identification, whichsays that a client cannot double spend a coinwithout revealing his identity.

To deposit a coin at the bank the seller has topresent a transaction which contains, in additionto the coin, some information certifying that hereceived the coin in a payment. A valid transac-tion is a transaction which could be accepted bythe bank, i.e., it contains a correct proof that thecoin is received in a correct payment. The bankaccepts a valid transaction if it does not containa coin that is already deposited using the same ora different transaction.

In the following, we denote by TR the set of alltransactions, and we define the function transId

which takes a transaction tr ∈ TR and returnsa pair (s, c), where s identifies tr and c is thecoin involved in tr. Such a pair can usually becomputed from a transaction. We also denoteby ID the set of all client identities, and by D aspecial data set that includes the data known tothe bank after the protocol execution, e.g., thedata presents in the bank’s database.

Definition 4 (Double Spending Identification)

An e-cash protocol ensures Double Spend-ing Identification if there exists a testTDSI : TR × TR × D 7→ ID ∪ {⊥} satis-fying: for any two valid transactions tr1and tr2 that are different but involve thesame coin ( i.e., transId(tr1) = (s1, c),and transId(tr2) = (s2, c) for some coin cwith s1 6= s2), there exists p ∈ D such thatTDSI(tr1, tr2, p) outputs (idc, e) ∈ ID× D, where eis an evidence that idc withdrew the coin c.

Double Spending Identification allows thebank to identify the double spender by runninga test TDSI on two different transactions that in-volves the same coin. For example, consider aprotocol where after a successful transaction theseller gets x = m.id + r where id is the identityof the client (e.g., his secret key), r is a randomvalue (identifies the coin) chosen by the client atwithdrawal, and m is the challenge of the seller.So, if the client double spends the same coin thenthe bank can compute id and r using the twoequations: x1 = m1.id + r and x2 = m2.id + r.The data p could be some information necessaryto identify the double spender or to construct theevidence e. This data is usually presented to thebank at withdrawal or at deposit. The requiredevidence depends on the protocol. Note that e isan evidence from the point of view of the bank,and not necessarily a proof for an outer judge.Thus, the goal of Double Spending Identificationis to preserve the security of the bank so that hecan detect and identify the responsible of dou-ble spending when happens. Note that, if a clientwithdraws a coin and gives it to an attacker whichdouble spends it, then the test returns the iden-tity of the client and not the attacker’s identity.

Example 2 (Real cash) In real cash, doublespending is prevented by ensuring that notes can-not be copied. However, Double Spending Identi-fication is not ensured: even if a central bank isable to identify copied banknotes using, e.g., theirserial numbers, this does not allow it to identifythe person responsible for creating the counterfeitnotes.

4

Double Spending Identification gives rise to apotential problem: what if the client is honestand spends the coin only once, but the attacker(e.g., a corrupted seller) is able to forge a sec-ond spend, or what if a corrupted bank is able tosimulate a coin withdrawal and payment i.e., toforge a coin withdrawal and payment that seemsto be made by a certain client. For instance, inthe example mentioned above, the two equationsare enough evidence for the bank. However, if thebank knows id he can generate the two equationshimself and blame the client for double spending.So, to convince a judge, an additional evidence isneeded, e.g., the client’s signature.

If any of the two situations mentioned aboveis possible, then a honest client could be falselyblamed for double spending, and also it gives raiseto a corrupted client which is responsible of dou-ble spending to deny it. To solve this problem wedefine Exculpability, which says that the attacker,even when colluding with the bank and the seller,cannot forge a double spend by a certain clientin order to blame him. More precisely, provideda transaction executed by a client idc, the at-tacker cannot provide two different valid transac-tions which involves the same coin, and the datap necessary for the test TDSI to output the iden-tity idc with an evidence. Note that Exculpabilityis only relevant if Double Spending Identificationholds: otherwise a client cannot be blamed re-gardless of the ability to forge a second spend orto simulate a coin withdrawal and payment, ashis identity cannot be revealed.

Definition 5 (Exculpability) Assume that wehave a test TDSI as specified in Def. 4, i.e., DoubleSpending Identification holds, and that the bankis corrupted. Let idc be a honest client (in par-ticular he does not double spend a coin), and idsbe a corrupted seller. Then, Exculpability is en-sured if, after observing a transaction made byidc with ids, the attacker cannot provide two validtransactions tr1, tr2 ∈ T that are different but in-volve the same coin c, and some data p such thatTDSI(tr1, tr2, p) outputs (idc, e) where e is an evi-dence that idc withdrew the coin c.

The intuition is: if the attacker can provide twotransactions tr1, tr2 such that TDSI(tr1, tr2) re-turns a client’s identity (that is, the two differentvalid transactions involve same coin), then it wasable to forge (at least) one transaction since thehonest client performs (at most) one transactionper coin.

If after observing a transaction executed bya client idc, the attacker can provide a different

valid transaction which involves the same coin,and the required data p, then the test will re-turn the identity idc with the necessary evidence,thus the property will be violated. Similarly, inthe case where the attacker can forge a coin with-drawal and payment seems to be made by a clientidc, then the attacker can obtain to transactionssatisfying the required conditions, together withthe necessary data p, so that the test will returnthe identity idc with an evidence.

Note that, Double Spending Identification andExculpability are only relevant in case of off-linee-cash systems where double spending might bepossible.

Example 3 (Real cash) As Double SpendingIdentification is not ensured in real cash, excul-pability is not relevant: any client that posses acounterfeit banknote can plausibly deny that heproduced this note.

3.2 Privacy Properties

We express our privacy properties as observa-tional equivalence, a standard choice for suchkind of properties. We use the labeled bisimilar-ity (≈l) to express the equivalence between twoprocesses (AF01). Informally, two processes areequivalent if an attacker interacting with themobserver has no way to tell them apart.

To ensure the privacy of the client, the follow-ing two notions have been introduced by cryp-tographers and are standard in the literaturee.g., (CG08; Fer94; Sch97).

1. Weak Anonymity : the attacker cannot link aclient to a spend, i.e., he cannot distinguishwhich client makes the payment.

2. Strong Anonymity : additionally to weakanonymity, the attacker should not be able todecide if two spends were done by the sameclient, or not.

In (CG08), Weak Anonymity is defined as the fol-lowing game: two honest clients each withdraw acoin from the bank. Then one of them (randomlychosen) spends his coin to the adversary. The ad-versary already knows the identities of these twoclients, and also the secret key of the bank. Itwins the game if it guesses correctly which clientspends the coin. Inspired by this definition, wedefine Weak Anonymity in the applied π-calculusas follows:

Definition 6 (Weak Anonymity) An e-cashprotocol ensures Weak Anonymity if for anye-cash instance CP, any two honest Clients idc1,

5

idc2, any corrupted Seller ids, we have that:CPI [Cσidc1σc1σids|Cwσidc2σc2 |Scσids|Bc] ≈l

CPI [Cwσidc1σc1 |Cσidc2σc2σids|Scσids|Bc], wherec1, c2 are any two coins (not previously knownto the attacker) withdrawn by idc1 and idc2respectively, I = {idc1, idc2, ids, idB}, idB is thebank’s identity, and Cw is a variant of C thathalts at the end of the withdrawal phase.

Weak anonymity ensures that a process in whichthe client idc1 spends the coin c1 to the corruptedseller ids1, is equivalent to a process in which theclient idc2 spends the coin c2 to the corruptedseller ids1. We assume a corrupted bank repre-sented by Bc. Note that the client that does notspend his coin still withdraws it. This is neces-sary since otherwise the attacker could likely dis-tinguish both sides during the withdrawal phase,as the bank is corrupted and typically the clientreveals his identity to the bank at withdrawal sothat his account can be charged. We also notethat we do not necessarily consider other cor-rupted clients, however this can easily be doneby replacing some honest clients from the con-text CPI (i.e., other than idc1 and idc2) withcorrupted ones.

Example 4 (Real cash) Real coins ensureweak anonymity as two coins (assuming thesame value and production year) are indistin-guishable. However, banknotes do not ensureweak anonymity according to our definition,as they include serial numbers. Since the twoclients withdraw a note each, the notes hencehave different serial numbers which the bank canidentify. In reality this is used by central banksto trace notes and detect suspicious activitiesthat, e.g., could hint at money laundering. Notehowever that banknotes ensure a weaker form ofanonymity: if two different clients use the samenote, one cannot distinguish them.

Strong Anonymity is defined in (CG08) usingthe same game as for Weak Anonymity, with thedifference that the adversary may have previouslyseen some coins being spent by the two honestclients explicitly mentioned in the definition. Wedefine Strong Anonymity as follows:

Definition 7 (Strong Anonymity) An e-cashprotocol ensures Strong Anonymity if for any e-cash instance CP, any two honest clients idc1,

idc2, any corrupted seller ids, we have that:

CPI [|0≤i≤m1Cσidc1σci1σids|0≤i≤m2

Cσidc2σci2σids|Cσidc1σc1σids|Cwσidc2σc2 |Scσids|Bc] ≈l

CPI [|0≤i≤m1Cσidc1σci1σids|0≤i≤m2Cσidc2σci2σids|Cwσidc1σc1 |Cσidc2σc2σids|Scσids|Bc]

where c1 and c11 . . . cm11 are any coins withdrawn

by idc1, c2 and c12 . . . cm22 are any coins with-

drawn by idc2, I = {idc1, idc2, ids, idB}, idB isthe bank’s identity, and Cw is a variant of C thathalts at the end of the withdrawal phase.

Strong Anonymity ensures that the process inwhich the the client idc1 spends m1 + 1 coins,while idc2 spends m2 coins and additionally with-draws another coin without spending it, is equiva-lent to the process in which the client idc1 spendsm1 coins and withdraws an additional coin, whileidc2 spends m2 + 1 coins. The definition assumesthat the bank is corrupted, and that the sellerreceiving the coins from the two clients idc1 andidc2 is also corrupted. Note that, we consider Cw

to avoid distinguishing from the number of with-drawals by each client.

Again, we can replace some honest clientsfrom CPI by corrupted ones.

Example 5 (Real cash) Again, real coins en-sure strong anonymity as, assuming the samevalue and production year, two coins are indis-tinguishable. Yet, for the same reason as inweak anonymity, banknotes do not ensure stronganonymity according to our definition: the serialnumbers allow an attacker to identify the differentclients.

We note that any protocol satisfying StrongAnonymity also satisfies Weak Anonymity, asWeak Anonymity is a special case of StrongAnonymity for m1 = m2 = 0, i.e. when the twohonest clients do not make any previous spends.

4 Case Study: Chaum’s Protocol

David Chaum proposed the first (on-line) e-cash system in (Cha83) based on blind signatures,and an off-line variant of the protocol is proposedin (CFN90). A real implementation based onthese two variants, allowing users to make pur-chases over open networks such as the Internet,was put in service by DigiCash Inc. The corpora-tion declared bankruptcy in 1998, and was sold toBlucora3 (formerly Infospace Inc.). The on-line

3http://www.blucora.com/

6

protocol implemented by DigiCash is presentedin (Sch97).

In the following, we describe and analyze boththe on-line and the off-line variants of the proto-col, as well as, the on-line protocol implementedby DigiCash. For this we use ProVerif an auto-matic tool that verifies cryptographic protocols.All the verification presented in the paper are car-ried out on a standard PC (Intel(R) Pentium(R)D CPU 3.00GHz, 2GB RAM).

4.1 Chaum’s On-line Protocol

The Chaum On-line Protocol was proposedin (Cha83) and detailed in (CFN90). It allows aclient to withdraw a coin blindly from the bank,and then spend it later in a payment without be-ing traced even by the bank. The protocol is “on-line” in the sense that the seller does not acceptthe payment before contacting the bank to verifythat the coin has not been deposited before, toprevent double spending. We start by giving adescription of the protocol.

Withdrawal Phase: To obtain an electroniccoin, the client communicates with the bank usingthe following protocol:

1. The client randomly chooses a value x, and acoefficient r, the client then sends to the bankhis identity u and the value b = blind(x, r),where blind is a blinding function.

2. The bank signs the blinded value b using asigning function sign and his secret key skB,then sends the signature bs = sign(b, skB) tothe client. The bank also debits the amountof the coin from the client’s account.

3. The client verifies the signature and removesthe blinding to obtain the bank’s signatures = sign(x, skB) on x. The coin consists ofthe pair (x, sign(x, skB)).

Payment (and deposit) Phases: To spendthe coin

1. The client sends the pair (x, sign(x, skB)) tothe seller.

2. After checking the bank’s signature, the sellersends the coin (x, sign(x, skB)) to the bankto verify that it is not deposited before.

3. The bank verifies the signature s, and thatthe coin is not in the list of deposited coins.If these checks succeed the bank credits theseller’s account with the amount of the coin

and informs him of acceptance. Otherwise,the payment is rejected.

Modeling in ProVerif We use ProVerif toperform the automatic protocol verification.ProVerif uses a process description based on theapplied π-Calculus, but has syntactical exten-sions and is enriched by events to check reach-ability and correspondence properties. Besides,it can check equivalence properties. As explainedabove, we model privacy properties as equivalenceproperties, and we use events to verify the otherproperties.

The equational theory depicted in Table 1models the cryptographic primitives used withinChaum on-line protocol. It includes well-known model for digital signature (functionssign, getmess, and checksign). The functionsblind/unblind are used to blind/unblind a mes-sage using a random value. We also include thepossibility of unblinding a signed blinded mes-sage, so that we obtain the signature of the mes-sage – the key feature of blind signatures.

getmess(sign(m, k)) = m

checksign(sign(m, k), pk(k)) = m

unblind(blind(m, r), r) = m

unblind(sign(blind(m, r), k), r) = sign(m, k)

Table 1: Equational theory

Analysis The result of the analysis is summa-rized in Table 2.

We model Unforgeability as an injective corre-spondence between the two events withdraw andspend, they are placed in their appropriate posi-tion, according to the Def. 3, inside the bank andseller processes respectively. We consider a hon-est bank and honest seller but corrupted client.We assume that the bank sends an authenticatedmessage through private channel to inform theseller about a coin acceptance. Otherwise, the at-tacker can forge a message which leads the sellerto accepting an already deposited coin. However,ProVerif still finds an attack against Unforgeabil-ity when two copies of the same coin spent atthe same time. In this case the bank makes twoparallel database lookups to check if the coin wasdeposited before. If the parallel deposit was notfinished yet and thus the coin is not yet insertedin the database, then each lookup confirms thatthe coin was not deposited before which results inacceptance of two spends of the same coin. Thisattack may be avoided with some synchronization

7

Property Result Time

Unforgeability × < 1s

Weak Anonymity X < 1s

Strong Anonymity X < 1s

Table 2: Analysis of the Chaum on-line protocol.A X indicates that the property holds. A × indi-cates that it fails (ProVerif shows an attack).

like locking the table when a coin deposit is ini-tiated and then unlocking it when the operationis finished. ProVerif does not support such anfeature. Protocols that rely on state could be an-alyzed using the Tamarin Prover4 thanks to theSAPIC5 tool (we keep this for future work.).

Note that corrupted clients cannot create afake coin as the correspondence holds without in-jectivity.

Double Spending Identification and Exculpa-bility are not relevant in the case of on-line pro-tocols as their countermeasure against doublespending is the on-line calling of the bank at pay-ment, and thus they do not have any kind of testto identify double spenders.

For privacy properties, we assume a corruptedbank and a corrupted seller, but honest clients.ProVerif confirms that the privacy of the client ispreserved, as both Weak Anonymity, and StrongAnonymity are satisfied. This due to the fact thatthe coin is signed blindly during the withdrawalphase, and thus cannot be traced later by theattacker even when colludes with the bank andthe seller. Note that, for Strong Anonymity, weconsider an unbounded number of spends by eachclient and one spend that is made by either thefirst client or by the second one.

4.2 DigiCash On-line Protocol

The on-line protocol implemented by DigiCashInc. is outlined in (Sch97). It has the same with-drawal phase as Chaum on-line protocol, exceptthat the client sends an authenticated coin to besigned by the bank, however the paper does notspecify the way of authentication. We ignore thisauthentication as its purpose is to ensure that thebank debits the correct client account. Hence, webelieve that it does not effect the privacy and un-forgeability properties (analysis confirms that aswe can see in Table 2). The payment and deposit

4http://www.infsec.ethz.ch/research/software/tamarin.html

5http://sapic.gforge.inria.fr/

Property Result Time

Unforgeability × < 1s

Weak Anonymity X < 1s

Strong Anonymity X < 1s

Table 3: Analysis of DigiCash on-line protocol.A X indicates that the property holds. A × indi-cates that it fails (ProVerif shows an attack).

phases are different from those of Chaum on-lineprotocol. They are summarized as follows:

Payment (and deposit) Phases in DigiCash:

1. The client sends to the seller pay =enc((ids, h(pay-spec), x, sign(x, skB)), pkB)which is the encryption, using the public keyof the bank pkB , of the seller’s identity ids,hash of the payment specification pay-spec(specification of the sold object, price etc),and the coin (x, sign(x, skB)).

2. The seller signs (h(pay-spec), pay) and sendsit along with his identity ids to the bank.

3. The bank verifies the signature, decrypts paythen verifies the value of h(pay-spec) and thatthe coin is valid and not deposited before. Ifso it informs the seller to accept the coin, andto reject it otherwise.

Modeling in ProVerif Additionally to theequational theory of the Chaum on-line protocol(Table 1), the equational theory of DigiCash on-line protocol includes well-known model of thepublic key encryption represented by the follow-ing equation: dec(enc(m, pk(k)), k) = m.

Analysis The result of analysis of DigiCash on-line protocol using ProVerif is summarized in Ta-ble 3. ProVerif shows the same results as obtainedfor Chaum on-line protocol. Namely, it showsthat Weak Anonymity, and Strong Anonymityare satisfied, and it outputs the same attackpresented in Section 4.1 against Unforgeability.Again Double Spending Identification and Excul-pability are not relevant.

Note that, obtaining the same result for thetwo protocols, even that they have different pay-ment and deposit phases, confirms that the blind-ing signature used during the withdrawal phaseplays the key role in preserving the privacy of theclient, as claimed by David Chaum.

8

4.3 Chaum’s Off-line Protocol

The off-line variant of the Chaum protocol is pro-posed in (CFN90). It removes the requirementthat the seller must contact the bank during ev-ery payment. This introduces the risk of doublespending a coin by a client.

Withdrawal Phase: to obtain an electroniccoin, the client randomly chooses a, c and d,and calculates the pair H = (h(a, c), h(a⊕ u, d)),where u is the client identity and h is a hash func-tion. The client then proceed as in the Chaumon-line protocol but with x (the potential coin)replaced by the pair H. Namely, the client blindsthe pair H and sends it to the bank. Then thebank signs and returns it to the client. The maindifference from the Chaum on-line protocol is thatthe coin has to be of the following form

(h(a, c), h(a⊕ u, d))

where the client identity is masked inside it. Thisaims to reveal the identity if the client later dou-ble spends the coin. In order for the bank to besure that the client provides a message of the ap-propriate form, Chaum et al. used in (CFN90)the well known “cut-and-choose” technique. Pre-cisely, the client computes n such a pair H wheren is the system security parameter. The bankthen selects half of them and asks the client toreveal their corresponding parameters (a, b, c andr). If n is large enough the client can cheats witha low probability.

At the end of this phase the client holds theelectronic coin composed of the pair H, and thebank’s signature S = sign(H, skB). The clientalso has to keep the random values a, c, d whichare used later to spend the coin.

Payment Phase:

1. To make the payment, the client presents thepair H and the bank’s signature S to theseller. The seller checks the signature, if it iscorrect then he chooses and sends a randombinary bit y, a challenge, to the client. Theclient returns to the seller:

• The values a and c if y is 0.

• The values a⊕ u and d if y is 1.

2. The seller checks the compliance of the valuessent with the pair H. If everything (the sig-nature and the values) is correct, the paymentis accepted.

At the end of the payment phase, the seller holdsthe pair H, the signature S, the values of either(a, c) or (a⊕ u, d), and the challenge y. All thesedata together compose the transaction the sellerhas to present to the bank at deposit.

Note, in case where n pairs are used for thecoin, the challenge y will be n bit string and foreach bit either the corresponding values of (a, c)or (a⊕ u, d) are revealed to the seller.

Deposit Phase:

1. The seller contacts the bank and provides itwith the transaction (H, S, y, (a, c)) or (H,S, y, (a⊕ u, d)).

2. The bank checks the signature and alsowhether the values (a, c) or (a ⊕ u, d) corre-spond to their hash value in H. If any of thesevalues is incorrect, the fault is on the seller’spart, as he was able to independently checkthe regularity of the coin at payment. If thecoin is correct, the bank checks its database tosee whether the same coin had been used be-fore. If it has not, the bank credits the seller’saccount with the appropriate amount. Other-wise, the bank rejects the transaction.

Chaum off-line protocol does not prevent doublespending, however it preserve client’s anonymityonly if he spend a coin once.

Note that, a double spender can be identifiedwhen the coin has the form (h(a, c), h(a ⊕ u, d)).However, the bank can simulate the coin with-drawal and payment (as the bank knows the iden-tities of all the clients), thus the bank can blamea honest client for double spending. As a coun-termeasure, the authors propose to concatenatetwo values z and z′ with u inside the pair H tohave (h(a, c), h(a ⊕ (u, z, z′), d)) and provide tothe bank, at withdrawal, additionally the client’ssignature on h(z, z′).

Modeling in ProVerif To mode the Chaumoff-line protocol in ProVerif, in addition to theequational theory used for the Chaum on-line pro-tocol (Table 1), we use the function xor to repre-sent the exclusive or (⊕) of two values. Given thefirst value, the second value can be obtained usingthe function unxor . Such an – admittedly limited– modeling for ⊕ operator is sufficient to catchthe functional properties of the scheme requiredby Chaum off-line protocol, but does not catchall algebraic properties of this operator. How-ever, there are currently no tools that supportobservational equivalence – which we need for the

9

anonymity properties – and all algebraic proper-ties of ⊕. Kuesters et al. (KT11) proposed a wayto extend ProVerif with ⊕. Their tool translatesa model of the protocol to a ProVerif input whereall ⊕ are ground terms to enable automated rea-soning. However, this tool can only deal with se-crecy and authentication properties, and does notsupport equivalence properties. The xor functionis only used to hide the client’s identity u us-ing a random value a (a ⊕ u), which we modelas xor(a, u). The bank then uses a to reveal theclient’s identity u if he double spends a coin. Thisis modeled by the following two equations

unxor(xor(a, u), a) = u

unxor(a, xor(a, u)) = u

which represents the various ways: ((a⊕u)⊕a) =u, or (a ⊕ (a ⊕ u)) = u. We always assume thatidentity is the second value, and this is how wemodel it inside honest processes.

Analysis As expected ProVerif confirms thatUnforgeability is not satisfied, a corrupted clientcan double spend a coin. In fact the seller cannotknow whether a certain coin is already spent ornot, he accepts any coin that is certified by thebank. However, a collusion between the clientand the attacker cannot lead to forging a coin.

In case of double spending, the bankmay receive two transactions of the formtr1 = (h, hx, sign((h, hx), skB), 0, a, c) and tr1 =(h, hx, sign((h, hx), skB), 1, xor(a, u), d). Thebank can apply a test to obtain the identityu. This is done using the unxor function asunxor(xor(a, u), a) = u. The evidence here isshowing that the identity of the client is maskedinside the coin. This can be done thanks tothe values of (a, c, xor(a, u), d) which are initiallyknown only to the client. Spending the coin onlyonce reveals either (a, c) or (xor(a, u), d) whichdoes not allow to obtain the identity u. Notethat, if the two sellers provide the same challenge,the two transactions will be exactly equal. Inthis case no double spending is detected, and thesecond transaction will be rejected by the bankwhich considers it as a second copy of the firsttransaction. In practice this can be avoided withhigh probability if n pairs coin is used and thusn bits challenge. Note that ProVerif consider allthe possibilities.

We model the output of an identity and an ev-idence of the test TDSI by an emission of the eventOK, and event KO otherwise. To say that DoubleSpending Identification is satisfied we should have

Property Result Time

Unforgeability × <1s

Double Spending Identif. × <2s

Double Spending Identif.∗ X <2s

Exculpability∗ × < 6s

Exculpability† X < 6s

Weak Anonymity X <1s

Strong Anonymity X <1s

Table 4: Analysis of Chaum off-line protocol.A X indicates that the property holds. A × indi-cates that it fails (ProVerif shows an attack).(∗) Only coins with the appropriate form are con-sidered. (†) After applying the countermeasure.

that the test TDSI does not emit the event KO forevery two valid transactions tr1, tr2 that are dif-ferent but involves the same coin, i.e., it alwaysemits event OK for such transactions. ProVerifshows that the test can emit the event KO forcertain two transactions satisfy the required con-ditions. Actually, a corrupted client can with-draw a coin that does not have the appropriateform (e.g., client’s identity is not masked insideit), thus the bank cannot obtain the identity incase of double spending. Note that, if the bankonly certifies coins with the appropriate form atwithdrawal (i.e., of the form (h(a, c), h(a⊕u, d))),then the property holds, ProVerif confirms that.Again, in practice applying the “cut-and-choose”technique can guarantee with high probabilitythat the coin is in the appropriate form. How-ever, applying this technique using Proverif doesnot make any difference since ProVerif works un-der symbolic world which deals with possibilitiesand not with probabilities. For instance, the at-tacker still can guess the pairs that the bank willrequest to reveal and construct them in the ap-propriate form, but cheat with the others whichwill compose the coin. We analyze Exculpabil-ity in case where only coins of appropriate formsare considered i.e., the case where Double Spend-ing Identification holds. ProVerif confirms that acorrupted bank can blame a honest client. Thebank can simulate the withdrawal and the pay-ment since the bank knows the identity of theclient. Thus it can obtain two transactions satis-fying the required conditions. This is due to thefact that the evidence obtained by the test, whichis showing that the client’s identity is masked in-side the coin, is not strong enough to act as aproof. However, the attacker cannot re-spend acoin withdrawn and spent by a honest client.

10

After applying the countermeasure that is in-cluding some terms z and z′ so that the clientsigns h(z, z′), ProVerif confirms that Exculpabilityholds. Applying the countermeasure results in anew test which takes, in addition to the two trans-actions, the client’s signature on h(z, z′). The testshows, in case of double spending, that the iden-tity u and the preimage (z, z′) of the hash signedby the client are masked inside the coin. This rep-resents a stronger evidence which acts as a proofthat the client withdrew the coin since the bankcannot forge the client’s signature.

We note that, Ogiela et al. (OS14) show an at-tack on Chaum’s off-line protocol: when a clientdouble spends a coin, the sellers can forge ad-ditional transactions involving the same coin, sothat the bank cannot know how many transac-tions are actually result from spends made bythe client and how many are forged by the sell-ers. In such a case, according to our definition,Unforgeability does not hold since the client hasto spend the coin at least twice. Yet, corruptedsellers can blame a corrupted client who doublespends a coin for further spends. Moreover thebank can still identify the client and punish himas the bank can be sure that he at least spend thecoin twice.

Concerning privacy properties, ProVerif showsthat Chaum off-line protocol still satisfies bothWeak Anonymity and Strong Anonymity.

To sum up, ProVerif confirms the claim aboutpreserving client’s anonymity. ProVerif also wasable to show that a client can double spend awithdrawn coin but cannot forge a coin, and thatthe bank can identify the double spender if thecoin is in the appropriate form. ProVerif alsoshows, in case of coin with appropriate form, thatthe bank can simulate a withdrawal and pay-ment, and thus can blame him for double spend-ing. After applying the countermeasure no attackagainst Exculpability is found.

5 Conclusion

E-cash protocols can offer anonymous elec-tronic payment services. Numerous protocolshave been proposed in the literature, and mul-tiple flaws were discovered. To avoid further badsurprises, formal verification can be used to im-prove confidence in e-cash protocols. In this pa-per we developed a formal framework to auto-matically verify e-cash protocols with respect tomultiple essential privacy and forgery properties.

Our framework relies on the applied π-calculusand uses ProVerif as the verification tool. As acase study, we analyzed the on-line protocol pro-posed by Chaum et al. , as well as, a real im-plementation based on it. We also analyze theoff-line variant of this system. We confirm someclaims and known weaknesses. We also identifiedthat some synchronization is necessary in case ofon-line protocols to prevent double spending.

As future work, we would like to investigatefurther case studies and to extend our model tocover transferable protocols with divisible coins.Also we would like to use the tool SAPIC basedon Tamarin, in order to see how it can help toanalyze e-cash protocols.

REFERENCES

Sattar J. Aboud and Ammar Agoun. Analysis ofa known offline e-coin system. InternationalJournal of Computer Applications, 2014.

Masayuki Abe and Eiichiro Fujisaki. How to dateblind signatures. In Advances in Cryptology- ASIACRYPT ’96, Korea, November 3-7,1996, Proceedings, volume 1163, pages 244–251. Springer, 1996.

Martın Abadi and Cedric Fournet. Mobile values,new names, and secure communication. InThe 28th Symposium on Principles of Pro-gramming Languages, ACM, UK, 2001.

M. Backes, C. Hritcu, and M. Maffei. Automatedverification of remote electronic voting pro-tocols in the applied pi-calculus. In CSF,2008.

Bruno Blanchet. An efficient cryptographic pro-tocol verifier based on prolog rules. In 14thIEEE Computer Security Foundations Work-shop (CSFW-14), Canada, 2001.

Stefan Brands. Untraceable off-line cash in wal-lets with observers (extended abstract). InProceedings of the 13th Annual InternationalCryptology Conference on Advances in Cryp-tology, CRYPTO ’93, pages 302–318, Lon-don, UK, UK, 1994. Springer-Verlag.

David Chaum, Amos Fiat, and Moni Naor. Un-traceable electronic cash. In Advances inCryptology: Proceedings of CRYPTO ’88,pages 319–327. Springer New York, 1990.

Sebastien Canard and Aline Gouget. Anonymityin transferable e-cash. In Applied Cryptog-raphy and Network Security, ACNS, USA,pages 207–223, 2008.

11

Sebastien Canard, Aline Gouget, and JacquesTraore. Improvement of efficiency in (uncon-ditional) anonymous transferable e-cash. InFinancial Cryptography and Data Security,12th International Conference, FC, Mexico.Springer, 2008.

David Chaum. Blind signatures for untraceablepayments. In Advances in Cryptology: Pro-ceedings of CRYPTO ’82. Springer US, 1983.

Giovanni Di Crescenzo. A non-interactive elec-tronic cash system. In Algorithms and Com-plexity, Second Italian Conference, Italy, vol-ume 778 of Lecture Notes in Computer Sci-ence, pages 109–124. Springer, 1994.

Chang Yu Cheng, Jasmy Yunus, and Kamaruz-zaman Seman. Estimations on the secu-rity aspect of brand’s electronic cash scheme.In 19th International Conference on Ad-vanced Information Networking and Applica-tions AINA, Taiwan, 2005.

I. B. Damgard. Payment systems and cre-dential mechanisms with provable securityagainst abuse by individuals. In Proceedingson Advances in Cryptology, pages 328–335.Springer-Verlag, 1990.

Stefano D’Amiano and Giovanni Di Crescenzo.Methodology for digital money based on gen-eral cryptographic tools. In Advances inCryptology - EUROCRYPT ’94, Workshopon the Theory and Application of Crypto-graphic Techniques, Italy. Springer, 1994.

Jannik Dreier, Rosario Giustolisi, Ali Kassem,Pascal Lafourcade, Gabriele Lenzini, and Pe-ter Y. A. Ryan. Formal analysis of electronicexams. In SECRYPT, Austria, 2014, pages101–112, 2014.

S. Delaune, S. Kremer, and M.D. Ryan. Verify-ing privacy-type properties of electronic vot-ing protocols. Journal of Computer Security,17(4):435–487, jul 2009.

J. Dreier, P. Lafourcade, and Y. Lakhnech. A for-mal taxonomy of privacy in voting protocols.In ICC, pages 6710–6715, 2012.

Jannik Dreier, Pascal Lafourcade, and YassineLakhnech. Formal verification of e-auctionprotocols. In Principles of Security andTrust, POST, pages 247–266. Springer, 2013.

D. Dolev and Andrew C. Yao. On the securityof public key protocols. Information Theory,IEEE Transactions on, 29(2):198–208, 1983.

Niels Ferguson. Single term off-line coins. In Ad-vances in Cryptology, Lecture Notes in Com-

puter Science - EUROCRYPT ’93, volume765, pages 318–328. Springer-Verlag, 1994.

Chun-I Fan, Vincent Shi-Ming Huang, and Yao-Chun Yu. User efficient recoverable off-linee-cash scheme with fast anonymity revok-ing. Mathematical and Computer Modelling,2013.

Sangjin Kim and Heekuck Oh. Making electronicrefunds reusable, 2001.

Ralf Kusters and Tomasz Truderung. Reducingprotocol analysis with xor to the xor-free casein the horn theory based approach. Journalof Automated Reasoning, 2011.

Zhengqin Luo, Xiaojuan Cai, Jun Pang, andYuxin Deng. Analyzing an electronic cashprotocol using applied pi calculus. In AppliedCryptography and Network Security, 5th In-ternational Conference, ACNS, China, 2007.

Tatsuaki Okamoto and Kazuo Ohta. Dis-posable zero-knowledge authentications andtheir applications to untraceable electroniccash. In Proceedings on Advances in Cryptol-ogy, CRYPTO ’89, pages 481–496. Springer-Verlag New York, Inc., 1989.

Marek R. Ogiela and Piotr Sulkowski. Improvedcryptographic protocol for digital coin ex-change. In Soft Computing and IntelligentSystems (SCIS), pages 1148–1151, 2014.

Birgit Pfitzmann, Matthias Schunter, andMichael Waidner. How to break anotherprovably secure payment system. In EU-ROCRYPT ’95, International Conference onthe Theory and Application of CryptographicTechniques, France, pages 121–132, 1995.

Birgit Pfitzmann and Michael Waidner. How tobreak and repair A ”provably secure” un-traceable payment system. In CRYPTO ’91,11th Annual International Cryptology Con-ference, USA, pages 338–350, 1991.

Berry Schoenmakers. Basic security of theecash payment system. In In AppliedCryptography, Course on Computer Securityand Industrial Cryptography, pages 201–231.Springer-Verlag, LNCS, 1997.

Aye Thandar Swe and Khin Khat Khat Kyaw.Formal analysis of secure e-cash transactionprotocol. In International Conference on Ad-vances in Engineering and Technology, Sin-gapore, 2014.

12