Coin Purchase

 

Figure 4:   The Coin Purchase process.

The Coin Purchase process involves the coin purchaser, the issuer and the coin purchaser's bank. The coin purchaser specifies how much he wants in e-coins, and in what denominations, and provides the information to make the coin purchase from the bank. The issuer makes the coin purchase and then issues the coins.

  

Figure 5: Coin Purchase rotocol

The requirements are as follows:

• Valid transactions go through.
• Can't get coins for nothing. It is not possible to get coins without paying for them: if a party ends up getting a certain dollar value of valid coins, then the issuer has the corresponding funds from the same party's bank account.
• Can't create false debits. An adversary may want to play spoiler: it doesn't want coins, but wants the coin purchaser's account to be unnecessarily debited. This should not be possible. That is, it is not possible for an adversary to create a fake coin request which leads the issuer into debiting the coin purchaser's account.

A protocol for the coin purchase process is shown in Figure 5. The field ${\rm{W}\mbox{-}DESC}$ contains two things. First, the type and number of coins he wants: this is a list of denominations, and, for each denomination, the number of coins of that denomination that are desired (see Section 2.4). Second, information necessary to enable the issuer to get paid, in real funds of equal value to the total dollar value of the coins. Here we take the case that this payment is made by coin purchase from the coin purchaser's bank, so this information includes the bank name and address, and the coin purchaser's account number. Note that this protocol does not make use of a certification authority. It assumes that the parties have each other's public keys and certificates already cached. The coin purchaser has the issuer ID and public key in his purse from enrollment, and similarly the issuer has the coin purchaser ID and public key in his database from enrollment.

There are three transactions: the coins request, in which the coin purchaser asks for the coins and provides the bank information; the execution, in which the ACH transaction is done; and the final issuance of coins. The protocol is designed to guarantee both privacy and authenticity of the data. This is to protect the coin purchase information and the coins that are issued. It must also provide freshness. For efficiency's sake we use a key exchange protocol to get a session key K under which later messages are encrypted or MACed. However, the coin purchase information is digitally signed for non-repudiability. We now go over the transactions in more detail.

• Coin Request. The coin purchaser requests that a certain amount in coins be returned to him, and authorizes the issuer to withdraw this amount from his bank account. The protocol begins with a key exchange which issues the key $K=K_{{\em CP}}\oplus K_{{\em I}}$ to both parties:
  • WRequest1. The coin purchaser chooses a random number $K_{{\em CP}}$, and then encrypts his identity ${\rm ID}_{{\em CP}}$and $K_{{\em CP}}$ under the public encryption key of the issuer, using the plaintext aware encryption algorithm. The ciphertext is passed to the issuer.
  • WRequest2. The issuer applies the plaintext-aware decryption algorithm to the received ciphertext. If this algorithm rejects the text as non-authentic then he rejects; else be obtains and records the identity ${\rm ID}_{{\em CP}}$ of the withdrawer and $K_{{\em CP}}$. Now he chooses a random number $K_{{\em I}}$ and also a random nonce $R_{{\em I}}$. He uses ${\rm ID}_{{\em CP}}$ to retrieve ${\rm PK}_{{\em CP}}$ and then encrypts ${\rm ID}_{{\em I}},K_{{\em I}},R_{{\em I}}$ under ${\rm PK}_{{\em CP}}$ using the plaintext aware encryption algorithm. The ciphertext is sent to the coin purchaser. The value $K=K_{{\em I}}\oplus K_{{\em CP}}$ is stored as the session key.
  • WRequest3. The withdrwawer applies the plaintext-aware decryption algorithm to the received ciphertext. If this algorithm rejects the text as non-authentic then he rejects; else be obtains and records the identity ${\rm ID}_{{\em I}}$, and the numbers $K_{{\em I}},R_{{\em I}}$. He checks that the identity is really that of the issuer by matching it with the value in his purse. He forms the session key $K=K_{{\em CP}}\oplus K_{{\em I}}$. Now he forms the indicated flow, which contains ${\rm{W}\mbox{-}DESC}$ and a signature, the whole encrypted under the shared session key K to ensure privacy of the bank coin purchase information. Note the nonce $R_{{\em I}}$ is included in the signature to ensure freshness.
• Execution. The issuer now uses the coin purchase information and authorization provided by the customer to make the ACH transaction of coin purchase from the bank.
  • WExecution. The coin purchaser uses K to decrypt the ciphertext and obtain ${\rm{W}\mbox{-}DESC}$ and the signature. He checks that the signature is valid, and stores it. Now he uses the information in ${\rm{W}\mbox{-}DESC}$ to make the ACH request. The issuer then waits a suitable period (which can range up to the order of days). If there is anything wrong, the bank sends a reject within this period; else the funds are in the issuer account. Now the issuer is ready to issue the coins.
• Issuance. The issuer forms e-coins ${\rm Coin}_1,\ldots,\allowbreak {\rm Coin}_n$ of the denominations requested in ${\rm{W}\mbox{-}DESC}$. (These coins may have been created earlier and are archived, or may be formed at this time.) Then:
  • Issuance1. The issuer encrypts the coins under the session key K to get ${\rm EncC}$. This ciphertext is then authenticated, also under K, by computing $\mbox{\bf mac}_K({\rm ID}_{{\em I}},{\rm EncC})$. The ciphertext and the MAC are sent to the coin purchaser.
  • Issuance2. The coin purchaser checks that the MAC is correct. (This means the coins are really from the issuer.) Then he decrypts the ciphertext to get the coins, which go into the purse. He now issues a final acknowledgment, consisting of the issuer nonce $R_{{\em I}}$ MACed under the session key.

In the full paper we show how requirements W1-3 are met. We now turn to the description of the Payment process.