Check out the new USENIX Web site. next up previous
Next: Integrating Card Cash Up: Processes and Protocols Previous: Coin Purchase


Figure 6:   Payment with Refresh: Flows

Figure 7: Payment with Refresh protocol.

\fbox {

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

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.

At this point the process is different depending on whether we are doing refresh or redeem. We continue to describe the refresh case.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.

next up previous
Next: Integrating Card Cash Up: Processes and Protocols Previous: Coin Purchase
Juan A. Garay