2.4 Enabling Mobile Payment
2.4.3 Non Proxy-Based Framework
A non proxy-based mobile payment system requires no proxy server. There- fore, it takes the constraints of wireless environments into account. These constraints mainly come from mobile devices and wireless networks discussed in chapter 1. Thus, various kinds of lightweight cryptographic techniques have been applied to reduce computational and communication load of the systems. Due to the fact that non proxy-based mobile payment systems do not re- quire any proxy server or mobile agent to increase transaction performance of
the systems, their main focus is the payment protocols operated in the sys- tems. Such payment protocols have to be lightweight and provide sufficient security. In this section, we therefore focus on existing non proxy-based pay- ment protocols.
Several payment systems and protocols have been proposed to secure non proxy-based mobile payment [Pay01, FAB02, KLK+02, ZK02, PBD01]. Pay- box [Pay01] is a payment system based on mobile telecommunication system. Its security also relies on the security of the mobile telecommunication system. Wireless SET (WSET) protocol [FAB02] was proposed to enable SET trans- actions in wireless environments by reducing the computation load at mobile users by using WTLS certificates [WAP01] instead of SET certificates. Kim
et al. [KLK+02] proposed an electronic cash protocol for wireless networks based on hash functions and digital signature. Zheng et al. [ZK02] proposed another electronic cash payment protocol based on Brands’ restrictive blinding signature to ensure untraceability property. Park et al. [PBD01] proposed a micropayment protocol for wireless networks based on tamper-proof resistant devices.
In this section, we outline Park et al.’s protocol [PBD01], Paybox [Pay01], Kim et al.’s protocol [KLK+02], and WSET protocol [FAB02] to provide the idea how non proxy-based mobile payment systems work and how various kinds of cryptographic techniques have been applied to the payment systems including the discussion about their security issues.
Park et al.’s Protocol
Park et al. [PBD01] proposed a postpaid micropayment protocol based on tamper-resistant devices. The protocol deploys only hash functions which re- sult in the reduction of engaging parties’ computation.
Three parties are involved in the protocol: user (or client) U, value-added service provider (or merchant)V, and service provider (or bank)S. The initial
assumptions of Park et al.’s protocol are shown as follows:
1. S possesses the keys KU V and KU S, where KU V = h(KV S, IDU) and KU S =h(KS, IDU). Note that KS is a secret known only to S.
2. U possesses the keys KU V and KU S. These secrets are sent fromS. 3. V possesses the keysKU V, where KU V =h(KV S, IDU). Note that KV S
is transferred from S toV in order to generate KU V.
Generally, whenU requests to make a payment toV, the requested amount is deducted from U’s account established atS and transferred to V’s account byS. Following PayWord [RS96] presented in section 2.3.2, Parket al.’s proto- col is divided into 3 sub-protocols: Payment Initialization Protocol, Payment Protocol, and Payment-clearing Protocol. The details of these protocols are shown as follows.
Payment Initialization Protocol
1. U sends her identity IDU and a random number rU toV.
U→V: IDU, rU (1)
2. V responses by sending U a random number rV together with charging data chdataand timestampT SV toU. Note that h(rU, rV, KU V) is used for authentication purpose.
V→U: rV, h(rU, rV, KU V), chdata, T SV (2) 3. After receiving the message,U generates a random numbercn, calculates
a set of electronic coins cj, where j = 1, ..., n and cj =h(cj+1), and cal- culates commitmentV and commitmentS. U then sendsV the following message:
where commitmentV = h(IDU, IDV, KU V, rU, rV, T SV, chdata, c0) and commitmentS = h(commitmentV, KV S). V can verify commitmentV to ensure that U has requested to make a payment to her.
Payment Protocol
1. To start making a payment, U sends V cj, wherej is equal to the value of the requested goods or services.
U→V: cj (4)
2. After receiving cj, V infers the value of the coin by repeatedly applying a number of hash functions to cj and comparing to c0.
Payment-clearing Protocol
1. After a specified period, V sends S the message including cjmax, the
highest value of cj, to redeem the money.
V→S: c0, cjmax, IDU, IDV, rU, rV, chdata, T SV,
commitmentV, commitmentS (5) 2. S verifiescommitmentV and commitmentS and compares cjmax withc0.
Then, S transfers the amount jmax toV.
Park et al.’s protocol is claimed to be suitable for wireless environments because it has low computation at all engaging parties [PBD01]. However, it has following problems:
1. As S knows all parties’ secret keys, KU S and KU V, it can impersonate as U to perform transactions to V.
2. c0 and cj used to infer U’s requested price are transmitted in cleartext. Thus, it is possible to trace U’s spending behavior.
Paybox
Paybox [Pay01] is a simple payment system based on a mobile network system in that both client and merchant are required to have mobile devices with unique phone numbers. Paybox allows the client to perform payment transac- tions from any kinds of telephone including mobile phone to mobile merchants, e.g. taxi drivers, or to other mobile users.
There are three parties involved in the Paybox system: payer (or client), payee (or merchant), and Paybox server. To perform a Paybox transaction, both client and merchant need to have bank accounts established. Figure 2.7 illustrates how Paybox operates. The details of Paybox transaction are given as the following: Client Merchant Paybox 1 1, 2 3 4
Figure 2.7: Paybox transaction
1. After the client agrees to purchase products or services from the mer- chant, the merchant contacts the Paybox server via the telephone or data network.
2. The merchant passes the requested amount and the client’s mobile phone number to the Paybox server.
3. The client is called back, and she needs to authorize the payment by entering a PIN number.
4. The requested amount is then transferred from the client’s account to the merchant’s account.
It can be seen that the security of Paybox relies heavily on the security of the telecommunication network. No additional data security is introduced [WSZ01]. Moreover, the client authentication can be achieved only by telling or entering the PIN number to the Paybox system. This offers a possibility of an attacker to tap the conversation or the data transmitted between the client and the Paybox server.
Kim et al.’s Electronic Cash
Kim et al. [KLK+02] proposed an electronic cash protocol for wireless envi- ronments. The protocol reduces party’s computation by deploying only hash functions and digital signature. Three parties are involved in the protocol: client, merchant, and bank. The protocol descriptions are shown as follows:
1. After the client and the merchant have agreed on goods or services, the merchant sends the price of the goods value and transaction code T to the client.
M→C: h(T, value), value (1)
2. The client requests for a payment token by sending the following message containing the password P assword shared between herself and the bank to the bank.
C→B: IDC, P assword, h(T, value), value (2) 3. The bank verifies the password and issues the payment token to the
client.
4. h(T, value) is considered as the payment token that the client is allowed to spend with the merchant. To pay for the goods, the client sends the merchant the following message:
C→M: T, IDB,{h(T, value)}KB−1 (4) 5. After receiving the message, the merchant deposits the amount valueto
the bank by sending the bank the following message:
M→B: IDV,{h(T, value)}K−1
B (5)
Although Kim et al.’s protocol offers low party’s computation, it has the following problems:
1. P assword is transmitted in cleartext over the air interface. Although it is transferred through WAP (Wireless Application Protocol) [WAP02] which deploys WTLS protocol [WAP01], a variant of TLS protocol (for- merly known as SSL protocol version 3.0 [FKK96]), it still suffers from the problem of WAP security gap. Note that normally, the mobile client communicates to the fixed-network merchant through a WAP gateway. The client transfers the information encrypted with a shared key between herself and the WAP gateway over the WTLS protocol to the WAP gate- way. Then, the information is decrypted and encrypted with another key shared between the WAP gateway and the merchant over TLS protocol. Such information is revealed to the WAP gateway because it lacks of end-to-end security between the client and the merchant.
2. In the message (5), the payment token {h(T, value)}K−1
B does not bind
with the merchant’s identity. Thus, any party who successfully captures {h(T, value)}K−1
3. Kim et al. did not mention how the client receives T. Also,h(T, value) received in the message (4) does not contain the the client’s balance after being transacted.
4. The client should have been able to verifyh(T, value) by applying a hash function to T and value. However, the client does not have T.
5. The protocol lacks of non-repudiation property in most of the messages, which are the messages (2), (4), and (5).
6. In the message (5), the bank should have been able to retrieve value from h(T, value) but it cannot because the bank does not haveT.
WSET Protocol
Fourati et al. [FAB02] proposed a wireless variant of SET protocol [Mas97] called WSET. The wireless part of WSET is based on WTLS protocol. A client in WSET performs a payment transaction with a merchant through a WAP gateway and deploys WTLS certificates instead of SET certificates in order to reduce computational load. In addition, using the WTLS certificates results in end-to-end security between the client and the merchant that solves the WAP security gap problem mentioned in the previous section. However, the client still has to perform high computational operations on the SET’s
PReqgeneration.