Digital Coins: Fairness Implemented by Observer

For real-world applications digital coin systems, i.e., off-line payment systems offering not only the unforgeability of conventional coins but also the anonymity of customers making purchases, need to have some additional features. One of these additional features is the hardware protection of the system, provided by dedicated tamper-resistant devices called observers which are used to physically prevent illegitimate copying of coins. Another essential feature for practical applications is anonymity-revocation mechanisms. Basically, digital coin systems guarantee perfect anonymity, i.e., the bank cannot link views of the withdrawal and payments in order to determine whether or not a customer spent her money at a certain shop. The customer’s privacy protection is the main difference between coin systems and those based on credit card or cheque based systems. While privacy protection is a desirable property of cash systems, perfect anonymity is not. Perfect anonymity makes possible perfect blackmailing or money laundering. To prevent such “perfect crime” it must be possible to revoke the anonymity of customers in case of need. Anonymity revocation is done by a trusted third party. Cash systems that allow anonymity revocation are called fair . We present a coin system featuring both observer and fairness, showing that both concepts do not interfere with each other and can be implemented simultaneously without loss of security. We prove this claim not only by presenting a fair variant of the Brands’ coin system but additionally by outlining a generic framework for fair wallets in which essentially any blind signature scheme can be used. Unlike other fair off-line coin systems, fairness is implemented with the help of the observer, thereby reducing the computational effort during the withdrawal.


Introduction
Electronic Commerce is one of the most important applications for the Internet and mobile devices. One prerequisite for establishing an (mobile) electronic marketplace is secure payment. Many protocols have been proposed to implement different kinds of payments: credit card payments, micropayments, and digital coins.
Cryptographically, the most challenging task is the design of digital coins. For every payment system mentioned above we have the requirement that the payment token has to be unforgeable. Usually, we achieve this goal by using digital signatures of the bank to validate a payment token. But in contrast to credit card payments and micropayments for digital coins we have an additional requirement -the anonymity of the payment token, i.e. the bank is not able to link a purchase to a certain customer.
In 1982, D. Chaum presented the notion of blind digital signatures that offer the possibility to design electronic coins, [5]. The bank blindly signs a set of data chosen by the customer which guarantees both the unforgeability of the coins and their anonymity, since the bank gets no information about the data it signed.
But blind signatures solve only half of the problem: since digital data can be copied, a customer can spend a valid coin several times (double-spending) if the deposit of coins is not done on-line. In order to validate each coin on-line, the vendor has to contact the bank in every purchase. In the interests of efficiency, this is highly undesirable. Therefore, we restrict our attention to off-line systems, i.e. those in which the vendor has to check the validity of coins without contacting the bank.
Since no vendor can distinguish an original coin from its copy, no cryptographic mechanism can prevent doublespending. In 1988 Chaum, Fiat, and Naor overcame the problem by presenting a double-spending detection mechanism, see [4]. A coin is constructed in a manner which allows its owner, the customer, to spend it anonymously once, but reveals her identity if she spends it twice.
From a theoretical point of view this solution is quite elegant, but it is quite impractical. Since 1988 a number of more efficient double-spending detections have been published, but the most efficient of them is still the system presented by S. Brands, see [3].
Nonetheless, all of these mechanisms are able only to detect a fraud but not to prevent one. A way to prevent the customer physically from copying his coins is to store essential parts of them in a tamper-resistant device called an observer. An example for this kind of tamper-resistant device needed for a payment system is a conventional smart card chip.
Another drawback of the coin systems described so far is the perfect anonymity they provide. A digital coin system is called perfectly anonymous if the bank's views of withdrawal and of payment are independent (in a stochastic sense). In practice this implies that the bank can by no means trace a customer or her coins, and is unable to determine which customer performed any given payment. Although perfect anonymity is a theoretically nice property it is not desirable in practice. In [16], [1], [13] the authors describe attacks on a perfect anonymous system: perfect anonymity makes blackmailing or money laundering possible. In practice, we need some anonymity revocation mechanism to prevent criminal activities or to trace the criminals. Obviously, another party different from the bank has to apply this mechanism in order to protect the honest participants within the system. Since customers and the bank have to trust this party in revealing only suspicious identities we call this new party a TTP (= trusted third party). Digital coin systems that implement this kind of anonymity revocation method are called fair.
Our approach is to modify a coin system with observers so that a TTP can revoke the anonymity of customers in case of need. Since crucial parts of the coins are stored by the observer and cannot be read by their owner, it is not obvious how to design a coin system which simultaneously provides both physical defence (by an observer) against doublespending and the fairness of coins. Based on the works of [9] and [3] we develop a coin system which provides both fairness and observer and prove the security of our construction (provided that the basic primitives are secure). This shows that both concepts can be implemented in one protocol without loss of security. By using observers we can achieve fairness in a more efficient way than [9].
The paper is organized as follows: In section 2 we briefly sketch a coin system with observer, whilst in section 3 we discuss fairness. In section 4 we present a system that features both observers and fairness, and the generic framework is given in section 5.

Coins in Wallets with Observers
There are several proposals in literature to model the properties of conventional coins for digital purposes, e.g., [4], [10], [3], [7], [11], [14]. A digital coin system as a conventional one has to provide non-forgery, off-line verification, and untraceability. In detail, • The unforgeability of digital coins is guaranteed by a digital signature of the bank. Hence, only the bank can generate coins, but everyone is able to verify the correctness of the signature. Forging a coin is as difficult as breaking the digital signature scheme, thus, in general we have computational security.
• To achieve the untraceability of coins the bank computes a "blind" signature instead of a conventional one. This means that the customer and the bank generate a set of data and a corresponding signature so that the bank cannot reconstruct the coin after the withdrawal.
The central problem with off-line coins is the possibility of double-spending, i.e. the lack of freshness of the coins. Although a merchant can verify the validity of the bank's signature, he is not able to decide whether or not a coin has been double-spent. Since the coins provide for the customers' unconditional anonymity, not even the bank knows who double-spent the coin.
The basic approach to solving this problem came from Chaum, Fiat, and Naor, [4], by including the customer's identity within the coin in a way that enables the bank to compute this identification number after a double-spending (and only in that case!). This implies that a payment cannot simply involve sending a coin to the vendor, but also requires the customer has to reveal a part of her identity.
Note, that the coin systems proposed in [4] and [11] cannot prevent double-spending, but instead detect it afterwards. Since no one can prevent the customer from making copies of the information stored in her computer, there is no other way to deal with the problem of double-spent coins cryptographically.
Accordingly, coins should not be stored by the customer's computer, but by a tamper-resistent hardware device which erases the coins after the customer spent them. To assure the customer's anonymity the tamper-resistant device is controlled by the customer's computer. This concept is often called an " observer "and was presented by Chaum and Pedersen in [6]. The observers are distributed by the bank.
To guarantee the prevention of double-spending the bank has to be sure that the observers cannot be tampered with by the customers. This is twofold: • It must not be possible for the customer to construct valid coins from the information sent by the observer during the communication.
• It must be impossible to physically extract information from the observer which enables the customer to construct valid coins.
On the other hand the customer's anonymity should not be compromised by the observer. Even if the observer is returned to the bank, the bank must not be able to link the customer to her payments. The approach used to achieve this goal is to let the customer control all communication between the observer and the world. This enables the customer to control the information provided by the observer.
For our fair off-line coin scheme we restrict this model slightly. In our model the observer cannot be returned to the bank. This restricts the bank's ability to select the data stored in the observers memory. In practice this can be done by destroying the observer before it is returned to the bank.
The use of an observer is a kind of first line of defence. If the customer cannot manipulate the device the observer can prevent double-spending. If the customer succeeds in tampering with the observer, the double-spending detection identifies the customer afterwards. The customer has to break the observer physically and the electronic cash system mathematically to cheat the bank.
To avoid the attacks described in [2], the observer's internal memory has to be protected by adding some error detection bits. We demonstrate the double-spending detection and the use of an observer in the system of [3].
Throughout the paper, we denote the actors as follows. A user is denoted by C , B is the bank, O is an observer, and the vendor is denoted by V .

Preparations of the Bank
The bank chooses a group G of prime order q, three generators g, g 1 , g 2 of G, a secret key x ∈ Z q and two one-way hash functions H : G 5 → Z q and H 0 : G 2 × ID × T IME → Z q where ID is the set of vendor identification numbers. The bank computes its public key h := g x . All computations are done in G.

Opening an Account
To open an account the customer authenticates herself to the bank. She secretly and randomly chooses u 1 ∈ Z * Note, that the customer does not know the representation of I.

Withdrawal
In principle, the withdrawal protocol is the generation of a Schnorr-signature, [15], The user performs some blinding operations and sends a blinded challenge c back to the bank. The bank signs the challenge using its private key and sends the signature back to the user. The user can unblind the bank's signature by

Purchase
In a purchase, the customer sends the coin (A, B, a , b , z , r ) to the vendor. The customer and the vendor perform a challenge-response-protocol: the vendor generates a challenge depending on the coin, the vendor's identification number and the time. The customer proves, with the help of the observer, that she knows a representation of A and B with respect to g 1 and g 2 . It is easy to prove that the customer cannot compute o 1 and o 2 from the information sent by the observer, under the assumption that she cannot compute discrete logarithms in G. This implies, that the customer is not able to perform the proof of knowledge without the interaction with the observer. And since the observer erases o 2 after the purchase, the customer cannot double-spend the coin.

Deposit
To deposit a coin, the merchant sends the coin and the transcript of the challenge-response-protocol to the bank. The bank checks the correctness of the coin's signature, of the vendor's challenge d and of the customer's responses to the challenge. If everything is correct, the bank checks in its database whether the coin has already been deposited. If it has not, the bank stores the coin, the vendor's challenge, and the customer's responses.
If it is, the bank compares the values of the challenges and the responses. If the challenges are the same, the vendor has tried to cheat by depositing the same coin twice. Thus, the bank rejects the deposit. If the challenges differ, so do the customer's responses, which enables the bank to compute the customer's identification number. Let d andd be the merchants' challenges and r 1 , r 2 andr 1 ,r 2 the customer's responses:

Fairness
Perfect anonymity protects the privacy of customers, in the sense that the bank is not able to decide whether or not the customer performed any given payment. Here, "perfect" refers to the fact that even a bank with unlimited computational power is not able to trace coins, i.e., the privacy protection is not based on any complexity assumptions.
To implement an anonymity-revocation mechanism one has to sacrifice the requirement of perfect anonymity. Frankel, Tsiounis, and Young showed in [8] that anonymity in a fair coin system can only be computational.
Furthermore, [8] shows that anonymity revocation has two different aspects: • Identity tracing: after a payment, the identity of the payer is revealed.
• Coin tracing: after a withdrawal, the coins or some crucial parts of them are revealed.
Identity tracing is needed if the bank receives suspicious money and wishes to know who spent it. This can be necessary in case of money laundering. In case of blackmailing the bank has a protocol transcript of a suspicious withdrawal. The task is to find the withdrawn coins, in order to publish them to prevent payments with these coins. Therefore, in this case coin tracing is needed.
There are many proposals as to implement identity and coin tracing, [1] [8], [9], [13]. The most efficient solution for a fair coin system is presented in [9]. It is based on Brands' coin system, and guarantees fairness by using encryptions of the customer's identity and parts of the coin. The customer has to prove the correctness of her encryptions by zero-knowledge proofs of knowledge.
We will give a brief overview of the protocols: In principle, three additional non-interactive zero-knowledge proofs for the equality of discrete logarithms are performed additionally: two during the withdrawal to provide the bank with the encryption of a part of the withdrawn coin to ensure coin tracing and a third one during the payment to ensure identity tracing.
Notation: EqLog[(A, a), G 1 , (B, b), G 2 ] denotes the zero-knowledge proof presented in figure 3. The non-interactive variant is constructed by the standard technique of replacing the random challenge c by a hash value c : = H(A, B, A , B , a, b, G 1 , G 2 ).

Initialization of the bank
As in the Brands' system the bank chooses a group G of prime order q. Generators g, g 1 , . . . , g 4 of G, q, and hash functions H , H 0 , H 1 , . . . are published.
The bank's secret key is x B and the corresponding public keys are h := g x B , h 1 :

Initialization of the TTP
The TTP chooses a secret key x T and publishes f 2 := g x T 2 , f 3 := g x T 3 .

Opening an account
There is no difference from Brands' system: the customer chooses u 1 ∈ Z q , g u 1 1 g 2 = 1, and computes I := g u 1 1 . She proves in zero-knowledge the knowledge of u 1 .

Withdrawal
The new protocol, presented in figure 4, differs in two ways from the basic system. Firstly, the customer has to transmit an ElGamal encrypted part of her coin, i.e., g s 2 . Secondly, in order to force her to use this term in the following withdrawal, a new value I is needed. I encodes the customer's identity. In V 1 the customer proves the correctness of this encoding, in V 2 the correctness of the ElGamal encryption. The combination ensures that g s

Purchase
The purchase protocol, presented in figure 5, contains an additional proof of equality of logarithms. The customer encrypts her identity under the public key of the TTP and proves that the encryption is a correct ElGamal encryption, and that the plaintext matches the identity number encoded in A of her coin.

Deposit
As in the basic system, the vendor deposits the coin by sending his protocol transcript of the payment to the bank.
Remark Note that the TTP does not register customers. Customers only need the TTP's public keys.

Analysis
We have to consider three aspects of security: (i) security for the bank, i.e., the unforgeability of coins, (ii) fairness, i.e., the TTP is able to trace identities and coins, (iii) security for the customers, i.e., the privacy protection. For a detailed discussion see [3] and [9].
(i) Unforgeability and unreusability are the same as in the basic system of Brands, [3].
(ii) The TTP can trace identities since it gets an ElGamal-Encryption A 1 , A 2 of the customer's identity I. The correctness of the encryption is proven using a zero-knowledge protocol, hence the probability that the customer cheated without detection is negligible. The TTP can trace coins because it gets the ElGamal encryption E 1 , E 2 of g s 2 = A · I −1 .
(iii) The customers' anonymity is based on the Diffie-Hellman-Decision assumption. The proof is performed in the random oracle model by a simulation technique. For details see [9].

Fair Coins in Wallets with Observers
To combine both concepts we have to carefully implement an observer in the fair system. In the previous section we saw that fairness can be achieved by some zero-knowledge proofs which increase the computational effort of the protocols. We now show how to eliminate the zero-knowledge proofs by replacing them with a signature of the observer.

Initialization of the Bank and the TTP
In addition to the system setup presented in 3.1 another generator g 5 ∈ G and two more hash functions H 2 , H 3 are published. The hash function H 3 and the generator g 5 are used for construction and verification of a Schnorr-signature generated by the observer.

Opening an Account
In addition to the account opening in 3.3 a signature key for the observer is created. A randomly chosen value x O is stored in its memory. x O which is unknown to the customer is the private key of the observer. The public key g x O 5 is stored by the bank and by the customer.

Withdrawal
The new withdrawal protocol presented in figure 6 uses a different method to achieve fairness than the one shown in 3.4. Instead of using zero-knowledge proofs to ensure tracing mechanisms, coin tracing is now guaranteed by the observer.
Compared to the protocol in 3.4 the ElGamal encryption (E 1 , E 2 ) and the value I are computed by the observer and signed afterwards using the Schnorr-signature scheme.
The signature σ O guarantees the correct construction of I and the ElGamal encryption (E 1 , E 2 ). To avoid the use of a subliminal channel between observer and bank as described in [12] all random values are chosen by the customer. Thus, the customer gets to know the observer's private key if observer and bank use the signature as a subliminal channel. The customer also verifies the signature as well as the correct construction of I and the ElGamal encryption (E 1 , E 2 ) before transmitting these values to the bank.

Purchase
The view of the vendor does not differ from that within the basic protocol. Since the customer does not know the discrete logarithm of her identity number I she has to perform the proof V 3 , which ensures that owner tracing can be done by the trusted third party, with the help of the observer. The protocol is presented in figure 7.
We omit the deposit since it is the same as in the basic system.

Efficiency
When implemented using a subgroup of order q of Z * p we save 17 modular exponentiations compared to [9], which is about a third of the modular exponentiations made during withdrawal.

Discussion
Again, we have to consider three aspects in order to show the security of our construction: (i) The unforgeability and unreuseability are proven by a standard simulation technique. (ii) The tracing algorithms of our construction are the Theorem 1 Under the Diffie-Hellman-Decision assumption and assuming that the observer is not returned to the bank the customers' privacy is computationally protected in the random oracle model.

Proof
We show that a machine M capable of deciding which coin originated from which withdrawal can break the semantic security of the ElGamal encryption and hence breaks the Diffie-Hellman-Decision assumption.
2 , s (i) , s ( j) and the encryption (E (0) 2 ) of µ (0) and (E (1) 2 ) of µ (1) as an input. Choosing s (i) and s ( j) uniformly on Z q implies a uniform distribution of µ (i) and µ ( j) on G. M has to find out whether i equals 0 or 1. M simulates two withdrawals and two payments: • M chooses x B and two random identity numbers u (i) • M knows s (i) and s ( j) . Hence M can compute: a ,b ,r ),

Account Opening
To open an account, the TTP issues an observer O to the customer. In O 's memory two secret keys x O , x O for the signature schemes σ resp. σ are stored, which are unknown to the TTP. The corresponding public keys are published.

Withdrawal
To withdraw a coin from her account, customer C and the bank B perform the following protocol: Step 1: C chooses a random message m and sends m to O .
Step 2: O encrypts m under the public key y T and signs the encrypted value with the signing key x O and sends the signature σ O ← σ(ϕ(m)) together with the encryption ϕ(m) to C .
Step 3: C verifies the signature sig O and sends σ O and ϕ(m) to B .
Step 4: B verifies sig O and blindly signs m and sends the signature σ B (m) to C . If σ O is a valid signature, B knows that the ϕ(m) was correctly encrypted, which ensures coin tracing.
Step 5: C verifies σ B (m) and obtains a signature on m, unknown to B .

Remarks:
Since O generated the encryption ϕ(m) and signed it with σ O the coin tracing mechanism is guaranteed. Note that C can still obtain blind signatures on coins m different from m. But C cannot spend these coins, since they are not generated with the help of O .

Payment
To pay with a valid coin C and V perform the following protocol: Step 1: C sends a message to O that she wants to pay with coin m.
Step 2: O checks if m is still stored in its EEPROM. If so, O encrypts C 's ID under the public key of the TTP and computes sig O ← σ (m, ϕ(ID)), deletes m, and sends sig O to C . If m is already erased O will abort the communication with C .
Step 3: C verifies sig O and sends sig O , σ B (m) to V .
Step 4: V verifies both signatures sig O and σ B (m). As mentioned above, C can obtain a blind signature on a different coin m during the withdrawal protocol. The fact that the coin m is part of the message (m, ϕ(ID)) signed by O , prevents C from successfully paying with m .

Deposit
To deposit a coin at B , V simply sends the coin m, its signature σ B (m), the encrypted identity ϕ(ID), and σ O to B . The bank B will accept the coin if σ B (m) is a valid signature on m and σ O is a valid signature on (m, ϕ(ID)).

On the choice of σ and σ
Basically, the two signature schemes σ and σ are used to guarantee coin tracing and owner tracing respectively, and to prevent C from spending coins that are not stored in the memory of O . During withdrawal one has to make sure that B is convinced that ϕ(m) was generated by the observer O , which was issued to C by TTP. Therefore it suffices to use an ordinary signature scheme for σ. Obviously, if one were to use the same key pair for σ , the anonymity of C 's coins would be lost. So, the signature scheme σ must preserve the anonymity of the coins. There are several ways to deal with this problem.

Pseudonyms:
For each customer C , the TTP creates a pseudonym, unknown to B . For all pseudonyms a key pair is generated. The secret keys are stored in the customers' observers and the corresponding public keys are made public. Due to this fact, both V and B can verify whether or not sig O was generated by an observer, but B cannot link sig O to the customer who withdrew the coin. Yet, B can link all coins withdrawn by the same customer.
Group key: For σ , the TTP chooses one key pair, which belongs to the group of all customers. The secret key is stored in all issued observers and the corresponding public key is published. Since there is only one public key, B gets no information about the customer afterwards. But if only one customer extracts the signing key from his observer, the TTP has to issue new observers and all coins stored in the old observers will become invalid.
Group signature: Instead of using an ordinary signature scheme, a group signature scheme is used for σ . So V and B do not learn any information about O during payment respectively deposit and both are convinced that • the coin was signed by an observer, and • that owner tracing can be performed at a later point of time.

Practical Implementations
Since the first digital coin systems were proposed in the early 1990s there have been many reasons why practical applications using digital coins have not been manageable: • First of all, most of the mobile devices and especially smart cards were not able to perform the necessary mathematical operations in a reasonable amount of time.
• Digital coins systems make heavenly use of public key infrastructures that have not been established at that point in time.
• The security of digital coin systems as any other payment system implicitly relies on secure computation environments. But the work on developing trusted devices that pass independent security evaluation and certification has not started before the end of the 1990s.
The situation has dramatically changed in the recent years. First of all, the most recent digital coin systems allow for the usage of elliptic curve cryptography which is far more efficient than classical RSA cryptography. Especially, the coin system presented by S. Brands which is not only the most efficient coin system today but can also be implemented using elliptic curves which significantly increases the efficiency of the system.
But more important are the technical improvements of the last ten years. Mobile devices and smart cards can perform modular exponentiations in only a few milliseconds allowing for the efficient generation of signatures especially on elliptic curves.
Furthermore, the growing area of smart card supported security applications lead to an extensive analysis and better understanding of hardware and system security which resulted not only in the establishment of public key infrastructures but also in the development of evaluation and certification schemes for hardware and software like the Common Criteria.
Since trust is most important in payment systems these efforts and changes are essential for implementing digital coins.
All these things considered, all technical prerequisites for digital coin systems are in place today.

Conclusion
We presented a digital coin system, which provides a physical defense as primary protection against double-spending by using a dedicated tamper-resistent device, supplemented by a well-known double-spending detection mechanism which can be invoked in the event of an observer being compromised by its owner. Furthermore, our system offers anonymity revocation, i.e., identity and coin tracing mechanisms.
We proved that both concepts, carefully implemented, do not interfere with each other in regard to security, i.e., our construction is as secure as its building primitives.
Further we presented a generic model for fair wallets with observer, where basically any blind signature scheme can be used as an underlying building block. This generic approach offers the necessary flexibility for practical implementations since one can combine the most efficient cryptographic primitives to build the coin system.
We argued that all technical pre-conditions for the real world application of digital coins are in place.
Given our results for hardware protection and protection against criminal abuse of digital coin systems we conclude that all practical and theoretical methods to enable the implementation and usage of digital coin systems are available today.