Trust Relationships among Engaging PartiesIn 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 strong because, practically, the bank in the protocol may be a payment gateway which is a company monitoring payment traffic and acts as a medium between the client and the merchant at the Internet side and between the client’s and the merchant’s financial institutions at the banking private net- work side. It may possibly have a conspiracy with an attacker or generate a fake the client’s request by itself.
Based on the trust relationships among engaging parties stated in the the Definition 3.11 of the proposed formal model, in the proposed protocol, we state partial trust relationship between the client and the bank instead. The bank cannot generate any fake request since each message sent from the client is composed of the components or the secrets which cannot be generated or known to the bank. Therefore, the above problem is solved. Performance AnalysisTo demonstrate the practicability of the proposed protocol, we compare our protocol with PayWord RS96, PayFair Yen01, and Park et al.’s protocol PBD01, in terms of transaction performance by focusing on the computation at engaging parties and the number of message passes in the protocol. Our comparison criteria is based on the proposed formal mobile payment model presented in section 3.1.
11.Party’s ComputationConsidering the party’s computation, we mainly focus on the number of cryptographic operations applied to each engaging party. We compare our post- paid micropayment protocol with PayWord RS96 and Park et al.’s protocol PBD01 and our prepaid micropayment protocol with PayFair Yen01.
Tables 9.1-9.4 demonstrate the comparison stated above. Note that, from the tables, n stands for the computation for generating a set of coins, p and q stand for public-key parameters which are large prime numbers, H stands for hash function, and KH stands for keyed-hash function (or MAC).Moreover, considering the following situation, we assume that the client receives a bank coupon and performs transactions with 10 different merchants. There are 20 times that the client performs the transactions which exceed the limit specified to each merchant. Note that in PayFair , when the requested payment order exceeds the limit specified to each merchant, the client has to repeat the entire protocol steps to get a new coupon, whereas, in the proposed protocol, the client can run the ECR Protocol to request the bank for extra credits. Table 9.
2 demonstrates the computation at the client of each protocol under the above situation.From Tables 9.1 and 9.
2, it can be seen that, in 1 transaction, the computation at the client of PayFair is slightly lower than that of the proposedCryptographic Operations Our PrepaidProtocol PayFairSignatureGeneration CM B — —SignatureVerification CM B — —SymmetricOperation CM B 112 1- 2Hash function (H) CM B nn n nn nKeyed-hashfunction (KH) CM B 413 345Session-keyGeneration CM B 2KH2KH2KH —CommunicationOverhead CM B — —Table 9.1: The number of cryptographic operations applied to our proposed prepaid protocol and PayFair in 1 transactionCryptographic Operations Our Prepaid Protocol PayFair1. Signature generation – -2. Signature verification – -3. Symmetric operation 10 2004.
Hash function (H) 10n 200n5. Keyed-hash function (KH) 430 600Table 9.2: The number of cryptographic operations at client applied to the proposed prepaid protocol and PayFair, respectively; when the client performs transactions with 10 different merchants and there are 20 times that she spends the coins over the limit specified to each merchant prepaid protocol. This is because our protocol deploys the session key generation technique (presented in section 8.2) that produces limited-used secret keys in order to enhance the security of the system, whereas PayFair deploys long-term, reusable, shared secrets among parties. The concern about security in the deployment of reusable, long-term, shared secrets has been discussed in section 2.
6. Moreover, the proposed protocol satisfies non-repudiation prop- erty, whereas PayFair does not. In higher number of transactions, it is clear that our prepaid protocol has lower number of client’s computation than Pay- Fair due to the feature of our proposed ECR Protocol.Cryptographic Operations Our PostpaidProtocol PayWord Park et al.’sProtocolSignaturegeneration CM B — 1- 1 —Signatureverification CM B — 122 —Symmetricoperation CM B 211 — —Hash function (H) CM B nn n nn n nn nKeyed-hashfunction (KH) CM B 2- 2 — 322Session-keygeneration CM B 2KH2KH2KH — —Communicationoverhead CM B — 2|p|+2|q |2|p|+2|q |3|p|+3|q | —Table 9.
3: The number of cryptographic operations applied to the proposed postpaid protocol, PayWord , and Park et al.’s protocol in 1 transaction Comparing the proposed postpaid micropayment protocol to the existing protocols, it can be seen in Table 9.3 that our protocol has lower client’s computation than PayWord This is because, in our protocol, only symmetric-key operations and hash functions are applied, whereas PayWord deploys public-key operations. Also, the communication load of PayWord is higher than that of our protocol.
This infers that the proposed postpaid protocol has better performance than PayWord. However, as shown in Table 9.3, the client’s computation of Park et al.’s protocol is slightly lower than that of our
