Proxy-Based Framework

A proxy-based mobile payment system allows a client to perform payment transactions by using an existing fixed-network payment protocol through a proxy server located in a fixed network operating on the client’s behalf. This is because the fact that, on the migration of a payment protocol to perform transactions in a wireless environment, the engaging parties that already have existing payment infrastructure do not want to change or upgrade their ex- pensive infrastructure to support mobile payment that may incur high cost. A simple solution is to set up a proxy server as a medium between mobile devices and the payment infrastructure. To make a payment to a merchant, the client sends a request over a wireless network to trigger the proxy server located in a fixed network to perform the transaction with the merchant on behalf of the client.

Several systems based on the proxy-based framework have been intro- duced [WSZ01, JRFH02, AG03, DZ03]. Three Domain (3D) SET for Mo- biles [WSZ01] and Jin et al.’s approach [JRFH02] were proposed to enable SET payment transactions in wireless environments. Antovskiet al. proposed an account-based payment protocol for wireless networks [AG03]. Dai et al.

[DZ03] proposed an authentication and payment scheme for mobile commerce by assigning a WAP gateway to perform transactions on behalf of the client in a fixed environment.

However, even though the proxy-based solution is compatible with existing fixed-network payment systems, the client is required to fully trust the proxy server in that the client’s sensitive information, such as credit-card information and the client’s private key, needs to be stored on the proxy server. Therefore, successful attacks on the proxy server will compromise the security of the entire system.

In this section, 3D SET for Mobiles [WSZ01], Antovski et al.’s approach [AG03], and Dai et al.’s approach [DZ03] are presented in details to give the idea how the proxy-based mobile payment systems work and their security issues are discussed.

Three Domain SET for Mobiles

Three Domain (3D) SET for Mobiles [WSZ01] is a system operating the SET protocol [Mas97] over wireless networks. In this system, an issuer performing transactions on behalf of a mobile client. The following steps illustrate how the system works (see Figure 2.2):

1. After browsing for goods or services on a merchant’s site, the client starts a SET payment session by selecting SET as the payment protocol.

2. The merchant notifies the client that the SET payment session is about to start.

3. The client is redirected to the issuer’s server. This server contains all the client’s payment-related information including credit-card information.

4. The issuer displays a screen with all payment-related information such as product descriptions and price. Then, the client is requested to fill in

authentication information such as password to confirm the payment.

5. The client enters the authentication information. After the authenti- cation is successful, the issuer performs the respective SET payment transaction on behalf of the client.

6. After the completion of the transaction, the client is redirected back to the merchant’s site.

1 2 6 5 4 3 Client Merchant Issuer

Figure 2.2: 3D SET for Mobiles

It can be seen that 3D SET for Mobiles offers many advantages:

• The client is not required to store any information on her mobile device. This can reduce the problem of limited storage of mobile devices.

• Only a few and small messages are transmitted over wireless networks. Moreover, all high computational operations are performed at the issuer. Thus, the communication load at the client side is low.

• As the system is centralized, all updates can be done only at the issuer including the change of the underlying payment protocol. This offers the flexibility to the system.

However, 3D SET for Mobiles has the following problems and limitations [WSZ01]:

• The client is required to fully trust the issuer that the issuer will not perform payment transactions on the client’s behalf without the autho- rization from the client.

• The client’s confidential information needs to be stored on the issuer’s server. This information will possibly be lost by successful attacks to the issuer’s server.

• The issuer can trace the spending behaviour of its clients and build the detailed client profiles.

Antovski et al.’s Approach

Antovskiet al. [AG03] proposed an account-based payment system for wireless networks. Three parties are involved in this system: client, merchant, and Financial Service Provider (FSP). FSP, acting on behalf of the client, performs transactions to the merchant on the client’s behalf. In this system, the client establishes an account with the bank and communicates with the bank through FSP. The payment protocol for this system is shown as follows.

Client Merchant FSP 1 2 3 4 5 6

1 C→M: InvoiceRequest

2 M→FSP: {Invoice}K

where K is the session key generated from SSL handshake.

3 FSP→C: {{Invoice}_K−1 F SP}KC 4 C→FSP: {{DeductionRequest}_K−1 C }KF SP 5 FSP→M: Acknowledgement 6 FSP→C: P aymentReceipt

The details of the above payment protocol are shown as follows:

1. The client sends a request to make a payment to the merchant.

2. The merchant sends an invoice to FSP over a SSL channel.

3. FSP signs the invoice with its own private key K−1

F SP and encrypts with the client’s public key KC, and then redirects the message to the client to request for the confirmation of money deduction from the client’s account.

4. The client retrieves the message. To confirm the payment, the client enters a password to unlock her private key stored on her mobile device. Then, the client sends FSP a deduction request as the payment confirma- tion signed with the client’s private key K_C−1 and encrypted with FSP’s public key KF SP.

5. On receiving the message, FSP verifies the client’s signature and retrieves the payment confirmation. Then, FSP forwards the confirmation to the bank.

6. FSP sends the notification to the merchant.

Antovskiet al. do not provide the details of each message transferred in the protocol. They claimed that the protocol is suitable for wireless environments. However, its computational and communication load are still doubtful because this protocol deploys public-key operations, especially at the client side.

Dai et al.’s Approach

Daiet al. proposed a payment system that allows clients perform transactions via mobile phones. Three parties are involved in this system: client, WAP gateway, and merchant. The client is assumed to have a WAP-enabled mobile phone, whereas the merchant has an e-commerce WAP site. This system de- ploys a WAP gateway to perform secure operations on behalf of the client. Dai

et al. argued that a WAP1.2 phone is capable of generating digital signature according to PKCS#1 standard [RSA93a] which cannot provide signature val- idation process. Note that the signature validation process is provided by the PKCS#7 standard [RSA93b].

To solve this problem, Daiet al. introduced a secure module into the WAP gateway to perform the functions that cannot be done on the WAP phone such as storing certificates, generating signatures according to PKCS#7 standard, and validating the merchant’s signature. Dai et al. also proposed an authen- tication and payment scheme based on this system. The client authentication scheme for this system can be simplified in Figure 2.4 as follows:

Client WAP Gateway Merchant SMSC 1 1 2 2 2 3 3 4

1. The client sends an authentication request to the merchant via the WAP gateway.

2. The merchant generates an authenticate message to the client via the WAP gateway and a SMSC (Short Message Service Center).

3. The client signs the message with PKCS#1 signature and passes it to the WAP gateway via the SMSC.

4. The WAP gateway verifies the signature. It signs the message with PKCS#7 signature and sends to the merchant.

The payment scheme for this system is shown in Figure 2.5 as follows:

Client WAP Gateway Merchant SMSC 1 1 2 6 5 3 4 2 4 5 7 7

Figure 2.5: The payment scheme according to Dai et al.’s approach

1. The client sends a request to the merchant via the WAP gateway.

2. The merchant sends back the payment type, e.g. credit or debit, to the client via the WAP gateway.

3. The client selects the payment type preferred to the WAP gateway.

4. The WAP gateway sends a contract to the client via the SMSC.

5. The client signs the contract with PKCS#1 signature and sends it back to the WAP gateway via SMSC.

6. The WAP gateway verifies the signature and performs the transaction on behalf of the client to the merchant.

7. The merchant sends the receipt to the client via the WAP gateway.

In this system, it is obvious that the security of the client relies on the security and trustworthiness of the WAP gateway. That is, the WAP gateway is able to impersonate as the client because it has the client’s private key. Moreover, the use of SMSC is unnecessary because the entire transaction can be performed with the direct communications between the client and the WAP gateway. The use of SMSC also incurs extra cost for the client in addition to being charged for the WAP usage. That is, in each transaction, the client has to be charged for two SMS messages: one in the client authentication phase and the other in the payment phase.