Extending the Proposed Protocol to Post- paid Micropayment 1 Payment Initialization Protocol To make a payment to the merchant

Extending the Proposed Protocol to Post- paid Micropayment
1

Payment Initialization Protocol

To make a payment to the merchant, the client runs the Setup Protocol to request for authorized total credits CLT . However, under the same assumption as that of PayWord which states that the client is allowed to spend up to the credit limit specified to any merchant, CLT issued by the bank in the proposed protocol stands for the credit limit that the client is allowed to spend to each merchant instead.
The client, receiving the random number c from the Setup Protocol, generates a set of coins {c0, …, cm}, where m = CLT . The client then sends the following message to the merchant:

C?M : {c0, CLT , Ttt, h(c0, IDM , Ttt, Yi)}Xi (9.17)

It can be seen that the merchant cannot generate this message by herself because she does not have Yi which is shared between the client and the bank. After retrieving c0 and CLT , the client can make the payment to the merchant by following the Payment Protocol previously presented in section 9.2.5.

Payment Clearing Protocol

At the end of a specified period, the merchant collects necessary information and sends the following message to the bank.

M?B : IDM , cjmax , Ttt, h(c0, IDM , Ttt, Yi) (9.18)

After receiving the message, the bank calculates cCLT , where cCLT = {c, Ttt} and calculates c0 from cCLT . The bank verifies the received c0 with the one that it has. If they are matched, the bank calculates jmax and transfers the amount jmax to the merchant’s account.

Analysis and Discussions

Transaction Security Properties

In this section, we show that the cryptographic technique applied to KSLv1 and KSLv2 protocols can be applied to our micropayment protocol which makes our protocol satisfy the transaction security properties stated in the Definition 3.10
of the proposed mobile payment model. The message 9.4 demonstrates how the technique works:

B?M : {c0, Ttt, SN, CLM , h(IDM , SN, CLTR, TTR, Yi)}Zj ,
h(c0, Ttt, CLM , s, Xi), s, t

It can seen that all transaction security properties stated in the proposed mobile payment model are satisfied as follows:

• Party Authentication is ensured by the symmetric encryption with the secret Zj and by the secret Yi shared between the client and the bank. The encryption ensures that either the bank or the merchant has originated the message, and the secret Yi ensures that the bank is the originator of the message.
• Transaction Privacy is guaranteed by the symmetric encryption with the secret Zj.
• Transaction Integrity is guaranteed by h(c0, Ttt, CLM , s, Xi) which is forwarded from the client. It is to ensure that c0 will not be modified during the transaction.
• Non-repudiation of Transactions is ensured by h(IDM , SN, CLTR, TTR, Yi) in that the bank cannot deny that it did not generate the message
{c0, Ttt, SN, CLM , h(IDM , SN, CLTR, TTR, Yi)}Zj since the bank is the only party that holds both Zj and Yi.

• Transaction Authorization is ensured by the secrets Xi and Zj which show that the client and the bank, respectively, have authorization on performing the transactions to the merchant.

Dispute Resolution

The proposed protocol offers the ability to resolve disputes among engaging parties in both direct and indirect manners. On one hand, the proposed protocol provides direct dispute resolution. Considering the message 9.5 in the Payment Initialization Protocol, we can prove that the bank is the originator of this message since h(IDM , SN, CLTR, TTR, Yi) can be retrieved by only the client and the bank, but the client does not have the secret Zj. Thus, the client is not the originator of the message. On the other hand, some protocol messages provide indirect dispute resolution. Considering the message 9.10 sent from the merchant to the client in the Extra Credit Request Protocol, although the client can generate this message by herself, she cannot modify the content of the message since it will later be detected by the bank.

Private Information

In any payment system, the information that is known only by relevant parties, such as secret keys, bank account information, price, or goods descriptions, is considered as private information 61. Revealing such information offers an opportunity to perform various kinds of attacks or to trace the client’s spending behavior.
In our proposed protocol, c0 and cjmax are transmitted in encrypted forms compared to signed messages in PayWord and clear text in PayFair Yen01. Moreover, only cj is sent from the client to the bank over the air interface. The bank can infer c0 from c0 = hn(c, Ttt), where n stands for the current CLTR, and later sends c0 to the merchant in the message 9.4. Therefore, the secrecy of the requested amount is preserved.

Secret Keys

The proposed micropayment protocol deploys the set of three different secrets
{X, Y, Z} shared among engaging parties. These secrets are used as encrypting keys and the keys for keyed-hash functions that must be updated periodically or upon the requests by engaging parties. It is suggested that, to increase performance of the system and to reduce the frequency of performing key distribution process, after the secrets X, Y , and Z have been distributed, each engaging party applies the key generation technique presented in section 8.3 in order to generate the sets of session keys Xi, Yi, and Zj, where i, j = 1, …, n, and then uses these session keys in transactions. The security analysis of the proposed key generation technique has been provided in section 8.4.

Trust Relationships among Engaging Parties

In PayFair the client is assumed to fully trust the bank in that the bank will not impersonate as the client to perform transactions to any merchants since all secrets of the client are known to the bank. Such an assumption is too s