In the previous section, we have presented KSLv1, a credit-card mobile pay- ment protocol which reduces the computation at the client who is assumed to perform payment transactions using a low computational capability mo- bile device. In KSLv1, the client’s computation is reduced by deploying symmetric-key operations, whereas the merchant and the payment gateway perform public-key operations as they are assumed to have powerful comput- ing capability devices.
It can be seen that, in KSLv1, the merchant and the payment gateway are restricted to perform transactions using fixed-network devices. However, in some applications, these parties can be mobile users. For example, a taxi driver who provides mobile payment service to passengers. She is required to have a mobile device installed in the taxi performing transactions as a merchant
in the payment system.
Moreover, a mobile payment system can be applied to money transfer among mobile users. For example, Alice requests Carol to pay money to Bob on behalf of Alice. In this case, Carol may be Alice’s personal agent or an authorized person who performs a transaction on Alice’s behalf as a result of the request from Alice. After receiving Alice’s request, Carol sends a message as a commitment to notify Bob that she will pay Bob the money on behalf of Alice. The actual payment may be later performed over a fixed network by Carol to Bob. In this case, Carol acts as a payment gateway in the mobile pay- ment system where no actual money is transferred, but only the commitments regarding fund transfer during the transaction are transferred among them.
In this section, we present KSLv2, a credit-card payment protocol for wire- less networks that is able to serve the above requirements. KSLv2 satisfies all transaction security properties stated in the Definition 3.10 of the pro- posed model without any public-key operations required at all engaging par- ties. Thus, all parties’ computation and communication passes are reduced. Moreover, without expensive PKI-based operations, the setup cost for payment infrastructure and the transaction cost are reduced. Therefore, all engaging parties including the merchant and the payment gateway are able to perform transactions on mobile devices.
In section 5.5.1, initial assumptions of the proposed KSLv2 protocol are given. Section 5.5.2 presents the key generation technique for KSLv2. In section 5.5.3, KSLv2 is presented in details.
5.5.1
Initial Assumptions
The initial assumptions of KSLv2 protocol are given as follows:
1. As well as KSLv1, there are five engaging parties in KSLv2: client, mer- chant, payment gateway, issuer, and acquirer.
2. The client shares her credit-card information (CCI) with the issuer.
3. Once the merchant registers herself to the payment gateway, the payment gateway shares the secret Z with the merchant. Both of them then generate a set of secrets Zj, where j = 1, ..., n, (the details of session key generation technique will be presented in section 5.5.2) and store it on their devices. Also, the issuer shares the secretY with the client. Both of them then generate a set of secrets Yi, where i= 1, ..., n, and store it on their devices. The secrets Y and Z can be distributed by using an AKE protocol for wireless networks. The details of existing AKE protocols have been presented in section 4.4.9.
4. The issuer is trusted by the client in that it will not reveal the client’s CCI and Y to other parties.
5. It is easy to compute h(x) from the given x, and it is computationally infeasible to compute x which y=h(x) from the given y. Moreover, the MAC algorithm is a fast and secure version.
5.5.2
Key Generation Technique
The key generation techniques for Xi and Yi, where i = 1, ..., n, have been presented in section 5.4.2. Based on [KSL04c], to generate a set of Zj, where j = 1, ..., n, we deploy the key generation technique for Xi as follows:
Z1 = h(1-bit-shift-of-Z), Z2 = h(2-bit-shift-of-Z),..., Zn = h(n-bit-shift-of-Z)
5.5.3
Details of KSLv2 Protocol
In this section, KSLv2 protocol is presented in details. As well as KSLv1, before performing a transaction, the client and the merchant need to run the
Merchant Registration Protocol to distribute the secret X. As the details of
Merchant Registration Protocol has been previously presented in section 5.4.3, in this section, we demonstrate only thePayment Protocol of KSLv2.
Payment Protocol
Step 1 C→M: IDC, i, T IDReq, MIDReq
M→C: {T ID, IDM}Xi
Step2 C→M: {OI, h(Yi), IDC, IDI, M AC[(P rice, h(OI), IDM), Yi]}Xi,
MAC[(OI, P rice, IDC, IDI), Xi+1]
Step 3 M→PG: {MAC[(P rice, h(OI), IDM), Yi], h(OI), i, T ID, P rice, IDC, IDI}Zj, IDM, j, MAC[(h(OI), T ID, IDC, IDI), Zj+1]
Step 4 Under private network,
4.1) PG→I: MAC[(P rice, h(OI), IDM), Yi], h(OI), i, T ID, P rice, IDC, IDM, h(Zj+1)
4.2) PG→A: P rice, IDM
4.3) I,A→PG: Y es/No,{h(OI), Y es/No, h(Zj+1)}Yi,
h(Y es/No, h(OI), h(Yi))
Step 5 PG→M: {Y es/No,{h(OI), Y es/No, h(Zj+1)}Yi,
h(Y es/No, h(OI), h(Yi))}Zj+1
Step 6 M→C: {{h(OI), Y es/No, h(Zj+1)}Y i}Xi+1
Step 1: the client and the merchant exchange the information necessary to start the protocol.
Step 2: the client sends the merchant a Payment Ordering request (re- ferred to the Definition 3.6 of the proposed model in chapter 3). ThePayment
Ordering request contains OI used to inform the merchant about the goods and price requested. It also contains MAC[(P rice, h(OI), IDM), Yi] which is a Debit request that is to be forwarded to the issuer. It can be noted that, although the merchant hasXi, she cannot generate this message since she does not have Yi used to construct MAC[(P rice, h(OI), IDM), Yi]. Thus, we can ensure that this message has really been generated by the client. It can be noted that the content of the message in this step is the same as that of Step 2 of KSLv1 except the additional h(Yi). The purpose of h(Yi) is to prevent the payment gateway from modifying the message in Step 5 sent from the payment gateway to the merchant. More details will be discussed in Step 5.
Step 3: the merchant decrypts the message to retrieveOI. The merchant then sends the payment gateway a Credit request encrypted with Zj. The
Credit request contains the forwarded Debit request. Note that IDC is used to identify the client, and the indexesi and j are used to identify the current session keysYi and Zj, respectively.
Step 4: after receiving the message, the payment gateway can identify the issuer from IDI. The payment gateway then passes the Debit request to the issuer. Also, the payment gateway sends IDM and P rice to notify the acquirer that the merchant is the party to which the requested amountP rice will be transferred. The issuer checks the validity of the client’s account and sends the approval result (Y es/No) to the payment gateway. Note that this step is performed under the banking private network. Thus, we do not need to concern about its security issue.
Step 5: the payment gateway sends a Credit response as a result of the
Credit request to the merchant. Note that the entire message encrypted with Zj+1 represents the Credit response, whereas{h(OI), Y es/No, h(Zj+1)}Yi rep-
resents a Debit response which will be later forwarded to the client. The merchant can check whether this message is the response of her request by com- paring the received h(OI) with the hash value of her own OI. If they are not
matched, the merchant rejects the transaction. Note that the payment gateway cannot fool the merchant by modifying the approval result because it does not have h(Yi). The merchant can verify Yes/No from h(Y es/No, h(OI), h(Yi)) by using OI and h(Yi) previously received from Step 2.
Step 6: the merchant encrypts {h(OI), Y es/No, h(Zj+1)}Yi, which rep-
resents the Debit response, with Xi+1 and sends the encrypted message to the client asPayment Ordering response. The client decrypts the message to retrieve the results of her requests from both responses.