Desktop version

Home arrow Business & Finance

  • Increase font
  • Decrease font

<<   CONTENTS   >>

Privacy-preserving Payments Due to the Research Community

As mentioned previously, privacy-preserving payments attracted the attention of the research community in the early years of applied cryptography. In the following, we introduce digital or electronic cash, which aimed to replace conventional cash, and proceed with primitives to enable privacy-preserving checks and credit card-based payments. Finally, we provide a look at other use cases related to privacy-preserving payments, such as stock market and taxation.

Digital Cash

In a first attempt to offer privacy-preserving payments that would reflect the real- world needs, in their paper “Revokable and Versatile Electronic Money” [7], Jakob- sson and Yung first presented the necessity for revokable anonymity in payments. To achieve this, users maintain their funds in bank accounts that carry their name or identity. To make payments, users withdraw anonymous coins from these accounts using a three-party protocol that takes place between the user, the bank, and a trusted “ombudsman” in charge of revocation. The user chooses a coin sequence number, and using a blind signature system,[1] the bank, and ombudsman generate a bank signature on information related to the coin. Clearly, the ombudsman, can potentially revoke the anonymity of a user. Although satisfying the need for revok- able anonymity in funds management, this scheme does not protect account activity information from the bank, since accounts themselves were not anonymous.

Digital cash or electronic cash was introduced by Chaum [8] as a cryptographic primitive to offer privacy-preserving cash-like payments. In its first version, digital cash is offered as a substitute for money on the Internet that cannot be faked, copied, or spent more than once, as long as the online participation of a bank can be guaranteed. In addition, it is known to provide absolute anonymity, namely no one, not even the bank itself, can relate a particular ecash coin (ecoin) with its owner. Consumers can indeed buy anonymous ecoins from a bank/mint and use them in their online transactions without being traced. Camenish, Lysyanskaya, and others [9-11] enhanced the work in [8] with accountability features, while offering the possibility of off-line transactions with resistance to double-spending. In [11], an ecash-based electronic payment system was introduced by taking into consideration real world system threats.

More concretely, an ecash (EC) [9, 12] system consists of three types of players: the bank, users, and merchants.

To open a bank account, users engage in a registration process through which they generate cryptographic keys to be identified within the system (EC.GenKey). When they need to perform a payment, the users contact the banks and withdraw funds in the form of ecash coins (EC.Withdraw). In most schemes, the users spend their coins among other users without the need to contact the bank at the time (EC.Spend). Users are not required to reveal their identities through EC.Spend and may participate in transactions through one-time pseudonyms [3, 13]. However, they need to use the secret keys they used during EC.Withdraw for the payment protocol not to fail. After the payment completes, merchants need to deposit their coins in the bank to allow double-spending detection to take place (EC.Deposit). These keys (and thus the identity of a payer) can be revealed (through EC.Identify) only if the payer attempts to double-spend a coin (confirmed through EC.VerifyGuilt). Depending on the scheme, it is only the identity of the double-spender or the entire set of his or her transactions that are revealed (EC.Trace).

A summary of the input and output specifications of the basic operations is listed below.

  • (pkB, skg) ^ EC.BGenKey(1k,params) and (pku, sku) ^ EC.UKeyGen(1k, params), which are the key generation algorithms for the bank and the users, respectively.
  • • (W, T) ^ EC.Withdraw(pkB,pku,n) [u(sku), B(skB)]. In this interactive procedure, u withdraws a wallet W of n coins from B.
  • • (W', (S,n)) ^ EC.Spend(pkM,pkB,n) [u(W), M(skm)]. In this interactive procedure, u spends a digital coin with serial number S from his or her wallet W to M. When the procedure is over, W is reduced to W', M obtains as output a coin (S, n), where n is a proof of a valid coin with a serial number S.
  • (T/±,L') ^ EC.Deposit(pkM,pkB) [M(skm, S, n), B(skB, L)]. In this interactive procedure, M deposits a coin (S, n) into its account in the bank. If this procedure is successful, M's output will be T and the bank's list L of the spent coins will be updated to L'.
  • (pku, nG) ^ EC.Identify(params, S, п, n2). When the bank receives the two coins with the same serial number S and validity proofs n and n2, it executes this procedure to reveal the public key of the violator accompanied with a violation proof nG.
  • • T/± ^ EC.VerifyGuilt(params, S,pku, nG). This algorithm, given nG, publicly verifies the violation of pku.
  • • {(Sj, П*)}* ^ EC.Trace(params, S,pku, nG, D, n). This algorithm provides a list of serials S* of the ecoins a violator pku has issued, with the corresponding ownership proofs П*.
  • • T/± ^ EC.VerifyOwnership(params, S, n,pku, n). This algorithm allows to publicly verify the proof П that a coin with serial number S belongs to a user with public key pku.

Camenish et al. presented in [12] a money-laundering prevention version of [9], where anonymity is revoked when the spender spends more coins with the same merchant than their spending limit. In this case ecoins are upgraded to:

C = (S, V, n),

where V is a merchant-related locator, while EC.Identify and EC.VerifyGuilt procedures are upgraded to the DetectViolator and VerifyViolation to support the extended violation definition.

Security Properties

Electronic cash systems are built with the following security properties: correctness, fairness, (conditional) anonymity, and resistance to impersonation attacks. Correctness requires that the electronic cash protocols work as intended if all players are honest. Fairness requires that no collection of users and merchants can ever spend more coins than they withdraw. On the other hand, anonymity of users requires that no entity, even the bank itself when colluding with any collection of (malicious) users and/or merchants can obtain information on a user's spending other than the information intentionally released in the network by the user (and associated side- information).

User anonymity is commonly conditional on honest user behavior. That is, given a violation with respect to a predefined policy, electronic cash system can output proofs of guilt nG and the violators’ public keys pkV such that EC.VerifyViolation accepts. Such a proof of violation enables systems to support the traceability of a violator’s behavior. That is, EC.Trace will output the serial numbers of all coins that belong to the violator with public key pkV along with the corresponding proofs of ownership that VerifyOwnership accepts.

Finally, resistance to impersonation attacks requires that an honest user u cannot be accused of conducting a violation that EC.VerifyViolation accepts.


Although initial schemes offering digital cash were online-based, recent digital cash payment systems are off-line, offering to some extent resistance to double-spending (or misbehavior). In particular, ecash schemes reveal the identity of the doublespender and/or the entirety of their transactions. Except for their initial version, those schemes do not require any trusted third-party (mediator). Finally, despite their privacy guarantees, these systems usually incur complicated cryptographic operations (e.g., blind signature) and are therefore penalizing in terms of performance.

  • [1] Blind signatures refer to a cryptographic primitive that allows an entity to digitally sign a messagewithout knowing or being able to read the message that it signs.
<<   CONTENTS   >>

Related topics