Payment

 

Figure 6:   Payment with Refresh: Flows

  

Figure 7: Payment with Refresh protocol.

The Payment process involves the payer (e.g., a customer), the payee (e.g., a merchant) and the issuer. The requirements are as follows:

• Valid payments go through. If the payer transfers a certain amount in valid coins, and if these coins are as yet unspent, then, after checking with the issuer, the payee accepts the payment. (He may end up with refreshed coins, or have redeemed them, or aggregated, as he wishes.)
• Accepted payments are valid. If after checking with the issuer a payee accepts a payment, then he knows that the refreshed coins he has obtained are valid. In particular, already-spent coins are detected: If a payer uses an already-spent coin then (by checking with the issuer) the payee will detect it, and the payee will not accept the payment.
• Payment is for the goods or services the parties have agreed on. An adversary A cannot divert a payment by the payer to A's advantage, or even change the order description in ``spoiler'' ways. This is an optional requirement, which can be provided given an external certification authority.
• Payer is informed of double spending. In case the issuer detects double spending, the payer should be told his coins are bad, and be sure that the issuer thinks so.

We provide two basic kinds of payment protocols: payment with refresh (i.e., the payee obtains new coins) and payment with redemption (the payee is enrolled, and obtains real funds). In this abstract we only describe the former; payment with redemption has the same flavor. The same applies to payment with aggregation. The flows involved in payment with refresh are shown in Figure 6, and the protocol in Figure 7. The ${\rm V\mbox{-}DESC}$ field indicates which option is being used. In addition, it includes whatever information is needed for the option being used. For example, if it is refresh, the ${\rm V\mbox{-}DESC}$ field includes the type and number of the desired coins; if it is redemption, the ${\rm V\mbox{-}DESC}$ field includes the bank name, address and the account number.

The payment protocols have certain optional flows. They are indicated in square brackets, for example $[\mbox{\bf S}_{{\em PY}}({\cal H}({\rm Com}))]$ means providing this signature in the first flow is an option. The issue here is certificates. The basic protocol does not need a certification authority: it is enough that the issuer have the public keys of the participants. But for the extra functionality of order protection and receipt, an external certification authority is needed to provide the payer with the public key of the payee. We now describe how the flows are computed.

• Invoice. This transaction consists of a single flow in which the payee provides the transaction ID. The latter is a randomly chosen number which uniquely identifies the transaction. For confirmation of amount and order information, it is suggested that this be accompanied by a signature of the common information.
• SendCoins. The payer picks from his purse a collection of coins ${\rm Coin}_1,\ldots,{\rm Coin}_n$ whose total dollar value equals the amount to be paid. (If the purse happens to not currently hold this amount, but holds coins of total dollar value which is larger, the payer can go through a change transaction to get change, and then resume the payment. If the purse has insufficient funds, the payer will have to make a coin purchase, and, since this is a lengthy process, he will probably stop the payment here and re-start when he has the funds.) The coins are put in an envelope by encrypting them (and the identity of the payee) under the public key of the issuer. The ciphertext is transmitted to the payee.
• Validation Request. The payee cannot open the envelope; he never sees the coins. Instead, he forwards them to the issuer for validation, along with ${\rm V\mbox{-}DESC}$ which indicates whether he wants refresh, redemption or aggregation. The payee also includes in ${\rm V\mbox{-}DESC}$ the amount, to guard against the payer paying less than the agreed amount. This is done, for privacy, under cover of an encryption under the issuer's public key. Also in the scope of the encryption go the payer identity, the transaction id, and a number $K_{{\em PY}}$, chosen at random, which will be used to derive a session key.

At this point the process is different depending on whether we are doing refresh or redeem. We continue to describe the refresh case.

• Issuance. The issuer decrypts the ciphertext to obtain ${\rm ID}_{{\em PY}},K_{{\em PY}},{\rm TID}_{{\em PY}},{\rm V\mbox{-}DESC},{\rm EncC}_1$. He then decrypts ${\rm EncC}_1$ to get the coins which were sent by the payee. The validity of these coins is checked, as also the fact that the total value of these coins matches the amount claimed by the payee that is present in ${\rm V\mbox{-}DESC}$. Now new coins are issued, of the type specified in ${\rm V\mbox{-}DESC}$, via two flows:
  • Issuance1. The issuer picks a number $K_{{\em I}}$ at random and forms the session key $K=K_{{\em I}}\oplus K_{{\em PY}}$. The session key, together with ${\rm ID}_{{\em I}}$, are encrypted under the public key of the payee, and the resulting ciphertext is transfered to the payee. Also the issuer encryptes the new coins under K; then MACs this ciphertext and some other stuff as shown. The second ciphertext and the MAC are also sent to the payee.
  • Issuance2. The payee acknowledge having received the new coins by sending a message signed under the session key K.
• Receipt. The last flow is optional, and consists of a receipt, from payee to payer, that the payer's payment was accepted by the issuer.

We have omitted from the protocol picture the flows related to error conditions, such as the issuer informing the payer if his coins are bad, or the issuer informing both parties if the claimed and paid amounts do not match. The issuer would sign the bad coins and the error statement, and pass this to the payee, who in turn passes it to the payer.

Several spoiling attacks are possible. For example an attacker could flip some bits in the MAC in the Issuance1 flow, making the payee reject. In a seemingly more sophisticated attack, he can remove the ValidationReq flow sent by the payee and substitute a fake one which contains the same information except that the value of $K_{{\em PY}}$ is different. (Note he is in possession of all information except $K_{{\em PY}}$ so can indeed do this.) Then the payee will again reject the Issuance1 flow since he will recover the wrong session key. However, such attacks do not really help the attacker. These kinds of spoiling attacks are unpreventable, and handled by appropriate error handling and re-transmission.