To merchant up to the amount specified

To make a payment to the merchant, the client generates a merchant coupon containing the value specified to the merchant. The value of the merchant coupon must not exceed the value of the bank coupon. This coupon has to be validated by the bank before being used.

To validate the merchant coupon, the client generates a set of coins, attaches it into the merchant coupon, and sends the merchant coupon to the bank. After the validation, the bank transfers the amount equivalent to the value of the coins to the merchant’s account. Then, the client can make payment to the merchant up to the amount specified in the merchant coupon.In the proposed protocol, the bank is trusted by the client to generate the correct number and value of the coins for coin validation purpose, but it is nottrusted to create payment initialization requests to merchants by itself. This is because the bank itself can generate the sets of coins.

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!

order now

It is possible to generate fake requests on behalf of its clients according to the trust relationships among engaging parties stated in the Definition 3.11 of the proposed formal model. Initial AssumptionsThe initial assumptions of the proposed protocol are given as follows: 1. The client shares a long-term secret CCI with the bank.

CCI represents the client’s account information which is known only between the client and the bank.2. Three secrets are shared among engaging parties as follows:• X is shared between the client and the merchant.• Y is shared between the client and the bank.• Z is shared between the merchant and the bank.The above secrets are distributed and updated periodically or upon the requests by the engaging parties. After the secrets X, Y , and Z have been distributed, each party generates the sets of secrets Xi, Yi, and Zj, where i, j = 1, .

.., n, by using the session key generation techniques presented in sections 8.

3.2, 8.3.1, and 8.3.

3, respectively, and stores them on each party’s device. These sets of secrets will be used as encrypting keys in the protocol. The purpose of generating these sets of keys is to reduce the frequency of key update process and to enhance security of the system. Note that such secrets can be distributed by using an authenticated key- exchange (AKE) protocol for wireless networks. The details of existing AKE protocols for wireless networks have been presented in section 4.


The bank is trusted by the client in that it will not reveal the client’sCCI to other parties.4. h(X, K) represents the keyed-hash value of a message X with the key K. It can be presented by Message Authentication Code (MAC) to achieve higher security.Our proposed protocol is composed of 6 sub-protocols: Setup, Payment Initialization, Payment, Extra Credit Request, Coupon Cancellation, and Coin Return protocols. Sections 9.2.3 to 9.

2.8 demonstrate the details of each sub- protocol. The proposed protocol is depicted in Figure 9.1. Setup ProtocolIn Setup Protocol, the client requests the bank for the authorization on making a micropayment transaction with the amount CLT as follows:C?B : IDC, CLT , TCP , h(CLT , TCP , Yi), r (9.1)Note that CLT stands for total credits that the client is allowed to spend in the system. TCP stands for the timestamp while generating the request.

r stands for a random number used to generate the set of Yi (referred to the technique for generating the set of Yi presented in section 8.3.1).

h(CLT , TCP , Yi) is used to protect integrity of the message. The bank checks the validity of the client’s account and then deducts the amount CLT from the client. The bank sends the client a bank coupon that can be used to perform transactions.Client Merchant BankFigure 9.1: The proposed micropayment protocol The bank coupon contains a unique serial number SN assigned by the bank and authorized credits CLT . TT stands for timestamp while issuing CLT , and c is a random number generated by the bank used for generating coins.

With this bank coupon, the client can make payment to many merchants repeatedly up to CLT . After running out of the credits, the client needs to run this protocol to request the bank for a new CLT again. Payment Initialization ProtocolTo make a payment to the merchant, the client generates a set of coins cj, where j = 0, ..

., m, m = CLT , as follows:cm = {c, Ttt}cj = h(cj+1) where j = 0, …, m ? 1The client specifies the amount CLM to spend with the merchant. The client attaches the coins and CLM into a merchant coupon, and sends the coupon to the bank: C?B : h(IDM , c0, Ttt, CLM , CLT , TT , SN, Yi),h(c0, Ttt, CLM , s, Xi), Ttt, s (9.

3) where Ttt stands for the timestamp while generating the set of coins. s stands for a random number used for generating the set of Xi (referred to section 8.3.2). Note that the client can either spend the entire credits to only one merchant or spend some credits to this merchant and spend the rest to other merchants.

We can see that h(c0, Ttt, CLM , s, Xi) represents a part of Payment Ordering request (referred to the Definition 3.6 of the proposed formal model) from the client to the merchant which is unreadable by the bank. The bank retrieves CLT and CLM from h(IDM , c0, Ttt, CLM , CLT , TT , SN, Yi), which is considered as a Debit request, and checks whether