issuer and the acquirer over a banking private network.Both SET and iKP protocols are credit-based in that the client is allowed to perform payment transactions up to credit limit specified by the issuer without paying any cents during the purchases. The client will be billed at the end of specified period. However, the client is required to have payment authorization from the issuer before making each payment. The purpose of the payment authorization is to check credit availability of the client. If the client has sufficient credits, her payment request will be approved. Token-Based Electronic Payment SystemsIn a token-based payment system, electronic money (or payment token) represents physical money.
A client exchanges physical money with payment tokens, electronic coins or electronic cash, with her issuer (by requesting the issuer 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 22 and micropayment protocols.Token-based payment systems can be classified into two categories: pre- paid and postpaid payment systems.
In a prepaid payment system 23, 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 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 pay men 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 cryptographic operations in that PayWord deploys public-key operations whereas PayFair is based on symmetric-key operations. Security vs. Transaction Cost of Electronic Payment SystemsWe have presented electronic payment systems in two categories: account- based and token-based systems. The payment systems in each category de- ploy various kinds of cryptographic operations to secure the transmission of payment related information over an insecure channel.
Selecting appropriate operations can enhance system performance.Mainly, selecting cryptographic operations for a protocol is based on the value of the information to be transmitted. That is, in each transaction, there is certain amount of transaction cost occurring from the computation at each engaging party and from the duration to complete the transaction.
PKI-based payment protocols that require higher computation and duration to complete each transaction than symmetric-key based protocols therefore incur higher transaction cost.From the previous sections, on one hand, it can be seen that public-key operations are mostly applied to account-based payment systems which involve higher value transfer than token-based ones. As public-key operations satisfy all transaction security properties mentioned in section 1.4, applying them in the transaction can secure the payment-related information transfer. On the other hand, due to the transaction cost constraint, low-valued transactions deploy symmetric-key operations and hash functions, which satisfy most of the transaction security properties, as the main cryptographic operations based on the idea that the system can accept certain degree of risks from attacks because it may not be worthwhile for an attacker to spend time and effort on attacking the payment system with low-valued transactions In addition, communication environment and availability of cryptographic operations must be taken into account when selecting appropriate cryptographic operations. An obvious example is selecting cryptographic operations for fixed and wireless environments.
As discussed in chapter 1, most mass produced mobile devices cannot perform public-key operations efficiently. Even though such operations are performed on the devices equipped with enhanced technology such as smartcard, they are time and battery consuming resulting in high transaction cost which may not be acceptable by users. How- ever, the deployment of simple cryptographic operations tends to be more vulnerable to attacks Therefore, this tradeoff must be taken into account when designing a practical and secure mobile payment system. Enabling Mobile PaymentIn the previous section, we have shown that the electronic payment systems originally designed for fixed environments cannot be directly applied to wireless environments due to a number of limitations.
To overcome such limitations, several payment frameworks have been proposed to enable mobile payment, mainly by migrating existing fixed-network payment systems to wireless net- works and by designing payment systems specifically for wireless networks.23According to the migration of existing fixed-network payment systems, two frameworks have been proposed: proxy-based and agent-based frameworks. The details of these frameworks will be presented in sections 2.4.1 and 2.
4.2, respectively. Whereas, the payment systems specifically designed for wireless environments are classified as non proxy-based framework. The details of the framework will be presented in section 2.4.
3.Table 2.1 summarizes existing mobile payment systems by categorizing the payment systems based on the above frameworks into account-based and token-based payment systems. The details of the mobile payment systems in each category will be presented in sections 2.4.1-2.4.3.Frameworks Account-basedPayment Systems Token-basedPayment SystemsProxy-basedFramework 3D SET WSZ01Jin’s approach JRFH02 Antovski’s approach AG03 Dai’s approach DZ03
