In a token-based payment system, electronic money (or payment token) repre- sents physical money. A client exchanges physical money with payment tokens, e.g. electronic coins or electronic cash, with her issuer (by requesting the is- suer to deduct the requested amount from her account) and uses them to pay for goods or services. A merchant collects the tokens and sends them to her acquirer to redeem the money (by the means of money transfer to the mer- chant’s account). For simplicity, it is assumed that the issuer and the acquirer are the same party called bank. Referred to the payment model presented in section 2.2, the bank is represented by the payment gateway which performs the tasks of both issuer and acquirer.
According to the token-based payment system, the client is not required to have payment authorization from the bank in every transaction. It therefore has lower operational cost compared to that of account-based payment systems. This results in more suitability for low-valued transactions. The examples of the protocols that operate in token-based payment systems are electronic cash [AM00, YL01] and micropayment protocols [HSW96, GMAG95, PBD01, RS96, Yen01, SV97].
Token-based payment systems can be classified into two categories: pre- paid and postpaid payment systems. In a prepaid payment system [Yen01, GMAG95], the client is required to purchase payment tokens by requesting the bank to deduct the money from her account to have the payment tokens in return. The client can spend the payment tokens with merchants for goods or services. The merchants collect the payment tokens and redeem the money from the bank.
In a postpaid payment system [RS96, HSW96, PBD01], the client is allowed by the bank to generate payment tokens by herself and spend them up to the credit limit specified to each merchant. The merchant collects the payment
tokens and redeems the money from the bank. After a specified period, the client receives the bill as a result of the micropayment transactions she has performed.
In this section, we outline two existing micropayment protocols: PayWord [RS96] and PayFair [Yen01] as examples of postpaid and prepaid token-based payment protocols, respectively. These protocols deploy different kinds of cryp- tographic operations in that PayWord deploys public-key operations whereas PayFair is based on symmetric-key operations.
PayWord
PayWord [RS96] is a postpaid micropayment protocol based on public-key operations. Three parties are involved in the system: client, merchant, and bank.
At the beginning of the protocol, where the client and the merchant have originally established accounts with the bank, the client requests the bank to perform a transaction using PayWord. The bank issues the client aPayWord certificate which contains an authorized amount CLthat the client is allowed to spend to each merchant. Then, the PayWord payment process can be performed as the following:
1. To make a payment to the merchant, the client generates a set of coins {c0, ..., cn}, where n=CL, which is specific to the merchant. The set of coins is generated as follows:
ci =h(ci+1), where i= 1, ..., n−1
2. In the first payment, the client sends the merchant acommitment, which contains the PayWord certificate and c0, digitally signed by the client.
3. Later on, in each payment, the client sends the coinci to the merchant. The merchant can infer the value of the coin i by applying a number of hash operations to ci as follows: c0 =hi(ci).
4. At the end of a specified period e.g. a day or a month, the merchant sends the highest value of ci together with the commitment to the bank. The bank then deducts the requested amount from the client’s account by calculating the amount from c0 and the maximum value of ci, and transfers the charged amount to the merchant’s account.
In PayWord [RS96], the computational load at the client is reduced com- pared to SET [Mas97] and iKP [BGH+00] protocols because the client is not required to have payment authorization from the bank in every transaction. However, PayWord is not suitable for wireless environments because it has high client’s computation due to public-key operations. In addition, the payment- related information, c0 and ci, is readable by any party who has the client’s public key. Therefore, she is able to trace the client’s spending behaviour.
PayFair
PayFair [Yen01] is a prepaid micropayment protocol which deploys symmetric- key operations and hash functions. The details of PayFair are given as follows:
Phase A: Prepaid Phase
C→B: IDC, OC, h(OC, KC) (a)
B→C: {{N, RN}SK, RT}KC, N, h({N, RN}SK, N, OC, KC) (b)
From the above protocol steps,SK is a secret known only to the bank. KC is shared between the client and the bank. RT is a nonce for replay protec- tion. The client requests the bank by sending order numberOC containing the requested amount. The bank returns the message containing a payment token
{N, RN}SK, which is later used for generating coins. RN is a random number generated from the serial number N and the secret SK. The client generates a set of coins wi, where i = 0, ..., n and wn = {N, RN}SK, from the process: wi =h(wi+1).
Phase B: Micropayment Phase
C→M: w0, N, h(w0, IDM, KC) (c)
M→B: w0, N, IDC, RM, h(w0, IDM, KC) (d)
B→M: w0, IDC, IDM, Y ES, h(w0, IDC, KM, RM, Y ES) (e)
The client sends the message (c) containingw0 to the merchant. The mer- chant then forwardsh(w0, IDM, KC) with relevant information to the bank in (d). After receiving the message, the bank can generate wn from w0, N, and its ownRN andSK. The bank then transfers the amount nto the merchant’s account and sends the response to the merchant in (e). The client can make a payment to the merchant as follows:
C→M: wi where i= 1, ..., n (f)
It can be seen that with the deployment of symmetric-key operations and hash functions, the computational load at the client of PayFair is reduced com- pared to that of PayWord [RS96]. However, the problem of revealing payment- related information occurred in PayWord still exists because, in (c) and (f),w0 andwi are transmitted in cleartext. In addition, although Yen [Yen01] claimed that the payment token wn is general-purposed, it is still merchant-specific when used, that is, although the coins are merchant-independently generated, they can still be used with only one specific merchant. Thus, the client needs to request the bank for a new payment token every time she wants to make a payment to a new merchant. Moreover, in (c), the bank can impersonate as
the client to perform transactions with the merchant.